Issue with QSPI External Flash Loader Verification Functionality for STM32H745

[APate.18]

I am writing to address a concern regarding the QSPI External Flash Loader that I have developed, which I have attached below for your reference.

The functionality of reading, writing, and erasing operations with the ".stldr" file in conjunction with other project files is working seamlessly. However, I am encountering an issue when attempting to verify the data during the loading/debugging process.

I would greatly appreciate your assistance in resolving this matter. If there are any insights or suggestions you could provide to help rectify this issue, it would be immensely helpful.

Thank you for your attention to this matter. I look forward to your prompt response.

 

[mtechmatt]

Hi tesla,

Further, if I load say 0x0F (or anything) using the CubeMX Prog, I can see it goes in (up to a certian point as I mentioned in myother post. If I then try and build and run from the the IDE, I get, as discussed, the error of verification failure, geting back 0.x00 instead of 0x0F, AND the SPI memory 9whcn checked witb the MXProg again s indeed now all wiped to 0x00.

Odd!

Any advice?

Thanks

Matt

[mtechmatt]

Heres an odd thing: Using the CubeMX loader, (You can see in the console what a sked to be written) It seems to stop at 0x90010000 depsite me asking to write:
15:33:15 : Time elapsed during the read operation is: 00:02:29.775
15:35:57 : Filling memory operation:
15:35:57 : Start address : 0x90000000
15:35:57 : Size(Bytes) : 0x01000000
15:35:57 : Data value : 0x0000000F
15:35:57 : Filling data size(Bytes): 8 bits
15:35:57 : Erasing external memory sectors [0 255]

Is there an issue here?

[mtechmatt]

[FA1234]

I have exactly this problem with an H7RS, and the programming is off by 1. If you were to shift all the data down by 1 byte, you would have a correct flash image.

I solved this by using the STM32CubeProgrammer from the command line and giving it an address of 0x90000001. It complains that the address is unaligned and it is "fixing it", but the result is a correct flashed image anyway.

This has got to be a bug in the programmer and not the external loader.

STM32_Programmer_CLI -c port=SWD -el <extmemloader> -d <binary-file> 0x90000001

In other words, if you flash at 0x90000000, you will get everything shifted by 1 byte. If you flash at 0x90000001, you will get the correct output *at* 0x90000000.

My current problem is getting the IDE to replicate this "quirk" when flashing the image so I can use the debugger.

[Tesla DeLorean]

>>This has got to be a bug in the programmer and not the external loader.

You could instrument the loader?

You could load it into RAM from your app, and call the entry points.

[FA1234]

The loader is the stock loader generated by the Cube in my case. If I program 0x90000000, it's off by 1, if I program 0x90000001, the programmer complains about unaligned, says it will align it for me, and then works perfectly.

I mean it's *possible* it's the loader's fault, but it seems unlikely given the programmer generates both good and bad results with ostensibly the same argument (since apparently unaligned isn't allowed).

[urbito]

Something similar has happen to me.

I have followed the series of videos from ST to build my own ExternalLoader for a STM37h755 and after a "successfully" generation, i found that the whole program was shifted by 1 and did add the "offset" directly in my EL, after adding the "offset" it have been working good until today; it have happen to me more than a year ago.

Greetings.

[Tesla DeLorean]

Yes, does sound odd, but not familiar with your hardware.

If I had to guess this revolves around a 3 or 4-byte addressing issue, and a mismatch between HW and SW settings.

[FA1234]

Can you share a quick patch of how you did this?

[FA1234]

So your thinking is that when it says unaligned addresses aren't allowed and it will align for me, it's actually performing an internal by-1 byte shift, rather than just masking off the lowest 2 bits?