ATMega165, odchazi pri programovani

Zpráva

hrabosh · #1 Příspěvek od **hrabosh** » 08 úno 2013, 22:33

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.

Andrea · #2 Příspěvek od **Andrea** » 08 úno 2013, 22:43

Nemusí být mrtvoly, stačí špatně nastavený zdroj hodin a to se dá léčit, probíralo se to tu už mnohokrát.

hrabosh · #3 Příspěvek od **hrabosh** » 09 úno 2013, 09:58

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?

Panda38 · #4 Příspěvek od **Panda38** » 09 úno 2013, 11:25

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.

hrabosh · #5 Příspěvek od **hrabosh** » 10 úno 2013, 17:37

Ani snížení SPI SCK frekvence nepomáhá. Zkoušel jsem to ted s 1kHz a nic...

fikes · #6 Příspěvek od **fikes** » 10 úno 2013, 20:14

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í.

Andrea · #7 Příspěvek od **Andrea** » 10 úno 2013, 20:25

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í.

fikes · #8 Příspěvek od **fikes** » 10 úno 2013, 21:19

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 :-)

AB1 · #9 Příspěvek od **AB1** » 11 úno 2013, 08:15

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.

fikes · #10 Příspěvek od **fikes** » 11 úno 2013, 09:42

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í).

AB1 · #11 Příspěvek od **AB1** » 11 úno 2013, 13:30

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.

Atlan · #12 Příspěvek od **Atlan** » 11 úno 2013, 17:27

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...

fikes · #13 Příspěvek od **fikes** » 11 úno 2013, 18:00

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.

hrabosh · #14 Příspěvek od **hrabosh** » 26 úno 2013, 08:44

Nevím, co bylo špatně, ale použití USBASP programátoru z Aukra za 169,- vyřešilo problém...