cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
2,787 Views
Registered: ‎07-09-2010

Cannot build application with LwIP 2.0.2 / FreeRTOS 10 on Vivado SDK 2018.2

Hi everyone,

I'm trying to build an application on a Microblaze platform with DDR for a very basic TCP/IP application using FreeRTOS and LwIP 2.0.2 in SDK 2018.2.  In the hardware I've included one each of tmrcntr, UARTlite and an EthernetLite blocks in the hardware design.  I'm implementing the design on an Arty A35 board.  I'm using the Socket AIP for LwIP and I've set this in the BSP settings. 

I'm trying to build the basic echo server application on my hardware platform, and I've kept the default BSP build settings apart from:

  1. Turned DHCP and ARP Checking off as I'm using a static IP address for the board.
  2. Set the phy link speed to 100Mbps, rather than to autonegotiate.

I've also modified the xadapter.c file in the LwIP202 library to include support for the EthernetLite IP block which appeared to be missing:

https://github.com/Xilinx/embeddedsw/pull/48

 

When I run the build I get the following errors:

cannot find -llwip4 smb_dcu_freertos
fatal error: lwip/timers.h: No such file or directory xemacliteif.c /smb_dcu_freertos_bsp/microblaze_0/libsrc/lwip202_v1_1/src/contrib/ports/xilinx/netif line 65
make: *** [microblaze_0/libsrc/lwip202_v1_1/src/make.libs] Error 2 smb_dcu_freertos_bsp
make: *** [smb_dcu_freertos.elf] Error 1 smb_dcu_freertos
make: Target `all' not remade because of errors. smb_dcu_freertos_bsp
make[1]: *** [xemacliteif.o] Error 1 smb_dcu_freertos_bsp
make[1]: Target `libs' not remade because of errors. smb_dcu_freertos_bsp

So it appears that the lwip/timers.h file isn't being generated for the BSP. Is this a bug or is this down to way I've configured the BSP settings?

Any help would be gratefully received!

Thanks,

Dan

0 Kudos
17 Replies
Highlighted
Explorer
Explorer
2,785 Views
Registered: ‎07-14-2014

Hi,

I've been looking at this with someone else in another thread I think.

Lwip 2.0.2 seems to have changed timers.h to timeouts.h and I think the relevant part of the Xilinx port of LWIP for the xemaclite port needs to be updated accordingly.

Try changing the failing #include to point to "lwip/timeouts.h" and see if that works.

Regards

Simon

0 Kudos
Highlighted
Visitor
Visitor
2,757 Views
Registered: ‎07-09-2010

I've tried changing the #include in the xemacliteif.c to point to lwip/timeouts.h rather than lwip/timers.h as you suggested, and this does build. When I run the program it looks like it gets as far as opening a port and the ethernet lights flash as expected on my board:

image.png

However, I cannot ping the board from the host (IP address configured to 192.168.1.11), I just get 'Reply from 192.168.1.11: Destination host unreachable':

image.png

Nor do I get a reply from the echo server if I connect to it via telnet.

So I'm a little bit further on but not quite there yet. By the way I should say that I've had the echo server application working with the LwIP 2.0.2 raw API, so I'm pretty sure my HW platform from Vivado is good.

Regards,

Dan

0 Kudos
Highlighted
Explorer
Explorer
2,748 Views
Registered: ‎07-14-2014

Can't say I have much experience with the echo server, but judging from the Destination Host unreachable message I would hazard a guess that there is some sort of ARP/MAC address issue (ARP request not being received/response not being sent or some other MAC address related issue, possibly)

Regards

Simon

0 Kudos
Highlighted
Visitor
Visitor
2,740 Views
Registered: ‎07-09-2010

That appears to be the case, if I look at the ethernet traffic using Wireshark there are a lot of broadcast ARP requests being sent out by my host, but the FPGA never sends a response:

image.png

Hence the ping fails because my host doesn't know the MAC address of my FPGA, which makes sense.  I'm assuming that indicates the ARP requests are not being processed by the FPGA, possibly due to the timers not being set up correctly?

Dan

0 Kudos
Highlighted
Explorer
Explorer
2,723 Views
Registered: ‎07-14-2014

Hi,

I don't think it is likely to be timer related. The timeouts.h file contains pretty much exactly what timers.h contained plus a bit extra. There shouldn't be much involvment of timers with an ARP request/response. I would suspect something else.

From what you have described it looks like either the stack is not receiving any data at all (interrupt not going off or not being handled correctly) or it is receiving and processing data but the Tx end is not running properly.

Check to make sure that the MAC interrupts are firing and being processed first. There are some debug levels you can turn on in LWIP to get it to print out every packet is receives so you can see what is going on. Might be worth doing that as well(apologies if I'm stating the obvious).

Regards

Simon

0 Kudos
Highlighted
Explorer
Explorer
2,721 Views
Registered: ‎07-14-2014

Also, just noticed at the top of your post that you mention have turned off ARP checking in the BSP. What do you mean by this? Which setting is it that you have turned off?

Just checking as even for fixed IPs, ARP is necessary for the ethernet layer of the network traffic

Simon

0 Kudos
Highlighted
Participant
Participant
2,705 Views
Registered: ‎10-22-2018

I am experiencing the same set of issues that you are describing, and had described in another post.     With a few more heads on teh problem i hope we can solve it now

0 Kudos
Highlighted
Contributor
Contributor
2,691 Views
Registered: ‎02-15-2014

All these questions  are understanding the compiler and IDE environment. That is a steep and not easily  documented journey. 

It is hard ! and if you are new to the game, harder.

As for LWIP on FreeRTOS ? LWIP is design for  tiny microcontrollers and single threaded program loops. LWIP is fight you every step of the way .

There is a far superior +TCP  IP stack, highly parameterizable and integrated into FreeRTOS... Suggest using the +TCP version of FreeRTOS . All the hints you will need to port the driver will be in LWIP.

I am working on a FreeRTOS +TCP port for the Arty7 PCB, when I receive my Arty.

Glen.

 

0 Kudos
Participant
Participant
2,683 Views
Registered: ‎10-22-2018

Thanks Glen, thats going to be really helpful.   That was my end goal, i was trying to make LwIP work as an intermediate step.   

My understanding was that that LwIP got used a long time ago ( before freertos_plus ) and its never been updated. Maybe there just was'nt a compelling reason.

 

0 Kudos
Highlighted
Participant
Participant
2,667 Views
Registered: ‎10-22-2018

If you have a look at this post on the Arty Forums, 

https://forum.digilentinc.com/topic/1312-arty-running-microblaze-on-freertos/

It seems you can make it work, but there is some issue in that it takes more than a minute before the device responds..     there are a few mods to make. 

0 Kudos
Highlighted
Explorer
Explorer
2,606 Views
Registered: ‎07-14-2014

Hi,

The long time to reply problem I may have an explanation for. I currently use FreeRTOS and the lwip stack on a Kintex 7 based microblaze system and after some initial problems like this (where it would sometimes take an age to respond) I did some digging).

It turns out that the xilinx port of lwip seems (in my opinion) to have a small bug when the emaclite interface is configured to have more than one buffer. Problem seemed to occur when back to back packets were on the wire. The ISR didn't account for another packet arriving whilst the first was being processed and didn't check the other buffer before clearing the ISR. This meant that a packet was getting stuck in the system. Had to tweak the lower level code to get around this and since then I have never had a dropped packet.

As for FreeRTOS+TCP I'm not sure that there is a Microblaze port for this yet. As I understand it from the forums, someone may be working on it but not sure of the status.

I think the problems you are having stem from recent lwip updates but the xilinx port feels like it has not been tested with these updates and may need some attention.

If I get some spare time, I'll see if I can donwload 2018.2 and spark up our KC705 development board and see what I can get to work.

Regards

Simon

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,603 Views
Registered: ‎12-21-2016

This issue is fixed in 2018.3, for 2018.2 refer the following AR for the patch

https://www.xilinx.com/support/answers/71330.html

Regards,
Raju
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.

0 Kudos
Highlighted
Visitor
Visitor
2,573 Views
Registered: ‎07-09-2010

Thanks everyone for all of the replies!

I myself am coming from the FPGA world into Microblaze and embedded C and it seems the choice of different TCP/IP stacks and OSes etc, plus the fact that theres a lot of outdated information out there means its a very steep learning curve for a newbie like me!


@rajut wrote:

This issue is fixed in 2018.3, for 2018.2 refer the following AR for the patch

https://www.xilinx.com/support/answers/71330.html


Thanks Rajut, I had already applied this patch to the xadapter.c file, because without it I couldn't even get the echo server application to build.

Simon, with regards to the changes I made to the ARP settings, it was only the DHCP switches in the BSP settings I changed (lwip_dhcp and dhcp_does_arp_checking under dhcp_options both set to false). I'm sure when I first built the application I got errors indicating I should turn these off, which is why I disabled them (and the fact I wanted my Arty to have a static IP address).  However, I've set these switches both back to true and the application does build, and now I can ping my Arty board:

ping.jpg

Well, 3 out of 4 pings received anyway, so a bit flaky still.

I also tried the echo functionality via telnet, and that works on and off - as mentioned there is a significant delay (~10 seconds) before the text is echoed back:

echo.jpg

So I guess that's some progress.

Thanks,

Dan

0 Kudos
Highlighted
Explorer
Explorer
2,567 Views
Registered: ‎07-14-2014

Hmm,

There's something else going on here, but I can't quite put my finger on it at the moment.

I have the older lwip running on a microblaze (running at 100MHz) with FreeRTOS and have sub 1ms ping times.

Is you EthernetLite block configured to use 0 or 1 buffers? As I mentioned further up (or was it in another thread) I had issues with packets that arrived close together. (Laptop was spewing enough other stuff that caused ping and some other packet to arrive close together) and one packet would get stuck in a buffer, until something else arrived, causing somewhat random delay times.

I can post my modifications if you think it might help

Regards

Simon

0 Kudos
Highlighted
Visitor
Visitor
2,547 Views
Registered: ‎07-09-2010

Hi Simon,

My ethernetlite block is configured with the RX and TX buffers set to 1.  To be honest I hadn't noticed the ping response times, but now you've pointed it out they are ridiculously slow.

So as you intimated I changed the RX and TX buffers setting in the Ethernetlite block to 0, and this has reduced the ping response times dramatically:

ping2.jpg

The echo server also responds a lot quicker now, although it echoes each character back as it is typed rather than waiting for a line return as it did before.

So I think I have the example working as it was intended to work now.

Thanks,

Dan

0 Kudos
Highlighted
Participant
Participant
2,519 Views
Registered: ‎10-22-2018

My results were very strange.  I'm not getting a UART,  and i'm only getting about 1 in 10 Pings and thye are very long.  the echo server did eventually reply, but it was in minutes!



0 Kudos
Highlighted
Explorer
Explorer
2,497 Views
Registered: ‎07-14-2014

Did you try checking the Rx and tx buffer settings like dharman above?

Failing that you might need to try and turn on the lwip debug at the IP level and see what packets you are receiving and when.

Simon

0 Kudos