VladislavS

А вот и он, гнилой зуб. Осталось по 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

Вам необходимо нормальный скаттер-файл в проекте иметь. https://developer.arm.com/documentation/100070/0612/scatter-loading-features/the-scatter-loading-mechanism/placing-the-stack-and-heap-with-a-scatter-file

Именно это я и показываю. Разносим классы по заголовочным файлам не увеличивая количество единиц трансляции. Что положительно сказывается на оптимизации - хочешь на скорость, хочешь на объём.

Две страницы назад я показывал пример как в заголовочном файле размещается код без создания дополнительных единиц трансляции. О чем, собственно, этот топик и есть. Ничего общего с примером организации интерфейса класса он не имеет. Это плод вашей фантазии. В классе на пол экрана кода всего с двумя открытыми методами выделять интерфейс нет никакого смысла.

Где я что показал? Ничего не показывал - у вас глюки.

Не только! И при желании можно организовать читаемую открытую секцию с интерфейсом и закрытую с реализацией. Шаблонные параметры класса это тоже его интерфейс и концепты позволяют с ними работать.

Нет, конечно.