NAU88C22 Design Review

Hallo,

Gibt es nur einen I2C Bus? Der NAU ist nicht nur mit dem ESP32 verbunden, sondern auch mit dem STM. Was macht der?

VG

Ja, es gibt nur den einen I2C-Bus. Der STM32 arbeitet da quasi als i/o extender (quasi PCA9685+PCA9655+ADS1115+MCP4725). Zum jetzigen Zeitpunkt ist er aber noch stillgelegt. Also: Alle Pins High-Z.

Vg Klaus

Mit welcher Frequenz wird der I2C-Bus betrieben? Im NAU-Datenblatt steht darüber nichts. Also verträgt er wohl nur den Standard, was 100kBit sind.

VG

Ja, 100kHz.

Vg Klaus

Kannst du den Schaltplan mal als PDF exportieren? Dann kann man auch ohne Kicad draufschauen :)

Eventuell ist der 4K7 Pullup zu hochohmig. Es sind doch viele ICs dran angeschlossen, was die Anstiegsflanke ziemlich verschleift. Schon Mal mit einem Oszilloskop gemessen?

VG

Hannes schrieb:

Kannst du den Schaltplan mal als PDF exportieren? Dann kann man auch ohne Kicad draufschauen :)

Gerne. Anbei die aktuelle Version (leichte Modifikationen, nichts I2C-relevantes

Georg P. schrieb:

Eventuell ist der 4K7 Pullup zu hochohmig. Es sind doch viele ICs dran angeschlossen, was die Anstiegsflanke ziemlich verschleift. Schon Mal mit einem Oszilloskop gemessen?

Anbei eine die Hardcopy eines ständigen Pings auf die Adresse des NAU88C22. Sieht m.E. ok aus.

Ich hatte zum Testen übrigens sowohl auf SDA als auch auf SCL einen weiteren 4K7 parallel geschaltet. Damit komme ich auf 2k35 und damit nahe an die empfohlene Untergrenze des PullUp von 2k0 ran.

Es gibt verwirrende Neuigkeiten!

Ich habe den ESP32 zum Testen mal ruhig gestellt (direkt eine Endlos-Schleife) und dafür mal den STM32 aufgeweckt und mit dem Arduino-Framework einen I2C-Scanner implementiert. Der findet alle I2C-Teilnehmer, also den AHT20, den LSM6 UND (!!!!) den NAU88C22 auf Adresse 0x1A.

Natürlich direkt den umgekehrten Weg ausprobiert (STM32 ruhig stellen und ESP32 wieder als I2C-Master einsetzen), aber kein Erfolg.

Einen Reim darauf machen kann ich mir noch nicht, aber zumindest unter bestimmten (magischen?) Umständen scheint die Hardware mal zu funktionieren. Sind das irgendwelche hauchzarten Timing-Themen beim ESP32?

vg Klaus

Darf CSB vom BMEx280 floaten?

Uwe B. schrieb:

Darf CSB vom BMEx280 floaten?

Uuups, nein, darf er nicht, er muss auf V_DDIO, also in meinem Fall auf 3V3. Vielen lieben Dank für den Hinweis! Schaltplan und Layout habe ich lokal bereits korrigiert und werde das zeitnah im Github bereit stellen!

Leider löst das aber nicht das Problem. Wie aus dem Schaltplan (möglicherweise nicht deutlich genug) hervorgeht, ist der BMx280 alternativ zum AHT20 zu bestücken. Derzeit ist er NICHT bestückt. Übrigens werden derzeit auch ganzen "Steckplätze" für die diversen I2C-Module (SCD40, BH1750 ...) nicht genutzt.

Bei meinem derzeitigen Test hängen konkret folgende Teilnehmer am I2C-Bus:

• NAU88C22
• AHT20
• LSM6DS3
• STM32 (zumindest, wenn die I2C-Slave-Variante der Firmware im Flash ist)

Leute, ich möchte dieses Thema erstmal pausieren.

Mit einem komplett reduzieren Testprogramm, das im ESP-IDF nur den I2C initialisiert und dann einen "Probe" auf die Adresse des NAU88C22 macht, bekam ich ein Acknowledge. Den Code habe ich quasi 1:1 aus meinem Hauptprojekt übernommen.

1

#include <driver/i2c_master.h>

2

#define TAG "MAIN"

3

#include "esp_log.h"

4

5

void app_main(void)

6

{

7

    i2c_master_bus_handle_t bus_handle;

8

    i2c_master_bus_config_t i2c_mst_config = {

9

        .i2c_port = 0,

10

        .sda_io_num = 4,

11

        .scl_io_num = 5,

12

        .clk_source = I2C_CLK_SRC_DEFAULT,

13

        .glitch_ignore_cnt = 7,

14

        .intr_priority = 0,

15

        .trans_queue_depth = 0,

16

        .flags = {

17

            .enable_internal_pullup = 1,

18

        }};

19

    i2c_new_master_bus(&i2c_mst_config, &bus_handle);

20

21

    for (uint8_t i = 0; i < 128; i++)

22

    {

23

        if (i2c_master_probe(bus_handle, i, 100) != ESP_ERR_NOT_FOUND)

24

        {

25

            ESP_LOGI(TAG, "Found I2C-Device @ 0x%02X", i);

26

        }

27

    }

28

}

Es scheint, als gäbe es eine sehr seltsame Wechselwirkung in meinem Hauptcode, die aber offensichtlich nur die I2C-Adresse 0x1A betrifft. Jedenfalls habe ich einen funktionierenden Startpunkt, von dem ich jetzt selbst weiter forschen kann. Ich werde jetzt mal meinen Hauptcode komplett reduzieren und dann Schritt für Schritt wieder aufbauen. Hoffentlich komme ich dadurch dem Problem auf die Schliche. Meine Vermutung, dass ich im Hardware-Design einen Fehler gemacht habe, hat sich nicht bestätigt.

Euch allen möchte ich für Eure Unterstützung sehr herzlich danken!

Viele Grüße

Klaus

Hallo zusammen,

ich melde mich wieder - das Problem ist noch nicht gelöst. Die Aussage aus dem vorherigen Post muss ich insofern erweitern, als dass es sich dabei um einen sehr sehr seltenen Ausnahmefall gehandelt hat. Per Log zweifelsfrei dokumentieren konnte ich das nur noch ein einziges mal.

Spannend ist aber das folgende: Ich habe testweise den ESP32 zum Nichtstun animiert (app_main(){while(true) vTaskDelay(100)}) und den STM32 zum I2C-Master gemacht und einen I2C-Scanner implementiert. Zur Erinnerung: der STM32 arbeitet eigentlich als I2C-Slave als I/O-Expander für den ESP32. Der STM32 findet den NAU88C22 immer! Ich habe auch dann eine Aufnahme mit dem Oszilloskop gemacht, um mögliche Unterschiede zu erkennen. Was fällt da auf?: Bei STM32 ändert sich SDA mit nicht sichtbarer Verzögerung, wenn SCL auf Low geht, beim ESP32 gibt es eine sichtbare Verzögerung von etwa 1us. Beides ist meines Erachtens OK, wobei mir das Verhalten des ESP32 fast besser gefällt...

Ich habe wegen dieser Thematik bereits hier https://www.esp32.com/viewtopic.php?f=13&t=41437&start=10 einen Thread gestartet, aber ein Ergebnis haben wir leider noch nicht. Vielleicht gibt es unter Euch noch jemanden, der mit einen Tipp, Rat oder Hinweis geben kann?

Vielen lieben Dank und viele Grüße

Klaus