Hi zusammen, ich habe mir den HV-Prog http://www.der-hammer.info/hvprog/ nachgebaut. Flashen wollte ich nun den 8535 über den ISP-Port und einem AVR-Prog. Es kommt jedoch immer die Meldung "Programming failed!" Ein HEX-File, welches mit dem AVR-Studio erstellt wurde, kann ich problemlos flashen und auch wieder auslesen. Hat jemand eine Idee woran es liegen kann oder gibt es die STK500.ebn auch irgendwo als HEX-File? Google hat da leider nichts gefunden. Vielen Dank, Torsten
hi torsten sorry, hatte leider noch keine zeit auf die mail zu antworten. klaus leidinger hatte mit seinem programmer das gleiche problem und eine leicht modifizierte firmware für das flashen benutzt mit der es dann einwandfrei ging. ich werde ihn mal fragen, ob er (oder ich) diese version online stellen kann. vielleicht liest er das hier ja auch mit. . sonst schreib ich dir, sobald ich was von ihm höre bye, tobi
Hallo, entscheidend ist, ob nach den brennes des *.ebn Files die LED des HVProg "arbeiten". Das ebn File benutzt Atmel um "kopiergeschützte" Software zu verteilen. AVRPROG brennt die Software und setzt gleich danach die Lockbits, verbietet damit ein auslesen des frisch gebrannte Controllers und auch den verify. Deshalb die Fehlermeldung. @Torsten: Welchen Programmer verwendest Du? Ciao, Klaus
ich antworte mal stellvertretend. er benutzt deinen avr910 programmer
bald mach ich auch mal an diesem Projekt weiter - ich habe meinen AT90S1200 auf dem STK dahingehend geändert, dass er das Setzen der Lockbits für den 8535 unterlässt, sollte also kein Problem sein, dass zurückzulesen. Ist dann natürlich das Problem der verschiedenen Versionen der Software.
Habe mal ebene das Programmieren nochmal getestet. Bei einem "normalen" HEX-File wechselt die LED von Grün nach Rot. Bleibt dann eine paar sekunden Rot und wechselt dann wieder nach Grün. Anschließend nochmal ein kurzer Wechsel nach Rot. Beim EBN-File wechselt die LED nur ganz kurz nach Rot und dann sofort wieder nach Grün. Habe dann den HV-Prog mal die Com gehängt - wird aber nicht erkannt :o( Durch die LockBits dürfte doch nur das Verify nicht mehr möglich sein, das Programmieren müsste doch funktionieren - oder bin ich da falsch? Grüsse, Torsten
nein, da liegst du richtig. dadurch sollte nur der verify nicht fuktionieren. welche led meinst du gerade? die vom programmer oder die vom hvprog? die led's vom hvprog sollten nach einem reset folgende folge haben: rot rot-grün grün kurz aus grün (und bleibt an)
ich meinte die LEDs vom AVR-Prog. Beim HV-Prog passiert gar nichts. Nicht eine LED geht an (ausser die für die Spannungsversorgung).
@Tobi: Danke ! - Werde es heute abend mal testen und dann berichten.
@Tobi: Hat leider nicht geklappt. Habe noch immer den selben Effekt. Ich glaube schon fast das es an dem stk500.ebn-File liegt.
mglw. am externen anschluss fuer die "STK500-emulation" was nicht in ordnung. oder XTAL fuses nicht korrekt. zum test 3,6xx MHz Quarz dran und schauen ob eine "avr-isp" erkannt wird. das verify bei avrprog sollte funktionieren.
Hallo Torsten, am ebn File an sich sollte es nicht liegen, wenn Du eines von der aktuellen AVRStudio Software nimmst. probiere mal sicherheitshalber vor dem brennes des ebn Files den Controller zu löschen. Wenn Du ein x-beliebiges Hex File in den HVprog brennst klappt dann der verify? Dann sollte zumindest mit dem ISP Teil der Schaltung alles OK sein. Nach dem brennes des abn Files müssen die LED in der von Tobi beschriebenen Weise leuchten, auch wenn ein verify error angezeigt wird. Welchen Controllertyp stellst Du denn bei avrprog ein? Der mega8115 sollte klappen. @mthomas: Der Tipp ist gut! Vor dem brennen des ebn Files müssen die Fuses für XTAL gesetzt werden, sonst taktet der mega8535 intern! Der "standart" 90S8535 hat diese Fusebits nicht, deshalb werden sie auch nicht durch das ebn File gesetzt. (allerdings müssten die LED dann trotzdem leuchten, nur die Baudrate ist dann falsch). Das ebn File setzt die Fuses nicht, nur die Lockbits. Im Dateianhang mal ein Bild von meinem HV-Prog, ist gerade fertiggeworden. Viel Erfolg, Klaus
Hallo Klaus, der ISP-Teil der Schaltung sollte okay sein. Ich habe ein einfaches Programm mit dem AVR-Studio erstellt und dann geflashed. Programming & Verifying Ok. Konnte den Code auch wieder auslesen. Ich verwende den 8535. Im AVR-Prog kann ich bei diesem eingestellten Controller nur die Lock-Bits setzen und SPI enable. Sonst ist da nix. Liegt dort vielleicht schon der Fehler? Vielen Dank für die bisherige Unterstützung, Torsten PS: Wir werden das Teil schon bezwingen ;)
meinst du jetzt einen mega8535 oder at90s8535? klar, irgendwie kriegen wir das schon ans laufen. :)
ich verwende den at90s8535. Tests und oder Versuche kann ich aber erst wieder am WE durchführen. Bin bis dahin beruflich unterwegs.
habe heute noch ein wenig ausprobiert und das Problem eingrenzen können. Der Programmer kann in den AT90S8535 kein FF schreiben. Sobald in einem Hex-File ein FF vorkommt bricht der Programmer an dieser Stelle ab. Eine Idee woran das liegen kann? Grüsse, Torsten
Hallo Torsten, welche Firmware im avr910 verwendest Du? Mit der V3.6 von meiner Seite dürfte das nicht vorkommen, jedenfalls hat das noch niemand berichtet. FF muss ja nicht gebrannt werden, das ist ja der Zustand nach dem löschen des Flash. Viel Erfolg, Klaus
kommt der fehler beim verify oder direkt beim schreiben? wenn erst beim verify könnte das auf einen fehlenden/fehlerhaften chip erase hinweisen (da ff nicht geschrieben wird wäre der alte speicherinhalt noch da). wenn direkt beim schreiben wirds wohl komplizierter. falls es mit der aktuellen firmware nicht geht müssen wir mal schaun wo da der bug begraben liegt
Der Fehler kommt direkt beim schreiben. Ich benutze die AVR-Version 3.6 In dem ScreenShot habe ich mal links ein AT90S2313 und rechts einen AT90S8535 am AVR-Prog gehabt. Wenn ich ein Chip Erase ausführe und dann den Chip auslese werden nur FF's ausgelesen. Das scheint somit zu funktionieren.
Ich glaube schon fast dass es an meinem Board liegt. Habe mal ein Foto gemacht. @Klaus: Gibt es von Deinem HV-Prog ein Layout welches ich verwenden könnte. Bin zwar eigentlich nicht so gut bei Doppel-Layer-Platinen, aber vielleicht kann man das auch mit Brücken lösen.
Torsten, passiert der Fehler beim schreiben auch beim 2313? Probiere mal als Alternative die Version 3.2 von meiner Seite. Ich glaube nicht, dass es an Deinem Board liegt, wenn das Programmieren von FFs nicht geht. Ich werde mal versuchen, das beim 90S8515 nachzustellen, den habe ich hier. Das aktuelle Layout ist leider nicht wirklich dazu geeignet mit Brücken zu arbeiten. Ich denke Dein Board sollten wir schon noch zum laufen bringen. Hast Du gar keinen anderen Programmer, den Du mal probieren könntest? Irgendwie musst Du doch auch den avr910 gebrannt haben. Viel Erfolg, und nicht aufgeben... Ciao, Klaus
ich werd das morgen auch mal versuchen. hab noch ein paar 8535 hier (zwar mega, aber das sollte gehen). wenn da ein bug in der firmware des programmers ist werd ich mal die zeilen, die die 0xff überspringen suchen und rausnehmen.
@Tobi: der Mega8535 hat Page Mode zum programmieren, benutzt also andere Routinen zum schreiben. Ist für einen 100% Vergleich nicht zu verwenden. @Torsten: Ich habe gerade einen 90S8515 mit der Firmware 3.6 geschrieben, alles OK. Auch im Mode für den 90S8535 getestet. Klappt ebenfalls. Der 8515 hat die gleiche interne Struktur wie der 8535. Im Anhang ein File zum testen (alle Bytes von 0x00 bis 0xFF). Probier mal das, am besten noch mit einem anderen Programmer. Ciao, Klaus
@Torsten, noch ein Tipp und eine Änderung die ich im momentanen testcode drin habe: Ändere mal die "brne es_err" Verzweigung wie unten angegeben auf "brne ws_del". Wenn Du im Source nach "ws_cb:" suchst, findest Du die Stelle sehr schnell. ws_cb: cp s_data,p_data breq ws_ok ; s_data = p_data dec temp3 brne ws_cy ; loop -->; rjmp ws_err ; 256 polling cycles are over --> rjmp ws_del ; 256 polling cycles are over, ; give additional standart Time ws_ok: tst temp3 ; if s_data = p_data at first cycle, Es gibt übrigens doch noch einen Unterschied zwischen 8515 und 8535: Der Wert des Polling Codes ist beim 8515 0x7F, beim 8535 0xFF. Wenns immer noch nicht klappt, schicke ich Dir mal einen anderen Source für den Programmer. Ciao, Klaus
Habe den Source geändert: ;ws_cb: ; cp s_data,p_data ; breq ws_ok ; s_data = p_data ; dec temp3 ; brne ws_cy ; loop ; clr B_Flag ; Reset B_Flag for normal operation ; breq ws_err ; 256 polling cycles are over ws_cb: cp s_data,p_data breq ws_ok ; s_data = p_data dec temp3 brne ws_cy ; loop ; rjmp ws_err ; 256 polling cycles are over rjmp ws_del ; 256 polling cycles are over, ; give additional standart Time ws_ok: tst temp3 ; if s_data = p_data at first cycle, breq ws_FF ; Check if 0xFF Code was sent rjmp ws_end Das Programmieren scheint nun zu gehen, es kommt jedoch dann eine Fehlermeldung. Denke aber das die vom Verify kommt. siehe Anhang Habe dann mal den AVR-Prog vom HV-Prog abgezogen, Strom getrennt und dann wieder angeschlossen. Nix passiert :( Keine LED zeigt etwas an. Irgendwie ist da der Wurm drin. Bin aber sicher dass WIR das hinbekommen. Werde morgen mla ein kurzes Progi schreiben, welches nur den PA4 und PA5 schaltet, mal sehen ob die LED's dann angehen. Bisher habe ich die einfache LPT-Port-Version (wie bei Rowalt beschrieben) genutzt. Damit habe ich dann auch den ersten 2313 für den AVR-Prog beschrieben. Bis dahin, Torsten
soeben den LED-Test erfolgreich durchlaufen :) Das Programmieren des ebn-Files funktioniert nun auch - wie oben gesagt mit dem Verify-Fehler (der Aufgrund der Lock-Bits Normal ist - denke ich zumindest). Nur leider passiert dann nix. Wir werden den Fehler wohl noch finden. Bis dahin, Torsten
@Torsten, Der Lesefehler hat nichts mit den Lockbits zu tun, bei gesetzten Lockbits müsste 0xFFFF gelesen werden. Hast Du vielleicht einen Wackelkontakt zwischen Board und Brenner? Oder am Quarz auf dem Board? Oder zwischen Steckverbindung und 8535? Der Fehler tritt ja eindeutig nicht bei einem 0xFF Byte auf. Wir helfen Dir ja so gut es geht, allerdings bringt das ganze nur was, wenn mal eine Fehlerquelle nach der anderen ausgeschlossen oder erkannt wird. Mal hier und mal da probieren hilft nicht so gut. Brenn mal das weiter oben angehängte burntest.hex File. (am besten mehrmals nacheinander, um einen Wackler auszuschliessen) Brenn es auch mal mit dem anderen Programmer, wenn es nicht klappt. Erst wenn beim brennen keine Fehlermeldungen mehr auftreten, schau mal wieder nach den LEDs. Findem musst den Fehler schon Du, wir können nur ein paar Tipps geben, oder ich kann die avr910 Software fixen, wenn der Fehler von dort kommt. Deshalb mal einen anderen Programmer nehmen. Ciao, Klaus
Habe mit Deiner Datei einen Test gefahren -> fehlerfrei Dann habe ich einfach mal selber eine BurnTest-Datei erstellt, welche fast den gesamten Speicher füllt -> fehlerhaft. Das Ergebnis habe ich dann mal in einer Excel-Tabelle gegenüber gestellt. Es ist dort ein System erkennbar. Leider habe ich keinen andern Programmer mit dem ich den Test auchmal durchfahren könnte. Auf meine HV-Prog-Board habe ich mal den kompletten Sockel "neu eingelötet", ebenso den Quarz und den ISP-Stecker. Bringt leider keine Besserung. Mein alter LPT-Programmer geht gar nicht mehr (seit XP-SP2). Vielleicht setzte ich mal einen Rechner mit W95 auf um den Test dann mal damit zu machen. Viele Grüsse, Torsten
der fehler tritt nur bei einem FF gefolgt von einem FE auf, und zwar nur dort. @klaus: könnte es sein, dass der programmer in so einem fall zu viel überspringt? da der fehler nur an einer so klar definierten stelle auftritt lässt sich ein hardwarefehler auf dem hvprog/avr-programmer board so ziemlich ausschliessen. das macht die wahrscheinlichkeit eines softwarefehlers grösser. wo auch immer der softwarefehler nun liegt... könnte man nicht das komplette überspringen solcher code inclusive polling ausschalten und auf den alten pause modus zurückschalten (d.h die funktionen Wait_S/M komplett rausnehmen?) sonst, @thorsten hast du zufällig einen mega16 bei dir rumfliegen? dann könnte ich dir was zusammenbasteln.
@Torsten, Interessantes Fehlerbild! In jedem 16 (0x0F) übertragenen Block wird das letzte Byte nicht gesendet oder nicht gebrannt.(allerdings kommt ein 0xFF auch nur in jedem 16 Block vor) Interessanterweise kann ich diesen Fehler mit avrprog 1.37 und einem 90S8515 nicht nachstellen, dort geht er (zumindest mit dem STK File) einwandfrei. Egal ob ich einen 8515 oder einen 8535 einstelle. @Tobi: ist auch plausibel, lässt sich bei mir aber auch nicht nachstellen. Ich habe das burntest1 File im Anhang bei mir auch ohne Probleme brennen können. Dort kommt immer als vorletztes Byte ein 0xFF und dann ein 0xFE. Anscheinend tritt der Fehler auch nur auf, wenn das FF als vorletztes Byte kommt, im STK500 File sind ja am Anfang auch einige FFs, und bei mir lässt es sich brennen. Seltsame Geschichte! Ich habe für diesen Test avrdude benutzt, werde es aber gleich noch mal mit avrprog probieren. @Torsten, versuch mal das von mir angehängte File, und schicke mir mal das Testfile von Dir im hex Format. Bau in dein Testfile mal ausschliesslich die Zeilen ein, die Fehler provozieren. Mal sehen, ob es jedesmal oder nur jeden 16 Block auftritt. Wenn der Fehler immer auftritt, probier mal folgende Änderung: ws_pol: cpi device,0x13 ; if (device == S1200D) breq ws_del ; polling not used (bug!) cpi device,0x20 ; if (device == S2313) brne ws_def ; S2313 shows 0x7F during polling cpi p_data,0x7f ; id (data == 0x7f) breq ws_del ; wait default delay ws_def: --> cpi p_data,0xff ; id (data == 0xff) --> breq ws_del ; wait default delay andi pol_cmd,0x0f ; write command: 0x48, 0x40 ori pol_cmd,0x20 ; read command: 0x28, 0x20 clr temp3 ; clear polling counter Du könntest noch die avr910 Software 3.2 von meiner Seite probieren, dort wird nicht im Blockmode übertragen. Bis bald, ;-) Klaus
oder avrdude im avrprog mode. das benutzt auch kein blockmode.
@Tobi: avrprog mode? meinst Du -c avr910? @Torsten: na wenn Du avrdude hast, probier das bitte auch mal -c butterfly ist blockmode, -c avr910 ohne Blockmode
So, ich konnte den Fehler jetzt nachstellen! Hab noch einen 2333 gefunden, der das gleiche Polling-Verhalten wie der 8535 hat. Tobis analyse war richtig. Bei einem 0xFF wird das nächste Byte übersprungen. (passiert in beiden modes, also auch in der V3.2) Erstaunlich dass der noch nirgends aufgetreten ist... Mea Culpa! @Torsten: Die in meinem vorletzten Posting gemachte Änderung bei ws_def: funktioniert bei mir! Bitte probier das zuerst aus! Heute Abend mach ich einen vernünftigen Bugfix. Asche auf mein Haupt, und danke für Eure Hilfe. Bis später, Klaus
Werde ich heute abend direkt testen. War schon am überlegen ob ich mir hier in der Apotheke (Conrad) einen neuen Controller mit Fassung kaufe um es auf eine Lochraster zu testen damit ich die meine Platine ausschließen kann oder dort den Fehler suchen muss. Das Geld spare ich mir nun erstmal. Ich bin dann vermutlich der erste, der Tobi's HV-Prog mit dem 90S8535 nachgebaut und mit dem AVR-Prog beschreiben wollte. Bin auf alle Fälle gespannt ob es damit klappt. Soll ich die Änderung bei WS_CP wieder zurück nehmen? Berichte heute abende ob es funktionierte. Der BurnHex-File welches ich zum testen verwendet habe ist in der Excel-Tabelle in Spalte A, in Spalte B ist das ausgelesene File. Habe das Hex-File angehängt. Danke an alle die bisher geholfen haben, Torsten
@Tobi, Du bist anscheinend überhaupt der erste, der einen 90S8535 mit dem avr910 gebrannt hat (oder zumindest ein 0xFF im File hatte) ;-) Die Änderung kannst Du erst mal drinlassen, ich mache sowieso noch bis Weihnachten die neue Version fertig. Bis später, Klaus
Es hat geklappt! Mein Burntest-File ist erfolgreich programmiert worden, keine Fehler mehr. Darauf sofort das STK500.EBN File genommen und es hat geklappt. Keine Fehler mehr. Nach einem Reset kommt nun folgenden LED-Folge : ROT ROT-GN GN Dunkel GN DANKE an alle! Jetzt mache ich dann erstmal Schluß (Des Haussegen wegen) Werden die Tage mal testen einen ATTiny2313 damit zu brennen. Viele Grüsse, Torsten
guuut :) das hört sich doch sehr gut an! berichte mal wenn das brennen damit geklappt hat. aber jetzt kann eigentlich nicht mehr viel schief gehen @klaus wirklich seltsam, dass das noch nicht aufgefallen ist. dabei sind doch 0xff nicht gerade selten. immerhin ein bug weniger :)
@Torsten Beharrlichkeit zahlt sich aus. Ein Glück das das Problem jetzt gefixt ist ;-) @Tobi liegt wohl eher daran, dass die 90S8535 so selten geworden sind... Der 2313 und 8515 z.B. pollt ja mit 0x7F, da ist der Fehler nicht aufgetreten, Die Megas machen Page Mode, da tritt es ebenfalls nicht auf Bin gerade am "finalen" Fix (rewrite der polling Routine) Mal sehen, ob wir dann neue Bugfs haben ;-) Danke für die Unterstützung an alle, Klaus
Bitte 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.