hal_lld should not assume pll is disabled

Use this forum for requesting small changes in ChibiOS. Large changes should be discussed in the development forum. This forum is NOT for support.
faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

hal_lld should not assume pll is disabled

Postby faisal » 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 |

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: hal_lld should not assume pll is disabled

Postby Giovanni » 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

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: hal_lld should not assume pll is disabled

Postby faisal » 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.


Return to “Small Change Requests”

Who is online

Users browsing this forum: No registered users and 7 guests