А еще есть "якобы бесполезная" штука. Называется юнит-тестирование. Можно ли проект прошивки влепить в обычное консольное приложение и прогнать комповыми отладочными инструментами? Если так сделать нельзя, значит структура проекта не очень хороша, раз аппаратные вопросы так тесно замазаны на низкоуровневые регистры и прочий код.

ТС, а что отладчик говорит вообще? Как оцениваете, что области не наезжают друг на друга?

Сообщение отредактировал Arlleex - Jul 19 2018, 07:57

У процессоров Intel x86 в защищённом режиме можно настроить дескрипторы так, чтобы из региона, где выполняется код чтение данных было запрещено. На то он дескриптор кода.

У STM32F7 также, не?

Сообщение отредактировал __inline__ - Jul 19 2018, 07:56

Почти во всём соглашусь, кроме того, что чтение данных из секции кода необходимо: если посмотреть любой асм-листинг ARM, то компилятор располагает константные данные вблизи функций их использующих, в этом же самом сегменте. Чтобы можно было дотянуться до них через косвенную адресацию по PC. И доступ ко всем переменным начинается с чтения её адреса в регистр через PC+смещение. Ну не предусмотрена в архитектуре ARM прямая адресация. Только косвенная.
А в остальном - у меня в MPU тоже примерно так же настроены сегменты, за исключением кучи. А стек - он у меня часть R/W-сегмента, не выделяю его в отдельный регион.
Ещё можно с помощью MPU отлавливать несанкционированные доступы к каким-то переменным: обнаружили что кто-то портит переменную, а кто - не знаем: выделяем её в отдельный сегмент и через MPU открываем доступ к этому сегменту на запись только в тех местах, где по алгоритму это нужно. И когда кто-то левый полезет в неё писать - получим fault. Но вот для дин.памяти эта полезность сразу отпадает - только статически.

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

Чтобы так сделать (запретить чтение из секции кода), придётся компилятору один из регистров CPU статически выделить для хранения адреса сегмента данных. И таскать его через все функции, используя его вместо адресации по PC. Компилятор такое вроде умеет делать (не пробовал, но думаю чекбокс IAR-а в свойствах проекта "No data reads in code memory" - именно про это).
Но полученный код будет неоптимальным. Через PC - гораздо удобнее.
Но этот чекбокс видимо полезен при создании перемещаемой программы, которую можно расположить и запустить с произвольного адреса памяти.

Ради быстрого эксперимента забил бы ОЗУ по включению питания 0xFF, а потом отдал на выполнение. Было бы видно как разместились области данных и пересекаются ли они вообще.

Хмммм.... не факт... У меня например много переменных объявлены с квалификатором __no_init. Собственно - все большие массивы с ним объявлены. Для ускорения старта ПО
Эти области будут выглядеть как неиспользуемые. А раз ТС использует сторонний софт, то неизвестно как там объявлены переменные.

Воу воу воу!! Парни остановитесь
Я только jcxz хотел чтобы меня научил. Это связано его, очевидно, очень глубоким познанием работы АРМа...

По сути дела:
1. конфигурация переменные в начале - стэк в конце работает всегда, с небольшим общим объемом, и любыми передвижениями этой конструкции по памяти
2. конфигурация стек до переменных - работает временами на каких-то значения границы работает, на каких-то нет.
3. Я по всякому двигал границы, раздвигал их и перемещал, в случае плохой работы повторяемость 100%. При этом нет фатального падения, есть задержка работы.
Этим я исключаю случайные повреждения памяти, потому что вероятность такого везения что в разных конфигурациях я херю одну и туже переменную, да так что это не приводит к тотальному падению - ноль. Так же я исключаю нехватку памяти, потому что имею работоспособные комбинации на объеме значительно меньшем общего объема.

Из интересных симптомов пакет данных посылаемый по УДП не теряется, а задерживается до следующего приема (возможно отправки). Причем каждый 4 пакет. То есть я запускаю пинг 3 ответа приходят сразу, 4 приходить только вместе с 5 запросом. И так по кругу. Смотрю диагностику LwIP похоже пакет отдают, то есть скорее всего все застревает в драйвере езернет. Пока нет времени разбираться дальше, но я думаю неверно заправляется ДМА езернета. И мак не стартует перекладку до следующего пакета. Потом происходит еще одна заправка и 2 пакета уходят разом.

Как влияет раскладка в памяти? Думаю задержками при переключении басматрикса. Это изменяет время копирования пакетов данных, и конкуренцию с ДМА. Как то так...