2018年4月8日日曜日

STM32CubeMX で出力される code の start addressを 0x4000 に変更する方法

ArmBootloader でその後起動する firmware の start address は MCU の reset vector に配置するのではなく、ArmBootloader で管理する firmware 領域の top に配置する必要がある.
今回 STM32F767 (実際は STM32H743 を使用したいが, NUCLEO 未到着) と STM32CubeMX が生成する code で, 単に board 上の LED を点滅される (GPIO を high / low させるだけ) code で FreeRTOS を追加すると FreeRTOS 部分で処理が止ってしまう現象があり 0x40000 に移動させるのに苦労してしまったので, 記録しておく.

環境
arm-none-eabi-gcc:   (15:5.4.1+svn241155-1) 5.4.1 20160919
STM32CubeMX:  4.25.0 (STM32F7: 1.11.0)

ちなみに STM32F767 の Flash ROM の Sector の都合により firmware の top address を 0x4000 でなく, 0x40000 となっています (ゼロの数に注意).


最終的な変更部は以下の通り,
### 1.   $(project_top)/STM32F767ZITx_FLASH.ld  内 FLASH 領域の変更
FLASH (rx)      : ORIGIN = 0x8040000, LENGTH = 0x1c000      /* address, size に変更 */

### 2.   $(project_top)/Src/system_stm32f7xx.c の VTOR の変更
  extern uint32_t       g_pfnVectors;      /* defined in startup_stm32f767xx.s */
  SCB->VTOR = &g_pfnVectors;


以上であるが, うまくいかなっかった点は, 2 番目の g_pfnVectors の扱いで, .s 内の assembler の label を C から参照するのに, label = pointer = address の場所という感覚であるので
     extern uint32_t       *g_pfnVectors;
     SCB->VTOR = g_pfnVectors;
したが, これでは ng で, assembler の label は, C はなんらかの value その物という解釈らしいので, uint32_t * でなく, uint32_t と extern し, VTOR の vector top register に格納する時に & するのが良いみたいだ.




STMCubeMX が出力する Makefile の SOURCES にいくつかの source が 2 重に定義されており linker で error になる. 手で削除が必要.
また, それなりに動作する sample code が得られると思ったが, 単に compile が成功する code が得られるだけで, たとえば usb audio でとりあえず stream が STM に流れるものが入手できるわけではなく, 色々 code の追加が必要そう. Kinetis はそれなりに動く code が入手できるのだが, ST はあまりそう気はないのだろうか.   RCC の HSE の周波数設定が間違っていただけでした...



2018年3月10日土曜日

20年ぶりの開局むけて


ちょっと前に 1 マアの資格を取った. モールスの実技がなくなり, 英文の筆記はあるが和文が完全になるなり, これならいけるだろうと言う事で受けた. 試験内容的には, 電卓がいらない試験の為計算問題といっても開平するといっても結果整数になる様なものしかない試験なので, それほど難しいわけでもない. とは言え国家資格試験で値段的に 1 万円に近い試験料なので, 2 回も受けるのはもったいないということで, 通勤時間だけだがそれなりには勉強した.

ところで最近のアマチュア無線ってどうなっているのかと色々な site を見ていると,  JT65 や FT8などという digital 通信がはやっているみただ. ただ, 通信 rate は破格の数 baud とかという遅さ. しかし正に地球の裏側まで行く様な通信方式になっている. なんか面白そうだと思ってしまって, ちょっと試してみたいと思ってしまった. そこでふらふら数も少なくなった無線機屋に行きどんな無線機があるのか見に行き, 話を聞いてみた.
驚いたのが最上位機種は大きな LCD があり, まさに測定器といった風貌で約 20 年前に覚えのある表示器は周波数その他数字だけを出せるものとはちょっと違っていた.
 対応してもらった方は多分 Yassu の研修生といっても見た目の年齢的に課長研修あたりではないかと思う感じで, 全般的に Yaesu 製品の説明を受けた感じになった. もともと購入するのであれば 10 万円程度のものが適当と考えていて FT-991A と IC7300 とが候補にあがっていた.

IC7300 は大型 LCD で見ためも良く, 受信側は direct SDR という事で digital 派の私的にはこちらかなと思ったが, 説明を受けていると FT-991A はそれなりの RF 回路があり近接妨害を受けにくいという謳い文句でこちらになかり傾いた. ただ, FT-991A の使用 report 的にはあまり操作が直感的でなく使いにくいというのを見た. しかし, すでに魅力的に cost 的に QSL card の交換とかしたいと思わないので, 音声は出たいと思わない. CW は出てみたい気はするがこちらに必要なくても相手から card の発行を期待されるとちょっと重荷になるので, そういうのもありあまり, 細かな操作性はいいと考えた.

あと, 無線機より問題なのが antenna の設置だった. 7 MHz, 14MHz あがりに出られれば良いかと考えているが, tower や八木などは上げられない. Di-pole か GP がいければと考えていると Windom antenna というのがあり, 7MHz の半波長の 20m 長で 7, 14, 28MHz が出られるという事で, この antenna にしようと考えた. 給電点は 1/6 と 2/6波長に相当する部分にありしかし, この様な antenna は通常店舗販売はされておらず, 通販か自作になる. 通販といっても balun の作成が面倒かどうかで, element の調整はどっちみちしないといけないので、自作する事にした. この antenna の入力 impedance は 272[Ohm] で同軸の 50[Ohm] はと balun が必要になる. 理想的には 1:6 だと思うが, 外界の影響で impedance が下る傾向にあるとの事, また, 1:4 balun が作りやすいので, 多くの site では 1:4 としているところが多い. とりあえず core として T106-6 と直径 0.5 mm のポリウレタン線を購入した. もうちょっと太いならびにそれなりの被覆のある線にしておいた方が良かったと後から思ったが, 何度か作り直しが必要だと思われるので, まずはこれでやってみようと思う.

結構 FT-991A に bias が掛った定性的 pros/cons になっているが、なにはともあれ FT-991A + Windom antenna の構成でいき, 無線機も購入してしまった.

あと面倒というか時間が掛るのが開局申請になる. 最近は電子申請ができるという事なので, とりあえず account 申請し, 郵送で user account と password が送られくる. この郵送の一回は無駄な気がするが, cost意識が薄いのと国民からいらぬ攻撃をなるべくかわす為と無理矢理理解した. ただ 2日程度で来たので, アマチュア無線の低迷も含め電波使用申請する人なんかそれほどいないんだとうと思う. 各種業務, 携帯電話会社, 放送局がそんなにバンバンできていないし, あっても楽天が携帯電話の申請をしたくらいで, そもそもこんな system を使うのではなく別 path があると思う (電波利用申請 lite の lite といっているくらいだし)
なにはともあれ, 紙で提出しなくて良くなったのはかなり楽になる.

FT8 などの digital 通信を考えていたので, 開局時に, FT-991A で通常 (音声, CW) 運用できる周波数帯ならびに電波形式, かつ付加装置で申請を考えたが無線機屋の店員が, 通常申請してから, 変更届けを出した方が保証認定から外れなく楽だという事でその手順にする事にした. すでに digital 通信方式を申請している局が新たな digital 通信方式の追加は無料でかつ申請だけで良いという旨を書いている site は多いが, 開局を含めてどの様にしたら良いかは見付けられなかったので一度に行なった方が良いかと思い, 店員に聞いてみると, 保証認定範囲の開局してから, 変更した方が楽だと言う事だった. ただ, 初めて digital 通信方式を追加する時に保証認定から外れると思うが、 最初から digital 通信方式を追加するとしないとで flow の違いが生じるというのがちょっと理解できなかったが, 時間的な観点で言うと, 兎に角電波形式はどうであれ開局するまでに時間が短かいのは, 保証認定内で申請して開局してしまう方法だというのは理解できた.
すぐ申請 site に access しようと思うが今日 (2018/03/10) 8時までは昨日夜からの maintenance で close になっている


2018年2月9日金曜日

arm gcc で compile した後 ld で -nostdlib 指定時の undefined references の解決

ARM cpu 系の soft 開発において gcc で compile した場合,  GPL の関係で -nostdlib を指定して標準 library を link しない様にした時に mul や div 系が undefine でエラーになる。その時は以下を compile し link すれば良い

https://github.com/bobbl/libaeabi-cortexm0

今回 ArmBootloader の kinetis 系の bootloader は NXP (旧 Freescale) のものをそのまま利用をする事にした. (以前は binary size を小くする事を考え独自作成を考えたが、互換性など担保するのが大変なのと、すでに存在する物を新たに作成するのはもったいないので変更).  その中で掛け算、割り算が使われている為に起こる. 以前は独自実装の ldiv などを使用していたが折角なので使用させていただくことに. License は何か主流なのを持ってきた物ではないが MIT license に近いのではないかと思われる. とりあえず notice 系をちゃんと残しておけば良く, その他の file への license 感染はない.


また、gcc の optimize option に -Os があるが、これを指定すると
"undefined references to `__gnu_thumb1_case_uqi' " が出る、if -- else if --  方から関数 pointer の配列型にするっぽいが、此れに対しては

https://chromium.googlesource.com/chromiumos/platform/ec/+/v1.9.0/core/cortex-m0

を使用させていただく事にした.  file 中に License 事項が書いてあるが BSD style だと言う事だ.

他にも色々あると思われるが, ググって最初の方に出てきたので, そのまま使用する

2018年1月27日土曜日

Arm 系の bootloader の開発 (ArmBootloader)

マイコンを使用する際、開発した program をどの様に update するかは問題です.
通常 JTAG や SWD などで udpate する場合が多いですが、製品化する場合それらをいつもでも使う事ができるわけではありません.そこで、bootloader を作成し、マイコンの power on reset で bootloader を実行する様にし, 開発した firmware が存在する場合 firmware を実行し、無いもしくは壊れている、または update mode の場合は bootloader に留まり外部からの firmware update 処理を行なえる様にする. もちろん bootloader 自分自身も update が行なえる方が良い.

以前は、チップ購入もしくは実装状態では、blank 状態が多く、書き込み納入してもらうか上記の様に JTAG や SWD などで書き込まなければならず firmware update の機構とは別の方法で update する必要があり煩雑であった. しかし最近はマイコンでチップ内 mask rom に bootloader の入った物が多くなってきた. この bootloader はなんらかの update protocol を持っており、この protocol をそのまま今回作成する bootloader に使用する事で、update 方法の違いによる煩雑さをなくす事ができる.

今回作成する bootloader の仕様は以下の通り

1.  ARM 系の chip を対象
2.  STM, Kinetis, LPC の update を基本とする
3.  update protocol は、mask rom の update protocol と同じにする
         (mask rom bootloader が無い場合は同種チップの update protocol を使用する)
4.  update する側の PC もしくは ホスト cpu の program は単一 program にする
         (上記 2で示すマイコンの protocol をすべて対応する)
5.  伝送路は UART を基本とし、USB, I2C, SPI は必要になった時に適宜サポートする
6.  bootloader その他用途の size は最大32kB とする (0x00007fff まで)
         以下の map が考えられる
         6-1  2kB: 1st bootloader, 28kB: 2nd bootloader, 2kB: configuration data
         6-2  2kB: 1st bootloader, 14kB x 2: 2nd bootloader, 2kB: configuration data
         6-3  2kB: 1st bootloader, 30kB: 2nd bootloader
         まずは 6-1 を想定する
7.  firmwre は 0x00008000 から配置
         firmware は、0x00000000 からではなく 0x00008000 から配置
8.  対象 compiler:  GCC, IAR (KEIL は未定)
         GCC は、gcc 標準の library は使用しない様にする
9.   ライセンスは MIT license


2018/06/28追記
STM系で USB CDC による UART update 方法を追加
USBでの update は, DFU であるが、細かな書き込み制御ができなさそうなのと DFU の実装が面倒だったので USB CDC の stream を UART update の処理部に突っこんだだけ

2017年10月22日日曜日

APB-3 を Ubuntu 上の wine で実行させる



Ojisankoubou のABP-3 を購入したが、普段 Ubuntu で作業をしているので Win PC を立ち上げるのが面倒なので、Ubuntu 上で wine を使用して測定できないかと検討し, 起動させる事ができた時の覚え書き

Install 環境

Ubuntu 17.04
CPU      Core i5-7600
Chiset   H270
wine      2.19-devel
APB-3   PC      20170917
              FPGA 12091415

Ubuntu 上の wine で APB-3.exeを動作させる為の注意点

a.  wine用 libftd2xx access wrapper である ftd2xx.dll.so の compile を
    する為にの i386 library が /wineroot/lib32 になってる必要がある
    install した wine は i386 library directory が /wineroot/lib など lib32以外の
    名前になっており、その場合は ln -s lib lib32 などで link を張ること
            (Install作業 1  の真ん中あたり参照)

b.  APB-3 の通信は /dev/ttyUSB? を通して行なっているわけではなく、 libftd2xx を介して
    行なっている, しかし APB-3を PC に接続した時に /dev/ttyUSB? に attach され wine 上の
    APB-3から access が排他される為 /dev/ttyUSB? を unbind する必要がある
    /etc/udev/rule.d に unbind する rule を追加
             (Install作業 6  を参照 )

 

Hierarchy

     +----------------------------------------------------------------------+
     |  APB-3.exe tool (Ojisankoubou)    app C#           | APB-3 tool
     +----------------------------------------------------------------------+
     |  FTD2XX_NET (FTDI corp)       C# .net wrapper   | APB-3 付属の物を使用
     +----------------------------------------------------------------------+
     |  WINE                                                              | 1, 2, 3
     +----------------------------------------------------------------------+
     |  ftd2xx.dll.so (linux)   linux ftd driver wrapper       | 4, 5x
     |                            include the libxftd2xx.a          |
     |  (FTD2XX (FTID corp, win) ftdi driver の代り)      |
     +----------------------------------------------------------------------+
     |  kernel, udeve (Ubuntu 17.04)                            | 6
     +----------------------------------------------------------------------+
     |  APB-3 本体 (FT232H device)                            |
     +----------------------------------------------------------------------+
%

Install 作業

1.  ubuntu に wine を install する 2.19(201710190時の develop版)

      wineの root は "/opt/wine-devel" になる

          sudo apt-get install libx11-dev:i386 libfreetype6-dev:i386
          wget -nc https://dl.winehq.org/wine-builds/Release.key
          sudo apt-key add Release.key
          sudo apt-add-repository https://dl.winehq.org/wine-builds/ubuntu/
          sudo apt-get update                # (20171206追記)
          sudo apt-get install --install-recommends winehq-devel
          sudo apt-get install -o Dpkg::Options::="--force-overwrite" --install-recommends winehq-devel   (Ubuntu17.10 では "/lib/udev/hwdb.d/20-sane.hwdb" が lock されていて errorになるので overwrite option を付ける 201803030追記)
          sudo ln -s /opt/wine-devel/lib /opt/wine-devel/lib32
                    #   (ftd2xx.dll.so を compile する時に */lib32 を見ている)

       msgothic.ttc を copy もしくは、 類似 font を /opt/wine-devel/share/wine/fonts  copy

      同 versionの soruce を取ってきて wine-x.xx/include を /opt/wine-devel/. にcopy
          git clone git://source.winehq.org/git/wine.git
          cp wine.git/include /opt/wine-devel/.
                         (正確には同一 verison ではない)
      もしくは
    https://dl.winehq.org/wine/source/ から tar.gzを取る
          cp wine-x.xx/include /opt/wine-devel/.


2.  wineの working directory の作成 (通常各自の home の下)

        WINEARCH=win32 WINEPREFIX=~/.wine winecfg # (bashで)
                                    (201803030追記 root で実行, 一版 user では libwine.so.1 が
                                     Operation not permitted になる)

3.  winetricks を入れる (app, dllなど入れる場合に必要、 今回特に使わない)

        apt-get install winetricks
        wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks
                    # apt-get は wget のが使えない場合

4.  ftd2xx.dll.so の install  (wine側の ftdi wrapper)

      sudo apt-get install binutils:i386   # (必要かどうか忘れた)

      https://github.com/brentr/wineftd2xx からすべての file を copy
        git clone git://github.com/brentr/wineftd2xx

      Makefile に wine includeの場所の指定する
      (通常は winedllpath で解決できるはず)
        CFLAGS = -g -O0 -Wall -I/opt/wine-devel/include  # "-Iうんたら" を追加

        make      # FTDIより libftd2xx.1.1.12.tar.gz を取ってくるが後で置き換える

      FTDI site (http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx-i386-1.4.6.tgz)
      とってくる置き換える
        wget http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx-i386-1.4.6.tgz
        tar xvfz libftd2xx-i386-1.4.6.tgz release/build/libftd2xx.a
        mv release/build/libftd2xx.a libftd2xx1.1.12/build/i386/.
        rm -rf release

        # compile
        make
        install
        sudo cp ftd2xx.dll.so /opt/wine-devel/lib/wine/.
        sudo cp libftd2xx.def /opt/wine-devel/lib/wine/.

      参考資料
        http://gatopeichs.blogspot.jp/2012/10/usb-d2xx-driver-for-wine-on-linux.html

5x. libd2xx_table の compile (特に必要なし, もし必要になれば)

        git clone git:/github.com/psi46/HDItest
        cd HDItest/FTDI-1.0.4/libftd2xx1.0.4/lib_table
        Makefile の compile, link option に -m32を追加
              ("CC = gcc" を "CC = GCC -m32" とした)
        make

6.  /etc/udev/rule.d に APB-3 接続時の /dev/ttyUSB? を unbind する rule を追加

        cat <<EOF > 45-ftdi-APB3.rules
# unbind the ttyUSB? device, if the APB-3 measurement is pluged to PC
#
### ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6014"
SUBSYSTEM=="usb",ACTION=="add",ATTRS{product}=="APB-3 ver.3 Ojisankoubou",RUN+="/bin/sh -c 'echo -n %k > /sys/bus/usb/drivers/ftdi_sio/unbind'"
EOF
        sudo cp 45-ftdi-APB3.rules /etc/udev/rule.d/.
       rm 45-ftdi-APB3.rules
       sudo udevadm control --reload-rules

7.  APB-3.exeの起動

        APB-3 の usbを接続する (もちろん APB-3電源を投入)
        wine APB-3.exe
                         (201803030追記 root で実行, 一版 user では libwine.so.1 が
                          Operation not permitted になる)

その他の事項

### debug 時に使用した tool など


WINEDEBUG=+loaddll wine APB-3.exe 2>&1        # loadされた dllを表示
WINEDEBUG=+dll wine APB-3.exe 2>&1        # DLL accessを表示
WINEDEBUG=+ntdll wine APB-3.exe 2>&1        # DLL fileに関する表示
                                            # loadしようとして load できなかった access も表示
udevadm monitor --env --subsystem-match=usb    # USB の probe/unprobe の確認

### wine の削除 (201803030追記)

sudo apt-get install --install-recommends winehq-devel
sudo apt-get remove wine-\*
sudo apt-get purge wine wine-\*
audo apt-get autoremove