iMX8MM, Cortex-M4, ECSPI with GPIO chipselect: how to detect when the last bit has been shifted out?

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

iMX8MM, Cortex-M4, ECSPI with GPIO chipselect: how to detect when the last bit has been shifted out?

跳至解决方案
1,133 次查看
Raal
Contributor III

Hello,

I'm using a GPIO signal for the chip select. According to the reference manual the ECSPI transfer complete interrupt shall not be used as an indicator that the last bit has been shifted out. Instead, the XCH flag should be polled, but it seems that this doesn't work - if I disable the GPIO chip select after the XCH flag goes low, the chip select is deasserted in the middle of the last byte. My question is how to reliably detect when the last bit has been shifted out without having to use delays?

Regards

0 项奖励
1 解答
1,074 次查看
Raal
Contributor III

Hello @JorgeCas 

thank you for the document, I'll check it. As I wrote, using XCH flag also doesn't work well. My current solution is as follows:
1) clear Rx FIFO
2) set SS to low
3) fill the Tx FIFO with 'n' bytes
4) poll the Rx FIFO count register until it reaches 'n'
5) set SS to high

Step #4 compares the number of receive FIFO entries against the number of entries to transmit. This way a delay is not needed. As far as I can see this works well. Can you confirm that this is a reliable way for detecting if the last bit has been shifted out?

Regards

在原帖中查看解决方案

0 项奖励
5 回复数
1,108 次查看
JorgeCas
NXP TechSupport
NXP TechSupport

Hello,

The ECSPI documentation is not fully accurate ; some bit descriptions are derivatives of earlier versions of documentation of the i.MX series. Say, really the XCH bit is cleared with some delay (non-specified) after the last data word is loaded to the shift register. Mainly this bit serves to indicate FIFO accessibility. It is possible to apply two approaches for data transfer : polling mode and DMA transfer. In polling mode - after writing data - the program holds when checking the FIFO full status.

Best regards.

0 项奖励
1,096 次查看
Raal
Contributor III

Hello @JorgeCas ,

thank you for this information. Please explain the behaviour when checking the FIFO: the FIFO is input to the shift register, so checking only the FIFO status doesn't tell if the shift register has finished. In DMA mode, I assume the issue is the same: if the DMA has run empty isn't an indicator that the shift register has finished.

Regards

0 项奖励
1,087 次查看
JorgeCas
NXP TechSupport
NXP TechSupport

Hello,

As you can see on reference manual, the TC bit does not provide a reliable indication that the transfer is complete. Under some conditions, the TC interrupt can occur before the transfer is completed. If the TC bit is used as an interrupt source, the XCH bit should be polled after the TC interrupt occurs to accurately confirm that the transfer is complete. So, to be sure the last bit has been shifted out It is needed to use the delay.

Other way to check a complete transferred data, you can fill FIFO register with zeros (or other value), and by the behavior of ECSPI, if the FIFO is not full, the port will repetitively transmit zeros until new data is written to the FIFO.

Please check the FIFO behavior on attached file to use it as a background for the process to check a complete transferred data.

Best regards.

1,075 次查看
Raal
Contributor III

Hello @JorgeCas 

thank you for the document, I'll check it. As I wrote, using XCH flag also doesn't work well. My current solution is as follows:
1) clear Rx FIFO
2) set SS to low
3) fill the Tx FIFO with 'n' bytes
4) poll the Rx FIFO count register until it reaches 'n'
5) set SS to high

Step #4 compares the number of receive FIFO entries against the number of entries to transmit. This way a delay is not needed. As far as I can see this works well. Can you confirm that this is a reliable way for detecting if the last bit has been shifted out?

Regards

0 项奖励
1,061 次查看
JorgeCas
NXP TechSupport
NXP TechSupport

Hello,

Got it, your process to check a finished transferred data seems to be ok, if you are having the expected behavior your you can do it on that way.

If you are trying to use XCH, unfortunately, because that TC behavior does not provide a reliable indication that the transfer is complete, that is why you are getting an unexpected behavior.

Best regards.