マイコンとプロセッサでのソフト開発の違い：マイクロプロセッサQ&Aハンドブック（7）（3/5 ページ）

[小谷豊（STマイクロエレクトロニクス），EDN Japan]

開発体制の違いからくる問題の事例

　開発体制の規模の拡大からからくる問題点もあります。そのような状況でよくある問題の例を見てみましょう。

　ここでは、ボードが完成したが、うまく起動しないときの調査を例に挙げます。

具体例

　ボードが完成しましたが、うまく起動しません。ボードは評価ボードからピンアサインなどを変更しています。

　ハードウェア担当者とソフトウェア担当者が別れています。また、それぞれの担当者が別々の会社です。

問題点

　それぞれの担当者が技術上の調査時、それぞれの責任の箇所のみを調べていますが、一向に問題の原因が分からず調査が難航しています。

原因

　ピンアサイン変更といったハードウェアのカスタマイズ部分に対応して必要なソフトウェアのカスタマイズが実施されていませんでした。コンソール用のUARTやPMIC接続用のI2Cのピンアサインの変更をした際に、デバイスツリーを変更してブートローダーのピンアサイン変更に対応していませんでした。また、原因調査時には、デバッグ用のJTAGやSWD用のコネクターやブート失敗を知らせるLEDなど、効率的なソフトウェアデバッグに必要なインタフェースが基板に搭載されておらず、効率的なデバッグが実施できませんでした。

問題発生に至る背景

　上記の例のように、原因自体は単純なピンアサインの変更だったとしても、ハードウェア担当者からソフトウェア担当者に、半導体ベンダーの評価ボードからピン割り当てをどのように変更したかの情報が連絡されていないと、調査は困難になります。また、ハードウェア担当者はブートローダのカスタマイズは自分の担当範囲外なので、コンソール用のUARTやPMIC接続用のI2Cのピンアサインの変更をした際に、デバイスツリーを変更してブートローダーのピンアサインカスタマイズ対応が必要だと知らないことがほとんどです。

　プロジェクトマネジャーはハードウェア担当者とソフトウェア担当者両方から状況のヒアリングをして調査を指揮しますが、コンソール用のUARTやPMIC接続用のI2Cのピンアサインの変更した際に、ブートローダーのデバイスツリーのカスタマイズとビルドが必要という知識がない場合、ソフトウェア担当者にデバイスツリーのカスタマイズとブートローダーのビルドが調査内容として割り当てられず、ボードに合わせてブートローダーをカスタマイズする箇所は責任境界がグレーな部分として残り、いつまでも調査が終わらないといった事態が発生します。

対策例

　回路図設計時の回路図チェックリストに、ソフトウェア変更に影響のある項目、コンソール用UARTのピンアサインやPMIC用のI2Cのピンアサインは評価ボードのものを流用する、デバッグに必要なデバッグ用インタフェースの追加項目を盛り込むといった対策が考えられます。ソフトウェア担当者に回路図チェックリストのデバッグ用インタフェースの項目のレビューを依頼するといったアクションを取ることで、大幅な手戻りを避けられます。