Elektroda.pl
Elektroda.pl
X
PCBway
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[STM32] [OpenOCD] Problem z debuggerem

21 Lis 2010 00:15 3755 20
  • Poziom 14  
    Witam!

    Posiadam mikrokontroler STM32F107, czyli Connectivity.

    Chce się z nim połączyć poprzez debugger/programator JTAG. Plik konfiguracyjny interfejsu debuggera w OpenOCD jest ustawiony na typ debuggera Amontec JTAGkey, natomiast plik konfiguracyjny procesora na stm32.cfg.

    Po połączeniu układów poprzez OpenOCD dostaję następujące komunikaty:
    Code:
    Info : clock speed 1000 kHz
    
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
    Warn : Unexpected idcode after end of chain: 64 0x00000000
    Warn : Unexpected idcode after end of chain: 96 0x00000000
    Warn : Unexpected idcode after end of chain: 128 0x00000000
    Warn : Unexpected idcode after end of chain: 160 0x00000000
    Warn : Unexpected idcode after end of chain: 192 0x00000000
    Warn : Unexpected idcode after end of chain: 224 0x00000000
    Warn : Unexpected idcode after end of chain: 256 0x00000000
    Warn : Unexpected idcode after end of chain: 288 0x00000000
    Warn : Unexpected idcode after end of chain: 320 0x00000000
    Warn : Unexpected idcode after end of chain: 352 0x00000000
    Warn : Unexpected idcode after end of chain: 384 0x00000000
    Warn : Unexpected idcode after end of chain: 416 0x00000000
    Warn : Unexpected idcode after end of chain: 448 0x00000000
    Warn : Unexpected idcode after end of chain: 480 0x00000000
    Warn : Unexpected idcode after end of chain: 512 0x00000000
    Warn : Unexpected idcode after end of chain: 544 0x00000000
    Warn : Unexpected idcode after end of chain: 576 0x00000000
    Warn : Unexpected idcode after end of chain: 608 0x00000000
    Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
    Warn : Unexpected idcode after end of chain: 64 0x00000000
    Warn : Unexpected idcode after end of chain: 96 0x00000000
    Warn : Unexpected idcode after end of chain: 128 0x00000000
    Warn : Unexpected idcode after end of chain: 160 0x00000000
    Warn : Unexpected idcode after end of chain: 192 0x00000000
    Warn : Unexpected idcode after end of chain: 224 0x00000000
    Warn : Unexpected idcode after end of chain: 256 0x00000000
    Warn : Unexpected idcode after end of chain: 288 0x00000000
    Warn : Unexpected idcode after end of chain: 320 0x00000000
    Warn : Unexpected idcode after end of chain: 352 0x00000000
    Warn : Unexpected idcode after end of chain: 384 0x00000000
    Warn : Unexpected idcode after end of chain: 416 0x00000000
    Warn : Unexpected idcode after end of chain: 448 0x00000000
    Warn : Unexpected idcode after end of chain: 480 0x00000000
    Warn : Unexpected idcode after end of chain: 512 0x00000000
    Warn : Unexpected idcode after end of chain: 544 0x00000000
    Warn : Unexpected idcode after end of chain: 576 0x00000000
    Warn : Unexpected idcode after end of chain: 608 0x00000000
    Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
    Command handler execution failed
    Warn : jtag initialization failed; try 'jtag init' again.


    Czy w ogóle debugger łączy się z procesorem? Chyba tak skoro wykrywa go poprzez wpisy:
    Code:
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    
    Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
    ?

    Po tym error oczywiście całość już nie działa. Co może być nie tak? Czy może być to spowodowane?

    UPDATE:

    Sprawdziłem jeszcze jak wyglądają połączenia między interfejsem JTAG a mikrokontolerem (korzystam z płytek ewaluacyjnych).

    Linie, z których korzystam:

    TRST_N - podciągnięte do +3.3V opornikiem 10kOhm
    TDI - podciągnięte do +3.3V opornikiem 10kOhm równolegle z opornikiem 10kOhm
    TMS - podciągnięte do +3.3V opornikiem 10kOhm równolegle z opornikiem 10kOhm
    TCK - podciągnięte do GND opornikiem 10kOhm równolegle z opornikiem 10kOhm
    TDO - podciągnięte do +3.3V opornikiem 10kOhm równolegle z opornikiem 10kOhm
    SRST_N - bezpośrednie połączenie JTAG - mikrokontroler.

    Btw, na stronie Olimex: Schemat układu STM32 linia TCK jest podłączona inaczej niż u mnie, do +3.3V. Czy to może powodować takie błędy (co prawda tam jest układ STM32F103, ale to chyba niewielka różnica)?

    Te równoległe połączenia wynikają z konstrukcji samych płytek. Czy takie połączenia równoległe mogą mieć wpływ na wypisane powyżej błędy? Same połączenia są chyba dobre (czy np. ta linia TCK powinna inaczej być podłączona)?

    Dzięki
  • PCBway
  • Specjalista - Mikrokontrolery
    W STM32 rezystory pull-up / -down są w ogóle nie potrzebne, za to brak jakiegokolwiek rezystora na linii resetu raczej nie jest normalny...

    Czy jesteś pewny, że JTAG i / lub płytka są sprawne?

    Możesz spróbować do wywołania OpenOCD dodać:

    -c "reset_config trst_and_srst srst_push_pull"

    Jaka to wersja OpenOCD?

    4\/3!!
  • Poziom 14  
    Dzięki za odpowiedź!

    Sprawdziłem jeszcze raz schematy, linia Resetu też jest podciągnięta do +3.3V poprzez rezystor 10kOhm i poprzez kondensator 100uF do GND.

    Co do płytki z procesorem to jest to gotowa płytka, sprawdzałem wgrywając programy poprzez Bootloader (przez USART) i wszystko działa dobrze.

    Nie wiem natomiast jak dobrze sprawdzić debugger JTAG? Podłączałem go bez żadnego układu i uruchamiałem OpenOCD tylko z plikiem dotyczącym interfejsu, ale nie wiem czy w ten sposób można sprawdzić układ JTAG (dostaję błąd typu "All ones" oraz "Autoprobing might not work", jeśli OpenOCD jest włączone w ten sposób i nie jest JTAG podłączony do żadnego układu).

    Co do wersji OpenOCD jest to 0.4. Spróbowałem tak jak mówisz, zmienić ten reset, jednak nic to nie daje. Chyba wszystkich kombinacji próbowałem z resetm, łącznie z wykasowaniem z stm32.cfg linii Reset_config. Jednak nic nie zmienia się w tym co wypisuje OpenOCD (tak jak powyżej).

    Jak można sprawdzić jeszcze ten JTAG? Czy układy w ogóle się komunikują (np. czy to jest efekt komunikacji: Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) ?)

    Dzięki
  • PCBway
  • Specjalista - Mikrokontrolery
    Możesz spróbować tym programikiem (będziesz musiał przeinstalować sterowniki na ftd2xx) sprawdzić JTAGa.
    https://www.elektroda.pl/rtvforum/viewtopic.php?p=7861499#7861499

    Jak masz skonfigurowane piny BOOT0 i BOOT1?

    Jaki program siedzi w mikrokontrolerze? Jeśli program robi jakieś dziwne rzeczy (włącza tryby uśpienia, wyłącza JTAGa), to może powodować problemy.

    Przetestuj najnowszą rozwojową wersję OpenOCD z mojej strony http://www.freddiechopin.info/index.php/pl/download/category/10-openocd-dev

    Spróbuj zainstalować najnowsze sterowniki (te w paczce z rozwojowym OpenOCD są dosyć nowe - więc jeśli masz jakieś prehistoryczne, to możesz ich spróbować).

    4\/3!!
  • Poziom 14  
    Dzięki za odpowiedź!

    Co do pinów BOOT:
    BOOT0 - przy JTAG podłączam do GND
    BOOT1 - przez rezystor 10kOhm do GND podłączone na stałe.

    Program wgrany na mikrokontroler to przykładowy serwer WWW .

    Co do OpenOCD, nie dodałem, że używam Linux Ubuntu do pisania oprogramowania (nie do wgrywania obecnie :) ). U Ciebie na stronie są chyba tylko kompilacje pod Windows? Gdzie można znaleźć wersję 0.5 pod Linux (ponieważ na stronie oficjalnej chyba tylko jest wersje 0.4 dostępna)?

    Co do samych sterowników, to wgrałem biblioteki libusb i libftdi-dev z menedżera pakietów Synaptic, więc pewnie są w miarę nowe (choć pewnie nie najnowsze).

    Cytat:
    Możesz spróbować tym programikiem (będziesz musiał przeinstalować sterowniki na ftd2xx) sprawdzić JTAGa.

    Mówisz o OpenOCD czy dałeś jakiś link?

    Dzięki

    UPDATE:

    Wgrałem jeszcze proste oprogramowanie zamiast tego serwera, które wysyła dane przez USART (i tylko to), ale efekt z JTAG jest identyczny jak był wcześniej.
  • Specjalista - Mikrokontrolery
    Peef napisał:
    Co do OpenOCD, nie dodałem, że używam Linux Ubuntu do pisania oprogramowania (nie do wgrywania obecnie :) ). U Ciebie na stronie są chyba tylko kompilacje pod Windows? Gdzie można znaleźć wersję 0.5 pod Linux (ponieważ na stronie oficjalnej chyba tylko jest wersje 0.4 dostępna)?

    Rozwojowe wersje możesz ściągnąć z git - http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=summary i potem skompilować.

    Cytat:
    Cytat:
    Możesz spróbować tym programikiem (będziesz musiał przeinstalować sterowniki na ftd2xx) sprawdzić JTAGa.

    Mówisz o OpenOCD czy dałeś jakiś link?

    Miał być link, ale zapomniałem [; Już poprawiłem, ale to też tylko pod Windowsa programik /;

    Swoją drogą pod Linuxem jest dużo zabawy w udev jeśli chcesz uruchomić OpenOCD, ale to chyba nie Twój problem, bo u Ciebie częściowo działa...

    Nie mam pomysłów ); Możesz zawsze włączyć maxymalny poziom komunikatów (-d 3) - może wtedy coś ciekawego się w logu ukaże.

    4\/3!!
  • Poziom 38  
    Nie trzeba się bawić w udev, jedynie co to dodać linijkę odpowiedzialną za dostęp do urządzenia, żeby nie musieć logować się na roota za każdym razem jak chcemy debugować. Jaja w nowym jądrze (!) wynikały z tego, że sterowniki ftdi ładowane do jądra "nie wiedziały", że urządzenie o podanym vid i pid to urządzenie oparte na ftdi i trzeba było im to jawnie powiedzieć :P (wtedy działał też UART, przy cudowaniu z dodawaniem na chama urządzeń i innych obejściach działa jedynie JTAG).

    Dla porządku napiszę raz jeszcze:

    Ze strony http://developer.berlios.de/project/showfiles.php?group_id=4148 ściągamy paczkę zawierające najnowsze OpenOCD w formie źródeł. Rozpakowywujemy sobie to gdzieś, odpalamy konsolę, wchodzimy do katalogu gdzie rozpakowaliśmy openOCD i wklepujemy

    Code:
    ./configure --enable-ft2232_libftdi
    
    make
    make install


    Nie wiem tylko czy nie trzeba tego dokonywać na roocie. Po tej operacji będziemy mieli zainstalowane OOCD w naszym systemie, pozostaje więc jedynie zadbać o to żeby mieć w systemie odpowiednie biblioteki. Znowu odpalamy konsolę:

    Code:
    sudo apt-get install libftdi-dev


    Po tym zabiegu jeszcze zostanie nam utworzenie pliku w /etc/udev/rules.c o nazwie np 45-harware.rules (forma xx-nazwa.rules musi być zachowana, xx to priorytet reguły, czym niższy tym wyższy i świadczy jedynie informację dla systemu, w jakiej kolejności system ma je wykonywać), żeby nie musieć za każdym razem do debuggingu logować się na roota i ręcznie wklepywać ładowanie modułu jądra. Treść tego pliku powinna wyglądać następująco:

    Code:
    #reguly dla jtaga
    
    ATTR{idVendor}=="0403", ATTR{idProduct}=="cff8" MODE="666", RUN+="/sbin/modprobe ftdi_sio product=0xcff8 vendor=0x0403", GROUP="gaskoin"


    zamiast "gaskoin" wpiszcie swoją grupę, żeby nie cudować z dodawaniem siebie do innych grup. Powyższy plik reguły jak i jego treść należy oczywiście tworzyć jako root ponieważ system generalnie zabrania zwykłemu użytkownikowi grzebania w /etc.To tyle, powinno już normalnie wszystko śmigać. Rzecz jasna jest to wpis dla jtagkey albo Choppinowego jtaglockpick, ale oczywiście dla innych układów też powinno działać. Trzeba jedynie przeczytać README do oocd żeby wiedzieć jakich opcji kompilacji użyć, aby włączyć obsługę odpowiednich JTAGów
  • Poziom 25  
    gaskoin napisał:
    Dla porządku napiszę raz jeszcze:
    [...]
    Code:
    ./configure --enable-ft2232_libftdi
    
    make
    make install


    Nie wiem tylko czy nie trzeba tego dokonywać na roocie. [...]

    Jako root trzeba wykonać tylko ostatnie polecenie "make install" jeżeli nie zmieniona domyślna ścieżka instalacji skryptem configure.

    gaskoin napisał:
    [...]
    Code:
    sudo apt-get install libftdi-dev

    [...]

    Proponował bym to polecenie wykonać przed konfigurowaniem i kompilowaniem źródeł openocd.
  • Poziom 38  
    Hmm racja, zapomniałem, że już na etapie kompilacji oocd wymaga bibliotek ftdi :)
  • Poziom 14  
    Dzięki za odpowiedzi!

    Zainstalowałem najnowszą wersję OpenOCD v0.5.

    Trochę zmieniły się komunikaty, jednak błąd jest cały czas podobny...

    Poniżej wklejam treść:
    Code:
    Info : only one transport option; autoselect 'jtag'
    
    1000 kHz
    adapter_nsrst_delay: 100
    jtag_ntrst_delay: 100
    Info : clock speed 1000 kHz
    Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
    Info : JTAG tap: stm32.bs tap/device found: 0x06418041 (mfg: 0x020, part: 0x6418, ver: 0x0)
    Warn : Unexpected idcode after end of chain: 64 0x00000000
    Warn : Unexpected idcode after end of chain: 96 0x00000000
    Warn : Unexpected idcode after end of chain: 128 0x00000000
    Warn : Unexpected idcode after end of chain: 160 0x00000000
    Warn : Unexpected idcode after end of chain: 192 0x00000000
    Warn : Unexpected idcode after end of chain: 224 0x00000000
    Warn : Unexpected idcode after end of chain: 256 0x00000000
    Warn : Unexpected idcode after end of chain: 288 0x00000000
    Warn : Unexpected idcode after end of chain: 320 0x00000000
    Warn : Unexpected idcode after end of chain: 352 0x00000000
    Warn : Unexpected idcode after end of chain: 384 0x00000000
    Warn : Unexpected idcode after end of chain: 416 0x00000000
    Warn : Unexpected idcode after end of chain: 448 0x00000000
    Warn : Unexpected idcode after end of chain: 480 0x00000000
    Warn : Unexpected idcode after end of chain: 512 0x00000000
    Warn : Unexpected idcode after end of chain: 544 0x00000000
    Warn : Unexpected idcode after end of chain: 576 0x00000000
    Warn : Unexpected idcode after end of chain: 608 0x00000000
    Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
    Error: Trying to use configured scan chain anyway...
    Error: IR capture error at bit 9, saw 0x0011 not 0x...3
    Warn : Bypassing JTAG setup events due to errors
    Info : stm32.cpu: hardware has 109 breakpoints, 2 watchpoints
    Error: stm32.cpu -- clearing lockup after double fault
    Error: stm32.cpu -- clearing lockup after double fault
    Error: stm32.cpu -- clearing lockup after double fault
    Error: stm32.cpu -- clearing lockup after double fault
    Error: stm32.cpu -- clearing lockup after double fault
    Error: stm32.cpu -- clearing lockup after double fault
    Error: stm32.cpu -- clearing lockup after double fault (ten wpis jest cały czas powtarzany

    Z tego by wynikało, że jest jakaś komunikacja, ale ten kod IR jest nie taki jakby OpenOCD chciało?
    Code:
    Error: Trying to use configured scan chain anyway...
    
    Error: IR capture error at bit 9, saw 0x0011 not 0x...3


    Jeśli dalej nie będzie to działać, to chyba zmienię debugger. Na Allegro jest JTAG Segger J-Link. Czy z tym debuggerem nie ma problemów pod OpenOCD?

    Przy okazji zapytam jeszcze, czy jest jakaś inna możliwość programowania tego procesora prócz JTAG i Bootloader?

    Dotychczas wgrywam programy przez USART (Bootloader), tylko tam trzeba ciągle zmieniać pin Boot0, w zależności od tego czy chce się korzystać ze swojego programu czy też wgrywać oprogramowanie (opcja Jump to User program działa chyba tylko podczas programowania, a po resecie znowu jest włączany bootloader)? Przez JTAG jest chyba najwygodniej programować mikrokontroler.

    Dzięki
  • Poziom 38  
    Tylko Jtag albo bootloader, inaczej się nie da
  • Specjalista - Mikrokontrolery
    Peef napisał:
    Z tego by wynikało, że jest jakaś komunikacja, ale ten kod IR jest nie taki jakby OpenOCD chciało?

    Jest problem z komunikacją. Ja stawiałbym na coś fizycznego.

    Cytat:
    Jeśli dalej nie będzie to działać, to chyba zmienię debugger. Na Allegro jest JTAG Segger J-Link. Czy z tym debuggerem nie ma problemów pod OpenOCD?

    LOL (; Pomijając fakt, że z J-Linkiem jest więcej problemów "ogólnie" (bo to zamknięty projekt komercyjny, a nie otwarte i proste FT2232), to z tym "J-Linkiem" (bo chyba nie wierzysz, że to oryginał) z allegro są bonusowe problemy - https://www.elektroda.pl/rtvforum/topic1794179.html

    Prawda jest taka, że OpenOCD i JTAG oparty na FT2232 (czyli np Twój) to jest najwygodniejsza i najpewniejsza (moim zdaniem) kombinacja, która działa "po prostu" - bez kombinacji. Wciąż nie pochwaliłeś się jakiego dokładnie masz JTAGa, czy jest to oryginalny JTAGkey, czy może klon, albo klon robiony samodzielnie? Jeśli któryś z dwóch ostatnich przypadków, to moja praktyka wskazuje, że w 99% przypadków problemem jest źle zlutowany JTAG i / lub układ docelowy.

    4\/3!!
  • Poziom 14  
    Dzięki za odpowiedzi!

    Debugger JTAG ostatnio sprawdzałem na innym układzie (STM32F103). Wszystko działało dobrze z OpenOCD, więc chyba debugger jest ok. Próbowałem też podłączyć do swojego układu (STM32F107) inny debugger (na pewno działający, w OpenOCD działa na layout usbprog) i błąd był taki sam jak wcześniej napisałem, a nawet nie wykrywał procesora (bity były chyba przesunięte).
    Btw, w wersji OpenOCD 0.5 korzystam z plików jtagkey.cfg oraz stm32.cfg (dostarczonych z tą wersją oprogramowania).

    Co do J-Link to czytałem to wszystko :) , dzięki za informację. Ale chyba jednak to nie jest kwestia mojego debuggera.

    Co do płytek, z których korzystam to płytka z procesorem to moduł firmy Propox MMstm32F107, natomiast debugger JTAG to And-Tech JTAG-ARM USB v2.

    Ostatnio czytałem jeszcze dokumentację STM32. Pomijając fakt, że w sumie zewnętrzne rezystory podciągające do JTAG są niepotrzebne to tak naprawdę linie, które wymagają podciągania to: TDI, TMS i nTRST (wg. standardu JTAG). Nie ma rekomendacji co do TCK (ale w sumie połączenie na płytce jest dobre, bo w STM32 jest pull-down zintegrowany, czyli na płytce połączenie też jest ok).
    Jednak wydaje mi się, że podciąganie linii TDO jest nieprawidłowe, ponieważ nie posiada żadnego zintegorowanego rezystora podciągającego, złącze jest jest określone w dokumentacji jako INPUT FLOATING. Dalej napisane, że jest to złącze typu "tristate", czyli stosując tam jakiekolwiek podciąganie nie ma już właściwości "tristate" (strona 1031 i 1032 z RM0008). Może wylutować z płytki ten rezystor od TDO?

    Btw, sprawdzałem poprawność połączeń między złączem JTAG oraz bezpośrednio mikrokontrolerem (czy może są niedolutowane), ale wszystko jest ok. :)

    Dzięki
  • Poziom 21  
    Witaj,

    Coś mi się nie podoba ta linijka

    Cytat:
    Info : stm32.cpu: hardware has 109 breakpoints, 2 watchpoints


    Ten procek nie ma tylu hardwarowych breakpointów z tego co pamiętam ma ich 8.

    W jakim programie kompilujesz i skąd aż 109 breakpointów ??

    Pozdrawiam
  • Specjalista - Mikrokontrolery
    Rezystory na liniach JTAGa jak dla mnie w niczym nie przeszkadzają, chyba że wymagany byłby konkretny stan konkretnego pinu po resecie aby włączyć JTAG.

    Skoro płytka nie działa z żadnym JTAGiem, to może jednak coś z nią jest nie tak? Zerknij do schematów innych modułów z takimi układami to zobaczysz jak tam to jest zrobione (chodzi o dołączenie JTAGa) - np moduł z Kamami STM32 Butterfly działa z OpenOCD i JTAGami na FT2232 bez problemu.

    4\/3!!
  • Poziom 14  
    Dzięki za odpowiedzi.

    @flapo213:

    Chodzi o kompilację samego programu? Korzystam z Eclipse z kompilatorem CodeSourcery G++. Nie wiem dokładnie co to są te breakpointy? To takie zwyczajne jak przy debuggowaniu? :) Czy np. interrupt'y procesora? Może to właśnie przez błędy transmisji danych?

    @Freddie Chopin:

    Cytat:
    Rezystory na liniach JTAGa jak dla mnie w niczym nie przeszkadzają, chyba że wymagany byłby konkretny stan konkretnego pinu po resecie aby włączyć JTAG.

    Ale czy stosując rezystor podciągający na właśnie linii TDO nie rezygnuje się z trzeciego stanu, który powinien być na złączu, czyli high-Z? I może dlatego są błędy typu unexpected IDCODE 0x0000, bo zamiast np. przełączyć się w high-Z to procesor trzyma linię na GND (rezystor podciągający) i tak wygląda wtedy transmisja tych danych (układ STM32 nie kończy transmisji danych)?

    Płytka, z którą sprawdzałem JTAG w ogóle nie miała żadnych rezystorów podciągających, jedynie chyba konwertery albo bufory napięciowe i nic więcej w JTAG.

    Co do zestawu Kamami, który podałeś, to stosują tylko rezystory podciągające na liniach TMS (+3.3V) i TCK (GND), czyli tak samo. W zestawie ZL30ARM jest tylko jeden rezystor TMS. Ale np. na płytce STM3210C-EVAL/STM z STM32F107 już mają komplet tych rezystorów na wszystkich liniach.

    Dzięki
  • Specjalista - Mikrokontrolery
    Zawsze możesz go wylutować, ale wątpię aby to coś dało.

    Jeśli miernikiem sprawdzałeś połączenia, to miej świadomość tego, że gdy przykładasz sondę do nóżki układu, to dociskasz ją jednocześnie do pada - jeśli była tam przerwa, to w tym momencie może jej już nie być. Sprawdź też czy linie nie są pozwierane między sobą i/lub szynami zasilania.

    4\/3!!
  • Poziom 21  
    Witaj,

    Czym podmieniasz oprogramowanie w tym procku. Openocd jtagiem czy uartem itd.

    Wogóle to dasz radę zaprogramować procka z użyciem openocd czy tylko debug Ci nie działa.

    Pozdrawiam
  • Poziom 21  
    Freddie Chopin napisał:
    W STM32 rezystory pull-up / -down są w ogóle nie potrzebne, za to brak jakiegokolwiek rezystora na linii resetu raczej nie jest normalny... (...)


    Odgrzebałem stary wątek ale jak to jest z rezystorem przy reset?
    Na rysunku z dokumentacji STM32F103xC, STM32F103xD, STM32F103xE nie ma rezystora podciągającego.
    [STM32] [OpenOCD] Problem z debuggerem

    I drugie pytanie czy sygnały RTCK, DBGRQ i DBGACK gniazda JTAG muszą być dołączone przez rezystory do masy (używam USBscarab) ?

    Pozdrawiam
  • Specjalista - Mikrokontrolery
    Piotr Piechota napisał:
    Odgrzebałem stary wątek ale jak to jest z rezystorem przy reset?
    Na rysunku z dokumentacji STM32F103xC, STM32F103xD, STM32F103xE nie ma rezystora podciągającego.
    [STM32] [OpenOCD] Problem z debuggerem

    No więc jak sam widzisz jest wewnętrzny, ale dosyć słaby - jeśli zależy Ci na odporności na zakłócenia, to zewnętrzny układ RC jest generalnie konieczny...

    Cytat:
    I drugie pytanie czy sygnały RTCK, DBGRQ i DBGACK gniazda JTAG muszą być dołączone przez rezystory do masy (używam USBscarab) ?

    Te sygnały w tym JTAGu (jak zresztą w 99% innych JTAGów) nie sa nigdzie podłączone, bo nie są obsługiwane i wykorzystywane.

    4\/3!!
  • Poziom 21  
    Dzięki za konkrety :) Pomógł nie działa bo to nie mój wątek.