SPI api issues

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 21:20:00 GMT

Phew - good news!

RE: SPI api issues

Meh — Wed, 15 Nov 2023 20:55:51 GMT

You were right! It looks like i need to shift all the addresses 1 bit to the left!

Thank you so much :)

RE: SPI api issues

Meh — Wed, 15 Nov 2023 19:36:57 GMT

I tried at 1MHz (all the things you saw here) - I sampled it at 4MHz due to Nyquist law

Edit:

Reduced CLK to 500kHz for the sake of the attempt. I get a similar example to before:

LOGGER:

The sampling rate of the logic analyzer - 4MHz, CLK sample 0.5MHz.

DTS:

&pinctrl {

    spi3_default: spi3_default {
		group1 {
                nordic,drive-mode = <NRF_DRIVE_H0H1>;
		};
	};
   };

   &arduino_spi {
       foo: foo@0 {
           compatible = "adi,adxl345";
           reg = <0>;
           spi-max-frequency = <500000>;
           label = "FOO";

       };
   };

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 17:46:23 GMT

Looks like gpio1 is ok but only at 1MHz; if you want to use 8 or 16MHz then P1 will not work.

RE: SPI api issues

Meh — Wed, 15 Nov 2023 17:03:16 GMT

So should I use spi3 even it uses pins from gpio1?

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 15:37:00 GMT

I would revert to the pre-pin overlay change as I now think that was working with port P1 pins and returning a value of 0x0000 which was the correct value for the command used 0x0008>>1=0x0004=INT_STATUS_TC1

Edit: This graph posted earlier shows that MISO was correctly driven low after the first 16 clock cycles to return the value of 0x0000 for that INT_STATUS_TC1 commmand

RE: SPI api issues

Meh — Wed, 15 Nov 2023 13:48:26 GMT

It's not it

I cleaned my nrf52840 overlay to this:

&pinctrl {

    spi2_default: spi2_default {
		group1 {
                nordic,drive-mode = <NRF_DRIVE_H0H1>;
		};
	};
   };
   
   



   &spi2 {
    status = "okay";
    cs-gpios = < &gpio0 11 0 >;
       foo: foo@0 {
           compatible = "adi,adxl345";
           reg = <0>;
           spi-max-frequency = <1000000>;
        //    duplex = < 0 >;
        //    frame-format = < 0 >;
           label = "FOO";

       };
   };

The output signals are:

(The small CS bump is on reset)

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 06:06:06 GMT

Ah, slightly silly but we are forgetting the ~Rd/Wr bit is the lsb so the command/address CHIP_ID 0x0008 is left-shifted 1 bit <sigh>. Try this (0x0010):

	tx_dat[0]  = 0x00;
	tx_dat[1]  = 0x10;

INT_STATUS_TC1 0x0004 will indeed return a reset value of 0x0000

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 05:15:27 GMT

Maybe post a link to the shield schematic/circuit diagram you are using; seems like there is a hardware issue here. The Analog Devices shield requires some resistors moving for SPI, not sure about others.

RE: SPI api issues

Meh — Wed, 15 Nov 2023 01:59:30 GMT

I connected the shield with jumpers, now using spi2 instead of the arudino_spi.

This is my overlay rn. I verified all the connections with the devicetree overlay.

&pinctrl {

    spi2_default: spi2_default {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,
				<NRF_PSEL(SPIM_MOSI, 0, 20)>,
				<NRF_PSEL(SPIM_MISO, 0, 21)>;
                nordic,drive-mode = <NRF_DRIVE_H0H1>;
		};
	};

	spi2_sleep: spi2_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,
				<NRF_PSEL(SPIM_MOSI, 0, 20)>,
				<NRF_PSEL(SPIM_MISO, 0, 21)>;
			low-power-enable;
		};
	};

   };
   
   



   &spi2 {
    status = "okay";
    cs-gpios = < &gpio0 11 0 >;
       foo: foo@0 {
           compatible = "adi,adxl345";
           reg = <0>;
           spi-max-frequency = <1000000>;
        //    duplex = < 0 >;
        //    frame-format = < 0 >;
           label = "FOO";

       };
   };

Yet my logic signals are:

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 01:02:01 GMT

I would just patch 3 High-Drive P0 pins across for MOSI, /CS and SCLK, though SCLK is usually the main culprit; leave the existing weak P1 port pins in default input mode so you don't have to cut them. Interesting the board would label P1 pins as SPI, if that is what Nordic did

RE: SPI api issues

Meh — Wed, 15 Nov 2023 00:56:16 GMT

So, should I manually connect between the shield and the DK to use the sensor?

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 00:55:05 GMT

Ah, those pins are too weak for SPI; check the manual 7.1 Pin Assignments for pins which are not "Standard Drive I/O only" - typically use P0

38 P1.15 Digital I/O General purpose I/O Standard drive, low frequency I/O only

RE: SPI api issues

Meh — Wed, 15 Nov 2023 00:48:52 GMT

My pinctrl overlay changes:

   &pinctrl {
    spi3_default: spi3_default {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 1, 15)>,
				<NRF_PSEL(SPIM_MISO, 1, 14)>,
				<NRF_PSEL(SPIM_MOSI, 1, 13)>;
                nordic,drive-mode = <NRF_DRIVE_H0H1>;
		};
		
	};

	spi3_sleep: spi3_sleep {
		group1 {
			psels = <NRF_PSEL(SPIM_SCK, 1, 15)>,
				<NRF_PSEL(SPIM_MISO, 1, 14)>,
				<NRF_PSEL(SPIM_MOSI, 1, 13)>;
			low-power-enable;
		};
	};
   };

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 00:44:12 GMT

Can you set a breakpoint after the transmit and check the pins for H0H1? I assume the pins are available as H0H1, ie on P0 not P1

RE: SPI api issues

Meh — Wed, 15 Nov 2023 00:40:35 GMT

I added it according to this link yet it doesn't appear to change anything

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 00:39:36 GMT

The last link discusses this, but I'm not using nRFConnect so not sure; you could still add the configuration after the init using SDK code ..

RE: SPI api issues

Meh — Wed, 15 Nov 2023 00:36:51 GMT

NCS v2.2

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 00:36:05 GMT

Is this SDK 17 or nRF Connect SDK?

how-to-define-spi-outputs-as-highdrive-h0h1-outputs-in-a-overlay-file

RE: SPI api issues

Meh — Wed, 15 Nov 2023 00:33:28 GMT

Should I add it on the overlay inside the spi3 instance?

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 00:29:14 GMT

Have a look at this: spi-communication-issue-software-problem

To clarify: The waveforms in real life are not clean as your logic analyser shows; the trace looks like square edges on the display but a 24MHz-capable SPI Slave sees slow edges and slight jitter in the real waveform as additional edges. H0H1 reduces the effect.

RE: SPI api issues

Meh — Wed, 15 Nov 2023 00:18:13 GMT

uint16_t foo_SPI_Receive(uint8_t *pTxData, uint8_t *pRxData, uint16_t TxSize, uint16_t RxSize)
{
    int ret = 0;

const struct spi_buf tx_buf = {
      .buf = pTxData,
      .len = TxSize,
  };
  LOG_INF("address being addressed is 0x%x%x\n", pTxData[0], pTxData[1]);
  const struct spi_buf_set tx_buff = {
      .buffers = &tx_buf,
      .count = 1,
  };

  const struct spi_buf rx_buf = {
      .buf = pRxData,
      .len = RxSize,
  };
  const struct spi_buf_set rx_buff = {
      .buffers = &rx_buf,
      .count = 1,
  };


  ret = spi_transceive_dt(&dev_spi, &tx_buff, &rx_buff);
  if (ret != 0)
  {
    LOG_ERR("SPI receive failed with error %d", ret);
    return ret;
  }
  return ADI_ADPD_DRV_SUCCESS;
}

[quote userid="65515" url="~/f/nordic-q-a/105588/spi-api-issues/455658"]does boosting the drive level get anything on MISO[/quote]

Can you clarify your intention here?

I doubled the LA sampling frequency to 8MHz now when the physical and software setups are alike.

1st operation

2nd

3rd

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 00:17:02 GMT

Sorry, I meant foo_SPI_Receive()

I see you do 2 transactions, 16-bit tx then further 16-bit tx to get the 16-bit receive, should work though .. does boosting the drive level get anything on MISO?

The logic analyser hides the soggy signals, whereas an oscilloscope shows the soggy edges and slow rise and fall times; that's why it's alwaays worth setting H0H1

RE: SPI api issues

Meh — Wed, 15 Nov 2023 00:02:40 GMT

WDYM?

My clock is 1Mhz exactly, haha.

Edit to respond to your edit @hmolesworth :

uint16_t foo_SPI_Transmit(uint8_t *pData, uint16_t Size)
{
  int ret = 0;
  const struct spi_buf tx_buf = {
      .buf = pData,
      .len = Size,
  };
  const struct spi_buf_set tx_buff = {
      .buffers = &tx_buf,
      .count = 1,
  };
  LOG_INF("Writing to address 0x%x%x the content: 0x%x%x\n", pData[0], pData[1], pData[2], pData[3]);
  ret = spi_transceive_dt(&dev_spi, &tx_buff, NULL);
  if (ret != 0)
  {
    LOG_ERR("SPI transmit failed with error %d", ret);
    return ret;
  }
  return ADI_ADPD_DRV_SUCCESS;
}

RE: SPI api issues

hmolesworth — Wed, 15 Nov 2023 00:01:02 GMT

Maybe boost /CS, MOSI and SCLK outputs to high-drive H0H1 either in the init or immediately after the init if clock is above 1MHz

Edit: Something funny about the clock pattern in the last trace; looks like 2 bursts of 16 clocks instead of a single burst of 32 clocks; normally the burst length is defined as the longer of tx and rx count with no gap. can you post foo_SPI_Transmit()?