More than one chip on SPI bus?

NicRoberts · ‎2025-06-10

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 · ‎2025-06-10

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 · ‎2025-06-10

@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?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

mƎALLEm · ‎2025-06-10

Hello,

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

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

Ozone · ‎2025-06-10

> ..., 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 · ‎2025-06-10

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.

NicRoberts · ‎2025-06-10

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.

NicRoberts · ‎2025-06-10

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

Andrew Neil · ‎2025-06-10

@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 ?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Ozone · ‎2025-06-10

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

Beat me to it ...

Yes, there seems something wrong on the bus.

I would start with a logic analyzer, and set a trigger on CS_0=CS_1=L.
And second, I would attach a scope to CS_1 as close to the second sensor as you get, if possible at the IC pin.

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

These sensors are advertised as "ultra low power". Which means they are "ultra" sensitive to EMI.
I don't know how long your cabling to the breadboard is.
Perhaps for testing, try drastically reducing the SPI clock frequency, i.e. an order of magnitude.