So painful to get a LED to blink on the STM32 Discovery

[jack2]

Posted on March 08, 2011 at 23:46

Wow, I can't believe how painful it is to get an LED to blink on the Discovery board.

I am using keil UV4 32k limited edition. I can download and run the demo project just fine. But when I compile and debug/download teh following I got a dead board. Any input is greatly appreciated! &sharpinclude ''stm32f10x.h''          //ST standard periph file: DPAL layer = ''Device Peripheral Access Layer''                                 //This header must come before the rest of the headers.    &sharpinclude ''system_stm32f10x.h''   //ST standard: For SystemCoreClock and SystemInit                                                                                  volatile uint32_t msTicks;                       // timeTicks counter used by SysTick Handler in stm32f10x_it.c JRH

__INLINE static void Delay (uint32_t dlyTicks)

{   uint32_t curTicks = msTicks;                 

  while ((msTicks - curTicks) < dlyTicks);

}

__INLINE static void LED_Init(void)              //Configure the LED(s) PC9 = Green LED3 And PC8 = Blue LED4 JRH

{   RCC->APB1ENR |= 0x10000000;                   //Power interface reset   RCC->APB2ENR |= 0x10;                   //Enable GPIOC clock                   GPIOC->CRH = 0x10;//GPIO_CRH_MODE9_1; //0x10 configure for output and speed 2Mhz JRH }

__INLINE static void LED_On (uint32_t led)

{   GPIOC->BSRR = 1<<9;//GPIO_ODR_ODR9;                 // Turn On  LED }

__INLINE static void LED_Off (uint32_t led)

{                                                GPIOC->BRR = 1<<9;//GPIO_ODR_ODR9;                 // Turn Off LED }

int main (void)

{   if (SysTick_Config (SystemCoreClock / 1000))   { /* Setup SysTick for 1 msec interrupts */     ;                                            /* Handle Error */     while (1);   }     LED_Init();                                  /* configure the LEDs */                                 while(1)   {     LED_On (0x100);                              /* Turn  on the LED   */     Delay (200);                                 /* delay  200 Msec    */     LED_Off (0x100);                             /* Turn off the LED   */     Delay (800);                                 /* delay  800 Msec    */   } } #fiber #cornflakes

[Tesla DeLorean]

Posted on March 09, 2011 at 03:57

Wow, I can't believe how painful it is to get an LED to blink on the Discovery board.

I doesn't help that you make life more difficult than it has to be. What with not using the VL examples, and insisting on bit banging the registers. Sure you can do it that way, but you can't really complain about wasting fruitless hours hacking around with it. The VL Firmware library actually includes working code that will blink the LED. Just changing the include section of your code, and compile and debug, it's working just fine. Personally' I'd mask in the GPIO configuration. If you have a dead board, I'm going to suspect you used the wrong library code, or had the wrong part setting, and the debugger is trying to run to main(). This might be problematic if it is setting the PLL, flash wait states, or whatever above 24 MHz, for a non VL part. Still you should have been able to uncheck ''run to main()'' and run the board until it crapped out. #include ''stm32F10x.h'' volatile uint32_t msTicks;                       // timeTicks counter used by SysTick Handler in stm32f10x_it.c JRH ....

[stm239955]

Posted on April 18, 2011 at 04:28

Don't worry about clive1, he forgot to eat his fiber.

I understand the desire to actually get the thing to work in a way that proves you know which way is up, it _is_ embedded after all.  So why use all the obfuscated libraries?  Beats me, I won't. Your example gave me the clue I needed -- my case was missing the RCC enable of the GPIOC clock. Probably too late to be much use to you, but the missing part of your example, I think, is the setting of the GPIO_CRH value...You used 0x10...  It defaults to 0x44444444, and I think you wanted to change it to 0x44444414.  I think it is pretty important to just overwrite the part you really care about.  Anyways, that's my guess.  Other than that your sample looks fine to me. Hope this helps someone! - Greg

[Tesla DeLorean]

Posted on April 18, 2011 at 19:01

Or someone pee'd in my corn flakes.

As I pointed out you can program these device at a bit/register level, just don't complain how difficult and painful it is for you to do it that way, or to read the TRM, or to use some of the existing sample code as a starting point. The library can save you some of this effort, especially if the tools represent a steep slope on the learning curve. Even if you are capable of doing it at the bit/register level, the library offers an efficient way to get things working quickly, and most any supposed bloat comes for initialization code executed once. Further it's a lot more portable, and doesn't require subsequent users of your code to dig out a deciphering chart to figure out WTF you were doing. I also pointed out that masking in the GPIO settings would be the way to go. Sure this is embedded, but we're not using 8051's and it's not the 1980's.