HTS221 - datas keep being stuck in not ready state

[JGreg.2]

Hello,

My company is using since more than one year the HTS221 component, in several thousands of units.

On really few parts, we observe that the HTS221 sensor is stuck in a not ready state: we request its status before reading its output data registers to make sure the sensor has new measured values to send. We have not identified any specific environmental pattern that would produce such a bug.

Here is the configuration:

• CTRL_REG1: BDU =1 and ODR1,ODR2 = 11 (12.5Hz)
• All other configuration registers are in default configuration state (we do not configure them, only CTRL_REG1 is initialized).

We measure thanks to an interruption the output registers every second (yes, than why a 12.5Hz outpute data rate ? I will change it to 1Hz but this shouldn't be the reason of the stuck issue, shouldn't it ?)

And if the sensor has not any data ready (status register H_DA and T_DAT are equals to 0), we send every millisecond a new reading command to its status register. After 800 iterations (about 800ms), we raised an error.

Is this status reading state frequency too high for him to let him have the time to make new measurements ?

Honestly, I was not in charge of the firmware developpment and I would have done differently but still, there shouldn't be any bug with it, so I am trying to find why there is.

Any idea ?

Extra questions:

• what happens if in BDU = 1 mode, we do not read MSB and LSB ? there is no new acquisition launched by the sensor and then no more update of the output data registers?
• If output data rate is 12.5Hz and an average made on 2 samples (AV_CONF), it means every 12.5Hz, the sensor will launch 2 acquisitions which will be averaged ? What is the time between these 2 acquisitions?

Thank you in advance,

[Eleon BORLINI]

Hi @JGreg.2​ ,

>> Is this status reading state frequency too high for him to let him have the time to make new measurements?

I believe you could slow down the polling of the status register, since the ODR updates the output register once every 80ms, but I'm not sure this is the blocking point... you may check if your configuration is similar to the one in the ST examples on Github (hts221_read_data_polling.c).

In the case of blocked devices, are you able to recover the acquisition after an hard reset of the device? (Vdd off --> Vdd on)

About the extra questions, when you set the BDU, the content of the output registers is not updated until you have read them. This to prevent the possibility that, if you read the registers to fast, you would read two times the same vale or concatenate different parts of consecutive 16-bit samples.

The sample average that can be selected from the AV_CONF registers refers to internal IC calculation: HTTS221 output will always be available "every" 12.5Hz, but the output sample will have been obtained from an average of N samples, where N is defined by AV_CONF bits (this to reduce the output noise, paying a little on the current consumption).

-Eleon

[JGreg.2]

Dear @Eleon BORLINI​ ,

First, thank you for the time you took to answer me.

I believe you could slow down the polling of the status register, since the ODR updates the output register once every 80ms, but I'm not sure this is the blocking point... you may check if your configuration is similar to the one in the ST examples on Github (hts221_read_data_polling.c).

In the case of blocked devices, are you able to recover the acquisition after an hard reset of the device? (Vdd off --> Vdd on)

==> Yes, after a hard reset of the device, it starts to work well again.

If I communicate with the sensor (in I2C), does it take time to the sensor, which delays its measurements)and/or ODR updates of the output register?

E.g.: i have send continously request, will it responds and make measurements + output register update in parallel ?

About the extra questions, when you set the BDU, the content of the output registers is not updated until you have read them. This to prevent the possibility that, if you read the registers to fast, you would read two times the same vale or concatenate different parts of consecutive 16-bit samples.

==> Yes, but does the sensor make its acquisition and just not update the output register up to I read the LSB&MSB output data ?

The sample average that can be selected from the AV_CONF registers refers to internal IC calculation: HTTS221 output will always be available "every" 12.5Hz, but the output sample will have been obtained from an average of N samples, where N is defined by AV_CONF bits (this to reduce the output noise, paying a little on the current consumption).

==> Yes, so that means the sensors makes more acquisitions to calculate an average on more samples, is that correct? So what would be the acquisition frequency just by curiosity?

[Eleon BORLINI · Accepted solution]

Hi @JGreg.2​ ,

>> If I communicate with the sensor (in I2C), does it take time to the sensor, which delays its measurements)and/or ODR updates of the output register?

E.g.: i have send continuously request, will it responds and make measurements + output register update in parallel?

Being the I2C speed typically much higher than the ODR data rate, the I2C communication time is negligible with respect to the difference between a valid sample and the next valid sample (spaced in time by 1/ODR). All the internal operation are made inside the 1/ODR time frame.

>> Yes, but does the sensor make its acquisition and just not update the output register up to I read the LSB&MSB output data?

If the BDU is set, the data out is not updated until it is not read. If the data is read much time after the data is available, internally the sensor has continued to capture data and so will make available the real-time physical value in the next data.

>> Yes, so that means the sensors makes more acquisitions to calculate an average on more samples, is that correct? So what would be the acquisition frequency just by curiosity?

Right. The internal master clock frequency should be about 1MHz, but it is heavily reduced by the internal clock tree division, so that the maximum average is 512 at 12.5Hz, meaning about 6.4kHz

In case these answers are helpful for you, please mark this answer as "best", so that the case can be closed.

-Eleon