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

BUT

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.


Regards.

Damien





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

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

Hi Dave,

Thanks for your reply :

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


Regards.


-------------8< ------------------------------------------
-D ROWLEY_LPC23xx \
-D THUMB_INTERWORK \
-mcpu=arm9 \
-D PACK_STRUCT_END=__attribute\(\(packed\)\) \
-D ALIGN_STRUCT_END=__attribute\(\(aligned\(4\)\)\) \
-fomit-frame-pointer \
-ffunction-sections \
-mthumb-interwork \
-Wreturn-type -Wunused -Wimplicit -Wpointer-arith -Wswitch \

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

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

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.

Regards.

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.

Ben

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! ;-)

Regards
Stefano

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),
FreeRTOSV5.0.3.zip\FreeRTOS\Demo\Unsupported_Demos\STR9_GCC_BH.zip\STR9\str91x_gcc.zip\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..
Regards.

Damien.

OK,

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.

regards.

Damien

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

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:

------------------------------------------------------------------------------------
#USE_THUMB_MODE = YES
USE_THUMB_MODE = NO

ifeq ($(USE_THUMB_MODE),YES)
THUMB = -mthumb
THUMB_IW = -mthumb-interwork
THUMB_D = THUMB_INTERWORK
THUMB_CLEAN = cs-rm $(THUMB_OBJS)
else
THUMB =
THUMB_IW =
THUMB_D = NO_THUMB_INTERWORK
THUMB_CLEAN =
endif

# 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 -Map=rtosdemo.map -Xlinker --no-gc-sections

CFLAGS= $(DEBUG) \
$(OPTIM) \
-T$(LDSCRIPT) \
-D STR91X_GCC \
-D STACK_LWIP_130 \
-D $(THUMB_D)
-mcpu=arm966e-s \
-D PACK_STRUCT_END=__attribute\(\(packed\)\) \
-D ALIGN_STRUCT_END=__attribute\(\(aligned\(4\)\)\) \
-fomit-frame-pointer \
-ffunction-sections \
$(THUMB_IW)

$(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.

Regards,
Stefano

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

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.



Regards.

Damien

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:

---------------------------------------------------------------------------------------
ARM_SOURCE= \
91x_it.c \
$(RTOS_SOURCE_DIR)/portable/GCC/STR9x/port.c \
$(RTOS_SOURCE_DIR)/portable/GCC/STR9x/portISR.c \
---------------------------------------------------------------------------------------

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! :)

If you simply need a printf implementation to format string, you find all needed at this web page http://www.menie.org/georges/embedded/index.html. 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.

Regards,
Stefano

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

Damien



------------------------------------------------------------------------
#Project name
PROJECT_NAME=FreeRTOS

#RTOS directory
RTOS_SOURCE_DIR=./FreeRTOS/Source

#ST Libraries
#Standard I/O Lib.
ST_LIB_INC_DIR=./Library/ST_91x/Std/inc
ST_LIB_SRC_DIR=./Library/ST_91x/Std/src
ST_LIB_ASS_DIR=./Library/ST_91x/Std/asm
#USB lib.
ST_USB_INC_DIR=./Library/ST_91x/Usb/inc
ST_USB_SRC_DIR=./Library/ST_91x/Usb/src
#Enet Lib
ST_NET_INC_DIR=./Library/ST_91x/Net/inc
ST_NET_SRC_DIR=./Library/ST_91x/Net/src
ST_NET_ASS_DIR=./Library/ST_91x/Net/asm

#EFSL Lib
EFSL_INC_DIR=./Library/Efsl/inc
EFSL_SRC_DIR=./Library/Efsl/src
EFSL_INTERFACE_INC_DIR=./Library/Efsl/inc/interfaces
EFSL_INTERFACE_SRC_DIR=./Library/Efsl/src/interfaces

#Application
APP_INC_DIR=./Application/inc
APP_SRC_DIR=./Application/src


CC = arm-elf-gcc
OBJCOPY= arm-elf-objcopy
NM = arm-elf-nm
OBJDUMP = arm-elf-size
LDSCRIPT=./Project_Utils/str91x.ld

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

DEBUG=-g
OPTIM=-O0
#DEBUG=
#OPTIM=-O3



CFLAGS= \
$(DEBUG) \
$(OPTIM) \
-T$(LDSCRIPT) \
-I $(ST_LIB_INC_DIR) \
-I $(ST_USB_INC_DIR) \
-I $(ST_NET_INC_DIR) \
-I $(EFSL_INC_DIR) \
-I $(EFSL_INTERFACE_INC_DIR) \
-I $(APP_INC_DIR) \
-I $(RTOS_SOURCE_DIR)/include \
-I $(RTOS_SOURCE_DIR)/portable/GCC/STR9x \
-D ROWLEY_LPC23xx \
-D THUMB_INTERWORK \
-mcpu=arm9 \
-D PACK_STRUCT_END=__attribute\(\(packed\)\) \
-D ALIGN_STRUCT_END=__attribute\(\(aligned\(4\)\)\) \
-fomit-frame-pointer \
-mthumb-interwork \
-ffunction-sections \
-Wreturn-type -Wunused -Wimplicit -Wpointer-arith -Wswitch \


# Here, File which will compiled in Thumb mode
THUMB_SOURCE= \
$(RTOS_SOURCE_DIR)/list.c \
$(RTOS_SOURCE_DIR)/queue.c \
$(RTOS_SOURCE_DIR)/tasks.c \
$(RTOS_SOURCE_DIR)/portable/MemMang/heap_2.c \
$(ST_LIB_SRC_DIR)/91x_gpio.c \
$(ST_LIB_SRC_DIR)/91x_scu.c \
$(ST_LIB_SRC_DIR)/91x_vic.c \
$(ST_LIB_SRC_DIR)/91x_wiu.c \
$(ST_LIB_SRC_DIR)/91x_fmi.c \
$(ST_LIB_SRC_DIR)/91x_tim.c \
$(ST_LIB_SRC_DIR)/91x_uart.c \
$(ST_LIB_SRC_DIR)/91x_rtc.c \
$(ST_LIB_SRC_DIR)/91x_ssp.c \
$(ST_LIB_SRC_DIR)/91x_dma.c \
$(ST_LIB_SRC_DIR)/91x_adc.c \
$(EFSL_INTERFACE_SRC_DIR)/sdhc.c \
$(EFSL_INTERFACE_SRC_DIR)/ST91x_efls_spi.c \
$(EFSL_SRC_DIR)/efs.c \
$(EFSL_SRC_DIR)/plibc.c \
$(EFSL_SRC_DIR)/disc.c \
$(EFSL_SRC_DIR)/partition.c \
$(EFSL_SRC_DIR)/time.c \
$(EFSL_SRC_DIR)/fs.c \
$(EFSL_SRC_DIR)/fat.c \
$(EFSL_SRC_DIR)/file.c \
$(EFSL_SRC_DIR)/debug.c \
$(EFSL_SRC_DIR)/dir.c \
$(EFSL_SRC_DIR)/mkfs.c \
$(EFSL_SRC_DIR)/ioman.c \
$(EFSL_SRC_DIR)/ui.c \
$(EFSL_SRC_DIR)/extract.c \
$(EFSL_SRC_DIR)/ls.c \
$(APP_SRC_DIR)/main.c \

# Here, File which will compiled in ARM mode
ARM_SOURCE= \
$(RTOS_SOURCE_DIR)/portable/GCC/STR9x/portISR.c \
$(RTOS_SOURCE_DIR)/portable/GCC/STR9x/port.c \
$(APP_SRC_DIR)/vectors.c \

# Here, File which will force reconstruction of the project
CONFIG_FILE= \
./Makefile \
$(APP_INC_DIR)/FreeRTOSConfig.h \
$(ST_LIB_INC_DIR)/91x_conf.h \
$(EFSL_INC_DIR)/config.h \
$(ST_LIB_ASS_DIR)/startup.s \
$(ST_LIB_ASS_DIR)/vector.s \

#--------------------------------------------------------------------------------
THUMB_OBJS = $(THUMB_SOURCE:.c=.o)
ARM_OBJS = $(ARM_SOURCE:.c=.o)

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

RTOSDemo.elf : $(THUMB_OBJS) $(ARM_OBJS) $(CONFIG_FILE)
$(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"

Hi,


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

Regards

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.

Regards,
Stefano

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 ?


Regards.

Damien.

Hi Damien,

you can send me the project at

software AT stf12 DOT net


Regards,
Stefano

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

http://developers.stf12.net/just-another-eclipse-demo-str91x#TOC-The-systems-hung-mixing-tasks-compi

Any feedback is welcome.

Regards,
Stefano