VladislavS

С таким количеством RAM код на время отладки проще загружать в неё, а не во FLASH.

Перечитал тему ещё раз. Да нет же, у ТС компилятор хрень делает, а не у меня. Хорошо что именно я ничего не понимаю в компиляторах. :)))

Потому что так задумано. DTCM и ITCM только для ядра доступны без всяких шин быстро и сразу. Вообще, настройки линкера никак не влияют на работу периферийных устройст, а лишь размещают данные в памяти. Можете тупо указывать в функциях абсолютные адреса и ни один линкер это не изменит. Проверяйте включены и настроены ли все нужные области памяти и периферийные модули. Обратите внимение на настройки MPU - защита и кэширование областей памяти могут мешать работе DMA.

Действительно, при чём тут С++? Обычный С-код.

Любая программа это последовательность операций "в одно действие". И это правильно, программа должна работать так как задумано. Хорошо что вы понимаете. Только почему-то это "понимание" не помогает правильные программы писать.

Ну вы сказали, и что изменилось?

Критерий "ровно в тот момент времени" огласите? С точностью до такта? На ARM с конвейером, предвыборками, разными шинами, DMA и кэшами это в принципе невозможно даже на ассемблере. "Ровно как написано" в смысле последовательности чтений/записей делается на С правильной расстановкой volatile вне зависимости от режимов компиляции/оптимизации.

А потом включаете LTO и... Во-первых, мы этого не видим, код засекречен. Во-вторых, внимательно следим за руками. Вот тут компилятор выдаёт предупреждение: Ну ок, объясним компилятору КАК мы хотим: И он нас услышал //int main() //{ main: // int tmp_a = a; LDR.N R2,??DataTable1_1 LDR R1,[R2, #+0] // int tmp_b = b; LDR R0,[R2, #+4] // c = tmp_a + tmp_b; ADDS R1,R0,R1 STR R1,[R2, #+8] // for(;;); ??main_0: B.N ??main_0 //} ??DataTable1_1: DATA32 DC32 a Хотите наоборот? Легко. //int main() //{ main: // int tmp_b = b; LDR.N R2,??DataTable1_1 LDR R0,[R2, #+4] // int tmp_a = a; LDR R1,[R2, #+0] // c = tmp_a + tmp_b; ADDS R0,R0,R1 STR R0,[R2, #+8] // for(;;); ??main_0: B.N ??main_0 //} Обращаем особое внимание, что компилятор оставил только операции с volatile сущностями, остальное для него было лишь пояснение что и как я хочу сделать.

Любая программа это и есть жесткая последовательность действий. Но если вы её компилируете оптимизирующим компилятором, то для него важны только функция main и все действия с volatile сущностями. Остальное он воспринимает как описание того что вы с ними хотите сделать. Если вы этого не понимаете, то получаете то что на вашей картинке. Да куда уж нам... 😄

Ещё раз. Компилятор не имеет права менять задуманный код, но для этого его надо правильно писать. Вы это как поняли, если код не предъявлен? В хрустальном шаре?

Чтобы компилятор вообще не менял задуманный код - его надо правильно написать. Если возникли желание/потребность отключить опитимизацию на участке кода, то вы явно что-то делаете не так.

Для этого просто обязательно умение писать под оптимизирующий компилятор. Либо на асме. Третьего не дано.

А смысл его показывать, если компилятор всё равно виноват :)) Ответ: Что в коде написали, то компилятор и сделал.

Последовательность поменяна и номера не все. Думаете нам интересно в этом дерьме разбираться? А ошибка уже в первой же С-ной строке. PS: И далеко не всё что видно объявлено volatile. Это по генерируемому коду видно.

Исходный код до компиляции без всяких асмов есть?

Это чтобы успеть лишний раз подумать а надо ли оно мне :)))

Что-то не очень похоже на STM32. Какой-то клон?

+1. Что 150 мкс, что 150 мс - суть одно и то же. При внутрисхемной прошивке вообще секунды контроллер в ауте. Схемотехника должна это предусматривать.

А где отладка то? Регистры процессора и периферии, дизасм?

Чисто в педагогических целях стоит решить задачу самому.

J-Link это всего лишь адаптер, он ничего сам не делает. Делает программа, которая с его помощью прошивает. Программ этих чуть больше чем дофига и каждая делает посвоему. Собственно и OpenOCD через J-link шить умеет.

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

Вообще-то, Кернигана и Ритчи 🙂 Это никому не повредит. Но что-то мне подсказывает, что там ни про работу с volatile сущностями, ни про оптимизирующий компилятор, ни про то как данные с задержками по шинам бегают, ни вообще про эмбэдд ни слова не будет. А до Страуструпа ещё надо дорасти.

Тут, кстати, "они там все" запросто получат двойной вход в одно и то же прерывание. Но об этом хомячкам не расскажут.

Между чтение для обработки и повторным чтением для очистки могло произойти что угодно. Это Секрет Полишинеля. Впрочем, тот код что для них индусы пишут, ещё ничего. :)))