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]

Насколько вы описали проблему, мне кажется, что проблема не в дровах и не в стеке. Ничего там не переполнится.
Судя по всему, у вас проблемы с синхронизацией между задачами. Либо второй вариант - где-то используется глобальная переменная, доступная на запись из нескольких задач. Туда ройте.

[k000858]

где-то используется глобальная переменная, доступная на запись из нескольких задач. Туда ройте.

такое есть. чем это чревато?

[Forger]

такое есть. чем это чревато?

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

[Aner]

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

С++ и его достоинства перед С, ... думаю не для STM c его осами и ограниченностью памяти. C++ даст только увеличение объема кода, подъест ресурсы которые и так ограничены. Хотя если задачка простенькая то пофигу на чем писать под STM хоть на С#.

Правильно pitt пишет в STM HAL в принципе не годится, у меня тоже свой. Все отлажено и работает в серийном изделии. А тот что выложен, у всех глючит и будет глючить по понятным причинам. Он для начинающих и лентяев.

И что ещё за шторм устройства Ethernet трафиком? Дураку, понятно что простых DoS атак STMы никак не потянут, даже старшие.