STHS34PF80 – Data remains constant, TOBJECT = -48

[los_trpaslikos]

Hello,
I am trying to get the STHS34PF80 sensor working on an STM32L0 platform via I²C. My initialization sequence is as follows:

1. Algorithm reset according to AN5867:

CTRL2 (0x21) = 0x10  // FUNC_CFG_ACCESS = 1
PAGE_RW (0x11) = 0x40 // FUNC_CFG_WRITE = 1
FUNC_CFG_ADDR (0x08) = 0x2A
FUNC_CFG_DATA (0x09) = 0x01
PAGE_RW (0x11) = 0x00
CTRL2 (0x21) = 0x00

1. Interrupt configuration:
   CTRL3 (0x22) = 0x05

2. AVG_TRIM:
   0x10 = 0x01

3. Continuous mode:
   CTRL1 (0x20) = 0x15 (BDU=1, ODR=4 Hz according to datasheet)

After this, I wait for EXTI interrupt (DRDY). On interrupt, I read:

• STATUS (0x23)
• TOBJECT_L/H (0x26/0x27) and etc.
• FUNC_STATUS (0x25)

Problem:

• The TOBJECT value remains constant (-48), even when I place a hand or heat source in front of the sensor.
• Presence/motion flags in FUNC_STATUS almost never change. Occasionally, I see a value of 1, but very rarely, even when moving a hand or breathing near the sensor.
• See attached screenshot of current data from the terminal.

Questions:

• Is my initialization sequence correct?
• What could cause TOBJECT to stay constant?
• Are there recommended threshold and AVG settings for reliable detection?

Thanks for any tips or reference to a working example.

[casadeib]

Hi @los_trpaslikos ,

Are you using STM32L0 platform together with a custom PCB with STHS34PF80? Can you please give us more details on you HW setup? Did you find out this issue only on one part?

[los_trpaslikos]

Hi @casadeib ,
we are using a fully custom PCB design with STM32L0, and the STHS34PF80 is connected exactly according to the reference schematic in the datasheet.

I have now received a second hardware unit, and with the exact same firmware the sensor behaves correctly. As proof, I am attaching two screenshots from the serial terminal: one from the working board and one from the non‑working board, showing both the configuration read back after initialization and the live data stream.

Based on this comparison, it really looks like the first unit I was testing is defective.
I would like to ask: is it possible that an incorrect register access sequence, during early development of our custom driver, could damage or “lock” the internal digital engine of the sensor?
For example, a wrong sequence involving FUNC_CFG_ACCESS or writing to embedded-function registers — could this permanently affect the sensor?

I also managed to reproduce another interesting scenario:
When I run the sensor in continuous mode but map DRDY to the interrupt pin instead of MOTION, I still see T_OBJECT stuck at –48 on the faulty unit, yet motion and presence detection clearly work in this configuration. This is quite strange and again suggests a problem internal to the first sensor.

In the next weeks we expect to receive more hardware units, so I will be able to test and compare more samples.
At the moment, however, I only have these two boards, and only one of them works as expected.

Thanks for any guidance.