Stránka 1 z 1

ATMega165, odchazi pri programovani

Napsal: 08 úno 2013, 22:33
od hrabosh
Zdravím.

stavím takovou konstrukci s megou165A. Jde o elektroniku, co má nahradit původní, vyhořelý programátor v myčce Indesit.


Odpálil jsem už třetí Megu! Používám paralelní programátor s bufferama AlteraByteBlaster vlastní výroby (http://real.kiev.ua/old/avreal/en/adapters.html) a program AvReal (http://real.kiev.ua/avreal/). KAbel i program jsem před tím používal na 5 dalších projektů a nikdy nebyl problém.

Projevuje se to vždycky stejně. Nové AVRko nejdřív jede, potom se programování přestane dařit napoprvé (program se zapíše, ale selhává verifikace - tzn. zapíše se špatně, nebo software při programování napíše "synchronization failed", později občas ani nenačte signaturu toho AVRka). No a skončí to tím, že je to AVRko proste mrtvý.

Nechápu, co je (k*rva) špatně! Napájení 5V, země pospojovaný. Když na ty data mrknu oscilioskopem, tak je tam krásnej obdélník. Krásnej obdélník leze i do mrtvýho AVR, bohužel na MISO pinu už není nic.

Napadá někoho, co může být problém?

Po 2. mrtvým AVRku jsem na piny programovacího rozhraní připojil 470Ω odpory a stejně to nepomohlo.

Napsal: 08 úno 2013, 22:43
od Andrea
Nemusí být mrtvoly, stačí špatně nastavený zdroj hodin a to se dá léčit, probíralo se to tu už mnohokrát.

Napsal: 09 úno 2013, 09:58
od hrabosh
Zkoušel jsem připojit externí zdroj hodin (programátor to umí) a nepomohlo to. Navíc je mi divný, že by to šlo takhle postupně. Kdyby si přepsal nějakej FUSE, kterej určuje zdroj kmitočtu, tak by to proste najednou "přestalo fungovat", ne?

Napsal: 09 úno 2013, 11:25
od Panda38
SPI programování je hodně závislé na rychlosti programování (a rychlosti krystalu). Už jsem se setkal s tím, že nový čip šel programovat snáz, ale při opakování už byla nutná nižší rychlost, jinak byla komunikace nestabilní nebo už to nejelo vůbec (nejela už ani synchronizace). Takže řešení by mohlo být zvýšit rychlost hodin a/nebo snížit programovací rychlost.

Napsal: 10 úno 2013, 17:37
od hrabosh
Ani snížení SPI SCK frekvence nepomáhá. Zkoušel jsem to ted s 1kHz a nic...

Napsal: 10 úno 2013, 20:14
od fikes
Není v tomto ohledu nad Microchipy, tam se to nastaví v configu a vygeneruje se *.hex, přehrávám procesory při ladění programu stokrát a bez obav, střídám firmwary jak se mi zachce a takové problémy jako s Atmelama nenastávaj. Je to věc výrobce jaký způsob zvolí, myslím, že co se týká Atmelu, tak se to moc nepovedlo, sám s Atmelama bojuju a s obavami přehrávám firmware aby se něco s broukem nestalo, viz zablokování pojistkama, což u Microchipů nehrozí.

Napsal: 10 úno 2013, 20:25
od Andrea
No vidíš a já už 14 let vesele programuju AVRka a žádný problémy se zablokováním nemám. Takže asi taky bude záležet na elementu mezi židlí a klávesnicí.

Napsal: 10 úno 2013, 21:19
od fikes
Tak to by jsi mi mohla dát nějaké typy jak na Atmely, a proč se mi to třeba děje, já spíše dělám s PICema, ale s Atmelama jsem nic neprogramoval, spíše vypaluju do konstrukce kterou potřebuju odzkoušet. Díky. Jsem si už v diskuzích všiml a též navštívil tvé stránky :-)

Napsal: 11 úno 2013, 08:15
od AB1
Typ je jednoduchý:
Používat spolehlivý programátor a testovací desku,
neprogramovat na nepájivých polích a jiných provizorních bastlech.
Je nebezpečné když se během programování přeruší (třeba i krátce) napájení nebo některý programovací vodič.

V posledních patnácti letech jsem postupně používal tyto programátory (všechny doma dělané):

SiProg + Ponyprog 2000
Avr910-Prog (http://www.klaus-leidinger.de/mp/index.html) + AvrOspII
Bootloader AVR109 + AvrOspII nebo Avrdude

Nikdy jsem neměl žádný problém, o samovolném přepsání fuse bitů jenom čtu ve forech.

Napsal: 11 úno 2013, 09:42
od fikes
Tak asi opět zapnu strší PC s COM portem a s PonyProg. Jen ještě dotaz:
po připojení na programovací konektor (MOSI, MISO, CLK, RESET) připojit zřejmě i Vdd +5V na procesor, ve schematech to nebývá zakresleno (jenom pro upřesnění).

Napsal: 11 úno 2013, 13:30
od AB1
Procesor samozřejmě musí být při programování napájený.
A pokud má nastavený krystalový oscilátor, tak musí být připojený krystal.

Napsal: 11 úno 2013, 17:27
od Atlan
fikes píše:Není v tomto ohledu nad Microchipy, tam se to nastaví v configu a vygeneruje se *.hex, přehrávám procesory při ladění programu stokrát a bez obav, střídám firmwary jak se mi zachce a takové problémy jako s Atmelama nenastávaj. Je to věc výrobce jaký způsob zvolí, myslím, že co se týká Atmelu, tak se to moc nepovedlo, sám s Atmelama bojuju a s obavami přehrávám firmware aby se něco s broukem nestalo, viz zablokování pojistkama, což u Microchipů nehrozí.


DAm nacitat poistky, nastavim co treba a raz ich naprogramujem a uz neriesim lem menim program flash a eeprom..... nemoze sa nic stat.
Fakt je to len problem uzivatela...

Napsal: 11 úno 2013, 18:00
od fikes
Už je to vyřešeno, do napájivého pole jsem zapojil k Atmelu externí oscilátor, propojil s programátorem, ten ho identifikoval, smazal jsem flash paměť, načetl pojistky, nastavil L=0xFF, H=0xFF a zapsal. ANO, přiznávám, s Atmalama pracuji hodně málo, jestli jsem s procesorama něco dělal, či zkoušel je už hodně dlouho, nepamatuji si v jakém režimu pracovali, zda ten či onen oscilátor, jsem chytřejší a děkuji za rady. Tři procesory jsem rozchodil, dva zatím ne, zkusím to ATMEL fusebit doctorem (opravdu už nevím co jsem s nimi zkoušel). Jsem zvyklej na Microchipy, tam je to jinak.

Napsal: 26 úno 2013, 08:44
od hrabosh
Nevím, co bylo špatně, ale použití USBASP programátoru z Aukra za 169,- vyřešilo problém...