STM32CubeProgrammer issues with OCTOSPI on STM32U5G9NJH6Q

[john-6]

I discovered this issue while trying to program the Riverdi SM-RVT50HQSNWC01 using the STM32UG59.  I spent days trying to figure out why the Riverdi demo in TouchGFX 4.26.1 was failing to program the external flash.  It always failed when trying to erase external flash.  This was with Programmer version 2.23.0.  Even with the GUI version, I found that after connecting to the board, the first read of external flash would fail.  Sometimes immediately, sometimes after a minute or so.  I discovered that the second read performed immediately after the failure would work.  Once I suffered through the first failure, I was able to read and program the external flash with no problem.  I was ready to give up on the Riverdi board when I decided to try a different system.  On this second system, I was able to create a demo from the Riverdi template, built it and program the board from TouchGFX 4.26.1.  Same version as the failing system.  I then noticed that the STM32CubeProgrammer on the second system was version 2.22.0.  

It was then obvious that all of these problems were caused by the CubeProgrammer.  This is a bug report, STM32CubeProgrammer v2.23.0 has introduced some problem with programming external flash.  I don’t know if it is restricted to OCTOSPI or if other external flash may be affected.  It’s always iffy when upgrading software, but one would expect fairly consistent behavior with features that once worked.  I lost may hours trying to find a problem that wasn’t mine.  It wasn’t an external loader issue either.  The loader was the same ST loader as used for a DK using the same chip.  The loader was installed by the Riverdi template.

[Aziz BRIGUI]

Hi ​@john-6,

I’ve tested programming external flash on the STM32U5G9-DK using STM32CubeProgrammer v2.23.0 and it’s going through as expected. Are you sure you’re using the same external loader between the two versions? Keep in mind that there are two versions of the DK loader included in the tool, MX66LM1G45G_STM32U5G9J-DK2_V1.1.0-RC1.stldr and MX66LM1G45G_STM32U5G9J-DK2.stldr.

Aziz

[john-6]

I’m using a Riverdi SM-RVT50HQSNWC01which is a smart display using the STM32U5G9NJH6Q.  The external loader is the one provided by Riverdi in their TouchGFX demo for that board.  It is \MX25LM51245G_STM32U599J-DK.stldr.”  The same loader is used in all instances that I tested.  STM32CubeProgrammer GUI 2.23.0 will program the external flash with no problem.  What fails is any attempt to program external flash on this board with the CubeProgrammer 2.23.0 CLI or the version of the CubeProgrammer embedded in STM32CubeIDE since it was recently upgraded to 2.23.  Outside of the GUI, it always fails when attempting to erase the external flash.  Even with the GUI, any time I connect with version 2.23.0 with the Riverdi board, I have to accept an initial read failure on the external flash, before the next attempt succeeds.

This behavior was exposed on two different systems using the same board.  When I moved development from the system with version 2.23.0 to the system with 2.22.0, there was no problem with directly loading the board from TouchGFX  or from STM32CubeIDE using the above external loader.  Somewhere during development, CubeIDE upgraded to the 2.23 version of the Programmer, and I could no longer program the board from CubeIDE.  The STM32CubeProgrammer standalone version was not updated, and TouchGFX didn’t have any issues programming the board’s external flash.  I tracked down the issue with CubeIDE to the recent upgrade and forced CubeIDE to use the Standalone version of STM32CubeProgrammer 2.22.0.  I was then able to programmer the board within CubeIDE.

So yes, I’m using the correct external loader as provided by Riverdi in all instances.  With version 2.23.0 of the STM32CubeProgrammer outside of the GUI there appears to be some potential timing issues or state issues.  Within the GUI there may be the same issue, but I get a second chance to programmer that you don’t get with the CLI.  I don’t have any other boards with OCTOSPI flash, so I don’t know if this problem is universal to the STM32U5G9NJH6Q or just the Riverdi implementation.  The one clear fact is that what was working prior to version 2.22.0 of the Programmer, doesn’t work in an automated workflow with version 2.23.0.

I spent many hours of troubleshooting to arrive at this discovery.  I’m confident that something changed in STM32CubeProgrammer in version 2.23.0 that is now incompatible with the Riverdi SM-RVT50HQSNWC01 and whatever implementation of the external flash they implemented.

Thanks for looking into the issue,