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?
Woher kommt die Datei? Ist die eventuell defekt? Gibt es Quellcodes zum selber compilieren?
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!?
sven schrieb: > Woher kommt die Datei? Ist die eventuell defekt? 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.
Sieht aus wie Intel-Hexformat. Auf Wikipedia findest du Informationen, wie so eine Datei aufgebaut ist.
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?!?
Hier noch das LOG vom Progger:
1 | PICPgm LVISP Programmer connected and initialized! |
2 | Detected PIC16F876, device ID 0x09E6! |
3 | Erasing Device ... |
4 | Erasing finished! |
5 | Programming started ... |
6 | Verify Error: Code Mem 0x00015E: PIC=0x3FFF Buf=0x0000 |
7 | Verify Error: Code Mem 0x000160: PIC=0x3FFF Buf=0x1107 |
8 | Verify Error: Code Mem 0x000162: PIC=0x3FFF Buf=0x0000 |
9 | Verify Error: Code Mem 0x000164: PIC=0x3FFF Buf=0x0000 |
10 | Verify Error: Code Mem 0x000166: PIC=0x3FFF Buf=0x20B6 |
11 | Verify Error: Code Mem 0x000168: PIC=0x3FFF Buf=0x20B6 |
12 | Verify Error: Code Mem 0x00016A: PIC=0x3FFF Buf=0x0008 |
13 | Verify Error: Code Mem 0x00016C: PIC=0x3FFF Buf=0x3024 |
14 | Verify Error: Code Mem 0x00016E: PIC=0x3FFF Buf=0x0084 |
15 | Verify Error: Code Mem 0x000170: PIC=0x3FFF Buf=0x3004 |
16 | Verify Error: Too much errors in Code Mem, giving up! |
17 | Verify Error: Cfg Mem 0x00000E: PIC=0x3FF2 Buf=0x3F72 |
18 | Programming finished with verify errors! |
19 | Operation took 21.0 seconds! |
Ab dem 2. Brennversuch bekommt man immer folgende (kürzere) LOG-Meldung:
1 | PICPgm LVISP Programmer connected and initialized! |
2 | Detected PIC16F876, device ID 0x09E6! |
3 | Erasing Device ... |
4 | Erasing finished! |
5 | Programming started ... |
6 | Verify Error: Cfg Mem 0x00000E: PIC=0x3FF2 Buf=0x3F72 |
7 | Programming finished with verify errors! |
8 | Operation took 22.0 seconds! |
Aus den Errormeldungen lässt sich vielleicht auch einges ableiten.
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)?
PS: die Files mit 45,1k Länge kann ich auch problemlos brennen - es ist allerdings noch nicht ganz klar, ob die auch richtig funktionieren.
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
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.