I am trying to intigrate FreeRTOS with an evk board that freertos does not have a support for(Alif ensemble E7). The processor used in it is CORTEX M55. I am facing the problem where get the prints the task has been created but i dont find it executing.
I have added the rtos kernel files tasks.c,list.c,queue.c. Also for porting freertos I have added port.c , portasm.c for the GCC compiler and ARM cortex M55 processor.
In the application code I am just trying to blink the leds in while(1) creating some delay using xtaskDelay.
The compiler i am using is GCC.
The following are the macros that I am using in FreeRTOSConfig.h
You should post the code creating the tasks and the task function. Otherwise it’s impossible to guess the problem.
It’s important that you enable stack checking and properly define configASSERT during development.
BTW I’d also recommend to enable #define configUSE_PORT_OPTIMISED_TASK_SELECTION 1
if you don’t have more than 32 tasks. It’s much more efficient.
Your code seems ok so far… Do you get the “led_blink_app” ei_printf output ?
(Is ei_printf is thread-safe and can be used in multiple tasks in case you’re adding more tasks later on ?)
Do you have a debugger attached ? Then you can put a breakpoint to the led_blink_app function and run the program (using a debug build).
The target should be halted there right after the scheduler was started. Then step through the task code to see what’s going on.
Oh yes … please enclose code blocks with 3 tildes ‘~’ or backticks ‘`’ for better readability.
Without debugger you’ll have a very, vey hard time to develop something a bit more complex than a blinking LED application…
However, if you only have ei_printf and maybe some LEDs then these are the debug tools you have.
So given that ei_printf is really working create a configASSERT macro using it to see when and where an assertion fails. That should provide some valueable information why the task couldn’t be started as expected.
to see if your system works at all, you can toggle the LEDs before you start the scheduler (to ensure that they work correctly), then toggle them on every 100th or so invocation of your sys tick handler…
Both configENABLE_TRUSTZONE and configRUN_FREERTOS_SECURE_ONLY are set to 0. This implies that Trustzone support is disabled and FreeRTOS is configured to run on the non-secure side. Does the hardware boots to non-secure? If not, then can you try setting configRUN_FREERTOS_SECURE_ONLY to 1 so that FreeRTOS runs on the secure side?
By setting both configENABLE_TRUSTZONE = 0configRUN_FREERTOS_SECURE_ONLY = 0.
2 . By setting configENABLE_TRUSTZONE = 0configRUN_FREERTOS_SECURE_ONLY = 1.
Carried out the second step as suggested by you that is by changing the port.c and portasm.c files with NTZ files from the given link but I am still not finding any change.
This question might sound stupid but have never done freertos integration before so want to ask
—does this the task execution have anything to do with system clock settings or SysTick_Handler definition.
The system tick interrupt must call xPortSysTickHandler(). Otherwise the tick count won’t increment. Some tools automatically define the SystTick handler to call SysTick_Handler, in which case you need to #define xPortSysTickHandler() to SysTick_Hander() to ensure it gets called. This page describes how to do that: https://freertos.org/FAQHelp.html
If the clock setting doesn’t match configTICK_RATE_HZ then the tick interrupt will execute at the wrong frequency, but the system should still run, it will just measure time incorrectly.