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?

[Hal3]

Yes,

The only difference should be the sensor ID, which you probably have correct.

Check wiring, GPIO function initialization, ultimaltly change SPI chip.

[Andrew Neil]

---

@NicRoberts wrote:

Just as a sanity check, I am OK to run two sensors on the same SPI bus 

---

Of course - that is the very definition of a bus !

 

---

@NicRoberts wrote:

as long as I'm clear which chip is selected?

---

The important thing is that no more than one chip is selected at any one time.

 

Have you looked at the chip pins with an oscilloscope to verify that signals are clean ?

Then look at the signals with an analyser to verify that the operation is correct - in particular, no overlap of the chip selects.

Make sure you are fully  abiding by the timing requirements:

in particular the CS Setup, Hold, and Disable times, and the Clock Enable time:

 

PS:

 

---

@NicRoberts wrote:

STM32WB55 NUCLEO

I have 2 ADXL362s on SPI1.

---

How are they connected?

Show your schematic; some good, clear photos may also help.

 

---

@NicRoberts wrote:

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

---

Is it always the same one ?

Have you tried connecting only one at a time ?

With both connected, have you tried permanently disabling each one in turn, and verifying that the other one works?

 

[NicRoberts]

 

---

Is it always the same one ?

Have you tried connecting only one at a time ?

With both connected, have you tried permanently disabling each one in turn, and verifying that the other one works?

 

---

I have connected them one at a time. If either of the single sensors is attached to CS_0 (no second sensor) I get the correct result but if connected to CS_1 (no second sensor) it gives the wrong result. To be clear that's just one sensor at a time.

 

The same thing if both are on the bus, if I swap the CS lines the sensor on CS_1 will be wrong. The values are consistent in there wrongness, there's no random fluctuations.

 

Chip statuses & IDs are being read correctly for both single & double set ups for both sensors.

 

 

[Andrew Neil]

---

@NicRoberts wrote:

 

I have connected them one at a time. If either of the single sensors is attached to CS_0 (no second sensor) I get the correct result but if connected to CS_1 (no second sensor) it gives the wrong result ...

:
:

The same thing if both are on the bus, if I swap the CS lines the sensor on CS_1 will be wrong. The values are consistent in their wrongness

---

Time to get scope & analyser on the bus, and see what's going on with CS_1.

Compare & contrast with CS_0

 

PS:

Have you tried different IO pins for the chip selects ?

Particularly for CS_1 ?

Are you sure that the pin you're using for CS_1 is in use by anything else on the Nucleo board ?

[mƎALLEm]

Hello,

---

---

See also this thread: SPI Communication ( Single Master Multiple Slave)

[Ozone]

> ..., the other is consistent but wrong!

With the ADXL362s being a machanical sensor, how did you come to that conclusion ?
How much is it off, in other words ?

Have you tried each of the sensors alone, sequentially ?

> They both have their own separate chip select GPIO pins.

I would say, that both SPI slaves are identical ICs, does not matter.
More than one slave on one bus usually requires you to manage the /CS signal by software (your code), instead of leaving it under hardware control.
I would not mix up any functionality by trying to drive both slaves at once.

[NicRoberts]

With the ADXL362s being a machanical sensor, how did you come to that conclusion ?

Well sensor 0 gives me 1g in the z direction and 0.01g in both x & y, which I expect on a flat table

Whilst sensor 1, on the same table in the same orientation gives 2.05g in z, 1.458g in x & -1.87g in y, so err yeah... wrong.

 

More than one slave on one bus usually requires you to manage the /CS signal by software (your code), instead of leaving it under hardware control.
I would not mix up any functionality by trying to drive both slaves at once.

I am managing CS in software, only one chip is selected at a time

 

 

[NicRoberts]

OK I didnt think I'd got that wrong, thanks.

The reason I think its an SPI issue is if I swap the CS pins around, its always the 2nd sensor that's wrong.

 

[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

 

 

[NicRoberts]

Well I just cant find the problem so have switched to I2C sensors which all work fine.