Skip to main content
Visitor II
March 7, 2018
Solved

[SOLVED] STM32H7 SPI does not seem to work with DMA

  • March 7, 2018
  • 11 replies
  • 11504 views
Posted on March 07, 2018 at 13:01

EDIT: 14/03/2018

https://community.st.com/people/Schwaninger.Hannes

‌ found that we need to use RAM_D1 and not DTCMRAM of the memory area. This is not made by default when we use STM32CubeMx to set SPI and DMA together. Hello, I am working on a full duplex SPI communication through DMA using STM32H7. So, I have bought 2 NUCLEO-H743ZI, one to be the master, the other to be the slave. I have downloaded, built and flashed SPI_FullDuplex_ComDMA example via TrueStudio. As there is no ''TrueStudio format'' example, I have generated the project with STM32CubeMx and replace Inc and Src generated files with SPI_FullDuplex_ComDMAfiles. And tadada! ... It is not working correctly....... Only a few bytes are sent and Rxbuffer is never filled.

0690X00000609ynQAA.png

I have made connexion wires as short as possible and I have increased spi clock prescaler to get ''slow, nice and smooth'' signals. Electronic not seems to be the problem. I have modified the example to run it without DMA by replacing :

HAL_SPI_TransmitReceive_DMA(&SpiHandle, (uint8_t*)aTxBuffer, (uint8_t *)aRxBuffer, BUFFERSIZE)�?�?�?�?�?�?�?�?�?�?

With :

HAL_SPI_TransmitReceive(&SpiHandle, (uint8_t*)aTxBuffer, (uint8_t *)aRxBuffer, BUFFERSIZE,5000)�?�?�?�?�?�?�?�?�?�?

And now it's working! But not with the DMA .... This test shows that SPI is set and works correctly. aRxBuffer is filled with the good values.

0690X00000609w9QAA.png

Back in my code, I am trying now to send data through DMA with master and read them with slave:

// Master
HAL_SPI_Transmit_DMA(&SpiHandle, (uint8_t*)aTxBuffer, BUFFERSIZE)
// Slave
HAL_SPI_TransmitReceive(&SpiHandle, (uint8_t*)aTxBuffer, (uint8_t *)aRxBuffer, BUFFERSIZE, 5000)�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

It's working! Master sends DATA through DMA and my aRxBuffer is correctly filled on slave.

However, I have never been able to read DATA on master or slave with one of these functions:

HAL_SPI_TransmitReceive_DMA(&SpiHandle, (uint8_t*)aTxBuffer, (uint8_t *)aRxBuffer, BUFFERSIZE)
HAL_SPI_Receive_DMA(&SpiHandle, (uint8_t *)aRxBuffer, BUFFERSIZE)�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

I have tried to set DMA and SPI with STM32CubeMx but the problem remains the same. HAL_SPI_TransmitReceive_DMA always returns HAL_OK but code quickly falls into HAL_SPI_ErrorCallback. That only happens with DMA, never wih SPI only...

I do not think that I am doing something wrong as I have not modified the SPI_FullDuplex_ComDMA''example'' Src and Inc files...

EDIT: 13/03/2018

I have tried HAL_SPI_TransmitReceive_DMA and HAL_SPI_Receive_DMA on a STM32F7 to be sure that there is no technological problem on Cortex-M7. All DMA functions are working perfectly with F7.

EDIT: 14/03/2018

https://community.st.com/people/Schwaninger.Hannes

has tested SPI_FullDuplex_ComDMA example with Keil and it seems to work. However, he can't make it work with same configuration files if he creates a new project.

For me there is a problem with files generated by STM32CubeMX.

Does anyone have already made a full duplex spi communication with dma on a stm32h7 with a new STM32CubeMx project?

Thanks for your help!

#dma #spi #nucleo-h743zi #stm32h7 #hal
    This topic has been closed for replies.
    Best answer by H S
    Posted on March 14, 2018 at 18:03

    I've just found the difference between the HAL Nucelo example projects and the CubeMX generated projects.The problem for the DMA transfer error is that we use the false RAM!!

    I have changed the settings in MDK-ARM from

    IRAM1 (default setting from CubeMX) to

    IRAM2 (same is in the example projects) and now the SPI DMA transfer runs without error.

    0690X0000060A89QAE.png

    I've found out, that with this memory address

    IRAM1 is the

    DTCM-RAM and

    IRAM2 is the

    AXI SRAM D1.

     

    enjolras.g

    please check also in your project with TrueStudio and if it works, please share also the correct settings.

    11 replies

    Visitor II
    March 13, 2018
    Posted on March 13, 2018 at 07:52

    did you get it working ?  

    you are ahead of most of us.

    this will promote your question.

    Geo EnAuthor
    Visitor II
    March 13, 2018
    Posted on March 13, 2018 at 10:58

    Thanks for your 'promoting support'!

    I was looking at the worst case scenario: 'technological problem on cortex-m7'... So I have tried to receive SPI data with DMA on a STM32F7. And all DMA functions are working as expected. So it is definitely a problem in STM32H7 HAL library... I will try to find what is wrong in the library but It is extremely time-consuming... I would have preferred to have a way to report them a bug and let them correct it.
    Visitor II
    January 3, 2019

    I have the same issue. I have DMA callback working on F7 , but same doesn't work on H7.

    did you found the solution??

    Visitor II
    March 14, 2018
    Posted on March 14, 2018 at 09:38

    I've just started with the H743ZI Nucleo and have also troubles with SPI and DMA in my ''real Project''

    (more about this later in a separate reply).

    But the SPI_FullDuplex_ComDMA example from H7 HAL V1.2.0 works in my case with two Nucleo (Master/Slave).

    I use Keil MDK-ARM and not TrueStudio.

    0690X00000609ZpQAI.png
    Geo EnAuthor
    Visitor II
    March 14, 2018
    Posted on March 14, 2018 at 11:57

    Can you confirm that Rx buffers on slave and on master are both filled with Tx buffer ?

    Sometimes I can send the whole frame, but I never have anything in Rx buffer except 0.
    Visitor II
    March 14, 2018
    Posted on March 14, 2018 at 13:24

    Yes I can confirm this, the Rx Buffers are both full.

    0690X00000609iNQAQ.png

    You can check it also on the LED status of the Nucleos (the green and blue LED must be on).

    Graduate II
    March 14, 2018
    Posted on March 14, 2018 at 13:44

    Apologies if you've already verified this but is the data cache being handled correctly on the (DMA) receiving side?

    Visitor II
    March 14, 2018
    Posted on March 14, 2018 at 14:26

    Hey David, who do you mean?

    If me, how can I check the data cache transfer, because I'm new with the Cortex M7...
    Graduate II
    March 14, 2018
    Posted on March 14, 2018 at 14:51

    In general, DMA receive buffers should be aligned and sized to cache-line boundaries and the cache invalidated before access.  Otherwise, DMA receive buffers should be located in a cache-inhibited address range.  ST's examples don't always rigorously follow either, leading the unwary on sometimes-wild chases.

    Visitor II
    March 14, 2018
    Posted on March 14, 2018 at 15:34

    As I wrote above, I have also a strange problem with the H743ZI Nucleo and SPI+DMA:

    The SPI_FullDuplex_ComDMA example from the H7 HAL V1.2.0 works without problems with MDK-ARM and the Nucleo.

    But

    if I create a new MDK-ARM Projekt for the Nucleo with CubeMX 4.24 with the same configuration as in the SPI_FullDuplex_ComDMA example (SPI1 Master FullDuplex, DMA2, Stream2 Rx, Stream3 Tx, same Rx/TXBuffers, same SPI Send Function, ...) it will send only some byte and the transfer stop with the

    hspi errorcode 0x10 (= HAL_SPI_ERROR_DMA = transfer error).

    HAL_SPI_TransmitReceive_DMA(&hspi1, (uint8_t*)aTxBuffer, (uint8_t *)aRxBuffer, BUFFERSIZE);

    0690X0000060A84QAE.png

    Without DMA transfer (polling) the full SPI transfer works without problems again.

    (a little bit similar to the behavior from Geo En if I look at the first post).

    I have also create a new project for the F746ZG Nucleo with CubeMX and the same configuration.

    The SPI DMA transfer works immediately without any problems.

    Did anybody have an idea what could be wrong?

    Or could anybody create a CubeMX project for the H743ZI Nucleo and check, if the SPI DMA transfer works?
    Geo EnAuthor
    Visitor II
    March 14, 2018
    Posted on March 14, 2018 at 15:43

    This is exactly my problem. As there is no 'TrueStudio format' example for 

    SPI_FullDuplex_ComDMA

    , I have generated the libraries with STM32CubeMX and copy/paste src and inc from the example. So the problem is probably coming from files generated by STM32CubeMX... but it seems to work for you with Keil... This is starting to make me crazy
    Visitor II
    March 14, 2018
    Posted on March 14, 2018 at 15:51

    Oh, i did not know that you have create your project with CubeMX. In this case we have the same problem... ;)

    Technical Moderator
    April 18, 2018
    Posted on April 18, 2018 at 18:34

    Hi, 

    Thanks HS for sharing the correct answer, actually for all application using DMA you have to do the same workaround. 

    Currently, a new interface is under dev in STM32CubeMX to handle the memory assignment and it will be delivered in  a later release. 

    Thanks for the interest in STM32CubeMX, enjoy using the tool. 

    Visitor II
    May 24, 2018
    Posted on May 24, 2018 at 14:00

    Hi All,

    I am using STM32 AC6 Workbench and STM32CubeMX 4.25. I am doing SPI DMA Transfer ( Memory to Peripheral) and have selected RAM_D1 (0x24008000) but i didn't see any output on MOSI line.  I used GPIO as CS and did following thing:

    uint8_t txBuf[3];

    txBuf[0]=0x1;

    txBuf[1]=0x2;

    txBuf[2]=0x3

    HAL_GPIO_WritePin(GPIOE, AD9913_SPI4_CS_DDS_Pin, GPIO_PIN_RESET);// chip-select low

    errorcode = HAL_SPI_Transmit_DMA(&hspi4, &txBuf[0], 3);

    HAL_GPIO_WritePin(GPIOE, AD9913_SPI4_CS_DDS_Pin, GPIO_PIN_SET);// chip-select high

    I debugged it on STM32 AC6 and i didn't see any data on TXDR register which is quite confusing. Although, when i did same thing without DMA operation then everything works fine but no data is watched on TXDR when i debugged it on STM32AC6.

    I do get 'Complete Xfer Callback' when all the data are transfered but i don't see any data on MOSI line. Is it BUG ?

    So two things bring out here:

    1. Why don't SPI DMA (MEM 2 PER ) works ?

    2. Why don't see data on TXDR while checking through STM32 AC6 Workbench ?

    Regards,

    Manish

    Visitor II
    May 24, 2018
    Posted on May 24, 2018 at 15:22

    This are less informations for other people to help you ...

    I would suggest, that you are starting with a working example project from the HAL repository folder (e.g. Nucleo \ Examples \ SPI_FullDuplex_ComDMA). If this code run on your board, then change the code like your desires.

    Visitor II
    May 31, 2018
    Posted on May 31, 2018 at 12:28

    Thanks. I am able to perform SPI DMA Transmit with some notable changes.

    Observation 1:

    I was using global buffer ( uint8_t txBuf[5] ; ) and I enabled (using STM32CubeMx) D-Cache inside main() then to perform DMA, I need to call SCB_CleanDCache_by_Addr((uint32_t*)&txBuf[0], 5) before HAL_SPI_Transmit_DMA(&hspi4, txBuf, 5) otherwise DMA doesn't work OR need to configure MPU_Config() for the DMA to work.

    Observation 2:

    I was using global buffer ( uint8_t txBuf[10] ; ) and I didn't enable (using STM32CubeMx) D-Cache  inside main() then to perform DMA , I don't need to call SCB_CleanDCache_by_Addr((uint32_t*)&txBuf[0], 5) before HAL_SPI_Transmit_DMA(&hspi4, txBuf, 5) and DMA works fine.

     

    I am confused with the results and i checked it 10-20 times. I am unable to reach to conclusion as i am new to it. Kindly help.

     

    Regards,

    Manish

    Visitor II
    November 5, 2018

    Was anybody able to get a SPI DMA Tx transfer working? I'm using CubeMx, TrueStudio, stm32H753 and was able to get a SPI DMA Rx transfer working. However, I am struggling to get the Tx working. It always ends with a SpiErrorCallback. Simply changing the RAM locations doesn't work for me either.

    Graduate II
    November 5, 2018

    What does HAL_SPI_GetError() tell you?

    Visitor II
    November 6, 2018

    It returns 0x10, which seems to be a DMA transfer error. I am not sure what the underlying problem might be.

    Graduate II
    November 6, 2018

    It's probably better if you start your own thread (and include some code).