Всем привет.

Столкнулся с очень непонятной штукой. GCC под Stm32F767, оптимизация О2, никакой линкер оптимизации.

Разметка памяти:
RAM = 0x20000000, size 0x80000,
data и bss - лежит с начала RAM
stack poitner задается на 0x20080000

тут все работает прекрасно, если сделать
RAM = 0x20000000, size 0x80000,
data и bss - лежит с 0x20010000
stack poitner задается на 0x20010000

тоже все работает хорошо, но если сделать
RAM = 0x20010000, size 0x70000,
data и bss - лежит с 0x20010000 (с начала RAM)
stack poitner задается на 0x20010000

то никаких падений нет, но начинаются проблемы в обмене по езернету. Пакеты застревают, причем не теряются, они все есть, но почему то временами не отправляются. То есть приходит UDP запрос, ответа нет, а со следующим запросом приходит ответ на этот и на предыдущий.

При этом в разметке
RAM = 0x20000000, size 0x20000,
data и bss - лежит с начала RAM
stack poitner задается на 0x20080000
тоже есть проблемы, но значительно реже проявляющиеся.


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

Где-то там глюк. Угадать вот так сходу не получится, наверное. У меня, к примеру, был глюк с возрастом несколько лет, но на поверхность он выполз только тогда, когда я изменил настройки буферов.

там где? все еще хуже :

разметка
SP: 0x20010000
RAM:0x20010000
работает

SP: 0x20020000
RAM:0x20020000
каждый 4 пинг 1 секунда, прям регулярно, 3 нормальных, 1 в секунду...

SP: 0x20010000
RAM:0x20020000
задержки пинга

SP: 0x20080000
RAM:0x20020000
работает

SP: 0x20020000
RAM:0x2002С000
задержки пинга.

Какая то очень черная и очень магия...

Думаю ключом ко всему этому разные задержки при доступе к памяти и наличие кэшированных областей (см. рисунок).

Вангую, что когда такая чертовщина происходит, значит какой-то буфер заезжает на другой.
Иными словами - опасная ошибка, которая обусловлена вылезанием за пределы буферов и затиранием переменных. Был флаг "отправлять" например, а затерли его в ноль и видим что не отправляется. Как-то так.

кеши выключены
уезжал в РАМ всей программой никаких изменений, есть рабочие сочетания, есть нет. Области увеличивали уменьшал, стек поглядел глазами, не улетает он далеко... переполнения практически невероятны

Включил отладку lwip ответ на пинг равномерный, говорит интерфейс данные получил, то есть пакет застревает при отправке... Там есть кривое место при заправке дма езернета, вероятно там и косяк...

напишите плис, если разберетесь

Всё тривиально: какая-то переменная наезжает на другую и пакостит ей. Когда меняете размётку, то она наезжает или на пустое место или на некритичную переменную.
Вангую активное использование кучи и указателей в вашем проекте

Там, где Ethernet, там и DMA. Если сделано криво, DMA тоже может напакостить там, куда ему лезть не положено.

несостоятельная теория. Регионы большие я их двигал и вместе и отдельно, там общих данных меньше чем расстояния между регионами.
И не понятно почему если граница 0x10000 не наезжают, а если граница 0x20000 наезжают.

Куча расположена в конце памяти после bss, и стек она не может достать....



не объясняет изменение поведения от передвижки границы стек-память.

Объясняет или не объясняет. Прилетит вдруг волшебник в голубом вертолёте и покажет пальцем "вот тут бяка"? Ага, щас.
Чтобы понять, что работает не так, надо для начала знать, как оно должно работать. В деталях. Ну а потом внутрисхемный отладчик (хорошо, что он есть). Старая добрая отладка всё покажет. При должной сноровке, конечно.

Хех!... молодо-зелено-наивно... Любая операция адресации памяти по указателю в ARM может "достать" куда угодно в пределах 4гиг.
Что-то на что-то залезло внутри этих ваших больших регионов, и это "второе что-то" вдруг оказалось указателем, по которому потом выполнилась запись, куда угодно в пределах 4гиг. Повезло - попала в пустое место, не повезло - снесла нафиг что-нить полезное или не очень. А потом это полезное или не очень опять оказалось указателем (ну или каким-то индексом, по которому указатель вычисляется; или счётчиком цикла, от которого зависит размер записываемой области памяти; и ещё 100500 вариантов....). И пострадало ещё нечто полезно-бесполезное.
Строите Вы своё ПО, строите как здание из доминошек, а потом одну доминошку криво ставите - и всё насмарку

PS: А насчёт дин.памяти я был прав. И MPU наверняка даже не инициализирован. Вангую

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

Он даёт для любых задач. Просто по дефолту его всегда используете и баги, связанные со всякими промахами в памяти, находятся быстрее.
Неиспользование_MPU + использование_дин.памяти: всё это суть - ступени одной лестницы, ведущий в подвал отладочного мрака и багов с разрушениями памяти.
Можно на одну ступеньку спуститься, можно на две. Но я предпочитаю оставаться наверху

Очень часто приходится иметь дело с чужим говно-кодом, портируя его на другие архитектуры. Да, указатели, куча, стеки и объекты ООП - злые враги эмбидинга.
И то что здесь написал ув. jcxz - обычные вещи. Доходило до того, что проект, собранный в GCC, работал, а вот этот же проект в Keil - крашился на случайном месте.

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

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

Далее обрабатывать эксепшены и смотреть. Как-то так

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

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

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

У STM32F7 также, не?

Почти во всём соглашусь, кроме того, что чтение данных из секции кода необходимо: если посмотреть любой асм-листинг 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 пакета уходят разом.

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