TWIM driver issue with LSM6DS3TC-R

RE: TWIM driver issue with LSM6DS3TC-R

Susheel Nuguru — Thu, 26 Jan 2023 14:20:29 GMT

nRFX library is available both in nRF5SDK and nRF Connect SDK. You can use nrfx_gpio to configure a pin for its drive strength.

RE: TWIM driver issue with LSM6DS3TC-R

captainfips — Wed, 25 Jan 2023 18:39:14 GMT

Okay... this code works in the nrf5 sdk, I don't know how to configure the drive strength in the connect sdk either.

RE: TWIM driver issue with LSM6DS3TC-R

brian.g — Wed, 25 Jan 2023 15:24:56 GMT

Thanks!

I'm using nrf connect. Total zephyr newbie, still trying to wrap my head around it all.

RE: TWIM driver issue with LSM6DS3TC-R

captainfips — Wed, 25 Jan 2023 15:13:46 GMT

Hi,

Currently this works for me:

#define GYRO_EN NRF_GPIO_PIN_MAP(1,8) // LSM6DS3_PWR
nrf_gpio_pin_set(GYRO_EN);
nrf_gpio_cfg(GYRO_EN, NRF_GPIO_PIN_DIR_OUTPUT, NRF_GPIO_PIN_INPUT_DISCONNECT, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_D0H1, NRF_GPIO_PIN_NOSENSE);
nrf_delay_ms(35);

Are you using nRF SDK or nrf connect?

RE: TWIM driver issue with LSM6DS3TC-R

brian.g — Mon, 23 Jan 2023 22:38:11 GMT

Also have an issue getting the sensor communicating. What did you use to change the output drive strength. I tried using

gpio_pin_configure_dt(&enableIMU, GPIO_DS_ALT_HIGH);

with no luck. Thanks.

RE: TWIM driver issue with LSM6DS3TC-R

captainfips — Thu, 27 Oct 2022 13:20:52 GMT

Hi,

yesterday I found the issue with my configuration after looking at the oscilloscope pictures again. The only possible reason for the I2C lines not to remain at Vcc after enabling the Power pin was simply that there wasn't enough power. In the nrfx_gpiote driver I found out that the default output drive strength for a gpiote_out_simple config was standard (S0S1). I changed my code to enable the power pin with drive strength S0H1 and it works perfectly now.

So thanks for your suggestions and I will verify one answer as a solution.

Best regards!

RE: TWIM driver issue with LSM6DS3TC-R

Nguyen Hoan Hoang — Tue, 25 Oct 2022 21:14:25 GMT

Sorry I didn't see it. There is something else however. The LSM6DS3 is powered by a gpis pin 1.08. Have you enable it ? Configure it as output and set it to high ?

RE: TWIM driver issue with LSM6DS3TC-R

captainfips — Mon, 24 Oct 2022 09:38:32 GMT

It has two 10k Pulup resistors. They are drawn in the middle of the same page as the gyro sensor in the schematic...

RE: TWIM driver issue with LSM6DS3TC-R

Nguyen Hoan Hoang — Mon, 24 Oct 2022 07:02:26 GMT

I2C requires pull-ups on both SDA & SCL. The board does not have those resistors therefore you must enable it in the driver.

RE: TWIM driver issue with LSM6DS3TC-R

Susheel Nuguru — Sun, 23 Oct 2022 18:20:07 GMT

I am not familiar with this sensor but looking at its data sheet it seems like it is possible to configure the sensor to control the pull of the SDA and SCK pins.

There are three things

Pull configuration from the master side of the actual SDA/SCK pins that are connected to the sensor.
Pull configuration from the sensor side of the actual SDA/SCK pins that are connected to the sensor.
pull configuration of the fork pins you are using that are connected to the oscilloscope. Maybe at powerup the ppi/gpiote configuration you made to simulate a fork of the sda/sck pins have a bug?

I suspect that what you are seeing might be something else than what is going on the actual pins. I would recommend you to set the gpio state of the forked (SDA/SCK) pins to a known state at startup before connecting those fork pins to the PPI/GPIOTE combo. If you do that then we can atleast exclude point number 3.

RE: TWIM driver issue with LSM6DS3TC-R

captainfips — Sun, 23 Oct 2022 12:46:30 GMT

Hi,

I just added the config of the ppi peripheral to mirror the i2c lines to accessible pins on the breakout boards, which works as it should: Blue=SCK Red=SDA Green=Power of the LSM6DS3. The next image shows the lines when the sensor is working:

Now if I just unpower and power the board back on, nothing happens on SCK and SDA lines :

I even tried "power cycling" the gyro sensor by turning the 6D_PWR line in the schematic on and off like this:

but the data and clock line remain low, as if the sensor would pull them low, even though it isn't powered...

Regards, Fabian

RE: TWIM driver issue with LSM6DS3TC-R

Susheel Nuguru — Mon, 17 Oct 2022 17:49:33 GMT

yes, you cannot change the TWIM driver config but to use gpiote api

RE: TWIM driver issue with LSM6DS3TC-R

captainfips — Mon, 17 Oct 2022 12:29:05 GMT

I will try that later, I don‘t have time at the moment. For the GPIOTE in event config I have to use the RAW config macro to not change the pin config of the twim driver?

- Fabian

RE: TWIM driver issue with LSM6DS3TC-R

Susheel Nuguru — Mon, 17 Oct 2022 10:53:04 GMT

Fabian,

You should e able to configure the GPIOTE in event mode and make it listen to the TWI pins to generate events. You can use these events to route it through PPI fork TEP to change another gpio pin to toggle the same way as the first input pin to GPIOTE.

RE: TWIM driver issue with LSM6DS3TC-R

captainfips — Wed, 12 Oct 2022 12:21:16 GMT

Hi,

yes, the problem definitely is that of the three TWIM events that are checked occurs. I already tried it without the no event handler flag, and also in debug vs release mode - no difference in behaviour. I even tried to check the ERRORSRC Register in the twim driver as well, but neither the ANACK nor the DNACK bit is set. Also Logging basically everything shows the same result.

I am not using the TRACE lines - even checked the nrf.h file for the project in SES, but everything seems to be initialised (deactivated) correctly.

The problem with oscilloscope data is, that the gyro sensor is not accessible on the xiao board. I thought of routing the gpios to other ones via PPI, to simply mirror the SCL and SDA lines to other pins that are accessible with the oscilloscope. Could that work or does the SDK/hardware not allow such functionality?

Best regards!

RE: TWIM driver issue with LSM6DS3TC-R

Susheel Nuguru — Wed, 12 Oct 2022 12:07:56 GMT

It is a bit difficult to say what is wrong, but the loop in which it is stuck seems to say that the transfer was initiated and none of the events occurred in the hardware. Without oscilloscope data we can only guess few things.

If you suspect if it has something to do with NRFX_TWIM_FLAG_NO_XFER_EVT_HANDLER enabled, then disable it and give the proper event handler just for testing.
Try to debug this with logs/prints and not using TRACECLK if you suspect this could be issue. If the program behaves differently in debug mode and in normal mode, then it is likely that it has to do with shared pins with debug interface.