Liebe Community, ich brauche Eure Hilfe bei meinem lab@home-Projekt. Seit mehreren Tagen suche einen Fehler im Design rund um den NAU88C22 Codec und finde ihn nicht. Vielleicht ist das Design für den einen oder anderen interessant. Zumindest einige von Euch haben eine Vorstellung, wenn sie diese Liste lesen: ESP32s3 + STM32G431 + NAU88C22 + DRV8313 + MAX3485 + SN65HVD230 + 4x WS2812 + LSM6DS3 + AHT20 + DS18B20 + IP5306 + TPS54202 + ST7789 + (optional: W5500 | NRF24l01 | SIM7080G | RFM95W) :-) Das KiCad-Projekt in der Version, die ich bei JLCPCB bestellt und hier zum Testen vorliegen habe, findet ihr hier: https://github.com/klaus-liebler/labathome/tree/a9d548a83eaae0b1662cdade2c64cd28fdfa974e/labathome_pcb15 . Das relevante Sheet heißt audioamplifier.sch. Das Problem ist schnell formuliert: Der NAU88C22 ist nicht per I2C erreichbar. Ich bekomme also auf ein Ping mit seiner Adresse kein ACK. Was habe ich bereits getestet (und welche Fehler ich damit ausschließen wollte): - Mehrfach Pinbelegungen im Datenblatt geprüft (Flüchtigkeitsfehler ausschließen) - Mehrfach Referenzschaltplan und Schaltplan anderer Projekte mit dem NAU88C22 gegengeprüft (Flüchtigkeitsfehler ausschließen) - BOM/CPL-Datei überprüft zumindest der relevanten Bauteile rund um den NAU88C22 und dem I2C-Bus (Bestückungsfehler ausschließen) - Optische Kontrolle der Leiterbahnen und der Lötstellen (Lötfehler) - Die anderen Geräte am Bus abgefragt (Fehler in der I2C-Konfiguration des ESP32 oder im Bus-Layout) - Versorgungsspannungen an den 3,3V und 5V-Leitungen gemessen. Spannung am MODE-Pin gemessen. Verbindung der I2C-Pins des NAU (16 und 17) mit den entsprechenden Pins am ESP32 geprüft (Lötfehler) - Kompletten Scan über alle 127 I2C-Adressen gemacht (irgendwelche Verwechslungen mit 7bit/8bit-Addressen) - Zweite Platine getestet (habe fünf bestellt) (Einzelfehler) - Schaltung mit einem ESP32s3-Dev-Board und diesem hier https://wiki.dfrobot.com/FireBeetle_Covers-Camera&Audio_Media_Board_SKU_DFR0498) fliegend nachgebaut (grundsätzlicher Denkfehler) Tja, was soll ich sagen - ich finde einfach keinen Grund, weshalb der NAU88C22 nicht per I2C erreichbar ist. Auf einen Seriendefekt des Bausteins oder auf Bestückungsfehler seitens JLCPCB möchte ich das Problem nicht schieben. Vermutlich ist es etwas peinlich Triviales... Bitte helft mir! Danke und viele Grüße Klaus
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
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.