• State
  • Locked Locked
  • Replies 0 replies
  • Subscribers 97 subscribers
  • Views 345 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM3730, unexpected McSPI delay between byte transfers

Jamaal_Charles
Genius 3245 points
Other Parts Discussed in Thread: DM3730

Hello,

We are using Linux on the DM3730, and we are seeing an unexpected delay between byte transfers.  We have developed device drivers for two of the McSPI units (2 and 4).  The SPI bus is running at 12 MHz.  The McSPI devices are in master mode, driving the clock and chip select.  Our word size is 8 bits.  We are using the provided spi.c and omap2_spi.c modules as our protocol and device drivers.  These are unaltered except for turning on DMA rather than polling in omap2_spi.c.

Our drivers are functional and data is being transferred to and from the slave devices without error, except for an unexpected delay between each byte of a transfer.  In the DM3730 TRM section 20.5.2.7 discusses Chip-Select Timing Control.  The minimum delay between words is shown to be .5 clock period after the first word and .5 clock before the next, or 1.0 clock total.  Table 20-36: MCSPI_CHxCONF shows that the reset value of the TCS field is zero, resulting in this .5 clock minimum idle clock case.  We do not modify this field and the low level driver does not have an interface to change this field.

Here are screenshots showing monitoring the SPI bus using the Beagle SPI protocol analyzer.  At 12 MHz the clock rate should be 83.3 nsec per bit.  The first picture shows a series of bytes transmitted from the DM3730.  The analyzer does not have 1 nsec resolution, but it can be seen that each bit time is roughly 80+ nsec.  The last bit of each byte is shown to take 3 bit times, which is one more than expected (1 for data, 1 for inter-byte gap, 1 for ???).

The Read screen capture shows that the last bit of each byte takes 5 bit times which is 3 more than expected!  It’s clear that this is a large hit on bus performance.

We artificially set the TCS register to all it’s legal values and confirmed that we could increase the inter-byte delay, but could never decrease it.  We experimented with setting the TURBO bit and this did indeed decrease the wasted time.  However on reads the McSPI issued one more byte read than requested, confusing our slave.  And on write, although TURBO is not advertised to have any effect, the gap did decrease, but our slave was again confused and always duplicated the 2nd byte of each transfer.

I wonder if this large inter-byte gap is a known issue with a work-around?  Is there something we are doing or understanding wrong?

Thanks!