STR912 Same Task ARM mode Crash Thumb OK

damienhoyen wrote on Thursday, September 18, 2008:

Hi everybody,

I m experiencing a strange problem, on the STR912 port
compiled with GCC / Yagarto / Eclipse

I configured my system with 6 task, each task has a really confortable 4 KByte stack (its huge but this microcontroller has 96 K, thats why)

When i compiling the C file in ARM mode which include a FreeRTOS task, the system crash in a endless reset loop, as soon as the scheduler start  (all my other file with task has always been compiled in thumbs why i never had problem before).


Exactly the same code, just the C file which include this FreeRTOS task compiled in THUMB mode works perfectly.

My function does nothing, for the test, i put just a endless while inside (look code)

Is somebody have already experienced this problem or a explanation ?
Did I do a mistake in compilation option of my makefile ?

Any ideas welcome.
Thanks in advance.



void FunctionTest(void *pvParameters)
    while (1);

davedoors wrote on Thursday, September 18, 2008:

Have you set -DTHUMB_INTERWORK in the compiler options. Assuming the STR9 port does the same as the STR750 port.

damienhoyen wrote on Thursday, September 18, 2008:

Hi Dave,

Thanks for your reply :

Yes, the THUMB_INTERWORK flag is present,
I included all compilation option, below.


-------------8< ------------------------------------------
-D PACK_STRUCT_END=__attribute\(\(packed\)\)
-D ALIGN_STRUCT_END=__attribute\(\(aligned\(4\)\)\)
-Wreturn-type -Wunused -Wimplicit -Wpointer-arith -Wswitch \

Thumb file compilation
$(CC) -c $(CFLAGS) -mthumb $< -o $@

ARM File compilation
$(CC) -c $(CFLAGS) $< -o $@

rtel wrote on Thursday, September 18, 2008:

The STR9 GCC port is a contributed port that I am not familiar with.  Check that it actually uses the THUMB_INTERWORK definition within its port.c file.  You can look at any of the official ARM7 GCC port.c files in the download to see how it is used.


ben_fnr wrote on Thursday, September 18, 2008:

I think that may have been my fault. I was looking at the Makefile the other day and noticed that the cpu/arch type is set to arm7tdi, I think, I can’t check until tomorrow.
If compiling THUMB code, this probably doesn’t matter to much and it would probably be the same, but if you are compiling ARM code I am not sure if it is compatible. I am not sure exactly what the differences are between the 2 cores.


stf12 wrote on Friday, September 19, 2008:

Hi Damien,

have you given a look to the STR9\GCC\Eclipse contributed RTOS demo? It works in ARM mode. I used Code Sourcery GNU tool chain.

And I made that demo starting from the Ben’s demo! :wink:


damienhoyen wrote on Friday, September 19, 2008:

Hi all,

To repply to STef :

In fact, Richard gave me by mail the STR912 GCC port, 3 or 4 months ago.

But it’s exactely the same file.

In the demo (to be sure we speaks about same file),\FreeRTOS\Demo\Unsupported_Demos\\STR9\\str91x_gcc

Unfortunately, in this demo, no task have been compiled in ARM mode.
Is somebody is able to reproduce this problem ?

To reply to Ben,

I haven’t yet tried in ARM7TDMI and ARM mode. I will do it and keep you in touch.
Seems a STR91x is “core compatible” to execute a Arm7TDMI code
(i never tried this kind of attempt and in all case, you will have plenty of problem with peripherals)

Yes, i changed to ARM9, I would change to ARM9E, but i have some trouble during the linkage with Newlib,  for the hardware / software processing of integer.
Means at this moment, i m not using the hardware "DSP" unit for a software emulation. Hopefuly, i have no numerical filtering or this kind of treatment, but…

If somebody have an idea, it’s welcome.

Thanks all…



damienhoyen wrote on Friday, September 19, 2008:


I tried by changing the target for ARM7TDMI, task file compiled in ARM mode and in fact, I have exactely the same trouble, as with the ARM9

I tried to move my task from a compilation in ARM mode to a thumb mode, still with a ARM7TDMI flag, and logically, it’s working.

Seems it’s not an error from this side.



ben_fnr wrote on Friday, September 19, 2008:

Are you compiling in pure ARM mode or thumb-interworking mode.

I have an Ogg decoder compiled in thumb-interworking mode working fine on the STR9x, but I have not tried pure ARM code.

Are you mixing pure ARM code with thumb-interwoking libraries ?

Do you have interrupt handlers for Undefined/Program/Data Abort interrupts. Is it possible you are getting one of these ?

Sorry can’t really think of anything else at the moment.

stf12 wrote on Saturday, September 20, 2008:

Hi Damien,

II speak about another demo (I made it only about one month ago ;-).
I had the same problem trying to compile in ARM mode and I solved it by modifying the makefile:


THUMB    = -mthumb
THUMB_IW = -mthumb-interwork
THUMB    =

# should use --gc-sections but the debugger does not seem to be able to cope with the option.
LINKER_FLAGS=  $(THUMB) -nostartfiles -Xlinker -oRTOSDemo.axf -Xlinker -M -Xlinker -Xlinker --no-gc-sections

        -D STR91X_GCC
        -D STACK_LWIP_130
        -D $(THUMB_D)
        -D PACK_STRUCT_END=__attribute\(\(packed\)\)
        -D ALIGN_STRUCT_END=__attribute\(\(aligned\(4\)\)\)

$(THUMB_OBJS) : %.o : %.c Makefile FreeRTOSConfig.h
    $(CC) -c $(CFLAGS) -mthumb $< -o $@

$(ARM_OBJS) : %.o : %.c Makefile FreeRTOSConfig.h
    $(CC) -c $(CFLAGS) $< -o $@


To compile in ARM mode I change the USE_THUMB_MODE macro.

Please note that -mthumb option automatically enables either 16-bit Thumb- 1 or mixed 16/32-bit Thumb-2 instructions based on the ‘-mcpu=name ’ and ‘-march=name ’ options. It is disabled by default to use  32-bit ARM instruction set.

I prefer also use the default -mno-thumb-interwork option since slightly larger code is generated when ‘-mthumb-interwork’ is specified.


P.S. I have not much experience with makefile, so any suggestion to improve it is welcome

damienhoyen wrote on Monday, September 22, 2008:

Hi all,

Thanks for all these repplies.

@ Ben

Usually, i compile all interrupts function in ARM mode, as other part of my code which could need a fairly fast execution.
In my case, more or less 80% of my code is thumb, 20% ARM…

I have a very comfortable size of flash (512K) and if tomorrow, i need a CPU execution little bit faster, i could be in the obligation to compile all the project in ARM mode.

The Newlib library (Yagarto) is (TBC) compiled in thumb (space optimisation)

In all case, i run in thumb-interworking mode, just to keep compatibility with the Newlib lib.

@ Stephano,

I just tried your makefile modification, to be right with you, now, i m receiving some errors from my startup file startup.s
like (register required: ‘ldmia SP!,{R0}’)…

Do you able to run a external library (like the Newlib) in this mode ?
I have a printf call to format string for LCD.



stf12 wrote on Tuesday, September 23, 2008:

Hi Damien,

if you are using a library compiled in thumb mode, you have to define USE_THUMB_MODE = YES to run in thumb-interworking mode, but note that some files has to be compiled in ARM mode:


I’m able to mix THUMB and ARM code using this configuration.

Otherwise you could compile the NewLib in ARM mode, but I have not tried to do it! :slight_smile:

If you simply need a printf implementation to format string, you find all needed at this web page I use that source file. In the STR91x project the outbyte function do nothing. In the STM32 project it is used to re-target the output in the display.


damienhoyen wrote on Tuesday, September 23, 2008:

Hi stefano:

Yes, according to your suggestion, i checked my makefile, these files have been compiled in ARM mode since the beginning, i think it’s not the source of these problem.

Below, my full makefile :wink:


#Project name

#RTOS directory

#ST Libraries
    #Standard I/O Lib.
    #USB lib.
    #Enet Lib


CC = arm-elf-gcc
OBJCOPY= arm-elf-objcopy
NM = arm-elf-nm
OBJDUMP = arm-elf-size

LINKER_FLAGS=-mthumb -nostartfiles -Xlinker -o$(PROJECT_NAME).elf --gc-section -lm -Xlinker -M -Xlinker -Map=$(PROJECT_NAME)LinkerOutput.txt


        -I $(ST_LIB_INC_DIR)
        -I $(ST_USB_INC_DIR)
        -I $(ST_NET_INC_DIR)
        -I $(EFSL_INC_DIR)
        -I $(APP_INC_DIR)
        -I $(RTOS_SOURCE_DIR)/include
        -I $(RTOS_SOURCE_DIR)/portable/GCC/STR9x
        -D ROWLEY_LPC23xx
        -D PACK_STRUCT_END=__attribute\(\(packed\)\)
        -D ALIGN_STRUCT_END=__attribute\(\(aligned\(4\)\)\)
        -Wreturn-type -Wunused -Wimplicit -Wpointer-arith -Wswitch \

# Here, File which will compiled in Thumb mode   
        $(APP_SRC_DIR)/main.c \

# Here, File which will compiled in ARM mode               
# Here, File which will force reconstruction of the project
        $(ST_LIB_ASS_DIR)/vector.s \


all: RTOSDemo.bin RTOSDemo.hex
RTOSDemo.hex : RTOSDemo.elf
    @echo "@@@ Generating HEX file @@@"
    $(OBJCOPY) -I elf32-littlearm $(PROJECT_NAME).elf -O ihex $(PROJECT_NAME).hex

RTOSDemo.bin : RTOSDemo.elf
    @echo "@@@ Generating BIN file @@@"
    $(OBJCOPY) -I elf32-littlearm $(PROJECT_NAME).elf -O binary $(PROJECT_NAME).bin
    $(CC) $(CFLAGS) $(ARM_OBJS) $(THUMB_OBJS) $(LIBS) $(ST_LIB_ASS_DIR)/startup.s $(ST_LIB_ASS_DIR)/vector.s $(LINKER_FLAGS)
    @echo "@@@ Build OK @@@"

$(THUMB_OBJS) : %.o : %.c $(CONFIG_FILE)
    $(CC) -c $(CFLAGS) -mthumb $< -o $@

$(ARM_OBJS) : %.o : %.c $(CONFIG_FILE)
    $(CC) -c $(CFLAGS) -marm $< -o $@

clean :
    rm $(THUMB_OBJS)
    rm $(ARM_OBJS)
    rm $(PROJECT_NAME).elf
    rm $(PROJECT_NAME).bin
    rm $(PROJECT_NAME).hex
    @echo "Clean OK"

damienhoyen wrote on Tuesday, September 23, 2008:


Another details, he seems, if the interrupt branched is correct (i put a breakpoint in the vector table, should be correct)
the processor trig a PREFECT ABORT Exceptions before the crash.

Any ideas welcome.

Thanks in advance


stf12 wrote on Thursday, September 25, 2008:

Hi Damien,

could you reproduce the problem using only some of the standard FreeRTOS task (for example math task, integer task, blocking queue task, … )?

If yes, and if you could send me your main.c and your Makefile, I’m able to reproduce the problem too in order to better analyze it.


damienhoyen wrote on Friday, October 03, 2008:

Hi Stephano,

Sorry for this repply little bit late, i had a lack of time these previous days.
I did a really simple project, 3 tasks, no interrupt (except the RTOS tick, of course)… and same problem…

where can i send you the project ?



stf12 wrote on Friday, October 03, 2008:

Hi Damien,

you can send me the project at

  software AT stf12 DOT net


stf12 wrote on Monday, October 13, 2008:

Hi Damien,

In my opinion the problem is not in the Makefile but in the portable layer, in the pxPortInitialiseStack function. Moreover the bug should affect the STR9 IAR port too.
The problem is that when the macro THUMB_INTERWORK is defined the THUMB mode bit of the initial SPSR registry of the task is always set, and if have a task entry function is compiled in ARM mode the system hung.

To fix the problem without modifying the kernel source code, I added a new extension API function - TaskCreateEx. For more information about my proposal solution, please look at the following web page

Any feedback is welcome.