External Loader for m95p32-SPI-Flash with STM32G070RB, Error: Data read failed

[f.foertig]

Hi,

I´m trying to develop an external loader ("EL") for my custom combination of an STM32G070RB with an external Flash in single SPI connection (M95P32-I). I´m using:

- SMT32CubeIDE Version: 1.13.0
- STM32CubeProgrammer 2.13.0

My EL is being accepted by the CubeProgrammer. Full chip erase, sector erase and write resp. fill memory works fine. Only the read instruction delivers an Error: Data read failed.

Manual read operations with prompting the buffer on a UART is also working fine. There should be no issue in the general read function, as I just took it from the software expansion package "X-Cube-EEPRMA1":

Please find attached the relevant files...
Oh, I can only attach 3 files... No, I can only attach 2 files...
And I had to rename the linker script *.ld. -> *.txt.
--> I´ll attach the other files in separate messages.

May be somebody has a hint for me, what to change to make it work.

[KDJEM.1]

Hello @f.foertig and welcome to the Community 🙂,

Could you please check the memory settings such as page size, start address....

I recommend you when you configure your SPI external loader project to follow the steps shared in these FAQs:

• How to add your SPI flash into the STM32CubeProgra... - STMicroelectronics Community
• How to add your spi flash into the STM32CubeProgra... - STMicroelectronics Community

I hope this help you!

Kaouthar

[f.foertig]

Hello Kaouthar,

thank you for your reply. Of course I´ve double-checked that parameters like page size etc. several times. And I´ve read this article very often. 
Since today, it never worked with the original loader-file from the article. It only was accepted by CubeProgrammer with my own configuration, beside the fact, that reading the flash was not possible. 
And today,.. just for double-double-checking it again. I took aigain the loader-file from the article and for some reason it worked.
So thanks for your advice. 
-----
It´s just a little frustrating, when you take the same code on different days. One day it works the other day not. :\
That is, what I experienced a lot with ST-controllers and their development tools.

[Tesla DeLorean]

One of the issues with External Loaders is that they don't use interrupts or the vector table, so Reset_Handler, startup.c and main() are not executed. The loader is then responsible for initializing the statics, the values in the C code you assume to be zero, or preinitialized, might not be, resulting in somewhat unpredictable behaviour.

Further unpredictable behaviour can occur in QSPI type memories because they don't have an async-reset pin and can be walked into and left in modes which are not compatible with those used/wanted in first-contact methods.

With loaders, test all the code externally within an app or wrapper/ framework, so you can debug them. Use output to serial for debug/diagnostic information because you're not going to be able to debug/single-step in STM32 Cube Programmer, and the logging there give's the PC side perspective, whereas the loader needs to report it's STM32 side perspective on the peripheral state, and what it's being asked to do.