SPIS: last byte missing if JTAG RTT disabled, otherwise ok

[Bas van den Berg]

We are using an nRF5340 board as SPI slave to receive a 7 byte frame @500KHz bus, 250 frames/sec.

The frames contain a counter, so we can see if we missed frames and have an otherwise known content.

The problem we have is that if we use JTAG RTT to view the log on the Nordic, it works fine (we receive all

frames, none missing). Once we turn off RTT, we receive only frames with 6 bytes (instead of 7)!!

We tried:

- changing IRQ prio

- changing Peripheral (SPIS1, SPIS2, SPIS3)

Any idea what could cause this??

Update: We use CPHA 0, CPOL 0.  Our transfer, as seen on the Logic analyser:

Update2: Having the CS go active a few usec earlier (in relation to Clk/Mosi) also changes the result of the SPIS, even while it should only sample on the rising clock flanks in this case.

[Bas van den Berg]

I've discovered some more: Without RTT, the frame is shifted 2 bits!

good frame: [51 23 00 00 14 D2 EF ] 0101000100100011
  bad frame: [44 8C 00 00 53 4F ]          0100010010001100

Why the Nordic SPIS would interpret that differently with/without RTT...??

[Edvin]

Hello,

Could it be that the reason you see the two shifted bits is that when you enable the RTT it also means that you are running a debug session, which forces the HFCLK to remain turned on, while when you are not, the device is sleeping, waking up on the GPIO interrupt that is the start of your SPI signal. Then it transmits two bits before the nRF has started properly, and is able to start reading the bits?

Is your nRF currently doing anything else? (network/bluetooth related, in particular)? If not, can you try to just start the HFCLK manually to see if the behavior changes? If you are using e.g. the bluetooth stack, then you need to request it properly, or else the bluetooth stack will just shut the clock off when it is done.

Try this if you are not using the bluetooth stack:

    // Close to the top of your main() function
    NRF_CLOCK->TASKS_HFCLKSTART=1;
    while (!NRF_CLOCK->EVENTS_HFCLKSTARTED) {
        // wait
    }
    // continue with the application

Best regards,

Edvin

[Bas van den Berg]

Hello Edvin,

Thanks for your advice!

Forcing the HFCLK to ALWAYSRUN solved the issue. But the power usage will suffer i suppose.

Is there another way to stay low-power as a SPI-slave? Maybe a longer CS before the SPI clk starts?

[Edvin]

Indeed. If it is an option (something you can configure), set the CS pin a bit earlier, just so that the nRF has time to spin up the HFCLK. It doesn't need to be the CS pin either, as long as it is something that can trigger the nRF to wake up.

Best regards,

Edvin

[Bas van den Berg]

I think this issue can be marked as solved, thx!