[STM32]Logger GPS nie działa gdy procesor jest aktywny

Witam,

Buduje pewne urządzenie które ma zapamiętywać pozycje z GPSa tak aby można sobie później przejrzeć gdzie urządzenie się znajdowało, taki logger GPS. Pierwsza wersja tego urządzenia powstała na procesorze AVR i module GPS FGPMMOPA6 i działało prawidłowo.
Konieczność rozbudowy zmusiła mnie do wymiany procesora na STM32F103RB. Po uruchomieniu i testach z nowym procesorem okazało się, że GPS nie widzi żadnych satelitów i aby GPS działał poprawnie STM32 musi być wyłączony lub uśpiony. Dosłownie wyłączenie procesora powoduje, że GPS nagle zaczyna widzieć satelity i działać prawidłowo. Pomyślałem, że to wina PCB które projektowałem w pośpiechu no i zrobiłem nowe już bardzo dokładnie stosując się do porad, które można znałeś na stronie st. Jednak problem nie ustąpił, próbowałem dodawać rożne wartości kondensatorów na zasilaniu procesora, ale nic nie pomaga.

Jeśli ktoś miał podobne problemy z procesorami STM32 lub wie co może być przyczyną to bardzo proszę o pomoc bo już nie mam pomysłów

ELTom2 napisał:

Jeśli ktoś miał podobne problemy z procesorami STM32 lub wie co może być przyczyną to bardzo proszę o pomoc bo już nie mam pomysłów

Miałem podobne problemy (w sensie że GPS raz działał raz nie, model FGPMMOPA6B). Problemy całkowicie zniknęły po zastosowaniu aktywnej anteny do GPS'a.

markosik20 napisał:

Problemy całkowicie zniknęły po zastosowaniu aktywnej anteny do GPS'a.

PCB mam na tyle uniwersalne, że mogę wlutować moduł GPS FGPMMOSL3 i podłączyć zewnętrzną antenę. Wtedy jakoś to działa ale nadal w porównaniu do AVR i modułu ze zintegrowaną anteną się chowa. Dodatkowo jak antenę położyć za blisko elektroniki (procesora STM32) to sygnał zanika. Wersje z AVR mogłem włożyć pod siedzenie w samochodzie i nadal miałem 10 lub 11 satelitów. A tutaj na zewnętrznej antenie przy szybie samochodu 6 czasem 7.

Dziwna sprawa tak jakby w około procesora było pole elektromagnetyczne o częstotliwości GPS.

Wygląda na to, że uC generuje zakłócenia... Najprostszy sposób, aby to sprawdzić, to zaekranować tą część PCB w której jest uC. Jeśli to pomoże, to znaczy, że trzeba przeprojektować PCB lub lepiej odfiltrować sygnały...

Witam! Może spróbuj spowolnić wyjścia procesora-zamiast 50mhz ustaw 10, jesli tylko jest taka możliwość z punktu widzenia aplikacji. Nawet tylko na próbę. Zdecydowanie wygląda to na zakłócenia od stm32, który jako zdecydowanie szybszy "sieje" znacznie wyżej niż avr. Kondensatory na zasilaniu mogą nie pomóc, bo to chyba wyjścia sieją. Spowolnienie gpio plus ekranowanie.

Wyjścia są ustawione na 2MHz najwolniej jak się da. Na poprzedniej wersji PCB próbowałem zamknąć STMa w ekran, jednak to nie pomogło. Możliwe że mój prototypowy ekran był nieszczelny. Spróbuje raz jeszcze.

Dzisiaj zrobiłem jeszcze eksperyment z programem. Jeśli procesor zaraz po starcie i zainicializowaniu zegara "zamknę" w pętli while(1); to GPS działa. Jeśli jednak puszczę program dalej i włączę zegar dla portów lub timera lub innych peryferiów to już GPS nie działa. Wnioskuję z tego że sam rdzeń i generator zegara nie zakłóca. Jednak to mi nie wiele pomaga

ELTom2 napisał:

Wyjścia są ustawione na 2MHz najwolniej jak się da.

Tu nie o to chodzi. Wyłącz PLL lub zmień jego nastawy. W bloku PLL występują nawet kilkuset MHz wartości.

W zasadzie mogło nie pomóc spowolnienie portów bo stromości zboczy przebiegów to nie zmnienia, a duża szybkość narastania/opadania to właśnie szerokie widmo zakłóceń. Zrób może fotki ustrojstwa, ogólną i zbliżenie pcb, oczywiście jakość musi być. Poszukałbym też not pod tytułem "Emc rules", tam poruszane są te właśnie kwestie.

W STM32 można regulować stromość narastania zboczy, może ustawione są zbyt strome...

Father napisał:

W STM32 można regulować stromość narastania zboczy, może ustawione są zbyt strome...

Hmm myślałem, że stromość zboczy zależy od ustawienia w odpowiednich rejestrach na jaką częstotliwość maja być przeznaczone. Ja ustawiłem na 2MHz tak jak pisałem wyżej jeśli można gdzieś zmienić stromość tych zboczy to proszę o konkret bo ja nic więcej w dokumentacji nie znalazłem.

Jeśli chodzi o PLL to tak jak napisałem samo włączenie PLL i działanie rdzenia nie zakłóca dopiero jak włączę zegar na innych peryferiach. Próbowałem różnych ustawień PLL i różnych wartości kwarcu za każdym razem to samo, nie działa.

Robiąc drugą wersje PCB korzystałem z takich rożnych PDFów o EMC znalezionych w internecie i miedzy innymi na stronach ST.
Później postaram się zrobić jeszcze kilka fotek i podeśle.

Dodano po 3 [minuty]:

olosie napisał:

Problem może być także spowodowany brakiem wystarczającej liczby kondenstarów odsprzęgająych. Kondensatory powinny być maksymalnie blisko procesora przy każdej nóżce z zasilaniem (jak procesor ma wyjście 1,8V to też tam powinny być). Możesz też spróbować dać cewkę (koralik smd) na zasilanie GPSa.

Kondensatory są 100n przy każdej nóżce zasilającej tak blisko jak to tylko możliwe mają obudowę TQFP i kondensator 0603. Dodatkowo jest jeden tantal 100u i gasik (100R + 100p szeregowo).

olosie napisał:

A może źródło zasilania nie radzi sobie z wydajnością? Stosowałeś przetwornicę czy stabilizator?

Całość zasilana jest z baterii Li-PO, a procesor po przez stabilizator LDO 3V3 300mA. Zasilanie na oscyloskopie wygląda idealnie. Jednak mam na uwadze, że poziom (i częstotliwość) sygnałów odbieranych przez GPS jest dla mnie nie do zmierzenia.

Hmm teraz zrobiłem eksperyment następujący, jedna PCB z prockiem uśpionym GPS działa. Druga PCB z włączonym procesorem jak zbliżyłem drugą płytkę do pierwszej (tak żeby nie zasłaniać anteny GPS) to pierwsza płytka straciła sygnał mimo, że nie było fizycznego (kablami) połączenia po miedzy nimi. Ewidentnie procesor lub któraś ze ścieżek robi za antenę i nadaje zakłócając GPSa.

Dodanie ekranu nie pomogło.

Wylutowałem procesor z PCB i polutowałem go w "pająka", zasiliłem go bezpośrednio z baterii litowej 3V. Jeśli takiego pająka położę obok GPS ( nawet w odległości 10cm ) to GPS traci sygnał. Wnioskuje z tego, że STM32 są całkiem tanim zagłuszaczem sygnału GPS.Problem przekazałem do inżynierów z ST zobaczymy co wymyślą.

Zrobiłem podobne testy na zakłócanie wykorzystując procesory AT91SAM7X i LPC1766. GPS z tymi procesorami działa normalnie.

Ja u siebie z STM32 i GPS z pasywną anteną też w ogóle nie łapałem satelit (no może po 15min złapało 1 lub 2 pod otwartym niebem ale FIX'a z tego nie dało się zrobić).
Z aktywną anteną ,podkładając ją nawet pod procesor nie zauważam różnicy (cały czas "łapie" 7-8 satelit).
Ciekawe jak ST zareaguje na Twój przypadek...napisz po otrzymaniu odpowiedzi.
I jaki masz model STM'a?

markosik20 napisał:

Ja u siebie z STM32 i GPS z pasywną anteną też w ogóle nie łapałem satelit (no może po 15min złapało 1 lub 2 pod otwartym niebem ale FIX'a z tego nie dało się zrobić).
Z aktywną anteną ,podkładając ją nawet pod procesor nie zauważam różnicy (cały czas "łapie" 7-8 satelit).
Ciekawe jak ST zareaguje na Twój przypadek...napisz po otrzymaniu odpowiedzi.
I jaki masz model STM'a?

Z aktywną anteną też na otwartej przestrzeni łapię od 6 do 8 satelitów, ale tak zwany ColdStart, który powinien wynosić 35s według dokumentacji, wydłuża się czasem nawet do kilku minut. Jeśli antenę przyłożę do procka to jeszcze trudniej złapać FIXa i czasem lubi zgubić sygnał lub pozycja jest bardzo niedokładnie wyznaczona. Poza tym ten moduł z wbudowaną anteną działa dużo lepiej, ma dużo lepszą czułość i na otwartej przestrzeni spokojnie łapie 11 satelitów. Tak jak pisałem w samochodzie nawet ukryty pod siedzeniem działa super. Naprawdę polecam te moduły (dla przypomnienia FGPMMOPA6B) jedyny warunek to nie zakłócać ich .

Model procka to dokładnie STM32F103RBT6. Jak tylko będę znać odpowiedź od ST to oczywiście napiszę.

ELTom2 napisał:

Kondensatory są 100n przy każdej nóżce zasilającej tak blisko jak to tylko możliwe mają obudowę TQFP i kondensator 0603. Dodatkowo jest jeden tantal 100u i gasik (100R + 100p szeregowo).

Procesor musi generować sporo harmonicznych i dla wysokich częstotliwości te 100n może mieć zbyt wysoką impedancję zwłaszcza jeśli te kondensatory są jakieś standardowe.
Spróbuj równolegle do 100n dołączyć kondensatory o mniejszych pojemnościach nawet rzędu pikofaradów. Np dla GSM i DCS stosuje się 8p2 i 39p.

michalko12 napisał:

Procesor musi generować sporo harmonicznych i dla wysokich częstotliwości te 100n może mieć zbyt wysoką impedancję zwłaszcza jeśli te kondensatory są jakieś standardowe.
Spróbuj równolegle do 100n dołączyć kondensatory o mniejszych pojemnościach nawet rzędu pikofaradów. Np dla GSM i DCS stosuje się 8p2 i 39p.

Też tak pomyślałem na samym początku. Dawałem rożne kondensatory kładłem je już na tak zwaną kanapkę (jedne na drugim) i niestety żadnej poprawy nie zauważyłem.

Widzę, że wszystkiego już chyba próbowałeś. Połóż może na procu, na jego wyprowadzeniach pierścień ferrytowy, może dodanie grama indukcyjności połączeniom coś zmieni. Dobrze byłoby zobaczyć analizatorem widma jak to wygląda-czy widmo raczej szerokie, czy może jakieś prążki. Większa odporność aktywnej anteny sugerowała by fakt istnienie zakłóceń w pobliżu częstotliwości lustrzanych odbiornika gps. Albo wchodzi to na pośrednią odbiornika. Podeślij jakieś materiały nt. tego modułu. Trochę daleko mieszkasz, bo wpadłbyś obejżeć to sobie na analizatorze. W ostateczności pakuj w bąbelki i przyślij. Sam jestem ciekaw o co tu chodzi.

Bruum napisał:

Widzę, że wszystkiego już chyba próbowałeś. Połóż może na procu, na jego wyprowadzeniach pierścień ferrytowy, może dodanie grama indukcyjności połączeniom coś zmieni. Dobrze byłoby zobaczyć analizatorem widma jak to wygląda-czy widmo raczej szerokie, czy może jakieś prążki. Większa odporność aktywnej anteny sugerowała by fakt istnienie zakłóceń w pobliżu częstotliwości lustrzanych odbiornika gps. Albo wchodzi to na pośrednią odbiornika. Podeślij jakieś materiały nt. tego modułu. Trochę daleko mieszkasz, bo wpadłbyś obejżeć to sobie na analizatorze. W ostateczności pakuj w bąbelki i przyślij. Sam jestem ciekaw o co tu chodzi.

Ahh miałem nadzieje, że wszystkiego nie próbowałem i ktoś na forum miał taki problem kiedyś i go rozwiązał. Sprawdzę z tym ferrytem czy pomoże coś. Pod analizatorem fajnie było by to obejrzeć, zobaczymy jednak na razie jak rozwinie się pomoc ze strony ST.
Ja jednak zobowiązany terminami muszę to szybko przebudować na inny procesor i zastanawiam się po między ATMELem AT91SAM7X256 lub NXP LPC1754 (dosyć nowe procesory z rdzeniem Cortex M3).

Jeśli widmo zakłóceń leży w pasmie lustrzanki lub pośredniej albo nawet subharmonicznej heterodyny modułu gps, to pomogłaby zmiana typu modułu na taki, który pracuje z inną pośrednią. Dlatego ważna jest znajomość szczegółowych parametrów sygnałów zakłócających. Czasami nie da się zaekranować poszczególnych bloków danego urządzenia tak, żeby wyeliminować wzajemne wpływy, pomaga wtedy odpowienie poprzestawianie częstotliwości pracy podzespołów.

STM32 zamieniłem na LPC1754. Od kilku dni testuje urządzenie i GPS z tym procesorem działa prawidłowo, startuje z czasami opisanymi w dokumentacji i nawet w mieszkaniu z daleka od okna łapie 7 satelitów.

Firma ST potwierdziła zgłoszenie problemu, ale jak na razie nie podała żadnej konkretnej odpowiedzi. Tak jak pisałem wcześniej jeśli będę coś wiedzieć to jeszcze napiszę. Na ten czas powiem tyle, że LPC spisuje się lepiej od STMa.

Przy okazji chciałbym polecić wszystkim narzędzie zwane LPCXpresso. IDE oparte o Eclipse i kompilator GCC, do tego dosłownie za grosze debugger. Ściągamy jeden plik i wszystko instaluje się samo bardzo szybko. Automatyczne generowane skrypty make file i linkera. Naprawdę można bardzo szybko i bezproblemowo stworzyć projekt na LPC wykorzystują to narzędzie. NXP zaskoczyło mnie bardzo pozytywnie

Muszę potwierdzić niestety spostrzeżenia autora (nie wiem dlaczego, ale wcześniej moduł tak się nie zachowywał...albo sprawdzałem byle jak ). Po odpaleniu wszystkich wymaganych peryferiów w STM32 moduł GPS niestety przestał "widzieć" satelity. Wystarczy antenę (aktywną) oddalić od modułu na około 10cm i wszystko wraca do normy. O złapaniu FIX'a w pobliżu działającego STM'a w ogóle nie ma mowy, pomaga tylko jego uśpienie..a i to nie zawsze.


Pytanie do autora: ST coś odpowiedziało?

Czyli nie jestem osamotniony w tym temacie . Tak jak pisałem wcześniej zmieniłem procesor na LPC i mam uruchomionych większość jego peryferiów i GPS działa normalnie. Co do STM32 to dowiedziałem się, że to wina pamięci flash. Według firmy ST gdyby wykonywać program z pamięci RAM to powinno działać ale nigdy tego nie sprawdziłem z braku czasu.

Sugerowali jeszcze dodanie filtrów EMI takich SMD jednego na zasilaniu idącym bezpośrednio do procka i jak najbliżej procka, drugiego na masie wracającej od procka. Najlepiej żeby oba filtry były blisko siebie i jak najbliżej procesora. Jednak ja próbowałem tego rozwiązania i mi nie pomogło.
Ogólnie chyba znali już temat i od razu napisali, że to wina pamięci flash. Może spróbować zamiast usypiać procesor to załadować jakąś pętle nieskończoną z kawałkiem kodu do pamięci ram i ją wykonać.

ELTom2 napisał:

Może spróbować zamiast usypiać procesor to załadować jakąś pętle nieskończoną z kawałkiem kodu do pamięci ram i ją wykonać.

Ja akurat i tak czy siak usypiam STM'a ze względu na oszczędność baterii (działa tylko GSM w trybie Sleep). Z tą pętlą w RAM to i może nie głupi pomysł ale co jak braknie RAM'u (a czekanie w nieskończoność na FIX'a mija się z celem....urządzenie może zmienić właściciela kilka razy ). Więc pozostaje przeprojektować wszystko na NXP.....jak u Ciebie się sprawdził?...bo w sumie architektura ta sama (cortex M3 LPC1754). Ja będę musiał odpalić na nim 3 UARTY, USB w trybie Device, SPI (SSP), pewnie jakieś timery, dużo przerwań zewnętrznych oraz tryby uśpienia i mam nadzieję że pójdzie równie gładko co z STM'em.

LPC spisuje się świetnie. Biblioteki do LPC niestety nie ma tak fajnej jak do STM32 i przez to troszkę bardziej trzeba się w rejestry zagłębiać. Działa normalnie z OpenOCD tylko troszkę plik konfiguracyjny od innego LPC17xx trzeba przerobić. Ja osobiście polecam LPCExpresso, ma od razu wbudowane rejestry procesora i szybko i fajnie działa.
Również odpaliłem na nim 3 UARTy, i mnóstwo przerwań wszystko chodzi jak należy. Jeszcze mnie czekają tryby uśpienia do zrobienia, ale powinno być ok.

Witam. Ja właśnie projektuje podobny układ. Wstępnie miał być na nim STM32F103RBT6. Mam wprawdzie inny moduł - GSP01 od Hope RF z aktywną anteną ceramiczną, która miała być wewnątrz, lub na zewnątrz (w zależności od wersji).

Czy mam sobie odpuścić od razu ten uC?

Skoro problem jest we flashu, to czemu ekranowanie nie pomaga? Czy zmniejszenie częstotliwości pracy uC też nie pomaga?

Pozdrawiam Jakub

Możliwe, że modułom HOPEa nie będą przeszkadzać zakłócenia od STMa. Zmiany częstotliwość nie przynosiły efektu, możliwe że na niektórych było lepiej na innych gorzej, ale i tak było beznadziejnie. Możliwe że mój ekran nie był doskonały, jednak czy warto, projektować specjalnie ekran skoro można użyć innego procesora i nie bawić się w ekranowanie?
Polutuj sobie na przewodach tego GPS i podłącz do RS komputera. Jak masz jakąś płytkę z tym procesorem to zbliż ją do anteny GPS i zobacz czy nadal wszystko działa, czy czas startu GPSa się nie zmienił. Ja tak później zrobiłem z popularnym "motylkiem" z procesorem STM i okazało się, że ten motylek to całkiem niezły zagłuszacz GPS

Okazuje się że oprócz zakłócania GPS'a STM32 również dobrze radzi sobie z GSM'em . Gdy antena jest oddalona o około 10cm od uC siła sygnału wzrasta z 19 do 25 (gdzie 31 to max).

Szczęście że znalazłem Wasz wątek, może zaoszczędzi mi wiele pracy. W skład mojej pracy magisterskiej wchodzi min. płytka z stm32F103 i wyżej wymieniony GPS. Czy te problemy występują także, gdy GPS oddalimy od mikrokontrolera nawet o jakieś 20-25 cm. Płytkę uC bym zaekranował, przy nóżkach zasilaniach mam wszędzie 100nF, na oddzielnej płytce GPS mam 10uF i 100nF, zasilanie poprzez dławik 10uH-100uH. Niby mógł bym zmienić uC na SAM7, ale dałem już wzory płytek pod stm32 promotorowi do zrobienia przez firmę.

Pozdrawiam.