STM32h7b0 - System memory bootloader AN2606

[timopteran]

Hi, I'm having issues on our custom board jumping to the system memory bootrom.

Likely i have a software issue but would like to clarify the system memory address for the bootloader. This is usually listed in AN2606 but there is no explicit mention of the STM32h7b0.
https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

I've been assuming that it is the same as the STM32h7b3 as its just a low flash varient, But as I'm facing issues it would be good to confirm.

Tim

[Tesla DeLorean]

The H7Ax and H7Bx are materially the same IC

[timopteran]

@Tesla DeLorean 
Ah yes, I'd assume so. However with the boot loader being a flash tool I guess they might have a different build of the ROM code and would suggest updating the Section 3 Glossary to match the device to its relevant bootloader section a good idea.

[Tesla DeLorean]

Some of the newer STM32 you can't jump to the ROM, and a reset is different than a power cycle.

Technically you can jump, but if it's checking for valid images in flash bank(s) it might just come back.

Best to have a BOOT0 button, or simply implement you own loader with the features/functions you want, and that your board/design facilitate.

All the die have the same flash, a sub-set is tested to reduce time-on-tester and provide for price stratification. There's a value stored in system flash indicating the amount tested, and also loader version number.

[timopteran]

---

@Tesla DeLorean wrote:

Some of the newer STM32 you can't jump to the ROM, and a reset is different than a power cycle.

Technically you can jump, but if it's checking for valid images in flash bank(s) it might just come back.

---

Any ideas on how to know this for sure? I'm guessing a launch under debugger is should see the program counter come back into the flash region?

We do have a BOOT0 switch, but we are migrating a existing design. There is a automated manufacturing test stage where we use this the system bootrom to put in a production test firmware and then to put in our custom bootloader. Could be painful to change this so would like to understand before presenting options. 

[timopteran · Accepted solution]

As suspected software issue. But thank you so much @Tesla DeLorean for your input.

In my case (using Zephyr) startup / reset assembly was touching CONTROL register CONTROL_SPSEL_Msk.

Adding the following I believe fixed the 'normal' jump code as found in the following thread:
https://community.st.com/t5/stm32-mcus/how-to-jump-to-system-bootloader-from-application-code-on-stm32/ta-p/49424

	if( CONTROL_SPSEL_Msk & __get_CONTROL( ) )
	{  /* MSP is not active */
		__set_CONTROL( __get_CONTROL( ) & ~CONTROL_SPSEL_Msk ) ;
		barrier_isync_fence_full();
		barrier_dsync_fence_full();
	}

Note for those that might come looking for answers - I am using Zephyrs hook to get a very early startup hook

SYS_INIT(<jump_function>, EARLY, CONFIG_BOARD_INIT_PRIORITY);