<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Micheal,<div><br></div><div>My 49,51,51 is 0x31, 0x33, 0x33 - or "1", "3", "3" - similar to your 0x30 "0".</div><div><br></div><div>The base64 stuff in net_msg and net comms is mostly lower and uppercase letters. We see ascii encoded numbers in VINs and GPS mostly (but I am using the car's GPS and you are using the ovms module's GPS). Anywhere else we'd expect to see long strings of ascii encoded numbers?</div><div><br></div><div>Or, perhaps, sprintf() somewhere is going crazy and printing numbers?</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 20 Dec, 2012, at 9:29 AM, Mark Webb-Johnson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael,<div><br></div><div>I think our revisions overlapped. I'd just merged in all your previous changes, plus documentation and server code updates.</div><div><br></div><div>I did make some minor layout fixes (where the indentation was wrong - I think you are using 4 spaces, or perhaps tabs, where the rest of the project uses 2). I also added your pseudo-command #6 to the protocol document.</div><div><br></div><div>Can you merge in my changes, then re-push yours? I'd like to get this v2 branch complete today and merge back into master tonight (my time).</div><div><br></div><div>Going forward, do you still want to maintain and work off your clone, or would it be easier if I just gave you write access to the main project? Your contributions are so helpful and good, that there is little I am having to do other than just accept them :-)</div><div><br></div><div>For the watchdog reboot and occasional ram trashing, I too suspect the NET, NET_MSG or SMS code. It is the only place where things are externally controlled to result in variable length strings. I did review it a while ago, but didn't see anything obvious. The other possibility is sprintf() elsewhere in the code (such as STAT).</div><div><br></div><div>Running v2.1.1 in my car, I have seen the firmware version go bizarre about a month ago:</div><div><br></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>2012-11-21 07:32:06.388834 -0500 info main: #74 C EV915 rx msg F 2.1.1/V2,SFZRE8B15B3000569,1,1,TR2N,3(2G)<br>2012-11-21 07:34:58.845568 -0500 info main: #61 C EV915 rx msg F 49.51.51/V2,SFZRE8B15B3000569,1,1,TR2N,3(2G)</div></blockquote></div><div><br></div><div>That is a sprintf().</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 20 Dec, 2012, at 9:13 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> 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've rewritten all my sprintf() calls now. I introduced a new
general string utils family to ease avoiding sprintf(), see my utils
module addition.<br>
<br>
I've had no garbled strings since and can now fetch all my history
rows from the server, so it had some positive effect.<br>
<br>
But the watchdog timeout reboots still occur, they still
occasionally trash variables and I once still got the STKUNF flag
from the reboot. That feels like some uninitialised pointer or
writing beyond array / string bounds. I'm about to review the basic
net code, if you've got an idea where to look first, tell me.<br>
<br>
An example of the RAM trashing can still be seen on the server: MP-0
W17.4,8,17.4,8,17.4,8,17.4,8,-1<br>
When that occured, a lot of other data was displayed wrong as well.<br>
The TPMS vars never get written to by the twizy module. The values
17.4 & 8 mean both car_tpms arrays had been filled completely
with 0x30 or '8'. Does that ring a bell?<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 18.12.2012 02:39, schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote cite="mid:86ED4BD2-42C3-4F65-8279-40A4B22E2199@webb-johnson.net" type="cite">
<div><br>
</div>
In general, I try to minimise stack and ram usage on the small
PICs.
<div><br>
</div>
<div>Early on in OVMS, we had a bunch of local variables, and some
were quite large. We were getting all sorts of random weird
behavior (reboots, corrupt messages, etc). Since we changed to
global variables, and very limited use of stacked function calls
and local variables, things have been much better.</div>
<div><br>
</div>
<div>I agree that a large sprintf may be the cause of your
problems. Can you try to change to itoa() and strcat(), to see
if it makes an impact?</div>
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
<div>
<div>On 18 Dec, 2012, at 8:05 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>
the client_app.pl hint was good, I had not recognized that
as a server query utility yet.<br>
<br>
I removed the comma (misread the draft) and can now see my
H entries. However, that lead me back to my assumed
connectivity issue:<br>
<br>
MP-0 c31,0,2,6,RTPWR-BattCell,1,1,76,2012-12-17
23:18:43,2012-12-17 23:18:43<br>
MP-0 c31,0,3,6,RT-PWR-BattCell,14,16,1215,2012-12-17
23:13:11,2012-12-17 23:18:43<br>
MP-0 c31,0,4,6,RT-PWR-BattC�ll,1,1,65,2012-12-17
23:18:43,2012-12-17 23:18:43<br>
MP-0 c31,0,5,6,RT-PWR-BattPack,1,2,202,2012-12-17
23:13:11,2012-12-17 23:18:43<br>
MP-0 c31,0,6,6,RT-PWR-Usag,1,1,45,2012-12-17
23:13:11,2012-12-17 23:13:11<br>
<br>
This C31 result shows all kinds of garbled chars in my
module's messages, and even a truncation on
"RT-PWR-UsageStats" (also missing parts on the data blob
on that one).<br>
<br>
Now that's a bit odd and most probably cannot be connected
to a GPRS link failure -- as that would not garble single
bytes in a TCP connection.<br>
<br>
I could fix some similar output problems in DIAG mode more
than once by reducing complex sprintf() calls, so I
searched for C18 sprintf() stack usage and found nothing
concrete, but many warnings about very high stack usage of
the whole printf family, plus advice not to use them at
all on small embedded systems. One source mentioned
sprintf() will need 70+ bytes stack for a simple integer
template.<br>
<br>
I also have read a bit into the C18 software stack
management and found my previous assumption to be correct:
it's currently fixed to bank 12 (0xC00), so provides 256
bytes for any kind of parameter + local vars combination.
I think sprintf() on a 256 byte stack could well be a
source of problems... and stack overruns can produce weird
effects, as those above. I think about rewriting all my
sprintf calls to itoa/ltoa/ultoa, but find it strange they
did no harm up to now, even with complex templates as in
net_msgp_environment(). Or maybe they did, unrecognized?<br>
<br>
Do you have some other info on C18 sprintf()? I'd rather
avoid recoding every output without sprintf(), but that's
my best bet currently...<br>
<br>
Regards,<br>
Michael<br>
<br>
</div>
</blockquote>
</div>
</div>
</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><a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br></blockquote></div><br></div></div></blockquote></div><br></div></body></html>