Skip to main content
n2wx
n2wx
Senior
February 29, 2020
Question

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

  • February 29, 2020
  • 7 replies
  • 958 views

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

This topic has been closed for replies.

7 replies

Tesla DeLorean
Tesla DeLorean
Guru
February 29, 2020

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

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
n2wx
n2wxAuthor
Senior
February 29, 2020

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.

Pavel A.
Pavel A.
February 29, 2020

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

-- pa

n2wx
n2wxAuthor
Senior
February 29, 2020

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
PMath.4
Senior III
March 1, 2020
 #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
waclawek.jan
Super User
March 1, 2020

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

JW

n2wx
n2wxAuthor
Senior
March 1, 2020

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

Terms & ConditionsAccessibility statement