Using LIBUARTE during flash operations

[oguzcan oguz]

Hi, 

We are using a NRF52840 chip (SDK 15.3) in an application where we use the softdevice (S140) in combination with 2 UARTS: one for sending out debug output (UART0 - nrfx_uart), and another one for communication with another MCU.

During (internal) flash writes when doing bonding or garbage collection, the CPU stalls for quite a long time (~85 ms during flash erase). In order to make sure we do not lose data from the other CPU we have been looking into the 'nrf_libuarte_async' functionality.

It is constructed by using:

NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 1, 1, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 2, 512, 3);

(UARTE1, TIMER1 for byte counting, TIMER2 for timeout, buffer size of 512).

During normal operation it works fine, but after the CPU stall, we ofter end it in an error in 'nrf_libuarte_async_rx_free', stating "Unexpected RX free input parameter.". In this case the 'rx_free_cnt' is bigger than the 'chunck_size'. We are following the example of examples\peripheral\experimental_libuarte and free the buffer in the NRF_LIBUARTE_ASYNC_EVT_RX_DATA event.

Could you give any indication what can be the issue here? We couldn't find much documentation wrt to this driver. 

Thank you.

[ovrebekk]

Hi

What baudrate is the UART1 running at?

How large is the UART utilization from the connected MCU? Do you think there is a risk that the UART RX buffer could fill up during those ~85 milliseconds?

Are you using hardware flow control or not?

Best regards
Torbjørn

[RoyCreemers]

Response on behalf of my collegue: The baudrate is 115200. There is no risk that the UART Rx buffer could fill up. The connected MCU can only send one single message (which is less <400 bytes),then it waits for a response. Unfortunately there is no possibility that to use hardware flow control

[ovrebekk]

Hi 

Are you able to share the sdk_config.h project file of your application so I can try to replicate your setup?

I have forwarded the issue to the developers also, but they need some more time to investigate. Hopefully I will hear back from them in a couple of days. 

Best regards
Torbjørn

[RoyCreemers]

Hereby the sdk_config.h file

2318.sdk_config.h

[ovrebekk]

Hi

Thanks. 

The developer has discovered a bug that is probably related to the issue you are seeing. 

I will try to prepare a patch next week so you can check if the problem is the same. 

Best regards
Torbjørn

[ovrebekk]

Hi

Please find the patched files attached:
nrf_libuarte_async_patch.zip

Can you give them a try and see if it solves the issue?

Best regards
Torbjørn

[RoyCreemers]

Thanks for the response. With this patch, the UART works as desired!

[ovrebekk]

No problem, I am happy to hear you got it working

[RoyCreemers]

After testing some more, it seems that there are still issues. The device logs:

<error> app: Fatal error
<warning> app: System reset

... and reboots.

I tried to build for debug, but then it looks like more issues are popping up (UART data loss/corruption). When I repeat this several time and ignore the UART error, it looks like an issue in the softdevice:

<error> app: SOFTDEVICE: ASSERTION FAILED

Some more info:

-  I got none of there errors when using the nrfx_uart driver

- When increasing the timeout of the UART (e.g. 5000us to 15000us) the problem of the UART data corruption seems to be reduced/dissapeared

- The assertion of the softdevice is not related to flash operations. In case I toggle between advertising & standby, I also get the assertion.

[ovrebekk]

Hi Roy

How often do you get these asserts, and do they appear to be connected to any particular event or state in your application?

You mention that they occur when you toggle between advertising and standby, but I get the impression they also occur at other times?

Are you able to share the code you use for toggling between advertising and standby?

Best regards
Torbjørn

[RoyCreemers]

Sharing the code is possible, but I'm not sure this will help a lot (of course I will share if you think is has benefits). It is part of quite a big C++ application, involving multiple MCUs.

Our "application core" has a button which triggers an event to toggle advertising. This is communicated by UART to the Nordic BLE MCU. In his turn, this sends back a response over UART, and toggles advertising (so in this case there is a high change that there is some UART activity during softdevice activity).

The start of the advertisement is done by:

sd_ble_gap_adv_start(advertisementHandle, APP_BLE_CONN_CFG_TAG);

the stop is done by:

sd_ble_gap_adv_stop(advertisementHandle);

The scenario above can easily be reproduced here, the assertion occurs at least one out of 10 times. I share your oppinion that they can also occur at other times (I also saw some softdevice assertions during our automated testing, not related to advertisement... just during normal BLE transmittions)