Moin, habe hier ein Programm (läuft ca. seit 4Jahren Non Stop ohne Fehler). Habe jetzt ein Update gemacht, löst das Problem aus hat aber nichts mit dem Problem zu tun. Jetzt geht beim Init, das ist das erste was der Chip macht das eeprom_read vom HI-Tech C Compiler nicht mehr, anderes Projekt, gleiche Routine geht. Hat vielleicht jemand eine Idee woran das liegen könnte? Danke im voraus
selbst schrieb: > habe hier ein Programm (läuft ca. seit 4Jahren Non Stop ohne Fehler). > Habe jetzt ein Update gemacht, löst das Problem aus hat aber nichts mit > dem Problem zu tun. Muß ja, da es nicht mehr geht ... > Jetzt geht beim Init, das ist das erste was der Chip macht das > eeprom_read > vom HI-Tech C Compiler nicht mehr, anderes Projekt, gleiche Routine > geht. > Hat vielleicht jemand eine Idee woran das liegen könnte? Wo sind die Programme? Womit wurde das alte Programm übersetzt? Welcher PIC 18Fxxxx wird verwendet? Welches Programmiergerät? Schaltplan? Aufbau?
Hallo, ich programmiere auch gerade mit einem PIC18 - allerdings in Maschinencode. Dein Problem kann ich nicht lösen, aber denjenigen, die das vielleicht versuchen würden, könntest du ihre Hilfsbereitschaft vergrößern, wenn du außer allgemeinen Sätzen auch was technisch Handgreifliches rausrücken würdest, z.B. welcher Prozessor genau, welche Version des Compilers, und zumindest die paar Zeilen, in welchen das EEprom ausgelesen werden soll, könntest du einstellen - ggf. hilfreich wäre auch, welche der genannten technischen Umstände gegenüber vormals nun anders sind. Grüße, wilhelmT Ups.... da war einer etwas schneller!
:
Bearbeitet durch User
Hallo, Prozessor PIC 18F2680 Compiler PICC 18 V.9.80 HI-Tech Pro Code: ID = eeprom_read(0x000A); ID = (ID<<8) + eeprom_read(0x0001); ID = (ID<<8) + eeprom_read(0x0002); ID = (ID<<8) + eeprom_read(0x0003); ich weiß aber nicht was das bringen soll, wie schon gesagt größeres Projekt, ging lange Zeit und eeprom_read gehört zum Compiler. Steht auch im Post "eeprom_read vom HI-Tech C Compiler".
Ach noch was ich habe das jetzt anders reingenommen, der Code geht auf mehreren Geräten einwandfrei (seit Jahren).
selbst schrieb: > ich weiß aber nicht was das bringen soll, Ich weiß es auch nicht. Wie soll Dir jemand aufgrund Deiner bisherigen Informationen helfen? Nicht mal die Fehlerbeschreibung ist klar. selbst schrieb: > Jetzt geht beim Init, das ist das erste was der Chip macht das > eeprom_read > vom HI-Tech C Compiler nicht mehr Was geht da nicht mehr? Hängt sich der Controller auf, bringt er nicht die erwarteten Inhalte (EEPROM-Inhalt korrupt?) oder oder oder PS: > Code: > ID = eeprom_read(0x000A); > ID = (ID<<8) + eeprom_read(0x0001); > ID = (ID<<8) + eeprom_read(0x0002); > ID = (ID<<8) + eeprom_read(0x0003); eeprom_read(EE_ADDR) bringt ein Byte aus der Adresse EE_ADDR zurück. Was machst Du damit warum? Das sieht irgendwie seltsam aus.
Hallo, stimmt habe ich nicht klar gesagt, eeprom_read(EE_ADDR) gibt immer 0x00 zurück. Die Werte sind halt die Adresse, der Code funktioniert schon, der EEprom ist in der Source gesetzt und gültig. Der Fehler tritt auf allen Modulen auf die neu Programmiert sind.
selbst schrieb: > der EEprom ist in der Source gesetzt und gültig. Der Fehler tritt auf > allen Modulen auf die neu Programmiert sind. Gerade das (EEPROM gesetzt und gültig) scheint dann aber nicht zu klappen.
selbst schrieb: > na ja, aber das Mplab zeigt mir den EEprom korreckt an. Hast Du mal den PIC abgesteckt, mplab beendet, neugestartet und den PIC dann angesteckt und das EEPROM neu ausgelesen? Den Prozessor hast Du nicht gewechselt? (andere Adressen, andere Größe des EEPROM o.ä.) (sorry, ist gerade Stochern im Nebel, hab kein mplab auf diesem PC, um das nachzuvollziehen)
Also ich habe das Update auf mehreren Modulen gemacht, alle andere Adresse. Die Updates gehen über Bootloader runter. Alle Module gleicher Fehler. Dann Module ausgebaut und zurück gelesen (im Mplab). In allen Modulen ist die jeweilige Adresse korrekt geschrieben. Im Mplab neu programmiert ohne Bootloader, gleicher Fehler.
Vielleicht kann ich dir doch einen Hinweis geben. Es gibt in deinen Berichten 3 Übereinstimmungen mit meinem (gelösten) Problem: Selbe Controller-Familie, bei mir war es ein PIC18F14K22, das „eigentliche Programm“ funktionierte, und es ging um das Auslesen des EEproms. Kein Update – ich hatte ein orig Prog von Microchip übers EEprom-Auslesen als Ausgangsbasis für mein späteres Prog benutzt. Im Original funkte alles, nach meinen Erweiterungen tauchte im völlig unveränderten Auslesen des EEproms eine Fehlfunktion auf. Da hatte sich durch die anschwellende Menge des Programm- und Daten-Codes plötzlich und für mich unbemerkt die Bank für die EEprom-Variablen geändert. Im Assembler-Code musste es statt „bewährt“ wie im Original movf EEDATA,0,1 stattdessen nun movf EEDATA,0,0 heißen. Passende Bank, ein einziges Bit geändert und schon gab das EEprom die lange vermissten Daten wieder her. Und aufgrund des Hinweises von "Löter": Unabhängig davon kämpfte ich noch an einer anderen Front. Beim ständigen Auf-und Abbau meiner "Schaltung", bestehend aus 3 einzelnen sehr fliegend verkabelten Platinen hatte ich es einmal geschafft, die Versorgungsspannung falsch anzuklemmen. Danach ging zwar alles wieder, so schien es mir jedenfalls, aber letztlich hatte der Prozessor doch einen Klatsch in einem Teilbereich gerade fürs EEprom weg. Da war dann doch der Tausch gegen einen Neuen nötig. Grüße, wilhelmT
selbst schrieb: > Im Mplab neu programmiert > ohne Bootloader, gleicher Fehler. selbst schrieb: > anderes Projekt, gleiche Routine > geht. Da hilft nur vergleichen und systematisch prüfen. Derselbe Controller? Außenbeschaltung? Was wurde vorher im Programm (anders) gemacht? EEPROM-Routinen korrekt aufgerufen? Initialisierung? ...
ja ist mir schon klar, hatte gehofft das schon jemand mal das Problem hatte. Ja alle Module sind gleich. Der Fehler ist im Init, da wurde auch vorher nichts anders gemacht, das ist ja die Sch....
selbst schrieb: > Der Fehler ist im Init, da wurde auch vorher > nichts anders gemacht, das ist ja die Sch.... Hast Du die alte stabile Version da? Übersetz und brenn die doch mal komplett neu. Dann weißt Du, ob es am Werkzeug oder am Programm liegt. Wenn Programm ... irgendwas muss anders sein, configuration bits, Initialisierung, anderer Code, der vorher läuft und eventuell was zerschießt, ...
also alte Version macht den gleichen Fehler, das ist ja blöd. Wie gesagt, provisorisch anders gelöst, Rest läuft einwandfrei.
Be T. schrieb: > Da hatte sich durch die anschwellende Menge des Programm- und > Daten-Codes plötzlich und für mich unbemerkt die Bank für die > EEprom-Variablen geändert. Im Assembler-Code musste es statt „bewährt“ > wie im Original movf EEDATA,0,1 stattdessen nun movf EEDATA,0,0 > heißen. Passende Bank, ein einziges Bit geändert und schon gab das > EEprom die lange vermissten Daten wieder her. Das "bewährte" Beispiel hat nur funktioniert, weil das BSR "zufällig" die passende Einstellung hatte. Eigentlich hätte schon immer auf die ACCESSbank zugegriffen werden müssen. selbst schrieb: > Wie gesagt, provisorisch anders gelöst, Rest läuft einwandfrei. Wie hast du es denn jetzt gelöst?
Das EEprom auslesen habe ich drin gelassen, danach setze ich die Adresse von Hand im Programm, damit bin ich aber nicht mehr frei konfigurierbar.
So geht wieder, einmal auf Assembler umgestellt und dann wieder zurück. Was für ein Fehler.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.