STM32F407: Program Counter & Stack Pointer Corruption on Reset

[kdevine9]

Posted on January 10, 2013 at 06:39

Hi Forum

I am using the STM32F407. My compiler is Keil UVision 4. I am using the ST-Link V2 for programming and debugging. For the last three months I have been using the MCBSTM32F400 for code development and everything has been working 100%. I am now trying to get my custom made hardware to work (using the same processor and firmware). 

I can use Keil to successfully program my application. The ST-Link Utility also works fine. The problem seems to be that the processor is not running the application. I can see that the image has been successfully loaded into flash, however upon reset I can see the program counter and stack pointer are loaded with bogus values. The IPSR register is showing ''0x3'', which I take to mean a HardFault. I assume the HardFault is causing the Core to go into a ''Lockup'' state where it is not loading the Program counter and stack pointer with the correct values. Documentation seems to be a bit aspecific on what could cause a HardFault.

I have checked my voltages and my reset lines. The 407 I am using is a Z revision in a UPBGA package, so I don't think the PDR_ON pin is an issue. Can anyone suggest to me what the problem might be? I am sure this is a hardware fault, but I am not sure where to look - like I said I can program and read memory and this firmware works fine.

#stm32f407

[Tesla DeLorean]

Posted on January 10, 2013 at 14:11

BOOTx pins?

[kdevine9]

Posted on January 12, 2013 at 03:53

BOOT0 is pulled to ground. BOOT1 is floating - but I think it that shouldn't matter. Surely if the BOOTx pins were an issue, I wouldn't be able to program the device?

Any other suggestions? The design was largely copied from the existing MCBSTM32F400, so I am quite baffled as to what it could be... 

[Tesla DeLorean]

Posted on January 12, 2013 at 04:35

Well how do these bogus SP/PC values relate to content of your firmware, it has to be pulling them from somewhere?

How about the VCAP pins? How does the design deviate from the one that works?

I'm not sure how it would lock-up. It's going to read the initial SP/PC and either fault immediately if they have invalid values, or the code which then executes jumps some place else or touches some other memory that is out-of-bounds. It might also hard fault if you get an interrupt with a bogus vector entry, or a vector table register that points somewhere it shouldn't.

What about a Hard Fault Handler, what state information do you have that generating? What processor context does it have stacked, what instruction address was faulting.

The BOOTx pins should have no impact on the ability to JTAG program the part, but they will impact where the processor pulls initial SP/PC values, and the memory that is mapped at zero.

[kdevine9]

Posted on January 14, 2013 at 03:09

OK. Problem solved. I was pulling my BOOTx pins low, but with a 1M resistor, which is obviously too large a value - by using a smaller value pull down, the problem was solved.

Thank-you for your help.