This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HS3001: sensor stuck providing stale data : difficult to reproduce failure mode

Problem

The HS3001 temperature sensor intermittently fails to update "stale" data per its status bits, and it then remains in this state until power cycle. This issue occurs more frequently on a few instances of the HS3001, but it is still difficult to reproduce.

Details

Measurement Timing

Both the humidity and temperature measurement resolutions are unchanged from the factory defaults of 14-bits. This is the highest resolution supported, and results in a worst-case measurement time of 33.90 milliseconds, as shown in the datasheet snippet below.

In the failing implementation, the MCU does not explicitly wait for 33.90 ms after initiating a Measurement Request to the HS3001 and before the first Data Fetch. Instead, the MCU issues Data Fetches to poll the status of the HS3001. Each Data Fetch takes ~760 µs to complete, as shown below.

Therefore, the HS3001 status should indicate valid data within 45 Data Fetch polling operations. This holds true in the working cases, such as the annotated I2C trace, below.

Start, h88 [ h44 | WR ], Stop                          - Measurement Request
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop  - Data Fetch #1, Stale Data indicated by bits[7:6] == 01b in first byte returned, h7F
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop  - Data Fetch #2, Stale Data indicated by bits[7:6] == 01b in first byte returned, h7F
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop  - continued...
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop
Start, h89 [ h44 | RD ], h0E, hB6, h65, h88 NAK, Stop  - Data Fetch #41, Valid Data indicated by bits[7:6] == 00b in first byte returned, h0E

The timeout of a Measurement Request is set to 100 Data Fetch operations. At ~760 µs per Data Fetch operation, this allows for nearly double the specified duration of 33.90 ms. 

The I2C trace below shows stale data for 100 consecutive Data Fetch operations. Note that this HS3001 had multiple successful Data Fetches on this power cycle until the failure, below.

Start, h88 [ h44 | WR ], Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, h81 NAK, Stop

The I2C trace below shows a re-issue of a measurement request, after receiving only stale data on the previous data fetches. The I2C trace below is not associated with the above I2C trace.

Start, h88 [ h44 | WR ], Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop
Start, h89 [ h44 | RD ], h7F, hFF, h67, hA1 NAK, Stop

I2C Timing

I2C timings are within the HS3001 requirements with plenty of margin. The exception is t_HDDAT, which has less margin towards the maximum. The I2C digital waveforms are attached. The table below shows the datasheet minimum and maximum timings compared to the measured timings in the implementation.

/cfs-file/__key/communityserver-discussions-components-files/291/HS3001_5F00_I2C_5F00_measurements.zip

Symbol Minimum Measured Maximum Units
f_SCL 20 62 400 kHz
t_HDSTA 0.1 6.5 N/A µs
t_LOW 0.6 9.55 N/A µs
t_HIGH 0.6 6.55 N/A µs
t_SUSTA 0.1 20.34 N/A µs
t_HDDAT 0 0.4 0.5 µs
t_SUDAT 0.1 9.17 N/A µs
t_SUSTO 0.1 6.5 N/A µs
t_BUS 1 13.75 N/A µs

Hypotheses 

This is not explained in the datasheet, but the "stale" Data Fetch data appears to provide some insight to discrete states within the HS3001.

Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop --- state 0: status indicates stale data, invalid humidity, invalid temperature 
Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop --- state 1: status indicates stale data, invalid humidity, valid temperature staged?
Start, h89 [ h44 | RD ], h0E, hB6, h65, h88 NAK, Stop --- state 2: status indicates valid data

Note that all Data Fetches use the longer of the two formats. 

Once the HS3001 enters the "stuck" failure mode, all readings are similar to "state 1: status indicates stale data, invalid humidity, valid temperature staged" in the above annotated I2C trace. This state remaining indefinitely on a given power cycle, even after MCU re-issues a Measurement Request.

This data indicates that the HS3001 may be "stuck" in the humidity measurement process.

Questions

  1. Per the data in the "Hypotheses" section above, could the HS3001 be "stuck" in the humidity measurement process?
  2. Can the HS3001 only be reset by removing the supply voltage? 
  3. Why is there a maximum to t_HDDAT? 



[locked by: IK_Renesas at 10:50 (GMT 0) on 24 Sep 2024]
  • Hi Steve,

    Thanks for the request. We have acknowledged your request and working on that. Meanwhile could you please share the following information:

    1. Share the circuit schematic.

    2. Please specify the target MCU and compiler that you are using in your project and also share the code.

    Question: 

    1.Per the data in the "Hypotheses" section above, could the HS3001 be "stuck" in the humidity measurement process?

    >> No such thing should not occur during humidity measurement.

    2. Can the HS3001 only be reset by removing the supply voltage?

    >> you can do reset by removing power supply.

    3. Why is there a maximum to t_HDDAT? 

    >> That I have to check.

    Please Make sure that you have followed the below steps:

    1. Connect sensor to i2c master (pullup resistors needed) and power supply with 1.8V to 5.5V. (I2C bus rate = 100kHz or 400kHz) 

    2. Send write command to I2C address

    3. Set delay for the measurement time (have a look at the datasheet) @ 14-bit it should be at least 16.90ms (T) + 16.90ms (RH) + 0.1ms (wake-up time). 

    4. Request the data. 

    I hope this helps. If not, please share the formation as I mentioned above.

    Regards:

    Raja

  • Hi Raja,

    Thank you for the response. I am unable to share the circuit schematic or source code at this time. However, please note that I included I2C bus traces from a trusted measurement tool, the Digilent Analog Discovery 2. Also, the measurement completes as expected over 99% of the time. Once the failure mode is entered, the status bits in the Data Fetch indefinitely report "Stale Data", even if another Measurment Request is issued. The I2C trace does not indicate any protocol errors. This indicates to me that the HS3001 is not behaving as expected. 

    I have some questions regarding the steps you outlined versus the datasheet. 

    1. I2C bus rate

    (I2C bus rate = 100kHz or 400kHz) 

    These are two common I2C bus rates. However, Table 6 in the datasheet aligns with another common I2C behavior, where arbitrarily lower clock frequencies are also allowed. 

    Is the device expected to perform better specifically at either 100kHz or 400kHz?

    2. Delay during measurement time

    Set delay for the measurement time (have a look at the datasheet) @ 14-bit it should be at least 16.90ms (T) + 16.90ms (RH) + 0.1ms (wake-up time)

    The above recommendation implies that the MCU should not poll the HS3001 for completion prior to 33.90ms. However, the datasheet indicates that either waiting or polling during the measurement time is acceptable. Below from section 6.6.

    1. "The status bits of the DF results can be used to detect if the data is valid or stale (see section 6.7)"
      1. I interpret this as MCU polling during measurement time.
    2. "otherwise, wait for the measurements to complete before performing the DF."
      1. I interpret this as MCU waiting during measurement time. 

    Polling is working until the failure mode appears. The observed time-to-completion is ~33.90 ms as I mentioned in my initial post, below.

    Both the humidity and temperature measurement resolutions are unchanged from the factory defaults of 14-bits. This is the highest resolution supported, and results in a worst-case measurement time of 33.90 milliseconds, as shown in the datasheet snippet below.

    In the failing implementation, the MCU does not explicitly wait for 33.90 ms after initiating a Measurement Request to the HS3001 and before the first Data Fetch. Instead, the MCU issues Data Fetches to poll the status of the HS3001. Each Data Fetch takes ~760 µs to complete, as shown below.

    Therefore, the HS3001 status should indicate valid data within 45 Data Fetch polling operations. This holds true in the working cases, such as the annotated I2C trace, below.

    Is the HS3001 expected to perform better if the MCU waits during measurement time as compared to polling during measurement time?

    I would also like to clarify some responses to my previous questions. 

    3. HS3001 discrete states

    >> No such thing should not occur during humidity measurement.

    I have three clarifications regarding this: 

    - Does this mean that the HS3001 cannot get stuck during humidity measurement? I'd like to make sure I'm interpreting the double negative of "no such thing should not occur" correctly.

    - Can the HS3001 get stuck during other parts of the measurement process? 

    - Can you comment on my interpretation of the discrete states that I noted regarding polling a measurement cycle? Are the below states indicative of states within the HS3001?

    This is not explained in the datasheet, but the "stale" Data Fetch data appears to provide some insight to discrete states within the HS3001.

    Start, h89 [ h44 | RD ], h7F, hFF, hFF, hFD NAK, Stop --- state 0: status indicates stale data, invalid humidity, invalid temperature 
    Start, h89 [ h44 | RD ], h7F, hFF, h65, h89 NAK, Stop --- state 1: status indicates stale data, invalid humidity, valid temperature staged?
    Start, h89 [ h44 | RD ], h0E, hB6, h65, h88 NAK, Stop --- state 2: status indicates valid data

    4. t_HDDAT

    3. Why is there a maximum to t_HDDAT? 

    >> That I have to check.

    Were you able to find out more about this? I am still interested in this parameter.

  • Hello,

    I am following up on my previous post. Could you please respond to the latest questions? 

    Regards,

    Steven

  • Hi,

    We will update you soon.

  • Hi Steven,

    Sorry for long wait. Please see my response highlighted in green. 

    Is the device expected to perform better specifically at either 100kHz or 400kHz?

    >>You can use any clock frequency between 20 kHz to 400 kHz to communicate our sensor. But for general practice you should use either 100kHz or 400 kHz. 

    Is the HS3001 expected to perform better if the MCU waits during measurement time as compared to polling during measurement time?

    >> I don't think so. For more info, please go through the programming manual notes. 

    HS300x Sample application - Sample Code (renesas.com)

    Can the HS3001 get stuck during other parts of the measurement process? 

    >> Our sensor should not stuck, during measurement process.

    Were you able to find out more about this? I am still interested in this parameter (t_HDDAT).

    >> The t_HDDAT is the I2C parameters. It is data hold time measured from falling edge of SCL applies to data in transition and the acknowledge. For details info, please go through any I2C details description notes. 

    I have also attached Arduino programming note for your reference.  

    // HS300x Example 
    
    #include <Wire.h> //include Wire.h library
    
    void setup()
    {
      Wire.begin(); // Wire communication begin
      Serial.begin(115200); // The baudrate of Serial monitor is set in 9600
      while (!Serial); // Waiting for Serial Monitor
      Serial.println("\nHS3001 test");
    }
    
    void loop()
    {
      Wire.beginTransmission(0x44); // Measurement request
      Wire.endTransmission();     // stop transmitting
    
      delay(35);  //Delay between Write (MR) and Read (DF).  14 bit should be ~ 33.9ms
    
    
      Wire.requestFrom(0x44, 4);    // Read data fetch 
    
      if(4 <= Wire.available())    // if two bytes were received
      {
        unsigned char res[4];
        unsigned int temp;
        float Humidity,Temperature; 
    
    
        res[0] = Wire.read(); 
        res[1] = Wire.read(); 
        res[2] = Wire.read(); 
        res[3] = Wire.read(); 
    
        temp = (res[0]<<8) +res[1];
        temp = temp & 0x3fff;
        Humidity = ((float)temp*100.0f)/(0x4000-0x01);
        temp = (res[2]<<8) +res[3];
        temp = temp>>2;
        Temperature = ((float)temp*165.0f)/(0x4000-0x01)-40.0f;
    
        Serial.print("\nHumidity = ");
        Serial.println(Humidity);
        Serial.print("\nTemperature = ");
        Serial.println(Temperature);
    
      }
    
      delay(2000);
    }
    

    Regards:

    Raja.

  • Hello Steven,

    Were you ever able to figure out how to resolve this issue? I am running into the same thing and I came across this post but it doesn't look like a final answer was ever posted.

    Thanks,

    James

  • Hello James,

    No, this issue was not resolved.

  • Thanks for your response. I don't know if you're still working on this yourself but I will post on here for future reference for anyone else if I'm able to figure out a solution.

  • I am no longer investigating this myself. The I2C polling data lead me to believe that the HS3001 is getting "stuck" during the humidity measurement state, although the existence of such discrete state was neither confirmed nor denied by Renesas (detailed in a previous comment). 

    I look forward to hearing whether or not your data supports this hypothesis. 

    I did not test if the failure mode is related to polling during temperature measurement. In other words, does the failure mode still occur if the I2C bus is idle for at least 35ms after initiating a Measurement Request, rather than polling during this time? The example code provided by Renesas performs this explicit wait, as shown in "HS3001_example.txt". However, my understanding is that this explicit wait is not necessary. If an explicit wait is necessary, I wonder if unrelated I2C traffic could result in a similar issue.

  • My code was already doing that wait between the request and the fetch but I took it a step further and I paused all other I2C devices on the bus during the wait period with no luck. I also tried manually setting the SDA and SCL lines both high and low for a period of time to see if that might cause the device to do anything differently but I wasn't able to find any way short of a power cycle to get it out of that state. It definitely seems to me like something strange going on internally on the sensor.  are you available for further support on this issue? Currently it seems my only options are to either make a hardware update so I can manually toggle power to the sensor to perform a reset or switch to a different sensor entirely.