SPI slave needs RTT debug connection to work

RE: SPI slave needs RTT debug connection to work

Vidar Berg — Wed, 18 Mar 2026 15:30:07 GMT

Ok thanks for confirming. I think there must be another explanation for why it is not working in your application. I still find it very strange that it works fine when the chip is in debug interface mode, but not in constant latency mode. From the cases I can recall where something worked in debug interface mode but not in low power mode, it would also work in constant latency mode. Using my test sample also confirms that the SPIS is behaving according to the specification. Suggestions for further troubleshooting: 1. Read out the peripheral registers from both projects do see if there are any differences in the configuration. 2. if possible, measure the sleep current of the nRF52840 alone to confirm that the chip stays in constant latency mode.

RE: SPI slave needs RTT debug connection to work

janR — Wed, 18 Mar 2026 12:13:20 GMT

We are using the nrfx_spis.

RE: SPI slave needs RTT debug connection to work

Vidar Berg — Wed, 18 Mar 2026 12:06:42 GMT

It should not make any difference. Which API are you using?

RE: SPI slave needs RTT debug connection to work

janR — Wed, 18 Mar 2026 12:00:23 GMT

Thanks,

I have tried the example (8030.spis_test.zip), and it works, but it is using the blocking version of the SPIS driver.

We are using the non-blocking version.

RE: SPI slave needs RTT debug connection to work

Vidar Berg — Fri, 13 Mar 2026 10:52:12 GMT

I finally got around to test this, but I did not manage to reproduce the issue where the SPIS is not even responding with DEF.

Here with CSN to CLK time set to 1 us:

And same at 0.3 us:

Setup:

- nRF52840 DK as SPI Slave

- nRF Connect SDK v3.2.1

devzone.nordicsemi.com/.../8030.spis_5F00_test.zip

RE: SPI slave needs RTT debug connection to work

janR — Tue, 10 Mar 2026 09:17:33 GMT

Thanks,

I have added a high resolution timer to the ST bootloader now, so I can set the CS to first clock pulse more accurate. It actually seems like the limit for SPIS is at about 2us. I have measured the timing more accurate when SPIS fails as well, and this is actually 1.3us.

I have tested a bit with delay at 3us now, and this seems to work fine.

1.3us works fine in ncs 2.6.0, but not in ncs 3.2.0, so something has happened.

I have tested the 3us delay on the unmodified SPI slave firmware (before requesting HFXO and constant latency mode changes was applied), and this works fine. So the problem has nothing with this do do. Only thing we see is that RTT connection resolves the problem.

RE: SPI slave needs RTT debug connection to work

Vidar Berg — Mon, 09 Mar 2026 14:01:10 GMT

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.

RE: SPI slave needs RTT debug connection to work

janR — Thu, 05 Mar 2026 12:58:48 GMT

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.

RE: SPI slave needs RTT debug connection to work

Vidar Berg — Thu, 05 Mar 2026 12:44:31 GMT

[quote userid="17713" url="~/f/nordic-q-a/127250/spi-slave-needs-rtt-debug-connection-to-work/562637"]There is no activity on MISO when SPIS fails.[/quote]

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

[quote userid="17713" url="~/f/nordic-q-a/127250/spi-slave-needs-rtt-debug-connection-to-work/562426"]bootloader on the ST is also immutable, so it can only be updated via SWI interface.[/quote]

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

RE: SPI slave needs RTT debug connection to work

janR — Thu, 05 Mar 2026 12:26:13 GMT

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.

RE: SPI slave needs RTT debug connection to work

Vidar Berg — Thu, 05 Mar 2026 07:13:05 GMT

Is the RTT logger backend disabled at this point?

[quote user="janarildroyneberg"]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.[/quote]

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

RE: SPI slave needs RTT debug connection to work

janR — Tue, 03 Mar 2026 14:18:56 GMT

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.

RE: SPI slave needs RTT debug connection to work

Vidar Berg — Tue, 03 Mar 2026 13:52:24 GMT

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?

RE: SPI slave needs RTT debug connection to work

janR — Tue, 03 Mar 2026 13:11:44 GMT

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

RE: SPI slave needs RTT debug connection to work

Vidar Berg — Tue, 03 Mar 2026 11:07:14 GMT

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.

[quote user=""]Any other workaround than delay between CS and first clock pulse?[/quote]

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