logo

CH552上的v1.1与v2.31引导加载程序有问题

我通常在v1.1引导程序中使用CH552芯片。
因为很容易转储完整的Flash内容,所以在初次下载我的应用程序后禁用引导加载程序。
通过应用程序调用加载程序仍然是可能的。 我已经开发了自己的工具来访问加载器
因为wchisptool不允许更改No_Boot_Load位。
我还使用IAP和I_CALL(0x3FF4 0x57 0xA8 )对引导加载程序进行了一些更改
这对使用v2.31加载器的新CH552芯片不起作用,因为缺少I_CALL。 我还发现至少CH559使用了v2.31加载器,它仍然支持I_CALL。
所以这是一个问题:
为什么有相同版本但功能不同的加载器?
当我使用v2.31加载程序获得CH552芯片时,我该如何解决这个问题?

这人很懒,什么都没留下

image.png

禁用BOOT,需要修改BOOT里面的配置位,这个只有BOOT和编程器有修改权限,编程器是不向一般客户开放的,那么请问你是通过什么方式禁用BOOT的?

破解BOOT协议?

image.png这个是个什么工具?


image.pngIAP我能理解,I_CALL是什么意思?你这个是不是借助1.1BOOT的漏洞,上电运行IAP,然后修改BOOT配置位?

上面这种方法存在BOOT被读出的风险,V231特地做了优化,关闭这个功能,如果你是通过这个方法实现的,那么V231就已经不支持了。

其实如果你有定制需求,可以联系我们,不管是定制BOOT还是程序开发我们都可以支持。



025-89692393 e-mail:lb@wch.cn QQ:2542195643(请备注公司信息和简要需求描述)

我正在使用谷歌翻译,所以我不知道中文翻译有多好。 如果在这里可以,我宁愿写英文。
改变位很容易。 我不公开讨论细节:
我使用cmd 0xB9进行读取,使用cmd 0xB8进行写入。 我已经写了我自己的工具。
我需要禁用引导加载程序,否则很容易从芯片中读取完整的flashcontents。 对于16kbyte,这可能只需不到10分钟。 所以我需要这样做来保护我的代码。

  我不会在这里发布参考文献,但相信我阅读flashcontents比你想象的要容易得多

关于IAP,我会再做一个帖子。

这人很懒,什么都没留下

我可以在这里发送一个简单的flashdumper,它可以在CH551 ... CH554芯片上运行,并将内容保存为IntelHex和bin。
为了使它无用,我将每个第16个字节设置为0xFF。 所以它只能作为演示。

这人很懒,什么都没留下

我称之为I_CALL实际上是使用IAP时调用的keil c51 libfunction。
我使用IAP来定制引导加载程序主要是为了使访问引导加载程序功能更加困难,但也包含一些额外的功能。 因此我压缩了加载器(ACALL / AJMP LinkerCodePacking),删除了串行代码并优化了密钥处理。 这为自定义函数提供了大约400字节的额外空间。
仅用于测试我将加载器链接到0x3000。 这工作正常。 但新的CH552使用V2.31加载器,所以我的方法不适用于新芯片。

这人很懒,什么都没留下

如果你为了自用,既然1.1已经实现,建议订货时可以直接联系销售订购1.1版本的芯片;

V231BOOT 我们暂时没有资料开放。

025-89692393 e-mail:lb@wch.cn QQ:2542195643(请备注公司信息和简要需求描述)
只有登录才能回复,可以选择微信和github账号登录