Am failing to get a basic RTOS build up on the Trenz Zynq board. Have constructed a build as per the guide in “Mastering the FreeRTOS” (pre-release version). This in on Xilinx Vivado 2014.4 (for historic reasons) and under Windows 10.
The construction of the project succeeds and can be downloaded to the target.
However when executing, the processor crashes in vPortInstallFreeRTOSVectorTable() within prvSetupHardware();
I have noted the following:
In debug when tracing, the address of _freertos_vector_table that is loaded is 0 - so does the code not simply copy the vector table over itself?
That stepping through the routine vPortInstallFreeRTOSVectorTable, when the instruction dsb is executed the link register lr is clobbered. Hence when the bx lr instruction is executed we effect a re-boot (without a reset).
Taking the existing Zynq demo from the FreeRTOS download, and
re-targeting it for your hardware (replacing the hardware definition
project to be correct for your hardware, then re-generating the BSP
project from the updated hardware definition).
Manually creating the project from scratch by allowing the SDK to
create a bare metal project that uses a standalone BSP, and then
manually adding in the FreeRTOS source files.
Using the SDK to create a FreeRTOS BSP instead of a standalone BSP,
and in so doing, having the SDK add the FreeRTOS source files into the
project for you.
Did you take the files you added to your project from the FreeRTOS V9.0.0 release? The SDK project in the V9.0.0 release uses the 2016.1 SDK, which may explain your download issue, as you are using 2014.4.
In the Zync 7000 demo found in FreeRTOS V9.0.0 _freertos_vector_table is implemented in FreeRTOS_asm_vectors.S, where it is placed in the freertos_vectors section. Looking at the linker file I see freertos_vectors is then placed at the very start of the .text region, which means it should appear at 0x00100000. Looking at the map file I see freertos_vectors does indeed appear at 0x00100000, but you are reporting that in your built _freertos_vector_table appears at address 0 - so could this be a linker script problem?
Have a look at
\FreeRTOS\Demo\CORTEX_A9_Zynq_ZC702\RTOSDemo\src\lscript.ld - I think
the addition of *(.freertos_vectors) was the only edit over the linker
script that was automatically generated for the hardware I was using.