ISM330DHCX - SPI driven by FPGA - some questions

[ASchm.3]

Hi,

I want to drive an ISM330DHCX by an FPGA using SPI. Due to the fast operation and the exact timing I can realise this way, a few questions occured.

1. Data sheet fig. 6 details the SPI timing. There is no value given for minimum time for CS=HIGH, i.e. the minimum time between two consecutive bus cycles. Am I right with e.g. 50 ns minimum CS=HIGH?
2. Which time is necessary to internally settle written register values, i.e. which time I have to wait before i) I can read written values back and ii) written values are internally valid (e.g. ODR or full-scale selection)?
3. A more general question: What is the meaning of CTRL9_XL bit 1 "DEVICE_CONF"? In the data sheet is written "It is recommended to always set this bit to 1 during device configuration.", but in STM's demo applications (STMems_Standard_C_drivers/ism330dhcx_STdC/example/) this register is not used at all.

[Eleon BORLINI]

Hi @Community member​ ,

Let me check if I can answer to your question:

1. The minimum time between two cycles is related to the internal chip master clock. Since it is about 5MHz (10MHz in some cases), I would say100ns (half of a cycle) min instead of 50ns.
2. The internal registers are set accordingly to the internal clock speed. Of course, the register setting are effective after longer time, in the order of magnitude of 1/ODR. Also the output register are refreshed at ODR rate, being this the speed at which the data-out is available; please consider however that several times the actual ODR is slightly different to the nominal ODR: for a more precise characterization, it's better to evaluate this parameter device by device.
3. That's a good point. It's recommended to set the DEVICE_CONF of CTRL9_XL for the correct device configuration. The examples on Github are not considering this, and you are right, so my suggestion is to open a new issue at this link directly on Github. This will be treated in about 1 week, typically. Meanwhile, I'll report it internally for knowledge.

-Eleon

[ASchm.3]

Hi Eleon,

thanks for the information.

Regarding DEVICE_CONF in CTRL9_XL I opened an issue on Github, and I received the answer that it is a bug indeed. They will fix it in the examples.

Regarding the other issues, I implemented a minimum time for CS=HIGH of 100 ns, as you recommended. I did some tests with a commercial ISM330 modul, but the problems were still present. Than I changed the modul, now using our own small sensor board. Now, it seems to work correctly. So, for the moment there is no open question any more. If there might be new issues later on, I'll be back here.

Best regards

Axel

[Eleon BORLINI]

Hi @Community member​ ,

thank you very much for your reply and for describing your solution.

Can I ask you which module are you using? Has you code designed and customized for it? This may be the reason for which the module with ISM330 it is not working well...

-Eleon

[ASchm.3]

Hi Eleon,

there is no special code for the module. But the commercial module is designed for both 5 V and 3.3 V operation. Within the SPI data and clock lines there are transistors for voltage adaptation, for CS there is a diode. I assume (just an assumption so far, I didn't test) this is the reason for being not as fast as our own module, which is designed for 3.3 V only - there is no component on board, which is not essential. This "pure" design seems to perform well, i.e. at the speed one can expect from reading the data sheet.

If there is a chance of an update of the data sheet, the "minimum CS HIGH time" between two consecutive SPI cycles should be added. I didn't test the absolute minimum value, but your 100 ns are already quite good (in fact it is just a single 10 MHz clock period).

best regards

Axel

[ASchm.3]

Hi Eleon,

finally I did a test - it's the diode. Removing the diode speeds up the communication, i.e. the time between two bus cycles is decreased.

best regards

Axel

[Eleon BORLINI]

Hi @Community member​ ,

thank you again for reporting your further investigation!

-Eleon