Bytes are lost when sending with nrfx_uarte_tx in uarte_handler

RE: Bytes are lost when sending with nrfx_uarte_tx in uarte_handler

Sigurd Hellesvik — Wed, 29 Jan 2025 09:20:38 GMT

[quote user="SvenSi"]Could you explain it more detailed why it is a problem to use the function in the interrupt context? Is there a function that can be used?[/quote]

As you can see in nrfx_uarte_tx(), the function has some loops waiting for stuff. In other words, it is blocking. And blocking functions is generally not a good idea in an interrupt context.

[quote user="SvenSi"]Yes, it seems to be a timing problem. I tested to use a workqueue to send the next byte. This seems to be ok, but now there is a delay between the bytes (as expected), so I would like to get it back to the ISR.[/quote]

The delay is likely because the workqueue is scheduled by the Zephyr scheduler. To make it faster, either do not use the scheduler but a polling function and global variable or semaphore to be really fast, or give the workqueue a higher priority.

RE: Bytes are lost when sending with nrfx_uarte_tx in uarte_handler

SvenSi — Tue, 28 Jan 2025 17:11:07 GMT

Yes, it seems to be a timing problem. I tested to use a workqueue to send the next byte. This seems to be ok, but now there is a delay between the bytes (as expected), so I would like to get it back to the ISR.

Could you explain it more detailed why it is a problem to use the function in the interrupt context? Is there a function that can be used?

RE: Bytes are lost when sending with nrfx_uarte_tx in uarte_handler

Sigurd Hellesvik — Tue, 28 Jan 2025 15:07:03 GMT

Hi,

Often errors like this comes from calling functions from interrupt contexts. This can interfere with peripheral timing.

See how the nrfx_prs sample uses a semaphore to check if the transfer is done, set in the DONE callback instead of calling nrfx_uarte_tx directly.

Regards,
Sigurd Hellesvik