Zephyr: nrf51_ble400.dts i2c pins inverted

[aleksmarcelo]

Describe the bug
On nrf51_ble400.dts the i2c pins are inverted.
on boards/arm/nrf51_ble400/nrf51_ble400.dts, it is:

&i2c0 {
    status = "okay";
    sda-pin = <0>;
    scl-pin = <1>;
    /* smba-pin = <2>; */
};

Must be: (Works only with this configuration):

&i2c0 {
    sda-pin = <1>;
    scl-pin = <0>;
};

To Reproduce

#define DISPLAY_DRIVER      DT_INST_0_SOLOMON_SSD1306FB_LABEL
...
  dev = device_get_binding(DISPLAY_DRIVER);
  printk("Device display=%d \n", dev);

Expected behavior
Expect to work with the default dts file (nrf51_ble400.dts)

Impact
Must define an overlay correcting the wrong pin definition.

Screenshots or console output
None

Environment (please complete the following information):
Linux delpix 5.5.0-050500-generic #202001262030 SMP Mon Jan 27 01:33:36 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

-- Zephyr version: 2.2.0-rc3
-- Found PythonInterp: /usr/bin/python3.6 (found suitable version "3.6.9", minimum required is "3.6")
-- Selected BOARD nrf51_ble400
-- Found west: /home/aleks/.local/bin/west (found suitable version "0.7.2", minimum required is "0.6.0")

Additional context
-

[carlescufi]

@aleksmarcelo would you mind sending a Pull Request to fix this?

[aleksmarcelo]

No, will be a pleasure! But, anyone is facing the problem you need to reset the MCU to start the communication in the I2C bus ?

[carlescufi]

No, will be a pleasure! But, anyone is facing the problem you need to reset the MCU to start the communication in the I2C bus ?

That I don't know but perhaps @anangl does.

[anangl]

No, will be a pleasure! But, anyone is facing the problem you need to reset the MCU to start the communication in the I2C bus ?

That I don't know but perhaps @anangl does.

No, I haven't heard of such issue. You need to reset it (with the RESET button, I assume) after flashing?

[aleksmarcelo]

I't seems the ssd1306 isn't right initialized in the ssd1306 / display driver. And the hardware (nrf51822) need some time to "wake up".
I am studying some zephyr driver implementation concepts to make a PR.

[pabigot]

I can't speak to why the display driver doesn't work, but:

• The BLE400 schematics clearly show SDA is P0.0 and SCL is P0.1;
• Continuity tests on the board confirm the P0.0 is connected to the pin labeled SDA on the I2C header;
• Plugging a Waveshare LSM303DLHC board into the BLE400 I2C header shows it works as intended.

So whatever the problem with SSD1306FB might be, the I2C pins are assigned correctly in devicetree for this platform.

[aleksmarcelo]

That's weird ! Mine works only if you invert the pins.

The display works, but it seems the nrf51822 need some extra time to start the i2c bus, so you need to put a delay at the beginning and and send some i2c commands to activate the oled display.

But, thank you for your answer; i was just sending a pull request...

Would be nice, if someone else with this board could make a try! I am using shields with the module N51822 QFAAHZ

[aleksmarcelo]

Hi @pabigot,
have you tried any I2C code using the ble400?

[pabigot]

Yes, I've done a lot with it. Multiple sensors and the LSM303DLHC I used to verify the pin assignment is correct. I do have some Waveshare OLED displays that worked fine in my own framework, don't remember whether I ever tried Zephyr with them.

[aleksmarcelo]

So, the problem seems to be deeper.
Couldnt it be a problem in the I2C pin assignment in the I2C initializer ?

Never mind. I made a git update in the zephyr repository and the problem is gone...