Can't seem to get SPI pinctrl to work (SDK 1.8.0)

RE: Can't seem to get SPI pinctrl to work (SDK 1.8.0)

Jake — Wed, 23 Oct 2024 13:35:47 GMT

Hi Edvin,

Good question, I haven't tried interacting with the pin before doing SPI, but I do know that it is low until the first transaction.

We've discovered a hack that we're going to use until we can get our SDK upgraded: the MOSI pin remains low if the final bit of the last SPI transaction is 0. This didn't work when I tried it previously because we had both CPHA and CPOL set, without those the hack works. We're sending a byte 0 with no CS when we want MOSI to go low now.

Many thanks

RE: Can't seem to get SPI pinctrl to work (SDK 1.8.0)

Edvin — Tue, 22 Oct 2024 13:34:18 GMT

Are you able to control the pin if you don't use it for SPI first? If so, is it possible to upload your current application, then I can have a look. (Or a strip down version of the application, that replicates the issue).

Best regards,

Edvin

RE: Can't seem to get SPI pinctrl to work (SDK 1.8.0)

Jake — Mon, 21 Oct 2024 16:37:51 GMT

Re:pm, I admit I didn't check for errors from pm_device_state_set, but the pin wasn't released for me to use as GPIO. It may have silently complained about no sleep configuration being available.

Yes, we have tried precisely gpio_pin_configure as DISCONNECT, INPUT as you suggest, or even OUTPUT followed by being set to 0. None of the options take control of the pin, it remains under control of the SPI driver.

There is an spi_release function which sounds like it might've helped, but the description in the definition makes clear that it's related to something else. We tried it anyway in comination with the 3 options above, none worked.

We just cannot find a way of getting SPI to let go of the pins so we can use simple GPIO!

Any more ideas?

Many thanks

RE: Can't seem to get SPI pinctrl to work (SDK 1.8.0)

Edvin — Mon, 21 Oct 2024 13:38:38 GMT

[quote user="qTelec"]I've tried using pm but it seems to have no effect without pinctrl in place,[/quote]

Does that mean you managed to disable the SPI? Or did it print some error to the log?

When you have done this, how did you try to control the pin? (I am sorry for not providing you a step by step guide, but I didn't start working with NCS much before 2.0.0, so I am not quite sure. I would say that instead of putting it to output low, you should set the pin as a disconnected input pin, which is the default pin state on the chip before it is initialized to do something.

You could try:

 gpio_pin_configure(led, LED0_GPIO_PIN, LED0_GPIO_FLAGS);

(fetched from the ncs\bootloader\mcuboot\zephyr\main.c)

but obviously change the pin number and LED0_GPIO_FLAGS. Try either setting it to: GPIO_DISCONNECTED or GPIO_INPUT.

Best regards,

Edvin

RE: Can't seem to get SPI pinctrl to work (SDK 1.8.0)

Jake — Mon, 21 Oct 2024 09:20:25 GMT

Thanks for confirming.

Yes, we're powering down our peripheral by completely removing the power, so the MOSI line being high means that it's indicentally half-powering the chip and causing a significant current leak. We would like all pins to be low.

How do I disable SPI to release these pins like you mention? I've tried using pm but it seems to have no effect without pinctrl in place, and there seems to be no way of uninitialising the SPI driver before I force the pin low with GPIO (it has no effect). I've tried a few other things but cannot seem to override this pin state at all.

The pins are in a good state after boot until the first SPI transaction happens. Is there a known working way of undoing what my first spi_write is doing to the SPI pins?

Many thanks

RE: Can't seem to get SPI pinctrl to work (SDK 1.8.0)

Edvin — Fri, 18 Oct 2024 21:20:00 GMT

Hello,

The pinctrl is not working in NCS v1.8.0. Only from v2.0.0 and onwards, so that is why you have a hard time to get it working.

Is the state of the MOSI pin between transactions actually causing any issues? It shouldn't really matter.

If you do, however want to control this pin, you need to disable the SPI, and then control the pin "normally" when it is no longer being controlled by the SPI.

Best regards,

Edvin