SPI slave needs RTT debug connection to work

[janR]

Hello,

We use the nrfx spis driver for communication between a ST processor (master) and a Fanstel BT840 module (nRF52840).

We have upgraded ncs from 2.6.0 to 3.2.1 and ran into a problem. The nRF52840 must now have a debugger (RTT) connected for the SPI slave to run. There does not need to go any messages over the RTT, it only needs connection.

Problem seems same as https://devzone.nordicsemi.com/f/nordic-q-a/126835/nrf54l15-spis-needs-constlat, except for it does not help to enable constlat.

When failure is present, the spis_handler() is not called anymore.

If we add a delay between SPI CS and first clock pulse, the SPI slave works.
Currently it seems like a delay of about 18uS works, while 2uS fails.

We also observes other strange things:
- Bootloader (mcuboot) from ncs 2.6.0 makes the SPI slave works (as will happen if we do a FOTA from old ncs 2.6.0 based firmware to new 3.2.1 based firmware). After FOTA to new firmware SPI slave works. But not if we update from 3.2.1 to 3.2.1.

Is there any explanation for what is happening here?

Any other workaround than delay between CS and first clock pulse?

Regards, Jan

[Vidar Berg]

Hei Jan,

A delay of 2 us will only work if the HF clock is already running. Otherwise, you need a longer startup time (10 us should provide plenty of margin) to allow the HFINT to ramp up in time to sample the input.

When you connect the RTT viewer, the chip is put into debug interface mode, which prevents it from entering lower power saving modes. Like with constant latency sub power mode, the HFINT is forced to stay on in idle. Other peripherals, such as the UART receiver, will also keep the HF clock running while the system is idle when they are enabled.

Any other workaround than delay between CS and first clock pulse?

For battery operated devices it is generally best to extend the CS delay when possible as this results in a considerably lower sleep current (~2 ua vs ~500 uA). If you want to enable constant latency as a workaround, please to so via the nrf_sys_event_request_global_constlat()/nrf_sys_event_release_global_constlat() APIs. These are reference counted and ensures that constant latency cannot be turned off by other SDK modules. API is included in the build with CONFIG_NRF_SYS_EVENT=y.

Best regards,

Vidar

[janR]

Thanks,

We have tried the nrf_sys_event_request_global_constlat(), but this unfortunately does not change anything. SPI still fails with CS - first clock pulse at 2us.

Also tried this: https://github.com/nrfconnect/sdk-nrf/blob/85fef3ca6680d73aa1e68169cb0d45f859a43f3c/samples/peripheral/radio_test/src/main.c#L11

This also did not work.

We are using the nRF52 Fanstel module (SPI slave) to do FOTA on the ST processor, so the best solution will be to have a  fix for the nRF52, as this problem makes it impossible to update the ST firmware via FOTA. The bootloader on the ST is also immutable, so it can only be updated via SWI interface.

It is possible to update the ST firmware via SWI, but with considerable more work.

What can be the reason for nrf_sys_event_request_global_constlat() to not work?

Regards, Jan

[Vidar Berg]

I'm surprised that requesting HFXO and constant latency mode both yield the same result. With constant latency enabled, the CS delay should work down to 1 us. Since you are getting the same with HFXO enabled, I don't think the issue is that const latency mode is not enabled. Is it possible to attach with RTT after the failed DFU to capture any crash or debug information from the RTT buffer?

[janR]

We have set the log output to be on the UART. The SPI slave still fails with this, and there is no error messages in log.

We have added a log output in the spis_handler (only ".") for each time spis_handler is entered, and the only thing we see is that this disappear (spis_handler is not called anymore) when SPIS fails. No error messages are seen.

Also when the ST firmware is run normally (not in DFU mode), SPI runs flawlessly. But then we have about 18us delay between CS and first clock pulse.

SPI fails immediately or after a couple of messages when the ST enters DFU. In DFU mode the delay is 2us.

But no error messages as we can see.

[Vidar Berg]

Is the RTT logger backend disabled at this point?

janR said:

Also when the ST firmware is run normally (not in DFU mode), SPI runs flawlessly. But then we have about 18us delay between CS and first clock pulse.

Have you probed the bus lines with a logic analyzer or scope to confirm that the longer CS delay is the only difference, or are there other potentially relevant differences as well, such as longer delays between transfers? And is the SPIS clocking out anything on MISO?

The transfer from the stm will also be ignored if the semaphore is not released in time, see: https://docs.nordicsemi.com/bundle/ps_nrf52840/page/spis.html#ariaid-title4 

[janR]

RTT logging is setup this way, both when SPIS fails (RTT disconnected) and when SPIS succeeds (RTT connected):

# Logging

CONFIG_LOG=y

#CONFIG_USE_SEGGER_RTT=y

#CONFIG_LOG_BACKEND_RTT=y

CONFIG_LOG_MODE_IMMEDIATE=y

CONFIG_LOG_BACKEND_UART=y

CONFIG_UART_CONSOLE=y

CONFIG_CONSOLE=y

CONFIG_SERIAL=y

Here are some plots:

SPI fail. No debug connection:

SPI OK, RTT connected:

There is no activity on MISO when SPIS fails.

Only difference between these captures are that the first is with RTT not connected, and the last is with RTT connected.

Debug output backend is the same in both cases.

[Vidar Berg]

janR said:

There is no activity on MISO when SPIS fails.

It's probably responding with the default DEF character (0x0)

janR said:

bootloader on the ST is also immutable, so it can only be updated via SWI interface.

Had you also tried modifying the bootloader so only the CS delay is extended? That might help narrow down the problem. 

[janR]

The DEF is configured this way:

spis_config.orc = 0xaa;

spis_config.def = 0x55;

so none of these.

We have tried to extend the CS delay in the bootloader. We used 1ms since then we could use an existing timer. Then SPIS runs fine. 

[Vidar Berg]

Thanks for confirming. I have not been able to find any other reports that seem similar to what you are observing. I will continue to investigate on my end. Please let me know if there is any progress on your end.