[SOLVED] STM32F746G-Discovery Board is giving HardFault after a few minutes of use

[sv1eia]

Posted on September 26, 2015 at 18:29

Hi,

Recently I got two STM32F746G-Discovery boards. I run the same firmware on both. On one the firmware runs ok without any issues. On the other, I got stops and via the debugger seen that is staying in loop inside HardFault_Handler function.

/**
* @brief This function handles Hard Fault exception.
* @param None
* @retval None
*/
void HardFault_Handler(void)
{
/* Go to infinite loop when Hard Fault exception occurs */
while (1)
{
}
}

What can be done for this? Is there any procedure for faulty boards?

[Tesla DeLorean]

Posted on September 27, 2015 at 04:14

I suspect it starts by talking to your vendor/distributor about their policies and getting an RMA started with them.

Of more immediate practical use, you might want to get an actual Hard Fault Handler coded so you can make sense of the failure, whether it relates to caching, or flash wait states, etc.

[sv1eia]

Posted on September 27, 2015 at 10:31

Thanks Clive,

It looks the mystery got solved, I'm currently conducting some more tests to verify. In my application the sysclock was set at 216MHz and the SDRAM was used too (for STemWin). Searching around seen that the SDRAM might not be working ok with 216MHz sysclock. So I reduced it to 200MHz and now it looks it works ok, yet I'm still conducting some endurance tests. The real puzzle is why the other board works ok even at 216MHz, it seems that even at high clock speed some SDRAM chips do seem to barely work. If it only ST made this clear in some STM32F746G-Discovery documentation about the proper SDRAM sysclock, it would save us the time and effort to find the problem ourselves.

[Nickname12657_O]

Posted on September 27, 2015 at 14:01

Dear christos, 

Indeed it might be the root-cause since our SDRAM interface is not qualified  beyond 200MHz when VDD is at high range such as 3.3 Volts.  The other board is working by chance as it depends  on our process variations from part to part and also the sdram ic part to part variance with a sepecific load for clock and data lines.  I invite you to look on our datasheets and also this is why the default clock demonstration on discovery is limited to 200Mhz.Cheers ST1-32

[sv1eia]

Posted on September 27, 2015 at 14:16

After quite some hours of free-running ok at 200MHz seems that this is the remedy.

Thus the case is solved.