b13dfa590fcbcc032da1beeda80f3e76.png

有STM32用户反馈,他在使用STM32H750VB编写用户引导程序【BOOT CODE】和应用程序【APP CODE】。根据数据手册描述,STM32H750有128K Bytes的片内flash,地址是从0x0800 0000~~0x0801 FFFF。他将用户bootloader放在0x0800 0000~0x0800 2FFF,应用程序放在0x08003000~0x0801 FFFF。但当他按照这样的存储分配设计时,发现总是没法实现从BOOT区到APP区的跳转。

基于该用户的反馈信息,给他做了些提醒,比如中断矢量表定位问题,客户都说已经注意到了,代码应该没有问题。我这边就客户反馈的问题找了块STM32H743的板做了验证测试。发现从BOOT区到APP区的跳转并没有异常,那么客户怎么又有问题呢?

再次查看了客户邮件的反馈信息。他用的默认内部SRAM区为AXI SRAM,地址区间在0x24000000 --0x2407FFFF,即下面表格中的A区,而我使用的默认内部SRAM区是DTCM SRAM,地址区间在0x20000000 -0x2001FFFF,即下面表格中的B区。

e4e85b8ddc5e1d213fb5ff8693b68d26.png

难道是这个差别导致跳转的不同结果?当然,这两个SRAM区在使用上还是有差异的。

我尝试着将测试工程的默认SRAM区从TCM RAM也改成AXI SRAM进行测试。果真没法实现从BOOT区到APP区的跳转!看来跳转失败跟选择这个默认SRAM区有关系。也就是说当我默认使用DTCM RAM时跳转正常,如果默认使用AXI SRAM时会跳转失败。

3909ea659e34ad48d23a126e404c4a6b.png

我们知道,STM32H7系列芯片支持D-CACHE/I-CACHE。具体到这里,如果使用AXI SRAM往往会用到D-CACHE。我们的工程代码里也的确开启了D-CACHE,如果是因为这个原因,如果在做跳转操作之前关闭D-CACHE应该就能实现正常跳转。 于是对代码稍加调整,实际上也就是加了句关闭D-CACHE的代码。【红色方框处】

ced9cae2bc460058aca7c5ea6f28e42c.png

34bf51dc4cf80d81d24e6335e3213677.png

再次进行测试,此时即使使用AXI RAM做为默认内存空间,从用户BOOT区也能可靠跳转到APP区,完美实现。

这里涉及到STM32H7系列芯片内部不同存储区的访问特性和D-Cache相关知识,细节还是挺多的。有兴趣的话,可以自行查看相关技术手册做进一步的了解和探究。有时间,后续将在这里做进一步交流。此时分享该应用案例,一做应用提醒,二做抛砖引玉。

===================

往期话题链接:【点击即可查看】

1、STM32定时器单脉冲输出模式话题

2、多定时器同步输出的配置示例

3、STM32调试中跟工具有关的几个问题

4、一个跟地址对齐有关的应用异常案例

5、STM8 cosmic C 编译器免费版面世

6、STM8系列MCU开发应用中的常见问题

b0d001e19dbb07c8f2d64eb6f81776f7.png

Logo

DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐