hard fault caused by BusFault

[jbrud]

Hi all,

I encounter frequent hard fault as soon I use CAN & USB at the same time. I'm using FreeRTOS  on a MK64F MCU.

I tried to analyze fault registers to find out the cause of the hard fault but I'm not sure to interpret the value of BFAR.

See below the steps when it is stopped in HardFault_Handler function:

1. Inspect Configurable Fault Status Registers

GDB: print/x *(uint32_t *) 0xE000ED28

Entire CFSR    0x008200

with [ UFSR | BFSR | MMFSR ]
UFSR           0x0000
BFSR           0x82
MMFSR          0x00

2. BusFault Status Register (BFSR) - 0xE000ED29

GDB: print/x *(uint8_t *) 0xE000ED29

BFSR 0x82

-> 0b10000010

7: BFARVALID    1
1: PRECISERR    1

3. Bus Fault Address Register (BFAR)

GDB: print/x *(uint32_t *) 0xE000ED38

-> 0x2c80001c

should hold the address which triggered the fault ?

See my linker script from SDK:

/* Specify the memory areas */
MEMORY
{
  m_interrupts          (RX)  : ORIGIN = 0x00000000, LENGTH = 0x00000400
  m_flash_config        (RX)  : ORIGIN = 0x00000400, LENGTH = 0x00000010
  m_text                (RX)  : ORIGIN = 0x00000410, LENGTH = 0x000FFBF0
  m_data                (RW)  : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000
  m_data_2              (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00030000
}

I would assume it should point somewhere in m_text region...

Any ideas ?  What am I doing wrong ?

Register addresses from: https://developer.arm.com/docs/dui0553/b/cortex-m4-peripherals/system-control-block/configurable-fau... 

[jbrud]

I solved my problem, but its to application specific to explain it here. It was basically  a memory corruption which cause a faulty stack.

Anyway my interpretation of ARM registers wast not correct. Just want to clarify it in case if someone encounter a similar problem and tries to follow my inspection of registers. The referred ARM specification says:

The BFAR contains the address of the location that generated a BusFault.

I misunderstood this statement. I thought that BFAR points to the "line of code" in flash memory. Instead it shows which address was tried to accessed. The "line of code" can be restored by recovering the call stack and is much more helpful.

[Sabina_Bruce]

Hello Johannes, 

Hope you are doing well. I apologize for the delayed response, this community thread is fine there is no need to open a ticket.

If possible could you please share an example project of when this is occuring using both CAN and USB, so that I may attempt to reproduce this error from my side and can check it with detail. 

Also if you could please confirm the IDE version you are using and your OS.

Best Regards,

Sabina

[jbrud]

Hello Sabina,

unfortunately this is not possible since we use a custom board and the software is not executable on a NXP's development board.

For me it would be helpful if a someone could check my inspection of fault registers. If I interpret them wrongly or why the result is out of specification ?

Thanks !

[Sabina_Bruce]

Hi Johannes,

In the case of the information provided, the address listed in the BFAR should point to where the exception is being made. Generally, you will find that the line prior to this, is causing the exception.

I recommend to check the tips given in the following site, they go through how to debug the different possibilities listed in the BSFR.

You can also refer to the ARM website for a more complete description of the above.

Also by stepping through just before the address while debugging, it will be easier to begin pin pointing where the root issue is.

Best Regards,

Sabina

[jbrud]

@NXP  should I open a ticket instead ?