Issue changing clock speed via internal PLL
Hi all,
We have a product using a STM32L451CEU6. We have gone through low rate initial production and it has met requirements but the customer has requested a change. We are experimenting with increasing the system clock speed the device is running at by changing the internal PLL settings. The device is running from the HSE, a 25 MHz crystal oscillator. It works without issue in the baseline clock configure shown below.
When we try and change the N multiplication values in the PLLs to any other value, something appears to go wrong during the setup phase of our application code, and it appears to lock up. We have a custom serial bootloader but we cannot access it at this point, so we have to reflash completely using STM32 ST-LINK Utility and a STLINK-V3 programmer. This occurs whether we increase or decrease the N values e.g. N values of 15 or 17 do not work. This occurs whether we edit the N values in the code directly, or change them via CubeMX and regenerate the code. If we change the N value back to 16, either directly or via CubeMX generation, we can build the application, load it onto our hardware, and it works.
We have also tried reducing the PLL M value and the effect is the same.
Our application code toggles a particular pin multiple times once we finish all of the initialization code. We probe this on an oscilloscope. We see that if we change the PLL settings it never reaches this point in the code, but if we change them back to the default above it does reach this point and goes on to do everything else it needs to do.
We have stepped through out startup code using a debugger. Initially we found that it would hang at the code initializing ADC1, where an Error Handler was entered. This seemed to be caused by having the PLL and PLLSAI1 N values set differently. We only really want to increase SYSCLK, so initially kept the PLLSAI1 N value at 16. To fix this issue, we started changing both.
Stepping through with the debugger now we get into some code setting up our serial communications, which includes setting up DMA. We can get as far as HAL_UARTEx_ReceiveToIdle_DMA in stm32l4xx_hal_uart_ex.c which successfully returns HAL_OK when we step through it, but once it returns the application hangs.
The next point in our application code is a call to a custom function for setting up a buffer for serial messages. It does not step into this function but hangs once we tell it step into it.
Some other details
No operating system is running. We are using the STM32L4 HAL libraries.
We are using the following:
- CubeMX Version 6.17.0
- STM32CubeIDE Version 2.0.0
- STLINK-V3
- STM32 ST-LINK Utility v4.6.0
The project was originally set up using CubeMX Version 6.12.1 using FW_L4 V1.18.1
When opening the .ioc file in CubeMX Version 6.17.0 to regenerate the configuration code we have been pressing “Continue” when prompted about the version difference rather than “Migrate”
Other peripherals we are using:
- GPIO Ports A & B
- DMA1
- DMA2
- ADC1
- SPI2
- TIM3
- TIM15
- TIM1
- TIM2
- TIM6
- TIM16