Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: FreeRTOS и arm-elf-gdb
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
xelax
Попытался подебажить проект с FreeRTOS и наткнулся на то что, не стартует проект под дебагером.

sam7x + arm-elf-gcc\gdb + eclipse

В проектах без FreeRTOS хожу по шагам, смотрю переменные и т.д. Всё нормально.

Вопрос, что меняется для дебагера при использовании FreeRTOS и как это побороть? Отлаживать код с помощью светодиодов не здорово. crying.gif

вот инициализационные данные:


target remote localhost:2331

monitor reset
monitor speed 30
monitor speed auto
monitor long 0xffffff60 0x00320100
monitor long 0xfffffd44 0xa0008000
monitor long 0xfffffc20 0xa0000601
monitor sleep 100
monitor long 0xfffffc2c 0x00480a0e
monitor sleep 200
monitor long 0xfffffc30 0x7
monitor sleep 100
monitor long 0xfffffd08 0xa5000401
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed
set remote memory-read-packet-size 1024
set remote memory-read-packet-size fixed
symbol-file test.elf
continue


P.S. JTAG Atmel SAM-ICE

P.P.S
Я пока не большой знаток составления make файлов в рукопашную. Взял makefile из примеров с сайта FreeRTOS. Возможно, какую-то из опций нужно добавить для информации для дебагера.
yaghtn
Цитата(xelax @ Nov 2 2007, 17:56) *
вот инициализационные данные:


target remote localhost:2331
.....
symbol-file test.elf
continue

А breakpoint где-нить вообще выставляется? На Reset, или на main(), например.
xelax
Цитата(yaghtn @ Nov 3 2007, 12:49) *
А breakpoint где-нить вообще выставляется? На Reset, или на main(), например.


07.gif а надо???
Если можно, то поподробней об этом.
И почему без ОС без брейкпойнтов на main останавливается?

З.Ы. инициализационный данные честно содрал с доки James Lynch с сайта атмела.
Сергей Борщ
Цитата(xelax @ Nov 6 2007, 09:03) *
07.gif а надо???
Если можно, то поподробней об этом.
В примерах с сайта Yagarto в скриптах дебаггера встречается команда
Код
break main
xelax
Цитата(Сергей Борщ @ Nov 6 2007, 17:26) *
В примерах с сайта Yagarto в скриптах дебаггера встречается команда
Код
break main


Дело было не в бабине sad.gif Установка брейкпойнта на main не помогла... Умирает где-то раньше, установка запрета wdt первой командой, тоже не помогла. Проблема в чём то ещё.

Народ, а кто-нибудь в проектах на основе FreeRTOS по шагам с помощью arm-elf-gdb ходил?
yaghtn
Цитата(xelax @ Nov 7 2007, 09:35) *
Установка брейкпойнта на main не помогла... Умирает где-то раньше


Ну вот и поставьте брейкпоинт раньше, чтоб понять где умирает.
На самый _start,
или вообще на нулевой адрес (последнюю строчку "continue" уберите).
xelax
Цитата(yaghtn @ Nov 7 2007, 13:05) *
Ну вот и поставьте брейкпоинт раньше, чтоб понять где умирает.
На самый _start,
или вообще на нулевой адрес (последнюю строчку "continue" уберите).

в том то всё и дело, что при наличии "continue" он упорно останваливается на нулевом адресе...

вот лог...

Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0xEA00233A)
Read 4 bytes @ address 0x00000000 (Data = 0xEA00233A)
Resetting target
JTAG speed set to 30 kHz
Select auto JTAG speed (8000 kHz)
Writing 0x00320100 @ address 0xFFFFFF60
Writing 0xA0008000 @ address 0xFFFFFD44
Writing 0xA0000601 @ address 0xFFFFFC20
Sleep 100ms
Writing 0x00480A0E @ address 0xFFFFFC2C
Sleep 200ms
Read 4 bytes @ address 0x00000000 (Data = 0xEA00233A)
Read 4 bytes @ address 0x00000004 (Data = 0xE59FF014)
Read 4 bytes @ address 0x00000008 (Data = 0xE59FF014)
Read 4 bytes @ address 0x0000000C (Data = 0xE59FF014)
Read 4 bytes @ address 0x00000010 (Data = 0xE59FF014)
Read 4 bytes @ address 0x00000014 (Data = 0xE1A00000)
Read 4 bytes @ address 0x00000018 (Data = 0xE51FFF20)
Read 4 bytes @ address 0x0000001C (Data = 0xE59FF00C)
Read 4 bytes @ address 0x00000020 (Data = 0x00100034)
Read 4 bytes @ address 0x00000024 (Data = 0x001000D0)
Read 4 bytes @ address 0x00000028 (Data = 0x00100038)
Read 4 bytes @ address 0x0000002C (Data = 0x0010003C)
Read 4 bytes @ address 0x00000030 (Data = 0x00100040)
Read 4 bytes @ address 0x00000034 (Data = 0xEAFFFFFE)
Read 4 bytes @ address 0x00000038 (Data = 0xEAFFFFFE)
Read 4 bytes @ address 0x0000003C (Data = 0xEAFFFFFE)
Read 4 bytes @ address 0x00000040 (Data = 0xEAFFFFFF)
Read 4 bytes @ address 0x00000044 (Data = 0xE24EE004)
Read 4 bytes @ address 0x00000048 (Data = 0xE92D4000)
Read 4 bytes @ address 0x0000004C (Data = 0xE14FE000)
Read 4 bytes @ address 0x00000050 (Data = 0xE92D4001)
Read 4 bytes @ address 0x00000054 (Data = 0xE59FE024)
Read 4 bytes @ address 0x00000058 (Data = 0xE59E0104)
Read 4 bytes @ address 0x0000005C (Data = 0xE58EE104)
Read 4 bytes @ address 0x00000060 (Data = 0xE92D50FE)
Writing 0x00000007 @ address 0xFFFFFC30
Sleep 100ms
Writing 0xA5000401 @ address 0xFFFFFD08
Setting breakpoint @ address 0x00103D2C, Size = 2, BPHandle = 0x0001
Starting target CPU...

останавливаемся на старте контроллера и всё... Хотя в дизасм окошке активная строчка расположенная по нулевому адресу...

нажатие кнопочки ресет, приводит к установки брейкпойнта на main.
xelax
Тупо добавил monitor reset перед continue
Теперь контроллер ресетуется не мной по кнопочке и дебаггером smile.gif
Пока работаю так.

Что скажут по этому поводу знающие люди. Как правильно сделать?
yaghtn
Цитата(xelax @ Nov 7 2007, 18:15) *
Тупо добавил monitor reset перед continue
Теперь контроллер ресетуется не мной по кнопочке и дебаггером smile.gif
Пока работаю так.


Не понятно, зачем сброс перед continue,
либо зачем скрипт что-то пишет в память мк.

"symbol-file test.elf" - у вас программа работает из внутренней флеш-памяти? Чем/как шъётся?
И опять не ясно, зачем тогда запись скриптом отладчика в память мк,
все инициализации должны быть расписаны в программе, заливаемой во флеш.
xelax
Цитата(yaghtn @ Nov 8 2007, 09:36) *
Не понятно, зачем сброс перед continue,
либо зачем скрипт что-то пишет в память мк.

"symbol-file test.elf" - у вас программа работает из внутренней флеш-памяти? Чем/как шъётся?
И опять не ясно, зачем тогда запись скриптом отладчика в память мк,
все инициализации должны быть расписаны в программе, заливаемой во флеш.


Да программа работает из внутренней флеши. Шью прогу самбой через sam-ice jtag.
Программа сама естественно всё инициализирует (настройка векторов, стека, lowlevelinit и т.д.).

Зачем что-то пишу в память? smile.gif Потомушта пока чайник в этом деле. Просто тупо скопировал чужие рабочие скрипты. До этого отлаживался в IAR и поэтому ни о каких скриптах и слыхом не слыхивал.

Был бы очень признателен если бы рассказали как надо правильно делать.

З.Ы. После того как убрал запись в регистры, дебаггер запускается нормально и без monitor reset перед continue.
yaghtn
Цитата(xelax @ Nov 8 2007, 09:59) *
Да программа работает из внутренней флеши. Шью прогу самбой через sam-ice jtag.
Программа сама естественно всё инициализирует (настройка векторов, стека, lowlevelinit и т.д.).

Зачем что-то пишу в память? smile.gif Потомушта пока чайник в этом деле. Просто тупо скопировал чужие рабочие скрипты. До этого отлаживался в IAR и поэтому ни о каких скриптах и слыхом не слыхивал.

Был бы очень признателен если бы рассказали как надо правильно делать.


Ничего лишнего делать не надо.
target remote 127.0.0.1:2331
monitor speed auto
monitor reset
symbol-file test.elf
thbreak _start (или main)
c

В том же gdb скрипте можно организовать и прошивку флеши, я например писал самой первой строчкой:
shell "C:\Program Files\SEGGER\JLink\jflasharm.exe" -openprj./prj/lpc2214.jflash -opentest.hex -auto -exit
target remote .... и т. д.


Запись отладчиком в память применяется для инициализации. Ремап, инициализация внешней sdram вместе с pll, например.
Да и то, мне например, кажется удобнее сваять небольшую программку, выполняющую необходимые процедуры (воспользовавшись имеющимися *.h файлами для имеющегося мк, а не прописывая в gdb скрипт кучу голых адресов и задержек) и грузить сначала её,
а потом отлаживаемую прогу:

target remote 127.0.0.1:3333
set *0xffffef00=0x3 //ремап
file init.elf
thbreak done
load
c

file test.elf
thbreak main
load
c
xelax
Спасибо за объяснение. a14.gif
Буду дальше изучать матчасть smile.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.