cancel
Showing results for 
Search instead for 
Did you mean: 

Frequencies change during program execution with a HardFault in stm32f207xx

Abdou
Associate II

Hello, please i need help

I'm using IAR Embedded Workbench IDE & STM32F207xx with TFT LCD Display, I configured the SysCLK to 120Mhz & HCLK to 120MHz & PCLK1 to 30MHz & PCLK2 to 60MHz, When I debug or execute program all frequencies change automatically to the random values and the HardFault exception execute.

how I know when the problems come

0690X00000AqMKbQAN.png

0690X00000AqMKlQAN.png

0690X00000AqMKvQAN.png

0690X00000AqML5QAN.png

7 REPLIES 7
Danish1
Lead II

I think the scrambling of those clock values and the hardfault are both symptoms of the same thing: Your program crashing.

You might be able to get some information about the crash from what's reported by the fault exception viewer - for example is 0x08012174 a valid address in your program code?

I don't have much experience of analysing these but I would have expected an odd address not an even one (this is a historic artefact of the move from 32-bit ARM instructions to 16-bit THUMB ones). But maybe IAR hides this from you.

LR is the top subroutine return address - which is odd as I expect. Is that just after a call?

But most likely things have gone wrong well before the hard fault. Perhaps you ran out of stack space so then stack and other variables interfered with one another. Or there was a bug relating to pointers or writing beyond the ends of an array.

It's also possible that you're being too aggressive with clock speeds / wait-states (if you didn't stick within the limits in the Reference Manual or use a configuration tool that follows those limits such as Cube) so the processor can't reliably read program instructions.

These things aren't easy to debug.

Hope this helps,

Danish

Ozone
Lead

In addition to Danish, you seem to have a starting point:

> Precise data access error at 0x200A8801

Cross check the map file (if necessary, re-build to create one), and observe the variable/data at this location in the debugger.

It is an odd address, so perhaps an unaligned access.

Abdou
Associate II

Thank you guys for you're reaping.

0x08012174 is a valid address, but the problems don't always give me the same address, each time gives me addresses differents.

I'm using STM32F207GZ, so the frequency can up to 120MHz, & I reconfigure it at 16MHz but always the same problems.

the program crash when I run the program, but if I debug it step by step, it will not crash.

my question is when the program give address of HardFault what can i do??

Sometimes I find the address in memory contain the values.

Thank you 

Ozone
Lead

The actual message text "has escalated a configurable-priority exception to Hardfault" sounds like your problem is in or with an interrupt handler.

Abdou
Associate II

yes the hardfault is related with an interupt.

Please how can I get the problem where is exactly, same function or something in IAR Systems can I get the last instruction where the crash is up 

thank you.

Difficult to say without the actual hardware and code.

But I would first identify the interrupt handler routine causing the issue, and review it.

Perhaps instrumenting or modifying the code.

There is a known issue with the Cortex M core if clearing an interrupt flag is the very last instruction before exiting the interrupt. But if I remember correctly, it didn't raise a hardfault.

As a side note: be careful with "livewatch" features. Reading status registers / flags will change the program flow. The debugger is no magic device.

Danish1
Lead II

How have you configured the 120 MHz? In particular how many wait-states have you given the FLASH?

What is your Vdd? (This might also affect how many wait-states you have to use with the FLASH).

Are you sure the power-supply can cope with the increased current consumption at 120 MHz. A 78L33 will probably overheat and shut down.

The "precise error" data address of 0x200a8801 sounds like the "middle of nowhere" - by which I mean I don't expect any memory to exist there. So any read / write of that address is an error.