命令行输出:
> st-flash write dioda.bin 0x08000000
st-flash 1.6.0-311-ga98b094
2020-05-17T17:59:37 INFO common.c: F0xx: 8 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
file dioda.bin md5 checksum: d3ad84699b33f431b86a77e53b16b11a, stlink checksum: 0x0000080b
2020-05-17T17:59:37 INFO common.c: Attempting to write 56 (0x38) bytes to stm32 address: 134217728 (0x8000000)
2020-05-17T17:59:37 INFO common.c: Flash page at addr: 0x08000000 erased
2020-05-17T17:59:37 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-05-17T17:59:37 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-05-17T17:59:37 INFO flash_loader.c: Successfully loaded flash loader in sram
2020-05-17T17:59:37 ERROR flash_loader.c: flash loader run error
2020-05-17T17:59:37 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
预期/描述:
期待它当然被闪现。 更多信息:
也许我知道这里有什么问题。 你可以试试我的分支吗(快速而肮脏的修复,作为我想法的证明)?
https://github.com/chenguokai/stlink/tree/stlink-v3_pre
如果我是对的,这个问题与新 flashloader 的非 PIC 代码以及 flashloader.c 中的脏修复有关。
你可以试试我的分支吗(快速而肮脏的修复,作为我想法的证明)?
我已经从您的分支构建并且可以确认,它解决了问题。
@chenguokai :我们这里有什么?
正如我所提到的,GPL 许可的 flashloader 是 PIC(位置无关代码),而新的则不是。 这也是为什么我需要编写一个链接描述文件,指定基地址。
通过反汇编编译的 flashloader,我识别出寻址模式与 PC(程序计数器)相关。 我认为它们是 PIC 的一种,所以我在 flashloader.c 中保留了肮脏的 hack 作为 marco。 从这个问题,我可以确认 flashloader 代码绝对不是 PIC,所以这两个 nop 应该添加到 flashloader 代码中,而不是附加在二进制文件之前。
好的,您可以提交 6 月发布的 PR,但请确保分支develop
而不是我在上次 PR 后删除的stlink-v3_pre
。 我不知道这是否会导致任何副作用。
@grzegorz-kraszewski 请验证我的 PR 是否解决了这个问题:-)
@grzegorz-kraszewski 请验证我的 PR 是否解决了这个问题:-)
不确定,因为它会触发另一个:
> st-flash write ~/dioda_f030.bin 0x08000000
st-flash 1.6.0-314-g273e798
2020-05-18T10:59:30 WARN common.c: unknown chip id! 0x374b
Failed to connect to target
@grzegorz-kraszewski:这看起来像是一个不同的话题。 请为此开一张新票。
不确定,因为它会触发另一个:
重新启动或拔下插头有帮助吗?
最有用的评论
我已经从您的分支构建并且可以确认,它解决了问题。