Activating I2C --> Pico W RP2040 does not boot correctly

[emefff]

The problem

Hi,
first of all, I am very happy, that RP2040 is included in ESPHome now. Very promising and also cheaper :-).

I tried I2C on two different Pico Ws now. Thus, I am fairly sure they are ok.

Defining I2C the usual way via something like:

i2c:
sda: 26
scl: 27
scan: true
id: bus_a

compiles successfully, OTA also works (see attached logs_test_upload).

But after the upload, the Pico W does not boot or connect to ESPHome (Dashboard in HA shows OFFLINE).

Unplugging the Pico and rebooting shows ONLINE, but the log tells me 'no connection' (see logs_test_logs). Also, uploaded code (like a blinking led or Dallas DS18B20) doesn't seem to be running. Maybe it is in some sort of brown-out-state?

I was under the impression I2C should already work? Or am I too early?

Any hints appreciated, thanks

Mario.
logs_test_upload.txt
logs_test_logs.txt

Which version of ESPHome has the issue?

2022.11.3

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2022.11.4

What platform are you using?

RP2040

Board

Pico W

Component causing the issue

i2c

Example YAML snippet

esphome:
  name: test

rp2040:
  board: rpipicow
  framework:
    # Required until https://github.com/platformio/platform-raspberrypi/pull/36 is merged
    platform_version: https://github.com/maxgerhardt/platform-raspberrypi.git

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "REDACTED"

ota:
  password: "REDACTED"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot in case wifi connection fails
  ap:
    ssid: "Test Fallback Hotspot"
    password: "REDACTED"
    
i2c: 
  sda: 26
  scl: 27
  scan: true
  id: bus_a

Anything in the logs that might be useful for us?

No response

Additional information

No response

[emefff]

Anyone having the same behavior?

[Otherbright]

Hi,

I'm seeing exactly the same behavior. I think there is still a lot of work to do to fully integrate the Pi Pico W into the ESPHome project.

Jon

[emefff]

Hi Jon,

thanks for your answer.

Mario.

[Otherbright]

I get this (truncated) output while compiling the pico micro controller firmware (from the esphome dev interface, on home assistant):

Compiling /data/picow1/.pioenvs/picow1/src/esphome/components/i2c/i2c.cpp.o
In file included from /data/cache/platformio/packages/toolchain-rp2040-earlephilhower/arm-none-eabi/include/c++/10.3.0/vector:72,
                 from /data/cache/platformio/packages/toolchain-rp2040-earlephilhower/arm-none-eabi/include/c++/10.3.0/functional:62,
                 from src/esphome/core/component.h:4,
                 from src/esphome/components/api/proto.h:3,
                 from src/esphome/components/api/api_pb2.h:5,
                 from src/esphome/components/api/api_pb2.cpp:3:
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/arm-none-eabi/include/c++/10.3.0/bits/vector.tcc: In member function 'void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with _Args = {long long unsigned int}; _Tp = long long unsigned int; _Alloc = std::allocator<long long unsigned int>]':
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/arm-none-eabi/include/c++/10.3.0/bits/vector.tcc:426:7: note: parameter passing for argument of type 'std::vector<long long unsigned int>::iterator' changed in GCC 7.1
  426 |       vector<_Tp, _Alloc>::
      |       ^~~~~~~~~~~~~~~~~~~
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/arm-none-eabi/include/c++/10.3.0/bits/vector.tcc: In member function 'std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {long long unsigned int}; _Tp = long long unsigned int; _Alloc = std::allocator<long long unsigned int>]':
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/arm-none-eabi/include/c++/10.3.0/bits/vector.tcc:121:21: note: parameter passing for argument of type '__gnu_cxx::__normal_iterator<long long unsigned int*, std::vector<long long unsigned int> >' changed in GCC 7.1
  121 |    _M_realloc_insert(end(), std::forward<_Args>(__args)...);

[Otherbright]

I'm using a RPI 4 to host Home Assistant and ESP Home. Which system are you using?

[emefff]

My HA OS runs in Virtualbox on a HP Prodesk mini G4 (Intel i8500T) with the VM reserving 8Gb of RAM an 2 cores for HA

[emefff]

@Otherbright
which GPIOs do you use for I2C?

[explo910]

@emefff
After a lot of back and forth, I think I can narrow down the problem.
It seems that the i2c component for the Pico W only works for the i2c0 bus.
When I compile the firmware with ports from the i2c1 bus, it takes a LONG time to come back online after flashing, and the API for viewing logs NEVER comes online. Only OTA works after I get a response via the serial port.

I have no idea why.

Hope this helps!

[emefff]

Thank you!
Now it's getting weirder: according to the pinout on p5 in

https://datasheets.raspberrypi.com/picow/pico-w-datasheet.pdf

we are using the same pins! Only, I used the pin notation (pins 26 and 27) and you used the GPIO notation (in your yaml on #3917 )

It seems using the pin numbers does not work, but using GPIO20 and GPIO21 instead works!

Thanks @explo910 I will close this one for now. It is kind of weird, but it works.

[explo910]

@emefff

Oh, i didnt mention it in my post, but it looks like the Pin numbers will be converted to GPIO numbers automatically.
I tested it with sda: 20 and scl: 21 and it still found the i2c address of my sensor.

Glad it works now!

[emefff]

@explo910 they should be converted, but somehow that does not work with my board, it seems. Also, shouldn't pin 26 be converted to GPIO20? Pins and GPIOs are not equal on this board acc. to the datasheet.

That's why I said, we used the same pins (GPIOs 20/21 and pins 26/27 are the same) and both are I2C0

[N6RDV]

@emefff

Oh, i didnt mention it in my post, but it looks like the Pin numbers will be converted to GPIO numbers automatically. I tested it with sda: 20 and scl: 21 and it still found the i2c address of my sensor.

Glad it works now!

Can you share the sketch please? I'm trying to make rpicow to work with ssd1306_spi OLED display, but as soon as I add I2C section below to the sketch - ESPHome won't reconnect to it to see the logs and have to re-flash to the default state via USB cable

i2c: 
  sda: 26
  scl: 27
  scan: true
  id: bus_a