'51(8252) z czystym flashem (FF..) - jak powinien dzialac?

Witam,

Jestem wlasnie w trakcie projektowania i uruchamiania mojego pierwszego ukladu z mikroprockiem 89S8252 (wczesniej zmontowalem jeden dzialajacy uklad z AVRem, ale to bylo w oparciu o gotowy schemat).

ISP dziala, bo zapisalem jakis program i odczytalem to samo.
Natomiast sam program nie dziala tak jakbym sie spodziewal. Pewnie jest to jakis blad w programie, zaraz bede tego szukal, ale najpierw chcialem sie zastanowic, czy w ogole uklad jest dobrze zmontowany. Konkretnie: jakie powinno byc zachowanie mikroprocka przy wyczyszczonym flashu (czyli same FF FF FF ..)? slabo znam assemblera, a tym bardziej kody odpowiadajace poszczegolnym instrukcjom, dlatego chcialbym sie Was zapytac, czy to normalne dla tak "zaprogramowanego" ukladu, zeby diody podlaczone do portu P0 szybko (szybko = tyle Hz, ze nie jestem w stanie na oko ich zliczyc, ale widze, ze mruga ) mrugaly? a dokladniej bardzo szybko zmienia sie konfiguracja swiecacych/nieswiecacych diod (sprawdzilem to zwierajac wyjscia kwarcu - wtedy diody "zastygaja" i przypadkowe [za kazdym razem inne] diody sie swieca). Spodziewalbym sie raczej, zeby porty przybieraly jakas losowa wartosc (jako niezainicjalizowane), ale by potem uklad "zamarzal" na instrukcjach FF FF FF .. Dlatego pytam: czy to normalne zachowanie? Zaczynam sie zastanawiac, czy np. nie mam gdzies jakiegos niepotrzebnego, albo zle zamontowanego kondensatora, ktoryby ciagle resetowal uklad?

Dzieki wielkie za pomoc.

Witam,

jeśli pamięc kontrolera serii '51 jest całkiem czysta tzn. każda komórka pamięci programu zapisana jest wartością FF ( szesnastkowo) to procesor wykonuje cyklicznie instrukcje MOV R7,A ( takiej instrukcji odpowiada kod FF ) a wsztkie porty ustawione są w stan wysoki ( jako wejścia ).

Pytanie czy pamięć twojego kontrolera jest napewno całkiem czysta ( raczej chyba nie ) bo wtedy miganie diód LED ( jakkolwiek są podłączone) to objaw trudny do wytłumaczenia i raczej nieprawidłowy.

Jednak przypuszczam że wpisujesz progam który zapala diody i albo zapomniałeś go zapętlić na końcu albo załączasz Watchdoga i stąd to cykliczne miganie.

Pozdrawiam

Nie, nie o to chodzi - moj program ktory ma dzialac, a ten FF FF to dwie rozne sprawy. Moj program w ogole nie dziala, tzn nie zapala sie nic, ale programator daje tez mozliwosc wyczyscic flasha do samych FF FF FF i wtedy wlasnie diody swiruja.. wiec skoro mowisz, ze stan portow powinien byc stabilny, to musialem cos sp* z hardwarem.. ech, cos czuje, ze czekaja mnie dlugie chwile z miernikiem w reku

Może Reset jest odwrotnie ? Co pokazuje woltomierz na resecie, jak diody "świrują" ?
Light'I

Na resecie jest 0.01 V, czyli wydaje sie w porzadku Nie moge miec tylko pewnosci, czy np. od jakichs kondensatorow nie robia sie jakies szpilki na resecie, ale tego nie mam jak sprawdzic, bo nie mam oscyloskopu.

Nowe procesory Atmela AT89s52, AT89S8252 mają w pamięci program testowy, który faktycznie wysyła jakieś wartości na port P2 . Na płytce testowej, którą posiadam, mam diody na P2, więc mrugają - przy czym P2.0 z większą częstotliwością niż P2.7. Częstotliwość mrugania zależy natomiast od kombinacji stanów logicznych portu P). Przynajmniej tyle zaobserwowałem. Być może są to kolejne wartości od 0 do 255. Nie wgłębiałem się. Może na inne porty też są wystawiane jakieś wartości. Procesor tak się zachowuje czasami również przy nieudanej (przerwanej) próbie programowania. Dziwię się, że osoby które odpowiadały poprzednio na post nic o tym nie powiedziały - może nie miały nigdy w rękach ATMELI '51...
Kiedy miałem problem z programatorem myślałem, że to procesorek jest uszkodzony - a to normalny objaw. Tyle, że nie znalazłem żadnej noty producenta...

amachaj napisał:

Nowe procesory Atmela AT89s52, AT89S8252 mają w pamięci program testowy, który faktycznie wysyła jakieś wartości na port P2 . Na płytce testowej, którą posiadam, mam diody na P2, więc mrugają - przy czym P2.0 z większą częstotliwością niż P2.7. Częstotliwość mrugania zależy natomiast od kombinacji stanów logicznych portu P). Przynajmniej tyle zaobserwowałem. Być może są to kolejne wartości od 0 do 255. Nie wgłębiałem się. Może na inne porty też są wystawiane jakieś wartości. Procesor tak się zachowuje czasami również przy nieudanej (przerwanej) próbie programowania. Dziwię się, że osoby które odpowiadały poprzednio na post nic o tym nie powiedziały - może nie miały nigdy w rękach ATMELI '51...
Kiedy miałem problem z programatorem myślałem, że to procesorek jest uszkodzony - a to normalny objaw. Tyle, że nie znalazłem żadnej noty producenta...

Nie wygłaszał bym takich poglądów na Twoim miejscu.

Ustalenie stanu RESET powoduje wpisanie do rejestrów SFR wartości określanych w nocie katalogowej jako "Reset Value".
Dla portów P0..P3 jest to 0xFF a to znaczy że wszystkie porty przyjmują wartość "jedynki" logicznej ( mogą pracować jako wejścia).

Nie wiem jaki jest Twój stan wiedzy na temat Atmeli '51

Cytat:

Tyle, że nie znalazłem żadnej noty producenta

ale po resecie warunki są jasno określone - bodaj tylko RAM nie jest zmieniany. Jeśli pamięć procesora jest kompletnie czysta ( wszystkie komórki pamięci programu mają wpisane "1" ew. wartości FF - jak kto woli) to procesor cyklicznie wykonuje instrukcje o kodzie maszynowym 0xFF a to jest MOV R7,A a to nijak nie zmiania stanu portów ( oczywiście jeśli cała pamięć jest wyczyszczona )

Inna sprawa to proces programowania (w szczególności weryfikowania), wtedy układy dołączone do portów mogą zachowywać się niestabilnie.
Z doświadczenia wiem że pomiędzy procesem programowania a weryfikowania zdąży wykonać się kilka linijek kodu ( ISP - program AECv3.0)

I żeby sprawę wyjaśnic z z portem P2 to przytaczam fragment opisu Portu P2 z najnowszej noty 89S52(rev.C 3/05) :

Cytat:

Port 2 emits the high-order address byte during fetches from external program memory and during
accesses to external data memory that use 16-bit addresses (MOVX @ DPTR).

i od razu tłumacze żeby nikt nie napisał że tu się pisze polsku:
P2 wystawia bardziej znaczący bajt adresu podczas pobierania instrukcji z zewnętrzej pamięci programu oraz podczas dostępu do zewnętrznej pamięci danych która używa 16bitowego adresu (instrukcja MOVX @ DPTR)

Cytat:

During accesses to external data memory that use 8-bit addresses (MOVX @ RI), Port 2 emits the contents of the P2 Special Function Register.

Podczas dostępu do zewnętrzenj pamięci danych która używa 8bitowego adresu Port2 wystawia zawartość rejstru P2 z obszaru rejestrów SFR ( instrukcja MOVX @ RI)

Cytat:

Port 2 also receives the high-order address bits and some control signals during Flash programming and verification.

Podczas programowania i weryfikowania (zapewne równoległego) port P2 odbera bardziej znaczący bajt adresu i niektóre sygnały kontrolne

NIE WIEM SKĄD POMYSŁ OCENIANIA WYPOWIEDZI INNYCH kiedy samemu nie wie się dokładnie co się chce powiedzieć

Cytat:

Kiedy miałem problem z programatorem myślałem, że to procesorek jest uszkodzony - a to normalny objaw. Tyle, że nie znalazłem żadnej noty producenta...

Dobra - żeby wrócić do konkretów. Polecam następującą procedure uruchomienia układu:
1. sprawdzenie napięć
- zasilającech =5V
- na wejściu RESET ~0V po ustaleniu
- na wejściu EA/VPP =5V gdy korzystamy z wewnętrznej pamięci
2. jeśli w układzie mamy jakąś diodę LED, to piszemy prosty program który ją zapali i wczytujemy
3. piszemy prosty program który ją zgasi i wczytujemy
4. ew. zamiast punktów 2 i 3 piszemy od razu program który ją zapali i zgasi cyklicznie kilka razy(opóźnienie pisane najlepiej bez używania Timerów), umieszczamy na początku programu i wczytujemy program do układu.

Jaki sens ma zabawa z ledami - jeśli na początku programu diody pomrugają sobie kilka razy to wiesz :
a) że program nie działa - diody nie mrugają
b) że program działa - diody mrugają
c) że program się co chwila resetuje lub tracisz kontrole nad programem i licznik PC osiąga wartość maksymalną dla danego proceora poczym zaczyna od rozkazu 0x00 - diody mrugają co jakiś czas
d) pomoże ci to ustalić że kontroler resetuje się w momencie przełączania np. przekaźników czy spadku napięcia

Jak już wszytko uruchomisz to możesz fragment z diodami wywalić.

A tak w ogóle to zamieście schemat, program, wtedy można dyskutować.

Pozdrawiam i życze mniej tak stanowczych osądów.

Cytat:

Dobra - żeby wrócić do konkretów. Polecam następującą procedure uruchomienia układu:
1. sprawdzenie napięć
- zasilającech =5V
- na wejściu RESET ~0V po ustaleniu
- na wejściu EA/VPP =5V gdy korzystamy z wewnętrznej pamięci
2. jeśli w układzie mamy jakąś diodę LED, to piszemy prosty program który ją zapali i wczytujemy
3. piszemy prosty program który ją zgasi i wczytujemy
4. ew. zamiast punktów 2 i 3 piszemy od razu program który ją zapali i zgasi cyklicznie kilka razy(opóźnienie pisane najlepiej bez używania Timerów), umieszczamy na początku programu i wczytujemy program do układu.

Jaki sens ma zabawa z ledami - jeśli na początku programu diody pomrugają sobie kilka razy to wiesz :
a) że program nie działa - diody nie mrugają
b) że program działa - diody mrugają
c) że program się co chwila resetuje lub tracisz kontrole nad programem i licznik PC osiąga wartość maksymalną dla danego proceora poczym zaczyna od rozkazu 0x00 - diody mrugają co jakiś czas
d) pomoże ci to ustalić że kontroler resetuje się w momencie przełączania np. przekaźników czy spadku napięcia

Jak już wszytko uruchomisz to możesz fragment z diodami wywalić.

A tak w ogóle to zamieście schemat, program, wtedy można dyskutować.

Pozdrawiam i życze mniej tak stanowczych osądów.

Proponuję żeby kolega się nie obrażał tylko zakupił nowego atmela 52, 8252 i zobaczył na własne oczy niedowiarka. Wystarczy podpiąć kwarc, kondensatorki, EA, kodensator od resetu, drabinka 4,7k na P0 i zobaczyć co jest na oscyloskopie na P2.0..7 (jeśli oczywiście ma takowe urządzenie).
Jestem przekonany, że właśnie o to chodzi w tym temacie. Moja przygoda z Atmelami zaczęła się właśnie od tego problemu. Wcześniej pracowałem z inną firmą.
Teraz mi to przyszło na myśl i sprawdziłem w dokumentacji - Atmele mają po prostu tak: Jeśli EA jest podpięte do 1 to i tak po przekroczeniu wewnętrznej (8kB) pamięci programu zaczynają odwoływać się do zewnętrznej pamięci programu. Na P2 wystawiany jest adres i odczytywane są dane z P0. Warunek jest taki, że P0 musi być podciągnięte do 1. To właśnie kolejne wystawiane bajty wyglądają na "dziwne mrugane". Przyznaję że bzdurą jest, iż jest to jakiś tryb testowy - to jest normalna praca czystego uK.

Dzieki wielkie za zainteresowanie i wszystkie rady!

Okazalo sie, ze sprzet byl w porzadku - nic sie nie zwieralo, resetowalo, ani nic podobnego, po prostu takie jest zachowanie procka z czysta pamiecia, zgodnie z tym co mowil amachaj. Problem byl nie ze sprzetem, tylko ze zle napisanym programem. Az wstyd sie przyznac, ale po prostu pomylily mi sie porty (a diody mialem podlaczone tylko do jednego) i sie dziwilem, ze nic sie nie dzieje Tak czy owak informacje o dzialaniu czystego procka na pewno beda przydatne na przyszlosc.

Jeszcze raz dzieki za odpowiedzi !

Potwierdzam, takie zachowanie jest normalne przy wykasownaym procku. u mnie też diody podpięte do P0 migają w chaotyczny sposób.

Cześć

Przy stanie resetu flasz ustawia sie na 0xffff, programowaie mozliwe jest tylko przy podaniu na reset stanu wysokiego

Pozdro