STM32 H757 QSPI read not working properly.

[vro.1]

Board: STM32 H757

Issue: We are using internal QSPI memory. Write is working fine. But reading have issue.

reading ignores first byte and also do swapping of 2 byte.

For example:

--> write 0<offset> 4<number of byte> 1 2 3 4<values to write>

--> read 0<offset> 4<number of bytes to read>

output ==> 03 02 FF 04

What can be reason here?

[Andreas Bolsch]

How can you possibly know that writing is working fine? Maybe the problem already appears during the write and not (only) during the read?

Typical problems: wrong number of address bytes (24 or 32-bit addresses), wrong number of dummy cycles (if you're using 4-line modes).

[Tesla DeLorean]

The QSPI memory is not internal. The STM32H757 is a chip, not a board.

The issue could be with the hardware, either pin choices or wiring.

It could be an issue with the software, either with the configuration of the interface, or the support of the various QSPI NOR Flash IC.

It takes quite a lot of work to get every correct and tested.

[vro.1]

We have written two application:

App#1) Use QSPI memory mapped(external to internal) (Using stm32 loader usage)

App#2) No QSPI memory mapped (no external to internal mapping)

Write is working fine as we tested like this:

======

1) write some value using App#1.

2) read value using App#1--> wrong here.

3) do hard reset --> power off and on

4) read value using App#2. --> proper value... Note: --> If we use App#1 to read then wrong are not proper.

So something is wrong with QSPI memory mapping.

Do you have any idea for what is wrong here?

[Andreas Bolsch]

I'm still not convinced that you can rely on data being written properly.

Whether memory mapped or indirect read mode is used, the actual data transfer works in exactly the same way from the flash's perspective.

But: If we suppose the external loader working properly, the power off might be the clue, as the flash chip then "forgets" its settings, in particular the address size and dummy cycles. So again, make sure that those settings are consistent. Not only in your firmware, but in your flash chip, too.

What's the size of your external flash chip? At most 16 MBytes or larger? Is your external loader tailored to that size?

[vro.1]

I have also check written data from STM32 ST-Link utility software and it is properly written.

We are using STM32 H757 EVAL kit itself. QSPI is (MT25QL512ABB8ESF-0SIT or MT25TL01GHBB8ESF-0SIT) as per sheet.

External loader in STM32 IDE = MT25TL01G_STM32H747I-EVAL, 0x90000000, NOR_FLASH, MT25TL01G_STM32H747I-EVAL.stldr

[Andreas Bolsch]

Ah, so that's dual quad configuration, each chip with 64 MBytes, hence 4-byte addressing. The loader is the one supplied by ST, so we may assume it does configure the flash chips properly to 4-byte addressing. So I'd suggest you verify that both applications

1) set QSPI interface to 4-byte addressing

and

2) configure the flash to use 4-byte addressing

Whether the latter succeeds can be checked via READ FLAG STATUS REGISTER command, bit 0 must be set.

If this doesn't pinpoint the problem, the next possibility would be to check that the configured number of dummy clocks for the QSPI interface in both applications match that of the flash chip (can be checked via READ VOLATILE CONFIGURATION command).

[vro.1]

I have following queries:

1) How to open stldr file and know setting in it? Is it possible to change setting and recompile as well?

2) Prebuilt STM32 IDE installed does not contain stldr file for STM32h757I-EVAL with MT25TL01G. Any idea from where to get it ?

Rakesh

[Andreas Bolsch]

ad 1) Most external loaders supplied by ST apparently come as compiled binary only, but there are some exceptions, see the files coming with STM32CubeProgrammer. So, you can't know the settings except by attaching a logic analyzer to the flash ... Or you can read the flash settings after the loader has completed.

ad 2) Well, if it is not supplied by ST in one of the usual places, I'm afraid you have to write your own. Take e.g. STM32CubeProgrammer/bin/ExternalLoader/N25Q256A_STM32L476G-EVAL/Sources/Loader_Files/Loader_Src.c and modify to suit your setup. That's not particulary difficult but requires good familiarity with the QSPI interface and your flash's datasheet. Furthermore debugging an external loader is slightly complicated.

ST has some material https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/external_QSPI_loader.html

AN4760. Moreover this is a recurring topic in this forum.

If you want to use OpenOCD instead of STM32CubeProgrammer: The current STM32CubeIDE includes a customized version of OpenOCD including this patch http://openocd.zylin.com/#/c/4321/. It also contains the proper config file for the H7-eval boards:

stm32cubeide_1.5.0/plugins/com.st.stm32cube.ide.mcu.debug.openocd_1.5.0.202011091203/resources/openocd/st_scripts/target/stm32h7x.cfg

The settings are visible there and can be modified easily, but again, this requires some familiarity with the QSPI stuff, but no recompilation. The relevant part is 'qspi_init'. I've tested that patch with a H747-Disco board with rather similar memory cofiguration, but not with a H7-eval board.

[Tesla DeLorean]

>>Any idea from where to get it ?

Try the FAE assigned to your account, the forum is not the means that most ST engineers use to communicate with customers.

If the BSP is not working in certain situations you'll need to debug the registers in the working vs non-working situations, looking at the clock and bus configurations. If you don't have the skills/resources in-house, you'll need to contract that out.