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.

 

[urbito]

For the STM32H745 discovery board you have one, if you have made your own board and have change any pin assigment related the QSPI, it wont work and you have to build your own.

Regarding your ask to me, i did it manually, i did open the .bin/.hex file and saw for example its content, and then i saw it started for example as 0A BB FA and so on...

then i went to the cubeprogrammer, under memroy and file editing, and place the start address from QSPI and saw that the data had 1 byte offset, what i saw was 00 0A BB FA instead of 0A BB FA ... This worked for me, in particular to find my offset issue, not saying it would work for you, but maybe it can help you to aim in the direction you would need :)

Greetings

[APate.18]

May i know are you talking about which hex.bin files 

Right now i am getting this value on external address.

[urbito]

May i ask if you could use to write/read the code you have use with this Loader?

If you follow the STM32 video guide, or by your own, when you write the code for an external loader, one think you may do is to test that with the code before generating the EL you can write and read it back. I am asking you this because my guess is, the write operations is happening but not as intended. Thats my guess since your data, for me, has no sence, but maybe i am wrong and it does make sence for you.

Greetings

[APate.18]

Hi i have Debug My code with Testing code of  in that i am getting right data but while i have loaded with CubeProgrammer i am getting following debug log and getting verification failed

my loader file memory defination is 

/* Memories definition */
MEMORY
{
RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K
/* Occupies both core's memory banks minus the bootloader and app header size.
Must remain in sync with bootloader_def.h, APPLICATION_PRIMARY_MAX_SIZE__BYTES.
Matched with the Release app just to enforce an expectation on the overall app
size.
*/
FLASH (rx) : ORIGIN = 0x08040400, LENGTH = 1791K
DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
QUADSPI (r) : ORIGIN = 0x90000000, LENGTH = 64M
}

===========Debug Logs==================

18:20:58:158 : Verifying ...
18:20:58:158 : Read progress:
18:20:58:159 : Reading data...
18:21:04:271 : r ap 0 @0x08000000 0x000D9540 bytes Data 0x24080000
18:21:04:274 : Reading data...

////.....

.....////

18:21:07:924 : r ap 0 @0x90000000 0x00064E00 bytes Data 0x99999999
18:21:10:732 : r ap 0 @0x90064E00 0x00064E00 bytes Data 0x00000000
18:21:13:546 : r ap 0 @0x900C9C00 0x00064E00 bytes Data 0x00000000
18:21:16:354 : r ap 0 @0x9012EA00 0x00064E00 bytes Data 0x00000000
18:21:19:137 : r ap 0 @0x90193800 0x00064E00 bytes Data 0x00000000
18:21:21:945 : r ap 0 @0x901F8600 0x00064E00 bytes Data 0x00000000
18:21:24:748 : r ap 0 @0x9025D400 0x00064E00 bytes Data 0x00000000
18:21:27:535 : r ap 0 @0x902C2200 0x00064E00 bytes Data 0x00000000
18:21:30:340 : r ap 0 @0x90327000 0x00064E00 bytes Data 0x00000000
18:21:33:145 : r ap 0 @0x9038BE00 0x00064E00 bytes Data 0x00000000
18:21:35:945 : r ap 0 @0x903F0C00 0x00064E00 bytes Data 0x00000000

Please help me on urgent basis its require.

1) Is this problem is related to  hardware

2) Is this problem related to linker file 

3) Is this problem related to any logical or method error

Or can you provide any .stldr file for winboard25Q512JV extrenal flash QSPI 

[Tesla DeLorean]

The memory basis for H7 External Loaders is 0x24000004

https://github.com/cturvey/stm32extldr/blob/main/ExternalLoader.ld

Posted a bunch of loaders for H7 W25Q512 and others, check if your pin selection is already supported

https://github.com/cturvey/stm32extldr/tree/main/h7_w25q512

Urgent custom work can be done at premium rates..

[APate.18]

It appears that you've attempted to use various files from the GitHub repository you mentioned (https://github.com/cturvey/stm32extldr/tree/main/h7_w25q512), but i consistently encounter an "Erase failed" error. Upon examining the configurations available, it seems none matches your specific setup for QSPI.

Your QSPI configuration is as follows:

• IO3 ----> PF6
• IO2 ----> PF7
• IO1 ----> PF9
• IO0 ----> PF8
• QSPI CLK ----> PF6
• QSPI NCS ----> PF6

Although i found a configuration (h7_w25q256) similar to mine, i encountered the same "Flash Erase failed" error.

One notable observation is that the file sizes of the configurations are considerably smaller compared to my generated .stldr file.

This suggests that there might not be an appropriate configuration available for your specific setup. 

[Tesla DeLorean]

PF6 can't be used for 3 functions.

They are smaller because there's less clutter in them. There's no reason a loader should take several hundred KB of RAM, and it impedes efficiency also.

For non erasure, check status bits for BP Block Protection and that READID returns Winbond details.

[APate.18]

Certainly, I've noticed an interesting phenomenon while programming a device using STMCubeProgrammer for verification purposes.

Here's a step-by-step breakdown of the process:

1. Begin by downloading two different .stldr files.

2) Duplicate one of the .stldr files and attempt to read data from it. However, when selecting the address as 0x90000000, an error occurs.

3) Revert to the original file, reconnect the device, and successfully read data from address 0x90000000.

5.Reconnect the device again and initiate programming with the verification option checked, which is successful.

6.Subsequently, without making any changes or selections, attempt to program and verify again, and surprisingly, it verifies successfully without repeating steps 1 and 2.

Note: Initially, it's necessary to perform steps 1 and 2. However, after that, the verification process succeeds without needing to repeat those steps.

[mtechmatt]

H Tesla,

Just to ask this for confirmation:

I am using an STM32H743 and my linker looks like this:

MEMORY

{

FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 2048K

DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K

RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K

RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K

RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K

ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K

QUADSPI (r) : ORIGIN = 0x90000000, LENGTH = 32M

}

I can download to ths memory usng your driver (correct for my pns) usng the STCube downoader (set to 0x9000000 but t doesent work in the IDE (agan using your loader)

I get :

Error: Data mismatch found at address 0x90000000 (byte = 0x00 instead of 0x0F)

Error: Download verification failed

Is this ebcuase the address needs to be as you said 0x24xxxxx?

Thanks,

Matt

[Tesla DeLorean]

No, the 0x24000004 is the RAM address used by the External Loaders, STM32 Cube Programmer loads them like a DLL and calls the entry points to Initialize, Erase, Write, etc.

https://github.com/cturvey/stm32extldr/blob/main/ExternalLoader.ld#L21

The 0x90000000 is the Basis for the QSPI memory, and used by the Application's Linker Script.

STM32 Cube Programmer should be able to write and verify the content of a .ELF being written to Internal and/or External memory.

The wrong values being a situation where there's a bug in the software, hardware, or you're overwriting content (bits get knocked down to 0x00 via repetitive writes of different patterns)

Seen several people how issue with Winbond devices getting locked down via BP/COM bits in SR1 and SR2. In older devices SR1+SR2 had to be written as a pair. Protection can preclude some sector Erase, and Write, and all Mass Erase, which basically completes immediately, and is unsuccessful.