[Sergey K 0]

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

 

[Darth Vader 0]

9 hours ago, Sergey K said:

но основная прошивка может оказаться неработоспособной и снова изменить биты на запуск загрузчика уже не сможет

Потому после POR всегда должен выполняться код загрузчика. Он проверяет некоторые условия и решает, что делать дальше:

1. Остаться и ждать прихода новой прошивки по какому-то внешнему интерфейсу (UART, CAN и т.п)

2. Перейти на выполнение основной программы - передать управление ей.

При таком построении шанс получить кирпич минимальный, потому, что:

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

б) при старте устройства он всегда гарантированно запускается вне зависимости от работоспособности основной программы

Тут можно посмотреть рассуждения на эту тему.

[jcxz 184]

15 минут назад, Darth Vader сказал:

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

Обновление загрузчика правильно реализованное само по себе никак не может привести к "кирпичу".

Только криво реализованное - может. Но и необновляемый загрузчик при кривых руках с таким же успехом даст "кирпич". Это не панацея.

[Sergey K 0]

On 4/18/2020 at 11:13 PM, Darth Vader said:

Потому после POR всегда должен выполняться код загрузчика. Он проверяет некоторые условия и решает, что делать дальше

Именно так и реализовано у меня на других МК. Не могу разобраться с битами конфигурации конкретно у Nuvoton (например, отзеркаливание первого сектора памяти загрузчика в нулевой сектор основной прошивки вводит меня в недопонимание логики работы этого камня), чтобы реализовать так-же и здесь.

 

On 4/18/2020 at 11:31 PM, jcxz said:

Обновление загрузчика правильно реализованное само по себе никак не может привести к "кирпичу".

Только криво реализованное - может. Но и необновляемый загрузчик при кривых руках с таким же успехом даст "кирпич". Это не панацея.

Например, отрубили питание в процессе (или комп повис), а загрузчик стартует только перенастройкой битов CBS[1:0] (как например предлагается в Nuvoton).

Изменено 20 апреля, 2020 пользователем Sergey K

[jcxz 184]

1 час назад, Sergey K сказал:

Например, отрубили питание в процессе (или комп повис), а загрузчик стартует только перенастройкой битов CBS[1:0] (как например предлагается в Nuvoton).

А почему у Вас эти биты не становятся в нужное состояние при вкл. питания?

Повисание компа (или ещё чего-то внешнего) вообще никак не должно влиять на работоспособность ПО.

[Sergey K 0]

2 hours ago, jcxz said:

А почему у Вас эти биты не становятся в нужное состояние при вкл. питания?

Я их могу изменить в процессе выполнения программы, могу выставить в битах конфигурации (а вот с этим у меня пока большая загвоздка - в keil я вообще никак их ни просмотреть, ни изменить не могу и пока никак не могу найти, как биты конфигурации можно задать в коде. Пока только с помощью отдельной программы для программирования МК).

Вопрос в другом, что выставить и как это работает на этом камне. Зачем отзеркаливать первый сектор LDROM в первый сектор APROM? 

[butthead2 0]

Вопрос повис открытым. Закроем его для будущих поколений. "Отзеркаливание сектора" есть не то иное как ремап таблицы векторов прерываний. SBC->VTOR в терминологии STM32. В битах конфигурации это разерешается (with IAP) или запрещается (without IAP). Первый сектор отзеркаливается по умолчанию, адрес можно изменить.