KICAD の short cut 専用 keyboardの作成 (win7対策)

KICAD short cut keyboard が Windows 7 で正しく認識しない問題を知らべている.

とりあえず波形調べてみた.

電圧が高い方が host の出力, 低い方が STM32L072 である. 今回 3.3V LDO がなかったので, 3.0V にた為, 電圧が低い. datasheet 上 margin 0 で範囲に入っている (通常 ng ですが...) これはおかしと思い, それでは mask rom の bootloader での USB DFU ではどうかと確認してみると, ほぼ同じ感じであきらかな違いはない.  どう考えても drive strength が低い様な気がする. しかし, mask rom の bootloader は正しく認識する (ある意味こんな波形で通信できるのかと感心した). 良く考えると, DM,DPは差動信号なので, cross した以降は特にらだらだ上っても問題ない. やはり, 信号波形とは関係なさそうだ.


当初から usb bus analyzer を使用しているが, どうも L072 が PC からの packet 正しく取れていないく, 当然 data も返す事もできていない様に感じる. ただし, ACK が返っているので, ちょっと謎である.

次に USB 用の内部 clock である HSI48 関連を見た. SYSCFG, CRS など関連 module の範囲が広いので enable の順番などを確認した. その中で, 時々正しく device descriptor の要求に対し, 返事を返している事があった. おおよそ 20 回に 1回程度であろうか. やはり USB clock がおかしいのであろうか... HSI48 の 48MHz の clock 出力周波数をみてみると, 結構 jitter が乗っている. また, オシロのなんちゃって周波数カウンタ的にも 100ppm 以上の変化がある. Ubuntu と Windows でのそれほどの違いはなさそうである. 唯一違うのが get device descriptor の setup を発行するまでに SOF が 36 個程度か 20 個程度かというものであるが, mask rom の bootloader の DFU では問題なく認識しているので, この SOF に起因するとは思えない.


HSI48をさんざん調べ一点直したところがあったが, 特に改善はみられない. setup 自体は問題なく受けていて処理ができていないのではなかと考え, 該当 code に printf を入れまくると, なぜか, setup を受けているはずなのに setup 処理 routine に飛んで行っていない. setup 割り込みが発生してから, 割り込み要因が途中で変化している事があった. その時には, Win7 が usb を reset していた. 今回割り込み要因を調べるのに, 毎回 EPnR register から読んでいた. もしやと思い EPnR を一度 locad buffer に入れてからそれを参照する様にした所, 全く問題なくなった.
毎回 EPnR を読むと割り込み要因が消す, もしくは次の packet を受信してその要因をみていたようだ. ふだん module の 割り込み register を一度 loal buffer にいれているのだが, register 名が割り込み感がなかったので毎回読んでいたのではないかと思う. STM32L4x でなにもなかったが STM32L0x は core clock の上限が 32MHz なので処理が比較的ゆっくりとなり, 問題が出てきたのではなかと思われる.

マイナンバーの署名用電子証明書 (長い方) のパスワードは英字はすべて大文字です

年末になり来年早々恒例の確定申告の作成をしなければならない. いままで郵送で送り付けしかも, 受取証の返信封筒なしのチャレンジャブルな方法で行なっていた. 今年始めに通知カードをマイナンバーカードに切り換えた. また, カードリーダも用意してずっと放置していたので, そろそろ設定などをしなければと重い腰を上げた.

以下の処理を行なった
1. JPKIの download と install
2. 国税庁 site の root 証明 / 中間証明設定
   信頼済み site 登録
3. 開始届出の新規設定

この 1 の所で, マイナンバーカードを認識させて, 証明書の表示ができるのでパスワードを打ってみた. これだと思うパスワードを打ってみたが通らない. 違うのかと思い別のパスワードを入れてみてなんやかんやで 5回を越えパスワードロックした.

ググってみると英字は  大文字  だと言う事だ.

通常大文字小文字混在やろうと思うのだが, 大文字だけであった. パスワードのアンロックは区役所の端末でしかできない. たぶん小文字で打ってしまっていたのを大文字にすれば良いはずだが, ロック解除だけでやっぱり違うパスワードだったとなったら二度手間なので, 今回は再設定をした. 大文字だけってなんかだなぁと, 思い区役所に行った. 手続きは,

1. 申請書 (名前, 住所, etc, ロック解除か再設定か, 印鑑いらなかった)
2. 端末で再設定 (4文字パスワードで入れて確認される)

役所に行かなければならないが, 内容はそれほど繁雑でなかった. 大文字だと再認識しながら, 多分同じであろうパスワードを打った. それほど混んでいなかったので役所に着いてから 20 分もかからず完了した.

家に帰り JPKI で確認すると問題なく証明書の確認ができた. ただ eTAX の送信時にまたなんらかのトラブルがあるはずだ. なかなか楽しませてもらえそうだ...




署名用電子証明書 (長い方) のパスワードは英字はすべて  大文字  です

KICAD の short cut 専用 keyboardの作成 (基本機能完成)

先に REF-STM32L4-01 基板を作成した基板に STM32L072 を実装した. L072 の RCC や SYSCFG などの software の実装が必要なので実装し, 安定して動作する様にした. 単一の code でなく, bootloader と本来の機能の firmware の 2 種あるので倍と言う訳ではないが, 1.5 倍くらいの時間が掛っている. また, USB 関連の自作 middleware で HID は実装していなかったのでこの code も実装した. USB の class は面倒な感じであるが, HID に関しては, Report descriptor が面倒なだけであって, 転送する data は 8 byte を送るだけである. また, Report descriptor も面倒と言っても keyboard (boot i/f) であれば, USB HID の document に書いている通りでそれほど苦労する事はない. とは言え実際はちょっと変えているが...



まずは, ROTTAY 22key に接続せず, 基板のみでこの基板上のスイッチでなんらかの Report (key code) を送信する事にし, とりあえず "a" を送る code を書いた. これは単に 0x00, 0x00, 0x04, 0x00, ... の 8 bytes を送るだけで, 難無く送れた. 0x04 部分が USB HID の key code で "a" に相当するものである. しかし, USB を PC に挿して送信できるまでに USB を認識するところで reset 出まくりっぽい挙動をしており, その調整が必要である. また, Windows 7 では全く認識しない. これは要調査である. まさか IAD descript を使っているからか?

USB HID で report を受信できたので, 次は実際に 22key に接続し, key を scan し, それら key に対応した report を送信でき様にする. これにより
    matrix key の読み込み
    押された key から対応する key code を認識
    key code の送信

の実装が必要になる.

key scan とくに問題ないが, key code を認識する所が面倒になる. と言うのも, どの key に key code を対応させるかを考える事になり, それはつまりその key にどの機能を割当るかと同等である. 今回 22key は左手で操作する事を検討しているが, home position や親指に近い方に重要な, もしくは良く操作する機能を assign するべきである. また 22 個の key しかないので, 拡張する為に "SHIFT" key も導入を検討した. 例えば grid 選択の順送りに対して逆は SHIFT を押すなどが可能である. とりあえずの assign はしているが, 頭で考えているだけではあまり意味がないので, 実際に回路を書いて, board data も書いて操作性を確認しようと考えている. 丁度この制御基板を書き key の assign の最適化をするのが良いのではないかと思っている (現状は reference board を使っている).

今は,
"5" に Auto zoom
"123" に部品関連
"789" に配線系
"+-=BS" に layer, grid
"ENTER" に SHIFT

を assign した. とりあえず pcbnew の assign をしたが, eeschema はまた違った assign が必要である. それもあり, 電卓 mark を押す事により, key code を eeschema 用, pcbnew 用の変更をできる様にもした. この 22key はすべての key top が青く光る仕様となっている為, どちらの key code になっているか分る様に pcbnew の key code が選らばれている場合には, 青く光らせている.

                                             左側が eeschema 時, 右側が pcbnew 時


まだまだスカスカでもっと assign できるのだが必要であれば, どんどん assign していけば良いだろう.  とにかく assign にはよく使う単品 command にするべきで

-  配線, 部品配置と良く使うものを assign (あたりまえだけだが)
-  mouse の wheel でできる事は assign しない
-  text の編集など通常の keyboard の操作が必要なものは assign しない
-  22key の組み合せ 2, 3 個で解決できるものは assign しない
             (layer の内層切り替えは Cu.Top +  NEXTにするとか)


ちなみに, key code の assign は人によって変更が必要になると思われるので, USB CDC の 簡易 shell にて, assign の変更ができる様にしておき, MCU 内部 EEPROM に記憶しおけば, 変更する毎に compile の必要はなくなるだろう. それもあって config descriptor は IAD descriptor を用いて CDC と HID の composite device としている.



そう言えば, 当初 22key の匡体が開けられないので, 横を切断した裏蓋を接着剤で止めたのが下の写真, 横から見ると不細工だが, 通常 key top しか見ないので問題ないだろう. とりあえずもう 1 台は必要なので, その時は最初から key top 部分のネジを外して裏蓋を開けよう.

STM32L072 の ROM area の Blank の値は 0x00 です.

タイトルの通り STM32L072 (STM32L0 系一般化できるのではないか) 0x08000000 から始まる ROM area (NVM) の Blank 時の値は 0x00 です.  0xff ではありません.

こんなん初めて見た. びっくりした.
bootloader, burning tool を STM32L0 系であれば, 0x00 は blank の値とする様に変更した.

STM32L4 / L0 reference board の作成と USB の有効化 (やはり USB で trouble)

最近 STM32 を好んで使用しているが, STM32L0 系 L4 系の reference board の NUCLEO-64 などは chip の USB bus が USB コネクタに出力されていない. そこで, USB-uB と chip を載せた reference board の作成を行なった.基板の仕様は以下の通り

1.  STM32 64pin chip (STM32L452RCT, STM32L0x2RBを対象)
2.  USB-uB, USART1/2, I2C slave/master, SWD  CN を実装可能
3.  3.3V, 1.8V DCDC (USBを使用する時は, 3.3V必須)
4.  VCTCXO, MCP4725による周波数安定回路
5.  LED 2個


当初 4層基板の検討をしたが, ひどい間違いで, ゴミ基板を作っても仕方がないので価格重視で両面基板にした. 2 枚集合でカットした後は, 20枚取れる事になるが, 機能的に 20 枚使用するだけの寿命があるかどうかは疑問...

現段階で, USB, USART1, SWD のみ確認済で, I2C は未検証である.
また問題点は以下の通り,

a.  1.8V, 3.3V DCDC の電圧調整用の分圧抵抗が 1個ずつなので, E24 ではあらい
            出力側もしくは GND 側のどちらかは 2個にしておきたい.
b.  DCDC (TLV62569) が 軽負荷すぎてか, リップルが 200mV程度あり


a は現状 1つの値を 9:1 になる様に 2つに分けるとして, b は LDOにするかどうしよう検討が必要である


この基板の最初の嫁ぎ先は, 先に書いた KICAD 専用 keyboard の controller として使用する予定だ. その為, USB HID class が必要で, 例の如く STMicro の標準の SDK は使用しないつもりなので, HID の実装が必要である. ただ, 以前他の CPU で digitizer の report を作成した事があるのでそれほど難易度は高くないと考えている. CPU は STM32L072 を使用した. もちろん HID の実装だけなので, L052 とか L032 で十分であるが, refernce board として高機能, memory 大きめの CPU を使用している. ただし, code を見て L052, L032 に移行できる様に, memory の使用を制限する予定である

HID の実装の準備としてまずは, USB の device desc, config desc を host pc に認識させる必要がある. 見た所 STM32L4 系と同じ usb module を使用していそうなので, usb driver は L4 系のものをそのまま使用した. 以前 H7 系で CRS を使用しないと, 挙動がおかしい事は経験済なので, これはあらかじめ code を書いておいた, しかし, USB 上の SOF が途中でなくなり通信ができなくなるので, USB 用 clock の HSI48 ならびに CRS の挙動を見てみると, MCO から出力される HSI48 の clock が徐々に周波数が低くなり, いずれ止ってしまうのを確認した. CRS が動作しているのにも係らずである.

Reference manual を確認すると, VREFINT と ENREF_HSI48 の bit を set する必要があるとの事, これらは SYSCFG module にあり, bit を set した. しかしそれでも HSI48 が不安定である. SYSCFG は clock gate を enable にした憶えがないので, RCC の SYSCFGEN を set し問題なく HSI48 が安定した.



STM32L072 (L0x2と一般化けいると思う) で USB を使用する時は,
A.  RCC の USBEN を有効
B.  RCC の SYSCFG を有効
C.  SYSCFG の VREFINT, ENREF_HSI48 を有効

KICAD の short cut 専用 keyboardの作成 (準備)

現在 KICAD の short cut 専用 keyboard の作成の検討をしている. ただし, スイッチいちからを並べて組むのは面倒なのと見た目もそれほど良いと思えないので, テンキーの製品を購入して内部の MCU は取り外してしまい, 新たに MCU を接続し KICAD 専用としてみようと考えている.

検討している使用は以下の通り.
1. 市販の USB テンキー (実際はもっとある物を使用)
2. USB MCU (STM32L072)
3. USB HID keyboard + USB CDC(設定用)
4. PC に特殊 driver/tool が必要がない様にする
5. キーのトグルにより EESCHEMA と PCBNEW で使い分けられる様にする
6. USB CDC にてキーバインドを変更でき EEPROM に保存できる様にする

 とりあえず, ROTTAY 22key を購入した. これにしたのは, key の個数もあるが, keyboard の台座部分がそれなりに空間がありそうで, 別途 MCU 基板を入れられると思ったからだ.

さっそく内部がどうなっているか見る為に, 開けようとするが, よくある裏面のステッカー部分やゴム足部分にネジがあるかと思ったがない, また匡体どうしのパッチン止めかとも思い力ずくでコジ開け様としたがだめだった. 仕方がないので, 側面をカットして内部を見える様にした.
やはり, かなりの空間があるので問題なく新たに基板は入れられそうだ.

しかしよく見ると, 匡体内部にボスが立っており, 押えにしては径が太い気がした. ボスが当っている部分を keyboard 側から見るとなんとネジがあり, それを外すと裏蓋が開きそうだったが, やってみると案の定なんなく裏蓋が空いた. はっきりいって側面を切る必要はなかった... 以下の写真は 2ヶ所しかないが,   1, 2, 3 key の下にも 2つネジがあります.

とにかくバラした感じは以下の通り.

基板は片面基板で, 配線同士がクロスする部分には積極的に 3220 サイズののコンダクタが使われている. もうちょっと最適化できるであろう部分があるが, スイッチの配置検討のまえに回路図や soft を fixしてしまったのではないかと思われる. あと, 幸いにも全体イルミ用 LED と NUM LOCK インジケータ LED は MCU で点灯制御ができる. であれば, eeschema 時は消灯, pcbnew 時には点灯など見た目を変えられそうだ (window manager にどれが focus 当っているか確認し, USB HID で MCU に設定すれば良いが, 現状そこまでする気はない).

ここまで分れば, hardware としては, keyboard と MCU を接続すれば良いのだが, STM32 の M0+, M4系の の NUCLEO 基板で USB が出ている物がなく, ちょっと前に基板作成に出した STM32L0xx, STM32L4xx の reference 基板を作成したので, それを入荷待ち状態である.

また software は,
a. Key 入力部
b. USB HID 部
c. USB CDC ならびに command parser 部

の開発が必要である.
USB HID は久しぶりで report の作り方などだいぶん忘れてしまった. まぁ OS をハングさせながら, ぼちぼち開発していけば良いかと考えている.

Totalphase の USB analyzer と USB PD analyzer の購入 (その4)

Analyzer soft の "Data Center" は Windows, Linux 2.6系, Mac OS X で操作可能だ. 最初に書いた通り, Windows でなく Ubuntu で動作させたい. 当然 Windows で動作させるよりも色々な困難があるだろうと容易に想像できる. とにかく色々やったが, あまり細かく書いても面倒だし, 同じ様に Ubuntu で動作させたいという奇特な人がこの page を見て混乱を与えてもいけないのでほぼ結論と理由だけを書く事にする.

今回の point は Data Center を動作させる為には gstreamer-0.10.0 が install されている事が必要である. 最近の Ubuntu はすでに gstreamer-1.0 になっており, gstreamer-0.10.0 を入れる事による他への弊害がありそうだ. この選択はやめ 0.10.0 が入っている Ubuntu 上で動作させる事とした.

結果的に, 14.04, 12.04 あたりは使え 18.04, 17.10, 16.04 は ng だった.
(16.04 は gstreamer-0.10 だが libpng12 がなかったりなど色々ありそう)
ただし, 現在使用している version は, 18.04 もしくは, 17.10 で gstreamer はすでに 1.0 となってしまっているので, Data Center で要求される shared library の version が 0.10.0 でない為, 実行できない. いつ Data Center が gstreamer-1.0 に対応してもらえるかはわからないので, virtualbox で Ubuntu 14.04 を動作させた.

動作環境は以下の通り

- Host pc Ubuntu 18.04, 17.10
- VirtualBox 5.2 + Extension
- Ubuntu 14.04 (english)
- Data Center v6.73 (Beagle version HW: 2.00, FW: 2.01)


この環境で以下の手順で install を行ない, Data Center を動作させた.
くどくど書いているが, ほぼ上の環境を入れるだけの作業なので, 今なにをしているかを考えながら入れると問題は少ないだろう. 動作させるのに必要な設定は特にないが, 画面サイズがそれなりに広いほうが良いので，Virtual box の default の 640x480 から1280x1024 に変更する設定程度でとりあえず使用する事ができると思う. 細かい設定たとえば, updateしない，不必要な daemon を off, auto logoff しない, file共有, などなど挙げればきりがないが, ぼちぼちやっていけば良いと思う.


### virtual box を install
% wget https://download.virtualbox.org/virtualbox/5.2.22/virtualbox-5.2_5.2.22-126460~Ubuntu~bionic_amd64.deb

% wget https://download.virtualbox.org/virtualbox/5.2.22/Oracle_VM_VirtualBox_Extension_Pack-5.2.22.vbox-extpack

% sudo dpkg -i virtualbox-5.2_5.2.22-126460~Ubuntu~zesty_amd64.deb

# USB などを virtualbox 上で使用する為の extension pack
# shell 上で実行できるかわからなかったのでファイラーからダブルクリックした
Oracle_VM_VirtualBox_Extension_Pack-5.2.22.vbox-extpack


### ubuntu を install
wget http://releases.ubuntu.com/14.04/ubuntu-14.04.5-desktop-amd64.iso

% virutalbox

# 仮想 machine の作成
# 名前 Ubuntu 14.04, memory 1024MB, 新規 10GB VDI 可変サイズ
# 起動後すぐに iso file の設定があるので, ubuntu-14.04.5-desktop-amd64.iso を指定
# PC名, user名を入力，passwordなしでの login にしておく (Data Center だけの為なので)


### 画面サイズの変更
- VirtualBox 上の デバイス -> Guest Addtions Cd イメージの挿入 -> auto run の許可
- reboot
- 画面で右 click -> Change Desktop Backgroud -> All Settings -> Displays -> Resolution -> 128x1024 -> Apply -> Keep This Configuration


### Data Center の取得
- Brower の立ち上げ -> (必要があれば proxy の設定) -> www.totalphase.com へ login
- Protocol -> USB
- "Beagle USB 5000 v2 SuperSpeed Protocol Aanlyzer - Standard Edition" を click
- page の一番下にある "DOWNLOAD" を clink
- Data Center SoftWare (v6.73) を clink
- Data Center Software v6.73 (Lunux 64-bit) を clink (download)


### Data Center の実行
command を起動
% cd download_point
% unzip data-center-linux-x86_64-v6.73.zip
% cd data-center-linux-x86_64-v6.73
% sudo ./Data\ Center



root で立ち上げないと, 起動後 Data Center 上の Analyzer -> Connect to Analyzer 
で接続しようとしても "One or more devices attached but inaccessible." となり, Beagle は見えているが, device file に access できない状態になってしまう. 慌てず騒がず sudo しよう (なんでもかんでも root で実行するのは本当はダメなんですが). 

本来は sudo でなく udev など usb の permission を整える必要がある

Totalphase の USB analyzer と USB PD analyzer の購入 (その3)

家に着き, 早速箱を開けると Beagle USB 5000 V2 キャリーケース, 電源ケーブル, USB type-C PD Analyzer が緩衝材の中に埋もれて入っていた. 想定外だったのが, Beagle USB 5000 V2 はキャリーケースに入っていたという事だ. タンボールもしくは厚紙の箱に入っている物と思われたが, それなりのプラスチックケースなので, 持ち運びに便利である. 個人的な使用として購入して物だが, 会社で使用している USB analyzer は HS までしか capture できないものなので, 必要がればちょっと持って行って測定も可能だ.

Beagle USB 5000 V2 のキャリーケースを開けると, 本体と AC アダプタがスポンジを刳り貫い部分に入っている. 一つ何も入っていない部分があるが, 電源ケーブルを入れる部分と思われる.

Beagle USB 5000 V2 のキャリーケースから取り出すと, 付属ケーブルが底に入っていた. 本体の匡体は, 鉄を使用している為か見た目以上に重い. 塗装は結構厚めにされている様な気がするが, キズを付けてしまうとそこから錆てしまうのではないかと思ってしまう. アルミかプラスチックで作って欲しいと思った. また AC アダプタの DC プラグは外装部のネジがバカになっており電極部のネジにうまくねじ込めず, すぐに抜けてしまう. 多分 AC アダプタ製造している時に力ずくで外装を嵌め込んでしまったのだろう. いずれ交換が必要である. ちなみに DC ジャックは 2.5mm センタープラス 12V 2A であれば良いので他の AC アダプタでも使えそうだ. まぁ, とりあえずはプラグを付け変えないといけなさそうだ.

ケーブル類は, USB3.0 ケーブル 3 本, IO trigger ケーブル 1 本, USB2.0 cable(20cmほど) 1 本, そして Warranty カードがあ入っていた. USB3.0 ケーブルはすべて 90cm 程であるので, Data Center (analyzer app) を動作させる PC を床に置いているので, analyzer との距離があり, 接続するのに別途購入が必要そうだ. ただし, Downlink (Data Center を動作させる PC と analyzer 間の link) は, Standard model では HS なので, USB3.0ケーブルである必要はない. ただ amazon 的に現状 1.8m の USB3.0 ケーブルが 1,000円程度とんでもなく高いというわけではないので, とりあえずカートに入れておいた.
あと, IO trigger ケーブルは, mini DIN とソケットが接続されているが, ソケット側で外皮を剥いて 1本ずつのケーブルにしている部分に収縮チューブなどの対策がなく単にカットされて終りになっていた. ケーブルの断線などしない様に自己融着テープで対策が必要であろう.

本体の正面ならびに背面の IO ならびに操作スイッチは以下の写真の通り.
あえて言うなら, 測定側の USB の VBUS 切断 SW があり, Trigger 端子は正面パネルにある. 背面の HDMI コネクタは何に使用するのかよくわからない. なんせドキュメントはあまり読んでいないので...

正面

  背面

Data Center の setup を環境を整えないといけない.

Totalphase の USB analyzer と USB PD analyzer の購入 (その2)

MUFG傘下にあり口座開設の斡旋もあって日本語対応がありそちらに電話をする. 対応時間は US の時刻なのと, 空時間的に日本で 13 時頃電話した. そこで分ったのはとりあえず上限は $2500 という事で, 確かに $3400 であればエラーになる. 早速上限を上げようとするがその日限り解除なので, US時間で 4時間くらいしか余裕がない. 仕切り直して翌日朝 4時頃電話して上限引き上げをした. 向こう側での問合せでなんやかんやで 20 分程度かかった. 殆どが保留音を聞く事になった. その中で, 物品がどういうものかという質問があり, "USB protocol analyzer" とか言っても分らないだろうから "測定器" と言った. "analyzer" と言た方がよかったかとも思ったが, どちらにして単なる symbol の転送をするだけだろう.

とりあえず $4000 への引上げが完了し, すかさず, Totalphase の web site で購入手続きをした.

今回は問題なくと通ったようだ.
また, オーダステータスも "billed" どうこうなので, 引き落しが完了しているみたいだ.
その 1時間後程度に "Sent" うんぬんと来たので発送もされた (ほぼ同じ画面なので発送画面は割愛).

発送されたという事は, そこからは Fedex の tracking を見る必要がある.

 
それによると, San Francisco の対岸に Okuland に集められるらしい. ほぼ時差を含めても次の日に成田に着いていた. 勝手な想像だが, もし他の荷物が多い場合は priority が優先されるのではないかと考えている. この日に Fedexから電話があったが, 気付いたのがすでに帰宅後であった. 次の日 (9日) の 9時頃電話をしたが, 関税の話であった. 前回のオシロの購入と同じ様に測定器関連は関税は 0% であるので, 無税であったが, 輸入消費税は必要で, 17,600円であった. 支払は色々な方法があったが, とりあえずクレジットカード払いにした. DTMF でカードカード番号を入れるのかと思ったら, 口頭で言えとの事. 裏面の code まで必要とされていなかったのでよかったが, ちょっと後味は悪い. 振り込み先を聞いて振り込ににした方がよかったかもと思った.
関税の支払いが 金曜日だったのもあって, 発送が土日に掛ってしまい受取が月曜日になってしまった. しかし, 平日の昼間など家にいないので月曜日にも受けとれるはずもなく，しかも Fedex は再配達も日本資本の大手宅配業者の様に細かく時間指定ができないので, 自ら受け取りに行く事にした. その旨を 13 日火曜日の Fedex のカスタマーサポートの電話対応が始まる 8:30 に連絡をした. 当日受け取りの旨を申し出た所問題なく受理され, しかも 1時間程経った後にドライバーからも営業所に荷物を置いたと連絡が来た. 実際, 受け取りに行っても荷物がなかったとかが心配だったのだが安心できた. US資本なので，こういう細かい事があやしかったりするが実務部隊は日本人であるのでそこはきっちりしているのだろうと感じた.
最寄りの Fedex の営業所がたまたま車もしくは鉄道の駅から近くにあったので問題がなかったが, Fedex の site を見てもそれほど多くの所に拠点がある様には見えなかったので, そうでなければ, 多くの諸外国の様に荷物の受け取りに 1 日中家にいなければならないという事になる. ただ, カスタマー サポートは凡その宅配時間を御知らせできますよ, との事だったが, 今回受け取りに行く事にしたので, 確認の時間が掛かるのを避ける為にそこまではしらわない事にした.
Fedex の事務所に着くと基本物流倉庫の一角を事務所にした様な作りになっており, 我々カスタマーのやりとりは 6 畳もない様な部屋でやり取りをする事になった. 事前に受け取りの電話をしているので, 名前を言うだけで荷物を持ってきてくれた. しかし, 当然ではあるが身分証明証の提示が必要で運転免許証を見せ, 受け取りのサインをして荷物を受け取った.
荷物は凡そ 5lb ちょっと (2.5kgいかないくらい) と分っていたが, サイズが不明であった. 物品を 2 つ購入し, それぞれの製品の大きさはわかっているので, バラせはディバックに入るかと考えたが, 念の為に折り畳みのゴロゴロキャリアを持っていった. やはり, 約40cm 四方のダンボールだったのでバラすにもゴミの問題もあるので, キャリアに縛り着け帰路に着いた.

Totalphase の USB analyzer と USB PD lanalyzer の購入 (その1)

先日 UNION bank に送金をしたが, その理由は US にある Totalphase という vendor から USB analyzer を購入しようとしたからだ. 今回購入を検討した analyzer は "Beagle USB 5000 v2 SuperSpeed Protocol Analyzer Standard Edition" である. これは, USB3.0 SS (SuperSpeed, 5Gbps) の packet capture が可能である. しかし, capture した packet を表示する PC との接続は HS (HighSpeed, 480Mbps) で, SS の packet を PC ですべて表示する事はできない. もし必要であれば, PC との接続も SS にする事ができる upgrade pack を購入すれば良い. data を一部しか capture しない機能があるとの事なので, まずはこの状態で使ってみれば良いかと考えた. あと, 決定的だったのが, PC soft に linux も対応している事であった. 普段から, linux を使用しているせいで, windows soft の場合わざわざ PC を立ち上げからしなければならなく面倒だからだ. だた linux 環境で実際に動作させていないので, 本当に使えるかどうかわからない. なにはともあれ, 購入しようと考えた.

基本性能は Totalphase の以下の site を参照していただきたい.

https://www.totalphase.com/products/beagle-usb5000-v2-standard/


しかし, この製品の購入にあたって Totalphase は日本に代理店があり, vendorによっては, その地域の代理店で購入しれくれとなる場合がある. しかし, Totalphase はまだマイナーな企業なのか (むしろ, バンバン売れるものではないという理由が大きと思うし, 昔 CATC 今 LeCroy の analyzer もあまり出していない様な気がする), 日本だけでなく各国の代理店で販売価格を表示している所は少ない. Totalphase は価格を出しているので, ちょっとは安心できるし, 販売価格を聞いて単にひやかしになってしまうのも気が引けてしまう, しかし出してもらっていると購入するかどうかの検討する事が可能である. そこで, 今回購入した物品を US 国内の海外転送サービス会社を受け取りにする事で Totalphase から直接購入できるのではないかと考えた (US国内で物品を購入する場合は, 日本の消費税に VAT がかからない Oregon 州などの転送サービス会社にすると良い事がわかった). US 国内から日本への転送サービス会社の手配をし Beagle 5000V2 をポチッた  (login account の登録と loginが必要です).

 意を決して "Proceed to Checkout" して購入手続ききをする (色々思考錯誤しているので, 送料が書かれてしまっているが, 実際は空欄になっている).

 請求先住所が聞かれているが特に問題ない. しかし上記の "In a rush?" という言葉に引っかかった. 各国の代理店での購入は "お急ぎ" の場合おすすめですよ! の話であって, 特に各国の代理店から購入しなければならないというわけではないのではないかと考え, Totalphase からの直接購入に切り替えた. そこで Shipping info を US の転送サービス会社にしていたが, それを使用せず上記画面の "Ship to this address" に checkを入れ, "Continue" した.

請求先住所と発送先住所が同じという事で, "2 Shipping information" は飛ばされた.
それなりの箱の大きさになる事, Fedex である事, Air である事から $120,30 になるのだろう. とりあえず 2 つの選択肢があるが本来なら $10 はケチるべきとは思うが, 高い方の Priority にした. どこかがちょっとだけ優先度が上るのだろう (振り分け業務あたりが優先的に仕分けされるののか?しらんけど).  US 国内はそれでも $70 くらいにはなっていた. 恐るべし Fedex.

支払は先に送金したおいた UNION bank から引き落されるクレジットカードで支払をする為, カード情報を入れる. "continue" で最終確認に入る.

"よし, 行ってまえ!!!" と "Place Order" をポチる.

しかし, error 発生. "transaction" なんか IP や HTTP(S) の transaction がおかしいのか? で, とにかく 3 回以上は最初の "1. Billing Information" から入力した. それでもおかしい.
そしてもっと奇妙な事に

いつの間にか価格改定 $600 値下!!! ようわかないがこのままとにかく "Place Order" を押しまくった. しかし, 全く埒があかず, sales@totalphase.com に mail した. これまたびっくりする事に 5分程度で返ってきた. US 時間 午後 3, 4時くらいと思ったがそれにしても速かった. よっぽど暇なのかと思ってしまった. mail いわくカードの上限とか region の制限とかないですかとの事, "transaction" って送金の方だとやっと気付いた. 普通は IP とか HTTP(S) の transaction とか思わないのか.

Firstrade で ACH を設定したが送金できない

USで物品の購入を検討しているが, Debit card で引き落される UNION bank の預金残高がそれほどない為, 先日 Fristrade で設定した ACH で UNION bank へ送金をしようとした. しかし, 以下の通り "no active bank" どうこう言われて送金ができない. UNION bank の取引履歴には ACH 登録時の合計 $1 以下の取引が 2回あり問題ないと考えていた.

とりあえず上写真の下の部分の "Bank profile setting" を click すると

UNION bank の項目が出ているので, なんらかの情報は Firstrade に登録されている.
しかし status が "closed" となっていて使用できないと思われる.
FAQs などちょこちょこ調べてみたがわからず, とりあえず 質問 mail を出した.
日本で言う所の振り込みの Wire transfer は, 手数料が $25 とチョー高いのでなんとか ACH で送金できないかと考えている.


2018/11/01
mail の返事が返ってきた.
どうも 2つの送金の金額を確認 page で入力していない事が原因だと言う. うん, 確かにそんな事はやっていない. 完全に忘れていた.
画面も以下の通り "Verify" 画面になっており 2 つの金額が入れられる様に変化している.

すでに 2 つの送金が行なわれているが, "Now, we have help you setup ACH profile again" と言っているので, 多分再度最初から, 金額が変更されて送金されると思うので, それを入れるのであろう. 期限が 10 日までなので, あせって ng になっても仕方がない.

2018/11/02
UNION bank に login し口座残高を確認すると, $0.02, $0.07 が振り込まれていたので, それぞれの額をl Deposit #1 #2 に入力し "Confirm" を Click すると, 問題なく設定できた (画面の capture をし忘れた).

その後, Withdraw の ACH を選ぶと, 送金金額を入れられる部分が表れ送金できる様になった.
"Enter Amount" に金額を入れ "SUBMIT" を Click すると, 送金予約が入った. 2 日は金曜日で実働 1, 2日かかるという事なので月曜日か火曜日という事になる.

Ubuntu 18.04 で gdb-multiarch を使用する (openocd に注意)

使用している PC の一つが Ubuntu 14.10 であったが Window manager が起動した後, ウンスン状態になった為，18.04 に入れなおした.
OS の install 後に STM32 の開発環境を整えていたが, gdb が gdb-arm-none-eabi でなく gdb-multiarch に変更になっており, それを apt install した. それと同時に openocd の apt install をした.  しかし,  apt install した openocd は 0.10.0 で, かねてより開発していた STM32H743 はまだ support 状態でないので, "Ubuntu 17.10上で openocd と gdb で STM32H743 を debug する方法" で stm32h7x.cfg をテキトーに作成して使用を試みた. しかし openocd を stm32h7x.cfg を 指定して起動すると,

Info : device id = 0x00000000
Warn : Cannot identify target as a STM32 family.
Error: auto_probe failed
Error: Connect failed. Consider setting up a gdb-attach event for the target to prepare target for GDB connect, or use 'gdb_memory_map disable'.
Error: attempted 'gdb' connection rejected

の様に error が出力され, 使用できない状態になってしまった.
とりあえず, "gdb_memory_map disable したらどうですか" との事なので 15行目の "set _ENDIAN little" の下に "gdb_memory_map disable" 入れたら connect できた.
 "Ubuntu 17.10上で openocd と gdb で STM32H743 を debug する方法" で言えば  

"# 3. stm32h7x.cfg の 34行目の _CPUTAPID を 0x6ba02477 に変更 " 

と言うべきであろうか
普段 openocd 経由で flash の書き込みなどをしないので, これで良いと思われる.


ただ, これで終ってしまっては, 面白くないので, openocd の development 版は STM32H7 をすでに入れているのではないかと思うので, 入れてみようと考えた. 手順は以下の通り

1.  sudo apt install pkg-config automake libtool libhidapi-dev
2.  git clone git://git.code.sf.net/p/openocd/code openocd-code
3.  cd openocd-code
4.  ./bootstrap
5.  ./configure --enable-cmsis-dap
6.  make -j4
7.   sudo make install

/usr/local/bin に install されるが search path により /usr/bin/openocd が起動するかもしれないので, search path の変更や apt remove openocd が必要になる.
 今回は STM32H7 系に接続したい為,

openocd -f interface/stlink-v2-1.cfg -f target/stm32h7x.cfg

を実行すると,

Open On-Chip Debugger 0.10.0+dev-00546-g1afec4f5 (2018-10-02-08:58)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
WARNING: interface/stlink-v2-1.cfg is deprecated, please switch to interface/stlink.cfg
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1800 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
/usr/local/bin/../share/openocd/scripts/target/stm32h7x.cfg:102: Error: invalid command name "stm32h7x.dap"
in procedure 'script'
at file "embedded:startup.tcl", line 60
at file "/usr/local/bin/../share/openocd/scripts/target/stm32h7x.cfg", line 102

と表示され,
"stlink-v2-1.cfg でなく stlink.cfg を使え" と， "stm32h7x.dap command がない" と言われる. stlink.cfg はこれを指定する事により特に問題なく切り替えられた, また "stm32h7x.dap どうこう" は色々調べてみると, STLINK でなく CMSIS-DAP を使用する場合に使える command だと理解できた. この事から, /usr/local/share/openocd/scripts/interface/stm32h7x.cfg の一番最後の行を

#$_CHIPNAME.dap apcsw 0x08000000 0x08000000

の様に行の先頭に "#" を追加して無効化した.  その以下のcommand を実行した

openocd -f interface/stlink.cfg -f target/stm32h7x.cfg

無事 openocd を立ち上げる事ができ gdb-multiarch から openocd の 3333 ポート に接続できた. 

STM32H743 SPI の DMA 受信できず

STM32H743 で USB MSC の storage として SPI flash rom を使用する為, SPI の送受信の code を書いていた. 例によって CubeMX で生成される code を使用せずに自前で driver を作成していた.

とりあえず PIO access で送受信できる様にし PC から drive として見える所まで持っていった. 使用頻度は少ないので PIO access でもいいが, data 転送だけの為に CPU resource を使うのももったいないので DMA  access に変更した. しかし, 送信だけを DMA, 受信だけを DMA にした場合は, 問題なく転送できる. しかし, 送受信両方 DMA にすると転送ができない.
SPI の転送残量 (SPIx->SR & CTSIZE)DMA の転送残量 (DMAx->NDTR)  を確認すると SPI 受信時 DMA 残量が SPI 残量より速く減算されており, 見るからに受信したより多く転送されている. SPI の受信信号が正しく DMA の転送 request に接続されていないかと, code を色々見たが
特に問題がなさそう (試しに他の request にすると, 全く転送されてない).
もしやと思い errata を見てみると, DMA 受信は, request が出っぱなしで正しく転送できないと書いてある!!!

 
対策として hardware reset を掛けるのが唯一の方法らしい. この "hardware reset" が CPU全体の reset なのか, SPI module だけなのか良くわからない. ただ, CPU reset はありえないので, RCC の RST を試してみた. Cの code 上 bit を立てて, 寝かせてを連続に行なった.
まぁ, とりあえず全 register が clear されているみたいな感じなので, 該当 SPI の reset はかかっていそう. とりあえず initialize と受信 request の設定を行なってみた.  が, やはり ng, 今度は SPIx->CR1 の MASTER bit が立たない. とにかくやたら MASTER を or する様にしたがそれでも立たない.
 とりあえずあきらめて, 送信は PIO, 受信は DMA として運用する.

現状 simplex RX/TX で実装しているので, Full Duplex で転送してみてどうなるかを検討してみようと思う. ただ, 使用頻度がそれほどないと, 他の SPI module は data 量も少なく送信だけなので, このままかもしれない.

愚痴: この SPI の 送受信 clock 生成の divider って 2の累乗しかできない... すげー仕様

STM32H743 USB の SOF 信号が 2回発生する

STM32H743 にて USB AUDIO 2.0 の実装を行っているが, そこで使用する Clock 周波数の feedback 用に SOF timing 信号を TIMx の Input Caputre 入力に入れ, 信号の立ち上がり事にAudio clock の count 値を latch し前回からの差分で kHz 単位の周波数を計算しようとしている.
現在は TIM5 経由で SOF timing を取り出しているが, 他の用途で32bit counter が必要となった. 32bit counter は TIM2, 5 の 2つ ***だけ*** で, TIM2 はすでに Audio clock 周波数の計測用に使用済で, TIM5 しか空いていない. TIM5 経由でなく, やはり SOF 端子そのものから SOF timing 信号を取りだしたい.

しかし, chip から出力される SOF timing 信号が SOF 毎に 2本立っており使えない状態にあった. その原因を調べ対策を行なった.

問題点： SOF 信号 USB 上の SOF packet 毎に 2 本  pulse が出力

                                         上が USB 信号,  下が SOF 出力端子の信号
                                         前側が偽信号,  後ろ側が本来の信号

環境：
             Ubuntu 17.10
             NUCLEO-H743ZI
             とある target board (NUCLEO-H743ZI を daughter board として使用)
             arm-none-eabi-gcc 5.4.1 20160919
             CubeMX 4.25.0
             CubeMX 4.25.0 で吐かれる HAL + 独自 driver

期待値: SOF packet 毎に 1 回  pulse を出力

行った事：
   とりあえず, ずーっとそういう bug と思っていたが, 念の為 CubeMX で USB と SOF timing 信号出力だけの source を作成し, USB33DEN 対策を入れたものを NUCLEO に焼いた. なんと問題く 1 本しかない!!!
   もしやと思い CRS の実装を行ない target に焼いた所問題なく 1 本なった.

結論：
  とりあえず USB としてだけ使うのであれば, 実力で通信ができるが, SOF 信号の取り出しなど細かい事をすると, CRS を使用しないと問題が発生してしまう.  CubeMX の code そのままであれば問題はなかったが, あまり使用しないとする方針としているので, 大切な一歩となった


余談 (ぐち):
TIMx はなんであんなに細か仕様なのか, すべて TIM2 の様に 32bit の仕様にできないのか.

Ubuntu 17.10上で openocd と gdb で STM32H743 を debug する方法

自前 USB stack (CDC, AUDIO, MSC) を作成しているが, MSC class実装時に memory を壊して hard fault を起してそうであるが, hard fault を起した場所は分るようにしているが, すでに memory がグチャグチャになっている後なので, どこで本当の原因のである memory を壊しているか全く分らない.

いままであまり debugger に頼らず soft を書いていたが, こればかりはどうしようもない.

そこで, opencd で ST-LINK を使い ST32H743 に接続し, debugger として gdb を使用できる様に環境を整えた.

環境について

環境は以下の通り

Ubuntu 17.10
openocd (apt installしたもの  0.10.0)
stm32f7x.cfg (openocd を apt install して install されているもの)
stm32h7x.cfg (stm32f7x.cfg を copy して STM32H7 系に変更したもの)
gdb (apt install したもの)

        connection
        gdb -----(localhost:3333)---- openocd -----(USB)------ STLINK ------(SWD)----- STM32H743

Install

# 1. apt get する

sudo apt install openocd gdb-arm-none-eabi 

#  2. stm32f の設定 file を stm32h 用に copy する

sudo cp /usr/share/openocd/scripts/target/stm32f7x.cfg /usr/share/openocd/scripts/target/stm32h7x.cfg

# 3. stm32h7x.cfg の 34行目の _CPUTAPID を 0x6ba02477 に変更

sudo vi /usr/share/openocd/scripts/target/stm32h7x.cfg

# 4. usb の rule file を作成

sudo vi /etc/udev/rules.d/99-stlink.rules

# 以下を追加

SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="374b", GROUP="plugdev", MODE="666", SYMLINK+="stlinkv2_%n"

# 5. udev を更新

sudo udevadm control --reload-rules

# 6. gdb_memory_map disable を stlink-v2-1.cfg に追加

sudo echo "gdb_memory_map disable" >> /usr/share/openocd/scripts/interface/stlink-v2-1.cfg

Exec for Debugging

# 11. openocd を起動し, STM32H743 に接続 (openocd の port#3333 が gdb 接続待ちになる)

openocd -f interface/stlink-v2-1.cfg -f target/stm32h7x.cfg

# 12. gdb を起動

arm-none-eabi-gdb   binary.elf

Debugging (gdb上での操作)

target remote :3333               # openocd に接続
monitor reset halt                # STM32H743 を reset
load                                     # symbol情報 elfから取得
b FunctionName                       # breakpoint の設定、    必要であれば
continue                                # 起動

[Ctrl-C]                                           # 停止, もしくは breakpoint で自動停止
bt                                                # trace 情報を表示
print ValiableName                 # 変数名 "ValiableName" の値を表示

info break                                        # 設定されている breakpoint の表示
delete breakp n                                # n 番の breakpoint を削除
delete                                             # breakpoint 全削除

continue                                          # 再起動

STM32H743 の USB が使えずの対策

CubeMX (4.25.0) で生成した STM32H743 の USB Audio, CDC の test code を自分流にアレンジして composite device として動作する様にしている. しかし, いつからか power on reset 後 USB が接続できず, PC が enum できない状態になってしまった. ただ, 一度 BOOT0 端子を high にして reset 解除を行なうと rom boot が動作する事になるが, 一旦, この rom boot を動作させた後, reset (power on reset でない) すると接続できていたので, この方法でずっと開発を行なっていた.
ただそろそろ,  power on reset 後に USB が認識できる様にしようと調べてみたが, 結論としては CubeMX で生成された code から power management の code を削除してしまったのが原因だったと思われる.

必要な code は以下の通り

HAL_PWREx_EnableUSBVoltageDetector();
内容は
PWR->CR3 |= PWR_CR3_USB33DEN;
を呼んでいるだけであるが, USB 用の 3.3V regulator を動作させるかどうかの電圧 detector の電源を on/off するもので,  USB を使用する前に on する必要がある. Reference manual には 5V を入力できてそれを 3.3V にする事ができるし, 3.3V を入力する事もできると書いているが,  Nucleo H743ZI の回路は 3.3V を接続されていて regulator を動作させる必要はない. しかし, この regulator を動作させるかさせないかの detect が動作させていない為, regulator の動作が不定になり, USB の動作ができなかったという事だと推察される.

現状 USB を initialize する時の Init(), Register(), Start() の後に code を入れたが, 使用前という事は Start()の前の気がしないではないが, cpu clock で数十数百程度の事なので, たぶんそれは細かすぎる事でなんでしょう.

以下 STM32H743ZI  reference manual DoclD029587 Rev3 から抜粋

追記 (201808050)
上記で rom boot からの reset でUSB が使えて件は, PWR->CR3 が power on reset 以外初期化をしない為に rom boot で USB33DEN を有効にしていてそれを reset 端子による reset 後も引き継いていた為でした (CR2 も同様).

以下 STM32H743ZI  reference manual DoclD029587 Rev3 (section 6 PWR)から抜粋

12TB RAID5 mount 出来ず, でも復活

 先日いきなり, Ubuntu 14.04 に接続している 12TBの RAID5 の disk が access できなくなった.
df してもそれほど問題がある様に思えない. ただ ls しても file がない. dmesg を見ると error っぽい log がある. HDDが動かなくなってはイヤなので fstab で mount 項目を comment out, RAID disk の電源はそのままに, PCだけ reboot した.
 
まず手動で mount すると syslog に以下のwarning が

Jun  7 07:03:46 waters kernel: [90179.663177] sd 9:0:0:0: [sdb] Attached SCSI disk
Jun  7 07:03:47 waters kernel: [90180.352750] EXT4-fs (sdb): ext4_check_descriptors: Checksum for group 3644 failed (10343!=7979)
Jun  7 07:03:47 waters kernel: [90180.352758] EXT4-fs (sdb): group descriptors corrupted!
 
ググってみると, superblock がおかしくなっているという事, mkfs 時に super block の backup が作られているので, 使用する superblock を backup の方を使うことで mount できる.

復活までの操作は
1.  mke2fs -n /dev/sdx   で該当 file system の情報を得る
2.  e2fsck.ext4 -b superblock -B blocksize /dev/sdx   で fsck する
3.  e2fsck.ext4 /dev/sdx  で念の為、通常の superblock で fsck


# mke2fs -n /dev/sdb
mke2fs 1.42.9 (4-Feb-2014)
/dev/sdb is entire device, not just one partition!
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=4096 (log=2)                                               ### fsck で指定する block size
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
366276608 inodes, 2930212864 blocks
146510643 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
89423 block groups
32768 blocks per group, 32768 fragments per group
4096 inodes per group
Superblock backups stored on blocks:                           ### 以下がsuperblock の list 今回は 32768 を使用
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,

    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
   102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
   2560000000




# fsck.ext4 -b 32768 -B 4096 /dev/sdb
e2fsck 1.42.9 (4-Feb-2014)
Superblock needs_recovery flag is clear, but ジャーナル has data.
Recovery flag not set in backup superblock, so running ジャーナル anyway.
/dev/sdb: recovering journal
Pass 1: Checking iノードs, blocks, and sizes
Iノード 721821000 is in use, but has dtime set.  修正<y>? yes             ### ひたすら "Enter" を押す
Iノード 721821000 has imagic flag set.  クリア<y>? yes
Iノード 721821000 has a extra size (30009) which is invalid 修正<y>? yes
Iノード 721821001 is in use, but has dtime set.  修正<y>? yes
Iノード 721821001 has a extra size (61060) which is invalid 修正<y>? yes
Iノード 721821001 has 圧縮ion flag set on ファイルシステム without 圧縮ion support.  クリア<y>? yes
Iノード 721821001 has a bad extended attribute block 2459851454.  クリア<y>? yes
Iノード 721821001, i_size is 4609247913415050120, should be 0.  修正<y>? yes
Iノード 721821001, i_blocks is 34852892082033, should be 0.  修正<y>? yes
Iノード 721821002 is in use, but has dtime set.  修正<y>? yes
Iノード 721821002 has imagic flag set.  クリア<y>? yes
Iノード 721821002 has a extra size (41406) which is invalid 修正<y>? yes
legal block #3 (3411828393) in iノード 721821004.  CLEARED.
Block #4 (2834099418) causes symlink to be too big.  CLEARED.
Block #5 (223285474) causes symlink to be too big.  CLEARED.
Block #6 (151183681) causes symlink to be too big.  CLEARED.
Illegal block #7 (3028417134) in iノード 721821004.  CLEARED.
Block #8 (286251651) causes symlink to be too big.  CLEARED.
Block #9 (2027505565) causes symlink to be too big.  CLEARED.
Block #10 (1513751525) causes symlink to be too big.  CLEARED.
Illegal block #11 (3043589953) in iノード 721821004.  CLEARED.
Too many illegal blocks in iノード 721821004.Clear inode<y>? yes
Iノード 721821000 has a bad extended attribute block 1787912555.  クリア<y>? yes
Iノード 721821000 has INDEX_FL flag set but is not a ディレクトリ.Clear HTree index<y>? yes
Iノード 721821000, i_size is 5904482037710001798, should be 0.  修正<y>? yes
Iノード 721821000, i_blocks is 1997111956269, should be 0.  修正<y>? yes
Iノード 721821003 has INDEX_FL flag set but is not a ディレクトリ.Clear HTree index<y>? yes
Iノード 721821003, i_size is 7593185805256298082, should be 0.  修正<y>? yes
Iノード 721821003, i_blocks is 113575096955107, should be 0.  修正<y>? yes

Restarting e2fsck from the beginning...
Pass 1: Checking iノードs, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one iノード...
Pass 1B: Rescanning for multiply-claimed blocks

：
：
Free blocks count wrong for グループ #9749 (32768, counted=1272).
Free blocks count wrong for グループ #9750 (32768, counted=1272).  
### ひたすら "Enter" 押すがかなり時間がかかるので 停止
 
# fsck.ext4 -y -b 32768 -B 4096 /dev/sdb         ### all yes を指定

# fsck.ext4 -y  /dev/sdb                                  ### 念の為, 通常の superblock を使用して fsck

# mount /dev/sdb /mnt                                  ### mount できた


RAID5 は壊れ出すと修復不可能だが, 今回は super blockがおかしくなっただけなので,なんとかなった.
しかし, いつ HDD が壊れてもしょうがない. 他の server に使用している同型の RAID5 は 2回 HDD を交換している. やはり backup がひつ必要だ. 幸い HDD が 6TBなどは 2,3万円で購入できる. RAID0 もでいいから 12TB の backup を用意しておいた方がよいだろう.

RIGOL DSA832E-TE の購入 --発注から到着まで 1ヶ月かかった--

最近アマチュア無線局を開局したが, 当初無線機を作成するという目的であったが, 自作無線機でいきなりの開局は大変だと思うので, 先の投稿の通り市販の無線機で開局した. ぼちぼちと自作無線機, 特に送信側の骨格が出来つつあり, 出力の電波の質を気にしないといけないくらいに来た. そこでスペアナの購入を考えた. 色々 web site を漁ってみると, RIGOL もスペアナを出しており, しかも低価格である. とりあえず検討した spec は 3.2GHz, tracking generator 付きだ.
RIGOL では DSA832-TE があり日本では 70 万円ほどで, 海外 site  約 $4500 ほどで流石にちょっと高かったので, 廉価版の DSA832E-TG がありそれであれば, 日本円で36万円程度, 海外で $2600 だった. とりあえず廉価版の DSA832E-TG が entry model  として検討するには良いかと考えた.


次はどこで購入するかだが, TEquimpment は site もまともで, 住所から google map で確認しても会社の建物と思われるものも存在していた.


ここで購入をしようと考えたが, 本体価格などは site に書いているし, 付加価値税的なものは米国外での購入の場合は, 納税の必要はない事はない事は分っているが, 送料がどうなるか分らない. 送料無料的な文字があるが流石に米国内だけと思うので, 早速 mail をして聞いてみると FedEx/UPS で $300 程かかる. 本体 $2600 とで約 $2900 程になる. ちょっと高いなと思いつつ, ないと無線機の製作も先に進まない, また TEquipment が見積書を作成し, 該当 site への登録も行なわれ外堀はちょっとずつ埋まってきた. なにはともあれ送料 $300 は高いと思いつつ購入を決めた, 次は支払いをどうするかの検討が必要であった.


クレジットカードでの支払いも良いが, 約 2% の手数料が発生する. 現状, 日本国内, 米国内にドルがあり, そのまま支払いができないかと考えた. 日本では, wire transfer すなわち送金をする場合 最安で 2000 円程度かかる, 海外では $30 ほどかかる. また海外口座の場合は ACH が使えそうだったがまだ使用した事がないので登録に時間がかかりそうだった. よくよく調べてみると外貨がそのまま使える debit card が使えそうだった. 各行 debit card を発行しているが, Sony bank と 住信Sbi bank  の口座は開設済で, debit card の利用登録も簡単そうだった. どちらにするか悩んだが, どちらも使用手数料の返金があるが, sony bank は現金, 住信は point で返金になるので, sony bank の Wallet の登録をする事にした.


支払い方法も確定した事だし, 発注をする事にした. 発注時に, 送料の選択が可能で FedEx/UPS だけでなく USPS なども可能で "Priority Mail Express International" であれば同じくらいの delibery 時間で $200 程度であれば, こちらを選ばないはずがない. 締めて $2800 で発注を行なった.


あとは, 到着を待つだけだ.


待つだけで来るはずなのだが, なかなか来ない, delibery history を確認しとうと思うが, tracking number がない. そんなはずはないと, 発注結果の mail を見ると,  USPS の tracking number があった. 早速 USPS の site で tracking number を入れてみるとちゃんと履歴が出るではないか...


見ると, 結構長旅をしている様に見えた


4/6   発送
4/10 PORTLAND出発
4/11 SFO 到着
4/12 SFO 出発
4/13 PU DONG (china) 到着


確認は 17 日に行なったので, 結構浦東に止っているなぁ, 流石 cost down の為に china air とか使って, 安くしているんだなぁ, 安さの為には浦東から日本に送るのに空を待っているんだと思っていても全く動きがない. 流石におかしいと思い, 日本郵便, TEquipment に mail した, USPS は米国内の customer  support があるが international のものはなく, 問合せ form に米国内の住所が必要で, とりあえず TEquipment の住所を入れても ng だった. 日本郵便は発送伝票をもって窓口に来てくれのそうすれば捜索手続をするとの事 (そんなものがあったのかと初めて知った) ただし, US の発送なので, 私が作成していないので伝票はない. TEquipment に聞いてもないとの事... なにはともあれ, "TEquipment に PU DONG で止ってそうなので, USPS に言って頂戴" と mail したが, 次の日の朝 delivery history の update があり, なっなっなんと SFO に戻っていた. 結局 SFO にもどるんかい! と思ってしまった.


4/19 TEquipment に mail
4/19 SFO に到着
4/21 日本の税関に到着


TEquipment から, "分った, 調べてやる" の mail が来たが, 日本の税関に届いたと mail, "よかった" と mail が来たが, まだ到着していないので, あまり良かった感がない. とは言え, TEquipment に文句を言ってもしょうがない. 文句は空港の荷さばき職人に言いたい...


そこからまだ長い...


後日日本郵便から通関の代理手続きの委任状が来た. 自分でやってみても面白いと思うが, 税関外郵出張所に自分で通関手続をするのだが, 場所的にちょっと行きにくい, まぁ ちょっと前から日本郵便が手数料として 6600 円が必要という事だがそれを受ける事にした. 結局 6600 円が必要なのであれば, FedEx/UPS にすれば良いかと思てしまった. 委任状を 23 日に発送したが, やはりここでも長い時間かかる.


5/1   日本郵便 国際郵便局に Tel, mail にて個人使用証明書を送ってもらい返送
           (浦東に止ってすごく delay したと泣き事も言いつつ)
5/3   不在通知が届いていた (税付国際郵便 税金：13,300円, 通関料: 200円)
5/4   受取

電話から数日で発送され, もっと早く電話すればよかったとちょっと後悔. 正味 1ヶ月かかって受けとりました. とにかく時間がかかりました...
長旅なので, 動作するか気になりますので, 電源を入れ TG と input を接続し, 波形を見ましたが, 問題は無さそうです. といっても直結しただけなので, ほぼとっと下落しているくらいで, もちろん正規化すると完全直線になり, 動作 checkとしてはあまり意味があるかよくわかりません.


掛った金額
DSA832E-TG:    278,665円  ($2,599.00 USDJPY: 107.22円 @20180405 MUFG TTM)
送料:                       21,291円  ($198.58, USPS Pri Mail Exp $100の保険付き)
関税:                                 0円  (税率 0%)
消費税:                     10521円 (税率: 本体価格の 60% の 6.3% )
地方消費税:              2,833円  (税率: 消費税額の 17/63 )
通関料:                         200円
通関代行手数料:      6,600円  0円 (課税対象額が 20万円越えなかった為)

合計:                     320,056円  313,456円
(関税, 消費税, 地方消費税は 100円単位切り捨てっぽく 13,300円になっている. 合計の計算は 13,300円によるもの)

うーん, 日本で購入の場合で 36 万円から計算上 4万円安いが, 紛失, 破損の risk を考えると, 本当に安いといえるのか難しいとろ.  また, 実際は手持ちのドルの平均 rate が 109 円程度なので, もうちょっと高くなる (為替差損状態). 今年の確定申告時にはなにか為替差益があるものと相殺したいところだ.

次回海外で 20万円以上の購入がある場合, FedEx/UPS を検討したいと思う. 日本郵便の 6,600円の通関代行手数料を知らなかったので, $100 けちったけど, 保険もそれなりにあるらしく FedEx/UPS に $300 払っても良いかと思える値差かと思える. ただ別途通関手数料はかかりますが, それほど高くない感じです (siteをちょっと見ただけなので, 書けるだけの知識と調べる気力がありません).

追記 -- 201805080 --
日本郵便に支払うはずの通関代行手数料は, 課税対象額 (本体価額の 60%) が 20万円越えなかった為, いらないとの事. 必要であれば, 消費税, 通関料含めてその旨を郵送するとの事を電話で確認できました. 本体価額が日本円換算で約34万円を越えれば, 6600円かかるので FedEx/UPSにするかの葛藤が有効ですが, 33万下回れば, USPSの方が純粋に $100 けちれます.

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 の周波数設定が間違っていただけでした...

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 になっている

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 だと言う事だ.

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

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 の処理部に突っこんだだけ