LPS28DFW Application reading data BUG

[SelimMuhammed]

Hi, ST
Now for my STEVAL-MKI225A Board which contains LPS28DFW Barometer sensor I Used the application “read_data_polling.c” which is running on “NUCLEO-F401RE Board” to test the sensor with the default example configurations which are:

md.odr = LPS28DFW_4Hz;

md.avg = LPS28DFW_16_AVG;

md.lpf = LPS28DFW_LPF_ODR_DIV_4;

md.fs = LPS28DFW_1260hPa;

and I noticed that when I’m getting the data in the while loop, It works correctly only with I2C Standard Mode (100KHz) and it stucks with fast mode.
but the main problem is when I’m adding delay or another code execution to the while loop, It also stucks and doesn’t work unless I removed the delay or the code added.

 

[Federica Bossi]

Hi ​@SelimMuhammed ,

It looks more like an I2C communication/timing issue than a sensor issue.
If the example works at 100 kHz but hangs in Fast Mode or when adding a delay/extra code in the main loop, please check:

• I2C pull-up resistors on SDA/SCL
• Wiring length and signal quality
• Correct I2C timing configuration in CubeMX
• All I2C return values / error codes
• A timeout in the polling loop instead of waiting forever

If needed, testing with a logic analyzer can help confirm whether the bus is stalling.

[Andrew Neil]

It works correctly only with I2C Standard Mode (100KHz) and it stucks with fast mode.

As ​@Federica Bossi said, that sounds very much like a bus hardware issue. So:

1. Look at the I2C bus signals with an oscilloscope;
   Are the edges clean, noise free, levels correct, etc ?
2. If all is OK according to the ‘scope, use a logic analyser to compare & contrast the working & non-working cases.

 

PS:

The STEVAL-MKI225A is a DIP module, so it won’t just plug straight on to the Nucleo.

So how are you connecting the STEVAL-MKI225A to the Nucleo ?

Please show your schematic, and some good, clear photos of your setup.

Remember that I2C is not designed for long wires …