UART bytes error in ble_app_uart examples

[DL_November]

Hi!

I'm trying to pass the BLE data to the PC using nrf52840 DK.

To do so, I've started with the ble_app_uart example and it was able to build fundamental features–find BLE device, get BLE notification, and send to PC via FIFO.

But the problem is that 1) a lot of data are missing during the UART procedure and 2) throughput seems to be lower than what I expected.

It was able to get a clean result with a low BLE data transmission rate (32k bps) and a low UART baud rate (115200).

The BLE data rate should be at least 10 times higher (320k bps, and 640k bps for the ideal). It means that I need to increase the UART baud rate to more than 460800.

But when I increase the baud rate to more than 230400, the data become weird.

For example, when I check the BLE packet with the nRF Connect application, a repeated 30-C8 (00110000-11001000) appears. But the UART result is 91-E8 (10010001-11101000).

This is quite a huge problem for me because all the bytes are in the form of 00xxxxxx-11xxxxxx.

Fortunately, in the case of the 460800 baud rate, this happens very few times but for the 921600 baud rate, the error becomes the major.

I may build my applications with the 460800 baud rate, but I want to be sure why this happens and whether I can solve the problem. Is there any related information?

Also, I'm curious whether the hardware flow control is working... 

I turned on the flow control option by changing NRFX_UARTE_DEFAULT_CONFIG_HWFC, NRFX_UART_DEFAULT_CONFIG_HWFC, UART_DEFAULT_CONFIG_HWFC to 1 but it seems there is no difference with those options are turned off.

P.S. I found the usbd_ble_uart example, but what is the advantage of using CDC ACM USB? Is there any performance improvement than JLink CDC UART port?

[Kenneth]

If you increase the baud rate, then it get more important to have more accurate clock used to set the baudrate. 

Can you try to call sd_clock_hfclk_request() after enabling the softdevice to ensure that you have a accurate clock.

[DL_November]

I added sd_clock_hfclk_request() after initialize part as you said. However, the result still seems the same.

[Kenneth]

Normally when sending data on UART the start bit is used to "synchronize" the receiver for every byte, if you send large amount of data back-to-back, and if there is some difference on the baud rate between the transmitter and receiver (due to error in the baudrate generator or clock), this may after some time lead to issue with the synchronization, and thereby errors in the data. Adding some delays between bytes and/or some delay (e.g. 10us) every 100bytes can help in such situation. Maybe you are able to experiment with that?

I have also seen that the SEGGER chip on the nRF DK in some situation is not very tolerant to UART "variations", so it could be that you should try to get a proper FTDI UART to interface to the nRF52840 instead.

If you have access to a logic analyzer that may also help to check the baudrate and data flow.

[DL_November]

Hi! I've tried what you suggested but the result still seems not good...

Kenneth said:

Adding some delays between bytes and/or some delay (e.g. 10us) every 100bytes can help in such situation.

I added some delay but still all the data were not what I sent.

In a document from infocenter, it says that 921,600 baudrate is not supported.

Then, is it possible to get 921,600 baudrate with nrf52840-DK board?

Kenneth said:

so it could be that you should try to get a proper FTDI UART to interface to the nRF52840 instead.

And is this mean that I have to make my own PCB board with nrf52840 and FTDI?

[Kenneth]

DL_November said:

In a document from infocenter, it says that 921,600 baudrate is not supported.

Seems that link just pointed to the start page. 

DL_November said:

And is this mean that I have to make my own PCB board with nrf52840 and FTDI?

You can use \usbd_ble_uart to use the USB interface of the nRF52840 to enumerate as a virtual com port, this should for all practical purposes be the same as using nRF52840 with a USB->UART bridge (FTDI or SEGGER) seen from the PC. Using \usbd_ble_uar you avoid having the limitations of the UART interface, instead you use USB directly to transport the data.

[DL_November]

Hi. I tried the usbd_ble_uart example and it was successful to get the 921600 baud rate with the virtual com port.

Sorry for taking the time to verify the answer. Your suggestion was really helped. Thanks!