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 の仕様にできないのか.
2018年8月5日日曜日
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 になる. 手で削除が必要.
2018年3月10日土曜日
20年ぶりの開局むけて
ちょっと前に 1 マアの資格を取った. モールスの実技がなくなり, 英文の筆記はあるが和文が完全になるなり, これならいけるだろうと言う事で受けた. 試験内容的には, 電卓がいらない試験の為計算問題といっても開平するといっても結果整数になる様なものしかない試験なので, それほど難しいわけでもない. とは言え国家資格試験で値段的に 1 万円に近い試験料なので, 2 回も受けるのはもったいないということで, 通勤時間だけだがそれなりには勉強した.
ところで最近のアマチュア無線ってどうなっているのかと色々な site を見ていると, JT65 や FT8などという digital 通信がはやっているみただ. ただ, 通信 rate は破格の数 baud とかという遅さ. しかし正に地球の裏側まで行く様な通信方式になっている. なんか面白そうだと思ってしまって, ちょっと試してみたいと思ってしまった. そこでふらふら数も少なくなった無線機屋に行きどんな無線機があるのか見に行き, 話を聞いてみた.
驚いたのが最上位機種は大きな LCD があり, まさに測定器といった風貌で約 20 年前に覚えのある表示器は周波数その他数字だけを出せるものとはちょっと違っていた.
対応してもらった方は多分 Yassu の研修生といっても見た目の年齢的に課長研修あたりではないかと思う感じで, 全般的に Yaesu 製品の説明を受けた感じになった. もともと購入するのであれば 10 万円程度のものが適当と考えていて FT-991A と IC7300 とが候補にあがっていた.
IC7300 は大型 LCD で見ためも良く, 受信側は direct SDR という事で digital 派の私的にはこちらかなと思ったが, 説明を受けていると FT-991A はそれなりの RF 回路があり近接妨害を受けにくいという謳い文句でこちらになかり傾いた. ただ, FT-991A の使用 report 的にはあまり操作が直感的でなく使いにくいというのを見た. しかし, すでに魅力的に cost 的に QSL card の交換とかしたいと思わないので, 音声は出たいと思わない. CW は出てみたい気はするがこちらに必要なくても相手から card の発行を期待されるとちょっと重荷になるので, そういうのもありあまり, 細かな操作性はいいと考えた.
あと, 無線機より問題なのが antenna の設置だった. 7 MHz, 14MHz あがりに出られれば良いかと考えているが, tower や八木などは上げられない. Di-pole か GP がいければと考えていると Windom antenna というのがあり, 7MHz の半波長の 20m 長で 7, 14, 28MHz が出られるという事で, この antenna にしようと考えた. 給電点は 1/6 と 2/6波長に相当する部分にありしかし, この様な antenna は通常店舗販売はされておらず, 通販か自作になる. 通販といっても balun の作成が面倒かどうかで, element の調整はどっちみちしないといけないので、自作する事にした. この antenna の入力 impedance は 272[Ohm] で同軸の 50[Ohm] はと balun が必要になる. 理想的には 1:6 だと思うが, 外界の影響で impedance が下る傾向にあるとの事, また, 1:4 balun が作りやすいので, 多くの site では 1:4 としているところが多い. とりあえず core として T106-6 と直径 0.5 mm のポリウレタン線を購入した. もうちょっと太いならびにそれなりの被覆のある線にしておいた方が良かったと後から思ったが, 何度か作り直しが必要だと思われるので, まずはこれでやってみようと思う.
結構 FT-991A に bias が掛った定性的 pros/cons になっているが、なにはともあれ FT-991A + Windom antenna の構成でいき, 無線機も購入してしまった.
あと面倒というか時間が掛るのが開局申請になる. 最近は電子申請ができるという事なので, とりあえず account 申請し, 郵送で user account と password が送られくる. この郵送の一回は無駄な気がするが, cost意識が薄いのと国民からいらぬ攻撃をなるべくかわす為と無理矢理理解した. ただ 2日程度で来たので, アマチュア無線の低迷も含め電波使用申請する人なんかそれほどいないんだとうと思う. 各種業務, 携帯電話会社, 放送局がそんなにバンバンできていないし, あっても楽天が携帯電話の申請をしたくらいで, そもそもこんな system を使うのではなく別 path があると思う (電波利用申請 lite の lite といっているくらいだし)
なにはともあれ, 紙で提出しなくて良くなったのはかなり楽になる.
FT8 などの digital 通信を考えていたので, 開局時に, FT-991A で通常 (音声, CW) 運用できる周波数帯ならびに電波形式, かつ付加装置で申請を考えたが無線機屋の店員が, 通常申請してから, 変更届けを出した方が保証認定から外れなく楽だという事でその手順にする事にした. すでに digital 通信方式を申請している局が新たな digital 通信方式の追加は無料でかつ申請だけで良いという旨を書いている site は多いが, 開局を含めてどの様にしたら良いかは見付けられなかったので一度に行なった方が良いかと思い, 店員に聞いてみると, 保証認定範囲の開局してから, 変更した方が楽だと言う事だった. ただ, 初めて digital 通信方式を追加する時に保証認定から外れると思うが、 最初から digital 通信方式を追加するとしないとで flow の違いが生じるというのがちょっと理解できなかったが, 時間的な観点で言うと, 兎に角電波形式はどうであれ開局するまでに時間が短かいのは, 保証認定内で申請して開局してしまう方法だというのは理解できた.
すぐ申請 site に access しようと思うが今日 (2018/03/10) 8時までは昨日夜からの maintenance で close になっている
登録:
投稿 (Atom)





