Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: China-Link, Вариант отладчика из Китая
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Отладочные платы
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
virfis
Цитата(jcxz @ Jun 28 2018, 13:11) *
Вы уверены??? Это очень серьёзное заявление! Мы у себя в проекте используем IAR8.11 и 8.20 - проблем не замечали.
Выложите пожалуйста участок кода, компиляция которого приводит к указанной ошибке. И ассемблерный листинг для него. А также какое ядро? и важные ключи компиляции.
Я думаю это будет полезно многим участникам здесь.


Заглянул в свойства проекта IAR 7.80.4 - присутствует ядро M7. Так что думаю должен работать с ними.
Да и в Keil наверняка можно внедрить какие нужно дрова segger-а - по-крайней мере мы у себя в Dave заменяли их без проблем (версию 6.12F).


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

Так я и внедрил в кейл нормальные драйвера 6.14b и получил то что на втором скриншоте.
jcxz
Цитата(virfis @ Jun 28 2018, 13:24) *
Уверен на 100% потому что я неделю потратил на поиск проблемы. Сделаю не прям сейчас, но позже и выложу листинги.

Будем ждать. И заранее спасибо!
IAR у нас официальный, и если баг подтвердится и будет проект, его иллюстрирующий, то наверное будем стучать в поддержку.

Цитата(virfis @ Jun 28 2018, 13:24) *
Так я и внедрил в кейл нормальные драйвера 6.14b и получил то что на втором скриншоте.

А после внедрения при подключении он обновлял прошивку J-Link-а? Если так, то наверное они как-то не полностью внедрились.
У нас, как только мы в Dave внедрили 6.12f, он сразу перестал требовать обновления прошивки. И сейчас работает без нареканий. Кейл не юзаем.
virfis
Цитата(jcxz @ Jun 28 2018, 14:02) *
Будем ждать. И заранее спасибо!
IAR у нас официальный, и если баг подтвердится и будет проект, его иллюстрирующий, то наверное будем стучать в поддержку.


А после внедрения при подключении он обновлял прошивку J-Link-а? Если так, то наверное они как-то не полностью внедрились.
У нас, как только мы в Dave внедрили 6.12f, он сразу перестал требовать обновления прошивки. И сейчас работает без нареканий. Кейл не юзаем.

Не умею работать с тегами в общем вот:
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 это очень хорошо, но проект не могу предоставить по политике предприятия.
jcxz
Цитата(virfis @ Jun 29 2018, 12:01) *
И pcb->cwnd не принимает нужного значения и потом все пакеты на входе выбрасываются

А как объявлены tcpwnd_size_t и pcb->cwnd? И какая именно версия IAR 8.xx?
Попробую позже у себя сэмулировать такое.
Хотя я конечно в принципе не использую локальные не-static переменные как рабочие внутри функций: только int/uint или выше. Чтобы не было лишних команд расширений.
virfis
Цитата(jcxz @ Jun 29 2018, 12:26) *
А как объявлены tcpwnd_size_t и pcb->cwnd? И какая именно версия IAR 8.xx?
Попробую позже у себя сэмулировать такое.

так как LWIP_WND_SCALE = 0, то
typedef u16_t tcpwnd_size_t;
и в структуре соответсвенно
tcpwnd_size_t cwnd;

Цитата
Хотя я конечно в принципе не использую локальные не-static переменные как рабочие внутри функций: только int/uint или выше. Чтобы не было лишних команд расширений.

Ну мне меньше всего хотелось бы ковырять код LwIP.

Я начал пробовать 8-ку начиная с 8.22.1 и далее до последней 8.30.1 проверял каждое обновление. Ошибка не исправлена. И думаю что без багрепорта не исправят.

Не смотря на то что это конечно важный момент, но возвращаясь к теме, кейл ни с 6.14b ни с 6.12f не хочет работать.
Прошивка в отладчике обычно обновлялась без проблем если подключиться более новой версией.
А есть возможность вернуть прошивку которая соответсвует драйверу 6,12 или 6,14? чем это делается и где ее взять?
jcxz
Цитата(virfis @ Jun 29 2018, 13:31) *
А есть возможность вернуть прошивку которая соответсвует драйверу 6,12 или 6,14? чем это делается и где ее взять?

Так у Вас что - он прошился чем-то более поздним и не вернули??? wacko.gif
Что-ж сразу не сказали? Естественно он не будет работать пока не откатите обратно, а потом не обновите до 6.12f.
Я же сразу сказал: только прошивка, которая в 6.12f точно работает с левыми Ultra V4.
UniSoft
Цитата(virfis @ Jun 28 2018, 16:37) *
С драйверами новее при отладке выдает ошибку что отладчик defective.
Как подружить Keil c драйвером или сделать чтобы jetlink не был defective.

Keil тут совершенно не играет никакой роли.
Это защита от клонов...
собственно проверка в самой dll (JLinkARM.dll, JLink_x64.dll).
проверяется несколько условий,
вот список забаненных серийников:
11111117, 20100214, 50331647, 20090626, 20080696, 20064001, 20101001, 24446459, 805306163, 377001345, 270676280, 17892859, 99999994, 286370559
также наличие лицензии: "GDBFull" приведет к defective.
В общем, без перепрошивки со сменой серийника никак.
Ну и как вариант, просто пропатчить dll
Код
JLink_V632g

JLinkARM.dll
  00082100: 55 -> C3
  00000179: 10 08 01 88 33 -> 00 00 00 00 00

JLink_x64.dll
  00090A80: 40 -> C3
  00000191: 28 15 01 88 33 -> 00 00 00 00 00
skripach
Остается тоько восхищаться SEGGERовской защите. Как умело они выуживают клоны при всём разнообразии аппаратных и программных версий своего отладчика.
virfis
Цитата(UniSoft @ Jun 29 2018, 17:45) *
В общем, без перепрошивки со сменой серийника никак.
Ну и как вариант, просто пропатчить dll
Моего серийника в этом списки нет.
Патч помог. Теперь всё работает с версией 6.32g. Главное не обновлять теперь драйвер jlink.
Огромное спасибо.
Vasen
Добрый всем!
Прикупил китайский StLinkv2 с целью перепрошить в JLink.
Посидел, подумал -> прилагаю архив с мыслями для Segger 6.32g.
Что имеем:
- перешитый StLink на ST32F103 поддерживает все чипы, а не только STM.
- убрана мессага о дефективном JLink v7 (серийник должен быть не в списке забанненых), что приводило к дисконектам.
- Ozone работает и с StLink и с JLink v7.
Для наката патча можно воспользоваться phyton скриптом в архиве. Пример:
Код
Python.exe idadif.py JLinkARM.dll JLinkARM.dif

Пользуйтесь на здоровье.
https://drive.google.com/file/d/1d-fe8UEQiu...iew?usp=sharing

Edit:
С внутреннего ресурса Нажмите для просмотра прикрепленного файла
Vasily_
Цитата(Vasen @ Jul 3 2018, 11:24) *
Для наката патча можно воспользоваться phyton скриптом в архиве. Пример:
Код
Python.exe idadif.py JLinkARM.dll JLinkARM.dif

Пользуйтесь на здоровье.
https://drive.google.com/file/d/1d-fe8UEQiu...iew?usp=sharing

А почему сразу в теме не выложить?

Цитата(Vasen @ Jul 3 2018, 11:24) *
Что имеем:
- перешитый StLink на ST32F103 поддерживает все чипы, а не только STM.

Не поддерживает, только что проверил.
Limitations
https://www.segger.com/products/debug-probe...-link-on-board/
Vasen
Цитата(Vasily_ @ Jul 3 2018, 12:40) *
А почему сразу в теме не выложить?


Не поддерживает, только что проверил.
Limitations
https://www.segger.com/products/debug-probe...-link-on-board/

Извините, но не совсем понял, что и куда выложить? И что не поддерживает? Имею в данный момент 1986ВЕ1Т с отладкой в Ozon программатором Jlink StLink.

Vasily_
Цитата(Vasen @ Jul 3 2018, 13:08) *
Извините, но не совсем понял, что и куда выложить? И что не поддерживает? Имею в данный момент 1986ВЕ1Т с отладкой в Ozon программатором Jlink StLink.

Выложить ваш скрипт прямо в теме, а не через ссылку, что кстати касается и изображений.
А не поддерживает ничего кроме ST. что прямо так и написано у Segger. Я проверил на TLE9879, не работает!
The firmware making the ST-LINK on-board J-Link compatible has some limitations in contrast to an original, industry leading SEGGER J-Link:

May be used with ARM based ST devices only
Only debugging on evaluation boards is allowed. Debugging on custom hardware is not supported and not allowed
No production flash programming support
Unlimited breakpoints in flash available for evaluation only
No support is given

То что у вас заработало с российским камнем не означает работу со всеми камнями, как вы об этом заявили.
Всего скорее Segger не знает о 1986ВЕ1Т, вот оно и работает.
Vasen
Цитата(Vasily_ @ Jul 3 2018, 13:18) *
Выложить ваш скрипт прямо в теме, а не через ссылку, что кстати касается и изображений.
А не поддерживает ничего кроме ST. что прямо так и написано у Segger. Я проверил на TLE9879, не работает!
То что у вас заработало с российским камнем не означает работу со всеми камнями, как вы об этом заявили.
Всего скорее Segger не знает о 1986ВЕ1Т, вот оно и работает.

А чем ссылка не устраивает? Поправьте, может чего сделал не так )) На всякий: Нажмите для просмотра прикрепленного файла
Вот еще пример на NRF:
Нажмите для просмотра прикрепленного файла


Цитата(Vasily_ @ Jul 3 2018, 13:18) *
... А не поддерживает ничего кроме ST. что прямо так и написано у Segger. Я проверил на TLE9879, не работает!
The firmware making the ST-LINK on-board J-Link compatible has some limitations in contrast to an original, industry leading SEGGER J-Link:

May be used with ARM based ST devices only
Only debugging on evaluation boards is allowed. Debugging on custom hardware is not supported and not allowed
No production flash programming support
Unlimited breakpoints in flash available for evaluation only
No support is given

То что у вас заработало с российским камнем не означает работу со всеми камнями, как вы об этом заявили.
Всего скорее Segger не знает о 1986ВЕ1Т, вот оно и работает.

ОО, догнал. Так на не пропатченном бинарнике и не работает ))
Vasily_
Цитата(Vasen @ Jul 3 2018, 13:59) *
А чем ссылка не устраивает?

Ссылка со временем просто будет нерабочая, что обычно и происходит.

Цитата(Vasen @ Jul 3 2018, 13:59) *
ОО, догнал. Так на не пропатченном бинарнике и не работает ))

Спасибо попробую.
Obam
Цитата(Vasily_ @ Jul 3 2018, 13:18) *
Всего скорее Segger не знает о 1986ВЕ1Т, вот оно и работает.

Ну не знаю, stlink-v2mini (от waveshare) перешитый в jlink-ob вполне себе "Debugging on custom hardware" atsam3s1; уж о нём-то segger знает wink.gif
jcxz
Цитата(virfis @ Jun 29 2018, 13:31) *
Я начал пробовать 8-ку начиная с 8.22.1 и далее до последней 8.30.1 проверял каждое обновление. Ошибка не исправлена. И думаю что без багрепорта не исправят.

У меня не получилось повторить Вашу проблему. Создал тестовый проект. Скомпилил в IAR 8.20.1 - компилит правильно.
Прикладываю сюда и проект и результат его компиляции.
Очень странным выглядит данный участок вашего кода:
Цитата(virfis @ Jun 29 2018, 12:01) *
Код
          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                        И вот ошибка при сравнении.

Зачем добавлены команды 0x8091786 и 0x809178a если в R0 уже имеется pcb->cwnd??? В моём тестовом проекте он не добавляет таких команд. Это наводит на мысли.... Может всё-таки какая-то проблема у Вас в исходниках?
Вот мой тестовый проект.
Нажмите для просмотра прикрепленного файлаКонфигурация "RAM_DEBUG" - без оптимизации, "RAM_RELEASE" - с balanced оптимизацией (ключи по умолчанию, а может дело в ключах этой оптимизации? Какие у Вас?)

В Func3() повторяю Ваш исходный код. Func4() тот же код, но я модифицировал его так, чтобы компилятор добавил дополнительное чтение p->cwnd перед сравнением, чтобы получить ситуацию похожую на Вашу.
И в том и в другом случае - результат компиляции верный.
Func3():
Код
     22            u16 new_cwnd = (p->cwnd + p->mss * p->mss / p->cwnd);
   \   00000008   0x8860             LDRH     R0,[R4, #+2]
   \   0000000A   0x8821             LDRH     R1,[R4, #+0]
   \   0000000C   0x4340             MULS     R0,R0,R0
   \   0000000E   0xFB90 0xF0F1      SDIV     R0,R0,R1
   \   00000012   0x1840             ADDS     R0,R0,R1
     23            if (new_cwnd > p->cwnd) p->cwnd = new_cwnd;
   \   00000014   0xB282             UXTH     R2,R0
   \   00000016   0x4291             CMP      R1,R2
Func4():
Код
   \   0000000A   0x8868             LDRH     R0,[R5, #+2]
   \   0000000C   0x8829             LDRH     R1,[R5, #+0]
   \   0000000E   0x4340             MULS     R0,R0,R0
   \   00000010   0xFB90 0xF0F1      SDIV     R0,R0,R1
   \   00000014   0x1841             ADDS     R1,R0,R1
     33            if (new_cwnd > p1->cwnd) p->cwnd = new_cwnd;
   \   00000016   0x8820             LDRH     R0,[R4, #+0]
   \   00000018   0xB28A             UXTH     R2,R1
   \   0000001A   0x4290             CMP      R0,R2
virfis
Я бы предложил вынести этот вопрос и все предыдущие сообщения по нему в отдельную тему модератором.

Тут как бы выдрано из контекста.
Я смог повторить так:
Надо скачать 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 перешел по адресу.
Vasen
По поводу патча, который выкладывал раньше. Когда вылезет вот такое сообщение
Нажмите для просмотра прикрепленного файла
нужно сгенерить лицензии генератором
Нажмите для просмотра прикрепленного файла
и внести их.
jcxz
Цитата(virfis @ Jul 12 2018, 10:28) *
Я смог повторить так:
Надо скачать 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 перешел по адресу.

Я Вам показал, что проблема похоже совсем не в работе с типами u16, а в чём-то другом.
И у меня складывается впечатление, что она скорей всего где-то во всей этой куче кубов, симуляторов и вашего кода.
Если Вы действительно желаете её локализовать, то стоит по частям сужать область поиска:
1) выбросить симулятор и найти подозреваемый участок в файле листинга;
2) выбросить куб;
3) вносить модификации в этот участок кода, смотря что происходит;
4) ...
И от поддержки или не поддержки stm32h7 этот код тоже не должен зависеть - все использованные там команды есть уже в M3/M4.
Желания копаться со всякими кубами и прочим хламом у меня нет никакого. Тем более, что скорей всего именно там где-то и кроется проблема. Мне видится крайне маловероятным, чтобы такая ошибка, проявляющаяся в таком месте как lwIP (который очень много кто использует), так долго не обнаруживалась никем кроме Вас и не исправлялась. Да IAR бы уже завалили тоннами жалоб.
Баг где-то у Вас в проекте. Имхо laughing.gif

Например может быть в этом:
Цитата(virfis @ Jun 28 2018, 13:24) *
В IAR 7.80.4 я компилирую под stm32f765, а мне надо еще stm32H743. И его он не знает.

Поставьте в свойствах проекта просто "ядро-M7" или "ядро-M4" и проверьте. Без всяких симуляторов и отладчиков!
virfis
Цитата
Желания копаться со всякими кубами и прочим хламом у меня нет никакого
С этого и надо было начинать.
Цитата
Баг где-то у Вас в проекте. Имхо
Проще всего указать на кривые руки, чем разобраться. Я просто привел способ воспроизведения проблемы. В кубе есть готовые проекты с lwip. Точно так же их можно скачать и без куба. Не будут дальше флудить. Создам отдельную тему.
jcxz
Цитата(virfis @ Jul 16 2018, 11:51) *
Проще всего указать на кривые руки, чем разобраться.

Я вовсе не указываю на кривые руки. Я говорю о том, что:
Так как инфы о том, что там конкретно у Вас проекте - нет никакой, а компиляция участка подобного описанному в другом проекте на аналогичном компиляторе не вызывает ошибки, то скорей всего ошибка в проекте, а не в компиляторе.
Достаточно хоть немного почитать этот форум, чтобы увидеть что тут некоторые товарищи чуть не каждый день находят "баг IAR-а". Который на поверку оказывается как всегда - "сам дурак".
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.