STM32H7 reading QUADSPI->DR freezes the MCU after QUADSPI->CCR = QUADSPI_CCR_FMODE_0 | QUADSPI_CCR_IMODE_0;

[berendi]

Executing this code sequence on a STM32H743ZI or STM32H743II

RCC->AHB3ENR |= RCC_AHB3ENR_QSPIEN;
	QUADSPI->CR = QUADSPI_CR_EN;
	QUADSPI->CCR = QUADSPI_CCR_FMODE_0 | QUADSPI_CCR_IMODE_0;
	QUADSPI->DR;

i.e. indirect read with only an instruction phase, then reading the data register freezes the MCU, i.e. no further instructions are apparently executed.

Debugger connection is lost, tries to reconnect a couple of times then gives up. I was able to reconnect the debugger only with Connect under reset enabled.

Watching the QSPI registers in the debugger has the same effect even when the DR register is not directly read by the code.

Workaround: avoid this sequence, use indirect write mode instead to send SPI commands with no parameters.

UPDATE

I have read the reference manual (better late than never) and found this:

When DMODE = 00, the data phase is skipped, and the command sequence finishes immediately by raising nCS. This configuration must only be used in only indirect write mode.

... and I was using DMODE = 00 in indirect read.

[Andreas Bolsch]

That's indeed unpleasant but works as expected/specified in RM: In indirect read mode any read access to FIFO stalls as long as there is not enough data available in the FIFO *and* BUSY is set . Hence no need to check FLEVEL, FTF or TCF before reading DR. But with no data phase there won't ever be enough data.

However, the interesting point is: After command completion BUSY should be cleared automatically, hence the bus stall should not last indefinitely? If it does, this would be a serious problem.

Regarding the debugger: It might be that it simply times out before BUSY returns to 0. You're using an ST-Link with OpenOCD? It's not usual that after a timeout the debugger can't regain control and only a target reset can resolve this. In fact, I observed this after a bus stall with OCTOSPI.

[berendi]

The problem is that BUSY is apparently never cleared, at least not whithin a minute. It can be aborted though.

It would be interesting to see what CS and CLK do.

[Andreas Bolsch]

Wow, that's bad news. The command must have been completed in a few us.

I remember vaguely that something like this was mentioned in one errata sheet, however, I don't remember the precise situation, the device affected and whether it was for the QSPI or OCTOSPI.

[berendi]

Yes, there is something similar there, but not the same.

2.6.3 QUADSPI cannot be used in Indirect read mode when only data phase is activated

Description

When the QUADSPI is configured in Indirect read with only the data phase activated (in Single, Dual, Quad or Dual-quad I/O mode), the QUADSPI peripheral hangs and the BUSY flag remains of the QUADSPI_SR register remains high. An abort must be performed to reset the BUSY flag and exit from the hanging state.

Workaround

Insert a dummy phase with at least two dummy cycles.

I've tried inserting up to 31 dummy cycles, but it still hangs when there is no data phase.

[waclawek.jan]

> The problem is that BUSY is apparently never cleared, at least not whithin a minute.

> It can be aborted though.

How? I was under the impression that the processor stalls...?

Don't have 'H7, do you think this can be reproduced on 'L476?

JW

[berendi]

If you read DR, it stalls.

If you don't read DR, you can observe that BUSY is never cleared, and you can set QUADSPI_CR_ABORT.

[waclawek.jan]

Ah, so. Thanks for the explanation.

JW

[berendi]

It does not occur on L476 or F746.

[Andreas Bolsch]

Just checked on Nucleo-H743ZI2: If DLR is cleared, BUSY bit sticks at 1, *no* other flag set. If DLR if set to 0xFFFFFFFF (the idea was that maybe BUSY is only cleared when transfer counter reaches 'nothing left' state) before writing to CCR, BUSY still remains set, but now TCF is set.

So, clearly, the BUSY reset logic has a flaw.