Diskuzní fórum Elektro Bastlírny

Zdravím.

Měl jsem na nepájivém poli odlaďenou konstrukci s ATMEGA88čkou. K té býl přímo připojený třímístný multiplexně řízený display, pár diskrétních vstupů a výstupů a přes SPI devítimístný maličký display, řízený taky AVRkem /MEGA8/.

Už na tom poli se mi občas po zapnutí, /nebo po flashování/ stávalo, že místo toho, aby processor začal vykonávat program, tak na jendom, nebo dvou digitech rozsvítil všechny segmenty a nereagoval na nic ... pomohl jen reset. Když to ale přežilo zapnutí napájení, nebo reset, bylo to schopné běžet třeba 12 hodin v kuse.

Teď jsem si udělal tišťák, osadil ho a výšezmíněná situace nastává tak v polovině případů a to ešte v případě, že je ten devítimístný SPI dispaly odpojený. Pokud je připojený, skoro nikdy to nenaběhne. Pokud už se to ale rozjede, můžu ho klidně připojit a chodí to zase až do vypnutí OK.

Ta konstukce má takovou vymyšlenost, že na log. 1 na jednom pinu se to uspí ( asm(sleep) - myslim, že to jednoho z těch režimů "tvrdšího" spánku). Probouzení se děje log. 0 na stejném pinu, resp. INT1, které se v tomto pžípadě zavolá-. Na bastdesce to fungovalo bez problémů, na plošňáku to snad naběhlo třirkát ... v drtivé většině případů se to "sekne", jak jsem popsal výše.

BOD je nastavený na střední úroveň. Když ho nastavím na tu nejvyšší (4,5V), processor je v RESETu i když ho napájím napětím 5,01V přímo ze 78M05. Ta má mimochodem z obou stran 100nF blokovací kondík, stejně jako ta MEGA. Na výstupu té 78M05tky je ještě 100uF kondík. Processor začne něco delat, až když zvýším externím zdrojem napětí na cca 5.5 - 6V. SUT (delay po resetu ... možná se ten FUSE menuje trochu jinak) je taky na maximu.

Už fakt nevím, co s tím ... nezdá se mi, že by ta MEGA byla vadná .. to by snad nejela vůbec a nedělala takový kraviny. Eště mě napadlo, jestli to nedělá ten interní RC oscillátor ... ale nidky jsem s ním problémy neměl.

Napadá vás někoho něco?

Tak nejdřív vyřeš ten problém, že procesor nenabíhá při BOD nastaveným na 4,3V. Můžeš mít bordel na napájení nebo nabořenej procesor.

Instrukce sleep neříká, do jakého sleep režimu procesor přejde, to říká nastavení registru SMCR. Pokud jsi po resetu SMCR nenastavil, tak je sleep zakázaný (instrukce sleep nedělá nic).

Bordel na napájení jsem kontroloval osciloskopem a tvářilo se to OK. Ještě to zkusím napájet z baterie ... čistší napájení už snad ani nejde, ne?

Jinak co se týká toho sleepu, tak to s tím registrem vím. Proto sem tam napsal, že se to uspává do jednoho z těch režimů "tvrdšího spánku", to mám právě nastavený v tom registru, jak píšeš.

Nicméně mám pocit, že problémy s rozběhem při takovém nastavní BOD měl i ten processor na bastldesce (-jinej kousek než teď na plošňáku).

Nemá ten BOD někde nastavitelnej offset napětí, nebo tak?

Jakej offset napětí? Má ty tři úrovně 1,8V, 2,7V a 4,3V. Při napájení 5V musí s BODem na 4,3V běžet naprosto spolehlivě.

No jestli ten BOD nepoužívá při měření těch napětí nejakej nastavitelnej offset.

Protože (jestli to teda nepojede ani na baterku), tak už fakt nevím ...

Používá pevnou interní bandgap referenci. A podle datašítu se ty procesory při výrobě testují při BOD 4,3V.

Před časem jsem řešil podobný problém (myslím s tím chováním po zapnutí), kdy jednou to naběhlo a dvakrát ne, pak třikrát ano a pak .... atd . Nejprve jsem zkoušel vše, co mě napadlo, pak ze zoufalství i hlavu do dlaní. Bohužel bez výsledku. Nakonec jsem zjistil chybu v programu resp. v posloupnosti instrukcí, kdy jsem nejprve nastavil konfiguraci a pak jsem jeden bitík registru v dalším bloku inicializace přepsal (tedy zrušil nastavení). Již si nepamatuji detaily, ale v simulátoru ten program krokoval bez potíží, v reálu viz. výše. Takže pomalu a pozorně zkontroluj program (hlavně část inicializace), zda náhodou tam není nějaká takováhle bota. Ze své zkušenosti říkám, že se to hledá hóóódně špatně.

Tak to opravdu vypadá na software, asi problém s přerušeníma.

Zkoušel jsem na různá místa kodu vkladat 5s delay s tím, že budu pozorovat, jestli se to sekne hned po zapnutí, nebo až po těch pěti sekundách.

Místem zlomu bylo sei(); - které je v kodu až po inicializaci periferií. Když jsem dal delay před sei, sekalo se to až po té prodlevě. Když jsem to dal za sei, sekalo se to hned po zapnutí napájení.

Stejně jako když jsem dal cli() jako první věc po probuzení, probouzelo se to v pohodě i z toho spánku ....

Napadá vás někoho, co bych měl konkrétněji hledat?

Chybu v programu.

Bohužel tyto příkazy jsou mi cizí, protže programuji "jen v assembleru". Ale možná pokud dáš kód k nahlédnutí, ostatní znalí ti třeba pomohou. Nebo potom už jedině zbývá využít radu od Andrey .

Chenzee píše:Bohužel tyto příkazy jsou mi cizí, protže programuji "jen v assembleru".

Asi moc neprogramuješ nebo ne AVR, protože ty "příkazy" jsou instrukce.

Hmm, programuji PICky (nebo pak okrajově VB a zabrouzdávám do PHP).
Ty závorky mě spíše připomínaly C ale jak říkám, to . TAKŽE SE OMLOUVÁM

sei() globálně povolí přerušení a cli() je zakáže.

Projdu kód a zkusím to najít ... mohl by takové chování způsobovat stav, kdy mám v povolené přerušení od nějaké periferie, ale nemám k tomu přerušení napsanou obsluhu?

... tedy alespoň u PICů (ale předpokládám, že to bude tu stejné), pokud nesmažeš příznak toho přerušení, které jej aktivovalo, po ukončení podprogramu přerušení a povolení globálního přerušení toto nedeaktivované přerušení znovu přerušení vyvolá . Takže se ti vlastně zacyklí program, protože se bude toto přerušení neustále vyvolávat.

hrabosh píše:mám v povolené přerušení od nějaké periferie, ale nemám k tomu přerušení napsanou obsluhu?

A proč to děláš?