Illegal use of the EPSR - uart fault

RE: Illegal use of the EPSR - uart fault

Einar Thorsrud — Wed, 02 Apr 2025 09:06:01 GMT

Hi,

I see. This is about where the callback function should be called via user_callback(). Perhaps it is worth setting a breakpoint there and see if the function pointer (data->user_callback) is valid?

RE: Illegal use of the EPSR - uart fault

michaelmac — Wed, 02 Apr 2025 08:59:46 GMT

yeah seems so, thanks.

on the faulting instruction - this was what got me to the uart interrupt. well, first using the addrline with r15/pc returned

'libsoftdevice_controller_s140_debug_soft__obfuscated.elf:?'

then i tried with r14/lr instead and got

uart_async_adapter.c:137

this is the switch_rx_buffer() function -> notify_rx_buffer_req(dev)

Im not sure how to go about looking at the stack trace

RE: Illegal use of the EPSR - uart fault

Einar Thorsrud — Mon, 31 Mar 2025 08:11:08 GMT

Hi,

Thank you for the epxlanation.

[quote user="michaelmac"]I got a fix which was to make sure the ST has its uart TX pin always set to output high in normal application mode[/quote]

I see. This could make sense. The error you described in the initial post are related to UART Rx only, and is what you would see if there is an invalid UART character received (framing error). So if the nRF is receiving and the Tx pin from the other MCU is not driven, this means that the Rx pin is floating, and this is expected. Solving this by making sure the ST sets it's Tx pin high when idle is the appropriate fix.

[quote user="michaelmac"]but would still be nice to know why the nRF cant handle that error gracefully and continue.[/quote]

Yes, I am suprised that you get a fault at this point, as you should normally be able to recover from a UART error. I would start by checking the Faulting instruction address (PC) from the error with addr2line to see where in your code this is? Can you learn anything else from debugging? What does the stack trace look like?

RE: Illegal use of the EPSR - uart fault

michaelmac — Mon, 31 Mar 2025 07:34:47 GMT

Hi Einar,

Thanks for the reply and apologies for the delay replying.

For the single byte, no i mean from the nRF to the other MCU. this is the basic structure:

Normally the ST and the nRF are communicating via spi, but for bootloading the ST uses a specific uart. So we send a special cmd to restart into it bootloader, which then looks for an initial byte on its uart. Then the nrf can do the bootloading over uart.

The issue seems to be that I've configured any unused pins to input high-z on the ST (including the uart tx pin). so when the ST resets itself to bootloader, this flicks that TX pin to output causing noise on the line which is picked up as the error.

I got a fix which was to make sure the ST has its uart TX pin always set to output high in normal application mode, which has solved it. but would still be nice to know why the nRF cant handle that error gracefully and continue.

will look into the HFXO as well.

cheers!

RE: Illegal use of the EPSR - uart fault

Einar Thorsrud — Wed, 19 Mar 2025 14:27:26 GMT

Hi,

The driver handles clearing of interrupts etc, and there is no high level API for that nor should it be neeeded. It would be good to understand a bit more about this issue first.

You write that you try to send a byte over UART, do then mean to the nRF, so that it is receiving? I ask just to confirm, as a framing error or break error would be related to reception/input and that match the other informaiton here. Also, can you elaborate more on what you do and the configuration? Are you using flow control? If not, does flow control help?

PS: Sometimes it can be a problem with UART fi you have a inaccurate HF clock, so it could be worth enabling the HFXO and seeing if that makes a difference (as mentionned here).