TI CC2538 ARM Cortex M3 パーツで newlib を使用しようとしています。目的は、メッセージのデバッグに printf を使用することであり、実際に機能しています。ただし、システムはいくつかのメッセージの後にセグメンテーション違反を起こし (ARM はそれを HardFault と呼びます)、その理由はわかりません。
GDB を使用して、次のスタック トレースを取得しました。
(gdb) bt full
#0 FaultISR () at src/startup_gcc.c:307
fault_stat = 0x8200
hfault_stat = 0x40000000
mmfault_stat = 0xfffffff8
busfault_stat = 0xfffffff8
buf = "\000\000\000\000\371\377\377\377\026\000\000\000\000\000\000\000\n\000\000\000\000\000\000\000\b\f\000 \002\000\000\000\060\r\000 \320\f\000 \002\000\000\000\303w \000\000\000\000\000w?\032\000\360\v\000 \360\v\000 \002\000\000\000\027\000\000\000\003\000\000\000\277\022\035\000\b\f\000 \b\f\000 \r\000 \027\000\000\000\f\000\000\000\371\377\377\377T\025\000 a\217 \000\r\000\000\000\001\000\000\000\210\r\000 s\263\""
#1 <signal handler called>
No symbol table info available.
#2 0x002076dc in strlen ()
No symbol table info available.
#3 0x0020494a in _svfprintf_r ()
No symbol table info available.
#4 0x002045aa in _vsnprintf_r ()
No symbol table info available.
#5 0x002045fe in vsnprintf ()
No symbol table info available.
#6 0x00200fa8 in ws_debug_vfprintf (f=STDERR, fmt=0x208f24 "Received a packet of length %u\n", args=...) at src/os/ws_debug.c:220
len = 0x27
buf = 0x20001538 "DBG src/net/mac/packet_scheduler.c:123 "
#7 0x00200f4e in ws_debug_fprintf (f=STDERR, fmt=0x208f24 "Received a packet of length %u\n") at src/os/ws_debug.c:201
args = {__ap = 0x20000e50 <pui32Stack+440>}
#8 0x00201dea in packet_scheduler_timer () at src/net/mac/packet_scheduler.c:123
phy_len = 0xd
pkt = 0x8ef6
fcf = 0x0
buf = 0x20001738 "\200\220"
#9 0x00200c32 in ws_timer_update () at src/os/ws_timer.c:156
ptr = 0x20001728
new = 0x20001728
#10 0x002005c2 in main () at src/main.c:143
No locals.
ご覧のとおり、newlib の部分 (#2 ～ #5) には情報がなく、デバッグが困難になっています。これは、newlib からデバッグ シンボルが取り除かれたためだと思いますが、newlib を再コンパイルしたところ、同じ結果が得られました。
公式リポジトリで利用可能なツールチェーンを使用して Arch Linux を実行しています。
arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/5.1.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-5-20150519/configure --target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi --with-native-system-header-dir=/include --libexecdir=/usr/lib --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib --with-newlib --with-headers=/usr/arm-none-eabi/include --with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc --with-isl --with-libelf --enable-gnu-indirect-function --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/ --with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 5.1.0 (Arch Repository)
-
arm-none-eabi-gdb -v
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Arch Build System (ABS) を使用して手動で newlib パッケージをビルドしましたが、デバッグ シンボルを含める必要があると思います (関数名は GDB に表示されます。それで十分ですか?)
次に試すことができるアイデアはありますか？
編集
障害ステータス レジスタが実際に読み取れるように、出力を修正しました。
デコードされた出力は次のとおりです。
fault_stat: 0x8200 (BFARV, PRECISE)
hfault_stat: 0x40000000 (FORCED)
busfault_stat: 0xfffffff8 (valid FAULTADDR)
これを解釈すると、問題のある命令のアドレスが FAULTADDR に格納されているバス障害例外が発生しました。CPU が 0xffffff8 を呼び出そうとした原因はわかりませんが、それが問題の原因であると確信しています。