Po uporaniu się z (banalnym jak się okazało) problemem z Ethernetem na
płytce z PIC32MZ zabrałem się za podobny układ na STM32F407. Tutaj znów
trafiłem na dziwny problem, tym razem jednak prawie na 100% software'owy.

Sytuacja wygląda następująco: jakiś czas temu zaprojektowałem płytkę pod
proste radio internetowe na STM32F107 + DP83848 + VS1003. Płytka działa
idealnie. Na chwilę obecną mam na niej FreeRTOS + lwIP + FatFS + własną
aplikację klienta TCP do odbierania streamów z Internetu. Jest też
serwer HTTPD (ten z pakietu lwIP, włączony przez kliknięcie odpowiedniej
opcji w CubeMX). Serwer na chwilę obecną udostępnia jedynie kilka
statycznych stron, w wolnej chwili będe musiał dopisać funkcje CGI.

Na chwilę obecną wszystko to działa poprawnie i stabilnie, jednak płytka
dość szybko okazała się być zbyt ciasna - w tej chwili wykorzystanie
pamięci RAM dochodzi do 90% i chociaż jeszcze nie powoduje to problemów
ze stabilnością, postanowiłem przenieść się na coś większego.

W jeden weekend powstała więc kolejna rewizja, z STM32F407.
Przeniesienie projektu nie powodowało większych problemów. Konfigurację
pinów i peryferiów wyklikałem na nowo w CubeMX i wygenerowałem kod.
Ethernet ruszył z miejsca. Potem zacząłem uruchamiać kolejne
funkcjonalności i przenosić swój kod. Wszystko działało poprawnie.

Do momentu, aż nie postanowiłem odpalić także serwera HTTPD. Kliknąłem
opcję w CubeMX, wygenerowałem kod, dodałem plik fsdata.c (obraz
udostępnianych stron), dodałem wywołanie httpd_init(). Wszystko tak jak
w starym projekcie.

Po wgraniu skompilowanego kodu na płytkę okazało się, że serwer nie
tylko nie chce działać, ale także zawiesza całą resztą. W momencie próby
wejścia na stronę oprogramowanie przestaje reagować - nie wykonuje się
mój kod a urządzenie przestaje być widoczne w sieci i nie odpowiada na
pingi. Jeśli tylko zakomentuję wywołanie httpd_init(), problem znika.

Przyjrzałem się bliżej problemowi, podpiąłem debugger żeby zobaczyć, czy
przypadkiem program nie utyka w jakiejś nieskończonej pętli, jednak
wszystko wskazywało na to, że FreeRTOS nadal działa.

Spróbowałem więc innego podejścia i dodałem w różnych taskach cyklicznie
wywoływane printy.

W tej chwili mam dwa taski utworzone przeze mnie:
MainTask - priorytet "Normal", tam odbywają się wszystkie operacje
związane z moją aplikacją.
IoTask - priorytet "Idle", jak sama nazwa wskazuje przeznaczony do
obsługi interfejsu użytkownika. W tej chwili jest tam kilka operacji, a
na końcu każdego przebiegu pętli wywoływane jest osDelay(20).

Do tego w tle swoje własne taski tworzy m.in. lwIP oraz sterownik USB.

Okazało się, że w momencie podjęcia próby wejścia na stronę przestają
wykonywać się printy z MainTask, ale te z IoTask nadal są wykonywane.

Pierwsza myśl jaka przyszła mi do głowy to problemy ze stosem, jednak:
- TOTAL_HEAP_SIZE w FreeRTOS/Config parameters w jest ustawiony na 20kB.
W starym projekcie było trochę ponad 14kB.
- Stosy tasków mają rozmiary takie jak w projekcie z działającej płytki,
wliczając w to rozmiary stosów bibliotek, które mogę ustawić w ich
konfiguracji.
- Próbowałem manipulować rozmiarami stosów i TOTAL_HEAP_SIZE, w pewnym
momencie zwiększając je dwukrotnie. Nie pomogło.
- Nie pomogły też eksperymenty z różnymi opcjami Memory Management
scheme. W tej chwili jest domyślna (heap_4) - ta sama co w starej wersji
projektu.
- Próbowałem też podnieść rozmiar MEM_SIZE w ustawieniach lwIP z
domyślnych 1600 bajtów do 10 kB. Nie pomogło.

Przeglądałem konfiguracje starego i nowego projektu, ale żadna istotna
różnica nie rzuca mi się w oczy. Pewnie chodzi o jakiś drobiazg, którego
nie potrafię zauważyć. Jest tutaj ktoś, kto na podstawie przedstawionych
objawów mógłby wskazać potencjalne źródło problemu?