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 を用意しておいた方がよいだろう.