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