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

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

Ethan.jskim — Tue, 29 Aug 2023 22:57:22 GMT

thank you Sigurd.

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

I will close this ticket.

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

Sigurd — Tue, 29 Aug 2023 11:50:04 GMT

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

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

Ethan.jskim — Tue, 29 Aug 2023 09:12:22 GMT

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,

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

Ethan.jskim — Mon, 28 Aug 2023 08:02:12 GMT

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.

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

Sigurd — Fri, 25 Aug 2023 16:04:45 GMT

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

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

Ethan.jskim — Tue, 22 Aug 2023 23:38:33 GMT

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?

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

Turbo J — Tue, 22 Aug 2023 10:40:51 GMT

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.