Всем привет.

Столкнулся с очень непонятной штукой. 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 Данные - экспешн

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