segfault in memset

Rule No.1: feel free to report any suspicious things without feeling guilty, because the discussion here might help someone sooner or later.

Back to the question, it looks to me that a wrong address is used as the entry address to library function memset. Are you using memset from libraries in our tool chain or from libraries provided by others? Is it possible for you implement a small case for us to reproduce this issue?

Seems like you are linking a ARM-mode library to Thumb-mode applicaiton. Can you please share your final link command? Experience shows it's better to use command like "arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 ..." to perform the link, such command will find correct library automatically.

Hi Terry

Thanks for your response. The final link command is, in summary (full command at end of post):

arm-none-eabi-gcc -o freertos-usart-et-stm32f103.elf (object files) -Os -g -Wall -Wextra -I. (other -I's) -fno-common -mthumb -MD -ffunction-sections -fdata-sections -mcpu=cortex-m3 -msoft-float -lc -Tstm32-h103RBT6.ld -nostartfiles -Wl,--gc-sections -march=armv7 -mfix-cortex-m3-ldrd

I can see in there the two switches you mentioned. I gather your concern is that it is picking up wrong libc.a.

A portion of Makefile may be a bit clearer (some options are redundant for linking):

------------------------------------
INCLUDES = $(patsubst %,-I%,$(DRIVERS_INC) $(FREERTOS_INC) $(FREERTOS_DEV))

CFLAGS += -Os -g -Wall -Wextra -I. $(INCLUDES) -fno-common -mthumb -MD
CFLAGS += -DGCC_ARMCM3 -ffunction-sections -fdata-sections
CFLAGS += -mcpu=cortex-m3 -DSTM32F1 -msoft-float

LDSCRIPT = stm32-h103RBT6.ld

LDFLAGS += -I . -lc -T$(LDSCRIPT) -L$(DRIVERS_DIR)/lib -nostartfiles -Wl,--gc-sections -mthumb
LDFLAGS += -march=armv7 -mfix-cortex-m3-ldrd -msoft-float -lopencm3_stm32f1

CFILES = buffer.c $(PROJECT).c rcc.c gpio.c
CFILES += tasks.c list.c queue.c timers.c port.c heap_1.c

OBJS = $(CFILES:.c=.o)

all: $(PROJECT).elf $(PROJECT).bin $(PROJECT).hex $(PROJECT).list $(PROJECT).sym
------------------------------------

I replaced -lc with the full path to the thumb libc. The program now works.

Can you think of a reason why it isn't finding the thumb libc?

Ken

arm-none-eabi-gcc -o freertos-usart-et-stm32f103.elf buffer.o freertos-usart-et-stm32f103.o ../../arm-library/libopencm3-examples/libopencm3/lib/stm32/f1/rcc.o ../../arm-library/libopencm3-examples/libopencm3/lib/stm32/f1/gpio.o tasks.o list.o queue.o timers.o port.o heap_1.o -Os -g -Wall -Wextra -I. -I../../arm-library/libopencm3-examples/libopencm3/include -I../../arm-library/FreeRTOS/Source/include -I../../arm-library/FreeRTOS/Source/portable/GCC/ARM_CM3 -fno-common -mthumb -MD -DGCC_ARMCM3 -ffunction-sections -fdata-sections -mcpu=cortex-m3 -DSTM32F1 -msoft-float -I . -lc -Tstm32-h103RBT6.ld -L../../arm-library/libopencm3-examples/libopencm3/lib -nostartfiles -Wl,--gc-sections -mthumb -march=armv7 -mfix-cortex-m3-ldrd -msoft-float -lopencm3_stm32f1

Hi Joey

Looks like your suggestion of -march=armv7-m works OK on all my programs.

I really appreciate your help. I was a bit stumped there for a few days.

cheers and thanks, Ken

Thanks Joey Ye, that solved my question.

Hi Joey Ye,

 I am a bit confused... may I ask what did you meant by "and remove -mfix-cortex-m3-ldrd, which is included"?

Does that mean that whenever I build something with -mcpu=cortex-m3 the ldrd errata related workaround of GCC is included implicitly?

I am using an MCU which comes with an r2p1 cortex-m3 core which supposedly fixes the ldrd error according to the errata sheet: http://www.ath.bielsko.pl/~kkajstura/mwa/Cortex-M3-Errata-r2p1-v3.pdf

If my understanding is correct and the fix is really included implicitly, is there a way to switch it off?

Thank you in advance for your kind response.

Best regards,
 Tamas

_