[Ovmsdev] Crashes with streaming mode
Mark Webb-Johnson
mark at webb-johnson.net
Wed May 1 21:05:58 HKT 2013
Michael,
No hardware flow control in OVMS circuit. But, we are only 9600baud and interrupt-driven - I think it should be ok.
My concern is RAM - say we have two channels open, we're going to need 2 more line buffers.
Here is the latest 'map' file:
Section Type Address Location Size(Bytes)
--------- --------- --------- --------- ---------
TX_CRYPTO udata 0x000100 data 0x000100
RX_CRYPTO udata 0x000200 data 0x000100
PM_CRYPTO udata 0x000300 data 0x000100
.stack udata 0x000c00 data 0x000100
.udata_crypt_hmac.o udata 0x000400 data 0x0000d8
NETMSG_SP udata 0x000500 data 0x0000c8
NETBUF_SP udata 0x000600 data 0x0000c8
NETBUF udata 0x000700 data 0x0000c8
.udata_UARTIntC.o udata 0x000800 data 0x0000c7
LOGGING udata 0x000060 data 0x000088
SFR_UNBANKED1 udata 0x000f80 data 0x000080
.idata_ovms.o idata 0x000900 data 0x000070
vehicle_overlay_data udata 0x000970 data 0x00006e
.idata_net_sms.o idata 0x000a00 data 0x000063
SFR_BANKED12 udata 0x000f00 data 0x000060
SFR_BANKED11 udata 0x000e20 data 0x000060
.idata_net_msg.o idata 0x000a63 data 0x000045
.udata_crypt_md5.o udata 0x000aa8 data 0x000040
.idata_crypt_md5.o idata 0x000b00 data 0x000040
.idata_net.o idata 0x0005c8 data 0x000035
.udata_ovms.o udata 0x0006c8 data 0x000030
.idata_vehicle.o idata 0x0007c8 data 0x00002b
.udata_net_msg.o udata 0x0004d8 data 0x000026
.udata_params.o udata 0x0009de data 0x000020
.idata_diag.o idata 0x0008c7 data 0x00001b
SFR_UNBANKED0 udata 0x000f60 data 0x000018
.idata_vehicle_twizy.o idata 0x0000e8 data 0x000014
MATH_DATA udata 0x000020 data 0x000014
.udata_vehicle.o udata 0x000ae8 data 0x000012
SFR_BANKED2 udata 0x000d80 data 0x00000c
SFR_BANKED1 udata 0x000d70 data 0x00000c
SFR_BANKED0 udata 0x000d60 data 0x00000c
.udata_c018i.o udata 0x0007f3 data 0x00000a
.udata_crypt_base64.o udata 0x0006f8 data 0x000008
SFR_BANKED6 udata 0x000de0 data 0x000008
.udata_net_sms.o udata 0x0008e2 data 0x000007
.idata_led.o idata 0x000afa data 0x000005
SFR_BANKED7 udata 0x000df0 data 0x000004
SFR_BANKED3 udata 0x000d90 data 0x000004
.udata_net.o udata 0x0005fd data 0x000003
.idata_stokpr.o idata 0x0009fe data 0x000002
SFR_BANKED4 udata 0x000dd4 data 0x000002
SEED_DATA idata 0x0004fe data 0x000002
.idata_logging.o idata 0x0007fd data 0x000001
SFR_BANKED10 udata 0x000dfc data 0x000001
.udata_led.o udata 0x000aff data 0x000001
SFR_BANKED9 udata 0x000dfa data 0x000001
SFR_BANKED8 udata 0x000df8 data 0x000001
SFR_BANKED5 udata 0x000dd8 data 0x000001
DELAYDAT1 udata 0x000034 data 0x000001
Stack definitely seems separately accounted for. The TX_CRYPTO and RX_CRYPTO are the rc4 contexts. The PM_CRYPTO is for Paranoid Mode (a lot of RAM for that, considering how few use it).
The crypt_hmac needs 64 bytes for iPad, 64 bytes for oPad, then 70 bytes for a MD5_CTX. Looking at the code, a lot could be saved. It looks like the iPad and oPad could be merged (slightly slower code, but saves a lot). Then, the pad and context could be on the stack (134 bytes of 256 bytes) - scary but a big win.
The crypt_md5 PADDING (64 bytes) seems to be able to be moved to rom with little impact.
From there, the returns seem to diminish.
Regards, Mark.
On 1 May, 2013, at 6:18 PM, Michael Balzer <dexter at expeedo.de> wrote:
> Mark,
>
> I also see the current modem communication layer as a problem source. The read buffer only takes 128 bytes, which will not be sufficient for many situations -- e.g. a GPS response now needs already two NMEA sentences adding up to about 108 bytes -- come in another modem answer before the buffer gets handled, and bang we go...
>
> The multiplex mode is quite interesting, didn't know this before -- although a really fully asynchronous modem comm handling would not need that, I think. But it would need more buffer RAM...
>
> Hm... the SIM908 manual says: "In Multiplex mode, it is recommended to use the hardware flow control."
>
> As far as I understand the circuit schemes the current hardware does not connect RTS/CTS (pins 66+67) -- right?
>
> Regards,
> Michael
>
>
> Am 30.04.2013 03:28, schrieb Mark Webb-Johnson:
>> Michael,
>>
>> Looking at the design for 3G modules, I noticed something recommended for those modules that seems to be supported for the SIM900 base we use (both SIM900 OVMS v1 and SIM908 OVMS v2). CMUX mode.
>>
>> http://www.m2m-platforms.com/seminars/2007seminar_material/Telit_CMUX_2_M2M_Platforms_seminar_2007.pdf
>>
>> This is GSM 7.10 TE-MS multiplexor protocol.
>>
>> The main problem we have is co-ordinating all the different comms channels of OVMS onto a single serial link to the modem. Incoming SMSes, status indicators, outgoing GPRS TCP data, etc, all run over each other.
>>
>> The CMUX protocol appears to allow us to have 3 (or 4?) virtual async links, over a single physical async port. We could use one for SMS, another for TCP, and a third for GPS polling. The 3G modules even allow the GPS NMEA data to be streamed back over one of the virtual ports (but I don't think that is available in the SIM908 module we use - hard to tell as the CMUX documents focus on SIM900 not SIM908 [the SIM908 embeds SIM900 and adds GPS]).
>>
>> It would mean some major restructuring of the comms layer (NET), and we would have to build a small library to encode/decode GSM 7.10, but may be a much more stable approach in the long-term.
>>
>> SIMCOM seem to implement a subset of the full GSM 7.10 functionality. Here's the manual on it for SIM900:
>>
>> http://www.mt-system.ru/sites/default/files/sim900_multiplexer_user_manual_application_note_v1.3.pdf
>>
>> <Mail Attachment.png>
>>
>> Regards, Mark.
>>
>> On 29 Apr, 2013, at 11:48 PM, Michael Balzer wrote:
>>
>>> Am 28.04.2013 17:06, schrieb Michael Balzer:
>>>> I just checked in my fix for the USSD reply handler. My tests with streaming enabled did not produce any more crashes, so I think that was the problem.
>>>
>>> I was wrong, it's still crashing. I have to dig deeper it seems.
>>>
>>> Has anyone observed crashes with streaming mode on other vehicles, or is this a Twizy specific bug now?
>>>
>>> Thanks,
>>> 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
>
> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130501/6e015927/attachment.htm>
More information about the OvmsDev
mailing list