2018年11月17日土曜日

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 四方のダンボールだったのでバラすにもゴミの問題もあるので, キャリアに縛り着け帰路に着いた.

2018年11月7日水曜日

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 とか思わないのか.

2018年10月31日水曜日

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日かかるという事なので月曜日か火曜日という事になる.

2018年10月3日水曜日

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 ポート に接続できた. 



2018年8月15日水曜日

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の累乗しかできない... すげー仕様

2018年8月5日日曜日

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 の仕様にできないのか.