[Ovmsdev] OVMS v3.3 hardware

[Mark Webb-Johnson]

The ‘devel’ state was intended for debugging and development work on the modem. It puts the cellular driver code into a state where it doesn’t send commands any more, and displays transmit/receive traffic as dumps. You can put it into this mode with ‘power cellular devel’ (usually after the modem MUX is up).

I’m still working trying to find out why the modem driver gets into this weird state. When I see it, if I ‘power cellular off’, wait for power down, then ‘power cellular on’, the connection is re-established. Similarly, resetting the module re-establishes the connection. Given that we already power cycle the modem if the connection can’t be established for a while, the problem is clearly in the driver code. Most likely the UART. Early on in the 3.3 project I tried completely clearing that (including PPP) but ran into bugs in the esp32 hardware/IDF corrupting memory. I will try again.

Regards, Mark.

> On 2 Jan 2022, at 5:55 AM, Craig Leres <leres at xse.com> wrote:
> 
> 
> I've seen my dev modem go into "user interrupt" several times without accompanying uart fifo overflows. So now I doubt there is any connection between these two issues.
> 
> I've been thinking that a strategy for debugging the "User Interrupt" issue would be to wait for the modem to get stuck and then send commands. But I guess ppp is implemented in esp-idf? (Maybe I should compare with a recent esp-idf to see if there are any interesting changes?) Still, I wanted to be able to send commands to the modem without fighting with the modem driver. When I looked I found there was already a Development modem state but it isn't registered as a command and I didn't see how it could be enabled. Is this a reasonable thing for me to create a PR to add it?
> 
>    @@ -1679,7 +1693,7 @@ CellularModemInit::CellularModemInit()
>       cmd_status->RegisterCommand("debug","Show extended CELLULAR MODEM status",cellular_status, "", 0, 0, false);
> 
>       OvmsCommand* cmd_setstate = cmd_cellular->RegisterCommand("setstate","CELLULAR MODEM state change framework");
>    -  for (int x = modem::CheckPowerOff; x<=modem::PowerOffOn; x++)
>    +  for (int x = modem::CheckPowerOff; x<=modem::Development; x++)
>         {
> cmd_setstate->RegisterCommand(ModemState1Name((modem::modem_state1_t)x),"Force CELLULAR MODEM state change",modem_setstate);
>         }
> 
> I tried that but then it's very difficult to do anything interactive with the modem when in Development state due to the many printouts that get enabled, e.g:
> 
>    void modem::tx(uint8_t* data, size_t size)
>      {
>      if (!m_task) return; // Quick exit if not task (we are stopped)
> 
>      if (m_state1 == Development)
>        { DevelopmentHexDump("tx", (const char*)data, size); }
> 
>      uart_write_bytes(m_uartnum, (const char*)data, size);
>      }
> 
> (I get flooded with the gnss/nmea messages.) What's a good way to add the ability to disable these? A new "Development2" state? Maybe tie these messages to a new "cellular-trace" tag?
> 
> 		Craig
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev