virfis

Вы не писали им случайно? Версия 8.30.2 - проблема устранена!!!

Да, подтверждаю. На 8.20.1 компилирует нормально. Свой проект перекомпилировал - тоже всё отлично работает. Для этого им надо о нём узнать. А сообщить может только тот у кого лицензия есть. В этой версии кстати, еще в файле STM32H7xx.dmac ошибка. Отладчик ругается при запуске, но указывает конкретное место в строке 203. Я лишнюю открывающую скобку убрал и нормально стало.

Да я как бы не имею доступа

Нашел 8.22.2 версию. Действительно открылся проект как М3, ничего не менял, просто перебилдил. if ((tcpwnd_size_t)(pcb->cwnd + pcb->mss) > pcb->cwnd) { 0x27e: 0x1852 ADDS R2, R2, R1 0x280: 0xb293 UXTH R3, R2 0x282: 0x4299 CMP R1, R3 0x284: 0xd208 BCS.N 0x298 pcb->cwnd += pcb->mss; 0x286: 0xe006 B.N 0x296 tcpwnd_size_t new_cwnd = (pcb->cwnd + pcb->mss * pcb->mss / pcb->cwnd); 0x288: 0x4352 MULS R2, R2, R2 0x28a: 0xfb92 0xf2f1 SDIV R2, R2, R1 0x28e: 0x1852 ADDS R2, R2, R1 if (new_cwnd > pcb->cwnd) { 0x290: 0x428a CMP R2, R1 0x292: 0xbf38 IT CC 0x294: 0x460a MOVCC R2, R1 0x296: 0x8302 STRH R2, [R0, #0x18] return pcb->cwnd; 0x298: 0x8b00 LDRH R0, [R0, #0x18] 0x29a: 0x4770 BX LR А где бы раздобыть версию 8.20?

Проблема обнаружилась когда проект с Lwip был перенесен на компилятор 8-й версии. Через некоторое время после установления соединения по TCP и обмена данными прекращался обмен. Тот же проект скомпилированный на 7-й версии работает нормально. Разбираясь и копаясь нашел что "восьмерка" создает неверный (на мой взгляд) код в функции tcp_receive при включенной оптимизации. Я сделал тестовые проекты под версии 7.80 и 8.30. Взгляните на результат вывода printf в обеих версиях. В папке два проекта. Проект test - это для 8.30, test7_80.eww - для 7.80 соответственно. test.zip

С этого и надо было начинать. Проще всего указать на кривые руки, чем разобраться. Я просто привел способ воспроизведения проблемы. В кубе есть готовые проекты с lwip. Точно так же их можно скачать и без куба. Не будут дальше флудить. Создам отдельную тему.

Я бы предложил вынести этот вопрос и все предыдущие сообщения по нему в отдельную тему модератором. Тут как бы выдрано из контекста. Я смог повторить так: Надо скачать STM32CubeMX. В нем поддержку процессоров stm32h7. Затем в папке c:\Users\Пользователь\STM32Cube\Repository\STM32Cube_FW_H7_V1.2.0\Projects\STM32H743I_EVAL\Applications\LwIP\LwIP_TCP_Echo_Server\EWARM\ скомпилировать проект. Поставить отладчик симулятор. Запустить отладку. И уже тут смотреть ассемблерный код. Я не запускал программу, но в map файле нашел адрес функции tcp_receive и в окне disassembly перешел по адресу.

Моего серийника в этом списки нет. Патч помог. Теперь всё работает с версией 6.32g. Главное не обновлять теперь драйвер jlink. Огромное спасибо.

так как LWIP_WND_SCALE = 0, то typedef u16_t tcpwnd_size_t; и в структуре соответсвенно tcpwnd_size_t cwnd; Ну мне меньше всего хотелось бы ковырять код LwIP. Я начал пробовать 8-ку начиная с 8.22.1 и далее до последней 8.30.1 проверял каждое обновление. Ошибка не исправлена. И думаю что без багрепорта не исправят. Не смотря на то что это конечно важный момент, но возвращаясь к теме, кейл ни с 6.14b ни с 6.12f не хочет работать. Прошивка в отладчике обычно обновлялась без проблем если подключиться более новой версией. А есть возможность вернуть прошивку которая соответсвует драйверу 6,12 или 6,14? чем это делается и где ее взять?

Не умею работать с тегами в общем вот: lwip 2.0 tcp_in.c строка 1145, оптимизация максимальная balanced /* Update the congestion control variables (cwnd and ssthresh). */ if (pcb->state >= ESTABLISHED) { if (pcb->cwnd < pcb->ssthresh) { if ((tcpwnd_size_t)(pcb->cwnd + pcb->mss) > pcb->cwnd) { pcb->cwnd += pcb->mss; } LWIP_DEBUGF(TCP_CWND_DEBUG, ("tcp_receive: slow start cwnd %"TCPWNDSIZE_F"\n", pcb->cwnd)); } else { tcpwnd_size_t new_cwnd = (pcb->cwnd + pcb->mss * pcb->mss / pcb->cwnd); if (new_cwnd > pcb->cwnd) { pcb->cwnd = new_cwnd; } LWIP_DEBUGF(TCP_CWND_DEBUG, ("tcp_receive: congestion avoidance cwnd %"TCPWNDSIZE_F"\n", pcb->cwnd)); } } Вот ассемблер проблемного места с моими комментариями: tcpwnd_size_t new_cwnd = (pcb->cwnd + pcb->mss * pcb->mss / pcb->cwnd); Тут в R0 - pcb->cwnd = FFFA 0x809177e: 0x4349 MULS R1, R1, R1 0x8091780: 0xfb91 0xf1f0 SDIV R1, R1, R0 после умножения и деления получили слагаемое в R1 = 20 0x8091784: 0x1809 ADDS R1, R1, R0 R1 = 1001A - Вот ошибка! new_cwnd объявлена как 16 бит, а не отброшены старшие 16 бит if (new_cwnd > pcb->cwnd) { 0x8091786: 0xf105 0x0044 ADD.W R0, R5, #68 ; 0x44 0x809178a: 0x8882 LDRH R2, [R0, #0x4] снова закинули в R0 - pcb->cwnd = FFFA 0x809178c: 0x4291 CMP R1, R2 И вот ошибка при сравнении. То есть мы не попадаем в условие if (new_cwnd > pcb->cwnd) { pcb->cwnd = new_cwnd; } И pcb->cwnd не принимает нужного значения и потом все пакеты на входе выбрасываются А вот код из версии 7,80 tcpwnd_size_t new_cwnd = (pcb->cwnd + pcb->mss * pcb->mss / pcb->cwnd); 0x8092650: 0x4349 MULS R1, R1, R1 0x8092652: 0xfb91 0xf1f0 SDIV R1, R1, R0 0x8092656: 0x1809 ADDS R1, R1, R0 if (new_cwnd > pcb->cwnd) { 0x8092658: 0xb28a UXTH R2, R1 - Вот она спасительная строка, убравшая старшие 16 бит. 0x809265a: 0x4290 CMP R0, R2 0x809265c: 0xbf38 IT CC 0x809265e: 0x4610 MOVCC R0, R2 0x8092660: 0x80b8 STRH R0, [R7, #0x4] 0x8092662: 0xe036 B.N 0x80926d2 То что официальный IAR это очень хорошо, но проект не могу предоставить по политике предприятия.

Уверен на 100% потому что я неделю потратил на поиск проблемы. Сделаю не прям сейчас, но позже и выложу листинги. В IAR 7.80.4 я компилирую под stm32f765, а мне надо еще stm32H743. И его он не знает. Так я и внедрил в кейл нормальные драйвера 6.14b и получил то что на втором скриншоте.

6.14b работает с iar как часы. Новее я пробовал только с 6.20. И уже не работает. Но мне то надо чтобы с keil работало. :bb-offtopic: Iar 8.xx помимо своего неудобства еще и имеет ошибки компилятора при включенной оптимизации выше low. А именно в lwip проявляется - при подключении по TCP, довольно быстро происходит переполнение счетчика cwnd. И следующие пакеты просто отбрасываются на приеме. Я анализировал ассемблерный код и там реально ошибка - не маскируются старшие 16 бит в регистре, при 16-битной переменной. В 7.80.4 на точно тех же исходниках этой проблемы нет. Но поддержка новых процессоров stm32h7 есть только начиная с 8-й версии, хотя на сайте в табличке сравнения быстродействия они как-то использовали версию 7.60. В общем я решил попробовать кейл, а тут проблема с jetlink.

Добрый день. Имеется следующая проблема. JetLink Ultra V4 работал нормально до обновления драйверов от сеггер не выше версии 6.14b. С драйверами новее при отладке выдает ошибку что отладчик defective. В принципе достаточно было подменять драйверы в IAR на версию 6.14 и все работало дальше. Но возникла потребность перейти на Keil. Он поначалу тоже ругался что дефектив. Подменил драйверы на 6.14. И он вообще отказывается записывать программу к контроллер. Выдает такую ошибку: При этом IAR с этим же драйвером работает нормально. Как подружить Keil c драйвером или сделать чтобы jetlink не был defective. Прошивка в jetlink от 20 апреля 2018 обновилась нормально сама. Да и всегда обновляется без проблем.

Если я правильно просморел код, то часть касающаяся PPP работает только под RTOS.

Как я понял не получится LwIP подключить к scmRTOS, т.к. требуется создание и удаление потоков во время исполнения программы. Придется смотреть в сторону freeRTOS.

Понятно, там инициализация. Прикинуть можно. С этим немного возникает вопрос. Программа использует часть flash памяти для конфигурации (EEPROM не хватает). И позволяет менять конфигурацию "на лету". Для этого функция записи flash находится в секции загрузчика (они там вместе прекрасно уживаются). Фкнция не использует прерывание, а только ассемблерные вставки с отключением прерываний на время записи страницы. не вызовет ли это несвоевременное переключение контекста?

Понимаю что с одним процессом не много смысла, смысл только в том чтобы для начала с минимумом переделок программы, она заработала совместно с LwIP. Потом уже можно распараллеливать задачи и т.п. Прикрутил с одним процессом, прерывания не оборачивал. Таймер 1 заменил таймером 0. Работает. Но возникли вопросы, переделал main вот так: int main() { // DDRB |= (1 << 4); TCCR2 |= (1 << WGM21); // CTC mode OCR2 = 230; // TCCR2 |= (1 << CS22); // Timer1 run with prescaling 1 TIMSK |= (1 << OCIE2); // Timer1 OC interrupt enable TCCR0 = 0x03; // Start System Timer TIMSK |= (1 << TOIE0); // ACSR |= (1 << ACBG) | (1 << ACIE); /* Ref ON, IE ON */ // DDRB |= (1 << 3); /* AIN1*/ OS::Run(); } Какой смысл закомментированных строк? Как их можно заменить? Я так понял что они отвечают за переключение процессов. У меня задействованы абсолютно все выводы МК. Еще вопрос, где определять размер стека? В опциях компилятора у меня стояли значения для CSTACK 0x300, RSTACK 100. Если я создаю процесс process<OS::pr0, 0x300, 200> TProc1, то какое значения ставить в опциях компилятора?

Т.е. если я возьму любой из 3-х демо проектов (я скачал последнюю версию), оставлю 1 процесс и в for(;;) вставлю то что у меня было в while(1) программа по идее должна работать? Ну и системный таймер переставлю на Timer0 например.

Добрый день. Есть ATMega128 со внешней памятью 64К. Программа под нее использует UART0, UART1, TWI, SPI, оставшие выводы МК используются как порты ввода/вывода общего назначение. На одном из UART подключен GPRS-модем со встроенным TCP/IP стеком. Задействованы прерывания UART0, UART1, TWI, Timer1 - 1 ms, Timer3 - 1ms. Скорость работы UART 115200, TWI - 400KHz. Программа написана на IAR EWAVR и занимает около 80 Кб кода. Интересует переход на стек LwIP, так как только он имеет PPP протокол, чтобы отказаться от использования встроенных стеков модемов. ПОтому что это универсальнее, можно выбрать любой модем, и быстрее, зачастую в модемах стеки работают не очень весело, особенно в дешевых. Как я понял LwIP требуется операционка. Реально ли пересадить всю программу на scmRTOS, например в один низкоприоритетный процесс, и настроить LwIP так как ему надо? Но при этом важно чтобы существующие прерывания исполнялись так же как выполняются сейчас, с таким же быстродействием и были приоритетнее чем задачи LwIP. Вариант смены железа не применим в принципе: достаточно большое кол-во оборудования уже установлено у заказчиков. Если использовать LwIP, то примерно 10 Кб освободиться, потому что уберутся драйвера модемов. От LwIP требуется только TCP и UDP.

Лучше задайте вопрос по схеме, я отвечу.

Пробовали использовать режим RTS/CTS: CTS в нуле, выдали 510 байт на 115200, через 23 мс видим CTS поднялся в 1 и модем завис. Тоже самое с режимом XON/XOFF - модем выдал XOFF после приема пакета и XON уже не выдает, повис. И дальше уже не отвечает ни на какие команды. Смотрели осциллографом - просадки напряжения нет после того как поставили 4700 мкФ.

Я использую программное управление потоком XON/XOFF, писал выше. Кроме того в документации написано что за один раз можно отправлять до одного килобайта. Я отправляю 510 байт. О каком переполнении буфера может идти речь. А разве программным управлением потока нельзя обойтись?

Пробовал, не помогает. Не получится, нет свободных выводов процессора. Поставили 100 мкФ, не помогает. На VBAT поставили 4700 мкФ. Все равно есть зависания. Снизили скорость до 19200. Работает без зависаний вообще.

SIMM300DZ, прошивка 1008B16SIM300D32_SST34HF3284.mot С модемом работаю на скорости 115200. Режим autobaud. Устанавливается связь по UDP. Модем может полдня проработать вообще без проблем, а потом начинаются проблемы. Модем пару минут принимает и передает данные. Потом на какой-нибудь передаче модем зависает, перестает давать ответы на любые команды. Обмен ведется пакетами не более 510 байт. Прежде чем отправить следующий пакет, всегда дожидаюсь ответа SEND OK. Используется режим управления потоком данных XON/XOFF. Переставил скорость на 9600 — зависания стали гораздо реже, скажем так раз в 10. Но интересно то что в другое время ситуация по скорости была с точностью до наоборот: на 9600 были постоянные зависания, а на 115200 стало работать без зависаний. Зависания не стабильные, т.е. нельзя сказать что четко при отправке 10-го или 20-го пакета модем виснет, ситуация «плавающая». При частых зависаниях поставил другую антенну (усиление 7 dB), то зависать стал реже, обычная антенна с усилением 3 dB. Напряжения на линиях RxD и TxD не превышают 3-х вольт. На линию BACKUP подается напряжение от батарейки 3 В. Если снизить это напряжение до 2 В через два последовательных диода, то зависания тоже становятся реже. Если вообще нe подавать напряжение на линию BACKUP (оставить в воздухе), то ситуация такая же как и с поданными 3 В. На VBAT установлено 2 танталовых конденсатора по 100 мкФ рядом с выводом модема и керамический 2 мкФ. Пробовали поставить еще 2 - не помогло. Пробовали поставить конденсатор на линию RxD 330 пФ, как описывали здесь в теме - тоже не помогло.

У меня рабочая частота 48МГц, я ставил и 72 и 24. Все одинаково. Заметил сейчас такую вещь. КОгда идет инициализация адресных линий, если устанавливается в PINSEL8 нога P4[4] в режим 1(А4), то почему-то загорается светодиод stat1, который на ноге P4[17]