組込みC開発

Question

お世話になります。

組込みでARMコアのCPUをチョイスしての仕事を任されました。

開発ツールはKeilというIDEで、C言語でOS使用しないで開発をしています。

C言語はかれこれ2年以上使用しており、文法上の事などはほぼマスター
しており、上記のIDEでソースをコンパイルしてコンパイルエラーもなく
60kbytesほどのコードが生成されます。

ただ、このプログラムをターゲットCPUへダウンロードして使うと
コードとは異なる動きをするときがあります。
これは、小規模なプログラムでは経験したことの無いことです。

たとえば、思った動きにならないときに、ソースを少しいじっただけで
今度は例外が発生して止まったりします。

割込みは内部タイマー、外部（ボタン等）、UARTなど計4種類を
設定していますが、どうもこのあたりが怪しいと考えています。
たとえばUARTでPCからデータを送って、ボタンを押す、などの
アクションを起こすと、データアボートやプリフェッチアボート
が発生したりしますので。

ちなみに、割込み処理は、IDEがサンプルソースでつけているものを
includeして使っています。

また、CでのプログラムでMISRA-C参考書も購入してチェックして
おります。

大規模なプログラミングは今回が初めてなのですが、こうもソース
を少しさわっただけで、例外が発生したりする（コード上問題ない
と考えています）ので、現状は記述の仕方を変えてみたりして
対応しています。

こうした規模の大きい組込み系でのプログラミングで、注意する点
や、常識的な部分があればお教えいただきたく思います。

よろしくお願いいたします。

zwi · Accepted Answer

#3のzwiです。

>地道にトレースしてどこでどう無限ループに達するのか、Abortへジャンプしてしまうのかを見ていくことが、組込み系でのデバッグ、ということになるのでしょうか。

再現性が高いだけでも恵まれてますよ！
めったに出ないバグなんか、泣きそうになります(>_<)
最悪アセンブラレベルでのトレースが必要になるかも知れませんが、とりあえずスタックの情報から流れが追えませんか？
暴走先にどうやって飛んできたのかのを調べるには、スタックに詰まれている情報を追ってみるのが一番です。
他のテクニックとしては、配列でリングバッファを作ってプログラムの要所要所の通過マークを格納していくって技もあります。流れがおかしくなったらリングバッファの通過マークの順番を見れば分かりますよね。
あとは、ＣＰＵのクロックを落として様子みてみるとか、ＡＲＭあたりだとＰＬＬで簡単に変更できるので簡単に実験できると思います。

話を聞いている限りでは、次のような不具合が可能性としてあります。
(1)ノイズでＲＡＭまたはレジスタの内容が破壊される。ハード？
(2)ＣＰＵキャッシュが何らかの原因で破壊される。ハード？
(3)コンパイラのバグで、とんでもない命令が実行される。コンパイラ？
(4)スタックが破壊される。ハードまたはソフトが原因。
あたりですかね。

>KeilというツールはもともとKeilという会社のコンパイラが搭載されていたわけですが、この会社、英国ARM社の傘下に入り、ARMが提供するコンパイラと同等のコンパイラを搭載するようになりました。
>あるWebでみかけたので気になるのが、ARMコアのコンパイラのチョイスでGNU,IAR,Keilが評価対象とされて、OverallでIARが勝利。次点でGNU、最後がKeilだったと記憶しております。　いまさらながら、IARのほうにしとけば、思っています^^;;;

どこのコンパイラもバグがあるのです。運が悪いと引っかかりますね。それも締め切り間際に(^^ゞ
まだバグだと確定したわけでもないですよね。周辺操作のタイミングのミスかも知れませんよ。


>pin1にボタン入力の割込み信号が入ると仮定して、本体CPUは常に30μs周期のtimer1の割込みで主に計算処理が中心の無限ループをさせています。
>ボタンが押された＝pin1がHighからLowに変化したところで、まずフラグをたてます(flag = 1)
>次に30μsのtimer1による無限ループ中に
>if(flag == 1) counter++;
>として、pin1の割込み発生からループが何回、回ったかをカウント。
>このカウントの値がインクリメントされ、既定の回数をカウントしてもなお、pin1がLowであれば、内部的にONを確定します。そしてflag = 2とします。
>次にボタンを離す行為の監視ですが、ONの監視と同様の処理をしています。

なんか複雑ですね。それにチャタリングはスイッチによりますが１０ｍｓ以上は続きますので、４００から５００カウントぐらいしないと確定できませんね。
私がやるとしたら、１ｍｓ毎ごとぐらいにしかチェックしません。例えば１ｍｓ毎２０回チェックして同じ状態が２０回続けばスイッチの変化を確定とします。それ以外のときは前のスイッチ状態が継続しているものとします。

volatileは、コンパイラの最適化を抑止してレジスタ処理のみとなること避けるための修飾子です。
プログラムの流れの外(割り込み等)で変数の値が変化する場合は、その変数にvolatileを付ける必要があります。
下記サイトを参考にしてください。
http://www.kumikomi.net/article/explanation/2003/10kumi/13.html

>・RAM 領域を定数で初期化するコードが、オブジェクト上に存在する。
Ｃのスタートアップルーチンが組み込まれていれば、ルーチン次第ですがＲＡＭ上の変数の初期化をしてくれています。通常アセンブラで書かれていますが、リンクしていませんか？

AsanoNagi · Answer

No. 7 です。
> ・RAM 領域を定数で初期化するコードが、オブジェクト上に存在する。

オブジェクトではなくて、オブジェクトファイルでした。
組み込みの場合、最終的に ROM に焼き込むことになりますが、そのもとになるファイルは、フォーマットに差があっても、
xxxx番地のデータはyy
という情報の集まりです。

この、xxxx番地が ROM 上にある場合は、問題ないのですが、開発環境やら、の関係で、RAM 上の番地を指定してしまうことがあります。

たとえば、
static int i = 50;
のような指定があると、
（i の番地）は、50
のようなデータがオブジェクトファイル上にできます。
エミュレータがこれを読み込むと、ごく自然に RAM 領域に初期値を割り当ててしまいます。ところが、マイコンに焼き込む段階では、RAM 領域への焼き込みはできませんから（できたとしても、電源を切れば消えますから）初期化されなかったことになるというものです。

const なしの static や グローバル変数に初期化すると、こうなるケースがあります（開発環境・オプションにより）

AsanoNagi · Answer

組み込み特有というか、エミュレータが絡んでくると、RAMの取り扱いが問題になることがあります。
ツールによっては変数全般も。

・初期化されていない変数がある
　これは、組み込みにかかわらず問題になる項目です。
　組み込みに場合、エミュレータ上で動かすと、エミュレータ自体が、きれいにRAMを初期化してしまうので、問題が表面化しない場合があります。

・RAM 領域を定数で初期化するコードが、オブジェクト上に存在する。
　これは、主に、コンパイル時に指定するメモリの割り当てに絡んできます。
　変数を初期化するコードで、ツールによっては、それを、単純に、指定された番地に埋め込むことがあります。（特にトップレベルのグローバル変数や、スタティック変数）
　ところがその変数がRAMだと、いわゆる、ROM への焼き込みができませんから、初期化しているつもりが初期化されていなかったりします。

こういうケースも時にはあります。

jacta · Answer

> 組込み系では、こうした対応策が一般的なのでしょうか？
> Cの文法上は問題ないけれども、optimizeしてみたり、ソースの書き方を
> 変更してみたりして、実機で（なんとか）動くようにするような対策です

確かにコンパイラの最適化バグに遭遇することはときどきありますが...

書かれている内容を読む限り、おそらくコンパイラの最適化バグではないような気がします。
単にvolatile修飾子を忘れているとか、きちんとタイミングを合わせなければならないのに、適当に書いてたまたま動いていただけとか、そんなところではないでしょうか。

たまたま動いていた場合には、ボードの個体差によって、動いたり動かなかったりします。量産した際に、ロットによって動かなかったりすると目も当てられません。

zwi · Answer

あと、組み込みは初めてですよね？
スイッチの入力は、チャタリング対策されてますか？
ハードかソフトでチャタリングの対策をしていないと、スイッチの値を読み間違うのは当たり前なんですが。
http://elm-chan.org/docs/tec/te01.html
これは、データアボートやプリフェッチアボートとは別の問題です。

zwi · Answer

>下記にも記載しましたが、Optimization levelを操作することで今回は回避できそうな気配です＾＾；

そんな方法で問題を回避しても無駄です。
趣味で作っているならともかく、仕事でそんなことをしたら酷い目にあいますよ！
量産したら動かない、現場ではちゃんと動かない、でも社内ではちゃんと動くってオチが待っていそうです。

もし、Optimization levelだけで回避できるとしたら、コンパイラのバグが原因です。どこのコードに問題があるか確認しておかないと本当に回避しているか保障できません。
私の勘では、ハードの異常動作な気がするんですけどね。オプティマイズレベルで周辺回路の操作タイミングが変わりますから。

zwi · Answer

「プリフェッチアボート」は普通ありえない例外です。
ノイズなどが原因でハードウェアが誤動作していないでしょうか？
データアボートやプリフェッチアボートの頻発がソフトウェアが原因とは思えません。パスコンを追加したりしたら直りませんかね？

>たとえばUARTでPCからデータを送って、ボタンを押す、などのアクションを起こすと
とてもノイズが原因っぽいですよね。

後は、ＡＲＭチップが、どこのメーカー製かわかりませんが、エラッタの資料を見て問題となるようなことをしていないか確認をしてみてください。たちの悪いエラッタに引っかかっている可能性もあります。

R32C · Answer

実機で、暴走するなら、デバッガーのリアルタイムトレース
で、動きを確認してみてはいかがでしょうか？

この辺が組み込み独自の方法なのかもしれませんね。
Keilの開発環境については、よく知りませんが、リアルタイムトレース
は使えるですよね。　ARMコそのものはオンチップでリアルタイム
トレース機能のサポートがあるので、対応デバッガで使えるはずです。
今お使いのツールでもしサポートしていないなら、使えるツールを
用意してみたほうがいいと思います。

jacta · Answer

> ただ、このプログラムをターゲットCPUへダウンロードして使うと
> コードとは異なる動きをするときがあります。

期待した動作とどのように異なるのでしょうか？

> たとえば、思った動きにならないときに、ソースを少しいじっただけで
> 今度は例外が発生して止まったりします。

発生した例外の要因は何でしょうか？

組込みC開発

#3のzwiです。

No. 7 です。

組み込み特有というか、エミュレータが絡んでくると、RAMの取り扱いが問題になることがあります。

> 組込み系では、こうした対応策が一般的なのでしょうか？

この回答への補足

あと、組み込みは初めてですよね？

>下記にも記載しましたが、Optimization levelを操作することで今回は回避できそうな気配です＾＾；

「プリフェッチアボート」は普通ありえない例外です。

実機で、暴走するなら、デバッガーのリアルタイムトレース

> ただ、このプログラムをターゲットCPUへダウンロードして使うと

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング