Прописал почти как Вы посоветовали. Только поместил код:
eml.extrinsic('open_system'); eml.extrinsic('close_system'); eml.extrinsic('get_param'); eml.extrinsic('assignin'); eml.extrinsic('evalin');
mdl = bdroot;
open_system(mdl);
ws = get_param(mdl, 'ModelWorkspace');
g_ts = evalin(ws, 'g_ts');
g_pwmF = evalin(ws, 'g_pwmF');
в InitFcn для каждого m-блока и добавил все эти параметры в "The Ports and Data Manager" для каждого m-блока. Так работает даже быстрее чем мой метод
Отключить даже если во флешь неправильная/отсутствующая прошивка? Не знаю. Думаю зависит от конкретного МК. Просто непонятно - что тогда процессору делать, если BootROM выключен и прошивки во флешь нет?
Я уже решил эту проблему. Сделал так:
В каждой m-функции прописал в её начале секцию чтения глобальных констант (g_ts, g_pwmF, ...) из ModelWorkspace:
eml.extrinsic('open_system'); eml.extrinsic('close_system'); eml.extrinsic('get_param'); eml.extrinsic('assignin'); eml.extrinsic('evalin');
persistent g_ts; persistent g_pwmF;
persistent ix;
if isempty(ix)
ix = 0;
mdl = bdroot;
open_system(mdl);
ws = get_param(mdl, 'ModelWorkspace');
g_ts = evalin(ws, 'g_ts');
g_pwmF = evalin(ws, 'g_pwmF');
end
Теперь при старте эти константы копируются в локальные копии каждого такого блока, а блоки simulink-а берут значения этих констант напрямую из ModelWorkspace, где я их редактирую вручную (в одном общем месте).
Но всё равно спасибо за Ваш совет. Позже попробую сделать и по Вашему совету.
PS: И спасибо Grizzly - это его совет по set_param натолкнул меня на правильный путь поиска, который через день поисков привёл меня к решению выше.
Но мы же здесь в основном - не разработчики МК, а скорее - их пользователи. А значит нам не важно что там процессор аппаратно выполняет до входа в BootROM, если наше приложение во флешь получит управление только после BootROM. Нам важнее требования этого самого BootROM-а.
В некоторых МК кстати и заход или незаход в BootROM определяется не лапками МК, а только флешью. Например в Tiva процедура старта МК прописана так:
1. The BOOTCFG register is read. If the EN bit is clear, the ROM Boot Loader is executed.
2. In the ROM Boot Loader, the status of the specified GPIO pin is compared with the specified
polarity. If the status matches the specified polarity, the ROM is mapped to address 0x0000.0000
and execution continues out of the ROM Boot Loader.
3. If the EN bit is set or the status doesn't match the specified polarity, the data at address
0x0000.0004 is read, and if the data at this address is 0xFFFF.FFFF, the ROM is mapped to
address 0x0000.0000 and execution continues out of the ROM Boot Loader.
4. If there is data at address 0x0000.0004 that is not 0xFFFF.FFFF, the stack pointer (SP) is loaded
from Flash memory at address 0x0000.0000 and the program counter (PC) is loaded from
address 0x0000.0004. The user application begins executing.
Изначально (на чистых МК из магазина) будет запускаться BootROM или из-за EN-бит==0 или из-за того что во флешь все 0xFFFFFFFF.
Здесь как видно вход в BootROM - опционален и определяется аппаратно.
Например XMC4xxx в режиме загрузки ABM-0 читает некую структуру данных (заголовок прошивки), начинающуюся с адреса 0x0C00FFE0, которая выглядит как:
Magic Key (32 bits)
Start address of code (32 bits)
Length of the code (32 bits)
CRC-32 code for code range (32 bits)
CRC-32 code for above 4 (32 bits)
проверяет её и, если она некорректна, то "execution is aborted and a diagnostics monitor mode (DMM) is entered.", а если корректна, то запускает прошивку с адреса 0x0C000000.
Но, для того чтобы определить режим загрузки, BootROM до этого может читать ещё "User Configuration Block" из другого места флеши и распарсить его.
PS: Так что всё может быть очень причудливо.
Не факт что аппаратно. Где-то это может делать код из BootROM. А где-то - аппаратно.
И не факт что "в самом начале". Опять-же - в самом начале чего?
"Странная таблица" может быть не только в клиентском ПО, но и в загрузчике. См. например семейство Infineon XMC4xxx. Т.е. - эта аксиома, что: "любое пользовательское ПО во флешь должно начинаться там с начала чего-то и управление передаётся на адрес из 0-го вектора и SP устанавливается туда-же" которую пропагандируют тут некоторые товарищи - вовсе не аксиома, а всего-лишь частный случай.
Вообще-то программа начинается задолго до main(). И VTOR у меня устанавливается задолго до main().
Причём тут? загрузчик и основная программа многократно устанавливают оба SP. И SP у меня также устанавливается в самой запускаемой программе в самом её начале. Можно конечно его и в бутлоадере установить, но необязательно.
У меня есть прошивки, где в начале лежит таблица своего формата. По которой загрузчик проверяет прошивку. И адрес старта указан в этой таблице. А приложение может быть вообще скомпилировано для работы в ОЗУ, и адрес старта указывать на точку сразу после таблицы. В этой точке находится небольшой код (он как раз - position independent), который просто копирует образ в ОЗУ. А таблица векторов находится где-то внутри образа, по такому адресу который будет выровнен на 256 после копирования в ОЗУ, но не выровнен в образе.
Нет. Только точку старта. В общем случае конечно может быть таблица в начале и он может оттуда читать адрес старта, но не обязательно.
К тому же при такой компоновке бывают проблемы с генерацией CRC32 для всего образа прошивки для некоторых МК в IAR: для МК LPC невозможно охватить CRC начальную часть таблицы векторов находящейся в начале образа - CRC не сходится никак.
Ещё раз повторю: Считаю, что если что-то слинковано (или ещё как-то сделано), неправильно, то правильный бутлоадер такое вообще не должен запускать или прошивать. Потому что он не может знать, что ещё внутри программы завязано на адреса, и попытавшись что-то скорректировать по своему разумению, приведёт к зависанию устройства или превращению его в кирпич.
Бутлоадер должен принимать только заранее предусмотренные форматы прошивок, жёстко проверять их и отвергать все, хоть чем-то неподходящие.
Что такое "Intended"? Про "indepedent" - знаю. Если Вы имели в виду всё-таки последнее, то:
А откуда загрузчик узнает о том, что оно так написано? А если оно не так написано, а он его куда-то зафигачит не туда?
Запускаемое приложение в любом случае знает где у него находится таблица векторов, так что в любом случае может выставить VTOR на неё. Хоть под что оно написано.
Да и VTOR оно обязательно должно устанавливать.
А откуда загрузчик знает где у загружаемой программы находится таблица векторов? Вобщем случае она может быть и не в начале образа. И их может быть несколько разных.
Всё-таки - VTOR лучше явно устанавливать в самой программе.
Впрочем и правда.
Как такое возможно? Если прошивка была написана на работу stand-alone, то её таблица векторов должна располагаться начиная со стартового адреса flash. Но там же должна находиться таблица векторов бутлоадера, иначе он бы не запускался.
И такую прошивку, которой "в запаре" что-то не так сделали, бутлоадер просто не должен прошивать во флешь или запускать. Мало ли что там ещё "в запаре" сделали или не сделали....
