SPI Mater<->Slave communication problem (slave starts to send 0x0010 after some while)

[KR51K]

Hello,

I'm working on a project with 2 STM32F4 that are communicating by SPI. The Master (running on 168MHz) is sending packages with 10x16bit every 1ms and 5.25mBit/s. The CS signal is connected to an EXTi pin of the slave that calls a DMA SPI transfer. My problem is, that after some point (minutes/hours) the slave starts answers the tranfer with only 0x0010 for every word. And it does not recover. After a reset everything works fine again. I'm wondering why the slave sends this data (its always the 0x0010) and does not recover... Does anyone has an idea what could cause this problem and why the slave does not recover from it's state?

Thanks and best regards!

[waclawek.jan]

Because of bug in your software.

My crystal cube won't show more.

Debug the slave as usually: run it with debugger, instrument your code e.g. toggling a pin in the EXTI ISR and another in the DMA ISR, output debug information through USART or any other communication link available, etc.

JW

[KR51K]

Hello,

yes, you are absolutely right! I have tried several things in the meantime, but it seems that the slave puts in the right data into the buffer, but I see very different signals on the MISO wire. That's kind of strange! But maybe I'm doing something wrong in general: where do I have to call the HAL_SPI_TransmitReceive_DMA function in the slave? I currently do this, when I get the external interrupt from the CS line. Is this correct?

Thanks and best regards

Christoph

[KR51K]

Ok, another thing I noticed: if I watch the MISO signal with the scope, everything is ok. But when I pause the debugger, I see this 'strange' data pattern on the MISO line. So what I could imagine is that the slave has an error with the HAL_SPI_TransmitReceive_DMA function at one point during the runtime and does not recover. So, anyone an idea what the correct behaviour is, if you get a a status != HAL_NOK from HAL_SPI_TransmitReceive_DMA?

[KR51K]

Normal behaviour

Behaviour during debugger paused:

[waclawek.jan]

We still know nothing about your application.

If slave receives clocks and there is nothing which would write to the SPI transmit register (e.g. because the program which normally writes to it is stopped by debugger), it keeps repeatedly transmitting the last frame.

JW

[KR51K]

Sorry, so the slave sends data to the master during transmit/receive. So I’m is a framecounter, some measurement values followed by a checksum. And this it what I absolutely don‘t understand: I never send this kind of data seen in the scope. So it seems that it it not the last frame I have sent before pausing the debugger.

[KR51K]

Ok, I ran into the error again after approx. 2 hours. So the error occurs when calling this line inside the HAL_SPI_TransmitReceive_DMA, when the function

 if (HAL_OK != HAL_DMA_Start_IT(hspi->hdmarx, (uint32_t)&hspi->Instance->DR, (uint32_t)hspi->pRxBuffPtr,
 hspi->RxXferCount))

return with a HAL_ERROR after calling the line

 __HAL_LOCK(hdma);

And so I return from my function call:

status = HAL_SPI_TransmitReceive_DMA(&hspi1, (uint8_t*)SPISlaveTXdata, (uint8_t*)SPISlaveRXdata, SPI_PACKET_SIZE);

with the status HAL_ERROR.

And it seems that the program/DMA do not recover from this state since I run into this error for always.

So what could help in this case? call the unlock for the hdma_spi1_rx in case of a HAL_ERROR?

[waclawek.jan]

By "frame" I mean byte or halfword or whatever is the bits-setting of SPI. So what you see is the last byte/halfword sent by slave (probably the challan from your description), repeated over and over.

I don't use Cube/HAL so won't comment on its one workings and failures.

JW