TM4C1290NCZAD: How to clear the Tx FIFO

Hi Charles

Thanks for your reply~ Yes, I mean what was transmitted on the TX pin was one of the very early bytes in the Tx FIFO, and just one byte, the next data is the ones from DMA. And it can be repeated every time, it's tricky if FIFO can be empty or not empty.

Besides, there are some points that still need your help to clarify:

Charles Tsai said:

Please note that when you disable the SSI module, it does not clear the TXFIFO

1. So how can we clear the Tx FIFO? Only by power cycle reset?

The startup routine is as below, the slave will run this routine if the master is offline(the master will notify the slave by a GPIO)

void SafeMcuSsiStartUp(uint8_t * RxBuffAddr,uint32_t RxBuffSize,uint8_t * TxBuffAddr,uint32_t TxBuffSize)
{
	uint32_t rsv;
	
	ROM_SSIDisable(SSI2_BASE);
	ROM_SSIConfigSetExpClk(SSI2_BASE, 120000000, SSI_FRF_MOTO_MODE_1, SSI_MODE_SLAVE, 120000, 16);
	ROM_SSIEnable(SSI2_BASE);
		
	while((HWREG(SSI2_BASE + SSI_O_SR) & SSI_SR_RNE) != 0)
	{
		rsv = HWREG(SSI2_BASE + SSI_O_DR);
	}
	rsv = rsv;
	SSI1RxNum = 0;
	ROM_SSIIntEnable(SSI2_BASE, SSI_DMATX);												
	ROM_uDMAChannelTransferSet(
															UDMA_CH13_SSI2TX|
															UDMA_PRI_SELECT,
															UDMA_MODE_BASIC,
															TxBuffAddr,
															(void *)(SSI2_BASE + SSI_O_DR),
															(TxBuffSize/2)
														);
	ROM_uDMAChannelEnable(UDMA_CH13_SSI2TX);														
}

2. The method they are using is abandoning the first byte, but I think it's unreliable if we can't explain this. So what's your recommendation for restarting the communication?

Expect for your reply, thanks!

Hello Shaofeng,

Other than power cycle reset, the other method is entirely disabling the SSI peripheral and reconfiguring once again. To my understanding, that would clear the FIFO as well. This would be better than a full POR.

I will let Charles also share his thoughts on the restart of communication, he may have different ideas, but my thought would be to send out dummy bytes to clear the FIFO followed by resuming communication with some form of 'retry' packet to prompt the slave to send over the 'lost' data.

Best Regards,
Ralph

Hi Shaofeng,

  As suggested by Ralph, have you tried to reset the SSI module by calling SysCtlPeripheralReset(SYSCTL_PERIPH_SSI2)?

Customer has already tried reseting the SSI module by calling peripheral reset, but it can not clear the Tx FIFO, there are still some previous date inside. From your side, the best way is to send the dummy data to refresh the FIFO, right?

Hi Charles

BTW, for the resetting, could you test on the EVM board for crossing check? Customer also complaint that we did not provide the Slave mode demo, can we provide an official demo for the Slave mode?

Hi Shaofeng,

Shaofeng Luo said:

Customer has already tried reseting the SSI module by calling peripheral reset, but it can not clear the Tx FIFO, there are still some previous date inside. From your side, the best way is to send the dummy data to refresh the FIFO, right?

That is correct. The best way is for the master to send out dummy clocks to the slave to clear out the FIFO. 

You can find below example demonstrates master and slave communication. 

C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\ssi_master_slave_xfer

There are a few more examples in C:\ti\TivaWare_C_Series-2.2.0.295\examples\peripherals\ssi.

Hi Charles

One more thing needed to confirm with you, customer reflected that the issue:

"what was transmitted on the TX pin was one of the very early bytes in the Tx FIFO, and just one byte, the next data is the ones from DMA."

will occur when they use

       ROM_SSIDisable(SSI2_BASE);

       ROM_SSIConfigSetExpClk(SSI2_BASE, 120000000, SSI_FRF_MOTO_MODE_1, SSI_MODE_SLAVE, 120000, 16);

       ROM_SSIEnable(SSI2_BASE);

Could you help to confirm that what the influence to the FIFO is using these codes?