SPI STM32H7 (SPIV3) and lld-v1

[__Max__]

Dear all,

I'm looking for some information about SPI driver on STM32H723 board (so SPIV3). For historical reason, my project work well on a STM32G474 (SPIV2) and hal_spi_lld version 1. I moved my project on an STM32H725 (so using SPIV3 and lld-v1) board but the code stopped at the first use of SPI driver. I use the same SPI configuration as on the G474, so I expect that the problem should not come from the configuration of the ChibiOS driver.

As anyone ever tried to use STM32H7 peripheral (SPIV3) with hal_spi_ll version 1?
Do you think that SPI peripherals on STM32H725 and STM32G474 are diferent enough to break compatibility between the boards using lld v1 ? Or in others words, could the lld_v1 not be compatible with STM32H7 SPI driver (SPIV3)?

Thanks you!
Max

[Giovanni]

Hi,

Which version are you using? I am a bit confused, in latest version H7 uses SPIv3/driver_v2.mk, so it is using the latest SPI driver (v2), is this the case in your setup?

Note that the new SPI driver has extra fields in the configuration structure, if you use the same initialization done for the old SPI driver then positions do not match. Make sure to initialize the SPI configuration structure by field name not by field position. Except for the configuration structure the driver should work exactly the same.

You should be able to revert H7 to the old SPI (v1) but you need to change the inclusion in STM32H7xx/platform.mk and change "HAL_LLD_SELECT_SPI_V2" to FALSE in STM32H7xx/hal_lld.h.

Giovanni

[__Max__]

Hello,

Yes, you are right. By defult H7 use SPIv3/driver_v2. But our project start some years ago on an STM32F4. On that board (for historical reasons that I do not remember) we use SPIv1/driver_v1. Then we move on a STM32G4; SPIv2/driver_v1 wich is works well without modifying anyting compare to the F4. And now on an STM32H7, I would like to use the same logic : SPIV3/driver_v1 for compatibility.

Note that the new SPI driver has extra fields in the configuration structure, if you use the same initialization done for the old SPI driver then positions do not match. Make sure to initialize the SPI configuration structure by field name not by field position.

The first time I tried to compile my project for H7, the compilation failed due to these diferencies in the configuration fields. So I have force driver_v1 in STM32H7xx/platform.mk and disable "HAL_LLD_SELECT_SPI_V2".

Except for the configuration structure the driver should work exactly the same.

So I understand from this, that SPIv3 on an STM32H7 should work well because I use exactly the same configuration than F4 and G4 (because my configuration of driver_v1 on these boards (F4 and G4) works well).

You should be able to revert H7 to the old SPI (v1) but you need to change the inclusion in STM32H7xx/platform.mk and change "HAL_LLD_SELECT_SPI_V2" to FALSE in STM32H7xx/hal_lld.h.

Yes, this is what we have done on F4 and G4, and everythings works well. Thats why I try to do the same thing on the H7, and it compile well. But the code crashes at runtime. By "crashes", I mean that code stop in chSysHalt function with reason "DMA Failure". I investigate this message in the mean time.

Max.

[Giovanni]

Hi,

DMA failure means that the DMA is hitting an invalid memory or peripheral location, it could be caused by passing invalid pointers to SPI functions.

Using the H7 is harder because you need to consider the various domains and effects of memory cache.

Giovanni

[Guillaume227]

One resource that has been useful to me in the past when struggling with DMA and cache coherency on H7:
https://www.chibios.org/dokuwiki/doku.p ... _coherence

One thing you can try is to use spiPolledExchange instead of spiExchange, my understanding is the former doesn't rely on the DMA so it would help disambiguate where the problem is coming from.

Also regarding H7 SPI specifically, I read up on previous threads there (work by tridge and Giovanni):
viewtopic.php?t=4140&start=80#p34874

One thing that did it for me was to explicitly set the CFG1 DSize in the driver config (1 byte in my case).
That's what my full config looks like:

Code: Select all

  static const SPIConfig encoder_spicfg = {
    false, // Circular mode
    nullptr, // Operation complete call back
    gpio::getPinPort<gpio::pin_t<gpio::MCio::ENCODER_SPI_CS>>(), // Chip select port
    gpio::pin_t<gpio::MCio::ENCODER_SPI_CS>::num, // Chip select pin
#if defined(STM32H7xx)
    // iC-MU datasheet: page 10, item 906: max freq is 10MHz
    // 64 is the lowest diviser D such that 550 MHz / D <= 10 MHz
    SPI_CFG1_MBR_DIV64 | SPI_CFG1_DSIZE_VALUE(7), // master Baud rate = SPI master clock divider
#else
    SPI_CR1_BR_2 | SPI_CR1_BR_0, // Register 1 config
#endif
    0 // Register  config (for SSOE and FRF bit for TI protocol if needed)
  };
 


Giovanni, you say that the two driver versions should work exactly the same. Is there a description somewhere of what the under the hood differences are? What are the benefits of switching to the new version?

[Giovanni]

Hi,

The new version supports slave mode and implements error codes from functions (spi v1 returned void) but this is not leveraged yet.

Giovanni

[__Max__]

Hello Giovanni, Guillaume,

Thanks for your help. It works now with your indications.

Max.