ISM330BX + MSPM0G3519 over I²C: Software Hang/Reset with Both Polling and Interrupt-Based Communication

[Dilip M]

Configuration:

• I2C address: 0x6A
• Bus speed: 100kHz (standard mode)
• ODR: 1920Hz for both XL and GY (ISM330BX_XL_ODR_AT_1920Hz, ISM330BX_GY_ODR_AT_1920Hz)
• Full scale: ±125dps gyro, ±4G accel
• Reading a 14-byte burst starting at register 0x20 (TEMP + GYRO + ACCEL) once every 10ms, from our control loop.
• The application currently checks the IMU every 10ms.

My intention is:

1. Every 10ms, determine whether a fresh IMU sample is available.
2. If fresh data is available, start one interrupt-driven burst read (gyro + accel).
3. When the transfer completes, update the application variables once.
4. Ignore intermediate samples produced by the IMU between 10ms periods.

Polling-based implementation

Initially, we have implemented the IMU driver using a polling-based I²C implementation (partially based on an open-source GitHub driver). During long-duration testing, the application hung/resetting inside the blocking I²C loops. Code for this method is attached in attachment 1.

Interrupt-based implementation

To overcome the blocking behavior, we redesigned the IMU driver using an interrupt-driven (non-blocking) I²C implementation. Although this implementation eliminates the blocking polling loops, the application still hangs/resets during long-duration testing. The code for this implementation is attached as Attachment 2.

Sysconfig settings (I2C):

I2C1.basicEnableController             = true;
I2C1.$name                             = "I2C_2";
I2C1.advDigitalGlitchFilter            = "CLOCKS_1";
I2C1.enableDMAEvent1                   = false;
I2C1.enableDMAEvent2                   = false;
I2C1.basicTargetSecAddressEnable       = true;
I2C1.intController                     = ["ARBITRATION_LOST","NACK","RXFIFO_TRIGGER","RX_DONE","TXFIFO_TRIGGER","TX_DONE"];
I2C1.timeoutACount                     = 2;
I2C1.peripheral.$assign                = "I2C2";
I2C1.peripheral.sdaPin.$assign         = "PC3";
I2C1.peripheral.sclPin.$assign         = "PC2";
I2C1.sdaPinConfig.hideOutputInversion  = scripting.forceWrite(false);
I2C1.sdaPinConfig.onlyInternalResistor = scripting.forceWrite(false);
I2C1.sdaPinConfig.passedPeripheralType = scripting.forceWrite("Digital");
I2C1.sdaPinConfig.$name                = "ti_driverlib_gpio_GPIOPinGeneric20";
I2C1.sclPinConfig.hideOutputInversion  = scripting.forceWrite(false);
I2C1.sclPinConfig.onlyInternalResistor = scripting.forceWrite(false);
I2C1.sclPinConfig.passedPeripheralType = scripting.forceWrite("Digital");
I2C1.sclPinConfig.$name                = "ti_driverlib_gpio_GPIOPinGeneric21";

Questions

1. Based on the attached polling-based and interrupt-driven implementations, is there any issue in our overall communication sequence or software architecture that could lead to intermittent software hangs or resets?
2. Is the current approach of checking the STATUS_REG (0x1E) every 10ms before initiating a burst read the recommended method for synchronizing with the ISM330BX, or is there a better approach? 
3. When executing the I²C read operation in the 10 ms task, DL_I2C_getControllerStatus(), DL_I2C_startFlushControllerTXFIFO(), and DL_I2C_isControllerTXFIFOEmpty() intermittently fail. Why does this happen, and what modifications are required to resolve the issue?
4. Are there any specific timing requirements, delays, register access sequences, or configuration settings that should be considered when communicating with the ISM330BX over I²C to ensure reliable operation?
5. After reviewing the attached code, are there any portions of the implementation that should be modified or improved to align with ST's recommended software practices for the ISM330BX?

 

[Andrew Neil]

Have you used an oscilloscope to verify that the I2C lines are clean, good edges, etc ?

Have you used a logic analyser to capture what’s actually happening on the wires - in particular, when the “hang” occurs ?

 

Please show your schematic; some good, clear photos of your setup could also help.

 

[AScha.3]

This is an I2C on scope:

Any spike here might disturb the data or even produce a hang up ….so check signals.

https://rheingoldheavy.com/i2c-signal-reverse-engineering/

 

+

You didnt tell : which cpu + on same board w. ground plane or free wires, how many mm I2C lines / distance to cpu  ?

 

→ because : random “hang up” indicates a hardware problem, probably spikes/stray-in EMI .

[Andrew Neil]

You didnt tell : which cpu

I guess MSPM0G3519 (in the title) is the MCU ?

 

​@Dilip M it’s a TI processor - nothing to do with ST - so you’ll have to ask TI about any specific issues with it.

If you’ve already go a post on the TI forums, please post a link here - so everyone can see the full discussion.

Similarly, be sure to give a link to this thread in your TI post.

 

Having said that, the ISM330BX neither knows nor cares what microcontroller you use - the only thing it sees is the signals on its I2C pins.

That’s why it’s important for you to look at what’s actually happening on those pins - using a scope and/or LA.

[Andrew Neil]

4. Are there any specific timing requirements, delays, register access sequences, or configuration settings that should be considered when communicating with the ISM330BX over I²C to ensure reliable operation?

That would be specified in the datasheet.

See also the Application Notes and other supporting materials on the Product Page:

https://www.st.com/en/mems-and-sensors/ism330bx.html#documentation

 

ST Provide platform-independent drivers - have you tried them?

https://www.st.com/en/mems-and-sensors/ism330bx.html#tools-software