Bus Fault (BFSR) and Hard Fault (HFSR)

cancel
Showing results for 
Search instead for 
Did you mean: 

Bus Fault (BFSR) and Hard Fault (HFSR)

1,149 Views
caden013
Contributor III

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:

caden013_0-1624034454563.png

I have also attached a file with my code. 

Labels (2)
Tags (3)
0 Kudos
9 Replies

1,123 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello caden013,

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

Also debug to check which code crash.

 

BR

Alice

0 Kudos

1,128 Views
frank_meyer
Senior Contributor II

> ... (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.

Tags (1)
0 Kudos

1,114 Views
caden013
Contributor III

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.

0 Kudos

1,105 Views
converse
Senior Contributor V

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

0 Kudos

1,102 Views
caden013
Contributor III

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?

0 Kudos

1,078 Views
converse
Senior Contributor V

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_meyer 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.

0 Kudos

1,107 Views
frank_meyer
Senior Contributor II

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.

0 Kudos

1,096 Views
caden013
Contributor III

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?

0 Kudos

1,069 Views
frank_meyer
Senior Contributor II

> 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.

0 Kudos