Uruchamiając układy z różnymi procesorami MSP430 napotkałem podobne
problemy, ich rozwiązanie zajęło mi troszkę czasu, może komuś go
zaoszczędzę.

1. Program nie uruchamiał się po włączeniu zasilania, jednak w trybie
debagowania, czy po resecie wszystko działało poprawnie.
2. Jeśli procesor współpracuje z innymi układami, to układy te po
włączeniu zasilania często nie działały, jednak w trybie debagowania,
czy po resecie wszystko działało poprawnie.

Okazało się, że powodem takiego zachowania jest ograniczona szybkość
narastania napięcia zasilającego.
MSP430 zaczyna działać przy 1,8V, zgodnie z przykładami od TI w
pierwszej linii kodu wyłączałem watchdoga, następnie konfigurowałem
procesor. Jeśli przełączenie wewnętrznego zegara na wyższą częstotliwość
nastąpiło zanim napięcie osiągnęło odpowiednią wartość to procesor się
zawieszał a watchdoga był wyłączony...
Np. dla zegara 16MHz wymagane jest napięcie co najmniej 3,3V.

Podobnie problem wygląda z peryferiami.
Inicjacja peryferiów występuje przeważnie na początku programu, jeśli
napięcie zasilające wynosi wtedy np. 2V a peryferia działają na 3,3V to
nie zostaną one zainicjowane i problem gotowy.

Jeśli w układzie nie mamy możliwości dodania nadzorcy napięcia to
najprostszym rozwiązaniem jest dodanie dostatecznie długo trwającej
pętli na początku programu.


--
Pozdrawiam,
Andrzej

do góry

> Uruchamiając układy z różnymi procesorami MSP430 napotkałem podobne
> problemy, ich rozwiązanie zajęło mi troszkę czasu, może komuś go
> zaoszczędzę.

> 1. Program nie uruchamiał się po włączeniu zasilania, jednak w trybie
> debagowania, czy po resecie wszystko działało poprawnie.
> 2. Jeśli procesor współpracuje z innymi układami, to układy te po
> włączeniu zasilania często nie działały, jednak w trybie debagowania,
> czy po resecie wszystko działało poprawnie.

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.

do góry

W dniu 2011-01-12 01:31, john smith pisze:
> 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.

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.

--
Pozdrawiam,
Andrzej

do góry

W dniu 1/11/2011 22:58, Andrzej W. pisze:
> Uruchamiając układy z różnymi procesorami MSP430 napotkałem podobne
> problemy, ich rozwiązanie zajęło mi troszkę czasu, może komuś go
> zaoszczędzę.
>
> 1. Program nie uruchamiał się po włączeniu zasilania, jednak w trybie
> debagowania, czy po resecie wszystko działało poprawnie.

Bo się układ zasilał z programatora.

> 2. Jeśli procesor współpracuje z innymi układami, to układy te po
> włączeniu zasilania często nie działały, jednak w trybie debagowania,
> czy po resecie wszystko działało poprawnie.

To samo.
>
> Okazało się, że powodem takiego zachowania jest ograniczona szybkość
> narastania napięcia zasilającego.
> MSP430 zaczyna działać przy 1,8V, zgodnie z przykładami od TI w
> pierwszej linii kodu wyłączałem watchdoga, następnie konfigurowałem
> procesor. Jeśli przełączenie wewnętrznego zegara na wyższą częstotliwość
> nastąpiło zanim napięcie osiągnęło odpowiednią wartość to procesor się
> zawieszał a watchdoga był wyłączony...

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 ?


> Np. dla zegara 16MHz wymagane jest napięcie co najmniej 3,3V.
>
> Podobnie problem wygląda z peryferiami.
> Inicjacja peryferiów występuje przeważnie na początku programu, jeśli
> napięcie zasilające wynosi wtedy np. 2V a peryferia działają na 3,3V to
> nie zostaną one zainicjowane i problem gotowy.


Jakie peryferia nie chciały działać ? wewnętrzne ?
>
> Jeśli w układzie nie mamy możliwości dodania nadzorcy napięcia to
> najprostszym rozwiązaniem jest dodanie dostatecznie długo trwającej
> pętli na początku programu.
>
>

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


Adam

do góry

W dniu 2011-01-13 13:05, Górski Adam pisze:
>
> Bo się układ zasilał z programatora.

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.

>
> C TI example:
> ......
>
> Wyraźnie widać oczekiwanie na uruchomienie generatora HF. Więc z czym
> problem ?

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.

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

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


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

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


--
Pozdrawiam,
Andrzej

do góry

W dniu 1/13/2011 13:50, Andrzej W. pisze:
> W dniu 2011-01-13 13:05, Górski Adam pisze:
>>
>> Bo się układ zasilał z programatora.
>
> 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.

No i duma dała znać.

>
>>
>> C TI example:
>> ......
>>
>> Wyraźnie widać oczekiwanie na uruchomienie generatora HF. Więc z czym
>> problem ?
>
> 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.
>
>>
>> Jakie peryferia nie chciały działać ? wewnętrzne ?
>
> Peryferia peryferyjne :-) czyli np. LCD, mój poprawnie działa dla napięć
> powyżej 3V.
>
>
>>
>> Zrobiłem z nim przeszło 30 projektów - nigdy nie miałem takich problemów.
>>
>
> 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ść.

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

do góry

W dniu 2011-01-13 14:41, Górski Adam pisze:
> 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.
>

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


--
Pozdrawiam,
Andrzej

do góry