spostrzeżenia z praktyki

To są problemy wspólne dla mikrokontrolerów nie wyposażonych w układ resetu. Nie napisałeś z jakimi MSP430 są takie problemy. MSP430 najczęściej mają w obwodzie resetu układ BOR (opisany w slau144e.pdf), w rodzinie 1xx większość, w 2xx i wyższych wszystkie. Jest to nieprogramowalny element obwodu resetu i informuje o poprawnym napięciu Vcc. Całość jest tak skuteczna, że jak testowałem resetowanie MSP430F2274 z zasilacza laboratoryjnego _po_odłączeniu_programatora_ zasilanego z USB to układ wstawał za każdym razem. Trzeba pamiętać, wejścia MSP zabezpieczane przed ESD diodami i gdy napięcie VCC jest mniejsze od napięcia programatora, to może tam popłynąć pasożytniczy prąd który może zasilić MSP430 i zrobić inne kłopoty.

W części układów MSP430 jest jeszcze SVS, bardziej złożony i już programowany nadzorca napięcia zasilającego. K.

W dniu 2011-01-12 01:31, john smith pisze:

Bawiłem się rodziną 2xx, która jest wyposażona w BOR i działa on poprawnie. To co opisałem nie jest błędem tej rodziny procesorów tylko błędem koncepcyjnym popełnionym w czasie projektowania układu z tym procesorem. Błędem o tyle trudnym do wykrycia, że objawia się on z pewnym opóźnieniem. Są to procesory o bardzo szerokim napięciu zasilającym co stanowi jedną z ich zalet, ale pociąga też za sobą konieczność innego spojrzenia na projekt. Trzeba pamiętać, że BOR uruchamia procesor od 1,8V a jeśli nasz układ potrzebuje wyższego napięcia by poprawnie działać to odpowiedzialność za jego kontrolę spoczywa na nas.

W dniu 1/11/2011 22:58, Andrzej W. pisze:

Bo się układ zasilał z programatora.

To samo.

C TI example:

void main(void) { unsigned int i; WDTCTL = WDTPW + WDTHOLD; // Stop WDT BCSCTL1 |= XTS; // ACLK = LFXT1 = HF XTAL P2DIR |= 0x01; // P2.0 = output direction P2SEL |= 0x01; // P2.0 = ACLK function P1DIR |= 0x02; // P1.1 = output direction

do { IFG1 &= ~OFIFG; // Clear OSCFault flag for (i = 0xFF; i > 0; i--); // Time for flag to set } while ((IFG1 & OFIFG)); // OSCFault flag still set?

BCSCTL2 |= SELM_3;

Wyraźnie widać oczekiwanie na uruchomienie generatora HF. Więc z czym problem ?

Jakie peryferia nie chciały działać ? wewnętrzne ?

Zrobiłem z nim przeszło 30 projektów - nigdy nie miałem takich problemów.

Adam

W dniu 2011-01-13 13:05, Górski Adam pisze:

Ja akurat nie używam programatora do zasilania prototypów. Zasilanie było "nierzeczywiste" i dlatego właśnie pisałem, że jest to problem ujawniający się z opóźnieniem dopiero w realnym układzie.

Wyraźnie widać, że nie doczytałeś, pisałem o zegarze wewnętrznym a nie generatorze kwarcowym. Wewnętrzny zegar nie ma chyba bitu awarii.

Peryferia peryferyjne :-) czyli np. LCD, mój poprawnie działa dla napięć powyżej 3V.

Ja zrobiłem kilka, może naście, natrafiłem na taki problem i go opisałem by oszczędzić czasu innym. Nie ukrywam, że akurat w tym projekcie zasilanie było złożone i przejście od 2V do 3,3V potrafiło zająć i ze 100 ms, a to dla procesora wieczność.

W dniu 1/13/2011 13:50, Andrzej W. pisze:

No i duma dała znać.

Miałeś normalne problemy z prototypem - kto tego nie zna ? Ale to nie problem z MSP tylko z projektem. Nie ma prototypów działających od pierwszego włączenia i tyle.

Pozdrawiam

Górski Adam

W dniu 2011-01-13 14:41, Górski Adam pisze:

Przecież pisałem, że to nie wina MSP, tylko specyfika projektu.