cancel
Showing results for 
Search instead for 
Did you mean: 

LIS2DH I2C wrong adresse compared to the documentation - Writing in register impossible

LSegu
Associate II

Hi,

I am currently using a STEVAL-MKI135V1 with a LIS2DH mounted on.

According to the datasheet, the adress is supposed to be 0x31 or 0x33 (depending on the SD0 pin pulled down or low).

I use an ATSAML11 mounted on the board SAML11 XplainedPro. I use the I2C bus declard in the Atmel Start Project to do so with the HAL driver SYNC.

The thing is that my I2C bus recognizes the LIS2DH at the address 0x18 or 0x19. Why? Also, I can read in all the register (the WHO_AM_I register shows me 0x33 as it is supposed to be) but it seems I can not write inside the registers to put the LIS2DH in "power-up mode".

According to the datasheet, the valuye in the CTRL_REG1 = 0x07 shows that it stays in power-down mode wherever I try to write in the registers.( And by the way, the readings and writing functions return the value '0' as they should.)

Someone has already faced this issue?

6 REPLIES 6
Eleon BORLINI
ST Employee

HI Lambert, about the I2C SAD issue, please consider this table on the I2C of the ds document:

0690X0000089uhpQAA.png

0x31 or 0x33 is the SAD+R bit [on overall 8bit]. So if you have to define the only SAD, you have to use the SAD[6:1]+SAD[0], which is in binary 0011000 and 0011001, that is 0x18 and 0x19 in hex notation.

Don't know however if the right data interpretation could be related also to the other issue (to write a reg you have to write 0x30 or 0x32 in the 1st I2C transmitted byte

Regards

AvaTar
Lead

The standard mode address on the I2C bus is 7 bits. The eights bit is added automatically (R/W access).

Howthis 7 bit is treated depends on the MCU, the master on the bus.

Some automatically shift it left one bit, others use it directly, ignoring bit 0. Yours does the shipt, supposedly.

Read the reference manual/datasheet/programming manual/user manual - however Atmel/Microchip calls the detailled description of the MCU + peripherals.

Thank you, but I already studied this array and I tried to bypass the Atmel driver by writing 0x30 in the first transmitted byte, no success...

S.Ma
Principal

Just radar sweep all addresses and feel progressing.

LSegu
Associate II

Already done, the Terminal prints the adresse 0x18 as the MEMS and that is all. The writing command still does not work.

RPaja.1
Associate II

Hi, STEVAL-MKI135V1 have SA0 internaly pull-up, as you can see in the table the "byte address" per read is 0x32

Maybe is a bug but in the driver use example provided by ST in repository (https://github.com/STMicroelectronics/STMems_Standard_C_drivers/blob/master/lis2dh_STdC/examples/lis2dh_read_data_polling.c)

use the same "address byte" for reading and writting ( LIS2DH_I2C_ADD_L = 0x31U// SA0 = 0)

HAL_I2C_Mem_Read(handle, LIS2DH_I2C_ADD_L, reg, I2C_MEMADD_SIZE_8BIT, bufp, len, 1000);

HAL_I2C_Mem_Write(handle, LIS2DH_I2C_ADD_L, reg, I2C_MEMADD_SIZE_8BIT, (uint8_t*) bufp, len, 1000);

From my point of view, you need to add for write ( RWbit to 0):

HAL_I2C_Mem_Write(handle, LIS2DH_I2C_ADD_L & 0xFE, reg, I2C_MEMADD_SIZE_8BIT, (uint8_t*) bufp, len, 1000);