Nucleo-F303 + SHT45 - I2C NACK Issue

[averiksen]

I needed a very small humidity sensor, so I made a PCB for the Sensirion SHT45. I interface it with a Nucleo-32 F303K8, and have tried a Nucleo 64 as well. It seems that I'm able to send commands to it, but when I try to read it, I receive only NACKs from the sensor. This behaviour could be because of a busy sensor, but I add enough time in between measurement request and reading that it should not be a problem. 

I tried a few chips. The first ones I soldered with an iron, then I tried hot air, most recently hot air from bottom of PCB, to shield the chip and especially its PTFE membrane from the heat of the air. I wonder if solder heat could have broken the sensor in a way where it will respond to I2C, but the sensing element might be broken.

I use CubeIDE, I2C standard default settings.

// Buffer to store RX data
uint8_t buffer[6] = {};

// Request High Precision reading - no error
if(HAL_I2C_Master_Transmit(&hi2c1, (uint16_t)(0x44 << 1),(uint8_t *)0xFD,1, 1) != HAL_OK){
uint8_t dummy = 1;
}

HAL_Delay(200); //have tried delays of 20, 50, 100 and 200 ms

// Reading sensor - always get NACK from sensor, hi2c1 errorcode 4 (NACK error)
HAL_StatusTypeDef ret = HAL_I2C_Master_Receive(&hi2c1, (uint16_t)(0x44 << 1), buffer, 6, 1);
while(ret != HAL_OK) {
ret = HAL_I2C_Master_Receive(&hi2c1, (uint16_t)(0x44 << 1), buffer, 6, 1);
}

HAL_Delay(20);

I use 2.2K pull up resistors, and very short soldered wires in my test setup.

Edited to apply source code formatting - please see How to insert source code for future reference.

[Andrew Neil]

---

@averiksen wrote:

It seems that I'm able to send commands to it

---

How have you verified that?

---

@averiksen wrote:

but when I try to read it, I receive only NACKs from the sensor.

---

Have you looked at the I2C lines with an Oscilloscope - are they clean, and with good edges?

Have you decoded what's happening on the lines (eg, with an analyser), and checked it against the SHT45 specifications?

Does your I2C work with any other chips?

---

@averiksen wrote:

I wonder if solder heat could have broken the sensor in a way where it will respond to I2C, but the sensing element might be broken.

---

You'd have to ask Sensirion about that; it's their chip - not ST's.

https://sensirion.com/products/support 

Have you tried with a Sensirion evaluation kit?

Or a 3rd-party breakout; eg, https://www.adafruit.com/product/5665 ?

[averiksen]

I probed the data lines on a regular scope, the waveforms seem clean. I could see the command being transmitted and acknowledged as one would expect the waveform to look. Additionally, the STM32 HAL returns HAL_OK from the HAL_I2C_Master_Transmit() function.

When the HAL_I2C_Master_Receive() executes, I see the sensor address on the data line, but the sensor pulls the data line high (NACK).

START - ADDR + READ-BIT - NACK   ... and nothing more.

I used the same Nucleo to read a HYT271 sensor, also humidity, not sensirion though, a while ago. I should try and check that it still works.

I haven't tried with an evaluation kit, but I have a cheap board coming in form Aliexpress soon.

Sensirion details that one should be very careful when handling the sensor, basically using a reflow oven and nothing else, but I was interested in hearing if others have had the experience of soldering one of these chips on a board.

[TDK]

> HAL_I2C_Master_Transmit(&hi2c1, (uint16_t)(0x44 << 1),(uint8_t *)0xFD,1, 1)

This is junk. You want this:

uint8_t data = 0xFD;
HAL_I2C_Master_Transmit(&hi2c1, (uint16_t)(0x44 << 1), &data, 1, 1000);

[averiksen]

Thanks for pointing it out, I changed my code. I increased the timeout to HAL_MAX_DELAY and it seems that it has done the trick. I had this setting before, but maybe with a overheated broken chip. I will look further into it, but I have got a reading now. Thanks for your replies everyone. I'll look into the problem a little more and update if I figure out anything interesting about the setup.

[TDK]

The delay wasn't the issue (although a 1 ms delay is silly). The issue was you were sending whatever random data happens to be at address 0xFD. Whereas you wanted to send the value 0xFD.