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月15日水曜日
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 の仕様にできないのか.
現在は 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 の仕様にできないのか.
2018年7月16日月曜日
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 を使用できる様に環境を整えた.
connection
gdb -----(localhost:3333)---- openocd -----(USB)------ STLINK ------(SWD)----- STM32H743
# 3. stm32h7x.cfg の 34行目の _CPUTAPID を 0x6ba02477 に変更
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 # 再起動
いままであまり 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 # 再起動
2018年6月28日木曜日
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 で数十数百程度の事なので, たぶんそれは細かすぎる事でなんでしょう.
追記 (201808050)
上記で rom boot からの reset でUSB が使えて件は, PWR->CR3 が power on reset 以外初期化をしない為に rom boot で USB33DEN を有効にしていてそれを reset 端子による reset 後も引き継いていた為でした (CR2 も同様).
ただそろそろ, 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)から抜粋
2018年6月8日金曜日
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 を用意しておいた方がよいだろう.
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 を用意しておいた方がよいだろう.
2018年5月1日火曜日
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円
通関代行手数料:
合計:
(関税, 消費税, 地方消費税は 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 けちれます.
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 の周波数設定が間違っていただけでした...
今回 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 になる. 手で削除が必要.
登録:
投稿 (Atom)