Hold 0 11 сентября, 2017 Опубликовано 11 сентября, 2017 (изменено) · Жалоба оптимизация отключена. Воткнул проверку на валидность адреса в функции prvCopyDataFromQueue static void prvCopyDataFromQueue( Queue_t * const pxQueue, void * const pvBuffer ) { if( pxQueue->uxItemSize != ( UBaseType_t ) 0 ) { pxQueue->u.pcReadFrom += pxQueue->uxItemSize; if( pxQueue->u.pcReadFrom >= pxQueue->pcTail ) /*lint !e946 MISRA exception justified as use of the relational operator is the cleanest solutions. */ { pxQueue->u.pcReadFrom = pxQueue->pcHead; } else { mtCOVERAGE_TEST_MARKER(); } if ( ( (uint32_t)pvBuffer < 0x20000000 || (uint32_t)pvBuffer > 0x2002FFFF ) || ( (uint32_t)(pxQueue->u.pcReadFrom) < 0x20000000 || (uint32_t)(pxQueue->u.pcReadFrom) > 0x2002FFFF ) ) { printf("\tIncorrect addr in prvCopyDataFromQueue\r\n"); } ( void ) memcpy( ( void * ) pvBuffer, ( void * ) pxQueue->u.pcReadFrom, ( size_t ) pxQueue->uxItemSize ); } } Запустил проверку, жду когда сработает. UPD: разбираюсь дальше UPD: Разбираюсь с функцией sys_arch_mbox_fetch, которую я взял из примера ST. Есть подозрение, что в ней бага, причем жирная. /*-----------------------------------------------------------------------------------*/ /* Blocks the thread until a message arrives in the mailbox, but does not block the thread longer than "timeout" milliseconds (similar to the sys_arch_sem_wait() function). The "msg" argument is a result parameter that is set by the function (i.e., by doing "*msg = ptr"). The "msg" parameter maybe NULL to indicate that the message should be dropped. The return values are the same as for the sys_arch_sem_wait() function: Number of milliseconds spent waiting or SYS_ARCH_TIMEOUT if there was a timeout. Note that a function with a similar name, sys_mbox_fetch(), is implemented by lwIP. */ u32_t sys_arch_mbox_fetch(sys_mbox_t *mbox, void **msg, u32_t timeout) { void *dummyptr; portTickType StartTime, EndTime, Elapsed; StartTime = xTaskGetTickCount(); if ( msg == NULL ) { msg = &dummyptr; } if ( timeout != 0 ) { if ( pdTRUE == xQueueReceive( *mbox, &(*msg), timeout / portTICK_RATE_MS ) ) { EndTime = xTaskGetTickCount(); Elapsed = (EndTime - StartTime) * portTICK_RATE_MS; return ( Elapsed ); } else // timed out blocking for message { *msg = NULL; return SYS_ARCH_TIMEOUT; } } else // block forever for a message. { while( pdTRUE != xQueueReceive( *mbox, &(*msg), portMAX_DELAY ) ){} // time is arbitrary EndTime = xTaskGetTickCount(); Elapsed = (EndTime - StartTime) * portTICK_RATE_MS; return ( Elapsed ); // return time blocked TODO test } } Суть в следующем - если нужно дропнуть пакет, то они вместо адреса получателя пакета ставят указатель заглушку и читают в него. В указатель типа void. Возможно проблема в том, что он не указывает ни на что, и по факту можем птытаться записать хрен пойми во что. Попробую выловить. UPD3: нет, там все верно, там же на входе указатель на указатель. Ищу дальше. UPD4: Еще одна бага в sys_arch.c. При создании mailbox-ов, незавивимо от указываемого размера, создавались они размеров всего-лишь 6 элементов. *mbox = xQueueCreate( archMESG_QUEUE_LENGTH, sizeof( void * ) ); Дополнительно включил SYS_LIGHTWEIGHT_PROT, поглядим Изменено 11 сентября, 2017 пользователем Hold Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 11 сентября, 2017 Опубликовано 11 сентября, 2017 · Жалоба Многократные передачи мегабайтной картинки, виснет именно 8720, как на собственной плате, так и на примере от starterkit. Это только на одной плате так или везде? Попробуйте не читать\записывать в регистры 8720 вообще ничего, и посмотрите. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Hold 0 12 сентября, 2017 Опубликовано 12 сентября, 2017 · Жалоба И все таки, кривой драйвер ethernetif.c. Взял драйвер отсюда , все завелось. Проверил на 3-х клиентах FTP, http-страничка и 3 пинга одновременно, все работает. Погоняю еще по времени. Зависаний LAN8720 пока не замечено. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alex_dobrikov 0 17 декабря, 2019 Опубликовано 17 декабря, 2019 · Жалоба В 08.09.2017 в 08:56, Hold сказал: Итак, что было сделано с момента первого поста. Решил еще раз переписать всё, используя последнее обновление "STSW-STM32070 LwIP TCP/IP stack demonstration for STM32F4x7 microcontrollers (AN3966)". Еще раз проверил все адреса PHY, убедился что регистры корректно читаются/пишутся, Auto-negotiation даёт нужные параметры. ethernetif.c взял оттуда же, к слову они внесли туда значительные изменения( правильное освобождение pbuf, проверка ошибок RBU и еще по мелочи). Еще раз пересобрал проект, отключил все остальные программные модули, оставил только дебажный usart, SDRAM 64 мбайта и ethernet. К тому же в их реализации sys_arch.c был критичный баг, при использовании мьютексов, они неверно передавали указатель (точнее передавали указатель на указатель, в итоге FreeRTOS вываливалась в assert). В итоге, всё завелось. Уж не знаю где конкретно был косяк, но проще было собрать всё заново, чем искать, к тому же прошлые исходники были далеко не свежие. Сейчас аплоад на виртуальный диск FTP составляет 8-9 МБайт/с (без физической записи на диск, файл просто создается и закрывается в конце передачи). Гоняю, проверяю на зависоны, но пока-что всё хорошо, залил 2 ТБ суммарно, ничего не зависло и не отвалилось. Как проверить на подвисание phy пока не могу придумать, но в принципе у меня отслеживается линк, низко-приоритетным таском, можно по таймауту функции ETH_ReadPHYRegister() отловить, попробую. Прикладываю все драйвера для LAN8720A + сам lwIP 2.0.2 (исправленным багом hostname-а DHCP) c портом для STM32 (исправлен косяк с взятием мьютекса). В lwIP 2.0.2 по сравнению с 1.4.1 внесли довольно много изменений, поменяли часть структур (к примеру, dhcp теперь отдельная структура, а не чать netif), инициазация заточена именно по 2.0.2. Инициализация всей сети: ETH_BSP_Config(); LwIP_Init(); #ifdef USE_DHCP xTaskCreate(LwIP_DHCP_task, (char const*) "DHCP", configMINIMAL_STACK_SIZE * 2, NULL,DHCP_TASK_PRIO, NULL); #endif http_server_netconn_init(); // тестовая страничка в каком-нибудь таске. lwIP_2.0.2_fix.zip STM32F4x7_ETH_Driver_LAN8720A_lwIP_2.0.2.zip Здравствуйте! В данный момент ковыряюсь с проблемой memp_malloc: out of memory in pool PBUF_POOL. Проблема аналогичная - на STM32F217+KSZ8721 работает FreeRTOS (v8.0.1)+LwIP (1.4.0) (TCP/IP(socket),DHCP,UDP), спустя 2-3 часа работы в сети вываливается в memp_malloc (однако связь с прибором и поиск устройства в сети (по UDP) продолжает работать). Не смог скачать для изучения Ваши примеры (ссылки не активны) и ссылка на "корректный" ethernetif.c тоже не доступна. Есть ли возможность перезалить примеры? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться