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

STM32F373 - Nie działa SysTick

16 Lut 2016 08:28 999 12
  • Poziom 26  
    Witam wszystkich.
    Uzywam Eclipse + OpenOCD (0.9.0) + GCC. Do tej pory używałem STM32F103 (Cortex-M3), a teraz przesiadłem się na STM32F373 (Cortex-M4). Wziąłem ze starego programu skrypt linkera, startup, vectors.c i posklejałem do kupy odpowiednio je modyfikując. Program generalnie odpala się, mogę sterować GPIO.
    Następnie spróbowałem uruchomić SysTicka. I tu niespodzianka - nijak nie mogę go zmusić do działania. Niby wszystko kompiluje się dobrze, w tablicy wektorów przerwań jest odpowiedni wektor na właściwym miejscu, stosy są ustawione, a do przerwania nie wchodzi.
    I tu moja prośba - ponieważ najpewniej coś pomyliłem albo o czymś zapomniałem, to prosiłbym o rzut oka na projekt i jakiekolwiek sugestie gdzie mógłbym szukać rozwiązania.

    Skrypt linkera (bazuje na skrypcie Freddy'ego):
    Kod: text
    Zaloguj się, aby zobaczyć kod
    [/code]

    Startup (też z przykładu Freddy'ego):
    Kod: armasm
    Zaloguj się, aby zobaczyć kod


    Plik vectors.c (na bazie przykładu Freddy'ego z F103, przerobiony przeze mnie na podstawie dokumentacji do F373):
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Kod programu (mój, działał bezbłędnie na F103):
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Załączam widok okna OpenOCD po załadowaniu programu. Zastanawiająca jest ostatnia linia: pc: 0x2000003a, która sugeruje, że program idzie z RAM-u?

    STM32F373 - Nie działa SysTick

    Siedzę nad tym od dwóch dni i nie mam pomysłów co jeszcze jest nie tak...
  • Specjalista - Mikrokontrolery
    Możliwe przyczyny: skrypt linkera, stos itd.

    "program idzie z RAM-u", a w programie mamy wymuszenie tablicy adresów wyjątków spod adresu 0.

    Parę innych kwiatków też tam jest, np. żmudne wisywanie do rejetrów ich domyślnej zawartości. No i to mnie rozwaliło:

    memset(&sys_timer.flaga, NIE, sizeof(sys_timer.flaga));

    - ileż się trzeba namęczyć, żeby wyzerować wyzerowaną już tyciunią zmienną... ;)
  • Specjalista - Mikrokontrolery
    arturt134 napisał:
    Zastanawiająca jest ostatnia linia: pc: 0x2000003a, która sugeruje, że program idzie z RAM-u?

    Może trzeba przestawić na płytce jakieś zworki?

    arturt134 napisał:
    Niby wszystko kompiluje się dobrze, w tablicy wektorów przerwań jest odpowiedni wektor na właściwym miejscu, stosy są ustawione, a do przerwania nie wchodzi.

    Ale program kręci się w tej pustej pętli while (1);, czy może się wiesza (wchodzi do default handler), albo może w ogóle zaczyna się dziać coś dziwnego?
  • Poziom 26  
    Blue Draco:
    1. Debugger twierdzi, że jestem we flashu. Programu do RAM-u nie ładuję. Nie wiem dlaczego wyświetl mi w oknie OpenOCD adres z RAM-u.
    2. Wpisywanie wartości domyślnych na pewno nie zaszkodzi. Widziałem już takie kwiatki, że rejestr jest po resecie inny niż deklarowany przez producenta (co prawda nieczęsto, ale nawyk mi pozostał).
    3. memset zostało z innego projektu - zapomniałem je usunąć, tutaj jest oczywiście zbędne.

    Freddie:
    1. Na płytce nie ma żadnych zworek - to nie gotowiec, tylko mój układ. Mogę wrzucić schemat, jeżeli coś pomoże. Na niezadane pytanie o pin BOOT0 odpowiadam, że jest dołączony do GND przez rezystor 100k.
    2. Program kręci się w pustej pętli i nie wchodzi do żadnego wektora. Próbowałem włączyć Watchdoga - niby wszystko się skonfigurowało, ale po upływie zadanego czasu procek się nie zresetował. Sprawdzałem SCB w rdzeniu - nie ma zapalonych żadnych flag od fault-ów, jedyne co jest ustawione to bit PENDSTSET w rejestrze ICSR.

    Załączam zrzut ekranu z debugera.
    STM32F373 - Nie działa SysTick

    Aha, wcześniej już co prawda pisałem o tym, ale jeszcze raz przypomnę - jeżeli w pętli głównej steruję pinem GPIO i oglądam go sobie oscyloskopem, to wszystko jest OK. Jeżeli tym samym pinem steruję w przerwaniu SysTick, to nic się nie dzieje.
  • Specjalista - Mikrokontrolery
    Może jakimś dziwnym sposobem masz globalnie zablokowane przerwania? Sprawdź co by było gdybyś je profilaktycznie włączył odpowiednimi funkcjami z CMSIS.
  • Poziom 26  
    Dodałem:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Nic nie pomogło.

    Dodałem sekwencję:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Również bez zmian.

    Pobrałem i zainstalowałem Atollic TrueStudio for ARM. Wygenerowałem czysty projekt, sprawdziłem wektory, startup, plik linkera - nie różnią się w istotny sposób od moich (są niemal identyczne). Debugowałem używając OpenOCD - efekt ten sam, czyli dokładnie tak samo nie działa.

    Wydaje mi się, że problem dotyczy albo sprzętu albo OpenOCD. Przez OpenOCD łączę się w trybie JTAG (TDO/TDI/TMS/TCK, nie mam podłączonego pinu TRST, ale według dokumentacji nie jest on niezbędny, nie można go tylko używać jako GPIO) - spróbuję jeszcze użyć trybu SWD....
    Mam też na półce płytkę STm32F4 Discovery, spróbuję połączyć się z nią, może coś się wyjaśni.

    Dzięki za dotychczasowe zaangażowanie i pozdrawiam. Oczywiście, cały czas pozostaję otwarty na sugestie.
  • Specjalista - Mikrokontrolery
    Jeśli podejrzewasz OpenOCD albo narzędzia, to po prostu wstaw miganie diodą do przerwania od systicka, zaprogramuj układ, odłącz wszystko a następnie podłącz tylko zasilanie.
  • Poziom 26  
    Tak zrobię. Na razie coś mi się posypało i program w ogóle nie chce się ładować. Może to jednak uszkodzony procek, który "prawie działa"....

    Dodano po 1 [godziny] 35 [minuty]:

    Jednak nie - procek jest sprawny. Udało mi się nawiązać połączenie i debugować korzystając z ST-Link (płytka STM32F4Discovery) i TrueStudio. SysTick działa.
    Wydaje mi się, że przyczyną złego działania była błędna obsługa JTAG-a przez OpenOCD 0.9.0 (interfejs JTAG, którego używam służy mi też do programowania ARM7 i tam chodzi bez problemu).

    Teraz pozostało mi zmuszenie do działania ST-linka z OpenOCD 0.9.0 i uruchomienie tego samego w Eclipse, na moich plikach.
  • Poziom 26  
    Problem rozwiązany - udało mi się uruchomić OpenOCD 0.9.0 + Eclipse + STLink. Działa debug i przerwania. Komunikacja w trybie SWD.
    Dziękuję wszystkim za pomoc.

    A jak Wy się łączycie z STM32? Przez JTAG, SWD, czy też kombinację obu interfejsów?
  • Specjalista - Mikrokontrolery
    Może napisz po prostu jakieś szczegóły, bo to co opisujesz (w sposób bardzo powierzchowny) nie ma żadnego sensu. Każdego ARMa i znajdujące się na nim peryferia można sobie bezproblemowo debuggować każdym rodzajem JTAGa (FTx232, ST-Link, J-Link, U-Link, ...) i przy użyciu dowolnego interfejsu (JTAG, SWD) - od lat nigdy nie miałem z tym żadnych problemów.
  • Poziom 26  
    No właśnie. Ja też zawsze podłączałem JTAGA używając linii: TDI, TDO, TMS, TCK i nRST. Jako interfejsu używałem: portpar (równoległy na porcie LPT), Andtech JTAG (zgodny z Amontec JTAGkey na FT2232), ZL24PRG (zgodny z OCDlink, na FT2232)
    Łączyłem się z prockami ARM7 i ARM Cortex-M3. Wszystko zawsze działało, na różnych OpenOCD (0.1.0, 0.4.0 i chyba jeszcze 0.6.0). Przesiadając się na Cortex-M4 ściągnąłem OpenOCD w wersji 0.9.0 i zong - nie działa z moim Andtech JTAG na FT2232, tzn. prawie działa, ale ma problemy z poprawnym debugowaniem układu - objawy były takie jakie opisałem we wcześniejszych postach. Innych interfejsów nie sprawdziłem, bo w tej chwili nie mam do nich dostępu.

    Dlatego też podłączyłem do mojej płytki STLink (z płytki STM32F4discovery, wyprowadzone złącze SWD). To nie jest JTAG, tylko SWD (podłączany tylko liniami SWCLK, SWDIO i nRST). Uruchamiam OpenOCD komendą:

    D:/OpenOCD/0.9.0/bin/openocd -f D:/OpenOCD/0.9.0/scripts/interface/stlink-v2.cfg -f D:/OpenOCD/0.9.0/scripts/target/stm32f3x.cfg

    i wszystko działa OK. Ale tak jak pisałem wcześniej, połączenie jest tylko przez SWD - z SWJ debug port procesora wykorzystuję linie: SWCLK, SWDIO, czyli według dokumentacji procesora łącze się przez SW-DP (serial wire debug port), niewykorzystane linie portu SWJ są fizycznie niepodłączone. Połączenie przez JTAG-a (oznaczone w dokumentacji JTAG-DP) nie działa prawidłowo. Stąd moje pytanie - czy łączysz się z procesorami Cortex-M4 poprzez SW-DP (nazwany przeze mnie skrótowo SWD), czy JTAG-DP (nazwany przeze mnie skrótowo JTAG)?
  • Specjalista - Mikrokontrolery
    Jedno i drugie - działa za każdym razem.

    Nowe wersje OpenOCD wprowadziły maskowanie przerwań podczas "single step" - może po prostu o to Ci chodzi? Opcja ta (można ją wyłaczyć działa tak, że podczas klikania "step" w debuggerze w zasadzie nigdy nie zostanie wykonane żadne przerwanie. Ma to pewne wady jak i pewne zalety (np. bez tej opcji debuggowanie kodu z włączonym timerem [który działa podczas zatrzymania rdzenia] jest niemożliwe).
  • Poziom 26  
    O tym nie wiedziałem... Ale ja puszczałem program również komendą continue, więc chyba nie powinno wtedy zadziałać wyłączanie przerwań. Zresztą, taka praca byłaby bez sensu, bo nigdy program nie zatrzymałby się w przerwaniu. Poza tym i tak coś się kaszaniło, miałem jakieś dziwne komunikaty, nawet przez jakiś czas myślałem że padł mi procesor.

    Myślę, że na tym możemy zakończyć naszą dyskusję - problem został rozwiązany 9a właściwie, to znalazłem sposób jego obejścia:), a jego przyczyn nie mam niestety czasu dochodzić. W każdym razie wygląda na to, że przyczyny te mogą wynikać z konfiguracji mojego komputera, driverów itp., a nie z błędu w OpenOCD.

    Jeszcze raz dziękuję za zaangażowanie. Temat zamykam.