Поиск

Перешел с 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, но это не внесло ясности, что-то я упускаю.

Ковыряю работу виртуального порта в проце Nuvoton 487. Не понимаю как управлять сигналами квитирования со стороны процессора. Если в примерах в одном месте была одна корявая закомментированная строчка , позволяющая понять как принять от компьютера DTR RTS, то как передать не понятно. void VCOM_ClassRequest(void) { if (gUsbCmd.bmRequestType & 0x80) /* request data transfer direction */ { // Device to host switch (gUsbCmd.bRequest) { case GET_LINE_CODE: { if ((gUsbCmd.wIndex & 0xff) == 0){ /* VCOM-1 */ HSUSBD_PrepareCtrlIn((uint8_t *)&gLineCoding, 7); HSUSBD_CLR_CEP_INT_FLAG(HSUSBD_CEPINTSTS_INTKIF_Msk); HSUSBD_ENABLE_CEP_INT(HSUSBD_CEPINTEN_INTKIEN_Msk); break; } /* VCOM-1 */ } default: { /* Setup error, stall the device */ HSUSBD_SET_CEP_STATE(HSUSBD_CEPCTL_STALLEN_Msk); break; } } }//if (gUsbCmd.bmRequestType & 0x80) /* request data transfer direction */ else { // Host to device switch (gUsbCmd.bRequest) { case SET_CONTROL_LINE_STATE: { if ((gUsbCmd.wIndex & 0xff) == 0) /* VCOM-1 */ { gCtrlSignal = gUsbCmd.wValue; // !!!!!!!!!!!!!!!!!!!!! тут от компьютера //printf("RTS=%d DTR=%d\n", (gCtrlSignal0 >> 1) & 1, gCtrlSignal0 & 1); } // DATA IN for end of setup /* Status stage */ HSUSBD_CLR_CEP_INT_FLAG(HSUSBD_CEPINTSTS_STSDONEIF_Msk); HSUSBD_SET_CEP_STATE(HSUSBD_CEPCTL_NAKCLR); HSUSBD_ENABLE_CEP_INT(HSUSBD_CEPINTEN_STSDONEIEN_Msk); break; } case SET_LINE_CODE: { if ((gUsbCmd.wIndex & 0xff) == 0) /* VCOM-1 */ HSUSBD_CtrlOut((uint8_t *)&gLineCoding, 7); /* Status stage */ HSUSBD_CLR_CEP_INT_FLAG(HSUSBD_CEPINTSTS_STSDONEIF_Msk); HSUSBD_SET_CEP_STATE(HSUSBD_CEPCTL_NAKCLR); HSUSBD_ENABLE_CEP_INT(HSUSBD_CEPINTEN_STSDONEIEN_Msk); /* UART setting */ if ((gUsbCmd.wIndex & 0xff) == 0) /* VCOM-1 */ // тут меняются настройки порта VCOM_LineCoding(0); // параметры обмена беруться из gLineCoding break; } default: { /* Setup error, stall the device */ HSUSBD_SET_CEP_STATE(HSUSBD_CEPCTL_STALLEN_Msk); break; } } } }

Доброго времени суток! Пытаюсь запустить FreeRTOS на NUC980 на отладочной плате NuMaker-Server-NUC980 (https://www.nuvoton.com/products/iot-solution/iot-platform/numaker-server-nuc980/). В репозитории NUC980_NonOS_BSP есть пример проекта (https://github.com/OpenNuvoton/NUC980_NonOS_BSP/tree/master/SampleCode/FreeRTOS). Проект собранный в Keil запускается и работает без проблем. Стартует и в отладке и при записи на SPI NAND Flash. Проблемы возникли c запуском прошивки собранной с помощью GCC. Если загрузить образ используя NuWriter в ОЗУ, то он стартует и работает нормально, а вот если его записать во Flash, то он стартует и работает до первого отключения питания платы. Если после подачи питания на плату выполнить соединение с NuWriter, при этом ни чего не загружать в контроллер, а просто перевести его в режим загрузки с SPI NAND переключателем на плате и нажать кнопочку reset, то образ, ранее записанный во Flash начинает запускаться нормально (до следующего сброса питания). Так же образ GCC если перед этим запустить любым из доступных способов образ собранный в Keil. Т.е. отличия, скорее всего, заключаются в начальной инициализации. Стартапы Keil и GCC отличаются тем, что для GCC инициализация векторов прерываний и очистка секции bss выполняется в в самом стартапе, а для keil это делается процедурой __main. GCC startup.S: Keil startup.s: При отладке вижу следующее: Запускается Scheduler FreeRTOS и передает управление первой задаче vCheckTask. В этой задаче вызывается vTaskDelayUntil(). Отработав,vTaskDelayUntil() вызывает portYIELD_WITHIN_API() (task.c строка 1275), т.е. `asm volatile ("SWI 0\n"`. Но вместо прерывания по вектору SWI_Handler (vPortYieldProcessor) вызывается прерывание по вектору Undef_Handler. Подскажите, пожалуйста куда копать.