Witam

Po tygodniowej walce popołudniami z CubeMX i Ethernetem zdecydowałem się założyć temat bo z STM i CubeMX doświadczenie mam zerowe a coś jest nie tak i nie mogę dojść co.
Mam pewne doświadczenie zawodowe w tworzeniu aplikacji typu bare metal z obsługą ethernetu bez dodatkowych bibliotek obsługi stosu tcp/ip (na podstawie przykładowego projektu gdzie było wykorzystane LwIP) na rdzeniu ARM.
To samo chciałem wykonać tutaj tzn. otrzymać działający projekt z LwIP do przetestowania sprzętu a potem docelowo napisać obsługę tylko ARP, ICMP, UDP, TCP. Problem w tym, że wygenerowany w CubeMX projekt nie działa i za bardzo nie mam na czym się oprzeć.

Sprzęt:
Testy przeprowadzane na "pająku" z STM32F407VET6 wlutowanym na płytkę uniwersalną, płytce stykowej (jako szyna rozprowadzająca zasilanie) oraz układem PHY DP83848. Wykorzystany programator ST-Link z Nucleo.
Układ to typowy pająk zajmujący pół biurka.

Testy przeprowadzone również na STM32F4 Discovery tylko z podpiętym DP83848 na kablach w celu wyeliminowania błędów z połączeniami, zasilaniem, itp.

Oprogramowanie: CubeMX wersja 4.20.1, biblioteki HAL, edytor System Workbench for STM.

LwIP skonfigurowany do DHCP; na wiresharku widzę, że zostaje wysłany 1 pakiet i potem następuje totalna cisza. Zmieniłem adres mac w celu weryfikacji i mac w pakiecie również się zmienił.
Podglądając deskryptory RX, widzę że bit OWN nie zostaje kasowany... wygląda to tak jakby DMA nie odbierało danych i nie przekazywało kontroli do CPU.

Próbowałem też wygenerować projekt bez LwIP tzn z samą inicjalizacją ethernetu. Tu dla odmiany CubeMX nie tworzy buforów na ramki czy deskryptorów. Nie wiem czy takie miało być założenie - czy resztę ma uzupełnić użytkownik według własnego uznania, czy po prostu jest to błąd Cube'a. Bez deskryptorów i buforów na surowe ramki w ogóle nie ma prawa to działać.

Dodałem te brakujące elementy, zainicjalizowałem za pomocą HAL_ETH_DMARxDescListInit(); i odpowiednika dla TX, wystartowałem ethernet komendą HAL_ETH_Start(); W pętli głównej uruchomiłem funkcję HAL_ETH_GetReceivedFrame(); ponieważ moja aplikacja miała pracować w poolingu a nie reagować na przerwanie przychodzącej ramki.

Efekt podobny jak wyżej opisałem tzn bit OWN deskryptorów jest sprawdzany w funkcji HAL_ETH_GetReceivedFramenie ale wygląda na to, że nie jest kasowany. Bufory ramek puste. Tak jakby nie działało DMA.

Posiłkowałem się notą UM1725 (Description of STM32F4xx HAL drivers) oraz Reference Manual (dział: Ethernet (ETH): media access control (MAC) with DMA controller). Nie sprawdzałem (jeszcze) dokładnie wygenerowanych funkcji inicjalizujacych z opisem konfiguracji w reference manual... może na tym etapie występuje jakiś błąd.

Z projektów które krążą po internecie jest tylko projekt bazujący chyba na bibliotekach SPL. Na chwilę obecną też go jeszcze dokładnie nie przeanalizowałem.
Tu za to znalazłem podobny opis problemu, niestety nie rozwiązany: http://www.openstm32.org/forumthread4693

Miał ktoś podobne problemy ?

Witam,

Nie wiem, czy będę pomocny, bo moje doświadczenie, jeśli chodzi o Ethernet jest zerowe, ale sporadycznie korzystam z CubeMX, głównie do generowania jakichś tam wstępnych szablonów, i bardzo często jest tak, że tego owego brakuje... W ciemno, stawiałbym, że np. nie CubeMX nie wygenerował "calbacków" do obsługi przerwań od DMA, albo wygenerował puste. Ale, w repozytorium Cube jest masa przykładów i one działają. Próbowałeś zaimportować któryś z projektów dotyczących LwIP ? Z tego co widzę, jest ich klika, co prawda na "ichni" zestaw uruchomieniowy, ale to nie powinno być problemem. Ostatecznie, jeśli nie dasz rady niczego z tym zrobić, mam działający projekt na STM32F407, ale na SPL. Daawno temu się nim bawiłem, trochę po "małpiemu" przeportowałem go z STM32F107, udało mi się go uruchomić i jakiś prosty serwer www nawet na nim działał, ale nie mam w tej chwili dostępu do niego, choć, jeśli nie będzie wyjścia, to poszukam .

Pozdrawiam serdecznie, QuadMan.

Nie miałem zbyt dużo czasu na ten temat ostatnio ale sprawa została rozwiązana.

Problem występuje gdzieś w plątaninie kabli / zasilaniu procesora na którym przeprowadzałem testy. Nie wykluczam też podrobionego uC (ściągany z Chin ). Na zestawie STM32F4 Discovery projekt ruszył. Pisząc ruszył mam na myśli pojawienie się ramek broadcast w buforach.
Czemu nie działał wcześniej ? A no dlatego że tworząc projekt w CubeMX wybrałem płytkę ewaluacyjną i odhaczałem piny tak, aby przepiąć je na Ethernet. Prawdopodobnie tu wystąpił jakiś błąd.
Odpalając na STM32F4 Discovery czysty projekt dla konkretnego uC, ze skonfigurowanym Ethernetem, po dłuższej chwili otrzymuję dane.

Interesowała mnie aplikacja bez stosu TCP/IP i tak jak wspomniałem wcześniej - w tej konfiguracji CubeMX nie tworzy buforów na ramki oraz deskryptorów. Należy je utworzyć samemu.

Konfiguracji z LwIP nie testowałem.