logo elektroda
logo elektroda
X
logo elektroda
Szukanie Zaawansowane
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[STM32] [STM32][Eclipse] Debugowanie krokowe przerywane przez przerwanie Timera

markosik20 03 Lis 2009 22:04 3751 7
REKLAMA
Zgłoś naruszenie prawa
Odpowiedz | Nowy temat
  • #1 7212503
    markosik20
    Poziom 33  
    Posty: 2261
    Pomógł: 208
    Ocena: 147
    Pojawił się u mnie ostatnio problem po dodaniu w programie przerwania od Timera.
    Dotychczas działało wszystko super, debagowanie trybie krokowym działało bez problemu itd.
    Po dodaniu przerwania program również działa ale niestety w trybie krokowym...nie do końca. Gdy zatrzymam rdzeń w jakimś miejscu programu i wykonam następną instrukcję pojawia się to co na zrzucie ekranu czyli rdzeń wpada w obsługę przerwania "gubi" adres powrotu (rejestr LR). Praca krokowa przestaje działać gdyż cały czas wykonuje się to co w obsłudze przerwania. Pomaga jedynie "puszczenie" programu dalej. Dodatkowo w konsoli OpenOCD pojawia się text:
    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    Error: AHBAP Cached values: dp_select 0x0, ap_csw 0xa2000012, ap_tar 0xffffffff
Error: SWJ-DP STICKY ERROR
Error: Read MEM_AP_CSW 0x23000052, MEM_AP_TAR 0xfffffffc


    Breakpointy działają prawidłowo..jednak brak możliwości pracy krokowej czasami utrudnia debugowanie kodu.

    Dołączam swój starup.c (trochę dziwaczny ....ale sięprzyzwyczaiłem) oraz skrypt linkera. Komendy GDB to poprostu

    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    target remote localhost:3333
monitor reset halt
load
monitor soft_reset_halt


    [STM32] [STM32][Eclipse] Debugowanie krokowe przerywane przez przerwanie Timera

    Może ktoś już "walczył" z podobnym zjawiskiem ?
    Załączniki:
    • stm32_ROM.txt (765 Bajtów) Musisz być zalogowany, aby pobrać ten załącznik.
    • startup_gcc.c (9.52 KB) Musisz być zalogowany, aby pobrać ten załącznik.
    F&Home: inteligentna automatyka budynkowa, która łączy technikę, wygodę i bezpieczeństwo [sponsorowane]
  • REKLAMA
  • Pomocny post
    #2 7212716
    Freddie Chopin
    Specjalista - Mikrokontrolery  
    Posty: 13336
    Pomógł: 1712
    Ocena: 870
    W STM32 domyślnie podczas zatrzymania rdzenia timery pracują, więc podczas twojej pracy krokowej zgłaszane są setki kolejnych przerwań. Aby to zwalczyć należy w rejestrze DBGMCU->CR (w manualu DBGMCU_CR) zapalić stosowny bit dotyczący stosownego timera. Niestety nie zawsze jest to możliwe (bo aplikacja może wymagać aby timer naprawdę stale pracował jeśli steruje np PWMem, którego nie można po prostu zapauzować).

    4\/3!!
  • REKLAMA
  • #3 7213987
    markosik20
    Poziom 33  
    Posty: 2261
    Pomógł: 208
    Ocena: 147
    Freddie Chopin napisał:
    W STM32 domyślnie podczas zatrzymania rdzenia timery pracują, więc podczas twojej pracy krokowej zgłaszane są setki kolejnych przerwań.
    4\/3!!


    No nic może uda się mi to wieczorkiem opanować to dam znać. W LPC...nie było tego problemu....ale z drugiej strony dokumentacja do STM32 ma dużo więcej stron :wink:.

    _____________________________

    No i racja wystarczy dodać na samym początku

    Kod: text Rozwiń Zaznacz wszystko Kopiuj do schowka
    DBGMCU->CR |= DBGMCU_TIM1_STOP;


    i znowu można się cieszyć pracą krokową.
  • REKLAMA
  • #4 9600641
    asier
    Poziom 12  
    Posty: 18
    Ocena: 2
    Freddie Chopin napisał:
    W STM32 domyślnie podczas zatrzymania rdzenia timery pracują, więc podczas twojej pracy krokowej zgłaszane są setki kolejnych przerwań. Aby to zwalczyć należy w rejestrze DBGMCU->CR (w manualu DBGMCU_CR) zapalić stosowny bit dotyczący stosownego timera. Niestety nie zawsze jest to możliwe (bo aplikacja może wymagać aby timer naprawdę stale pracował jeśli steruje np PWMem, którego nie można po prostu zapauzować).

    4\/3!!

    Rada odnośnie timerów jest super, ale jak poradzić sobie z przerwaniem od USART2 w STM32? Jak je automatycznie blokować podczas debugowania?
  • REKLAMA
  • #5 9601007
    nsvinc
    Poziom 35  
    Posty: 2870
    Pomógł: 262
    Ocena: 88
    Jedno mnie dziwi - nigdy nie miałem takich problemów. To, że timery czy inne peryferia sobie pracują, gdy rdzeń jest halt to nie powinno nikomu przeszkadzać, skoro stepowany rdzen w ogóle nie skacze pod wektory ISRów...?
  • #6 9601057
    asier
    Poziom 12  
    Posty: 18
    Ocena: 2
    nsvinc napisał:
    Jedno mnie dziwi - nigdy nie miałem takich problemów. To, że timery czy inne peryferia sobie pracują, gdy rdzeń jest halt to nie powinno nikomu przeszkadzać, skoro stepowany rdzen w ogóle nie skacze pod wektory ISRów...?

    Gdy używam Ride7 to nie mam tego problemu, ale gdy przekroczyłem limit 32kB przesiadłem się na Eclipse+OpenOCD. No i niestety w trakcie debugowania wskakuje mi w procedurę obsługi przerwania od USART1 gdy takowe się pojawia (wysyłanie i odbieranie danych w przerwaniu). ST dało możliwość automatycznego maskowania przerwań w trybie debug (o czym wspomniał Freddie), ale w tym rejestrze są w zasadzie tylko maski dla timerów..
  • #7 9667696
    asier
    Poziom 12  
    Posty: 18
    Ocena: 2
    Z problemem poradziłem sobie w 90% stosując sztuczki z wpisami hook w pliku ".gdbinit" oraz dodatkowym wpisem do pliku konfiguracyjnego openocd dla eventu "old-pre_resume". Chodzi o użycie "cortex_m3 maskisr on/off".
    Dopiero najnowsza poprawka do OpenOCD 0.5.0 z 28 czerwca dodała automatyczne włączanie/wyłączanie bitu C_MASKINTS w Debug Halting Control and Status Register [0xE000EDF0]. Pierwsze próby pokazują, że działa to całkiem fajnie dla procesorów STM32. Debugowanie przy bardzo często pojawiającym się przerwaniu od USART wreszcie stało się łatwiejsze :)
  • #8 9707232
    Freddie Chopin
    Specjalista - Mikrokontrolery  
    Posty: 13336
    Pomógł: 1712
    Ocena: 870
    Wkrótce (postaram się dziś wieczorem) będą dostępne na mojej stronie www.freddiechopin.info najnowsze kompilacje OpenOCD 0.5.0-rc1 i -rc2, które zawierają już (chyba obydwie) funkcję "cortex_m3 maskisr auto", która to rozwiązuje pięknie problemy przedstawione w tym wątku (;

    EDIT: -rc1 jest już wrzucone, -rc2 (i zapewne -rc3, jeśli zostanie otagowane) - wkrótce.

    4\/3!!
Odpowiedz | Nowy temat
Zgłoś naruszenie prawa

Podsumowanie tematu

✨ Problem dotyczy debugowania krokowego w mikrokontrolerach STM32 przy jednoczesnym użyciu przerwań od timerów. Podczas zatrzymania rdzenia w trybie debugowania timery nadal pracują, co powoduje ciągłe wywoływanie przerwań i "gubienie" adresu powrotu (rejestru LR), uniemożliwiając poprawne wykonywanie kroków instrukcji. Rozwiązaniem jest ustawienie odpowiedniego bitu w rejestrze DBGMCU->CR, który zatrzymuje timer podczas debugowania (np. DBGMCU_TIM1_STOP). Problem z przerwaniami od innych peryferiów, takich jak USART, można częściowo rozwiązać poprzez konfigurację OpenOCD i użycie funkcji maskowania przerwań (cortex_m3 maskisr on/off), dostępnej w nowszych wersjach OpenOCD (0.5.0 i wyższe). Dodatkowo, w Eclipse z OpenOCD problem jest bardziej widoczny niż w środowisku Ride7. Wprowadzenie automatycznego maskowania przerwań w trybie debugowania znacząco ułatwia pracę z często występującymi przerwaniami USART i timerów w STM32.
Wygenerowane przez model językowy.
REKLAMA