Hi guys,
I have noticed that there is a problem with losing bytes at high baud rates on UART. Is there a limit to how high the baud rate can be when using a softdevice?
I use the following things:
- nRF52820 SoC
- Example project: ble_app_uart_c (modified)
- SDK 17.1.0
- Softdevice s140 7.2.0
Hello,
The softdevice will during BLE event have some processing that may delay application interrupts, but whether this is enough to lose bytes I am a bit unsure of.
My suggestions:
1. Enable hardware flow control when init UART, e.g. use APP_UART_FLOW_CONTROL_ENABLED instead of APP_UART_FLOW_CONTROL_DISABLED.
2. Configure the UART to have higher interrupt priority, e.g. use APP_IRQ_PRIORITY_HIGHEST instead of APP_IRQ_PRIORITY_LOWEST. Note that this means you can't call softdevice api directly from the uart_event_handle(), and instead for instance set a flag to ensure you call ble_nus_c_string_send() from main() context instead.
3. Are you sure the problem is that the UART are not able to catch up? Or can it be that the BLE link are not able to handle the data throughtput, e.g. check if ble_nus_c_string_send() may be returning NRF_ERROR_RESOURCES, which means that the BLE link is not able to handle the data throughput.
Best regards,
Kenneth
Hello,
The softdevice will during BLE event have some processing that may delay application interrupts, but whether this is enough to lose bytes I am a bit unsure of.
My suggestions:
1. Enable hardware flow control when init UART, e.g. use APP_UART_FLOW_CONTROL_ENABLED instead of APP_UART_FLOW_CONTROL_DISABLED.
2. Configure the UART to have higher interrupt priority, e.g. use APP_IRQ_PRIORITY_HIGHEST instead of APP_IRQ_PRIORITY_LOWEST. Note that this means you can't call softdevice api directly from the uart_event_handle(), and instead for instance set a flag to ensure you call ble_nus_c_string_send() from main() context instead.
3. Are you sure the problem is that the UART are not able to catch up? Or can it be that the BLE link are not able to handle the data throughtput, e.g. check if ble_nus_c_string_send() may be returning NRF_ERROR_RESOURCES, which means that the BLE link is not able to handle the data throughput.
Best regards,
Kenneth
Hi Kenneth,
thank you very much for your answer.
1. Enable hardware flow control when init UART, e.g. use APP_UART_FLOW_CONTROL_ENABLED instead of APP_UART_FLOW_CONTROL_DISABLED.
I've been thinking about that, too. But then we would have to make changes in the hardware design (we have only used UART_TX and UART_RX so far), so I was looking for another alternative. But maybe this will be possible in the future.
3. Are you sure the problem is that the UART are not able to catch up? Or can it be that the BLE link are not able to handle the data throughtput, e.g. check if ble_nus_c_string_send() may be returning NRF_ERROR_RESOURCES, which means that the BLE link is not able to handle the data throughput.
I converted the project ble_app_uart_c to a BLE scanner, which only takes the information from BLE devices nearby and sends it via UART to another microcontroller. I removed most of the functions, only the adv_report parser and the scan functions are still needed. I do not connect to any BLE device.
If a package gets lost with all the data from nearby BLE devices, it's not so tragic. However, I sometimes send short commands from the other microcontroller to the nRF SoC and there are sometimes errors in the UART communication, which I have analyzed with NRF_LOG_INFO. The bytes are in any case all on the UART-line (checked with logic analyzer) but the nRF SoC does not pick them all up (despite UART Fifo). That's why I suspected that my baudrate is too high and due to interruptions by the softdevice not all bytes are recorded.
However, I have now thought of another solution. If I want to send a command from the other microcontroller to the nRF chip, I first pull a GPIO pin to ground, which triggers an interrupt in the nRF. In the interrupt routine I disable the softdevice for a short time.
