[1891ВМ12Я 0]

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

[Arlleex 131]

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

Изменено 19 июля, 2018 пользователем Arlleex

[repstosw 18]

Смеетесь что ли.

 

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

 

У STM32F7 также, не?

Изменено 19 июля, 2018 пользователем repstosw

[jcxz 184]

MPU : настроить секцию 1 только для выполнения кода. Секция 2 - для RO данных. Секция 3 - R/W. Секция 4 - стек. Секция 5 - куча.

При попытке считать данные их секции кода - эксепшн

При попытке записать данные в RO Данные - экспешн

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

А в остальном - у меня в MPU тоже примерно так же настроены сегменты, за исключением кучи. А стек - он у меня часть R/W-сегмента, не выделяю его в отдельный регион.

Ещё можно с помощью MPU отлавливать несанкционированные доступы к каким-то переменным: обнаружили что кто-то портит переменную, а кто - не знаем: выделяем её в отдельный сегмент и через MPU открываем доступ к этому сегменту на запись только в тех местах, где по алгоритму это нужно. И когда кто-то левый полезет в неё писать - получим fault. Но вот для дин.памяти эта полезность сразу отпадает - только статически.

[Arlleex 131]

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

 

У STM32F7 также, не?

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

[jcxz 184]

У STM32F7 также, не?

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

Но полученный код будет неоптимальным. Через PC - гораздо удобнее.

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

[Arlleex 131]

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

[jcxz 184]

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

Хмммм.... не факт... У меня например много переменных объявлены с квалификатором __no_init. Собственно - все большие массивы с ним объявлены. Для ускорения старта ПО :rolleyes:

Эти области будут выглядеть как неиспользуемые. А раз ТС использует сторонний софт, то неизвестно как там объявлены переменные.

[Golikov 0]

Воу воу воу!! Парни остановитесь:)

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

 

По сути дела:

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

2. конфигурация стек до переменных - работает временами на каких-то значения границы работает, на каких-то нет.

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

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

 

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

 

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