- ベストアンサー
h8マイコン GNU環境 プログラムにおけるライブラリ関数の利用
- 秋月のH8/3048Fマイコンボードを利用して測定システムの開発を行っています。
- A/D変換を行うプログラムを作成していますが、実際に動かすことができません。
- ライブラリ関数の使い方がおかしいのか、プログラム自体がまともに動かなくなってしまいます。
- utaibito33
- お礼率64% (34/53)
- その他（プログラミング・開発）
- 回答数3
- ありがとう数3
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
メモリマップ的にはオーバーしていないようです。 原因はわかりませんが、気になることがあります。 ANo2.のお礼 >Memory Configuration >vector 0x00020000 0x00000100 xr >rom 0x00020100 0x00007f00 xr >ram 0x00028000 0x00007000 rw >stack 0x0003f000 0x00001000 rw というロケーションであることが分かりました。 ANo1のお礼 >_startと.mvdataの逆アセンブルコードが >0x00020000 extu.w r2 >0x00020002 add.w #0x30,r2 >0x00020006 mov.w r2,r1 >0x00020008 mov.w #0x1,r0 >0x0002000c jsr @0x2012a:24 とありますが、20000から0x100はベクターテーブル のはずだと思いますが、おかしくありませんか？
その他の回答 (2)
- R32C
- ベストアンサー率39% (115/290)
まったく動いていないということは、リンク、ロケートが正しくされていないっぽいです。 浮動小数点ライブラリが有効になることで、コード領域（textセクション相当）が増え、正しくロケートされていないか確認してください。 AD_test.map を 浮動小数点を使う場合と使わない場合で見比べてみればいいでしょう。
お礼
初心者な質問で申し訳ないのですが、ライブラリのシンボルが書き込まれている場所がコード領域であることが正しくロケートされていないということなのでしょうか？ 浮動小数点を使う場合、標準Cライブラリより浮動小数点演算に必要なものを有効にすると思いますが、自分のマップファイルでは、字数制限のためすべて載せれませんが、ライブラリの領域は、 Memory Configuration vector 0x00020000 0x00000100 xr rom 0x00020100 0x00007f00 xr ram 0x00028000 0x00007000 rw stack 0x0003f000 0x00001000 rw .vectors *(.vectors) .text 0x00020540 0x2e0 /usr/h8/lib/gcc/h8300-elf/3.4.6/h8300h/libgcc.a(_addsub_sf.o) 0x000207a4 ___subsf3 0x00020732 ___addsf3 .text 0x00020820 0x1d0 /usr/h8/lib/gcc/h8300-elf/3.4.6/h8300h/libgcc.a(_mul_sf.o) 0x00020820 ___mulsf3 .text 0x000209f0 0x84 /usr/h8/lib/gcc/h8300-elf/3.4.6/h8300h/libgcc.a(_si_to_sf.o) 0x000209f0 ___floatsisf .text 0x00020a74 0x8e /usr/h8/lib/gcc/h8300-elf/3.4.6/h8300h/libgcc.a(_sf_to_si.o) 0x00020a74 ___fixsfsi .text 0x00020b02 0x132 /usr/h8/lib/gcc/h8300-elf/3.4.6/h8300h/libgcc.a(_pack_sf.o) 0x00020b02 ___pack_f .text 0x00020c34 0xb0 /usr/h8/lib/gcc/h8300-elf/3.4.6/h8300h/libgcc.a(_unpack_sf.o) 0x00020c34 ___unpack_f *(.strings) *(.rodata) .rodata 0x00020ce4 0x8 /usr/h8/lib/gcc/h8300-elf/3.4.6/h8300h/libgcc.a(_thenan_sf.o) 0x00020ce4 ___thenan_sf でした。これがすでに正しくロケートされてないということなのでしょうか？
- R32C
- ベストアンサー率39% (115/290)
H8 gccで浮動小数点は、利用したことはありませんが、 ライブラリ libgcc.a が １）もともと対応していないもの ２）対応しているが、コード領域が不足している のどちらかが問題が発生する場合があると思います。 さらに具体的に以下のことを提示いただけますか １）プログラムはどこまで動くのか？ リセットベクターからスタートすると思いますが、 そこからユーザープログラムの先頭であるmain() main()から演算処理まであると思いますがどこまで 動くのでしょうか？ もしくはリセットベクターすら 動かないのでしょうか？ ２）演算処理の逆アセンブラ 演算処理を行う部分の逆アセンブラでは、どんなコード になっていますか？
お礼
R32様、毎回の回答ほんとうにありがとうございます。 1）プログラムはどこまで動くのか？ _start関数を逆アセンブルしたところまったくおかしくなっていまして、リセットベクタの時点で止まっています。 2）startの時点でおかしいのでその部分の逆アセンブラコードを載せたいと思います。 まず、スタートアップルーチンh8_3048f.Sの内容 .h8300h .section .text .global _start .extern _main .extern ___dtors_end .extern ___data .extern _stack _start: /*スタックポインタの初期化*/ mov.l #_stack,sp /*初期値のある書き換えデータ領域のコピー。ROM->RAM。*/ mov.l #___dtors_end,er0 mov.l #___data,er1 mov.l #_edata,er2 .mvdata: mov.l @er0,er3 mov.l er3,@er1 adds #4,er0 adds #4,er1 cmp.l er2,er1 blo .mvdata /*main()をコール*/ jsr @_main /*終了処理は無限ループ*/ _loop: bra _loo これで、浮動小数点演算を行うA/D変換プログラムとリンクした出力ファイルの_startと.mvdataの逆アセンブルコードが 0x00020000 extu.w r2 0x00020002 add.w #0x30,r2 0x00020006 mov.w r2,r1 0x00020008 mov.w #0x1,r0 0x0002000c jsr @0x2012a:24 0x00020010 mov.w @(0xfffc:16,er6),r2 0x00020014 subs #1,er2 0x00020016 mov.w r2,@(0xfffc:16,er6) 0x00020018 mov.b #0xfc,r7l 0x0002001a bra .-56 (0x1ffe4) 0x0002001c mov.w #0x20,r1 0x00020020 mov.w #0x1,r0 0x00020024 jsr @0x2012a:24 0x00020028 mov.w #0x56,r1 となっています。ちなみに@0x2012aはLCDOUT4というLCDへの4ビット出力関数の始まりのアドレスです。 それと、浮動小数点演算を使用しない場合のA/D変換のプログラムも作ってみたところ、リセットベクタよりmain関数にジャンプしており正常にプログラムは動作します。やはり、ライブラリ関数の組み込み方によって、いろいろな部分がおかしくなってしまっているのでしょうか？
お礼
すみません。どこがおかしいのか試行錯誤していました。リンカスクリプトの部分を変更していたら、お礼に書いた逆アセンブルコードの時はvector領域を宣言してない場合のものです。両者が同じものではないです（＾＾； >Memory Configuration >vector 0x00020000 0x00000100 xr >rom 0x00020100 0x00007f00 xr >ram 0x00028000 0x00007000 rw >stack 0x0003f000 0x00001000 rw とした場合、No.1のお礼で表示したコードのアドレスに0x100がプラスされたものになります。 ただ、確実におかしくなっているのはこの部分だと断定できると思います。実際のアセンブラコードは、まったく違うものですので。 それと、本日GDBより、stubから外部RAM領域に書き込む前にアセンブラコードを表示したら、アセンブラコードが 0x00020100 <_start+0>: 7a 07 00 03 f0 00 mov.l #0x3f000,er7 0x00020106 <_start+6>: 7a 00 00 02 0c ec mov.l #0x20cec,er0 0x0002010c <_start+12>: 7a 01 00 02 80 00 mov.l #0x28000,er1 0x00020112 <_start+18>: 7a 02 00 02 80 00 mov.l #0x28000,er2 0x00020118 <.mvdata+0>: 01 00 69 03 mov.l @er0,er3 0x0002011c <.mvdata+4>: 01 00 69 93 mov.l er3,@er1 0x00020120 <.mvdata+8>: 0b 90 adds #4,er0 0x00020122 <.mvdata+10>: 0b 91 adds #4,er1 0x00020124 <.mvdata+12>: 1f a1 cmp.l er2,er1 0x00020126 <.mvdata+14>: 45 f0 bcs .-16 (0x20118) 0x00020128 <.mvdata+16>: 5e 02 03 52 jsr @0x20352:24 最終的にmain関数に飛ぶようになっていたんです。 書き込みのときにおかしくなっているとも考えられるような気がしてきました。