How to disable framing errors in serial_lte_modem

[Caycee]

I'm working with SDK 1.30 and the new application serial_lte_modem (moved from samples to applications in this SDK version).

However when my control hardware tries to communicate, it will auto-baud to get started.

This almost certainly causes Framing/Break errors and causes UART_RX_STOPPED to lock up the modem.

I have found nothing in the API to free these errors and allow the modem to respond to subsequent commands.

Restarting the UART just causes more framing errors (likely because they haven't been cleared).

The 1.30 docs don't mention much, and the other questions I have seen do not refer to the zephyr UART library.

[Håkon Alseth]

Hi,

 

It looks like you have stumbled upon a bug on our side! My apologies for the inconvenience!

When a framing error occurs, this sequence will be called:

https://github.com/nrfconnect/sdk-zephyr/blob/master/drivers/serial/uart_nrfx_uarte.c#L732-L733

 

However; the RX isn't actually stopped when the callback is sent, but rather afterwards, which makes it quite hard for the application to recover. I'll make an internal ticket on this, and propose that we do not stop the RX in uart_nrfx_uarte.c, or change the order of the user-callback and the stopping of the UARTE RX, so that the application can start it again by calling uart_rx_enable(...) from the user-callback.

 

As I see it, you have two options here to work around the issue:

1. Comment out the call to (void) uarte_nrfx_rx_disable(dev);

2. Change the ordering of the above linked two lines, and call uart_rx_enable() in your application.

 

Kind regards,

Håkon

[Caycee]

Okay, that change does allow the modem to resume (often with an error on the next command).

I still ought to be able to clear the error from user application and reset things so further communications are possible. Is there such a command in the API or is that all in the protected/secure area?

I also had to include the following code in cmd_send in slm_at_host.c to assure blank lines would not stop up the modem...though I'm not sure this is the best way to handle it.

    if ((strlen(at_buf) == 1) && (at_buf[0] == '\r')) 
    {
        LOG_WRN("CR_only");
        at_buf[0] = 0;
        goto done;
    }

[Håkon Alseth]

Hi,

 

Caycee said:

I still ought to be able to clear the error from user application and reset things so further communications are possible. Is there such a command in the API or is that all in the protected/secure area?

The driver should clear it for you when an error event is set: https://github.com/nrfconnect/sdk-zephyr/blob/v2.3.0-rc1-ncs1/drivers/serial/uart_nrfx_uarte.c#L721

 This function call essentially reads the NRF_UARTEx->ERRORSRC register, and writes '1' to the bits that are set (which clears the source)

 

Caycee said:

I also had to include the following code in cmd_send in slm_at_host.c to assure blank lines would not stop up the modem...though I'm not sure this is the best way to handle it.

 You insert this logic in slm_at_host.c::cmd_send()? Which termination mode are you currently using? Does procedure lock up the device?

 

Kind regards,

Håkon

[Caycee]

I'm using CR_MODE.  I didn't bother with the other modes for the time being.

I inserted that in cmd_send just prior to at_cmd_write.  It fixed the issue I was having when just a single '\r' being received caused an ignore-everything-else mode.

I figure Nordic may correct this in a future release, as I saw another question within the past week where this was mentioned (I can't find it now), and that this is a known issue. 

[Håkon Alseth]

Hi,

 

Caycee said:

I figure Nordic may correct this in a future release, as I saw another question within the past week where this was mentioned (I can't find it now), and that this is a known issue. 

Yes, you're right! Thank you for investigating. I will add a link to your thread in the already made internal bug report.

 

Kind regards,

Håkon