SPI not transferring when sck pin not used

[JVKran]

Hi there!

I'm in the process of migrating a project from a nRF52832 to nRF52840 due to insufficient memory and of course some problems arise during the process. Most of the problems are configuration related, but I believe this one to be a bug.

When the sck_pin is set to NRF_DRV_SPI_PIN_NOT_USED, the transfer isn't completed. In fact, the pin is made high and becomes low after 1.6ms; then all nrf_drv_spi_transfer calls return NRF_ERROR_BUSY. This is the case in both, the project and the spi example in the most recent version of the SDK. What I find interesting, is that setting the sck_pin to NRF_DRV_SPI_PIN_NOT_USED works with the nRF52832 DK, but not with the nRF52840 DK.

The problem is temporarily solved by just initializing the sck_pin with a random (unused) pin. Anyway, I thought I'd raise this question to save a couple days of debugging for people who are also coping with this problem and to get to know why this is happening.

Thanks in advance,

Jochem

[awneil]

Why would you set the SCK pin as 'not used' - surely that makes no sense?!

SCK is essential to SPI.

[JVKran]

Sorry, forgot to add that I wrote a library for the WS2812 leds. Using SPI at 4MHz with DMA is a very efficient way to control these leds. Then, 4 bits represent 1 bit in the WS2812 protocol. Hence MOSI is connected straight to the DIN pin of the leds and other pins are not used nor necessary.

[awneil]

Aha - that's a key bit of information! Yes, I have done this on nRF52832; haven't tried nRF52840.

Strictly, it is using the SPI peripheral in a way it's not intended - I guess we'll have to wait for the Nordic guys to say if there's anything that can be done ...

[JVKran]

Yep, haha. I know it's kinda mis-using SPI, but still; I wouldn't expect the macro to completely prevent transactions from completing. 

At least there's a temporary fix; wouldn't be the end of the world if there isn't a proper solution.

[awneil]

Have you tried looking at (or stepping through) the code to see if there's anything obvious that's messed up by having the SCK pin as 'Not Used' ... ?

[JVKran]

Yes, I've looked at it but couldn't find anything obvious. In fact, the NRF_DRV_SPI_DEFAULT_CONFIG even has all pins (sck, mosi, miso and ss) set to NRF_DRV_SPI_PIN_NOT_USED. 

[hmolesworth]

We found that the general purpose peripheral which underlies SPIM/TWIM requires the clock signal to physically exist otherwise the internal registers are not clocked; maybe a consequence of using the same peripheral hardware to accept both internal (master) and external (slave) synchronous clock to drive the registers. Somewhere there is a note about this, but of course I don't remember where. This only applies to SCK, not MOSI and MISO. It's not  bug, it's a feature ..

[JVKran]

Oh well... That's great... Makes sense though. Just wish it would've been easier to find or using the macro on the sck_pin threw an error.

[awneil]

JVKran said:

Just wish it would've been easier to find

I guess that always the trouble with "abusing" a feature like this.

Still interesting that you got away with it on the nRF52832, though!

[JVKran]

Is it solved though? It is temporarily solved with a workaround. Wouldn't be too hard for the devs to implement a construction that throws an error when sck_pin is set to not_used. Could save people a lot of time...

[awneil]

Well, the question of why it happens is answered - so marking it would help people to find threads which answer the question?

[JVKran]

Haven't looked at it that way. Thanks. This was my first question by the way. Still a bit new all this ; ).