探究STM32H7芯片IAP跳转失败案例

有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区。
难道是这个差别导致跳转的不同结果?当然,这两个sram区在使用上还是有差异的。
我尝试着将测试工程的默认sram区从tcm ram也改成axi sram进行测试。果真没法实现从boot区到app区的跳转!看来跳转失败跟选择这个默认sram区有关系。也就是说当我默认使用dtcm ram时跳转正常,如果默认使用axi sram时会跳转失败。
我们知道,stm32h7系列芯片支持d-cache/i-cache。具体到这里,如果使用axi sram往往会用到d-cache。我们的工程代码里也的确开启了d-cache,如果是因为这个原因,如果在做跳转操作之前关闭d-cache应该就能实现正常跳转。 于是对代码稍加调整,实际上也就是加了句关闭d-cache的代码。【红色方框处】
再次进行测试,此时即使使用axi ram做为默认内存空间,从用户boot区也能可靠跳转到app区,完美实现。
这里涉及到stm32h7系列芯片内部不同存储区的访问特性和d-cache相关知识,细节还是挺多的。有兴趣的话,可以自行查看相关技术手册做进一步的了解和探究。有时间,后续将在这里做进一步交流。此时分享该应用案例,一做应用提醒,二做抛砖引玉。

智慧农业解决方案:温室智能监控物联网系统
专家观点:车载电子为“主动安全”护航
电源模块中纹波和噪声的区别介绍
科创板交控科技董事、副董事长王燕凯介绍、履历信息
助力SiC功率半导体国产化替代,美浦森和泰克携手产业链合作共赢
探究STM32H7芯片IAP跳转失败案例
SAR型ADC的RC滤波器设计
iPhone8什么时候上市?iPhone8最新消息:iPhone8、iPhone7S、iPhone7SPlus配置、价格对比,iPhone8有何优势?
分布式电压接线异常在线监测技术实现
YouTube 宕机期间,谷歌损失了约 170 万美元
DRAM合约价续涨 4GB模组均价站上18美元大关
海南省设立首支科技成果转化投资基金
科技创新为我们燃起了新希望“无镜头”的成像技术
现实世界会是计算机程序虚拟生成的吗?
薄膜表面瑕疵在线检测系统的原理、参数及功能
SiC在电动汽车有哪些应用
侧面指纹和屏幕指纹谁才是更快的触控识别技术
简单易制的STC单片机ISP下载线,ISP PROGRAMMER
芯片价格战日趋白热化集成电路产业未来路在何方?
无线开关量模块使用注意事项