lwIP (PPP) проблема, странная Опции

[kan35]

Модем 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, но допетрить не могу. Спасибо!!!!!

Сообщение отредактировал kan35 - Oct 21 2011, 13:08

[kan35]

Заменил модем на 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;
}

Сообщение отредактировал kan35 - Oct 21 2011, 14:03

[cpl]

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

[kan35]

Какой менеджер памяти в 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 пакета.

Сообщение отредактировал kan35 - Oct 29 2011, 08:00

[cpl]

CTS-RTS модема обрабатываются корректно ?
Попробуйте посмотреть не влетает ли ртос в функцию FREERTOS:vApplicationMallocFailedHook.

[kan35]

CTS-RTS модема обрабатываются корректно ?
Попробуйте посмотреть не влетает ли ртос в функцию FREERTOS:vApplicationMallocFailedHook.

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

[cpl]

Где в стеке поддержка XON XOFF, в lwip1.3.2 не нашел ?
Работу XON XOFF проверяли ?
Смотреть пробовали когда выдает pppInProc[0]: Dropping bad fcs 0x63B8 proto=0x0021
что выкинул модем и что действительно было принято контролером.
Попробуйте посмотреть не влетает ли ртос в функцию FREERTOS:vApplicationMallocFailedHook.
Если IP_REASSEMBLY=1 ?
если убрать (char *)pvPortMalloc(buflen) будет ли затык ?

[kan35]

Где в стеке поддержка 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 действительно заработали, а по поддержке стеком, сейчас изучаю, думал что поддерживает...

Сообщение отредактировал kan35 - Nov 2 2011, 07:09

[kan35]

Рано обрадовался. Началось совершенно непонятное.
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

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

[cpl]

XON-XOFF Не применял, пока обхожусь CTS-RTS.
Стек об XON-XOFF нечего не знает, это больще относится к SIO.

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

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

[kan35]

XON-XOFF Не применял, пока обхожусь CTS-RTS.
Стек об XON-XOFF нечего не знает, это больще относится к SIO.


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

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

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

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

Сообщение отредактировал kan35 - Nov 2 2011, 10:54

[cpl]

Система не упала и ошибок не выдает значит все нормально работает.
Может GPRS тормозить, кто знает что там у оператора твориться, бываю таймауты по несколько десятков секунд пока прейдет новая порция данных.
Сколько по времени продолжается это самая остановка ?
Если попробовать только принимать пакеты и соответственно на передающей стороне только передавать в непрерывном режиме, посмотреть что изменится ?
Какой алгоритм обмена данными ?
Почему длинна пакетов приближена к максимально возможной ?

[kan35]

GPRS не тормозит на самом деле, а стоит только отправить пакет с данными - модем начинает валить следующие 35 пакетов, потом опять подвисает и т д
Оператора менял, модем менял, возвращался к старым прошивкам - которые работали на 9 пакетов - они стали тоже по 35 пакетов принимать. Мистика!!!
Пакеты нарезаются по 1400 байтов у билайна, у мегафона по 1300, я это не регулирую вроде.
Остановка продолжается 60 секунд - ровно тот таймаут на netconn_recv. Потом я начинаю передачу и модем оживает.
Скажу прямо, я соединяюсь с сервером Wialon по их протоколу Wialon IPS. Функция, которую я отлаживаю - обновление прошивки, которая заключается в отправке файла на подсоединенное устройство - даже без подтверждений - бинарник тупо выплёвывается в устройство. Уже грешу на какое то нестандартное поведение сервера. Хотя если через гипертерминал я соединяюсь с сервером, то массив массив данных передается в гипертерминал четко за доли секунды.

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

Сообщение отредактировал kan35 - Nov 2 2011, 19:44

[cpl]

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

Держите.

Прикрепленные файлы

 lwipopts.h.zip ( 2.77 килобайт ) Кол-во скачиваний: 43

 

[kan35]

Держите.

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

Код

#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).