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

STM32F0 - HardFault przy wejściu do funkcji

02 Gru 2019 14:27 144 4
  • Poziom 30  
    Witam,

    Nie mogę rozwiązać jednego problemu, może będziecie w stanie mi pomóc.
    Próbuję na STM32F042 uruchomić biblioteki dla czujnika VL53L (biblioteki ULD), ale problem w sumie raczej nie w tym.

    Kompilacja przechodzi bez problemu, ale przy próbie wywołania funkcji wpada w HardFault i nie mam pojęcia czemu.
    Kod: c
    Zaloguj się, aby zobaczyć kod

    STM32F0 - HardFault przy wejściu do funkcji
    WatchDog jest wyłączony, rozmiary stert:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Nie wiem jak za bardzo działa "Instrution Stepping Mode", ale jeśli faktycznie wykonuje rozkaz po rozkazie na CPU (a nie emuluje na PC) to w tym trybie program działa poprawnie.
    Mikrokontroler pracuje na 48MHz, późnienie w dostępie do pamięci jest włączone:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Kompilator w wersji "9 2019-q4-major", zaktualizowałem aby mieć pewność że to nie jego wina.

    Macie pomysł co może być winą albo jak dojść do problemu?
  • Pomocny post
    Specjalista - Mikrokontrolery
    Albo za mały stos, albo błąd w kodzie (np. włączone przerwanie które nie jest obsługiwane, używanie nieprawidłowego wskaźnika, ...). Żeby wyeliminować pierwszą opcję wystarczy stos powiększyć i sprawdzisz co się wtedy stanie.
  • Specjalista - Mikrokontrolery
    WWDG -> watchdog?
    Ze znakiem zapytania, bo rzadko piszę na STM, to nie znam wszystkiego na pamięć.
    Na stosie nie widzę hard fault-a.
  • Poziom 21  
    @szelus Wiekszość startupów ma ten sam adres obłsugi tych wyjątków. Dlatego nazwą się nie sugeruj o ile nie zostały napisane ich handlery

    ADI-mistrzu napisał:
    Nie wiem jak za bardzo działa "Instrution Stepping Mode",
    Nie. Normalnie wykonuje to na uC

    ADI-mistrzu napisał:
    Macie pomysł co może być winą albo jak dojść do problemu?

    1. Jeżeli masz zainstalowany Atolloc albo CubeIDE to znajdź FaultAnalyzer (w Window ....) i po prostu zobacz co się stało.
    2. Jeżeli jednak jesteś zwolennikiem DIY konfiguracji to musisz się nieco pomęczyć. Niestety M0 jest bardziej męczący w tym aspekcie niż nowsze rdzenie W skrócie:

    1. Zobacz w rejestrze LR bit 2 aby stwierdzić, który stos (MSP, PSP) jest w użyciu

    (jeżeli wskaźnik jest w "legalnej" pamięci)
    2. Zobacz na stosie wskazanym przez odpowiedni wskaźnik rejestr PC (xSP + 0x18)
    STM32F0 - HardFault przy wejściu do funkcji - tam wystąpił fault (nie zawsze to prawda)

    3. Sprawdź bit T w zachowanym na stosie xPSR - może zły kod - albo niewłaściwe "entry" w tablicy wektorów (wszystkie muszą być nieparzyste)

    4. Jeżeli PC jest na instrukcji odwołującej się do pamięci sprawdź: czy adres jest właściwy, czy jest właściwe wyrównanie dla tej instrukcji

    5. Sprawdź IPSR w xPSR - to też może Ci dać jakieś informacje

    Dodaj jakiś delay przed skokiem do tej funkcji - zobaczysz czy akurat przypadkiem w tym momencie nie przychodzi jakieś przerwanie (delay typu for(unsigned x = 0; x < 100000; x++) asm(""); )
  • Poziom 30  
    Już wiem, @Freddie Chopin miał rację z przerwaniem.
    Było włączone przerwanie od GPIO (obsługa IRQ czujnika) ale nie zadeklarowałem funkcji do obsługi niego...
    Trywialny błąd, nie wiem jak to pominąłem...

    W efekcie po inicjalizacji czujnika pin IRQ zaczął być aktywny i wywoływał przerwanie w MCU, z racji iż było default'owe to lądowało tam gdzie wszystkie inne, czyli HardFault.

    @osctest1, jestem zwolennikiem DIY, a więc Twój opis przyda mi się w przyszłości :)
    Wole mieć jedno środowisko pod różne MCU niż mnóstwo różnorakich (chodź nie zawsze się da).