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 tskIDLEPRIORITY (above 0) and ensure configUSETIMERS 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). Let us know what you determine.

Hi Richard, 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(); LEDSet(1); //The LED doesn’t turn on xTaskCreate(task1, “LED0″, 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, “LED0″, 128, NULL, configMAXPRIORITIES-1, NULL); vTaskStartScheduler(); while (1) { } } ~~~ Attached the log of the GDB session, hope it brings info.

As the task is not toggling an LED any more, how do you know it isn’t working when you flash then reset? When you debug are you running from RAM? If so, try debugging from flash so it matches the code and memory map as per the flash and reset case.

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=) at src/freertos/tasks.c:1320

2 0x200002ac in main () at src/main.c:125

~~~ and the registers ~~~ r0 0x0 0 r1 0x200013cc 536875980 r2 0x0 0 r3 0x0 0 r4 0x20000e14 536874516 r5 0x64 100 r6 0x20000354 536871764 r7 0x7070707 117901063 r8 0x8080808 134744072 r9 0x9090909 151587081 r10 0x10101010 269488144 r11 0x11111111 286331153 r12 0x2000117c 536875388 sp 0x23ffff80 0x23ffff80 lr 0x20000e28 536874536 pc 0x8 0x8 cpsr 0x600000d3 1610612947 ~~~ I hope it will be usefull!

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 ~~~ r0 0xe59e0100 3852337408 r1 0x658 1624 r2 0xfffff214 4294963732 r3 0x0 0 r4 0x200941 2099521 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x303de8 3161576 sp 0x0 0x0 lr 0x20000010 536870928 pc 0x10 0x10 cpsr 0xd7 215 ~~~

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.

 Cheers,

 Colin

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.