Stránka 1 z 2
cas vypocitany ATMEGA16 ide pomalsie, odtienene a OK
Napsal: 07 říj 2010, 20:47
od r1a2s3t4o5
Napsal: 08 říj 2010, 06:59
od divous
Ono je ještě otázkou, zda se čas generuje pomocí toho atmelu či jiného RTC obvodu.
U toho RTC neporadím, ale pokud by měl čas v režii atmel, tak mne napadlo, že by mohly být přepsány fuses bity.
Podle fotek bych řekl, že je použit vnitřní RC článek.
(Tedy pokud ten odpor není k plusu a pokud k němu není ještě někde nějaký kondík k zemi. V tom případě by šlo o vnější RC článek)
Frekvenci vnitřního RC článku lze pomocí fuses bitů nastavit na 8MHz, 4MHz, 2Mhz a 1MHz.
A zde nejspíš došlo k přepsání.
V podstatě budeš muset nechat ten procesor přeprogramovat a
to od někoho, kdo má správný firmware. (takže zpět do výroby)
Jedinou nadějí (poměrně malou) by bylo, kdyby ve výrobě při programování zapomněli zapnout ochranu procesoru.
Pak by ti stačil pouze středně zkušený programátor.
Napsal: 08 říj 2010, 08:20
od r1a2s3t4o5
Ano, ja takisto predpokladam ze je pouzity vnutorny RC. Plosak ma miesto na crystal ale nieje osadeny.
Niekde som videl, ze chlapik programoval chip ktory bol osadeny, jednoducho sa napojil programatorom rovno na piny ktore treba na programovanie.
Myslis zeby to slo aj s tymto?
Je mozne osciloskopom zistit na akej freq to bezi teraz?
Aky programator (co najjednoduchsi) doporucujes?
Je mi jasne, ze ak je program chraneni proti citaniu, budu to vyhodene peniaze, ale keby slo zbastlit/kupit programator v rozumnej cene (do 1000) tak to skusim.
Napsal: 08 říj 2010, 09:40
od Andrea
Programovací piny jsou vyvedené na ten neosazený konektor vedle neosazeného krystalu.
Napsal: 08 říj 2010, 09:54
od r1a2s3t4o5
Dnes som prepocital, aky maju hodiny sklz.
za 14 hodin normalneho casu, su hodiny na peci o 2 hodiny pomalsie.
Nasiel som programator na LPT:
http://www.captain.at/electronics/atmel-programmer/
este Linux a paralelny port a mozem skusat...
Precitat ako su nastavene Fuses ide tymto:
Kód: Vybrat vše
uisp -dlpt=/dev/parport0 -dprog=dapa -dpart=ATmega16 --rd_fuses
Napsal: 08 říj 2010, 10:14
od divous
Hmm, tento programátor neznám, takže ti s ním neporadím.
Každopádně to můžeš odzkoušet. A pak sem hoď výsledek.
Mám však dojem, že pokud je zaplá ochrana, tak ti nepůjdou přečíst ani fuses bity.
Z toho poměru zpomalení bohužel nedokážu nic rozeznat.
Ten poměr zpomalení je prostě nějaký divný.
Teď mne ještě napadlo, že by mohla být změněná kalibrace vnitřního RC článku.
I v tomto případě však vše závisí na tom, zda přečteš ty fuses.
Napsal: 08 říj 2010, 10:25
od Crifodo
není to zpomalení tím, že procesor je pořád přerušován?
Napsal: 08 říj 2010, 10:38
od divous
Crifodo píše:není to zpomalení tím, že procesor je pořád přerušován?
Jak přerušován?
-napájení - snad to má nějaké záložní napájení (doufám, z těch fotek to není poznat)
-mikroprocesoru - průměrný programátor (myslím tím člověka) by s tím měl počítat a takovou začátečnickou chybu obejít.
Napsal: 08 říj 2010, 10:42
od Andrea
Alespoň průměrný programátor neudělá zařízení, které se po výpadku napájení začne chovat o dost jinak než před výpadkem.
Napsal: 08 říj 2010, 10:49
od divous
Andrea píše:Alespoň průměrný programátor neudělá zařízení, které se po výpadku napájení začne chovat o dost jinak než před výpadkem.
Pokud to byla chyba programátora. Mohlo jít o chybu procesoru (i to se stává).
To však nyní neřešme, jinak se nám to tu zvrhne v planou diskusi.
Počkejme si, s čím přijde
r1a2s3t4o.
Napsal: 08 říj 2010, 10:52
od Crifodo
přerušován na přerušovacím vstupu nějakým falešným impulsem od periférie. Přeprogramování na čtvrtinu nebo na dvounásobek nezpůsobí chybu 2h na 14 hodinách.
Napsal: 08 říj 2010, 11:29
od divous
Crifodo píše:přerušován na přerušovacím vstupu nějakým falešným impulsem od periférie. Přeprogramování na čtvrtinu nebo na dvounásobek nezpůsobí chybu 2h na 14 hodinách.
To je mi jasné, proto jsem později odhadoval chybu v kalibraci vnitřního RC článku.
Napsal: 08 říj 2010, 14:35
od r1a2s3t4o5
divous píše:Andrea píše:Alespoň průměrný programátor neudělá zařízení, které se po výpadku napájení začne chovat o dost jinak než před výpadkem.
Pokud to byla chyba programátora. Mohlo jít o chybu procesoru (i to se stává).
To však nyní neřešme, jinak se nám to tu zvrhne v planou diskusi.
Počkejme si, s čím přijde
r1a2s3t4o.
Neviem cim to je, ale toto je uz druhy modul, ktory takto zlyhal. Nechcem kupovat dalsi modul ale zistit preco ide cas pomalsie a vyriesit to raz a navzdy.
K pocitacu s Linuxom a LPT sa dostanem najskor buduci tyzden, dovtedy skusim zbastlit programator.
EDIT: Stiahol som program, ale nemam cim analyzovat co tam je naprogramovane. Viete mi poradit nejaky disasembler?
Napsal: 11 říj 2010, 16:19
od r1a2s3t4o5
uisp -dlpt=/dev/parport0 -dprog=dapa -dpart=ATmega16 --rd_fuses
Kód: Vybrat vše
Atmel AVR ATmega16 is found.
Fuse Low Byte = 0x83
Fuse High Byte = 0xdf
Fuse Extended Byte = 0xff
Calibration Byte = 0xbf -- Read Only
Lock Bits = 0xfc
BLB12 -> 1
BLB11 -> 1
BLB02 -> 1
BLB01 -> 1
LB2 -> 0
LB1 -> 0
Podla datasheetu je low byte 0x83 => CKSEL3-0 nastavene na 0011
4Mhz internal clock.
Ak su LB01 a LB02 = 0
Further programming and verification of the Flash and
EEPROM is disabled in Parallel and SPI/JTAG Serial
Programming mode. The Fuse bits are locked in both
Serial and Parallel Programming mode.(1)
Napsal: 12 říj 2010, 08:04
od divous
Tak teď ti už vážně poradit nemohu.
Procesor je zamknutý, a ten soubor rozhodně neobsahuje žádný funkční program.
Je v něm ukryta pouze posloupnost čísel.
Vypadá to tam asi takto:
(00h 00h 01h 01h 02h 02h 03h 03h ..... a tak to pokračuje až po FFh).
Tato řada se opakuje 32x a zbytek paměti je vyplněn hodnotou FFh.
Takže je mi líto, ale pokud se ti nepodaří sehnat funkční program
(a to i s daty z EEPROMky), tak se dál tímto směrem nepohneme.