SPI Master CS is on for very long & additional byte is being clocked out

[ryerye120]

Hi,

I'm using SDK5 V16 with the NRF52dk. I'm writing a SPI <-> BLE <-> USB I/O chain and am still kinda stumped by the SPI. All the examples work just fine, but when I look at the SPI packets with an oscilloscope I found some weird things:

1) CS is held low by the SPI Master for an extra 2.9+ ms? Is it possible to reduce this so that it's just low while the packet is being transmitted? In the photo below, I've sent the test string "000" so it should only be a 24-byte packet. The packet is sent (it's just blocked by the oscope cursor). Going through nrfmx_spim.c, it seems like the CS is handled through SW. This explains the delay, but the delay is pretty consistent ... almost too consistent for something handled in SW.  Is there a more HW driven solution for the SPI available?

 

2) Regardless of the packet length, the SPI Master always clocks out an extra byte of 0's. This doesn't show up on the slave though. Is this expected? CS is still low and the clock is still toggling so why aren't these being picked up? There's a comment by 'fluent' on this thread where this problem is mentioned but that's for the nRF52832 and is not mentioned in the nRF52840 errata. Here is a photo of the same packet as sent above (only I've zoomed in on the packet lol). I'm expecting 24 bits, but, 32 clock pulses are sent through.

Thanks so much for your help.

- Ryan

[Håkon Alseth]

Hi,

 

CS is held low by the SPI Master for an extra 2.9+ ms? Is it possible to reduce this so that it's just low while the packet is being transmitted? In the photo below, I've sent the test string "000" so it should only be a 24-byte packet. The packet is sent (it's just blocked by the oscope cursor). Going through nrfmx_spim.c, it seems like the CS is handled through SW. This explains the delay, but the delay is pretty consistent ... almost too consistent for something handled in SW.  Is there a more HW driven solution for the SPI available?

const char * some_string = "000"; will take up 4 bytes in memory, as strings are null terminated:

https://en.wikipedia.org/wiki/Null-terminated_string

 

Try this instead:

char array[3] = {'0', '0', '0'};

Wrt. CSN handling, you can handle that in the application if you'd like, by setting the .cs_pin member 0xFF ( define NRF_DRV_SPI_PIN_NOT_USED). Its very strange that it holds it for so long. Could you expand the timeline of the second image, so that the CSN handling includes a SPI transaction?

 

Kind regards,

Håkon 

[ryerye120]

Håkon Alseth said:

const char * some_string = "000"; will take up 4 bytes in memory, as strings are null terminated:

Of course! My C is rusty - that worked like a charm.

Håkon Alseth said:

Could you expand the timeline of the second image, so that the CSN handling includes a SPI transaction?

Here is an image of the entire transaction. This time I'm sending 520 bits so that it's a little more visible 

Looking at the hardware drivers reference for the nrf52840, it seems there's a SPIM extended configuration that has a hardware slave select option:

But this option doesn't exist in the SPI config that I'm currently using. What is the difference between SPI and SPIM? Is there a way to enable the .use_hw_ss in the SPI config?

Thanks for your help!

Ryan

[Håkon Alseth]

Hi,

 

ryerye120 said:

But this option doesn't exist in the SPI config that I'm currently using. What is the difference between SPI and SPIM? Is there a way to enable the .use_hw_ss in the SPI config?

That section is for the SPIM3, which is a higher speed SPIM module, present on nRF52840.

SPIM (on nRF52832) does not have a dedicated hardware controlled chip select. Its expected that the application handles this.

Do you by any chance have logging enabled? that might explain why it uses ~3 ms. Try setting sdk_config.h::NRF_LOG_ENABLED to 0 and recompile to see if this has any impact on execution time.

 

Kind regards,

Håkon 

[ryerye120]

Hi Hakon!

I believe it was related to printing statements out over the LOG. I removed all of my log statements and voila, I could achieve my desired 1Mbps.

Thank you so much for your help!

Kindest regards,

Ryan