| |
 RL-ARM и bootloader, Запуск основной программы после перепрошивки |
|
|
|
|
 May 24 2012, 07:50
|
Частый гость
Группа: Свой
Сообщений: 182
Регистрация: 30-01-05
Из: Volgograd
Пользователь №: 2 305
|
Ну как-же не признался.  Вот оно все. Было. Цитата(EXeGLuMATOR @ May 21 2012, 17:00)  Отвлекся на другие дела...
Не совсем может понятно написал. В лоадере RL-ARM не используется. Там все просто. Камушек LPC1343. Используется встроенный HID - драйвер. По HID происходит обносвление основной прошивки. Потом соотв переход на неё. Из встроенной периферии используется помимо USB еще UART - для вывода сообщений. Ну GPIO еще. И собственно все.
Так вот, если заливать и стартовать основной код с адреса 0 - то он сам себя прекрасно перезапускает. Тестовый код тоже простой - ничего не инитится, только ЮАРТ - вывод строчки на терминал и далее - перезагрузка.
Следующий этап - через лоадер. Заливаем софтинку лоадером. Если простая тестовая софтинка - та-же что и впредыдущем этапе - все нормально. Все обновляется, запускается и выполняется переход на основной код. Там тоже все нормально.
Но как только появляется RL-ARM в пользовательском софте - все. Никаких движений после перехода на пользовательский софт. Стартапы одинаковые - тестовый проект сделан на базе основного, только урезан по максимуму. Вот - как-то так. Аналогичные грабли были и на LPC2368. Но там разобрался. Цитата На LPC2368 - нужно было стартап править и таблицу SWI.
Здесь не пойму, что не так.
Может кто-нибудь startup_LPC13xx.s и SVC_Table.s от рабочих проектов с RL-ARM в качестве загружаемой софтины выложить? Перерыл кучу форумов в том числе и и на Кейле - народ мается теми-же проблемами, но решения что-то не нашел.
|
|
|
|
|
|
|
|
May 24 2012, 08:05
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
QUOTE (EXeGLuMATOR @ May 24 2012, 10:50) Ну как-же не признался. Вот оно все. Было. Виноват. Пропустил. Могу посоветовать такой алгоритм: 1) запрещаете прерывания. 2) записываете в SCB->VTOR значение PAYLOAD_START_ADDR. 3) Записывате в MSP значение, взятое по адресу PAYLOAD_START_ADDR. (используйте функцию CMSIS __set_MSP()) 4) Делаете переход таким образом: CODE void (*user_code_entry)(void);
user_code_entry = *((void (**)(void))(PAYLOAD_START_ADDR+4));
user_code_entry(); Обратите внимание, что вы переходите не на адрес PAYLOAD_START_ADDR+4, а на адрес, который записан в ячейке с адресом PAYLOAD_START_ADDR+4. Ваши же примеры являют какую-то смесь из кода запуска для ARM (переход на первый адрес приложения, по которому располагается вектор исключения, представляющий из себя команду перехода) и кода для Cortex у которого вектор сброса расположен со смещением 4 байта (или sizeof(int)), но он представляет из себя не команду, а указатель. Поэтому очень сомнительно, что ваш предыдущий код хоть как-то работал. Добавлено: похоже, не все кортексы-M3 одинаково одинаковые. Открыл мануал на 13xx, в нем нет упоминания про VTOR (хотя это часть ядра M3), зато есть упоминание про REMAP. Поищу еще, но, похоже, вам придется делать копирование векторов в ОЗУ и Remap.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
|
|
|
May 24 2012, 08:30
|
Частый гость
Группа: Свой
Сообщений: 182
Регистрация: 30-01-05
Из: Volgograd
Пользователь №: 2 305
|
Цитата(Сергей Борщ @ May 24 2012, 12:05) Виноват. Пропустил. Могу посоветовать такой алгоритм: 1) запрещаете прерывания. 2) записываете в SCB->VTOR значение PAYLOAD_START_ADDR. 3) Записывате в MSP значение, взятое по адресу PAYLOAD_START_ADDR. (используйте функцию CMSIS __set_MSP()) 4) Делаете переход таким образом: Код void (*user_code_entry)(void);
user_code_entry = *((void (**)(void))(PAYLOAD_START_ADDR+4));
user_code_entry(); Обратите внимание, что вы переходите не на адрес PAYLOAD_START_ADDR+4, а на адрес, который записан в ячейке с адресом PAYLOAD_START_ADDR+4. Ваши же примеры являют какую-то смесь из кода запуска для ARM (переход на первый адрес приложения, по которому располагается вектор исключения, представляющий из себя команду перехода) и кода для Cortex у которого вектор сброса расположен со смещением 4 байта (или sizeof(int)), но он представляет из себя не команду, а указатель. Поэтому очень сомнительно, что ваш предыдущий код хоть как-то работал. Добавлено: похоже, не все кортексы-M3 одинаково одинаковые. Открыл мануал на 13xx, в нем нет упоминания про VTOR (хотя это часть ядра M3), зато есть упоминание про REMAP. Поищу еще, но, похоже, вам придется делать копирование векторов в ОЗУ и Remap. Спасибо. Проверю. Еще вопросик - какие особенности при компиляции основной программы? С учетом RL-ARM? Ну, помимо адреса старта.
|
|
|
|
|
|
|
|
May 24 2012, 08:50
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
QUOTE (Сергей Борщ @ May 24 2012, 11:05) похоже, не все кортексы-M3 одинаково одинаковые. ДА, сочувствую. Им удалось совместить ядро M3 и механизм ремапа из LPC2xxx. Придется вам жертвовать кусочком ОЗУ и делать по-старинке. В скрипте линкера надо будет откусить от начала ОЗУ кусочек для векторов. При ремапе на нулевые адреса отражается 512 байт ОЗУ (см. рис. 2 в руководстве пользователя). Из них реально под вектора используются: 4 байта на начальный адрес стека, 4 * 15 байт на вектора исключений ядра и 4 * 57 байт для векторов прерываний периферии. Итого 292 байта. Именно столько надо будет зарезервировать. А стартовать можно примерно так: CODE #define APPLICATION_IMAGE_START 0x00002000
#define VECTORS_REMAP_AREA 0x10000000 // start of SRAM
typedef struct
{
typedef void( *handler )( void );
uint32_t MSP_init;
handler Reset_vector;
handler Core_handler[14];
handler MCU_handler[57];
} vectors_t;
vectors_t const * const pApp_vectors = (vectors_t const * const)APPLICATION_IMAGE_START;
vectors_t * const pRemap_area = (vectors_t * const)VECTORS_REMAP_AREA;
// copy application vectors table to remap area
// memcpy(pRemap_area, pApp_vectors, sizeof(vectors_t));
uint32_t const * pSrc = (uint32_t const *)pApp_vectors;
uint32_t * pDst = (uint32_t *)pRemap_area;
do
{
*pDst++ = *pSrc++;
}
while(pSrc < (uint32_t const *)(pApp_vectors + 1));
// Init application main stack pointer
__set_MSP(pApp_vectors->MSP_init);
// remap to ram
LPC_SYSCON->SYSMEMREMAP = 1;
// start application
pApplication->Reset_vector(); Да, и еще такая тонкость: этот код (хотя бы начиная с LPC_SYSCON->SYSMEMREMAP = 1) должен располагаться с адреса больше 512. В противном случае его "накроет" после ремапа содержимым ОЗУ.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
|
|
|
May 24 2012, 11:30
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
QUOTE (EXeGLuMATOR @ May 24 2012, 13:20) Т.е. получается, что #define VECTORS_REMAP_AREA 0x10000000 // start of SRAM будет выглядеть как #define VECTORS_REMAP_AREA 0x10000180 Нет, вы не поняли - первые 512 байт ОЗУ отображаются на адреса начиная с 0. Поэтому обращаясь к векторам по адресу 0, 4, 8... проц фактически обращается в ОЗУ по адресам 0x10000000, 0x10000004, 0x10000008 .... И изменить это невозможно. VECTORS_REMAP_AREA должна начинаться с 0x10000000, ни байтом больше, ни байтом меньше. Боюсь вас разочаровывать, но, похоже вам придется либо отказаться от набортного USB-драйвера, либо от обновлений, либо от еще 292-8 = 284 байтов в области загрузчика, прерываний загрузчика и делать так называемые "трамплины". Или искать, куда потерялся VTOR. QUOTE (Сергей Борщ @ May 24 2012, 13:48) Или искать, куда потерялся VTOR. "Легенда меняется. Вы- нищий" (с)"Чокнутые". Оказывается у меня старательно хранился мануал версии 0.1 от 2009года. В свежем версии 4 от 2011 года VTOR есть. Сейчас пообедаю и напишу, как сделать через него. Как вариант: CODE #define APPLICATION_IMAGE_START 0x00002000
typedef struct
{
typedef void( *handler )( void );
uint32_t MSP_init;
handler Reset_vector;
handler Core_handler[14];
handler MCU_handler[57];
} vectors_t;
vectors_t const * const pApp_vectors = (vectors_t const * const)APPLICATION_IMAGE_START;
// activate application's vectors table
SCB->VTOR = (uintptr_t)pApp_Vectors;
// Init application main stack pointer
__set_MSP(pApp_vectors->MSP_init);
// start application
pApplication->Reset_vector();
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
|
|
|
May 25 2012, 08:46
|
Частый гость
Группа: Свой
Сообщений: 182
Регистрация: 30-01-05
Из: Volgograd
Пользователь №: 2 305
|
Урррааа! Заработало. Большое спасибо! Думаю пусть код здесь будет - мало-ли кому пригодится. Код typedef void( *handler )( void );
typedef struct
{
uint32_t MSP_init;
handler Reset_vector;
handler Core_handler[14];
handler MCU_handler[57];
} vectors_t;
void execute_user_code(void)
{
vectors_t const * const pApp_vectors = (vectors_t const * const)PAYLOAD_START_ADDR;
// activate application's vectors table
SCB->VTOR = (uintptr_t)pApp_vectors;
// Init application main stack pointer
__set_MSP(pApp_vectors->MSP_init);
// start application
pApp_vectors->Reset_vector();
}; Это все полностью работает. RL-ARM стартует, инитится и вроде даже нормально шевелится. Еще полностью все проверю. Да, не все...  Поторопился - не работает его встроенное USB. Видимо таки наложение где-то происходит. З.Ы. Ан нет. все работает. Эт я глюкнул - в ходе экспериментов закомментил обработчик ЮСБ. Но все равно - после обновления прошивки и перехода на основной код ЮСБ таки не работает. А вот если отресетить камень, то после отработки загрузчика ЮСБ работает нормально - у меня в коде загрузчика если не требуется обновления ЮСБ и не инитится. А вот если инитится в лоадере - то что-то не хочет с ходу работать. Видимо тоже есть особенности, пока не ясные.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
