[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