Wskaźnik losowo przypisany tajemnicze wartości (A5A5A5A5 i FFFFFFFF) na stm32 przy użyciu freeRTOS powodujące hardfault

Question

Mam problem z hardfault, który pojawia się w pozornie przypadkowych razy, gdy wskaźnik wskazuje adres A5 lub FF (moja dozwolona pamięć jest daleko poniżej 80000000 i więcej). Wydaje się, że zawsze jest ten sam wskaźnik z tymi dwiema wartościami.

Używam wbudowanego systemu z procesorem STM32F205RE, który komunikuje się z układem fm/bluetooth/gps o nazwie cg2900, w którym występuje ten błąd.

Korzystając z debugera, widzę, że wskaźnik wskazuje odpowiednio adresy A5 i FF podczas kilku testów. Wydaje się, że zdarza się to w przypadkowych czasach, czasami mogę uruchomić test przez godzinę bez awarii, a innym razem ulega awarii 20 sekund.

Używam freeRTOS jako harmonogram, aby przełączać się między różnymi zadaniami (jeden dla radio, jedno dla bluetooth, drugie dla innej konserwacji okresowej), które może w jakiś sposób zakłócać.

Co może być tego przyczyną? Ponieważ działa niestandardowy sprzęt, nie można wykluczyć, że jest to problem sprzętowy (potencjalnie). Jakieś wskazówki (nie gra słów), jak podejść do debugowania problemu?

EDIT:

Po dalszych badań wydaje się, że to jest bardzo losowe gdzie ulega awarii, nie tylko, że specyficzny wskaźnik. Użyłem hardfault obsługi, aby uzyskać następujące wartości tych rejestrów (wszystkie wartości w hex):

Semi-long run przed katastrofą (w minutach):

R0 = 1 
R1 = fffffffd 
R2 = 20000400 
R3 = 20007f7c 
R12 = 7 
LR [R14] = 200000c8 subroutine call return address 
PC [R15] = 1010101 program counter 
PSR = 8013d0f 
BFAR = e000ed38 
CFSR = 10000 
HFSR = 40000000 
DFSR = 0 
AFSR = 0 
SCB_SHCSR = 0 

bardzo krótkim okresie przed zderzeniowych (w sekundach):

R0 = 40026088 
R1 = fffffff1 
R2 = cb3 
R3 = 1 
R12 = 34d 
LR [R14] = 40026088 subroutine call return address 
PC [R15] = a5a5a5a5 program counter 
PSR = fffffffd 
BFAR = e000ed38 
CFSR = 100 
HFSR = 40000000 
DFSR = 0 
AFSR = 0 
SCB_SHCSR = 0 

Innym krótki (sekundy)

R0 = 0 
R1 = fffffffd 
R2 = 20000400 
R3 = 20007f7c 
R12 = 7 
LR [R14] = 200000c8 subroutine call return address 
PC [R15] = 1010101 program counter 
PSR = 8013d0f 
BFAR = e000ed38 
CFSR = 1 
HFSR = 40000000 
DFSR = 0 
AFSR = 0 
SCB_SHCSR = 0 

po bardzo długim okresie (1 godzina +):

R0 = e80000d0 
R1 = fffffffd 
R2 = 20000400 
R3 = 2000877c 
R12 = 7 
LR [R14] = 200000c8 subroutine call return address 
PC [R15] = 1010101 program counter 
PSR = 8013d0f 
BFAR = 200400d4 
CFSR = 8200 
HFSR = 40000000 
DFSR = 0 
AFSR = 0 
SCB_SHCSR = 0 

Wydaje awarii w tym samym miejscu przez większość czasu. Poprawiłem pamięć zgodnie z wcześniejszymi sugestiami, ale nadal wydaje mi się, że mam ten sam problem.

Dziękujemy za poświęcony czas!

poważaniem

Answer 1

Okazuje się, że problem został spowodowanych pamięcią. Ponieważ pracowałem z procesorem przy najwyższej prędkości (120 Mhz) i zasilałem napięciem 1,8 wolta (jest ono przeznaczone głównie na 3 V), miałem pewne warunki wyścigowe z pamięcią. Rozwiązano go, stosując wyższy stan oczekiwania.

Answer 2

W swoim komentarzu wspomnieć, że ten wskaźnik jest wyraźnie przypisana raz potem nigdy zapisywane. W takim przypadku powinieneś przynajmniej zadeklarować to jako opcję inicjowania zamiast przypisywania, np.

arraytype* const ptr = array ; 

który pozwoli kompilator wykryć żadnych wyraźnych pisze. Jednak jest bardziej prawdopodobne, że wskaźnik jest uszkodzony przez jakiś niepowiązany błąd kodowania.

Moduł Coretx-M3 do debugowania chipów obsługuje punkty przerwania dostępu do danych; powinieneś ustawić taki punkt przerwania na danym wskaźniku, aby wszystkie wejścia do niego były uwięzione. Otrzymasz przerwę na inicjalizację, a następnie modyfikację - celową lub inną.

Prawdopodobne przyczyny są przekroczone w sąsiedniej tablicy lub stosie wątków.

Answer 3

Jeśli próbowali przenieść tablicę i nadal z tym samym problemem,

następnie niektóre zadaniem jest przepełnione.

Jak wspomniano, używasz FreeRTOS, a ponieważ zachowanie jest losowy jest prawdopodobne, że coś jest nie tak z ustawieniami STACK_SIZE w zaproszeniach do xTaskCreate

Dzieje się tak zwykle, gdy przydzielona rozmiar jest mniejszy niż ty naprawdę potrzebuję.

Jeśli przeczytałeś dokumentację o usStackDepth, zauważyłeś, że reprezentuje mnożnik, a nie liczbę bajtów.

Osobiście wykluczyć problemów ze sprzętem w osadzonym pokładzie i chciałbym skupić się na problemach konfiguracyjnych FreeRTOS