STM32F0 - Pętla while nie kończy się mimo dekrementacji timer_cnt do 0

Witam,
Bawie sie płytka STM32F0Discovery, napotkalem na dziwne zachwowanie prostej funkcji opozniajacej.
Od razu mówie ze docelowo bedzie ona i tak uruchomiona na timerze, a to co ponizej traktuje jako swego rodzaju ciekawostke.

Mianowicie zmienna timer_cnt schodzi do 0, a petla while sie nie chce zakonczyc.
W tym czasie przerwania, DMA i Systick działa poprawnie.
Moze moglby ktos sprawdzic jaki kod generuje inny kompilator?
Czy to wogole wina kompilatora?

Optymalizacja jako -O0

Debugger stoi na "while", nie znam jeszcze assemblera na ten procesor.
Prosilbym o jakis hint.



wywołanie z main w taki sposob:



Listing przed assemblerem:

uzi18 napisał:

Kod: C / C++

Zaloguj się, aby zobaczyć kod

Przydałby się kod tego przerwania, żebyśmy zobaczyli, jak timer_cnt jest zmniejszany.
Może w ogóle nie jest zmniejszany?
Może przerwanie jest wołane tak rzadko, że jeszcze nie zjechało z 1000 do zera?
Może się przekręca przez zero i liczy dalej od MAX_INT?
Może przerwanie jest w innym pliku i zmniejsza inną zmienną o tej samej nazwie?
Może... chyba już dość się bawię ze szklaną kulą.

Pozdrowienia,
m.ki

Tak jak napisalem, schodzi do 0 i stoi.
Za to petla sie nie zakancza.



W debugerze podgladalem zmienna wiec mam pewnosc ze schodzi do 0.

Bez przesady z ta szklana kula.

Ano szklana.

I niby co mamy z niej wywróżyć..

Kod niekompletny ot cała odpowiedz na jaką możesz liczyć.

Systick i delay_ms sa w jednym module main.c
Postaram sie go okroic do minimum, nie mam teraz kodu pod reka aby cos wkleic.

Dopóki nie pokażesz całej obsługi tej zmiennej to nie da się pomóc

Tyle ze nic wiecej nie ma ... w programie zwiazanego z ta wlasnie zmienna.
Sprawdzalem przed chwila jak wyglada kod przy optymalizacji -Os i tyle ze mniej obciazany jest stos.

Generalnie wyglada na to ze sama funkcja jest ok i blad jest gdzies indziej ...
Czy przed wejsciem do handlera systick jakies rejestry ida na stos?

Widac np. ze przy optymalizacji -Os istnieje niebezpieczenstwo zamazania rejestru r3 ale w tym wypadku (-O0) nie powinno miec to miejsca.

Wpisz do wnętrza pętli while(timer_cnt!=0); np. 'mruganie' portem żeby mieć pewność, że właśnie tam program się wykonuje.

uzi18 napisał:

Tyle ze nic wiecej nie ma ... w programie zwiazanego z ta wlasnie zmienna.
Sprawdzalem przed chwila jak wyglada kod przy optymalizacji -Os i tyle ze mniej obciazany jest stos.

Generalnie wyglada na to ze sama funkcja jest ok i blad jest gdzies indziej ...
Czy przed wejsciem do handlera systick jakies rejestry ida na stos?

Widac np. ze przy optymalizacji -Os istnieje niebezpieczenstwo zamazania rejestru r3 ale w tym wypadku (-O0) nie powinno miec to miejsca.

Po co ta bezsensowna dywagacja o optymalizacjach i rejestrach?

Pokaż kod inaczej na żadną pomoc nie licz.

Na 100% błąd leży po twojej stronie.

Sprawdź czy program tak samo zachowuje się bez podłączonego debuggera.

Przyczepilem sie optymalizacji itp. opcji kompilatora ale w miedzyczasie wyszlo ze najwyrazniej rdzen zrzuca na stos rejestry r0-r3 i klika innych, wiec problem nie lezy tutaj.

Wiem ze gdzies popelnilem blad, nie mam doswiadczenia z ARM-ami.
Oczyszcze i zminimalizuje kod aby bylo absolutne minimum powodujace problemy i wrzuce.

Systick szczesliwie miga diodami, wiec funkcjonuje.
Delay na petli for tez dziwnie sie zachowuje albo trwa w nieskonczonosc albo nic nie trwa (podejrzewam ze tu pewnie optymalizator miesza).

Ciekawostka jest taka ze jak sie wstawi breakpointa na fragment w assemblerze po przypisaniu, gdzie jest
wczytywan wartosc na porownanie do 0 i skok na poczatek wczytywania jesli nie rowne, to ...
wynik porowania jest ok i wychodzi z while (przechodze przez wszystkie linijki w trybie Instruction List, tj. wykonuje sie kod maszynowy).
Bez debugowania i debugowanie zgodnie z linijkami kodu w "c" niestety nie wyskakuje.

Zminimalizuje kod do minimum i zobaczymy moze cos wyjdzie przy okazji.

Panowie, problem rozwiazany, poniewaz poczatkowo korzystalem tylko z przerwan (glownie systick) miałem ustawioną maske SCB_SCR_SLEEPONEXIT_Msk w SCB->SCR.

Gdy zaczalem wrzucac do main() co rusz to cos wiecej, pierwsze wywołanie handler-a Systick zatrzymywało wykonywanie funkcji która została przerwana.
Debugger omijal to ograniczenie.

Dotarlem do tego poprzez okrajanie kodu do minimum.

Dziekuje wszystkim za pomoc.