程序运行一段时间后出现hardfault？CmBacktrace需要的是啥文件？

发布于 2020-12-05 16:33:27 浏览：2044 订阅该版

r00: 0xffffffff
r01: 0x20008c68
r02: 0x07ffffff
r03: 0x40008c64
r04: 0x00004394
r05: 0xdeadbeef
r06: 0xdeadbeef
r07: 0x20008ad0
r08: 0xdeadbeef
r09: 0xdeadbeef
r10: 0xdeadbeef
r11: 0xdeadbeef
r12: 0x00000000
 lr: 0x08004a4f
 pc: 0x0801eb64
hard fault on thread: mbtcp_te
thread   pri  status      sp     stack size max used left tick  error
-------- ---  ------- ---------- ----------  ------  ---------- ---
mbtcp_te  12  running 0x00000344 0x00000800    73%   0x00000003 000
Mb_RTUM_   9  suspend 0x000000d8 0x00000800    45%   0x00000008 000
Mb_RTUM_   8  suspend 0x00000180 0x00000800    57%   0x00000006 000
Mb_RTUS_   7  suspend 0x000001f8 0x00000800    30%   0x0000000a 000
tshell    20  suspend 0x00000184 0x00001000    09%   0x00000009 000
HC148_EX   6  suspend 0x000000a0 0x00000200    37%   0x00000032 000
wiz_stat  28  ready   0x000000b4 0x00000800    16%   0x00000014 -02
wiz        5  suspend 0x000000ac 0x00000200    71%   0x0000000f 000
sample_L  14  ready   0x000001e8 0x00000400    79%   0x00000011 000
sys_work  23  suspend 0x00000088 0x00000800    63%   0x00000001 000
tidle0    31  ready   0x00000088 0x00000100    53%   0x0000000d 000
timer      4  suspend 0x000000b0 0x00000200    88%   0x00000009 000
main      10  suspend 0x00000144 0x00000800    60%   0x00000004 000
bus fault:
SCB_CFSR_BFSR:0x82 PRECISERR SCB->BFAR:40008C00

附加：CmBacktrace跟踪时用的啥文件？我看文档上有的用的是”.out”文件，有的说是”.axf”,这个.axf文件在studio下如何生成？

2 个回答

aozima 2020-12-05

调网络不抓包，调I2C等时序不上逻辑分析仪，就像电工不用万用表！多用整理的好的文字，比截图更省流量，还能在整理过程中思考。

这日志上面原因和地址指示得非常精确了。

杰瑞鼠 2020-12-07

2025再接再励

mbtcp_te这个线程是基于W5500的libmodbus,用的是spi总线，这个知道，原来没什么问题的，我是想知道这属于什么类的错误，一般错误原因都是哪些？

aozima 2020-12-07

调网络不抓包，调I2C等时序不上逻辑分析仪，就像电工不用万用表！多用整理的好的文字，比截图更省流量，还能在整理过程中思考。

标签和右边的相关话题里面有好多类似的贴子和解决办法了。
从经验上看是个空指针。

杰瑞鼠 2020-12-11

2025再接再励

相关话题我看了，也没找到相近的解决办法，CmBacktrace跟踪hardfault究竟能用什么文件？在studio下如何生成？

请登录后再发布评论，点击登录

追加回复

杰瑞鼠 2020-12-22

2025再接再励

还是一个多小时出现，怎么解决这类问题，有谁碰到过这种情况？

杰瑞鼠 2020-12-22

2025再接再励

有时候前后还不一样

杰瑞鼠 2020-12-23

2025再接再励

后来将基于w5500的modbustcp线程禁掉之后，运行了一个晚上没有问题，但早上来之后，操作了几次按键，10分钟后系统又崩溃了，但这次提示的是usage fault,embacktrace跟踪的结果如图所示，为何会这样？
我系统的架构是

按键通过一个HC164的连接到单片机的中断引脚，在回调里面读出键值然后发信号量给HC164.C的按键处理线程，在按键处理中（根据是哪一个按键给出是哪一个显示界面）,然后给LCD.C发邮箱（不识别邮箱内容，当信号量使用，只为了解除LCD.C的邮箱等待阻塞）。
2 MBELE_RTU的采集线程：如果当前的显示界面是ELE，就通过邮箱将ele数据送lcd显示；
3 MBGAS_RTU的采集线程：如果当前的显示界面是GAS，就通过邮箱将GAS数据送lcd显示；
4 lcd.c的显示线程：平时因为邮箱阻塞等待，如果解除阻塞：先根据是哪个显示界面刷新固定显示；然后根据邮箱的内容（ELE/GAS)然后送不同的显示界面（动态采集数据刷新）

杰瑞鼠 2020-12-24

2025再接再励

修正了一些错误后，还是会出现hardfault,不过是这次是2~3小时后出现，位置thread timer，类型

Usage fault is caused by attempts to switch to an invalid state (e.g., ARM)
[2020-12-23 21:24:07.981 R]thread   pri  status      sp     stack size max used left tick  error
-------- ---  ------- ---------- ----------  ------  ---------- ---
mbtcp_te  12  suspend 0x000002c8 0x00000800    74%   0x00000001 000
Mb_RTUM_   9  suspend 0x000000dc 0x00000800    48%   0x00000007 000
Mb_RTUM_   8  suspend 0x0000017c 0x00000800    54%   0x00000005 000
Mb_RTUS_   7  suspend 0x000001f4 0x00000800    30%   0x00000009 000
tshell    20  suspend 0x00000184 0x00001000    09%   0x00000009 000
sample_L  14  ready   0x0000013c 0x00000800    45%   0x00000032 000
HC148_EX   6  suspend 0x000000a0 0x00000200    41%   0x0000002d 000
wiz_stat  28  suspend 0x000000b8 0x00000800    19%   0x00000014 000
wiz        5  suspend 0x000000b0 0x00000200    75%   0x00000008 000
sys_work  23  suspend 0x00000084 0x00000800    63%   0x00000001 000
tidle0    31  ready   0x00000060 0x00000100    59%   0x0000001b 000
timer      4  running 0x000000b0 0x00000200    88%   0x00000009 000
Firmware name: rtthread, hardware version: 1.0, software version: 1.0
Fault on thread timer
===== Thread stack information =====
  addr: 200011c0    data: ffffffff
  addr: 200011c4    data: 20001d5c
  addr: 200011c8    data: 00000000
  addr: 200011cc    data: 20000ffc
  addr: 200011d0    data: 00000001
  addr: 200011d4    data: 00000000
  addr: 200011d8    data: deadbeef
  addr: 200011dc    data: deadbeef
  addr: 200011e0    data: 200011e8
  addr: 200011e4    data: 0800e8f7
  addr: 200011e8    data: deadbeef
  addr: 200011ec    data: 20003b0c
  addr: 200011f0    data: 00000000
  addr: 200011f4    data: 00000000
  addr: 200011f8    data: 20001200
  addr: 200011fc    data: 080139f3
  addr: 20001200    data: 20001208
  addr: 20001204    data: 08017baf
  addr: 20001208    data: 00000000
  addr: 2000120c    data: 00000328
  addr: 20001210    data: 20002678
  addr: 20001214    data: 00000001
  addr: 20001218    data: 20001220
  addr: 2000121c    data: 08015d1f
  addr: 20001220    data: 00000000
  addr: 20001224    data: 200015d0
  addr: 20001228    data: 00000000
  addr: 2000122c    data: 000001f6
  addr: 20001230    data: 00000001
  addr: 20001234    data: 200015d0
  addr: 20001238    data: 20002678
  addr: 2000123c    data: 2000160c
  addr: 20001240    data: 20001248
  addr: 20001244    data: 08008111
  addr: 20001248    data: 20001250
  addr: 2000124c    data: 20008fa4
  addr: 20001250    data: 20003f34
  addr: 20001254    data: 008d440f
  addr: 20001258    data: 20001260
  addr: 2000125c    data: 080081df
  addr: 20001260    data: 00000000
  addr: 20001264    data: 00000000
  addr: 20001268    data: 008d43ab
  addr: 2000126c    data: 00000064
  addr: 20001270    data: deadbeef
  addr: 20001274    data: 08007259
  addr: 20001278    data: 23232323
====================================
=================== Registers information ====================
  R0 : 20001d5c  R1 : ffffffff  R2 : 20001d5c  R3 : 00000784
  R12: 00000000  LR : 08004a23  PC : 00000784  PSR: 20000000
==============================================================
Usage fault is caused by attempts to switch to an invalid state (e.g., ARM)
Show more call stack info by run: addr2line -e rtthread.elf -a -f 00000784 08004a22 0800e8f6 080139f2 08017bae 08015d1e 08008110 080081de 
Current system tick: 9257999