Hallo,
kennt sich hier jemand gut mit PICs aus?
Habe für ein Bastelprojekt ein Hex-File, das auf einen Pic 16F876
geschrieben werden soll.
Das Hex-File ist 7kB groß.
Nach dem Brennen auf den Pic gibt es eine Fehlermeldung, dass beim
Verifizieren der geschriebenen Daten Fehler festgestellt wurden.
Ein anderes Hex-File mit 47kB Größe läßt sich problemlos und fehlerfrei
auf den Pic schreiben.
Liegt es möglicherweise an der Dateigröße, dass beim ersten Hex-File
Fehler angezeigt werden?
Es gibt verschiedene Hex-File_Formate.
Beim Intel-Hex-format zum beispiel sind
noch Prüfsummen enthalten. Du must herausfinden
welches Format dein PIC-Brenner haben möchte.
Danke für die schnellen Antworten!
Ich benutze den PICPgm Development Programmer.
http://picpgm.picprojects.net/software.html
Leider steht dort nicht, welches hex-File-Format verwendet werden muss.
In jedem Fall möchte er die Dateiendung .hex, aber das hilft
wahrscheinlich erst mal auch nicht weiter!?
richard schrieb:> Das Hex-file fw_120_7.hex soll auf einen PIC16F876 :>> http://dl4jal.eu/fwnwt/fw_120_7.hex>> Ob es möglicherweise defekt ist, weiß ich nicht.
Der erste Record vom Record-Typ 4 (erste Zeile) gefällt mir nicht. Er
hat in neueren Formaten eine bestimmte Rolle, und erzeugt in alten
Loadern und Programmern Error. Hatte auch damit zu tun. Jedoch beim
8051, nicht PIC, das sollte aber keine Rolle spielen. Einfachere alte
Loader kennen nur Record-Typen 0 (für laufenden Code) und 1 (für letzte
Zeile), und spucken alles andere wieder aus.
Ich entfernte für meine Anwendungen jeweils diese Zeile vom Record-Typ
4, da sie keinen Programminhalt hat. Möglicherweise hat man also Glück,
wenn man die erste Zeile einfach manuell entfernt. Nach lesen, was sie
bedeutet, sollte man dennnoch.
Danke für die Antworten!
Günter Lenz schrieb:> Sieht aus wie Intel-Hexformat.> Auf Wikipedia findest du Informationen,> wie so eine Datei aufgebaut ist.
Hm, habe dort auf eng. und dt. nichts gefunden.
Mit Record-Typen kenne ich mich leider nicht aus.
Gibt es dafür Datenkonverter?
Habe das aufgespielte hex-File (nach der Fehlermeldung) einfach mit der
Programmiersoftware wieder vom PIC ausgelesen und angehangen.
Dort sind offensichtlich auch die nicht genutzten Speicherzellen
enthalten.
Möglicherweise müssten diese einfach bei dem file oben angehangen
werden?!?
Stefan schrieb:> Habe es mal durch meinen Compiler gejagt.> Vielleicht läuft es ja.
*** Programming finnished successfully ***
Danke Stefan, hat sich ohne Fehlermeldung auf den PIC aufspielen lassen!
Kannst du noch kurz sagen, was du wie compiliert hast?
Testen kann ich es erst morgen, weil die Hardware noch nicht ganz fertig
ist - gebe dann ein feedback.
Stefan schrieb:> Habe es mal durch meinen Compiler gejagt.> Vielleicht läuft es ja.
Hallo, muss mich noch mal melden.
Hatte die Datei test.hex auf den Pic gebrannt, was ja vom Brennvorgang
her auch problemlos geklappt hatte.
Leider funktioniert der Pic mit dieser Firmware aber nicht.
Gibt es eine andere Möglichkeit, das File im Anhang so zu konvertieren,
dass der PICPgm LVISP damit umgehen kann?
Hey John, Danke fürs Uploaden!
Gibt leider wieder "Verifying errors".
Das Problem ist wohl u.a. die File-Größe. Der Progger verwendet
wahrscheinlich ein format, bei dem auch die leeren
Programmspeicheradressen hinter dem Programmende gebrannt werden müssen.
Entsprechend sollte das Hex-ile ca. 48kB groß sein.
Eigentlich sollte diese FW verwendet werden:
http://dl4jal.eu/fwnwt/fw_119_7_mit_bootloader.hex
sowie da dort lvp abgeschaltet ist, geht dies warscheinlich auch nicht.
Nimm Hvp, einfach eine 9V Batterie oder 12V von einem Netzteil
verwenden.
chris schrieb:> sowie da dort lvp abgeschaltet ist, geht dies warscheinlich auch nicht.> Nimm Hvp, einfach eine 9V Batterie oder 12V von einem Netzteil> verwenden.
Kenne mich leider mit Pics kaum aus.
lvp = Low voltage Prog., schätze ich.
Wo wird dann der 9V-Block angeschlossen?
rb3 muss ein pull down zu gnd haben (Widerstand, 1k - 10k, egal
welcher).
9V wird an MCLR angeschlossen.
Zuerst Batterie anschliessen und dann erst 5V an VDD geben.
chris schrieb:> rb3 muss ein pull down zu gnd haben (Widerstand, 1k - 10k, egal> welcher).> 9V wird an MCLR angeschlossen.> Zuerst Batterie anschliessen und dann erst 5V an VDD geben.
Danke für die Infos!
Und dann ganz normal mit dem PICPgm LVISP flashen?
Stefan schrieb:> Versuch mal ob das läuft.
Bis auf die Config-Bits entspricht diese Hex-Datei einem leeren PIC.
Damit läuft bestimmt nichts.
Im ersten Hex-File von Stefan fehlen die Daten für das EEPROM.
Ich hab die mal rein kopiert. Vielleicht geht das.
richard schrieb:> Programming started ...> Verify Error: Cfg Mem 0x00000E: PIC=0x3FF2 Buf=0x3F72> Programming finished with verify errors!
GRRMPF...
Ja siehst du das denn nicht selber? VERIFY Error. Zu deutsch: der
Programmer wollte in Adresse 0E den Wert 3F72 hineinschreiben und beim
Zurücklesen kam 3FF2 zurück.
Du hast vermutlich kein Problem mit dem Hexfile, sondern mit deinem
Programmiergeschirre.
richard schrieb:> Verify Error: Code Mem 0x000168: PIC=0x3FFF Buf=0x20B6> Verify Error: Code Mem 0x00016A: PIC=0x3FFF Buf=0x0008> Verify Error: Code Mem 0x00016C: PIC=0x3FFF Buf=0x3024
Hier wird es noch viel deutlicher: egal was der Brenner brennen will,
aus dem PIC kriegt er nur 3FFF (also gelöscht) zurück.
Entweder kann deine Programmiersoftware den Algo dieses PIC's nicht oder
du hast nen echten Hardwarefehler: Brenner kaputt, falsche Vpp, Strippe
ab, PIC kaputt, deine Schaltung zum Programmieren ungeeignet, und so
weiter.
Klaro?
W.S.
Danke für die Antwort!
W.S. schrieb:> GRRMPF...>> Ja siehst du das denn nicht selber? VERIFY Error. Zu deutsch: der> Programmer wollte in Adresse 0E den Wert 3F72 hineinschreiben und beim> Zurücklesen kam 3FF2 zurück.>> Du hast vermutlich kein Problem mit dem Hexfile, sondern mit deinem> Programmiergeschirre.>> richard schrieb:>> Verify Error: Code Mem 0x000168: PIC=0x3FFF Buf=0x20B6>> Verify Error: Code Mem 0x00016A: PIC=0x3FFF Buf=0x0008>> Verify Error: Code Mem 0x00016C: PIC=0x3FFF Buf=0x3024>> Hier wird es noch viel deutlicher: egal was der Brenner brennen will,> aus dem PIC kriegt er nur 3FFF (also gelöscht) zurück.>> Entweder kann deine Programmiersoftware den Algo dieses PIC's nicht oder> du hast nen echten Hardwarefehler: Brenner kaputt, falsche Vpp, Strippe> ab, PIC kaputt, deine Schaltung zum Programmieren ungeeignet, und so> weiter.>> Klaro?
Hast du den Beitrag richtig gelesen? "Normale" Hex-Files für den 16F876
werden richtig gebrannt (die mit 45,1kB Länge). Probleme bereiten die
kürzeren Formate.
Warum das so ist, ist im Prinzip noch offen.
@Stefan: Danke fürs file!
Grüß Dich, Richard,
eben habe ich das hex-file mal testhalber mit dem Sprut-Brenner 8 und
mit einem Topwin auf einen 876er gebrannt. Funktioniert mit beiden
Geräten ohne Probleme. Falls Du den gebrannten 876er haben möchtest,
mail genügt.
Viele Grüße
Roland
Danke fürs Ausprobieren, Roland!
Damit wir nicht aneinander vorbeireden, hast du das File im Anhang auf
den Controller brennen können (und welche Brenn-Software hast du dafür
verwendet)?
Nabend Richard,
ich habe das file Deiner mail von 20.42 Uhr verwendet.
Der Sprut-Brenner funktioniert nur mit der Sprut-eigenen Software
(USB113 oder so ähnlich); gleiches gilt für den TopWin. Die
Versionsnummern der Software habe ich gerade nicht parat, weil ich an
einem anderen Rechner arbeite; beide Versionen sind aber schon deutlich
älter als zwei Jahre.
Viele Grüße
Roland
Hallo Roland,
"blöde Frage", wenn du das file auf den Pic brennen konntest, kannst du
es dann vielleicht auch wieder vom Pic auslesen und in dem hex-Format
speichern, das ca. 45,1kB groß ist?
Die anderen "künstlich verlängerten" Files weiter oben funktionieren
leider nicht.
Das wäre auf jeden Fall noch mal einen Versuch wert.
Ansonsten muss ich mir wohl oder übel einen anderen Pic-Progger bauen,
der mit allen gängigen Formaten umgehen kann (bzw. dessen
Brennsoftware).
Welchen Sprut-Brenner hast du verwendet?
http://www.sprut.de/electronic/pic/brenner/
Viele Grüße!
Grüß Dich, Richard,
ich habe den Sprut-Brenner 8, der allerdings nur *.hex speichern kann.
Der TopWin kann mehrere Formate speichern. Ich habe den 876er eben
ausgelesen und die files als .bin (17kB) und als .hex (40kB) angehängt.
Vielleicht funktioniert ja eins von beiden.
Viele Grüße
Roland
Hallo Roland,
vielen Dank für die Files! Das ganze hat mich wohl auf die richtige
Fährte gebracht - wie es aussieht, hat das Brennbrogramm einen Bug oder
der Pic-Controller einen Defekt: die Config-Bits werden nicht richtig
geschrieben und verursachen Verify-Errors. Der Rest scheint ok zu sein.
Kannst Du eventuell mal gucken, wie die Config Bits/das Config Mem
gesetzt werden müssen?
Hier die Daten, wie es im Moment ist:
Config bits:
FOSC...HS oscillator
WDTE...Disabled
PWRTE..Enabled
BOREN..Enabled
LVP....Disabled
CDP....Disabled
WRT....Enabled
DEBUG..Disabled
CP.....Disabled
Config Mem:
2000 FFFF
2001 FFFF
2002 FFFF
2003 FFFF
2004 FFFF
2005 FFFF
2006 FFFF
2007 3F72
Vielleicht bekommt man die Sache ja doch noch mit dem bestehenden
Brenner hin.
Viele Grüße und noch mal Danke!
Nabend Richard,
der Sprut-Brenner sagt:
HS Oscillator
Watchdog timer disabled
PWRTE enabled
brown out reset enabled
LVP disabled
Data EE Code memory protection disabled
flash program memory write enable enabled
Die config-bits stimmen also mit den von Dir genannten überein.
EEPROM-Inhalt:
0x0000 E0 DE 65 DC 17 00 -- -- e
Hoffentlich bringt Dich das weiter.
Viele Grüße
Roland
Hallo Roland,
Danke für die Infos!
Das Problem war anscheinend, dass man die Bootlader-Version flashen
muss:
http://dl4jal.eu/fwnwt/fw_119_7_mit_bootloader.hex
Also eine von den Dateien hier ganz unten:
PIC-Code mit Bootloader
http://dl4jal.eu/fw.htm
Der Pic funktioniert jetzt (juhuuuu). Allerdings besteht bei meinem
Progger immer noch das Problem mit den Config bits, die man nach dem
Flashen irgendwie in den Controller mogeln muss und die derzeit von den
Einstellungen oben abweichen.
Wenn du noch mal Zeit und Lust haben solltest, könntest du mal schauen,
ob bei der Datei
http://dl4jal.eu/fwnwt/fw_119_7_mit_bootloader.hex
die Config Bit Einstellungen von denen oben abweichen (wäre auch nicht
dringend)?
Ansonsten werde ich mir wohl längerfristig auch mal einen Sprut8 bauen.
:O)
Viele Grüße und einen schönen 1. Advent noch mal Danke für die Hilfe!
Grüß Dich, Richard,
super, daß der 876er endlich spielt, wie er soll.
Die config-bits der bootloader-Version sind absolut identisch mit den
von mir bereits geposteten; auch der EEPROM-Inhalt ist gleich.
Der einzige Unterschied ist die bildliche Darstellung der memory-map im
Sprutschen Brennprogramm: bei der bootloader Version sind die ersten
etwa 1,1 kB belegt, dann von 1,1kB bis 3,8 kB leer und von 3,8kb bis
knapp 4kB wieder belegt. Bei der ersten Version ist lediglich der erste
Bereich bis 1,1kB belegt.
Auch Dir wünsche ich einen schönen 1. Advent und viele Grüße
Roland
Hey Roland,
Danke für die Infos!
Möglicherweise sind bei dem Controller auch einfach die Configbits
defekt und lasen sich nicht überschreiben?!?
(habe leider grade keinen zweiten 16F876 zur Hand, um das zu überprüfen)
In jedem Fall läuft das Bastelprojekt so weit ich sehe auch mit der
aktuellen Konfiguration.
Viele Grüße und noch mal DICK DANKE!!!
Rich
