would you check SpiTimeClk2Cs, SpiTimeCs2Clk and SpiTimeCs2CS?

[rlaxortn]

i am using s32k314, s32ds RTD4.0.0.

i am testing spi communication. 

but i think it is not work well.

so would you check SpiTimeClk2Cs, SpiTimeCs2Clk and SpiTimeCs2CS?

1. what is meaning SpiTimeClk2Cs, SpiTimeCs2Clk and SpiTimeCs2CS?

2. would you check spi configure SpiTimeClk2Cs, SpiTimeCs2Clk and SpiTimeCs2CS compare with pics.

3. When controlling the CS pin of SPI communication with GPIO instead of PS0, I want to match the timing for normal SPI clock operation. How can I do this? (Communication is not working when controlled with PS0.) 

1) control cs pin by GPIO(miso data is wrong.)

2) control cs pin by PS0

4. how fix that point in spi clock?(mark part)

thanks to help

[PavelL]

Hello @rlaxortn ,

Q1: What is the meaning of SpiTimeClk2Cs, SpiTimeCs2Clk, and SpiTimeCs2Cs?
A1:

• SpiTimeCs2Clk corresponds to the CS setup time (tcssu) — the delay between CS going active and the first SPI clock edge.
• SpiTimeClk2Cs is the delay between the last SPI clock edge and CS going inactive — not explicitly specified by your device.
• SpiTimeCs2Cs is the minimum time between two consecutive CS activations — i.e., from CS going inactive to the next activation.

Q2: Would you check the SPI configuration (SpiTimeClk2Cs, SpiTimeCs2Clk, and SpiTimeCs2Cs) and compare it with the timing diagrams?
A2: The values for SpiTimeClk2Cs, SpiTimeCs2Clk, and SpiTimeCs2Cs can typically be left at 1 µs, which is safe for most devices.
However, there is a critical issue with the SpiDataShiftEdge setting — it should be set to TRAILING, because your device (BNO080) requires CPOL = 1 and CPHA = 1.

Q3: When controlling the CS pin of SPI communication with GPIO instead of PS0, I want to match the timing for normal SPI clock operation. How can I do this? (Communication is not working when controlled with PS0.)
A3: This should not be a problem if the timing is handled correctly. The recommended sequence when using GPIO for CS is:

• Pull CS LOW
• Wait for 0.5–1 µs
• Start the SPI transfer
• Wait for the transfer to complete
• Wait again for 0.5–1 µs
• Release CS HIGH

This mimics the behavior of hardware-controlled CS and ensures proper timing for the slave device.

Q3a: Controlling CS pin by GPIO results in incorrect MISO data.
A3a: This is likely caused by an incorrect SpiDataShiftEdge setting, as mentioned above. Please ensure it is set to TRAILING to match CPHA = 1.

Q3b: Controlling CS pin by PS0 (hardware-controlled)
A3b: This setup looks correct overall. The only concern is the initial CLK pulse before CS goes active. However, since this pulse occurs before CS is asserted, it should be harmless and ignored by the slave device.

Q4: How to fix the marked point in the SPI clock (unexpected pulse)?
A4: It is indeed unusual that a similar pulse appears even when CS is controlled by the LPSPI module. Please check what code is executed between pulling CS low and starting the SPI transfer. Any premature enabling of the LPSPI module or misconfigured timing parameters could cause this behavior.

Best regards,

Pavel

[rlaxortn]

@PavelL 

and when i set SpiDataShiftEdge is Tailing, source generation is pic's right side.(CPOL(1U), CPHA(1U)). and when i set SpiDataShiftEdge is Leading, source generation is pic's Left side(CPOL(1U), CPHA(1U)). 

so if i have to set CPOL =1, CPHA =1 for using BNO080, i have to set SpiDataShiftEdge is Leading, and SpiShiftClockIdleLevel is high. is it right?

[rlaxortn]

@PavelL 

hello. i respond sooo late. i did other work. 

and i did not solve spi yet..

anyway i don't know you remember your respond. 

you responded my setting(SpiDataShiftEdge) is wrong, but other person is leading is right. 

This is Post:

https://community.nxp.com/t5/S32K/how-is-set-spi-communication-mode/m-p/2117524

so, what is correct?

( i am soooo sorry, i respond so late...)