Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: IAR ARM 6.3 загрузка в RAM заливает неверный код
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
megajohn
MCU:
LPC1778
ROM=0x0000 0000....
RAM=0x1000 0000...

Делаю загрузчик, и столкнулся что ассемблерный код в памяти не соответствует сишнику, и не соответствует коду, что для флеши.
Меняю только адрес для ROM и регистр VTOR

Debugger->run_to = выключено ( то есть после загрузки сразу встаем на вектор сброса )
и уже на этапе загрузки битые значения

поставил бряк стоит на изменение где лежит эти инструкции mem_set - нечего не выявил

что может портиться при загрузке программы в RAM через JTAG ? Кто сталкивался ?

Add: если гружу в RAM в симуляторе - то всё нормально. А через jLink беда

Add2:
включил Verify Download + Supress Download и куча ошибок
Thu Feb 05, 2015 19:22:58: Warning:
Verify error at address 0x10000001, target byte: 0xBE, byte in file: 0xA1
Thu Feb 05, 2015 19:22:58: Warning:
Verify error at address 0x10000002, target byte: 0xFE, byte in file: 0x00
Thu Feb 05, 2015 19:22:58: Warning:
Verify error at address 0x10000003, target byte: 0xE7, byte in file: 0x10
Thu Feb 05, 2015 19:22:58: Warning:
Verify error at address 0x10000004, target byte: 0x81, byte in file: 0xDD
Thu Feb 05, 2015 19:22:58: Warning:

если только Verify Download то ошибок нет и вектора нормально, а моя функция битая =(
jcxz
Возможно у Вас какие-то косяки в командном файле линкёра (.icf) - может какие-то секции накладываются друг на друга.
Попробуйте заменить базовый адрес 0x10000000 на другую часть ОЗУ.
По-крайней мере у меня в одном проекте (LPC1768) сборка проекта для отладки делается полностью в ОЗУ. И никаких проблем. Тоже JLink.
Вот описание регионов RAM из этого проекта:
Код
define region RAM_regionA     = mem:[from 0x10000000 size 0x8000]; //main RAM
define region RAM_regionBB    = mem:[from 0x2007C000 size 0x3000];
define region RAM_regionB     = mem:[from 0x2007F000 size 0x5000]; //AHB RAM

RO-секции линкуются в RAM_regionA и RAM_regionBB, RW-секции - в RAM_regionB. Flash не используется.

ЗЫ: Как это Вы ReadOnlyMemory умудряетесь JTAG-ом шить? wink.gif
megajohn
Цитата(jcxz @ Feb 5 2015, 19:58) *
Возможно у Вас какие-то косяки в командном файле линкёра (.icf) - может какие-то секции накладываются друг на друга.

да уже не раз всё перепроверил. Вот чуть чего файл Нажмите для просмотра прикрепленного файла

Цитата(jcxz @ Feb 5 2015, 19:58) *
ЗЫ: Как это Вы ReadOnlyMemory умудряетесь JTAG-ом шить? wink.gif

а как Segger->FlashCommander и IAR со снятой галкой FlashLoader заливают ? ( то что в IAR C-spy заливает в RAM свой прошивальщик знаю, но это когда стоит опция )
Сергей Борщ
Возможно глупость скажу, но у ИАРа Flash Loader - программа, которую отладчик грузит в ОЗУ, запускает и именно она заливает прошивку во флеш. Если вы грузите в ОЗУ, то Flash Loader грузить не надо. Возможно именно он и не дает залить поверх себя вашу программу.
jcxz
Цитата(megajohn @ Feb 5 2015, 23:07) *
да уже не раз всё перепроверил. Вот чуть чего файл Нажмите для просмотра прикрепленного файла

Может у Вас секция с векторами прерываний на начало ROM_region накладывается (слишком большая)? Смотрите .map-файл.
Определите для векторов также отдельный регион, чтобы линкёр контролировал его размер, либо сделайте ROM_region от 0x10000000 и расположите в его начале секцию векторов: place in ROM_region {ro, first section .intvec, ...}.
В целом вроде всё нормально.
Цепляю Вам сюда свой ram.icf для LPC1768 - всё отлично работает. Для LPC1778 увеличить только соотв. регионы да убрать ненужные секции.
Нажмите для просмотра прикрепленного файла
Цитата(megajohn @ Feb 5 2015, 23:07) *
а как Segger->FlashCommander и IAR со снятой галкой FlashLoader заливают ? ( то что в IAR C-spy заливает в RAM свой прошивальщик знаю, но это когда стоит опция )

ROM != flash

Цитата(Сергей Борщ @ Feb 5 2015, 23:56) *
Возможно глупость скажу, но у ИАРа Flash Loader - программа, которую отладчик грузит в ОЗУ, запускает и именно она заливает прошивку во флеш. Если вы грузите в ОЗУ, то Flash Loader грузить не надо.

"Use flash loader" в настройках Debugger не нужно включать ни при загрузке в RAM ни при прошивке во Flash. У меня и без неё прекрасно шьёт. На той вкладке только "Verify download" нужно вкл.

ЗЫ: А вообще совет - заменить IAR на хотя-бы 6.50. В 6.30 были глюки - неверно код компилил. Я приводил сюда примеры в своё время.
megajohn
АААА ! Нашел !

RAM used by Boot process prior to entering user program Following chip reset, the Boot program uses a subset of the RAM that is used for ISP command handling.
This includes location 0x1000 0120 and also parts of the top 32 bytes of on-chip RAM.
The stack is located at RAM top - 32. The maximum stack usage is 32 bytes.
If the user program assumes that RAM is unchanged during a reset where power is not removed from the device, it is important to be aware of these exceptions.


а в LPC1768 же

RAM used by ISP command handler ISP commands use on-chip RAM from 0x1000 0118 to 0x1000 01FF .
The user could use this area, but the contents may be lost upon reset. Flash programming commands use the top 32 bytes of on-chip RAM.
The stack is located at RAM top - 32. The maximum stack usage is 256 bytes and it grows downwards.
A. Fig Lee
Цитата(jcxz @ Feb 5 2015, 22:39) *
"Use flash loader" в настройках Debugger не нужно включать ни при загрузке в RAM ни при прошивке во Flash. У меня и без неё прекрасно шьёт. На той вкладке только "Verify download" нужно вкл.


А у меня нет, шьет плохо, с ошибками без этой галочки.
jcxz
Цитата(megajohn @ Feb 6 2015, 14:38) *
АААА ! Нашел !

Мимо кассы.
И причём здесь это? Вы же грузите через JTAG. А это - для встроенного бутлоадера, загружающего через ISP и для IAP (работающего флеш).
Ни то ни другое у Вас не должно использоваться.
К тому-же - я же привёл свой .icf - там у меня в этой области как раз находятся ro-секции. И никаких проблем и затираний.

Даже для IAP приведённое Вами имхо - неактуально. Я как-то проверял, вызывая функции IAP из под отладчика - никакой из 4-х краёв регионов ОЗУ (чтобы не понималось под "top") не портится.
Кроме собственно стека, на котором происходит вызов. Так что думаю - этот кусок мануала уже неактуален, а остался от какой-то старой версии прошивки ROM.

Цитата(A. Fig Lee @ Feb 6 2015, 18:07) *
А у меня нет, шьет плохо, с ошибками без этой галочки.

Озвучьте МК.
У меня несколько текущих проектов на LPC1758/LPC1768/LPC1778 - везде шьётся и грузится без галки.
Вероятно - у Вас в чём-то другом проблема.
megajohn
Цитата(jcxz @ Feb 6 2015, 16:47) *
Мимо кассы.
...
а остался от какой-то старой версии прошивки ROM.


вырезал из проекта ВСЁ, и заполняю память тестовым паттерном
Нажмите для просмотра прикрепленного файла

вот и проект для проверки
Нажмите для просмотра прикрепленного файла
Golikov A.
кортекс м3 в каком то месте записывает контрольную сумму. Где то в районе начальных адресов в таблице прерываний, вроде место похоже. Эту контрольную сумму вычисляет сам зашивальщик и всегда ее в это место льет. А то кортекс отвергнет прошивку. кажется это она...
megajohn
Цитата(Golikov A. @ Feb 6 2015, 19:55) *
кортекс м3 в каком то месте записывает контрольную сумму. Где то в районе начальных адресов в таблице прерываний, вроде место похоже. Эту контрольную сумму вычисляет сам зашивальщик и всегда ее в это место льет. А то кортекс отвергнет прошивку. кажется это она...


есть такое, но адрес не тот да и вычисляется компилятором

Criterion for Valid User Code
The reserved Cortex-M3 exception vector location 7 (offset 0x001C in the vector table)
should contain the 2’s complement of the check-sum of table entries 0 through 6. This
causes the checksum of the first 8 table entries to be 0. The boot loader code checksums
the first 8 locations in sector 0 of the flash. If the result is 0, then execution control is
transferred to the user code.

повторюсь, в моем случае в симуляторе всё ок, в реале через JLINK - битые данные по адресу 0x1000 0120.
jcxz
Цитата(Golikov A. @ Feb 6 2015, 22:55) *
кортекс м3 в каком то месте записывает контрольную сумму. Где то в районе начальных адресов в таблице прерываний, вроде место похоже. Эту контрольную сумму вычисляет сам зашивальщик и всегда ее в это место льет. А то кортекс отвергнет прошивку. кажется это она...

Это относится к процессу загрузки из флешь. Так ROM-бутлоадер определяет валидность прошивки во флешь.
Для случая работы из ОЗУ это не имеет смысла (и не делается конечно) так как по определению при старте бутлоадера (вкл. питания) в ОЗУ не может быть прошивки.
megajohn
Цитата(jcxz @ Feb 6 2015, 16:47) *
У меня несколько текущих проектов на LPC1758/LPC1768/LPC1778...


могу ли Вас попросить проверить приложенный mcu_ldr_tst.rar ?

А то хочется разобраться до конца, но у себя уже всё что мог посмотрел ( даже логи работы Jlink )

Либо у кого есть LPC1778/1788 + минутка свободного времени ?
jcxz
Цитата(megajohn @ Feb 9 2015, 15:44) *
могу ли Вас попросить проверить приложенный mcu_ldr_tst.rar ?

А что хотите узнать?
Запустил у себя на LPC1778 Ваш проект. Всё ок - до функции main дошёл нормально.
Вот содержимое ОЗУ на точке входа в main():
Нажмите для просмотра прикрепленного файла
megajohn
Цитата(jcxz @ Feb 9 2015, 13:24) *
А что хотите узнать?
Запустил у себя на LPC1778 Ваш проект. Всё ок - до функции main дошёл нормально.


дык вы загрузились через JTAG, boot loader не используется, тогда почему по 0x10000120 не то что должно быть ?
Как бы вы и опровергаете все свои ранее озвученные аргументы
jcxz
Какие именно аргументы я опроверг????
Я вообще-то говорил, что я отлаживаю у себя в проекте на LPC1768 в ОЗУ и всё работает ок.
Про Ваш проект я ничего не говорил, ибо не знал как у Вас сделано.

ЗЫ: А как Вам нравится такая картинка?
Нажмите для просмотра прикрепленного файла
А я всего лишь сделал одно мааааааленькое изменение в Вашем проекте.... Только и всего sm.gif
Угадаете где? wink.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.