Hello,
I am trying to follow the example on how to create a static event group. I am using Xilinx SDK 2016.1 and a project with freeRTOS_823xilinx platform:
#include "FreeRTOS.h"
#include "task.h"
#include "event_groups.h"
/* Declare a variable to hold the handle of the created event group. */
EventGroupHandle_t xEventGroupHandle;
/* Declare a variable to hold the data associated with the created
event group. */
StaticEventGroup_t xCreatedEventGroup; // ERROR HERE: UNKNOWN TYPE NAME
/* Attempt to create the event group. */
xEventGroupHandle = xEventGroupCreateStatic( &xCreatedEventGroup );
As commented in the code, the StaticEventGroup_t is not recognized. How to fix it?
Static allocation was introduced in FreeRTOS version 9. http://www.freertos.org/FreeRTOS-V9.html V9 is backward compatible, so
you should be able to copy the V9 files over the top of your V8 files.
I do not know how to change/update the SDK environment. The question above is a consequence of a problem that I started having when using freeRTOS. So, I though that switching to “static” would fix it. But maybe you could suggest what could be the problem in the following:
Xilinx SDK 2016.1 freeRTOS823_xlinx OS platform
My code seemed to work fine until I introduced some freeRTOS elements. The general functionality of my code as follows:
In the Interrupt subroutine, I assign a value to a variable focusPosition read from the IP register:
The code prints the correct value, however, when I try to implement some additional lines in the code, like xTaskCreate() xEventGroupCreate(), something messes up all the memory and the printed value stays constant, which is not correct.
How can simple addition of the code that has nothing to do with the variable have any influence on that variable? As far as I understand, the xTaskCreate() and xEventGroupCreate() are created on the heap. I tired pocking around to see if Xil_DCacheDisable() would help, but no. Any ideas? Is my focusPosition variable properly defined/declared?
I don’t know what XRb_focus_Get_position_o() is, or what it does, but
would agree that calling an unrelated function should probably have no
impact on it.
There are two things the FreeRTOS create functions do that touch the CPU
or run time state. The first is disable then re-enable interrupts -
could that impact XRb_focus_Get_position_o()? The second is allocate
some RAM (which I am presuming is why you were looking to use a static
system). How RAM is allocated depends on which heap_n.c implementation
you are using - see http://www.freertos.org/a00111.html Which are you
using? (heap_1, heap_2, heap_3, heap_4 or heap_5?).
The only other mention of XRb_focus_Get_position_o() I can find on the
web is on the following link - does the link provide any relevant
information?
I do not know how to change/update the SDK environment. The question above
is a consequence of a problem that I started having when using freeRTOS.
So, I though that switching to “static” would fix it. But maybe you could
suggest what could be the problem in the following:
Xilinx SDK 2016.1 freeRTOS823_xlinx OS platform
My code seemed to work fine until I introduced some freeRTOS elements. The
general functionality of my code as follows:
In the Interrupt subroutine, I assign a value to a variable
focusPosition read from the IP register:
The code prints the correct value, however, when I try to implement some
additional lines in the code, like xTaskCreate() xEventGroupCreate(),
something messes up all the memory and the printed value stays constant,
which is not correct.
How can simple addition of the code that has nothing to do with the
variable have any influence on that variable? As far as I understand, the
xTaskCreate() and xEventGroupCreate() are created on the heap. I tired
pocking around to see if Xil_DCacheDisable() would help, but no. Any ideas?
Is my focusPosition variable properly defined/declared?
The link you referred was my question regarding the same project, but for a different reason. The XRb_focus_Get_position_o() is a custom function that is automatically created as a driver function for the IP block that is implemented in the programmable logic on the FPGA. This function works fine. The problem arises ONLY WHEN I introduce anything related to freeRTOS (or some other things that I am not aware yet).
I doubt that the XRb_focus_Get_position_o() coud be affected. It simply accesses the IP block register and reads its value.
I tend to believe that your second suggestion is the reason. As you can see, the variable focusPosition is dealt with when wrinting to it (in ISR), and then when reading from it (in printf). I feel like the two functions access different physical addresses after I create any freeRTOS objects. I do not know which heap# is used in the my implementation. Whatever is set by SDK default settings…
You should be able to see which heap_n.c file is being used in the IDE.
Are you using the Xilinx SDK, which is Eclipse, if so and you are
using FreeRTOS as part of the BSP (rather than adding the files into
your project manually) then the heap_n.c file will be listed along with
the other BSP files (in the BSP project, not the application project).
Indeed, the BSP libsrc folder contains heap_4.h. So, when I use functions like these - xTaskCreate() xEventGroupCreate() - they probably call heap functions to allocate memory. Is there a way to prevent them from interfering with other variable in my project?
Is there a way to prevent them
from interfering with other variable in my project?
Its a bit of a non-question as there is of course no known reason why
they would interfere with your variables - so the task is to find out
why they are.
Heap_4.c is good as it is using a statically allocated array as the
heap. If you were using heap_3.c it would be more complex as we would
have to look at the linker scripts.
The size of heap_4.c is set by the configTOTAL_HEAP_SIZE constant found
in the FreeRTOSConfig.h file. If you are building FreeRTOS as part of
the BSP then the FreeRTOSConfig.h will be automatically generated. You
can set its value by editing the BSP settings through the IDE, but for
now just look at the file (it will be in the BSP project too) to see
what configTOTAL_HEAP_SIZE is set to. It is also possible to step
through the function to see what it does when you attempt to create a
FreeRTOS object - but you will need to set the optimisation level to 0
to make that easy. By default the BSP is built at optimisation level 2
which with GCC makes things tricky to debug.
When you create an RTOS object are you actually checking the object is
created successfully? The easiest way of doing that is by checking the
return value of the function used to create the RTOS object. If it
returns pdFAIL (0) then the object was not created because the memory
allocation failed.
This is such an odd problem I suspect it has little to do with FreeRTOS,
so other questions to ask are:
Are you sure the linker script is correct for your hardware.
Are you sure the hardware itself is functioning as you expect. For
example if you do something more complex but not involving FreeRTOS
would the same issue eventually show up?
Are you sure the debugger is working as you expect - in particular -
are you sure the variable is REALLY behaving the way you say, and its
not just that the debugger can no longer read the varibable’s value.
I think it is just something simple I don’t do right (because I am unexperienced).
So, #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 65536 ) ), the number represents bytes or bits? That is, the allocated memory is 64kB or 8kB?
The* focusPosition* is assigned a value in the interrupt subroutine:
The program starts “malfuctioning” after I simply uncomment the line that calls xEventGroupCreate():
//separate file
#include "xil_printf.h"
#include "FreeRTOS.h"
#include "event_groups.h"
EventGroupHandle_t RB_EventGroup;
int RB_THREAD_init()
{
int Status=0;
//RB_EventGroup = xEventGroupCreate();
if( RB_EventGroup == NULL ){xil_printf("Event Group Create FAILED!\n");}
return Status;
}
So, really there should be no change to the functionality of the program. I can not figre out why the program starts printing incorrect values of , after the line is uncommented.
After some investigation I found that the ISR is not executed anymore, so the variable is not updataed. At this point I think that the addition of the commented line affects the execution of ISR (it is not called). Why would this be the case?
If you call a FreeRTOS API function before the scheduler has started
then FreeRTOS will deliberately leave interrupts disabled. That is done
to ensure no ISRs attempt to use FreeRTOS services before the scheduler
has been started. When you start the scheduler interrupts are
automatically re-enabled.
Hm… I am not sure I understood your reply correctly, but so far, it does not seem to hold:
My hardware initialization and interrup registration are congifured before calling any freeRTOS API function, and all the interrups work fine (for a second) until the API is called. After that, one of the interrupts is not called any more.
The interrups do not seem to be disabled before starting the scheduler, since I have other interrups that work fine, like VDMA block that moves video data between the memory and programmable logic.
The “Hello World” xilinx example calls xTaskCreate() and xQueueCreate() functions before vTaskStartScheduler().
To me - it’s a mystery.
Also, is it possible to prevent freeRTOS from affecting the interrupts? My application goal is to have interrups running when needed, and I would like to flag the events in the interrupts. Then, I would have two threads running and executing necessary code when the events is set.
Hm… I am not sure I understood your reply correctly, but so far, it
does not seem to hold:
My hardware initialization and interrup registration are congifured
before calling any freeRTOS API function, and all the interrups work
fine (for a second) until the API is called. After that, one of the
interrupts is not called any more.
Yes - the C start up code will no doubt enable interrupts.
The interrups do not seem to be disabled before starting the
scheduler, since I have other interrups that work fine, like VDMA block
that moves video data between the memory and programmable logic.
After you call a FreeRTOS API function interrupts that have a priority
at or below
configMAX_SYSCALL_INTERRUPT_PRIORITY/configMAX_API_CALL_INTERRUPT_PRIORITY
will be disabled, and interrupts that have a priority above that will
still be enabled. So what you are reporting is completely expected IF
the interrupt that is still running has a priority high enough.
Google running FreeRTOS on a Cortex-A microcontroller (is that what you
are using? I’m not viewing the forum at the moment so that is from
memory) to find the page on the FreeRTOS.org site that explains this.