[MKdemiurg 1]

1 hour ago, dimka76 said:

Только я один не вижу map файл ?

 

Обычный для GCC.
Где-то в середине файла должна быть карта памяти, скопированная из файла линковщика.

В ней же и атрибуты памяти.

Примерно так выглядит

Далее идут стандартные для GCC text, data, bss.

Так же могут быть секции, объявленные пользователем.

1 hour ago, VladislavS said:

Я всё же _user_heap_stack подозреваю. Посмотрите в hex, там хорошо видно даже глазами кусочки из разных областей памяти.

да в Хекс вроде как норм

 

subbootloader.hex

[jcxz 184]

4 минуты назад, VladislavS сказал:

Я всё же _user_heap_stack подозреваю.

А что с ним не так? стек как стек. Расположен там же, где и другие BSS-секции - значит в ОЗУ. Размер нормальный.

[VladislavS 29]

5 минут назад, MKdemiurg сказал:

да в Хекс вроде как норм

Не хотите же вы сказать, что содержимое bin и hex  отличается? Они должны одни и те же данные описывать. Только в hex по адресам всё видно, а в bin "дыры" место занимают.

[jcxz 184]

10 минут назад, MKdemiurg сказал:

да в Хекс вроде как норм

subbootloader.hex 113.64 кБ · 0 загрузок

Где же "норм"?

Смотрим - есть строчка:

:020000040800F2

и есть:

:020000042000DA

задающие сегменты памяти. Расстояние между коими == (2000h-800h)*65536 = 400 МБ

 

А теперь ищите - какое непотребство у вас лезет в сегмент 0x2000 (по которым адресам находится ОЗУ)? имея при этом атрибут .const или .text или какая иная RO-секция.

[MKdemiurg 1]

3 minutes ago, VladislavS said:

Не хотите же вы сказать, что содержимое bin и hex  отличается? Они должны одни и те же данные описывать. Только в hex по адресам всё видно, а в bin "дыры" место занимают.

да

В хексе нулей нет

3 minutes ago, jcxz said:

Где же "норм"?

Смотрим - есть строчка:

:020000040800F2

и есть:

:020000042000DA

задающие сегменты памяти. Расстояние между коими == (2000h-800h)*65536 = 400 МБ

 

А теперь ищите - какое непотребство у вас лезет в сегмент 0x2000 (по которым адресам находится ОЗУ), имея при этом атрибут .const или .text или какая иная RO-секция.

а, да...

[VladislavS 29]

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

020000042000DA

А вот и он, гнилой зуб. Осталось по map посмотреть что в 2000DA00 попало.

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

А что с ним не так?

Там не очевидно, попало ли туда что-то. Эта секция как bss не объявлена.

[jcxz 184]

5 минут назад, VladislavS сказал:

Осталось по map посмотреть что в 2000DA00 попало.

Точнее - в 0x2000B600.

.noinit         0x000000002000b600      0x149                                               
 *(*.noinit*)                                                                               
 .noinit        0x000000002000b600      0x149 ../../build//application/bsp_safety_control.o 
                0x000000002000b74c                . = ALIGN (0x4)                           

Похоже у этой секции стоит атрибут RO (readonly). Потому она и оказывается в результирующем образе.

Или какой-то подобный атрибут.

[dimka76 42]

On 11/23/2023 at 8:01 PM, VladislavS said:

Там не очевидно, попало ли туда что-то. Эта секция как bss не объявлена.

Ну и что. Зато указано, что _user_heap_stack класть в RAM.

[jcxz 184]

3 минуты назад, dimka76 сказал:

Ну и что. Зато указано, что _user_heap_stack класть в RAM.

Ну да - а потом эту RAM цеплять к загрузочному образу, заполняя дырку между ней и флешем и получая огромный .bin.

В RAM не должно попадать никаких неинициализируемых (startup-ом) RO-секций.

[dimka76 42]

On 11/23/2023 at 8:04 PM, jcxz said:

Точнее - в 0x2000B600.

.noinit         0x000000002000b600      0x149                                               
 *(*.noinit*)                                                                               
 .noinit        0x000000002000b600      0x149 ../../build//application/bsp_safety_control.o 
                0x000000002000b74c                . = ALIGN (0x4)                           

Похоже у этой секции стоит атрибут RO (readonly). Потому она и оказывается в результирующем образе.

NOINIT 			(rwx)  	: ORIGIN = 0x20000000 + LENGTH(_RAM_SIZE) - _Min_Stack_Size - LENGTH(_MAIL_SIZE), LENGTH = LENGTH(_MAIL_SIZE)
  
.noinit :
  {
    /* place all symbols in input sections that start with .noinit */
    KEEP(*(*.noinit*))
  } > NOINIT

У региона памяти NOINIT стоит атрибут чтения-записи

On 11/23/2023 at 8:09 PM, jcxz said:

Ну да - а потом эту RAM цеплять к загрузочному образу, заполняя дырку между ней и флешем и получая огромный .bin.

В RAM не должно попадать никаких неинициализируемых RO-секций.

Видимо потому, что регион памяти NOINIT объявлен с атрибутами rwx.

А атрибут х означает, что секция содержит исполняемый код.

On 11/23/2023 at 7:58 PM, MKdemiurg said:

да

А что у вас в файле bsp_safety_control.c ?

[jcxz 184]

20 минут назад, dimka76 сказал:

У региона памяти NOINIT стоит атрибут чтения-записи

Опять 25...  уже говорил, что целевые регионы памяти тут не при чём. При чём - секции и их атрибуты.

У той ".noinit"-секции какие атрибуты стоят?

GCC у меня нет, пример под IAR. Пишем в .cpp:

__root u32 const volatile zzz[7] @ ".noinit" = {1,2,3,4,5,6,7};  ///

компилим, получаем в .map:

zzz                     0x200043d0     0x1c  Data  Lc  gen.o [1]                            

zzz попала в ОЗУ.

Далее - чуть меняем описание zzz:

__ro_placement __root u32 const volatile zzz[7] @ ".noinit" = {1,2,3,4,5,6,7};  ///

опять компилим, получаем .map:

zzz                     0x080002e0     0x1c  Data  Lc  gen.o [1]                            

zzz попала во FLASH.

 

Командный файл компоновщика и конфигурация выходных регионов памяти не менялась. Имя секции ".noinit" - тоже. Но она попала в совершенно другой регион памяти. Т.е. - её попадание туда обусловлено только изменившимися атрибутами этой секции.

Также и у ТС может быть.

[MKdemiurg 1]

7 minutes ago, dimka76 said:

NOINIT 			(rwx)  	: ORIGIN = 0x20000000 + LENGTH(_RAM_SIZE) - _Min_Stack_Size - LENGTH(_MAIL_SIZE), LENGTH = LENGTH(_MAIL_SIZE)
  
.noinit :
  {
    /* place all symbols in input sections that start with .noinit */
    KEEP(*(*.noinit*))
  } > NOINIT

У региона памяти NOINIT стоит атрибут чтения-записи

Мдэ

:020000042000DA
:01B6000055F4
:0400000508001DBD15
:00000001FF

хекс

линкер

  .noinit :
  {
    /* place all symbols in input sections that start with .noinit */
    KEEP(*(*.noinit*))
  } > NOINIT

static volatile __attribute__((section(".noinit"))) uint8_t test= 0x55;

[jcxz 184]

6 минут назад, MKdemiurg сказал:

static volatile __attribute__((section(".noinit"))) uint8_t test= 0x55;

Ну вот - почти повторяет мой пример: Секция ".noinit", но почему-то имеет инициализатор. Но не может быть инициализирована startup-кодом при старте программы. Из-за этого видимо ей был присвоен атрибут RO, и она была помечена как "должна присутствовать в образе прошивки". И добавлена туда.

Уберите инициализатор (0x55) и возможно всё станет ok.

[MKdemiurg 1]

3 minutes ago, jcxz said:

Ну вот - почти повторяет мой пример: Секция ".noinit", но почему-то имеет инициализатор. Но не может быть инициализирована startup-кодом при старте программы. Из-за этого видимо ей был присвоен атрибут RO, и она была помечена как "должна присутствовать в образе прошивки". И добавлена туда.

Без инициализатора история такая же

:04C12000000000001B
:020000042000DA
:01B600000049
:0400000508001DBD15
:00000001FF

#pragma GCC optimize ("O0")

static volatile __attribute__((section(".noinit"))) uint8_t test;

#pragma GCC optimize ("Og")

 

[jcxz 184]

2 минуты назад, MKdemiurg сказал:

Без инициализатора история такая же

Значит ещё чего-то не хватает. В IAR нужно было бы добавить префикс __no_init:

__no_init static volatile uint8_t test @ ".noinit";

Но в GCC - не знаю.

А что скрывается за __attribute__?