Two different STM32H7 REV Y mcus hang on new 1.4.0 HAL

[David Viens]

I have two very unrelated hardware projects that worked fine under STM32Cube_FW_H7_V1.3.2 namely STM32H750 and a STM32H743 both rev Y

Comparing STM32Cube_FW_H7_V1.3.2\Drivers\STM32H7xx_HAL_Driver with STM32Cube_FW_H7_V1.4.0\Drivers\STM32H7xx_HAL_Driver I see quite a few instances where REV_ID_Y is checked in RCC and RCC_EX:

Example if(HAL_GetREVID() <= REV_ID_Y))

but I keep thinking you might have missed a spot. MCU hangs at RCC Clock init (I think- sorry just SWOing) and I need to connect under reset to unbrick it. Reverted to 1.3.2 and all is well. but its frustrating as I want to move forward. Thanks

[Tesla DeLorean]

I've seen cases where the H7 reads zeros from the DBGMCU space, so HAL_GetREVID() might not be working as expected.

[David Viens]

Thanks. I can successfully read 0x00001003 from HAL_GetREVID() (at least when everything is inited) on 1.3.2 that is for sure

[David Viens]

After a Connect under reset in st-link I can step in the boot code, but LoopCopyDataInit (as matched from PC per IDA disassembly of my .elf) is way too big so I cant get where it dies. And If i hit RUN I get a "Can not run core while booting from flash memory and Read out protection is activated" ... which I it inst, I guess its a bad error report.

[David Viens]

Ok this is how I fixed the issue (for anyone having the same problem).

Upgrading the SDK and generating code from CubeMX did NOT apparently change some critical new code in system_stm32h7xx.c that makes it all work.

So to fix, save your .ioc elsewhere, generate code and compare everything with your old code. There is just too much changes to the SDK to have this work magically.

Here's just a part of everything that changed which CubeMX didnt do on my older 1.3.2 rev: