Debug:coredump

1. 在CPU触发异常时，会把当前的内存中的数据dump到串口中，用户可以保存到日志为coredump.log，coredump格式如下。

-+-+-+- BFLB COREDUMP v0.0.1 +-+-+-+

------ DATA BEGIN 62xxxxxx@00000400@predefined ------

...

------ END R6yo3A== ------

2. 将这些数据导入到gdb server中，可以使用gdb来对这些数据进行解析，获得异常发生时的一些状态。比如哪个进程发生了异常，别的进程的状态是什么样子的。

./tools/byai/coredump.py命令会创建一个gdb server，创建虚拟的32bit内存空间，把elf文件与coredump文件加载到内存空间中，并自动打开gdb client连接。

usage: coredump.py [-h] [-x GDB_INIT] log_file elf_file

3. 如下的例子，可见coredump.py传入coredump.log与elf后，这可打印当前运行的任务，可以使用bouffalo_sdk.gdb内置的一些函数来对某个TCB进行backtrace。

:~/bouffalo_sdk$ ./tools/byai/coredump.py coredump_20260604b/coredump.log coredump_20260604b/image_transmission_bl616cl.elf

Auto-selected free port: 50659

Starting local GDB server on port 50659...

GDB server ready. Connect from GDB using:

(gdb) file coredump_20260604b/image_transmission_bl616cl.elf

(gdb) target remote localhost:50659

(gdb) source /home/wyb/repo/new4/bouffalo_sdk/tools/bouffalo_sdk.gdb

Auto-starting GDB client: riscv64-unknown-elf-gdb -ex file coredump_20260604b/image_transmission_bl616cl.elf -ex target remote localhost:50659 -x /home/wyb/repo/new4/bouffalo_sdk/tools/bouffalo_sdk.gdb

...

Reading symbols from coredump_20260604b/image_transmission_bl616cl.elf...

Remote debugging using localhost:50659

Loading ELF PT_LOAD data from: coredump_20260604b/image_transmission_bl616cl.elf

Loaded 6 ELF PT_LOAD segments, 623074 bytes at LMA

Initialized 6 ELF PT_LOAD segments at LMA from coredump_20260604b/image_transmission_bl616cl.elf

Parsing coredump from: coredump_20260604b/coredump.log

Found 1 COREDUMP sections, processing the last one

Parsed 4460 memory blocks

Loaded 4460 coredump memory blocks at VMA from coredump_20260604b/ReceivedTofile-COM5-2026_6_4_11-43-48.log

Target local: Client connected from 127.0.0.1:38348

0x00000000 in ?? ()

(gdb) p pxCurrentTCB

$1 = (TCB_t * volatile) 0x880f49d4

(gdb) task_dump 0x880f49d4

$2 = {pxTopOfStack = 0x60fd83d4, xStateListItem = {xItemValue = 0, pxNext = 0x60fd0084 <pxReadyTasksLists+108>, pxPrevious = 0x60fd0084 <pxReadyTasksLists+108>, pvOwner = 0x880f49d4, pvContainer = 0x60fd007c <pxReadyTasksLists+100>}, xEventListItem = {xItemValue = 27, pxNext = 0x880f4974, pxPrevious = 0x880f4974, pvOwner = 0x880f49d4, pvContainer = 0x0}, uxPriority = 5, pxStack = 0x60fd7560, pcTaskName = "shell_task\000\000\000\000\000", pxEndOfStack = 0x60fd8550, uxCriticalNesting = 0, uxTCBNumber = 4, uxTaskNumber = 0, uxBasePriority = 5, uxMutexesHeld = 0, pxTaskTag = 0x0, pvThreadLocalStoragePointers = {0x0}, pvThreadLocalStoragePointersDelCallback = {0x0}, ulRunTimeCounter = 65, ulNotifiedValue = {0, 0, 0, 0}, ucNotifyState = "\000\000\000", ucStaticallyAllocated = 0 '\000', ucDelayAborted = 0 '\000', iTaskErrno = 0}

FPU is CLEAN (FS=0x2) - using offset +31 words

mstatus: 0x5880

stack_top: 0x60fd83d4

#0 0x800729b6 in shell_memtrace (argc=<optimized out>, argv=<optimized out>) at ./components/shell/shell.c:93

#1 0x80072f62 in shell_exec_cmd (retp=<optimized out>, length=<optimized out>, cmd=<optimized out>) at ./components/shell/shell.c:533

#2 shell_exec (cmd=0x60fd3916 <_shell+606> "memtrace", length=21) at ./components/shell/shell.c:601

#3 0x80073136 in shell_handler (data=<optimized out>) at ./components/shell/shell.c:794

#4 0x80073944 in shell_task (pvParameters=<optimized out>) at ./components/shell/shell_freertos.c:135

#5 0x00000000 in ?? ()

Backtrace stopped: frame did not save the PC

(gdb) task_list_wait

tcb: 0x880f7298 mstatus: 0x5880 [FPU_CLEAN] name: xxxx

tcb: 0x880f4d20 mstatus: 0x5880 [FPU_CLEAN] name: tcpip_thread

tcb: 0x60fccc08 mstatus: 0x5880 [FPU_CLEAN] name: display_thread

tcb: 0x60fc8ae0 mstatus: 0x5880 [FPU_CLEAN] name: MainTask

tcb: 0x880f73c4 mstatus: 0x5880 [FPU_CLEAN] name: xxxx

tcb: 0x880f6850 mstatus: 0x5880 [FPU_CLEAN] name: xxxx

tcb: 0x880f6e28 mstatus: 0x80007880 [FPU_CLEAN] name: xxxx

tcb: 0x880f5124 mstatus: 0x80007880 [FPU_CLEAN] name: xxxx

tcb: 0x60fd18c8 mstatus: 0x5880 [FPU_CLEAN] name: Tmr Svc

tcb: 0x880f4aec mstatus: 0x5800 [FPU_CLEAN] name: wifi fw

(gdb) task_list_ready

tcb: 0x60fd1840 mstatus: 0x5880 [FPU_CLEAN] name: IDLE

tcb: 0x880f49d4 mstatus: 0x5880 [FPU_CLEAN] name: shell_task

Q：如何退出

A：按CTRL+D或者CTRL+C可以退出coredump.py

Q：日志的格式，多个COREDUMP在同一个日志会怎么样

A：日志支持UTF8，UTF32LE、BE，CRLF/LF，基本上默认的格式不需要转换都支持，当日志中有多个保存的coredump时，会自动选择最后一个。

Q：有时候会有如下打印，是什么意思

crc check addr: 88021400, length: 00000400, end_crc: eebd05e9, crc: 8981de62

crc check addr: 8806e000, length: 00000400, end_crc: 2f25c5c9, crc: a9c6462e

crc check addr: 880ac800, length: 00000400, end_crc: 28c04c90, crc: 79f28ecb

crc check addr: 880c5400, length: 00000400, end_crc: 70dadb0a, crc: 8bcde759

A：在通过串口把内存中的数据dump出来时，尤其是带有PSRAM的情况，大量的数据通过串口通信可能会出错，这些是发现某段的CRC校验出错，很多时候一小段出错并不影响DEBUG。

Q：如何简单判断ELF与COREDUMP的对应关系

A：可以通过读取ELF文件与芯片上电时的时间来对比

ELF文件中的Build时间：

```

riscv64-unknown-elf-objdump -s coredump_20260604b/image_transmission_bl616cl.elf |grep -A 3 Build

80097030 0a000000 4275696c 643a3039 3a35383a ....Build:09:58:

80097040 35342c20 4a756e20 20342032 3032360d 54, Jun 4 2026.

80097050 0a000000 436f7079 72696768 74202863 ....Copyright (c

80097060 29203230 32322042 6f756666 616c6f6c ) 2022 Bouffalol

```

启动日志中的Build时间：

```

Build:09:58:54, Jun 4 2026

```

Debug:coredump

导航菜单

搜索