nRF52832 SPI Master

RE: nRF52832 SPI Master

Bernard Chan Lye Hock — Tue, 12 Feb 2019 00:47:44 GMT

I find that using this method to read do a sensor read apart from the 20us delay in between transfer, the receive bytes is also 2 bytes instead of 1 bytes. Although it has been declared to receive 1 byte as following. Does anyone see this and how to fix it so that I could get only 1 bytes instead of 2 bytes? Is this a Nordic bug?

nrf_drv_spi_transfer(&spi, NULL ,0, m_rx_buf, 1);

RE: nRF52832 SPI Master

GeneYap — Fri, 18 Jan 2019 09:01:07 GMT

Thanks Jared!

It helped, however I noticed there is around 20us delay in between step(1) and step(3), even I didn't insert any delay in step(2). Is it because of waiting the spi_xfer_done flag to be set in the spi_event_handler after transfer completed?

void sensor_read(uint8_t addr)
{
		spi_xfer_done = false;	
		nrf_gpio_pin_clear(SPI_SS_PIN);	
		nrf_drv_spi_transfer(&spi, &addr, 1, NULL, 0);		
		while (!spi_xfer_done){
            __WFE();}
						
		spi_xfer_done = false;		
		nrf_drv_spi_transfer(&spi, NULL ,0, m_rx_buf, 1);	
		while (!spi_xfer_done){
            __WFE();}
		nrf_gpio_pin_set(SPI_SS_PIN);
}

RE: nRF52832 SPI Master

hmolesworth — Thu, 10 Jan 2019 20:57:58 GMT

Sounds like a similar issue I had with TI AFEs; here are my notes:

// Sending Multi-Byte Commands
// The ADS1291, ADS1292, and ADS1292R serial interface decodes commands in bytes and requires 4 tCLK cycles
// to decode and execute. Therefore, when sending multi-byte commands, a 4 tCLK period must separate the end of
// one byte (or opcode) and the next.
// Assume CLK is 512 kHz, then tSDECODE (4 tCLK) is 7.8125 us. When SCLK is 16 MHz, one byte can be
// transferred in 500 ns. This byte-transfer time does not meet the tSDECODE specification; therefore, a delay must be
// inserted so the end of the second byte arrives 7.3125 us later. If SCLK is 1 MHz, one byte is transferred in 8 �s.
// Because this transfer time exceeds the tSDECODE specification, the processor can send subsequent bytes without
// delay. In this later scenario, the serial port can be programmed to move from single-byte transfer per cycle to
// multiple bytes.

Assuming the issue is similar the byte transfer time is what matters, not the individual SCK cycles and so using (say) a clock of 500kHz is a quick workaround for such as an ADS1292. If the device in question really cannot tolerate any edge on SCK then this suggestion won't be much help unless you tolerate a very slow clock period in which case DMA helps.

RE: nRF52832 SPI Master

natersoz — Thu, 10 Jan 2019 14:30:15 GMT

You will need to manipulate the SS (slave select - NCS in your diagram) externally and not give control to the SPIM driver.

RE: nRF52832 SPI Master

awneil — Thu, 10 Jan 2019 14:14:30 GMT

Sounds a bit odd - what sensor is it?

How to properly post source code:

RE: nRF52832 SPI Master

Jared — Thu, 10 Jan 2019 13:56:48 GMT

Hi,

You can try this:

Transmit the data with nrf_driver_spi_transfer() and pass a NULL to the receive buffer.
Insert the delay
Receive the data with nrf_driver_spi_transfer() and pass a NULL to the transmit buffer.

Chip select should be held low the entire time, the clock signal will only tick when data is exchanged.

Best regards

Jared

RE: nRF52832 SPI Master

GeneYap — Thu, 10 Jan 2019 07:22:39 GMT

The sensor need some time before it could response to an incoming address.