Stlink: [функция] STLINK-v3: Поддержка программистов

У меня тоже серьезная проблема. Я только что купил новый оригинальный программатор / отладчик STLINK-V3SET от StMicro.

• Тип программатора: STLINK-V3SET
• Операционная система: Debian 9 (stretch)
• Версия инструментов stlink: v1.5.1-31-g625f4cd
• Название инструмента командной строки stlink: st-info и все остальные
• Целевой чип: STM32F746VG и / или STM32F469NI с использованием оригинального программатора / отладчика STLINK-V3SET

Утилита st-info без проблем обнаруживает мою новую плату STM32F746G-Discovery и управляет ею.
Когда я подключаю свой новый программатор STLINK-V3SET, выполняю команду:

./st-info --probe

Я получаю только:

_ "Найдено 0 программистов stlink._"

Я уже поместил соответствующий файл в /etc/udev/rules.d (имя файла: 49-stlinkv3.rules).
Выполняя команду lsusb -v, я получаю следующее:

mmazza @ linux9 : ~ / ARMtoolchains / stlink-master / build / Выпуск $ lsusb -v

Шина 005 Устройство 003: ID 0483: 374f STMicroelectronics
Дескриптор устройства:
b Длина 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Разное устройство
bDeviceSubClass 2?
bDeviceProtocol 1 Интерфейсная ассоциация
bMaxPacketSize0 64
idVendor 0x0483 STMicroelectronics
idProduct 0x374f
bcdDevice 1.00
iManufacturer 1 STMicroelectronics
iProduct 2 ST-LINK / V3
iSerial 3 005200363137510239383538

Любые идеи?
Я действительно застрял.
Заранее спасибо,

Максимум

У меня такая же просьба.

Кто-нибудь должен что-то сделать для поддержки STLINK-V3SET? Пожалуйста.

Как и @unclebanjoman , в Ubuntu 18.04 LTS моя система обнаруживает зонд V3, но st-info --probe возвращает 0 устройств. Я немного разберусь с этим, но ничего не могу обещать.

У меня такая же просьба. Мне нравится использовать make flash в Makefiles, но мне также нравится новая версия v3.
Моя конкретная ошибка (Windows 10, Cygwin) с подключенным STLINK-V3SET (и может использоваться с помощью STM32CubeProgrammer, а также с помощью утилиты STLINK):
st-flash --reset запись bin / X.bin 0x8000000
st-flash 1.3.0
2019-10-09T22: 56: 02 WARN C: \ Users \ Jerry \ Desktop \ stlink-master \ src \ usb.c: Не удалось найти устройства ST-Link / V2

Эй, ребята!

Мне удалось исправить исходники, чтобы мой STLink V3 mini был распознан и инициализирован.

Честно говоря, я вспомнил, что это просто вопрос добавления PID и настройки правильных конечных точек. Что ж, это было не так просто, но благодаря отличной работе Антонио Борнео над openOCD мне удалось легче разобраться в различиях.

Мой код живет здесь:
https://github.com/martonmiklos/stlink/pull/new/add_stlink_v3_support

Мне не удалось его протестировать (у меня дома есть мини, но нет устройства с шагом 1,27 JTAG conn).
Не стесняйтесь протестировать его (он должен работать, поскольку наибольшая разница была в инициализации) и составьте отчет.

@WRansohoff : Вы заинтересованы в его тестировании, просмотрев текущую ветку разработки?

Я могу взглянуть, когда у меня снова появится доступ к одной из более новых плат. Но это может произойти через пару недель, так что, может быть, кто-нибудь еще сможет меня опередить :)

Спасибо, что исправили это!

У меня есть stlink-v3, и я могу помочь вам с тестированием.
Я скомпилировал ваш код и подключил свой программатор stlink-v3 к плате bluepill (stm32f103c8).

$ ./st-info --version
v1.6.0

$ ./st-info --probe
Found 1 stlink programmers

$ ./st-info --flash
0x10000

$ ./st-info --sram
0x5000

$ ./st-info --descr
F1 Medium-density device

$ ./st-info --pagesize
0x400

$ ./st-info --chipid
0x0410

$ ./st-info --serial
303034323030314633313337353130413339333833353338

$ ./st-info --hla-serial
"\x30\x30\x34\x32\x30\x30\x31\x46\x33\x31\x33\x37\x35\x31\x30\x41\x33\x39\x33\x38\x33\x35\x33\x38"

Запуск st-flash вызывает некоторые ошибки, как вы можете видеть ниже.

Стереть, казалось, удалось, и она стерла уже работающую микросхему:

$ ./st-flash erase
st-flash 1.6.0
2020-02-26T11:27:37 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2020-02-26T11:27:37 INFO common.c: Loading device parameters....
2020-02-26T11:27:37 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-02-26T11:27:37 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
  core status: unknown
Mass erasing

Затем я перепрограммировал чип с помощью STM32CubeProgrammer и попытался читать и записывать обратно, используя вашу версию stlink.

Чтение чипа выдает ошибки:

$ ./st-flash read /tmp/saved.img 0x8000000 0x1000
st-flash 1.6.0
2020-02-26T11:24:35 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2020-02-26T11:24:35 INFO common.c: Loading device parameters....
2020-02-26T11:24:35 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-02-26T11:24:35 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
  core status: unknown

А также ошибки при попытке обратной записи в чип:

$ ./st-flash write /tmp/saved.bin 0x8000000
st-flash 1.6.0
2020-02-26T12:30:40 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2020-02-26T12:30:40 INFO common.c: Loading device parameters....
2020-02-26T12:30:40 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-02-26T12:30:40 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
  core status: unknown
2020-02-26T12:30:40 INFO common.c: Ignoring 3396 bytes of 0xff at end of file
2020-02-26T12:30:40 INFO common.c: Attempting to write 700 (0x2bc) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-02-26T12:30:40 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-02-26T12:30:40 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-02-26T12:30:40 INFO flash_loader.c: Successfully loaded flash loader in sram
  core status: unknown
  core status: unknown
  core status: unknown
  core status: unknown
  core status: unknown
  core status: unknown
  core status: unknown

---- multiple lines trimmed ----

  core status: unknown
  core status: unknown
2020-02-26T12:30:41 ERROR flash_loader.c: flash loader run error
2020-02-26T12:30:41 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Если вы хотите, чтобы я провел определенные тесты, пожалуйста, помогите мне, и я это сделаю.

Я бы посоветовал протестировать общие варианты использования и задачи, которые могут быть выполнены с помощью набора инструментов stlink, так же, как мы ожидаем, что они будут работать с уже поддерживаемым программатором stlink-v2. Кажется, не проблема, если какие-либо дополнительные функции могут еще не быть полностью функциональными, но основные функции должны оказаться в рабочем состоянии. @kioan @WRansohoff @martonmiklos : Возможно, вы сможете обсудить друг с другом более конкретные тесты, а также проконсультироваться с нашей документацией и "How-To" за некоторыми идеями. Я тоже займусь этим через несколько дней.

Я собираю вместе все необходимое, чтобы иметь возможность отлаживать во время выполнения. Думаю, это будет проще и эффективнее всего. Большое спасибо @WRansohoff и @kioan за выполнение тестов.

Я немного новичок в github и т. Д., Поэтому, если бы кто-нибудь мог дать мне несколько рекомендаций, это было бы действительно полезно.

В моей системе работает Debian. Есть ли способ создать пакет debian для его установки?
Это позволило бы мне протестировать его, используя среду, которую я уже использовал (я только начал изучать разработку STM32, используя книгу Уоррена Гея, поэтому я использую его make-файлы в качестве базовой структуры)

@kioan : Возможно, вам будет полезно заглянуть в / doc / compiling в качестве первого шага и посмотреть, как далеко вы продвинетесь. К сожалению, он не полностью обновлен, но поскольку я стараюсь изо всех сил - вот «быстрое и грязное» обновление, которое поможет вам в этом:

1) Создайте репо на главной странице проекта: https://github.com/texane/stlink
2) Clone / Download показывает git-ссылку, которую вы должны скопировать в буфер обмена.
3) Создайте новую локальную папку для ваших git-Projects и убедитесь, что у вас установлен пакет git , что, как я предполагаю, уже имеет место.
4) перейдите в новую папку через терминал и введите git clone $pasted_link
5) Убедитесь, что у вас установлены следующие пакеты:

• CMake (v2.8.7 или новее)
• Компилятор C (gcc, clang или mingw)
• libusb 1.0 (v1.0.13 или новее)
• libusb-dev 1.0 (v1.0.13 или новее)

... а затем следуйте инструкциям. Пожалуйста, дайте нам знать, если у вас возникнут проблемы. ;-)

Спасибо! В случае, если кто-то другой, как я, захочет выполнить эту процедуру, сразу после клонирования (шаг 4) он должен проверить ветку разработки и скомпилировать ее вместо основного.
Это можно сделать, запустив
git branch -a чтобы показать все ветки, за которыми следует
git checkout remotes/origin/develop - ветка с поддержкой stlinkv3.

Я успешно создал пакеты debian и установил их. Я пробовал make-файлы, которые раньше работали с программатором stlinkv2, но получаю те же ошибки, о которых упоминал ранее .
По крайней мере, теперь я знаю, что могу протестировать ваши будущие патчи.

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

См. Также №863.

Хорошо, я собрал плату «Nucleo» STM32G431, которая имеет отладчик «STLINK-V3E», и опробовал ее с веткой «develop». В отладчике используется STM32F723! Жаль, что они не делают больше выводов этого чипа на плате, а?

В любом случае, я могу прошить чип с помощью простой программы «мигающий светодиод», используя st-flash , и эта программа будет работать без ошибок после прошивки.

Проблемы начинаются, когда я загружаю программу, которая использует прерывания; все работает нормально, когда программа 'мигающий светодиод' использует цикл 'while' для задержки между переключениями светодиодов, но когда она использует прерывание SysTick , ST-Link, похоже, не может впоследствии подключиться к отладчику начальная загрузка программы. Я получаю всевозможные необычные ошибки, от «неизвестный идентификатор чипа» до «не удалось разблокировать флэш-память» и «не удалось проверить флэш-память».

Может быть, отладчику не удается достаточно долго удерживать микросхему в состоянии сброса или не удается отключить прерывания после того, как он переведен в состояние отладки? Извините, что я недостаточно знаю о внутренней работе, чтобы сделать более обоснованное предположение. Чтобы вернуть плату в рабочее состояние, мне нужно было выполнить массовое стирание с помощью одной из утилит, распространяемых ST.

Я получаю ошибки, похожие на те, что сообщил @kioan, когда пытаюсь открыть отладочное соединение с помощью st-util . Кажется, что соединение открывается успешно, но когда я подключаюсь к цели в GDB, оно не предоставляет надежных данных, и приложение st-util выводит кучу сообщений «основной статус: неизвестно».

Вот что происходит, когда я тестирую текущую ветку "develop" с помощью STLink-V3, но это определенно выглядит многообещающим! И извините за задержку с ответом; В последнее время я переезжаю, поэтому большая часть моего микроконтроллера уже упакована.

Привет! Как успехи?

Помогло бы предоставление захвата с использованием Wireshark и usbmon с помощью STM32CubeProg?

Я получаю тот же результат, что и https://github.com/texane/stlink/issues/820#issuecomment -591358679, используя STLINK-V3SET, но может быть запрограммирован через интерфейс командной строки STM32CubeProg. Я не могу использовать их графический интерфейс из-за отсутствия библиотеки.

OpenOCD в последнем источнике читает регистр DCB DHCSR для получения статуса
https://github.com/ntfreak/openocd/blob/bff1b6f05a56eed8e150c25d925bd51ca2840daf/src/jtag/drivers/stlink_usb.c#L1743

Может быть, это исправит проблему "основной статус: неизвестно"

Привет, народ,

Прошу прощения за поздний ответ. Мне все еще не удалось отладить все это физически.

@medicalwei Я думаю, что на данный момент в этом нет необходимости, у меня есть оборудование на работе и дома, поэтому, если я найду время поработать над этим, я могу отладить это.

@ Ant-ON Поддержка OpenOCD Stlink была написана с использованием защищенной NDA документации от ST, так что мой план: если я выделю проблемные точки, я посмотрю на код OpenOCD. (Изменения, которые я добавил, тоже были основаны на этом.)

@martonmiklos : Нет проблем, не

У меня есть плата STM32H745 Nucleo-144, которая поставляется с STLINK-V3E. Есть ли информация, которую я могу выкопать, или что можно проверить, чтобы помочь вам всем заставить ее работать?

@lvdlvd : добавляете немного неудобную комбинацию. В настоящее время мы не поддерживаем ни STM32H7, ни STLINK-V3 ... :-D,

НО оба на самом деле являются запланированными функциями с доступными открытыми проблемами. В настоящее время я не могу сказать, что из того и другого сложнее реализовать. Если кто-то, знакомый с H7, сделает шаг вперед и желает внести свой вклад и, таким образом, получить поддержку, я могу изменить текущий план выпуска для этого. Вы, ребята, скажите мне, что вы предпочитаете, и я смогу удовлетворить ваш спрос. И как всегда - приветствуется любая помощь. : +1:

я думаю, что заставить stlink v3 работать с bluepill было бы
быть правильным первым шагом, то, как только это сработает, я смогу заглянуть в H7.

Мне понадобятся выходные, чтобы освоить вашу кодовую базу.

Оп ма 30 мрт. 2020 ом 01:01 schreef nightwalker-87 < [email protected]

:

@lvdlvd https://github.com/lvdlvd : Спасибо, за повышение интереса - хотя
вы добавляете немного неудобную комбинацию. В настоящее время мы ни
поддерживает STM32H7 и STLINK-V3 ... :-D,

НО оба на самом деле являются запланированными функциями с доступными открытыми проблемами. я
в настоящее время трудно сказать, что из того и другого сложнее реализовать. Если
кто-то, знакомый с H7, делает шаг вперед и готов внести свой вклад и, таким образом,
получить его поддержку, я могу изменить текущий план выпуска для этого. Ты
ребята скажите мне, что вы предпочитаете, и я могу удовлетворить спрос. И, как
всегда - любая помощь приветствуется. 👍

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/texane/stlink/issues/820#issuecomment-605715609 или
отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ACIGIC7VBB7BSZU6F7RZC5TRJ7HN7ANCNFSM4IG5F6WA
.

@lvdlvd : ладно, не торопитесь. Действительно, последние недели были довольно загружены этим проектом, и в нем было много над чем поработать из прошлого. Я надеюсь скоро избавиться от остатков еды, чтобы мы могли с нетерпением ждать ...

Хорошо: начиная с самой первой проблемы, о которой сообщил @kioan
core status: unknown

Заглянув в код openOCD, выясняется, что в случае, если поддерживаемый JTAG API больше 1, используется другой метод запроса статуса:
https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L1789

Если вы посмотрите на определение JTAG API в openOCD, выяснится, что не все так просто, что StLinkV2 использует V2 API, но и V1 это тоже после определенной версии JTAG:
https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L989

У меня всегда создается впечатление, что нам было бы проще, если бы мы обернули код openOCD напрямую. :улыбка:

@martonmiklos

У меня всегда создается впечатление, что нам было бы проще, если бы мы обернули код openOCD напрямую. 😄

Боюсь, что не можем. stlink находится под лицензией BSD, а openocd - под GPLv2 и более поздними версиями. Это означает, что если мы обернем какой-либо код из openocd, проект должен быть под GPL или, по крайней мере, под смешанными лицензиями, которые я делаю в чистой комнате, чтобы удалить.

Да, я это понимаю. Но, глядя на количество хаков, реализованных в OpenOCD (и зная тот факт, что у них есть доступ к материалам ST), мне всегда трудно оправдать то, что я трачу свободное время на проект.

Также имейте в виду, что разработка OpenOCD, похоже, когда-то застопорилась в 2017 году. Если нам нужна эта функция с подходом, совместимым с BSD-3, нам понадобится кто-то, кто потратит на это некоторые усилия (что может занять больше времени).

Что ж, я бы сказал, что разработка OpenOCD застопорилась: поддержка STLinkV3 была добавлена ​​в прошлом году, и если вы возложите вину на https://github.com/ntfreak/openocd/blame/master/src/jtag/drivers /stlink_usb.c вы увидите, что над этим ведется активная работа.

Но в любом случае я взломаю V3, чтобы он заработал, если однажды начну!
Мне удалось обойти основной запрос статуса, теперь работает чтение, стирание моего bluepill.

Что ж, я бы сказал, что разработка OpenOCD застопорилась: поддержка STLinkV3 была добавлена ​​в прошлом году, и если вы возложите вину на https://github.com/ntfreak/openocd/blame/master/src/jtag/drivers /stlink_usb.c вы увидите, что над этим ведется активная работа.

Интересно это видеть. Мое заявление указывало на официальную страницу проекта.

Кто-нибудь знает, почему флеш-загрузчик не попадает в точку останова?

А мы приехали ...:

        h->cmdbuf[h->cmdidx++] = STLINK_DEBUG_COMMAND;
    if (h->version.jtag_api == STLINK_JTAG_API_V1)
        h->cmdbuf[h->cmdidx++] = STLINK_DEBUG_APIV1_WRITEREG;
    else
        h->cmdbuf[h->cmdidx++] = STLINK_DEBUG_APIV2_WRITEREG;

После обновления stlink v2.1 в версии "V2J36M26 STM32 Debug + VCP" он был распознан с идентификатором pid stvink v3:

Bus 003 Device 010: ID 0483:3752 STMicroelectronics ST-LINK/V2.1

и не распознаются st-util:

$ st-util -s 3
stlink version 3 unknown!

@Igorbunow К вашему сведению: это не V3 PID, а V2.1 без MSD:
https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L73

В случае, если кому-то интересно, что функциональность записи mem 32 нарушена (вот почему загруженный не загружается), и я еще не мог понять разницу между OpenOCD и этим инструментом (и мне нужно немного поспать сейчас ).

Если кто-то хочет разобраться в этом, вот коды:
https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L2266
https://github.com/martonmiklos/stlink/blob/add_stlink_v3_support/src/usb.c#L291

Поскольку я добавил send_recv в _stlink_usb_write_mem32, у меня всегда возникали проблемы с тайм-аутом libusb. Так что я кое-что упустил.

Может ли кто-нибудь помочь @martonmiklos в этой теме в целом? Я думаю, что эта тема заслуживает, чтобы по крайней мере два участника активно работали над ней, если мы хотим, чтобы она была полностью рассмотрена в течение следующих нескольких недель и увидела надлежащую реализацию в следующем выпуске.

@martonmiklos Вы добавляете send_recv и отправляете команду и пробуете _read_ 32-битные данные из stlink вместо _write_ их. Stlink устройство ожидает данные, но мы пытаемся их прочитать.
Думаю, нужно вернуться к:

int _stlink_usb_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {
    /* data must be a multiple of 4 and word aligned */
    if (len % 4 || addr % 4) {
        printf("[!]Invalid data alignment");
        return -1;
    }

    struct stlink_libusb * const slu = sl->backend_data;
    unsigned char* const data = sl->q_buf;
    unsigned char* const cmd  = sl->c_buf;
    int i, ret;

    i = fill_command(sl, SG_DXFER_TO_DEV, len);
    cmd[i++] = STLINK_DEBUG_COMMAND;
    cmd[i++] = STLINK_DEBUG_WRITEMEM_32BIT;
    write_uint32(&cmd[i], addr);
    write_uint16(&cmd[i + 4], len);
    ret = send_only(slu, 0, cmd, slu->cmd_len);
    if (ret == -1)
        return ret;
    ret = send_only(slu, 1, data, len);
    if (ret == -1)
        return ret;

    return _stlink_usb_get_rw_status(sl);
}

@ Ant-ON, вы правы, я упустил из виду поведение OpenOCD.

Я обнаружил разницу в OpenOCD в команде запуска, а также в том, что я реализовал, но ядро ​​все еще не остановилось.

Как ни странно, регистр управления остановкой отладки и состояния всегда остается 0x90001 с V3, в то время как с V2 он начинается с 0x41001 и устанавливается на 0x43003, когда ядро ​​останавливается.

@martonmiklos, возможно, вы отлаживаете другое ядро. Это значение имеет четкое значение для Cortex-M3 DHCSR (и некоторых других ядер).

Я смотрел код еще несколько раз, но не нашел критических отличий.

Может быть, попробовать после записи проверить конфигурационный регистр чтения загрузчика? (это проверка правильности операции чтения / записи регистра)
Также можно попытаться прочитать регистр ПК после каждой попытки чтения состояния ядра. Возможно, ядро ​​остановлено, но мы не получаем реального статуса ядра.

Незначительные комментарии. Это поддержка break V1, думаю нужно вернуть 0.

int _stlink_usb_get_rw_status(stlink_t *sl)
{
    if (sl->version.jtag_api == STLINK_JTAG_API_V1)
        return -1;
...
}

В исходном коде stlink второй вызов send_only имеет значение второго аргумента 1. Это может нарушить поддержку V1 (если он все еще работает ...).
`` С ++
int _stlink_usb_write_mem32 (stlink_t * sl, uint32_t addr, uint16_t len) {
...
ret = send_only (slu, 0, cmd, slu-> cmd_len);
если (ret == -1)
return ret;
ret = send_only (slu, 0, данные, len);
если (ret == -1)
return ret;
...
}

Позвольте мне попросить _ снова_ объединить текущие изменения из develop в соответствующий PR.
Мы склонны рассматривать проблемы, которые также были каким-то образом решены или отредактированы @grevaillot или могут быть связаны с недавними изменениями, внесенными им, которые уже были объединены.
Я не хотел бы, чтобы связанный PR вместе с его ветвью уходил от develop дальнейшем. Я не хочу разрешать существующие конфликты, так как я уже теряю понимание того, какие изменения-различия взять из какой ветки.

@ Nightwalker-87 К вашему сведению: слияние не решило проблему.

Что ж, по крайней мере, это разрешило конфликт слияния и гарантирует, что эта ветка будет с последней кодовой базой. Хотя связь могла быть. На момент написания я не мог этого исключить.

Привет народ!

Я снова начал работать над этим, но был удивлен: мне удалось запрограммировать bluepill с моим V3 из ветки разработки.

Я проверил файл usb.c (где была проделана большая часть реализации V3), но я даже не вижу виноватых в моем объединенном коммите, и, как я вижу, многие вещи там изменились.
Помимо изменений кода st-link, я также должен отметить, что моя прошивка V3 обновлялась несколько раз с тех пор, как я последний раз работал над этим. Для справки я использую версию V3J6M2B4S1.

Итак, ребята, пожалуйста, протестируйте свое оборудование V3 с различными микроконтроллерами и, если все в порядке, закройте эту проблему: smiley:

К вашему сведению: я проверил свой исходный коммит, в котором программирование flash не удалось, и теперь он работает OOTB, так что это должно быть улучшение прошивки V3. Мы могли бы либо выполнить понижение версии прошивки V3 один за другим и проверить, в какой точке он выйдет из строя, либо, проще говоря, мы могли бы реализовать проверку версии, чтобы пользователи запускали как минимум версию V3J6M2B4S1.

~ И, кстати,. мы также должны немного улучшить вывод st-info, чтобы распечатать аппаратное обеспечение STLink и версию прошивки, прежде чем мы скажем, что эта функция завершена. ~

Привет, @martonmiklos. Да, с тех пор было сделано несколько вкладов.
@ all: проверьте текущую ветку develop с аппаратным обеспечением программатора V3 ST-LINK и предложите дальнейшие улучшения, которые кажутся необходимыми. Также проверьте прошивку программатора и сообщите, работает ли эта функция с соответствующей версией. Я также хотел бы закрыть эту тему, но предпочел бы сделать это с окончательным PR, чтобы иметь возможность прикрепить к нему все связанные проблемы.

Спасибо за вашу работу. я понимаю, что нахожусь в этой теме, потому что я думал
у меня было бы время внести свой вклад, но бах ... год пролетел незаметно.

по крайней мере, я могу помочь вам протестировать: просто программировать bluepill с чем-то
Я валялся.

на хозяине я получаю

$ ../stlink/build/Release/bin/st-flash --format ihex записать main.hex
st-flash 1.6.1-1-gbaab8ca
2020-12-20T20: 51: 36 ИНФОРМАЦИЯ common.c: F1xx Средняя плотность: 20 КиБ SRAM, 64 КиБ
прошить как минимум на страницах размером 1 КиБ.
2020-12-20T20: 51: 36 INFO common.c: Попытка записи 21860 (0x5564) байт
на адрес stm32: 134217728 (0x8000000)
2020-12-20T20: 51: 36 INFO common.c: Флэш-страница по адресу: 0x08000000 удалена
[.... куча похожих строк удалена ....]
2020-12-20T20: 51: 37 INFO common.c: Флэш-страница по адресу: 0x08005400 удалена
2020-12-20T20: 51: 37 INFO common.c: Завершено стирание 22 страниц из 1024
(0x400) байт
2020-12-20T20: 51: 37 INFO common.c: Запуск записи Flash для VL / F0 / F3 / F1_XL
основной идентификатор
2020-12-20T20: 51: 37 INFO flash_loader.c: загрузчик флеш-памяти успешно загружен
в sram
Написано 22/22 страницы
2020-12-20T20: 51: 38 INFO common.c: Начало проверки записи завершено
2020-12-20T20: 51: 38 ИНФОРМАЦИЯ common.c: Flash написан и проверен! весьма неплохо!

$ ../stlink/build/Release/bin/st-info --probe
Найдено 1 программистов stlink
серийный: 303636464646353335353530373535313837323434313430
hla-серийный номер:
"x30x36x36x46x46x46x35x33x35x35x35x30x37x35x35x31x38x37x32x34x34x31x34x30"
flash: 0 (размер страницы: 0)
sram: 0
идентификатор чипа: 0x0004

еще в разработке:

$ ../stlink/build/Release/bin/st-flash --format ihex записать main.hex
st-flash 1.6.1-197-g4918223
2020-12-20T20: 55: 35 WARN common.c: Неверный тип вспышки, проверьте устройство
декларация

Люкс- новый- mbp
- зонд
Найдено 1 программистов stlink
версия: V2J25S13
серийный: 303636464646353335353530373535313837323434313430
hla-серийный номер:
"x30x36x36x46x46x46x35x33x35x35x35x30x37x35x35x31x38x37x32x34x34x31x34x30"
flash: 0 (размер страницы: 0)
sram: 0
идентификатор чипа: 0x0000
descr: неизвестное устройство

Стандартный, который я использую изо дня в день:

$ st-info --version
v1.5.1
$ st-info --probe
Найдено 1 программистов stlink
серийный: 303636464646353335353530373535
openocd: "x30x36x36x46x46x46x35x33x35x35x35x30x37x35x35"
вспышка: 65536 (размер страницы: 1024)
sram: 20480
идентификатор чипа: 0x0410
описание: F1 Устройство средней плотности

На Nucleo-H7745ZI-Q,

$ ../stlink/build/Release/bin/st-info --probe
Найдено 1 программистов stlink
версия: V3J2
серийный: 303034453030333933313337353130443339333833353338
hla-серийный номер:
"x30x30x34x45x30x30x33x39x33x31x33x37x35x31x30x44x33x39x33x38x33x35x33x38"
вспышка: 2097152 (размер страницы: 131072)
sram: 131072
идентификатор чипа: 0x0450
описание: H74x / H75x

так что хорошо! Я скоро начну писать для него код.

есть одна вещь, которую я заметил ранее, но я не уверен, есть ли у вас
это не сломано, не чините это политика, поэтому я просто включаю патч здесь как
вложение, и вы можете увидеть, хотите ли вы этого (мне не нужен кредит) или игнорируете
Это. в основном это
https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html вместо этого
из http://www.ibm.com/developerworks/aix/library/au-endianc/index.html

С уважением / Луук

Op zo 20 дек. 2020 ом 13:13 schreef nightwalker-87 < [email protected]

:

Привет, @martonmiklos https://github.com/martonmiklos . Да, был
мало вкладов с тех пор.
@ all: проверьте текущую ветку разработки с помощью V3 ST-LINK
программатора и предлагать дальнейшие улучшения, которые, по всей видимости,
необходимо. Также проверьте прошивку вашего программатора и сообщите, есть ли эта функция
работает с соответствующей версией. Я бы хотел закрыть это
тема-тема тоже, но предпочел бы сделать это с окончательным PR, чтобы быть
возможность прикрепить к нему все связанные вопросы.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/stlink-org/stlink/issues/820#issuecomment-748599836 ,
или отказаться от подписки
https://github.com/notifications/unsubscribe-auth/ACIGICZN7TVSLVUTXHUJK5TSVXS5XANCNFSM4IG5F6WA
.