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.

[Tesla DeLorean]

Still, make this LESS aggressive

 /*##-2- Configure peripheral GPIO ##########################################*/

 /* QSPI CS GPIO pin configuration */

 GPIO_InitStruct.Pin    = QSPI_CS_PIN;

 GPIO_InitStruct.Mode   = GPIO_MODE_AF_PP;

 GPIO_InitStruct.Pull   = GPIO_PULLUP;

 GPIO_InitStruct.Speed   = GPIO_SPEED_FREQ_VERY_HIGH;

 GPIO_InitStruct.Alternate = GPIO_AF10_QUADSPI;

 HAL_GPIO_Init(QSPI_CS_GPIO_PORT, &GPIO_InitStruct);

[Peaga]

Hello Clive!

Yes, "Speed" for CS on my code was set only to "HIGH". Now each Flash pin is set to "LOW", no difference. Anyway, even at 45 MHz, all QSPI commands are working fine. Using Memory Mapped, I can "debug" the first 32 bytes burned on Winbond, same as bin file. I'm really starting to think it's a "Y" issue...

[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