Поиск
Показаны результаты для тегов 'загрузчик'.
-
В даташите есть такая схема: Но всё равно не очень понятно, как именно это должно работать. То есть нужно загрузиться из system memory (Boot0 = 1, Boot1 = 0) и прислать на любой USART байт 0x7F и по этому USART'у можно послать прошивку через CubeProg?
- 7 ответов
-
- stm32
- bootloader
-
(и ещё 2 )
C тегом:
-
Доброго дня, коллеги. Возникла острая необходимость обновить софт в >1000 изделий на STM32F0. Устройства уже смонтированы на объекте, демонтировать их нельзя, доступ для перепрошивки весьма затруднен - работа на высоте со страховкой, на холоде 😞 Использование загрузчика конструкцией не предусмотрено, перепрошить можно только через 4-пиновый разъем SWD (GND, nRST, SWDIO, SWCLK) при помощи ST-LINK. Проблема в том, что для ST-LINK нужен хост с утилитой, это , насколько я себе представляю на сегодня, - как минимум нетбук, - громоздко и тяжело, заряда батарей надолго не хватит, тем более на морозе:( Надо коробочку со светодиодом и кнопкой, с батарейным питанием. Из похожего/подходящего нашел только это - стоит как чугунный мост, сроки доставки зашкаливают, а таких штук надо бы несколько и побыстрее... Прошу помощи.
-
Продолжение моего прошлого вопроса. До этого хотел реализовать загрузчик с прошивкой в качестве hex-файла, теперь попытался с бинарным и возникла проблема. "Получать прошивку должен по UART. На данный момент загрузчик успешно выполняет передачу управления основной программе и стирает память по адресу, соответствующему программе, при получении прошивки." Отправляю bin-файл через TeraTerm, контроллер его вроде как получает, но пропускает цикл с записью прошивки, не могу понять почему. Проблема находится где-то в районе "strtoul". Пробовал конец строки, что в буфере, добивать нуль-терминирующим символом - безрезультатно. Прикладываю файл загрузчика, буду благодарен за любую помощь.main.c
-
Пишу загрузчик на stm32f103. Получать прошивку должен по UART. На данный момент загрузчик успешно выполняет передачу управления основной программе и стирает память по адресу, соответствующему программе, при получении прошивки. Застрял на моменте отправки hex-файла загрузчику - плохо понимаю как это реализовать. Со стороны компьютера должно быть приложение, позволяющее передать файл прошивки, на это выделено 10 секунд. Пробовал использовать Tera Term, но ничего не выходит. Не знаю, не позволяет приложение или криво написан код. Сам код с получением файла прошивки не мой, планирую сначала проверить его, а затем уже написать свой. Новичок в этом деле, так что прошу не судить строго. main.c
- 20 ответов
-
- stm32
- bootloader
-
(и ещё 2 )
C тегом:
-
Проблема со стартом приложения из загрузчика
simark1979 опубликовал тема в ARM
Добрый день, Ситуация следующая. Есть бутлоадер, из которого стартует основное приложение. Если я загружаю и запускаю основное приложение по адресу 0x08020000 непосредственно из IAR. всё работает чётко, но если программу запускает загрузчик, один из потоков затыкается (возможно и не один) Отладки при старте через загрузчик нет, поэтому приходится только гадать. Часть бутлоадера: #define MAIN_PROGRAM_START_ADDRESS (uint32_t)0x08020000 void jumpToApplication(); // Переход в основную программу typedef void (*pFunction)(void); uint32_t jumpAddress; pFunction Jump_To_Application; ......................... ......................... void jumpToApplication() { HAL_DeInit(); __disable_irq (); //Пробовал комментировать, без толку jumpAddress = *(__IO uint32_t*) (MAIN_PROGRAM_START_ADDRESS + 4); Jump_To_Application = (pFunction) jumpAddress; SCB->VTOR = MAIN_PROGRAM_START_ADDRESS; __set_MSP(*(__IO uint32_t*) MAIN_PROGRAM_START_ADDRESS); Jump_To_Application(); } Приведу комментарий из основной программы, т.е. это то, что там сделано. // ВНИМАНИЕ: НЕСТАНДАРТНОЕ РАЗМЕЩЕНИЕ ПРОГРАММЫ ВО FLASH: 0x08020000 (стандартное 0x08000000) // Так как используем загрузчик, эту программу нужно разместить там, куда прыгает загрузчик (см. в загрузчике MAIN_PROGRAM_START_ADDRESS) // в нашем случае (0x08020000), поэтому нужно поправить: // 1. Указать абсолютный адрес программы во flash в настройках линкера. // тут: VECTOR TABLE/.intvec start // тут: Memory Regiong/ROM Start // 2. В system_stm32f2xx.c в VECT_TAB_OFFSET указать сдвиг относительно стандартного размещения программы. // В нашем случае VECT_TAB_OFFSET = 0x20000 (т.е. 0x08020000 - 0x08000000) Самое интересное, что иногда приложение стартует штатно. примерно 1 раз из 5, всегда по разному. Дополнение. Если я запускаю бутлоадер из IAR, далее основная программа запускается всегда КОРРЕКТНО. Что может быть, или как отловить? Всю дополнительную информацию готов предоставить. Просьба кидать все идеи -
Есть бутлоадер. Его линкер файл То есть начинается как положено с 0 адреса. Я его прожигаю с J-Link. В главном проекте я устанавливаю define symbol __ICFEDIT_region_ROM_start__ = 0x00000В00; //следующий за AFF define symbol __ICFEDIT_region_ROM_end__ = 0x07FFFFFF; и генерирую бинарный файл srec. Я запускаю утилиту буллодера нажимаю Connect и она мне пишет Несмотря на WARNING! S19 image will not fit into available memory (at address 0x00000000)! бинарный файл прожигается но ничего не работает. В коде бутлодера есть такое JumpToUserApplication(*((unsigned long*)RELOCATED_VECTORS), *((unsigned long*)(RELOCATED_VECTORS+4))); RELOCATED_VECTORS почему то 0x4000. Получается главный прект я должен начать с 0x4000? Я пробовал но получаю тот же WARNING! S19 image will not fit into available memory (at address 0x00000000)! и ничего не работает после рисета.
-
Добрый день! Задаю вопрос по просьбе своего коллеги. Они изготовил бутлоадер, который принимает приложение по каналу связи, и записывает его во внутреннюю флеш микроконтроллера. Само приложение 100% работает. Но вот нюанс. И приложение, и бутлоадер инициализируют внешнюю SDRAM, которую каждый использует для себя. И вот на старте инициализации SDRAM приложением проц то-ли улетает куда-то, то-ли зависает. Вопрос: почему такое может происходить. Ведь при повторной инициализации EMC приложением, данных, используемых кем-либо, нет. Это какая-то особенность контроллера памяти?
- 28 ответов
-
давайте обсудим логику работы системы и самого процесса исходя из того, что как обновлять прошивку в 100..500 девайсах вопросов не вызывает
-
Самописный бутлоадер stm32f429
yanvasilij опубликовал тема в STM
Доброго времени суток! Вроде бы тривиальная задача, а вот однако застрял не могу понять, где ошибся. Проц - stm32f429. Суть такая "верхнее" приложение парсит hex-файл, выбрасывая из него все служебные данные, и данные не относящиеся к flash. Далее полученное подобие bin отправляется байт за байтом по последовательному порту в микроконтроллер. Микроконтроллер принимает, зашивает и переключается. Так вот после переключения ничего не происходит, проц зависает непонятно где. Прошивку принятой программы я делаю так: #define AVALIABLE_SECTORS_NUM 17 /**< @brief Общее количество доступных мне секторов */ #define USER_APP_START_ADR 0x08020000 /**< @brief Адрес куда шить программу */ /** Сектора, которые мне доступны */ static const u16 sectors [AVALIABLE_SECTORS_NUM] = { FLASH_Sector_5, FLASH_Sector_6, FLASH_Sector_7, FLASH_Sector_8, FLASH_Sector_9, FLASH_Sector_10, FLASH_Sector_11, FLASH_Sector_12, FLASH_Sector_13, FLASH_Sector_14, FLASH_Sector_15, FLASH_Sector_16, FLASH_Sector_17, FLASH_Sector_18, FLASH_Sector_19, FLASH_Sector_20, FLASH_Sector_21 }; /** Тут лежит принятая прошивка (массив в SDRAM) */ static u8 __attribute__((section ("._sdram"))) userApp[MAX_BIN_FILE_LEN]; /** Это счетчик принятых байт */ static u32 byteCount = 0; void programmUserApp (void) { u32 numOfPages = byteCount / PAGE_LEN; if (byteCount % PAGE_LEN) numOfPages++; FLASH_Unlock(); FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR | FLASH_FLAG_PGAERR | FLASH_FLAG_PGPERR|FLASH_FLAG_PGSERR); /** Стираю необходимые мне сектора */ for (u32 i = 0; i < numOfPages; i++) { if (FLASH_EraseSector(sectors[i], VoltageRange_3) != FLASH_COMPLETE) { FLASH_Lock(); while (1); /* Стопор на всякий случай */ } } /** Далее шью по 4 байта */ u32 * word = (u32*)userApp; u32 wordCount = byteCount/4; if (byteCount%4) wordCount++; u32 adr = USER_APP_START_ADR; for (u32 i = 0; i < wordCount; i++) { if (FLASH_ProgramWord(adr, *(word++)) != FLASH_COMPLETE) { FLASH_Lock(); while (1); /* Стопор на всякий случай */ } adr += 4; } FLASH_Lock(); } Далее, чтобы удостовериться, что я зашил, то что хотел, я считываю и вывожу в последовательный порт данные, которые оказались во flash в результате моих манипуляций: void showProgram (void) { u8 * p = (u8*) USER_APP_START_ADR; printf ("\r\n"); for (u32 i = 0, j = 0; i < byteCount; i++, j++) { if ( (j>0) && ((j%16) == 0) ) printf ("\r\n"); printf ("%02X", p[i]); } printf ("\r\n"); printf ("End\r\n"); } Переключаю программу вот так: typedef void(*VoidFunction)(void); void jumpToUserApp (void) { NVIC_SetVectorTable(NVIC_VectTab_FLASH, (USER_APP_START_ADR & (~(0x08000000)))); u32 jumpAddress = *(__IO uint32_t*) (USER_APP_START_ADR + 4); VoidFunction jumpToApp = (VoidFunction) jumpAddress; __set_MSP(*(__IO uint32_t*) USER_APP_START_ADR); jumpToApp(); } Так вот, после считыания я вижу, что зашилось именно то, что лежит в hex-файле в полях данных. То есть данные в hex и во flash совпадают (за вычетом служебных данных). Я не могу понять, что я упустил. Есть у кого соображения, поделитесь если не трудно?