[Ovmsdev] New features: sufficient charge alerts, ideal max range

Wed Nov 14 09:50:17 HKT 2012

Michael,

Urgh. Those are really hard to track down.

I don't think we really have any loops that go crazy.

A couple of guesses / things to look for:

My first guess would be RAM shortage and stack overflow (RAM usage has been growing lately, and is something I've been looking at in the v2 branch I'm working on).

Another thing to look at (tied to your can overflow problem) is if your can bus filters are working correctly. Perhaps count the number of messages received and make sure it is not excessive?

Are you running this code in DEBUG mode in the car? If so, can you try RELEASE mode to see if it makes a difference.

We do get the occasional report of a module reset (we know because users using the digital speedo feature report it when it happens, as they lose the non-permanent feature on reboot and the digital speedo mod stops working). Mine has been running 1.5.1 for more than a month now, and hasn't reset in that time.

Regards, Mark.

On 14 Nov, 2012, at 1:41 AM, Michael Balzer wrote:

> Mark,
> 
> I'm sure it was a full reset, and they still occur frequently, but only while charging it seems.
> 
> I just checked RCON and STKPTR: it seems the resets are due to watchdog timeouts (TO).
> 
> Do I need to instrument the code with some checkpoints (storing checkpoint ids into a persistent feature) to track down where this occurs, or is there an easier way?
> 
> Do you have a suggestion where to go hunting first? It's most probably not in my Twizy code, as I've got no loop condition at all.
> 
> Thanks,
> Michael
> 
> 
> PS: here's the RCON checking code for others trying to debug similar problems:
> 
> Insert this right at the top of main() just after clearing sys_features[]:
> 
>   // DEBUG: save last reset reason in feature 7 (RCON bits inverted for readability):
>   sys_features[7] = (~RCON) & 0x1f;
>   if( STKPTRbits.STKFUL ) sys_features[7] += 32;
>   if( STKPTRbits.STKUNF ) sys_features[7] += 64;
>   // ...and clear RCON:
>   RCONbits.NOT_BOR = 1;     // b0 = 1  = Brown Out Reset
>   RCONbits.NOT_POR = 1;     // b1 = 2  = Power On Reset
>   //RCONbits.NOT_PD = 1;    // b2 = 4  = Power Down detection
>   //RCONbits.NOT_TO = 1;    // b3 = 8  = watchdog TimeOut occured
>   RCONbits.NOT_RI = 1;      // b4 = 16 = Reset Instruction
> 
> => a feature dump will show the last reset reason.
> 
> 
> 
> Am 12.11.2012 01:07, schrieb Mark Webb-Johnson:
>> Michael,
>> 
>> The feature #10 was somewhere we suspected was a problem, so added the record there. But, I too have never seen it fire. I was planning on removing the check for the next firmware.
>> 
>> The modem resetting, in GSM/GPRS outages, is normal and expected. But, the module should not reset under normal conditions. If you are seeing this, then it is either a code fault (an endless loop, most likely) or stack overflow, causing watchdog timer to fire.
>> 
>> When you say you saw the module reset, are you sure it wasn't a modem reset? If the module resets you'll get the firmware version being blinked out. Modem resets are highlighted by both red and green leds being constant on for a second or two.
>> 
>> Regards, Mark.
>> 
>> On 12 Nov, 2012, at 12:56 AM, Michael Balzer wrote:
>> 
>>> Mark,
>>> 
>>> it doesn't seem the old Android App supports setting arbitrary features? I currently have to use SMS to set them.
>>> 
>>> I need these configs to be persistent as the module does quite a lot of resets at the moment, it seems especially if GPRS connectivity is bad.
>>> 
>>> I just had to take yet another persistent feature slot (13) in use to store my last known range due to permanently losing my range calculations during charge.
>>> 
>>> I tried to sort out why I get those resets and found the
>>>    // Temporary kludge to record in feature #10 the number of times this happened
>>> ...but my value was not increased, even after I watched the module doing a reset.
>>> 
>>> Is there another condition for an automatic reset? I found none...
>>> 
>>> I thought feature slots are especially meant for this kind of user configuration. I could avoid using feature slots at all if a) the module would only do a reset if absolutely needed (so I don't lose my local configuration) and b) I can introduce a car specific command to set my local configuration. Or is there another way?
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 11.11.2012 13:35, schrieb Mark Webb-Johnson:
>>>> Michael,
>>>> 
>>>> I guess you need these as features, so they can be set from the App?
>>>> 
>>>> If so, can they be put as experimental at the moment? Those won't survive a reboot, but are less impacting. I suggest 0x05, 0x06 and 0x07.
>>>> 
>>>> For MAXRANGE, that is fine. Make it a permanent feature, 0x0D.
>>>> 
>>>> Regards, Mark.
>>>> 
>>>> On 11 Nov, 2012, at 7:42 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>>> 
>>>>> Mark,
>>>>> 
>>>>> I just checked in my latest Twizy updates:
>>>>> 
>>>>> https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/0a70e483baf182f4226d1a1afc8d0734c2fa48d9
>>>>> 
>>>>> These contain two extensions that could be generally useful:
>>>>> 
>>>>> 1) As the Twizy "ideal" range varies widely depending on your driving, geography and environment, I implemented a feature for that config.
>>>>> 
>>>>> 2) If I just need an intermediate charge for a certain SOC or range (to get home for example), I can now activate an alert for one or both values.
>>>>> 
>>>>> I used the next three free feature slots for these:
>>>>> 
>>>>> #define FEATURE_SUFFSOC      0x0A // Sufficient SOC feature
>>>>> #define FEATURE_SUFFRANGE    0x0B // Sufficient range feature
>>>>> #define FEATURE_MAXRANGE     0x0C // Maximum ideal range feature
>>>>> 
>>>>> I know, feature slots are getting full... what do you think?
>>>>> 
>>>>> Regards,
>>>>> Michael
>>>>> 
>>>>> -- 
>>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>>> 
>>>>> <dexter.vcf>_______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> 
>>> -- 
>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>> 
>>> <dexter.vcf>_______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> -- 
> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
> <dexter.vcf>_______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121114/ae32c53d/attachment.htm>