STM32H750VB Quad-SPI questions

[Yevpator]

Hello,

Due to so attractive price + some specific features, the H7 Value Line looks to me very attractive to take into a new design, but 128kB Flash is not enough for me, I have to take an external flash, which is QSPI. I have a few basic questions about that.

1. I am almost sure that Quad-SPI works with the Value line H7 as well​, but since I saw in some doc that an H7 Discovery works with Dual SPI only, I have some hesitation. Can one here confirm that?

2. If work through Quad-SPI (QSPI Memory Mapped), how the performance will be reduced vs a normal mode @ 400MHz?

3. Does this Quad-SPI make debugging more complicated? What issues did you face , especially with Atollic?

4. Does ST-Link support H7 programming with Quad-SPI enabled?

5. What are other issues with H7 + Quad SPI, you would recommend me ​to take in account ?

​

T​hanks!​

[Andreas Bolsch]

From Table 7 you will deduce that all 2x4 data lines, both chip selects and clock are available even in LQFP100, so it's possible to use two paralleled spi flash devices in QPI mode. For DTR chips this will give 1 byte per clock edge, so this could be pretty fast.

However, using all 11 pins for flash might severly impact availability of other peripherals, so you have to check that for your application there is no conflict.

The performance penalty is impossible to predict. For pure sequential access, you can calculate the throughput as above. But if you need big data areas with random access: each single byte read requires one byte instruction, 3 or 4 address bytes, some dummy cycles, and the actual read, so ...

When the flash is memory mapped, it looks more or less like internal memory, so debugging is not affected except for soft breakpoints, as the actual instruction is temporarily replaced by a breakpoint instruction. I don't know whether any debugger is aware of external flash and could handle this. But single-stepping, hardware breakpoints are no problem.

For ST-Link and STM32CubeProgrammer (and probably anything else): As the pin mapping is variable and the various flash chips differ in some details and do support different modes (one-line, two-line, ...), you can't expect those to work "out-of-the-box" with the external flash. You will have to provide your own board/chip specific external loader, there are already a lot of postings here regarding this. Or you could use openOCD with either this

http://openocd.zylin.com/#/c/4321/

patch or that one

http://openocd.zylin.com/#/c/4760/

Regarding program/read speed: This depends heavily on JTAG/SWD clock. But as long as your code doesn't exceed 1 or 2 MBytes in size, that's no real issue. But mass erase gets a bit slow ...

For the H7, L4+ and MP1 there is a hardware issue (probably exactly the same for all of these three families): Avoid accessing the last few bytes in memory mapped mode, or set the FSIZE field to a higher value than the actual capacity: The last byte is incorrectly read as 0x00, and too persistent accesses to the last few bytes via debugger causes the debug interface to go berserk. For me (Nucleo with STLink) the only cure was power-cycling the board.

[MikeDB]

Whilst the H750 doesn't have much (official) Flash, it does have a lot of RAM so an alternative may be to use a slow external SPI flash and actually run the program from RAM.

Probably best thing is to develop on a H743 board first and migrate to the H750 once you have proven it is viable for the job.

[Yevpator]

Thank you very much for your valuable answer!​

[Andreas Bolsch]

Ah, forgot to mention AN5188, this contains some figures about internal vs. external code execution. But as the exact setup is not specified and there are too many variables, they're not that helpful. So anything between almost no impact and significant impact is possible.

[Yevpator]

Thank you so much for the prompt, detailed and valuable answer. Didn't get everything you wrote, but will give yet another chance to understand by myself before reasking ​.

​

Best regards.​