Bus Fault (BFSR) and Hard Fault (HFSR)

[caden013]

Hi all, 

I have been working on a piece of code recently, trying to input data from an external ADC via SPI communication. To my chagrin, I keep getting active faults in my code: a bus fault and a hard fault (the hard fault is probably due to the bus fault, correct?). I have looked through my code (I mostly just copied code from NXP examples), but I cannot manage to find my errors. I know that it is probably something simple that I am overlooking, but I would appreciate it if anyone could help me out.

Here is the faults tab in MCUXpresso:

I have also attached a file with my code. 

[Alice_Yang]

Hello caden013,

Please check have you enable peripheral clocks you used, for example ADC, SPI ...

Also debug to check which code crash.

BR

Alice

[frank_m]

> ... (the hard fault is probably due to the bus fault, correct?)

Indirectly, yes. If there is no handler for a specific fault, it is escalated to hardfault.

I would suggest this tutorial first:

https://www.keil.com/appnotes/files/apnt209.pdf

And then trying to pinpoint the exact location by instruction-stepping (assembler code) in the debugger, at least near the fault.

[caden013]

I have found the line that causes a fault.

base->MATCH_ACCESS16BIT[s_currentMatch].MATCHL = (uint16_t)matchValue;

This line of code is from the file "fsl_sctimer.c"

The variable s_currentMatch has a value of 0, which is a valid index number, when this line is executed, yet it still causes a fault. Do you know why I receive a fault at this point?

Thanks in advance.

[converse]

What is the value of base at this point? Could it have been corrupted (e.g. stack overflow?)

[caden013]

The value of the base at this point is 1074286592 (decimal)/40085000 (hex). Could it be that the instruction to access the register is causing the problem?

[converse]

You are going to have to debug this yourself - without your exact setup and source code, we can only offer some pointers.

So, as @frank_m said, switch to instruction level (assembler) debugging and find the exact instructions that is causing the fault. What is the instruction, and what is the values causing the fault.

[frank_m]

Is the timer unit properly initialised at that time, i.e. clock enabled ?

I guess not.

This is why I mentioned assember / instruction stepping debug mode. The fault probaly happens when the peripheral register is accessed.

[caden013]

The timer unit is properly initialized -- the clock for the SCTIMER is enabled. Right before the instruction in question is executed, the value of the base is 1074286592. Is it possible that the error is due to the settings for the base?

[frank_m]

> Right before the instruction in question is executed, the value of the base is 1074286592.

This might be correct, you can check in the MCU's user manual. "base" is the base address of the peripheral, and SCT_Type is a struct laid over the unit and it's registers.

I am having a LPC54628, and the SCT0 is at the same address:

/* SCT - Peripheral instance base addresses */
/** Peripheral SCT0 base address */
#define SCT0_BASE         (0x40085000u)
/** Peripheral SCT0 base pointer */
#define SCT0              ((SCT_Type *)SCT0_BASE)

Perhaps the stack got corrupted, as converse suggested ?

I would switch to instruction stepping mode (debugging), and check the register values of the "offending" instruction.