How to solve Rx data shift register in slave mode (S32K312 LPSPI Slave mode using AUTOSAR API)

[WW1984]

Dear Team.

I tested LPSPI slave mode using AUTOSAR API. When I setting LPSPI2 Slave mode and DMA + Half-duflex configuration, First response was correct. However, Second response is wrong.

I think the LPSPI data bit is being read from the first rising edge.
In the second response, 1 bit is shifted backward, and in the third response, 2 bits are shifted backward.

Please refer to the data table comparing my expected data and Rx data.

	Expected data						RX data (read buffer data)
1st RX data	A0	03	4E				A0	03	4E	…
2nd RX data	A0	03	4E				D0	0B	A7	…
3rd RX data	A0	03	4E				E8	05	D3	…

Is there anything that needs to be modified to solve the problem?

The image below is the SPI configuration I set up and applied Errata
- SCK Idle clock: High
- Data Shift Edge: Trailing

Thanks.

Best regards.

[danielmartynek]

Hi @WW1984,

With this configuration, the Slave device should capture the RX data on the falling edge of SCK.

And in the waveform, there is the first falling edge during the 8th bit of 0xA0 (MSB first).

Can you share the waveforms along the CS signal?

BR, Daniel

[WW1984]

Hi @danielmartynek ,

I updated CS Pin waveform.

 1st Response data

 2nd Response Data

3rd Response Data

Thanks,

Best regards.

[danielmartynek]

Thi is a screenshot of the first frame right?

How the frames (including CS) that are incorrectly received look at the oscilloscope?

Thanks,

Daniel

[WW1984]

There was no difference on incorrectly received frame.

According to my analysis, old data in shifter seemed to be append to first bit of current RX FIFO.

So I made work around to do following codes to clear old data in shifter every time RX finished.

        Base->CR |= LPSPI_CR_RST_MASK;

        Base->CR &= ~LPSPI_CR_RST_MASK;

By above codes, responses from device could be received correctly.

Could you check why old data in shifter couldn't be cleared after RX process was done?

Additionally, my work around has no risk?

[danielmartynek]

Hi @WW1984,

Can you share the project here or via a support ticket?

Please describe what data you need to received from the Master: Frame size, number of frames.

Thanks,

BR, Daniel

[WW1984]

Hi @danielmartynek ,

I shared project file base on the ISELED SDK.

Since IC specialized functions cannot be provided, we updated the sample code that performs SPI TX in the main function.

As mentioned above, the RTD driver generated code is operating normally after initializing the RST register.

Best regards.

[danielmartynek]

Hi @WW1984,

In the test project, you are calling the Spi_AsyncTransmit() functions in a while loop without checking whether the previous transfer is completed successfully or not.

Do you have the same issue with the Spi_SyncTransmit()?

Thanks

[WW1984]

Hi @danielmartynek 

In this project, LPSPI0 is master configuration that send to smart LED and LPSPI2 is slave configuration that receive data from master IC. 

When I tested Synctransmit or Asynctransmit of master channel (LPSPI0), there is no issue.

My focus is on the initialization problem of RX FIFO Shifter in Slave configuration.

Thanks.

Best regards

[danielmartynek]

Hi @WW1984,

I'm sorry for the delay, I was out of office for the last week.

I think there might be a problem with the half-duplex mode.

Can you test in the full-duplex mode with dummy TX data and MISO disconnected?

Also, the screenshot you posted does not seem to match the data you want to receive.

Thanks,

Daniel

[WW1984]

Hi, @danielmartynek,

Thanks for your reply.

I'm sorry for late response, I'm out of office at last week. 

As you mentioned, the waveform signals are 0xA0 (MSB first).

However, In the RX buffer data are incorrect at second read data.

 Since the CS pin is not used in the MASTER IC, the CS pin is asserted from the start of the main function to the end.

I will modify the logic to assert CS pin before receiving RX and share the waveform after testing.

BR, Thanks.