Stlink: [特性] STLINK-v3：程序员支持

我也有严重的问题。 我刚从 StMicro 买了一个全新的 STLINK-V3SET 编程器/调试器。

• 编程器类型：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/Release$ 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 意法半导体
iProduct 2 ST-LINK/V3
iSerial 3 005200363137510239383538

有任何想法吗？
我真的被困住了。
提前致谢，

最大限度

我有同样的要求。

有没有人应该做些什么来支持STLINK-V3SET？ 请。

与@unclebanjoman相同，在 Ubuntu 18.04 LTS 上，我的系统检测到 V3 探测器，但st-info --probe返回 0 个设备。 我会调查一下，但我不能保证任何事情。

我有同样的要求。 我喜欢在 Makefiles 中使用“make flash”，但我也有点喜欢新的 v3。
我的具体错误（Windows 10，Cygwin）与 STLINK-V3SET 连接（并且可以使用 STM32CubeProgrammer 以及使用 STLINK Utility）：
st-flash --reset write 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 和配置正确端点的问题。 嗯，事情没那么简单，但多亏了 Antonio Borneo 在 openOCD 方面的出色工作，我设法更轻松地解决了这些差异。

我的代码住在这里：
https://github.com/martonmiklos/stlink/pull/new/add_stlink_v3_support

我还没有设法测试它（我家里有一个 mini，但没有带有 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 ：也许你们可以互相讨论一些更具体的测试，也可以参考我们的文档和“操作方法”以获得一些想法。 过几天我也会跳到这个。

我将把必要的东西放在一起，以便能够在执行期间进行调试。 我认为这将是最容易和最有效的。 非常感谢@WRansohoff和@kioan执行测试。

我是 github 等的小新手，所以如果有人能给我一些指导，那将非常有帮助。

我的系统正在运行 Debian。 有什么方法可以创建 debian 包来安装它？
这将允许我使用我已经在使用的环境来测试它（我刚刚开始使用Warren Gay 的书学习 STM32 开发，所以我使用他的 makefile 作为基本结构）

@kioan ：您可能会发现首先查看 /doc/compiling 并了解您的

1) 在项目主页面 fork repo：https://github.com/texane/stlink
2) Clone/Download 显示一个 git-link，您应该将其复制到剪贴板。
3）为您的 git-Projects 创建一个新的本地文件夹，并确保您安装了包git ，我认为已经是这种情况
4）通过终端cd进入新文件夹，然后输入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 软件包并安装了它们。 我尝试了过去与 stlinkv2 程序员一起使用的 makefile，但我遇到了我之前提到的相同错误。
至少现在我知道我可以测试你未来的补丁。

是的，你是对的 - 我忘了提到每个人_强烈鼓励_使用开发分支。

另见#863。

好的，我找到了一个带有“STLINK-V3E”调试器的 STM32G431“Nucleo”板，并在“develop”分支上试用了它。 他们在调试器中使用了 STM32F723！ 太糟糕了，他们没有在板上提供更多可用的芯片引脚，是吧？

无论如何，我可以使用st-flash使用简单的“闪烁 LED”程序使芯片闪烁，并且该程序在闪烁后运行时不会出错。

当我上传一个使用中断的程序时，问题就开始了； 当“闪烁 LED”程序使用“while”循环来延迟 LED 切换时，一切正常，但是当它使用SysTick中断时，ST-Link 之后似乎无法连接到调试器初始程序上传。 我收到各种异常错误，从“未知芯片 ID”到“无法解锁闪存”再到“闪存验证失败”。

也许调试器无法将芯片保持在复位状态足够长的时间，或者一旦进入调试状态就无法禁用中断？ 抱歉，我对内部运作的了解不够，无法做出更有根据的猜测。 为了使电路板恢复到工作状态，我需要使用 ST 分发的其中一种实用程序执行批量擦除。

当我尝试使用st-util打开调试连接时，我遇到了与@kioan报告的类似的错误。 连接似乎成功打开，但是当我连接到 GDB 中的目标时，它不提供可靠的数据，并且st-util应用程序会打印一堆“核心状态：未知”消息。

所以这就是我用 STLink-V3 测试当前的“开发”分支时发生的情况，但它看起来绝对是一个有希望的开始！ 并对延迟回复表示抱歉； 我最近一直在搬家，所以我的大部分微控制器东西都被打包带走了。

嘿！ 你最近还好吗？

无论如何，使用 Wireshark 和 usbmon 使用 STM32CubeProg 进行捕获会有帮助吗？

我使用 STLINK-V3SET 得到与https://github.com/texane/stlink/issues/820#issuecomment -591358679 相同的结果，但可以通过 STM32CubeProg 的 CLI 进行编程。 由于缺少库，我无法使用他们的 GUI。

最新源中的 OpenOCD 读取 DCB DHCSR 寄存器以检索状态
https://github.com/ntfreak/openocd/blob/bff1b6f05a56eed8e150c25d925bd51ca2840daf/src/jtag/drivers/stlink_usb.c#L1743

可能是解决问题“核心状态：未知”

嗨，大家好，

我为迟到的答复道歉。 我仍然没有设法在物理上调试整个事情。

@medicalwei我认为目前没有必要，我的工作场所和家里都有设备，所以如果我有时间做这件事，我可以调试它。

@Ant-ON OpenOCD Stlink 支持是使用 ST 的 NDA 保护文档编写的，所以这就是我的计划：如果我隔离有问题的点，我将查看 OpenOCD 代码。 （我添加的更改也是基于此。）

@martonmiklos ：没问题，花点时间。 我们不着急。 我只是要求保持正轨。

我有一块带有 STLINK-V3E 的 STM32H745 Nucleo-144 板。 有没有我可以挖掘的信息或要测试的东西来帮助你们所有人让它发挥作用？

@lvdlvd ：

但实际上两者都是具有可用未解决问题的计划功能。 我目前几乎无法判断两者中哪一个更难实现。 如果熟悉 H7 的人站出来并愿意做出贡献并因此获得支持，我可以为此更改当前的发布计划。 你们告诉我你喜欢什么，我可以满足需求。 和往常一样 - 欢迎任何帮助。 ：+1：

我认为让 stlink v3 在那件事上与 bluepill 一起工作会
是有效的第一步，一旦成功，我就可以查看 H7。

我需要一些周末来加快你的代码库的速度。

Op ma 30 地铁 2020 年 01:01 schreef nightwalker-87 <通知@github.com

：

@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

如果您查看 openOCD 中的 JTAG API 确定，就会发现 StLinkV2 使用 V2 API 并没有那么简单，但在某个 JTAG 版本之后，它也使用 V1：
https://github.com/ntfreak/openocd/blob/master/src/jtag/drivers/stlink_usb.c#L989

我总是有一种印象，如果我们直接包装 openOCD 代码，我们会更容易。 ：微笑：

@马顿米克洛斯

我总是有一种印象，如果我们直接包装 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;

在版本“V2J36M26 STM32 Debug+VCP”中更新 stlink v2.1 后，它已被 stvink v3 pid id 识别：

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，因此您发送命令并尝试从 stlink _read_ 32 位数据而不是 _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 以及我实现的内容有所不同，但核心仍未停止。

奇怪的是，调试停止控制和状态寄存器对于 V3 始终保持为 0x90001，而对于 V2，它从 0x41001 开始，并且在内核停止时设置为 0x43003。

@martonmiklos也许您正在调试不同的核心。 该值对于 Cortex-M3 DHCSR （和其他一些内核相同）具有明确的含义。

我又看了几遍代码，但找不到关键的区别。

可以尝试在写入后检查读取加载程序配置寄存器吗？ （检查正确的寄存器读/写操作）
也可以在每次尝试读取内核状态后尝试读取 PC 寄存器。 可能核心已停止，但我们没有获得真正的核心状态。

小评论。 这是中断 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 支持（如果它仍然有效......）。
```C++
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）
返回 ret;
ret = send_only(slu, 0, data, len);
如果（ret == -1）
返回 ret;
...
}

请让我_再次_将当前更改从develop合并到相关 PR 中。
我们倾向于查看@grevaillot也已以某种方式解决或编辑的
我不希望看到相关的 PR 及其分支远离develop我不愿意解决现有的冲突，因为我已经失去了从哪个分支采取什么变更差异的跟踪。

@ Nightwalker-87 仅供参考：合并没有解决问题。

好吧，它至少确实解决了合并冲突，并确保此分支使用最新的代码库。 虽然可能有关系。 在撰写本文时，我无法排除这一点。

嗨伙计！

我再次开始研究这个，但我感到惊讶：我设法用我的 V3 从开发分支编写了一个 bluepill。

我已经检查了 usb.c 文件（大部分 V3 实现都在那里完成），但我什至没有看到我的合并提交归咎于，而且我看到那里发生了很多变化。
除了 st-link 代码更改之外，我还需要注意，自从我上次处理此问题以来，我的 V3 固件已经更新了几次。 作为参考，我使用的是 V3J6M2B4S1 版本。

所以伙计们，请用各种 MCU 测试您的 V3 设备，如果一切顺利，请关闭此问题 :smiley:

仅供参考：我已经检查了闪存编程失败的原始提交，现在它可以在 OOTB 中运行，因此它应该是 V3 固件的改进。 我们可以在 V3 固件中逐一降级并检查它会失败的点，或者简单地说，我们可以实施版本检查以强制用户至少运行 V3J6M2B4S1 版本。

~顺便说一句。 在我们说这个功能完成之前，我们还应该对st-info的输出进行一些pimp，以打印出STLink硬件和固件版本。~

嗨@mar​​tonmiklos。 是的，从那以后有一些贡献。
@all：请使用您的 V3 ST-LINK 编程器硬件检查当前的develop分支，并建议似乎有必要的进一步改进。 还要检查您的编程器固件并报告此功能是否适用于相应版本。 我也想关闭此功能主题，但更愿意通过最终 PR 来完成此操作，以便能够将所有相关问题附加到它。

感谢您的工作。 我意识到我在这个线程上是因为我认为
我有时间做出贡献，但是噗……一年过去了。

至少我能做的是帮助你测试：只是用一些东西编程一个 bluepill
我躺着。

在主人我得到

$ ../stlink/build/Release/bin/st-flash --format ihex 写入 main.hex
st-flash 1.6.1-1-gbaab8ca
2020-12-20T20:51:36 INFO common.c：F1xx 中等密度：20 KiB SRAM，64 KiB
闪存至少 1 KiB 页。
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：开始为 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 INFO common.c：Flash 已写入并已验证！ 好开心！

$ ../stlink/build/Release/bin/st-info --probe
找到 1 个 stlink 程序员
序列号：303636464646353335353530373535313837323434313430
hla-串行：
“x30x36x36x46x46x46x35x33x35x35x35x30x37x35x35x31x38x37x32x34x34x31x34x30”
闪存：0（页面大小：0）
内存：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：闪存类型无效，请检查设备
宣言

Luuks-new- mbp:stm32f103_adc2serial lvd$ ../stlink/build/Release/bin/st-info
- 探测
找到 1 个 stlink 程序员
版本：V2J25S13
序列号：303636464646353335353530373535313837323434313430
hla-串行：
"x30x36x36x46x46x46x35x33x35x35x35x30x37x35x35x31x38x37x32x34x34x31x34x30"
闪存：0（页面大小：0）
内存：0
芯片编号：0x0000
描述：未知设备

我日常使用的股票：

$ 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 12 月 20 日 2020 年 13:13 schreef nightwalker-87 <通知@github.com

：

嗨@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
.