hallöle,
ich hab den uralten STK500v1 aus dem Jahr 1783 oder so... (1783 war ein
hervorragendes Jahr...:-)
Im Lauf der Zeit hab ich damit immer mal wieder kleine Minis in
Assembler mit dem AVRstudio3 und 4 programmiert... immer wieder ist es
mal vorgekommen, daß sich die Kiste mitten beim Flashvorgang weggehängt
hat.
meistens reichte es dann den ISP-Takt mal von (meinen normalen)56 auf
115 oder auf 4 kHz zu verändern und dann lief das Flashen des jeweiligen
Files wieder anstandslos durch. Auch warens mal Inkompatibiläten der
verschiedenen Softwarestände (AVRstudio3.xx und 4.xx) und auch
verschiedene PCs...
ABER: das HEXfile aus dem Anhang (erzeugt mit WinAVR20070122 unter
AVRstudio4.14-598) läßt sich nicht flashen... egal wie und was ich
anstelle, es bricht mittendrin ab. Das File ist zwar kompiliert für nen
Mega64, aber ich habs auch mal mit nem Mega16 probiert... gleiches
Ergebnis, Abbruch irgendwo mittendrin. Wenn ich den mega64 danach
auslese, dann sehe ich, daß etwa 1a00 bis 1e00 words geflasht wurden
(variiert immer etwas) und dann der Abbruch kam.
Mit Ponyprog2000 läßt sich das File einwandfrei (so wie alle anderen
auch) flashen und das Programm läuft auch korrekt... dauert mir aber
ehrlich gesagt viiiiiiiel zu lange.
Kennt jemand dieses Verhalten, bzw. weiß jemand wo hier der Fehler
liegt?
SoLaLa wrote:
> hallöle,> ich hab den uralten STK500v1 aus dem Jahr 1783
Kann nicht sein.
Den AVR gibts ja erst seit 1997 und das STK500 seit 2000.
Hast Du denn auch im STK500 die Firmware updaten lassen?
Peter
hallo Peter,
STK500 hat version ..0A
das interessante ist ja, wenn ich am C code mal wieder n bissi was
ändere, dann läuft das anstandslos durch, auch mit 460k ISPfrequenz.
Allgemein möcht ich sogar behaupten WENN das proggen klappt, dann auch
mit allen möglichen geschwindigkeiten. manchmal bekomm ich aber hexfiles
die nicht auf Anhieb flashbar sind (und dann nach umstellen auf 4kHz
sich doch flashen lassen).
Aber dieses eine ist dermaßen hartnäckig :-) geht einfach nicht... und
deshalb interessiert mich halt das warum.
ich hatte da irgendwo mal was gelesen mit $FF oder $F0 oder sowas genau
an eine Pagegrenze. Aber das war nicht auf STK500 bezogen sondern auf
irgendnen anderen ISPprogger
@Rosettenhengst:
danke für die Info... aber JTAG wär ja auch ganz fies, wenn das nicht
ginge :-)
für alle anderen die gerad n bischen rumflashen möchten:
bitte mal kurz ausprobieren ob sich das ding auf nem STK500 oder
kompatibel auf nen mega64 flashen läßt.
ok, hier nochmal n paar infos:
Detecting on 'COM1'...
STK500 with V2 firmware found on COM1
Getting revisions.. HW: 0x02, SW Major: 0x02, SW Minor: 0x0a .. OK
Getting isp parameter.. SD=0x02 .. OK ===>115kHz
Mega16 auf internem Sockel:
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Reading signature .. 0x1E, 0x94, 0x03 .. OK!
Leaving programming mode.. OK!
Mega64 auf externem Board:
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Reading signature .. 0x1E, 0x96, 0x02 .. OK!
Leaving programming mode.. OK!
5V, 16MHz Quarz
Fuses:
Entering programming mode.. OK!
Reading fuses address 0 to 2.. 0xBE, 0xDF, 0xFF .. OK!
Leaving programming mode.. OK!
BODEN war auch schon abgeschaltet, JTAG war auch schon mal probehalber
eingeschaltet (mußte aber wieder aus, weil ich den PORTF brauche)
SUT_CKSEL war auch schon auf 16k+64ms
hier mal wieder geändert:
Entering programming mode.. OK!
Writing fuses address 0 to 2.. 0xFF, 0xDF, 0xFF .. OK!
Reading fuses address 0 to 2.. 0xFF, 0xDF, 0xFF .. OK!
Fuse bits verification.. OK
Leaving programming mode.. OK!
auf "PROGRAM" geklickt (mit auto erase, ist aber egal, 20mal manuelles
Löschen vorher bringt auch nix):
Getting isp parameter.. SD=0x02 .. OKOK
Reading FLASH input file.. OK
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Erasing device.. OK!
Programming FLASH .. FAILED! ===> hier läuft jetzt der schöne
blaue Balken... leider nicht bis zum Schluß durch, sondern bleibt
mittendrin irgendwo stehen
Leaving programming mode.. FAILED!
zackbummweg... LEDleuchtet orange und nur n Power off/on bringt wieder
leben in die Kiste.
Vielleicht ist Dein Netzteil zu schwach und die Spannung aufm STK bricht
ein.
Wichtig ist auch, daß das Netzteil zum STK erdfrei ist.
Die Erdverbindung darf ausschließlich über Pin 5 der RS-232 erfolgen und
nirgends anders.
Ideal sind alte Wandwarzen (z.B. 12V/300mA).
Peter
Da du den ATmega64 offenbar ja extern hast, kommen weitere Fragen auf:
. saubere Masseverbindungen
. nicht zu lange ISP-Kabel
. ordentliche Abblockung des ATmega64
Wenn du mir erzählst, was ich damit machen soll, kann ich noch einen
Funktionstest vornehmen. ;-) Der ATmega128 sollte zum ATmega64
binärkompatibel sein.
Danke mal für die vielen Tips und Danke Jörg, daß Du das mal eben hast
durchlaufen lassen.
Ich hab gestern das ganze mal genauer untersucht:
es ist KEIN analoges Problem (Netzteil, Erdung, Entkopplung usw...)
die Versorgungsspannung (auf dem externen Board genauso wie die vom
STK500) zeigt mir n kleinen 50mV ripple im 100ns bereich, sonst nix.
Ich denke, bin mir mittlerweile ziemlich sicher, daß es ein Problem der
STK500 Software ist (Probleme der seriellen Schnittstelle mit XP hab ich
mal durch Test an nem Win98 Rechner ausgeschlossen, der das gleiche
Verhalten zeigt)
Nachdem ich (danke an dieses Forum) das Logging aktivieren konnte,
zeigte sich, daß o.g. HEXfile beim flashen immer exakt an der selben
Stelle hängenbleibt:
1
Receiving packet 06/27/2008 02:09:24.171
2
(10000ms) < 1B 51
3
(expected 3 more bytes but timed out)
4
Sequence number 81, message size n/a, checksum n/a
5
No data in packet
6
Returned status: Client: Total timeout exceeded (PC side gave up)
Wenn ich dann im Source beispielsweise innerhalb einer Stringkonstante
nur einen einzigen Buchstaben ändere, dann läuft das flashen anstandslos
durch. Ändere ich den Buchstaben wieder auf den vorherigen Inhalt, dann
bleibts flashen wieder reproduzierbar an exakt obiger Stelle hängen.
hallöle an alle interessierten :-)
ich hab noch n bissi Info und glaube, daß das Problem tatsächlich die
STK500 Software ist. Ich hab das o.g. Hexfile ---mal wieder--- mit dem
ponyprog in den mega64 geschaufelt. Dann das mega64board wieder an den
STK500 gehängt und mit AVRstudio connected.
Ich hab jetzt KEINEN ERASE veranlaßt, sondern schlichtweg nur auf
"program" geklickt... wie gewohnt bleibt der Flashvorgang mit
Fehlermeldung kurz vorm Ende stehen und bricht ab.
Danach hab ich den Verify gemacht und eben festgestellt, daß das File
immer noch vollständig im chip vorhanden war. (wurde ja auch nur
"drüberkopiert").
Für mich bedeutet das jetzt, daß NICHT das flashen des chips selbst,
sondern die Kommunikation zwischen STK500 und PC bzw. die Verarbeitung
der übertragenen Sequenzen im STK500 selbst den Abbruch verursacht.
irgendwelche Ideen?
SoLaLa wrote:
> ich hab noch n bissi Info und glaube, daß das Problem tatsächlich die> STK500 Software ist.
Oder in deinen seriellen Treibern.
Gegenbeweis:
Ich habe ihm exta noch einen ATmega64 gefaket (und dann mit -F zum
Weitermachen gezwungen, da ja ein ATmega128 drin ist), damit er
intern exakt so arbeitet wie bei einem ATmega64. Du kannst in den
Ausschriften auch sehen, dass meine Firmware mit 2.10 exakt deiner
(AVR Studio: 0x02 0x0a) entspricht.
Ich hab Dein Hex auch flashen können, aber nur in nen ATMega168, da ich
keinen größeren habe.
Mein STK500 hat HW: 02, SW: 02,0a
SoLaLa wrote:
> irgendwelche Ideen?
Wenn Du nen Bootloader in den Chip brennst, kannst Du das Hex dann per
Bootloader flashen.
Peter
hi ihr lieben mitfühlenden :-)
ich hab soeben den 4. (den vierten) PC getestet mit gleichem Ergebnis...
Abbruch
das waren jetzt: Asus A7V@1GHz mit win98SE, altes Gericom 1st
Supersonic@1GHz mit WinXP HomeSP2 (das hat noch ne serielle), AsRock
K7VT4A@2,6GHz winXP HomeSP2 und dieser ist jetzt n Asus P5LD2@3,46GHz...
sniffsniff...
achja: zwischenzeitlich hatte ich dann auch mal den Weg über AVRdude
gemacht (unter WinXP)... es lief ein wenig besser, ließ sich manchmal
sofort, manchmal nachm 3. Anlauf flashen, manchmal aber auch wieder
garnicht... Um mal wieder ins Jahr 1783 zurückzufallen:
" Das ist Teufelswerk!"
hmmmm... ich werd mir gelegentlich mal was zum Loggen der seriellen
zusammenstöpseln
ahja... das mit dem Bootloader war ja auch ne nennenswerte Idee, muß ich
mir mal zu Gemüte führen aber gleich ne Frage vorweg:
Wenn der Bootloader dann da drauf ist, wird ab dann immer noch über das
STK500 mit serieller Schnittstelle das Hauptprogramm übertragen, also
das STK500-Protokoll benutzt? Wenn ja, dann wäre es n ausgiebigen Test
wert.
SoLaLa wrote:
> Wenn der Bootloader dann da drauf ist, wird ab dann immer noch über das> STK500 mit serieller Schnittstelle das Hauptprogramm übertragen, also> das STK500-Protokoll benutzt? Wenn ja, dann wäre es n ausgiebigen Test> wert.
Das Übertragen erfolgt dann über RS232 SPARE.
Mein Bootloader benutzt nicht das STK500-Protokoll, da es benötigte
Funktionen nicht unterstützt (Autobauding, Eindrahtmodus,
Verbindungsaufbau durch den AVR innerhalb 0,3s nach Poweron-Reset).
Peter
P.S.:
Ein RS232-Sniffer:
http://www.serial-port-monitor.com/free-serial-port-monitor-product-details.html
SoLaLa wrote:
> achja: zwischenzeitlich hatte ich dann auch mal den Weg über AVRdude> gemacht (unter WinXP)... es lief ein wenig besser, ließ sich manchmal> sofort, manchmal nachm 3. Anlauf flashen, manchmal aber auch wieder> garnicht...
Was passierte, wenn es sich nicht flashen ließ? Auch wieder compare
errors?
Ist schon irgendwie seltsam, dass alle anderen deine Hexfiles benutzen
können.
Zwischenbericht:
-ISPheader für den 90S8535 auf den SK500 gelötet
-Reset und MCUreset verbogen,
-90S1200 mit dauerLOW stillgelegt
-STK500_90S8535.hex mit Ponyprog geflasht und verifiziert
-auch der EEprom inhalt ist vorher sauber leer und wird dann nach dem
ersten Start mit den Hard-und Software-Versionsnummern beschrieben (und
noch n paar andere Sachen, denke mal Takt-/Oszillatorsettings, Vcc/Vtg
und sowas)
-Verhalten danach beim Programmieren des obigen hexfiles--->keine
Änderung
@Joerg: Compare- bzw. Verifyerrors hab ich ja nicht, entweder bleibt der
Flashvorgang stehen, dann wird bis dahin alles sauber übertragen und
weil der PC keine Antwort mehr vom STK bekommt gibt die Software nach 10
sec mit nem timeout auf (AVRdude zeigt die timeouts auch an, während
AVRstudio einfach nur wartet und dann das übliche Fehlerpopup
erscheint).
Ich hatte ja oben schonmal beschrieben, daß ich den Mega64 mit Ponyprog
fertig programmiert hatte und dann mit STK500 OHNE VORHERIGES LÖSCHEN
dasselbe File nochmal "drüberprogrammiert" hab. Die interne
Programmierlogik des mega64 kann dann immer nur mit ner Erfolgsmeldung
antworten, die bits des Flashs werden an den entsprechenden Stellen ja
nur von 1 auf 0 reduziert, da sie aber vorher schon richtig waren gibt
es danach keine Verifyerrors.
Für den anderen Fall, daß das Flashen ganz durchläuft hatte ich noch nie
irgendeinen Verifyerror, weder bei diesem noch bei irgendnem anderen
chip.
Ich kümmer mich mal ums Loggen der seriellen Kommunikation
Hast du Zugriff auf irgendein unixoides Betriebssystem (Linux, MacOS X,
FreeBSD, PC-BSD, was auch immer)? Dann würde ich mir das dort nochmal
ansehen.
Ich kann dir nur wiederholen, dass ich nicht die geringsten Probleme
mit deinem Hexfile habe.
SoLaLa wrote:
> aber ich hab keine Ahnung was ich für AVRentwicklung auf Linux alles> brauche...
Um ein Hexfile zu flashen, brauchst du nur ein avrdude.
"Uuuuups..." sprach der Fehler, "da bin ich wieder!" :-)
hallöle an alle,
da ich mal wieder n bissi Zeit hatte und auch wieder n bissi bauen mußte
(Motordrehzahl/Lüfterdrehzahl/Geschwindigkeit/Temperatur/Spannungs- und
Lüftertakterfassung mit serieller Ausgabe auf n Laptop) kams wie es
kommen mußte:
das STK500 verweigert recht häufig wie oben beschrieben seinen Dienst...
grmmmpffff
daher hab ich mir mal auf die Schnelle den USBprogV3 nachgebaut und
siehe da: alles läßt sich immer anstandslos flashen (aus AVRstudio
heraus). Hab auch mehrfach die Gegenprobe mit dem STK500 gemacht.
Es muß also wirklich nen Fehler auf diesem alten Board sein, bzw. ein
bug in der Software im Zusammenspiel mit dem alten V1-Board.
Ich erkläre das Thema hier deshalb mal für erledigt zumal ich mit dem
USBprog auch sehr gut leben kann... Danke mal an den/die Entwickler des
USBprog
