More than one chip on SPI bus?

[NicRoberts]

STM32WB55 NUCLEO

I have 2 ADXL362s on SPI1.

They both have their own separate chip select GPIO pins.

They are both configured the same.

They are both in the same orientation (on the same breadboard).

The output of both is processed using the same logic.

One of them gives expected results, the other is consistent but wrong!

Just as a sanity check, I am OK to run two sensors on the same SPI bus as long as I'm clear which chip is selected?

[Andrew Neil]

---

@Ozone wrote:

I don't know how long your cabling to the breadboard is.

---

@NicRoberts This is where the good, clear photos of your setup could help!

Also still waiting to see your schematic.

And solderless breadboards are notorious for poor connections ...

---

@Ozone wrote:

I would start with a logic analyzer, .

---

I would start with a scope,  to see if there are any "analogue" issues - noise, levels, rise/fall times, etc ...

[NicRoberts]

Schematic

Picture (shows 2 temp sensors on the I2C1 bus, I disconnected them for the SPI tests)

I'll get the scope on it when I get time later today. After your post I suspect that PA9 (my CS_1) isn't acting like a GPIO IO even though the HAL GPIO init indicates that it is,

/* GPIO Ports Clock Enable */
__HAL_RCC_GPIOB_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();

/*Configure GPIO pin Output Level */
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4|GPIO_PIN_9, GPIO_PIN_RESET);

/*Configure GPIO pins : PA4 PA9 */
GPIO_InitStruct.Pin = GPIO_PIN_4|GPIO_PIN_9;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

[Andrew Neil]

Your schematic doesn't identify which pins you've used - neither on the Nucleo board, nor the MCU.

---

@NicRoberts wrote:

After your post I suspect that PA9 (my CS_1) isn't acting like a GPIO IO even though the HAL GPIO init indicates that it is

---

Again, check that there isn't anything on the Nucleo board that would interfere with its use as a GPIO pin.

Have you tried a different pin?

[NicRoberts]

CS_0 - PA4 pin D10 on Arduino header

CS_1 - PA9 pin D9 on Arduino header

SLK - PA5 pin D13 on Arduino header

MISO - PA6 pin D12 on Arduino header

MOSI - PA7 pin D11 on Arduino header

I moved CS_1 to PA8 on D6 but still the same results

[Danish1]

ADXL362 can suffer from offsets. It is possible you have a bad chip.

A reply from ADI Engineer Zone https://ez.analog.com/mems/f/q-a/590638/adxl362-offset-and-gain-drift-over-time states:

This part is designed for ULP applications such as activity trackers, portable medical monitors, or wireless industrial applications. This, among other considerations, makes this part packaged in plastic. This is not the case with other part families targeting high stability markets (ADXL35x) which have a ceramic encapsulation.

For our plastic inertial sensors, we can expect drift over life in the hundreds of mg range. I cannot give you a more precise answer because with this package, any stress related to humidity and temperature can affect the MEMS die, and this is tightly coupled to each specific application context. (this does not affect the general drift or sensitivity, as this is related to the ASIC)

[NicRoberts]

I'm not so concerned about offsets for this application as I can calibrate out drift every now & then but that's good to know thanks.

I've swapped out the chip but I keep getting the same results.

[Danish1]

So whichever chip you connect to CS1 always reads wrong?

That sounds like you're handling CS1 differently from CS0.

Compare all instances of CS1 with CS0.

Check that pin (port, number) isn't used elsewhere.

Could it be timing? The delay between asserting CS1 or CS0 and starting / stopping the SPI transfer?

Do you read wrong values for the ID register of that ADXL362?

Do you _start_ measurements on both of them, or just one?

[Andrew Neil]

---

@Danish1 wrote:

That sounds like you're handling CS1 differently from CS0.

---

Indeed.

Or there is some hardware issue on CS1 (although @NicRoberts says a different pin has been tried, with no change).

---

@NicRoberts wrote:

CS_0 - PA4 pin D10 on Arduino header

CS_1 - PA9 pin D9 on Arduino header

---

@NicRoberts have you tried putting CS0 on PA9, and CS1 on PA4 ... ?

To make sure that handling of the two chip selects is identical, I'd have a single function, which takes the CS line as a parameter - something like

void read_accelerometer( uint16_t cs_pin )
{
  // assert the appropriate CS
  HAL_GPIO_WritePin( GPIOA, cs_pin , GPIO_PIN_RESET );
  :
  :
  // Do SPI stuff
  :
  :
  // release the appropriate CS
  HAL_GPIO_WritePin( GPIOA, cs_pin , GPIO_PIN_SET );
}

[NicRoberts]

have you tried putting CS0 on PA9, and CS1 on PA4 ... ?

Just tried that & now both sensors are wrong & remains wrong when I revert to the original pinout until I unplug the board & then repower & then its back to how it was - sensor 0 correct, sensor 1 wrong.

To make sure that handling of the two chip selects is identical, I'd have a single function

Yes that's how I've implemented the SPI reads, they both use the same function

@Danish1 Could it be timing? The delay between asserting CS1 or CS0 and starting / stopping the SPI transfer?

I've but in a 1ms delay after each SPI transfer, see trace below, top CS0, bottom CS1.

@Danish1 Do you read wrong values for the ID register of that ADXL362?

Addresses & statuses comeback as expected

[Ozone]

Since I didn't see it mentioned ...

What SPI clock frequency you run ?

Have you verified that none of the CS pins, especially PA9, is connected to onboard peripherals ?

> Addresses & statuses comeback as expected

With identical sensor deviced, overlapping responses for this register values could go unnoticed.
An electrical "overlap" of measurement values would produce invalid ("wrong") results, as you observed.