Hallo, habe einen komischen Fehler der mir die Haare ausfallen läßt :( Auf einem bisher funktionierenden Board mit einem nahezu nagelneuen AtMega644 wollte ich eine neue Version meiner Testsoftware aufspielen. (Der Quellcode wurde an nur unwesentlichen Stellen umgebaut) Denke mir, prima, compilieren fehlerfrei, mal hochladen. Wie immer ISP Stecker drauf und Strom und das ganze dann mit PonyProg hochladen. (Fusebits orginal Werkszustand) Dann schreibt er und verifiziert, dann "Writing Failed". Na super denke ich mir, aber was solls, ist ja nicht das erste mal, gleich nochmal beschreiben. Dann die Fehlermeldung "Device missing or unknown -24". Na toll... Also das 2. Board genommen was ebenfalls funktionierte, mit einem ebenfalls fast nagelneuen AtMega644 drauf und die Software dort aufgespielt. Er zählt brav hoch beim schreiben, verifiziert wieder und BING "Writing Failed". Jeder weitere Versuch schreiben oder leen zu können scheiterte mit dem gleichen Fehler "Device missing or unknown -24". Hab schon Reset, SCK und MISO oder MOSI geprüft. Bis auf MISO oder MOSI (weis nicht gerade welcher es davon war) kann ich mit LEDs eine Aktivität prüfen. Langsam bin ich ratlos :( Man kann mit einem fehlerfrei compilierten Code doch kein µC schrotten?!?
Sicher, dass Du nur das Flash programmiert hast, und nicht vielleicht auch die Fuses?
Doch kann man... wenn das Target nicht eigenbestromt ist und sich den Saft über das ISP zieht, dann kann es beim "hot-plug" dazu kommen, dass der Strom für den uC über dessen Clamp Dioden am POort fliesst, meist das letzte Mal. Habe 3 Stück in Serie zerschossen bis ich auf den Trichter kam.
Die Fuses muss ich bei PonyProg ja in einem seperatien Fenster schreiben lassen... Also glaube ich kaum. Und warum sollte dann beim 1. Schreiben immer das "Writing Failed" kommen?
Christian J. wrote: > Doch kann man... wenn das Target nicht eigenbestromt ist und sich den > Saft über das ISP zieht, dann kann es beim "hot-plug" dazu kommen, dass > der Strom für den uC über dessen Clamp Dioden am POort fliesst, meist > das letzte Mal. Habe 3 Stück in Serie zerschossen bis ich auf den > Trichter kam. Also das Board hatte Strom... Und hab auch nochmal gemessen... Also 5 Volt lagen auch definitiv von selbst an und nicht durch den ISP. Kann man denn ein µC irgendwie retten/resetten/löschen/etc? Hab da vor 2 Wochen mal was in der Art gelesen...
>habe einen komischen Fehler der mir die Haare ausfallen läßt :( Das liegt an der äußerst ungunstigen Kombination "Anfänger <-> Gurkenprogrammer <-> PonyProg". Kauf Dir einen anständigen Programmer, der vom AVR-Studio unterstützt wird und lies Dir die Anleitungen im AVR-Studio-Tools Guide durch und dann klappt das auch
Markus B. wrote: > orginal Werkszustand) Dann schreibt er und verifiziert, dann "Writing > Failed". Na super denke ich mir, aber was solls, ist ja nicht das erste > mal, gleich nochmal beschreiben. Dann die Fehlermeldung "Device missing > or unknown -24". Na toll... Wenns nicht das erste mal ist, vielleicht mal über nen Wechsel der Programmier-HW/SW nachdenken. Ich benutze das STK500 mit AVRStudio und hatte noch nie sowas. Programmieren klappt zu 100%. Zum Entwickeln nehme ich dann den Bootloader, da gibts dann manchmal nen CRC-Error, wenn die Baudrate zu hoch ist. Ich reduziere dann meistens auf 38400Baud. Peter
Gast
#787661
@Markus B. Ich habe festgestellt, daß es mit Ponyprog über sie serielle Schnittstelle Ärger gibt (wie von Dir beschrieben), wenn der Takt des Zielmikrokontrollers 4Mhz übersteigt. Dort waren dann Fuses gesetzt, die ich nie angesprochen hatte. Ich mußte den MC mittles HV-Programmer "wiederbeleben". Bei einem Programmer für die parallele Schnittstelle tritt der Effekt nicht auf. Wie Roy Black schon sang: Du bist nicht allein..... MfG Paul
Paul Baumann wrote: > "wiederbeleben". Bei einem Programmer für die parallele Schnittstelle > tritt der Effekt nicht auf. Ich habe einen Parallelportprogrammierer mit so einem Oktalwandler drin...
Gast
#787682
Hm, ich habe einen mit 74HCT244 drin. Seit ich den habe, habe ich den HV-Programmer nicht mehr gebraucht. :-) Mit der version 2.07a von Ponyprog habe ich damit auch ATmega644 für einen Webserver "beladen". MfG Paul
Hallo, ich habe immer PonyProg mit einem STK200-Dongle (mit dem 74HC244) benutzt, unter W98 und W2000. Irgendein Windows-Update von W2000 muß was verändert haben, plötzlich brach Pony irgendwo mittendrin ab, mal nach 10%, mal nach 30%, völlig zufällig. Am W98-Notebook läuft noch alles, am W2000-Rechner hängt jetzt eben der Dragn, der war sowieso da. ;) Ich schätze 90% der Effekte mit Pony sind zu neue Rechnerhardware (Pegel der Schnittstellen) und zu neues Windows (irgendein Programmteil fummelt bereits beim Booten an den Schnittstellen rum oder ein Dienst ändert ungefragt was im Hintergrund). Bei XP und Notebooks potenziert sich das dann irgendwie noch... Gruß aus Berlin Michael
Ja genau den Chip hab ich im Programmierer auch drin! Aber Hardware habe ich nicht geändert....... Weder am PC noch am EvalBoard
Hallo, auch ich habe da so ein Problem... Einen Mega128 mitttels Ponyprog und 74HCT244-Programmer begattet, welcher nun nur noch einen Fehler "Device missing or unknown -24" von sich gibt. Wie kann ich das Teil nun wiederbeleben? Mittels einem HV-Programmers? Wenn ja, was ist da zu empfehlen? Kann das der USBprog von Benedikt Sauter? Danke für eure Antworten. Viele Grüße, Jürgen
Ich werde nachher mein Glück beim Elektronikladen des Vertrauens um die Ecke bei mir mein Glück versuchen. Die haben einen GAL-Progger und wollen versuchen das Teil neu zu bespielen. Ich werde mir ab mal einen USB-fähigen Progger kaufen müssen. LPT hat man ja eh fast nimmer.
Gast
#787909
Ich habe diesen hier gebaut.: http://elm-chan.org/works/avrx/avrxp.png Der ist bis jetzt allen Widrigkeiten gewachsen gewesen. MfG Paul
Angehängte Dateien:
-
programmer.png
(180 KB)
Gast
#787911
@Paul Baumann, der Link ist tot, hast du nen aktuelleren? :)
Gast
#787936
Nein, hab ich nicht. Bei mir geht der Link aber?! Kopf kratz Paul
denke das Problem liegt an der ponyprog.ini hier gibts einige Einstellungen die das Programmieren betreffen. Meiner Ansicht läuft das Programmieren zu bald los und Ponyprog liefert noch keine Einstellungen wodurch alle Fuses auf 0 gesetzt werden. PowerUpDelay=200 LanguageCode=Default SoundEnabled=YES ClearBufferBeforeLoad=YES MDAWriteDelay=0 SPIResetPulse=100 SPIDelayAfterReset=50 BigSPIPageWrite=16 ATMegaPageWriteDelay=50 AVRByteWriteDelay=20 AVREraseDelay=50 I2CBusSpeed=NORMAL SPIBusSpeed=NORMAL MicroWireBusSpeed=NORMAL PICBusSpeed=NORMAL SDEBusSpeed=NORMAL LogEnabled=NO VerifyAfterWrite=YES ClearBufferBeforeRead=NO AutoDetectPorts=YES I2CBaseAddress=0xA0 I2CBusPageWrite=16 DeviceType=ATmega8
Also sollte man die Werte auf das hier z.B. stellen: PowerUpDelay=200 ---- > 40 MDAWriteDelay=0 ---- > 10 SPIResetPulse=100 ---- > 200 SPIDelayAfterReset=50 ---- > 100 ?? (Mal als ne grobe Schätzung)
Gast
#787979
> Kauf Dir einen anständigen Programmer, der vom AVR-Studio unterstützt wird
Da mir PonyProg auch schon einen ATMega644 gekillt hat (und ich bin bei
der Bedienung kein Anfänger), wird das Programm nur noch einmal
eingesetzt: Bootloader drauf und danach nur noch damit flashen.
>wird das Programm nur noch einmal eingesetzt: Bootloader drauf
Einmal Fuses falsch setzen reicht ja auch! Gurkenprogrammer sind MURKS!
Welchen kannst Du da empfehlen der auch USB-fähig ist?
Jürgen A. wrote: > Hallo, > (...) > Wie kann ich das Teil nun wiederbeleben? > Mittels einem HV-Programmers? Wenn ja, was ist da zu empfehlen? > Kann das der USBprog von Benedikt Sauter? > > Danke für eure Antworten. > > Viele Grüße, > Jürgen Ja, diese Frage hatte ich oben schon mal gestellt... Welcher ist da zu empfehlen, insbesondere auch um mittels HV-programming ein Teil wiederzubeleben? Danke und Grüße, Jürgen
Naja, der Punkt ist ja gerade dass man HV programming eigentlich nicht mehr braucht wenn man einen anständigen Programmer einsetzt, da falsch gesetzte fuses nicht mehr vorkommen wenn man ein bisschen vorsichtig ist (Mir jedenfalls noch nie passiert). Und wenns dann doch mal passiert, ersetz ich den AVR halt. Daher würd ich USBprog empfehlen. Läuft wirklich einwandfrei und ist flexibel einsetzbar. Ausserdem ist er sehr platzsparend. Sonst halt das STK500, mit HV-Programmierung aber ohne USB. Vom Dragon der auf den ersten Blick wie die eierlegende Wollmilchsau aussieht würde ich echt abraten. Ist eher ein Spielzeug oder eine Techdemo und gibt gerne den Geist auf, was nach Aussage von einem ATMEL Mitarbeiter auch "normal" ist, da es sich halt um einen Low-Cost-Programmer handelt. Grüsse, Michael
Dragon mit Schutzbeschaltung (Serienwiderstände in externe Leitungen) und im Gehäuse eingebaut ist eine feine Sache.
Gast
#788054
Ich kann auch nur das STK500 empfehlen. Ich wollte auch nie soviel Geld ausgeben, aber es hat sich gelohnt. Und soweit ich weiß läuft das STK auch problemlos mit einem USB-Seriell-Wandler-Kabel . Davor hatte ich einen ISP-Programmer mit nem tiny2313, der war auch OK und lief auch mit einem USB-Seriell-Wandler-Kabel
Gast
#788083
@Markus: Ponyprog ist ja nun Open Source vielleicht tut sich in der Hinsicht noch was, also das der Programmieralgo verbessert wird, vielelicht liegts ja wirklich an der Programmiergeschwindigkeit. Das hier habe ich in der Datei noch gefunden was sicherlich einen Einfluss drauf hat. ATMegaPageWriteDelay=50 AVRByteWriteDelay=20 AVREraseDelay=50
Oha... Wenn ich also meinen Mega128 retten möchte, würde ich ein STK500 benötigen und zusätzlich ein STK501, um den Mega128 einzusetzen. Da mein Mega128 aber auf der Platine verlötet ist, geht das schon mal prinzipiell nicht... Da ich das Teil wohl eh auslöten muß, ist es wohl einfacher, gleich einen neuen zu kaufen, da der jetzige aufgrund meiner 'Laborausstattung' das Auslöten wohl eher nicht überlebt ;-( Ansonsten würde ich einen seriellen HV-Programmer benötigen, oder habe ich da etwas übersehen? Danke und Grüße, Jürgen
der Dragon kann auch parallel HV proggen für den ATTiny26 gehts aber z.B. nicht bzw. steht im Datenbaltt drin das es nicht zuverlässig läuft ich habe es mal testweise probiert und ihn verfused mit dem STK500 habe ich ihn dann wieder gerettet. Aber bei deiner Gehäuseform hast du wie gesagt das Problem der Kontaktierung.
Im Datasheet des Mega128 steht leider nichts über serielles HV programmieren... Muß ich das Teil wohl ersetzen ;-( Grüße, Jürgen
Du könntest den ATMEGA128 auf der Platine lassen und die nötigen Pins mit Fädeldraht kontaktieren, welcher wiederum mit Litzen oder dickeren Drähten an das STK500 angeschlossen wird. Eventuell mußt Du den Reset-Pin an der Platine abklemmen, da dieser 12V sieht beim HV-Programmieren. Alle anderen Pins sehen lediglich 5V.
Also nachdem ich ein langes Gespräch mit meinem Elektronikhändler hatte und er immerhin 1 von den 2 AtMega644 wieder löschen konnte scheint es wohl an den Parameter zu liegen... Hat jemand einen Vorschlag aus Erfahrung zur INI?
Markus B. wrote:
> ... Hat jemand einen Vorschlag...
Ja: AVRISP (oder AVRdragon) von Atmel kaufen!
Mit 2 "zerforschten" 644-ern hast Du schon ca. 1/4 der Kosten des
Programmers versenkt (Ärger und Lauferei nicht mal mitgerechnet). Und
o.g. Geräte haben den Vorteil, dass sie von zukünftigen AVRstudio
Versionen jeweils - soweit möglich - für die neuesten Controller
fitgemacht werden.
Programmer sind Werkzeuge und wer beim Werkzeug spart zahlt immer drauf!
Gast
#788751
Könntest deinen Arzt fragen ob er dir die Dinger unters Röngtengerät legt. Irgendwie wäre so eine private Röngtenanlage schon noch praktisch, bräuchte kenerlei EEPROM oder HV Programmer mehr, müsste den Chip nur noch röngten
Gast
#788795
>Irgendwie wäre so eine private Röngtenanlage schon noch praktisch, >bräuchte kenerlei EEPROM oder HV Programmer mehr, müsste den Chip nur >noch röngten Danach weißt du maximal ob der Controller einen Bit- oder Bytebruch hat. MfG spess
Stefan Wimmer wrote: > Mit 2 "zerforschten" 644-ern hast Du schon ca. 1/4 der Kosten des > Programmers versenkt (Ärger und Lauferei nicht mal mitgerechnet). Und > o.g. Geräte haben den Vorteil, dass sie von zukünftigen AVRstudio > Versionen jeweils - soweit möglich - für die neuesten Controller > fitgemacht werden. > > Programmer sind Werkzeuge und wer beim Werkzeug spart zahlt immer drauf! Also ich habe ja einen aktiven Parallelportprogrammer... Nach Aussage von meinem Elektronikhändler der schon über 10 Jahre sich mit sowas beschäftigt sei der absolut nicht im Nachteil zum AVRISP mkII außer das meiner einen Parallelport braucht statt USB. Längerfristig werde ich aber eh zu dem einen Open-Source-USB-Progger umschwenken.
[ ] Dein Händler hat Ahnung [ ] Du hast's begriffen
Gast
#788984
Möchte mal wissen, wieviele MCs insgesamt auf das Konto Billig-Programmer + PonyProg gehen. Manche Sachen sind einfach nicht auszurotten...
Gast
#788995
also ich hab pony schon lane in die ecke gerfeuert :-/
das würde mich auch mal interesserien wieviele AVRs Ponyprog schon gehimmelt hat. <Verschwörungsmodus_an>Man könnte fast meinen das das Programm von einem µC-Hersteller entwickelt wurde um im ersten Moment den Absatz von µCs zu steigern und im 2ten Moment den Absatz der eigenen Programmer, die ja bekanntlich funktionieren ;-) <Verschwörungsmodus_aus>
Unsinn. PonyProg taugt für diejenigen User, die genau damit umzugehen wissen. Außerdem kann PonyProg mehr, als nur Controller zu programmieren. Laßt mal die Kirche im Dorf!
sicherlich kann Ponyprog mehr als nur AVRs abschießen aber darin ist es ungeschlagen, denke das auch Nutzer davon berichten können die imstande sind Programmer ohne Fehler aufbauen und trotzdem Probleme mit Ponyprog hatten.
Gast
#789096
> Unsinn. PonyProg taugt für diejenigen User, die genau damit umzugehen wissen Da habe ich aber andere Erfahrungen gemacht. Ponyprog schafftt es auch, einen ATMega644 stillzulegen, ohne dass man selber Fehler macht (wobei mir das zuletzt mit der gepatchten Version passiert ist, also der früheren Version, die den 644 unterstützen sollte, aber nicht unterstützt hat, und dann als gepatchte Version in Umlauf gebracht wurde - vieleicht eine etwas zweifehlhafte Version): einige hundert mal ging es gut, dann ist der AVR nach einem Programmiervorgang plötzich tot. Das ist mir innerhalb von 6 Moanten zweimal mit dem ATMega644 passiert.
Das Problem ist nicht unbedingt PonyProg, sondern falsch eingestellte Werte in der ini-Datei, ein instabiles Windows-System oder eine zu schlappe Schnittstelle. Parallel laufende Software oder Hintergundtreiber tun ihr Übriges, um das Timing am LPT oder COM durcheinanderzubringen. >sicherlich kann Ponyprog mehr als nur AVRs abschießen aber darin ist es >ungeschlagen, Nein, es kann serielle EEPROMS, RTCs, I2C-Devices und viele andere Bausteine lesen, beschreiben und einstellen. Als freies Tool ist es somit eine gute Hilfe für den ambitionierten Bastler und Hobbyelektroniker.
das mit den anderen Bauteilen ist klar, aber der AVRISP braucht er ganricht mit vom Werk falsch eingestellten ini-Werten zu kämpfen, hat keine Probleme mit dem instabiles Windows-System und mit der Schnittstelle hat es auch keine Probleme. Aber da es ja nun Open Source ist könnte es ja passieren das ein paar fähige Leute diese Fehler noch ausmerzen. Aber um AVRs zu programmieren scheidet es für mich aus weil das Risiko einfach zu hoch ist.
Gast
#789174
@Paul Baumann, wenn ich den Link anklicke lande ich auf einer Registrar-Seite für INet-Domains... :D Wenn ich mich von der Hautpseite aus durchklicke gehts komischerweise. Wird wohl an meinem Browser liegen. :D
Also so wie es aussieht werd ich mir das Teil hier besorgen: http://www.embedded-projects.net/index.php?page_id=135 Wie schaut es denn, bis das Teil bei mir verfügbar ist, aus mit den Werten der INI Datei? Belassen? Delay höher?
dieses Teil funktioniert nicht mit Ponyprog ist auch nicht dafür gedacht aber als AVR ISP 2 Clone kannst du damit direkt aus dem AVRStudio raus arbeitet und das sollte einwandfrei funktionieren
Thomas O. wrote: > aber als AVR ISP 2 Clone kannst du damit direkt aus dem AVRStudio raus > arbeitet und das sollte einwandfrei funktionieren Das ist ja das was ich damit bezwecken will :)
Gast
#789831
möchte mal anmerken, dass man sowohl mit dem stk500 als auch mit dem isp mkII usb mega16s wunderbar abschießen kann. und das ganz ohne in den fuses rum zu fusen. woran es liegt weiß ich nicht, könnte mir aber ein nicht einwandfreies xp als ursache vorstellen, vielleicht auch die sache von oben mit der spannungsversorgung des boards.
könnte es sein das noch dein Demo AVR im STK500 steckt? Notfalls die Baudrate am Rechner niedriger einstellen.
Also jetzt wird es lustig... Habe mal aus Spaß versucht meinen geschossenen AtMega644 per AVRDude zu beschreiben. Als Programmierer hab ich den STK200 gewählt und bin dann auf WRITE... Siehe da der µC wurde beschrieben und geht nun wieder. Ich werde jetzt nur noch AVRDude benutzen und lass PonyProg in der Ecke liegen :)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.