ST-Link nie widzi STM32F107RCT6

[Elvis]

Ciężko jest zgadywać co może być źle nie mając przed sobą płytki, ani nawet nie widząc programu bo "nie tak" może być właściwie wszystko.

Chociaż proponowałbym zacząć od programu - jak wysyłasz dane przez ten UART?

[atlantis86]

Ok. Wygląda na to, że mam coś nie tak z taktowaniem...

Obok instrukcji wysyłającej dane przez UART dodałem też funkcję zmieniającą stan konkretnego pinu. Podpiąłem do niego analizator stanów logicznych i zmierzyłem długość impulsu - stan zmienia się co dwie sekundy, zamiast co jedną. Następnie podłączyłem analizator do do wyjścia UARTa - faktycznie widać na nim impulsy składające się na transmisję. Program rozpoznaje w nim sekwencję składającą się na słowo "Test" jednak wykrywa baudrate na poziomie 57971 - czyli z grubsza mniej więcej połowa 115200 (algorytm nie jest zbyt dokładny). Terminal odpalony na 57600 wyświetla już prawidłowy komunikt.

Wychodzi więc na to, że mikrokontroler działa dwa razy wolniej niż powinien.

Ktoś ma jakiś pomysł co do tego, co może być powodem? Użyty kwarc SMD został kupiony w TME jako kwarc 8 MHz, na obudowie ma napis "8.000", a zresztą takich samych elementów już kilka wykorzystałem w innych projektach.

Ktoś ma jakiś pomysł co do możliwej przyczyny? Możliwe, że STM32CubeMX coś namieszał w konfiguracji?

 

UPDATE: Ostatecznie nie wiem co było powodem ale okazało się, że ponowne wygenerowanie projektu usunęło tę sytuację. Nie przychodzi mi inne wyjaśnienie poza tym, że projekt został założony w starej i dawno nieaktualizowanej wersji CubeMX, a potem edytowałem go w najnowszej. Coś pewnie się rozsypało...

Edytowano Styczeń 26, 2021 przez atlantis86

[Gość]

Przyczyna jest prozaiczna i jest to napisane gdzieś w UM 1718.Gdy konfigurujesz zegar to kliknij prawym przyciskiem myszy na HCLK .Ukażą się dwie opcje Lock i Unlock.Domyślnie jest unlock.Jeśli klikniesz lock to główna częstotliwość taktowania  zostanie zablokowana.Niezablokowanie może prowadzić do niespodzianek tego typu jaki wystąpił w Twoim rozwiązaniu.