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?

[TallMike]

Hi, and thank you for your thoughts.

I'm attaching a better schematic.  

Also, just to clarify the behavior, it doesn't seem to be a per-power-up probabilistic situation.  Rather, it is acting like it has 2 different 'states' that it is somehow 'remembering', across power cycles (as long as 12 hours or as short as 1 second).  When it's in the 'good' state, it will repeatedly (over 200 times in a row) start up properly.  Then at some point (apparently during power-up), it will transition into the 'bad' state, where some part of the startup code (apparently the  SCB_EnableDCache fn, though if that is bypassed, then it instead seems to take a long time initializing the QSPI flash).  It will then stay in the 'bad' state for approximately 5 to 30 power cycles in a row (hence my thinking that unlikely to be an independent per-power-on situation).

There's been at least two other Daisy Seed users who have run into this.  Electro-Smith has not been at all responsive about this.

I'll submit a case with ST as well, thanks for that link.

[Tesla DeLorean]

Nothing in the schematic is jumping out immediately.

Can you cite these other cases?

Power and clocking tend to be the biggest contributors, the M7 Core should be good to over 600 MHz. I don't think the core has egregious issues that present this way.

You need to watch the VOS and PLL settings, so those are speed appropriate.

The H7 is an odd bird, the power cycling and reset behave differently, watch especially LDO / SMPS settings, as this is something retained in a non-volatile manner.

Check the clocks are starting consistently. Have code to output internal clocks via MCO, and print out what the core thinks it's doing, so you can establish what's happening and different between working and acting up situations, and better document that.

Code running from internal FLASH? Code running from QSPI?

QSPI typically has non-volatile register, so be wary of how that's being configured and operated.

[TallMike]

A few responses:

For doing the testing, we were doing a full power cycle (unplugging the USB cable), both quickly and with several seconds between, and sometimes several hours or overnight.

The code is being run directly from the Internal FLASH.

Here's a an example from the Daisy forum:

https://forum.electro-smith.com/t/seed-bootloader-dfu-util/3743/5

Look for 'vdgno's post.  I later directly messaged them and they said that they were able to get it working again after many power cycles.

[TallMike]

Just to follow up: It appears that the EnableDCache was a Red Herring and the real issue appears to be with the QSPI flash sometimes randomly getting set to Write Protect mode due to some tweaky startup/GPIO timing.