Debugging a port

colingd wrote on Friday, May 25, 2018:

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!

rtel wrote on Friday, May 25, 2018:

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

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).

Let us know what you determine.

colingd wrote on Friday, May 25, 2018:

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() {
    // The LED does turn on.
    while(1) {}

int main() {
    //The LED doesn't turn on
    xTaskCreate(task1, "LED_0", 128, NULL, 0, NULL);
    xTaskCreate(task2, "LED_1", 128, NULL, 0, NULL);

rtel wrote on Friday, May 25, 2018:

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.

colingd wrote on Saturday, May 26, 2018:

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…

colingd wrote on Tuesday, May 29, 2018:

So I have news. I managed to debbug my debugger script :slight_smile: 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) {

int main () {
  xTaskCreate(task, "LED_0", 128, NULL, configMAX_PRIORITIES-1, NULL);
  while (1) {

Attached the log of the GDB session, hope it brings info.

rtel wrote on Tuesday, May 29, 2018:

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.

colingd wrote on Tuesday, May 29, 2018:

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

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!

colingd wrote on Thursday, May 31, 2018:

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

colingd wrote on Thursday, June 07, 2018:

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.


colingd wrote on Friday, June 08, 2018:

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!

rtel wrote on Friday, June 08, 2018:

Previously third party ports have been uploaded to 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.