ISM330DHCX: Hi, is there any known issue regarding the WHO_AM_I of ISM330DHCX, when having a number of them on one bus? Sometimes I read 0x48 instead of the expected 0x6B. There is no issue with SPI speed (10 MHz or 1 MHz tested).

[ASchm.3]

I'm testing a system with a number of ISM330DHCX, generating the CE signals apart from the SPI component. Having a number of sensors on the bus (by means of CE only one of them active at any given time) I read sometimes a wrong WHO_AM_I-value. Bus clock is fine, there is no mis-interpretation, there are wrong data on the bus, but the sensor itself seems ok too (correct values when testing in different combination). I don't know what to look for - any ideas?

[niccolò]

Hi @Community member​ ,

there are no known issues regarding WHO_AM_I register, so don't worry, you can figure this out.

The problem could be that the timing between the transitions of the Chip Select (I think that is what you refer to as CE).

Remember that there should be just one CS down at a time (while you read device X the other's CS must be high), can you check this?

It can also depend on the timing of the single CS: please, refer to the table on page 14 of the datasheet ( https://www.st.com/resource/en/datasheet/ism330dhcx.pdf) and check if the t(su(CS)) is enough in your case (sorry for bad formatting, I hope you can understand what I mean).

Let me know if this helps you.

[Eleon BORLINI]

Hi @Community member​ , besides @niccolo.ruffini​ hints, in the unlikely event of some kind of signal cross-talk on the pcb, since you are using the SPI communication protocol only I would suggest you to write the I2C_disable bit to 1 in the CTRL4_C (13h) register before starting the sensor acquisitions. It is only a redundant procedure in any case. If you are however facing issue only with WHO_AM_I register, please disregard my suggestion. You can share with us the "failing" ISM330DHCX top marking picture to check if it is the correct part number. Regards

[ASchm.3]

Hallo Eleon,

when I start using a specific sensor, I already disable I2C. But before doing so, I need to identify the ISM330DHCX - that's why there is a WHO_AM_I register, I assume.

Meanwhile, I found the strange behaviour also in case of only a single sensor directly connected to the SPI pins of a Raspberry Pi, so there is no issue regarding CS anymore.

[niccolò]

So it is just one specific sensor that has issues with the WHO_AM_I reading?

[ASchm.3]

Hallo Niccolo,

no. I have a number of sensors, maybe 15 of them already tested. The problem is always the same. There is no sensor, which is definitely defect, sometimes they behave correctly. But sometimes I have the wrong answers when reading the WHO_AM_I register. What I mentioned in the post before was that I now tested the sensors in a single-sensor-config, directly connected to the SPI pins of a Raspi (therefore, my adapterboard including the CS generation is out of the problem). But I did this with several sensors.

Pictures of the SPI signals for ok- and nok-case attached, also the design of my small sensor board.

[niccolò]

Hi @Community member​ ,

sorry I misunderstood, I hoped that the problem was easier to solve.

Both communications seem ok, from a signal point of view, just as you stated.

The only odd aspect is the fact that in the OK comm, the SDO stays in high idle state, as I would expect, while in the NOK comm it goes to low; maybe the aftermath of the communication can tell us something, but it should be investigated the reason why it is like that.

I'll ask some colleagues for help.

Meanwhile, can you confirm the behavior of the CS pin during the transmission?

I know it would be odd if it set/reset without any input, but I am running out of possible root causes.

Can you also share the schematic of the circuits you are using?

I can't understand everything from just the board view.

[ASchm.3]

Hallo Niccolo,

thanks for your answer. Shortly answering your questions:

• after communication the SDO line might remain in the last state it is for the last bit, I assume
• CS pin is fine. I'm sure about, even if not shown in the picture.
• schematics is not necessary. The sensor is the lower one of the two, SPI pins go directly to the connector (pins from top: +3.3, GND, CS, SCLK, MOSI, MISO). The chip beside the sensor is a monostable pulse generator (LTC6993), which "extends" the CS to a visible output pulse at an LED - just to have an indication which of the sensors are in use.

More important: After some reading I inserted a serial resistor (currently 39 Ohm) in the SDO line at the sensor board. Now it seems to run well, also with the SPI speed of 10 MHz. Surely we'll do further tests, but for the moment I think this might solve the problem.

But still I don't really understand what happens. At the sensor boards, I have a 30..35 cm ribbon cable, which seems not optimal, but which is also not that much. As shown in the pictures, the signals still are quite ok, so the cable doesn't affect them too much. Having it run with a serial resistor would mean that the sensor isn't able to drive the signal properly (L or C of the cable too high ?), but in that case the signals should look somehow disturbed. In contrast I see a quite good signal, but wrong data.

That's why I want to ask:

• Could you imagine such a phenomenon?
• What serial resistance is already present inside the sensor's SDO line? It would be nice to have a value for proper calculation of the additional serial resistor - both resistors should add up to the cable impedance, I assume.

[niccolò]

Hi @Community member​ ,

1) ok, I see why you think that CS pin is ok, with the LTC6993 you are able to keep track of it.

But the thing is, I did not want to see the CS because I think it is not enabled, but just to be sure you enable/disable it with the right timings before and after every complete read. can you confirm that?

It could be useful in this sense, to see a wider communication pattern with all the data. I was thinking at the previous and following reads.

2) Also, are these data recorded at the microcontroller side or on the board? (It would be better to know exactly what the sensor is sending out)

3) may I also ask you what is the configuration of your sensor? (ODR, FS, mode)

4) If adding a R in series fixes it, it could be a line problem: you manage to adjust the impedance of the line and to move forward the cut off frequency of the line by adding it. (I'm sorry, but I don't have data on the serial resistance on the sensor's SDO line)

[ASchm.3]

Hallo Niccolo,

thanks for your answer. Regarding your questions:

1) I can confirm proper timing for the CS. In case of testing directly connected to Raspi, the Raspi SPI component does the CS setting with correct timing. In case of my adapter (to enable the use of several sensors at one SPI bus), I do the CS with a separate I/O-expander. That means, from Raspi side I have a I2C bus transfer to set CS, the SPI transfer itself and another I2C transfer to clear CS. The I2C driver calls before and after SPI ensure a sufficiently long time of CS before and after the SPI transfer.

2) The pictures show the signals after the first sensor cable, i.e. in a distance of roughly 30 cm from the sensor and quite close to the Raspi SPI pins. This was a first shot to control the received signal, i.e. to verify the data given by the SPI read in the software. You're right, the signals look a little different directly at the sensor - there are sometimes some spikes etc. That's why I was on the way to impedance matching.

3) There is complete default setting. After switching on the whole system, I want test all available ports, if an ISM330 is present, later on one can choose which of the available sensors to use. Up to that point there was no communication, and only the choosen sensors will be configured later on.

4) Obviously, I managed it up to a point, where it seems to run well. To have it more exactly, I want to know the "inner" resistance of the SDO line. In a forum article I found a statement of taking 20 Ohm as a good choice in case of no information about the correct value. I started with 33 Ohm, which also was ok, and ended up to now with 39 Ohm - the picture looked slightly better. But I did no further tests right now about the resister value, because the final configuration of the whole system might look different. Than I have to test again.

Best regards

Axel