FreeRTOS with UDP stack

bruce4243 wrote on Thursday, August 13, 2015:

Hello,

I need to get UDP running on a Zynq processor with the FreeRTOS. I have been working on trying to get the +TCP Zynq port up and running. I appreciate you sending us the Zynq port before it is actually
posted, the network stack is something we need to get tested and running.

The code has been integrated in 3 steps:

  1. Update the OS from 8.0.0 to 8.2.1
  2. Pull in the +TCP/IP files, source and includes, but not the low level
    emac files
  3. Pull in the emac files

Step one seems to have gone OK, for the most part our application is still
running as expected. The version was upgraded by copying over the FreeRTOS files you emailed to replace the version 8.0.0 that was running here. Step two took a little more work due to the amount of files and some naming conventions. I think this is working, and with stubbed out network interface functions that the stack will initialize. The third step is where it comes apart. It seems that at the lowest level there has been a lot of good work done to enhance the functions themselves, as well as renaming of
variables/functions. There is also some dependency on other projects such as
the FAT etc. It quickly became difficult to get it working.

Another approach was to upgrade the version to 8.2.1, use the +UDP
stack that comes with 8.2.1, and take the network interface and low level
emac files from the drop you emailed. That had its own set of issues,
especially in the buffer_management.c files. Again it was a lot of reworked
functions etc.

Note that the heap_4.c was used when required.

Unfortunately for us the demo you provided can’t be opened here. There is
some tooling (SDK) problem. The SDK actually crashes when trying to build
the demo. So it seemed a good path to integrate the + code into an existing
project that is running.

The UDP functionally is actually all that is needed, I’m wondering if you
see an easier way to achieve this? Perhaps the approach being taken is not
the best one, can you provide input? I know the +TCP/IP Zynq port is still
in the lab, do you have some estimate of when it might be released? Do you
see a more clean way to proceed on getting the FreeRTOS with a UDP stack
running?

Thank you

rtel wrote on Friday, August 14, 2015:

The version was upgraded by copying over the FreeRTOS files you emailed to replace the version 8.0.0 that was running here

That should be fine.

Step two took a little more work due to the amount of files and some naming conventions.

The easiest way of doing this is to simply open the project that was sent, as that is already correctly configured and contains the correct files, include paths etc. . . . but:

Unfortunately for us the demo you provided can’t be opened here.

Which version of the SDK are you using? 2015.2 is required, and is freely available from the Xilinx website.

It seems that at the lowest level there has been a lot of good work done to enhance the functions themselves, as well as renaming of variables/functions

The project uses (references) a BSP project that is generated by the SDK. None of the files in the BSP project have been edited. Some of the files have however been copied into the driver layer, and edited there. The versions in the driver layer are then used by the compiler, instead of the versions in the BSP project, as C will only bring functions out of a library if they are not used anywhere else. There should not be any dependencies on the FAT code in the TCP driver code.

Another approach was to upgrade the version to 8.2.1, use the +UDP
stack that comes with 8.2.1, and take the network interface and low level
emac files from the drop you emailed

I think that would be harder, as the interface will not be the same.

Regards.

bruce4243 wrote on Friday, August 14, 2015:

Hello,

Thank you for the fast reply. I am using the SDK 2015.2 version, but I think there is some issue here with system patches causing SDK to crash after I import your project and attempt to open any file. This is not an issue with your code; it’s an unfortunate problem on my side.

I had tried to pull your demo TCP/IP code out into an existing project I have, but was not able to resolve all the issues I had. It just seemed to fall apart once I got to the low level driver files. This existing project started out as an 8.0.0 and then was patched using the files in the drop you emailed. I was able to run the project after patching, and before trying to add any network files. Maybe this is not the best way to proceed. For the demo, is all of the code that is necessary in the drop you emailed, or do I need to use that drop to patch the 8.2.1 download from the FreeRTOS site? In other words, should I be able to get a demo going with only the drop you emailed. If that is the case maybe it’s better to import your BSP and demo, try to build that with the version of SDK I can actually get working.

Also, I see that you have some tcp_server code in the demo, is there a #define that turns that off? I see one to use only UDP in there. The goal at this point is not to fully integrate the new stack with my application code, but to just blast UDP packets to see the performance.

Any suggestions will be appreciated,
Thank you

rtel wrote on Friday, August 14, 2015:

I think everything you need is in the zip file I sent - you should not
need to take anything additional from the main FreeRTOS source files.

You should be able to turn TCP off using the ipconfigUSE_TCP
constant - but to be honest most of our recent testing has been with
this turned on, so it is feasible turning it off could cause an issue.

heinbali01 wrote on Saturday, August 15, 2015:

Hi Bruce,

I have a bootloader that uses UDP to get its firmware from a host. That project uses:

#define ipconfigUSE_TCP 0

So yes, it does get tested from time to time :slight_smile:

It uses UDP broadcasts so that e.g. 10 devices can be programmed simultaneously. The devices send their acknowledgements individually.

SDK 2015.2 :Not sure if it helps, but if you want I send can you a Makefile project that can be imported as such in the SDK.

You want to see UDP performance? The FreeRTOS Zynq project runs on a single core and when using a 100 Mbit network it will fill the bandwidth with 98 Mbit. When using Filezilla (FTP) I measured a nett speed of +/- 10 MByte per second.

Regards.

bruce4243 wrote on Monday, August 17, 2015:

Hello,

Thanks for the replies, I appreciate it. I’ll be working on this again this week, and am trying to resolve the tooling issues as well.

Hein, thanks for the info about the performance and the configuration. Iet me try to resolve my tooling issues here on this version of SDK beofre trying to import a makefile project, I have a feeling it’s the same problem.

Thanks for your help,

bruce4243 wrote on Wednesday, August 19, 2015:

Hi,

I was able to resolve the tooling issue here and built the demo project with sdk 2015.2. The project build with no errors and was programmed onto the zc702 eval board via jtag.The code does not execute as expected, it seems to keep jumping to the vector table over and over, starting at 0x4 up to 0xA I think.

I added a printf as the very first instruction in main, but am not able to even get that far. Any suggestions to what me happening? Also, I read through the user manual for the zynq in an attempt to see what interrupt was mapped where, but did not find that iofrmaiton. As a side question, where does the mapping of interrupt to memory reside?

thanks,

rtel wrote on Wednesday, August 19, 2015:

How are you running the application? Standalone, or through the
debugger. As delivered it expects to be executed through the debugger -
so downloaded and started using a launch configuration in the SDK.

The debugger launch configuration should be set to run the ps7_init -
you will see a check box for this on the “Target Setup” tab of the
launch configuration. It is also best to ensure the Reset Entire System
check box is also checked. If you run it standalone it will be
necessary to call ps7_init() manually from the compiled code.

The documentation for this will be online soon - it was written some
time back.

Regards.

heinbali01 wrote on Thursday, August 20, 2015:

Hi Bruce,

I added a printf as the very first instruction in main,
but am not able to even get that far

printf won’t do a thing before the hardware and the libraries are initialised.

But the debugger should stop at the first instruction at main(), if configured to do so (see Debugger Options -> GDB Options -> Stop at main() when debugging ). If not you might want to put a breakpoint on the first instruction.

I attached a screendump of a working Xilinx SDK 2015.2 in debugging mode. Hopefully it helps.

Regards.

bruce4243 wrote on Thursday, August 20, 2015:

Hello,

Thanks for the replies. I was running the code by loading it though command line xmd. I performed the following each time I loaded:
stop
reset processor
download what I believe to be the ps7_init code
download the application
run

The build machine with the 2015.2 is not the same machine the hardware is connected to, so I was using the xmd command line. I can also try to get the hardware connected to the build machine and try the sdk debug as you suggested.

thanks,