STM32H750IB getting into persistent problem with SCB_EnableDCache

[TallMike]

Hi, We've been using a board (the Daisy Seed) that has an STM32H750IB and external QSPI flash chip.

We're having an issue with some of the boards somehow getting into a persistent (across reset. power cycle, and chip erase) state whereby the SCB_EnableDCache function is taking several seconds to execute.  Even stranger, when DCaching is disabled, then the QSPI init call takes several seconds.   Most of the boards are working fine, but somehow something happens and the board/chip will start doing this.  In one case, it just as randomly stopped doing it. 

    Could some kind of un-initialized variable be causing this?

     Also, we're using an older version of CMSIS code (Ver 5.0.1), has anything been fixed or changed in the newer versions?

[Tesla DeLorean]

Needs to cover the 0x90000000 region/behaviour. ST has a white paper / app note on this.

https://community.st.com/t5/stm32-mcus-products/stm32h750-mpu-xip/td-p/155859

https://www.st.com/resource/en/application_note/an4838-introduction-to-memory-protection-unit-management-on-stm32-mcus-stmicroelectronics.pdf

https://www.st.com/resource/en/application_note/an4760-quadspi-interface-on-stm32-microcontrollers-and-microprocessors--stmicroelectronics.pdf

https://www.st.com/resource/en/application_note/dm00287603-lcdtft-display-controller-ltdc-on-stm32-mcus-stmicroelectronics.pdf

[Tesla DeLorean]

My primary concern would be with the VCAP capacitors, either one 4u7 or a pair or 2u2

Inadequate, low ESR, capacitance here is the source of a lot of quirky behaviour

[TallMike]

Here's a picture.

[TallMike]

Looks like it's 2 of the 2.2 uF caps, one on each VCAP pin.  Don't have the part number, however.

[TallMike]

The QSPI is not being used in Memory-mapped / XIP mode, just as external storage, so do we still need to set up the 0x90000000 region?

[TallMike]

Update: Interesting and unsettling new data point:
I plugged and unplugged the Daisy Seed board (stand-alone, using the on-board USB port) about 20 times, and it suddenly started behaving again!

[AScha.3]

What you think...?  🙂

[TallMike]

Looks like a 'V'

But still having this super weird seemingly impossible unexplainable inexplicable situation!

Any ideas?

How is it even possible?

[TallMike]

Hi, just wanted to follow up and see if there's any progress on figuring this out?  It's got us quite worried about shipping a board until this is resolved.

[Tesla DeLorean]

I don't think anyone here has advanced your issue, you should perhaps escalate with Electro-Smith, or your local ST Micro FAE if you're working with them. Did you get a better schematic from them?

You could open your own support ticket via the online support system https://ols.st.com/s/

Can't say I've seen any other Daisy Board users here.

Odd behaviour tends to be power related, or with Internal Flash timing. If clocks don't start things can be relatively slow. The H7 starts on a 64MHz HSI, you can continue to use that without doing anything, and output via a serial port to understand internal state and progress.

Should see 1.25 V on the + side of the VCAP's, you could perhaps look at supply stability there, and the 3.3V rails.