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

[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.

[janR]

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.