Hello,
I had a previous ticket where originally it was thought that the some lost words from the SPI peripheral was down to EDMA3 transfer issues (see post here ), but it turns out that the SPI peripheral is flagging issues on the SPI bus and are discarding words due to either bit length errors on SIMO or TX errors on SOMI (both very occasionally, say once every hour). We are running a single master and single slave (OMAP) SPI bus. The PCB line lengths for CS, SOMI, SIMO and CLK are almost identical (+/- 1mm). There is a single in-line 22ohm resistor on CS, with the other lines being directly connected. Clock edges look sharp and there is little or no noise or ripple on the lines.
The master transfers 2 16-bit words separated by a chip select de-assert and assert. This is mainly due to the OMAP limitation of not being able to do 32-bit SPI transfers. The clock rate varies from 24.192 to 24.64MHz. At 24.64MHz the timing slack on a clock-by-clock basis is 580ps. The maximum clock rate according to the OMAP (for 1.3 operation and running at 456MHz) is 25MHz or 40ns per clock cycle. I have verified that when the SPI peripheral flags either of these issues, that the master timing is correct and within specification.
Here is a view showing the CS (magenta), CLK (blue) and MOSI (yellow):
![]()
Clock cycle measurement, showing more than 40ns clock cycle time:
![]()
Timing from chip select assert to first clock edge (OMAP requirement seems to be 5.88ns)
![]()
Timing measurement for last clock edge to CS de-assert (OMAP requirement seems to be 8.4ns)
![]()
I have tried modifying the master behaviour (register settings) to essentially concatenate the SPI words, i.e. one 16-bit transfer directly after the other, but the OMAP SPI peripheral almost immediately flags a TX error under these conditions.
Here is a capture, showing the 2x 16-bit transfers that almost immediately causes an issue:
![]()
1) Is there an OMAP limitation of running continuous 25MHz SPI operation, i.e. a continuous clock?
2) What is the minimum chip select de-asserted period?
3) SYSCLK2 is 228MHz in this case. Is there any other setup that is important for the SPI peripheral to achieve this operational speed?
Here is the code to initialise the SPI0 peripheral as a slave:
//configure pins
regs->spiPc0|=SPI_SPIPC0_PINSENABLE3; //enable SOMI,SIMO,CLK
regs->spiGcr1&=~SPI_GRC1_CLKMOD_MASTER; //slave
//configure slave pin directions
regs->spiPc1=SPI_SPIPC1_SLAVEDIR;
//select data word format 0
regs->spiDat1&=~SPI_SPIDAT1_DFSEL;
//clear CSNR[n]
regs->spiDat1&=~SPI_SPIDAT1_CSNR;
//MSB first
regs->spiFmt0&=~SPI_SPIFMT_SHIFTDIR;
//no c2TDELAY and T2CDELAY in chip select timings
regs->spiFmt0|=SPI_SPIFMT_DISCSTIMERS;
//polarity: low active
regs->spiFmt0&=~SPI_SPIFMT_POLARITY;
//phase delayed
regs->spiFmt0|=SPI_SPIFMT_PHASE;
//set valid prescale value (ignored)
regs->spiFmt0|=(2<<8);
//charlen = 16 bits
regs->spiFmt0|=0x10;
//enable overflow interrupt, bit error interrupt, data length error
regs->spiLvl |= SPI_SPILVL_OVRNINTFLG|SPI_SPILVL_BITERRENA|SPI_SPILVL_DLENERRENA;
regs->spiInt0 |= SPI_SPIINT0_OVRNINTFLG|SPI_SPIINT0_BITERRENA|SPI_SPIINT0_DLENERRENA;
Thanks
