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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

Jump to solution
1,597 Views
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 Kudos
Reply
1 Solution
1,538 Views
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

View solution in original post

0 Kudos
Reply
5 Replies
1,572 Views
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 Kudos
Reply
1,560 Views
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 Kudos
Reply
1,551 Views
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,539 Views
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 Kudos
Reply
1,525 Views
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.