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]

В зависимости от текста... Как правило непредсказуемыми последствиями...
Здесь давече была тема про атомарный доступ к таким переменным. Не хочу вступать в полемику, так как в программировании, одну и туже задачу можно десятком способов решить...
Я обычно решаю так:
Есть задачи А, Б, С. Например задача А выставляет какой то запрос флагом фА. Задачи Б и С могут его прочитать, но не сбросить! Задача Б по флагу фА подтверждает запрос выставив флаг фБ. По флагу фБ задача А сбрасывает флаг фА.
То есть Одна задача только читает, вторая только пишет. Найболее яркий пример реализации в протоколе centronix.
Если всё же не избежать взаимных колизий, то использую защищённую секцию, либо средства самой ОС. Ну в зависимости, от частоты события...
===
Ну приведу классическую работу с кольцевым буфером:
1. При поступлении символа либо пакета, в прерывании двигается хвост очереди tail.
2. В задаче, после обработки пакета - двигается голова очереди head.
Вроде всё класс. Но вам требуется определить размер доступных данных... Ну типа так..
len = tail - head;
if(len <0) len += sizebuf;
....
И здесь видно, что во время операции len = tail - head, значение tail может измениться в прерывании (например пришёл пакет, и указатель сдвинулся по кольцу). В результате вы можете получить значение совершенно неверное. Дабы это предотвратить, вы должны например запретить прерывание на эту операцию. Либо приостановить планировщик, если речь не о прерывании, а о задачах.

Для FreeRTOS:
taskENTER_CRITICAL() — вход в критическую секцию
taskEXIT_CRITICAL() — выход из критической секции
vTaskSuspendAll() - Приостановка планировщика
xTaskResumeAll() - возобновления работы планировщика

Если приложение написано верно, то таких мест будет крайне мало... У меня их единицы. Но всё же они есть.