Code causes hard fault, can anyone guess why?

[martinkarlsson9]

Posted on June 21, 2010 at 11:22

Code causes hard fault, can anyone guess why?

[swhite2]

Posted on May 17, 2011 at 13:55

One of the first things I implemented when I started using STM32's was fault handling (all faults--not just hard). Then when one occurred I'd look at the linker map file and listing files to locate (i.e. figure out where the PC was in the source) the offending code.

I dumped the output to a serial port I used for debug messages.

e.g.

12/11/2009 13:55:15.530 Last exit() due to Cortex-M3 hard fault!.

12/11/2009 13:55:15.536 SP = 0x20004f68, CFSR = 0x20000125, HFSR = 0x20004000

12/11/2009 13:55:15.543 PC = 0x0800b7ec, PSR = 0x41000000, LR = 0x080096CF, R12 = 0x0801652D

12/11/2009 13:55:15.552 R0 = 0x00000000, R1 = 0x05F5E100, R2 = 0x00000000, R3 = 0x00000000

[domen23]

Posted on May 17, 2011 at 13:55

Don't you need to wait for flash on every word programmed?

At least fwlib's FLASH_ functions suggest that.

[martinkarlsson9]

Posted on May 17, 2011 at 13:55

The NOR_WRITE stuff in the beginning is a bit of cargo cult programming... The library the came with the flash does this. I checked the specs and its a reset plain and simple. Makes sure that the flash is in read mode. I might not need it but on the other hand it cant hurt to leave it in for now.

I did as you suggested, both with writing static data (doesn't work) and leaving out the increment (still doesn't work). Thanks anyway.

[t1_it]

Posted on May 17, 2011 at 13:55

I'm not sure why you need the code below if you are only reading from external flash:

NOR_WRITE(ADDR_SHIFT(0x0555), 0x00AA);

NOR_WRITE(ADDR_SHIFT(0x02AA), 0x0055);

NOR_WRITE((BANK1_NOR2_ADDR + extaddr), 0x00F0);

Anyway, what happens if, instead of reading from external flash, you write a constant to internal flash?

*(uint16_t*) (intaddr) = 0X0000;

If that works OK, then what happens if you leave out the increment to the external flash address?

extaddr += 2;

[martinkarlsson9]

Posted on May 17, 2011 at 13:55

Thats correct. It doesn't make my problem go away though. I have updated the code in the OP to include the wait.

[martinkarlsson9]

Posted on May 17, 2011 at 13:55

Good call. I turns out that those variables isn't even set when the code is running (works in debug stepping mode) witch means that the fault happens earlier than I thought. Maybe I still have a problem with interrupts? I'll try to clear them twice and clear pending interrupts as well.   

[t1_it]

Posted on May 17, 2011 at 13:55

That seems to rule out a problem reading external flash.

If you make 'intaddr' a global variable, you should be able to see what value it has reached when the fault occurs.  Maybe that will give a clue.