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).

[PICture]

Ich vermute bisher unbekannte fehlerhafte Zuweisung von Pins. Ich mag eben nur über etwas konkretes reden.

[RoboHolIC]

Danke euch für die vielen Beiträge.

@Siro: Ich programmiere in ASM. Die TRISx-Register setze ich gleich zu Anfang und immer byteweise. Dann wird per bcf TRISC,3 und bsf TRISC,3 die eventuelle I2C-Busbelegung weggetaktet; erst dann erfolgt die Aktivierung des MSSP-Moduls als I2C-Master.

@witkatz: Jo, kann alles passieren, passt aber.

@PICture: Grundsätzlich gebe ich dir recht: Konkreter Code ist besser als rätseln. Weil ich jetzt eine Reihe zugemüllter und verbastelter Source-Varianten habe, ist da erstmal eine Konsolidierung fällig.

Ich habe eine ande Minimal-Schaltung mit PIC16F886, einem LCD-Modul und I2C-Anschluss herumliegen. Die war für mein Altimeter bestimmt, passte aber wider Erwarten (ich Dussel !) in keines der beim großen C..... verfügbaren handlichen Gehäuse . Für sie - und eben den 16F886 - existiert funktionierender I2C-Code. Den hatte ich dieser Tage schon auf Minimum reduziert und mit meiner bewährten Ausleseroutine für den Zielbaustein (den bisher noch unerwähnten BMA020 auf dem Breakout von ELV) angepasst, um rauszukriegen, ob
a) das Trägerplatinchen für den BMA020 noch funktioniert und
b) ich nicht zu doof zum ASM-Programmieren geworden bin.

Das Ergebnis lag binnen Stundenfrist vor und war in jeder Hinsicht erfreulich. Der (oben erwähnte) Portierungsversuch auf den anderen Controller und das andere "Biotop" (die eigentliche Ziel-Leiterplatte) war wie beschrieben erfolglos verlaufen.

Jetzt werde ich den Spieß umdrehen und versuchen, die funktionierende Kombination durch Chiptausch und Codeanpassung auf 16F876A umzustricken. Dieser Weg sollte ja der kürzere sein. Vielleicht entpuppt sich so die große handgestrickte und später umfangreich modifizierte Ziel-Leiterplatte als Fehlerquelle.

Ich bin gespannt und werde berichten.

Gruß
RoboHolIC

[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