Forum: Mikrocontroller und Digitale Elektronik NAU88C22 Design Review


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Klaus L. (keyel80)


Lesenswert?

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

von Georg P. (perthil)


Lesenswert?

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

von Klaus L. (keyel80)


Lesenswert?

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
von Georg P. (perthil)


Lesenswert?

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

von Klaus L. (keyel80)


Lesenswert?

Ja, 100kHz.

Vg Klaus

von Hannes (taurus16)


Lesenswert?

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

von Georg P. (perthil)


Lesenswert?

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

von Klaus L. (keyel80)


Angehängte Dateien:

Lesenswert?

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

von Klaus L. (keyel80)


Angehängte Dateien:

Lesenswert?

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
von Klaus L. (keyel80)


Lesenswert?

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

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Darf CSB vom BMEx280 floaten?

von Klaus L. (keyel80)


Lesenswert?

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)

von Klaus L. (keyel80)


Lesenswert?

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

von Klaus L. (keyel80)



Lesenswert?

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
Noch kein Account? Hier anmelden.