10 years, 5 months ago.

LWIP on the LPC4088

I have downloaded the TCPSocket_HelloWorld application onto an LPC4088 board in order to proto-type some TCP/IP traffic applications that I will need.

I left the configuration of the app to use DHCP and it is on a network with a DHCP server. What I have observed is that the TCP/IP stack is able to send but unable to receive correctly. The packet reception is having a problem in file lpc17_emac.c in function lpc_low_level_input(). When the status info is checked 2 errors are always present (EMAC_RINFO_SYM_ERR and EMAC_RINFO_CRC_ERR). The received packet is then dropped.

All packets are showing this error on the lpc4088 board. However their is another device on the same network and it has no problems receiving packets (they are the DHCP packets to setup the network information).

I have removed this error checking just to see what happens and then the packet does actually make it up to the TCP/IP layer but runs into other problems.

I guess what I need to know is should this driver work with the LPC4088 board? Are the MAC's the same or am I going to have to write my own MAC layer.

Cheers!!

Question relating to:

Official mbed lwIP library (version 1.4.0) arp, DHCP, icmp, ip, lwip, PPP, TCP, UDP

It is working when I'm running this application on the LPC4088 QuickStart Board. Have you updated the libraries in the application? you update these by clicking on the library (e.g mbed+rtos) and then the Update button in the right part of the compiler window.

posted by EmbeddedArtists AB 03 Jun 2014

I can create, download and run successfully the app from the Browser/Compiler for both the LPC4088 QuckStart Board and the LPC1768 board running with the Embedded Artist board.

I then export the app for either of the 2 boards (making sure to get the correct architecture) to my Xpresso IDE. I then compile the app and load it onto the board and run it. For the LPC4088, I get the problems listed above. I have not debugged the problems with the LPC1768 board as thoroughly (my target is the LPC4088) but it never makes it out of the initialization of the network interface and never sends a packet.

I guess I really need someone who has this working or has seen it working to try the same thing. Export the project TCPSocketHelloWorld to one of the 2 boards (preferably the LPC4088) and using NXP's Xpresso IDE compile, download and run the application. A report on which version of the Xpresso platform and the toolchain would be helpful as well.

My Xpresso Version is: LPCXpresso v7.2.0 [Build 153] [2014-05-19] Toolchain: arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 4.8.3 20140228 (release) [ARM/embedded-4_8-branch revision 208322]

Cheers!!

posted by John Dowd 05 Jun 2014

So, more investigation has been done and I believe I have identified a bug in the toolchain/IDE of LPC Xpresso.

I brought up a VM for Ubuntu Linux and downloaded the mbed project mentioned above for the gcc-arm environment. I compiled and flashed the image into the LPC4800 and it worked. This I believe, removes the problem from the mbed source code repository and how it gets bundled for export. So now the problem lies somewhere in the LPC Xpresso product.

I did not test the LPC1768 board using the gcc-arm environment.

I tried the same project but this time with the 6.x version of LPC Xpresso and it does not work with that IDE either (and therefore it's toolchain).

I'll be pursuing the rest of my inquiries with NXP. Thanks for all of your time.

Cheers!!

posted by John Dowd 05 Jun 2014

1 Answer

10 years, 5 months ago.

The problem seem to be an alignment problem. There are compiler specific settings in the networking code that has to do with setting up the memory area used by the EMAC driver. The aligned keyword is missing when setting up this region when using GCC compiler.

  1. Open EthernetInterface/lwip-eth/arch/TARGET_NXP/lpc17_emac.c
  2. Search for ETHMEM_SECTION
  3. Change row 141 to look like below (i.e. add the aligned keyword)

​#     define ETHMEM_SECTION __attribute__((section(".data.$RamPeriph32"), aligned))

Accepted Answer

Will you issue a new pull request for this fix? Thanks.

posted by Martin Kojtal 09 Jun 2014

Yes, I will issue a pull request, but I would like the customer to test the fix first to make sure it solves his problem. It solved the problem I could reproduce.

posted by EmbeddedArtists AB 09 Jun 2014

Thanks for your efforts. This fix does the trick. I gather you guys will be coordinating the fix being put into the system?

Cheers!!

posted by John Dowd 09 Jun 2014

A pull request has already been issued and also merged into the SDK. I don't know when it will be available in the online tools.

posted by EmbeddedArtists AB 09 Jun 2014