[Ovmsdev] sprintf / crashes
Mark Webb-Johnson
mark at webb-johnson.net
Thu Dec 20 22:38:52 HKT 2012
If you go to project settings, C18 / MPLINK, you can set a map file for the linker. Looking at what has been generated for a V2 experimental build, I get:
...
__AARGB4 0x000025 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
__AARGB3 0x000026 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
__AARGB2 0x000027 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
__AARGB1 0x000028 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
__AARGB0 0x000029 data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
__AEXP 0x00002a data extern C:\MCC18\v3_39\src\traditional\math\aarg.asm
__BARGB3 0x00002b data extern C:\MCC18\v3_39\src\traditional\math\barg.asm
__BARGB2 0x00002c data extern C:\MCC18\v3_39\src\traditional\math\barg.asm
__BARGB1 0x00002d data extern C:\MCC18\v3_39\src\traditional\math\barg.asm
__BARGB0 0x00002e data extern C:\MCC18\v3_39\src\traditional\math\barg.asm
__BEXP 0x00002f data extern C:\MCC18\v3_39\src\traditional\math\barg.asm
__TEMPB3 0x000030 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
__TEMPB2 0x000031 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
__TEMPB1 0x000032 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
__TEMPB0 0x000033 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
__TEMP 0x000033 data extern C:\MCC18\v3_39\src\traditional\math\temparg.asm
DelayCounter1 0x000034 data extern C:\MCC18\v3_39\src\traditional\delays\delayd1.asm
ovms_firmware 0x000060 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_linevoltage 0x000063 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_chargecurrent 0x000065 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_chargelimit 0x000066 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_chargeduration 0x000067 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_chargestate 0x000069 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_chargesubstate 0x00006a data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_chargemode 0x00006b data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_charge_b4 0x00006c data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_chargekwh 0x00006d data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_doors1 0x00006e data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_doors2 0x00006f data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_doors3 0x000070 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_doors4 0x000071 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_lockstate 0x000072 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_speed 0x000073 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_SOC 0x000074 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_idealrange 0x000075 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_estrange 0x000077 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_time 0x000079 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_parktime 0x00007d data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_ambient_temp 0x000081 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_vin 0x000082 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_tpem 0x000094 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_tmotor 0x000095 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_tbattery 0x000096 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_tpms_t 0x000097 data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_tpms_p 0x00009b data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
car_trip 0x00009f data extern /Users/mark/Documents/vm shared/ovms/Open-Vehicle-Monitoring-System/vehicle/OVMS.X/ovms.c
...
The firmware version number is right at the start, so that would explain why I'm seeing it overwritten. It is the most vulnerable.
As you can see, tpms is a little further down.
The net buffers are much later.
Data usage summary is:
Section Info
Section Type Address Location Size(Bytes)
--------- --------- --------- --------- ---------
.idata_ovms.o idata 0x000060 data 0x000069
.idata_vehicle.o idata 0x0004d8 data 0x000028
.idata_net.o idata 0x0005c8 data 0x00002c
.idata_vehicle_twizy.o idata 0x0007e8 data 0x000014
SEED_DATA idata 0x0007fc data 0x000002
.idata_led.o idata 0x0008c7 data 0x000005
.idata_stokpr.o idata 0x0008cc data 0x000002
.idata_diag.o idata 0x000900 data 0x0000b9
.idata_net_sms.o idata 0x000a5e data 0x00005d
.idata_net_msg.o idata 0x000abb data 0x000045
.idata_crypt_md5.o idata 0x000b00 data 0x000040
MATH_DATA udata 0x000020 data 0x000014
DELAYDAT1 udata 0x000034 data 0x000001
.udata_ovms.o udata 0x0000c9 data 0x00002d
.udata_c018i.o udata 0x0000f6 data 0x00000a
TX_CRYPTO udata 0x000100 data 0x000100
RX_CRYPTO udata 0x000200 data 0x000100
PM_CRYPTO udata 0x000300 data 0x000100
.udata_crypt_hmac.o udata 0x000400 data 0x0000d8
NETMSG_SP udata 0x000500 data 0x0000c8
.udata_crypt_base64.o udata 0x0005f4 data 0x000008
.udata_net.o udata 0x0005fc data 0x000003
.udata_led.o udata 0x0005ff data 0x000001
NETBUF_SP udata 0x000600 data 0x0000c8
.udata_net_msg.o udata 0x0006c8 data 0x000026
.udata_vehicle.o udata 0x0006ee data 0x000012
NETBUF udata 0x000700 data 0x0000c8
.udata_params.o udata 0x0007c8 data 0x000020
.udata_vehicle_twizy.o udata 0x0007fe data 0x000002
.udata_UARTIntC.o udata 0x000800 data 0x0000c7
.udata_crypt_md5.o udata 0x0009b9 data 0x000040
.udata_net_sms.o udata 0x0009f9 data 0x000007
vehicle_overlay_data udata 0x000a00 data 0x00005e
.stack udata 0x000c00 data 0x000100
SFR_BANKED0 udata 0x000d60 data 0x00000c
SFR_BANKED1 udata 0x000d70 data 0x00000c
SFR_BANKED2 udata 0x000d80 data 0x00000c
SFR_BANKED3 udata 0x000d90 data 0x000004
SFR_BANKED4 udata 0x000dd4 data 0x000002
SFR_BANKED5 udata 0x000dd8 data 0x000001
SFR_BANKED6 udata 0x000de0 data 0x000008
SFR_BANKED7 udata 0x000df0 data 0x000004
SFR_BANKED8 udata 0x000df8 data 0x000001
SFR_BANKED9 udata 0x000dfa data 0x000001
SFR_BANKED10 udata 0x000dfc data 0x000001
SFR_BANKED11 udata 0x000e20 data 0x000060
SFR_BANKED12 udata 0x000f00 data 0x000060
SFR_UNBANKED0 udata 0x000f60 data 0x000018
SFR_UNBANKED1 udata 0x000f80 data 0x000080
Interestingly, you can see you 0x100 byte stack.
Still looking, but I reckon the problem is more likely to be sprintf() or library based than our net / net_msg / sms handlers.
Regards, Mark.
On 20 Dec, 2012, at 9:42 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>
> Micheal,
>
> My 49,51,51 is 0x31, 0x33, 0x33 - or "1", "3", "3" - similar to your 0x30 "0".
>
> 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?
>
> Or, perhaps, sprintf() somewhere is going crazy and printing numbers?
>
> Regards, Mark.
>
> On 20 Dec, 2012, at 9:29 AM, Mark Webb-Johnson wrote:
>
>> Michael,
>>
>> I think our revisions overlapped. I'd just merged in all your previous changes, plus documentation and server code updates.
>>
>> 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.
>>
>> 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).
>>
>> 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 :-)
>>
>> 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).
>>
>> Running v2.1.1 in my car, I have seen the firmware version go bizarre about a month ago:
>>
>> 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)
>> 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)
>>
>> That is a sprintf().
>>
>> Regards, Mark.
>>
>> On 20 Dec, 2012, at 9:13 AM, Michael Balzer <dexter at expeedo.de> wrote:
>>
>>> Mark,
>>>
>>> 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.
>>>
>>> I've had no garbled strings since and can now fetch all my history rows from the server, so it had some positive effect.
>>>
>>> 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.
>>>
>>> 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
>>> When that occured, a lot of other data was displayed wrong as well.
>>> 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?
>>>
>>> Regards,
>>> Michael
>>>
>>>
>>>
>>> Am 18.12.2012 02:39, schrieb Mark Webb-Johnson:
>>>>
>>>> In general, I try to minimise stack and ram usage on the small PICs.
>>>>
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>> Regards, Mark.
>>>>
>>>> On 18 Dec, 2012, at 8:05 AM, Michael Balzer wrote:
>>>>
>>>>> Mark,
>>>>>
>>>>> the client_app.pl hint was good, I had not recognized that as a server query utility yet.
>>>>>
>>>>> I removed the comma (misread the draft) and can now see my H entries. However, that lead me back to my assumed connectivity issue:
>>>>>
>>>>> MP-0 c31,0,2,6,RTPWR-BattCell,1,1,76,2012-12-17 23:18:43,2012-12-17 23:18:43
>>>>> MP-0 c31,0,3,6,RT-PWR-BattCell,14,16,1215,2012-12-17 23:13:11,2012-12-17 23:18:43
>>>>> 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
>>>>> MP-0 c31,0,5,6,RT-PWR-BattPack,1,2,202,2012-12-17 23:13:11,2012-12-17 23:18:43
>>>>> MP-0 c31,0,6,6,RT-PWR-Usag,1,1,45,2012-12-17 23:13:11,2012-12-17 23:13:11
>>>>>
>>>>> 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).
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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?
>>>>>
>>>>> 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...
>>>>>
>>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121220/09f1a410/attachment.htm>
More information about the OvmsDev
mailing list