cancel
Showing results for 
Search instead for 
Did you mean: 

Bus Fault during program execution

jerzybog
Associate
Posted on March 09, 2011 at 08:46

Bus Fault during program execution

5 REPLIES 5
Posted on May 17, 2011 at 14:27

You could try :

 To verify your actual clock speeds.

 Increasing wait states on flash.

 Dropping the speed of the processor.

 Running at 24 MHz, with the flash buffering disabled.

Not looking to fix the problem, but rather to identify/isolate a potential timing issue.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
jerzybog
Associate
Posted on May 17, 2011 at 14:27

zabel
Associate III
Posted on July 04, 2011 at 12:15

Hi,

I am using a stm32f103ZGT (eval board STM2110E-EVAL)

I get a bus fault with:

NVIC_CFSR = 0x8200 (i.e. PRECISERR = 1 and BFARVALID = 1)

NVIC_BFAR = 0x480ab52b

the programming manual  says, that in this case BFAR contains the faulting address and the stacked pc points to the instruction which caused the fault.

sp is 0x2000c3d8, according to to the description of exception handling the stacked pc should be at sp+5*4 = 0x2000c3ec. At 0x2000c3ec I find 08055d37, which indeed is inside my program, but at 0x08055d36 there is a movew r3, #0 instruction.

Now I don't know how to interpret this: how can this instruction cause a bus fault?

Regards

  Dirk

Posted on July 04, 2011 at 15:22

There are TWO stacks, if you pick the wrong one the data on it isn't going to help much.

You should try to use a fault handler along the lines of the one described by Joseph Yiu, which processes this more mechanically.

At a guess the address you pulled might be LR, and the preceding instruction is a BL (ie a subroutine call, with the MOVEW at the returning address). That might help identify where to look next. If not you will need to repeat the experiment with more/better instrumentation.

The Hard Fault question in this thread is a bit obscured by the forum breaking and destroying the first post, I doubt changing speed will impact many systems unless the flash subsystem is not set up correctly.

Generally, you'll want to look at all the registers to see if anything is outside the bounds of the RAM/FLASH/ROM/PERIPHERALS, attempts to run ARM code, or reading/writing unaligned words, especially to FLASH.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
zabel
Associate III
Posted on July 11, 2011 at 15:24

Hi Clive1

Thank you for your advice.

My problem was, that the fault handler was not ''naked'', so it pushed an additional register on the stack which confused me.

Regards

  Dirk