Hey Team,
I've asked a question regarding the TMS570 mibspi in slave mode here. The following query can be considered a follow up on that question. We have been able to set up and test the following (This is setup to test the MIBSPI.)-
- TMS570 chip as slave with external master and external clock (which is also a TMS dev kti Hercules xl-570LC4357).
- External clock for the slave is currently coming from the master tms 570 but on the actual board is a free running clock coming from a dsp chip.
- 4 pin mode (CS, MOSI MISO, CLK) but in out case we only have data transmission from master -> slave. so we only connect MOSI pin and leave MISO floating.
With the above mentioned setup we are able to send data (uint16 {1,2,3,4,5,6,7,8}) over MIBSPI at 6.75 Mhz and see the following behavior.
- We send this data continuously from the master in a while loop.
- For most of the times, we are able to see the same data on the slave.
- Some of the times we are only seeing zeros upon copying rx data. This is after checking the RXEMPTY bit in the SPI receive register buffer.
Seeing this behavior leads me to believe that the sampling is not happening exactly when it should leading to the salve believing that it sees some data but it actually is just sampling 0's. Clock phase and polarity on both ends is 0.
When we increase the frequency to 12.5 Mhz, we don't see the exact data at all and see data bit shifted to the left ({0x10,0x200,0x300,..}) or see a list of 0's upon reading the rx buffer. This is only resolved by placing a considerable amount of delay between two subsequent transfers.
On our board the master device is a dsp chip that is sending data in the spi format and is outputting a free running clock as spi clock and has active low config for chip select whenever sending data. In this case we are unable to suspend the free running clock in the spi clock line. The delay between subsequent CS lows is ~25 microseconds. Our VCLK is set to 75 Mhz. We see the above mentioned issue of multiple 0's or bit-shifts here as well.
Is this still acceptable behavior from the tms side since it should ideally only look into the clock upon when CS goes low ? If it is then how do we resolve the issue of bit shifts and incorrect sampling. Our requirement is to run the mibspi clock at 25.576 Mhz and send data on the SPI bus at that rate. the below shown image is what the actual spi transaction looks like.
Thanks
Sree