SPI, sporadic problem loosing ~CS during transfer

Hi,
I detected sporadic data corruption and it was not so simple to take a shoot.

The iMX7 is the master and it generates the SCLK signal, blue trace and the ~DL_CS signal. The slave system sends data, red trace.
Here we see, that the iMX7 sets the ~DL_CS signal high, and continues clocking, the slave system stops sending data, this is the correct behaviour for getting clock pulses during ~DL_CS is high.

The result is a data loss.

The slave system counting down the transmitted bytes and after a packet is done, it sets ~BRDY high. You see that behaviour during the first two (correct) transfers. After the third transfer, ~BRDY stays low, cause the transfer was disturbed and not all bytes were transmitted.

This happens after transferring about 2.5MB, but it is hard to reproduce, sorry.

Any work around?

With best regards

Gerhard

… two more shots, this time Looks similar, and isn#t a spike on the line, for sure.

Sorry.

[upload|GPltPIsCg7mvrMKpwSDhC/hyhd8=]

[upload|IQX1z3n4WO+ZzbLr1iaD8BWQ1mc=]

Dear @Gerhard,

Thank you for contacting the support. I guess this should be a little difficult to reproduce the problem.
I will try to reproduce the problem on my side, if I need any help I will get back you.

Hi Raja,

sent a test app, which this app it is very easy to reproduce the error.

https://share.toradex.com/b1lb77r3oy0qxnu

And see mails according to ticket: Ticket#2018111910000062

With best regards

Gerhard

Dear @Gerhard,

Thank you for the application, let me reproduce the problem with your application and get back you.

Hi Raja,
hope you have a scope at hand which is able to trigger on pulses shorter than a limit you set.
Just measure the typical lenth of the Transmission and than set the Trigger to pulses shorter than 80% of the Transmission length.
I tried to set the ~CS Signal ‘per hand’, but same Situation.
Should I Change the wiring to use a total different Signal?

[upload|Y/+vwGdbTc9I2D5D9SUqSBT/zc8=]

Init:
[upload|HEMXfwnkOVEm7EfZ8f29+d1Zja4=]

Uage:
[upload|QJml6yhxLmbB9lUaaWnc7uW21h8=]

With best regards

Gerhard

Hi Raja,

any news?
My current status is: We waiting for a ticket from our software department. No point in time available now.

My customer needs results until July, so we have to start with measurements at beginning of April.

With best regards

Gerhard

Hi @Gerhard

Raja is out of office this week, and I would like to leave the processing of this task to him. Please be patient.
We suspect that a conflict with other GPIO accesses could cause the problem. As a quick workaround, you could try to choose a GPIO from another block-of-32 GPIOs as a ~CS signal. However, I cannot guarantee that this will solve the problem.
BTW: We have equipment such as scopes around to properly investigate the issue.

Regards, Andy

Hi Andy,
I do lot of investigation on this issue together with Raja. I wrote a little app which clearly shows the problem. It is a conflict of register access. Two threads trying to set GPIOs. I have an workaround, but this fools my scope and my other system by clock speeds > 8Mhz.
Raja get a ticket and (hopfully) someone is working on that. But as we diskuss this the last time, Raja has no idea when this Problem is fixed.

In general, creating the ~CS signal by setting a GPIO line manually isn’t that good. The SPI controller do this way better. The problem is, that an extra clock transition is generated after ~CS is low. This can fool SPI hardware and cause a shift of one bit.

With best regards

Gerhard

Hi @Gerhard
I fully agree it would be much safer if the SPI controller could take control of the ~CS signal, but as you mentioned yourself this does not properly work. We cannot change the silicon, so the only way is to use a software workaround with a regular GPIO.
The ticket is in our system, and I raised the priority internally along with your deadline of beginning of April.
Regards, Andy

Hi Andy,

thanks. Raja told me, he created a ticket somewhere (your programmers crew) to solve this.
Raja also told me, that the Driver didn’t use the ~CS created by the SPI Hardware, maybe this is a work around a Silicon bug, doesn’t know.

However, I hope there will be a good solution.

I have enough work for this week, so it is no Problem to wait until Raja is back.

Thanks for helping.

With best regards

Gerhard

Hi Andy,

thanks. Raja told me, he created a ticket somewhere (your programmers crew) to solve this.
Raja also told me, that the Driver didn’t use the ~CS created by the SPI Hardware, maybe this is a work around a Silicon bug, doesn’t know.

However, I hope there will be a good solution.

I have enough work for this week, so it is no Problem to wait until Raja is back.

Thanks for helping.

With best regards

Gerhard

Hi Andy,
any news?
The system works now, but for the final PCB release I need a thread safe GPIO driver. I need some GPIO signals and it isn’t possible to put all on different banks.
Raja promised a thread safe driver …
With best regards
Gerhard

Hi @Gerhard
This is still on our To-Do list. Do you have any deadline until when you need the solution?
Regards, Andy

Hi,

I wanted to start developing the PCB at beginning of April …

I can do most of the work, and fix the GPIO lines later, but I should finish that in September …

With best regards

Hi,

I wanted to start developing the PCB at beginning of April …

I can do most of the work, and fix the GPIO lines later, but I should finish that in September …

With best regards