LPSPI under Zephyr

[kk7xo]

We are using Zephyr and the iMXRT1052 LPSPI.  I am trying to interface to a device (LTC2986) that requires me to send 7 bytes in a single transfer.  The driver does not allow a frame of 56 bits, so I set a frame of 8 bits and I transfer 7 bytes.  However, between each 8 bit group there is a "glitch" in the clock.  The clock goes high for the last bit and then goes low so fast as the next byte starts, that it appears as a glitch.  The last bit in the frame does not get a full clock high time.  I spent all day trying different configurations in an attempt to fix this, with no success.  Do  you have any suggestions?

The driver in use is the NXP fsl_lpspi.c/h.

[kerryzhou]

Hi @kk7xo ,

  To the RT1050 SPI, the minimum frame size is 8bits, so your 7 bit can't be supported.

   If you want to use 8bit*7, and you want each byte is not delayed, I suggest you use the DMA, that transfer is quick, and each byte is near, you can try it on your side.

Best Regards,

Kerry

[kk7xo · Accepted solution]

We are using 8 bit frames.  The problem was that we needed to send 7 such frames.  We are not attempting to send 7 bits, we are sending 7 bytes.

I fixed the problem after my colleague found some variables that can be set in the device tree to affect the operation of the driver.  There are 3 variables, sck-pcs-delay, pcs-sck-delay, and transfer-delay.

pcs-sck-delay sets the number of ns from chip-select active to sck active at the beginning of the transfer.

sck-pcs-delay sets the number of ns from sck inactive to chip-select inactive at the end of the transfer.

transfer-delay sets the number of ns between frames during the transfer.

Since we were not using these variables at first we were getting 0 ns between frames during the transfer, which appeared as glitches on the scope.  I set transfer delay to 1000 and it put 1 us between frames which made the glitches disappear, and now everything works fine.

Thank you for your interest and help.

[anthony_asterisk]

Thanks for posting the solution, it has helped me alot!

I cannot believe the driver doesn't default to a sane value when transfer-delay is absent, its a really bad design by NXP!