nRF9160 MOSI idle state depending on last byte sent

[Alexander Lopatin]

Hello,

we are currently experiencing issues with the SPI interface which we suspect is due to the behaviour of the MOSI line in idle state. We have noticed that during communication the last byte of a message decides at which level the MOSI line will stay in the next idle cycle (not affected by ORC). From what we have seen so far a leading 1 of the last byte (>=0x80) leads to the MOSI line staying HIGH whilst a leading 0 (<0x80) leads to an idle LOW state. 

We suspect that due to this behaviour our SPI connected device crashes when a special command is triggered. To be more precise: If MOSI idle state switches during a sequence of messages out SPI device crashes and we have to reset our system.

This issue seems closely related to: https://devzone.nordicsemi.com/f/nordic-q-a/41266/nrf52832-why-does-mosi-stay-high-after-transmitting-any-byte-7f and https://devzone.nordicsemi.com/f/nordic-q-a/77430/why-does-mosi-stay-high-afther-sending-last-byte-with-a-value-higher-than-decimal-127-binear-0111-1111 

I assume that this issue is still present. Is there maybe a way we can force MOSI into a defined state to check if that is really the issue at hand? We have tried adding a pull-up/pull-down resistor but MOSI seems to be actively driven to a certain state. We have also tried using SPI_0 through to SPI_3 without any success. All of them show this kind of behaviour.

To visualize the issue at hand here are a couple examples:

MOSI ending with 0xAF leads to a HIGH idle state.

MOSI ending with 0x02 leads to a LOW idle state

[Kenneth]

Likely your observation is correct, as mentioned in the post by Stian in one of your links; it should not matter the logic level of the MOSI as long as there is no more CLK. If the state is important I think the best you can do is after deasserting CSN is to disable the SPIM, this should leave pins fall back to GPIO configuration (e.g. with pull if they are set as input with pull).

Kenneth

[Alexander Lopatin]

Hey Kenneth,

sorry for the late answer. We want to make sure that this is the origin of our problem. Our driver is currently running with Zephyr's SPI API. I do not think that it is possible to uninitialize Zephyr's SPI driver so I will probably have to uninitialize through NRFX drivers, if I understand that correctly.

I've tried using nrfx_spim_uninit which leads to Zephyr crashing with a bus fault.

I have also tried setting the registers directly. That unfortunately had no effect on the idle state of MOSI:

static void spi_disable() {
    NRF_SPIM2_NS->TASKS_STOP = 1;
    NRF_SPIM2_NS->ENABLE = 0;
    NRF_P0_NS->OUTCLR = (1 << 10);
    NRF_P0_NS->OUTCLR = (1 << 11);
}

static void spi_enable() {
    NRF_SPIM2_NS->ENABLE = 7;
}

Can you maybe help me out on how to achieve what you have discribed?

Thanks in advance!

[Kenneth]

Alexander Lopatin said:

do not think that it is possible to uninitialize Zephyr's SPI driver so I will probably have to uninitialize through NRFX drivers, if I understand that correctly.

Unfortunately you can't mix zephyr spi api with low level use of nrfx_spi and/or direct spi register access no. So if you want more low level control you need to use the nrfx_spi directly, hopefully this example may be to some help: https://devzone.nordicsemi.com/f/nordic-q-a/66488/using-spi-with-ppi-in-zephyr/272139#272139 

[Alexander Lopatin]

Thanks for the quick answer. Is it possible to use the power manager to uninitialize SPI? The other solution would unfortunately break our current driver architecture as it strongly relies on Zephyr's API's and device tree model. That would take substantial rework to implement.

[Kenneth]

Maybe, you can also possible look into manipulating the nrfx_spim driver if you want it to behave in a specific way:
https://github.com/nrfconnect/sdk-hal_nordic/blob/main/nrfx/drivers/src/nrfx_spim.c#L430
https://github.com/nrfconnect/sdk-hal_nordic/blob/main/nrfx/drivers/src/nrfx_spim.c#L502 

Kenneth