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?
Hi, lässt sich problemlos am ATSAM7SE512-EK raufspielen. Habe das Olimex-USB-JTAG dazu verwendet.
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.
Wie hast du den ATmega64 an das STK getüddelt? Kann das STK die Kennung und die Fuses korrekt auslesen?
Ich kann es leider nicht testen, da ich weder einen ATmega64, noch ein passendes Adapter habe.
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
ATmega64 habe ich gerade nicht, nur einen ATmega128 (in einem STK501 montiert):
1 | % avrdude -p m128 -c stk500v2 -P /dev/ttyS0 -U ~/download/AccuControl.hex |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.01s |
6 | |
7 | avrdude: Device signature = 0x1e9702 |
8 | avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed |
9 | To disable this feature, specify the -D option. |
10 | avrdude: erasing chip |
11 | avrdude: reading input file "/home/jwunsch/download/AccuControl.hex" |
12 | avrdude: input file /home/jwunsch/download/AccuControl.hex auto detected as Intel Hex |
13 | avrdude: writing flash (7968 bytes): |
14 | |
15 | Writing | ################################################## | 100% 10.94s |
16 | |
17 | avrdude: 7968 bytes of flash written |
18 | avrdude: verifying flash memory against /home/jwunsch/download/AccuControl.hex: |
19 | avrdude: load data flash data from input file /home/jwunsch/download/AccuControl.hex: |
20 | avrdude: input file /home/jwunsch/download/AccuControl.hex auto detected as Intel Hex |
21 | avrdude: input file /home/jwunsch/download/AccuControl.hex contains 7968 bytes |
22 | avrdude: reading on-chip flash data: |
23 | |
24 | Reading | ################################################## | 100% 10.09s |
25 | |
26 | avrdude: verifying ... |
27 | avrdude: 7968 bytes of flash verified |
28 | |
29 | avrdude: safemode: Fuses OK |
30 | |
31 | avrdude done. Thank you. |
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:
1 | % avrdude -p m64 -c stk500v2 -P /dev/cuad0 -Fv -U /tmp/AccuControl.hex |
2 | |
3 | avrdude: Version 5.6cvs, compiled on Jun 13 2008 at 23:21:15 |
4 | Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ |
5 | |
6 | System wide configuration file is "/usr/local/etc/avrdude.conf" |
7 | User configuration file is "/home/joerg/.avrduderc" |
8 | |
9 | Using Port : /dev/cuad0 |
10 | Using Programmer : stk500v2 |
11 | AVR Part : ATMEGA64 |
12 | Chip Erase delay : 9000 us |
13 | PAGEL : PD7 |
14 | BS2 : PA0 |
15 | RESET disposition : dedicated |
16 | RETRY pulse : SCK |
17 | serial program mode : yes |
18 | parallel program mode : yes |
19 | Timeout : 200 |
20 | StabDelay : 100 |
21 | CmdexeDelay : 25 |
22 | SyncLoops : 32 |
23 | ByteDelay : 0 |
24 | PollIndex : 3 |
25 | PollValue : 0x53 |
26 | Memory Detail : |
27 | |
28 | Block Poll Page Polled |
29 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
30 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
31 | eeprom 4 20 64 0 no 2048 8 0 9000 9000 0xff 0xff |
32 | flash 33 6 128 0 yes 65536 256 256 4500 4500 0xff 0xff |
33 | lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
34 | hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
35 | efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
36 | lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
37 | calibration 0 0 0 0 no 4 0 0 0 0 0x00 0x00 |
38 | signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 |
39 | |
40 | Programmer Type : STK500V2 |
41 | Description : Atmel STK500 Version 2.x firmware |
42 | Programmer Model: STK500 |
43 | Hardware Version: 2 |
44 | Firmware Version Master : 2.10 |
45 | Topcard : STK501 |
46 | Vtarget : 3.1 V |
47 | SCK period : 10.9 us |
48 | Varef : 3.0 V |
49 | Oscillator : 3.686 MHz |
50 | |
51 | avrdude: AVR device initialized and ready to accept instructions |
52 | |
53 | Reading | ################################################## | 100% 0.02s |
54 | |
55 | avrdude: Device signature = 0x1e9702 |
56 | avrdude: Expected signature for ATMEGA64 is 1E 96 02 |
57 | avrdude: safemode: lfuse reads as E3 |
58 | avrdude: safemode: hfuse reads as 11 |
59 | avrdude: safemode: efuse reads as FF |
60 | avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed |
61 | To disable this feature, specify the -D option. |
62 | avrdude: erasing chip |
63 | avrdude: reading input file "/tmp/AccuControl.hex" |
64 | avrdude: input file /tmp/AccuControl.hex auto detected as Intel Hex |
65 | avrdude: writing flash (7968 bytes): |
66 | |
67 | Writing | ################################################## | 100% 11.01s |
68 | |
69 | avrdude: 7968 bytes of flash written |
70 | avrdude: verifying flash memory against /tmp/AccuControl.hex: |
71 | avrdude: load data flash data from input file /tmp/AccuControl.hex: |
72 | avrdude: input file /tmp/AccuControl.hex auto detected as Intel Hex |
73 | avrdude: input file /tmp/AccuControl.hex contains 7968 bytes |
74 | avrdude: reading on-chip flash data: |
75 | |
76 | Reading | ################################################## | 100% 10.18s |
77 | |
78 | avrdude: verifying ... |
79 | avrdude: 7968 bytes of flash verified |
80 | |
81 | avrdude: safemode: lfuse reads as E3 |
82 | avrdude: safemode: hfuse reads as 11 |
83 | avrdude: safemode: efuse reads as FF |
84 | avrdude: safemode: Fuses OK |
85 | |
86 | avrdude done. Thank you. |
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.
einen mit fedora core8 hab ich auch noch... aber ich hab keine Ahnung was ich für AVRentwicklung auf Linux alles brauche...
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
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.