# ARM strange behaviour clock speed

I am just starting with ARM and have made a small breakout board with an STM32F030 in TSSOP20 package.

I've uploaded the following program which works when the clockspeed of the device is set to 8MHz and also 24MHz:

#include "stm32f030xx.h"

void delay(unsigned int);

void delay(volatile unsigned int num) {
volatile unsigned int index = 0;
for(index = (num); index != 0; index--) {}
}

void initClock()
{
RCC_CR &= ~BIT24;
while( (RCC_CR & BIT25));   // wait for PLL ready to be cleared
FLASH_ACR |= BIT0;
FLASH_ACR &=~(BIT2 | BIT1);
FLASH_ACR |= BIT4;

RCC_CFGR &= ~(BIT21 | BIT20 | BIT19 | BIT18);
RCC_CFGR |= (BIT18);        // set x3 multiplier (24mhz)

RCC_CR |= BIT24;            // and turn the PLL back on again
RCC_CFGR |= BIT1;           // set PLL as system clock source
}

void configPins() {
RCC_AHBENR |= BIT17; // Power up PORTA
GPIOA_MODER = BIT10; // make pin 5 (2x5=10) an output
}

int main() {
initClock();
configPins();
while(1) {
GPIOA_ODR |= BIT5; // pin 5 has an LED to ground via a resistor
delay(24000*12);
GPIOA_ODR &= ~BIT5;
delay(240000*12);
}
return 0;
}


Now this simply pulses an LED attached to PA5.

When I increased the PLL from x3 to x5, by changing:

RCC_CFGR |= (BIT18);

to

RCC_CFGR |= (BIT18|BIT19);

instead of pulsing faster, the LED stayed on, although it is likely to be toggling on and off very fast rather than staying on. However, it should blink on and off like before, but just slightly faster (1.6x previous speed, by my calculations).

Is there some strange 'gotcha' that I haven't thought about? This is my first ever time using ARM chips so I'm struggling to figure it out. Thanks for any help.

• If you don't have a scope you can perhaps use a piezo disk to hear if the pin is toggling. Have you tried reversing your clock modification to see if the old mode still works, ie, that the failure is not due to some other inadvertent change? Also if you have an SWD debug connection, see if you can tell if the program is running, vs. sitting in the infinite loop of a fault handler. Jun 3 '16 at 23:52
• I had the same issue and it turned out to be the VCCA not having sufficient power (connected to PLL). Jun 23 '16 at 11:54
• When the clock config is screwed up, STM32's have a variety of clock recovery modes that they will try just to get things working. You may be in one of these modes. Jun 23 '16 at 12:43