原文链接Armino平台AP系统swd调试ap系统支持在线调试使用jlink工具及Eclipse上位机工具即可快速搭建调式环境。JLink环境通过Eclipse集成JLink gdb server gdb 工具Jlink和BK7258连线:1# VTref ---- VREF7# SWDIO ---- SWDIO9# SWCLK ---- SWCLK20# GND ---- GNDJLink软件版本 https://www.segger.com/downloads/jlink/JLink_Windows_V768_x86_64.exeArm工具链版本 https://armkeil.blob.core.windows.net/developer/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-win32.exeEclipse版本 eclipse-embedcpp-2020-12-R-win32-x86_64.zipEclipse工程配置BK7258 JLink configurationBK7258 JLink configurationBK7258 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的全局变量而不是while1是防止编译器将后面的代码全部优化掉然后接入Jlink后修改g_test_mode变量值开始往下调试。由于GPIO管脚复用所以默认版本接入JLINK调试需要输入调试命令或者在代码里设置调试模式关闭看门狗重新配置SWD相关的gpioswd调试示例连接好jlink后可以按照以下步骤打断点调试根据函数指针或者函数名在Disassembly页找到dump的地址BK7258 JLink configuration示意图1BK7258 JLink configuration示意图2在dump函数之前的语句设置断点将断点属性设置为hardwareBK7258 JLink configuration示意图3点击resume继续运行程序。运行错误代码如我在sta命令里加了错误代码BK7258 JLink configuration示意图4程序在断点处停下BK7258 JLink configuration示意图5Armino平台异常dump一键恢复现场工具请参考发布工具中使用文档: https://dl.bekencorp.com/tools/Debug_tool/BK7258-debug.zipBK7258 dump工具常见问题:默认Release版本dump功能是关闭的, 可以通过CONFIG_DUMP_ENABLE配置打开当前的架构采用cpap模式, 可以通过两者的config文件修改打开dump功能Dump工具恢复现场的原理是脚本通过分析log,解析出regs,itcm,dtcm,sram内容,然后通过gdb将这些内容恢复到qemu虚拟机中Log文件的后缀支持txt, log, DATLog文件的编码当前只支持utf-8, 其他编码格式可用通过notepad手动转换为utf-8编码格式如果工具目录下有多份Log, 或者Log中有多次Dump, 工具会分析最后一次Dump, 需要保证工具目录下只有一份Log, 且Log中只有一份dumpDump工具可以自动去掉日志里规则的时间戳: [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 0x01 r1 x 0x28061ca02 r2 x 0x03 r3 x 0x8061ca04 r4 x 0x28061d745 r5 x 0x28061d706 r6 x 0x28085a907 r7 x 0x28061de48 r8 x 0x80808089 r9 x 0x909090910 r10 x 0x1010101011 r11 x 0x1111111112 r12 x 0x114 sp x 0x2000092815 lr x 0x21ec90916 pc x 0x21ec8fa17 xpsr x 0x6100000018 msp x 0x2808ff4819 psp x 0x2000090820 primask x 0x021 basepri x 0x022 faultmask x 0x023 fpscr x 0x030 CPU1 xPSR x 0x431 LR x 0xfffffffd32 control x 0xc40 MMFAR x 0x8061ca041 BFAR x 0x8061ca042 CFSR x 0x8243 HFSR x 0x0MemFault 初步异常原因是内存访问异常dtcm格式:stack mem dump begin, stack_top20000000, stack end20004000stack mem dump end. stack_top20000000, stack end20004000itcm格式:stack mem dump begin, stack_top00000020, stack end00004000stack mem dump end. stack_top00000020, stack end00004000sram格式:stack mem dump begin, stack_top28040000, stack end28060000stack mem dump end. stack_top28040000, stack end28060000stack mem dump begin, stack_top28060000, stack end280a0000stack mem dump end. stack_top28060000, stack end280a0000stack mem dump begin, stack_top28000000, stack end28010000stack mem dump end. stack_top28000000, stack end28010000stack mem dump begin, stack_top28010000, stack end28020000stack mem dump end. stack_top28010000, stack end28020000stack mem dump begin, stack_top28020000, stack end28040000stack mem dump end. stack_top28020000, stack end28040000当系统打开CONFIG_MEM_DEBUG时, Dump过程会将当前系统正在使用的Heap内存全部打印出来, 并检查是否有内存越界:tick addr size line func task6976 0x28064b68 80 425 xQueueGenericCreate media_ui_task6976 0x28064be0 80 425 xQueueGenericCreate media_ui_task6976 0x28064c58 160 425 xQueueGenericCreate media_ui_task6976 0x28064d20 1024 863 xTaskCreate_ex media_ui_task6976 0x28065148 104 868 xTaskCreate_ex media_ui_task6976 0x2807d098 80 425 xQueueGenericCreate transfer_major_task6976 0x2807d110 80 425 xQueueGenericCreate transfer_major_task正常情况下也会将task相关信息dump到日志, 供问题分析时参考Armino平台系统稳定性问题分析嵌入式稳定性问题是一类常见但不容易定位的问题其具有以下特征不可预测性系统故障的时间点不固定难以预测可能在长时间运行后突然发生多样性问题可能以崩溃、死机、卡顿或错误行为等多种形式出现累计效应系统运行时间越长资源泄漏或数据损坏等问题可能积累最终导致崩溃环境依赖性稳定性还可能受温度、湿度和电源波动等环境因素的影响为了帮助用户更好的定位稳定性问题下面的链接文档中提供了常见的分析手段备注本文档仅针对软件引起的稳定性问题,建议用户在碰到稳定性问题时优先参考该文档
