• Replies 16 replies
  • Subscribers 443 subscribers
  • Views 30432 views
  • Users 0 members are here
Options
Related

【セルフプログラミング】マイコン暴走？

よっしー9999
CubeSuite+を使ってセルフプログラミングの開発をしています。

ライブラリ関数(FlashEnv(1))を実行していると、
逆アセンブルウィンドウでプログラムがストップします。メッセージウィンドウには「不正命令例外により停止しました」
と表示されます。原因が分からないのでアドバイスいただけないでしょうか。

-------------
_SelfLib_FlashEnv_Activate:
b013 sst.b r2\, 0x30[ep]
6119 tst r1\, sp
ff37c765 ld.hu 0x65c6[lp]\, r6
3742 satadd -0x9\, r8
8143 sst.b r8\, 0x1[ep]
fa6f ?
de4f ?
55174431 st.b r2\, 0x3144[r21] <---ここでストップ
45a5 sst.w r20\, 0x88[ep]
fcff ?
-----------

FlashEnv(1)は以下の関数からコールしています。

int erase_mem(UB startBlk\, UB endBlk)
{
__DI(); //マスカブル割込み禁止

FlashEnv(1);

・・・
}
  • よっしー9999さん

    メモリパネルから当該アドレスを一旦ウォッチパネルに登録すれば
    ウォッチパネルからアクセスブレークを設定できそうですけども、いかがでしょう？

    もしくは、ウォッチパネルから「新規ウォッチ式を追加」でアドレスを直接入力してウォッチに登録してからアクセスブレークを設定するとか。
  • 再度アドバイスありがとうございます。

    書き込みブレークの設定はできましたが、値は変わらず(ブレークせず)でした。

    現状、erase_mem()はreturnするようになったのですが、その後ステップ実行していると0xfffffff番地という、RAMの範囲外にPCが飛んでいき暴走するという現象が起こっています。
    アセンブルウィンドウを見ていたところ、レジスタ(r12)の値がおかしいためにこのような動作になっているようですが、その原因まではつかめていない状況です。レジスタに対しては書き込みブレークが設定できないため。
  • よっしー9999さん

    Kirinさんがアドバイスされているアクセスブレークですが、何か値を設定されていますか？

    指示値がない場合、値によらずWriteアクセスされるとブレークするので、もし未実施でしたらお試しください。

    破壊されている箇所の特定は、mainタスクからcallした時の_SelfLib_FlashEnv_Activate:
    のスナップショット（PrintScreenで十分です）を撮り、もう一方で異常値である、他タスクからのcall時の
    _SelfLib_FlashEnv_Activate:の内容を撮ります。
    比較すると、どのアドレスが壊れているかわかるので、そのアドレスにAccessBreakを置いてください。

    そして、ですが、レジスタ（R12）の値についてはRAM破壊の影響を受けた結果なので、あまり重要視しなくていいと思います。

    まずはどのタイミングでRAM破壊を起こすのかをトレースしましょう。そうしたら犯人？がおのずと分かってくるはずです。

    ひょっとしたら、異常を引き起こすタスクでメモリ操作関数や可変長のメモリ取得関数が悪さをしているかもしれませんし。
  • アドバイスいただきありがとうございます。

    アクセスブレークは指示値なしにしています。

    破壊されるRAMのアドレスは最初は_SelfLib_FlashEnv_Activateだったのですが、その後変わったようです。。そのため、現在どこが壊されているか探しています。メモリダンプできればいいんですが。。

    スタック容量が足りないのが原因かなと推測しているんですが、増やすとオーバーフローしてしまいビルドエラーになるのでどうしたものか悩み中です。。
  • よっしー9999さん

    メニューバーのところから、
    デバッグ(D)->デバッグ・ツールからアップロード(U)
    を選ぶと任意のメモリ範囲のデータをHEXかバイナリファイルに落とすことができますよ。
  • よっしー9999さん

    今回は方法論ではなく、外枠から推察してみました。

    ・RAM破壊の場所が変わった
    -> 領域で書き換わっているわけではない？
    -> 大規模なメモリ操作によるものではなさそう
    -> フラッシュ書き換え関数もしくは呼び出しに至る関数において引数不渡りか？

    ・mainタスクはOK、NGタスクはダメ
    -> mainタスクとNGタスクのスタック量の差は？
    -> mainタスクのスタック量をNGタスクと同等まで減らすとダメになる？
    -> NGタスクは関数の多重呼び出し等でスタックを浪費していないか？
    -> NGタスクで未初期化のポインタを参照していないか
    -> NGタスクで巨大な自動変数を利用していないか

    ・ヒープを使っていないか
    ->alloc系とfreeを繰り返していると解放漏れもありうる
    （解放漏れというと語弊がありますね。ヒープ管理領域が右肩上がりするケースがありました）


    今はホワイトボックス的にイタズラ箇所を探していると思いますが、行き詰ったらブラックボックス的にはこんな探し方もあるので、参考までに。