Stm32 SPI Slave Incorrect Data Receive or SPI going out of Sync from Master

[AGond.2]

Hello Community,

I have Several Query Related to STM32F439 Microcontroller SPI 6 Slave DMA Mode,

Let me Explain the Scenario , we have Custom Board Build Around STm32F439 micro-Controller and using HAL Stm32V27 Library Version.

so we are Communicating with Different Module Via SPI6 Slave Mode using DMA, So as Power on we are Sending Around 9000 bytes of Data from Master to SPI6 Slave  Micro Controller in 6 bytes of Frame, so we Observed that whenever MISO line is Coming in Between or Going in Between our Receive Data Lost and SPI went out of Sync as we are using SPI Transmit Receive DMA API for our Communication, Referencing of this Statement i have Attached my Observation and Saelee Logic Analyzer, Capture 1 Fully Working Condition , as you can see Capture 1 Grey Clock , Below one Chip Select, Pink one MOSI Data and Below there is no Moment of MISO Signal and It's working fine but sometime am Getting Capture like this in Capture 2,  Grey Clock, Below one Chip Select, Pink one MOSI and Yellow one is MISO and in this type of Micro Controller Behavior we are getting data Lost after change in state of MISO  Signal and Facing out of Sync Problem, i have Attached Capture 3 Similar to Capture 2. so Whenever This Scenario is Happening am Getting Garbage Data and Facing out of Sync issue, and Whenever am Seeing Capture 1 and One more Scenario like MISO Always there as long as long MOSI is Present that time am not Seeing any Data and Sync issue.

So Overcome this Problem i Change API From Transmit Receive DMA API  to Receive DMA API only as Power on we Don't need to Transmit Back anything to Master From Slave but whenever Master Initiate Read Command am Calling Transmit Receive DMA API , so with this Approach Problem Reduced  by 90% but still we are facing Data lost and  Out of Sync Issue, because of this Master not able to Read Back Acknowledgement Register from Slave Module.

So can Anybody tell why this Happening? 

what Approach and Methodology we can use to Over Come this Problem?

Why this Happening Once in While or 1 out of 20-30 times Power on Condition ?

is this Software Problem or Issue we Micro Controller ?? 

 

Capture 1

 

Capture 2

 Capture 3

[Ozone]

There is not really much to see and discern on the attached images, especially not the timing of individual signals in relation to each other.
I would suggest the reproduce the problem with (significantly) less transfers, or post only relevent sections

> ... .as you can see Capture 1 Grey Clock , Below one Chip Select, Pink one MOSI Data ...

That doesn't seem right.
I have a somewhat similiar application (for the F303), were the STM32 acts as SPI slave, transferring roughly 1kB of data at once.
However, /CS is activated at the start of the transfer, and remains low until the end. There is no /CS transition for individual bytes / values.

[AGond.2]

Hello 

Thank you for your reply

As we are Facing issue in Large Data Set, so till 2Kb data  i Didn't got any Issue.

So, when we are sending more then 3Kb data at Once Power on that time only we are facing issue also out of 10 Run the issue will be there 1-2 times only.( in this Scenario i used SPI Receive DMA API only) 

so Whenever i use Transmit Receive API(instead SPI Receive DMA) Power on Condition, Issue will more than 60% and what we observed issue is only coming when MISO Signal is not Consistent through out the 8KB Data Set.

Sometime MISO is not at all there then Suddenly Visible in between the Transaction of 8Kb data Set.

Also we are Sending Data in frame of 6 bytes. 

we are making CS low from Master Side before Asserting Clock and MOSI  in Slave for 6 byte of data and After Dumping 6 bytes of Data CS will go high and this will keep on Happening for each 6 bytes Frame and will Continuous High once we Send Full Data Set of 8Kb.

[Ozone]

Perhaps you have an electrical / signal issue.

One thing you can try is to configure your logic analyser / scope to trigger on the error condition and focus on reviewing the surrounding transmissions.

Another thing you could try is to reduce the SPI clock frequency, say, to about one-tenth of the current one.
If that helps it is most probably a signal integrity issue, either PCB-related or EMI.