【问题标题】:Segger Jlink flash download mechanismSegger Jlink flash下载机制
【发布时间】:2021-04-28 17:27:25
【问题描述】:

我正在使用 Rohitab 出色的 API 监控工具来监控 Keil uVision 对 Segger 的 JLinkARM.dll 进行的 DLL 调用,以便我可以在自动化测试环境中复制它们。

作为其中的一部分,我试图了解 uVision 与闪存加载程序通信以下载正在调试的图像的机制。

我知道 uVision 下载是一个闪存加载程序到目标设备的 RAM,并且加载程序与板载闪存交互以擦除它并下载新图像,尽管我很难看到从 uVision 发出的 DLL 调用实际上将图像流式传输到闪存加载器。

我本来希望看到一大堆JLINKARM_WriteMem 调用来流式传输数据,但我没有。我可以看到一堆JLINK_WriteRegJLINK_ReadReg 调用,但不足以构成图像。我的猜测是它们用于监视闪烁过程。我知道 Jlink 支持许多与 Flash 下载相关的 API,但我没有看到它们在这里使用。我也没有看到任何经过的路径。 JLink 自己的日志文件在这里同样没有帮助。我在这里缺少一些带外机制吗?

【问题讨论】:

  • 您为什么不简单地在命令行模式下调用 Segger 自己的 J-Flash 工具?甚至是命令行模式下的 uVision 本身:keil.com/support/man/docs/uv4/uv4_commandline.htm。您似乎没有什么理由想要对此进行逆向工程,而且当这两种工具都支持数百个部件时,您设计的任何解决方案都将针对该部件。
  • 好点。我可能会走那条路。过去,我在 Jlink DLL 周围使用了 Python 包装器,这对于创建有效的回归测试平台效果非常好。我问了这个问题,因为我不清楚机制。这更多是出于好奇,而不是会真正阻止我前进的事情。

标签: embedded keil segger-jlink apimonitor


【解决方案1】:

对不起。我不应该在累的时候发这样的问题。 JLINKARM_WriteMem 正是使用的机制。我不知道为什么我第一次尝试时没有看到它们。

【讨论】:

    猜你喜欢
    • 2012-08-08
    • 1970-01-01
    • 2014-09-19
    • 1970-01-01
    • 2020-07-03
    • 2019-11-01
    • 2014-05-16
    • 2010-12-01
    • 1970-01-01
    相关资源
    最近更新 更多