nRF52840 - UARTE dropping 7th character

[DarkMeans]

I'm essentially building a BLE to UART gateway to allow our microcontroller device to talk to our apps.  The BLE section is the nRF52840 and I'm trying to simply use it to pass through the data from the UART (from the microcontroller) to the BLE using the NUS.

For some reason, when the initial data payload comes back from the microcontroller to the nordic is losing the 7th byte.  EVERYTHING beyond that appears to be there, but I don't currently have it properly splitting across multiple packets yet.

I believe that the issue I'm running into is exactly the same one in the below link, but this is using ncs_v2.5.0 and not the older sdk16 or sdk17.
https://devzone.nordicsemi.com/f/nordic-q-a/105313/losing-uart-characters---activating-uart-in-place-of-uarte-in-nrf52840 

Right now I'm at a loss as to where the issue is, other than obviously I'm not getting into the interrupt quickly enough when the data is flowing out.  I've read other forum posts as well which mention various similar aspects, but nothing seemed to ever have a direct fix mentioned other than it was fixed.  I'm at a big loss as to root cause, as I believe the issue exists in my Zephyr and ncs_v2.5.0 setup, as the bare-metal side doesn't have the same issue.  I have scoped the line, and the data IS there, it's just not entering the nordic system to be bypassed.

My project file uses the following configurations with regards to the UARTE and uses flow control.

# Enable the UART driver

CONFIG_SERIAL=y

CONFIG_UART_ASYNC_API=y

CONFIG_UART_LINE_CTRL=y

CONFIG_NRFX_UARTE0=y

CONFIG_UART_0_ASYNC=y

CONFIG_UART_0_NRF_HW_ASYNC=y

CONFIG_UART_0_NRF_HW_ASYNC_TIMER=2

CONFIG_NRFX_TIMER2=y

[Håkon Alseth]

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

[DarkMeans]

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.

[DarkMeans]

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.

[Håkon Alseth]

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

[DarkMeans]

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?

[DarkMeans]

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.