Armino平台AP系统swd调试
ap系统支持在线调试，使用jlink工具及Eclipse上位机工具，即可快速搭建调式环境。
JLink环境通过Eclipse集成JLink gdb server + gdb 工具
Jlink和BK7258连线:
1# VTref ---- VREF
7# SWDIO ---- SWDIO
9# SWCLK ---- SWCLK
20# GND ---- GND
JLink软件版本 https://www.segger.com/downloads/jlink/JLink_Windows_V768_x86_64.exe
Eclipse版本 eclipse-embedcpp-2020-12-R-win32-x86_64.zip
Eclipse工程配置
BK7258 JLink configuration
BK7258 JLink configuration
BK7258 JLink configuration
默认swd连接cpu0(cp端)，BK7258有两个swd口(grou1/group2)
可以通过setjtagmode cpu0 group1命令设置swd连接cpu0(cp端)
可以通过setjtagmode cpu1 group1设置swd连接cpu1(ap端)
可以通过jtagmode命令查看当前jtag状态
备注
使用Jlink进行SWD调试连接，需要编译DEBUG版本。
如果是开机异常，在串口输入命令的形式可能无法连接上Jlink。可以在driver_init里bk_gpio_driver_init();之后手动调用： bk_set_jtag_mode(0,0); //第一个参数0表示调试cpu0，第二个参数0表示使用第一组SWD gpio管脚 while(g_test_mode); //定义一个volitale的全局变量，而不是while（1）；是防止编译器将后面的代码全部优化掉
然后接入Jlink后，修改g_test_mode变量值，开始往下调试。
由于GPIO管脚复用，所以默认版本接入JLINK调试，需要输入调试命令，或者在代码里设置调试模式：
关闭看门狗
重新配置SWD相关的gpio
swd调试示例
连接好jlink后，可以按照以下步骤打断点调试：
根据函数指针或者函数名在Disassembly页找到dump的地址
BK7258 JLink configuration
示意图1
BK7258 JLink configuration
示意图2
在dump函数之前的语句设置断点，将断点属性设置为hardware
BK7258 JLink configuration
示意图3
点击resume继续运行程序。运行错误代码，如我在sta命令里，加了错误代码
BK7258 JLink configuration
示意图4
程序在断点处停下
BK7258 JLink configuration
示意图5
Armino平台异常dump一键恢复现场工具
请参考发布工具中使用文档: https://dl.bekencorp.com/tools/Debug_tool/BK7258-debug.zip
BK7258 dump工具常见问题:
默认Release版本dump功能是关闭的, 可以通过CONFIG_DUMP_ENABLE配置打开
当前的架构采用cp+ap模式, 可以通过两者的config文件修改打开dump功能
Dump工具恢复现场的原理是脚本通过分析log,解析出regs,itcm,dtcm,sram内容,然后通过gdb将这些内容恢复到qemu虚拟机中
Log文件的后缀支持txt, log, DAT
Log文件的编码当前只支持utf-8, 其他编码格式可用通过notepad++手动转换为utf-8编码格式
如果工具目录下有多份Log, 或者Log中有多次Dump, 工具会分析最后一次Dump, 需要保证工具目录下只有一份Log, 且Log中只有一份dump
Dump工具可以自动去掉日志里规则的时间戳: 2024-02-03 14:35:13.375193, 如果遇到不规则的时间戳, 需要手动去除
Dump过程中如果出现2次异常, 常见的如检测内存越界时, 遇到Assert, 会多打印一次寄存器, 解析时需要删掉第二次寄存器打印
任一个cpu Dump都会将当前cpu的寄存器, itcm, dtcm, 以及640k sram全部dump出来
默认cp侧的Log和Dump通过UART0输出
默认ap侧的Log和Dump通过MAILBOX到cp再通过UART0输出
Dump过程中如果遇到多个cpu同时dump, 需要将Log拆分成两份dump文件,分别用cp和ap的elf来恢复现场
每个cpu需要当前cpu的寄存器, itcm, dtcm, sram加上elf就可以恢复现场
寄存器格式:
CPU1 Current regs: =========> CPU1 表示当前寄存器是cpu1出现异常的寄存器
0 r0 x 0x0
1 r1 x 0x28061ca0
2 r2 x 0x0
3 r3 x 0x8061ca0
4 r4 x 0x28061d74
5 r5 x 0x28061d70
6 r6 x 0x28085a90
7 r7 x 0x28061de4
8 r8 x 0x8080808
9 r9 x 0x9090909
10 r10 x 0x10101010
11 r11 x 0x11111111
12 r12 x 0x1
14 sp x 0x20000928
15 lr x 0x21ec909
16 pc x 0x21ec8fa
17 xpsr x 0x61000000
18 msp x 0x2808ff48
19 psp x 0x20000908
20 primask x 0x0
21 basepri x 0x0
22 faultmask x 0x0
23 fpscr x 0x0
30 CPU1 xPSR x 0x4
31 LR x 0xfffffffd
32 control x 0xc
40 MMFAR x 0x8061ca0
41 BFAR x 0x8061ca0
42 CFSR x 0x82
43 HFSR x 0x0
MemFault =========> 初步异常原因是内存访问异常
dtcm格式:
stack mem dump begin, stack_top=20000000, stack end=20004000
<<<<stack mem dump end. stack_top=20000000, stack end=20004000
itcm格式:
stack mem dump begin, stack_top=00000020, stack end=00004000<<<<stack mem dump end. stack_top=00000020, stack end=00004000
sram格式:
stack mem dump begin, stack_top=28040000, stack end=28060000<<<<stack mem dump end. stack_top=28040000, stack end=28060000
stack mem dump begin, stack_top=28060000, stack end=280a0000<<<<stack mem dump end. stack_top=28060000, stack end=280a0000
stack mem dump begin, stack_top=28000000, stack end=28010000<<<<stack mem dump end. stack_top=28000000, stack end=28010000
stack mem dump begin, stack_top=28010000, stack end=28020000<<<<stack mem dump end. stack_top=28010000, stack end=28020000
stack mem dump begin, stack_top=28020000, stack end=28040000<<<<stack mem dump end. stack_top=28020000, stack end=28040000
当系统打开CONFIG_MEM_DEBUG时, Dump过程会将当前系统正在使用的Heap内存全部打印出来, 并检查是否有内存越界:
tick addr size line func task
6976 0x28064b68 80 425 xQueueGenericCreate media_ui_task
6976 0x28064be0 80 425 xQueueGenericCreate media_ui_task
6976 0x28064c58 160 425 xQueueGenericCreate media_ui_task
6976 0x28064d20 1024 863 xTaskCreate_ex media_ui_task
6976 0x28065148 104 868 xTaskCreate_ex media_ui_task
6976 0x2807d098 80 425 xQueueGenericCreate transfer_major_task
6976 0x2807d110 80 425 xQueueGenericCreate transfer_major_task
正常情况下也会将task相关信息dump到日志, 供问题分析时参考
Armino平台系统稳定性问题分析
嵌入式稳定性问题是一类常见但不容易定位的问题，其具有以下特征：
不可预测性：系统故障的时间点不固定，难以预测，可能在长时间运行后突然发生
多样性：问题可能以崩溃、死机、卡顿或错误行为等多种形式出现
累计效应：系统运行时间越长，资源泄漏或数据损坏等问题可能积累，最终导致崩溃
环境依赖性：稳定性还可能受温度、湿度和电源波动等环境因素的影响
为了帮助用户更好的定位稳定性问题，下面的链接文档中提供了常见的分析手段
备注
本文档仅针对软件引起的稳定性问题,建议用户在碰到稳定性问题时，优先参考该文档