[const 1]

On 8/27/2024 at 2:43 PM, jcxz said:

Использую CRC в IAR и никакой константный адрес для CRC не прописываю ни разу. Располагаю CRC в таблице векторов прерываний.

Я так и не понял, вы ее сами располагаете или линкер без указаний ее туда ложит?

Мой, если без указаний, ложит сюда:

 .checksum            const     0x800'38e8         4     0x4  Place holder __checksum

похоже, что это далеко за таблицей векторов.

[dimka76 85]

On 8/29/2024 at 12:19 AM, const said:

Покажите как это выглядит в линкере и как передать адрес расположения размера прошивки (в прошивке) в программу, пожалуйста. И как положить КС в конец прошивки.

у меня GCC

On 8/28/2024 at 12:57 PM, Arlleex said:

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

Программе патча вообще по таблицам векторов лазить не обязательно.
Она размер прошивки по размеру файла бинарника может определить.

[AlexRayne 14]

А есть в ИАР способ задания диапазона подсчета КС не по фиксированым адресам а по диапазону прошивки?

[Arlleex 311]

2 часа назад, dimka76 сказал:

Программе патча вообще по таблицам векторов лазить не обязательно.
Она размер прошивки по размеру файла бинарника может определить.

И? Где хранить размер образа в бинарнике собираетесь?

[dimka76 85]

On 8/29/2024 at 12:47 PM, Arlleex said:

И? Где хранить размер образа в бинарнике собираетесь?

В общем случае, где угодно, лишь бы сама прошивка знала где он располагается.
И в моем случае (GCC) размер прошивки линковщик сам вычисляет и размещает куда нужно.
А комповая утилита просто по размеру бинарного файла определит размер прошивки.

[jcxz 342]

5 часов назад, const сказал:

Я так и не понял, вы ее сами располагаете или линкер без указаний ее туда ложит?

Почему без указаний? Указываю: класть в 8-й вектор таблицы векторов.

1 час назад, dimka76 сказал:

А комповая утилита просто по размеру бинарного файла определит размер прошивки.

Иногда бывает нужно прошивку сопроводить набором других бинарников. Которые удобно цеплять в хвост бинарника основной прошивки. Это содержимое внешних флешек устройства. Например в моём 3D-принтере прошивка дополняется кучкой файлов - разных пиктограмм для ЖК-индикатора. Которые пишутся в SPI-флешку. Места для них во флешь МК - нету.

Также прошивка основного МК может дополняться прошивками разных модулей, входящих в состав устройства. Которые основной МК прошивает после старта. У нас так в одном проекте прошивались модули: PLC, ZigBee, GSM-модем, RF-модуль... Прошивки всех их хранились в SPI-флешке основного МК.

Также бывает нужно шифровать прошивку или добавить её электронную подпись (сгенерённую SHA-xxx например). Тогда тоже по размеру бинарника размер прошивки не определить.

В этом случае удобно размер основной прошивки хранить в фиксированном месте - в таблице векторов например.

[Arlleex 311]

2 часа назад, dimka76 сказал:

В общем случае, где угодно, лишь бы сама прошивка знала где он располагается.
И в моем случае (GCC) размер прошивки линковщик сам вычисляет и размещает куда нужно.
А комповая утилита просто по размеру бинарного файла определит размер прошивки.

У меня бинарник содержит не только прошивку, но и базовую конфигурацию, например. Эта область не должна проверяться чексуммой ФПО, так как одно и то же ФПО может быть на девайсах с самой разной конфигурацией. Для этой области отдельные контрольные суммы. Поэтому по размеру бинарника не выйдет собрать валидный образ (у меня).

[const 1]

И с КС прошивки вопрос решил. Считаю как jcxz - "с разрывом". Только куда ложить КС линкеру не говорю (сморю куда положил так: &__checksum).

Он ее по разному ложит при изменении исходника, но это уже не проблема, как и хотел, диапазон задаю только в одном месте - на вкладке линкера Checksum.

[jcxz 342]

46 минут назад, const сказал:

Только куда ложить КС линкеру не говорю (сморю куда положил так: &__checksum).

Он ее по разному ложит при изменении исходника, но это уже не проблема, как и хотел, диапазон задаю только в одном месте - на вкладке линкера Checksum.

Это не проблема, пока не захотите прошивку анализировать каким-то внешним инструментом: Своим бутлоадером например; или какой-то сервисной утилитой, которая проверяет и шифрует прошивку перед отправкой. Вот тогда будет весьма полезно знать точное местоположение CRC.

[const 1]

1 hour ago, jcxz said:

Это не проблема, пока не захотите прошивку анализировать каким-то внешним инструментом: Своим бутлоадером например; или какой-то сервисной утилитой, которая проверяет и шифрует прошивку перед отправкой. Вот тогда будет весьма полезно знать точное местоположение CRC.

Вы кладете в восьмое прерывание отсчитывая с нуля? То есть КС будет тут?

__vector_table
        DCD     sfe(CSTACK)
        DCD     Reset_Handler             ; Reset Handler

        DCD     NMI_Handler               ; NMI Handler
        DCD     HardFault_Handler         ; Hard Fault Handler
        DCD     MemManage_Handler         ; MPU Fault Handler
        DCD     BusFault_Handler          ; Bus Fault Handler
        DCD     UsageFault_Handler        ; Usage Fault Handler
        DCD     0                         ; Reserved
        DCD     0                         ; Reserved /* ТУТ */
        DCD     0                         ; Reserved
        DCD     0                         ; Reserved
        DCD     SVC_Handler               ; SVCall Handler
        DCD     DebugMon_Handler          ; Debug Monitor Handler
        DCD     0                         ; Reserved
        DCD     PendSV_Handler            ; PendSV Handler
        DCD     SysTick_Handler           ; SysTick Handler

 

[jcxz 342]

1 час назад, const сказал:

Вы кладете в восьмое прерывание отсчитывая с нуля? То есть КС будет тут?

да

[Arlleex 311]

3 часа назад, jcxz сказал:

Это не проблема, пока не захотите прошивку анализировать каким-то внешним инструментом: Своим бутлоадером например; или какой-то сервисной утилитой, которая проверяет и шифрует прошивку перед отправкой. Вот тогда будет весьма полезно знать точное местоположение CRC.

Да банально для сертификации - сертификаторы обычно говорят "запускайте свою шарманку, чтоб показала, что файл, который загружается, имеет ту контрольную сумму, что прописана на бумажке". Загружаем - программа выводит. Потом он говорит - "Теперь шей этим файлом микроконтроллер". Шьем. Он говорит - "Теперь покажи, что зашитая программа имеет нужную КС". Запрашиваем сервисной утилитой связи с девайсом - он возвращает.

Если не знать, куда ляжет каждый раз КС, се-ля ви, досвидос.

[const 1]

2 hours ago, jcxz said:

да

подскажите, что прописать в .icf

я пробую так

place at address mem:__ICFEDIT_region_FLASH_start__+0x20 { readonly section .checksum };

выдает ошибку

	Error[Lp015]: section placement failure: overcommitted content in [0x800'0000-0x800'001f]		

 

[jcxz 342]

14 часов назад, const сказал:

подскажите, что прописать в .icf

Очень просто:

Таблицу векторов описываю как две разные секции: 1-я секция - первые 8 векторов (section .intvec); 2-я секция (section .intvecTail) - остальные вектора начиная с 9-го (с пропуском 8-го).

Далее в .icf (в данном конкретном примере ниже у меня 8-й и 9-й вектора заняты спец.функциями: 8й = CRC, 9й = указатель на таблицу описателей прошивки (section .codehead); поэтому пропущены 2 вектора: 8й + 9й) объявляю блок IMAGE_HEAD, в котором делаю объединение секций в нужном порядке и потом уже - размещение в регион памяти:

define region FLASHC_regionA = mem:[from 0x08000000 to 0x080FFFFF]; //PMU/FLASH (cached)
...
define block IMAGE_HEAD with fixed order {section .intvec, section .checksum, section .codehead, section .intvecTail, section .codeSignature};
place in FLASHC_regionA {ro, first block IMAGE_HEAD, section .dma_const, last section .codetail};
...

[AlexRayne 14]

48 минут назад, jcxz сказал:

Очень просто:

А удавалось ли Вам положить в самый конец прошивы секцию? У меня ИАР после 

last section

еще докладывает  секцию  с "Initializer bytes    const" - она делается после сборки всех секций, и не удается мне положить чтото за ней, чтобы подсчитать реальный размер прошивы

Edited August 30, 2024 by AlexRayne