Reliable UARTE reception with active softdevice

[Adrian Eggenberger]

Hi

I've done a few attempts in the last years to implement a reliable reception by using the UARTE. In the past we used the UART periphery from the nRF51, but we thought it should be the right way to use the new UARTE that comes with the nRF52. There are multiple threads in the DevZone that show that implementing reception with UARTE is difficult if it is not known when and how much bytes you will receive.

Last week we started a new project that will use the nRF52810 und will need UART communication. As the nRF52810 doesn't have the legacy UART we need to switch to the UARTE peripheral. So we did a new attempt and found the libuarte module in the SDK15. It seemed to be the solution for us to use the UARTE. The usage of 10(!!!) PPI channels for implementing a UART function seems a bit odd to me, but if it works we could live with that.

We testet the functionality with a modified "experimental_libuarte" example and it works as expected. Bytes come in immediately after reception and all bytes are received.

To test this I've written a C# tool SerialTest, that sends bytes to a Comport in random interval. Any byte that is sent is increased by one. The test program is attached to this issue. The firmware tests any incoming byte if it is equal to a increased last byte. After the first byte has been received LED4 is enabled. As soon as a followed byte is not equal to the previous byte plus 1 the LED3 is enabled. In a sucessfull test the LED4 is on but LED3 remains off during the sending of all 10000 test bytes. 

In a second step I've modified the libuarte example to run in parallel with a BLE advertising. This would somehow be near my real use case. Now the test fails in most cases. If the debugger is used I can seen that some bytes are lost in these cases. The example for this test is also attached to this issue. The attached files need to be extracted in the "\examples\peripheral" folder of the SDK15.

My question is:
- Can the libuarte be fixed to work reliable if BLE is enabled?
- How should we realize UART communication with the UARTE peripheral?

Regards
Adrian

SerialTest.zipuarte_test.zip

[Einar Thorsrud]

Hi Adrian,

I see from your code that you are not using flow control (NRF_UARTE_HWFC_DISABLED). You should always use flow control if you need reliable UART and you are doing something else with higher priority (such as BLE).

[Adrian Eggenberger]

Hi Einar

I agree that for reliable communication the flow control must be used. Maybe "reliable" wasn't the correct word in my description.

My point is that the UARTE implementation looses bytes where the (much easier) legacy UART implementations doesn't.

This is problem is independent from the flow control, but to be sure I've modified the example the following way:
1) I've enabled the flow control in the test firmware and C# test application.
2) I've added a new project configuration that allows to switch between an implementation for legacy UART (works) and a UARTE implementation based on the libuarte modules that looses octets.

Regards Adrian

uarte_test_v2.zipSerialTest_v2.zip

[Einar Thorsrud]

Hi Adrian,

I see. I have tested your code and can reproduce it on my side. Unfortunately, I have not been able to go in depth yet, so I do not have any explanation or suggestion for a fix at this point.

By the way, why are you using the experimental nrf_libuarte_async instead of the UART driver (which also support UARTE)?

[Adrian Eggenberger]

Hi Einar

I would prefere to use the UART driver for the UARTE, but is this driver capable of continuous asynchronous reception?

Regards Adrian

[Einar Thorsrud]

Hi Adrian,

You are right, the UARTE driver is not capable of continuous asynchronous reception. The nrf_libuarte_async is intended to work around that (using a lot of PPI). I do not have any more info yet, but I will look into this and discuss with the developer next week and get back to you.