MPC5xxx中的主题 Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

CNarendra — Wed, 22 Jan 2025 16:02:23 GMT

Hello,

I have a few queries regarding the SPI read function implementation. I am attempting to communicate with a slave device (MCP2518FD CAN extender) via SPI in polling mode at 16.5 MHz.

Issue:
When reading the OSC register from the slave, the expected data is 0x60040000. Upon probing with an oscilloscope, the data on the SPI bus is correct (0x60040000). However, during the software read operation, the data observed in the debugger appears as 0x00600400 instead of the expected 0x60040000. The first byte is always received as zero during the read operation.

Scope Data below is 0x60040000

Debugger window of received data(0x00600400)

Modified Code:
To address this, I modified the code to perform a dummy read for flushing the RX FIFO immediately after writing the dummy data into the PUSH.R register. This modification resolves the issue, and the read operation now works as intended. kindly check below one

Additional Observations:

Interestingly, other slaves like FRAM and FLASH work fine without requiring the dummy read to flush the RX FIFO placement. After applying the dummy flush placement modification, these other slaves continue to work correctly without any issues, while the MCP2518FD slave now works as expected.

Question:
Is performing a dummy read to flush the RX FIFO immediately after writing dummy data into the PUSH.R register the correct approach? Are there any alternative or recommended ways to handle this scenario?

Looking forward to your guidance.

Thanks & Regards

Narendra C

@PetrS ,#MPC5674F ,#MPC5xxx

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

PetrS — Thu, 23 Jan 2025 12:19:28 GMT

Hi,

you can check SR register to know how many entries are in RX FIFO.
RXFIFO can flushed using MCR[CLR_RXF].
Also do not use instantiation (.B) for flags clearing, to avoid other flags clearing too. Check chapter 3.2 of https://www.nxp.com/docs/en/engineering-bulletin/EB758.pdf for more info.

BR, Petr

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

CNarendra — Fri, 21 Feb 2025 19:07:57 GMT

Hi @PetrS,

I have observed that I am only able to see 1 RXFIFO in the SR.RXCTR flag.

I have attempted to flush the RXFIFO using the MCR[CLR_RXF] bit and cleared the relevant flags as shown in the code below without instantiation.

Previously, I hadn’t checked below 16.5 MHz, but after doing so, I can confirm that the SPI read fails to work at frequencies below 16.5 MHz, even after performing the dummy read (for flushing) after the clock cycle and clearing the CLR_RXF bit.

To provide more context, there is no issue when communicating with other slaves, such as FRAM or FLASH, across different frequencies. However, when communicating with the CAN Extender MCP2518FD, the SPI read fails below 16.5 MHz.

I would appreciate any insights or suggestions you might have on resolving this issue.

/** * * @name spi_read * * @brief Reads a sequence of bytes from the SPI interface. The function * supports both polling and interrupt modes. In polling mode, it * waits for the read transfer to complete before returning * * * @Param p_spi_config - Pointer to the SPI configuration structure. * @Param p_rx_buffer - Buffer to store the received data. * @Param num_bytes - Number of bytes to read from the SPI interface. * * @return spi_status_enum_t - Status of the SPI operation (eSPI_SUCCESS, * eSPI_ERROR). * */ spi_status_enum_t spi_read(const spi_config_t *p_spi_config, uint8_t *p_rx_buffer, uint16_t num_bytes) { uint16_t pos = 0; uint8_t dummy; spi_status_enum_t status = eSPI_ERROR; // assign with error // Read if the SPI configuration, transmit buffer, and byte count are valid if ((NULL != p_spi_config) && (NULL != p_rx_buffer) && (num_bytes > 0)) { // Clear any residual data in the rx fifo // dummy = SPI_READ_DATA(p_spi_config->port); // Clear RFDF Receive FIFO Drain Flag // SPI_CLEAR_RX_FIFO_DRAIN_FLAG(p_spi_config->port); // polling mode if (p_spi_config->mode == eSPI_POLLING_MODE) { status = eSPI_SUCCESS; // Assume success unless error occurs for (pos = 0; pos < num_bytes; pos++) { // write data for clock SPI_WRITE_DUMMY_DATA(p_spi_config->port); // flush rx register ,CLR_RXF is 21st bit p_spi_config->port->MCR.R |= (1 << (31 - 21)); // wait for Receive FIFO Drain Flag. // The bit is set while the RX FIFO is not empty while(!(p_spi_config->port->SR.R & (1u << (31 - 14)))) { } // store into buffer p_rx_buffer[pos] = SPI_READ_DATA(p_spi_config->port); // clear RFDF flag , RFDF is 14 th bit p_spi_config->port->SR.R |= (1u << (31 - 14)); } } else // interrupt mode { // Initialize the SPI reception spi_interrupt_buffer.p_rx_buffer = p_rx_buffer; spi_interrupt_buffer.rx_length = num_bytes; spi_interrupt_buffer.rx_pos = 0; // spi_interrupt_buffer.port = p_spi_config->port; // send dummy message to invoke interrupt SPI_WRITE_DUMMY_DATA(p_spi_config->port); dummy = SPI_READ_DATA(p_spi_config->port); // Enable RX FIFO Drain Interrupt SPI_ENABLE_RX_FIFO_DRAIN_INT(p_spi_config->port); status = eSPI_SUCCESS; // Interrupt mode assumed successful } } // returns spi communication status return status; }

Thanks & Regards
Narendra.C

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

davidtosenovjan — Mon, 24 Feb 2025 08:44:50 GMT

Hi, Petr is currently on vacation.

In my opinion, there is no need to clear the RXFIFO counter during operation and always having PUSH/POP pairs is the right approach.

I would recommend checking the timing requirements of the SPI slave device in question to confirm that the settings match.

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

CNarendra — Mon, 24 Feb 2025 10:38:09 GMT

Hi @davidtosenovjan

Should I check the Tcs2sck and Tsck2cs parameters, or are there other parameters I should consider in SPI timings? . Kindly look at attachment of slave datasheet MCP2518FD DS.book

Thanks

Narendra C.

,#SPI

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

CNarendra — Tue, 25 Feb 2025 10:34:37 GMT

Hi @davidtosenovjan @PetrS

We tried adding a delay between chip select and clock, but it didn't resolve the issue. Could you provide some inputs on this?

Thanks & Regards,
Narendra.C

,#SPI

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

davidtosenovjan — Wed, 26 Feb 2025 13:40:04 GMT

Have you measured all four lines of SPI communication i.e. MISO, MOSI, CLK and CS?

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

CNarendra — Thu, 27 Feb 2025 17:23:58 GMT

Hi @davidtosenovjan @PetrS,

We captured SPI signals at different frequencies and attempted to read various registers, including the 32-bit OSC and 32-bit C1CON (0x000) registers. We found the C1CON register particularly useful for analysis, as all bytes have some values.

We have set a delay between frame-to-frame using the PDT and DT parameters. We observed a noticeable difference in the delay between frames at 16.5 MHz, 8.5 MHz, and 11 MHz. While the oscilloscope shows the data correctly, the software fails to capture the one byte.

Data Expected to Receive: -0x60079804

Data on SPI Bus -0x60079804

Data received on Software below 16.5Mhz- 0x600798xy

void spi_initialize(spi_config_t *spi_config) { uint8_t i = 0; // todo: Need to Improve this function , this is very starting point // Configure GPIO pins // CLK set to Primary Function, Output and max slew rate SIU.PCR[spi_config->bus_pins.sck].R = PCR_SCK; // MISO set to Primary Function, Input, and Weak Pullup SIU.PCR[spi_config->bus_pins.miso].R = PCR_MISO; // MOSI set to Primary Function, Output, and Max Slew Rate SIU.PCR[spi_config->bus_pins.mosi].R = PCR_MOSI; // set chip select enable for (i = 0; i < MAXIMUM_SLAVES; i++) { if (spi_config->chip_select[i] != 0) { SIU.PCR[spi_config->chip_select[i]].R = GPIO_PCR_WRITE; SIU.GPDO[spi_config->chip_select[i]].B.PDO = eCS_HIGH; } } if (spi_config->write_prot.has_wr_prot) { SIU.PCR[spi_config->write_prot.wr_prot].R = GPIO_PCR_WRITE; SIU.GPDO[spi_config->write_prot.wr_prot].B.PDO = eCS_LOW; } // Stop the DSPI interface spi_config->port->MCR.B.HALT = 1; // Configure DSPI interface spi_config->port->MCR.B.MSTR = 1; // Master Mode spi_config->port->MCR.B.DIS_TXF = 1; // No TX Queue spi_config->port->MCR.B.DIS_RXF = 1; // No RX Queue spi_config->port->MCR.B.CONT_SCKE = 0; // No Continuous Clock spi_config->port->MCR.B.DCONF = 0; // SPI spi_config->port->MCR.B.MTFE = 0; // Modified Timing Disabled spi_config->port->MCR.B.PCSSE = 0; // Unused spi_config->port->MCR.B.ROOE = 1; // RX Overwrite spi_config->port->MCR.B.DOZE = 0; // No Doze spi_config->port->MCR.B.SMPL_PT = 0; // Sample Point // Configure CTAR0 (Clock and Transfer Attributes Register) spi_config->port->CTAR[0].B.DBR = 0; // No Baud Rate Doubling spi_config->port->CTAR[0].B.FMSZ = 7; // 8 Bit Frame spi_config->port->CTAR[0].B.CPHA = 0; // Capture on Rising Edge, SPI-0 Mode spi_config->port->CTAR[0].B.LSBFE = 0; // MSB First spi_config->port->CTAR[0].B.PCSSCK = 0; // PCS to SCK Delay Prescaler spi_config->port->CTAR[0].B.PASC = 0; // Last SCK to PCS delay Prescaler spi_config->port->CTAR[0].B.PDT = 1; // Frame to Frame Delay Prescaler spi_config->port->CTAR[0].B.PBR = 0; // Baud Rate Prescaler spi_config->port->CTAR[0].B.CSSCK = 0; // PCS to SCK Delay Scaler spi_config->port->CTAR[0].B.ASC = 0; // After SCK Delay Scaler spi_config->port->CTAR[0].B.DT = 1; // Frame to Frame Scaler spi_config->port->CTAR[0].B.BR = (uint8_t)(spi_config->baud_rate_scale); // Baud Rate Scalerspi_config // Calculate and verify SCK based on: // SCK = (fPeriph / PBR) * (1 + DBR) * (1 / BR) // = (132MHz / 2) *(1 + 0) *( 1 / config->baud_rate_scale) // where fPeriph is the peripheral clock frequency, typically 132MHz as per absolosence board // Enable SPI spi_config->port->MCR.B.HALT = 0; }

Command SequenceREG_C1CON(0x000)@8.5MHzREG_C1CON(0x000)@10.5MHzREG_C1CON(0x000)@16.5MHzDebug_Console@8.5MhzDebug_Console@16.5Mhz

Note: Other slaves, such as FRAM and Flash, are working fine in all frequencies

Kindly refer to the images below, along with the debug console outputs, for further inputs.

Thanks & regards

Narendra

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

CNarendra — Fri, 28 Feb 2025 04:18:21 GMT

Hi @davidtosenovjan,

I have continued debugging the issue and have been examining the DSPI Receive FIFO Registers (DSPI_x.RXFR[0].R) to track message entries in the RX FIFO. We can see all data correctly in both POPR.R and DSPI_x.RXFR[0].R. However, it appears that one byte—either the first or the last—is being overwritten in the buffer, which is causing the issue.

I am currently investigating the root cause, and I am uncertain whether this is due to compiler optimization or timing constraints from the SPI slave device.

Kindly refer to the attached files for further details.

Buffer_OverwrittenWorking one

Thanks

Narendra .C

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

CNarendra — Fri, 28 Feb 2025 07:27:48 GMT

Hi @davidtosenovjan ,

1. As part of debugging ,I added a random delay after the dummy write (for clocking), and now the read operation works correctly.

spi_status_enum_t spi_read(const spi_config_t *spi_config, volatile uint8_t *rx_buffer, uint32_t num_bytes)
{

    uint16_t pos = 0;
    uint16_t dummy;
    spi_status_enum_t spi_status = eSPI_SUCCESS;

    dummy = (uint8_t)(spi_config->port->POPR.R);

    spi_config->port->SR.B.RFDF = 1;

    if (spi_config->mode == eSPI_POLLING_MODE)
    {
        for (pos = 0; pos < num_bytes; pos++)
        {

            // write data for clock
            spi_config->port->PUSHR.R = 0x00;

            // we are adding delay 
            delay2();

           // first byte always read as 0xff . we are bypassing here
            dummy = (uint8_t)(spi_config->port->POPR.R);

            // wait for data
            while (spi_config->port->SR.B.RFDF == 0)
            {

            }

            rx_buffer[pos] = (uint8_t)(spi_config->port->POPR.R);

            spi_config->port->SR.B.RFDF = 1;

        }
    }

    return spi_status;
}


void delay2()
{
   uint64_t i = 0;
   for(i = 0 ; i < 100 ;i++)
   {
   }
}

2. However, as I mentioned earlier, if I comment out the following line:

dummy = (uint8_t)(spi_config->port->POPR.R);

the first byte always reads as 0xFF.

We are reading this 0xFF into dummy as a bypass, but the first byte consistently comes as 0xFF across all frequencies.

Kindly help us in giving inputs .This is critical one

Thanks

Narendra .C

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

davidtosenovjan — Fri, 28 Feb 2025 13:07:47 GMT

Probably the problem is that you are doing pop operation too early after push operation. Due to that probably RxFIFO underflow happens.

Looking to my example code I did in the past with using of polling method I always did it this way:

PUSH
WAIT_UNTIL_RxFIFO_IS_NOT_EMPTY;
POP

where following macro is defined
#define WAIT_UNTIL_RxFIFO_IS_NOT_EMPTY while (!(DSPI_B.SR.B.RFDF)) {}

Example code you may donwload here:
https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/Example-MPC5676R-DSPI-ext-SPI-memory-S25FL129P-CW210/ta-p/1104839

Mentioned SPI code snippets in dspi_S25FL129.c and .h

Hope it helps

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

CNarendra — Sun, 02 Mar 2025 12:48:24 GMT

Hi @davidtosenovjan , @PetrS

I have implemented the suggested changes, but the issue still persists. I also used SPI_Popr_Read_Fix for analysis. The first byte received is either 0xFF or 0x00, even though the correct data is visible in the RXFIFO (debug register DSPI_A.RXFR[0].R).

The first byte in the RX FIFO is not getting updated in DSPI_A.POPR.R (shift register). I have attached a debug screenshot for reference. While using a delay and dummy read has served as a temporary workaround, we need a permanent solution.

Kindly assist us in identifying the root cause and providing a reliable fix.

#define PPC_NOP(x) {uint8_t n = x; do{ PPCASM(" e_nop"); } while(n--);} #define SPI_DUMMY_READ_DATA() ((uint8_t)DSPI_A.POPR.R) #define SPI_WRITE_DUMMY_DATA() (DSPI_A.PUSHR.R = 0x00) #define SPI_TRANSMIT(data) \ do { \ DSPI_A.SR.B.TCF = 1; \ DSPI_A.PUSHR.R = (uint32_t)((uint8_t)(data) & 0xFF); \ while (DSPI_A.SR.B.TCF == 0); \ } while (0) #define SPI_RECEIVE(buffer) \ do { \ while (DSPI_A.SR.B.RFDF == 0); \ buffer = (uint8_t)(DSPI_A.POPR.R); \ DSPI_A.SR.B.RFDF = 1; \ } while (0) // by default we are reading only 4 byte register void MCP2518_Read_Data(CAN_DEV_LIST_t selectedDevice, uint8_t cmd, uint16_t address, uint8_t *p_rxbuffer, uint8_t length) { uint8_t i = 0; uint16_t data = 0; uint8_t spi_tx_cmd[2] = {0}; if(!p_rxbuffer) { return eSPI_ERROR; } data = ( ((cmd) << 12) | ((address) & 0xFFF) ); // pack command and address spi_tx_cmd[0] = ((data >> & 0xFF); spi_tx_cmd[1] = data; // chip select LOW MCP2518_Device_Select[selectedDevice](); // send command SPI_TRANSMIT(spi_tx_cmd[0]); // send Register Address SPI_TRANSMIT(spi_tx_cmd[1]); //1st byte SPI_WRITE_DUMMY_DATA(); if(SPI_Popr_Read_Fix) { // adding delay for fix PPC_NOP(1) // we are always receiving first byte as 0xff or 0x00 even we see // correct data in RXFIFO(debug register DSPI_A.RXFR[0].R) // but DSPI_A.POPR.R shift register value is 0x00 or 0xff // here we are reading dummy SPI_DUMMY_READ_DATA(); } SPI_RECEIVE(p_rxbuffer[0]); // 2nd byte SPI_WRITE_DUMMY_DATA(); SPI_RECEIVE(p_rxbuffer[1]); // 3rd byte SPI_WRITE_DUMMY_DATA(); SPI_RECEIVE(p_rxbuffer[2]); // 4 th byte SPI_WRITE_DUMMY_DATA(); SPI_RECEIVE(p_rxbuffer[3]); // chip select High MCP2518_Device_Deselect[selectedDevice](); }

Spi read issue

First Byte in POPR.R(shift register) is not getting updated from RXFIFO

Spi Read Working

Thanks

Narendra.C

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

davidtosenovjan — Mon, 03 Mar 2025 09:09:25 GMT

Don't use .B instance. Petr already mentioned it in the very first response (EB758). It is very important.

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

davidtosenovjan — Mon, 03 Mar 2025 09:32:24 GMT

Check status register whether you see overflow/underflow and also check whether you have enabled FIFOs.

Re: SPI Read Issue on MPC5674F: Incorrect Data Received from MCP2518FD CAN Extender

CNarendra — Thu, 22 May 2025 04:14:15 GMT

Hi,

Issue got resolved after enabling FIFO(s) in DSPI

Thanks & regards
Narendra.C