реклама на сайте
подробности

 
 
> LwIP STM32F4 перестает отвечать через время, если добавить свою задачу
khomin
сообщение Apr 16 2015, 07:40
Сообщение #1


Участник
*

Группа: Участник
Сообщений: 26
Регистрация: 14-06-14
Пользователь №: 81 950



Здравствуйте. Собрал плату на STM32f429, PHY Ksz8041, FreeRTOS. Проект в Coocox, собрал из примеров от ST. При работе только со "штатными" задачами из примеров, все работает нормально (1 час пингов держал), но если добавить несколько собственных задач, стек LwIP через минуту-две перестает нормально работать (или возможно проблема с MAC), при этом сохраняется активность на TX-0-1 на PHY от MAC, все задачи исправно работают (стек не переполняется), пакеты так же продолжают приходить (прерывание ETH_IRQHandler срабатывает). Задача "ethernetif_input" и функция "low_level_input" так же выполняются ... Попытки играть с приоритетами, выделением памяти (heap_4), и т.п. результатов за два дня не принесли sad.gif
Знаю про "косячный" драйвер от ST, самые "известные" на форумах баги подправил, но ничего не изменилось

Пытался запустить LWIP_DEBUG, но видимо во FreeRTOS retarget надо как-то буферизовать, происходит переполнение стека и оказываюсь в ловушке - vApplicationStackOverflowHook, пока не разобрался.

настройки FreeRTOS:
HTML
#define configUSE_PREEMPTION 1
#define configUSE_IDLE_HOOK 0
#define configUSE_TICK_HOOK 0
#define configCPU_CLOCK_HZ ( 150000000 )
#define configTICK_RATE_HZ ( ( portTickType ) 1000 )
#define configMAX_PRIORITIES ( ( unsigned portBASE_TYPE ) 15 )
#define configMINIMAL_STACK_SIZE ( ( unsigned short ) 128 )
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 20 * 1024 ) )

Прием:
CODE

void ethernetif_input( void * pvParameters )
{
struct pbuf *p;

for( ;; )
{
if (xSemaphoreTake( s_xSemaphore, emacBLOCK_TIME_WAITING_FOR_INPUT)==pdTRUE)
{
while ((p = low_level_input( s_pxNetIf )) != 0)
{
if (p != 0)
{
if (ERR_OK != s_pxNetIf->input( p, s_pxNetIf))
{
pbuf_free(p);
p=NULL;
}
}
}
}
ethernet_watchdog();
}
}

static void ethernet_watchdog(void)
{
/* When Rx Buffer unavailable flag is set: clear it and resume reception */
if ((ETH->DMASR & ETH_DMASR_RBUS) != (u32)RESET)
{
/* Clear RBUS ETHERNET DMA flag */
ETH->DMASR = ETH_DMASR_RBUS;

/* Resume DMA reception. The register doesn't care what you write to it. */
ETH->DMARPDR = 0;
}
}

Надеюсь на пинок в нужный вектор ...
Все перелопатил, останется только изучать низкий уровень Ethernet (DMA, склейка-разбор пакетов и т.д.), что безусловно полезно и интересно, но уровень для меня пока высоковат ...

В общем, товарищи, куда можно дальше копать?

Сообщение отредактировал khomin - Apr 16 2015, 12:10
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов (1 - 13)
scifi
сообщение Apr 16 2015, 07:48
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136



Цитата(khomin @ Apr 16 2015, 10:40) *
но если добавить несколько собственных задач, стек LwIP через минуту-две перестает нормально работать

А эти добавленные задачи случайно не вызывают функции lwip? Потому что нельзя. Функции lwip можно вызывать только из одного потока.
Go to the top of the page
 
+Quote Post
khomin
сообщение Apr 16 2015, 07:51
Сообщение #3


Участник
*

Группа: Участник
Сообщений: 26
Регистрация: 14-06-14
Пользователь №: 81 950



Цитата(scifi @ Apr 16 2015, 08:48) *
А эти добавленные задачи случайно не вызывают функции lwip? Потому что нельзя. Функции lwip можно вызывать только из одного потока.

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

Сообщение отредактировал khomin - Apr 16 2015, 08:53
Go to the top of the page
 
+Quote Post
Мусатов Констант...
сообщение Apr 17 2015, 07:44
Сообщение #4


Частый гость
**

Группа: Участник
Сообщений: 188
Регистрация: 10-10-06
Пользователь №: 21 172



А не пробовали добавить стека потокам, в т.ч. и LwIP?
Go to the top of the page
 
+Quote Post
khomin
сообщение Apr 17 2015, 19:03
Сообщение #5


Участник
*

Группа: Участник
Сообщений: 26
Регистрация: 14-06-14
Пользователь №: 81 950



Цитата(Мусатов Константин @ Apr 17 2015, 07:44) *
А не пробовали добавить стека потокам, в т.ч. и LwIP?
да, это было первым с чего начал

в общем, в процессе разбора, обнаружил ряд моментов:
При старте, все работает нормально, через примерно минуту происходит "утечка" памяти, после чего даже в исходящем пакете появляются ошибки (время жизни и т.п.), это видно в wireshark-е

выделенные розовым - уже битые пакеты.

далее включил #define SYS_LIGHTWEIGHT_PROT 1 , по идеи это защита критической области по освобождению памяти, разницы не заметил.

затем включил системную статистику стека,
#define LWIP_STATS 1
и структуре lwip_stats.memp.memp[1] появился счет ошибок

первое значение в .err по времени совпадает с появлением битых пакетов.
причем ошибки появляются только в массиве memp[1], в других значение max не превышает avail.
Далее, если так все оставить, счет прибавляется дальше, в конечном итоге работа полностью нарушается, происходит HardFault или просто все слетает ...
Буду разбираться дальше )
Go to the top of the page
 
+Quote Post
khomin
сообщение Apr 18 2015, 01:57
Сообщение #6


Участник
*

Группа: Участник
Сообщений: 26
Регистрация: 14-06-14
Пользователь №: 81 950



разобрался с отправкой, был косяк с очисткой pcb (protocol control block), каждый раз создавался новый, понятное дело через время залезал за пределы памяти.
сейчас так:
Код
    void MyTask(void *pvParametes)
{
    struct pbuf * pb;
    struct ip_addr addr;
    struct udp_pcb *pcb;
    addr.addr = 0x5A6EA8C0;
    ETH_BSP_Config();
    LwIP_Init();
    for(;;)
    {
        pcb = udp_new();
        udp_bind(pcb, IP_ADDR_ANY, 3003);
        udp_connect(pcb,&addr, 3003);
        pb = pbuf_alloc(PBUF_TRANSPORT, 512, PBUF_RAM);
        pb->len = 512;
        udp_sendto(pcb, pb, &addr, 3003);
        pbuf_free(pb);
        udp_disconnect(pcb);
        udp_remove(pcb);
        vTaskDelay(1000);
    }
}

Некоторое время работает, потом пинги пропадают ...
Наверно потому, что счет ошибок в:

идет с чудовищной скоростью ...

происходит это здесь:
Код
err_t sys_mbox_trypost(sys_mbox_t *mbox, void *msg)
{
err_t result;

   if ( xQueueSend( *mbox, &msg, 0 ) == pdPASS )
   {
      result = ERR_OK;
   }
   else {
      // could not post, queue must be full
      result = ERR_MEM;
#if SYS_STATS
      lwip_stats.sys.mbox.err++;
#endif /* SYS_STATS */    
   }
   return result;
}

т.е. через раз не удается записать msg в очередь ...
не понятно почему так происходит и должно ли так быть ... стека на задачи отвел в 10 раз больше чем в примерах

Сообщение отредактировал khomin - Apr 18 2015, 02:07
Go to the top of the page
 
+Quote Post
Golikov A.
сообщение Apr 18 2015, 05:16
Сообщение #7


Гуру
******

Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454



если слать данные и никто их не будет забирать, забьеться окно, и данные нельзя будет слать... по идее вы должны адекватно реагировать на не возможность отправки данных
Go to the top of the page
 
+Quote Post
khomin
сообщение Apr 18 2015, 15:42
Сообщение #8


Участник
*

Группа: Участник
Сообщений: 26
Регистрация: 14-06-14
Пользователь №: 81 950



Цитата(Golikov A. @ Apr 18 2015, 05:16) *
если слать данные и никто их не будет забирать, забьеться окно, и данные нельзя будет слать... по идее вы должны адекватно реагировать на не возможность отправки данных
Спасибо, данные просто выплевываются по UDP.
Добился отсутствия счета ошибок, теперь стек просто перестает работать через 5-10 минут отсылок и пинга )) Похоже это конец (
Go to the top of the page
 
+Quote Post
scifi
сообщение Apr 18 2015, 15:58
Сообщение #9


Гуру
******

Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136



Цитата(khomin @ Apr 18 2015, 18:42) *
теперь стек просто перестает работать через 5-10 минут отсылок и пинга )) Похоже это конец (

Нет, это начало! С такими вводными можно легко обнаружить и устранить. Вот если раз в месяц глючит, то это совсем печально...
Go to the top of the page
 
+Quote Post
khomin
сообщение Apr 19 2015, 07:23
Сообщение #10


Участник
*

Группа: Участник
Сообщений: 26
Регистрация: 14-06-14
Пользователь №: 81 950



Цитата(scifi @ Apr 18 2015, 15:58) *
Нет, это начало! С такими вводными можно легко обнаружить и устранить. Вот если раз в месяц глючит, то это совсем печально...

оказывается, через время прерывание от DMA Ethernet пропадают, при этом биты RXE-RXEI включены, не представляют где искать причину такого поведения ...
Go to the top of the page
 
+Quote Post
scifi
сообщение Apr 19 2015, 11:38
Сообщение #11


Гуру
******

Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136



Цитата(scifi @ Apr 18 2015, 18:58) *
С такими вводными можно легко обнаружить и устранить.

Ну, относительно легко, естественно.

Цитата(khomin @ Apr 19 2015, 10:23) *
оказывается, через время прерывание от DMA Ethernet пропадают, при этом биты RXE-RXEI включены, не представляют где искать причину такого поведения ...

Это надо на месте разбираться. У меня были глюки с lwip (весьма редкие, кстати). Стал разбираться внутрисхемным отладчиком - обнаружил невменяемое поведение кода, который нагенерил компилятор. Списал всё на это. Это Яр для Coldfire, если что, и глюки этого компилятора я уже до этого фиксировал. Первый раз, когда обнаружил, понижение уровня оптимизации с High до Medium вроде бы решало проблему. Теперь понизил до None - глюки наконец-то ушли (надеюсь, навсегда). Кстати, в какой-то момент перешёл на gcc для Coldfire, и там этих проблем ни разу не было.
Я не к тому, что в данном случае компилятор виноват. Просто надо иметь представление о работе всех частей системы. Если глюк воспроизводится каждые несколько минут - это счастье. А если раз в неделю - это мучение.
Go to the top of the page
 
+Quote Post
khomin
сообщение Apr 19 2015, 12:48
Сообщение #12


Участник
*

Группа: Участник
Сообщений: 26
Регистрация: 14-06-14
Пользователь №: 81 950



Цитата(scifi @ Apr 19 2015, 11:38) *
Ну, относительно легко, естественно.


Это надо на месте разбираться. У меня были глюки с lwip (весьма редкие, кстати). Стал разбираться внутрисхемным отладчиком - обнаружил невменяемое поведение кода, который нагенерил компилятор. Списал всё на это. Это Яр для Coldfire, если что, и глюки этого компилятора я уже до этого фиксировал. Первый раз, когда обнаружил, понижение уровня оптимизации с High до Medium вроде бы решало проблему. Теперь понизил до None - глюки наконец-то ушли (надеюсь, навсегда). Кстати, в какой-то момент перешёл на gcc для Coldfire, и там этих проблем ни разу не было.
Я не к тому, что в данном случае компилятор виноват. Просто надо иметь представление о работе всех частей системы. Если глюк воспроизводится каждые несколько минут - это счастье. А если раз в неделю - это мучение.

Думаю без понимания работы стека у меня ничего не получится. Понял, что легко проблему не решить, правда до этого перепробовал фрагменты коды драйвера из разных примеров, одни проблемы сменялись другими, надо разбираться. Вот уже неделю занимаюсь изучением, и дело понемногу продвигается )
По мере появления уже серьезных вопросов, буду отписываться здесь
Go to the top of the page
 
+Quote Post
Пришелец
сообщение Jun 19 2017, 04:22
Сообщение #13


Частый гость
**

Группа: Участник
Сообщений: 183
Регистрация: 28-01-05
Пользователь №: 2 272



Цитата(khomin @ Apr 16 2015, 11:40) *
Знаю про "косячный" драйвер от ST, самые "известные" на форумах баги подправил, но ничего не изменилось


Добрый день! А ссылочку на "известные баги" можно?

Занимаюсь с похожей проблемой.

И попутно вопрос: как сделать полную инициализацию стека (железа, кучи LWIP, всех контекстов...)?
Иными словами аналог RESET но только для LWIP.
Go to the top of the page
 
+Quote Post
zuuuuk
сообщение Jul 17 2017, 06:18
Сообщение #14


Частый гость
**

Группа: Участник
Сообщений: 188
Регистрация: 26-04-07
Пользователь №: 27 334




khomin, может заменить lwip на FNET?
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 21st July 2025 - 22:13
Рейтинг@Mail.ru


Страница сгенерированна за 0.01471 секунд с 7
ELECTRONIX ©2004-2016