Find root cause for instruction bus error

[Christoph]

Hello,

   I’m struggling with a problem and need your help. I have an application where a nrf52840 communicates with another nrf52840 over BLE using nus and some services. But the nrf52840 crashes from time to time (<10 min). After some debugging I enabled the hard fault handler and got this result (different runs):

00> <error> hardfault: HARD FAULT at 0x81200004
00> <error> hardfault:   R0:  0x00000000  R1:  0x81200004  R2:  0x00000000  R3:  0x00000000
00> <error> hardfault:   R12: 0x48A1C000  LR:  0x00032F19  PSR: 0x40000032
00> <error> hardfault: Cause: Instruction bus error.

 

00> <error> hardfault: HARD FAULT at 0x81200004
00> <error> hardfault:   R0:  0x00000000  R1:  0x81200004  R2:  0x00000000  R3:  0x00000000
00> <error> hardfault:   R12: 0x101D0000  LR:  0x00032F19  PSR: 0x40000032
00> <error> hardfault: Cause: Instruction bus error.

 

00> <error> hardfault: HARD FAULT at 0x81200004
00> <error> hardfault:   R0:  0x00000000  R1:  0x81200004  R2:  0x00000000  R3:  0x00000000
00> <error> hardfault:   R12: 0x50B04000  LR:  0x00032F19  PSR: 0x40000032
00> <error> hardfault: Cause: Instruction bus error.

 

But I absolutely don’t understand where this comes from and how to find the expression that causes this error. Do you have any useful hints for me?

thanks and best regards 

Christoph

[Vidar Berg]

Hello Christoph,

The fault is apparanelty triggered by the invalid execution address 0x81200004, so the question is what caused the program to jump to this address in the first place. Are you using RTC2 in your application. I noticed from the PSR register that the hardfault is always triggered in the RTC2_IRQn context.

Best regards,

Vidar

[Christoph]

Hello, no, I don't use RTC2 in my application:

// <q> RTC2_ENABLED  - Enable RTC2 instance
 

#ifndef RTC2_ENABLED
#define RTC2_ENABLED 0
#endif

Best regards

Christoph

[Vidar Berg]

Ok, I must have typed in the wrong number earlier when I thought it was the RTC2_IRQn, it's actually the PWM2_IRQn, right?

I suspect the function pointer "p_cb->handler()". When you get the hardfault, can you see what the value of p_cb->handler()" is?

[Christoph]

No, unfortunately not. When I say "Add to watch" I only get the message "cannot evaluate" in uVision.

[Vidar Berg]

That's probably because the 'm_cb' variable is defined statically. You could remove the 'static' keyword temporarily. That should allow you to track the variable from the watch window. Alternatively, you could add a check inside the PWM ISR that checks if the pointer is in a valid address range.

static void irq_handler(NRF_PWM_Type * p_pwm, pwm_control_block_t * p_cb)
{
   if ("p_cb->handler() invalid")
   {
        __ASM("nop") //<-- place breakpoint here to catch the error before the fault exception is triggered
    }
  ...

[Christoph]

Hi,

this is my result from debugging:

But I have seen in a prior session that it was m_cb{2] instead of m_cb[3], so it is not a general problem. Any idea how this could happen or how to prevent this error?

[Vidar Berg]

Hi,

Does this show the data content of m_cb when the hardfault has been triggered?

[Christoph]

Yes, exactly

[Christoph]

Ok, might be that I was wrong with pwm[2]. So this is my initialization:

    APP_ERROR_CHECK(nrf_drv_pwm_init(&m_pwm0, &pwm0_config, pwm0_handler));
    APP_ERROR_CHECK(nrf_drv_pwm_init(&m_pwm1, &pwm1_config, pwm1_handler));
    APP_ERROR_CHECK(nrf_drv_pwm_init(&m_pwm2, &pwm2_config, pwm2_handler));

    (void)nrf_drv_pwm_simple_playback(&m_pwm0, &m_pwm_seq[0], 1, NRF_DRV_PWM_FLAG_LOOP);
    (void)nrf_drv_pwm_simple_playback(&m_pwm1, &m_pwm_seq[1], 1, NRF_DRV_PWM_FLAG_LOOP);
    (void)nrf_drv_pwm_simple_playback(&m_pwm2, &m_pwm_seq[2], 1, NRF_DRV_PWM_FLAG_LOOP);

So no channel 3 is ok

[Vidar Berg]

I had expected to see a corrupt function pointer, but they all look ok. Are you able to provide a project that I can use to replicate the fault on my side?

[Christoph]

No, unfortunately not

[Vidar Berg]

Ok. You may try to increase the Call stack size in case it's caused by a stack overflow and also go over memcpy's, etc in your code to see if there is something that may lead to a buffer overrun.