打印
[STM32F1]

香主:芯片STM32F103加密后,还能更新IAP代码吗?

[复制链接]
4115|12
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
泰山特曲123|  楼主 | 2014-5-2 11:57 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
芯片STM32F103已经加密,产品已经发给国外客户,可以通过IAP升级APP,但现在想把位于FLASH前面的IAP代码修改,有可能吗?
沙发
Simon21ic| | 2014-5-2 13:06 | 只看该作者
有可能

使用特权

评论回复
板凳
mmuuss586| | 2014-5-2 13:33 | 只看该作者
1、你的IAP程序支持不,不支持吧应该;
   
2、通过其它方式烧写IAP,估计操作会比较麻烦吧;

使用特权

评论回复
地板
kseeker| | 2014-5-2 18:28 | 只看该作者
按道理说,你另做一个iap,作为app烧写到app区,然后跳转过去把原来的iap作为app改了就好了,惟一的问题是如果中间出错,比如断了电,片子就挂掉了。

使用特权

评论回复
5
泰山特曲123|  楼主 | 2014-5-2 22:11 | 只看该作者
kseeker 发表于 2014-5-2 18:28
按道理说,你另做一个iap,作为app烧写到app区,然后跳转过去把原来的iap作为app改了就好了,惟一的问题是 ...

如果芯片没有加密,已经可以实现通过APP修改IAP代码,蛋疼的是读保护后会自动将前面两个页写保护,这个写保护要去除读保护才能解掉,曾试过在RAM中运行APP来解保护,但解保护后要复位才生效的。

使用特权

评论回复
6
guet_new_man| | 2014-5-2 22:45 | 只看该作者
首先,不知道你的APP是怎么做的??
其次,你这个问题可以归结为boot与APP相互升级的问题, 如果设计的代码具备此功能,就应该既APP支持升级boot代码、同时boot代码也可以升级APP,(当然,中间可能也包括一些备份等环节)。

使用特权

评论回复
7
guet_new_man| | 2014-5-2 22:47 | 只看该作者
补充一点,IAP(包含“BOOT升级APP”和“APP升级BOOT”)跟是否打开闪存的读保护没有任何关系, 闪存的读保护只是为了保护你的板子不会被别人通过JTAG、SWD口读取出来而已。

使用特权

评论回复
8
泰山特曲123|  楼主 | 2014-5-4 07:33 | 只看该作者
guet_new_man 发表于 2014-5-2 22:47
补充一点,IAP(包含“BOOT升级APP”和“APP升级BOOT”)跟是否打开闪存的读保护没有任何关系, 闪存的读保 ...

stm32f1xx读保护会自动将flash前面几个页写保护的,所以导致升级不了boot,如果芯片没有读保护的话,已经可以实现升级boot了!

使用特权

评论回复
9
coslight| | 2014-5-4 08:06 | 只看该作者
关注

使用特权

评论回复
10
lr2131| | 2014-5-4 09:32 | 只看该作者
kseeker 发表于 2014-5-2 18:28
按道理说,你另做一个iap,作为app烧写到app区,然后跳转过去把原来的iap作为app改了就好了,惟一的问题是 ...

对,就是有这样的风险,我之前也有遇到这样的问题。

使用特权

评论回复
11
王紫豪| | 2014-5-4 10:16 | 只看该作者
为了避免风险, boot还是不要轻易能改;不然客户断电,只能通过 isp或者 调试口烧写了,这样烧写代码就暴露了

使用特权

评论回复
12
guet_new_man| | 2014-5-5 10:19 | 只看该作者
泰山特曲123 发表于 2014-5-4 07:33
stm32f1xx读保护会自动将flash前面几个页写保护的,所以导致升级不了boot,如果芯片没有读保护的话,已经 ...

这个倒没注意过,按说读保护不会跟写保护挂钩。但是,如果确实有这种情况的话,你可以选择另外一种折中的方案,把boot做成分两步引导:第一步引导就放在闪存的最前面,这块以后就不要动了,它的作用纯粹是占用所谓的可能被写保护的区域,当然也负责跳转到第二步;第二步就是真正的boot,而且具备与升级APP有关的功能。  最后,再由第二步跳转至第三步APP部分。

使用特权

评论回复
13
guet_new_man| | 2014-5-5 10:53 | 只看该作者
重新翻了一下stm32f1xx的闪存操作手册,打开读保护之后,确实看到flash的最前面四页或两页会自动配成写保护。如下:

2.4.1 Read protection
The read protection is activated by setting the RDP option byte and then, by applying a
system reset to reload the new RDP option byte.
Note: If the read protection is set while the debugger is still connected through JTAG/SWD, apply a
POR (power-on reset) instead of a systemreset (without debugger connection).
Once the protection byte has been programmed:
● Main Flash memory read access is not allowed except for the user code (when booting
from main Flash memory itself with the debug mode not active).
Pages 0-3 (for low- and medium-density devices), or pages 0-1 (for high-density and
connectivity line devices)
are automatically write-protected. The rest of the memory can
be programmed by the code executed from the main Flash memory (for IAP, constant
storage, etc.), but it is protected against write/erase (but not against mass erase) in
debug mode or when booting from the embedded SRAM。

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

13

主题

327

帖子

1

粉丝