STM32L471 запрет прямой адресации

[Forger 0]

6 minutes ago, Arlleex said:

В большинстве подобных задач вся "головная боль" сводится лишь к тому, каким макаром конкретная копия прошивки может признать себя невалидной/неактуальной/плохо отлаженной/и т.д., либо как это может понять сам бутлоадер. По сути это будет лишь перетасовывание флагов "валидности" в какой-то области Flash (может, в дескрипторной части самих прошивок, если предусмотрено).

Можно применить аппаратную сторожевую собаку, а уже бутлодер при страрте прочитав соотв флаги о причине последнего сброса, поймет сам - от собаки был сброс или это было типовое включение питания.

Разумеется прошивка должна уметь грамотно работать с такой сторожевой собакой, а не тупо сбрасывать ее в суперлупе.

Я применяю вообще отдельную задачу под оконный WDT, с самым низким приоритетом. Сбросил слишком рано - ресет, слишком поздно - тоже.

Если идти дальше, то эту "сторожевую" задаче можно наделить функционалом проверять все остальные задачи (речь конечно по проекте под ртос).

[jcxz 4]

25 минут назад, Arlleex сказал:

Понятно. Тогда PIC.

Необязательно. Компилировать можно один раз, а компоновку запускать (из одних и тех же объектных файлов) - 2 раза (с двумя разными командными файлами компоновщика, настроенными на разные области  флешь). Затем склейка двух готовых образов (hex/bin/etc.) в один.

[Arlleex 1]

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

Необязательно. Компилировать можно один раз...

У ТС не абсолютно одинаковые прошивки, поэтому один фиг компилировать несколько раз. А раз такая пьянка - то в keil-е проще настроить второй target, в его опциях поставить галку пост-сборочного запуска утилиты (хоть самописной, хоть, например, srecord) склейки. Запускаем компиляцию/сборку первого target-а - формируется его hex; запускаем компиляцию второго target-а - формируется его hex и тут же автоматом программа склейки объединяет все как надо. Способов миллион. Но раз ТС утверждает, что на неком временном срезе не известно, где в памяти какая прошивка хранится (старая/новая) - то лучше PIC, если не в ущерб производительности. Хотя и в этом случае маркеры нужны - где какая сейчас лежит.

[urri_urri 0]

Флэш память STM32L471 Позволяет переключать банки памяти с помощью регистра SYSCFG. В первой странице размешаете загрузчик, который определяет, какой банк будет использоваться(какая прошивка валидная). Основная программа размещается на второй странице с адреса 0x0800 0800. Второй экземпляр прошивки в банке 2 по адресу  0x0808 0800. При необходимости банки перемапируются. Это позволяет компилировать с прямой адресацией и без изменения настроек.

[Димон Безпарольный 0]

11 hours ago, Forger said:

Тогда задача значительно упрощается - делайте сразу две прошивки, привязанные жестко к двум разным адресам.

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

Я уже писал что неизвестно на каком адресе окажется прошивка. В нижней или верхней половине. Потому как прошивка может не запустится и тогда стартует предыдущая. 

На приборе нет ни одного органа управления и корпус герметичный. Кстати, Заказчика совершенно не волнует кража кода. Прибор специфичный.

2 hours ago, urri_urri said:

При необходимости банки перемапируются. 

А как в этом случае, загрузчик тоже переместится во второй банк?

[Arlleex 1]

Делайте уже PIC и не парьтесь Тем более, если заказчик сам хочет видеть такую реализацию.

[x893 0]

10 hours ago, Димон Безпарольный said:

А как в этом случае, загрузчик тоже переместится во второй банк?

А что мешает загрузчику сначала перейти в RAM ?

И оттуда уже переключать как угодно

[urri.gureev 0]

26.05.2022 в 08:47, x893 сказал:

А что мешает загрузчику сначала перейти в RAM ?

И оттуда уже переключать как угодно

Или так. Я размещал 2 одинаковых загрузчика в обоих банках. Вернее, при старте загрузчик проверял, есть ли его копия в другом банке, еси нет - копировал, потом, если надо, переключался.

[Димон Безпарольный 0]

Включил опцию ReadOnly Position Independed. Получаю 700 варнингов:

 

Quote

warning:  #1357-D: static initialisation of variable "camellia_256_cbc_info" using address of string literal may cause link failure -ropi

Нарыл только то, что статические переменные должны инициализироваться до динамических. 

 

https://fullstackuser.com/questions/529011/initialisation-of-static-variable-with-itself

Edited May 29 by Димон Безпарольный

[Anxigeros 0]

Position independent code and data (ROPI and RWPI)

Цитата

When this option is used, these limitations apply:

Pointer constants cannot be initialized with the address of another constant, a string literal, or a function. However, writable variables can be initialized to constant addresses at runtime.

[Forger 0]

Складывается впечатление, что затея в итоге приведет к повторному переписыванию и отладке всего кода 

 

[Димон Безпарольный 0]

Также ругается на скаттер файл:

 

Quote

Systems that implement shared libraries with RWPI use a process data table (PDT). It is created at static link time by the linker and must be placed first in the data area of the image.

This message indicates that the scatter file does not permit placing the PDT first in the data area of the image.

To avoid the message, adjust your scatter file so that the PDT is placed correctly. This message can also be triggered if you accidentally build object files with --apcs=/rwpi.

Каким образом надо поменять скаттер чтобы таблица PDT разместилась первой?

 

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IROM1 0x08004800 0x00100000  {    ; load region size_region
  ER_IROM1 0x08004800 0x00100000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
  }
  RW_IRAM1 0x20000000 0x00018000  {  ; RW data
   .ANY (+RW +ZI)
  }

  RW_IRAM2 0x10000000 UNINIT 0x0000400  { ;no init section. Эта область памяти закрыта аппаратной защитой
  *(.noinit )}

  RW_IRAM3 0x10000400 0x00008000 - 0x400  {
   .ANY (+RW +ZI)

  }
}
 

Edited May 29 by Димон Безпарольный

[Димон Безпарольный 0]

Quote

L6640E: PDTTable section not least static data address, least static data section is <secname>

Systems that implement shared libraries with RWPI use a process data table (PDT). It is created at static link time by the linker and must be placed first in the data area of the image.

This message indicates that the scatter file does not permit placing the PDT first in the data area of the image.

To avoid the message, adjust your scatter file so that the PDT is placed correctly. This message can also be triggered if you accidentally build object files with --apcs=/rwpi.

Как - то надо изменить скаттер файл, но не пойму как. Почему линкер не хочет разместить PDT таблицу в RW_IRAM1 тоже непонятно.

Edited May 29 by Димон Безпарольный

[Димон Безпарольный 0]

Position independence is not supported in microlib.
Упс... 

 

Quote

Restrictions

You cannot use --rwpi:

• With --scatter.
• If an object file contains execute-only sections.

Related reference

А как тогда быть?

Edited May 29 by Димон Безпарольный