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

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

[Vidar Berg]

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

8030.spis_test.zip

[janR]

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.

[Vidar Berg]

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

[janR]

We are using the nrfx_spis.

[Vidar Berg]

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.