Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Compiling with GCC

Posted by Nobody/Anonymous on 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







RE: Compiling with GCC

Posted by Nobody/Anonymous on 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.

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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.

RE: Compiling with GCC

Posted by Richard on 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.

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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.

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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.

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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
}

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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?

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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

RE: Compiling with GCC

Posted by Richard on 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.

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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

RE: Compiling with GCC

Posted by Richard on 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.

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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

RE: Compiling with GCC

Posted by Richard on 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.

RE: Compiling with GCC

Posted by Nobody/Anonymous on July 29, 2005
Richard,
I have sent you the hex file on your e-mail address.
Anything, I should be trying?
Thanks,
B

RE: Compiling with GCC

Posted by Richard on 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?

RE: Compiling with GCC

Posted by Nobody/Anonymous on 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

RE: Compiling with GCC

Posted by Richard on July 29, 2005
Yes, I tried it on the 40162 board, the Embest ATE40X board. Flashed with the Embest flash tool.

RE: Compiling with GCC

Posted by Nobody/Anonymous on August 1, 2005
Well, I am lost.
Will touch base with you after you come back from vacation.
Have fun at vacation.
B

RE: Compiling with GCC

Posted by Richard on August 3, 2005
Unfortunately a business trip, not a vacation. :-(

RE: Compiling with GCC

Posted by Nobody/Anonymous on August 8, 2005
Here is the update on where I am:
I was able to flash my code into Flash and run it. It worked fine - i.e. the led starts flashing at regular intervals as expected.
For this to work, I had to do the following:
MEMORY
{
flash: ORIGIN = 0x00000000, LENGTH = 64K
ram: ORIGIN = 0x00300000, LENGTH = 128K
}

__stack_end__ = 0x00300000 + 128K - 4;

What is not clear to me is :
Since the boot.s does not do any re-mapping, RAM that is available on power on at 0x00300000 is only 8K where as the linker file assumes it to be 128K.
Do you have any ideas on this??

Now getting back to running it from RAM,
I have tried various combinations of memory mapping and the only one that PARTIALLY works is:
MEMORY
{
sram: org = 0x00200000, len = 512K/* 512KBytes of SRAM */

}
__stack_end__ = 0x02000000 +5128K - 4;

This flashes the LED 4 times (as programmed) but then stops asoon as the OS is started.

I have tried using the secondary RAM bank statring at 0x00100000 but it would not even load the code there?

Setting the memory at 0x000000000 did not work either.


Any suggestions?


Regards,
B

RE: Compiling with GCC

Posted by Nobody/Anonymous on August 9, 2005
Can you remap using the JTAG. Some JTAGs have scripts that can peek and poke before and after download. This way you can remap before the code runs, and therefore run it directly from RAM at the start.

I suspect the problem of the LED's running but stopping when the scheduler starts is due to incorrect mapping of the IRQ vector. The code runns fine from RAM, but when the scheduler starts the tick interrupt is causing a vector to an incorrect address.

You can manually copy the vectors into the correct place. Look at the position and size in RAM of the vectors, then copy them into the correct place following the remap.

RE: Compiling with GCC

Posted by Nobody/Anonymous on August 9, 2005
Interrupt vector seems to be OK. I did the following experiment:
I added a dummy variable xTickCount1 in the vTaskIncrementTick() function to see if the interrupt was being invoked.
I put two break points in the code:
One in main routine, where I call the vTaskDelay(..)
and one in the tasks.c at the end of the vTaskIncrementTick().

inline void vTaskIncrementTick( void )
{
/* Called by the portable layer each time a tick interrupt occurs.
Increments the tick then checks to see if the new tick value will cause any
tasks to be unblocked. */
if( uxSchedulerSuspended == ( unsigned portBASE_TYPE ) pdFALSE )
{
++xTickCount;
++xTickCount1;//bs

if( xTickCount == ( portTickType ) 0 )
{
volatile xList *pxTemp;

/* Tick count has overflowed so we need to swap the delay lists. If there are
any items in pxDelayedTaskList here then there is an error! */
pxTemp = pxDelayedTaskList;
pxDelayedTaskList = pxOverflowDelayedTaskList;
pxOverflowDelayedTaskList = pxTemp;
}

/* See if this tick has made a timeout expire. */
prvCheckDelayedTasks();
}
else
{
++xTickCount1;//bs

++uxMissedTicks;
}
} //Added break point at the line number corresponding to this statement.

Second break point was added as:
break tasks.c:lineNumber if xTickCount1 > 20
i.e. the routine has been hit 20 times.
The program does break at this point and the value is 21.

Another observation:
If I remove the breakpoint in main, then it does not hit this break point either.

Any other ideas?
Desparately trying to get out of this to make some progress with the actual project.

Thank you for your time.
Regards,
b

RE: Compiling with GCC

Posted by Nobody/Anonymous on August 10, 2005
Are you able to send Richard the code? He is normally quite good at taking a look for people to see if anything can be found?

RE: Compiling with GCC

Posted by Nobody/Anonymous on August 10, 2005
He is helping but he is out on a business trip.
I don't think there is any issue with the code. I believe the issue is with the linker file. There are some difference in the available memory between AT91R40807 processor (which I have on my board) and the AT9140008 for which the code has been tested.

Any and all ideas are welcome as long as I can try it with my setup.
Regards,
B


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists