[STM32H743VIT6] Zawieszanie się podczas inicjalizacji

Witajcie,

chcę na tym wypaśnym mikrokontrolerze stworzyć generator. Jednak mam problemy z jego inicjalizacją, ponadto, pierwszy raz muszę użyć HALa.

Kod nie jest rozbudowany: w pętli nieskończonej ma migać diodą oraz generować jakiś prosty sygnał na wyjściu CH1 licznika TIM1.
Nie jest piękny, lecz chcę na razie w ogóle to uruchomić.




Dopóki jechałem na ustawieniu RCC na DeInit, wszystko działało. Problem pojawia się nie po uruchomieniu PLL (mogę wyprowadzić sygnał zegarowy na wyjście MCO i tam faktycznie odpowiada on częstotliwości 480MHz) i próbie dołączenia szyn do jego wyjścia. Testowałem różne konfiguracje preskalerów, włączać i wyłączać wbudowany LDO, na nic. Mikrokontroler zawiesza się: zrywa komunikację po SWD, dioda nie miga, TIM1 nie generuje sygnału.

Co mogę tutaj zrobić, aby zadziałał poprawnie?

Nie znam się na HALu al jak dla mnie to problem wynika z czasu dostępu do FLASH. Musisz zwiększyć te czas.

excray wrote:

Musisz zwiększyć te czas.

Zwiększyłem, próbowałem różne dostępne opcje - bez zmian. Jest to zaznaczone w moim kodzie.

Przecież w Twoim kodzie nie ma ustawiania tzw. "flash latency".

Zacytuję, jest:

Futrzaczek wrote:

HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2); //jaki Latency mam ustawić?

Chyba, że to się robi inaczej?

Nie tyle jaki, co gdzie - przed zmianą zegara.

Po pierwsze flash latency należy włączyć _PRZED_ przestawieniem zegara dla rdzenia. Po drugie - prawidłową wartość można znaleźć w dokumentacji, ale coś wątpię, żeby to było 2...

Dodano po 2 [minuty]:

Z Reference Manuala, rozdział o flash:

Freddie Chopin wrote:

Po pierwsze flash latency należy włączyć _PRZED_ przestawieniem zegara dla rdzenia.

OK, rozumiem, mea culpa. Lecz jeżeli używam wysokich preskalerów (dla SYSCLK 512 i tak dalej), to częstotliwość będzie wręcz niższa...

Zamiast się męczyć, jak już i tak używasz HAL, wygeneruj te inicjalizacje w CubeMX. Po to on jest. Potem po prostu skopiuj te funkcje inicjalizujace zegar.

Jak chcesz być HALowcem na całego to pisz tylko pomiędzy znacznikami w kodzie wygenerowany przez Cube. Wtedy ponowne generowanie po zmianie parametrów nie nadpisze Twojego kodu

osctest1 wrote:

Zamiast się męczyć, jak już i tak używasz HAL, wygeneruj te inicjalizacje w CubeMX. Po to on jest. Potem po prostu skopiuj te funkcje inicjalizujace zegar.

Ha ha.
Na Cube zawiodłem się ponownie - użył funkcji, których nie było w bibliotekach, więc kod nie mógł zostać skompilowany.
Sory, to było moje trzeci podejście do tego chłamu i trzeci raz się zawiodłem.
Więc to, co jest tutaj, to adaptacja radosnej twórczości Cube'a do tego, co jest w bibliotekach. Więcej czasu zmarnowałem niż pisząc wprost z datasheeta, którego i tak musiałem wertować poprawiając kod.

osctest1 wrote:

Jak chcesz być HALowcem na całego

Nie chcę, nie lubię, nie kocham HALa. Urodziłem się SPLowcem. Tyle, że ST nie wypuścił już SPL dla tego mikrokontrolera.

Futrzaczek wrote:

Ha ha.
Na Cube zawiodłem się ponownie - użył funkcji, których nie było w bibliotekach, więc kod nie mógł zostać skompilowany.

myślę że coś źle wyklikales:). Pokaż jakie tam masz opcję w projekcie

Przesyłam widok okna konfiguracji zegarów, okno konfiguracji projektu (tworzę w SW4STM32) jak i sam plik Cube'a.

Uploader obrazków nie działa, dodaję je jako załączniki.

Masz złą skonfigurację tego PLLa.

Nie używałem nigdy STM32H7, ale wg datasheeta wewnętrzna częstotliwość w PLL może wynosić max 836 MHz, u Ciebie jest 960 MHz.



Do tego w opisie jest o wybieraniu pomiędzy VCOL i VCOH, które mają inne wymagania częstotliwości wejściowej (twoje 8 MHz pasuje tylko do VCOH), oraz w przypadku VCOL max wewnętrzna częstotliwość PLLa jest jeszcze niższa - 420 MHz.

Moim zdaniem lepiej olej tego HALa i ustaw sobie to sam. Realnie włączenie PLLa i zmianę zegara można spokojnie zrobić w kilkunastu linijkach i to bez żadnego cudowania czy minimalizacji. Przynajmniej wtedy wiesz dokładnie co się dzieje, a my w kodzie możemy zauważyć czego ewentualnie brakuje. Teraz w zasadzie pytanie powinieneś kierować do twórców kodu HALa albo na forum ST...

Freddie Chopin wrote:

Moim zdaniem lepiej olej tego HALa i ustaw sobie to sam.

Futrzaczek: Spróbuj wygenerować zegary w LL, tę możliwość powinien mieć CUbeMX, zresztą alternatywnie CubeMX może chyba wygenerować inny kod niż szablony z SW4STM32, więc może problem sam się rozwiążę.
Gdy będziesz miał kod z LL to łatwiej odniesiesz się do RM, żeby znaleźć gdzie popełniłeś błąd.

Inny problem to czy zadbałeś dobrze o sekcję zasilania. Wg moich doświadczeń najwyższy zegar "nie ruszy" jeśli nie będziesz miał Vcap,ów.

0. Proponuję sprawdzić rewizję układu na płytce. Tylko układy z rewizją V mogą pracować do 480 MHz. Starsze (np. Y) pracują do 400 MHz. Znoszą jakoś niewielkie przekroczenie zakresu (420 MHz), ale 480 MHz nie tolerują. Sprawdzałem
1. Zasilanie musi być solidne. STM32H743xI_DS Sekcja 7.1.6.
2. Zmiana taktowania wymaga postępowania zgodnie z procedurą opisaną w RM. Ja sprawdzam czy nowa częstotliwość jest równa, wyższa, niższa od aktualnej.
Jeżeli taka sama, to nic nie zmieniam.
Jeżeli wyższa, to zmieniam zasilanie (VOS), aktualizuję WS, czekam na gotowość WS i VOS, przełączam taktowanie na nowe źródło.
Jeżeli niższa, to przełaczam taktowanie na nowe źródło, aktualizuję WS i zasilanie, czekam na gotowość i melduję wykonania zadania
Jeżeli trzeba zmienić ustawienia PLL, to przełączam się tymczasowo na sensowne źródło, najczęściej HSI64. PLL nie można przekonfigurować w locie.

@Freddie Chopin Odwołujesz sie do parametrów rewizji Y (czyli 400 MHz max). Nowsze wersje mają kilka usprawnień i dlatego mogą pracować do 480 MHz, dlatego ważne jest sprawdzenie rewizji układu.

Marek_Skalski wrote:

@Freddie Chopin Odwołujesz sie do parametrów rewizji Y (czyli 400 MHz max).

Wszystko co wrzuciłem wyżej jest z najnowszego RM ściągniętego dziś ze strony [;

To jest ta sytuacja, gdy każdy z nas może mieć rację.
Porównaj proszę rodział 7, sekcja 7.3.10, tabela 147 z rozdział 6, sekcja 6.3.10, tabela 50.
Od czasu wprowadzenia 2-rdzeniowych H7, wszystkie układy pracują z wyższą częstotliwością. Nigdy nie wiadomo jak długo układ leżał w magazynie, dlatego trzeba sprawdzać rewizję układu; albo wzrokowo na obudowie, albo odczytując w programie sygnaturę.

Spróbuj obniżyć częstotliwość maksymalną o jakieś 20%. Niestety ja to zjawisko też zaobserwowałem. Co prawda na procesorze STM32F413RH. Przy ustawieniu zegara na 100MHz (maksymalnie) "program" w postaci pustej pętli działał kilka sekund, a później wszystko zdychało. Obniżyłem zegar do 92MHz i problem zniknął. Moje wrażenie jest takie, że z chwilą wprowadzenia "oszczędzania energii na siłę" nie wszystko poszło tak jak trzeba. Albo nie do końca dokładnie zostało opisane na co trzeba zwrócić szczególną uwagę (np. rejestr PWR i bity VOS).
Cube się zwykle pruje (na bordowo) jak się przekroczy ograniczenia pętli PLL. Ale po przeczytaniu tego wątku sprawdziłem i na pewno w moim przypadku nie przekraczam zakresów.

Zainteresowałeś mnie tym opisem.
Sprawdzamy dokumentację, a tam jest zapis:

RM0430_rev.8 wrote:

After reset the VOS register is set to scale 2. When the PLL is OFF, the voltage regulator is set to scale 3 independently of the VOS register content. The VOS register content is only taken into account once the PLL is activated and the HSI or HSE is selected as clock source.

STM32F41x3_G/H wrote:

Table 17. General operating conditions
Power Scale2: Regulator ON, VOS[1:0] bits in PWR_CR register = 0x10 -> fHCLK (Max) = 84 MHz

Z tego zgaduję, że nie włączyłeś trybu 3 w regulatorze zasilania. Obniżenie prędkości do 92 MHz to tylko przypadkowo działające rozwiązanie. Zgodnie z dokumentacją powinno to być najwyżej 84 MHz.
Jeżeli układ zamiera po kilku sekundach, to albo jest problem z zasilaniem, albo ląduje w HF na skutek błędu programowego.
Zainteresowałem się tym, ponieważ nie spotkałem jeszcze żadnego STM32, który nie osiąga parametrów deklarowanych przez producenta, a Ty postawiłeś dość śmiałą tezę, że producent kłamie w dokumentacji.

Czy pamiętałeś o zainicjowaniu wszystkich pól struktur dla HAL? Coś mi się widzi, że ustawiasz tylko niektóre, a pozostałe mają wartości losowe.

Dziękuję za odpowiedzi.
W kodzie, który wrzuciłem, próbuję uruchomić szyny z HSI, nie z PLL i to z preskalerami. Próbowałem z PLL, próbowałem z HSE (bez włączania PLL), na nic.
Samo PLL generuje poprawnie (IMHO) skoro na MCO mam sygnał odpowiadający, po przeskalowaniu, 480MHz. Ale mogę to zmniejszyć i sprawdzić.

BlueDraco wrote:

Czy pamiętałeś o zainicjowaniu wszystkich pól struktur dla HAL?

Nigdy wcześniej nie używałem HAL, więc to bardzo prawdopodobne.
Tutaj uruchamiam zegar dla szyn, wcześniej konfigurując strukturę:

Futrzaczek wrote:

HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2); //jaki Latency mam ustawić?

Przejrzałem biblioteki HALowskie i nie widzę, bym o czymś zapomniał. Chyba, że...?