JDE - チュートリアル - JSD-STM32F103-P52 ROMモニタの構築とブート書き込み

　STM32F103-P52 モニタ実行サンプルプログラム　STM32F103-P52 リセット実行サンプルプログラム

■ このチュートリアルで使うボード ■

組込プログラムではリセットスタートで起動し、自分自身で必要なハードウェアの初期化をするプログラムが基本となります。
そのようなプログラムの例としてROMモニタをとりあげます。
ここではROMモニタをソースから構築してCPUボードに書込むまでの手順を説明します。

1. このチュートリアルで使うボード

   JSD-STM32F103-P52 CPUボード		JSD-OPENOCD-JTAGボード
   CPU CLOCK USB SCI SPI CAN A/D TIMER ROM RAM 電源 その他	STM32F103 72MHz 1CH コネクタ有り 3CH 端子直接接続 2CH 1CH 12bit x 15CH 16bit x 6CH 128KFLASH内蔵 20K内蔵 5V or USBバスパワー ブレッドボード対応の端子 ONボードにLED ｘ ８ 圧電ブザー取付可 OPENOCD-JTAG対応 回路図	CPU 電源 機能	FTD2232D USBバスパワー USB-SERIAL１CH（TTLレベル） オープンソースopenocd互換 Flash書き込み 回路図

   ターゲットボードとしてSTM32F103-P52を使います。
   STM32F103Uはコード効率の良いARMアーキテクチャcortex-m3を採用したCPUで高性能でありながら外付けクロック、リセット回路無しでも動作可能、高分解能A/D内蔵、豊富なタイマ機能内蔵などが組み込み用として使いやすいCPUです。
   STM32F103Uはシリアル経由のブート書込も可能ですが、ここではinsight(GDB)を使ったデバッグとフラッシュ書き込みが出来るOPENOCD対応のJTAGボードを使ってブート書き込みをおこないます。

2. STM32F103-P52のプログラムを開発するためのGNUTOOL

   stm32f103のプログラム開発にはarm-none-eabi-gcc.exe を中心とするGNUTOOLを使います、
   JDEのGNUTOOLディレクトリにARM-NONE-EABI4_2_1が必要です。　
   GNUTOOLがインストールされてない場合はGNUTOOLのインストールを参考にしてarm-none-eabi4_2_1.exe をダウンロードしてインストールして下さい

■ ブート書込：ROMモニタの構築・書込・実行 [JSD-STM32F103-P52] ■

組込プログラムではリセットスタートで起動し、自分自身で必要なハードウェアの初期化をするプログラムが基本となります。
そのようなプログラムの例としてROMモニタをとりあげます。
ここではROMモニタをソースから構築してCPUボードに書込むまでの手順を説明します。

1. stm32f103-p52 ROMモニタプロジェクトを開いてプログラムを構築する。

   プロジェクトはJDEVer5.07のインストールで JDE\work\stm32f103-p52\mon_stm32f103-p52_V10\mon_stm32f103-p52_v10.jpr としてインストールされています。

   メニューからプロジェクト mon_stm32f103-p52.jpr を開き（再構築）をクリックします。
   コンパイルメッセージ欄に「コンパイルとリンクが終わりました」と表示されたら構築完了です。
   エラーが発生した時は下図と較べて設定を確認して下さい。
   
   
   
   どのようなメモリ配置でプログラムが作成されたかを確認するにはメッセージ欄の文字 mon_stm32f103-p52.map をダブルクリックします。
   表示されたエディタウィンドウでまず .text という文字列を検索してみます。
   .textはプログラムのセクションでプログラムが0x08000130から0x5384のサイズで展開されていることを示しています。
   stm32f103ではフラッシュメモリが0x08000000に配置されており、0x00000000からも同じ内容を読み出すことが出来るようになっています。

   セクション.isr_vectorは割り込みベクタテーブルでstm32f10x_vector.cに記述されています、stm32f103はリセット後このベクタテーブルの先頭から1番目にある値をスタックにセットし、2番目にあるReset_Handlerのアドレスを参照してそこへジャンプします。
   
   これは.textセクションの 0x8000130 から 0x50のサイズで 関数stm32f10x_vector.cをコンパイルしたstm32f10x_vector.oというオブジェクトが配置され 関数Reset_Handler が0x8000130に配置されました。 という意味のメッセージです。　

   同様に .bss .heap .stack 等について検索するとメモリ配置がCPUの内蔵ROM、RAMの範囲を超えていないことを確認できます。
   リンカスクリプトで定義されたROM、RAMの範囲を超えてリンカエラーが発生した時以外はこのマップファイルを確認しなければならないことはほとんどありませんが、リンカスクリプトを変更してメモリ配置をカスタマイズする場合はmapファイルの情報が役に立ちます。
   
   
   
   次にmon_stm32f103-p52.motをダブルクリックして生成された転送用のSフォーマットファイルを見てみます。
   これは下図のようにプログラムのバイナリデータをアスキー文字でフォーマット化したものです。
   先頭5-8文字がアドレスで続いて16進表記のデータが続き最後の2文字がチェックサムになっています。
   通常はこのファイルを意識する必要はありませんが組み込みプログラムの基礎知識としてどのような形式のファイルが生成・転送されるかを知るために一度は確認しておくと何かの時に役立ちます。
   
   

2. 構築したプログラムをブート書き込みでCPUの内蔵FlashROMに書き込む

   OOCD-JTAGによるブート書き込みを参照してOOCD-JTAGボードとCPUボードを接続し構築したモニタプログラムをCPUボードに書き込んでください。
   

3. モニタの起動

   書き込んだモニタを起動してみます。
   青枠で囲んだリセットボタンを一度押して、左端のLEDが点滅を開始したらモニタが正常に動作しています。
   
   
   モニタ起動のプログラムが存在しないときはリセットボタンでモニタが起動します。
   　一度プログラムを書き込むとリセットボタンで書き込んだプログラムが起動するようになります、強制的にモニタを起動するときは黄色い枠で囲んだボタンを押したままリセットボタンを押して離しモニタLEDが点滅開始するまでしばらく待ちます。
   
   通信プログラムを起動してENTERキーをたたくとモニタプロンプトが表示され、’？’を入力するとモニタコマンド一覧が表示されます。
   
   
   

■ プログラムのリセット起動とモニタ起動 ■

プログラムをモニタから起動する場合のメリット、デメリットについてはプログラムのモニタ起動に説明があります。
実際にはターゲットCPUボードによってブート書き込みの方法やメモリの容量が異なるためリセット起動とモニタ起動のどちらを選ぶべきかは変わってきます、ここではstm32f103-p52の場合についてリセット起動とモニタ起動を比較してみます。

1. リセット起動とモニタ起動の比較

   	リセット起動	モニタ起動
   書き込み速度	10KB / sec	8..5KB / 4sec
   使用できるRAM	20KB	18KB
   使用できるROM	128KB	100KB
   書き込みに必要なツール	OOCD-JTAG	USBケーブルのみ
   USB標準入出力サポート	無し	有り
   プログラムのCRCチェック	無し	有り
   プログラム名と日付の記録	無し	有り

2. リセット起動

   リセット起動の場合、CPUのハードウェアリソースを全て使うことが出来ますがCPU機能イニシャライズ全ての面倒をみなければなりません。
   USB機能を使わない、外付けクロックを使わない場合はブート書き込みでリセット起動のプログラムを使うことになります。

3. モニタ起動

   stm32f103-p52CPUボードでの組み込みプログラム入門はモニタ起動のプログラムがお奨めです。
   簡単なプログラムで始めることができ、printfを使っての動作確認も簡単です。

■ JTAGを使ったデバッグとprintfデバッグ ■

デバッグにはJTAGとデバッガソフトinsight(GDB)を使う方法と、printfデバッグがあります。PC上でのプログラム開発はデバッガを使うのが効率的ですがボード上のプログラムをデバッグするには両者をうまく使い分けるのが効率的です。

1. JTAGによるデバッグとprintfデバッグの比較

   	JTAGデバッグ	printfデバッグ
   デバッグの手間	やや煩雑	簡単
   プログラムトレース	可	不可
   コードの解析	得意	不得意
   デバッグに必要なツール	OOCD-JTAG	USBケーブルのみ
   プログラム構造の勉強	向いている	不向き
   プログラム経験の必要性	初心者、ベテラン	ベテラン
   リアルタイム事象のデバッグ	不得意	得意

2. JTAGによるデバッグ

   insight(GDB)とJTAGを使ったデバッグでソースコードレベルでプログラムの動作をトレースし、レジスタ、変数の値を確認することができます、
   Cのソースがどのようにアセンブラに展開されているかを確認しながらステップ実行をおこなうことも出来るので、コンパイラの動作やCPUの動きを勉強するのに向いています。
   　一方、リアルタイム動作の問題を解析するのには向いていませんし最適化により発生する問題の解析にも向いていません、USBやモータ制御などの最終段階でのデバッグはprintfデバッグが活躍します。

3. printfデバッグ

   監視したいポイントにターゲットを絞ってprintfで情報を出力できるため、組み込みプログラムの難しさであるタイミングに起因して起きる不具合の解析に向いています。ただし、出力すべき情報の絞り込み、printf関数のオーバヘッドなどが把握できる経験豊富なプログラマでないとprintfデバッグのメリットを使いこなせない面もあります。