


Currently, I have configured cs-gpios in the device tree and loaded the SPI in the main function. Why is D0 (representing CS) kept high in my experimental waveform, and SCLK (D2), MOSI (D4), and MISO (D6) also behave abnormally?



Currently, I have configured cs-gpios in the device tree and loaded the SPI in the main function. Why is D0 (representing CS) kept high in my experimental waveform, and SCLK (D2), MOSI (D4), and MISO (D6) also behave abnormally?
Typically, after configuring cs-gpios in the device tree, there is no need to bind the CS pin further in the main function. However, the experimental results show that the CS pin must be bound in the main function; otherwise, neither Bluetooth initialization nor SPI transmission will succeed. If cs-gpios is configured in the device tree and the CS pin is still bound in the main function, the experimental results indicate that the CS pin is not pulled high and low as specified. Moreover, the pin bound in the main function competes with the cs-gpios configured in the device tree for control of CS, which also fails to meet the requirement of the hardware automatically pulling down CS.
Hi,
Are you testing on a nRF5340-DK?
If yes, then P0.15 is not routed to the pin header:
https://docs.nordicsemi.com/bundle/ug_nrf5340_dk/page/UG/dk/hw_drawings.html
P0.03 is a nfc pin, and must also be handled accordingly on the DK:
https://docs.nordicsemi.com/bundle/ug_nrf5340_dk/page/UG/dk/hw_nfc_if.html#d47e117
In addition, this is required in device tree to use NFC pins as generic GPIOs:
&uicr {
nfct-pins-as-gpios;
};
Kind regards,
Håkon