How can firmware detect that it is running on a STM32H743ZI2 vs a 743ZI? The CPUIDs are identical.

[n2wx]

So I'm back to the silly problem where the HAL misconfigures the default HSI calibration when I flash the same firmware to an STM32H743ZI that works on a ZI2, and vice versa: That is the HSI clock is off by 4% (see these questions

https://community.st.com/s/question/0D50X0000BiD6fISQS/stlink-provides-808-mhz-instead-of-8000-on-new-nucleoh743zi2?t=1583004744665 and https://community.st.com/s/question/0D50X0000BYocRMSQZ/stm32h7-64mhz-hsi-is-off-by-4 for ex).

I know how to fix it manually by redefining RCC_HSICALIBRATION_DEFAULT depending on whether I'm at rev Y or rev V but I ran into a stumbling block: Firmware can't use the SCB CPUID to distinguish between rev Y or rev V, or at least I can't figure out how because they have identical SCB CPUIDs (0x411fc271 if you're interested).

Is there some other way that code can tell which rev it's running on? Surely there must be some constant on the wafer that has the revision but I can't find it. Please help me out. Thank you

[Tesla DeLorean]

The DEVID in DBGMCU should identify the stepping, but on the H7 this tends to get blocked if the debugger in running.

[Pavel A.]

IIRC in SystemInit() there is a check for rev. Y. I don't have rev. Y so cannot test.

-- pa

[n2wx]

Thank you. I now see DBGMCU documented on page 3166 of the ref manual. I wish TrueStudio would have attempted to show it, but I ought not complain given the price.

Do you recall if having the debugger running the program was enough to block it or was it more an issue of being unable to inspect it while it was paused? I'm trying to determine if it's even worth pursuing, it probably isn't if running is enough to obstruct it.

[n2wx]

Your recollection is correct - there's code that checks for (DBGMCU->IDCODE & 0xFFFF0000 ) < 0x2000000 and the comment claims it's rev Y when that condition is true. I do have a Y board to try it. I'll report back what I (or actually the debugger) sees. It definitely doesn't come up true with a debugger attached to a "V" rev

REPORTING BACK it seems to reliably hit the breakpoint before it hits main() when I run it on a Y board so I think the check is viable and maybe I can get away with reconfiguring the clock long after SystemInit(), when it's in my code.

Ahhh I wish ST had dealt with the HSI cal in their stuff dynamically, it would have been so easy for the reset of us. Not how I wanted to spend my Saturday night.

[PMath.4]

 #define MAINCLOCKSPEED (HAL_GetREVID()==0x1003 ? 400 : 480)
 if(HAL_GetREVID()==0x1003)__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1); // Y parts have revid 0x1003
  else __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE0);
  
RCC_OscInitStruct.PLL.PLLN = MAINCLOCKSPEED;
 

From my startup code

[waclawek.jan]

IIRC the thread from first link in initial post deals with STLink's HSI not the target's... Am I overlooking something?

JW

[n2wx]

No, you're not overlooking something, I was. I wasn't careful when I copy/pasted.