Andrey
05be38a04a
Добавить защищённое обновление приложения через RS и CAN с сохранением загрузчика, проверкой CRC, восстановлением передачи и защитой EEPROM. Подключить общий процесс сборки C2000 и автоматический счётчик версии для согласованных RAM, Flash, CAN и паспортов бинарных образов. Уточнить запуск ЦАП, обработку измерений и параметров нагрузки, начальную индикацию и документацию регистров GAS. Дополнить модели аппаратуры и изолировать заголовки CAN в тестах. Проверка: 26 тестов выпуска, 4 теста восстановления CAN и восемь программных моделей CAN, Flash, EEPROM, ЦАП, параметров и TESTLAMP.
88 lines
7.4 KiB
Markdown
88 lines
7.4 KiB
Markdown
# Обновление внутренней Flash F28335 по CAN
|
||
|
||
В постоянный загрузчик ProtoCAN добавлена запись приложения во внутреннюю Flash.
|
||
Сектор A (`0x338000…0x33FFFF`, адреса в 16-битных словах) остаётся загрузчиком;
|
||
обновляются только B–H (`0x300000…0x337FFF`). RS-232 и обновление EEPROM A/B
|
||
сохраняют прежние команды. Поддерживается текущая аппаратная конфигурация M95M02:
|
||
её неактивный слот используется для временного хранения полного образа.
|
||
|
||
## Первичная установка
|
||
|
||
1. Собрать обновлённый постоянный загрузчик из зависимости SETGUI:
|
||
|
||
```powershell
|
||
python K:/git_project/newProject/SETGUI/third_party/templates/c/protocan-boot/projects/build.py --device f28335 --configuration Release --output K:/git_project/28335_periph/outputs/can-flash-20261021/loader
|
||
```
|
||
|
||
Нужны установленный TI C2000 COFF compiler и официальный TI Flash API v2.10
|
||
F28335. Его include/lib подключены в Debug и Release CCS-проекта.
|
||
|
||
2. Через JTAG установить новый `F28335_CAN_AB.out` **только в сектор A**.
|
||
Использовать существующий режим установки постоянного загрузчика с маской A;
|
||
полное стирание чипа удалит приложение. Разметка EEPROM и параметры не меняются.
|
||
3. Аппаратный режим запуска должен выбирать Flash boot. Старый запуск непосредственно
|
||
SPI ROM не передаёт управление постоянному загрузчику и не разрешает CAN handoff.
|
||
|
||
Существующий загрузчик без этой доработки отклоняет новую команду выбора памяти.
|
||
Обновить сам сектор A через действующий RS Flash или CAN нельзя: он защищён от записи.
|
||
|
||
## Обновление приложения из SETGUI
|
||
|
||
1. Открыть общую страницу «Прошивка», выбрать **CAN / ProtoCAN Boot** и подключить
|
||
CAN-адаптер. Штатная скорость PERIPH — 250000 бит/с.
|
||
2. Выбрать нужный PERIPH: УМП1 — Type 1 / Device 5, УМП2 — 1/6, задатчик — 1/8.
|
||
Product Type — `0x2833`, аппаратная ревизия — 1.
|
||
3. В поле **«ProtoCAN: память прошивки»** выбрать **«Внутренняя Flash F28335»**.
|
||
4. Открыть `*_flash_rs.bin` из папки `rs` штатного комплекта сборки. Это тот же
|
||
SCI8 Flash BIN с FAB1, который используется для RS Flash. RAM BIN из `can`
|
||
либо `eeprom`, COFF OUT и образ с аппаратным входом сектора A не подходят.
|
||
5. Запустить обновление и дождаться подтверждения записи и перезапуска.
|
||
|
||
Максимум — 130560 октетов SCI8, до 64 непересекающихся секций. Исполняемый entry
|
||
обязан присутствовать в данных приложения. EEPROM-кандидат после такого обновления
|
||
не создаётся: при обычном reset постоянный boot предпочитает проверенную Flash,
|
||
а подтверждённый EEPROM-образ остаётся резервным источником запуска.
|
||
|
||
## Последовательность и сохранность
|
||
|
||
`ENTER_BOOT → SELECT_MEMORY(1) → BEGIN_IMAGE → BEGIN_COMPAT → ERASE staging →
|
||
DATA → VERIFY → COMMIT Flash → REBOOT`.
|
||
|
||
Новая управляющая команда `0x10` имеет один октет данных: 0 — прежняя EEPROM A/B,
|
||
1 — внутренняя Flash. Она принимается только в текущей ненулевой сессии до любых
|
||
метаданных. Каждая новая сессия начинает с EEPROM по умолчанию; сменить цель после
|
||
начала передачи нельзя. Старый клиент без этой команды сохраняет прежнее поведение.
|
||
|
||
На VERIFY загрузчик заново читает staging EEPROM, проверяет транспортную CRC32,
|
||
границы SCI8, перекрытия, наличие entry и FAB1, CRC будущей физической Flash.
|
||
Перед COMMIT эти проверки выполняются повторно. Только затем TI Flash API стирает
|
||
маску `0x00FE` (B–H), записывает данные порциями до 128 слов и проверяет каждую порцию.
|
||
FAB1 записывается последним; затем проверяется CRC уже физической Flash.
|
||
|
||
Код и таблицы TI API копируются из A в RAM `0x8000…0x97FF`. На время аппаратных
|
||
вызовов IRQ запрещены: секторы A–H используют общий банк Flash. Сам CAN-сервис и
|
||
его очередь остаются в постоянном загрузчике. Подтверждение COMMIT приходит после
|
||
полной записи и проверки; клиент ждёт до 180 секунд и затем отдельно запрашивает reset.
|
||
|
||
При отказе erase/program/readback COMMIT возвращает ошибку. Частичный образ с
|
||
недействительным FAB1/CRC не запускается; boot A сохраняется для восстановления.
|
||
Подтверждённый EEPROM-слот и параметры не изменяются. Прежний неактивный слот
|
||
EEPROM используется как staging и при этом теряет свой старый резервный образ.
|
||
|
||
## Проверка
|
||
|
||
```powershell
|
||
python tests/can_boot/run_flash_test.py
|
||
python tests/protected_boot/run_test.py
|
||
```
|
||
|
||
`CAN_FLASH_IMAGE` позволяет передать тесту настоящий Flash BIN текущей сборки.
|
||
Сквозной тест использует реальный клиент SETGUI, ядро ProtoCAN, аппаратный CAN-порт,
|
||
EEPROM-журнал и Flash writer; подменяются только физические CAN/SPI/Flash.
|
||
Проверяются сохранность A и параметров, резервный EEPROM-слот, CRC, неверные адреса,
|
||
обрезание, перекрытия, изменение staging после VERIFY и обрыв erase/данных/FAB1.
|
||
|
||
Debug и Release собраны TI C2000 22.6.0.LTS; проверены реальные COFF LOAD-адреса
|
||
в секторе A. Испытание физических CAN, SPI, питания и автономного запуска на плате
|
||
ещё требуется. В ходе разработки плата не программировалась.
|