Anyone get lwIP working with Processor Expert yet?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Anyone get lwIP working with Processor Expert yet?

Jump to solution
1,650 Views
dave408
Senior Contributor II

I hate to cross-post, but I could really use some help with getting the TCP/IP stack working with lwIP and PEx.  I posted in the Processor Expert forum, but haven't gotten any responses yet, and since this forum has a reasonable amount of traffic, I thought I'd link to my original post here.

Assistance needed with lwIP + PEx + KSDK

In a nutshell, I believe I have correctly converted the FSL lwip_tcpecho demo application over to work with KSDK 1.1, PEx, and MQX, but even though the code compiles and runs, and stepping through the code line by line seems to be very similar or identical between the two applications, the demo app works (I can ping and connect via telnet), my app doesn't.

I've also attached my application here.  Hopefully, someone can take a look and see what I'm doing wrong.  In addition, maybe it will help others trying to use lwIP to get a little bit farther with their projects...

Original Attachment has been moved to: k64lite_lwip_pex_mqx.zip

0 Kudos
1 Solution
965 Views
dave408
Senior Contributor II

I've gotten my project to work now, but I'm not sure how.  One major piece was Marek's observation that I hadn't connected the pins in PEx (duh!).  But after that it still didn't work.  Last night, I was trying to resolve the include conflicts, and in the process of doing that (but still having the compiler warnings) I got it working.  The problem is... I'm not sure how.  My basic approach was to ensure that my PEx project from scratch included all of the same paths as the lwIP example code, and I also favored Generated Code over other paths, followed by favoring KSDK_PATH paths over SDK paths (those copied to the project via the new project wizard).  I'm still working on it and am gradually optimizing the path list and checking for functional code along the way.

View solution in original post

0 Kudos
7 Replies
965 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi Dave408,

I tried to compile your project, but got some error and many warnings, so I am wondering if you uploaded the correct project because you said the code can be compiled and run well, would you please help to clarify?

Untitled.png

Thanks for your patience!

Have a great day!

Kan

0 Kudos
966 Views
dave408
Senior Contributor II

I've gotten my project to work now, but I'm not sure how.  One major piece was Marek's observation that I hadn't connected the pins in PEx (duh!).  But after that it still didn't work.  Last night, I was trying to resolve the include conflicts, and in the process of doing that (but still having the compiler warnings) I got it working.  The problem is... I'm not sure how.  My basic approach was to ensure that my PEx project from scratch included all of the same paths as the lwIP example code, and I also favored Generated Code over other paths, followed by favoring KSDK_PATH paths over SDK paths (those copied to the project via the new project wizard).  I'm still working on it and am gradually optimizing the path list and checking for functional code along the way.

0 Kudos
965 Views
dave408
Senior Contributor II

The other thing worth noting is that the lwip tcpecho demo application that I based my project off of also has a bunch of similar compiler warnings.  So maybe that isn't the cause of my problems anyway, but I still need to go through it and try to make sense of the conflicts.  If anyone can explain how to work around this, that would be much appreciated.  In the meantime, I'll go through the files and will try to change the project settings and include directories to make the warnings go away.

EDIT - I went ahead and looked into the lwIP tcpecho demo to determine the source of the multiple definitions.  It looked related to the fact that the stdio.h used was the one in the output folder.  I deleted all of the include paths that pointed to the output folder and instead added the necessary paths from the KSDK.  After making these changes, all of those compiler warnings went away.

The problem is that my PEx-based project is already including the paths that I think are correct, yet it has these problems.  It will require some more investigation.

0 Kudos
965 Views
dave408
Senior Contributor II

Kan, I'm not sure how to resolve this problem.  Perhaps my sample program has more SDK files included than it should?  The problem is that mqx_stdlib/source/include/std_prv.h #includes nio.h.  nio.h #includes errno.h.  But lwIP #includes arch.h, which has the same error codes, but the values are different.  Should I be removing some of the files that the wizard included if I'm using lwip?  Or do you have access to, or can you create an example that uses lwIP with PEx?

0 Kudos
965 Views
dave408
Senior Contributor II

Hi Kan, I'll take a look.  I do get those same warnings.  I'm glad you brought this up, because I looked into it again, and apparently the values are different in the conflicting files.  When I looked into this over the weekend, I could have sworn the conflict was coming from two different files with the same contents, so I didn't pursue a fix then.

The problem here is that arch.h used by lwIP has contents that conflict with errno.h in /rtos/mqx/mqx/source/nio.  I'll try playing with the include directories to get around this.

I'm not sure why you get a build error, though.  Can you post a screenshot of your console output?  That will have more detail around the cause of the error.

0 Kudos
965 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi Dave408,

The error message is as below:

Untitled.png

and I am not expertise for LwIp, so I am not familiar how to create an LwIp application, but in my opinion , you may start from BM application, that is without any RTOS, you know , most of the warnings are from the conflicts between LwIp lib and MQX lib, so how about bring up a BM application at first? maybe it would make things easier.

Hope that helps,

Kan

0 Kudos
965 Views
dave408
Senior Contributor II

Kan, it looks like you're getting bitten by the 8192 maximum character command line problem in Windows.  The file is called fsl_mpu_common.o, and when characters magically get removed from filenames, that's a pretty good indication that it's the 8192 char problem.

Please see Erich Styger's post here on how to fix it the easy way.

0 Kudos