0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ 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. \$\endgroup\$ – Chris Stratton Jun 3 '16 at 23:52
  • \$\begingroup\$ I had the same issue and it turned out to be the VCCA not having sufficient power (connected to PLL). \$\endgroup\$ – Charles Nobbert Jun 23 '16 at 11:54
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – Scott Seidman Jun 23 '16 at 12:43
2
\$\begingroup\$

I confirm it was a bad connection to VCCA. The device worked without VCCA powered, but not at higher clock speeds.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.