Compiling with GCC

Kernel
1

nobody wrote on Tuesday, July 19, 2005:

I have Cygwin installed on the windows syste.
GCC version I have is:
gcc (GCC) 3.3.3 (cygwin special)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

When I run make or ram_ram.bat, I get the following errors:
arm-elf-gcc -c -Wall -D  -D GCC_AT91FR40008 -I. -I…/…/Source/include -I…/Common/include  -mcpu=arm7tdmi -T -Wcast-align  …/…/Source/portable/GCC/ARM7_AT91FR40008/portISR.c -o …/…/Source/portable/GCC/ARM7_AT91FR40008/portISR.o
arm-elf-gcc: cannot specify -o with -c or -S and multiple compilations
make: *** […/…/Source/portable/GCC/ARM7_AT91FR40008/portISR.o] Error 1

With ./ram_arm.bat

c:\freertos-1\FreeRTOS\Demo\ARM7_AT91FR40008_GCC>set USE_THUMB_MODE=NO

c:\freertos-1\FreeRTOS\Demo\ARM7_AT91FR40008_GCC>set DEBUG=-g

c:\freertos-1\FreeRTOS\Demo\ARM7_AT91FR40008_GCC>set OPTIM=-O0

c:\freertos-1\FreeRTOS\Demo\ARM7_AT91FR40008_GCC>set RUN_MODE=RUN_FROM_RAM

c:\freertos-1\FreeRTOS\Demo\ARM7_AT91FR40008_GCC>set LDSCRIPT=atmel-ram.ld

c:\freertos-1\FreeRTOS\Demo\ARM7_AT91FR40008_GCC>make
arm-elf-gcc -c -Wall -D RUN_FROM_RAM -D GCC_AT91FR40008 -I. -I…/…/Source/include -I…/Common/include -g -mcpu=arm7tdmi -Tatmel-ram.ld -Wcast-align -O0 …/…/Source/portable/GCC/ARM7_AT91FR40008/portISR.c -o …/…/Source/portable/GCC/ARM7_AT91FR40008/portISR.o
/ecos-c/DOCUME~1/Owner/LOCALS~1/Temp/ccIEhNNj.s: Assembler messages:
/ecos-c/DOCUME~1/Owner/LOCALS~1/Temp/ccIEhNNj.s:38: Error: literal referenced across section boundary (Implicit dump?)
/ecos-c/DOCUME~1/Owner/LOCALS~1/Temp/ccIEhNNj.s:87: Error: literal referenced across section boundary (Implicit dump?)
/ecos-c/DOCUME~1/Owner/LOCALS~1/Temp/ccIEhNNj.s:103: Error: literal referenced across section boundary (Implicit dump?)
make: *** […/…/Source/portable/GCC/ARM7_AT91FR40008/portISR.o] Error 1

Any suggestions as to what needs to be done to get it going. Is it gcc version or something else that is causing it to not compile?

Thanks and regards
B

2

nobody wrote on Tuesday, July 19, 2005:

Are you able to try the gnuarm version linked to from the FreeRTOS web site (http://www.gnuarm.org I think?).  This should install all you require.

3

nobody wrote on Tuesday, July 19, 2005:

Thanks for quick response. The GNUARM tool chain I have is from GNUARM site. However based on your suggestion, I went to the site again, but it leads me again to the cygwin download.
Am I missing something very basic?
Any help to get me going will be great.
Regards.

4

rtel wrote on Tuesday, July 19, 2005:

Odd, I’m afraid I don’t know what these errors mean.  It should compiler very cleanly.

I think we need to ensure the version you are using first, then if there is still a problem look at other options.

You say you went to the sight again and downloaded the tools, but the output you provided shows GCC V3.3 (only for Mac OS X).  This version is not available from the gnuarm site.  Is it possible that you have two versions installed on your PC and you are accidentally using the wrong one?

A direct link to the setup file is:
http://www.gnuarm.org/bu-2.15_gcc-3.4.3-c-c++-java_nl-1.12.0_gi-6.1.exe

Is this the link you used?

It should give you a standard win32 setup routine.  Then you can use the tools from a standard command prompt (not cygwin shell) provided the path is set to the correct compiler installation.

Regards.

5

nobody wrote on Tuesday, July 19, 2005:

I just tried compiling a clean installation and it worked ok.  Try a complete rebuild.  This can be acheived by touching the makefile:

"touch makefile" from the command prompt.

Then call the RAM_ARM batch file again.

6

nobody wrote on Wednesday, July 27, 2005:

Thanks for the help. I am finally able to compile the program with 3.4.3 version of gcc
To test the demo program, I am using EB40 board from Atmel with AT91R40807 processor. This
is very similar to 40008 processor except the internal RAM is 136 Kbytes.

I am using Wiggler from Macraigor to download and test the code using JTAG port.

For some reasons, I was not able to run the code from the internal RAM (although the size
of the code is much smaller than 136 KBytes). So, I modified the linker file to execute from external SRAM (board has 512KBytes of SRAM). It still didn’t work.

Just to make sure that I could download the code and do something, I modified the main function to loop in a tight loop and toggle LED’s (I bypassed invoking of all tasks and scheduler). This worked fine.

Next, I modified the main routine to bypass everything except:

xTaskCreate( vErrorChecks, "Check", configMINIMAL_STACK_SIZE, NULL,

mainCHECK_TASK_PRIORITY, NULL );
       
vTaskStartScheduler();

Then I modified the error check function to include only the following code:
for (;;){

vParTestToggleLED( mainON_BOARD_LED_BIT );
vTaskDelay( 5000);
}

At this point I am expecting to see the LED toggling every 5000 ticks.
But LED’s are NOT toggling. My suspicion is that the task is not coming out of the delay?

I am assuming that when I called the vTaskStartScheduler(); it set up the timer tick as
well as enabled the timer.

Any suggestions on debugging this?

Thanks
B

7

nobody wrote on Thursday, July 28, 2005:

Yes, the timer is setup automatically when you start the scheduler.

A few quick questions -

1/ Does the call to vTaskStartScheduler() return?  It should not, but if it does it gives us a clue.

2/ Does the code run from ROM?  You only mention RAM builds in your text.  Again if it runns from ROM but not RAM then this will give us a clue what to do next.

3/ The program you do have running that flashes the LED’s, does this also run from external RAM?  This would indicate that the wait states etc are setup correctly.

8

nobody wrote on Thursday, July 28, 2005:

Thank you for getting back to me.
1. Call to vTaskStartScheduler() does not return.
2. Code is running from External RAM.
3. The code that flashes the LED runs from external RAM.
I can break the code at the start of both instructions in the for loop the first time around but after that it never breaks.

Thanks for your time.
Regards,
B

I have now modified the test program as follows. On startup it flashes the LED’s for the count specified in 'X" but after it gets out of this while loop, it does not.

/*
* Starts all the other tasks, then starts the scheduler.
*/

int main( void )
{
/* Setup the hardware for use with the Olimex demo board. */
portLONG x;
x=4;
prvSetupHardware();
   while(x–){
       vParTestToggleLED((P4));
       dly(800000);
    }
#if 0
    /* Start the demo/test application tasks. */
  vStartIntegerMathTasks( tskIDLE_PRIORITY );
    vAltStartComTestTasks( mainCOM_TEST_PRIORITY, mainCOM_TEST_BAUD_RATE, mainCOM_TEST_LED );

    vStartLEDFlashTasks( mainLED_TASK_PRIORITY );
    vStartPolledQueueTasks( mainQUEUE_POLL_PRIORITY );
    vStartMathTasks( tskIDLE_PRIORITY );
    vStartSemaphoreTasks( mainSEM_TEST_PRIORITY );
    vStartDynamicPriorityTasks();
    vStartBlockingQueueTasks( mainBLOCK_Q_PRIORITY );

    /* Start the check task - which is defined in this file. */
    xTaskCreate( vErrorChecks, "Check", configMINIMAL_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL );

    /* Now all the tasks have been started - start the scheduler. */
    vTaskStartScheduler();
#endif

#if 1
xTaskCreate( vErrorChecks, "Check", configMINIMAL_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL );
        //vStartLEDFlashTasks( mainLED_TASK_PRIORITY );
        vTaskStartScheduler();
#endif
    /* Should never reach here! */
    x=30;
    return 0;
}

static void vErrorChecks( void *pvParameters )
{
portTickType xDelayPeriod = mainNO_ERROR_FLASH_PERIOD;
unsigned portLONG ulMemCheckTaskRunningCount;
xTaskHandle xCreatedTask;

for (;;){

vParTestToggleLED( mainON_BOARD_LED_BIT );
    //dly(800000);
vTaskDelay( 5000);
    }
#if 0
// original code

#endif
}

9

nobody wrote on Thursday, July 28, 2005:

Hmm.  Tricky one.  I presume you are able to step through the code with the wiggler?

If you place a break point on the first line of vErrorChecks() (or anywhere before the delay), does the break point get hit.  If so then the scheduler is starting the first task but there is a problem with the tick maybe.  If not then there seems to be a problem with starting the first task.

Previously people have had problems starting the scheduler because the CPU mode is wrong when the scheduler starts.  Are you using the startup code from the download?  The CPU must be in supervisor mode when the scheduler is started.  Are you able to check this?

10

nobody wrote on Thursday, July 28, 2005:

Thanks for your response.
I am able to step thru the code.
I can put a break point inside the vErrorChecks(…)
and program breaks at the defined point i.e. at taskDelay as well as on Toggle led call. But that happens only one time.

The boot.s file that I am using is from the download and is dated 1-25-05

Regards,
B

11

rtel wrote on Friday, July 29, 2005:

Seems we are tracking it down, but now we are getting to the really detailed bit.

What I would suggest is:

+ Switch to the cooperative scheduler (set configUSE_PREEMPTION to 0 in FreeRTOSConfig.h).  This will prevent the tick interfering with the debugger.

+ Put a break point on your vTaskDelay() call in the error checks task.

+ Run the code so it breaks on the delay  we then no the scheduler has started and started the first task correctly (as before).

+ Next open tasks.c, search for the function prvIdleTask()  it is defined as:

static portTASK_FUNCTION( prvIdleTask, pvParameters )

and place a break point on the line prvCheckTasksWaitingTermination().  This is at the top of the idle task function loop.  Now continue running the code  it should break on the second break point almost immediately.

When your first task calls delay  the only other task in your system (being the idle task) should start to run.   If the second break point is hit then the switch to the idle task was successful.  If you then never leave the idle task even after the expiration of the delay it would seem that there might be a tick problem.

Each time you continue to exit the code the idle task should loop round and hit the second break point again.  Can you check this happens.  Then you could try running it for a second or two, break again and inspect the variable xTickCount (within tasks.c).  It should not be zero if the tick interrupt is working.

Any further tests will involve stepping through the task switch which is a little more complex.

Try the above first to see if we can narrow the problem down even further.  If there are still problems then you could try sending me a zip file containing the entire project (inc. makefiles. etc.) and I could try it here.  I will be out of the office for an extended period for the next week or two so will be away from my hardware but I still may be able to spot something.  If you send the zip file send it to the email address from the contacts page of the FreeRTOS.org WEB site (r dot barr. at  freerto…).

Regards.

12

nobody wrote on Friday, July 29, 2005:

Thank you very much for your response.
As suggested, I tried setting the configUSE_PREEMPTION = 0.
I get to the first break point (taskDelay()) but
It never hit the second break point.

I went back and set the configUSE_PREEMPTION = 1.
Same results.
Regards,
B

13

rtel wrote on Friday, July 29, 2005:

Once it has stopped responding, if you stop the debugger, what is it executing?

I think you said before that you are using the startup code from the download, so this must mean that the SWI handler is installed correctly.

You could try stepping into the vTaskDelay() function.  At the very bottom of this function is a call to taskYIELD().  This is effectively an SWI instruction.  If you break the code there, then switch into asm view in the debugger, you can step through the task switch code and see what happens.  Unless you are already familiar with the scheduler code this might be a bit tricky.

If you could send me the code ASAP I could take a look before my trip.

14

nobody wrote on Friday, July 29, 2005:

I sent you a zip file. Please let me know if you received it.
Thank you very much for your help.
Regards,
B

15

rtel wrote on Friday, July 29, 2005:

Is the hex file in the zip file built for RAM execution?  I cannot get it to work, however my processor is different to your (it is actually an AT91FR40162) so maybe this is not surprising.

I can do a clean build using:

>touch makefile
>rom_thumb

then blow the resulting hex file into the flash and it runs fine  no problems.  I have left it for half an hour and it just keeps flashing every 5 seconds.  I did not change any source or build files.

I am however having problems with execution from RAM.  I think this must be due to an incorrect startup sequence.  Maybe the remap is not working when the hardware is set up?

If you want to do a clean rom_thumb build and send me the hex file I can try blowing it into the flash.  If this works it rules out your compiler as being the problem.

Regards.

16

nobody wrote on Friday, July 29, 2005:

Richard,
I have sent you the hex file on your e-mail address.
Anything, I should be trying?
Thanks,
B

17

rtel wrote on Friday, July 29, 2005:

This hex file works too.  Toggles exactly every 5 seconds (after the first four toggles).

But this file does not work on your hardware?  Could this be a linker script issue if your hardware has a different memory map?

18

nobody wrote on Friday, July 29, 2005:

I have never tried the rom version on my board. I was still trying to get something to work. I am not sure if the code would work as it is on the flash?
Was this code tested on  AT91FR40162 board?
What utility do you use to burn the code into flash - may be I can try that by modifying the atmel-rom.ld file to tailor it to my harware map i.e. Flash at 0x01010000 and RAM at 0x02000000

Thanks,
B

19

rtel wrote on Friday, July 29, 2005:

Yes, I tried it on the 40162 board, the Embest ATE40X board.  Flashed with the Embest flash tool.

20

nobody wrote on Monday, August 01, 2005:

Well, I am lost.
Will touch base with you after you come back from vacation.
Have fun at vacation.
B