LAN-Problem mit LPC1768

[Alram L. (alram)]

Hallo,

Ich kämpfe seit längerem mit einem Problem an meinem LPC1768 Board, wo 
ich nicht mehr weiter weiß und euch im Hilfe/Hinweise bitte.

Ich verwende folgendes:
- Mini DK2 Board 
(http://www.hotmcu.com/lpc1768minidk2-development-board-p-55.html)
- Segger JLink edu
- als Basis für mein Projekt verwende ich LPCXpresso/LPCOpen Projekte
  applikation: webserver_freertos
  board: lpc_board_nxp_lpcxpresso_1769
  chip: lpc_chip_175x_6x

In den letzten Wochen konnte ich schon recht viel von meinen 
Vorstellungen umsetzen. Kürzlich wollte ich nun weitere CAN Nodes in 
betrieb nehmen und musste daher den JLink mal an andere Board's 
anschliessen. Dabei hat das MiniDK2 Board plötzlich zum 'zicken' 
angefangen. Zwischenzeitlich kann ich das Problem genau nachstellen, mir 
aber überhaupt nicht erklären.

Auf dem Board läuft freeRTOS und der Webserver aus dem Demoprojekt. Wenn 
ich nun Projekt kompiliere und auf den Chip schreibe (via JLink), 
funktioniert der Webserver einwandfrei. Ich kann den Chip resetieren 
(via reset Taster am Board) - kein Problem, alles funktioniert 
weiterhin.

ABER: Schalte ich das Board aus (sprich stromlos machen) und dann wieder 
ein, reagiert der Webserver auf keine Anfragen via LAN. Das RTOS läuft 
aber soweit einwandfrei (Taster reagieren, Display funktioniert normal, 
CAN Bus funktioniert, Debugausgaben auf UART kommen am PC an). Nur auf 
LAN Anfragen von aussen reagiert das Board einfach nicht.

Erst wenn ich den JLink Commander (JLink.exe) starte (und mehr braucht 
es nicht!), dann reagiert der Webserver plötzlich. Es braucht keinen 
Reset des Prozessors; Einfach nur die Verbindung vom JLink reicht aus. 
Beende ich den JLink Commander mit "exit", reagiert das Board schon 
wieder nicht mehr auf LAN Anfragen. Das Spielchen läßt sich beliebig oft 
wiederholen. Ziehe ich das JTAG Kabel vom Board ab, während JLink.exe 
gestartet ist, bleibt der Webserver funktionstüchtig. Der Webserver 
funktioniert nun auch, wenn ich die Reset Taste betätige und uC neu 
startet. Bis der uC einmal stromlos gemacht wurde, funktioniert nun 
alles. Ziehe ich den JTAG Kabel vom Board ab, während JLink.exe nicht 
gestartet ist, funktioniert es nie.

Da nicht nur der Webserver betroffen ist, sondern auch ein neuer Task 
von mir, welcher auf eine TCP Netzwerkverbindung wartet, hab ich mir mal 
die Debugmeldungen von LWIP aktiviert (da ich das Problem eher dort 
vermutet habe). Das einzige was ich damit bisher feststellen konnte, 
dass viel zu wenige (fast keine) Pakete vom Netzwerk beim LWIP Stack 
ankommen (ich hab mich mal auf ARP Broadcasts beschränkt). Wenn 
JLink.exe gestartet ist, sehe ich am uC alle ARP Broadcasts, welche auch 
Wireshark auf meinem PC anzeigt. Ist JLink.exe nicht gestartet, sehe ich 
fast keine ARP Broadcasts am uC - aber eben nur fast keine (ich würde 
mal sagen 90% der ARP Broadcasts sieht der uC nicht).

Mein Problem ist nun: mit Debugger finde ich das Problem nicht, da JLink 
bzw. GDB Server ja nicht gestartet sein dürfen, damit der Fehler 
auftritt. Mit Debugmeldungen auf der Konsole bin ich auch nur begrenzt 
weitergekommen. In diesen Bereichen (LWIP, Ethernet, PHY) hab ich nichts 
(wissentlich) verändert.

Daher stelle ich mir die Frage, gibts eine Einstellung, welcher 
JLink.exe im uC verändert, sobald dieser mittels SWD zum uC verbindet? 
Gleichzeitig aber wieder zurücksetzt, wenn JLink.exe sauber beendet 
wird. Und einen Reset setzt diese Einstellung nicht zurück. Ein stromlos 
machen wiederum schon. Gibts so eine Einstellung?

Hat jemand eine Idee für mich, was da mitspielen könnte? Bzw. was ist zu 
tun, um den Fehler auf die Spur zu kommen?

Die Hardware hab ich mal soweit ausgeschlossen, als ich da ein zweites 
MiniDK2 Board zum testen verwendet habe. Beide zeigen identes verhalten 
...

Bin für alle eure Tipps dankbar!

vG Alram

[Jim M. (turboj)]

Alram Lechner schrieb:
> Daher stelle ich mir die Frage, gibts eine Einstellung, welcher
> JLink.exe im uC verändert, sobald dieser mittels SWD zum uC verbindet?

IIRC unterbindet es tieferes Schlafen mit dem SLEEPDEEP Bit im SCR 
Register. Das darf bei Ethernet und CAN nicht gesetzt sein, denn damit 
werden auch die entsprechenden Clocks angehalten.

[Alram L. (alram)]

Jim Meba schrieb:
> IIRC unterbindet es tieferes Schlafen mit dem SLEEPDEEP Bit im SCR
> Register. Das darf bei Ethernet und CAN nicht gesetzt sein, denn damit
> werden auch die entsprechenden Clocks angehalten.

Hi,

Danke für den Tipp. Der hat mich auf den richtigen Weg gebracht:
Das entsprechende SLEEPDEEP Bit im SCR ist bei mir zwar nicht gesetzt, 
aber in der FreeRTOSconfig.h hab ich folgende Zeile gefunden:

#define configUSE_IDLE_HOOK      1

Der IDLE Task hatte widerum ein

__WFI();

zur Folge.

Scheinbar verträgt sich __WFI() mit Ethernet nicht besonders (oder in 
dieser Implementierung).

Abgeändert nach

#define configUSE_IDLE_HOOK      0

und jetzt funktioniert vorerst bestens!

vG Alram

[holger (Gast)]

>Abgeändert nach
>
>#define configUSE_IDLE_HOOK      0
>
>und jetzt funktioniert vorerst bestens!

Mach doch einfach das __WFI(); da weg.
Der IdleHook kann durchaus nützlich sein.