Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SPI master timings

Hi

I modified the SPI master example to read an 16-bit ADC at 44.1 kHz.

While the HAL_TIMER achieves its ~22 microseconds quite good, the SPI driver is quite slow: the CS pin stays low for 7.5 us for a 8 MHz transfer of ca 2 us (see picture). Do I have a possibility to optimize that?

And I don't know if it's related: when I reduce the timer to 20 us, just after starting up it works fine (the toggles on the 'TIMER' channel have ca 19.9 us):

But after 28 ms it changes and I get the following shapes, as if the time did get some delay and has to catch up (total time of an ON-OFF toggle is 38.8 us):

Is the 20 us value a limit for this application?

Thanks,

Sébastien

  • So there are two questions here?

    1. Why is the CSN chip low for so long? This is probably, at least partly, due to the SPI driver in the SDK. The CSN pin is not automatically controlled by HW, but is controlled by SW in the driver. It seems a bit weird that it would stay low that long though. 
    2. You have configured the timer to generate a waveform with a period of 20us, but then it suddenly changes to 38us? Is that correct?

    Is this nRF52832?
    Are you using a Softdevice?
    What timer are you using?
    Can you upload your code so I can test it?

  • That's right! Two question, but perhaps related :-) So I start with #2

    Yes it's nRF52832

    No Softdevice for the moment, but my next step will be adding S132 for remote purposes

    I use the HAL timer (controlled by nrf_drv_timer)

    Code:

    Hope it works... Thanks in advance.

    Sébastien

  • Hi,

    It worked like a charm and I managed to reproduce it:

    You can see how after ~40-60ms things start going haywire. The problem seems to go away if you slow down the timings, and  disappears entirely if you remove __WFE() from your main loop, but obviously that is not a viable fix. This made me think of erratum 108: RAM content cannot be trusted upon waking up from System ON Idle or System OFF mode, but it doesn't quite fit these symptoms. I'm going to need a couple more days to debug this.

     

  • I'm thrilled to learn more about this issue!

  • Hi, I just thought I'd let you know I'm still working on this. It's a very weird issue, and I need to involve some experts. 

1 2