We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Keil uVision 5.28a
Target: ST Nucleo F429ZI (Cortex M4)
My colleague created a project using Keil uVision 5.28a. The only options used in the project creation wizzard were startup.s and CMSIS->Core and DEVICE->Startup
The only code (in main.c) is shown below
#include <stm32f4xx.h> //INCLUDE THE HEADER FILE FOR THIS MCU FAMILY //this file contains the definitions for register addresses and values etc... int main(void) { //ENABLE PORT(S) RCC->AHB1ENR|=RCC_AHB1ENR_GPIOBEN; //GPIO B clock enable //CONFIGURE PORT PIN FUNCTIONS GPIOB->MODER =(1<<(2*0)); //set new pin functions on GPIOB0 while(1) //ENTER 'FOREVER' LOOP - THIS LOOP WILL NEVER EXIT { GPIOB->ODR=(1<<0); //LED ON for(unsigned i=0;i<1000000;i++) {__nop();} //delay GPIOB->ODR=0; //LED OFF for(unsigned i=0;i<1000000;i++) {__nop();} //delay } }
This should simply flash the on-board LED.
We test by a full compile and download (no debugging)
We've both stepped through all the code to try and locate the issue.
Note that when the code is run using the debugger, it works for both settings!
Any ideas?
Addendum: this is using ARMCC v6
Have a delay, or read-back after enabling the GPIOB clock. Several STM32 have an errator that you need at least one bus cycle between enabling a clock, and using the peripheral the clock enables.
Use volatile for the loop iterator.
ODR writes ALL pins in the bank.
Print out register settings on serial port so you can inspect to differences in internal states with/without the debugger. See if the debugger is setting up the chip in a way you aren't.
Already tried making the loop var volatile. Tried adding noop after setting up the GPIOB clock. No luck.
Will try looking at registers.