In our project we are using the microcontroller STM32H753. We are trying to use mcuboot with the sample smp_svr (overlay-udp.conf) for software updates over Ethernet. This has been working good for the F767 microcontroller, but we are failing when using the H753 microcontroller.

From what I’ve read on git-hub I’m not sure if mcuboot right now is compatible with the STM32H7-series due to changes in the flash (dual banks and new byte alignment). Am I right or do you know any walk arounds for using STM32H7-series with mcuboot?

I’ve done the following steps when trying to use mcuboot with ”smp_svr”:

1. Build and flash mcuboot. The board boots and everything seems good.

1. Build, sign and flash the sample ”smp_svr” to flash partition slot 0. For the signing procedure to work I hade to add the argument ”align 8” when signing (default was ”align 32”), see below. Mcuboot and smp_svr boots and everything seems good.

> west sign -t imgtool -- --align 8 --key ~/zephyrproject/bootloader/mcuboot/root-rsa-2048.pem

1. Upload a second image to flash partition slot 1, usign mcumgr as the tool for uploading. No errors.

>./mcumgr --conntype udp --connstring=[192.168.2.25]:1337 image upload ~/zephyrproject/zephyr/build/zephyr/zephyr.signed.bin

1. List the images. Both images appear as intended.

>./mcumgr --conntype udp --connstring=[192.168.2.25]:1337 image list

Images:

image=0 slot=0

    version: 0.0.0

    bootable: true

    flags: active confirmed

    hash: 5bc6846f35e3f01fcb8351b1e3138ecf9f24039776e3b154095ec695e12d9e79

image=0 slot=1

    version: 0.0.0

    bootable: true

    flags:

    hash: 1b3543e439b29e03ac380f46f87e907fec45cc6aff1cd3b75c75ff570c85f174

Split status: N/A (0)

1. Test the image with the hash code. It fails.

>./mcumgr --conntype udp --connstring=[192.168.2.25]:1337 image test 1b3543e439b29e03ac380f46f87e907fec45cc6aff1cd3b75c75ff570c85f174

Error: 1

The following is printed on the UART debug port:

[00:01:36.416,000] <err> flash_stm32h7: Write offset not aligned on flashword length. Offset: 0xbfff0, 2

[00:01:36.416,000] <err> flash_stm32h7: Write range invalid. Offset: 786416, len: 16 

Do you know how to solve this alignment error when using mcuboot with the STM32H7-series of microcontrollers?

Regards, Per-Erik

Hi,

While the newlib itself is thread-safe, libgcc and libstdc++ (and therefore C++ exceptions) are not.

We currently build the GCC with --enable-threads=no (i.e. single thread model), so we are using the libgcc gthr-single.h with dummy lock implementations.

In the future, this issue will be addressed by providing Zephyr-specific gthread implementation in the libgcc (gthr-zephyr.h) and building GCC with --enable-threads=zephyr.

For more details, refer to the Zephyr SDK issue #350.

Regards,

Stephanos

Hi there,

Right now, no. archs (unlike SoCs or boards) are expected to be in-tree. If you cannot upstream your arch you will likely need to keep a fork of Zephyr patched.

Carles

Hello,

I'm using the Zephyr RTOS on a STM32F091 and have recently started working on implementing some low-power states (sleep and STOP). The system is fed by the PLL (48MHz) which is in turn fed by a HSE (20MHz).

I'm using the RTC peripheral to manage wake-ups, I simply set ALARMA at ~500ms before going to sleep.

What I see after waking up from STOP mode, is a bunch of garbage characters on the UART output and the whole system seemed to have slowed down significantly. A blinking LED for example, is now blinking much slower.

This is the code I use to enter the STOP mode (in functions pm_power_state_set and pm_power_state_exit_post_ops):

Note that this is not a Zephyr power driver, since the F091 was not supported yet. It is, however, heavily influenced by the other available power driver for STM32 platform (G0/L0 for example)

1. //Switch to HSI clock before entering stop mode, needed so we can turn HSE off before entering (page 87 of RM)
2. /* Enable HSI if not enabled */
3. if (LL_RCC_HSI_IsReady() != 1) {
4. /* Enable HSI */
5. LL_RCC_HSI_Enable();
6. while (LL_RCC_HSI_IsReady() != 1) {
7. /* Wait for HSI ready */
8. }
9. }
10.  
11. /* Set HSI as SYSCLCK source */
12. LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_HSI);
13. while (LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_HSI) {
14. }
15. //Disable the HSE now that the HSI is enabled
16. LL_RCC_HSE_Disable();
17.  
18. LL_RCC_PLL_Disable();
19.  
20. LL_PWR_SetPowerMode(LL_PWR_MODE_STOP_MAINREGU);
21. LL_LPM_EnableDeepSleep();
22.  
23. //Disable SysTick interrupts so we don't immediately wake up
24. LL_SYSTICK_DisableIT();
25.  
26. //This calls __WFI();
27. k_cpu_idle();

Then this is called whenever the STOP mode is exited:

1. LL_LPM_DisableSleepOnExit();
2.  
3. //Restore clock configuration
4. stm32_clock_control_init(NULL);
5.  
6. //Re-enable the systick interrupt
7. LL_SYSTICK_EnableIT();
8.  
9. irq_unlock(0);

The stm32_clock_control_init(NULL) does the following in sequence:

• Configure some init struct for peripheral clock configuration
• Enable default clocks (only SYSCFG peripheral clock in this case)
• Clock is switched to HSI
• PLL is disabled
• Configure and switch to PLL with HSE as source clock
• Disable HSI and MSI

To verify, I routed the SYSCLK to MCO, so I can monitor it on a scope. It shows the correct clock speed of 48MHz before entering the low-power procedure, then it is 8MHz after exiting STOP mode (HSI is startup clock).

After the stm32_clock_control_init(NULL) function has been executed, the SYSCLK is back at 48MHz, and the RCC registers show the right configuration.

Then, very shortly after, the RCC configuration is reset back to exit STOP conditions, i.e. HSI on, HSE and PLL off, HSI as system clock, back at 8MHz. This seems to happen asynchronously and I can't pinpoint why it happens.

This does not happen when I enter/exit sleep mode, only STOP.

I've verified that the Clock Security System is off. 

Any help with this would be greatly appreciated, as I am grasping at straws at this point.

Thank you kindly,

Marijn Stam

Hello,

I'm using the Zephyr RTOS on a STM32F091 and have recently started working on implementing some low-power states (sleep and STOP). The system is fed by the PLL (48MHz) which is in turn fed by a HSE (20MHz).

I'm using the RTC peripheral to manage wake-ups, I simply set ALARMA at ~500ms before going to sleep.

What I see after waking up from STOP mode, is a bunch of garbage characters on the UART output and the whole system seemed to have slowed down significantly. A blinking LED for example, is now blinking much slower.

This is the code I use to enter the STOP mode (in functions pm_power_state_set and pm_power_state_exit_post_ops):

Note that this is not a Zephyr power driver, since the F091 was not supported yet. It is, however, heavily influenced by the other available power driver for STM32 platform (G0/L0 for example)

1. //Switch to HSI clock before entering stop mode, needed so we can turn HSE off before entering (page 87 of RM)
2. /* Enable HSI if not enabled */
3. if (LL_RCC_HSI_IsReady() != 1) {
4. /* Enable HSI */
5. LL_RCC_HSI_Enable();
6. while (LL_RCC_HSI_IsReady() != 1) {
7. /* Wait for HSI ready */
8. }
9. }
10.  
11. /* Set HSI as SYSCLCK source */
12. LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_HSI);
13. while (LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_HSI) {
14. }
15. //Disable the HSE now that the HSI is enabled
16. LL_RCC_HSE_Disable();
17.  
18. LL_RCC_PLL_Disable();
19.  
20. LL_PWR_SetPowerMode(LL_PWR_MODE_STOP_MAINREGU);
21. LL_LPM_EnableDeepSleep();
22.  
23. //Disable SysTick interrupts so we don't immediately wake up
24. LL_SYSTICK_DisableIT();
25.  
26. //This calls __WFI();
27. k_cpu_idle();

Then this is called whenever the STOP mode is exited:

1. LL_LPM_DisableSleepOnExit();
2.  
3. //Restore clock configuration
4. stm32_clock_control_init(NULL);
5.  
6. //Re-enable the systick interrupt
7. LL_SYSTICK_EnableIT();
8.  
9. irq_unlock(0);

The stm32_clock_control_init(NULL) does the following in sequence:

• Configure some init struct for peripheral clock configuration
• Enable default clocks (only SYSCFG peripheral clock in this case)
• Clock is switched to HSI
• PLL is disabled
• Configure and switch to PLL with HSE as source clock
• Disable HSI and MSI

To verify, I routed the SYSCLK to MCO, so I can monitor it on a scope. It shows the correct clock speed of 48MHz before entering the low-power procedure, then it is 8MHz after exiting STOP mode (HSI is startup clock).

After the stm32_clock_control_init(NULL) function has been executed, the SYSCLK is back at 48MHz, and the RCC registers show the right configuration.

Then, very shortly after, the RCC configuration is reset back to exit STOP conditions, i.e. HSI on, HSE and PLL off, HSI as system clock, back at 8MHz. This seems to happen asynchronously and I can't pinpoint why it happens.

This does not happen when I enter/exit sleep mode, only STOP.

I've verified that the Clock Security System is off. 

Any help with this would be greatly appreciated, as I am grasping at straws at this point.

Thank you kindly,

Marijn Stam