SLM "Ready" has garbage prefix

[Konstantin Klitenik]

When running SLM on nrf91, it sends "Ready\r\n" over UART on boot/reset. On nrf54, we use "Ready" to detect reboots and rerun the setup. However, when the modem reboots, sometimes it has a prefix character in front of "Ready" (see log below, prefix c0), which breaks modem handler parsing. This doesn't always happen and the character varies, which leads me to believe it's UART noise while SLM is booting up.

[00:00:04.346,176] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: RECV
                                                c0 52 65 61 64 79 |.Ready

What has worked for us is changing SLM_SYNC_STR to include \r\n before it. This way any garbage gets flushed out by the handler on nrf54, and "Ready" is parsed correctly.

#define SLM_SYNC_STR     "\r\nReady\r\n"

[00:00:40.903,648] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: RECV
                                              ff |.
[00:00:40.903,712] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: RECV
                                              52 65 61 64 79 |Ready
[00:00:40.903,712] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: match cmd [Ready] (len:5)

If this solution makes sense, please incorporate into `ncs-serial-modem` repo. If not, I'd be interested in other settings that could fix this issue. Or if there is a better way to detect SLM reboot, I'm open to suggestions.

Thanks,

Konstantin

[Simon D-M]

Hi, Konstantin,

Just to be sure we are on the same page, you have 2 MCUs connected with a UART bus. One is a nrf9151 and the other is a nrf54(Lxx?). On the nrf9151 you have the SLM app running, and you want to use it through the nrf54 using the UART bus. When the nrf9151 reboots, the UART sometimes has noise on it, thus the nrf54 reads corrupted data.

Am correct with the situation ? 

However, when the modem reboots, sometimes it has a prefix character in front of "Ready"

Can you please precise how you reboot the modem ? Is it with the RESET pin, the ENABLE pin, AT#RESET, ... ?

I'm wondering if this is not that the nrf9151 tries to send something on the UART and gets interrupted by a reboot, thus do not send a termination character. And when the "Ready" message comes, the nrf54 already has something in the buffer. 

I'm thinking that because I am not sure if this really is noise or if it is sent by something.

If this solution makes sense, please incorporate into `ncs-serial-modem` repo. If not, I'd be interested in other settings that could fix this issue. Or if there is a better way to detect SLM reboot, I'm open to suggestions.

Yes, this solution makes sense for your case if the problem is parasitic character on the UART bus. However, I'm not too sure if it is a good idea to put it in the repository, as I think it is quite specific to your case.

You can try to make a pull request on the repository and see how it goes.

Best regards,

Simon D-M

[Konstantin Klitenik]

Your assumption is correct. nrf54 is the main application, and nrf91 is running SLM over UART.

We are using the reset line to reboot. I don't think it's something that happens on nrf54. I tried rebooting when I know modem is not sending anything (CFUN=0). I also tried clearing the UART ring buffer immediately after toggling the reset line.

If you have a setup similar in the office, I'd be curious if you can reproduce. It doesn't happen every time but if you try a few times you should see it.

[Simon D-M]

The closest thing to this setup I have at my disposal, is a Thingy91x which contains a nrf9151 connected with 2 UARTs to a nrf5340. I'll try that and will keep you updated (most likely tomorrow) if I was able to reproduce the behavior you are seeing or not.

Best regards,

Simon D-M

[Konstantin Klitenik]

Thanks. One other thing of note is we don't use hw flow control.

[Simon D-M]

Hi,

I deactivated the hardware flow control and tried rebooting the device around 100 times. But couldn't reproduce your behavior... 

Konstantin Klitenik said:

We are using the reset line to reboot.

Are you respecting the minimum pull-down time for the nRESET pin ? It needs to be more than 5us (link).

Maybe you can also try to measure when the host MCU is receiving the parasitic character. It can be useful to know the cause of this character and to see if it really is noise or if it is sent from somewhere...

The thing is that UART should have some resilience to noise (not a lot but still), so I find it more believable (not that I don't trust you) that the parasitic character is most likely is sent from somewhere. And I am not aware of Zephyr sending a character on the bus before being told to.

(For the next 2 weeks, you might not get a response from us. We are running low on staff during Christmas / New year.)

Best wishes ,

Simon D-M