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

Wed Nov 14 01:41:54 HKT 2012

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 
>>> <mailto: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 <mailto:OvmsDev at lists.teslaclub.hk>
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto: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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121113/e919e0bf/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121113/e919e0bf/attachment-0002.vcf>