Forum: Mikrocontroller und Digitale Elektronik Atmega328p + AS7261 I2C kein Ack vom slave


von MP (Gast)


Angehängte Dateien:

Lesenswert?

Moin,
ich versuche einen AS7261 XYZ+NIR Sensor (https://ams.com/en/as7261) mit 
einem atmega328p über I2C zum laufen zu bekommen. Betrieben wird der 
328p mit einem 12Mhz Quarz ( ist im schem noch ein 16Mhz, das stimmt 
leider nicht 100%).
Meine Erfahrungen mit beiden sind leider sehr beschränkt. Habe jedoch 
auch shcon diverse Kollegen um Rat gefragt und wir sind nicht weiter 
gekommen:

Das Problem ist, dass ich bei der I2C initialisierung kein ACK vom 
sensor bekomme. Ich habe zusätzlich versucht das I2C mit einer DS1307 
RTC (https://www.linkerkit.de/index.php?title=LK-RTC) aus getestet, 
jedoch hier genau das gleiche Problem (die RTC wurde mit 5V versorgt und 
nicht mit 3,3V wie der Sensor).

wir haben mit einem Logic analysator geschaut ob denn der output vom 
328p stimmt, dies scheint soweit der fall zu sein, bis auf das weder von 
der RTC noch vom sensor ein ack zurück kommt... SCL ist laut dem logic 
analysator die eingestellten 100k Hz und die richtige addresse + r/w bit 
kommt auch hinten raus aus dem 328p. nur halt keine ack Antwort....
Der 328p gibt als Status ausgabe 0x20 aus, also SLA_w transmitted - no 
ack

dies passiert sowohl bei der addresse der RTC als auch beim sensor. 
Ebenso wenn ich 0x00 als addresse verwende, welche laut datenblatt des 
328p ein "general call" ist auf den alle slaves mit ack antworten 
sollten.

Spannung liegt soweit an allen Anschlüssen wie vorgesehen an, für den 
as7261 ist auch der i2c_enable auf 3,3V gezogen.

die Pullups R2 und R3 sind 2k Ohm. In meiner Verzweiflung habe ich auch 
schon 4,7k Ohm eingelötet da dies zumindest für die RTC im Beispiel 
schematic genutzt wurde, einfach nur um es auszuprobieren...

der I2C code basiert auf dem von peter fleury.

zur Zeit bin ich ratlos wo das Problem ist. Irritierend ist, dass auch 
die RTC nicht antwortet, ansonsten hätte ich auf Hardwareprobleme an der 
Sensorseite geschlossen. daher hoffe ich hier hilfe zu finden :)

von hmm (Gast)


Lesenswert?

Hi,

schonmal den IIC scanner durchlaufen lassen ?
evtl hast du ja einfach nur die flaschen Adressen ;)

Ich hab gerade ein ähnliches Problem, baue gerade ein Testgerät um 
Module zu prüfen. Durch die Leitungslänge bekomm ich beim ersten Versuch 
das Modul an zu sprechen auch kein ACK (aufem Ozi sehen die Pakete, 
jedenfalls das erste immer, nicht gut aus) hab als workaround mir ne 
schleife geschrieben, dass der Controller bis zu 20x versucht ne 
verbindung auf zu bauen. Meistens kommt das ACK nach den 2. oder 3. 
Versuch. Ist zwar nicht optimal aber für mein Zweck ist das in Ordnung.

Gruß

von Pete K. (pete77)


Lesenswert?

- Im Datasheet sind noch 100nF beim AS7262 eingezeichnet.
- AREF nicht beschaltet
- Versuche mal 0x92 als Adresse (8-bit)

von Pete K. (pete77)


Lesenswert?

Was soll das?
1
/* I2C clock in Hz */
2
#define SCL_CLOCK  1000

von Hanni (Gast)


Lesenswert?

Moin,
in deinem ersten Bild hängt der 3,3V Via von R3 auf SCL. Nicht so schön.

Viele Grüße
Hannes

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

MP schrieb:
> Main_c.txt
> i2cmaster_h.txt
> twimaster_c.txt
> UART_h.txt
Kleiner Tipp: häng *.c Dateien einfach als *.c Dateien und *.h Dateien 
als *.h Dateien an. Dann gibts Syntax-Highlighting kostenlos...

> wir haben mit einem Logic analysator geschaut
Habt ihr auch mal mit dem Oszi geschaut, ob die Signale "gut aussehen", 
also nicht zappeln, klingeln und vor allem die Flanken gut aussehen?

> ob denn der output vom 328p stimmt, dies scheint soweit der fall zu sein, Und 
passt das Timing sonst zu dem, was der AS7261 erwartet?

Hanni schrieb:
> in deinem ersten Bild hängt der 3,3V Via von R3 auf SCL.
Das ist nur die Kupferfreistellung.

Allerdings ist der C5 als Blockkondensator im Layout völlig wirkungslos.

: Bearbeitet durch Moderator
von MP (Gast)


Angehängte Dateien:

Lesenswert?

Moin,

hmm schrieb:
> schonmal den IIC scanner durchlaufen lassen ?
> evtl hast du ja einfach nur die flaschen Adressen ;)

ja, es kommt leider weder von der RTC noch vom sensor eine antwort auf 
irgendwelchen kanälen

Pete K. schrieb:
> - Im Datasheet sind noch 100nF beim AS7262 eingezeichnet.
> - AREF nicht beschaltet
> - Versuche mal 0x92 als Adresse (8-bit)

die hardware habe ich so von einem kollegen übernommen, der ist leider 
ausgeschieden bevor er weiter mit arbeiten konnte. Das habe ich 
tatsächlich nicht gesehen und schau mal ob ich das noch verschalten 
kann. Es ist leider schon eine platine... ich bin für solche prototypen 
ja eher der Fan von Steckboards... Du meinst an VDD 1/2 zusätzlich zu 
dem 10uF oder? bei mir im bild C5

normalerweise sollte es doch eigentlich aber auch ohn den 100nF 
funktionieren wenn die signale gut aussehen oder?
Zudem hat ja auch die RTC probleme, welche ich im endeffekt nur an die 
SCL und SDA vom 328p angeschlossen hab ( RTC hatte eine eigene 
stromversorgung, habe allerdings die GNDs zusammen geschaltet. Da der 
328p wie gesagt schon auf Platine verlötet ist, war das etwas adhoc und 
sollte auch nur hardwarefehler auf der 328p seite ausschließen)

0x92 für den AS7261 habe ich auch schon direkt probiert ( ebenso 0x93 
welches slave+r/w sein soll)

Pete K. schrieb:
> Was soll das?/* I2C clock in Hz */
> #define SCL_CLOCK  1000

sorry das ist noch überbleibsel meiner versuche. Nachdem sowohl 100k Hz 
als auch 400k Hz nicht funktioniert haben habe ich versucht die SCL 
clock extrem niedrig zu stellen (fragt mich nicht wo, aber irgendwo habe 
ich das als möglichen lösungsversuch gelesen)
der AS7261 soll sowohl normal als auch fast-i2c können



Lothar M. schrieb:
>> wir haben mit einem Logic analysator geschaut
> Habt ihr auch mal mit dem Oszi geschaut, ob die Signale "gut aussehen",
> also nicht zappeln, klingeln und vor allem die Flanken gut aussehen?
>

ja wir haben auch mit dem oszi geschaut, die signale sahen soweit alle 
"sauber" aus ( siehe bild vom SCL) die SDA leitung habe ich leider nicht 
richtig raufbekommen, da der start bit ca. 100ms vor der Ack anfrage 
gesendet wird und mein oszi das leider nicht gemeinsam aufnimmt ( ist 
das evt. der kasus knacktus das zwischen start und eigentlichen daten 
soviel zeit vergeht?)

beim aufnehmen von dem Bild eben ist mir aufgefallen, das der SCL nur 
mit 50k Hz läuft. da schau ich nochmal nach, aber eigentlich sollte es 
doch trotzdem gehen?

>> ob denn der output vom 328p stimmt, dies scheint soweit der fall zu sein, Und
> passt das Timing sonst zu dem, was der AS7261 erwartet?

der AS7261 soll 100k und 400k Hz SCL können. Meines wissens nach sollte 
ein langsamerer SCL auch kein problem darstellen oder?


Lothar M. schrieb:
> Kleiner Tipp: häng *.c Dateien einfach als *.c Dateien und *.h Dateien
> als *.h Dateien an. Dann gibts Syntax-Highlighting kostenlos...

ok, ich werde mich zukünftig daran halten, war mein erster beitrag :)

von EAF (Gast)


Lesenswert?

MP schrieb:
> ja wir haben auch mit dem oszi geschaut, die signale sahen soweit alle
> "sauber" aus (

Das Bild, was du da zeigst?
Gruselig!

Der Ruhepegel bei I2C ist High, bei dir sieht er Low aus.
Die steigende Flanke ist oben auch sehr scharfkantig.
Bei 100 oder gar 400 kHz hätte ich da etwas verschleifen erwartet.

von MP (Gast)


Lesenswert?

EAF schrieb:
> MP schrieb:
>> ja wir haben auch mit dem oszi geschaut, die signale sahen soweit alle
>> "sauber" aus (
>
> Das Bild, was du da zeigst?
> Gruselig!
>
> Der Ruhepegel bei I2C ist High, bei dir sieht er Low aus.
> Die steigende Flanke ist oben auch sehr scharfkantig.
> Bei 100 oder gar 400 kHz hätte ich da etwas verschleifen erwartet.


du hast recht, der SCL is auf low.
Das ist mir auf dem bild tatsächlich nicht aufgefallen. Eine nochmalige 
Messung hat ergeben: der SCL witrd erst auf low gezogen, wenn ich mit 
dem 328p die Kommunikation starte, ansonsten ist der nämlich auf 3,3V.

Ich hätte jetzt erwartet, dass solch scharfkantige flanken gut sind? ich 
hab da wie gesagt leider wenig erfahrung.

von EAF (Gast)


Angehängte Dateien:

Lesenswert?

MP schrieb:
> Ich hätte jetzt erwartet, dass solch scharfkantige flanken gut sind?

Im Grunde hast du ja auch recht.....
Nur, je nach den Umständen verschleift es doch etwas.

Ich zeige dir mal ein Bild, wo das noch im stabilen Rahmen ist.
Insgesamt 4 Busteilnehmer ca 5K Pullup, an 5V
Recht lange parallel geführte Leitungen, also recht hohe Kapazität.

von MP (Gast)


Angehängte Dateien:

Lesenswert?

Ich habe noch einmal über den SCL auf low nachgedacht:

es macht sinn, dass dort der SCL zu beginn auf low ist.
Ich habe das oszi getriggert auf steigender flanke eingestellt. daher 
ist der SCL von der vom 328p gesendeten start condition auf LOW gezogen. 
Das wird nur nicht mehr angezeigt, da das oszi auf 25us zeitintervall 
gestellt ist. Im normalzustand ist der SCL wie gesagt auf 3,3V 
hochgezogen.

im logik analyzer ist das zeitintervall ziwschen dem start und der 
eigentlichen ACK anfrage mit der i2c addreese wie gesagt auch irgendwie 
sehr lang gewesen. die gründe dafür sind mir allerdings nicht so richtig 
ersichtlich

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

MP schrieb:
> irgendwie sehr lang gewesen.
Wieviel ist "sehr lang" in Sekunden?

> im logik analyzer
Das ist doch schon mal der richtige Ansatz. Jetzt musst du aber nicht 
nur "Messen", sondern dein Messergebnis und den zeitlichen Verlauf von 
SDA UND SCL auch mit dem Timing und den Werten aus dem Datenblatt 
vergleichen.

Dann findest du auch heraus, welche dieser Zeilen aus der "Main_c.txt" 
die Richtige ist:
1
 */ also tried : i2c_start(AS72621_ADDR+I2C_WRITE) / i2c_start((AS72621_ADDR)
2
 ret = i2c_start((AS72621_ADDR<<1)+I2C_WRITE);
Die Richtige ist nämlich die, die die korrekte Bitreihenfolge erzeugt.

: Bearbeitet durch Moderator
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Pete K. schrieb:
> - Versuche mal 0x92 als Adresse (8-bit)

Das ist für die Library von P. Fleury auf jeden Fall richtig. 0x92 ist 
die W Adresse und 0x93 dann die R Adresse.

: Bearbeitet durch User
von rotar füller (Gast)


Lesenswert?

Lothar M. schrieb:
> Die Richtige ist nämlich die, die die korrekte Bitreihenfolge erzeugt.

Die Reihenfolge der Bits ist unabhängig von der Adresse, daher ist
die Reihenfolge immer richtig oder immer falsch. Bei Peter Fleury
wird sie immer richtig sein und ich kenne keine andere Reihenfolge
beim I2C Bus Protokoll.

von matthias (Gast)


Lesenswert?

Falls sich das nicht schon erledigt hat: Ich hatte eben das gleiche 
Problem - kein ACK vom AS7261. Bei mir war das Problem, dass der AS7261 
nach einem Reset anscheinend relativ lange (>200ms) braucht, bis er auf 
I2C antwortet. Nach einer Sekunde Wartezeit ging es.

Und: Der AS7261 braucht am SPI einen Flash mit Firmware.

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.