I2C auf 16F876A klappt nicht

[RoboHolIC]

Hallo.

Ich habe jetzt etwa 10-15 Stunden intensiv Microchip-Doku gelesen, probiert, geändert, allgemein recherchiert ..., ohne dem PIC16F876A eine I2C-Kommunikation entlocken zu können. Der Austausch mit einem fabrikneuen Teil hat nichts geändert. Versorgungsspannungen sind Oszi-gesichtet und OK.
Kupferseitig ist alles getestet, PullUps vorhanden (wobei die 3,3kOhm-Widerstände in der Schaltung bei gestecktem Controller als 1,7kOhm gemessen werden ???).

Auf der Basis von PIC16F886 hatte ich schon verschiedene I2C-Bausteine zum Sprechen gebracht; einer davon war aktuell verwendet worden - ebenfalls bewährte Hardware. Der Code war eigenentwickelt, sodass schon etwas Erfahrung mit diesem Bus und dem Controller vorliegt.

Was nicht gelingen will, ist die Portierung auf den PIC16F876A, obwohl ich keinerlei Hinweise darauf habe, dass sich Register, Bits oder Logik des MSSP-Moduls zwischen den beiden Typen unterscheiden könnten.

Die SCL-Leitung ist trotz des PullUps sehr EMV-empfindlich; bereits die Berührung mit dem Oszi-Tastkopf bringt den Programmablauf in einen Blockierzustand (Warten auf Godot). Diesen führe ich darauf zurück, dass meine I2C-Codeabschnitte keine Timeout-Absicherungen haben - das war bisher nie nötig.

Hat jemand ähnliche Erfahrungen und das Problem gelöst?

Gruß
RoboHolIC

P.S.:
Dieses Problem ist "Hobby" innerhalb des Hobbies - im Grunde unwichtig, aber Aufgeben ist keine Art, mit solchen Problemen umzugehen, oder?

[PICture]

Hallo!

Was nicht gelingen will, ist die Portierung auf den PIC16F876A, obwohl ich keinerlei Hinweise darauf habe, dass sich Register, Bits oder Logik des MSSP-Moduls zwischen den beiden Typen unterscheiden könnten.

Man kann nicht alle mögliche vom Microchip eingeführte Änderungen nur anhand Datenblätter erkennen. Ich habe immer nach Programablaufdiagram nacheinander kleine Fragmente von gesamten auf anderen PIC geprüften Program zum Laufen gebracht. Es gibt nie zu viel Übung und Erfahrung.

[witkatz]

10-15 Stunden intensiv Microchip-Doku gelesen

Hast du auch das MSSP Erratum studiert?

Gruß
witkatz

[RoboHolIC]

Danke Euch für die Hilfestellung.

Die 10-15 Stunden beziehen sich auf alle Tests, Arbeiten am Source, Verschmelzungen etc. gesamt.
Dieses Erratum kenne ich schon seit meinen PIC-Anfängen, ich sehe aber keine Anknüpfungspunkte zu meinem Code; trotzdem Danke.

Zur Konkretisierung reiche ich die Symptome des Nicht-Funktionierens nach:
- SDA ist (fast) immer "H", die angeblich gelesenen Bytes sind alle 0xFF
- gestern habe ich allerdings einiges Gezappel auf SDA entdeckt; dessen Wiederholfrequenz dürfte der Durchlaufzeit der Hauptschleife entsprechen, die fast auschließlich von der Aktualiserung des LCD bestimmt wird
- SCL scheint EMV-sensibel zu sein oder mit seinem Echo zu sprechen - bereits das begrabschen des I2C-Flachbandkabels führt zur Störung / Blockierung; Oszi-Tastkopf dito (allerdings bilden die Schirmungen von Oszi und PICkit3 -- USB -- PC eine "Brummschleife") Es sind keine SCL-Pulse darstellbar, weil der Controller dann sofort im Programmdurchlauf hängen bleibt.
- der elektrische Test bestand darin, SCL und SDA als I/Os mit L-Pegel zu konfigurieren, die beiden TRISC-Bits zu toggeln und den Pegelwechsel zu oszilloskopieren. Am SCL war bei der fallenden Flanke ein hässlicher Unterschwinger bis etwa -2V zu sehen.

Jetzt würde ich gerne die OpenDrain-Konfiguration testen. Man kann ja I2C per Firmware emulieren. Läuft das mit TRISC-Registern oder steuert man dann die OpenDrains direkt an? Und falls ja, wie? Das Blockschaltbild für I2C-Master-Betrieb macht mir allerdings wenig Hoffnung auf einen direkten Zugriff auf die OpenDrains.

[Siro]

Hallo RoboHolIC

Das klingt irgenwie als wäre der SCL Pin hochohmig.

Für einen Fullspeed Modus sollten deine beiden Pullups bei 3,3 Volt Versorgung 1K haben.
Hier sehe ich aber eher nicht das Problem.

Könnte es sein, dass dein TRISC-Register von einer anderen Initialisierung überschrieben wird.
Durch ein sogenanntes Read Modify Write kann dies unvorhergesehene Ergebnisse haben und deine Initialiseiugn des Registers stimmt nicht mehr.

Schau mal im Datenblatt: 4.3 PORTC and the TRISC Register, ist bei mir die Seite 46

Aus dem Datenblatt:
When enabling peripheral functions, care should be
taken in defining TRIS bits for each PORTC pin. Some
peripherals override the TRIS bit to make a pin an
output, while other peripherals override the TRIS bit to
make a pin an input. Since the TRIS bit override is in
effect while the peripheral is enabled, read-modifywrite
instructions (BSF, BCF, XORWF) with TRISC as the
destination, should be avoided. The user should refer
to the corresponding peripheral section for the correct
TRIS bit settings.

Versuche mal deine Software so zu ändern, dass Du nur ein "einziges" Mal einen Zugriff auf das TRISC Register hast.
weis jetzt nicht ob Du in Assembler oder C programmierst. Also TRISC = xxxx;

oder
movlw xxx
movwf TRISC

Siro

[PICture]

Für erfolgreiches Portieren eines geprüftes Programms muss die Software lauffähig ganz unabhängig von der Hardware sein.

[witkatz]

@RoboHolIC: wenn das mein ASM Projekt wäre, würde ich prüfen, ob ich die Bank für TRISC richtig selektiert habe (und zu 50% läge ich damit richtig). Für einen alten Hasen wie dich ist dieser Tipp wohl überflüssig. Leider habe ich keinen PIC16F876A um das Problem nachzustellen. Ich kann dir nur anbieten, über dein Quellcode drüberzuschauen, wenn du es posten magst (sonst gerne per PN oder Mail).

[RoboHolIC]

Hallo an alle, die bis hierher mitgedacht und sich bemüht haben.

Jetzt werde ich den Spieß umdrehen und versuchen, die funktionierende Kombination durch Chiptausch und Codeanpassung auf 16F876A umzustricken ...
... Ich bin gespannt und werde berichten.

Uuups - der Spieß hat sich gedreht, nur nicht so wie ich es mir vorgestellt hatte. Der angedeutete Testfall findet nicht statt, weil das für den 16F886 entwickelte Platinchen aus der Grabbelkiste dem 16F876A nicht den benötigten externen Taktgeber/Schwinger bieten kann. Da fällt mir doch glatt der technische Fortschritt auf die Füße ...

Natürlich könnte ich den Lötkolben anheizen, die Teilekiste auspacken und loslegen:

Dieses Problem ist "Hobby" innerhalb des Hobbies - im Grunde unwichtig, aber Aufgeben ist keine Art, mit solchen Problemen umzugehen, oder?

Aber angesichts eines Restbestands von zwei Stück 16F876A vielleicht wiederum doch ...

Gute Nacht wünscht
RoboHolIC

[Andre_S]

Hallo RoboHolIC!

Vor der Umstellung auf 18F422 und später dsPIC30F5013 haben wir den 16F876 in allen unseren Steuerungen eingesetzt.
Das es jetzt bezüglich der Version A Unterschiede im MSSP Modul oder dessen Initialisierung gibt hab ich erst mal nicht in Erinnerung, zumindest der 16F876 wurde von uns in sehr vielen Geräten verbaut. Dei A gabs wohl Unterschiede im flashen und der Geschwindigkeit.
Bei allen arbeitet der I²C-Bus zwecks Kommunikation mit Speicherbaustein, RTC und steckbarer Speicherkarte ohne Probleme. Der Bus ist somit auf die Größe des Platinenlayouts beschränkt und wird nicht extern weitergeführt.
Allerdings bediene ich diesen auf Grund der Umweltbedingungen (Freifeldeinsatz) und nicht benötigter höherer Geschwindigkeit, von vorn herein nicht mit maximaler Busgeschwindigkeit der Komponenten, sondern soweit ich mich erinnern kann mit ca. 125Khz. (MC mit 4Mhz)

Grundvoraussetzung um wirklich „effektiv“ helfen zu können, wäre sicherlich die Offenlegung der Quellcodes bezüglich Initialisierung und Kommunikation deinerseits, zumindest um so möglichen Fehlerquellen innerhalb der Programmierung ausschließen zu können.
Meine Quellen sind ebenfalls in Assembler, aber eventuell hast Du den Fehler inzwischen auch lokalisieren können…


Gruß André

[Siro]

Hallo RoboHolIC

Ich hab jetzt nicht ganz verstanden warum Du das RC3 Bit einmal auf Input und dann wieder auf Output setzt, das ist doch die Clockleitung
aber genau da könnte der kritische Punkt sein.

wenn Du mit dem BCF oder BSF Befehl arbeitest, liest der Controller den "gesamten" Port, also "ALLE" Bits vom C-Port (READ)
und speichert sie irgendwo zwischen. Dann wird das entsprechende "einzelne" Bit gesetzt oder gelöscht. (MODIFY)
Dann wird der zwischengespeicherte Wert zurück an den Port geschrieben. !! ALLE 8 Bits (WRITE)
Das Problem: Hat der Controller ein High auf einem anderen Bit gelesen, wird dieses Bit nun auch High gesetzt,
obwohl man dieses Bit garnicht anfassen wollte. Das bedeutet Du möchtest nur ein Bit verändern im TRIS Register aber
es ändern sich unter Umständen auch andere Bits, die man garnicht verändern wollte. Dann stimmt plötzlich zum Beispiel die Richtung IN/OUT nicht mehr

Ich habe mir um das zu vermeiden oft eine Variable angelegt und NUR Änderungen mittels BCF und BSF in dieser Variablen getätigt.
dann den gesamten Wert (8 Bit) auf den Port geschrieben.

Das ist natürlich nur eine Vermutung dass der Fehler daher rührt.
Bankselect ist ebenso "SEHR" wichtig, wie witkatz schon schrieb.
Das waren auch zu 99 Prozent meine Softwareprobleme.

Siro