STM32F407 DP83848 Raw vs Netconn-FreeRTOS

[Klaus L. (keyel80)]

Hallo Forum,

ich habe an meinen STM32f4-Discovery erfolgreich ein Waveshare 
DP83848-Board anschließen können und ohne zu großen Aufwand das Beispiel 
"LwIP_HTTP_Server_Raw" für das "STM324xG_EVAL" aus der 
"STM32Cube_FW_F4_V1.1.0" portieren können. Ich nutze meine Toolchain aus 
http://klaus4.blogspot.de/ .

Nun wollte ich die nächste Stufe erklimmen und auch das 
"LwIP_HTTP_Server_Netconn_RTOS"-Projekt portieren, das ja mit FreeRTOS 
als Basis läuft.
Hier beiße ich mir jedoch die Zähne aus und hoffe auf Eure Hilfe. Mein 
klassischer erste Test ist ein PING, der ja mit einem ARP-Request 
beginnt.

Mit dem Debugger konnte ich feststellen, dass der Request empfangen wird 
und auch eine Response aufgebaut wird. In der Datei smt32f4xx_hal_eth, 
Funktion HAL_ETH_TransmitFrame, sollte dann durch die folgende Zeile 699

(heth->Instance)->DMATPDR = 0;

die Response zurück gesendet werden. Dies konnte ich auch in der 
RAW-Variante mit Wireshark auch so nachvollziehen. In der 
FreeRTOS-Netconn-Variante passiert jedoch schlicht und ergreifend 
nichts...

Soweit ich das überblicken kann, sind Kontrollfluss und Variablenwerte 
in dieser Funktion in der RAW und der FreeRTOS-Netconn-Variante 
identisch. Ich stehe nun vor einem Wald an Registern und Deskriptoren 
und weiß nicht, wo ich hier suchen muss. Wer ist bereit, meinen Blick 
hier etwas zu schärfen?

Danke für Eure Hilfe
Klaus

[Klaus L. (keyel80)]

Hallo zusammen,

ich habe heute durch einen zeilenweisen Vergleich des Quellcodes 
festgestellt, dass ich einige GPIOs nicht korrekt initialisiert haben. 
Das Problem war natürlich schnell behoben und die Sache läuft:-)

Ein wenig unschön ist, dass das DP83848 den Interrupt-Anschluss nicht 
nach außen führt und ich leider gezwungen bin, permanent im 20ms-Zyklus 
nach neuen Daten zu fragen.

Grüße
Klaus

[Martin K. (martinko)]

Klaus L. schrieb:
> Hallo zusammen,
>
> ich habe heute durch einen zeilenweisen Vergleich des Quellcodes
> festgestellt, dass ich einige GPIOs nicht korrekt initialisiert haben.
> Das Problem war natürlich schnell behoben und die Sache läuft:-)
>
> Ein wenig unschön ist, dass das DP83848 den Interrupt-Anschluss nicht
> nach außen führt und ich leider gezwungen bin, permanent im 20ms-Zyklus
> nach neuen Daten zu fragen.
>
> Grüße
> Klaus

Hi,

Du brauchst nicht im 20ms Zyklus nach Daten fragen. Das einzige was der 
Dir liefert ist die Information zum Ethernet Link und dessen Parameter. 
Also ob Kabel eingesteckt oder nicht, ob 100MBit oder 10, ob Vollduplex 
oder halb. Diese Infos reichen Dir sicher auch im 200ms Zyklus oder 
mehr.

Gruß Martin

[Klaus L. (keyel80)]

Hallo Martin,

vielen Dank für Deine Nachricht. Ja, Du hast recht! Ich habe die 
Interrupt-Handler im Beispielprojekt mal bis an ihre Quelle 
zurückverfolgt und mir auch nochmal das Handbuch des DP83848 zu Gemüte 
geführt und kann Deine Aussage bestätigen: Der Interrupt, der die 
Empfangsroutine per Semaphore freischaltet, kommt nicht über den Pin 7 
des dp83848, sondern sollte aus dem Mac-Modul des STM32 kommen.

Ich habe meinen Code wieder in den Ursprungszustand zurückversetzt und 
insbesondere auch einen Breakpoint in diese Methode gesetzt:

void ETH_IRQHandler(void)
{
  ETHERNET_IRQHandler();
}

Mir einem kleinen Umweg über den HAL wird die Funktion 
HAL_ETH_RxCpltCallback aufgerufen, die die Semaphore freigibt:

void HAL_ETH_RxCpltCallback(ETH_HandleTypeDef *heth)
{
  osSemaphoreRelease(s_xSemaphore);
}

Sobald ein Paket im MAC angekommen ist, sollte die CPU also in 
ETH_IRQHandler springen und damit die weitere Verarbeitung triggern. 
Leider passiert dies nicht. Der Code ist mit ganz geringfügigen 
Anpassungen dem ST-Beispiel "LwIP_HTTP_Server_Netconn_RTOS" entnommen. 
Grundsätzlich funktioniert die Sache ja auch, wenn man eben nicht über 
den Interrupt geht, sondern den MAC alle 20ms pollt.

Wo sollte ich mit der Fehlersuche am besten beginnen?

Viele Grüße
Klaus

[Klaus L. (keyel80)]

Hallo zusammen,

ich habe mich nochmals tiefer vorgearbeitet und mir die Register des 
ETH_DMA angeschaut.
NACH der Initialisierung ist ETH_DMAIER->NISE und ETH_DMAIER->RIE auf 
true.
Das ETH_DMATST->RS ist false.

VOR dem Anpingen bleibt ETH_DMATST->RS auch auf false.

NACH dem Anpingen ist ETH_DMATST->RS auf true.

Bis hierhin ist alles korrekt und läuft so, wie ich das erwartet habe.

Im startup_stm32f407xx.asm wird die "ETH_IRQHandler"-Methode als 
Event-Handler definiert. Diese ist in stm32f4xx_it.c implementiert, ein 
Breakpoint darin wird jedoch nie erreicht.

Wo und wie kann der Aufruf dieser Handler-Methode gehemmt werden?

Danke für Eure Hilfe!

Klaus