Перейти к содержанию
    

Всем привет.

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

image.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Там есть кривое место при заправке дма езернета, вероятно там и косяк...

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

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

 

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...