STM32H7 crashes when reading the last bytes from a memory-mapped QSPI

[Nico1]

I'm trying to use memory-mapped QSPI with STM32H743XI, but it always crashes when reading the last few bytes (something like 96 bytes before the end address, but not entirely consistent). It crashes without a fault and just disconnects the debugger and has to be reset/power on/off to work again. I tried many things, but I couldn't change anything. I'm aware of the errata "2.4.4 Memory-mapped read of last memory byte fails", but it happens A LOT sooner than the last byte and the behaviour doesn't seem to be consistent with the description there. Also there's no mention for this errata in the revision table and I don't know if my chip is affected or not.

Any help is appreciated :smiling_face_with_smiling_eyes:

[Tesla DeLorean]

It is something I've noted before. I think it was the last 32-bytes, and likely related to caching or prefetch.

You might want to check the MPU setting. Edit: No been there, tried that..

Add 1 to the Size field when the QSPI memory is initialized.

[Tesla DeLorean]

Had to use Google, the f***ing search implementation here is worst than useless..

https://community.st.com/s/question/0D50X0000BOvYcuSQF/h7-quadspi-weirdness

[ChahinezC]

Hello @Nico Lüthi,

You are right, the "2.4.4 Memory-mapped read of last memory byte fails" errata is missing in the Summary of device limitations. I will take care to report it internally to be added. 

Concerning the initially described issue, I believe that the behavior is the same as described in the errata ES0392 in the 2.4.4 section.

In fact, the debug crashing that you are observing is due to the AXI stall (which leads to CPU hang).

Then the workaround you applied is already provided:

If you think that it is not the same case mentioned in the errata, can you please provide details on how you were able to confirm that it crashes in the last 96 bytes or sooner? 

For example screenshots of the signals you based on them with minimum code to reproduce the issue will be welcomed.

Chahinez.

[Nico1]

I think I misunderstood what the "for example by taking margin in FSIZE bitfield setting" means and didn't think to increase FSIZE with that wording. I only did think about taking margin with my data access and not with FSIZE itself, but I'm not natively English-speaking so this might be my fault. Also did not expect to be able to change FSIZE without wreaking havoc, either on the chip or with invalid addresses to the flash device itself.

To your other point if I could prove how not only the last byte is affected: I was never able to get the the failing memory region down to one single byte, but I might not have tried hard enough. If I would control every single factor it might only be the last byte, but I never got below like 8 bytes or something. I think in a "normal" use-case its hardly only the last byte even though the errata might be technically correct. Also @Community member​ talks in his post about 32 bytes, so it really can be a huge range and quite confusing. Also never seen the 0x00 readout, but with caches, prefetching and debuggers running it's hardly a surprise.

Is a next silicon revision planned or will this limitation stay as it is until EOL? And has anybody any information if the FSIZE + 1 trick works with 256MB (0x90000000-0x9FFFFFFF) memory-mapped QSPI flash?

[ChahinezC]

Hi @Nico Lüthi​,

Concerning the 32 bytes; the QUADSPI supports a prefetch mechanism feature allowing to fill the FIFO (32bytes) during read operations in memory mapped mode as explained in the 23.3.7 section of RM0433.

It should work with 256MB flash memory since the Fsize can be configured up to 4Gb, while the memory mapped region is only up to 256Mbytes.

Chahinez.