STM32F0 Discovery -> Demo source hard faults???

[tonofsteel]

Posted on November 04, 2013 at 05:13

I got the IAR tool chain installed and downloaded the discovery kit firmware package from the page:

http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF253215

I open the STM32F0-Discovery-Demo and then in IAR select Project->Download and Debug.

I anticipate the LED's turning on just like when the board was powered up through USB before programming and...... nothing.

So I go through the code step by step in the debugger to try track down the problem and here is what I get:

In main the following is called:

  /* Configure LED3 and LED4 on STM32F0-Discovery */

  STM_EVAL_LEDInit(LED3);

Which you end up in stm32f0xx_gpio.c at:

void GPIO_Init(GPIO_TypeDef* GPIOx, GPIO_InitTypeDef* GPIO_InitStruct)

In this function the following is called:

        /* Speed mode configuration */

        GPIOx->OSPEEDR &= ~(GPIO_OSPEEDER_OSPEEDR0 << (pinpos * 2));

If I hit F11 step into on this line the LED debugger light on the board flashes and nothing further happens.  When I hit break I end up at the following:

void HardFault_Handler(void)

{

  /* Go to infinite loop when Hard Fault exception occurs */

  while (1)

  {

  }

}

What??? How is it possible that the factory demo code does not work for a simple LED blinking example.  I have to assume due to my experience that I am missing something but what is it?

I am at a loss of even what the do next, do I start messing around in the stm32f0xx_gpio.c file?  I find it hard to believe that there would be an error with the above code since it is such a basic example that comes pre-installed, so any trouble with this code should have been long sorted out.

I installed IAR in a virtual machine (Windows 7) for testing purposes running on a Windows 8 computer.

[Tesla DeLorean]

Posted on November 04, 2013 at 16:50

What??? How is it possible that the factory demo code does not work for a simple LED blinking example.

Would seem to be more something I'd blame IAR for, I'm not sure what version of the tool chain the demo was constructed on, but it's probably not the same version you're using.

The Hard Fault is the sign of a pretty gross failure, where the wrong addresses are touched, wrong instructions used, or a broken stack. Use the opportunity to implement a capable handler which can provide you with the registers and CPU context so you can identify the instructions and reason for the failure. Joseph Yiu has several books/examples of more effective fault handlers.

[tonofsteel]

Posted on November 04, 2013 at 17:16

[tonofsteel]

Posted on November 04, 2013 at 17:18

[tonofsteel]

Posted on November 04, 2013 at 17:21

[Tesla DeLorean]

Posted on November 04, 2013 at 17:25

Mobile device?

[tonofsteel]

Posted on November 05, 2013 at 03:42

I ended up finding out what my issue was and indeed it was something I was doing wrong.  I received the package and just assumed that I had a STM32F0 discovery board.  However what I received was actually a STM32VLDISCOVER.  So this explains the hard faults.  I was sure in the past that when I tried to program a chip and had the wrong one selected that a warning or error would be thrown when working with other platforms.  So now I am OCD with the part numbers and specific chips on specific boards.  I see there is a whole slew of discovery board and even multiple ones in the same Fx line.