RE: nrf9160 SPI reading problems

frax84 — Wed, 13 May 2020 12:55:46 GMT

Hi Kennet,

thank you for your answer. Going in order:

[quote userid="2111" url="~/f/nordic-q-a/61196/nrf9160-spi-reading-problems/249308"]This is somewhat similar to this case:
https://devzone.nordicsemi.com/f/nordic-q-a/60531/clarification-about-spim---ss-pin-management-for-nrf9160[/quote]

I well know this post, considering i'm the one who wrote it 🙂

[quote userid="2111" url="~/f/nordic-q-a/61196/nrf9160-spi-reading-problems/249308"]so getting a trace is a good next step. [/quote]

My bad for not being totally clear about this. I have no logic analyzer, but i'm using a digital oscilloscope, so i'm confident that signals are going.

Purpose of the ticket was being sure that i had no code issues. By the way, taking my time to perform some "trial and error" test i'm able to address most of my questions now. Leaving the answers here for the purpose of sharing:

[quote userid="86927" url="~/f/nordic-q-a/61196/nrf9160-spi-reading-problems"]- Is the spi config structure correctly set or i missed anything? In particular i want to be sure that i understood CPOL and CPHA setting;[/quote]

Yes, it is set correctly. In particular, SPI_MODE_CPOL and SPI_MODE_CPHA means respectively "Set SPI CPOL = 1" and "Set SPI CPHA=1". Not setting, of course, means the opposite.

[quote userid="86927" url="~/f/nordic-q-a/61196/nrf9160-spi-reading-problems"]- What about the "slave" element of spi config structure? I have 1 slave so i suppose i had to set it to 1, but is it really necessary?[/quote]

Seems not. I didn't find any problem in changing slave from 0 to 1 and back. I don't know what's the purpose. Maybe Kenneth can make clear this point?

[quote userid="86927" url="~/f/nordic-q-a/61196/nrf9160-spi-reading-problems"]I'm having hard time getting a full grasp about "spi_buf" and "spi_buf_set" structure. While is intuitive understanding why "spi_buf" is structured like this, i don't understand why "spi_buf_set" has a "count" element. Why should i set an array or spi_buf struct?[/quote]

It can be generally useful when using multi slave. My bad for not thinking enough...

[quote userid="86927" url="~/f/nordic-q-a/61196/nrf9160-spi-reading-problems"] Is, in general, the flow described in the above picture reproduced by my code or i am missing anything?[/quote]

This is a critical point. No, the code i described doesn't work. This is the correct code:

int spi_dev_read(struct device * spi_dev, const struct spi_config * spi_cfg, 
                                                          u8_t reg_addr, u8_t * rx_data) {
  
  int err=0;
  
  //create the tx and rx buffer
  u8_t tx_buf[1]={SPI_READ_REGISTER|reg_addr};
  u8_t rx_buf[2];

  const struct spi_buf spi_tx_buf = {
	.buf = tx_buf,
	.len = sizeof(tx_buf),
  };
  const struct spi_buf_set tx = {
	.buffers = &spi_tx_buf,
	.count = 1,
  };

  const struct spi_buf spi_rx_buf = {
	.buf = rx_buf,
	.len = sizeof(rx_buf),
  };
  const struct spi_buf_set rx = {
	.buffers = &spi_rx_buf,
	.count = 1,
  };
  err = spi_transceive(spi_dev, spi_cfg,&tx, &rx);
  *rx_data = rx_buf[1];  //first byte is dummy, second one is the correct result
  return err;
}

Please note that this time i used transreceive and not spi_write + spi_read. This is because when used the spi_cs_control structure as pointed here both spi_write and spi_read pull low (at the beginning) and high (at the end) of the function at the end of the function, while many spi devices want that write (register address) and read (register value) happen in the same transaction. This can be obtained even using SPI_HOLD_ON_CS option, but i think is more efficient this way.

I'm leaving the ticket open for further comments of Kenneth. I will close it in a few days if no comment come.

Best,

Francesco

RE: nrf9160 SPI reading problems

Kenneth — Mon, 11 May 2020 20:37:28 GMT

Hi,

This is somewhat similar to this case:
https://devzone.nordicsemi.com/f/nordic-q-a/60531/clarification-about-spim---ss-pin-management-for-nrf9160

To be able to debug this further you will need an logic analyzer trace, I can highly recommend https://www.saleae.com/, then you can observe all data pins and see exactly how the configuration will change the transfer. You can also upload the trace for us to open here. At the moment the problem may be anything (even electrical), so getting a trace is a good next step.

Best regards,
Kenneth