avrdude probleem

Ik heb de miso en mosi en clk aangesloten op de juiste pinnen en de reset van de atmel aan 5V gehangen.

Hoezo, aan 5V?! Die moet aan de RESET-lijn van je programmer. De programmer moet die lijn laag kunnen maken, en vervolgens wat magische woorden de MOSI-pin insturen, alvorens er geprogrammeerd kan worden.

Dat heb ik ook wel geprobeerd maar misschien net in een verkeerde combinatie. Ik zal dat verder testen. Dit is nieuw gebied voor mij

Ik las in een tutorial dat deze atmel de reset aan plus moet terwijl de meeste aan gnd moeten. Dus ik dacht dat de reset van de programmer dan net verkeerd om zou werken. Ik heb nog niet gemeten wat die reset doet maar ik dacht daarom dat hij laag zou zijn en af en toe hoog wordt. In het datasheet staat ook dat hij bij in situ programmeren door de reset in programmeer stand moet. Ik dacht daarom permanent hoog.

De programmer is wel goed denk ik. Hij stuurt in ieder geval op de "zend" lijn een signaal naar de uProcessor en de rode led licht dan even op. Maar daar blijft het bij.

Je mag de RESET-pin v/d AVR wel met een 10k-weerstand aan Vcc knopen, en daarbij nog een C van 100nF tussen RESET en GND. Dat zorgt voor een stabiele reset bij het inschakelen van de voedingsspanning.
Zelf plaats ik een 100Ω-weerstand tussen de reset v/d programmer en de AVR-reset. Mogelijk overbodig, maar het kan nooit kwaad.

Het programmeren zelf is niet moeilijk. Kijk eens bij "Memory Programming -> Serial Downloading" in de datasheet.

Bedankt, ga ik morgen proberen.
Ik gebruik linux en avrdude. Ik probeer te lezen dmv
sudo avrdude -p 8253 -c usbasp -U flash: r :naam:a
sudo avrdude -p 8253 -c usbasp -U flash:w:i:naam

Ik dacht dat het kwam omdat er geen signature bij de config file staat maar de signature in de datasheet wordt niet herkend. Ik ga eerst die rest maar eens op de juiste manier doen.

Wanhoopskreten als

avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1

hebben niets te maken met je config-file, maar wel met een mislukte handshake die het begin vormt van een programmeer-cyclus. Als de handshake (zie datasheet voor meer details) mislukt, kan je de rest ook vergeten...

Fred101 + AVR = Help

ineens snap ik het. er zitten geen buizen in... sorry fred Pros kan het beter uitleggen als ik. maar kon deze reactie neit nalaten

Moet ik de miso lijn van de controller ook aan miso van de Atmel aansluiten. In het datasheet doen ze dat wel maar ik ga er van uit dat de programmer connector pennen genoemd zijn naar de doel, dus dat miso betekent dat hij aan miso moet. Klopt dat ?

Henk, dan zit het probleem waarschijnlijk in iets anders. Ik voed hem gewoon met 6,3V, en op poort B staat 300V is dat niet goede dan ?

[Bericht gewijzigd door fred101 op zaterdag 26 februari 2011 21:47:49 (22%)

Moet ik de miso lijn van de controller ook aan miso van de Atmel aansluiten. In het datasheet doen ze dat wel maar ik ga er van uit dat de programmer connector pennen genoemd zijn naar de doel, dus dat miso betekent dat hij aan miso moet. Klopt dat ?

MOSI (Master Out, Slave IN) van de programmer moet in theorie aan MISO (Master In, Slave Out) van de AVR. "in theorie" omdat ik geen ervaring met de programmer heb...

In de config file staat dat de device signature 1E 73 en 2 byte is is, en hij beweert in zijn foutbericht dat hij FFFFFF zou verwachten en 0000 leest.

Lijkt erop dat hij zijn eigen config file niet correct interpreteert.

Verder zie ik aan je foutberichten, dat hij eerst niet kan initialiseren en daarna wel. Waarschijnlijk is de delay van wachten na een reset dan te kort, omdat de RC tijd van de powerup reset groter is.

[Bericht gewijzigd door Henry S. op woensdag 10 augustus 2011 19:58:14 (97%)

pros:

MOSI moet aan MOSI
immers de linker is master en de rechter slave. wat bij de Master Out is is bij de slave de rechter dus dan Slave In.

[Bericht gewijzigd door Henry S. op woensdag 10 augustus 2011 19:58:28 (95%)

Ik ben nu helemaal gaar van het uren in die datasheet spitten en nu echt compleet de weg kwijt.

De signature is niet opgegeven, hij leest 0x0000 maar dat mag ik niet ingeven. 0x00 0900 0000 wel maar dat is 000000 en oxox met wat dan ook erachter is een syntaxfout, "x" Maar met -F zou hij dat moeten negeren.

In -t mode gaat het rode lampje aan en een dump flash geeft een rits FF en. Dus de programmer werkt.

Mosi moet aan mosi, staat in de DS en als ik met de scoop meet is dat een uitgang van de programmer en dus de ingang van de AT.

De reset van de programmer mag niet gebruikt worden. De reset moet gedurende de hele programmering hoog blijven en de reset trekt hem juist even laag. De klok van de AT is 12MHz dus de programmer moet op 1/16e werken. Alleen weet ik nog niet hoe ik dat instel of wat dat nu is. Ik denk dat ik jp3 dan moet zetten en/of de -i functie in avrdude.

Het probleem zit hem denk ik in de config file. Ik ben bang dat die voor parallel programeren is gemaakt ipv serieel. Verder weet ik niet of ik page of byte mode moet nemen. In ieder geval lijken de read/write ext commando' s niet juist maar dat kan ook aan mijn onkunde liggen. Het gloeit niet, het heeft teveel pootjes en het werkt op veel te lage spanning, dat is vragen om problemen

Op 26 februari 2011 22:08:50 schreef pros:
[...]
MOSI (Master Out, Slave IN) van de programmer moet in theorie aan MISO (Master In, Slave Out) van de AVR. "in theorie" omdat ik geen ervaring met de programmer heb...

Met rx- en tx-pinnen klopt die redenering, maar hier gaat het om de naam van een lijn. Er is 1 master en 1 slave, dus master out slave in moet niet aan master in slave out, want dat spreekt elkaar tegen, twee uitgangen op elkaar aansluiten is vragen om problemen mijns inziens.

Op 26 februari 2011 21:09:26 schreef High met Henk:
Fred101 + AVR = Help

ineens snap ik het. er zitten geen buizen in...

En nog verwarrender is dat de AT89S8253 geen AVR is

Ik ken die programmer en die software niet.

datasheet blz 36 onderaan staat de device signature 1E 73

configfile die je in de startposting opgaf staat hij vrij onderaan bij "signature"

En je opgegeven foutberichten zeggen dat die niet klopt dat hij 0000 leest en dat het FFFFFF moet zijn. Hij weet het dus beter dan zijn eigen config file die hem van die kennis 1E 73 voorziet.

Het is logisch dat hij alvorens instructies te gaan verwerken eerst kijkt naar de signature om die te checken met de in config file opgegeven waarde die de structuur van de voor programmeren vereiste SPI bytepatronen bevat.

De avrdude zal die eerst verifieren met de opgave in zijn config file om vast te kunnen stellen dat het device past bij de config file, zodat hij niet het verkeerde type gaat programmeren. Vermoed ik.

Mogelijk dat de avrdude zelf de reset ook goed zet omdat hij het devicetype weet. Dan zou - mits de juiste configfile is aangesloten - de resetlijn normaal laag zijn en tijdens programmeren hoog. Bij andere devices andersom.

In ontwerpdetails diepgaaand spitten heeft alleen zin bij ontwikkeling, niet bij reparatie of de boel aan de gang krijgen.

Suggesties:

*Probeer de config file weg te halen en kijk of je scherm dan afwezigheid meldt. Mogelijk staat de config niet op de plek waar naar haar gezocht wordt en wordt er een default genomen die daar wel staat.

*Signature lezen van het device (1e 73)
staat zowel bij parallel programmeren als serieel (laatste instructie in de lijst in de datasheet) en dan worden niet alleen miso mosi en clk bediend bij par prog., je programmerinterface connector naar je te programmeren device kan dus uitsluitsel.
Misschien kun je wel kiezen, serie of parallel, geen idee.

*Ik vermoed dat i voor input o voor output en x voor don't care staat in de config file, dat is makkelijk na te lopen omdat de seriele instructies voor programmeren staan in de datasheet op blz 38 en blz 39.

Daar staan meen ik andere commando's voor serie- en parallel programmeren, dus gewoon die pagina's goed lezen en de commando's vergelijken met de opgave in je config file. Die staan daar ook in omdat ze mogelijk per device type verschillen.

[Bericht gewijzigd door Henry S. op woensdag 10 augustus 2011 19:58:48 (99%)

En nog verwarrender is dat de AT89S8253 geen AVR is

Dat kan je wel zeggen. Blijkbaar moet RST hoog zijn bij het programmeren, en niet laag zoals bij een AVR. Op dit punt was fred juist en ondergetekende fout.

Met rx- en tx-pinnen klopt die redenering, maar hier gaat het om de naam van een lijn. Er is 1 master en 1 slave

Nog een stommiteit van mijnentwege. MOSI moet idd. aan MOSI en MISO aan MISO.
't Was blijkbaar mijn helderste moment niet...

De klok van de AT is 12MHz dus de programmer moet op 1/16e werken. Alleen weet ik nog niet hoe ik dat instel of wat dat nu is. Ik denk dat ik jp3 dan moet zetten en/of de -i functie in avrdude.

Dat kan idd. met de -i optie. "-i 32" bv.

Verder weet ik niet of ik page of byte mode moet nemen.

Voor een normale AVR is page-mode gebruikelijk. Maar in de link lees ik:

Only byte mode Read/Writes operations supported.

Aanvulling:

Het probleem zit hem denk ik in de config file. Ik ben bang dat die voor parallel programeren is gemaakt ipv serieel.

Uit de "programmer" config (zie link) blijkt toch duidelijk dat het om serieel programmeren gaat. Het is wat verwarrend, omdat een programmer, die je via de parport stuurt, vaak een paralelle programmer wordt genoemd.

[Bericht gewijzigd door pros op zondag 27 februari 2011 12:43:49 (16%)

Weet je zeker dat 'ie nog wel programmable is? Als het SPI_EN bit in de duses omgezet is gaat dit sowieso niet lukken.

De regel "avrdude: Device signature = 0x0000" in de output geeft aan dat de proc helemaal niet gelezen wordt. Je krijgt dezelfde meldingen wanneer de lijnen verkeerd aangesloten zijn of wanneer de fuses gezet zijn voor een externe klok die niet aanwezig of kapot is.

De config file wordt wel gelezen, anders had avrdude part 8253 niet herkend. Wat mij echter opvalt bij entries in avrdude.conf is een regel "signature = 0x.. 0x.. 0x.." vrij aan het begin van iedere part sectie. Die regel mist in jou config.

Ik begrijp nu hoe het werkt. De programmer is master, deze geeft op zijn sck de klok en die moet maximaal 750KHz zijn. Ik heb niets ingesteld dus dat zal te snel staan. In een Duitse link las ik dat het commando -B 10 voor 100KHz moet worden meegegeven.
Dan moet hij de reset hoog zetten en na een bepaalde tijd een mosi opdracht geven waarna de atmel op miso antwoord. Het geheel wordt gesynct door de klok van de master. Maar dan moet die atmel als slave staan. Zover ik begrijp gebeurd dat vanzalf door die reset.

De reset kan permanent aan plus dus ik ga geen moeite doen de programmer daar op de een of andere manier voor aan te passen. De auteur van de software doet dat ook altijd zo (maar dan met zelfgeschreven software en zelfbedachte programmer)

De signature vond ik wel in een ander topic: 0x1e 0x73 0x1e want hij schijnt toch niet alle bytes te lezen en op deze manier krijgt hij toch de juiste. Bij memory signature moet dat adres blijkbaar weg en moet size op 3.

Alleen staat bij page_mode=no en de datasheet heeft het wel over pagemode en in de config staat readback_p1 en 2 wel gedefinieerd.

De config wordt gelezen want anders zou hij bij avrdude -p? niet de 8253 in de lijst aangeven en ook niet reageren op fouten die ik maakte bij testen.

Kortom ik heb weer wat te testen.

Danny, hij zou programmable moeten zijn volgens de programmeur. Ik weet alleen niet hoe ik er achter kom of de SPI_EN fuse is omgezet.
Dat van dat niet lezen klopt wel denk ik want ook met een draad los krijg ik die melding maar zonder -B 10 is de externe klok wel veel te snel waarschijnlijk dus dat zou het kunnen zijn.

heb je al een GUI voor avrdude getest?

mvg,
noone.

Ja, gnome-avrdude maar die weigert de config file te zien en ik kan nergens een eigen configfile vinden. Maar ik heb geen probleem met terminal commando' s

ik heb zelf wel eens AVR8-Burn-O-Mat gebruikt.

mvg,
noone.

Er MOET communicatie tussen de PC en de AVR plaats gaan vinden: "Hier is je nieuwe programma".

D'r zijn een aantal "dingen" die daar tussen zitten. De eerste is de programmer software. De tweede is de "programmer".

Als je een eenvoudige programmer maakt is de eerste substap van communicatie tussen de programmer software en de AVR dat de software probeert te zeggen: "hoi Hoe heet je?". Je zult ze de kost moeten geven dat ze een verkeerde unit zitten te programmeren!

In ieder geval, heeft iedere avr chip dan een antwoord op "hoi hoe heet je". Als je daar 0xffffff of 0x000000 terugkrijgt, dan heeft er geen communicatie plaatsgevonden: De programmer heeft tegen de open lucht lopen babbelen. Steeds als er een volgend bitje van "hoe heet je" terug moest komen is steeds weer een "0" teruggekomen. Of steeds een "1". Een normale chip geeft een aantal nullen en een aantal 1nen terug, maar niet steeds hetzelfde.

AVR chips resetten prima zonder condensatortje aan de resetlijn. Ik laat dat dus allemaal los hangen. Alleen een 10k naar de voeding. Daarna aansluiten zoals op de programmer staat aangegeven: VCC aan VCC, GND aan GND, MOSI aan MOSI etc etc.

Als ik hem in -t mode zet en ik doe een fash dump dan is dat FF aangesloten en 00 als ik ik miso los haal. Er vind dus idd geen communicatie plaats.

Ik hen nu zo'n beetje alles geprobeerd wat ik op het net en in de datasheet kon vinden. Maar hij vertikt het gewoon om contact te maken. Op mosi komt data aan, de klok wordt laag en ik heb vanalles tussen 80 en 300KHz geprobeert, rode led aan maar dan stopt het met de signature error.

Dus ik denk dat mijn programmer wel wil maar blijkbaar chinees praat ipv Atmels of misschien een software/hardware fout heeft. De Atmel doet het nog steeds gewoon met de oude software, hij is dus niet defect.
Ik vond een topic waar men zegt dat het wel kan met avrdude maar niet met de usbasp. Ik ben bang dat ze gelijk hadden.

Ik weet het dus echt niet meer en om alleen voor deze ene keer een andere programmer te maken zie ik ook niet zitten, uiteindelijk werkt mijn andere decoder ( met zelfde type Atmel) prima, deze nieuwe software is verbeterd met side toon en extra filtering en was bedoeld om te vergelijken met de andere en dan met de beste software een tweede versie te bouwen.

In ieder geval heb ik weer een hoop geleerd.

Er is gewoon een hardware probleem met je programmer <-> avr
Of met programmer <-> PC.

Of je hebt je programmer-software ingesteld om programmer type X te gebruiken terwijl jij type Y hebt gebouwd. Mijn galzen bol is stuk en ik kan hiervandaan niet zien wat je verkeerd hebt gedaan.

Verhalen op het internet van "avrdude wertk gewoon niet met programmer XXXX" komen bij figuren vandaan die het na een dagje proberen opgeven. Zoals jij.

Als programmer XXXX bij de mogelijkheden van avrdude staat dan heeft iemand het gemaakt en niet opgegeven voordat het werkte. Anders komt het er niet in. Dus het HEEFT gewerkt....

REW, Goed lezen, het gaat niet om een AVR anders had je helemaal gelijk. Verder ben ik al wel wat langer dan een dagje hiermee bezig en dat ik zeg dat ik het niet meer weet, wil niet zeggen dat ik het opgegeven heb. Ik geef niet zo snel op.

Ik ben wat onduidelijk denk ik, AVRdude werkt wel met usbasp. Die programmer staat standaard in de config. Wat echter niet in de config staat is de AT89S8253. Dat is een heel andere beest als een AVR en die lijn wordt niet ondersteund. Die heb ik zelf toegevoegd. De mensen die het wel werkend kregen hebben a) een echte programmer en niet zo'n lowbudget bitbangertje als ik en b) de gene die wel de usbasp gebruikte hebben deze van andere firmware voorzien waarna het wel werkte. Vandaar dat ik bang ben dat het mij niet gaat lukken wat niet wil zeggen dat ik daarom nu stop zoeken en proberen.
zie bv hier: http://www.mikrocontroller.net/topic/140310
Onderin deze link staat nog iets wat misschien de oplossing is maar ik niet helemaal begrijp: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&am… Het lijkt alsof hij beschrijft wat hij in de firmware van de asp veranderd en niet iets in de config.

De programmer werkt, denk ik goed met avrdude samen. Ik had bv fuses en eeprom niet gedefineerd. Als ik in debug mode dan een dump vroeg daarvan zei avrdude dat deze niet geconfigureerd zijn voor dit device. Als ik die dan aan de config toevoeg, nav de info uit de datasheet, kan ik daarna wel die dump doen alleen is dat altijd FF.
In debug mode zie ik ook de klok op de ingestelde frequentie, er komt een commando aan op mosi maar geen reactie van miso. Dus op de LA lijkt de communicatie richting AT89S in orde.

Als ik een directe write opdracht in debug doe, dan zegt avrdude bij alles dat het opgegeven adres niet binnen het bereik ligt en toen ik zomaar een adres nam voor signature wat in het gewone flash viel vertelde hij dat hij daar niet kon schrijven omdat de inhoud 0xFF was. Ik denk dat daar het probleem zit. Dat de AT89S met meer of minder bytes werkt of bv in een andere volgorde. Alleen weet ik (nog) te weinig van uP's om dat te testen.

Vandaar mijn opmerking dat de Atmel een andere taal spreekt dan de programmer/avrdude combi.

Fred heb je dit nog ooit aan de praat gekregen ?
Ik probeer een AT89S8253 te programmeren onder Windows 7.

Mijn TL866 programmer leest ze prima, erasen gaat ook goed maar kan er alleen maar 00 in programmeren dus ik zoek een alternatief.