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