【中科蓝讯】从两次偶发死机，理解 com 区和 bank 区

刚接触中科蓝讯 SDK 时，我经常看到函数前面有AT(.com_text.xxx)。一开始我只知道照着原有代码写，却不明白它为什么在这里。后来看了资料和工程里的写法，我才认识到：SDK 把代码分区域存放，不同区域的运行方式不一样。

这篇只是我目前从应用侧整理的一点理解，重点放在看到AT(...)时怎么读。

一、com 区和 bank 区有什么区别

按照官方资料的说明，芯片上电后，一部分代码会从 Flash 搬到 RAM 里常驻下来，这部分就是com区；剩下的代码继续待在 Flash，用到时才被加载到bank运行区。

com区的空间有限，所以不要因为更快，就把普通功能都放进去。

二、真正要注意的是中断和它调用的函数

中断函数和它调到的关键函数，通常需要放在com区。因为中断来了要马上处理，不能等到需要时再去加载代码。

在工程里看定时和一些中断相关代码时，我能看到类似下面的写法：

AT(.com_text.user)voiduser_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 可能帮不上忙。