【中科蓝讯】从两次偶发死机,理解 com 区和 bank 区
刚接触中科蓝讯 SDK 时,我经常看到函数前面有 AT(.com_text.xxx)。一开始我只知道照着原有代码写,却不明白它为什么在这里。后来看了资料和工程里的写法,我才认识到:SDK 把代码分区域存放,不同区域的运行方式不一样。
这篇只是我目前从应用侧整理的一点理解,重点放在看到 AT(...) 时怎么读。
一、com 区和 bank 区有什么区别

按照官方资料的说明,芯片上电后,一部分代码会从 Flash 搬到 RAM 里常驻下来,这部分就是 com 区;剩下的代码继续待在 Flash,用到时才被加载到 bank 运行区。
| 区域 | 简单理解 | 适合放什么 |
|---|---|---|
com 区 |
上电后会加载到 RAM,并在运行期间常驻 | 中断函数、实时性要求高的 |
bank 区 |
代码存在 Flash,运行时按需加载到 bank 运行区 | 大多数普通应用逻辑 |
com 区的空间有限,所以不要因为更快,就把普通功能都放进去。
二、真正要注意的是中断和它调用的函数
中断函数和它调到的关键函数,通常需要放在 com 区。因为中断来了要马上处理,不能等到需要时再去加载代码。
在工程里看定时和一些中断相关代码时,我能看到类似下面的写法:
AT(.com_text.user)
void user_timer_isr(void)
{
// 中断中的处理
}
实际用的时候,我是先看同模块已有代码的写法,不凭空猜。但照抄还不够——踩过两次坑才知道,光盯着函数本身的 AT,容易漏掉更深层的依赖。
第一次是在中断里调了一个普通函数,我给那个函数加了 AT(.com_text.xxx),以为这就完事了。结果还是偶发异常。排查后发现,这个函数内部又调了另一个普通函数,那个子函数没加 AT。中断触发时 CPU 跳到 com 区,执行到嵌套的子函数时,它的代码还在 bank 区没加载进来,一样挂。这件事的风险在于,被调函数可能还调了其他函数,嵌套几层之后很容易漏掉。所以给函数加 AT 时,得顺着调用链往下检查,确保整条执行路径上的函数都在 com 区。如果调用深度比较大,更稳妥的做法是通过消息转发把逻辑放到其他线程执行,避免在 com 区里越套越深。
第二次是 printf 的格式字符串。我之前在 UART 中断里加 printf 调试,跑起来后出现了偶发性死机。排查时对比了同文件里其他中断函数的写法,才发现人家的格式字符串前面都带了 AT(.com_rodata...),就我新加的这一句没写。补上之后死机不再复现。回头想这件事,原因其实就回到 com 区和 bank 区的区别上:函数本身已经放在 com 区,但格式字符串如果不加 AT(.com_rodata...),就会被分配到 bank 区的只读段。中断触发时 CPU 直接跳过来执行,不会等 Flash 按需加载——字符串还没到位,访问就异常了。所以中断里加打印,不能只看 printf 调用本身,格式字符串的段属性也要和中断函数保持一致,都在 com 区才安全。
三、总结
回到一开始的问题:看到 AT(.com_text.xxx) 该怎么读?对我来说,它表达的就一件事——com 区执行路径上的所有东西,函数也好、字符串也好、调用的子函数也好,都得在 com 区,漏一个就可能偶发异常。
平时写普通应用逻辑,沿用什么都不加就行,SDK 默认放在 bank 区,不用每行代码都去想该放哪个区。但一旦涉及中断、定时回调这类对时机敏感的场景,加 AT 之前我会先想两件事:一是这个函数内部调了谁,整条调用链上有没有会漏掉的;二是这件事一定要在 com 区做吗,如果调用链太深,放消息转发到其他线程反而是更安全的选择。改完如果出现偶发性问题,代码放置位置就是一个排查方向。
现在再看 AT(.com_text.timer),我不会把它当成一串无意义的标记了——它是在提醒我:这段代码跑起来的时候,Flash 可能帮不上忙。
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐


所有评论(0)