Jump to content

    

Stm32f7 stack pointer

Всем привет.

 

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

тоже есть проблемы, но значительно реже проявляющиеся.

 

 

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

 

Share this post


Link to post
Share on other sites
Есть у кого какие-то идеи как может разметка памяти так драматически влиять?

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

Share this post


Link to post
Share on other sites

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

 

разметка

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

задержки пинга.

 

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

Share this post


Link to post
Share on other sites
Какая то очень черная и очень магия...

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

image.png

Share this post


Link to post
Share on other sites
Какая то очень черная и очень магия...

Вангую, что когда такая чертовщина происходит, значит какой-то буфер заезжает на другой.

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

Share this post


Link to post
Share on other sites

кеши выключены

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

 

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

Share this post


Link to post
Share on other sites
Там есть кривое место при заправке дма езернета, вероятно там и косяк...

 

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

 

Share this post


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

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

Вангую активное использование кучи и указателей в вашем проекте :laughing:

Share this post


Link to post
Share on other sites
Всё тривиально: какая-то переменная наезжает на другую и пакостит ей. Когда меняете размётку, то она наезжает или на пустое место или на некритичную переменную.

Вангую активное использование кучи и указателей в вашем проекте :laughing:

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

Share this post


Link to post
Share on other sites
Всё тривиально: какая-то переменная наезжает на другую и пакостит ей. Когда меняете размётку, то она наезжает или на пустое место или на некритичную переменную.

Вангую активное использование кучи и указателей в вашем проекте :laughing:

 

несостоятельная теория. Регионы большие я их двигал и вместе и отдельно, там общих данных меньше чем расстояния между регионами.

И не понятно почему если граница 0x10000 не наезжают, а если граница 0x20000 наезжают.

 

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

 

 

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

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

Share this post


Link to post
Share on other sites

Объясняет или не объясняет. Прилетит вдруг волшебник в голубом вертолёте и покажет пальцем "вот тут бяка"? Ага, щас.

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

Share this post


Link to post
Share on other sites
Куча расположена в конце памяти после bss, и стек она не может достать....

Хех!... молодо-зелено-наивно... Любая операция адресации памяти по указателю в ARM может "достать" куда угодно в пределах 4гиг.

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

Строите Вы своё ПО, строите как здание из доминошек, а потом одну доминошку криво ставите - и всё насмарку ;)

 

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

Share this post


Link to post
Share on other sites

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

Share this post


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

Он даёт для любых задач. Просто по дефолту его всегда используете и баги, связанные со всякими промахами в памяти, находятся быстрее.

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

Можно на одну ступеньку спуститься, можно на две. Но я предпочитаю оставаться наверху :laughing:

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this