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.

OMAP3530 - Getting SPI to Work



I am trying to get the SPI working on the OMAP 3530. I am trying to be a master to an the ADIS16364 (an IMU). We are using McSPI4 (only one chip select). I have been able to individually request and retrieve data from this (slave) device. But this device supports a mode called burst where the master puts out 1 address (0x3e00) followed by 11 don't care addresses separated by 1 SCLK all the while keeping CS low. I was almost able to accomplish this by using the TX FIFO. The problem though is CS goes high in between words. The manufacturer says that puts it's device in an unknown state. I though turbo mode would help me, but it does not. The TI spec says (19.2.5.2.3) that I must also set the SPIm.MCSPI_MODULCTRL[0

  •  I believe the only way to achieve the CS assertion for only n words traditionally would be to use the manual control of the FORCE bit, I don’t see any way of limiting assertion to just n words otherwise. If you happen to have a programmable logic device (i.e. FPGA) in your design which can spare a few pins, you could set some logic up to force the CS low for n cycles when accessing the ADIS16364 in burst mode. One soft alternative, if you were using DMA would be to use a chained DMA channel (i.e. one triggered by completion of a prior transfer) or a timer delay driven channel to write into the MCSPI_CHxCONF.FORCE bit to clear it after the n words were transferred. This is a bit non traditional, and I have not seen it done on the OMAP3, but I have seen similar ideas used in legacy DSP devices.

     

    Another thought would be if you are only making these sorts of accesses, you could leave the CS asserted all the time, and have the ISR that starts the new transfer clear the FORCE bit immediately, and than re set it before exiting, thus toggling the CS before each new transfer. The only problem I see in this solution would be that is if your ISR is sufficiently short, you may not have it deasserted long enough for your SPI device.