FreeRTOS, uIP and LPCXpresso17xx+Baseboard

[lpcware]

Content originally posted in LPCWare by rattus on Fri Aug 05 20:58:33 MST 2011
I am attempting to produce a working uIP implementation with FreeRTOS 7.01. I have taken the FreeRTOS demo for the Code Red RDB1768, and grafted in the emac.c (and others) from Micropendous, as they have an LPC1768 interface to the 8720 PHY. Code compiles clean, and debugging works OK until checking the PHY part number (emac.c line 161); the prvReadPHY routine (and the MRDD register) always returns 0xffff, and thus the lEMACInit routine fails. The MCMD manipulation sequence and MADR addresses are correct per the LPC17xx user guide.

I figure if I can't even read the PHY device number correctly, something is wrong...

Hardware is LPCXpresso1769 + EA LPCXpresso Base Board.

Thanks,

Mike

[lpcware]

Content originally posted in LPCWare by rattus on Mon Aug 08 15:17:13 MST 2011
Thanks to those who responded... it turns out that it was a simple IP address mismatch. I didn't notice that when I turned off the wireless (and lost DHCP), my machine was configured to revert to a manual 169.254.xx.xx IP address, which  conflicted with my prototype's 192.168.xx.xx address (especially with a 255.255.00.00 subnet mask on the host).

I found the problem when I was analyzing tcpdump output, and noticed my host was using an unusual address <slap forehead>

My old easyweb-based code never bothered to check addresses.

Anyway, a quick switch of the host's address and not only the demo, but all last week's code suddenly worked. ;-)

Mike

[lpcware]

Content originally posted in LPCWare by bortolomaeus on Mon Aug 08 03:38:36 MST 2011
Thanks for this

http://interactive.freertos.org/entr...or-lan8720-phy

That helped me running the RTOS uIP stack on my LPCxpresso with a 1769!

regards

nicolas

[lpcware]

Content originally posted in LPCWare by rattus on Sun Aug 07 21:18:44 MST 2011
I had set the IP to my usual IP testing address,  and made sure it was valid - having a display sure helps with debugging without resorting to printfs on a semihosting console, although I am printing other status (like data received on the console), and hoping that the timing isn't being adversely affected by the console interaction.

Not at the board at this time, will report back hopefully tomorrow.

[lpcware]

Content originally posted in LPCWare by JojoS on Sun Aug 07 17:56:55 MST 2011
ok. And its not something obvious like a wrong IP? The sample does not support dhcp, have you adjusted the ip settings?

[lpcware]

Content originally posted in LPCWare by rattus on Sun Aug 07 08:40:24 MST 2011
Thanks jstratmann. I had stumbled on the latest Code Red demo project for the RDB1768v2 in the meantime, and it also includes an 8720 version of the emac code. It returns the correct PHY ID, but is still unresponsive - the arp negotiation sequence doesn't complete. I was in the process of examining the packets to see what was up.

The easyweb demo from the baseboard project works fine, so I'm assuming my jumper settings are correct ;-)

I'll try your link and report back.

Mike

[lpcware]

Content originally posted in LPCWare by JojoS on Sun Aug 07 03:41:01 MST 2011
http://interactive.freertos.org/entries/20203123-emac-for-lan8720-phy

This code worked for me, but use the one frome the 1st comment. When this code is running, check first the return value of the PHY id. If it can't be read, I guess some jumpers on the baseboard are not set correctly.