Hi all, I’ve ported FreeRTOS to AT91SAM9G20 as I need it for work. I’ve inspired my self from other ports and and bare metal software that initialise all the hardware properly and tested those. However I managed to compile everything without errors my system is not working as expected, i.e. flashing a led. Which I manage do without FreeRTOS. I’ve noticed that if I place a call to portDISABLE_INTERRUPTS nothing works. I am no expert in ARM, perhaps someone may have a hint. I cant debug with gdb as I haven’t received my jlink.
You can checkout my repo here . I’ll be very thankful if someone can help me out. I’ve been struggling for over two days now and I really need it to work. I can’t see what I’m doing wrong!
We will need more information that ‘does not work’ - and I fear it will
be hard for you to provide that information (at least, not efficiently)
unless you can debug your code.
The first thing to determine is, are you entering main()?
On the assumption you are, the next is, are you reaching the call to
vTaskStartScheduler()?
If yes, the next is is vTaskStartScheduler() ever returning?
If vTaskStartScheduler() is not returning, do you ever enter the first task?
To determine if you ever enter the first task start with a very simple
test that only creates one task that has a priority above
tskIDLE_PRIORITY (above 0) and ensure configUSE_TIMERS is 0. That way
you will know the first task to run is your task (as there is no timer
task and the idle task has priority 0).
Thank you for your quick reply.
Well, it’s hard to tell. Whenever I comment out everything that is related to FreeRTOS, I do enter the main as I manage to turn on an LED. However whenever I call xTaskCreate(), the led doesn’t even turn on. I find this simptom very odd…
int main() {
ConfigureLeds();
LED_Set(1);
// The LED does turn on.
while(1) {}
}
int main() {
ConfigureLeds();
LED_Set(1);
//The LED doesn't turn on
xTaskCreate(task1, "LED_0", 128, NULL, 0, NULL);
xTaskCreate(task2, "LED_1", 128, NULL, 0, NULL);
vTaskStartScheduler();
}
Without the right tools (ref your comment about waiting for the JLink)
it is going to be very hard for you to be productive in setting this up,
or for us to be productive in trying to assist. If simply adding the
call to xTaskCreate() to the function causes the LED not to turn on then
it could be a linker issue, a heap issue, an alignment issue, etc. with
a debugger you will be able to step into the functions and see exactly
where the issue occurs, and exactly where the MCU program counter ends
up (I’m guessing in an exception handler) - and you will be able to
debug the call stack, etc.
I do understand, I found an old jlink yesterday at work after several hours. Unfortunately the gdb script shipped with my developpment kit seems to be bugged… It feels like to world is against me, more about that later…
So I have news. I managed to debbug my debugger script I tried what you said and I did get to the first task with the instructions that you gave me usign gdb. However when I flash it directly and boot it up normally, it doesn’t work… I wonder what that means…
This is what the main.c looks like
void task(void *pParam) {
int i = 0;
while (1) {
i++;
}
}
int main () {
xTaskCreate(task, "LED_0", 128, NULL, configMAX_PRIORITIES-1, NULL);
vTaskStartScheduler();
while (1) {
}
}
Attached the log of the GDB session, hope it brings info.
I did try with an LED, it works fine with GDB (i.e. I enter de task and toggle the LED).
I am indeed debugging from RAM, however the developpement kit works with a small boot loader that loads my code into RAM. Though I enter the task, it seems that I loop only once in the while statement then gdb is stuck. As for debugging freertos from RAM I end up whith the following frame :
Stack level 0, frame at 0x23ffff80:
pc = 0x8; saved pc = 0x20000e28
called by frame at 0x23ffff88
Arglist at 0x23ffff80, args:
Locals at 0x23ffff80, Previous frame's sp is 0x23ffff80
and the stack is as follows :
#0 0x00000008 in ?? ()
#1 0x20000e28 in vTaskDelay (xTicksToDelay=<optimized out>) at src/freertos/tasks.c:1320
#2 0x200002ac in main () at src/main.c:125
I did debugged the whole boot process. On this boards the idea is that that booting happens on two levels before running user code. First the microcontroler boot called sam-ba (that runs from internal rom) it initializes external memory and loads the second level bootloader from flash and into internal SRAM. This second level bootloader, AT91Boostrap is open source and no longer mantained by Atmel/Microchip for legacy boards such as mine. Instead a community of users keep maintaining it. This bootloader performs harware initialisation for master clock, plls, external SDRAM and other peripherals. Finally it will load the user image into SDRAM and jump to it. Until now this has worked with other simple programs like the demo program and personal programs. So I did the whole boot process using gdb and after loading the image into SDRAM and jumping to it the program gdb indicates the following after typing info frame
pc = 0x10; saved pc = 0xea000066
called by frame at 0xc
Arglist at unknown address.
Locals at unknown address, Previous frame's sp is 0xc
Saved registers:
r4 at 0x0, r5 at 0x4, lr at 0x8
I do not know how to interprate it really. Perhaps you may find something interesting and the registers like store the following
Hi all,
Good news! I managed to get FreeRTOS working flawlessly when using the J-Link, there’s still an other issue that prevents it from working when I boot it up from flash. But that’s another matter! Perhaps other people can be interested in this port? Once I get it working, how could I share it with the community? I believe that there’s a lot of potential users that could be interested.
This microcontroller is used on the onboard computer that a company is selling to cubesat/student projects and this port could save them some time. With this in mind, I’d like to know what does an official port implies and whether or not it could be feasible to make an official port out of the one I started so that students working with this µ-controller could have a little more documentation.
I’m sure that Mr. Barry has several obligations and don’t expect him to answer my every posts. Though I’m surprised no one else has commented this thread any further!
Previously third party ports have been uploaded to https://interactive.freertos.org but unfortunately the forum hosts no longer allow attachements. It would be great if you could use the forums to link to the code though.
I tried what you said and I did get to the first task with the instructions that you gave me usign gdb. However when I flash it directly and boot it up normally, it doesn’t work… I wonder what that means…