11-12-2018 04:25 AM
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:
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:
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: *** [xemacliteif.o] Error 1 smb_dcu_freertos_bsp
make: 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!
11-12-2018 04:36 AM - edited 11-12-2018 04:47 AM
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.
11-12-2018 07:24 AM - edited 11-14-2018 06:48 AM
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:
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':
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.
11-12-2018 07:49 AM - edited 11-12-2018 07:50 AM
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)
11-12-2018 08:36 AM
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:
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?
11-13-2018 02:06 AM
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).
11-13-2018 02:18 AM
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
11-13-2018 10:41 AM
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
11-13-2018 12:52 PM - edited 11-13-2018 01:02 PM
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.
11-13-2018 01:11 PM
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.
11-13-2018 08:35 PM
If you have a look at this post on the Arty Forums,
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.
11-14-2018 01:22 AM
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.
11-14-2018 01:22 AM
This issue is fixed in 2018.3, for 2018.2 refer the following AR for the patch
11-14-2018 03:45 AM
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!
This issue is fixed in 2018.3, for 2018.2 refer the following AR for the patch
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:
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:
So I guess that's some progress.
11-14-2018 04:23 AM
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
11-14-2018 07:21 AM
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:
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.
11-14-2018 04:28 PM - edited 11-15-2018 01:18 AM
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!
11-16-2018 02:32 AM
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.