STM32F407: Ethernet, HAL + Lwip Опции

[k000858]

Всем привет.

Кто изучал драйвер Ethernet'а, идущий с HAL библиотеками (вариант для FreeRTOS: ETHERNET прерывание релизит семафору, которая парсится в отдельной realtime задаче ОС)? Что будет при переполнении указанного количества приёмных буферов? Ошибка DMA обработается, но не будет ли DMA записывать данные дальше (портить память) или это исключено т.к. указывается в размер буферов в настройках DMA?

Имею следующую ситуацию: устройство с Ethernet в параллельной задаче (с меньшим приоритетом чем Ethernet) копирует данные (memcpy функцией) с внутренней FLASH контроллера. При шторме устройства Ethernet трафиком, в какой то раз данные копируются неправильно (временно нарушается адресация флэш - откуда копировать, но до конца процесса восстанавливается), в результате часть данных получается битыми.

Пока подозрения на ошибку в Ethernet драйверах либо LwIP стеке (v1.4.1).

То есть многократное срабатывание прерывания Ethernet + работа задачи по сохранению принятого по Ethernet пакету приводит к сбою работы memcpy

Нехватка памяти для RTOS и его задач контролируется соответствующими отладочными функция FreeRTOS

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

[SasaVitebsk]

Ну в принципе, здесь возможны 4 ошибки.
1. классическая, то есть глобальная переменная которая модифицируется в разных задачах или прерываниях при этом не предусмотрены средства контроля за этим.
2. неверная работа с указателем.
3. более сложная. Какой либо буфер выходит за пределы и портит указатель или переменную, а эта переменная уже начинает косячить..
4. стек задачи выходит за пределы.
Исходя из того, что порча происходит кратковременно, и потом ситуация восстанавливается, две последних маловероятны.
А портится один и тот же участок?

[Forger]

Если проектировать код похожим образом (на C++ без глобальных объектов), т.е. как я указывать в самом начале этой темы, то:

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

Этого никогда не произойдет, т. к. нет ни одного глобального объекта.

2. неверная работа с указателем.

Указатели не используется, лишь ссылки на объекты, и то очень многие с квалификатором const. Нужно изрядно постараться, чтобы навредить ))
Т.к. нет указателей, то приведение типов НИГДЕ не используется, а это - тоже очень частая причина неконтроллируемых сбоев.

3. более сложная. Какой либо буфер выходит за пределы и портит указатель или переменную, а эта переменная уже начинает косячить..

Самодельных буферов нет, есть давно отлаженные и вылизанные классы, которые реализуют работу буферов.

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

4. стек задачи выходит за пределы.

Контроль стека средствами RTOS с соотв. отладочной информацией. Это уже встроено во всех нормальных RTOS.

Эти все сущности однажды написаны и отлажены, поэтому нет никакой нужды в каждом проекте лечить подобный "анальный зуд"!
Впрочем, у каждого свои предпочтения


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