nRF52832 SPI Master

[GeneYap]

Hi,

I'm facing an issue when communicating to a sensor using Nordic SPI master. The sensor requires nRF52832 to have 2us delay after first byte (address) is transmitted before receive byte (data) from the sensor. Is there any way to insert the 2us delay given Nordic's SPI Master has only continuous SPI clock input? 

Here is my source code and I couldn't find a way to insert the 2us delay between the address and data. Any other workaround is appreciated as well. Thanks. 

uint8_t spi_read ( uint8_t addr)
{
memset(m_rx_buf, 0, m_length); // Reset rx buffer and transfer done flag
spi_xfer_done = false;

nrf_drv_spi_transfer(&spi, &addr, 2, m_rx_buf, 2);

while (!spi_xfer_done)
{
__WFE();
}

return m_rx_buf[1];
}

[GeneYap]

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

[Jared]

Hi,

You can try this:

1. Transmit the data with nrf_driver_spi_transfer()  and pass a NULL to the receive buffer.
2. Insert the delay 
3. 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 

[awneil]

Sounds a bit odd - what sensor is it?

How to properly post source code:

[natersoz]

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

[hmolesworth]

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.