VladislavS

Все средства разработки отлично в Windows работают без танцев с бубном. Просто берёшь и работаешь. К чему всё это? 😮

Об IAR для какого процессора речь? Для ARM, например, startup есть в любом проекте в виде исходника. Меняй сколько хочешь. В папке с установленным IAR много разной документации. В EWARM_DevelopmentGuide.ENU.pdf много полезного.

А что даташит про это говорит?

Дело даже не в компиляторе. На уровне языка можно только предполагать где что будет размещено. А дальше можно чем-то управлять ключами, чем-то скриптом линкера. Всё implementation dependent, так вроде в стандарте языка сказано. Ничего странного. Стандарт языка не определяет как оно под капотом должно работать. Что-то в gcc поменяли в очередной версии. Бывает. Более того, то что .noinit ведёт себя как обычная непривилегированная секция, в отличии от .bss, очень даже правильно.

Перемещение и выкидывание это разные вещи. Компилятор может rom->ram по разным критериям перекидывать. Ради скорости, например.

Да пофиг на атрибуты секции rwx. Надо линкеру в скрипте сказать, что эту секцию не загружать. В случае с .bss это автоматом, видимо, происходит - компилятор и линкер знают про неё. Для .noinit кроме названия (линкеру пофиг на него должно быть) ничего не говорит, что её надо игнорить. Это расширение IAR и только IAR. Для совмесиимости лучше наоборот в iar писать __attribute__. В коде нет, в скрипте линкера всё.

А вот и он, гнилой зуб. Осталось по map посмотреть что в 2000DA00 попало. Там не очевидно, попало ли туда что-то. Эта секция как bss не объявлена.

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

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

Давайте и линкерскрипт смотреть.

_user_heap_stack подозрительно.

Экстрасенсы требуют загрузить в хрустальный шар map-файл.

Точно точно?

На приведённых вами картинках DIVMx, DIVNx, ... это оно и есть.

Микросхемы работают на волшебном дыме. Когда вы подали питание на закороченную цепь - дым вышел.

Прошивку считать, к бабке не ходи.

Запускаешь 10 копий программы и отлаживаешь 20 контроллеров одновременно.

Вот тоже думаю, что работать надо инструментом предназначенным для этого.

Это вообще логический оператор. Из 0 в 1 получается через несколько приведений типов. Это называется "грязной лапой". А если речь про С++, то там вот так делают enum class cursor_mode : uint8_t { NO_BLINK=0, BLINK=1 };

Кстати, в "arm\src\flashloader\NXP\FlashIMXRT1170_FlexSPI" лежат исходники FlashLoader-а. Можете посмотреть до последней команды что он делает. У вас же в .board написано, что для адресов 0x60000000+ его использовать.

В файл FlashIMXRT1170_FlexSPI2.flash загляните

раз у вас флэшка на SPI1 работает, то алгоритм прошивки для неё есть. Вам надо перенастроить в .board адреса и в .mac инциализацию на SPI2.

Ну так берём и правим под себя. За вас этого никто не сделает. В папке с доками у IAR есть файлик FlashLoaderGuide.ENU.pdf - там всё подробно расписано.

Алгоритм прошивки флэшки

Вот пример простенького скаттера для Cortex-M0+ и компилятора V6. STM32G071xB_flash.sct