cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronization string losed using SPI with DMA

de Haro Carbonell
Associate III
Posted on August 11, 2017 at 15:07

Hello Community,

I have configured a STM32F429ZIT to communicate through SPI (SPI6) as slave and using DMA, see attached file.

The transmission works very well during 1 - 5 min but suddenly some transmission errors ocurs and HAL_SPI_ErrorCallback is called.

/***********************************************************************/

void HAL_SPI_ErrorCallback(SPI_HandleTypeDef *hspi)

{

    if(hspi -> Instance == SPI6)

    {

        HAL_GPIO_WritePin(GPIOF, GPIO_PIN_1, GPIO_PIN_SET);

        memcpy((uint8_t*)HMI_slave_TX_data, (uint8_t*)HMI_slave_TX_working_buffer, 8);

        HAL_SPI_TransmitReceive_DMA(&hspi6, (uint8_t*)HMI_slave_TX_data, (uint8_t*)HMI_slave_RX_data, 8); //--- initiate HMI communication

    }

}

/********************************************************************/

Then the communications is still there but the string 'HMI_slave_TX_data' sent by the STM32 is shifted or delayed 8bits, I have seen this on the oscilloscope. But the content of this string is correct, i can see the transmission delayed on the oscilloscope and HMI_slave_TX_data values using debut (and also using STMStudio) and their values are OK!!!!

So, at the beginning the transmission is perfect but suddenly the GPIOG PIN 1 is set and the transimion is shifted...

So i don’t understand what is happening with DMA, memory address or something related to the transmission...

Some similar it happens using DMA in circular mode instead normal mode...

Could anyone help me on this issue???

Thanks in advance and best regards.

Alejandro
12 REPLIES 12
Posted on August 16, 2017 at 11:06

Thanks for your quick reply.

It is interesting the behaviour of the System Workbench for STM32 in debug mode when I place a breakpoint inside

of HAL_SPI_ErrorCallback(), because it always stops within (every cycle), for example if i place it on HAL_GPIO_WritePin(GPIOF, GPIO_PIN_1, GPIO_PIN_SET); line, and this pin is set. But in RUN mode, this pin is set only when the transmission issue ocurs... so looks like that in debug mode the SPI and DMA doesnt works as i expected. This is another reason it is very difficult to me understand what is happening.

On the other hand, I am going to connect the oscilloscope trigger signal to PIN1 GPIO and let's see if i find out something new.. I will keep inform you !

Thanks!

de Haro Carbonell
Associate III
Posted on November 17, 2017 at 10:33

Hello,

I finally got the solution, I found what the problem was!

Usually, the CS signal goes from 1 to 0, then MISO and MOSI communicates, and once the communication finishes CS signal goes from 0 to 1, and the STM32F429 continues with the rest of the tasks...

This was happening every 150 ms, that's the period of thime both uC are communicating. But the STM32 uC has another tasks with more priority than SPI communication.

When one of this higher priority starts during SPI communication, and once this higher priority is done then the uC continues with the task was doing ( it was SPI),

obviously

this frame is lost and 'HAL_SPI_ErrorCallback' is executed, and then SPI is restarted.If SPI is restarted when CS signal is 1, (spi idle), then there is no problem, SPI is restarted properly and the next frame will be received without problem. BUT if SPI is restarted when CS signal is 0 (STM32 SPI is selected and ready to communicate) then the STM32 is waiting to send and receive an amount of bytes but it will receives less, so an a mismatch of communication bytes is the key of the PROBLEM.

I have solved this issue just adding:

void HAL_SPI_ErrorCallback(SPI_HandleTypeDef *hspi)

{

    if(hspi -> Instance == SPI6)

    {

        while(HAL_GPIO_ReadPin(GPIOG, GPIO_PIN_8) != GPIO_PIN_SET) // CS signal

        {

        }

        HAL_SPI_TransmitReceive_DMA(&hspi6, (uint8_t*)HMI_slave_TX_data, (uint8_t*)HMI_slave_RX_data,10);

    }

}

I have to modify 'WHILE' in order to not stop the processor , but it is the first approximation.

Now the communication is working all the time, but some times a frame is lost (and ' HAL_SPI_ErrorCallback' is called) due to higher priority task. But it is normal, a CRC is implemented to note that.

Thansk JW to help me and support.

I hope this helps to other people.

Best regards.

Alejandro.

PGaik
Associate II

did you find any solution?