SPI operations failing on custom board versus development kit

RE: SPI operations failing on custom board versus development kit

hmolesworth — Tue, 11 Jan 2022 15:39:00 GMT

One assumes the SPI devices all share the same VCC and that their SS (/CS) lines on pins 9 and 13 are all set high; if not the issue you describe may be caused by that difference, shared VCC is particularly important. Pin 9 in particular is particularly troublesome as it is not an i/o pin by default; CONFIG_NFCT_PINS_AS_GPIOS is required to be defined in your project preprocessor settings. Probability that this is the root cause of the problem is 83%.

Ah, time to run a simple pin check test which should be at the start of main() before any SPI initialisation is done. Two sets of code, first tests that each pin is not accidentally connected to another and the second that each pin is not connected to VCC or GND. The tests rely on a datasheet mistake, namely that each i/o pin has an optional pull-up or pull-down of about 14k which can be applied regardless of whether the pin is input, output or used as a peripheral pin. Note you can write code or just manually use the debugger SPI peripheral. Using code is better because it can be incorporated as a board power-on-test (POST).

Test sequence pin cross-talk:

set MOSI, MISO, SCK, SS, SS2, SS3 to inputs with pull-down enabled
for each pin of 6 pins
  set just the 1 pin as input with pull-up enabled
  test that pin with pull-up, should be '1'
  test other 5 pins, all 3 pins should be '0'

set MOSI, MISO, SCK, SS, SS2, SS3 to inputs with pull-up enabled
for each pin of 6 pins
  set just the 1 pin as input with pull-down enabled
  test that pin with pull-down, should be '0'
  test other 5 pins, all 3 pins should be '1'

Test sequence pin shorted to VCC or GND or another pin

stuck-at-0 test
set MOSI, MISO, SCK, SS, SS2, SS3 to inputs with pull-down enabled
for each pin of 6 pins
  set just the 1 pin as output with pull-up disabled
  set that pin to '1'
  test all 6 pins, all 6 pins should be '0' except that pin which should be '1'
  set that pin to '0'
  test all 6 pins, all 6 pins should be '0'
  revert that pin to input with pull-down enabled
  
stuck-at-1 test
set MOSI, MISO, SCK, SS, SS2, SS3 to inputs with pull-up enabled
for each pin of 6 pins
  set just the 1 pin as output with pull-up disabled
  set that pin to '0'
  test all 6 pins, all 6 pins should be '1' except that pin which should be '0'
  set that pin to '1'
  test all 6 pins, all 6 pins should be '1'
  revert that pin to input with pull-up enabled

RE: SPI operations failing on custom board versus development kit

cldelahan — Tue, 11 Jan 2022 14:52:51 GMT

Talking to the hardware folks - just realized something that may be pretty important. We also have other SPI sensors (one at pin 9 and one at pin 13) that share the same MISO, MOSI, SCK lines. This would also be a difference between the nRF52 Development Kit and the custom boards. We don't intend to work with these boards for this custom board iteration, though they are on the boards. Could they be interfering the signal? Is there special consideration we should take for them.

Thanks again for your time.

RE: SPI operations failing on custom board versus development kit

cldelahan — Tue, 11 Jan 2022 14:19:28 GMT

Thanks for the response!

Apologies for the pin confusion! About the pins, I had made a mistake when copying the code into the website, sorry about that. We have

#if defined(USING_DEV_BOARD)
/* SAADC Pin */
#define SAADC_BATTERY_PIN               NRF_SAADC_INPUT_AIN3 // 5
/* SPI Pins */
#define LPS22_MISO                       15
#define LPS22_MOSI                       14
#define LPS22_SCK                        12
#define LPS22_SS                         16
#else
/* SAADC Pin */
#define SAADC_BATTERY_PIN               NRF_SAADC_INPUT_AIN6 // 30
/* SPI Pins */
#define LPS22_MISO                       15
#define LPS22_MOSI                       14
#define LPS22_SCK                        12
#define LPS22_SS                         17
#endif

to block off flashing to the nRF52 Development Board versus the production chip, and in cutting away fluff chose the wrong half of that.

Thanks for the advice on switching the modes. I have been circling through, and while the received WHO_AM_I value is changing (MODE_0: 0, MODE_1: 102, MODE_2: 152, MODE_3: 0), none are matching the expected value.

Here is just the current consolidated SPI code that yielded these numbers.

#define LPS22_MISO                       15
#define LPS22_MOSI                       14
#define LPS22_SCK                        12
#define LPS22_SS                         17

#define SPI_BUFSIZE                         8
#define SPI_INSTANCE                        0

#define SET_READ_SINGLE_CMD(x)  (x | 0x80)      // Indication that we are reading data
#define SET_WRITE_SINGLE_CMD(x) (x & ~(0xC0))   // Indication that we are writing data

uint8_t spi_tx_buf[SPI_BUFSIZE];
uint8_t spi_rx_buf[SPI_BUFSIZE];

static volatile bool spi_xfer_done;

static const nrf_drv_spi_t m_spi = NRF_DRV_SPI_INSTANCE(SPI_INSTANCE);

void spi_event_handler(nrf_drv_spi_evt_t const * p_event, void * p_context) {
    spi_xfer_done = true;
}

static void spi_init(void) {
    nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
    spi_config.ss_pin       = LPS22_SS;
    spi_config.miso_pin     = LPS22_MISO;
    spi_config.mosi_pin     = LPS22_MOSI;
    spi_config.sck_pin      = LPS22_SCK;
    spi_config.frequency    = NRF_DRV_SPI_FREQ_4M;
    spi_config.mode         = NRF_DRV_SPI_MODE_0;

    APP_ERROR_CHECK(nrf_drv_spi_init(&m_spi, &spi_config, spi_event_handler, NULL));

    nrf_gpio_cfg(LPS22_MOSI, NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_H0H1, NRF_GPIO_PIN_NOSENSE);
    nrf_gpio_cfg(LPS22_SCK,  NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_H0H1, NRF_GPIO_PIN_NOSENSE);
    nrf_gpio_cfg(LPS22_SS,   NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_CONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_H0H1, NRF_GPIO_PIN_NOSENSE);
}


void spi_register_write(int reg, int data) {
    spi_tx_buf[0] = SET_WRITE_SINGLE_CMD(reg);
    spi_tx_buf[1] = data;
    spi_xfer_done = false;
    APP_ERROR_CHECK(nrf_drv_spi_transfer(&m_spi, spi_tx_buf, 2, spi_rx_buf, 0));
    while(spi_xfer_done == false) {};
}

uint8_t spi_register_read(int reg) {
    spi_tx_buf[0] = SET_READ_SINGLE_CMD(reg);
    spi_xfer_done = false;
    APP_ERROR_CHECK(nrf_drv_spi_transfer(&m_spi, spi_tx_buf, 1, spi_rx_buf, 2));
    while(spi_xfer_done == false) {};
    return spi_rx_buf[1];
}

RE: SPI operations failing on custom board versus development kit

hmolesworth — Tue, 11 Jan 2022 03:45:53 GMT

Those mappings are different to the one you posted in the code snippet above, as originally SS was pin 16 not pin 17; is that intentional?. Other than that the only pins which don't work well as SPI pins are those designated as Quiet, or potential NFC or potential Reset, but none of those pins are in the four you are using.

Given that the part is the LPS22HB I would suggest trying the 4 different SPI modes and see if any work; the HH works with this mode, but not sure if the HB is the same:

// CPOL 0 -- clock polarity active high, CPHA 1 -- sample on trailing clock edge, send Msb first

RE: SPI operations failing on custom board versus development kit

cldelahan — Tue, 11 Jan 2022 02:36:05 GMT

Thanks for the reply and continued support - I really do appreciate it.

On the nRF52 Development Kit (the working one) our trace is roughly 4" as wires connect to the external breakout board. However, on our custom board (not working), the trace is ~2mm (factory manufactured PCB board).

I had interchanged VCC and VDD, but we operate the custom board at 3.3V.

And I should have specified further - we are using LPS22BH, which has WHO_AM_I of 0xB1. Hadn't realized there was a LPS22HH version, apologies for the confusion.

Cleaned up the buffer size as suggested but still running into the same issue.

Our pin mappings are:

#define LPS22_MISO                       15
#define LPS22_MOSI                       14
#define LPS22_SCK                        12
#define LPS22_SS                         17

With the LPS22 getting power from the VCC powering the board.

I appreciate all the ideas on what could be incorrect - I really appreciate. I think I also remember reading something on another log about UART causing a difference between nRF52 Dev Kits and stand-alone nRF52 boards? Is there any module side effects like this I should be sure to watch out for?

Thanks again,
Conner

RE: SPI operations failing on custom board versus development kit

hmolesworth — Tue, 11 Jan 2022 01:50:35 GMT

Is the trace length between nRF52832 and LPS22 longer than the dev kit? More than (say) 2" (50mm) and the reflections on the SCK input at the LPS22 causes incorrect clocking without suitable termination or at least a series resistor at signal source; often a series resistor of 22R is used, not correct impedance but sufficient without degrading the signal. What is VCC by the way? LPS22HH is 0xB3, I checked - and I use the same part.

Assuming 4-wire SPI these are the pin mappings I use:

//  1 Vdd_IO Power supply for I/O pins
//  2 SCL SPI serial port clock
//  3 GND
//  4 4-wire SPI MOSI
//  5 4-wire SPI MISO
//  6 /CS SPI active-low enable
//  7 INT_DRDY Interrupt (typically NC)
//  8 GND 0 V supply
//  9 GND 0 V supply
// 10 VDD Power supply

3-wire also works

Edit: also note that sending a second unknown byte is not a good idea; either send 1 byte (receive 2 anyway) with NRF_SPIMn->ORC set to 0x00 or set 2nd byte in Tx to 0x00 and send 2.

// for who am i change
 APP_ERROR_CHECK(nrf_drv_spi_transfer(&m_spi, spi_tx_buf, 2, spi_rx_buf, 2));
to
 APP_ERROR_CHECK(nrf_drv_spi_transfer(&m_spi, spi_tx_buf, 1, spi_rx_buf, 2));
.. provided ORC is set to 0x00

.. or set 2nd tx byte to something other than whatever was left in the spi_tx_buf
   buffer from previous transfer ..

RE: SPI operations failing on custom board versus development kit

cldelahan — Tue, 11 Jan 2022 01:22:00 GMT

Hi,

I apologize - I had miswrote earlier. The WHO_AM_I was constantly returning 0, not a variable value. I believe the WHO_AM_I is still 0xB1 on the LPS22, but am having no luck either way.

Ramped it up to 8MHz and set default SPI Mode to 0, still running into the same issue. We are ordering some additional custom boards to check if hardware, but there doesn't seem to be any visible difference between the non-working board we are using and the development kit.

RE: SPI operations failing on custom board versus development kit

hmolesworth — Tue, 11 Jan 2022 00:16:23 GMT

Who am i is 0xB3, not 0xB1 methinks ..

#define LPS22HH_WHO_AM_I_REG_ADDR 0x0F
#define LPS22HH_WHO_AM_I_RESP     0xB3

Also 125kHz is pretty slow, I would bump the clock speed to 8MHz and double-check that the default is SPI Mode 0 when using the default NRF_DRV_SPI_DEFAULT_CONFIG

RE: SPI operations failing on custom board versus development kit

cldelahan — Mon, 10 Jan 2022 23:40:33 GMT

Circling back. Completed testing - no stability issues. Custom board has very stable 3.3V on VCC throughout SPI initialization

RE: SPI operations failing on custom board versus development kit

cldelahan — Mon, 10 Jan 2022 22:33:52 GMT

Thanks for your fast response - I greatly appreciate it.

The BLE with advertising and UART-send works great, so it sounds like it is not a 32kHz crystal issue.

Looking over the schematic, the Nordic chip and the LPS22 have the same electrically-connected VCC, though we don't have a decoupling capacitor next to VCC next to LPS22 as recommended in the datasheet. However, we were able to get SPI reads on a modified version of the Adafruit LPS22 Breakout board that also removed the decoupling capacitator.

We are presently checking the stability of that VCC during initialization.

We have observed also that the WHO_AM_I register on the LPS22 is variable on each read as well (on the custom boards); don't know if that gives any other useful information.

RE: SPI operations failing on custom board versus development kit

hmolesworth — Mon, 10 Jan 2022 21:03:57 GMT

"we have not been able to get the SPI feature to work" - does the BLE work? If not, most likely cause is not using a 32kHz crystal (or using a module with no 32kHz crystal) without setting the defines up for internal 32kHz RC operation.

If the BLE does work ok then maybe post the schematic; you already have high drive SPI signals, so unless there is an FTDI preventing proper board reset or the SPI output signals MOSI/SS/SCK are driven high before the LPS22 VCC (if LPS22 VCC is provided by a nRF52 port pin) causing phantom power issues there's not much that can go wrong. If a port pin is used to power the LPS22 the VCC must be stable (say 10mSecs) before driving MOSI/SS/SCK high which happens on the SPI init. It's ok to let those pins go high if there is a pull-up to LPS22 VCC but not to drive them from a different supply (eg nRF52832 VCC) prematurely. If both VCCs are the same (electrically connected) then of course no issues with sequencing.