STM32CubeMX FMC pin solver hangs on STM32H7R7 when legal alternate FMC address mappings are present

[7alken]

“STM32CubeMX FMC pin solver hangs on STM32H7R7 when legal alternate FMC address mappings are present; removing redundant A16–A23 alternate functions avoids the hang.”

… attached is project with stm32H7R7L8H3 with FMC32 configured with 4x SRAM and 2x SDRAM but for this was used patched mcu definition file “STM32H7R7L8HxH.xml” (included, has commented alternate address lines on upper pins which point to bottom address pins in fact, the “solver” is probably confused - I opted to forced exclusive one selected variant and then FMC configurrator stopped hanging on multiple selected SRAM/SDRAM … without patch it is impossible to configure … it probably MUST beheve similary on different parts also - provided is also list of potential other packages … I used chatgpt (high) to analyze this and she found issue also with help of log …

I also tried to configurpart stm32H7R7L8H6H (only 16bit FMC) - this worked … and surprisingly worked also stm332F429NEHx with FMC32 - I was confused too, where is problem; definition data looks ok according to datasheet but even latest version of CubeMX was simply hanging … includedis also list of “similary looking definitions to test”

Petr

[7alken]

actuall problem found in log ….

“

Ya — these files gave us a much better clue than I expected. I think we are now looking at a CubeMX pin-assignment solver problem, rather than a bad FMC peripheral definition or some electrical FMC32 restriction.

The strongest clue is in your log. At the point where CubeMX becomes stuck it records:

Mcu:1689 - InternalPropertyChange: try BijectiveRequest:23 bits

and then there is essentially no progress for several minutes until the project is closed/killed.

BijectiveRequest is very suggestive: CubeMX is trying to solve a one-to-one mapping of a multi-bit peripheral signal group onto available pins. And 23 bits is suspiciously close to exactly the thing you are changing in FMC — the large address-bus selection.

The H7R7 device XML itself looks basically sane

Both your problematic OCTO device:

STM32H7R7L8Hx — TFBGA225 OCTO, 152 I/Os

and the working HEXA device:

STM32H7R7L8HxH — TFBGA225 HEXA, 150 I/Os

point to exactly the same FMC implementation:”