Подключение libc (из состава arm-kgp-eabi) на STM32, Необходимо подключит стандартную библиотеку к проекту Опции

[gba]

Пытаюсь подключить стандартную библиотеку к проекту для STM32. Использую Eclipse + тулчейн от KGP.

Насколько я понимаю, линкер должен выдать мне десяток сообщений о том, что не найдены системные вызовы типа sbrk, read, write и т.д., но ничего подобного не происходит все компилится на ура. Однако при попытке вызова printf() проц вываливается в HardFault. Если я правильно понимаю это может происходить из-за проблем с адресацией(?). Т.е., например, указатель указывает на область данных?

Параметры компиляции:

Код

CROSS_COMPILE    = arm-kgp-eabi-
CC                = $(CROSS_COMPILE)gcc
LD                = $(CROSS_COMPILE)gcc
AR                = $(CROSS_COMPILE)ar
AS                = $(CROSS_COMPILE)as
CP                = $(CROSS_COMPILE)objcopy
OD                = $(CROSS_COMPILE)objdump
OPENOCD            = openocd

CCFLAGS    = -std=c99 -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb -DSTM32F10X_HD -DUSE_FULL_ASSERT -DUSE_STDPERIPH_DRIVER
ARFLAGS = -rcs
LDFLAGS    = -Tstm32_flash.ld -nostartfiles -nostdlib -L../lib
CPFLAGS    = -Obinary
ODFLAGS    = -S

В чем может быть косяк?

PS Могу выложить Makefile целиком, если необходимо

[gba]

Можно не любить калькулятор, но он тем не менее ускоряет работу Честно говоря, я первый раз сталкиваюсь с таким глюкаловом при отладке. Хотя может это специфика отладки железок?

Спасибо за работающий обработчик HardFault. К сожалению он ясности не добавил, вот что в регистрах:

Код

        r0 = 0x08018238
        r1 = 0x000000FF
        r2 = 0x00000001
        r3 = 0x200008F0
        r12 = 0xFFEFFBFF
        lr = 0x08000829
        pc = 0x0800128C
        psr = 0x21000000

По адресу 0x0800128C вызов printf():

Код

287           printf("New DBGU enabled %d!\n", 0xff);
08001280:   movw r0, #33336; 0x8238
08001284:   movt r0, #2049 ; 0x801
08001288:   mov.w r1, #255 ; 0xff
0800128c:   blx 0x800e050 <printf>

Соответственно по адресу 0x0800e050 printf() и лежит:

Код

          printf:
0800e050:   push {r0, r1, r2, r3}
0800e054:   push {lr}              ; (str lr, [sp, #-4]!)
0800e058:   ldr r3, [pc, #44]      ; 0x800e08c <printf+60>
0800e05c:   sub sp, sp, #12
0800e060:   ldr r0, [r3]
0800e064:   add r12, sp, #20
0800e068:   ldr r1, [r0, #8]
0800e06c:   ldr r2, [sp, #16]
0800e070:   mov r3, r12
0800e074:   str r12, [sp, #4]
0800e078:   bl 0x800e1a4 <_vfprintf_r>
... ... ...

Принципиальных отличий с Вашим примером не смог пока найти... пробовал даже подсовывать в свой проект Ваши sysinit.c и syscalls.c толку ноль. Скрипт линкера тоже такой же. Единственное, что может еще отличаться это Standard Peripheral Library - я качал где-то месяц назад с сайта ST.

[AHTOXA]

Можно не любить калькулятор, но он тем не менее ускоряет работу

Посчитать 2+2 быстрее в уме

Код

0800128c:   blx 0x800e050 <printf>

Меня смутило blx. Насколько я понимаю, это вызов с переключением режима. Причём, поскольку операнд имеет сброшенный нулевой бит, то переключение в ARM-моде, которого в кортексах нет. Вот и HardFault... Вы случаем не потеряли ключик -mthumb или что-то типа того?

[gba]

Меня смутило blx. Насколько я понимаю, это вызов с переключением режима. Причём, поскольку операнд имеет сброшенный нулевой бит, то переключение в ARM-моде, которого в кортексах нет. Вот и HardFault... Вы случаем не потеряли ключик -mthumb или что-то типа того?

Это фейл... Я думал архитектуру только компилятору надо указывать, а оказывается еще и линкеру. Спасибо в очередной раз!

PS Всегда всем говорил, что программить надо начинать с ассемблера, а сам до армового ассемблера так и не добрался

[AHTOXA]

Да ерунда всё это. Нормальный процесс начального вхождения. Дальше всё легче пойдёт.
ЗЫ. Ассемблер для АРМ я тоже не знаю, так, читаю со словарём