HOME会社概況業務内容開発分野開発事例CANモジュールソフテックだよりお問い合わせ
HOME > ソフテックだより > 第99号(2009年10月7日発行) 技術レポート「ハードウェアを含めたデバッグの難しさ 2」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより(技術分野別)のページへ
ソフテックだより(シーン別)のページへ


ソフテックだより 第99号(2009年10月7日発行)

技術レポート

「ハードウェアを含めたデバッグの難しさ 2」

1. はじめに

本号では、前号(第97号 2009年9月2日 技術レポート「ハードウェアを含めたデバッグの難しさ 1」)の続きの内容となります。
前号で紹介し切れなかった、「デバイスの仕様/特性の把握」と「機能追加による弊害」の2点を、開発のまとめとともに、紹介したいと思います。

2. デバイスの仕様/特性の把握
2-1. デバイスの仕様と特性における注意点

CPUマニュアルなどはページ数が多く、全ての内容を把握するのは困難ですが(もちろん時間があれば把握するに越したことはありません)、最後のページの注意点などに重要な制限事項が書かれていたりします。
また、メーカーのHPに製品のアップデート情報やバグ情報が出ていたりするので、場合によってはそちらも合わせて調査する必要があります。
開発対象となる基板には、機能を実現する為に、多くの場合はターゲットとなるマイコン以外にもSRAM、SDRAMなどのデバイスが搭載されています。マイコンが複数のデバイスへアクセスする場合には、基本的にはバスは共通で使用されます。その為、アクセスの競合が発生したりすると、データが化けたり、正しく制御できなくなります。

2-2. バス競合の問題と対策
2-2-1. 問題の発生経緯

一度テストまで完了した後、ブラシアップ期間(お客様に動作確認していただきながら仕様や使い勝手などの向上を行う)をもともと設けていたため、納期より前に暫定版リリースを行いました。
お客様より、(今まで使用していた)ICE(※1)が接続可能なデバッグ基板での動作としては問題ないという回答を頂き、コンパクトフラッシュ(CF)への保存データの変更など細かい対応を進めていたのですが、後日、デバッグ基板では動くが、CPU実装基板だと動かないという連絡を頂きました。
もともと、CPU実装基板での確認は対応範囲としては含まれていませんでしたが、動作しないことは問題ですので、お客様にCPU実装基板を送って頂き、調査を開始しました。

2-2-2. 解決へのアプローチ

行ったことを以下にまとめます。(お客様より、基板上の違いは、実チップが載っているかICE接続用のソケットが載っているかどうかだけだったとお聞きしましたので、ソフトの調査から進めました) ハードウェア絡みではソケット以外に違いがないとはいえ、基板改修を行っている為、端子の接続なども考慮して確認を行っていきました。

  • ソフトウェアの観点ソフトウェアの観点

    ICEを使用した場合としていない場合での違いで考えると、メモリの初期化等が正常に行われていない可能性がありますので、確認しましたが、問題ありませんでした。

  • エラー発生箇所と、エラー条件の確認

    ソフトウェアから追っていきましたが、ドライバのイニシャル時点でCFにアクセス出来ていないことが分かりました。

  • ロジックアナライザを使用したデジタル波形の確認

    マイコンの各端子からの出力、CFからの出力それぞれをロジックアナライザで取得し、確認しました。デバッグ基板とCPU実装基板で同じ波形が出力されており、ここに問題はなさそうでした。

  • 基板のハンダ、接続等の見直し

    設計上はICEが接続されるかそうでないかの違いだけといっても、基板の改修を行っていることもあり、テスターでCFと接続されている端子の、導通チェックを行いました。ここも正常に接続されていることが確認できました。

  • ICEの設定見直し

    ICEの設定が間違っているのでは、という点で見直し、クロック設定が間違っていることが分かりました。修正し、再度動作確認を行いましたが、状況は変わりませんでした。

  • ウェイトの調整

    BSC(※2)の調整を行い、再度CFのマニュアルの見直しを行いながら、余裕を持たせた波形などに切り替えてみましたが、状況は変わりませんでした。

  • オシロスコープを使用したアナログ波形の確認

    データバスの出力がCPLD(※3)と競合していることが判明しました。

上記のように、時間をかけていろいろ進めていましたが、糸口はなかなかつかめませんでした。

2-2-3. 原因は同じCS空間を使用していること

ハードウェア側からの確認も万策尽きたかというところで、オシロスコープでアナログ波形の確認を行いました。そうしたところ、実装基板で、CFへアクセスする際にCPLDへ接続されているCS7信号がアクティブ(ローレベル)になっていることが分かりました。
オシロスコープで確認したところ、やはりCS7空間にアクセスしている為、データバス出力が競合しており、正常にアクセスできませんでした。結果として、リード/ライト両方が不可になっており、イニシャル処理すら通らない状況になっていました。

最初ロジックアナライザで波形を確認していましたが、スレッショルドの設定が出力されているレベル以下になっていた為、その時点では発見できませんでした。今思い返してみると、何故最初からアナログ波形で確認しなかったのかと思いますが、この時はすぐに使用できる状況でなかったこともあり、そこまで対応しませんでした。
なお、なぜこの間違いになかなか気づくことができなかったというと、ICEを接続して使用するデバッグ基板では、このCFへアクセスするときのCS7信号は出力されなかった為です。(この仕様がなぜそうなっているかについては、不明です)

以下に、マイコンのメモリマップを示します。

網掛け部分が全てCS7空間として認識されていました
図1. CS空間

2-2-4. 対策

この現象の対策としては、以下を提案しました。

  • CFアクセス時はCS7信号を出力させないようにする。

    開発対象のH8マイコンには、バスアクセス時にCS7信号を出力するかどうかを決められるレジスタがある為、CFアクセス時にそのレジスタを操作することで対策できます。

CFアクセスする際には毎回ポート制御とレジスタ設定の変更を行う必要がありますので、制御としては遅くなってしまいますが、仕方のないところでした。上記対策を打った結果、最終的には、実装基板でもCFへのアクセスが可能になり、正常に(デバッグ基板と同じように)動作するようになりました。
結果として、原因は「CFアクセス時にCS7が出力されることを考慮できていなかった」ということになります。

(※1)
ICE(In-Circuit Emulator) … CPUの機能をエミュレートする装置。デバッグ機能を持つ。
(※2)
BSC(Bus State Controller) … バスステートコントローラ。CPUの外部バス制御を行うコントローラ。使用するバス幅やウェイト、デバイス種類の選択等を行う。
(※3)
CPLD(Complex programmable logic device) … ユーザーの手で内部論理回路を変更できる集積回路(PLD)を複数内部で接続した構成となる。
3. 機能追加による弊害
3-1. 既存処理への機能追加する際の注意点

元々の機能だけであれば動作していたのに、新たな機能や基板の改造を行った為に動作しなくなるということがあります。この場合、例えば必要なメモリサイズが不足していることや、ソフトウェアの問題が考えられます。

3-2. RTOSを使用したシステムへの機能追加時の問題と対策
3-2-.1 問題の発生経緯

本開発では、H8マイコンと、OSとしてμITRON準拠のRTOS(※4) NORTi Version 4(※5)を使用しています。
2.1の問題での対策を行った後、しばらくは問題ありませんでしたが、ウォッチドッグタイマ(WDT)やタスク優先度の関連で、問題が発生しました。弊社で動作確認に使用していたお客様から頂いた既存ソフトは既に使用されておらず、新システムに合わせて改造が施されたソフトが使用されており、そちらで問題が発生していたとのことでした。
この時は、既に検収済みであり、お客様のほうでの納期も間近になっており、私としても報告を迅速に行うように心がけました。

3-2-2. 原因はタスクの追加による競合

発生した問題としては、CFのタスクを追加(ファイルシステムを用いている為、自動的にタスクが一つ生成されます)したことによって、他タスクとの競合が発生してしまい、結果、システムがデッドロックしてしまうということでした。
問題の内容としては、CFへ書き込みが行われる際、数回に一回の割合で、WDTによるリセットが発生する、というものです。

原因は以下のとおりです。

  • 外部WDTクリア関数をメインループ内で繰り返しコールしていたことにより、メインタスクで処理が間に合わなくなり、「メッセージバッファへ送信」システムコール(snd_mbf)で待ちが発生してしまう。その為、WDTリセットを行うIO制御タスクが待ちになってしまい、その結果、WDTのリセットがかかってしまう。
3-2-3. 対策

この現象の対策としては、以下を提案しました。

  1. メインタスク優先度を上げる

    メインタスクが正常に処理できれば、待ち状態になりませんので、メインタスク優先度を関係のあるタスクより上位へ上げてやれば、動作します。

  2. snd_mbf関数の換わりに別のシステムコール(psnd_mbf関数)を使用する

    snd_mbf関数は、送信不可であれば、送信待ち状態になりますが、タイムアウトでエラーを返す関数が別にありますので、エラーの場合に適切な処理をすれば問題ありません。

  3. CFのアプリでは外部WDTクリア関数をコールしない

    メインタスクと、CFタスクは、マルチタスクで動作しますので、通常、WDTにひっかかることはないと考えられます。

そもそもの要因は、旧システムでは存在しなかったCFアプリ内で、外部WDTクリア関数がメインタスクのwhileループ毎にコールされるようになった為でした。最終的には、お客様の判断により、C.の対策を行った後、外部WDTクリア関数を実行するのではなく、直接ポートをたたく処理を挿入することでOKとなりました。

(※4)
RTOS(Real Time Operating System) … リアルタイムOS。リアルタイム性を重視した処理を行うための機能を実装したOSのこと。
(※5)
NORTi Version4 … 株式会社ミスポ製 uITRON4.0仕様に準拠したリアルタイムOS。
4. 開発を振り返って

今回の開発では、私の至らない点が数多くありましたが、上司からの多くの助言もあり、なんとか完了させることができました。
また、調査が必要な問題が発生する度に、OSやハードウェアについて調べ直すところも多く、その度に知識がついていったというところもあります。(本来であれば、事前に調べておく必要があったところだと思いますが、最初にそこまで検討出来ませんでした)

これらの問題解決へのアプローチを検討する際には、多くは経験が必要となると考えられますが、上司や先輩社員によく相談し、助けてもらうことで、早期解決に役立つことが多いと感じさせられました。
また、細かいところを突き詰めて調査していくだけでなく、一度基本に立ち返る、全体として見直すというところも非常に重要だと考えさせられました。

今回のような、システムの一部だけを担当する場合や、デバイスドライバに密着しておりハードウェアのデバッグ等が必要な場合には、担当範囲を明確にしておくだけでなく、予定外の作業に関してもある程度見通しを立て、余裕を持って進めるようにするということが、注意点として挙げられると思います。

5. 最後に

弊社はソフトウェア開発を行っていますがデバイスドライバなどハードウェアに密着したソフトウェアを作成している以上、ハードウェアを用いたデバッグ、テストや不適合対応の作業などは必ず発生します。
上述したとおり、そのような場合にも、お客様の状況に合わせた柔軟な対応を行っています。
今回紹介した例で言えば、CPU実装基板でのデバッグ等、当初は範囲外となっておりましたが、ソフト/ハードの問題点切り分けという意味で積極的に行うことで、問題解決までの時間を早めることができました。

今後とも、ハードウェアへの対応にも積極的に取り組んでいきたいと思います。

(Y.S.)

[参考文献]
SanDisk CompactFlash Memory Card OEM Product Manual Version 12.0

関連ページへのリンク

関連するソフテックだより