技術レポート「ハードウェアを含めたデバッグの難しさ２」

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-1 既存処理への機能追加する際の注意点

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

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

3-2-1 問題の発生経緯

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

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

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

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

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

3-2-3 対策

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

Ａ．メインタスク優先度を上げる

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

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

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

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

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

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

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

1. はじめに

2. デバイスの仕様/特性の把握

3. 機能追加による弊害

4. 開発を振り返って

5. 最後に