2

after stumbling upon very strange thing I would like to find out if anyone could provide reasonable explanation.

I have SHT31 humidity sensor running on I2C and after trying to run it on STM32F2 it didn't work.

uint8_t __data[5]={0};

__data[0] = SHT31_SOFTRESET >> 8;
__data[1] = SHT31_SOFTRESET & 0xFF;


HAL_I2C_Master_Transmit(&hi2c3,((uint16_t)0x44)<<1,__data,2,1000);

I have opened the function and saw:

/**
  * @brief  Transmits in master mode an amount of data in blocking mode.
  * @param  hi2c Pointer to a I2C_HandleTypeDef structure that contains
  *                the configuration information for the specified I2C.
  * @param  DevAddress Target device address: The device 7 bits address value
  *         in datasheet must be shifted to the left before calling the interface
  * @param  pData Pointer to data buffer
  * @param  Size Amount of data to be sent
  * @param  Timeout Timeout duration
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_I2C_Master_Transmit(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{
  /* Init tickstart for timeout management*/
  uint32_t tickstart = HAL_GetTick();

  if (hi2c->State == HAL_I2C_STATE_READY)
  ....... and it goes ....

So I followed the comment and frustration from my scope (looking why my bits are not going on the wire) and did: 

HAL_I2C_Master_Transmit(&hi2c3,((uint16_t)0x44)<<1,__data,2,1000);

Finally my bits are going out and device ACKs me back - voila it works!

But why?? What would be the reason behind putting burden on the programmer to shift the address?

user505160
  • 1,176
  • 8
  • 25
  • 44

3 Answers3

2

Because the programmer should probably be made aware if he wants to read or write data to or from the I2C slave device.

In common I2C communication the first seven bits of the "address byte" contains the slave address, whereas the last bit is a read/write bit. 0 is write and 1 is read.

In your case, you want to write data to the device (to perform a soft reset) and therefore a simple left shift will do the trick.

Michael Heil
  • 16,250
  • 3
  • 42
  • 77
  • 2
    In this case this is not the right argument, as the STM32 HAL explicitly specifies _Transmit and _Receive i2c routines that could as well add the addr LSB and just let the programmer input the 7-bit address from the datasheet. To make matters worse, the HAL_I2C_Init() function requires a config option that says I2C_ADDRESSINGMODE_7BIT (not 8BIT). It's just an annoyance as the first time you encounter this waste of time, you learn to never trust I2C documentation and APIs... :) – BjornW Sep 24 '21 at 13:15
2

It has never been agreed whether an I2C address is to be specified:

  1. such that it needs to be shifted for transmission, or
  2. such that it does not need to be shifted for transmission.

Therefore some device datasheets specify it in variant 1 and some in variant 2. Similarly, some I2C APIs take the address in variant 1 and some in variant 2.

If the device and the API use a different variant, it's the programmer's burden to shift the address.

It creates a lot of confusion and is quite annoying. I doubt it will every be clarified.

Codo
  • 75,595
  • 17
  • 168
  • 206
0

Sorry for the late reply, I just bumped my head against this myself. This should be considered a bug but ST refuses to acknowledge it as such. If you research the reference manual for the I2C section, the OAR1 register states that the address is stored in bits 7:1 for 7 bit mode. Bits 0, 8 and 9 are ignored. The HAL routine that sets the address should then shift the 7 LSB's so that bits 6:0 of your address get written to bits 7:1 of the OAR1 register. This doesn't happen. Essentially, because the code was released, it is now a "feature" and not a bug. Another way to look at it is that the address byte that you send to the HAL is left aligned. This is extremely irritating as it is not consistent for 7 and 10 bit addresses.

Charles Maxim
  • 1