[jcxz 184]

А есть возможность вернуть прошивку которая соответсвует драйверу 6,12 или 6,14? чем это делается и где ее взять?

Так у Вас что - он прошился чем-то более поздним и не вернули??? :wacko:

Что-ж сразу не сказали? Естественно он не будет работать пока не откатите обратно, а потом не обновите до 6.12f.

Я же сразу сказал: только прошивка, которая в 6.12f точно работает с левыми Ultra V4.

[UniSoft 15]

С драйверами новее при отладке выдает ошибку что отладчик 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 5]

Остается тоько восхищаться SEGGERовской защите. Как умело они выуживают клоны при всём разнообразии аппаратных и программных версий своего отладчика.

[virfis 0]

В общем, без перепрошивки со сменой серийника никак.

Ну и как вариант, просто пропатчить dll

Моего серийника в этом списки нет.

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

Огромное спасибо.

[Vasen 3]

Добрый всем!

Прикупил китайский 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:

С внутреннего ресурса SEGGER_JLink_v632g_patch.7z

Изменено 3 июля, 2018 пользователем Vasen

[Vasily_ 45]

Для наката патча можно воспользоваться phyton скриптом в архиве. Пример:

Python.exe idadif.py JLinkARM.dll JLinkARM.dif

Пользуйтесь на здоровье.

https://drive.google.com/file/d/1d-fe8UEQiu...iew?usp=sharing

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

 

Что имеем:

- перешитый StLink на ST32F103 поддерживает все чипы, а не только STM.

Не поддерживает, только что проверил.

Limitations

https://www.segger.com/products/debug-probe...-link-on-board/

[Vasen 3]

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

 

 

Не поддерживает, только что проверил.

Limitations

https://www.segger.com/products/debug-probe...-link-on-board/

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

 

Изменено 3 июля, 2018 пользователем Vasen

[Vasily_ 45]

Извините, но не совсем понял, что и куда выложить? И что не поддерживает? Имею в данный момент 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 3]

Выложить ваш скрипт прямо в теме, а не через ссылку, что кстати касается и изображений.

А не поддерживает ничего кроме ST. что прямо так и написано у Segger. Я проверил на TLE9879, не работает!

То что у вас заработало с российским камнем не означает работу со всеми камнями, как вы об этом заявили.

Всего скорее Segger не знает о 1986ВЕ1Т, вот оно и работает.

А чем ссылка не устраивает? Поправьте, может чего сделал не так )) На всякий: SEGGER_JLink_v632g_patch.7z

Вот еще пример на NRF:

 

 

... А не поддерживает ничего кроме 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_ 45]

А чем ссылка не устраивает?

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

 

ОО, догнал. Так на не пропатченном бинарнике и не работает ))

Спасибо попробую.

[Obam 30]

Всего скорее Segger не знает о 1986ВЕ1Т, вот оно и работает.

Ну не знаю, stlink-v2mini (от waveshare) перешитый в jlink-ob вполне себе "Debugging on custom hardware" atsam3s1; уж о нём-то segger знает ;)

[jcxz 184]

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

У меня не получилось повторить Вашу проблему. Создал тестовый проект. Скомпилил в IAR 8.20.1 - компилит правильно.

Прикладываю сюда и проект и результат его компиляции.

Очень странным выглядит данный участок вашего кода:

          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??? В моём тестовом проекте он не добавляет таких команд. Это наводит на мысли.... Может всё-таки какая-то проблема у Вас в исходниках?

Вот мой тестовый проект.

tst_iar8.zipКонфигурация "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 0]

Я бы предложил вынести этот вопрос и все предыдущие сообщения по нему в отдельную тему модератором.

 

Тут как бы выдрано из контекста.

Я смог повторить так:

Надо скачать 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 перешел по адресу.

Изменено 12 июля, 2018 пользователем virfis

[Vasen 3]

По поводу патча, который выкладывал раньше. Когда вылезет вот такое сообщение

нужно сгенерить лицензии генератором

Segger_J_Link_keygen.rar

и внести их.

[jcxz 184]

Я смог повторить так:

Надо скачать 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:

 

Например может быть в этом:

В IAR 7.80.4 я компилирую под stm32f765, а мне надо еще stm32H743. И его он не знает.

Поставьте в свойствах проекта просто "ядро-M7" или "ядро-M4" и проверьте. Без всяких симуляторов и отладчиков!