Перейти к содержанию
    

оптимизация отключена. Воткнул проверку на валидность адреса в функции 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: разбираюсь дальше

post-95184-1505129077_thumb.jpg

 

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, поглядим

Изменено пользователем Hold

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Многократные передачи мегабайтной картинки, виснет именно 8720, как на собственной плате, так и на примере от starterkit.

 

Это только на одной плате так или везде? Попробуйте не читать\записывать в регистры 8720 вообще ничего, и посмотрите.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

И все таки, кривой драйвер ethernetif.c. Взял драйвер отсюда , все завелось.

Проверил на 3-х клиентах FTP, http-страничка и 3 пинга одновременно, все работает. Погоняю еще по времени. Зависаний LAN8720 пока не замечено.

post-95184-1505203293_thumb.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В 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 тоже не доступна.

Есть ли возможность перезалить примеры?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...