svedach 0 20 мая, 2018 Опубликовано 20 мая, 2018 · Жалоба Проект на Zynq. Есть интенсивная отправка UDP пакетов, начало по внешней команде. После начала отправки, через 2-3 секунды, процессор уходит в DataAbortHandler, уходит на выполнении udp_send(pcbServiceSnd, SrvcMsg_pBuff);. Код отправки (фрагмент, т.к. код с xemacif_input(&NetItfs) и т.д. в другой части): case MSG_SLOT_TX_WAIT: //Укладываем в сообщение уникальный идентификатор *(uint16_t*)&SrvcMsgQueue[Idx].Message.RawData[1] = SrvcMsgCounter; SrvcMsg_pBuff = pbuf_alloc(PBUF_RAW, sizeof(SrvcMsgHeader_Type) + SrvcMsgQueue[Idx].Message.PayloadLen, PBUF_RAM); if (SrvcMsg_pBuff != NULL) { memcpy(SrvcMsg_pBuff->payload, SrvcMsgQueue[Idx].Message.RawData, sizeof(SrvcMsgHeader_Type) + SrvcMsgQueue[Idx].Message.PayloadLen); udp_send(pcbServiceSnd, SrvcMsg_pBuff); pbuf_free(SrvcMsg_pBuff); SrvcMsgCounter++; SrvcMsgQueue[Idx].Busy = (SrvcMsgQueue[Idx].Message.Header.OpFlags & OP_FLAGS_CONFIRM_BIT) ? MSG_SLOT_NOT_CONFIRMED : MSG_SLOT_FREE; SrvcMsgQueue[Idx].ReSendTimeout = MSG_RESEND_TIMEOUT; SrvcMsgQueue[Idx].ReSendCounter = 0; } break; Грешил на нехватку кучи, пробовал задавать в линкере 64МБайта и для LWIP 32МБайта, на время успешной отправки это не повлияло (в пределах погрешности...). Настройки LWIP (в виде картинки, так наверное нагляднее...): Может кто сталкивался, буду рад любой информации... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
svedach 0 21 мая, 2018 Опубликовано 21 мая, 2018 · Жалоба Проблема рушилась костылем в виде usleep(20) после pbuf_free(SrvcMsg_pBuff). Это немного снизило поток (до 200 МБит/с), но проработало всю ночь... Рабочее предположение пока - непонятки с кучей. Только почему она портится, ведь usleep(20) - это простой цикл, система BareMetal... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xvr 12 21 мая, 2018 Опубликовано 21 мая, 2018 · Жалоба А первым параметром в pbuf_alloc не должен быть PBUF_TRANSPORT ? http://lwip.nongnu.org/2_0_x/group__pbuf.h...75b5a8619ac1ebf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
svedach 0 21 мая, 2018 Опубликовано 21 мая, 2018 · Жалоба А первым параметром в pbuf_alloc не должен быть PBUF_TRANSPORT ? http://lwip.nongnu.org/2_0_x/group__pbuf.h...75b5a8619ac1ebf Да, действительно это так! Проглядел... Параметр PBUF_TRANSPORT ситуацию улучшил, но не решил... Скорость отправки стала более 300 МБит/с, но через секунд 5 вылетает на выделении памяти. Все-таки проблема в куче, вот только как ее мониторить? Я смог бы снизить поток, зная, что куча заканчивается... Может кто знает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться