Hallo,
seit kurzem beschäftige ich mich mit AVR µCs und bin sehr davon angetan;
momentan habe ich jedoch das Problem, dass mein USB-Programmer
(Diamex-AVR) sich weigert, die ATTiny2313-Controller korrekt zu
programmieren. Ohne erkennbaren Determinismus scheinen Bits zwischen
Programmer und IC zu kippen, so dass mal die Controller-Signatur nicht
stimmt, mal die Kommunikation komplett abbricht oder manchmal avrdude
erst beim Verifizieren der geschriebenen Daten aussteigt. Je nach
Mondphase funktioniert es dann auch mal.
Der Programmer ist per ISP-Stecker mit einer Platine verbunden, auf der
ein 8- und ein 20-poliger Sockel mit den entsprechenden PINS verbunden
sind; interessanterweise lassen sich ATTiny13-Controller im
erstgenannten Sockel problemlos beschreiben, während der
parallelgeschaltete 20polige Sockel halt Probleme macht. Um ein Problem
mit der Platine auszuschließen, habe ich nochmal eine zweite
zusammengelötet, die nur den 20poligen Sockel enthält; auch hier erhalte
ich nur einen bunten Strauß an Fehlermeldungen. Ein angeschlossenes
Conrad-Pong mit ATMega8 lässt sich vom Programmer problemlos
beschreiben, ich bin mir daher nicht sicher, wo ich den Fehler suchen
soll.
Hier ein Auszug aus mehreren avrdude-Aufrufen, ohne die Verkabelung oder
etwas anderes anzufassen:
1 | stefan@exa:~/git/tiny-pong […] $ avrdude -p attiny2313 -c stk500v2 -P /dev/diamex
|
2 |
|
3 | avrdude: AVR device initialized and ready to accept instructions
|
4 |
|
5 | Reading | ################################################## | 100% 0.02s
|
6 |
|
7 | avrdude: Device signature = 0x1e910a
|
8 | avrdude: safemode: Verify error - unable to read hfuse properly. Programmer may not be reliable.
|
9 | avrdude: safemode: To protect your AVR the programming will be aborted
|
10 |
|
11 | avrdude done. Thank you.
|
12 |
|
13 | stefan@exa:~/git/tiny-pong […] $ avrdude -p attiny2313 -c stk500v2 -P /dev/diamex
|
14 |
|
15 | avrdude: stk500v2_command(): command failed
|
16 | avrdude: stk500_2_ReceiveMessage(): timeout
|
17 | avrdude: stk500v2_program_enable(): bad STK600 connection status: Unknown (0x64)
|
18 | avrdude: initialization failed, rc=-1
|
19 | Double check connections and try again, or use -F to override
|
20 | this check.
|
21 |
|
22 |
|
23 | avrdude done. Thank you.
|
24 |
|
25 | stefan@exa:~/git/tiny-pong […] $ avrdude -p attiny2313 -c stk500v2 -P /dev/diamex
|
26 |
|
27 | avrdude: stk500v2_command(): command failed
|
28 | ^C
|
29 | stefan@exa:~/git/tiny-pong […] $ avrdude -p attiny2313 -c stk500v2 -P /dev/diamex
|
30 |
|
31 | avrdude: AVR device initialized and ready to accept instructions
|
32 |
|
33 | Reading | ################################################## | 100% 0.02s
|
34 |
|
35 | avrdude: Device signature = 0x1e910a
|
36 | avrdude: safemode: Verify error - unable to read efuse properly. Programmer may not be reliable.
|
37 | avrdude: safemode: To protect your AVR the programming will be aborted
|
38 |
|
39 | avrdude done. Thank you.
|
40 | stefan@exa:~/git/tiny-pong […] $ avrdude -p attiny2313 -c stk500v2 -P /dev/diamex
|
41 |
|
42 | avrdude: AVR device initialized and ready to accept instructions
|
43 |
|
44 | Reading | ################################################## | 100% 0.02s
|
45 |
|
46 | avrdude: Device signature = 0x1e910a
|
47 | avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
|
48 | avrdude: safemode: To protect your AVR the programming will be aborted
|
49 |
|
50 | avrdude done. Thank you.
|
51 | stefan@exa:~/git/tiny-pong […] $ avrdude -p attiny2313 -c stk500v2 -P /dev/diamex
|
52 |
|
53 | avrdude: AVR device initialized and ready to accept instructions
|
54 |
|
55 | Reading | ################################################## | 100% 1.49s
|
56 |
|
57 | avrdude: Device signature = 0x1e01ff
|
58 | avrdude: Expected signature for ATtiny2313 is 1E 91 0A
|
59 | Double check chip, or use -F to override this check.
|
60 |
|
61 | avrdude done. Thank you.
|
Wie man sieht, ist das ganze nicht wirklich deterministisch. Und
natürlich habe ich schon verschiedene Exemplare des 2313 durchprobiert,
das ganze zieht sich systematisch durch, eine erfolgreiche
Programmierung ist da eher Glückssache. Ab und zu gibt e dann noch den
Fall, dass das initiale Auslesen des Chips keine 0.2s (wie oben) dauert,
sondern eher 20 Sekunden - und dann meist trotzdem wegen irgendwas
abgebrochen wird.
Hat jemand eine Idee, woran das liegen könnte? Der Programmer versorgt
den Sockel mit 5V, die Spannung liegt laut Multimeter und testweise
angebrachter LED auch an den Beinchen an.
Thread beobachten
Seitenaufteilung abschalten