ST-Link nie widzi STM32F107RCT6

[atlantis86]

Zabrałem się właśnie za budowę jednego z urządzeń swoich projektów. Płytka wytrawiona i zlutowana, układ zasilania wytwarza właściwe napięcia. Podpiąłem więc programator celem sprawdzenia czy mikrokontroler (STM32F107RCT6) będzie przez niego wykrywany. Niestety, uzyskuję następujący wynik:

st-flash read dummy.bin 0 0xFFFF
st-flash 1.6.1-201-g4bfaab0
2021-01-22T18:15:05 WARN usb.c: NRST is not connected
2021-01-22T18:15:05 WARN common.c: Invalid flash type, please check device declaration
Failed to connect to target 

st-info --probe
Found 1 stlink programmers
  version:    V2J17S4
  serial:     483f6c06507251482938153f
  hla-serial: "\x48\x3f\x6c\x06\x50\x72\x51\x48\x29\x38\x15\x3f"
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x0000
  descr:      unknown device 

Programator jest z całą pewnością sprawny. Testowałem go na płytce BluePill oraz moim innym projekcie, z STM32F407.

Ktoś wie o co może chodzić? Od czego zacząć debugowanie?

Nie widzę żadnych oczywistych błędów w projekcie ani montażu. Nie ma zwarć, które wywalałyby bezpiecznik na wejściu. BOOT1 podłączony do masy, NRST podciągnięty do 3,3V rezystorem 10k. Układ był nowy, kupiony u zaufanego dystrybutora. Czy jest jakieś inne wytłumaczenie, poza jego uszkodzeniem?

Przychodzi mi do głowy jeszcze jedna kwestia - "kropka" na obudowie wygląda dziwnie - raczej jak ślad po wytłaczaniu, a nie typowe oznaczenie pinu 1. Innego jednak nie ma, założyłem więc, że to właściwe oznaczenie. Może jednak źle to zinterpretowałem i wlutowałem go nieprawidłowo?

[Anonim]

Ładne cacko zrobiłeś super!

Do programowania używam STM32Programmer,którego opis jest w pliku UM2237.Na razie używam portu UART do programowania ale to się zmieni gdy przyjdzie paczka ze sprzętem.Spróbuj zaprogramować przez UART  a jeśli się próba powiedzie to wrócisz do STlink-a.W tym STM32Programmer  jest coś takiego  a plik UM2237 to opisuje.

Być może trzeba wgrać nowszy firmware a ten program to oferuje i to bezboleśnie.

[atlantis86]

Wygląda na to, że winę za mój oryginalny problem ponosił źle przylutowany pin mikrokontrolera. Programator zaczął widzieć układ po ponownym przygrzaniu padów lutownicą.

Niestety, to nie koniec problemów:

1) Jestem w stanie wgrać kod z poziomu STM32CubeIDE, jednak najwyraźniej nie jest on wykonywany. Nie zmienia się nawet stan linii, które ustawiłem na początku programu. Moje pierwsze podejrzenie to błędna konfiguracja zegara, ale nie wiem co mogłoby być z nią nie tak:

2) Jak widać powyżej, konfigurację projektu (plik .ioc) stworzyłem jeszcze w STM32CubeMX, a potem wyeksportowałem go do IDE. Niestety, z jakiegoś powodu w IDE nie chce mi się otworzyć ten graficzny edytor ustawień, nie mogę więc wyklikać żadnej zmiany i wygenerować kodu na nowo. Widzę jedynie szare pole... Ktoś wie jak to naprawić?

Edytowano Styczeń 23, 2021 przez atlantis86

[Anonim]

przeczytaj stosowne rozdziały w UM1718

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[atlantis86]

10 minut temu, szymonw napisał:

przeczytaj stosowne rozdziały w UM1718

A może by tak coś więcej? Czytałem i wydaje mi się, że konfiguracja z obrazka wrzuconego wcześniej jest ok.

Jeśli wiesz co jest nie tak, to wypadałoby po prostu powiedzieć, a nie odsyłać do dość obszernej dokumentacji bez podania szczegółów.

[Elvis]

Proponuję zacząć od ustawienia HSI jako źródła taktowania, nawet bez PLL. Sama konfiguracja zegarów wygląda ok, ale jeśli z lutowaniami były problemy to może oscylator nie działa?

[atlantis86]

Spróbowałem ustawić HSI. Płytka zachowuje się dokładnie tak samo.

Gdzie jeszcze mogę szukać możliwej przyczyny? BOOT0 podłączony do masy, NRST podciągnięty d 3,3V rezystorem 10k.

Edytowano Styczeń 23, 2021 przez atlantis86

[Anonim]

Jestem na etapie tłumaczenia tego pliku,który tak naprawdę jest kursem stm32mx i jestem pod dużym wrażeniem.Dlatego proponuję by się z nim zapoznać.Z tego co widzę chodzi o radio internetowe a więc o połączenie z internetem .Twój problem może mieć rozwiązanie rozdziałle18.10."18.10 Konfiguracja Ethernet: dlaczego nie mogę określić DP83848 lub LAN8742A w niektórych przypadkach?Nie wiem czy dobrze odczytuję Twoje intencje dotyczące projektu.

[atlantis86]

25 minut temu, szymonw napisał:

Jestem na etapie tłumaczenia tego pliku,który tak naprawdę jest kursem stm32mx i jestem pod dużym wrażeniem.Dlatego proponuję by się z nim zapoznać.Z tego co widzę chodzi o radio internetowe a więc o połączenie z internetem .Twój problem może mieć rozwiązanie rozdziałle18.10."18.10 Konfiguracja Ethernet: dlaczego nie mogę określić DP83848 lub LAN8742A w niektórych przypadkach?Nie wiem czy dobrze odczytuję Twoje intencje dotyczące projektu.

Ok, źle zinterpretowałem twój komentarz. 😉 Tak, to ma być radio Internetowe z wykorzystaniem DP83848 i dekodera VS1003. Projekt zacząłem rozwijać jakiś czas temu, początkowo na na PIC24 z ENC28J60, potem przeniosłem się na PIC32 wykorzystując wbudowany interfejs RMII, aż w końcu postanowiłem zrobić (mam nadzieję) ostateczną wersję płytki z STM32, na której dokończę projekt. Wcześniejsze wersje mają uruchomiony sprzęt, więc w sumie jeśli już napiszę warstwę aplikacji, to będzie ją można w miarę łatwo przenieść na tamte płytki.

W sumie przyszła mi do głowy jeszcze jedna możliwość. W STM32CubeMX wyklikałem od razu wszystkie ustawienia dla peryferiów i pinów IO. Spróbuję je tymczasowo wyłączyć - może np. błędne ustawienie którejś linii powoduje, że inicjalizacja peryferium utyka w wiecznej pętli?

Edytowano Styczeń 23, 2021 przez atlantis86

[Anonim]

STM nakazuje dużą ostrożność w przebudowywaniu  peryferiów bo można bardzo łatwo wyłomotać  cały program.Autorzy STM32MX mówią o tym programie,że jest to programowalna grafika.Natomiast jeśli idzie o wyszarzenia  w clock cofiguration to trzeba włączyć  np.I2C a następnie przejść do clock configuratin i tam coś skonfigurować a następnie powrócić do I2c i  wypełnić tabelkę ale to wszystko znajdziesz w dokumentacji z którą należy się zapoznać.Zwracam uwagę na ustawienia zaawansowane,które są pomijane przez większość a tam możesz wiele rzeczy skonfigurować np.Zamiast bibliotek HAL  możesz zastosować biblioteki LL i ustawić rejestry Callback.

                                                      Figure 111. Advanced Settings window

Możesz też,włączyć do projektu swoje biblioteki ale to w IDE po wygenerowaniu projektu.

Edytowano Styczeń 23, 2021 przez szymonw
literówki

[slon]

4 godziny temu, atlantis86 napisał:

Nie zmienia się nawet stan linii, które ustawiłem na początku programu.

Nie wiem czy moja podpowiedź będzie pomocna ale jakiś czas temu STM8CubeMX napsuł mi trochę krwi. Nie generuje on kodu tak jak STM32CubeMX ale jest bardzo przydatny przy konfiguracji peryferiów (dostępności i ułożenia pinów). Konkretnie dla procka STM8L152 cubeMX ustawia domyślnie UARTA na POTRA. W praktyce aby mieć UARTA na na pinach PA2 i PA3 trzeba zrobić pin remapping (wystarczy przestawić jeden pit w rejestrze odpowiedzialnym za remapping) bo domyślnie czyli przy reset value UART jest na PORTC. Sprawdź czy to co generuje ci Cube jest zgodne z oczekiwanymi wartościami dla danych rejestrów.

[atlantis86]

Ok, chyba moja poprzednia hipoteza okazała się być prawidłowa. Sam mikrokontroler działa.

Dodałem sterownik Ethernet i lwIP. Urządzenie się nie zawiesza, ale po podłączeniu go do sieci lokalnej nie znajduję go też na liście w routerze. Stąd kolejne pytanie - kod wygenerowany przez STM32CubeMX wystarczy do uruchomienia stosu TCP/IP z DHCP na urządzeniu, czy trzeba jeszcze coś ręcznie dopisać?

[Anonim]

Idź do B.3.6 LwIP tego samouczka UM 1718

[atlantis86]

Trafiłem na kolejny problem. Postanowiłem uruchomić UART, żeby mieć wygodne narzędzie do debugowania w dalszych etapach uruchamiania płytki. Uruchomiłem UART1 (próbowałem także z UART3 w trybie half-duplex/transmit only) w STM32CubeMX, dodałem funkcję _write() odpowiedzialną za działanie funkcji printf(), a następnie w pętli głównej napisałem instrukcję, która powinna co 10 sekund wysyłać komunikat za pomocą printf().

Do pinu TX podłączony konwerter UART-USB, w roli terminala używam linuksowego screena, ustawionego na właściwą prędkość 115200 bps. Czyli innymi słowy coś, co robiłem wiele razy przy wielu różnych projektach. Tym razem jednak nie chce działać...

• W terminalu pojawiają się śmieci, zamiast oczekiwanego słowa "Test".
• Co prawda to moje subiektywne odczucie, bo jeszcze nie mierzyłem dokładnie, mam jednak wrażenie, że przerwa pomiędzy kolejnymi transmisjami wynosi trochę ponad 10 sekund.
• Przesyłane "śmieci" nie są losowe, wygląda na to, że za każdym razem odbieram tę samą sekwencję znaków.

Kwarc jest prawidłowy i o tej samej wartości, co ustawiona w STM32CubeMX (8 MHz). Ktoś ma pomysł co może być nie tak? 

[Anonim]

To w tym terminalu jest opcja odczytu danych i trzeba ustawić(o ile można ustawić):

1.Format HEX

2.Znacznik czasu.

Od razu będziesz wiedział co przychodzi i jakie są odstępy czasu.

3.Jeśli to co przychodzi jest nieregularne to popraw lutowania bo już raz miałeś problem.Tu proponuję Ci zrobienie dwóch przewodów do miernika zakończonych igłami.Sprawdź lutowania nóżka mikrokontrolera ścieżka  płytki.

Niestety proces uruchamiania bywa żmudny i najeżony jest wieloma niespodziankami.