CLK level error after S32K148 SPI initialization

[Embedded_novice]

HI.

When I call SPI_Init in the S32K148 microcontroller, the level of the CLK signal will change from a high level to a low level. However, in the software, I have configured CLK as a GPIO push-pull output with an initial high level output. At the same time, I have made software pull-up configuration and hardware pull-up as well. Why is it that the CLK level will only return to its original state after attempting to send any data on the SPI? Could you provide me with some ideas for troubleshooting?

[VaneB]

Hi @Embedded_novice 

From what you have described, it sounds like you want to manually control the CLK pin rather than letting the SPI module manage it. Is that correct?

Could you share your current configuration so we can check if there are any incorrect or missing settings? Also, have you tried the Spi_Transfer_S32K148 to see if the behavior changes?

BR, VaneB

[Embedded_novice]

HI. @VaneB 

I don't want to manually control the CLK pin. I still hope that the CLK pin is automatically controlled by the SPI component. However, my question is that I have set the CLK pin to a high level in the idle state, and I have also configured the SPI0_CLK pin in the PORT to be a high level initially. Theoretically, the CLK pin should remain at a high level from the completion of SPI initialization until the first communication arrives. But the current phenomenon is that the CLK pin is in a low level state from the completion of SPI initialization until the first communication arrives. Here is my configuration. Please check if there is any error.

[VaneB]

Hi @Embedded_novice 

Sorry for the misunderstanding, and thank you for the clarification.

It is not strictly necessary to configure the CLK pin as high in the Port driver, since it is managed by the SPI driver.

I performed a test on my side using the S32K148EVB and the Spi_Transfer_S32K148 example. I modified the configuration so that the CLK pin is driven high by the Port driver and also set SpiShiftClockIdleLevel to HIGH. With these changes, I did not observe the behavior you described. Could you please try running the same example with these modifications and let me know if the behavior changes on your setup?