i.MX6D ECSPI transmitting issues.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6D ECSPI transmitting issues.

Jump to solution
837 Views
takashitakahash
Contributor III

Dear Comunity.

Our customer has question below.

In i.MX6D, I use the DMA in the Master mode of ECSPI is transmitting of 1008Byte
But, SCLK is stopped during transmission as attachments (remains Low),
Phenomenon during which SIMO is High will occur about two times.

Timing that occurs will continue to shift little by little not fixed.

What you may be considered, such as something cause

Thanks,

Best.

T.Takahashi

pastedImage_1.png

pastedImage_2.png

Pink :SS

Yellow:SIN

Green:SCK

Labels (2)
0 Kudos
1 Solution
656 Views
takashitakahash
Contributor III

Dear igor.

Thank you for support.
This problem has been resolved.

Cause was found.

The 1008Byte = 8064bit = 0x1F80bit as trying to set in BURST_LENGTH,
BURST_LENGTH because of 12bit, like lower 12bit worth of 0xF80 = 496Byte has been specified.


Therefore burst transfer for each 496Byte had become the behavior to stop.

Thank you,

Best Regards.

T.Takahashi

View solution in original post

0 Kudos
6 Replies
656 Views
takashitakahash
Contributor III

Dear igor san,

According to the log,
- 496 clock (62Byte) SCLK for each transmission is stopped four clocks.
· SCLK during the stop, MOSI is about 0.5 clocks Low next, and then about 3.5 clocks High
Become.
· SCLK after the stop, communication is resumed normally.
It looks like phenomenon is repeated that.

Would you please advice this issues?

Thank you,

Best Regards.

T.Takahashi

0 Kudos
656 Views
igorpadykov
NXP Employee
NXP Employee

Hi Takashi

 

is it working without sdma, using polling method ?

Please try to test it on latest L4.1.15 BSP on i.MX6Q Sabre SD reference board

http://www.nxp.com/webapp/Download?colCode=L4.1.15_1.1.0_LINUX_DOCS&Parent_nodeId=133769948107170617... 

 

Best regards
igor

0 Kudos
657 Views
takashitakahash
Contributor III

Dear igor.

Thank you for support.
This problem has been resolved.

Cause was found.

The 1008Byte = 8064bit = 0x1F80bit as trying to set in BURST_LENGTH,
BURST_LENGTH because of 12bit, like lower 12bit worth of 0xF80 = 496Byte has been specified.


Therefore burst transfer for each 496Byte had become the behavior to stop.

Thank you,

Best Regards.

T.Takahashi

0 Kudos
656 Views
igorpadykov
NXP Employee
NXP Employee

Hi Takashi

this may be caused by i.MX6D ERR009165, ERR009606 i.MX6DQ Errata

http://cache.freescale.com/files/32bit/doc/errata/IMX6DQCE.pdf

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
656 Views
takashitakahash
Contributor III

Dear igor - san.

Thank you for your replay.

The transmitter size of the data  are 1008Byte, ERR009606 would not fall.

And, although ERR009165 is errata which data is sent twice.

Size of the transmitted data was confirmed in a normal,
As the attached file, there is no state that has been transmitted twice before and after the point of the problem, of ERR009165
It does not seem to be a phenomenon.

Would you please any other advice.

Thank you,

Best Regards.

T.Takahashi

pastedImage_3.png

0 Kudos
656 Views
igorpadykov
NXP Employee
NXP Employee

Hi Takashi

to narrow down problem please try without sdma, using polling method.

Best regards
igor

0 Kudos