UART stop-bit pulse time is not fit to baudrate.

[Ethan.jskim]

Dear expert.

I found something strange thing in UART operation

one of our product is developed based on the NUS example in nRF5_SDK using nRF52833

In low speed baudrate(under 115200bps) settings, all uart pulses are same duration

but in high speed baudrate(from 115200bps and over), stopbit pulse time is different with other bits pulse every data.

Below image is captured signal by analyzer in each baudrate and can find delta-time(p0: normal bits time, P1: stopbit time)

In test sequence, nRF52833 send TX response "+OK\r" if received "AT\r"

capture image shows stopbit pulse keep 57kHz even though over 57600bps baudrate

I don't know why stopbit pulse shows strange symtom in high speed baudrate

let me know what am I should check.

BR.
Ethan

[Turbo J]

Are you using UART? Those will have longer stop bit times due to how the interrupt processing works. UART needs to process an interrupt for each transmitted byte - which can take longer than one byte cycle especially when BTLE runs in parallel.

You should be able to eliminate those gaps using the UARTE peripherial which supports EasyDMA.

[Ethan.jskim]

Thanks Turbo J.

to verify this long stopbit issue, I use just UART peripheral without BTLE operation and long stopbit issue  was still occured.

so I think this is not caused by BTLE.

If this stopbit delay occured by process on interrupt handling, I think this is depend on UART driver(or Library) and there is almost nothing I can do on Application code.

and From your advice, I understand that there are different types of drivers (or libraries) for UART and UARTE, and that UARTE could be improved this issue.

Is my understanding correct?

[Sigurd]

The NUS example in nRF5_SDK v17 should already be using UARTE by default.

Looking at your image, it seems like "+OK\r" was split in 2 transfers. 

'+' was sent in 1 transfer, and then the rest in the next transfer. Are you using app_uart_put()? Try using nrf_drv_uart_tx() instead

[Ethan.jskim]

Sigurd

Thank you so much for your advice.

As you say, it looks like split between every bytes while the UART Tx("+OK\r") happens.
And it was confirmed that we are using app_uart_put() when doing UART Tx as you said .

We will change the code to can use the nrf_drv_uart_tx() API and test again.
Then I'll update the post with the test results.

[Ethan.jskim]

Sigurd

We confirmed that to use app_uart_put() is initialized and used in app_uart_fifo.c or can be initialized and used in app_uart.c.

In addition, when initializing and using in app_uart.c, as a result of testing nrf_drv_uart_tx() api is operating I expected, it was also confirmed that there is no problem with the stop-bit.

However, while verifying nrf_drv_uart_tx() for UART output, one more question arose.

previously we were also used UART output for active-debugging, it was possible using printf() without any special difficulty with the RETARGET functionallity, but it was found that printf() does not operate normally when using nrf_drv_uart_tx() api.

is printf() for active-debugging can't use if nrf_drv_uart_tx() api?

My English is so poor, so please tell me if you don't understand the explanation, 

[Sigurd]

Hi!

printf is using app_uart_put(), so if you are using e.g. both nrf_drv_uart_tx() API directly and printf(), you might get some conflict.

The nRF52833 has 2 UARTE instances, so one option is to e.g. use e.g. UARTE1 for your nrf_drv_uart_tx() , and let app_uart use UARTE0

[Ethan.jskim]

thank you Sigurd.

I understood and I will try other UARTx for active debugging.

I will close this ticket.