nRF52840 UARTE1 Interrupt Crashes in MBR Region

RE: nRF52840 UARTE1 Interrupt Crashes in MBR Region

Susheel Nuguru — Thu, 02 Apr 2020 13:46:17 GMT

then I cannot understand why nrf_drv_uart_tx is causing this. Can you please upload a project where i can reproduce this. I can try to debug and find the root cause and a workaround.

RE: nRF52840 UARTE1 Interrupt Crashes in MBR Region

Kenneth — Thu, 02 Apr 2020 13:01:55 GMT

That's good to know. However, I'm using the default priority for nrf_drv_uart of UART_DEFAULT_CONFIG_IRQ_PRIORITY = 7. All my callback is doing is setting a volatile global boolean to true, then returning.

RE: nRF52840 UARTE1 Interrupt Crashes in MBR Region

Susheel Nuguru — Thu, 02 Apr 2020 12:21:57 GMT

Which context are you calling the nrf_drv_uart_tx? Seems like something is happening in the uart callback handler.

What is the priority which which you initialize the nrf_drv_uart? UART_DEFAULT_CONFIG_IRQ_PRIORITY?
what are you doing inside the uart_callback handler?

If you have changed the priority of uart driver to high, and calling some sd_xxx from inside the uart callback handler, that would cause an hardfault, This is because all calls to sd_xxx are converted to SVC calls which are at priority 4. Calling sd_xxx calls from higher priority context would immediately trigger an hardfault on ARM Cortex architectures.

RE: nRF52840 UARTE1 Interrupt Crashes in MBR Region

Kenneth — Mon, 30 Mar 2020 21:08:35 GMT

The call stack window just contains the HardFault_Handler with no previous state. It also breaks when it attempts to execute at 0xA60, but also with no call stack. If I comment out the call to nrf_drv_uart_tx there is no crash and HardFault_Handler is not called. I do see the full UART message display on my FTDI cable I have connected to it which is why I thought it could be related to the TX DONE event being triggered. The program does have BLE running during this time but removing BLE processing does not seem to affect it.

RE: nRF52840 UARTE1 Interrupt Crashes in MBR Region

Susheel Nuguru — Mon, 30 Mar 2020 12:59:13 GMT

Hmm, looks like a crash in the MBR, which should not happen. What is the context before this happens? can you see anything meaningful in the call stack window?

RE: nRF52840 UARTE1 Interrupt Crashes in MBR Region

Kenneth — Fri, 27 Mar 2020 13:13:34 GMT

I updated my code as requested and got the following when using __get_PSP:

p_addr = 0x18

addr = 0x733.

I also ran it again with __get_MSP and got the following:

p_addr = 0x2003eef8

addr = 0xE0

Based on p_addr, I believe MSP is the correct stack pointer to use.

RE: nRF52840 UARTE1 Interrupt Crashes in MBR Region

Susheel Nuguru — Fri, 27 Mar 2020 08:28:33 GMT

most likely it is the PSP and not the MSP for your application.

Also the address of the instruction that is causing the hard fault is given by

uint32_t *p_addr = (void *)( __get_PSP()) + 0x18;
uint32_t addr = *(p_addr);

Then the addr would contain the address of instruction that caused hardfault

RE: nRF52840 UARTE1 Interrupt Crashes in MBR Region

Kenneth — Thu, 26 Mar 2020 19:43:21 GMT

Hi Susheel,

I created the hardfault handler similar to the tutorial but updated the offset to point to PC on the stack and got 0x000000E0. This would be the interrupt handler, correct?

Below is the code I used to display the PC in case I made a mistake.

void HardFault_Handler(void)
{
    uint32_t *addr = (void *)( __get_MSP()) + 0x18;

    NRF_LOG_ERROR("Hard Fault at address:");
    NRF_LOG_ERROR(" 0x%08x\r\n", (unsigned int)*addr);
    NRF_LOG_FLUSH();
    while(1)
        ;
}

RE: nRF52840 UARTE1 Interrupt Crashes in MBR Region

Susheel Nuguru — Thu, 26 Mar 2020 08:23:09 GMT

You should be able to get the address of the instruction that is causing the hardfault by backtracking the stack.similar to how it is done in this threads

post 1
post 2
tutorial 1

Once you know which instruction is causing this by looking at the instruction address in the .map file, we can try to get a workaround based on the context.