Other Parts Discussed in Thread: TPIC2060A
The SPI has the following features:
Up to 66 MHz operation
The manual for the Serial Peripheral Interface (SPI) for KeyStone Devices User's Guide mentioned above supports operations up to 66 MHz.
On the hardware platform of C6678, implement SPI dual bus control within a 3.3us (3300ns) interrupt cycle, and perform multiple SPI read and write data (DSP uses SPI for data transmission to TPIC2060A (35M=28.6ns) and AD/DA (48M=21ns) boards). One read and write register of the 36M SPI device is 16 (data bits)+2 (startup) * 28.6ns=514.8ns.
Encountering a problem, the theoretical calculation shows that within the interrupt cycle, 3300/515=6.4, SPI communication can be performed 6.4 times. However, in actual transmission, the interrupt cycle exceeded 2.3us (5.6us) after only 4 transmissions, and exceeded 1us (4.3) after 3 timeouts. It is estimated that 5.6-4.3=1.3us, and the usage time for one transmission is 1.3us, far exceeding 514.8ns.
SPI communication refers to TI's "7242.K1-STK_v1.1" SPI driver code:
//In the reference case, SPI communication adopts the read write synchronization method (read while writing). The function name is as follows:
Uint32 KeyStone_SPI_TxRx(Uint8 * txBuf, Uint32 firstTxByte,
Uint32 numTxByte, Uint8 * rxBuf, Uint32 firstRxByte, Uint32 numRxByte,
SPI_Transfer_Param * transfer)
Upon checking the program, it was found that the above function called KeyStone_SPI_wait_flag to delay checking the TXINTFLG and RXINTFLG states.
code：if(0==KeyStone_SPI_wait_flag(CSL_SPI_SPIFLG_RXINTFLG_MASK, CSL_SPI_SPIFLG_RXINTFLG_MASK))
#define SPI_TIMEOUT_CYCLES ((1000)*8*100)
Int32 KeyStone_SPI_wait_flag(Uint32 flag_mask, Uint32 expect)
{
Uint32 startTSC;
Uint32 delay;
volatile Uint32 flag;
startTSC= TSCL;
//flag_mask:CSL_SPI_SPIFLG_RXINTFLG_MASK
flag= gpSPI_regs->SPIFLG&flag_mask; //CSL_SPI_SPIFLG_RXINTFLG_MASK (0x00000100u)
/*Wait until SPI flag= expect value */
//1 = Transmit buffer is empty. An interrupt is pending to fill the transmitter.
while(flag!= expect)
{
/*if wait time is much larger than theoretical transfer time of
a byte, then it is looked as timeout.*/
delay= TSC_getDelay(startTSC);
// printf("KeyStone_SPI_wait_flag delay= %d \n",delay);
if(delay> SPI_TIMEOUT_CYCLES)
{
printf("KeyStone_SPI_wait_flag 0x%x timeout, SPIFLG=0x%x\n",
flag_mask, gpSPI_regs->SPIFLG);
return 0;
}
flag= gpSPI_regs->SPIFLG&flag_mask;
};
return 1;
}
The function is used to determine TXINTFLG and RXINTFLG in SPI Flag Register (SPIFLG), where there is a delay waiting code to determine whether TXINTFLG and RXINTFLG are 1, resulting in a delay.
At first, attempts were made to modify # define SPI-TIMEOut-CYCLES (((1000) * 8 * 100) ---># define SPI-TIMEOut-CYCLES ((400) * 1 * 1), but the SPI transfer time did not change.
Furthermore, the write to TXINTFLG judgment was masked in the KeyStone_SPI-TxRx function, resulting in 4 SPI communication interruption cycles becoming 4.7us (0.9us shorter than the previous 5.6us). At this point, the two SPI control ICs read and write register data OK.
Finally, the write RXINTFLG judgment was masked in the KeyStone_SPI-TxRx function, and the interrupt cycle returned to normal 3.3us. But two SPI control ICs read register data NG, but the write data IC acted.
1. The maximum operating speed in the SPI manual is 66MHz, which means that the SPIDAT1 or SPIBUF register data conversion speed can also support up to 66MHz.
2. To ensure the correctness of SPI transmission data, do we need to check the TXINTFLG and RXINTFLG flags before reading or writing SPIDAT1 or SPIBUF registers? When writing new SPIDAT1 data from the instruction manual, TXINTFLG will be updated. Do we need to make a judgment when writing data?
3. Now that the RXINTFLG write judgment has been blocked, the interrupt cycle has returned to normal 3.3us, and the IC has acted (feels normal), which indicates that the controlled IC has read the transmission data of SPI. Can hardware circuit problems be ruled out?
