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]

In  my particular case, in the "write" function on the "qspi.c" i "added" the offset to the "address" parameter/member requiered to by the function.

[Tesla DeLorean]

No

[FA1234]

Okay. Then if the programmer is just masking off the final 2 bits before writing to the device, I don't see how this can't be a bug in the programmer. I mean, if it were doing a by-1 shift, then maybe it's a start address issue in the QSPI flash, or an SFDP driver error or something. But, if just simply masking off the final 2 bits, then the resulting commands to the device would be identical.

Either way, it's telling it to start writing at 0x90000000 and the byte stream that it says to write should be identical.

I will do some more instrumenting. Thanks to urbito for the idea to make the change there too. More to come tomorrow...

[Tesla DeLorean]

No, I mean I think it's unrelated to alignment, but simply an off-by-one issue

Alignment in QSPI NOR FLASH terms is most typically 256-byte pages, how those buffer and write, and don't span.

You'll have to convince me something else is going on, with data

Suggest you set logging verboseness to 3 and observe what's being sent to the External Loader, or instrument the external loader so you can view it's perspective. These things are a pig to debug, and conjecture is a waste of time.

[FA1234]

It's much later, and I haven't fully diagnosed the issue (I'm still using the off by 1 to program), but there were several issues here in the stm32_sfdp_driver.c (and related functions) and how it interacts with a Winbond W25Q16 or W25Q32.

If you are using this part, beware you're probably running it in 1 lane, single data rate, at a speed less than 50MHz (possibly much less, depending on your clock setup), no matter how you've configured it.

There are many interaction issues with this part and the driver. These can all be fixed with driver changes. The part actually seems really powerful, but the STM driver does not know how to access these features.

I now have this part running at 4S4D4D (4 lanes, double data rate for all but command) and 64MHz, and probably could get it higher, but it's just not worth the return at this point for me.

Some issues to look at if you have this issue or use this part:

1) dummyCycles info in JEDEC is incorrect for this part. See stm32_sfdp_data.c:1640. If you try to use CONFIG_4LINES, it will set dummyCycles to 

JEDEC_Basic.Params.Param_DWORD.D7._4S4S4S_DummyClock + JEDEC_Basic.Params.Param_DWORD.D7._4S4S4S_ModeClock;

Unfortunately, winbond reports 4S4S4S_DummyClock as 0 (which is true if you use QPI mode, but we're not using that). It should be 2.

2) Complicating the matter further is that CONFIG_4LINES always fails because the specific method to enable 4S4S4S mode is not supported by the driver, which causes an error, and the entire driver to give up. See 

JEDEC_Basic_Manage4S4S4SEnableSequence()

 for more info. Fortunately, this Winbond part is always in 4S4S4S mode, so you don't need to enable it, but you'll need to work around that function returning an error.

3) The driver will force the speed to the next even integer divider clock speed below 50MHz and never set it back to whatever you set it to. So, you'll need to manually reset your clock rate (and make sure to calibrate the XSPI interface, which is a challenge if you're running XIP).

4) At around line 1603, it sets dummyCycles = 0 for 1S1S1S default mode. This should be 8.

5) Winbond reports a JEDEC 4-byte addressing header which causes the driver to completely fail in both recognizing basic SPI configuration as well as the 4-byte mode. I worked around this by masking out the 4-byte addressing header before calling the BuildGenericDriver() function.

6) If you use 4S4D4D mode, there are no JEDEC values reported, so you'll need to find them yourself. The correct answer for dummyCycles is 9.

I hope that helps someone.