STM32H747I Flash Management

[RIPHeisenberg]

Hello everyone,

I am currently developing a rather memory-consuming project on the STM32H747I_DISCO_M7 chip. We are utilizing 1.7 megabytes out of the 2 megabytes flash area available. According to the STM32H747I Disco manual, 1 megabyte is allocated for the M7 and 1 megabyte for the M4 chip. It is necessary to use the STM32CubeProgrammer to reconfigure the BOOT_CM7 and BOOT_CM4 addresses, as described here: [link]. The Zephyr board man-page also confirms this.

Desired Solution:

It would be advantageous to configure the M7 and M4 flash areas in KConfig or devicetree. Using the STM32Cube programmer to set the BOOT_CM_ADDR1 makes production more time-consuming and error-prone. The USER_VECT_TAB_ADDRESS in system_stm32h7xx_dualcore_boot_cm4_cm7 already provides the possibility to change the Flash bank values. Is there a native Zephyr way to achieve this? Am I overlooking something?

Let me know if my point is valide?

Best regards

[RIPHeisenberg]

Link: https://wiki.st.com/stm32mcu/wiki/AI:How_to_run_larger_models_on_STM32H747I-DISCO

[erwango]

At one moment, you'll need to update to update flash base addresses/sizes in following files: https://github.com/zephyrproject-rtos/zephyr/blob/1ae357850d5c0e37f8542e33e1146a6de52bed6e/dts/arm/st/h7/stm32h747Xi_m7.dtsi#L19-L20 https://github.com/zephyrproject-rtos/zephyr/blob/1ae357850d5c0e37f8542e33e1146a6de52bed6e/dts/arm/st/h7/stm32h747Xi_m4.dtsi#L24-L25

Then regarding the option bytes, they need to be programmed somehow before executing the binary in any case. An alternative to STM32Cubeprogrammer GUI usage would be to update west stm32cubeprogrammer runner to launch OB configuration systematically before flashing the application (not clear if you could take advantage of https://github.com/zephyrproject-rtos/zephyr/pull/69748 to do that)

[RIPHeisenberg]

Hi, thanks for the Info. I followed your tips and found following solution.

1. I added the flash1 partition as you suggested.

&flash { flash1: flash@8100000 { reg = <0x08100000 DT_SIZE_K(1024)>; compatible = "st,stm32-nv-flash", "soc-nv-flash"; write-block-size = < 0x20 >; erase-block-size = < 0x20000 >; max-erase-time = < 0xfa0 >; }; };

2. I sourced the STM32CubeProgrammer (not mandatory) export PATH=/home/maikel/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/STM32_Programmer_CLI:$PATH source ~/.bashrc
3. I made a script to set the config bytes for the STM32 config bytes. `#!/bin/bash

STM32_Programmer_CLI -c port=SWD -w ./build/zephyr/zephyr.bin 0x08000000 -rdu -ob BOOT_CM7_ADD0=0x800 BOOT_CM4_ADD0=0x81f`

It works like a charm. Are there efforts to be able to change the config bytes by Zephyr?

Best regards

[erwango]

STM32_Programmer_CLI -c port=SWD -w ./build/zephyr/zephyr.bin 0x08000000 -rdu -ob BOOT_CM7_ADD0=0x800 BOOT_CM4_ADD0=0x81f`

It works like a charm. Are there efforts to be able to change the config bytes by Zephyr?

If the question is how to upstream this part, I don't know for sure. I guess you'd need to update the cubeprogrammer runner to support this functionality. This is for sure. But now how to make it callable by west, I don't know for sure if there are ways around this . One idea would be to follow what was done on nrf to support the --recover option.

[RIPHeisenberg]

Yes something like that would help a lot. It might be a lot of work. Because of all the different config registers etc. How does nordic manage to add its vendor specific register configs to Zephyr? Thanks for the discussion. I appreciate the effort.

Cheers

[erwango]

Yes something like that would help a lot. It might be a lot of work. Because of all the different config registers etc. How does nordic manage to add its vendor specific register configs to Zephyr? Thanks for the discussion. I appreciate the effort.

I don't think this is that much of work. Idea would be to have BOOT_CM7_ADD0=0x800 BOOT_CM4_ADD0=0x81f as argument of a west flash --ob_write command.

[RIPHeisenberg]

Yes that would be great! :D