ChibiOS Free Embedded RTOS

Posted: **Tue Oct 11, 2022 6:29 pm**

A software bootloader may configure the PLL before the ChibiOS application runs. hal_lld.c can deactivate the PLL in case it's already on, and then reactivate when it has configured it.

Below is an example for the L4+ series:

Code: Select all

$ git diff HEAD~1 -- ChibiOS_20.x.x/os/hal/ports/STM32/STM32L4xx+/hal_lld.c | cat -p
diff --git a/ChibiOS_20.x.x/os/hal/ports/STM32/STM32L4xx+/hal_lld.c b/ChibiOS_20.x.x/os/hal/ports/STM32/STM32L4xx+/hal_lld.c
index 73b3eb936..4779bc459 100644
--- a/ChibiOS_20.x.x/os/hal/ports/STM32/STM32L4xx+/hal_lld.c
+++ b/ChibiOS_20.x.x/os/hal/ports/STM32/STM32L4xx+/hal_lld.c
@@ -274,6 +274,16 @@ void stm32_clock_init(void) {
      This range is used exiting the Standby mode until MSIRGSEL is set.*/
   RCC->CSR |= STM32_MSISRANGE;

+#if STM32_ACTIVATE_PLL
+  /* Disable PLL in case starting in ON */
+  /* PLL deactivation */
+  RCC->CR &= ~RCC_CR_PLLON;
+
+  /* Wait until PLL Ready is cleared */
+  while ((RCC->CR & RCC_CR_PLLRDY) != 0u)
+    ;
+#endif
+
 #if STM32_ACTIVATE_PLL || STM32_ACTIVATE_PLLSAI1 || STM32_ACTIVATE_PLLSAI2
   /* PLLM and PLLSRC are common to all PLLs.*/
   RCC->PLLCFGR = STM32_PLLPDIV | STM32_PLLR  |
@@ -293,6 +303,14 @@ void stm32_clock_init(void) {
 #endif

 #if STM32_ACTIVATE_PLLSAI1
+  /* Disable PLLSAI1 in case starting in ON */
+  /* PLLSAI1 deactivation */
+  RCC->CR &= ~RCC_CR_PLLSAI1ON;
+
+  /* Wait for PLLSAI1RDY to clear */
+  while ((RCC->CR & RCC_CR_PLLSAI1RDY) != 0u)
+     ;
+
   /* PLLSAI1 activation.*/
   RCC->PLLSAI1CFGR = STM32_PLLSAI1PDIV | STM32_PLLSAI1R |
                      STM32_PLLSAI1REN  | STM32_PLLSAI1Q |
@@ -307,6 +325,14 @@ void stm32_clock_init(void) {
 #endif

 #if STM32_ACTIVATE_PLLSAI2
+  /* Disable PLLSAI1 in case starting in ON */
+  /* PLLSAI1 deactivation */
+  RCC->CR &= ~RCC_CR_PLLSAI2ON;
+
+  /* Wait for PLLSAI1RDY to clear */
+  while ((RCC->CR & RCC_CR_PLLSAI2RDY) != 0u)
+     ;
+
   /* PLLSAI2 activation.*/
   RCC->PLLSAI2CFGR = STM32_PLLSAI2PDIV | STM32_PLLSAI2R |
                      STM32_PLLSAI2REN  | STM32_PLLSAI2P |

Posted: **Mon Oct 17, 2022 4:28 pm**

Hi,

The solution for this could be to not let the loaded application to re-initialize by setting STM32_NO_INIT at TRUE. Bootloader and application should have the same mcuconf.h settings, this way all the calculated macros would be the same. This also makes the boot a little faster and use less code space.

Is this not acceptable for some reason?

Giovanni

Posted: **Mon Oct 17, 2022 5:25 pm**

Giovanni wrote:Hi,

The solution for this could be to not let the loaded application to re-initialize by setting STM32_NO_INIT at TRUE. Bootloader and application should have the same mcuconf.h settings, this way all the calculated macros would be the same. This also makes the boot a little faster and use less code space.

Is this not acceptable for some reason?

Giovanni

Bootloader is a firmware that is typically not updated (as it typically requires JTAG/SWD access). The application firmware can evolve separately from the bootloader including the PLL settings.

I agree that if you have the luxury of developing the bootloader and application together, you may want to align them - but that is not always the case.

ChibiOS Free Embedded RTOS

hal_lld should not assume pll is disabled

hal_lld should not assume pll is disabled

Re: hal_lld should not assume pll is disabled

Re: hal_lld should not assume pll is disabled