This release upgrades the freeRTOS port with minor changes for SDK 14.2. This port is based on the version 14.2 of Xilinx ISE Design Suite, and was developed and tested on a Zynq EPP based ZC702 board.
Xilinx_Zynq.zip
FreeRTOS Interactive
|
This release upgrades the freeRTOS port with minor changes for SDK 14.2. This port is based on the version 14.2 of Xilinx ISE Design Suite, and was developed and tested on a Zynq EPP based ZC702 board.
Hi Suneel,
I am using Zynq eval board ZC702. I want to run FreeRTOS on one core and
Linux on the other core. Xilinx has provided a Linux example. How can
I combine that with your port? Have you or someone tried doing that?
Regards,
Pramod Ranade
Suneel,
Neither this port for SDK 14.2 or the previous one for SDK 14.1 will compile and link with the g++ compiler.
Mostly the lack of extern "C" provisions in the portable files, but looks like there are a few other problems also.
I'm trying to fix these issues because I have a huge amount of legacy C++ code running on FreeRTOS on Microblaze that I need to port to Zynq.
Regards,
John Kennedy
Hi John,
Thanks for pointing out the issue with g++ compiler.
I am aware of it and will be fixed in the next release of the port for zynq.
Thanks,
Suneel
Suneel,
I had to add #include "task.h" and the check for __cplusplus to portISR.c and add the check for __cplusplus to port.c.
I had to add the flag -fpermissive to the compiler flags but this still causes lots of warnings.
WIth the above changes the BSP will build.
However I tried to build hello_world by creating an empty c++ project and copying the c source into main.cc.
The main.cc compiles but I get a bunch of link errors from timers.o:
../../freertos_zynq_bsp_1/ps7_cortexa9_0/lib\libfreertos.a(timers.o): In function `prvCheckForValidListAndQueue':
C:\P4\dev\john_kennedy\projects\zynq\zynqbsb\zynqbsb.sdk\SDK\SDK_Export\freertos_zynq_bsp_1\ps7_cortexa9_0\libsrc\freertos_zynq_v1_01_a\src/timers.c:636: undefined reference to `xQueueCreate'
../../freertos_zynq_bsp_1/ps7_cortexa9_0/lib\libfreertos.a(timers.o): In function `xTimerGenericCommand':
C:\P4\dev\john_kennedy\projects\zynq\zynqbsb\zynqbsb.sdk\SDK\SDK_Export\freertos_zynq_bsp_1\ps7_cortexa9_0\libsrc\freertos_zynq_v1_01_a\src/timers.c:271: undefined reference to `xQueueGenericSendFromISR'
C:\P4\dev\john_kennedy\projects\zynq\zynqbsb\zynqbsb.sdk\SDK\SDK_Export\freertos_zynq_bsp_1\ps7_cortexa9_0\libsrc\freertos_zynq_v1_01_a\src/timers.c:266: undefined reference to `xQueueGenericSend'
../../freertos_zynq_bsp_1/ps7_cortexa9_0/lib\libfreertos.a(timers.o): In function `prvProcessReceivedCommands':
C:\P4\dev\john_kennedy\projects\zynq\zynqbsb\zynqbsb.sdk\SDK\SDK_Export\freertos_zynq_bsp_1\ps7_cortexa9_0\libsrc\freertos_zynq_v1_01_a\src/timers.c:504: undefined reference to `xQueueGenericReceive'
../../freertos_zynq_bsp_1/ps7_cortexa9_0/lib\libfreertos.a(timers.o): In function `prvProcessTimerOrBlockTask':
C:\P4\dev\john_kennedy\projects\zynq\zynqbsb\zynqbsb.sdk\SDK\SDK_Export\freertos_zynq_bsp_1\ps7_cortexa9_0\libsrc\freertos_zynq_v1_01_a\src/timers.c:383: undefined reference to `vQueueWaitForMessageRestricted'
collect2: ld returned 1 exit status
make: *** [empty_cpp_0.elf] Error 1
The file times.c isn't part of the port files so I can't understand the reasons for these errors?
If I don't configure timers in FreeRTOS everything builds and runs fine.
Any thoughts?
John
Suneel,
As distributed from FreeRTOS queue.h and queue.c compile OK using g++ but as shown above linking is a problem.
This is because the definition of xQueueHandle is different between queue.h and queue.c, so even though the contents of queue.h is inclosed in extern "C" {} the g++ linker knows things are different between queue.c and queue.h and generates link errors. I'm not sure if this is a quirk of the arm cortexa9 g++ compiler or not but I doubt it.
This can be fixed by moving the definiton of xQueueHandle from queue.c to queue.h and including queue.h in queue.c and commenting out the redundant function prototypes in queue.c.
I'm not sure what the FreeRTOS developer's motivation was for hiding the definition of xQueueHandle in queue.c rather than putting it in queue.h to avoid this problem?
There are LOTS of "C style" casts in the FreeRTOS distribution that require the -fpermissive g++ compiler option to change all the compiler errors into warnings.
It would be nice if the FreeRTOS developers would make the FreeRTOS distribution more compatible with C++ compilers.
John
> I'm not sure what the FreeRTOS developer's motivation was for hiding the
> definition of xQueueHandle in queue.c rather than putting it in queue.h to avoid this problem?
Data hiding, in this manner, is sound software engineering practice. The contents of the structure are hidden from users of the API so users are not tempted to use the structure members directly. That way the implementation can change at any time without breaking user code.
FreeRTOS was never designed to be used with C++, but lots of people do. If you look in the "Any other business" forum you will find FreeRTOS C++ frameworks, and searching the forums you will find lots of discussion on it.
Generally, to use C++, you can either break the data hiding (not recommended, as updating to new FreeRTOS versions will be difficult) or compiler the FreeRTOS files as C and the rest of the application as C++. This is not something I have ever done myself, but know lots of people who do.
Regards.
Richard,
Thanks for your suggestion, compiled FreeRTOS with gcc and everything else with g++ worked great without having to change the distribution files.
I have a lot of legacy c++ code using FreeRTOS, so I need to reuse it if I can.
I didn't think the g++ linker would link C files with C++ files but it worked fine, seems like I had problems with this using the older Xilinx tools?
I love FreeRTOS I've been using it for years, rock solid!
Looking forward to using the new version on Xilinx Zynq!
I appreciate your support,
John
When using FreeRTOS on Zynq, I'm having a lot of trouble with the Xilinx SDK debugger. Specifically when I hit a breakpoint in a FreeRTOS task or if I hit the suspend button almost always the debugger can't access the target and I can't do anything else at that point? If I try to run or step or look at memory I just get SDK errors so I have to restart the XMD session, reload the FPGA and terminate then start the debugger again. If I don't set breakpoints FreeRTOS runs fine so I don't think this is a FreeRTOS problem, but rather something in the SDK debugger. Sometimes (rarely) when I hit a breakpiont in a FreeRTOS task everyting works fine. Sometimes after FreeRTOS has been running awhile I can hit the suspend button or set breakpoints and everyting works OK? This problem makes it very difficult to debug code for a new FreeRTOS task especially when the task starts up. I've contacted our local Xilinx FAE about this problem but it's been 2 weeks and no support from Xilinx yet?
Does anyone here have any ideas about what may be causing this problem?
Thanks,
John
Hi,
I want to use FreeRTOS on Zynq core1 instead of core0. What changes I need to do?
Actually, I already have Linux/standalone running on core0/core1. I want Linux/FreeRTOS. So tried the above FreeRTOS code, but did not work. I changed linker script suitably, added the option
-DUSE_AMP=1. Also set stdin and stdout to none. What else do I need to change?
Regards,
Pramod Ranade
Hi,
Forgot to mention that I am using 14.3 toolset. Have made necessary changes in .tcl and .mld file. Still it doesn't work. When I start core1, it does nothing - and also core0 crashes (stops responding).
Regards,
Pramod Ranade
Hi John,
Thanks for the comment.
Can you help me with the procedure to reproduce the SDK debugger issue. I have re-tested on the released examples and I couldn't face any issue.
I believe you are using 14.2 SDK release.
Regards,
Suneel
Suneel,
I don't think the problem is with FreeRTOS because the code runs fine if I don't set any breakpoints. So I think there are problems with the SDK debugger interface to Zynq? Oddly sometimes everything works OK, but that seems rare. We've sidelined our Zynq project for the time being, the Xilinx software tools just aren't to a point to be realiabe enough to be useable for a large software project. Xilinx makes great FPGAs and hardware tools but their software tools and SDK suck. Hopefully this will get better in future releases of the SDK but we'll see.
John
Finally, FreeRTOS is running on Zynq core1 (and Linux on core0).
See last post of this thread:
forums.xilinx.com/t5/7-Series-FPGAs/where-is-pre-canned-AMP-solution-Linux-FreeRTOS/m-p/259490
Regards,
Pramod Ranade
To run in SDK 14.4,
the FSBL step as described in the documentation is NOT needed anymore.
regards.
Hello Everyone,
I am currently following the direction in the FreeRTOS_Zynq_Port.pdf and I am stuck at the XMD console section. I successfully connected to the processor using "connect arm hw" and get the following printout:
XMD%
Accepted a new TCLSock connection from 127.0.0.1 on port 52385
connect arm hw
JTAG chain configuration
--------------------------------------------------
Device ID Code IR Length Part Name
1 4ba00477 4 Cortex-A9
2 03727093 6 XC7Z020
CortexA9 Processor Configuration
-------------------------------------
Version.............................0x00000003
User ID.............................0x00000000
No of PC Breakpoints................6
No of Addr/Data Watchpoints.........1
Connected to "arm" target. id = 64
Starting GDB server for "arm" target (id = 64) at TCP port no 1234
I then attempt to download the fslb elf file to the board:
XMD% dow zynq_fsbl_0.elf
warning: FPGA is NOT Configured. Accessing FPGA Address space can
cause the System to hang. Use "fpga" command to Configure the FPGA
ERROR: Failed to download ELF file
UNABLE to Open File
: zynq_fsbl_0.elf
What am I doing wrong? I attempted commands like below and gave it the exact path just as a last resort but it just keeps giving the same error above:
XMD% dow C:\Users\SCDC-093011\Documents\Zynq\freeRTOS_ver2\freeRTOS_ver2.sdk\SDK\SDK_Export\zynq_fsbl_0\Debug\zynq_fsbl_0.elf
In the pdf it says: Type “dow <path to Zynq fsbl elf file>” and hit enter.
I see that there are the commands
dow <filename> Download Elf File
dow <filename> <addr> Download PIC Elf File from <addr>
So i also tried this (dow <filename> <addr>) out of desperation:
XMD% dow zynq_fsbl_0.elf C:\Users\SCDC-093011\Documents\Zynq\freeRTOS_ver2\freeRTOS_ver2.sdk\SDK\SDK_Export\zynq_fsbl_0\Debug\zynq_fsbl_0.elf
Thank you for your time. I hope that this will also help anyone else having this problem.
Hi Timothy,
I commented above. The FSBL step is not needed anymore.
Hey Teddy,
I am currently using 14.2. So wouldn't I still need it? I forgot to mention that. Also I JUST figured out what was wrong with my command. I was using "\" instead of "/". This happened because I copied the folder address from window and it put it in the C:\Users\SCDC-093011\Documents\Zynq\... format. I just replaced the slashes C:/Users/SCDC-093011/Documents/Zynq/....
-Tim
Hey Everyone,
I also wanted to note that sometimes when downloading to the processor I get the following error:
XMD% dow C:/Users/SCDC-093011/Documents/Zynq/...../Debug/freertos_blink_led_mutex_0.elf
invalid command name "-processor
To solve this (saw this used on other forums for other projects) i used the command "rst -processor" and you will get the following output:
"Target reset successfully
0"
From here you should not get the "invalid command name "-processor"" error. It has happened several times when messing around with the FreeRTOS port so I figured I would post about it.
-Tim
hi
I want to load free RTOS hello world application on my board and run it
my platform includes zynq 7000 soc zedboard , xilinx XPS/SDK 14.2
I create freeRTOS BSP , follow the steps in this document without any additional step
and get an error while I want to download the application to target board
here is the sceenshot of the error message
does anyone meet similar problem like this ? am I missing anything ?
thank you
hi
sorry , here is the updated message on my XMD console
thank you
XMD% connect arm hw
JTAG chain configuration
--------------------------------------------------
Device ID Code IR Length Part Name
1 4ba00477 4 Cortex-A9
2 03727093 6 XC7Z020
CortexA9 Processor Configuration
-------------------------------------
Version.............................0x00000003
User ID.............................0x00000000
No of PC Breakpoints................6
No of Addr/Data Watchpoints.........1
Connected to "arm" target. id = 64
Starting GDB server for "arm" target (id = 64) at TCP port no 1234
XMD% dow ./zynq_fsbl_0/Debug/zynq_fsbl_0.elf
warning: FPGA is NOT Configured. Accessing FPGA Address space can
cause the System to hang. Use "fpga" command to Configure the FPGA
Downloading Program -- ./zynq_fsbl_0/Debug/zynq_fsbl_0.elf
section, .text: 0x00000000-0x0000884b
section, .handoff: 0x0000884c-0x00008897
section, .init: 0x00008898-0x000088af
section, .fini: 0x000088b0-0x000088c7
section, .rodata: 0x000088c8-0x00008b8f
section, .data: 0x00008b90-0x00009c73
section, .eh_frame: 0x00009c74-0x00009c77
section, .bss: 0x00009c78-0x0000a17b
section, .mmu_tbl: 0x0000c000-0x0000ffff
section, .init_array: 0x00010000-0x00010007
section, .fini_array: 0x00010008-0x0001000b
section, .heap: 0x0001000c-0x0001200f
section, .stack: 0xffff0000-0xffffcbff
Setting PC with Program Start Address 0x00000000
XMD% run
Processor started. Type "stop" to stop processor
XMD% stop
Processor stopped
XMD% User Interrupt, Processor Stopped at 0xfffffe1c
XMD% dow ./freertos_hello_world_0/Debug/freertos_hello_world_0.elf
warning: FPGA is NOT Configured. Accessing FPGA Address space can
cause the System to hang. Use "fpga" command to Configure the FPGA
Downloading Program -- ./freertos_hello_world_0/Debug/freertos_hello_world_0.elf
section, .text: 0x00100000-0x0010cc63
section, .init: 0x0010cc64-0x0010cc7b
section, .fini: 0x0010cc7c-0x0010cc93
section, .rodata: 0x0010cc98-0x0010d073
section, .data: 0x0010d078-0x0010dc5f
section, .eh_frame: 0x0010dc60-0x0010dc63
section, .bss: 0x0010dc64-0x0010de93
section, .mmu_tbl: 0x0010de94-0x00113fff
section, .ARM.exidx: 0x00114000-0x00114007
section, .init_array: 0x00114008-0x0011400f
section, .fini_array: 0x00114010-0x00114013
section, .heap: 0x00114014-0x0011601f
section, .stack: 0x00116020-0x0011ac1f
Timeout waiting for ACK in ArmJtagDP transaction.
Please reset the system by running rst -debug_sys or
power-cycle the target
ERROR: Failed to download ELF file
XMD%
Metalalive have you tried what I mentioned above? Type "rst -processor" then try to upload it again.
I am using freertos on Zynq processing system. I am facing severe problem while configuring Zynq UART interrupt. Could any body tell, how is best way to configure UART interrupt for freertos.
Any help is highly appreciated.
Fayyaz
Hi Fayyaz,
Please ask the question more specifically. It is currently difficult to understand what you mean.
Dear Teddy,
First sorry about the un cleared question.
Thank you very much for reply. Actually, I was setting interrupt for the UART but suddenly I realized that I have to check the freertos tick interrupt as well. I observed that even interrupt for the timer (for tick) is not working. I tried two things, fist I add vTaskDelay(1000) into one of tasks, but it does not work. Secondly, I inserted a break point inside the vTickISR to check whether the interrupt happen or not. But break point never hit inside the Xilinx SDK debugger. Could you please tell me, what is reason. Any help is highly appreciated.
Regards
Fayyaz
I am using freertos for Zynq processor. I found that the interrupt for the vTickISR never happened in debugger. I do not know why, although it should work by default.
Can anybody suggest me, what should, I do to enable interrupt. Any help is highly appreciated.
Fayyaz
Dear Teddy,
Could you please help me to sort out the interrupt problem. Actually, I am configuring interrupt for the UART-0 on Zynq processor in freertos environment. Attached is a complete code for the interrupt configuration. The problem, I am facing my ISR never hit. I tried my things but could not succeed. So please see and suggest something. Any help is highly appreciated.
Regards
Fayyaz
Dear Fayyaz,
did you solve your Problem and got the UART Interrupt running? I'm facing the same problem!
Kind regards
Fayyaz, MvE2003,
Also having an issue with interrupts, and in particular, just getting the vApplicationTickHook to be called. I have enabled tick hooks in the bsp settings and stepped through the code where the timer and interrupts are being initalised...currently a mystry as to why I dont seem to be getting any interrupt activity. Also confirmed from a task using a queue. If I set the wait time to anything other than 0 it just loops in idle....did you guys solve this?
SDK 2016.2
FreeRTOS 1.1 (from bsp settings - actually v8.0.1?)
Thanks!