STM32F103RET6 - Debugger traci połączenie, TCK pin LOW zamiast HIGH

Witam,

mam PCB na której leży sobie STM32F103RET6. Układ działa.
Szopki są tylko przy debuggowaniu: podłączam debugger, włączam zasilanie układu, klikam w keilu "debug" i debuguję sobie w najlepsze przez parę chwil (10s..5m). Po pewnym losowym czasie debugger traci połączenie z prockiem, możnaby powiedzieć, że prawie bezpowrotnie. Nie dotykając nic po wywaleniu, po prostu próbuję łączyć się z procem jeszcze raz. Efekt? Nie widzi go, bo "TCK pin is LOW, but should be HIGH". Mierzę oscylem - faktycznie jest LOW...
Bywa, że pomaga przełączenie debuggera w "connect under reset", lub przecyklowanie zasilania, lub wielokrotne przecyklowanie zasilania, lub odłączenie i podłączenie USB od debuggera, lub kombinacje powyższych. Bywa, że nic nie pomaga - już jeden taki procesor istnieje, który DZIAŁA, ale debug ni cholerę...

Co ciekawe, problem występuje tylko z tym konkretnym modelem procesora. Na różnych płytkach, wykonując różne kody.
Mój debugger współpracował już z różnymi mikrokontrolerami, małe LPC, duże LPC, różne STM32 z serii performance (głównie F103RBT6,F103CBT6,F103ZET6), i nigdy nie występowały takie problemy.

Debugger dziala na pewno, bo podłączony do układu z innym modelem procesora wszystko jest OK.
Kod na pewno nie kombinuje przy konfiguracji pinów odpowiedzialnych za SWD; postawiłem pułapkę na pamięć GPIOA->CRH i AFIO->MAPR. Na 100% nic nigdy nie dotyka tych rejestrów (poza chamskim initem który wykonuje sie od razu przy starcie programu).

Zaczynam podejrzewać, że to po prostu ten konkretny model procesora ma jakieś ukryte wady...

Procesor: STM32F103RET6
Interfejs: SWD
Piny SWD i SWC: floating digital input
Debugger: Oryginalny segger j-link
Srodowisko: Keil mdk-arm

Ciekawa sprawa. Żeby wykluczyć błędy Keila lub tego konkretnego mikrokontrolera, proponuję zrobić test debugowania w jakimś alternatywnym środowisku np. IAR. Zwykle udostępniają do testów wersję 30-dniową.

Heh... w dokładnie tą samą płytkę został wyrzucony F103RET6 a w jego miejsce poszedł F103RBT6. Problem magicznie znikł. Więc to na pewno nie wina pcb, zasilania czy zakłóceń...

A próbowałeś np. ten sam typ procesora tylko, że inny podłączyć? Miałem kiedyś inny problem na STM32F103VET6, używałem jednego pwm'a oraz usarta. Program wgrany do jednego procka pwm działa nie chodzi usart, program wgrany do następnego wszystko ok i działa jak należy. Żadnych zmian w kodzie, a sama errata nie wiedziała nic na ten temat. Może to po prostu kwestia jakiś bugów jeszcze nie opisanych w erratach.

Skoro używasz komercyjnego środowiska i full wypas debugera i jesteś osobą prowadzącą działalność (firmą) to może skorzystaj z ich supportu ? Mogło się zdarzyć, że panowie piszący soft czegoś nie przewidzieli, zapomnieli, pomylili się.
Panuje twierdzenie, że jeżeli firma ma renomę, np taki Texas Instruments etc. to produkty, które tworzą, są pozbawione wad. Przecież tam pracują tacy sami ludzie jak ja czy mój sąsiad i mają takie same prawa do pomyłek.

gaskoin napisał:

Panuje twierdzenie, że jeżeli firma ma renomę, np taki Texas Instruments etc. to produkty, które tworzą, są pozbawione wad. Przecież tam pracują tacy sami ludzie jak ja czy mój sąsiad i mają takie same prawa do pomyłek.

Ale z tym to już poszaleli
Stellaris - czyli jak sie teraz produkuje procesory

Ja sugeruję sprawdzić na starszej wersji Keila lub testowe użycie ULINKA (generalnie na innych driverach).
To co fachowcy z Keila wyprawiają z driverami do debuggerów to jest kosmos. Ja używam STLinka i niestety kiedyś miałem spory problem z załadowaniem nieciągłego kodu do pamięci (mam plik "scater" i nie korzystam z "pomagaczy" okienkowych z menu). Zapisywała się tylko pierwsza strona a później wszystko było OK do chwili uruchomienia programu (okazało się, że części programu nie ma w pamięci a problem był w tym, że algorytm nie kasował części stron pamięci, którą później próbował zapisać). Problem nie stanowił STlink bo narzędziem z ST wszystko się zapisywało bez problemu. Tylko z poziomu Keila były cyrki. Mało tego zrobiłem wcześniej własny debugger COOCOX i zachowywał się identycznie. A teraz najlepsze. Wysłałem zapytanie do Keil'a (produkt zakupiony i powinien mieć support) i "fachowcy" stwierdzili, że to nie ich problem tylko drivery z ST są "nie takie" a ST nabrało wody w usta i koniec sprawy. Nie chciało mi się dalej walczyć.
Natomiast nie mam żadnych zastrzeżeń co do kompilatora zaszytego w Keil'u. Działa tak jak trzeba.
Oczywiście wszystko nie znaczy, że procesor nie ma jakiegoś błędu (mało prawdopodobne ale...)
Ogólnie ST zaliczyło też ostatnio wpadkę z innym układem scalonym. Sprawdziłem działanie na próbkach i napisałem żeby sobie opis położyli na półkę bo 1/3 nie odpowiada temu co piszą. A układ działał w pewnych warunkach dość nieprzewidywalnie. Zrobił się tygodniowy dym (dystrybutor się przestraszył bo miał zapas magazynowy) i teraz cisza bo jeszcze nikt układu nie kupi i zostaną z ręką w nocniku.

kemot55 napisał:

Ogólnie ST zaliczyło też ostatnio wpadkę z innym układem scalonym. Sprawdziłem działanie na próbkach i napisałem żeby sobie opis położyli na półkę bo 1/3 nie odpowiada temu co piszą.

Możesz napisać który? Używałem STM32F103VCT6, w którym I2S nie działa prawidłowo w trybie slave. W nowym projekcie planuję wykorzystać STM32F405.

ST produkuje poza STM32 też wiele innych układów.
Generalnie nie pisałem o procesorze tylko o układzie zabezpieczającym przez zwarciem i przeciążeniem (sam zobacz czym się ostatnio bardzo chwali ST w tym zakresie). Układ całkiem sprytnie zaprojektowany tylko jest jakieś niedomówienie/niedopisanie/"mały druczek" albo coś....i użytkownikowi zostaje poletko pod tytułem "domyśl się sam"