嘿,
如果我使用STM32H753i-EVAL板检查 ST-Link,则会出现以下消息:
> st-flash write arm_app.bin 0x8000000
st-flash 1.4.0-14-gfbd55d9
2018-02-20T13:39:55 INFO common.c: Loading device parameters....
2018-02-20T13:39:55 WARN common.c: Invalid flash type, please check device declaration
...
确实无法识别芯片 ID:
> st-info --chipid
0x0000
我想这里的问题是在chipid.c
中根本不包含 H7。
是否有计划也用 stlink 支持这些设备?
目前不支持。 Chipid 读数为零,因为可能读取了错误的寄存器并返回零。 如果您愿意,可以尝试添加它。
好吧,是不是只有chipid.c里面的东西需要查出来? 或者我还必须修改其他部分吗?
我假设我们需要为 h7 添加一个 flashloader https://github.com/texane/stlink/tree/master/flashloaders
我不确定,如果我错了,希望有人可以纠正我。 仍在研究 st-flash 依赖项到底是什么。
我们需要找到正确的位置来读取chipid,然后我们选择flash loader。 组装中有一小部分在 RAM 中运行,另一部分在 PC 上运行。 这是一次深潜,但可能值得付出努力。 同时,您还可以将 openocd 与 gdb 一起使用,它可能已经支持 H7 芯片变体。
我可能没有时间为此做出贡献,因为我能够通过 openocd 满足我的需求。 我需要一种命令行方式来构建二进制文件,使用 ST-Link 将其闪存到目标 STM32H7 并运行可执行文件,以便我可以自动执行回归测试。
我的步骤包括:
安装 AC6 eclipse http://www.openstm32.org/Downloading%2Bthe%2BSystem%2BWorkbench%2Bfor%2BSTM32%2Binstaller
在项目上使用 eclipse 收集运行启动器配置以及我需要的所有运行设置。
它为我生成的运行启动器是这样的(我去掉了注释,因为这里的代码格式不喜欢它们):
source [find interface/stlink.cfg]
set WORKAREASIZE 0x8000
transport select "hla_swd"
set CHIPNAME STM32H743ZITx
set ENABLE_LOW_POWER 1
set STOP_WATCHDOG 1
set CLOCK_FREQ 4000
reset_config srst_only srst_nogate connect_assert_srst
set CONNECT_UNDER_RESET 1
source [find target/stm32h7x.cfg]
使用 AC6 Eclipse,我看到了它使用的命令行执行。 我已经把它放在这里供您使用:
$AC6_INSTALL/plugins/fr.ac6.mcu.externaltools.openocd.linux64_1.17.0.201801121207/tools/openocd/bin/openocd -f YOUR_LAUNCH_CONFIG.cfg -s YOUR_PROJECT -s $AC6_INSTALL/plugins/fr.ac6.mcu.debug_2.1.4.201801121207/resources/openocd/st_scripts -c "program
YOUR_BINARY reset exit"
我可能可以做更多的研究来创建我自己的 openocd 配置并单独使用 openocd,但我认为这有效并且如果我不需要的话不想重新发明轮子。
嗨@johanderson我明白了。 OpenOCD 有更多的贡献者,并且与texane/stlink
工具的工作方式几乎相同。 感谢您的回复,祝您回归测试好运。
@xor-gate 我有一个 H7 板并做了一些初步的发现,
{
//RM0433 document was used to find these paramaters
.chip_id = STLINK_CHIPID_STM32_H74XXX,
.description = "H743xx device",
.flash_type = STLINK_FLASH_TYPE_F4,
.flash_size_reg = 0x1FF1E880, // section 61.2
.flash_pagesize = 0x800, // No flash pages
.sram_size = 0x100000, // "SRAM" byte size in hex from
.bootrom_base = 0x1FFF0000, //! "System memory" starting address from
.bootrom_size = 0x1E800 //! <strong i="6">@todo</strong> "System memory" byte size in hex from
},
STLINK_CHIPID_STM32_H74XXX = 0x450 /* Found on page 3069 in the RM0433
但是,在编译和运行st-util
我得到以下信息,所以我想我错过了一些东西
st-util 1.4.0-20-gaf4d2eb
2018-02-26T09:18:20 INFO common.c: Loading device parameters....
2018-02-26T09:18:20 WARN common.c: Invalid flash type, please check device declaration
2018-02-26T09:18:20 INFO gdb-server.c: Chip ID is 00000000, Core ID is 6ba02477.
2018-02-26T09:18:20 INFO gdb-server.c: Listening at *:4242...
可能核心没有停止或读取无效的chipid寄存器,这就是它读取0x00000000
。
@xor-gate mkay,关于从哪里开始寻找的任何提示,与flash_type
?
如前所述,chipid 是从 DBGMCU_IDC 寄存器中读取的,具有 DEV_ID[11:0] 位(数据表 RM0433 第 3069 页)。
DBGMCU 寄存器不会通过系统复位而复位,只能通过上电复位。 调试器可通过基址 0xE00E1000 处的 APB-D 总线访问它们。 它们也可由基地址 0x5C001000 处的两个处理器内核访问
它似乎没有在此处读取 DEV_ID 的正确寄存器: https : https://github.com/texane/stlink/blob/19691485359afef1a256964afcbb8dcf4b733209/include/stlink/chipid.h#L10
这意味着我们还需要读取 reg 0xE00E1000
。
@异或门
这意味着我们还需要读取 reg 0xE00E1000。
嗨,这会返回零,但是读取另一个地址 (0x5C001000) 会返回芯片 ID:
(gdb) call stlink_read_debug32(sl, 0xE00E1008, chip_id)
$16 = 0
(gdb) print *chip_id
$17 = 0
(gdb) call stlink_read_debug32(sl, 0x5C001000, chip_id)
$18 = 0
(gdb) print /x *chip_id
$19 = 0x10036450
@iabdalkader你可以试试这个分支https://github.com/texane/stlink/tree/stm32h7xx-improvements。 我花了一些时间来弄清楚如何以编程方式验证程序员正在与哪个核心交谈以及哪个 stm32 变体。 现在应该工作。 请参阅https://github.com/texane/stlink/blob/stm32h7xx-improvements/src/common.c#L592 -L602。
@xor-gate 嗨,我收到一条关于 stlink_core_id 中未初始化的 ret 的警告(被视为错误)。 将 ret 初始化为 0 或 -1 即可解决。 添加上面的芯片id和参数后,它的工作原理:
st-util 1.4.0-24-g20ec71a-dirty
2018-03-08T00:26:35 INFO common.c: Loading device parameters....
2018-03-08T00:26:35 INFO common.c: Device connected is: H743xx device, id 0x450
2018-03-08T00:26:35 INFO common.c: SRAM size: 0x100000 bytes (1024 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 2048 bytes
2018-03-08T00:26:35 INFO gdb-server.c: Chip ID is 00000450, Core ID is 6ba02477.
2018-03-08T00:26:35 INFO gdb-server.c: Listening at *:4242...
2018-03-08T00:26:38 INFO gdb-server.c: Found 8 hw breakpoint registers
2018-03-08T00:26:38 INFO gdb-server.c: GDB connected.
2018-03-08T00:26:41 INFO gdb-server.c: Found 8 hw breakpoint registers
但是断点不起作用。 这是我从 gdb 端运行的:
Remote debugging using :4242
brwarning: Overlapping regions in memory map: ignoring
e0x08068f60 in Reset_Handler ()
(gdb) break main
Breakpoint 1 at 0x8062a16
(gdb) monitor reset
(gdb) c
Continuing.
有任何更新吗?
只要 OpenOCD 还不能工作,您可能会更好地使用它。
进展如何? 什么是停止添加 STM32H7 支持? 我有什么可以帮忙的吗?
我的 stm32H743 Nucleo 板不能正常工作
$ st-info --probe
不显示信息
@SL-RU 没有进展,如果人们需要这个才能正常工作,必须有人站出来修复它。
@hggq您的问题与问题 #716 有关
你好。 有什么进展吗?
我做了一些修改并成功加载,制作断点和其他调试。 我会再测试一下,然后做公关;
@SL-RU 很棒!
你好。 还有人对这个话题感兴趣吗?
克隆了stm32h7xx-improvements分支并成功构建了它。 正如 iabdalkader 在 2018 年 3 月 7 日评论的那样,common.c 中的第 590 行存在一个问题,其中 int ret 应初始化为 (-1)。 不过很容易修复。 但是我在运行 st-util 时仍然得到未知的芯片 id 错误,即使 core-id 是正确的......似乎chipid.c/h 更新不是分支的一部分
olofwalker 于 2018 年 2 月 26 日评论,将此块添加到chipid.c
{
//RM0433文件用于查找这些参数
.chip_id = STLINK_CHIPID_STM32_H74XXX,
.description = "H743xx 设备",
.flash_type = STLINK_FLASH_TYPE_F4,
.flash_size_reg = 0x1FF1E880, // 第 61.2 节
.flash_pagesize = 0x800, // 无闪存页面
.sram_size = 0x100000, // 十六进制的“SRAM”字节大小
.bootrom_base = 0x1FFF0000, //! “系统内存”起始地址从
.bootrom_size = 0x1E800 //! @todo “系统内存”字节大小(十六进制)来自
},
并到chipid.h
STLINK_CHIPID_STM32_H74XXX = 0x450
@zainkamoi如果需要,请提供拉取请求,这是要走的路。 谢谢!
@zainkamoi这不是真正的问题...真正的问题是你需要在 asm 中编写 flash 上传器并深度修改 stm32h7 的所有内容,因为寄存器和核心与 F7 等完全不同......这是很多工作并且需要学习数据表和其他文档! 现在我只是使用 TrueStudio 的 gdb 服务器
有任何更新吗?
@SL-RU 您好,我已经进行了数据表研究,也许您可以将这些文件用作修改模板:
https://github.com/EmBitz/EBlink/blob/master/scripts/stmicro/stm32h7x.script
https://github.com/EmBitz/EBlink/blob/master/scripts/stmicro/flash/stm32h7_fl.script
我现在使用这些脚本在 H7 项目上工作了将近 10 个月,到目前为止没有任何问题。
最有用的评论
你好。 有什么进展吗?
我做了一些修改并成功加载,制作断点和其他调试。 我会再测试一下,然后做公关;