STM32H7B3 - Warning - CubeIDE 1.3 All Projects are in a broken state

[ehughes]

Just a warning/advisory.

 I just got an STM32H7B3 discovery kit.   The part looked interesting as it has a lot of internal RAM for LCD frame buffers.   

What I discovered is that the all of the example code,  even the code that CubeIDE 1.3 generated from the V1.7.0 H7 package is broken.  If you generate a skeleton project with with CubeIDE and select the STM32H7B3 discovery kit, it will generate a project that will crash  in the  SystemClock_Config(); function.      When the code turns the PLL on,  the CPU goes nuts the debugger connection is lost.     The Crystal Oscillator is working (verified with a scope).    I can switch the CPU clock to the internal reference oscillator and it works OK.     Also,  all of the example projects supplied in the V1.7.0 H7 package exhibit the same behavior at the same line of code

I am going through the errata now to see if I got old silicon ,etc.   I am pretty sure the hardware is OK.  The pre-compiled binary does work but NONE of the examples actually work, even the LED/GPIO blinker.


----update------

After some experimentation I discovered that I could make the examples in the V1.7 package work by decreasing the CPU clock to 200MHz from the default of 280MHz.
I set DIVN1 to 200 and could get things working. Any value above that would cause erratic behavior.


Same for skeleton the project created from scratch.    Any CPU frequency about 200MHz is a problem.

[Jay1011]

Are you sure the board is receiving adequate power?  I've not used the Discovery boards, just the Nucleo ones, and the Nucleo boards typically enumerate to the USB host as self-powered, so it's legal for the host to limit the current delivered to something like 100mA.  Most USB hosts won't impose such a limit, but it might be worth a check.  The same issue could occur if you have your board plugged into an unpowered USB hub or something similar.

TL;DR -- if you're powering solely from USB, you might want to check the "VBUS" USB voltage as received at the board.

[thm_w]

Possible to output the 200MHz either directly or via a divider and check that its as expected?

[hansd]

From STM32H745I-DISCO 400MHz
/** Supply configuration update enable
  */
  HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);
  /** Configure the main internal regulator output voltage
  */
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);

  while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}
  /** Macro to configure the PLL clock source
  */
From STM32H7B3I-DK 280MHz
/*!< Supply configuration update enable */
  HAL_PWREx_ConfigSupply(PWR_DIRECT_SMPS_SUPPLY);

  /* The voltage scaling allows optimizing the power consumption when the device is
  clocked below the maximum system frequency, to update the voltage scaling value
  regarding system frequency refer to product datasheet.
  */
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE0);

  while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}

Problem must be in voltage scaling. Also check on the board that SMPS Supply Config is done correctly.

[ehughes]

I was not in the office today to check the hardware but after reading through the reference manual again, the issue may be the default flash latency.       The example projects and the projects that cube IDE generate seem to have incorrect values.     

[Berni]

Yep a lot of times stuff from STM CubeMX doesn't work.

None the less i still use it cause it provides a good starting point in bringing the hardware up into a working state. Makes for a good starting point for new projects and quick experimentation, letting you replace any underperforming original HAL drivers with your own at your own pace.

For your particular issues id enable the clock output pin and measure the frequency to make sure it is actually running at the clock speed it should be running and that the PLL is stable. If all is ok then start adjusting clock speeds, only one clock at a time between recompiling code. This will help you narrow down the problematic clock output where you can then continue investigating if perhaps whatever that clock is feeding is configured wrong. Flash sounds like a good hint too.

[ehughes]

it provides a good starting point in bringing the hardware up into a working state. Makes for a good starting point for new projects and quick experimentation,

It is much worse than that!       The issue here was the the examples packaged with CubeIDE all crash.    Just a simple skeleton project will not even run using the default settings.  I get that these tools will have bugs and such... Been dealing with MCUs for 20 years now and it has always been this way.      I fully expect to have to rewrite peripheral drivers, etc. but  it would be nice to have a basic project come up and work to see *something* happen correctly.

I did verify that the root cause of the problem was the FLASH_LATENCY setting.    All of the examples and the generate code for a skeleton project all use a value of FLASH_LATENCY_3 which simply cannot work with the default clock config. The other issue I noticed is that the magic peripheral tool doesn't even allow for a correct setting.    The max value is FLASH_LATENCY_3 .   I am guessing they have a script that auto generates the code based upon this max setting.   For this MCU,  it may never have been coded into CubeIDE correctly.

[Berni]

Okay that is a bigger blunder than i usually find with CubeMX. I usually just have problems with a peripheral being misconfigured or its driver being broken in some way. But so far all of my projects made it to the main loop without major problems.

Oh and the H7 series launch was pretty terrible all together. For one of the STM32H7 family chips i been using they suddenly released a new updated revision of the chip that changed the max CPU clock speed from 400MHz to 480MHz. Okay so they figured out they can squeeze a bit more speed out of it later on, sounds nice. Buuuut they also slightly changed the functionality of some registers in the ADC and the USB peripherals, so if you ran existing firmware on that new revision chip your ADC would be running at twice the clock speed(causing it to stop working if it was already set close to max speed) and the USB registers changed around so much that it would not work at all with any existing software. And this is just a revision! It doesn't get a new partnumber, It doesent even get a special letter on the end of the partnumber! If you order the chip on digikey you had a random chance of getting the old or new revision chip, only way to know was to check the markings on the chip when you get it!

And to make things worse CubeMX was then updated for the new revision chip. So if you still had old revision chips the ADC and USB will not work in projects generated by the new CubeMX and vice versa.

EDIT:
Oh and i had to manually find this stuff out. They just did an engineering change order like for any revision where there brush it off as slight differences. There is no warning that software using there peripherals is guaranteed to break on the new revision. Nor is there any trace of the old 400MHz information left on the websites. Digikey will list it as a 480MHz ARM CPU at a point where they might still be shipping out old revision chips from the existing stock.

[nuclearcat]

Maybe related to this?
https://www.eevblog.com/forum/microcontrollers/stm32h7-series-revision-beware-of-the-changes!/

[ehughes]

I saw the thread on some of the mask changes.  It is too bad.    The GFX hardware in the ST chips is better than NXP (although the RT family has a nice GFX engine)  and they tend to include more SRAM.    This chip was interesting as you could drive a fairly large display without having to use external SDRAM for 2 frame buffers.

I am concurrently evaluating several solutions at the moment.     Might be that this family needs a few more years of maturity.

[HwAoRrDk]

If you order the chip on digikey you had a random chance of getting the old or new revision chip, only way to know was to check the markings on the chip when you get it!

In that situation would you not have good cause to return any old revision chips and claim a refund? Essentially they're not fit for purpose (and possibly also not "as described") if they don't work with any software written to the current specs and using the manufacturer's current toolchain.

Seems crazy that ST would make such significant changes without even altering the part number. I've seen some other manufacturers change a part no. suffix simply due to a change of factory, with no changes to spec at all.

[Berni]

Well if you know about this revision blunder then you can probably make sure you get the right ones by asking them.

Its more of a trap when you have no idea about the significance of this revision. Say that you just started making your project after this thing. You would design in the chip, you get the new documentation, then you build the prototype and happen to get an old revision chip, resulting in tearing your hair out over why its doing weird things. Or you already designed the project for the old chip and is already in production, but then the next production run you do results in boards that don't work and you have no idea why.

[ehughes]

Just as an update....     ST finally looked at the issue.      They admitted to a few bugs in CubeIDE that was generating bad default settings.  It is both a flash latency issue which is cause by an improper voltage settings.

At some point there will be an update but for now STM32H7A3/B3 projects don't work out of the box.

Also, it is clear that the examples in the firmware package support package aren't actually tested before release. The ones I tested (graphics related) hardfault/crash for having improper voltage/flash configuration.

 

[dmendesf]

I'm a happy user of STM32 chips but this bullshit also drove me nuts. I think it's related to their "10 years commitment" for chip manufacturing. They can't just make a new revision (stm32f743A) and stop making the older ones, so they cheat and call both the same name.

Oh and the H7 series launch was pretty terrible all together. For one of the STM32H7 family chips i been using they suddenly released a new updated revision of the chip that changed the max CPU clock speed from 400MHz to 480MHz. Okay so they figured out they can squeeze a bit more speed out of it later on, sounds nice. Buuuut they also slightly changed the functionality of some registers in the ADC and the USB peripherals, so if you ran existing firmware on that new revision chip your ADC would be running at twice the clock speed(causing it to stop working if it was already set close to max speed) and the USB registers changed around so much that it would not work at all with any existing software. And this is just a revision! It doesn't get a new partnumber, It doesent even get a special letter on the end of the partnumber! If you order the chip on digikey you had a random chance of getting the old or new revision chip, only way to know was to check the markings on the chip when you get it! :palm
 

[paul002]

I use a nucleo 144 with a h745zi. Thought 2 cores is handy. Big mistake. Complicated . I am busy with a arm-sdr Example of https://www.i2phd.org/armradio/index.html but getting the ADC working and the interrupts correct is almost imposible. Every step you add you hit bugs of cubemx, but now I more or less know how to deal with it. Have a skeleton project which I use to compare the generated code. Special in the stm32h7xx_it.c file cubemx removes interrupt handlers crashing your application. Now I have most stuff working together spi, dma ADC, dma dac, freetos, timers,  datacaching etc. You have to test every I/o Independent and then try to bring together, just too simulate a Crystal receiver 

[DD4DA]

I recently bought a STM32H747I discovery board. I really liked the display with the DSI, because i still use an STM32F7 disco board, which also uses this display. So I can swap times. When buying it, I was not careful, because this H747 MCU has an F4 and an H7 core, which is connected to the system via many buses and bridges. But this is exactly where the risk of turning the board into a letterpress is built in. There is an initialization with which the clock domains and processor configuration are programmed. If you are not careful, the processor can only be brought back to life with the help of a full JTAG (not just SWD). I look again for the line that does this. the disco board and me, will never be happy.
 

[ehughes]

Just an update.      It has been 6 weeks or so.     A new release of CubeIDE (1.4)  and the associated firmware projects.   


Default projects are still broken.   I have been trying to work with support but they are not actually testing there changes on actual hardware.      They claimed to fix it but the skeleton code (as well as some of the application examples in the firmware repository) will crash as soon as the PLL starts.


It is possible to fix the issue manually but don't rely on CubeIDE to generate working clock/flash init code out of the box.

[dmendesf]

I generated code for a Stm32F407 yesterday (old stuff) and it crashed. Luckly I remembered this thread and lowered the clock (working again...) then put a higher latency for flash with higher clock (also worked).

Damn ST... don't mess with older hardware this way...