nRF54L15-DK I2C voltage issues with sensors failing to be detected as "ready" unless voltage reduced to below 3.3V

[zpm1066]

Hello,

As part of an effort to migrate applications to nRF5415 devices, I've encountered voltage sensitivity issues when using existing sensors (bme688, bme280). After reviewing and trying out various overlay & pinctrl settings for a few days and cross-referencing them against the nRF5L15-DK pin assignments , I was at a loss as to why the sensors were not being recognized. 

I decided to vary the nRF54L15DK VDD using the Nordic Board Configurator (v1.1.3). As soon as the VDD was dropped below 3.3V to 2.5V and then 1.8V, the BME sensors got detected as "Ready" and they worked flawlessly. The SSD1306 OLED displays that are being used with the nRF54L15DK worked without any issues in the range 1.8V - 3.3V.

I suspect the issue may be to do with I2c sensor driver or perhaps the way nRF54L15DK works with I2C that causes these sensors not to be detected.  

The BME280 and BME688 sensors (Pimoroni) are rated at 2V-5V range. They have been working without any issues at 1.8v - 3.3V on several existing devices (nRF52840, nRF5340, Raspberry Pi Pico, and ESP32). 

In the tests conducted with nRF54L15-DK, the BME280 and BME688 sensors failed to be detected in "ready" state unless the voltage was reduced below 3.3V. For BME280, the working range was found to be in the range 1.8V- 2.7V , and 1.8-V-2.4V for BME688. The sensors were configured to use the internal pull-ups. 

The Board Configurator was used to vary the voltage range. The TWIM_SDA, TWIM_SCL and VDD on the nRF54L15-DK  were verified for the voltage range using a multimeter. Unfortunately, as I currently don't have an oscilloscope, I wasn't able to look at I2C signal timings, etc.

Below are the configuration and overlay used with the nRF54L15-DK.

I've used quite a few I2C sensors on multiple platforms but haven't encountered such behaviour before.

Do you have any suggestions as to why the peculiar voltage behaviour of the nRF54L15DK with these sensors? Thank you.

Environment:

• nRF54L15DK with nRF Connect SDK 3.2.1 on macOS 15.7.3 and latest VS Code / nRF Connect

Devices used

• nRF54L15-DK, Particle_Xenon (nRF52840), and Thingy53

nRF and Zephyr samples

• Verified sensor I2C detection on nRF54L15-DK with samples bme68x_iaq and bme280 

Sensors

• BME688 (Pimoroni, rated at 2-5V)
• BME280 (Pimoroni, rated at 2-5V)

I2C overlay

• Used i2c22 
• Also tested with i2c21  (pinctrl TWIM_SDA  1,12 and TWIM_SCL 1,11)

&i2c22 {
    /delete-property/ status;compatible = "nordic,nrf-twim";
    compatible = "nordic,nrf-twim","i2c-device";
    status = "okay";
    clock-frequency = <I2C_BITRATE_FAST>;
    zephyr,concat-buf-size = <4096>;
    pinctrl-0 = <&i2c22_default>;
    pinctrl-1 = <&i2c22_sleep>;
    pinctrl-names = "default", "sleep";
    
    bme688: bme688@76 {
        compatible = "bosch,bme680";
        reg = <0x76>;
    };
};

&pinctrl {
    i2c22_default: i2c22_default {
        group1 {
            psels = <NRF_PSEL(TWIM_SDA, 1, 12)>,
                    <NRF_PSEL(TWIM_SCL, 1, 11)>;
                    nordic,drive-mode = <NRF_DRIVE_H0H1>;
                    bias-pull-up;         
        };
    };

    i2c22_sleep: i2c22_sleep {
        group1 {
            psels = <NRF_PSEL(TWIM_SDA, 1, 12)>,
                    <NRF_PSEL(TWIM_SCL, 1, 11)>;
                    low-power-enable;
        };
    };
};

prj.conf

CONFIG_SENSOR=y
CONFIG_SENSOR_INFO=y

CONFIG_BME680=n
CONFIG_BME68X_IAQ=y

#I2C configuration
CONFIG_I2C=y
CONFIG_I2C_SHELL=y
CONFIG_I2C_LOG_LEVEL_DBG=y

CONFIG_APP_TRIGGER=n

nRF54L15-DK and SSD1306 OLED setup with a Sparkfun QWICC multiplexer.

Results

• nRF52840 and Thingy53
  • No issues
  • Both BM688 and BME280 worked, as expected, with device and sensor voltages at 3.3V.
    
    
• nRF54L15-DK
  • Sensors BME280 and BME688 were not detected on the I2C at VDD 3.3V. “Device not ready” message observed.
  • However, SSD1306 was detected correctly at 3.3V
  • Using the Board Configurator v1.1.3, tried several setting between 1.8V to 3.3.V
    
    
  • BME280 sensor was detected and output sensor values correctly for voltage range 1.8V - 2.7V. Failed to be detected on I2C above 2.7V.
  • BME688 sensor was detected successfully on the I2C bus for voltage range 1.8V - 2.4V. It failed I2C detection above 2.4V
    
    

BME688 console output - VDD set to 2.4V

*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:00.018,858] <inf> app: App started
uart:~$ 
[00:00:05.018,951] <inf> app: temp: 25.80; press: 100549.60; humidity: 27.91; iaq: 50; CO2: 500.00; VOC: 0.49
uart:~$  device list
devices:
- clock@10e000 (READY)
  DT node labels: clock
- gpio@10a000 (READY)
  DT node labels: gpio0
- gpio@d8200 (READY)
  DT node labels: gpio1
- gpio@50400 (READY)
  DT node labels: gpio2
- uart@c6000 (READY)
  DT node labels: uart20
- rram-controller@5004b000 (READY)
  DT node labels: rram_controller
- i2c@c8000 (READY)
  DT node labels: i2c22
- spi@4a000 (READY)
  DT node labels: spi00
- mx25r6435f@0 (READY)
  DT node labels: mx25r64
- temp@d7000 (READY)
  DT node labels: temp
- bme688@76 (READY)
  DT node labels: bme688
[00:00:15.019,052] <inf> app: temp: 24.27; press: 100546.75; humidity: 29.87; iaq: 50; CO2: 500.00; VOC: 0.49
uart:~$ 

i2c scan i2c22: BME688 detected at address 0x76

uart:~$ i2c scan i2c22
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:             -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- 76 --                         
1 devices found on i2c22

BME688 console output - VDD set to 3.3V

[00:00:00.016,272] <err> bsec: Failed to init bme68x: -2
*** Booting nRF Connect SDK v3.2.1-d8887f6f32df ***
*** Using Zephyr OS v4.2.99-ec78104f1569 ***
[00:00:00.016,499] <inf> app: App started
uart:~$ 

i2c scan i2c22: Failed to detect BME688 on the I2C bus

uart:~$ i2c scan i2c22
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:             -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
0 devices found on i2c22
[00:00:05.016,590] <err> app: device is not ready
uart:~$ 
uart:~$ i2c scan i2c22
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:             -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
0 devices found on i2c22

[Håkon Alseth]

Hi,

 

In order to run 400 kHz I2C, you will need a stronger pull resistor than the internal pull on the nRF gpio, which is nom. 13 kOhm.

You want 5kOhm or lower.

You can look at the SDA/SCL lines with an oscilloscope to confirm how the waveform looks.

 

Can you please try to add stronger pull-resistors, and see if the system starts to behave more stable?

Kind regards,

Håkon

[zpm1066]

Hi Håkon,

Thank you for the quick response. Very much appreciated!

I tried using 100 KHz I2C (I2C_BITRATE_STANDARD) with the internal pull on the nRF GPIO. This behaves the same as previously. The BME688 sensors again work only at 2.4V or below but the SSD1306 works up to 3.3V.

It is somewhat strange that at I2C_BITRATE_FAST, the SSD1306 has no issue on I2C bus with the internal pull resistors.

As per your suggestion, I'll try 5kOhm resistors on the SDA/SCL GPIOS to see if it makes any difference.


Best Regards,
Ravi

[zpm1066]

Hi Håkon,

Thank you for the quick response. Very much appreciated!

I tried using 100 KHz I2C (I2C_BITRATE_STANDARD) with the internal pull-up on the nRF GPIO. This behaves the same as previously. The BME688 sensors again work only at 2.4V or below but the SSD1306 works up to 3.3V.

Update:

With I2C_BITRATE_STANDARD and bias-pull-up disabled, I tried using 4.7kOhm on the SDA/SCL GPIOS to see if it makes any difference. Unfortunately, not much of a difference. The BME sensors were not stable at anything much higher than 1.8V. SSD1306 display was fine at 3.3V, same as with internal pull-up.

Best Regards,
Ravi

[Håkon Alseth]

Hi,

 

Your sensor seems to be a module, more specifically this one:

https://shop.pimoroni.com/products/adafruit-bme688-temperature-humidity-pressure-and-gas-sensor-stemma-qt?variant=39358272798803

 

Which states:

For your convenience, Adafruit have pick-and-placed the sensor on a PCB with a 3.3V regulator and some level shifting, so it can be easily used with your favorite 3.3V or 5V microcontroller.

 

Although the IC accepts lower voltage, your module does not seem to do this.

 

Kind regards,

Håkon

[zpm1066]

Hi Håkon,

Actually the BME280 and BME688 sensors we're using are from Pimoroni.

We've been using these for several years on a number of devices, including nRF9151-DK, nRF5340-DK, nRF52840, ESP32, and Raspberry Pi Picos without any issues at voltages up to 3.3V and at both I2C_BITRATE_STANDARD / I2C_BITRATE_FAST settings.

It's only the nRF54L15-DK that seems to be problematic.

The Pimoroni BME280 and BME688 are rated at 2V-5V range, have I2C level shifting and 10KOhm pull-ups. So, don't quite understand why they don't work with the nRF54L15-DK at 3.3V. Problems start with voltages above 2.4V.

The Adafruit BME688 in your link above also provides the same 10KOhm pull-ups with level-shifting.

Best Regards,
Ravi

 

[Håkon Alseth]

Hi,

 

Can you share the logic trace when trying to communicate?

Please share both working and non-working scenario.

  

Kind regards,

Håkon