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

k000858

Участник
 Профиль  Обзор контента

  • Постов

    322

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные k000858

  1. Опубликовано · Пожаловаться

    У меня такая же проблема. Есть ли решение?

    К сожалению, уже не помню, как решил данную проблему.

    Кажется, было связано с чтением регистра с датой: толи необходимо читать его после каждого чтения регистра времени (именно после него) толи что то такое.

     

    Ни на кого не надо капать. :)

     

     

    Забить на эти регистры, разрешить секундные прерывания и по ним инкрементировать счётчик в памяти.

    ага и дату самому считать и календарь весь

  2. Опубликовано · Изменено пользователем k000858 · Пожаловаться

    Приложение запрашивает IP адрес по названию хоста функцией getaddrinfo. По Ethernet интерфейсу все работает хорошо, однако по PPP (GPRS) ответов на запрос DNS нет.

    Может есть какие то ньюансы? LwIP версии 2.0

     

    Ложная тревога. сим-карта не имела доступа во внешнюю сеть. с другими симками все ок

  3. Опубликовано · Пожаловаться

    Отвечу последователям: для установки SSL-соединения (во всяком случае с сервером gmail.com) необходимы корректные шифро-наборы в ClientHello запросе. Для этого необходимо прописать нужные дефайны.

    Информации крайне мало и сами дефайны в библиотеке не очень то прокомментированы..

  4. Опубликовано · Пожаловаться

    Пытаюсь прикрутить mbedTLS (она же бывшая PolarSSL) для работы с smtp на примере gmail.com (465 порт).

    Пока безрезультатно

     

    Performing the SSL/TLS handshake...failed

    mbedtls_ssl_handshake returned -30592: SSL - A fatal alert message was received from our peer

     

    Ктонибудь уже проходил такой путь? С чем может быть связана ошибка при попытке установить соединение?

    Быть может нужны особые настройки в mbedtls_config ?

     

     

  5. Опубликовано · Пожаловаться

    И вообще, мне кажется, было бы логичнее отправлять ответы на запросы в тот интерфейс, в по какому они были получены. Иначе это уже какой то маршрутизатор. Может есть какая то настроечка для LwIP ?!

  6. Опубликовано · Пожаловаться

    Можно тупо влезть в код lwip и закомментировать соответствующую строку, если это не выведено наружу в виде настройки.

    это то да)

    но может есть более изящный способ, в смысле, может есть какая то настроечка) вдруг кто сталкивался с подобныи эффектом

  7. Опубликовано · Пожаловаться

    Не надо грязи.

    Вообще-то обычно вполне разумно устанавливать ppp интерфейсом по умолчанию. Если вам это не подходит, есть функция netif_set_default().

    В моем случае разумней дефолтным интерфейсом использовать Ethernet (что в коде и делается, однако после поднятия PPP - он переназначается дефолтным), потому как GPRS является резервным каналом.

    С помощью netif_set_default можно конечно снова переназначить Ethernet дефолтным. Просто мне не совсем понятно зачем PPP переназначается принудительно, да происходит это не сразу после поднятия PPP (во всяком случае после вызова колбэк-функции по его поднятию, поэтому не ясно когда стоит сново назначить дефолтным Ethernet)

  8. Опубликовано · Пожаловаться

    уж очень смахивает на дурдом в коде...

    мусор - не похож, 4 байта подряд...

    обнуляют обычно нулями...

    края на затирку вроде как не 7Bh...

     

    имхо = ищите ляпы в коде...

    (круглый)

    мда. похоже неудачный пример привел. ок

    на Eth интерфейсе 172.31.74.11 (маска 255.255.255.0), а пакет уходит на 172.31.68.231, при этом на GSM интерфейсе 172.16.0.31

    Ни тот, ни другой IP не входит в диапазон адреса получателя, соответственно LwIP использует дефолтный интерфейс.

     

    мусор в коде то у кого? у меня или у LwIP?

     

  10. Опубликовано · Пожаловаться

    кажется, разобрался. с помощью ip_route проверяются оба интерфейса на предмет предчастности к ip адресу доставки. Если адрес не подходит к интерфейсу, выбирается дефолтный интерфейс. Зачем то в LwIP после поднятия PPP он делается дефолтным. До его поднятия пакеты уходят куда надо, а после начинается такая вот фигня

  11. Опубликовано · Пожаловаться

    Есть устройство, на борту Ethernet и GSM модуль.

    Протоколы (в том числе и PPP для работы GPRS) обеспечивает стек LwIP. И есть одна странность:

     

    После поднятия PPP стек начинает отправлять данные по TCP соединению, поднятому по интерфейсу Eth, но в PPP протокол. Соответственно исходящие пакеты уходят не в Ethernet интерфейс а в GSM модуль. Как такое вообще возможно? Как пофиксить или хотя бы по-дебажить?

  12. Опубликовано · Пожаловаться

    Может быть кому то поможет. Нашлось решение проблемы, пока сам не допонял, чем именно помогло

     

    При отключении хардварного подсчета контрольной суммы, скорость работы интерфейса повысилась (что логично), а генерации пакетов снизилась.

    Снять эффект зависания интерфейса можно, например, искусственно замедлив скорость интерфейса (тоже самое происходит при работе хардварного подсчета срс), вставив задержку или лишнее отладочное сообщение в функции приёма eth-фрейма

     

    Так же пофиксить зависание удалось следующим способом: в функции приёма фрейма в месте 

      /* Set Own bit in Rx descriptors: gives the buffers back to DMA */
  for (i=0; i< EthHandle.RxFrameInfos.SegCount; i++)
  {  
    dmarxdesc->Status |= ETH_DMARXDESC_OWN;
    dmarxdesc = (ETH_DMADescTypeDef *)(dmarxdesc->Buffer2NextDescAddr);
  }

  /* Clear Segment_Count */
  EthHandle.RxFrameInfos.SegCount =0;

     

    сделать так:

      /* Set Own bit in Rx descriptors: gives the buffers back to DMA */
  FlagStatus next_owned    = RESET;    // флаг занятости следующего дескриптора
  for (i=0; i< EthHandle.RxFrameInfos.SegCount; i++)
  {  
    dmarxdesc->Status |= ETH_DMARXDESC_OWN;
    dmarxdesc = (ETH_DMADescTypeDef *)(dmarxdesc->Buffer2NextDescAddr);

    // MY: если после смены дескриптора на следующий он не свободен
    if((dmarxdesc->Status & ETH_DMARXDESC_OWN) == (uint32_t)RESET)
        next_owned    = SET;
  }

  /* Clear Segment_Count */
  if(next_owned == RESET)    // если следующий дескриптор не занят DMA
      EthHandle.RxFrameInfos.SegCount =0;

     

     

    Есть у кого то понимание, как это могло помочь?

  13. Опубликовано · Пожаловаться

    В теме слово lwIP, в сообщениях вывод статистики по lwIP, в ответе - FreeRTOSconfig.h

    Forger, Вы вопрос-то читали?

     

     

    Возвращаясь к нашим утечкам.

    Во-первых, мы про какую версию разговариваем? Глянул последнюю, 2.0.2 - там счётчики занятых-свободных объектов - mem_size_t, который тот же size_t, т.е. на ARM'ах явно 32-битный. Гипотеза "счётчик буфера входящих пакетов в один прекрасный момент стал меньше нуля" работает только на 16-битных счётчиках.

     

    Во-вторых, во всё той же версии есть опция проверки утечек памяти - место, которое должно быть свободным, заполняется паттерном, при выделении памяти этот паттерн проверяется. Тормозить будет, конечно, но так только баг быстрее вылезет :-)

    Версия 1.4.2. Тип данных счетчиков - u16_t (unsigned short).

     

    В каком случае могло так получиться, что счетчик стал отрицательным?

     

    Как включаются данные проверочки, быть может они есть и в 1.4.2 версии?

     

  14. Опубликовано · Пожаловаться

    да, все так: устраиваю шторм трафика по eth-интерфейсу, при этом срабатывает много-много прерываний. eth-интерфейс при этом виснет.

     

    не понимаю, почему стек выделяет больше указанного в настройках стека количества?

    MEM TCPIP_MSG_INPKT
avail: 8
used: 65530
max: 65535

  15. Опубликовано · Изменено пользователем IgorKossak
    [codebox] для длинного кода. [code]-для короткого!!!     · Пожаловаться

    Тестирую устройство на устойчивость от большого количества трафика по Ethernet. При этом в отладку вывожу статистику:

     

    MEM HEAP
avail: 10240
used: 0
max: 6560
err: 0

MEM RAW_PCB
avail: 4
used: 1
max: 1
err: 0

MEM UDP_PCB
avail: 6
used: 4
max: 4
err: 0

MEM TCP_PCB
avail: 10
used: 10
max: 10
err: 0

MEM TCP_PCB_LISTEN
avail: 6
used: 3
max: 3
err: 0

MEM TCP_SEG
avail: 12
used: 0
max: 5
err: 0

MEM NETBUF
avail: 2
used: 0
max: 0
err: 0

MEM NETCONN
avail: 4
used: 2
max: 2
err: 0

MEM TCPIP_MSG_API
avail: 8
used: 0
max: 0
err: 0

MEM TCPIP_MSG_INPKT
avail: 8
used: 65530
max: 65535
err: 0

MEM SYS_TIMEOUT
avail: 10
used: 4
max: 4
err: 0

MEM SNMP_ROOTNODE
avail: 30
used: 21
max: 21
err: 0

MEM SNMP_NODE
avail: 50
used: 30
max: 30
err: 0

MEM SNMP_VARBIND
avail: 10
used: 0
max: 0
err: 0

MEM SNMP_VALUE
avail: 8
used: 0
max: 0
err: 0

MEM PBUF_REF/ROM
avail: 10
used: 0
max: 2
err: 0

MEM PBUF_POOL
avail: 10
used: 11
max: 15
err: 50124

SYS
sem.used:  3
sem.max:   3
sem.err:   0
mutex.used: 0
mutex.max:  0
mutex.err:  0
mbox.used:  3
mbox.max:   3
mbox.err:   878

     

    Есть некоторые вопросы по этой самой статистике:

    1) в каких случаях растет счетчик mbox.err: 878

    2) как может быть использовано больше пулов чем доступно?

     

    MEM PBUF_POOL
avail: 10
used: 11
max: 15

     

    MEM TCPIP_MSG_INPKT
avail: 8
used: 65530
max: 65535

  16. Опубликовано · Пожаловаться

    Я бы эту проблему решал поэтапно - для начала полностью вылечить пункт 1.

    Для этого вырезал бы из проги все, что можно, кроме драйвера Eth, или даже проще - создал бы пустой отладочный проект, где отлаживается именно этот драйвер Eth (по возможности, испытать его на все случаи жизни).

    Ниже пункта 1 описал, что изменение кода приводит к снятию эффекта

    Причем даже отключение несвязанных между собой программных блоков приводит к снятию эффекта

    Если оставить один Eth, подозреваю висяка не будет

  17. Опубликовано · Пожаловаться

    пока удалось выяснить вот что:

    1) при шторме UDP трафика на не открытый порт происходит сбой работы Ethernet интерфейса (дело не в стеке TCP), перестает срабатывать Eth прерывание. устройство перестает обрабатывать входящие запросы (пинг, арп и тд)

    2) при этом устройство уходит в HardFault_Handler, но благодаря наличию RTOS, зависнув в вечном цикле обработчика HardFault_Handler, продолжает генерировать исходящий трафик на eth интерфейсе

    3) при попытке вставать отладочный код в HardFault_Handler приводит к снятию эффекта зависания Eth интерфейса. к аналогичному эффекту приводит и хаотичное отключение различных программных блоков в ПО устройства

     

    При этом на события нехватки стека памяти для задач ОС и кучи самой ОС стоят отладочные заглушки, памяти судя по всему хватает.

  18. Опубликовано · Пожаловаться

    Очень рекомендую подключить (для сборки DEBUG) вот такую штуку.

    Мне она уже неоднократно помогала быстро находить подобные корявые баги. Жалею, что раньше не применял, иначе съэкономил бы вагон времени и нервов ))

    Подключается быстро, т. к. там уже есть порт, заточенный под freertos.

    к сожалению J-Link'а не имею, в моем распоряжении только ST-Link v2

     

  19. Опубликовано · Пожаловаться

    В проект включены LwIP (1.4.0) и FreeRTOS. Ethernet интерфейс работает на прерывании, которое освобождает семафору. Задача по освобождению семафоры забирается пакеты.

     

    Версия проекта со включенной ETH_CHECKSUM_BY_HARDWARE (в драйвере Ethernet и LwIP стеке) хорошо выдерживает тест на шторм трафика, ничего не виснет

    Версия проекта с софтовым расчетом контрольной суммы при тесте на шторм трафика виснет: Ethernet прерывание перестает выстреливать при получении пакетов, LwIP перестает получать пакеты. необходима именно эта версия проекта.

     

    Кто нибудь сталкивался с таким эффектом? есть идеи как можно подебажить проблему?

  21. Опубликовано · Пожаловаться

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

    Отправка накопленных данных осуществляется в tcp_poll колбеке. К сожалению колбэк вызывается слишком редко (500мс) и уменьшит этот параметр не удается.

     

    Пытался реализовать это с помощью NETCONN API

     

    conn = netconn_new(NETCONN_TCP);
err = netconn_bind(conn, NULL, 7);
netconn_listen(conn);
while (1) 
{
    accept_err = netconn_accept(conn, &newconn);
    if (accept_err == ERR_OK)    // дождался соединения
    {
          netconn_recv(newconn, &buf);  // принимаю данные
    }
}

     

    в другом месте (отдельной задачей ОС) пытаюсь отправить данные netconn_write(newconn, data, len, NETCONN_COPY); но ничего не получаю

     

    как заставить такую контструкцию работать?

  23. Опубликовано · Пожаловаться

    Я был осенью на ARM event от TI

    там как раз был тренинг по contiki+6LowPAN - запускали сеть на sub 1hz (cc1310)...

    глючит все и тормозит!

    при чем именно все!

    Особенно PCшная часть. (включая маршрутизатор)

    все ясно: у них напрочь отсутствует решение коллизий, оттуда потери пакетов = тормоза.

  24. Опубликовано · Пожаловаться

    Есть у кого нибудь опыт использования этой связки для передачи данных по радио-интерфейсу?

    поделитесь опытом: с какими сложностями столкнулись? на каком железе использовали?

     

    Больше всего волнует вопрос, приживется ли это ПО в проекте с freeRTOS?

  25. Опубликовано · Пожаловаться

    И все это ради того, чтобы не дать указание компилятору-линкеру разместить переменную в правильном месте. :laughing:

    лично для меня это нужно, что бы обратиться к переменной, не заморачиваясь, куда же ее разместил линкер-компилятор

     

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