Board is not working. Inclinometer error

[SathvikKunuru]

We are currently working with the LIS2HH12TR accelerometer on our Smarttrak board, using an STM32U575VIT6Q as the main MCU, and are facing an issue with unstable sensor readings.

Communication appears to be functioning correctly, we verified the I2C clock waveform and confirmed that the bus is operating at 100 kHz. The accelerometer responds properly, and we are able to read data successfully. However, the measured values are not stable.

For example, the calculated angle values normally stay around 20–30 degrees, but occasionally they suddenly jump to 70–80 degrees without any actual movement. These abrupt spikes are causing instability in our application and affecting overall board operation.

An additional challenge is that this behavior appears randomly and in 1 out of 5 devices, making it difficult for us to trace the exact source of the issue.

We would appreciate any guidance on possible causes and recommended debugging steps. Specifically, we would like to understand:

• What could cause sudden spikes or abnormal accelerometer readings?

• Could this be related to I2C timing, noise, grounding, PCB layout, or sensor configuration?

• Are there specific STM32 side precautions or best practices for reliable accelerometer data acquisition with the LIS2HH12TR?

Any suggestions or troubleshooting advice would be greatly appreciated.

 

 

 

[Federica Bossi]

Hi ​@SathvikKunuru ,

Could you please provide some of the following information?

• What is the readout data rate?
• Are you using the FIFO, or are you relying on DRDY and INT to read each sample?
• Have you enabled any filters?
• Are you printing the data?
• Are you reading the five sensors simultaneously?
• After reading the acceleration data, do you perform any processing on the values?
• Are you sure you are allowing enough time for the complete acquisition and processing chain?

A first possible consideration would be to try using the FIFO to store multiple samples and check whether the issue still occurs. Another aspect to review is limiting UART/USB printing, since printing several values or very long fields may make it seem as though there is an error in the measured data, when in reality the issue could be related to the output formatting or transmission time.