STM32F469I-DISCO Blank Screen When using STM32CubeProgrammer instead of STM32CubeIDE

[Kneepatch]

I set my copy of the STM32CubeIDE to generate a hex file whenever I build my project. I want to make a portable file that I can give to other engineers so they can program their STM32F469I-DISCO devo boards for testing without having to install the full STM32CubeIDE toolchain on their PCs (which is quite involved and error-proned because of the various settings and packages required to get it to work on each PC).

The problem is, if I start with a new board from the factory, it does not initialize and get past a black screen if I program the board with the STM32CubeProgrammer and generated .hex file. If I use the STM32CubeIDE first, the board fully initializes and I get a good screen.

Now, if I program the board first with the STM32CubeIDE, I can program it with the STM32CubeProgrammer after and it works just fine and has all my updates.

Can you please tell me what I am missing? Any tips/tricks to figure out what is different in the process of programming it with the STM32CubeIDE vs the STM32CubeProgrammer?

[SofLit]

Hello,

---

The problem is, if I start with a new board from the factory, it does not initialize and get past a black screen if I program the board with the STM32CubeProgrammer and generated .hex file. If I use the STM32CubeIDE first, the board fully initializes and I get a good screen.

---

That's the first time I hear about that behavior. Is it only related to complex applications or also with simple onez? Ex: toggling a LED?

[Tesla DeLorean]

Not sure..

Do you have some method of doing integrity checking on your images? CRC, signing? Contrasting what's in memory vs what's in the file?

Do you see the same behaviour with .ELF objects?

Verify works?

Describing Internal FLASH only, or External QSPI FLASH too?

[Kneepatch]

This is happening with a complex application designed by TouchGFX and STM32CubeIDE. We build the GUI with TouchGFX and then we edit the low level code with STM32CubeIDE.

[Karl Yamashita]

Did you setup the STM32Cube Programmer for External Loader and select the correct flash memory?

[Kneepatch]

I've never done a CRC on an image or what's on device memory, do you have a perferred method that you use for situations like this? I see that there is a Verify option in the programmer. I've never used it before today. I think its comparing what is in memory vs what is in the device according to what is in documentation (STM32CubeProgrammer software description - User manual). I did a fresh download to the device and then verified. It failed. I get the feeling that I will never get the verify to 100% check out.

Looks like I am using internal FLASH and External QSPI:

The .ELF files sounds promising, maybe I will try that next time. I won't be able to attempt this again for two weeks (the unprogrammed factory devices are in a box at work), so I will be sure to follow up with my findings by the end of this month. Thanks for your thoughful comments!

[Tesla DeLorean · Accepted solution]

You'll need to select an External Loader associated with the STM32F469I-DISCO to write content at 0x90000000 into the Micron N25Q128 QSPI NOR FLASH

STM32 Cube Programmer natively only supports writes into the Internal FLASH of the STM32F4