STM32 pracuje z połową prędkości

Atlantis snipped-for-privacy@wp.pl napisał(a):

Sprawdź jaka jest prędkość na HSI, które też ma 8 MHz.

W dniu 2021-01-25 o 23:20, Atlantis pisze:

Częstotliwość kwarcu możesz sprawdzić oscyloskopem ;)

Jestem zawsze nieufny co do kodu wygenerowanego przez CubeMX. Ja bym debuggerem sprawdził po wszystkich funkcjach inicjujących stan rejestrów decydujących o zegarze: RCC->CR RCC->CFGR i zweryfikował, czy naprawdę jest w nich to, co powinno być.

Na przykład w rejestrze RCC->CFGR jest bit PLLXTPRE, który ustawiony dzieli częstotliwość HSE przez 2. A jak dasz jako wejście PLL rezonator wewnętrzny (HSI) to tego dzielenia nie ma. Więc zmieniając HSE z HSI można się zdziwić.

W kodzie HAL powinna być zdefiniowana stała HSE_VALUE. Sprawdź, czy ma poprawną wartość (8000000). Z niej są wyliczane dalsze dzielniki.

Pozdrowienia, MKi

I jeszcze mi się przypomniało: W HAL powinna być funkcja SystemCoreClockUpdate() której działanie polega na ustawieniu zmiennej globalnej SystemCoreClock - na częstotliwość SYSCLK. Możesz tę funkcję wywołać na początku programu po funkcjach inicjujących i sprawdzić, czy w SystemCoreClock jest to co powinno być. Ta funkcja działa przy założeniu, że HSE_VALUE jest poprawne.

Pozdrowienia, MKi

Atlantis wrote on 25.01.2021 23:20:

W twoim przypadku tradycyjnie:

1. ojej, nie zauważyłem że nie przylutował się lub pomyliłem kondensator lub urwałem przewód w obwodzie oscylatora i procek pracuje na wbudowanym RC
2. ojej, załadowałem inny kod niż mi się wydawało
3. ojej, źle ustawiłem typ procesora w okienku.
4. ojej, ale tej dokumentacji dużo, nie będę czytał o konfiguracji zegara, tylko poszukam kogoś ze szklaną kulą na grupie dyskusyjnej.

Mało to razy coś się odlutuje, źle kliknie albo inaczej pomyli? Tylko ten się nie myli, kto nic nie robi.

Zakładam, że czytał, tylko utknął i skończyły mu się pomysły. Od tego jest przecież grupa.

Arnold Ziffel snipped-for-privacy@hooterville.invalid napisał(a):

Akurat to o szklanej kuli jest słuszne bo nie została wklejona ani jedna linijka kodu, nie mówiąc już o zawartości rejestrów konfiguracyjnych i statusowych.

I jak ktoś na grupie ma to wykryć? Przejrzyj historię postów Atlantisa - ludzie się produkują, rzucają pomysłami a on na koniec napisze, że pomylił wsad albo niedolutował (vide post sprzed 4 dni)

I gdzie jest opis miejsca w którym utknął?

Atlantis ma naprawdę długą historię debugowania problemów na grupie i zazwyczaj sprowadza się to do:

1. czy podłączyłeś oscyloskop do kwarcu i sprawdziłeś przebiegi? no niebardzo.
2. czy przeszedłeś w debugerze kod inicjalizacyjny dystrybucji zegara krok po kroku i sprawdziłeś czy nie zwraca błędów? też nie.
3. Czy sprawdziłeś jaka częstotliwość zegara jest brana do obliczeń prędkości UARTu? a skąd.

PS. żeby nie było, to nie mam nic przeciwko takim postom. Ale czy naprawdę ciężko jest ogarnąć kilka podstawowych kroków, zwłaszcza jeśli się popełnia podobne błędy?

Mnie tam Atlantis nie przeszkadza ... nawet popkorn wyciągam czasami. O wiele gorszy był Identyfikator_cośtam_cośtam ... ten to się dopiero naprodukował śmieci.

c.

Pewnie masz rację. Ciągle nie wiem co było przyczyną, ale lekarstwem okazało się być ponowne wygenerowanie projektu, od podstaw.

Aha. "Historię". Z przytoczonych przez ciebie przykładów bardzo luźno można by dopasować jeden - kiedy faktycznie problem ustąpił po poprawieniu lutów. Reszta to zwyczajne chochoły.

Pytałem, czy komuś nie zdarzył się podobny przypadek przy korzystaniu z STM32CubeMX bo faktycznie utknąłem. Narzędzie powinno automatycznie generować kod w oparciu o podane dane (źródło sygnału zegarowego, częstotliwość kwarcu, oczekiwana częstotliwość zegara systemowego). Jeśli uzyskanie określonej prędkości przy danej konfiguracji nie jest możliwe - pojawia się stosowny komunikat. SysTick też jest ustawiany automatycznie tak, aby przy danym taktowaniu występował co 1 ms.

Gdybym ręcznie pisał kod konfiguracyjny, to założyłbym, że faktycznie musiałem gdzieś popełnić błąd. Tutaj jednak odpowiadało za to automatyczne narzędzie, więc do jedynym wyjaśnieniem jakie przychodziło mi do głowy była albo przyczyna sprzętowa, albo bug w samym narzędziu. Bo po podaniu prawidłowej częstotliwości kwarcu (a ta był właściwa) SysTick oraz zegar na wejściu UART-a powinny zostać przeliczone, nawet gdybym przez pomyłkę ustawił gdzieś inne źródło albo inny dzielnik.

Finalnie nie mam pojęcia co było przyczyną, bo problem zniknął, gdy nie mając już żadnego pomysłu zbudowałem projekt od początku, wyklikując wszystkie opcje w czystym pliku. Nie wiem, może fakt, że projekt był założony w starej wersji SMT32CubeMX i edytowany w najnowszej miał z tym coś wspólnego?

Atlantis snipped-for-privacy@wp.pl napisał(a):

Możliwe. Niemniej gdybyś od razu podzielił się plikiem projektu i źródłami, moglibyśmy odpowiedzieć na te pytania. Tak zostaje tylko zgadywanie.