Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Dziwne zachowanie procesora stm32f103 po przylutowaniu generatora kwarcowego

norbis15 10 Wrz 2018 10:28 438 12
  • #1 10 Wrz 2018 10:28
    norbis15
    Poziom 14  

    Witam,
    Podczas oczekiwania na dostawę płytki napisałem program na innym sprzęcie, ale z tym samym procesorem STM32f103CBT6.
    Jak otrzymałem druki, testuję płytkę debugerem (środowisko AC6) i program po pierwszych funkcjach się zawiesza. Żeby upewnić się, że czegoś nie sknociłem przy lutowaniu, utworzyłem nowy projekt z wykorzystaniem bibliotek HAL migający diodami i ten projekt działa. Następnie otworzyłem nowy projekt ze SandardLib (tak jak mój program docelowy napisany wcześniej) i ten projekt również się zawiesza.

    Podsumowując:
    Program zStdLib się zawiesza po starcie na na nowym druku, a program z HAL działa poprawnie.
    Oba programy działają na innym druku z tym samym procesorem.
    Czy ktoś spotkał się z podobnym problemem?

    Update 2018.09.11:
    Okazuje się że kwarc stanowi problem.
    Przeprowadziłem testy:
    1)Nowy druk i tylko nowy procesor na płytce, komunikacja SWD działa i programy się wykonują zarówno na HAL jak i StdLib
    2)Dodałem kondensatory blokujące 100nF w liczbie 9 i generator kwarcowy 16MHz:Link i teraz działa tylko program na HAL.

    Czemu dodanie kwarcu może powodować taki problem i jak się go pozbyć?

    Zamieszczam zrzut z Oscyloskopu linii zegara i schemat druku, zrzuty z konsoli przy próbach debugowania oraz fragment płytki (podświetliłem kondensatory 100nF i ścieżkę zegara)

    Dziwne zachowanie procesora stm32f103 po przylutowaniu generatora kwarcowegoDziwne zachowanie procesora stm32f103 po przylutowaniu generatora kwarcowegoDziwne zachowanie procesora stm32f103 po przylutowaniu generatora kwarcowegoDziwne zachowanie procesora stm32f103 po przylutowaniu generatora kwarcowegoDziwne zachowanie procesora stm32f103 po przylutowaniu generatora kwarcowego

    0 12
  • #2 11 Wrz 2018 13:22
    mycodename47
    Poziom 12  

    Jeśli możesz to pokaż schemat, kody, bo tak to będzie ciężko pomóc ;)

    0
  • #4 11 Wrz 2018 21:41
    ex-or
    Poziom 14  

    Ja tam się nie znam, ale płytka wygląda dla mnie dosyć podejrzanie: pola miedzi z niczym nie połączone (w tym po µC :-? ), ścieżki zasilania procka poprowadzone...hmmm... :roll: , C16 i C19 (ten szczególnie) umieszczone źle, nie widać przelotek więc laminat zapewne jednowarstwowy czyli na pewno bez pola masy.
    Podejrzewam, że zakłócenia szaleją.
    Dlaczego jeden program działa, a drugi, wydawało by się taki sam, nie? Może piny w obu przypadkach mają ustawiony inny slew rate i to w tym środowisku wystarcza?

    0
  • #5 12 Wrz 2018 08:20
    norbis15
    Poziom 14  

    Tak płytka jest jednowarstwowa, a pole masy jest co widać na padach ujemnych kondensatorów. Ścieżka kondensatora C19 jest taka ze względu na brak przelotek - zdjęcie jest dużym powiększeniem i ta ścieżka jest bardzo krótka. A rzeczywiście jest parę wysp miedzi, ale w czym one przeszkadzają?

    Generalnie znalazłem przyczynę i okazuje się, że jest nią sam procesor!! Przylutowałem go na inny hardware i okazało się że tam on się zachowuje tak samo. Nawet inny przetestowany już dużo wcześniej program napisany z wykorzystaniem StdLib się zawiesza! Idąc za ciosem przelutowałem stary procek z tego starego sprowadzonego hardware`u na moją nową płytkę i na tym starym Procku wszystko działa jak należy:-?

    Kupiłem do projektu 3 procesory STM32f103CBT6 i na wszystkich wystąpił ten problem. Te same procesory kupione pół roku temu działają poprawnie! Czy ktoś potrafi to sensownie wyjaśnić?

    0
  • Pomocny post
    #6 12 Wrz 2018 10:34
    rb401
    Poziom 33  

    norbis15 napisał:
    Czy ktoś potrafi to sensownie wyjaśnić?


    Jak najbardziej sensownie da się wyjaśnić.
    Na opisie na procesorze, dla obudowy LQFP48 w dolnym prawym rogu, znajduje się litera lub cyfra oznaczająca rewizję (np. dla tych Twoich może być jeden ze znaków “B”, “Z”, “Y”, “1”, “2”, “3”, “X” ).
    Zobacz jaki znak masz dla chodzących a jaki dla niechodzących.
    I są faktycznie między rewizjami znaczące różnice, tak że może się zdarzyć że określony program wręcz może nie chodzić, przy określonej rewizji i ustawieniach optymalizacji kompilatora i bibliotece.
    Biblioteki HAL jak tam zaglądałem do źródeł, mają w pewnych miejscach komentarze że są zrobione "podpórki" pod ewentualne rewizje i tak jak zauważyłeś HAL chodzi pewniej. W StdLib jest pewnie z tym gorzej, bo jest przestarzały.
    Dokładniej o różnicach w rewizjach i potencjalnych problemach dowiesz się z erraty do tych procesorów.

    0
  • Pomocny post
    #8 15 Wrz 2018 08:41
    rb401
    Poziom 33  

    norbis15 napisał:
    W erracie nie widzę za bardzo informacji odnośnie różnic między rewizjami...


    Rzeczywiście, wprost to nie jest wyjaśnione a wręcz niejednoznacznie.
    Tam jest przykładowo rozdział:
    Dziwne zachowanie procesora stm32f103 po przylutowaniu generatora kwarcowego

    gdzie piszą że z nowymi kompilatorami bez ewentualnych problemów chodzą tylko rewizje Y i 1. Ale ta errata była aktualizowana już po zmianie tych rewizji na nowsze X i 2 wprowadzone w 2013r. :
    Dziwne zachowanie procesora stm32f103 po przylutowaniu generatora kwarcowego
    i nie wiadomo co z tymi akurat rewizjami. Po za tym te rewizje u Ciebie tak właściwie są równoległe tylko różnią się miejscem wykonania chipów.
    Nie wynika też jednoznacznie że akurat ten problem występuje u Ciebie, bo potrzebne by były testy z różnymi wersjami kompilatorów i wariantami optymalizacji.

    Ale z Twoich doświadczeń wynika jasno że rewizja, w pewnym splocie okoliczności, może być istotna.
    Tu akurat osobiście podejrzewam że HAL pod tym względem może być dużo lepszy, bo choć znalazłem w nim jawne rozpoznawanie rewizji tylko w jednym miejscu (dotyczyło rewizji Z gdzie źle liczone było CRC dla SPI), to ogląd implementacji pewnych funkcji napisanych jakby nie całkiem intuicyjnie zgodnie z opisem działania w DS, nasuwa mi podejrzenie że te udziwnienia to mogą być ewentualnie "obejściami" kłopotów z problemami rewizji.

    0
  • Pomocny post
    #9 15 Wrz 2018 10:04
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Wtrącę swoje 2 gr.

    Używam STM32 w zasadzie od momentu jak pojawiły się na rynku w PL. Firmware piszę zawsze sam, bez SPL i bez HAL. Nigdy w życiu nie musiałem robić żadnego obejścia ze względu na jakieś problemy opisane w erracie. Nie mówię oczywiście o problemach typu "funkcjonalność X w układzie peryferyjnym Y nie działa i koniec", ale właśnie o jakichś takich, że coś tam zależy od kompilatora, biblioteki, optymalizacji, ...

    Ustawienie zegara w STM32F103 to realnie może z 10 linii kodu. Działa zawsze. Tyle że to trzeba by najpierw przeczytać ze zrozumieniem odpowiedni rozdział w Reference Manual, a nie tylko klikać myszką w generatorach projektu. Jak taki kod nie działa, to znaczy że jest błąd w sprzęcie.

    1
  • #10 15 Wrz 2018 10:24
    rb401
    Poziom 33  

    Freddie Chopin napisał:
    Jak taki kod nie działa, to znaczy że jest błąd w sprzęcie.


    Ale zauważ że w ramach testu kolega zmieniał całe otoczenie kości (p.#5) i różnica działa, nie działa dotyczyła tylko samej kostki z inną rewizją.

    Ale co przyczyny, to osobiście rozważałbym też że coś w sofcie może być pokręcone (z gatunku że coś niezainicjowane co trzeba inicjować, odczyt z nieistniejącego adresu lub nieużywanych bitów itp.) i może akurat pewna drobna różnica normalnie nawet nieistotna (nawet nie to co opisują w erracie) powoduje że jedna wersja softu nie działa na danej rewizji a na drugiej "przypadkiem" działa.

    0
  • #11 15 Wrz 2018 10:51
    Freddie Chopin
    Specjalista - Mikrokontrolery

    rb401 napisał:
    Ale zauważ że w ramach testu kolega zmieniał całe otoczenie kości (p.#5) i różnica działa, nie działa dotyczyła tylko samej kostki z inną rewizją.

    Typowe "anecdotal evidence" (zresztą tak jak i moje [; ). To są układy z drobnym rastrem, nie widzę powodu dla którego dwukrotne przylutowanie pod rząd tego samego układu nie może być błędne (np. zimny lut czy zwarcie).

    Oczywiście problemy sprzętowe są możliwe (np. układ faktycznie jest uszkodzony), ale jeśli tylko nie został kupiony u chińczyków, na pchlim targu albo za "okazyjną cenę", to prawdopodobieństwo czegoś takiego jest naprawdę minimalne. Płytka nie jest zbyt cudownie zaprojektowana, ale raczej powinna działać (może nie pracować stabilnie, ale generalnie powinna się uruchamiać w większości przypadków). Jeśli się zawiesza, to wystarczy 5 minut z debuggerem żeby wiedzieć gdzie dokładnie. Jeśli nie ma debuggera, to 20 minut z diodą LED. Tymczasem tu debata trwa już pięć dni i sprowadza się do porównywania jednej beznadziejnej biblioteki (SPL) z drugą beznadziejną biblioteką (HAL).

    0
  • #12 15 Wrz 2018 11:09
    rb401
    Poziom 33  

    Freddie Chopin napisał:
    To są układy z drobnym rastrem, nie widzę powodu dla którego dwukrotne przylutowanie pod rząd tego samego układu nie może być błędne (np. zimny lut czy zwarcie).


    Osobiście mnie to nie przekonuje, bo sam lutuje takie rastry i nieraz przekładałem kostki bez żadnych problemów. Kwestia wprawy i odpowiednich narzędzi.
    Co prawda nie znam uwarunkowań kolegi norbis15 w tej dziedzinie.
    Ale wydaje mi się że jednak to co stwierdził, że jedna rewizja działa a druga nie, jest prawdopodobna i wytłumaczalna racjonalnie, choć tu akurat w tym przypadku wymagała by dalszych badań, jak proponujesz, by dojść do sedna problemu.

    0
  • #13 15 Wrz 2018 19:53
    norbis15
    Poziom 14  

    Procki zamawiałem w Łodzi... Na trzech procesorach stm32f103cbt6 z jednego zamówienia miałem ten problem, przelutowywałem je po między nową płytką a starą sprawdzoną i na nich programy StdLib za nic nie chciały wystartować (tworzyłem nawet nowe czyste projekty).
    Zakupiłem wczoraj (również w Łodzi) stm32f103c8t6 (ma mniej flash`u to może inna partia, czy w innym momencie wyprodukowany?). Zmniejszyłem w linkerze obszar flash i program działa bez problem - dziś cały dzień testuje.
    Pewnie jakbym pisał nie korzystając z bibliotek to bym nawet nie wiedział, że takie problemy mogą wystąpić i oszczędził bym sobie stresu i nie musiał kupować kolejnego procka...

    0