Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[STM32L4] [GCC, FreeRTOS] Hardfault podczas korzystania z sprintf z floatami.

conkerkh 22 Apr 2017 19:30 1698 14
  • #1
    conkerkh
    Level 6  
    Witam, postaram sie opisac problem najprosciej jak to mozliwe. Mianowicie zauwazylem ze przy kompilacji z parametrami:
    Code:
    -spec=nano.specs -u _printf_float -specs=rdimon.specs -lc -lrdimon

    kazde odwolanie w zadaniu do sprintf w ktorym znajduje sie float powoduje hardfault. Kiedy korzystam z biblioteki nosys bez opcji semihostingu ten problem nie wystepuje. Wiem ze sprintf moze sie odwolywac do malloc() oraz free(), z tego co sie dowiedzialem to wlasnie w regionach gdzie zwalniany jest zalokowany bufor wystepuje hardfault. Kiedy korzystam z sprintf z floatem przed odpaleniem kernela wszystko jest ok. Dodam tylko ze zadania maja wystarczajaco duzo zalokowanej pamieci, wiec to napewno nie jest problem. Gdzie szukać dalej, co zmienić bede wdzięczny za sugestie.
  • #2
    User removed account
    User removed account  
  • #3
    conkerkh
    Level 6  
    Piotrus_999 wrote:
    w port.c

    zmien pxTopOfStack -= 2; na pxTopOfStack -= 1;

    kiedyś miałem podobny problem.

    Ale to też zależy od wersji RTOS-a.

    Generalnie jest z tym trochę problemów.


    U mnie to tak wyglada:

    Code: c
    Log in, to see the code


    czyzby linia z -= 5 byla odpowiednim miejscem do grzebania? Reszta wyglada jakby byla wyrownana.
  • #4
    User removed account
    User removed account  
  • #5
    Freddie Chopin
    MCUs specialist
    Jeśli używasz stosunkowo "starego" newliba (starszy niż max kilka miesięcy, mogę dokładnie sprawdzić), to malloc() w wersji "nano" _NIE_ nadaje się do działania wielowątkowego choćbyś nie wiem co zrobił. W nowszych newlibach trzeba sobie przedefiniować dwie funkcje i dodać tam np. blokowanie mutexów. Inna opcja to przedefiniowanie malloc() i free() na funkcje z FreeRTOSa (jeśli nie używa on malloc() / free() z newliba [; ).
  • #6
    conkerkh
    Level 6  
    Freddie Chopin wrote:
    Jeśli używasz stosunkowo "starego" newliba (starszy niż max kilka miesięcy, mogę dokładnie sprawdzić), to malloc() w wersji "nano" _NIE_ nadaje się do działania wielowątkowego choćbyś nie wiem co zrobił. W nowszych newlibach trzeba sobie przedefiniować dwie funkcje i dodać tam np. blokowanie mutexów. Inna opcja to przedefiniowanie malloc() i free() na funkcje z FreeRTOSa (jeśli nie używa on malloc() / free() z newliba [; ).


    Faktycznie korzystanie z newliba bez nano poprawia sytuacje i sie nie wykrzacza. Natomiast pojawia sie dosc dziwny problem ze float'y nie sa poprawnie wyswietlane jesli uprzednio nie skorzystalem z semihostingu (nie wywolalem printf()). Nie wiem jaki ma to sens zupelnie. Zdefiniowalem malloc i free tak zeby korzystaly z pvPortMalloc i vPortFree. Generalnie mam to tak ustawione ze sprawdzam rejestr DHCSR czy jest ustawiony bit debugowania i nie wywoluje nic odpowiedzialnego za semihosting jesli debuger nie jest wpiety ale z tego co widze to nie wystarcza i chyba musze sobie po prostu zrobic druga konfiguracje, ktora bedzie inaczej linkowac biblioteki.
  • #8
    User removed account
    User removed account  
  • #9
    conkerkh
    Level 6  
    Mysle ze finalnie wywale po prostu semihosting... Bede korzystac z VCP i logow do karty pamieci bo nie mam sily juz z tym walczyc. Stos niby jest wyrownany bo jest to sprawdzane przez assert() i przechodzi przez to... Dzieki panowie za rady, jesli ktos ma jeszcze jakies pomysly chetnie wyslucham moze ewentualnie uda sie cos z tym zrobic, jak nie to trudno.
  • #10
    User removed account
    User removed account  
  • #11
    Freddie Chopin
    MCUs specialist
    Ja bym się tam nie poddawał. Jeśli nie działa Ci printf() z floatami, to - jak pisałem - jest spora szansa, że w projekcie masz poważny problem związany z wyrównaniem stosów. Zignorujesz semihosting to w końcu trafisz na inny objaw tego samego, nierozwiązanego problemu. W każdym razie problem z wyrównaniem stosów objawia się też tak, że czasem takie funkcje powinny działać. Jeśli nie działa Ci absolutnie każda i w każdym przypadku, nigdy nie zdarzyło się aby zadziałała poprawnie, to być może jednak problem jest inny. Tak czy siak po prostu ignorując go w jednym miejscu masz szansę trafić na niego w innym miejscu i w innym czasie.

    Stosy wątków może i są wyrównane, ale co ze stosami przerwań oraz co ze stosem głównym (być może to jeden i ten sam stos)? Jaka to wersja RTOSa? Jak jakaś stara, to jednak zacząłbym od aktualizacji. Jaki toolchain, jaka wersja?
  • #12
    conkerkh
    Level 6  
    Freddie Chopin wrote:
    Ja bym się tam nie poddawał. Jeśli nie działa Ci printf() z floatami, to - jak pisałem - jest spora szansa, że w projekcie masz poważny problem związany z wyrównaniem stosów. Zignorujesz semihosting to w końcu trafisz na inny objaw tego samego, nierozwiązanego problemu. W każdym razie problem z wyrównaniem stosów objawia się też tak, że czasem takie funkcje powinny działać. Jeśli nie działa Ci absolutnie każda i w każdym przypadku, nigdy nie zdarzyło się aby zadziałała poprawnie, to być może jednak problem jest inny. Tak czy siak po prostu ignorując go w jednym miejscu masz szansę trafić na niego w innym miejscu i w innym czasie.

    Stosy wątków może i są wyrównane, ale co ze stosami przerwań oraz co ze stosem głównym (być może to jeden i ten sam stos)? Jaka to wersja RTOSa? Jak jakaś stara, to jednak zacząłbym od aktualizacji. Jaki toolchain, jaka wersja?


    Genralnie wyglada to tak. Mam linker w konfiguracji release ustawiony tak:
    Code:
    -specs=nosys.specs -u _printf_float -specs=rdimon.specs

    to dziala bez zadnego problemu sprintf z floatem chodzi. Nosys i tak wiadomo jest ignorowany tutaj.

    Druga konfiguracja debug wyglada tak:
    Code:
    -specs=rdimon.specs -u _printf_float -lc -lrdimon


    Z tego co wiem musze to tak linkowac bo semihosting nie bedzie dzialac. Podejrzewam ze to jest wlasnie wina tego wszystkiego. Sprintf przy tej drugiej konfiguracji nie dziala poprawnie do momentu wywolania chociaz raz printf, bo wypisuje bzdury ale sie nic nie wykrzacza, jak wywolam juz printf to sprintf zaczyna dzialac z floatami jak powinien. To jest normalny objaw?

    Toolchain najnowszy ze strony arma. RTOS jest w wersji 9.0.0
  • #14
    conkerkh
    Level 6  
    Freddie Chopin wrote:
    conkerkh wrote:
    To jest normalny objaw?

    Nigdy nie używałem semihostingu, ale przypuszczam że zachowanie które obserwujesz nie jest normalne [;


    Chyba musze dokladnie przestudiowac te opcje linkowania bibliotek i toolchain bo chyba cos sie tam dzieje czego nie widze i jest poza moja kontrola.
  • #15
    rajszym
    Level 20  
    Tak dla porządku: wywołujesz funkcję "initialise_monitor_handles"?