nRF52840 - UARTE dropping 7th character

RE: nRF52840 - UARTE dropping 7th character

DarkMeans — Wed, 06 Nov 2024 21:20:01 GMT

Thank you for all of the help.

In addition to the changes in the above post (marked as "verified answer" above), there was some additional logic inserted into the project was causing the system to disable the uart multiple times using uart_rx_disable(). For whatever reason, instead of crashing, the system just took it. This happened to close and re-open at the time of the 7th character coming in.

RE: nRF52840 - UARTE dropping 7th character

DarkMeans — Wed, 06 Nov 2024 14:49:57 GMT

I'll have to turn on all of the logs and rerun some things later this morning. We initially turned them all off thinking that the logs were part of what was causing the data to be lost.

We are queueing up this data in the uart_cb, and the ble nus_send is happening in it's own thread with a semaphore just waiting for data. My question with the UART_RX_RDY queuing point was really looking to bounce the idea off, is that where you would trigger the ble send on your side doing the same type of data?

RE: nRF52840 - UARTE dropping 7th character

Håkon Alseth — Wed, 06 Nov 2024 13:10:57 GMT

Hi,

Please note that the "uart_cb" is running in interrupt context, and you should rather send data in a dedicated thread or schedule the operation to the main-context. Queueing the data in uart_cb is fine, but you should not call a ble-related function directly from that function.

Can you share any logs from the sequence?

Kind regards,

Håkon

RE: nRF52840 - UARTE dropping 7th character

DarkMeans — Tue, 05 Nov 2024 23:05:10 GMT

Alright, your changes helped quite a bit I think. The first response now works as expected, but now all subsequent responses don't, and when I let my Windows machine sit there and watches the announcements, when the system looks like this icon which it has always looked like in the past. With this icon, it responds properly. After the first response, the icon changes to this heart thing and it still drops the 7th byte.

When data comes I'm using uart_cb and UART_RX_RDY to queue up the data to send. Is that the right way to do it? Due to the nature of the data, JSON, I'm doing my best to queue up the entire message up until the timeout before releasing it to the NUS service.

RE: nRF52840 - UARTE dropping 7th character

DarkMeans — Tue, 05 Nov 2024 19:26:46 GMT

Thank you for your response. I'm going to start investigating your changes.

As you can see in the below snipped, the response always has the 7th character missing.

RE: nRF52840 - UARTE dropping 7th character

Håkon Alseth — Tue, 05 Nov 2024 15:20:21 GMT

Hi,

If I understand your setup correctly, you have connected a host-controller to the nRF52840 via UART.

Only the initial payload has a problem, is that correct?

If I understand correctly, I believe that this line is the root-cause:

https://github.com/nrfconnect/sdk-nrf/blob/v2.5.0/samples/bluetooth/peripheral_uart/src/main.c#L325

Where the '50' should be changed to UART_WAIT_FOR_RX, as done in this PR:

https://github.com/nrfconnect/sdk-nrf/commit/75304da581f92f35a7cec2c2039399e9569f43ab

Kind regards,

Håkon