Jump to content

    
Sign in to follow this  
kan35

lwIP (PPP) проблема

Recommended Posts

Модем Quectel M72, FreeRTOS 7 на sm32.

Работаем через PPP протокол и сверху TCP/IP по виалоновскому протоколу.

При приемо-передаче небольших пакетов данных проблем не возникает. Но при передаче на устройство большого массива байтов прием сбоит. Стек принимает ровно 9 IP пакетов (по ~1400байт каждый), после чего netconn_recv перестает принимать пакеты (потому что модем их перестает выдавать). Память нигде не утекает, это контроллируется. На нехватку памяти не похоже. FreeRTOS находится в IDLE >92% времени. Такое ощущение что проблема на уровне IP, перешевелил все настроки, которые понимал и не понимал, но бесполезно - 9 пакетов и хоть умри. Тип и содержание файла не влияет на результат.

Из зависания выходит если начать новую передачу на устройство. При этом в лог сыпется такое:

pppInProc[0]: got 1355 bytes
[b]pppInProc[0]: Dropping bad fcs 0x63B8 proto=0x0021[/b]
pppDrop: pbuf len=500
pppInProc[0]: got 1405 bytes
pppInput[0]: ip in pbuf len=492
pppifOutput[0]: proto=0x0021
pppInProc[0]: got 1405 bytes
pppInput[0]: ip in pbuf len=492
pppifOutput[0]: proto=0x0021

Тут видно, что начинается передача которая подвисла, но срывается FCS (но потом восстанавливается) и в конечном итоге, когда массив допередастся, система вновь приходит в штатное состояние.

 

Подскажите где могла собака порыться? Чую что какие то настройки надо подправить в lwipopt.h, но допетрить не могу. Спасибо!!!!!

Edited by kan35

Share this post


Link to post
Share on other sites

Заменил модем на SIM300DZ - результат на 100% тот же самый

Скачал заново версию стека 1.3.2, полностью обновил все файлы стека в своем проекте, опять безрезультатно.

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

 

Файл с пользовательскими настройками lwipopt.h прилагаю, прошу поделиться аналогичным файлом, если у вас описанная проблема не наблюдается.

 

А вот так выглядят функции приема/передачи по последовательному каналу в sio.c

 

volatile unsigned char stop = 0;
extern xQueueHandle queue_gprs_bytes;

u32_t sio_read(sio_fd_t fd, u8_t *data, u32_t len)
{ 
    unsigned long i = 0;
    while (xQueueReceive(queue_gprs_bytes, &data[i], 0) == pdTRUE )
    {
        i++;
        if (stop || (i == len) )
        {
            stop = 0;
            return i;
        }
    }
    return i;
}

u32_t sio_write(sio_fd_t fd, u8_t *data, u32_t len)
{
    for (unsigned long i = 0; i<len; i++)
    {
        while (    !USART_GetFlagStatus(USART_MODEM, USART_FLAG_TXE) );
        USART_SendData(USART_MODEM, data[i]);
    }
    return len;
}

void sio_read_abort(sio_fd_t fd)
{
    stop = 1;
}

Edited by kan35

Share this post


Link to post
Share on other sites

Какой менеджер памяти в freertos используете ? сколько памяти под кучу ?

Сколько памяти выделено для стека ?

Попробуйте включить полное протоколирывание, а так непонятно что не так.

Share this post


Link to post
Share on other sites
Какой менеджер памяти в freertos используете ? сколько памяти под кучу ?

Сколько памяти выделено для стека ?

Попробуйте включить полное протоколирывание, а так непонятно что не так.

Использую heap_2, и в lwIP используется только куча freeRTOS, памяти выделил около 50кБ, стеку хватает, так как в ином случае последний бы ругался в лог и к тому же принимая в цикле данные pbuf = netconn_recv вижу, что используются одни и те же сегменты pbuf - и паять не утекает. И еще - увеличение или уменьшение кучи не приводит ник чему - 9 пакетов и стопорится. Хотя изредка 1 на 100 случаев принимается от 10 до 13 пакетов.

Подключался в разных местах - размеры пакетов у разных операторов в разных точках немного отличались - от 1260 до 1460 байт, но результат один - 9 пакетов:-)

Модемы тоже менял - без изменений!

 

    struct netbuf * in_buf;
    unsigned short k = 2;
    while (bytesleft)
    {
        if (in_buf = netconn_recv(conn))
        {
            // успешно приняли что то
            char * incoming_data;
            unsigned long buflen = netbuf_len(in_buf);

            if (incoming_data = (char *)pvPortMalloc(buflen))
            {
                {
                    char * data; u16_t len;
                    netbuf_data(in_buf, (void **)&data, &len);
                    printf_diagn("%d: %lX->%lX (%d:%d)\r\n\r\n", k, data, incoming_data, buflen, bytesleft-buflen );
                }
                netbuf_copy(in_buf, incoming_data, buflen);
                //file_write(file, buflen, (unsigned char *)incoming_data);
                vPortFree(incoming_data);
            }
            bytesleft -= buflen;
            netbuf_delete(in_buf);
            k++;
        }
        else
            bytesleft = 0;
    }

lwipopts.h

sio.c

 

Порт sys_arch.c lwIP для FreeRTOS взял из примера ST для STM32F2xx.

Больше ничего в стеке я не менял! И потому хотел поинтересоваться - получалось ли у вас принимать такие передачи в стеке lwIP и в частности через их PPP?

 

Вот логи:

TCP log: TCP+.txt

IP log: IP.TXT

PPP log: PPP.txt

Сняты с разных подключений, но все остановлены на месте где модем перестает выдавать очередной пакет - всегда после 9 пакета.

Edited by kan35

Share this post


Link to post
Share on other sites
CTS-RTS модема обрабатываются корректно ?

Попробуйте посмотреть не влетает ли ртос в функцию FREERTOS:vApplicationMallocFailedHook.

У меня между модемом и контроллером только RX и TX. У модема эти сигналы висят в воздухе. В режиме связи конкретный модем QUECTEL L72 использует XON XOFF и стек это поддерживает.

Share this post


Link to post
Share on other sites

Где в стеке поддержка XON XOFF, в lwip1.3.2 не нашел ?

Работу XON XOFF проверяли ?

Смотреть пробовали когда выдает pppInProc[0]: Dropping bad fcs 0x63B8 proto=0x0021

что выкинул модем и что действительно было принято контролером.

Попробуйте посмотреть не влетает ли ртос в функцию FREERTOS:vApplicationMallocFailedHook.

Если IP_REASSEMBLY=1 ?

если убрать (char *)pvPortMalloc(buflen) будет ли затык ?

 

Share this post


Link to post
Share on other sites
Где в стеке поддержка XON XOFF, в lwip1.3.2 не нашел ?

Работу XON XOFF проверяли ?

cpl, спасибо большое тебе

Оказалось следующее: модем действительно работал через аппаратные CTS и RTS, хотя при согласовании параметров выдавал поддержку XON/XOFF:

...
ppp_send_config[0]: outACCM=0 0 A 0
ppp_recv_config[0]: inACCM=0 0 A 0
link_established: 0
upap_lowerup: 0 s=0
IPCP: lowerup state 0 (LS_INITIAL) -> 2 (LS_CLOSED)
upap_authwithpeer: 0 user=beeline password=beeline s=1
...

Возможно, я не правильно это понимаю (0 0 A 0)?

 

Достаточно было подать AT команду

AT+IFC=1,1 и XON XOFF действительно заработали, а по поддержке стеком, сейчас изучаю, думал что поддерживает...

Edited by kan35

Share this post


Link to post
Share on other sites

Рано обрадовался. Началось совершенно непонятное.

IFC=1,1 конечно было не лишним, но как оказалось XON и XOFF - 0x11 и 0x13 в пакетах так и не начали участвовать, это значит что RX буферы модема вполне все вмещают. Мои dropped были из за того, что в контроллере переполнялся messagebox, я увеличил его и все стало гладко. Пришлось вручную добавить поддержку XON XOFF в свой драйвер, это оказалось не сложным делом.

Однако, образовалось новое ограничение - 35 пакетов и остановка.

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

вот моя инициализация модема:

ATV1

AT+CLIP=1

AT+CRC=0

AT+IFC=1,1

AT+CGDCONT=1,"IP","internet.beeline.ru"

ATD*99***1#\r

... и поехал PPP

 

на что думать?

Share this post


Link to post
Share on other sites

XON-XOFF Не применял, пока обхожусь CTS-RTS.

Стек об XON-XOFF нечего не знает, это больще относится к SIO.

 

Однако, образовалось новое ограничение - 35 пакетов и остановка.

Что значит остановка ?

 

 

Share this post


Link to post
Share on other sites
XON-XOFF Не применял, пока обхожусь CTS-RTS.

Стек об XON-XOFF нечего не знает, это больще относится к SIO.

 

 

Что значит остановка ?

Я в SIO и добавил отслеживание XON XOFF. Попробую аппаратно прокинуть еще и RTS, CTS.

 

Остановка это значит, что контроллер отправил подтверждение приема очередного пакета (№35) ~1400байт и все, модем не выдает следующий пакет. Как только по таймауту выходит из netconn_recv прога начинает предпринимать попытки ожить - отправляет данные, пытается принять подтверждения, и в это время с подтверждениями сыпятся все те пакеты, которые не дошли! все сыпется кучей, как только пакеты заканчиваются, прога оживает полноценно (до следующей попытки принять большой массив).

 

При чем что характерно, каждая новая порция данных - это всегда ровно 35 пакетов. Потом опять торможение до нового netconn_write, после него опять 35... И до ни прога ни стек не падают мертво - весгда все очухивается и продолжает трудиться, я уже в отчаянии. Почему вдруг стало вместо 9 35, при чем и в старых проектах и на других платах и с разными операторами...

Edited by kan35

Share this post


Link to post
Share on other sites

Система не упала и ошибок не выдает значит все нормально работает.

Может GPRS тормозить, кто знает что там у оператора твориться, бываю таймауты по несколько десятков секунд пока прейдет новая порция данных.

Сколько по времени продолжается это самая остановка ?

Если попробовать только принимать пакеты и соответственно на передающей стороне только передавать в непрерывном режиме, посмотреть что изменится ?

Какой алгоритм обмена данными ?

Почему длинна пакетов приближена к максимально возможной ?

 

Share this post


Link to post
Share on other sites

GPRS не тормозит на самом деле, а стоит только отправить пакет с данными - модем начинает валить следующие 35 пакетов, потом опять подвисает и т д

Оператора менял, модем менял, возвращался к старым прошивкам - которые работали на 9 пакетов - они стали тоже по 35 пакетов принимать. Мистика!!!

Пакеты нарезаются по 1400 байтов у билайна, у мегафона по 1300, я это не регулирую вроде.

Остановка продолжается 60 секунд - ровно тот таймаут на netconn_recv. Потом я начинаю передачу и модем оживает.

Скажу прямо, я соединяюсь с сервером Wialon по их протоколу Wialon IPS. Функция, которую я отлаживаю - обновление прошивки, которая заключается в отправке файла на подсоединенное устройство - даже без подтверждений - бинарник тупо выплёвывается в устройство. Уже грешу на какое то нестандартное поведение сервера. Хотя если через гипертерминал я соединяюсь с сервером, то массив массив данных передается в гипертерминал четко за доли секунды.

 

Я бы не отказался от файла lwipopt.h с рабочей системы lwip-1.3.2.

Edited by kan35

Share this post


Link to post
Share on other sites
Держите.

ну что собственно, не помогло как ни странно:-)

Правда чтобы заработало я добавил:

#define LWIP_SOCKET    0
#define LWIP_ARP    0
#define lwipINTERFACE_STACK_SIZE        1000
#define lwipINTERFACE_TASK_PRIORITY        1
#define LWIP_SO_RCVTIMEO                1// это пробовал и 0 и 1

Но TCP_MSS явно на что то влияет, так как при значении 600 я принимаю четко 75 пакетов. Уменьшил TCP_MSS до 100 - начал принимать 175 пакетов. Может быть проблема кроется в FreeRTOS, у вас какая версия? (у меня 7.0.0).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this