H750 vs H743 for QuadSPI Boot

[Peaga]

Hello guys!

I'm working on a custom board with STM32H750VB and a Winbond QuadSPI flash. The ideia is boot the code from QSPI as H750 program memory is a little low. I'm also working with STM32H743VI on a twin custom board, so I can create and debug the code on this board before porting it to H750 and the external flash (as I can't debug on it). I'm using both TrueStudio and CubeMX as starting point, and the boards are running at 400 MHz using internal clock (no crystal).

The problem is, the code is working fine for H743 and not for H750. I've created a simple "blink led", loaded to QSPI from a USB stick (so internal flash acts like a bootloader) and the program runs ok. The same code for H750 jumps to application and fails, nothing happens. Another issue, on H743 I can run the QSPI at 100 MHz (setting prescaler) but on H750 I can't go over 45 MHz!

I've checked the burned code on Winbond and it's fine, so I don't know what is happening. The only difference between the STM32 is revision: "X" for H743 and "Y" for H750. There's an errata for QuadSPI, about writing routines and dummy clocks. Applying the working around for Memory Mapped routine, didn't work.

Do you have any clue about this case?

Thanks a lot!

[Tesla DeLorean]

If you have short connections to the QSPI, try backing off the slew rate of the pins (SPEEDR). Signal integrity in the design will become more critical the faster you clock it. Try to ensure the traces are of equivalent length and don't have stubs.

Debugging should be possible. I would try to avoid relying on single-stepping to understand how your own code behaves. Instrument the code, and provide for a debug console/monitor.

On the F750-DISCO the demo code is 188KB in size,

[Peaga]

Hi Clive, thanks!

I don't get your point about signals... They are two identical boards, only microcontrollers are differents. For H750 I can't even reach half speed as H743!

About debugging, Winbond is XiP capable but I didn't find a clearly AN from ST to work that way using QSPI, maybe I'm wrong, but it's something for Keil or IAR systems.

I'll take a look at F750 demos.

Thanks!

[Tesla DeLorean]

Perhaps something was addressed in the X stepping, the Y is the older of the two.

I would see if I could observed ringing in the signals. Do you have the ability to add series resistors in the lines?

You could also wire the QSPI device to a NUCLEO-H743ZI, most of those I've seen have the Y stepping.

[Peaga]

Well, I had to pause this project and only now I was able to continue it... Both H743 and H750 are working with QuadSPI Flash (it was an error in H750 main application) and both custom board were revised (added small series resistors in data lines). But now, I can't go over 60 MHz. Even with old H743 board, the 100 MHz works only for a while, freezing the main application after some time.

Do you guys have any other tip?

[Tesla DeLorean]

Is it faulting or locking up on the bus?

What is the part# for the Winbond device?

Is it something you can exercise/validate outside of your primary application?

Is the failure something you can constrain on a logic analyzer?

[Peaga]

Hello Clive

It's a W25Q32FV from Winbond. After a reset command, a 0x9F command is sent (read JEDEC ID) in SPI Mode using "HAL_QSPI_Command". At 100 MHz, the "HAL_QSPI_Receive" method fails by timeout (5000 ms). I'm trying to find a scope that can measure high frequencies, but as the memory is really close to STM32, I'm quite sure the clock is fine...

[T J]

I would try :

inspect / thicken up the ground pin & Vcc pin to the W25, add extra capacitance, 1uF and 0.1uF as a minimum

desperation:

pull up the MISO line with 4k7 and maybe the MOSI too

[Peaga]

Hello again

Well, my journey with external flash in H750 has another bad chapter... Even with QSPI at 60 MHz, a simple app (using SPI, USART, I2C, GPIOs) works fine. But after adding new peripherals like SDMMC and Ethernet, things become odd. Most of the time the SD Card isn't initialized correctly and parts of the code where I must use HAL_Delay and DWT_Delay (microseconds) lose precision. Exactly the same code on internal flash woks flawless. In theory, running the code on external flash makes the total score goes down, but I've read on AN that it should be improved by M7 cache system.

Am I missing something?

[Tesla DeLorean]

Well the cache is of finite size, typically people model the behaviour and create a tighter working set, and balancing the critical stuff into the fastest/closest tiers of the memory subsystem.

Move code into RAM. Check how much FLASH is actually on-die.

The H745/H750 DISCO has double wide QSPI pair of MT25QL512ABB8ESF-0SIT, might experiment if I find time, unfortunately no one is interested in paying for support.

[Peaga]

Hello Clive, thanks!

I understand your point and I totally agree with you. You help the community a lot, but I still miss the ST team here, especially as H7 is somewhat "new". I just saw on Cube FW 1.4.0 the new H750 DK demos and for external memory using MT25Q, they set the QSPI clock to 50 MHz. So based on that, my first problem "was solved": it is not guaranteed that H7 can work at full speed.

About your tip to move the code to RAM, I don't have much space... RAM_D1 is used for TFT LCD (STemWin buffer) and RAM_D2 for lwIP. DTCMRAM for heap and stack (USB also in use)...