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

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

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

577 Views
WW1984
Contributor II

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 dataA0034E   A0034E
2nd RX dataA0034E   D00BA7
3rd RX dataA0034E   E805D3

 

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

WW1984_0-1716193256637.png

WW1984_1-1716193768507.png

WW1984_2-1716193944864.png

Thanks.

Best regards.

 

0 Kudos
Reply
10 Replies

539 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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

 

0 Kudos
Reply

491 Views
WW1984
Contributor II

Hi @danielmartynek ,

I updated CS Pin waveform.

tek00004.png

 1st Response data

2024-05-27_09h20_40.png

 2nd Response Data

2024-05-27_09h21_06.png

 

3rd Response Data

2024-05-27_09h21_21.png

Thanks,

Best regards.

0 Kudos
Reply

462 Views
danielmartynek
NXP TechSupport
NXP TechSupport

Thi is a screenshot of the first frame right?

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

 

Thanks,

Daniel

 

0 Kudos
Reply

440 Views
WW1984
Contributor II

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?
0 Kudos
Reply

408 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

349 Views
WW1984
Contributor II

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.

0 Kudos
Reply

341 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

313 Views
WW1984
Contributor II

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

0 Kudos
Reply

221 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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

0 Kudos
Reply

495 Views
WW1984
Contributor II

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.

2024-05-27_08h20_05.png

 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.

0 Kudos
Reply