Forum: Mikrocontroller und Digitale Elektronik I2C mit MSP430FR5739 ACK wird nicht gesetzt


von Alexander H. (himmelsbach_a)


Angehängte Dateien:

Lesenswert?

Hallo alle zusammen,

Ich bin im Moment dabei einen MSP430FR5739 zu programmieren. Dieser soll 
über I2C Werte von einem Temperatursensor (DS1631) einlesen. Dazu sende 
ich ihm zunächst die Konfigurationsdaten (12 Bit Result + Single convert 
mode) anschließend den Befehl die Temperatur einzulesen.

Um zu überprüfen ob die Wandlung abgeschlossen ist lese ich das 
Statusbyte des DS1631 wieder ein und überprüfe das DONE Bit.
Ist Die Wandlung abgeschlossen will ich die Temperatur auslesen.

Jetzt ist allerdings das Problem, dass ich nach dem ersten einlesen des 
Statusbytes die anfrage mit einem NACK quittiere, was dazu führt, dass 
bei den nächsten Einlesevorgängen Nur noch die Adresse, aber nicht mehr 
der erforderliche Befehl gesendet wird.

Wie kann ich an stelle des NACK mit einem ACK quittieren?


Datasheet DS1631: http://datasheets.maxim-ic.com/en/ds/DS1631-DS1731.pdf
Datasheet MSP430FR5739: http://www.ti.com/lit/ug/slau272/slau272.pdf
im Anhang mein Code + Mitschnitt des I2C Bus

von Jörg S. (joerg-s)


Lesenswert?

Normalerweise ist das NACK doch in Ordnung, so sagen die Master 
eigentlich immer dem Slave das das das letzte Byte war.

von Alexander H. (himmelsbach_a)


Lesenswert?

Vielen Dank für die Antwort,

aber dann verstehe ich nicht warum der Controller nach dem ersten mal 
Einlesen , bei der erneuten Anfrage den Befehl auf das Controll-Register 
zuzureifen nicht sendet, sondern nur die Adresse sendet. Habe ich bei 
der Parametrierung der I2C Schnittstelle etwas falsch gemacht?

von Tobias K. (kurzschluss81)


Lesenswert?

Ist doch ok so
ER soll doch lesen nicht schreiben. Dazu wird nur die Adresse gesendet 
und danach in den Lesemodus umgeschaltet. Das einstellen welches 
Register du auslesen möchtest machst du doch vorher indem du ein Byte 
(Konfigurationsbyte) rüberschreibst.

von Jörg S. (joerg-s)


Lesenswert?

Schau doch mal welcher Interrupt nach dem ACK des Slave ausgelöst wird.

Ist das zweite init_iic(); in der while Schleife eigentich notwendig?

von Alexander H. (himmelsbach_a)


Lesenswert?

Ja richtig, das zweite init_iic(); ist nicht notwendig, das was ein 
Überbleibsel von einem Test. Hat aber keine Auswirkung auf das 
Verhalten.

Einen Interrupt der bei einem ACK ausgelöst wird gibt es nicht, ich kann 
lediglich auf ein NACK einen Interrupt auslösen.
Doch in diesem Fall ist es ja kein NACK welches vom Sensor kommt, 
sondern eines, das mein Controller setzt.

Ja ich möchte lesen, jedoch muss ich ihm ja angeben, was ich lesen 
möchte, also sende ich ihm zunächst 0xAC was bedeutet, dass das 
Configurationsbyte ausgelesen werden soll.
Dies wäre theoretisch nur einmal notwendig, da er dieses Byte ja 
mehrfach auslesen soll.

Spätestens jedoch beim auslesen der Temperatur, muss ich angeben dass 
ich diese auslesen will. D.h. zunächst muss ich 0xAA (Read_Temperature) 
senden und anschließend den Wert einlesen. Doch da dies nicht gesendet 
wird bekomme ich beim einlesen der Temperatur den wert des 
Controllregisters zurück.


Ich bin mir auch nicht sicher ob es überhaupt mit zusammen hängt, ich 
dachte es nur, weil bei meinem ersten send-Befehl mein Comand ja noch 
gesendet wurde und nachdem ich eingelesen habe (also nach dem ersten 
NACK) nicht mehr.

von Tobias K. (kurzschluss81)


Lesenswert?

Du mußt normalerweise vor jeder Leseoperation das Kommandobyte senden 
über welches du auswählst was du lesen möchtest. Das geschieht nicht 
automatisch sondern sind zwei Arbeitsschritte die du selber machen 
musst.

von Jörg S. (joerg-s)


Lesenswert?

Tobias Korrmann schrieb:
> Du mußt normalerweise vor jeder Leseoperation das Kommandobyte senden
> über welches du auswählst was du lesen möchtest.
Genau das will er ja, Das Kommando-Byte wird aber nicht gesendet.

von Alexander H. (himmelsbach_a)


Lesenswert?

Richtig, genau das versuche ich, beim ersten mal sendet er das 
Kommando-Byte noch, nach dem ersten mal Einlesen dann nicht mehr. Daher 
habe ich gedacht, könnte es vielleicht an dem NACK liegen, das der µC 
beim vorhergegangenen Einlesen gesendet hat. Wenn das NACK aber wie Jörg 
sagt in Ordnung ist weiß ich auch nicht mehr woran es liegen könnte.

von Tobias K. (kurzschluss81)


Lesenswert?

Dann hatte ich dich falsch verstanden.
Ic hatte mit dem selben Controller hier auf Arbeit diese Problem nicht 
beim I2C von daher kann ich dir dazu nichts sagen.
(dumme Frage hast du ihn nach dem Lesen wieder in den Schreibmodus 
gebracht?)

von Alexander H. (himmelsbach_a)


Lesenswert?

Ja, habe das ich.
Ich setze in der send function das UCTR Bit auf 1.

von Rush .. (rush)


Lesenswert?

Ist zwar schon ein Jahr her aber ich antworte trotzdem mal.

In der iic_init fehlt noch die aktivierung der RX-Interrupts
1
UCB0IE |= UCTXIE0 + UCRXIE0 + UCNACKIE;

Dann werden auch mehrere Bytes als nur eines gelesen und das NACK kommt 
auch an der richtigen stelle.

MfG Rush

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.