Newbie - ST32F407 Discovry board Blue led issue

[ankitmcgill]

Posted on November 02, 2015 at 05:35

Hi all,

I have just started learning ARM and have picked up the STM3F4 discovery board. Below is my first code to light up all the 4 user leds on board (connected to GPIOD 12to 15).

#include ''stm32f4xx.h''
int
main(
void
)
{
//enable clock to gpiod
RCC->AHB1ENR = (1<<3);
//gpiod - led
GPIOD->MODER = (1<<22) | (1<<24) | (1<<26) | (1<<28);
//default push pull
//default low speed @ 2mhz
//default no PUPD
//GPIOD->ODR = (1<<12) | (1<<13) | (1<<14) | (1<<15);
GPIOD->BSRRL = (1<<12) | (1<<13) | (1<<14) | (1<<15);
while
(1)
{
}
}

When I run this code, all the leds light up except tjhe blue one. Cam someone point out what I am doing wrong?

[Nesrine M_O]

Posted on November 02, 2015 at 11:08

Hi ankitmcgill,

I don’t see problems in your code it can be related to the hardware,Try to display the output signal from your PD15 pin with oscilloscope.-Syrine-

[AvaTar]

Posted on November 02, 2015 at 11:28

Try to display the output signal from your PD15 pin with oscilloscope.

There is only one ''set'' action. A voltmeter will do as well. When stepping through, can you see the bits change in the debugger (GPIOD->ODR) ?

[ankitmcgill]

Posted on November 02, 2015 at 11:59

This is weird. I did a continuity check and verified that pin PD15 is connected all the way from the MCU to the 680Ω resistor and then to the blue led to ground.

Also, when running the default ST firmware, the blue led lights up just fine.

[Tesla DeLorean]

Posted on November 02, 2015 at 17:37

I wouldn't blind write into registers like that, it's bad practice.

Also watch for the write-buffering/pipeline issue where you really should dwell briefly between enabling a clock and programming the peripheral. The SPL avoids this and has call/return overhead.

// STM32 TOGGLE PD.15 GPIO STM32F4 Discovery - sourcer32@gmail.com
#include ''stm32f4_discovery.h''
/**************************************************************************************/
void RCC_Configuration(void)
{
/* --------------------------- System Clocks Configuration -----------------*/
/* GPIOD clock enable */
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
}
/**************************************************************************************/
void GPIO_Configuration(void)
{
GPIO_InitTypeDef GPIO_InitStructure;
/*-------------------------- GPIO Configuration ----------------------------*/
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_15;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_Init(GPIOD, &GPIO_InitStructure);
}
/**************************************************************************************/
extern void GPIOTest(void);
int main(void)
{
RCC_Configuration();
GPIO_Configuration();
while(1) // Don't want to exit
GPIOD->ODR ^= GPIO_Pin_15;
}
/**************************************************************************************/
#ifdef USE_FULL_ASSERT
/**
* @brief Reports the name of the source file and the source line number
* where the assert_param error has occurred.
* @param file: pointer to the source file name
* @param line: assert_param error line source number
* @retval None
*/
void assert_failed(uint8_t* file, uint32_t line)
{
/* User can add his own implementation to report the file name and line number,
ex: printf(''Wrong parameters value: file %s on line %d

'', file, line) */
/* Infinite loop */
while (1)
{
}
}
#endif
/**************************************************************************************/

[waclawek.jan]

Posted on November 02, 2015 at 18:33

> I wouldn't blind write into registers like that, it's bad practice.

I recommend to use symbols from stm32f4xx.h (although ST was/is reluctant to properly define constants for the bit-fields, that's why I have augmented mine www.efton.sk/STM32/stm32f4xx.zip). > Also watch for the write-buffering/pipeline issue where you really should dwell briefly between enabling a clock and programming the peripheral. This is a nasty gotcha indeed. > The SPL avoids this and has call/return overhead. Not necessarily - one day, a smart optimizing linker might catch you by surprise too. IMO the safe way is to read back the value written into RCC, or to have enough ''other things to do'' (e.g. write to other RCC registers meantime). JW

[Tesla DeLorean]

Posted on November 02, 2015 at 20:24

Not necessarily - one day, a smart optimizing linker might catch you by surprise too.

Perhaps, but it would have to be very aggressive, as we're only talking about a fencing read/write, and a couple of bubbles in the pipeline would get you there. The failure mode is two back-to-back writes via an STR, which occurs if you in-line the write to the RCC followed by one to the peripheral. Going to be worse on a slower APB. A read-back of the RCC would suitably fence the operation, as the Cortex isn't going to fold write/read via a cache or pipeline shortcut. Filling in the GPIO_Init structure, or enabling all the other required clocks, and coming back to the peripheral, are also reasonably robust strategies. Comparatively this will give the most grief

RCC->AHB1ENR = (1<<3);
GPIOD->MODER = (1<<22) | (1<<24) | (1<<26) | (1<<28);

Both patterns can use an immediate load constant. Heck GCC 4.9.3 can't build FatFs with optimization without breaking it.

[waclawek.jan]

Posted on November 02, 2015 at 23:24

> Heck GCC 4.9.3 can't build FatFs with optimization without breaking it.

Why? Surely, FatFS is more about shifting data than dealing with peripherals, or am I overlooking something (I don't use it just am aware of its existence and having written some FAT stuff before)? Can you please give details - maybe in a different thread, as this is getting OT here? Thanks, Jan

[ankitmcgill]

Posted on November 08, 2015 at 08:54

Hi Clive, 

Thank you for your help. Writing the code from scratch and using rcc functions and gpio structures to initialize the clock gpiod solved the issue. I am able to light up all the leds now.However I still have some doubts ...1. What is the write-buffering/pipeline issue issue that you refer to?2. When I upload my original program to the board using the ST-LINK utility, it would sort of hang after uploading and automatically disconnect from my computer. I receive the following message At this point I would not even be able to connect to the board unless I use the ''connect under reset mode'' option in ST-LINK. Flashing the board with default discovery firmware makes this go away. So what in my original code be causing this?Thanks for all the help!