Zephyr i2c_write_dt Fehlermeldung trotz erfolgreichem Transfer

Schwierig schrieb:

Debuggen ist mit vscode etwas "na ja"; letzendlich wird in i2c_write_dt() wohl i2c_write() aufgerufen, was wiederum i2c_transfer() aufruft und letztendlich die -5 liefert.

Was sagt denn die Doku der Funktion? Ist ein Rückgabewert von -5 überhaupt ein Fehlerwert? Und wenn ja: welche Bedeutung hat dieser Fehler?

-5 bedeutet "-EIO (general input / output error". Laut Doku soll das kommen, wenn vom Slave ein NACK kommt. Tut es aber nicht. Häufigste Ursache sind wohl vergessene Pull up. Aber der Transfer funktioniert ja nachweislich. Der einzig andere Rückgabewert ist 0 für alles in Ordnung.

Schwierig schrieb:

-5 bedeutet "-EIO (general input / output error". Laut Doku soll das kommen, wenn vom Slave ein NACK kommt. Tut es aber nicht. Häufigste Ursache sind wohl vergessene Pull up.

Oder ein Bug in der Treiberroutine, hier also in i2c_transfer(). Muss so sein, hast du ja selbst durch Messung/Funktionsprüfung festgestellt.

Also: Man muss sich anschauen, was i2c_transfer() wohl falsch macht. Wobei dabei natürlich durchaus herauskommen kann, dass garnicht die Routine selber schuld ist, sondern ein Bug in der I2C-Hardware, die sie verwendet.

Lösung gefunden: Im Device Tree möchte der µC anscheinend gerne "sein" I2C-Attribut im Overlay haben:

1

&i2c0 {

2

    compatible = "nordic,nrf-twim";

3

    status = "okay";

4

    clock-frequency = <I2C_BITRATE_STANDARD>;

5

    my_sht40: my_sht40@44{

6

        compatible = "i2c-device";

7

        reg = < 0x44 >;

8

        label = "MY_SHT40";

9

        status = "okay";

10

    };

11

    clock-frequency = <I2C_BITRATE_STANDARD>;

12

13

    pinctrl-0 = <&i2c0_default>;

14

   pinctrl-1 = <&i2c0_sleep>;

15

    pinctrl-names = "default", "sleep";

16

};

17

18

&pinctrl {

19

  /omit-if-no-ref/ i2c0_default: i2c0_default {

20

    group1  {

21

      psels = <NRF_PSEL(TWIM_SCL, 0, 27)>,

22

             <NRF_PSEL(TWIM_SDA, 0, 26)>;

23

          bias-pull-up;

24

    };

25

  };

Also: compatible = "nordic,nrf-twim"; statt compatible = "i2c-device"; obwohl es im Nordic-Beispiel explizit als "allgemeines" I2C-Beispiel mit "i2c-device" beschrieben ist: https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-6-serial-com-i2c/topic/exercise-1-6-2/

Schwierig schrieb:

Lösung gefunden: Im Device Tree möchte der µC anscheinend gerne "sein" I2C-Attribut im Overlay haben: [c] &i2c0 { compatible = "nordic,nrf-twim";

Also passte also wohl tatsächlich der Treiber nicht ganz zur Hardware und muss entsprechend "hingedengelt" werden.

Interessant wäre hier noch, zu testen, was passiert, wenn dann tatsächlich mal kein ACK vom Target kommt. Nur wenn dann wieder -5 vom Treiber kommt, hast du wirklich eine valide Lösung gefunden.

Das funktioniert. Zumindest wenn man einen anderen Sensor nimmt und SCL und SDA vertauscht...