Forum: Mikrocontroller und Digitale Elektronik HV Prog: STK500.ebn flashen -> "Programming failed"


von Torsten (Gast)


Lesenswert?

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

von Tobi (Gast)


Lesenswert?

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

von Klaus Leidinger (Gast)


Lesenswert?

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

von Tobi (Gast)


Lesenswert?

ich antworte mal stellvertretend. er benutzt deinen avr910 programmer

von crazy horse (Gast)


Lesenswert?

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.

von Torsten (Gast)


Lesenswert?

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

von Tobi (Gast)


Lesenswert?

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)

von Torsten (Gast)


Lesenswert?

ich meinte die LEDs vom AVR-Prog.

Beim HV-Prog passiert gar nichts. Nicht eine LED geht an (ausser die
für die Spannungsversorgung).

von Torsten (Gast)


Lesenswert?

@Tobi: Danke ! - Werde es heute abend mal testen und dann berichten.

von Torsten (Gast)


Lesenswert?

@Tobi: Hat leider nicht geklappt.
Habe noch immer den selben Effekt. Ich glaube schon fast das es an dem
stk500.ebn-File liegt.

von mthomas (Gast)


Lesenswert?

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.

von Klaus Leidinger (Gast)


Angehängte Dateien:

Lesenswert?

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

von Torsten (Gast)


Lesenswert?

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 ;)

von Tobi (Gast)


Lesenswert?

meinst du jetzt einen mega8535 oder at90s8535?

klar, irgendwie kriegen wir das schon ans laufen. :)

von Torsten (Gast)


Lesenswert?

ich verwende den at90s8535.

Tests und oder Versuche kann ich aber erst wieder am WE durchführen.
Bin bis dahin beruflich unterwegs.

von Torsten (Gast)


Lesenswert?

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

von Klaus Leidinger (Gast)


Lesenswert?

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

von Tobi (Gast)


Lesenswert?

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

von Torsten (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Torsten (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Klaus Leidinger (Gast)


Lesenswert?

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

von Tobi (Gast)


Lesenswert?

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.

von Klaus Leidinger (Gast)


Angehängte Dateien:

Lesenswert?

@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

von Klaus Leidinger (Gast)


Lesenswert?

@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

von Torsten (Gast)


Angehängte Dateien:

Lesenswert?

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

von Torsten (Gast)


Lesenswert?

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

von Klaus Leidinger (Gast)


Lesenswert?

@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

von Torsten (Gast)


Angehängte Dateien:

Lesenswert?

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

von Tobi (Gast)


Lesenswert?

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.

von Klaus Leidinger (Gast)


Angehängte Dateien:

Lesenswert?

@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

von Tobi (Gast)


Lesenswert?

oder avrdude im avrprog mode. das benutzt auch kein blockmode.

von Klaus Leidinger (Gast)


Lesenswert?

@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

von Klaus Leidinger (Gast)


Lesenswert?

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

von Torsten (Gast)


Angehängte Dateien:

Lesenswert?

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

von Klaus Leidinger (Gast)


Lesenswert?

@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

von Torsten (Gast)


Lesenswert?

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

von Tobi (Gast)


Lesenswert?

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 :)

von Klaus Leidinger (Gast)


Lesenswert?

@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
Noch kein Account? Hier anmelden.