SPI communication with multiple CTARs (MPC577C)

[Fabio1970]

Hi,

I'm using one of the DSPI modules of the MPC5777C (acting as controller) to communicate with an external device (acting as peripheral) via SPI and am having troubles with the Rx part: although I see the expected data sent by the peripheral in one of the Receive FIFO registers available for debugging purposes (DSPI_RXFRn), it seems that they do not end up in the POP Rx FIFO Register (DSPI_POPR).

I'm using multiple CTAR registers and believe they have been set up correctly (Tx seems ok). However, I'm not sure how Rx works with multiple CTARs. My guess would be that a given "channel" would receive as many bits as those specified by the FMSZ field in its corresponding CTAR. For instance, DSPI_CTAR0.FMSZ = 0xF means that channel 0 can transmit/receive 16 bits.

- Is my assumption correct?

- Would the lower 16 bits of the DSPI_POPR hold the response from the peripheral?

Let now assume that channel 1 is configured to transmit/receive 8 bits (DSPI_CTAR1.FMSZ = 0x7). Would the LSB of the DSPI_POPR hold the response from the peripheral in this case?

Thanks for any help.

[lukaszadrapa]

Hi @Fabio1970 

the same CTAR is used for both transmit and receive operation. For example, if the frame size is set to 8 bits then you will transmit 8 bit and also receive 8 bits. If you use different CTAR for next operation then configuration from that different CTAR is used for both transmit and receive. If the receiving doesn't work even if you can see some signal on the RX pin, check the configuration of RX pin.
Maybe some examples could help. If you use SDK, you can check:
c:\NXP\S32DS_Power_v2.1\S32DS\software\S32_SDK_S32PA_RTM_3.0.3\examples\MPC5777C\driver_examples\communication\dspi_master_interrupt\

If you do not use SDK:
https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/Example-MPC5777C-DSPI-master-TX-RX-DMA-S32DS-Pow...

Regards,
Lukas

[Fabio1970]

Hi Lukas,

thank you very much for your prompt reply!

I had a deeper look into the issue and noticed that, when reading the data sent by the peripheral, the Pop Next Pointer (POPNXTPTR) field in the SR of the controller points to the wrong Rx FIFO Entry, i.e., it points to the RXFR element next to the one holding the received data. For instance, POPNXTPTR = n, indicating that the RXFR_n holds the SPI data that will be returned when reading POPR, but I can see the received data byte in RXFR_n-1. As a consequence, I always read the dummy byte sent by the peripheral, when I read from POPR.

Does that simply mean that I'm not reading the Rx FIFO at the correct time, resulting in a mismatch between the expected and actual FIFO entries, or could the issue be caused by something else?

Thanks again for any help.

Best,

Fabio

[lukaszadrapa]

Hi @Fabio1970 

yes, it looks like you read the POPR in wrong way. PUSHR and POPR should be always written/read in a pair in order to be synchronized - write PUSHR, wait for transmission is done and then read the POPR. If you follow this rule, there should be no problem with this.

Regards,
Lukas

[Fabio1970 · Accepted solution]

Hi Lukas,

thank you for your reply. You were absolutely right about keeping PUSHR/POPR synchronized.

Another issue was the debugger: entries from the RX FIFO were unintentionally removed because POPR was accidentally displayed together with other SPI registers in the Watch Window. As a consequence, POPR was constantly drained, causing the RX FIFO counter to be always equal to zero, which in turn affected the internal address calculation logic of RX FIFO entries.

To summarize, the fix was:

1. Performing paired writing/reading of PUSHR/POPR

2. Removing unintentional read accesses to POPR

Thanks again for the help!

Best,

Fabio