2395751_en-US

[#1]

S32K312 EVB - SD Card SPI Initialization using LPSPI Hardware PCS0

Hi,

I am implementing an SD Card driver over SPI on the S32K312 EVB using RTD 6.0.0 (Non-AUTOSAR Lpspi_ Ip driver).

According to the SD Physical Layer Simplified Specification, the SPI initialization sequence is:

1. Keep CS HIGH after power-up.
2. Generate at least 74 clock pulses (I am sending 80 clocks by transmitting 10 bytes of 0xFF).
3. Pull CS LOW.
4. Send CMD0 (0x40 00 00 00 00 95).
5. Keep CS LOW while polling with 0xFF until the card responds with **R1 = 0x01`.

My issue is with hardware-controlled PCS0.

When using the Lpspi_Ip driver with hardware PCS0, the PCS signal is automatically asserted/deasserted by the LPSPI peripheral during SPI transfers. Because of this, I cannot generate the initial 80 clock pulses while keeping CS HIGH and then CMD0 with CS LOW, as required by the SD specification.

I have the following questions:

1. Does the S32K312 LPSPI peripheral support keeping PCS inactive (HIGH) while generating SPI clocks?
2. Is there any Lpspi_Ip API, register configuration, or recommended method to manually control PCS or temporarily disable hardware PCS during the SD card initialization sequence?
3. If not, is the recommended approach to configure the SD card CS pin as a GPIO and manually control it while using LPSPI only for SCK, MOSI, and MISO?

Additionally, if NXP has any reference implementation, application note, example project, or SDK/RTD example demonstrating SD card communication over SPI on the S32K3 series, could you please share the reference?

Thank you.

Re: S32K312 EVB - SD Card SPI Initialization using LPSPI Hardware PCS0

Hi @parvathitp 

The PCS (Peripheral Chip Select) signal is designed to be controlled by the LPSPI module. When a hardware PCS is selected, it is automatically asserted and deasserted by the LPSPI peripheral during SPI frame transfers.

There is no dedicated API available to manually control a hardware PCS signal while it is assigned to the LPSPI module. Therefore, as you mentioned, the best approach for this case is to configure the CS pin as a GPIO.

In this configuration, the CS signal is controlled through the SIUL2/GPIO APIs, and you are responsible for controlling it. 

Currently, there is no S32K3-specific application note, example project, or reference document that demonstrates this exact implementation.

BR, VaneB