ble_app_uart

[Moshe Baker]

Hi,

This is related to this:

https://devzone.nordicsemi.com/f/nordic-q-a/60464/c-pc-app-development-with-nrf52840-dongle

I am now testing the UART communication between the nRF52840 (using eval board ISP1807), which is connected over UART to another MCU (controlling sensors).

The Nordic chip is running the ble_app_uart.

I am getting unstable data arriving at my main MCU. It seems some initialization/synchronization issue between the two MCUs.

I'm running both MCUs in debug, and cannot determine why the Nordic is sending other data than expected.

Questions:

1. Is the uart_init() in the main enough? When restarting app, is this call enough, or any other reset/uninitialize call is required? How can i make sure UART buffers are empty during app initialization?

2. I see that printf() also calls the uart_put/get functions. This of course will cause contention. So I tried commenting out the uart calls in file retarget.c, but strangely, it seems that causes the UART to stop altogether. How should the retarget.c be handled?

Thanks, Moshe

[Einar Thorsrud]

Hi Moshe,

I am getting unstable data arriving at my main MCU. It seems some initialization/synchronization issue between the two MCUs.

There are two typical reasons for getting problems with UART communication on a DK (or similar board, as in this case).

1. The onboard debugger tends to corrupt UART communication if the USB mass storage device is enabled. I recomend you disable mass storage as described here.

2. Using an inaccurate HFCLK could cause problems, seen as framing errors. Therefore, I suggest you enable the HFXO, for instance by calling nrf_drv_clock_hfclk_request() before a UART transaction.

1. Is the uart_init() in the main enough? When restarting app, is this call enough, or any other reset/uninitialize call is required? How can i make sure UART buffers are empty during app initialization?

By restarting app, do you mean resetting the chip? If so, all UART peripheral registers are reset when the chip is reset, so you will start at the same point every time.

2. I see that printf() also calls the uart_put/get functions. This of course will cause contention. So I tried commenting out the uart calls in file retarget.c, but strangely, it seems that causes the UART to stop altogether. How should the retarget.c be handled?

Most SDK examples use NRF_LOG for logging, and printf is only used for UART examples (such as ble_app_uart), where it is intended to write to the UART (via retarget.c). I suggested you remove it altogether if you don't want to use printf to write to UART.

Einar

[Moshe Baker]

Hi, I modified the main MCU to handle UART using DMA. This fixed sending data from Nordic to main MCU. However when testing the other direction from MCU to Nordic, it fails after 4 bytes. I get APP_UART_COMMUNICATION_ERROR, error_communication is 1 in the UART handler. The BAUD rate is at 1M (max). I also added a call to nrf_drv_clock_hfclk_request(NULL) during initialization (before my one and only transaction). My sdk_config.h is default.

What can I do to fix this? Thanks.

[Einar Thorsrud]

Hi,

One other obvious possible reason I forgot to mention. Do you use flow control?

[Moshe Baker]

How do I check?  I am using default sdk_config.h. Should I use it?

[Einar Thorsrud]

If you refer to uart_init() in the ble_app_uart main.c file that does not use flow control by default (APP_UART_FLOW_CONTROL_DISABLED). And if you transfer a lot of data at a high speed that is a likely problem. You can set it to APP_UART_FLOW_CONTROL_ENABLED, but of course, you also need to configure the other side to use flow control, and you must connect RTS/CTS signals in addition to Rx and Tx (if not already done).