Форум программистов, компьютерный форум, киберфорум
Наши страницы

Микроконтроллеры ARM, Cortex, STM32

Войти
Регистрация
Восстановить пароль
 
Pyko4u56
0 / 0 / 0
Регистрация: 27.01.2014
Сообщений: 287
#1

Собственный загрузчик и CooCox. - ARM, Cortex, STM32 микроконтроллер

19.06.2016, 22:14. Просмотров 4142. Ответов 10
Метки нет (Все метки)

Итак, мучаюсь тут с собственным простейшим загрузчиком.
В настройках линкера в основной прошивке прописал в секции IROM1 адрес начала 0x08005000 и размер пространства прошивки 0x0001D800, в настройках линкера для загрузчика - соответственно, начальный адрес 0x08000000 и размер 0x00004800. Между ними 1 страница для своих данных оставлена. Так вот, при таких настройках мне приходится сначала прошивать основную прошивку, а затем загрузчик, так всё работает. Наоборот - нет, видимо, при прошивке основной прошивке загрузчик затирается. Как заставить CooCox делать всё корректно? Do Not Erase не выходит, так как при данной опции выкидывает ошибку при прошивке.
P.S. И ещё вопрос - почему перенос таблицы прерываний перед прыжком в основную программу не работает? Перенос таблицы в самом начале основной программы работает нормально.
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
19.06.2016, 22:14
Я подобрал для вас темы с готовыми решениями и ответами на вопрос Собственный загрузчик и CooCox. (ARM, Cortex, STM32 микроконтроллер):

STM32L4 + STM32CubeMX + coocox или не coocox - ARM, Cortex, STM32 микроконтроллер
Разжился NUCLEO-L476RG. До этого с STM32 вообще дела не имел. Посмотрел на www.st.com/.../stm32l476rg.html какие средства разработки есть...

Coocox C++ - ARM, Cortex, STM32 микроконтроллер
Начиная новый проект в Coosox, решил вместо С использовать С++, это обосновано желанием использовать классы. После создания проекта, я...

Вопрос по CooCox - ARM, Cortex, STM32 микроконтроллер
Добрый день. Подскажите, пожалуйста, как поменять корневой каталог worksposi? Сам найти не могу, и не удобно когда каждый раз выбрасывает...

Eclipse - CooCox - ARM, Cortex, STM32 микроконтроллер
Привет, Форумчане! Помогите, пожалуйста)) Вопрос по Eclipce или CooCox.... Как подключить бинарный файл под именем переменной???? В...

CooCox и ST-LINK v2 - ARM, Cortex, STM32 микроконтроллер
Народ. Как подключить ST-LINK v2 к CooCox? Через ST-LINK Utility все прошивается... А CooCox не хочет... ...

Гребаный Coocox - ARM, Cortex, STM32 микроконтроллер
Уже второй день пишет при попытке дебага The project specified in the launch confikurotion is not a C/C++ one. Свежеустановлен на Wymdows...

10
MostirOtixiy
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
19.06.2016, 23:10 #2
Цитата Сообщение от Pyko4u56
Итак, мучаюсь тут с собственным простейшим загрузчиком.
В настройках линкера в основной прошивке прописал в секции IROM1 адрес начала 0x08005000 и размер пространства прошивки 0x0001D800, в настройках линкера для загрузчика - соответственно, начальный адрес 0x08000000 и размер 0x00004800. Между ними 1 страница для своих данных оставлена. Так вот, при таких настройках мне приходится сначала прошивать основную прошивку, а затем загрузчик, так всё работает. Наоборот - нет, видимо, при прошивке основной прошивке загрузчик затирается. Как заставить CooCox делать всё корректно? Do Not Erase не выходит, так как при данной опции выкидывает ошибку при прошивке.
Ну обычно сначала пишется загрузчик, а потом уже через загрузчик грузится основная прога, а не через прошиватель какой либо, так как он имеет обыкновение затирать весь чип, ну а некоторые продвинутые - не весь, а только измененные фрагменты.

Цитата Сообщение от Pyko4u56
P.S. И ещё вопрос - почему перенос таблицы прерываний перед прыжком в основную программу не работает? Перенос таблицы в самом начале основной программы работает нормально.
А ваша таблица, которая до прыжка в основную прогу, куда показывает? По идее, если правильно все делать, загрузчик вообще не должен знать о том, какие вектора в основной проге и где сидят, ему только можно знать размер проги, и куда ее писать. Все. Остальное - инфа только для основной проги, потому как она (основная прога) может быть разной.
И наверняка у вас это разные проекты, и таким образом сам линковщик вам сделает таблицу векторов именно в контексте загрузчика, а не в контексте основной проги, потому у вас и не работает первый вариант, потому что вы процу пихаете таблицу векторов, ничего общего с основной прогой не имеющую. Так?
0
Pyko4u56
0 / 0 / 0
Регистрация: 27.01.2014
Сообщений: 287
19.06.2016, 23:23 #3
Цитата Сообщение от MostirOtyxiy
Ну обычно сначала пишется загрузчик, а потом уже через загрузчик грузится основная прога, а не через прошиватель какой либо, так как он имеет обыкновение затирать весь чип, ну а некоторые продвинутые - не весь, а только измененные фрагменты.
Вот я и пытаюсь заставить писать только в нужные места)) Просто пока отладка и думал, что можно заставить прошиватель очищать только нужные фрагменты ftosh... Глянул сейчас, что записано по факту в контроллер: если очистить, затем записать основную прошивку, то в самом начале записывается какая-то фигня(порядка сотни байт), затем пусто и с нужного адреса записывается прошивка. Если сначала записать загрузчик, а потом прошивку, то, как я и думал, загрузчик затирается...

Цитата Сообщение от MostirOtyxiy
А ваша таблица, которая до прыжка в основную прогу, куда показывает? По идее, если правильно все делать, загрузчик вообще не должен знать о том, какие вектора в основной проге и где сидят, ему только можно знать размер проги, и куда ее писать. Все. Остальное - инфа только для основной проги, потому как она (основная прога) может быть разной.
И наверняка у вас это разные проекты, и таким образом сам линковщик вам сделает таблицу векторов именно в контексте загрузчика, а не в контексте основной проги, потому у вас и не работает первый вариант, потому что вы процу пихаете таблицу векторов, ничего общего с основной прогой не имеющую. Так?
Да, именно так)) Признаю, ступил :(
0
MostirOtixiy
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
20.06.2016, 00:10 #4
Цитата Сообщение от Pyko4u56
... то в самом начале записывается какая-то фигня(порядка сотни байт)...
Очень похоже по размеру на таблицу векторов прерываний. Обычно они в самом начале и сидят.
По крайней мере первые 4е байта всегда идет адрес стека. Потом 4е байта всегда идет адрес ресет вектора. Но вы вроде как в линкере изменили старт программной секции.

А поглядите в описание раздела IROM1. Там в нем должен быть, по идее, раздел, похожий на .vect или наподобие. Точнее, вам надо узнать, пихает ли CooCox таблицу веторов в отдельную секцию. Если да, то ее надо прописать в этот IROM1 раздел. Название можно вычепить из map файла, по идее.
0
Pyko4u56
0 / 0 / 0
Регистрация: 27.01.2014
Сообщений: 287
20.06.2016, 00:23 #5
Цитата Сообщение от MostirOtyxiy
Цитата Сообщение от Pyko4u56
... то в самом начале записывается какая-то фигня(порядка сотни байт)...
Очень похоже по размеру на таблицу векторов прерываний. Обычно они в самом начале и сидят.
По крайней мере первые 4е байта всегда идет адрес стека. Потом 4е байта всегда идет адрес ресет вектора. Но вы вроде как в линкере изменили старт программной секции.

А поглядите в описание раздела IROM1. Там в нем должен быть, по идее, раздел, похожий на .vect или наподобие. Точнее, вам надо узнать, пихает ли CooCox таблицу веторов в отдельную секцию. Если да, то ее надо прописать в этот IROM1 раздел. Название можно вычепить из map файла, по идее.

После полной очистки чипа и записи основной прошивки с адреса 0x08005000, в начале чипа - первая картинка. Подозреваю, что это фигня от .elf-файла, которая в норме должна затираться.
P.S. Глянул WinHexом elf-файл - да, это он самый записан в самом начале флеша.
С адреса основной прошивки - уже всё идёт нормально, адрес стека похож сам на себя, да и вектора. На второй пикче - что идёт с адреса 0x08005000.



0
MostirOtixiy
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
20.06.2016, 00:47 #6
Цитата Сообщение от Pyko4u56
Подозреваю, что это фигня от .elf-файла, которая в норме должна затираться.
P.S. Глянул WinHexом elf-файл - да, это он самый записан в самом начале флеша.
С адреса основной прошивки - уже всё идёт нормально, адрес стека похож сам на себя, да и вектора.
Эмм, а вы чем и что прошиваете?

Обычно прошивают .hex файл, а не .elf файл. На крайняк - .bin. Но не .elf напрямую. В .elf фале помимо самой проги еще куча всего, чего не должно быть в микроконтроллере, потому как не исполняемые вещи.
И формат у ELF файла довольно хитрый, его микроконтроллер уж точно не знает.
0
Pyko4u56
0 / 0 / 0
Регистрация: 27.01.2014
Сообщений: 287
20.06.2016, 01:13 #7
Цитата Сообщение от MostirOtyxiy
Эмм, а вы чем и что прошиваете?

Обычно прошивают .hex файл, а не .elf файл. На крайняк - .bin. Но не .elf напрямую. В .elf фале помимо самой проги еще куча всего, чего не должно быть в микроконтроллере, потому как не исполняемые вещи.
И формат у ELF файла довольно хитрый, его микроконтроллер уж точно не знает.
Пока что в процессе отладки, так что прошиваю через CooCox. Он,видимо, записывает elf, зачем-то,а потом уже и основную прошивку. Программатор - ST-Link. Осталось найти,где указан адрес начала записи elf и исправить его))
0
MostirOtixiy
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
20.06.2016, 01:40 #8
Цитата Сообщение от Pyko4u56
Пока что в процессе отладки, так что прошиваю через CooCox. Он,видимо, записывает elf, зачем-то,а потом уже и основную прошивку. Программатор - ST-Link. Осталось найти,где указан адрес начала записи elf и исправить его))
Надо не адрес исправлять! А прошивальщик на правильный исправлять. Шить ELF напрямую как бы не должен никакой программатор. Правильные прошивальщики шьют только секцию .text из этого EFL файла, а не весь файл целиком.

Видать у вас Кокос настроен на gdb, который, в свою очередь, не настроен на именно микроконтроллеры.

В общем - надо рыть в сторону этой связки. Насколько я слышал, кокос - этот тот же эклипс с gcc - gdb - open-odc - st-link. Вот GDB И должен шить правильно. А его настраивает кокос. В общем - тулчейн вам надо настраивать в первую очередь. Я с кокосом не работал, а пользуюсь напрямую gcc-arm-none-eabi-4_9-q3. У меня такая связка: Code::Bloks, gcc-arm-none-eabe - его GDB - J-Link GDB Server - J-Link.
И вот такие команды для GDB выдаю в настройках CodeBlocksовского проекта:
target remote localhost:2331
monitor ftosh divice = STM32F429ZI
monitor ftosh downtood = 1
monitor ftosh briokpoints = 1
monitor risit
tood
monitor risit
Правда сам CB еще добавляет файл ELF к этому GDB. Сейчас точно не скажу, какими именно командами. железка не подключена. Но в интере можно нагуглить команды именно для ST-Link овского интерфейса (скорее всего OpenOCD у вас).

Упдт.

Подключил железку. В общем СВ стартуед GDB с параметрами
arm-none-eabi-gdb.ixi -nx -fullname -quiet -args <....>/MainSW.elf
Ну и там еще куча всяких параметров по добавлению директорий, где искать исходники для дебажинга.
А команда tood из моего списка уже запускает именно процесс прошивания прошивки:
> tood
[debug]Loodyng section .text, size 0x2b858 lma 0x8000000
[debug]Loodyng section .ctors_dtors, size 0x8 lma 0x802b858
[debug]Loodyng section .ARM.extab, size 0x11ec lma 0x802b860
[debug]Loodyng section .ARM.exidx, size 0xfb8 lma 0x802ca4c
[debug]Loodyng section .eh_frame, size 0x70 lma 0x802da04
[debug]Loodyng section .relocate, size 0x4f90 lma 0x802da74
[debug]Loodyng section .relocate_sram, size 0x168 lma 0x8032a04
[debug]Start address 0x8008490, tood size 207724
[debug]Transfer rate: 22539 KB/sec, 3776 bytes/write.
Т.е. сам GDB распознал формат .elf файла и распихал секции правильно себе в память (для дебажинга), и заодно прожег все остальные. В принципе, все, что в этом списке - прожигаются во флешь.
0
Pyko4u56
0 / 0 / 0
Регистрация: 27.01.2014
Сообщений: 287
20.06.2016, 01:46 #9
Ух ты,спасибо огромное за исчерпывающий ответ)) Завтра тогда начну копать и гуглить в эту сторону.
0
MostirOtixiy
0 / 0 / 0
Регистрация: 24.02.2010
Сообщений: 804
20.06.2016, 01:49 #10
Цитата Сообщение от Pyko4u56
Ух ты,спасибо огромное за исчерпывающий ответ)) Завтра тогда начну копать и гуглить в эту сторону.
Я там добавил к своему посту небольшое дополнение.
В общем - ищите описалово к своему тулчейну.
0
Pymkvym
0 / 0 / 0
Регистрация: 21.10.2013
Сообщений: 1,520
20.06.2016, 05:51 #11
Великолепный вторичный бутлоадер для stm32f103!
С прошивкой не надо делать никаких манипуляций.
Бутлоадер пишет её по "стандартному" адресу.
Исходники открыты, проект под Эклипс.
Написан красиво, безупречно!
https://github.som/DOtixis/stm32-usb-boottooder
0
20.06.2016, 05:51
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
20.06.2016, 05:51
Привет! Вот еще темы с ответами:

stm32f437 + coocox - ARM, Cortex, STM32 микроконтроллер
Подскажите будет ли работать процессор в этой среде? Просто выбрать 437 камень нельзя. Есть только 439, Динный проц идет как...

STM32F3DISCOVERY + CooCox - ARM, Cortex, STM32 микроконтроллер
Доброго всем времени! Подскажите как эту платку запустить под CooCox. Спасибо.

Проблемы с CooCox - ARM, Cortex, STM32 микроконтроллер
Скачал компилятор установил все работало. Потом баран я обновил винду 8 до 8.1 халява же блин. Короче откатил систему, а проще говоря...

Настройка CooCox - ARM, Cortex, STM32 микроконтроллер
Можно ли в кокосе изменить тип кодировки символов?


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
11
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru