nRF52 Stale UART RX Data

RE: nRF52 Stale UART RX Data

operator — Mon, 31 Jul 2017 17:58:34 GMT

Hell Hung, thank you very much for your response but as mentioned above I have resolved the issue by rejecting any potential garbage on the UART through a custom error checking and retry mechanism.

RE: nRF52 Stale UART RX Data

Hung Bui — Mon, 31 Jul 2017 13:24:33 GMT

Sorry to hear ab your struggle with the UART. Is it possible to reproduce the issue with a very simple code ? Let's ignore BLE , simply send a byte to the peer and then wait for a byte (ACK/NACK ) to come back from the peer ? From what I understand, you only receive the ACK of the pervious packet from the peer ?

RE: nRF52 Stale UART RX Data

operator — Sat, 29 Jul 2017 00:15:54 GMT

I managed to more or less resolve the issue with a ferociously strict set of message checking logic and retries within the APP_UART_DATA_READY event handler.

It doesn’t explain the stale data I was seeing but it’s a fairly robust and sufficient solution for the time being.

RE: nRF52 Stale UART RX Data

operator — Fri, 28 Jul 2017 19:07:57 GMT

Additionally, I had a feeling the alpha SDK would come up as an issue (what exactly is different in the UART driver between the alpha and release version?) so I took the several hours necessary to port my code to the 13.1 SDK in a separate branch of my project and the result is exactly the same; the issue remains.

RE: nRF52 Stale UART RX Data

operator — Fri, 28 Jul 2017 19:07:52 GMT

The UART example in the SDK does not exhibit this behavior but it is also not representative of my use case.

The issue noted above is the gist of problem. In my actual application a byte is written to a custom characteristic over BLE. This value is encoded with a message type and sent over UART to the secondary MCU which parses the data and sends back an acknowledgement message with the same value to confirm the data has been handled. This message is then read by the nRF52 (this is where I'm having the issue) and the value is used to update a separate characteristic byte value.

I know that everything else in the communication chain is working properly as I can hardcode values and messages are still one behind. Values are reinitialized before every call so the only place the old data could be sitting is in the UART buffer.

RE: nRF52 Stale UART RX Data

Hung Bui — Fri, 28 Jul 2017 08:53:36 GMT

Hi, do you see the same issue with the uart example in the SDK ? Also, the latest SDK is 13.1, you may consider moving away from the SDK v13 alpha.