<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael,<div><br></div><div>Urgh. Those are really hard to track down.</div><div><div><br></div><div>I don't think we really have any loops that go crazy.</div><div><br></div><div>A couple of guesses / things to look for:</div><div><br></div><div><ul class="MailOutline"><li>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).<br><br></li><li>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?<br><br></li><li>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.</li></ul></div></div><div><br></div><div>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.</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 14 Nov, 2012, at 1:41 AM, Michael Balzer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
Mark,<br>
<br>
I'm sure it was a full reset, and they still occur frequently, but
only while charging it seems.<br>
<br>
I just checked RCON and STKPTR: it seems the resets are due to
watchdog timeouts (TO).<br>
<br>
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?<br>
<br>
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.<br>
<br>
Thanks,<br>
Michael<br>
<br>
<br>
PS: here's the RCON checking code for others trying to debug similar
problems:<br>
<br>
Insert this right at the top of main() just after clearing
sys_features[]:<br>
<br>
// DEBUG: save last reset reason in feature 7 (RCON bits inverted
for readability):<br>
sys_features[7] = (~RCON) & 0x1f;<br>
if( STKPTRbits.STKFUL ) sys_features[7] += 32;<br>
if( STKPTRbits.STKUNF ) sys_features[7] += 64;<br>
// ...and clear RCON:<br>
RCONbits.NOT_BOR = 1; // b0 = 1 = Brown Out Reset<br>
RCONbits.NOT_POR = 1; // b1 = 2 = Power On Reset<br>
//RCONbits.NOT_PD = 1; // b2 = 4 = Power Down detection<br>
//RCONbits.NOT_TO = 1; // b3 = 8 = watchdog TimeOut occured<br>
RCONbits.NOT_RI = 1; // b4 = 16 = Reset Instruction<br>
<br>
=> a feature dump will show the last reset reason.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 12.11.2012 01:07, schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote cite="mid:3411BF92-E961-4DA7-BFF8-D853AF21C9D2@webb-johnson.net" type="cite"><span class="Apple-style-span" style="font-family:
monospace; ">Michael,</span><span class="Apple-style-span" style="font-family: monospace; "><br>
</span><span class="Apple-style-span" style="font-family:
monospace; "><br>
</span><span class="Apple-style-span" style="font-family:
monospace; ">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.</span><span class="Apple-style-span" style="font-family: monospace; "><br>
</span><span class="Apple-style-span" style="font-family:
monospace; "><br>
</span><span class="Apple-style-span" style="font-family:
monospace; ">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.</span><span class="Apple-style-span" style="font-family: monospace; "><br>
</span><span class="Apple-style-span" style="font-family:
monospace; "><br>
</span><span class="Apple-style-span" style="font-family:
monospace; ">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.</span><span class="Apple-style-span" style="font-family:
monospace; "><br>
</span><span class="Apple-style-span" style="font-family:
monospace; "><br>
</span><span class="Apple-style-span" style="font-family:
monospace; ">Regards, Mark.</span><span class="Apple-style-span" style="font-family: monospace; "><br>
</span>
<div>
<div><br>
</div>
<div>On 12 Nov, 2012, at 12:56 AM, Michael Balzer wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>Mark,<br>
<br>
it doesn't seem the old Android App supports setting
arbitrary features? I currently have to use SMS to set them.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I tried to sort out why I get those resets and found the<br>
// Temporary kludge to record in feature #10 the number
of times this happened<br>
...but my value was not increased, even after I watched the
module doing a reset.<br>
<br>
Is there another condition for an automatic reset? I found
none...<br>
<br>
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?<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
Am 11.11.2012 13:35, schrieb Mark Webb-Johnson:<br>
<blockquote type="cite">Michael,<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">I guess you need these as features,
so they can be set from the App?<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">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.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">For MAXRANGE, that is fine. Make it
a permanent feature, 0x0D.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">Regards, Mark.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">On 11 Nov, 2012, at 7:42 AM, Michael
Balzer <<a moz-do-not-send="true" href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>>
wrote:<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Mark,<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">I just checked in my latest Twizy
updates:<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><a moz-do-not-send="true" href="https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/0a70e483baf182f4226d1a1afc8d0734c2fa48d9">https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/0a70e483baf182f4226d1a1afc8d0734c2fa48d9</a><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">These contain two extensions that
could be generally useful:<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">1) As the Twizy "ideal" range
varies widely depending on your driving, geography and
environment, I implemented a feature for that config.<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">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.<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">I used the next three free feature
slots for these:<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">#define FEATURE_SUFFSOC 0x0A
// Sufficient SOC feature<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">#define FEATURE_SUFFRANGE 0x0B
// Sufficient range feature<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">#define FEATURE_MAXRANGE 0x0C
// Maximum ideal range feature<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">I know, feature slots are getting
full... what do you think?<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Regards,<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Michael<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">-- <br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Michael Balzer * Paradestr. 8 *
D-42107 Wuppertal<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Fon 0202 / 272 2201 * Handy 0176 /
206 989 26<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><dexter.vcf>_______________________________________________<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">OvmsDev mailing list<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><a moz-do-not-send="true" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><a moz-do-not-send="true" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</blockquote>
<blockquote type="cite">_______________________________________________<br>
</blockquote>
<blockquote type="cite">OvmsDev mailing list<br>
</blockquote>
<blockquote type="cite"><a moz-do-not-send="true" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
</blockquote>
<blockquote type="cite"><a moz-do-not-send="true" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
<br>
-- <br>
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal<br>
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26<br>
<br>
<span><dexter.vcf></span>_______________________________________________<br>
OvmsDev mailing list<br>
<a moz-do-not-send="true" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
</div>
<span><dexter.vcf></span>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>