株式会社 ソフテック
制御用ソフトウェアの受託開発を手がけて５２年の経験と
受注案件６９９５件（2024年3月末時点）の実績
受注案件６９９５件（2024年3月末時点）の実績
「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。
ソフテックだより（発行日順）のページへ
ソフテックだより 技術レポート（技術分野別）のページへ
ソフテックだより 現場の声（シーン別）のページへ
本号では、前号（第97号 2009年9月2日 技術レポート「ハードウェアを含めたデバッグの難しさ 1」）の続きの内容となります。
前号で紹介し切れなかった、「デバイスの仕様／特性の把握」と「機能追加による弊害」の2点を、開発のまとめとともに、紹介したいと思います。
CPUマニュアルなどはページ数が多く、全ての内容を把握するのは困難ですが(もちろん時間があれば把握するに越したことはありません)、最後のページの注意点などに重要な制限事項が書かれていたりします。
また、メーカーのHPに製品のアップデート情報やバグ情報が出ていたりするので、場合によってはそちらも合わせて調査する必要があります。
開発対象となる基板には、機能を実現する為に、多くの場合はターゲットとなるマイコン以外にもSRAM、SDRAMなどのデバイスが搭載されています。マイコンが複数のデバイスへアクセスする場合には、基本的にはバスは共通で使用されます。その為、アクセスの競合が発生したりすると、データが化けたり、正しく制御できなくなります。
一度テストまで完了した後、ブラシアップ期間(お客様に動作確認していただきながら仕様や使い勝手などの向上を行う)をもともと設けていたため、納期より前に暫定版リリースを行いました。
お客様より、(今まで使用していた)ICE(※1)が接続可能なデバッグ基板での動作としては問題ないという回答を頂き、コンパクトフラッシュ(CF)への保存データの変更など細かい対応を進めていたのですが、後日、デバッグ基板では動くが、CPU実装基板だと動かないという連絡を頂きました。
もともと、CPU実装基板での確認は対応範囲としては含まれていませんでしたが、動作しないことは問題ですので、お客様にCPU実装基板を送って頂き、調査を開始しました。
行ったことを以下にまとめます。(お客様より、基板上の違いは、実チップが載っているかICE接続用のソケットが載っているかどうかだけだったとお聞きしましたので、ソフトの調査から進めました) ハードウェア絡みではソケット以外に違いがないとはいえ、基板改修を行っている為、端子の接続なども考慮して確認を行っていきました。
ICEを使用した場合としていない場合での違いで考えると、メモリの初期化等が正常に行われていない可能性がありますので、確認しましたが、問題ありませんでした。
ソフトウェアから追っていきましたが、ドライバのイニシャル時点でCFにアクセス出来ていないことが分かりました。
マイコンの各端子からの出力、CFからの出力それぞれをロジックアナライザで取得し、確認しました。デバッグ基板とCPU実装基板で同じ波形が出力されており、ここに問題はなさそうでした。
設計上はICEが接続されるかそうでないかの違いだけといっても、基板の改修を行っていることもあり、テスターでCFと接続されている端子の、導通チェックを行いました。ここも正常に接続されていることが確認できました。
ICEの設定が間違っているのでは、という点で見直し、クロック設定が間違っていることが分かりました。修正し、再度動作確認を行いましたが、状況は変わりませんでした。
BSC(※2)の調整を行い、再度CFのマニュアルの見直しを行いながら、余裕を持たせた波形などに切り替えてみましたが、状況は変わりませんでした。
データバスの出力がCPLD(※3)と競合していることが判明しました。
上記のように、時間をかけていろいろ進めていましたが、糸口はなかなかつかめませんでした。
ハードウェア側からの確認も万策尽きたかというところで、オシロスコープでアナログ波形の確認を行いました。そうしたところ、実装基板で、CFへアクセスする際にCPLDへ接続されているCS7信号がアクティブ（ローレベル）になっていることが分かりました。
オシロスコープで確認したところ、やはりCS7空間にアクセスしている為、データバス出力が競合しており、正常にアクセスできませんでした。結果として、リード/ライト両方が不可になっており、イニシャル処理すら通らない状況になっていました。
最初ロジックアナライザで波形を確認していましたが、スレッショルドの設定が出力されているレベル以下になっていた為、その時点では発見できませんでした。今思い返してみると、何故最初からアナログ波形で確認しなかったのかと思いますが、この時はすぐに使用できる状況でなかったこともあり、そこまで対応しませんでした。
なお、なぜこの間違いになかなか気づくことができなかったというと、ICEを接続して使用するデバッグ基板では、このCFへアクセスするときのCS7信号は出力されなかった為です。(この仕様がなぜそうなっているかについては、不明です)
以下に、マイコンのメモリマップを示します。
図1. CS空間
この現象の対策としては、以下を提案しました。
開発対象のH8マイコンには、バスアクセス時にCS7信号を出力するかどうかを決められるレジスタがある為、CFアクセス時にそのレジスタを操作することで対策できます。
CFアクセスする際には毎回ポート制御とレジスタ設定の変更を行う必要がありますので、制御としては遅くなってしまいますが、仕方のないところでした。上記対策を打った結果、最終的には、実装基板でもCFへのアクセスが可能になり、正常に(デバッグ基板と同じように)動作するようになりました。
結果として、原因は「CFアクセス時にCS7が出力されることを考慮できていなかった」ということになります。
元々の機能だけであれば動作していたのに、新たな機能や基板の改造を行った為に動作しなくなるということがあります。この場合、例えば必要なメモリサイズが不足していることや、ソフトウェアの問題が考えられます。
本開発では、H8マイコンと、OSとしてμITRON準拠のRTOS(※4) NORTi Version 4(※5)を使用しています。
２．１の問題での対策を行った後、しばらくは問題ありませんでしたが、ウォッチドッグタイマ(WDT)やタスク優先度の関連で、問題が発生しました。弊社で動作確認に使用していたお客様から頂いた既存ソフトは既に使用されておらず、新システムに合わせて改造が施されたソフトが使用されており、そちらで問題が発生していたとのことでした。
この時は、既に検収済みであり、お客様のほうでの納期も間近になっており、私としても報告を迅速に行うように心がけました。
発生した問題としては、CFのタスクを追加(ファイルシステムを用いている為、自動的にタスクが一つ生成されます)したことによって、他タスクとの競合が発生してしまい、結果、システムがデッドロックしてしまうということでした。
問題の内容としては、CFへ書き込みが行われる際、数回に一回の割合で、WDTによるリセットが発生する、というものです。
原因は以下のとおりです。
この現象の対策としては、以下を提案しました。
メインタスクが正常に処理できれば、待ち状態になりませんので、メインタスク優先度を関係のあるタスクより上位へ上げてやれば、動作します。
snd_mbf関数は、送信不可であれば、送信待ち状態になりますが、タイムアウトでエラーを返す関数が別にありますので、エラーの場合に適切な処理をすれば問題ありません。
メインタスクと、CFタスクは、マルチタスクで動作しますので、通常、WDTにひっかかることはないと考えられます。
そもそもの要因は、旧システムでは存在しなかったCFアプリ内で、外部WDTクリア関数がメインタスクのwhileループ毎にコールされるようになった為でした。最終的には、お客様の判断により、C．の対策を行った後、外部WDTクリア関数を実行するのではなく、直接ポートをたたく処理を挿入することでOKとなりました。
今回の開発では、私の至らない点が数多くありましたが、上司からの多くの助言もあり、なんとか完了させることができました。
また、調査が必要な問題が発生する度に、OSやハードウェアについて調べ直すところも多く、その度に知識がついていったというところもあります。（本来であれば、事前に調べておく必要があったところだと思いますが、最初にそこまで検討出来ませんでした）
これらの問題解決へのアプローチを検討する際には、多くは経験が必要となると考えられますが、上司や先輩社員によく相談し、助けてもらうことで、早期解決に役立つことが多いと感じさせられました。
また、細かいところを突き詰めて調査していくだけでなく、一度基本に立ち返る、全体として見直すというところも非常に重要だと考えさせられました。
今回のような、システムの一部だけを担当する場合や、デバイスドライバに密着しておりハードウェアのデバッグ等が必要な場合には、担当範囲を明確にしておくだけでなく、予定外の作業に関してもある程度見通しを立て、余裕を持って進めるようにするということが、注意点として挙げられると思います。
弊社はソフトウェア開発を行っていますがデバイスドライバなどハードウェアに密着したソフトウェアを作成している以上、ハードウェアを用いたデバッグ、テストや不適合対応の作業などは必ず発生します。
上述したとおり、そのような場合にも、お客様の状況に合わせた柔軟な対応を行っています。
今回紹介した例で言えば、CPU実装基板でのデバッグ等、当初は範囲外となっておりましたが、ソフト/ハードの問題点切り分けという意味で積極的に行うことで、問題解決までの時間を早めることができました。
今後とも、ハードウェアへの対応にも積極的に取り組んでいきたいと思います。
（Y．S．）
関連ページへのリンク
関連するソフテックだより