ESP-IDFを使ってみる

CoreDump機能


ESP-IDFにはCoreDumpの機能が有りますが、デフォルトでは無効になっています。
これを有効にするとパニック発生時の原因を解析することができます。
そこで、順を追ってCoreDump機能を有効にする手順を説明します。



以下のコードを実行するとパニックが発生し再起動します。
#include <stdio.h>
#include <inttypes.h>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_log.h"

void app_main()
{
        printf("Now esp is crashed\n");
        assert(0);
}

そこで、パニック発生時の挙動を変更します。




これで、パニック発生時はCPU haltに変わります。




次にコアダンプ機能を有効にします。
コアダンプの出力先はUARTです。




StackSizeを指定しないと、なぜか再起動してしまいます。


この内容でファームをリビルドします。
パニック発生時にコアダンプがずらずらと表示されます。


次にコアダンプのDecode機能を無効にします。


この内容でファームをリビルドします。
パニック発生時にコアダンプの生の Base64 エンコードされた本体が、UARTに出力されます。


そこで、コアダンプのテキスト本体をコピペしてローカルファイル(core-dump.txt)に保存します。
ローカルファイルに保存するときに、CORE DUMP START/CORE DUMP ENDの行は含めません。
以下のコマンドでBase64 エンコードされたコアダンプを解析することができます。




次にコアダンプの出力先をFlash上のパーテイションに変更します。
Flashにコアダンプ格納用のパーティションが必要になります。
以下の内容で、パーティション定義ファイル(partitions.csv)を作成します。
$ cat partitions.csv
# Name,   Type, SubType, Offset,  Size, Flags
# Note: if you change the phy_init or app partition offset, make sure to change the offset in Kconfig.projbuild
nvs,      data, nvs,     0x9000,  0x6000,
phy_init, data, phy,     0xf000,  0x1000,
factory,  app,  factory,,         1M,
#coredump, data, coredump,,        64K
coredump, data, coredump,,        0x10000,

このパーテイションを有効にします。


コアダンプの出力先をFlashに変更します。


なぜか、Integrity checkがCRC32だと再起動してしまいます。
この現象はesp-idf v5.4では発生しますが、esp-idf v5.5では発生しません。
そこで、esp-idf v5.4では、Integrity checkをSHA256に変更します。


この内容でファームをリビルドします。
パニック発生時にコアダンプがFlashに保存されます。


以下のコマンドでFlashに保存されているコアダンプを解析することができます。


以下のコマンドでポートを指定することができます。


以下のコマンドでFlashに保存されているコアダンプを、ローカルファイルに保存することができます。


パーテイションのローカルファイルへの保存はparttool.pyを使っても可能です。
parttool.pyはどんなパーティションでも読み出すことができます。


ローカルに保存したコアダンプの解析は以下のコマンドです。


長期運用を行う場合、Flashへのコアダンプ保存を有効にしておくことで、思わぬ障害発生時の解析を行うことができますが、
解析にはESP-IDFとFreeRTOSに関するかなりの知識を必要とします。

続く...