Поиск

В даташите есть такая схема: Но всё равно не очень понятно, как именно это должно работать. То есть нужно загрузиться из system memory (Boot0 = 1, Boot1 = 0) и прислать на любой USART байт 0x7F и по этому USART'у можно послать прошивку через CubeProg?

Перешел с Microchip на ARM32 в лице Nuvoton NUC472, в целом программа уже работает, но столкнулся с непониманием работы FMC, а именно логики работы загрузчика. Микроконтроллер предлагает две области памяти: LDROM для загрузчика и APROM для самого приложения, но в настройках есть варианты отзеркаливания части загрузчика в первом секторе основной программы и честно говоря я не совсем понимаю, как это работает и зачем это нужно. 00 LDROM with IAP function Chip booting from LDROM, program executing range including LDROM and most of APROM (all except first 2048 bytes as the first 2048 bytes is mapped from LDROM). LDROM address is mapping to 0x0010_0000 ~ 0x0010_3FFF, and also the first 2048 bytes of LDROM is mapping to the address 0x0000_0000 ~ 0x0000_07FF. The address 0x0000_0000 ~ 0x0000_07FF can be re-mapped to any other page within executing range through ISP command. Both APROM and LDROM are programmable in this mode no matter the code is currently running on LDROM or APROM. Data Flash is meaningless in this mode, because any area of APROM and LDROM can just be used as the Data Flash. DFBADR is not functioned in this mode. 01 LDROM without IAP function Chip booting from LDROM, program executing range only including LDROM; APROM cannot be access by program directly, except by through ISP. LDROM is write-protected in this mode. 10 APROM with IAP function Chip booting from APROM, program executing range including LDROM and APROM LDROM address is mapping to 0x0010_0000~0x0010_3FFF The address 0x0000_0000 ~ 0x0000_07FF can be re-mapped to any other page within executing range though ISP command. Both APROM and LDROM are programmable in this mode no matter the code is currently running on LDROM or APROM. Data Flash is meaningless in this mode, because any area of APROM and LDROM can just be used as the Data Flash. DFBADR is not functioned in this mode. 11 APROM without IAP function Chip booting from APROM and program executing range only including APROM. LDROM cannot be access by program directly, except by through ISP. APROM is write-protected in this mode. Собственно мне нужно, чтобы МК стартовал с загрузчика, проверял состояние ножки и если нет нужды - передавал управление основной программе. Насколько я понял, логика предполагает, что я должен в основной программе изменить биты (CBS[1:0]), отвечающие за старт и после перезагрузки запустится загрузчик, он выполнит обновление прошивки и изменит биты на запуск основной прошивки, но основная прошивка может оказаться неработоспособной и снова изменить биты на запуск загрузчика уже не сможет. Смотрел примеры, которые входят в комплект CMSIS, но это не внесло ясности, что-то я упускаю.

Продолжение моего прошлого вопроса. До этого хотел реализовать загрузчик с прошивкой в качестве hex-файла, теперь попытался с бинарным и возникла проблема. "Получать прошивку должен по UART. На данный момент загрузчик успешно выполняет передачу управления основной программе и стирает память по адресу, соответствующему программе, при получении прошивки." Отправляю bin-файл через TeraTerm, контроллер его вроде как получает, но пропускает цикл с записью прошивки, не могу понять почему. Проблема находится где-то в районе "strtoul". Пробовал конец строки, что в буфере, добивать нуль-терминирующим символом - безрезультатно. Прикладываю файл загрузчика, буду благодарен за любую помощь.main.c

Пишу загрузчик на stm32f103. Получать прошивку должен по UART. На данный момент загрузчик успешно выполняет передачу управления основной программе и стирает память по адресу, соответствующему программе, при получении прошивки. Застрял на моменте отправки hex-файла загрузчику - плохо понимаю как это реализовать. Со стороны компьютера должно быть приложение, позволяющее передать файл прошивки, на это выделено 10 секунд. Пробовал использовать Tera Term, но ничего не выходит. Не знаю, не позволяет приложение или криво написан код. Сам код с получением файла прошивки не мой, планирую сначала проверить его, а затем уже написать свой. Новичок в этом деле, так что прошу не судить строго. main.c

Привет, народ. Пытаюсь разобраться как прошивать плату STM32F103C8T6 (Blue Pill) по miniUSB-кабелю. Свои изыскания я записываю здесь: Как прошивать Blue Pill STM32 F103 через обычный USB-кабель в Linux Затык происходит на том, что я прошиваю DFU-бутлоадер в плату, плата становится видна по USB: [25760.232130] usb 2-2: new full-speed USB device number 7 using xhci_hcd [25760.385437] usb 2-2: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00 [25760.385444] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [25760.385447] usb 2-2: Product: Maple [25760.385449] usb 2-2: Manufacturer: LeafLabs [25760.424009] cdc_acm 2-2:1.0: ttyACM0: USB ACM device [25760.424307] usbcore: registered new interface driver cdc_acm [25760.424310] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters Однако утилита dfu-util (версии 0.9) ни одной платы не видит. И версия 0.8 тоже не видит: > dfu-util --list dfu-util 0.9 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2016 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Пробовал давать команду с указанием id-шников устройства: dfu-util -d 1eaf:0004 --list так тоже DFU-устройство не обнаруживается. Пробовал и под рутом, и от обычного пользователя, хотя DBUS правило для доступа пользователем прописывается при установке пакета dfu-util (Debian Linux 11). Что еще нужно донастроить, чтобы увидеть DFU-устройство?

Добрый день, Ситуация следующая. Есть бутлоадер, из которого стартует основное приложение. Если я загружаю и запускаю основное приложение по адресу 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, далее основная программа запускается всегда КОРРЕКТНО. Что может быть, или как отловить? Всю дополнительную информацию готов предоставить. Просьба кидать все идеи

Замаячила на горизонте задача менять прошивку в STM32H750 с помощью веб морды. При этом хотелось бы сохранить содержимое прошивки в тайне (RDP Level 1 или PCROP). С веб мордами проблем, вроде, нет. LWIP + HTTPD работают на ура. Зашифрованный файл (AES) заливается методом POST в SRAM и ждёт там своего часа на расшифровку и заливку. Аппаратный AES дешифратор в чипе есть. Но вот незадача. В STM32H750 всего 1 сектор флэша на все 128 Кб. Загрузчик некуда впихнуть А код сам себя не перезапишет. Буду рад любому пинку в правильном направлении.

Есть бутлоадер. Его линкер файл То есть начинается как положено с 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 приложением, данных, используемых кем-либо, нет. Это какая-то особенность контроллера памяти?

давайте обсудим логику работы системы и самого процесса исходя из того, что как обновлять прошивку в 100..500 девайсах вопросов не вызывает

Доброго времени суток! Вроде бы тривиальная задача, а вот однако застрял не могу понять, где ошибся. Проц - 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 совпадают (за вычетом служебных данных). Я не могу понять, что я упустил. Есть у кого соображения, поделитесь если не трудно?