请选择 进入手机版 | 继续访问电脑版
查看: 907|回复: 0

比特世界病虫害防治指南(一)

[复制链接]
  • TA的每日心情
    开心
    3 天前
  • 签到天数: 266 天

    [LV.8]以坛为家I

    3296

    主题

    6541

    帖子

    0

    管理员

    Rank: 9Rank: 9Rank: 9

    积分
    31904
    最后登录
    2024-3-28
    发表于 2021-5-21 12:35:43 | 显示全部楼层 |阅读模式
    比特世界病虫害防治指南(一)

    两周前,本站有一篇杰作“那个讨厌的HardFault,看你往哪里跑!”,今天开始我来更深入地探讨一下这个Fault机制。

    人们常说,幸福的家庭都是相似的,不幸的家庭各有各的不幸。然而,如果是咱们MCU工程师的家庭,不幸之处却也常常相似——主要成员常年被各种软、硬件结合的玄妙问题所虐,胸有邪火,心无人伦,眼睛盯的是屏幕和板子,手上写的不是人话而是C语言,屁股底下抹胶水,积累各种家庭矛盾,也让局部地区灾害多发。哎,这晦涩的嵌入式开发还真是让人爱恨交加呀!
    不过,如果是在Cortex-M上干活,却有一个专属的“福报”,利用好的话能大大地解救咱们于水火。那就是时常陪伴我们左右,却想说爱你不容易的——“Hard Fault”!
    说Hard fault是福报,倒不是在于它为咱们带来了更多的996,恰恰相反,而是它给咱们带走了更多的996。
    HardFault就像是比特世界里的超级巡警,让咱们撸码时播下的很多病虫害失去了肆意破坏的机会,刚开始作祟,就被逮个正着了。而早年很多单片机的架构,因为CPU缺少异常处理的机制,就算程序执行非法指令、访问错误的地址,也置若罔闻,放任它们搞花样百出的破坏,而可怜的工程师就只能从更扑朔迷离的后果中,自己绞尽脑汁地探求原因了。
    其实,在主流和高档Cortex-M系列CPU上,如M3, M4, M7, M33,以及最新的M55,Hard fault是一众faults的“民意代表”(在M0, M0+, M22上,则只有Hard fault)。强大的Cortex-M CPU能够识别出多达15种异常的执行状态,并且把它们分为三大类fault,分别对应:
    ·总线事务出错 (Bus Fault),
    ·访问禁止的地址(MemManage Fault),
    ·以及对CPU的无效的使用方式(Usage Fault)。

    这三大类fault在向量表中都有自己的一席之地,指派处理函数。

    不过,大多数系统中常常只有单个异常处理的总衙门,所以很多程序都按照默认的设置,禁用了各自“基层”fault入口。这些fault于是就由Hard Fault来代表了,并且由Hard Fault的处理函数统一接管。就算它们各自已经启用,只要是由于优先级不够高之类的原因无法马上执行,也会上诉到Hard fault那里。

    Bus fault, MemManage fault, Usage fault, 以及它们的总代表——Hard fault,好比是程序中各种病虫害的四大缉事厂,协助咱们在Cortex-M的比特世界中除四害!

    Hard Fault的处理函数可不是好当的差事,如果说要应付15种异常状态时就够让小心肝发颤了,那要是这些状态有些还可以互相迭加呢,这还让不让人活了?

    俗话说,風多不痒,债多不愁。既然这个Hard Fault是这么个烫手山芋,干脆就束手打转吧!君不见很多程序框架的模子中,Hard Fault的处理函数不就是用个“B  .”来原地打转吗?

    体贴一点的,HardFault处理程序会收集现场的寄存器并打印出来,到串口上,或者像上一篇那样打印到gdb神器的控制台上,然后,就没有然后了…… 哦不,然后就靠你了。

    说到这里不能不衷心地表一表armink同学,他开发了一套叫cmbacktrace的开源库,带来保姆级的HardFault辅助分析功能。不但能以人类可读的方式打印出是哪一种异常状态;还从栈中往前翻出在出事时的层层函数调用关系。

    不过,辅助程序再强大,也只是带给我们更多线索,无法替代工程师的思考,还是得面对15种异常状态和它们的组合。

    别怕,咱们肩膀上顶着世界上最强大的深度神经网络——自己的大脑!可以把程序中两手一摊的麻烦事给接过来。而且,虽说CPU能捕捉15种异常状态,并且还可以叠加,看似千变万化,实则有规可循。还有最重要的,那就是程序中病虫害的高发地,常常是指针误用、数组越界、地址不对齐、栈溢出这些常见的情况。这其实也常常是拜C语言的“一切相信程序员”的哲学所赐:咱们在享受至高无上的折腾系统的权力时,也要承受一丝不苟的伺候系统的义务。

    那么,接下来,就让小编和大家一起揭开调试Hard Fault的不太神秘的面纱,顺着CPU提供的线索,把事故现场尽量完整地还原出来。

    故事的第一步,就是要知道CPU在发生Fault时,都干了些什么。

    其实说来也简单,Fault是异常的一种,而CPU处理异常的流程和处理中断几乎是一样的。其中的重头戏,都是自动地把8个寄存器压入到出事前正在使用的栈区(可能有同学会问如果是栈指针无效导致的fault呢,嗯,这个后面咱们再杠),然后改用由MSP所指示的主栈区,最后跳转到由向量表中HardFault入口指定的地址处执行。这8个寄存器都是什么,各自压在哪里,咱们最好烂熟于心。这里小编整理了一个图:
    1.png
    这里利用了KEIL的一个强大的调试功能:通过在Memory Window中输入寄存器的名字,就能自动跳到寄存器中的地址。

    与中断不同的是, CPU还会根据具体的异常原因来设置几个重要的寄存器,来告知这15种异常状态中的哪些种发生了,这个寄存器就是大名鼎鼎的CFSR,位于CPU的SCB空间。

    在CMSIS库中,可以使用SCB->CFSR来读取。CFSR中有很多位,散落在32个位之中,看起来零乱不堪。更何况调试工具一般用8个16进制数来表示它们,让人类解码显然是强人所难。

    于是,包含cmbacktrace库在内的一些体贴点的HardFault处理程序,把它们转换成人类易读的形式了。常见的IDE也常常有些可视化的处理。

    这不,在KEIL下的调试会话中,就可以打开”Fault Reports”窗口,像这样:
    3.png
    上图中粉红色背景的就是这15种异常情况,哪个打了勾,就表示哪种异常情况发生了。备注:细心的读者可能发现其实图上有17个框,但是”BFARVALID”和“MMARVALID”用于提供额外信息,并不是独立的错误状态,不能算。
    有了事故现场,就可以继续分析啦,就算找不出最终根源,根据这些线索一般也能找出直接原因。不过,这也是难啃的部分,好在实际情况是几种常见情况出现得最频繁。由于篇幅所限,这部分就容小编在后面一一展开介绍吧,一定要看哦!


    签到签到
    回复

    使用道具 举报

    您需要登录后才可以回帖 注册/登录

    本版积分规则

    关闭

    站长推荐上一条 /4 下一条

    Archiver|手机版|小黑屋|恩智浦技术社区

    GMT+8, 2024-3-29 07:07 , Processed in 0.100507 second(s), 20 queries , MemCache On.

    Powered by Discuz! X3.4

    Copyright © 2001-2021, Tencent Cloud.

    快速回复 返回顶部 返回列表