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!
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".
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, ...
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?