STM32F10x peripheral driver bug

[rigomate]

Posted on September 09, 2012 at 16:31

I found the following bug.

I have a 16MHz crystal on my board design. I use the STM32F103RB uC with Atollic True Studio Lite 3.2. The stm32f10x.h advises me to set theHSE_VALUE according to my crystal. So I set it to16000000. In the system_stm32f10x.c file I uncommented the following line:

#define SYSCLK_FREQ_72MHz 72000000

It is supposed to the set the system clock to 72MHz, but as you can see in theSetSysClockTo72 function in the system_stm32f10x.c file:

/* PLL configuration: PLLCLK = HSE * 9 = 72 MHz */
RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE |
RCC_CFGR_PLLMULL));
RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMULL9);

It does not care about the definedHSE_VALUE value. It just assumes that the crystal value is 8MHz. Now if I want a correctly initialized 72MHz system I have to uncomment the following line:

#define SYSCLK_FREQ_36MHz 36000000

I think this is a big bug. Or at least it should be mentioned in the readme section of either file. Any ideas where there is a bugzilla or something similar? #peripheral-driver-bug

[Tesla DeLorean]

Posted on September 09, 2012 at 20:13

It's more of a matter of tailoring the code to suit your specific set of circumstances, which is left as an exercise for the user.

[rigomate]

Posted on September 10, 2012 at 14:01

Well, that's okay, but I think this very perspective of it should be mentioned to the user, somewhere in the documentation. Because I obviously have found the problem, but still took me some time. If I had known this aspect of the peripheral drivers, then it would not have given me a confusion whether I misunderstood the datasheet, or just maybe used a bad crystal.

But I guess I just go on using these drivers with suspicion in the future.

[Tesla DeLorean]

Posted on September 10, 2012 at 23:17

/*!< Uncomment the line corresponding to the desired System clock (SYSCLK)

   frequency (after reset the HSI is used as SYSCLK source)    IMPORTANT NOTE:    ==============    1. After each device reset the HSI is used as System clock source.    2. Please make sure that the selected System clock doesn't exceed your device's       maximum frequency.    3. If none of the define below is enabled, the HSI is used as System clock     source.    4. The System clock configuration functions provided within this file assume that:         - For Low, Medium and High density Value line devices an external 8MHz           crystal is used to drive the System clock.         - For Low, Medium and High density devices an external 8MHz crystal is           used to drive the System clock.         - For Connectivity line devices an external 25MHz crystal is used to drive           the System clock.      If you are using different crystal you have to adapt those functions accordingly.     */ The documentation isn't particularly good, but the libraries have gotten more robust over time. I would generally stay skeptical, and validate things behave as expected, but you'll still be miles ahead of trying to decipher the manual and bit minutia if you throw out the library and program at a register level. This is a user forum, ST plays very little attention to it, and frankly I don't know a good way to report a bug, or escalate a post/issue. Your best bet is to push back at your local ST rep or FAE. Having some kind of open bugzilla interface would suggest a much more transparent and active level of support, which given the years I worked on these parts is not something I expect to happen, and thus plan accordingly. One of the problems with PLL settings are that getting the desire output frequency is not always possible, and depends on the multiply and divide options, and the sweet spot in the comparison frequency/filtering. The math gets messy, and it takes a lot more code/cycles than writing a single constant. I've written some general solutions to setting frequency on the STM32F1 parts so I can do clock gearing, and that are aware of what clock is currently driving the part, which isn't always HSI.

[rigomate]

Posted on September 11, 2012 at 16:56

Oh darn!

''If you are using different crystal you have to adapt those functions accordingly''I certainly ran over these lines, don't know how I did not see them.Thanks for your repies, your thoughts cleared up things for me.

[Tesla DeLorean]

Posted on September 11, 2012 at 18:19

You're welcome.

The source usually represents the primary documentation, and a place to check the expected parameters to certain functions. The CHM help files provide some additional perspective, and cross reference.