2014-09-30 07:26 AM
Dear community,
I am having an issue with the setup of the PLL, which causes the CPU to jump into reset. Used libraries are libopencm3, toolchain is the latest arm-none-eabi release for linux (4.8 2014q3), JLink used as debug interface. I also tried older compiler- and gdb-versions and used different boards to evaluate, every time with the same result. The code in question is the following:// Ensure PLL is disabled
RCC_CR &= (~RCC_CR_PLLON);
// Wait for PLLRDY bit to be cleared
while
((RCC_CR & RCC_CR_PLLRDY) != 0);
// Make flash adjustments
FLASH_ACR |= FLASH_ACR_PRFTBE;
FLASH_ACR = (FLASH_ACR_LATENCY_1WS | (FLASH_ACR & (~(0x07))));
// Select HSI as PLL source
RCC_CFGR &= (~RCC_CFGR_PLLSRC);
RCC_CFGR = (RCC_CFGR_PLLMUL_MUL12 | (RCC_CFGR & (~(0xf << 18))));
//RCC_CFGR_PLLMUL)));
// Set APB and AHB prescaler to 1, which effectively is no prescaling
RCC_CFGR = (RCC_CFGR_PPRE_NODIV | (RCC_CFGR & (~RCC_CFGR_PPRE)));
RCC_CFGR = (RCC_CFGR_HPRE_NODIV | (RCC_CFGR & (~RCC_CFGR_HPRE)));
// Enable PLL ... dies right here
RCC_CR |= RCC_CR_PLLON;
// Wait for PLL to become ready
while
((RCC_CR & RCC_CR_PLLRDY) == 0);
// Select PLL as system clock
RCC_CFGR = (RCC_CFGR_SW_PLL | (RCC_CFGR & (~RCC_CFGR_SW)));
// Wait until the hardware has set PLL as system clock
while
((RCC_CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_PLL);
When debugging, the registers seem to have to values I intend them to have. But when executing
RCC_CR |= RCC_CR_PLLON;
, the cpu jumps into reset. Tried pretty much everything imaginable. Addresses of registers seem fine, too.
Hope you guys can give me some help!
Best regards, Per
EDIT:
If someone could lend me his hands with the code formatting, that would be marvelous!
Thanks, Clive! #idiotic-editor2014-09-30 07:36 AM
Format Code Block - Paintbrush [<>] icon, upper left of Word-in-a-box(tm) interface.
2014-09-30 08:04 AM
In the code snippet you posted, I don't see you selecting the processor clock source NOT to be the PLL before playing round with the PLL - in other words setting it to either HSI or HSE.
It is quite likely that the PLL will overshoot its target frequency while trying to find lock, and this could be too fast for the microcontroller given your chosen FLASH_ACR, HPRE and PPRE values. Try adding the following lines before your code snippet:// Select HSI as system clock
RCC_CFGR = (RCC_CFGR_SW_HSI | (RCC_CFGR & (~RCC_CFGR_SW)));
// Wait until the hardware has set HSI as system clock
while
((RCC_CFGR & RCC_CFGR_SWS) != RCC_CFGR_SWS_HSI);
Hope this helps,
Danish
2014-09-30 09:15 AM
Thanks for the advice! Unfortunately the cpu will still jump into reset. If it is of any further help, the setup really is the first thing to be executed after the automated startup. The whole thing is somewhat baffling ...
2014-10-01 12:17 AM
> RCC_CFGR = (RCC_CFGR_PLLMUL_MUL12 | (RCC_CFGR & (~(0xf << 18))));
//RCC_CFGR_PLLMUL))); What is RCC_CFGR_PLLMUL_MUL12? What output frequency do you expect from PLL? JW2014-10-01 06:14 AM
This line evolves into
RCC_CFGR = ((0xa << 18) | (RCC_CFGR & (~(0xf << 18))));
resulting in a desired frequency of 8Mhz / 2 * 12 = 48 Mhz.
2014-10-01 06:59 AM
Just ported the code to the STM32F051 discovery board (with HSI as system clock selected and the STM32F051R8T6 mounted to it) and it works like a charm. This leaves me really clueless. I hope you guys may come up with another idea, where the source of the problem might be. As said before, I tested this code on multiple STM32F051K8, all with the same result.
2014-10-01 08:31 AM
> Just ported the code to the STM32F051 discovery board (with HSI as system clock
> selected and the STM32F051R8T6 mounted to it) and it works like a charm. This leaves me > really clueless. IMO this points to hardware problem, most probably inadequate power source/grounding/decoupling. JW