Nucleo-H743ZI2 and Rev.V support

[robcazzaro]

New Nucleo H742ZI2 boards are shipped with Rev.V chips, which have quite a few core differences in clock speed, clock voltage level (new VOS0), RCC registers, Kernel clock for ADC, etc as per https://www.st.com/content/ccc/resource/technical/document/application_note/group1/95/22/7c/0c/57/de/4b/f9/DM00609692/files/DM00609692.pdf/jcr:content/translations/en.DM00609692.pdf

In order to fully support the Nucleo H743ZI2, support for Rev.V should be enabled and proper clock, VOS0, ADC dividers, etc must be added

[fpistm]

Hi @robcazzaro ,
The ZI2 variant already exists, as the core use HAL/LL, this should be transparent.

[robcazzaro]

I probably misunderstand how I'm supposed to use it, then. I can see that the SystemClock_Config() function from the HAL is included into the variant.cpp file for each processor/board.

The function currently in the repository, initializes the clock with a voltage scale of 1, and clock of (I think) 400MHz, plus it's using the internal clock, and not the 8MHz clock from the STLink (which being provided by a crystal, is more stable than the internal oscillator)

I haven't looked further, but I'm pretty sure that the ADC clocks are not configured properly for the Rev V divisors (why ST decided to make Rev V so different from Rev Y and breaking code, it's a question better left to another time :))

So, if I want to properly enable a Nucleo H743ZI2 with Rev V, what are the necessary steps? I can generate any file with STM32CubeMX and cut/paste into the right places, but I see a few differences in the type of calls that variant.cpp in this repository uses, and the code I get from the latest STM32CubeMX and HAL 1.5.0 for STM32H7

And shouldn't the Arduino core library already provide a variant of the Nucleo H743ZI2 with the proper setting for Rev V, which is all that is available to users now?

[fpistm]

By default, I didn't use the clock provided by the STLink as on several boards the ST-LINK part of the PCB can be cut out to reduce the board size.
The SystemClock_Config is a weak function so user can easily override it at sketch level.
Anyway if you think a better one can be done you can provide a PR and maybe a new entry board dedicated to this rev. The ADC clock only relies to call __HAL_RCC_ADCx_CLK_ENABLE() so it is assumed it is correctly set in SystemClock_Config.
Note that the core now used HAL v1.6.0 for STM32H7.

[robcazzaro]

thanks for all the prompt replies.

Interestingly enough, both on the ST.com site and via STM32CubeMX, the most recent version of the HAL is 1.5.0. Where can I find 1.6.0? That could explain the differences I noticed

And, no, the Rev Y variant of the HAL has different ADC initialization code, so at the moment using the Nucleo H743ZI platform on a Rev V H7 chip will result in malfunctioning or non-functioning ADC code. Using only 400MHz clock has no downsides (apart from losing a big chunk of performance), but the ADC code must be tweaked and use different clock dividers and also has different max conversion rates. Basically the Rev V ADC is really a different block from the Rev Y one (documented in the application note I linked above, I suggest you have a quick look at it to see the amount of differences).

For what is worth, all recent Nucleo H7 boards ship with Rev V (and have since mid summer), and the new PCBs are all monolithic. Nobody can buy anymore a Nucleo H743ZI or ZI2 with the breakoff ST Link (unless is old stock). I was disappointed to discover that there's no way to break off the ST Link anymore. So, for newer users, it would be best to have a specific variant that uses the HSE clock and properly sets clock at 480MHz (with the right voltage scaling of 0). And uses the right HAL for the Rev V chip, otherwise there will be problems here and there.

I was debating if I wanted to use the Arduino cores for my project (which relies heavily on ADC), but it looks as if I will have to do pretty much all the same amount of configuration work with the STM32CubeMX, not to mention figure out how to make the ADC work with Rev V. At this point, I think I will use the default integrated development from ST, at least I will be using something supported.

I will leave this open, because until there is a specific variant for Rev V, the current H7 core is not fully functional. It might also help people trying and having ADC problems and searching online for clues. As I mentioned before, the Rev V release has caused quite a few issues and there are more than a few threads in the official ST forum

[fpistm]

Well, you talk about the https://www.st.com/en/embedded-software/stm32cubeh7.html
v 1.5.0 while I talk about HAL version 1.6.0 which is include in this Cube H7 release.

I've already read it, I will try on my side with this version.
Then I will update this issue.

[fpistm]

@robcazzaro
I've made an update to use HSE (bypass).