MMC_SPI subsystem on STM32H743ZI

[donquichotte]

Dear all,

I am trying to use the MMC_SPI subsystem on an STM32H743ZI.

The application gets stuck in mmcConnect()/spiIgnore()/osalSuspendS(), just after spiIgnore(mmcp->config->spip, 16);

The call to osalSuspendS() just never returns. CS and the clock frequency behave as expected.

One weird thing is that in mmcConnect, there is the comment /* Slow clock mode and 128 clock pulses.*/, but I can only observe 64 pulses at the clock pin.

Does anyone have an idea what is happening here? The project is based on the ST_NUCLEO144_H743ZI demo.

[Giovanni]

hi,

You mean it is stuck into spiIgnore() ?

It should emit 128 pulses, strange. It is like the DMA fails for some reason and does not complete the operation, this could also explain why it is not exiting that function, it is the DMA interrupt to wake up the thread.

You may try placing breakpoints into SPI-DMA callbacks and see if those are actually called.

Giovanni

[donquichotte]

Thank you for your response.

It appears that the whole issue is a configuration problem, I forgot to set SPI_CFG1_DSIZE_VALUE(7) in the SPI driver config. Now the correct number of clock pulses are emitted, DMA works fine and spiIgnore() returns.

Now spiReceive() blocks sometimes, but I am sure this is also a configuration issue that can be solved by reading the STM32H7 Reference Manual.

Thanks!

[Giovanni]

Hi,

Perhaps what CPU sees and what DMA wrote in memory is not aligned.

Consider that H7 has cache, you need to place your buffers in un-cached RAM (using MPU you can declare non-cacheable regions) or doing buffers flushing/invalidation manually using the functions in the DMA driver.

Giovanni

[donquichotte]

Thanks Giovanni.

I figured out some more issues which I will put here in case someone runs into the same problem:

1) In order to initialize the SD card, one needs to generate the clock pulse train with NSS pulled high. Change to software slave-select management:
ChibiOS/os/hal/ports/STM32/LLD/SPIv3/hal_spi_lld.c:708 change SPI_CFG2_SOE to SPI_CFG2_SSM

2) Check the memory areas that the DMAMUX can access. See [1] for reference.

D-Cache is disabled and I am using AXI RAM now, but still no luck.

[1] https://community.st.com/s/question/0D5 ... m32h7-dcmi

[donquichotte]

The issue was that in spi_lld_serve_dma_rx_interrupt() in spi_lld.c, the SPI driver was suspended with spip->spi->CR1 |= SPI_CR1_CSUSP, but never unsuspended by setting SUSPC in IFCR.

Is that expected behaviour? I now never suspend SPI. The other way would be to wake SPI up at the start of spi_lld_ignore, spi_lld_exchange, spi_lld_send, spi_lld_receive.

[Giovanni]

The issue was that in spi_lld_serve_dma_rx_interrupt() in spi_lld.c, the SPI driver was suspended with spip->spi->CR1 |= SPI_CR1_CSUSP, but never unsuspended by setting SUSPC in IFCR.

I think there is no need to clear SUSPC, it is the interrupt flag and is not used, re-starting SPI is done using CSTART (which is cleared by SUSPC).

About the CR1 bits: SSM is the SS input which is used by SPI in slave mode, we are using master mode.

Are you controlling SS using spiSelect() and spiUnselect() (GPIO mode)?

Giovanni

[donquichotte]

> I think there is no need to clear SUSPC, it is the interrupt flag and is not used, re-starting SPI is done using CSTART (which is cleared by SUSPC).

[1], p2220 says "[CSTART] is cleared by hardware when End of Transfer (EOT) flag is set", does that not mean that we don't have to clear it in software?

p2228 (SUSP) seems to indicate that the SUSP bit can only be cleared with SUSPC, not automatically with CSTART.

NuttX sets CSTART [2] when using SPI with DMA, but does not suspend SPI. It only does so in polled mode.

> About the CR1 bits: SSM is the SS input which is used by SPI in slave mode, we are using master mode.

From Figure 616 in [1] it appears that SSM is affecting SPI both in slave and master mode. It seems to me that this switches between "hardware chip select" and "software chip select". What is super weird is that if I don't set SSI = 1, I never get to the rx dma callback, but SSI seems to be only related to slave mode. However, NuttX mentions a "MODF" error without these settings, which I was unable to reproduce. [3]

> Are you controlling SS using spiSelect() and spiUnselect() (GPIO mode)?

Yes, in hal_mmc_spi.c, spiSelect() and spiUnselect() are called. I am using SPI_SELECT_MODE_LINE, so this translates to palSetLine() and palClearLine().


[1] RM0433 Rev 6 https://www.st.com/content/ccc/resource ... 314099.pdf
[2] https://github.com/apache/incubator-nut ... pi.c#L1739
[3] https://github.com/apache/incubator-nut ... pi.c#L1982

[Giovanni]

[1], p2220 says "[CSTART] is cleared by hardware when End of Transfer (EOT) flag is set", does that not mean that we don't have to clear it in software?

It means that it is cleared in hardware if there is an EOT but the driver does not use TSIZE so the SPI is started and suspended in SW.

I need to understand what you are trying to address here, so lets separate MMC and SPI, what is the problem with SPI alone? others are using it.

Giovanni

[Giovanni]

Hi,

There is another report, lets continue the discussion here: viewtopic.php?f=25&t=5332

It is about SPIv3 not MMC_SPI.

Giovanni