PetaLinuxで手軽にZynq(MicroZed)用カスタムLinuxを作る

2017年1月25日水曜日

PetaLinuxとは何なのか

私の現時点でのPetaLinux認識は次のとおりです。
Xilinxが提供しているカスタムLinux構成管理ツール兼カーネル・rootfsビルダー。標準のYocto Linux向けビルドツールチェーンに手を加えてXilinx SoC向けの各種コンフィグを追加したり、bitbakeコマンド体系をラップして扱ってくれたり、Yocto向けの適切なレシピ管理あたりまでやってくれるもの。Vivadoが生成するハードウェア定義を利用し、当該ハードウェア向けLinux一式の構築から各種媒体への一次デプロイメントまである程度カバーする。

PetaLinuxの基本をざっと把握する

Xilinxのドキュメントをひたすら読んでいくのが良いです。
私はUG980→1156→1157→1144という順でざっと読んでいきました。順序はドキュメント一覧(https://www.xilinx.com/support/documentation-navigation/design-hubs/dh0016-petalinux-tools-hub.html)を眺めてクイックスタートガイド→ワークフローのチュートリアル→コマンドリファレンス→リファレンスガイドと適当に決めましたが、結果的に割と良い順だったと思うのでおすすめです。
本エントリの最後におまけとして、私が読んでいった中でのメモを簡単に残しています。

PetaLinuxのビルド環境を作る

ホスト(コンパイル)環境にはUbuntu 16.04を利用します。古いバージョンのPetaLinux SDKは古いバージョンのUbuntu上で利用したほうが良さそうですが、基本的に最新版を使っていきたいのでこのようにしました。

必要なパッケージの導入

今回ビルドに使った環境は元々Yocto Linuxのビルド環境を構築していたので、その際に導入したパッケージを下敷きにしています。Yocto Project を使用して組み込み用のカスタム Linux ディストリビューションを作成するの「リスト 3. Ubuntu で必要なパッケージのインストール」を最初に導入しました。ものによっては不要なはずです。その後はUG1144の表1-3に従って不足分を補うのが良いかと思います。
PetaLinuxのSDKインストール時点で最低限のパッケージが不足していればハネられるのですが、アーカイブ(5GB超、バージョンによっては7GB)のチェックサム検証→展開→...の後に依存関係チェックがおこなわれるので、失敗すると最初からやり直しで時間がかかって厳しいです。
後述する事情によりPetaLinux 2016.2を使う必要が生じたので、
AR# 67503 / 2016.2 PetaLinux - PetaLinux インストールで 32 ビット互換ライブラリのインストールが求められる
2016.1 および 2016.2 バージョンの Petalinux インストールに対しては、32 ビット依存ライブラリが必要となります。
ということで、通常インストール状態のUbuntu 16.04でそのままビルドを通すのは無理です。このページも参考にしつついくつかパッケージを導入しました。なお、Ubuntu 16.04ではここに書かれているlib32bz2-1.0自体存在しないようで、ビルド上も問題は無かったので多分不要です。
また、
sudo apt-get install bc lib32ncurses5 lib32tinfo5
として追加いくつかインストールしておきました。
さもないと次のようなエラーで苦しむことになります。
[INFO ] build zynq_fsbl
[ERROR] make[3]: *** [xqspips.o] Error 1
[ERROR] make[2]: *** [ps7_cortexa9_0/libsrc/qspips_v3_3/src/make.libs] Error 2
[ERROR] make[1]: *** [build] Error 255

dash村からの脱出

PetaLinuxは/bin/shがbashであることを期待するので、dashをbashに戻す作業が必要です。手元ではsudo dpkg-reconfigure dashを使いました。

ロケールをゴリッと変更する

日本語ロケールで無邪気にPetaLinuxビルドを進めると次のようなエラーで終了します。
[INFO ] install linux/kernel
[ERROR] ERROR: Invalid ELF file '/home/muo/mz_7010_2016_2/images/linux/vmlinux'
[ERROR] make[1]: *** [package-subsystem-FIT] Error 255
https://forums.xilinx.com/t5/Embedded-Linux/Petalinux-2015-2-Invalid-ELF-file-vmlinux/td-p/659064
petalinux-build parses the output of readelf to check generated kernel format.
うわぁぁ…。ひどい。
特に必要のない日本語ロケールを、macOSからSSHでログインした場合にUTF8系ロケールが求められる警告メッセージがうるさいという理由でlocale-genやっていた結果がこれなので報われない。例によってMacからSSHだとアレしてソレみたいな問題があるので、http://yano3.hatenablog.jp/entry/2012/11/25/234244の結果を丸ごと~/.bashrcに書きました(もちろん~/.bash_profileでも良いでしょう)。あとはSSH入り直してok。

PetaLinux SDKを導入する

PetaLinux SDKはhttps://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools/2016-4.htmlこのあたりから入手しますが、Xilinx SDKとは違ってWebインストーラがありません。
つまり、v2016.4の場合は8.34GBをごっそりダウンロードしてインストールするほかありません。
後述しますが、MicroZedをターゲットボードとする場合にはv2016.4をインストールしてはいけません。2016.2を選択する必要があります。2016.2はたった5.5GBで済みます、よかったですね(なお私は両方ダウンロードしました)。
PetaLinuxで諸々のLinuxイメージを生成する範囲ではXilinx SDK不要だと思いますが、必要そうならインストールしましょう。

PetaLinuxでMicroZed向けのLinux一式を構築する

事前に読んでおいたドキュメントに従ってBSPからプロジェクトを生成します。
MicroZedのBSPはhttp://zedboard.org/support/design/1519/10でひっそりと配布されているので入手します(Avnetの会員登録が必要)。MicroZed 7010/7020ともに最新版は2016.2用、と書かれています。

PetaLinuxプロジェクトを生成する

$ petalinux-create -t project -s mz_7010_2016_2.bsp
これだけですね。mz_7010_2016_2というディレクトリにプロジェクトが生成されます。この名前は変更して構わないのかな…。

PetaLinuxをひとまずビルドす・・・る?

まずはビルドしてみましょう。
$ petalinux-build
WARNING: Your PetaLinux project was last modified by PetaLinux SDK version "2016.2",
WARNING: however, you are using PetaLinux SDK version "2016.3".
Please input "y" to continue. Otherwise it will exit![n]
おう2016.3なんてSDKしらねーけど大丈夫か?と聞かれます*1。力強くyと返します。
y
INFO: Checking component...
ERROR: Cannot find XLNX__4___4 of linux-kernel
INFO: Generating make files and build linux
INFO: Generating make files for the subcomponents of linux
ERROR: Cannot find XLNX__4___4 of linux-kernel
ERROR: Failed to get subcomponents for linux
ERROR: Failed to build linux! Failed to get makefiles for subcomponents of linux!
全然大丈夫じゃありませんでした。
これはどうあがいてもPetaLinux SDK 2016.3以上でビルドを通すのは無理なので、PetaLinux SDK 2016.2をインストールしました。PetaLinux SDKは相当巨大でダウンロードから面倒なのにやり直しなの大変苦しいです。
ZedboardはPetaLinux SDKの各バージョンローンチに合わせてhttps://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools/2016-4.htmlでBSPを配布してもらえるのにMicroZedには無い…。仕方ない、売れてない?のが悪いんや。大人はみんなそうや… 正論いやいいと思ってやがる…
ということで、実はhttps://forums.xilinx.com/t5/Embedded-Development-Tools/Error-when-creating-first-SDK-project-after-installation-of/td-p/643937に、なんやビルドが失敗して辛いという話がありまして、このあたりを参考にして適宜パッケージを導入しましょう。
[*1] ちなみに最新版の2016.4を使わず2016.3を使っていたのは、SDSoCの最新が2016.3でそれにあわせたためです

PetaLinux SDK 2016.2でMicroZed用Linuxをビルドする

気を取り直してもう一度。念のためさきのプロジェクトディレクトリは削除してBSPから生成し直し、ビルドコマンドを実行します。
$ petalinux-build
今度は通りました。最後にTFTP用(ネットワークブート用かな)のファイル書き出しに失敗した旨のエラーが出るので、指定ディレクトリをsudo mkdirで掘っておくと次回から安心ですね。なお、あっさり通った風に書いていますが、実際は本エントリの序盤にまとめた依存パッケージやらロケールやらの問題でずいぶん遠回りをしました。
$ petalinux-boot --qemu ...
でQEMU上での実行を確認した感じ、ざっくりいけてそうです。rootで入ってhaltまで確認しました。
halt後にQEMUは自動終了してくれない(内部管理コマンドがあった気がしますが覚えていません)ので、tmuxで専用シェルを立ち上げて実行し、終わったら画面1枚丸ごと閉じる運用をしています。

ビルドするLinuxに含めるパッケージをカスタマイズする

カスタムしてこそYocto Linux、簡単にカスタムできてこそPetaLinuxです。
petalinux-configコマンドを実行して表示されるメニューは階層化されていますが、サブメニュー内の詳細設定、たとえばrootfsに含めるパッケージの選択はpetalinux-config -c rootfsは-c rootfsで明示しないと入れません。
全体コンフィグを抜けると後処理諸々(FSBL用のBSP生成とか)が走るので時間かかります。なお、-c rootfsで実行した画面を抜けると無言で時間かかるのでkill -KILLしそうになりますが、1分程度待っていればちゃんと抜けるので我慢しましょう。
さて、手元ではQtのベースパッケージとexamples、fontあたりを含めてビルドしてみました。
Qt込みにするとrootfs.cpioが順当に膨らみます。
-rw-rw-r--  1 muo  staff  11540480  1 14 22:57 rootfs.cpio
-rw-rw-r--  1 muo  staff  73434112  1 15 07:10 rootfs.cpio
導入するパッケージ量にともなって肥大化するrootfsをどこに置くかは悩ましい問題です。SDカード上の別パーティションへ書き出す筋がスタンドアロン動作面で良いのですが、開発中は何かと面倒です。MicroZedが安定してネットワークにつながる状態ではNFSもよさそうですが、メモリを1GB積んでいるのがこのボードの良いところでもあるので、ひとまず100MBぐらいまではinitramfsでいくつもりです。

PetaLinuxに関する所感

よさそうです。Yoctoのbitbakeを直接触るよりもエラー出力が少なめな分、トラブルシュートをやりづらいと感じますが、間口を広くしたりプロジェクト内での部分オーバーラップしつつの分業体制をうまく回していくのに向いている設計だと感じました。
MicroZedのBSPが2016.2までしか提供されていない点については、差し当たり大きな問題がないこと、そろそろMPSoC時代の安価な評価ボードも出てくるであろうことから、そんなもんかなと思っています。2013年発売のボードですし、あと1年ぐらい色々と使い倒して乗り換えるぐらいのノリでいればいいと思います。

各種の関連FAQ

PetaLinuxをさらさらと使っていく上で読んだFAQエントリを簡単にまとめておきます。何かの役に立つかもしれません。

ツールチェーンの差し替え

AR# 59553 / PetaLinux 2013.10 - Can I Use A Cross-Compiler Other Than the Built-In CodeSourcery Toolsを読むと
I would like to use a cross-compiler other than the default toolchain included with PetaLinux.  Is this possible?
に対して、環境変数指定で内部のツールチェーンを部分的に差し替えられると書いています*2
[*2] そういえばhttp://www.wiki.xilinx.com/Install+Xilinx+ToolsでZynq 7000用に紹介されているツールチェーン、Code Sourcery版とlinaro版などの差が分かっていないので、そのうち調べようと思います。単純にsoftfpuとhardfpu利用の差だけなのかな

Linuxを指定Gitリポジトリからビルドする方法

Xilinxのlinux-xlnxリポジトリから派生させて手を加えたGitリポジトリのコードを使いたい場合、などの話だと思います。
AR# 60406を読むと
PetaLinux 2013.10 and later support the ability to retrieve source code for the Linux kernel or UBOOT from a Git repository.  How do I use this feature in my design workflow?
に対してpetalinux-configで実行するメニュー内での操作方法が書かれています。

PetaLinuxの生成するデバイスツリーファイル(DTS/DTSI)にイーサネットのPHYやMDIOの情報が含まれない

AR# 61117 / PetaLinux - My System Device Tree DTS Does Not Include Ethernet PHY Information
質問はタイトルどおりなので省略し、これに対する答えが
Ethernet PHY information is board level and board-specific information that PetaLinux does not have access to without user input.
ということなんだけど、イマイチ腑に落ちてない…。system-top.dtsもPetaLinuxが生成していけない理由がないように思う(PetaLinuxのプロジェクト生成時点でBSPを読み込んでいるので、ターゲットボードもそのハードウェア構成も分かっているはず)し、petalinux-configの設定画面中にもPHY設定あったような?見間違いかもしれないので、そのうちこのあたりに触れる段になったらもう一度確認してみます。

PetaLinux関連のUGめぐり読みメモ

よく分かっていない状態から段々と全容が掴めていくまでが見て取れるメモです。

UG980(Board Bringup Guide)

  • 諸々ビルドして、bitstream生成も込みでボード上で起動するまでが書いてある
  • おまけとしてシステム構成のコンフィグ方法も書いてあるっぽいのが良い
  • prerequisites部分にシリアルコンソール用のUARTは必須とあるけど本当かなこれ
  • Vivadoからexport hardwareでhardware description fileができる
  • PetaLinux toolsから.dtsやu-bootイメージを生成できる
  • petalinux-createでtemplateにできるのは、ドキュメント上zynqとmicroblazeだけだった
    • 今ならMPSoCとか増えてるんだろうけど、ドキュメントがちょい古い
  • petalinux-createは-t projectでプロジェクト作れるけど、-t appsならアプリ作れる
    • 想定よりも広範囲かな、と思ったけれど ビットストリーム生成まではみ出してはいかないので想定のうち
  • --get-hw-descriptionという不思議オプションがある
    • これ毎回mz7010指定するやつ?
  • petalinux-configからシステム構成設定へと進める
    • 用途とても広い: "If you want to do advanced PetaLinux project configurations such as enabling some kernel options, modifying
the default flash partition table settings and so on, or you just want to view the current configuration, you can run petalinux-config to do so."* petalinux-config -c kernelでカーネルのみの設定を開けるらしい** 同-c rootfsでrootfsをいじれる** ここに追加パッケージ入れるとかやれそうな気がするけど、そこらは直接Yoctoのレイヤを触る感じなのかな* その後にpetalinux-buildを走らせるとLinux本体(つまりカーネル)とrootfsをビルドしてくれるとある* Zynqの場合、petalinux-package --boot ...を使って.binフォーマットにまとめると** 先日触ったXilinx向けYoctoの構成でも、このへんまでbitbake petalnux-buildでやってくれてる気がする。用途の切り分けがよくわからない*** 気持ちの話をすると、Yoctoのbitbake系とPetaLinux SDKでのpetalinux-*コマンド群はiterativeに混ぜて使えてほしい* autoconfigに期待するやつ** "If a component is selected to enable autoconfig, when petailnux-config is run, its config files will be auto updated based on the top system level settings. ... device tree autoconfig is enabled, when petalinux-config runs, the kernel config file <project-root>/subsystems/linux/configs/kernel/config will be auto updated with the top system level settings."とあって期待を持てる*** autoconfigどれぐらい選択肢あるんだろう。頑張ってほしい

UG1156(Workflow Tutorial)

  • "1-1: Design Flow Overview"部分がとてもきれいに役割分担と共にまとまっていて良い。そのまま抜粋
    • Design Flow Step Tool / Workflow
    • Hardware Platform Creation Vivado
    • Create PetaLinux Project
      • petalinux-create -t project
    • Initialize PetaLinux Project
      • petalinux-config --get-hw-description
    • Configure System-Level Options
      • petalinux-config
    • Create User Components
      • petalinux-create -t COMPONENT
    • Configure the Linux Kernel
      • petalinux-config -c kernel
    • Configure the Root Filesystem
      • petalinux-config -c rootfs
    • Build the System
      • petalinux-build
    • Deploy the System
      • petalinux-package
    • Test the System
      • petalinux-boot
  • 気持ち伝わってきたので、あとは全力で飛ばし読み
    • 配布されてるボード用BSPもpetalinux-buildでビルドしてみるところからスタートするのが良さそう
      • Makefileあるけど、直接makeじゃなかったんや…
  • "This step will generate a device tree DTB file, a first stage bootloader (if selected), U-Boot, the Linux kernel, and a root filesystem image. Finally, it will generate the necessary boot images."
    • 大事
    • これでimages/.../image.ubが出て来る。これはFITイメージ?というものらしい
  • リビルドしたらQEMUで試そうな、という優しさ
  • そしてこういう丁寧版も書いてある
    • 1. Change to your project directory and boot the prebuilt linux kernel image: $ petalinux-boot --qemu --prebuilt 3
    • The --qemu option tells petalinux-boot to boot QEMU, instead of real hardware via JTAG, and the --prebuilt 3 boots the linux kernel.
  • デフォルトのログイン情報はID: root、PW: root
    • 意外とハマるやつだ
  • petalinux-bootだけはWindows環境から叩けるようにしておかないと困らない??と思うんだけど、ひょっとすると無いのかこれ
    • JTAGアクセス部分だけLinuxからやるとか微妙に不毛な気がするな...?
  • QEMUの章
    • The --kernel option is used to boot the project’s most recently built Linux image. For Microblaze, it is "<plnx-proj-root>/images/linux/image.elf". For Zynq, it is "<plnx-proj-root>/images/ linux/zImage".
      • なるほど。微妙にわかりづらい挙動やな
  • p.29にちょっと面白いのがあった: "Anatomy of a PetaLinux Project"
  • 続いてp.30。Yoctoだ!!!! となった
  • CAUTION! "<plnx-proj-root>/build/" is automatically generated. Do not manually edit it. Contents in this directory will get updated when you run petalinux-config or petalinux-build. "<plnx-proj-root>/images/" is automatically generated and managed. Files in this directory will get updated when you run petalinux-build.
    • あっ、そういうことなの
    • 若干きな臭い? 個別のパッケージ管理などはあくまでもbuild/conf/以下のファイルで制御しろということか、それすらも触るなということなのか
      • petalinux-configでインストールするrpmパッケージを選べるようになってたら特に文句はないんだけど、どこまで細かくいじれるんだろう(注: その後、petalinux-createで割となんとかなりそうな気がしてきた)
  • p.31-32にも各構成ファイルの役割が書かれていて、そのうち戻ってくるとお得な感じがする

UG1157(PetaLinux Command Line / Reference)

  • 単純にコマンドのリファレンスだと思う
    • 全体の流れが分かってきているので、流し読みぐらいで良いはず
  • petalinux-config -c rootfsからパッケージ選択いける気がしてきた
    • https://www.beyond-circuits.com/wordpress/tutorial/tutorial25/ このへんのスクショ見る感じ、パッケージ選択がある
  • あと問題は、手元の~/build/環境に放り込んであるrecipesをpetalinux-config系にどうやって取り込むか
    • 環境変数設定(setupsdk?)だけでいい感じにそっちを見に行ってくれるのならとても嬉しい
  • bitbake petalinux-imageとかpetalinux-*とついてるレシピ?が何をやってるのか気になるので読もう
    • リポジトリはそこらに生えてるはずなので読みに行けるはず
    • 逆に、petalinux-*の無印コマンドを呼んだ際にbitbakeを内部で呼んでるオチだったらシャンシャンとなる
  • petalinux-create -t COMPONENTというのが出てきた
    • なんだろうこれ
  • "The petalinux-create -t COMPONENT command allows you to create various components within the specified PetaLinux project. These components can then be selectively included or excluded from the final system by toggling them using the petalinux-config -c rootfs workflow. There are no component-specific options for the petalinux-create -t modules workflows."
    • つまり例の.bbファイル相当のもの+そのカタログ管理用ラッパーなのかな
  • 例示
    • Create an application component that is enabled in the root filesystem.
    • $ petalinux-create -t apps -n <NAME> --enable
    • Create a new install-only application component. In this flow, nothing is compiled.
    • $ petalinux-create -t apps -n <NAME> --template install
  • ふーむ
  • ATFはARM Trusted Firmwareということで例のsecure-bootやらTrustZoneやらの系統かー
  • Yoctoへの言及
    • "Introduction: PetaLinux is a development and build environment which automates many of the tasks required to boot embedded Linux on Xilinx AP SoC’s and FPGA’s. It uses Yocto Project underneath for configuring and building various components."
      • のっけにあった
    • petalinux-buildにもあった
      • This tool uses the Yocto Project underneath. Whenever petalinux-build is invoked, it internally calls bitbake. While the tool provides a single workflow, the specifics of its operation can be dictated via the petalinux-build -c and petalinux-build -x options.
      • "-x, --execute"の意
        • Execute specified build step. All yocto tasks can be passed through this option. To get all tasks of a component use “listtasks”. This is optional.
      • なるほど、ようやっと全容見えてきた
      • となると、PetaLinuxのrepoで認識できる形でYoctoの一式を維持しようとすると、PetaLinux側でソースのフェッチから何からやらなきゃいかんのかな? それともsetupsdkでつないでくれる(build/で全部やる)のか
    • まずはpetalinux-configからのワークフローを試して慣れていくのが近道な気がする

UG1144(Reference Guide)

  • Yoctoとの絡みもちょいちょい書いてあるリファレンス
  • 最終的にこれを片手にやっていく感じなのかな
  • bitbakeもちょいちょい露出してるけど、bblayersが出てこないので微妙にこれだけだと不足しそう
  • p.50あたりにprebuilt modulesの追加方法があった
    • 要は*.bbのレシピ追加と組み込みの話なので、これが大事
    • $ petalinux-create -t apps --template install --name mymodule --enable
    • これでいい感じにしてくれるのか、なるほど
    • --template installを与えずにこれやるとCで新規アプリを書いて組み込むテンプレートが生成される
      • こんなんわかるかー!となる
      • autoconfのテンプレートもあって、まあ一貫してはいる..
  • "CAUTION! You can delete the app directory if it is no longer required. Apart from deleting the app directory, you have to remove the line: IMAGE_INSTALL_append= “myapp” from <plnx-proj-root>/project-spec/meta-plnx-generated/recipes-core/images/petalinux-image.bbappend. Deleting the directory by keeping the mentioned line will throw an error."
    • これでbblayersを使ってなくても問題ない理由が明らかになった
  • -t app、-t moduleとあって、それぞれテンプレートがちょいちょいあるので、使い分けは実際やるときに読み直す
  • 原則、-t app --template installのものはビルド済みのやつ(*.ko)を単純に取り込むだけっぽい
    • もちろん他のことに使えんではないだろうけど、役割分けてる
  • p.20からのHardware Import部分もとても大事
    • ハードウェアプラットフォームと.hdfを使うとある
    • これ、BSPとの絡みはどうするんだろう
  • SDSoCからPetaLinuxへ必要なものを渡してビルド、とはならないはずなので注意する
    • SDSoCはあくまでも最終地点
    • カーネルとrootfsの両方を作り上げてSDカードへ書き込める状態にして、それをSDSoC側で設定して使う
    • なんならBSPはSDSoC側で頑張るイメージもあるんだけど、どうだろう
    • 結局bitstream差し替えの都合上、BOOT.binはSDSoCが書き換えるあるいは作り直す認識でいいのかな
    • カーネルとrootfsだけがPetaLinuxからの成果物として、その先は別フロー
    • これまでプラットフォームをエクスポートしてせっせとPetaLinux環境で頑張っていたのが順序逆転して、下回りで必要なものやアプリを組み込んだカーネル・rootfsを先にPetaLinuxで作り、メインアプリをせっせとその上にSDSoCで構築して動作確認までサクサクやる流れ、と捉えると良さそう
    • BSPの出番は更に前で、PetaLinuxのプロジェクトを作るタイミングで必要か、なるほど

$99のオープンソースなロジック・アナライザ DSLogic Proを使ってみたところかなり良かった

2017年1月9日月曜日

前回: ハード開発で詰みが見えたので、やすうまロジック・アナライザを探した

TL; DR

  • $99のオープンソースなロジック・アナライザ DSLogic Proを購入し、使ってみた
  • 製品は注文から2週間ほどで届き、未署名ドライバの壁はあるもののトリガー込みできちんと動作した
  • 信号キャプチャ→デコード確認のためArduino Pro Miniに対するUSBシリアル書き込み(UART)をデコードしてみた
    • 調歩同期式のUARTでは正しいbaud rateを見つけるのが割と大変
  • 想定通りに動作したので満足しました。これから使っていけそう
図1 DSLogic Proで信号をキャプチャしているところ

発送から到着まで

12/13の晩に注文したところ、同深夜に「配送トラブル時のために電話番号を教えてほしい」というメールが届きました。電話番号を連絡するついでに、住所表記の一部が漢字だったのでアルファベット表記で発送してほしい旨を返信しました。
DreamSourceLabは決済だけではなくショッピング管理全体にPayPalを使っているようで、12/27にPayPalから荷物トラッキング番号の通知メールが届きました。
日本での配送は安定の郵便局で、トラッキング情報は次の通りでした。
  • 2016/12/15 19:55 引受 (CHINA)
  • 2016/12/16 14:59 国際交換局から発送 (GUANGZHOU, CHINA)
  • 2016/12/26 07:11 国際交換局に到着 (川崎東郵便局, 神奈川県)
  • 2016/12/27 09:00 通関手続中 (川崎東郵便局, 神奈川県)
  • 2016/12/27 09:56 国際交換局から発送 (川崎東郵便局, 神奈川県)
  • 2016/12/27 23:54 到着 (最寄り局)
2週間弱で最寄り局着ですね、China Post系としては一般的な日数です。以前Twitterに書いた時は3週間弱かかったと書きましたがこれは勘違いでした。12/27の晩に最寄り局へ到着、翌日配達(不在持ち戻り)となりましたが、結局コミケ(C91)の1日目が終わってから引き取りに行きました。

波形ビューア: DSViewのインストール

基本的にWindows用のセットアップ手順へ従います。
ダウンロードした0.96をインストールします。
特にドライバのインストールでハネられることもなく終わりました。そんなばかな。

DSLogic用ドライバのインストール

前述のインストール手順はWindows 8までをカバーしますが、手元環境はWindows 10なので少々手順にアレンジが必要です。
まずDSViewのインストール先を見たところ、ファイルはコピーされていました。
図2 DSLogic用のドライバディレクトリ
この状態なら、Windows 10でやたら強固になった未署名ドライバのインストール制限を回避すれば使えそうですね。当然、仕事用PCでやるべきことではないので注意してください。
手順はhttp://pasofami.game.coocan.jp/Win10_DrvIns.htmに従いました。
一通りの回避設定をして前述の場所にあるdpinst-amd64.exeを実行したところ、次の画面が表示されました。
図3 未署名ドライバの警告
ちなみに回避設定をしない状態だとインストールが強制中断されます(スクリーンショットを残していませんが)。ドライバをインストールしないと話が進まないので、今回は「このドライバー ソフトウェアをインストールします」を選択して続けます。
図4 ドライバのインストールが完了
さて、ドライバをインストールしたら諸々の回避設定を元に戻します。TESTSIGNINGをOFFにしてもきちんと動作するか否かはドライバ依存な気がしますが、DSLogicのドライバは問題なく動作し続けました。めでたしめでたし、です。
ドライバのインストール後にDSLogic ProをUSB接続すると、次のダイアログが出ます。よかったですね。
図5 ドライバがうまく入ってる雰囲気

DSViewの起動とDSLogic Proのセルフテスト

DSViewを起動したら、ひとまず簡単な動作確認をしてみます。
図6 DSViewの起動直後
DSLogic Pro側にセルフテスト用の仕組みが備わっているので、まずはそれを使います。
DSLogicのチュートリアルから多少画面が変わっていますがノリで。Optionsを開いてInternal Testを雰囲気で実行します。0番ピンから15番ピンにかけて信号間隔が広がっていく結果が出ればokです。
図7 DSLogic Proのセルフテスト結果

DSLogic ProでArduino書き込み時のシリアル通信をダンプする

内部信号を使うセルフテストは通ったので、次は外部信号を実際にキャプチャしたいところです。ロジアナを使うの自体が初めてなので、クリップ設置が難しくないターゲットでお手軽に動作確認したいという気持ちもあります。
そこで、ちょうど目の前にあったArduino Pro Mini互換機へUSBシリアル変換モジュール経由でファームウェアを書き込む通信をダンプしてみることにしました。
秋月のFT232RL USBシリアル変換モジュールにつないだPro Mini互換機です。かわいいですね。
気持ちでプローブをつなぎ、気持ちでUARTのデコードまで試してみました。
図8 気持ちの結果(うまく動作していない)
サンプリングレートとサンプル数の設定をいくつか変更してみたところ、いずれもきちんと動作していそうでした(RLE付きの圧縮保存系は未確認)。
一見きちんと動作していますが、ここでのデコード結果はデタラメです。バイナリエディタで書き込み対象のArduinoスケッチを開いてバイト列の一致を探したところ、一切見つかりませんでした。
しばらく試行錯誤した後に、もしや通信速度(baud rate)が合っていないのではないかと考えました。Arduinoの書き込みに内部で利用されているavrdudeはbaud rateを割と好きに変更できます。
Arduino IDEの書き込みログを詳細表示へ切り替えて確認したところ、案の定57600指定になっていました。
図9 baud rate = 57600
そういうわけで1MHz-16Mサンプル取得を指定してデコーダのオプションを次のように設定しました。
図10 UARTデコーダの設定
baud rate以外は、Data formatをasciiからhexへ変更しただけで他はデフォルト値のままです。
デコード設定の変更はダイアログを閉じるとすぐに反映されるので、データの再取得は必要ありません。baud rate指定に対して取得済みデータのレートが低すぎる場合には警告が表示されます。最低でもbaud rateの4倍は必要なようで(サンプリング定理の都合というよりは、信号立ち上がり位置の正確な検出にはよく4倍と言われるあれでしょうか)、今回のbaud rate = 57600では200kHzまで怒られて500kHzから通りました。
今回はDSLogic Pro上のDRAMにキャプチャ済みデータを一旦全て溜め込んでキャプチャ終了後にホストPCへ転送するBuffer Modeを利用しました。さきのレート計算によると115,200bpsの通信も500kHzで収まるので、よくあるシリアル通信であれば64Mサンプルめいっぱい使って131秒間キャプチャできる計算です。優秀ですね。
逐次ホストへキャプチャデータをストリーム転送するStream Modeでは(16ch時10MHz、8ch時25MHzの制約はあるものの)データ量制限がある程度緩和されます。しかしディスク容量の限りキャプチャできるかというとそういうわけではなく、DSView側の制限で512Mサンプルまでしか指定できません。更に、512Mサンプル取得を指定してキャプチャを実行するとメモリ確保エラーが発生します。32bitアプリ・・・。このあたりは必要と思う人がいじって拡張すればよいという感じでしょうか。
本題に戻ります。正しいbaud rateを指定してデコードしたところ図11のとおり、キャプチャした信号をデコードした結果と書き込み対象ファームウェアのバイナリの一部が一致することを確認できました。キャプチャ成功です。
図11 ファームウェア書き込みのキャプチャ結果
調歩同期式のUARTでは設定baud rateが合っていなくてもそれなりに正しそうな誤ったデータへとデコードできてしまうので、baud rateをなんとか調べて合わせるのが重要という教訓を得ました。
I2Cのように常時クロック信号が出ているものなら高レートでクロック信号をキャプチャするだけで実レートの推測が可能なはずですが、UARTだと微妙に面倒ですね。ソフトとデコーダによっては高レートキャプチャしたデータからbaud rateをそれなりの精度で推測してくれそうですが、どうなんでしょう(その後にGuess bitrateというデコーダがDSView内にあるのを見つけたので、今度使ってみます)。それとも信号線のstart bitを見つけた時点で信号サイクルの逆数から通信レートを察するのが基礎技能なんでしょうか。
さて、その後にDTR信号線の立ち上がり/立ち下がりにトリガーを仕込んでのデータキャプチャも試してみました。Arduino IDEの場合、画面上の書き込みボタンを叩くと再度コンパイルから走るためキャプチャタイミングを図りづらいのですが、トリガーがあると無駄に巨大データをキャプチャせずに済みますね。DSViewのUI上で信号線にトリガーオプションを付けるだけで、期待通り必要な部分のサンプリングをおこなえました。

今後

DSView(というか元のPulseView+プラグイン群)ではSPI通信のデコーダ(図12)など、プロトコル解析機能が割と充実しているので開発の中で順次試していこうと思っています。
図12 SPIのデコードオプション

まとめ

$99のオープンソースなロジック・アナライザ DSLogic Proを購入し、使ってみました。
製品は2週間ほどで届き、未署名ドライバの壁はあるもののトリガー込みできちんと動作しました。
手軽なキャプチャ→デコード確認用にArduino Pro Miniに対するUSBシリアル書き込み(UART)をデコードしてみました。
調歩同期式のUARTでは設定baud rateが合っていなくてもそれなりに正しそうな誤ったデータへとデコードできてしまうので、baud rateをなんとか調べて合わせるのが重要です。
想定通りに動作したので満足しました。これから使っていけそうです。

ハード開発で詰みが見えたので、やすうまロジック・アナライザを探した

2017年1月6日金曜日

基板上の信号が見えない

昨年末に同人ハードウェア製作をしていたのですが、自前設計の基板に正しく信号が流れているのか確認するのに苦労することが何度かありました。
これまでは安いテスター1本でやってきたのですが、さすがに限界かなということでオシロスコープ(オシロ)やロジック・アナライザ(ロジアナ)の導入を検討しました。

オシロを買うかロジアナを買うか

信号がきっちり出ていることを確認したいという意味では、オシロの範疇に思えます。回路や基板の設計をやっていると、たとえばI2Cでのプルアップ抵抗値と信号波形の関係を把握しつつ試行錯誤するケースがあります。そのような場合にロジアナではどうにもなりません(ロジアナのA/D変換部分で4-8bit程度の出力をするMSO風オプションがあっても良い気はしますが)。
しかし、私が扱うのは基本的にデジタル信号です。迷ったら両方買えという格言がありますが、このあたりの高額機材をポンポン買っていては身が持ちません。扱っている信号種別はSPIやI2Cのようにスタンダードなものが多く、それらをいかにサクッと検証できるかを重視すべきと考えました。
ということで今回はロジアナを買うことにしました。格好良くいえばデジタル側に軸足を置くみたいな話ですが、アナログ側で本格的に詰まったら結局半泣きで秋月へ駆け込んでオシロも買うと思います。

安価で機能の充実したロジアナ探し

1万円~2万円あたりの(製品ドメインとしては)手頃なロジアナを求める人は昔から居て、一定は先人のレールがあるようでした。検討の過程で上がってきたものをいくつか書き残しておきます。
AliExpressもざっと見てみましたが、ライセンス的に危うそうなSaleae製品のコピー商品が多いと感じたのでやめました。

ZEROPLUS 64kb 16ch 100MHz

秋月で売っているZEROPLUSロジックアナライザ64kビット16ch100M LAP−C(16064)は割と良さそうでした。2万円は予算オーバーですが、調べた限りハード・ソフト共に評判が結構良い製品です。しかし発売から6年経っていることから、もう少し新しいアーキテクチャで確保可能なデータ量も多い製品があるのではないかと考えました。

1万円ロジアナ自作キット

一部界隈で有名なカメレオンUSBの方のロジックアナライザキットもあります(ました)。あまりこの方面の手組みはしたくないなと思って見送りました。

Sigrok: オープンソースの信号分析ソフト

ここで少々目をソフトに転じました。信号をキャプチャするハードを安価に揃えられても、信号を解釈してデータダンプするにはソフトが必須です。
いくらか探してみて見つかったのがSigrokというオシロとロジアナの両方の機能を持つオープンソースの信号分析ソフト(というか信号分析基盤)です。幅広いロジアナをサポートし、それなりに幅広い信号種をサポートするという素晴らしさです。

Sigrokと組み合わせる前提の廉価ロジアナ

Sigrok wikiのCategory:Open source hardwareでいくつかの製品が紹介されています。
20MHz駆動のPICに32KBのSRAMを4つ組み合わせるというゴリ押しみの高いLogic Shrimpが割とツボでした(実用性はさておき)。
AndroidとがっちゃんこしたOsciPrimeも面白そうでしたがオシロはひとまず買わないことにしたのと、値が張るので回避しました。
この界隈ではFPGAをベースとするロジアナの老舗SUMP.ORGがあり、これに基づいたボードが数種類存在するようでした。たとえば$50のOpen Workbench Logic Snifferです。割と良さそうですね。
秋月ではXilinxのSpartan系開発ボードであるPapilioシリーズに対するロジアナ拡張であるPapilio FPGA Logic Analyzer Tools Kitも扱っています。

DSLogic Pro

そんな中で見つけたのがDreamSourceLabのDSLogic Proです。元々は2013年末頃のKickstarter案件だったようです。
製品ポイントをまとめると:
  • 最大サンプリングレート: 4チャネル400MHz
    • 16チャネル時は100MHz
  • 内蔵バッファメモリサイズ: 256Mbit
  • ソフト: Sigrokのカスタム版+自前ビューア
    • Windows/Mac OS X/Linux用ドライバ提供
    • ビューアはSigrokのPulseViewベース
  • 直販で買えばクリップ10個付き送料込み$99
ということで、きちんと動いてくれればかなりお買い得な製品だと感じました。似た価格帯でオープンソースなものとそうでないものがある場合、オープンソースなものを選んだほうが何かと嬉しいですし。
ビューアのGitHubリポジトリ: DSViewを見た感じ、最近メンテスピードが落ちているようですがそれなりの品質には到達していそうです。
そういうわけでサイト直販のPayPal払いで2016年12月13日の晩に注文しました。
次回は製品が無事に届いて実際に動作を確認した話です。

よなよなリフロー: レギュレータMIC5524-3.3V その2

2016年11月30日水曜日

よなよなリフロー: 極小レギュレータ MIC5524-3.3Vと同じパーツ・基板です。
この寸法のパーツもなるべく扱いたいので、手慣らしがてらやりました。
今回はパーツ配置上の工夫と、問題が顕在化した「ステンシルの保存」について概要を書きます。リフローと動作確認は前回と同じなので省略します。

配置上の工夫

前回のリフロー作業時にはパーツ中央をピンセットでつまんでターゲットの真上から降ろしていくスタイルで配置しました。
今回は他の方法を試してみたかったので、まずパーツをつまむ位置を中央から片端へと変えました。そして、基板に対して平行にパーツを降ろしていく方法ではなく、先に片端をソルダーペーストに接触させた後でパーツを離してトンッと置いてみました。
パーツ中央をつまんで平行に降ろす方法だとピンセットを開いてもなかなかパーツが離れずにパーツ位置がズレてしまうケースがあるため試してみた策で、これは位置の目算を誤らなければ割といい精度で置けそうです。パーツ配置作業の後半まで基板面が見えるというメリットもあるので、これで安定すると嬉しいところですが、目算を誤るとソルダーペーストを拭き取って塗り直しなので大変です。

ステンシルのメンテと保存状態の重要性

ステンシルは構造上ソルダーペーストが穴に残りがちです。今回は食品用の消毒アルコールとティッシュペーパーを使って拭き取っていました。
しかしこれだけでは不十分でした。1週間ほど経ってまた同じ基板をリフローしようという段になって、今回の拭き漏らしソルダーペーストが0.25x0.32mmのステンシル穴に詰まっていると気付きました。その時には既にかなり硬くなっており、ソルダーペーストで上面から押し込むようにしてもなかなかうまく抜けてくれませんでした。
この話はだいぶ長くなるので回を改めて書きますが、ステンシル利用直後にマメなクリーニングをすべきというのが今のところの結論です。手間はかかりますが、ソルダーペーストが詰まって固まると本当に厄介でボードの出来に大きく響いてくるため重要ポイントです。
事前に自宅リフローについて調べた際にあまりこの方面の情報は見つかりませんでした。
理由を推察するに
  • 自宅リフローで主流の紙系(ユポ紙系)ステンシルは原則的に使い捨て用
  • 詰まりが問題になるような0.3mm平方前後の小さな穴をカッティングシートで実現するのが困難
  • そもそもステンシルを中途半端なクリーニング状態で1週間以上放置して再度利用することがまれ(?)
このあたりでしょうか。

手作業リフロー向きの部品形状・寸法について考えた

紆余曲折あって結論は「MIC5524-x.xYMTの寸法のパーツ(TIのX2SON-4なども同様)を多用するとソルダーペースト塗り・リフローの両面で歩留まりを悪化させるので当面は避ける」と落ち着きました。今回の試作品についてはステンシル用に書いたパターンが今ひとつ良くないのも原因のひとつですが、それを差し引いても結構難易度の高いパッケージという印象です。
何よりもこの寸法・パッド形状のパーツはリフロー工程で失敗した際にリワークするのが困難です。リワークの難しさはボード全体の歩留まり悪化に直結します。手作業リフローではなるべくミスを起こしづらく、リワークが可能なパーツを選定すべきだと考えています。
とりわけ、部品点数が10以上あって部分的な失敗が全体に響く構造のボードであれば、以下のポリシーで運用すると安定しそうです。
  • 抵抗・コンデンサは0603(1608; 1.6x0.8mm)品で問題ない
    • 配置を詰めすぎるとピンセット実装が大変なので、その点には注意
  • IC/LSIはなるべく0.5mm以上ピッチ・角丸0.25x0.8mm以上パッドのパーツを選ぶ
    • なるべく、側面にランドの露出しているQFNパッケージ(および類似品)を選ぶ
    • まだBGAはスキル的に無理。特に、リフロー機材選択時に両面部品実装の筋は捨てているので当面考えない
  • レギュレータはTLV713のSOT-23(5)パッケージ品(0.95mmピッチ・0.55x1mmパッド)などを利用する
    • TLV713シリーズは入出力コンデンサ不要ながらも安価なのがとても良い
    • 出力が150mAで不足する場合は400mA出力のTPS736シリーズなどを検討する(しかし内蔵コンデンサの大容量化によるものか、値段が250円程度まで上がるので可能なら避けたい)
    • 諦めて入出力コンデンサを配置する場合はRohmのDUxxSD5シリーズが手頃(50円程度)でよさそうだが未検証
ボードの極端な小型化は製造難易度を上げて歩留まりを悪化させるので、ほどほどで諦めるのも重要だと実感しました。どういうことをすれば費用的・時間的に「高くつく」かが見えてきたのは自宅リフロー1ヶ月目の大きな収穫です。

よなよなリフロー: PIC16F753-I/ML(その2)

2016年11月29日火曜日

前回のよなよなリフロー: PIC16F753-I/MLでうまくいったものと同じ構成です。このチップはリフローの練習用と割り切って安価なものを入手しているので、色々な方法を試しつつスライムを安定して殴れるような水準まで早く行きたいところです。
が、今回は残念ながらパッド間でブリッジしてしまいました。

ピン間でブリッジしてしまった悲しさと対策検討


図1 ピン間でブリッジしてしまった
実はこの2ピンはNCなので外部的な問題はありません。内部でもおそらく結線されていないので問題ないと思いますが、やはり気持ちの良いものではありません。
失敗原因として、パーツを置いてから多少ピンセットで触って位置合わせをしたことが挙げられます。前回ピンセットでのパーツ位置の調整が割とうまくいったため、そのノリでやりすぎたかもしれません。当初のペースト乗りがきちんとしていても、あまり横移動させると当然ブリッジしやすくなりますからね…。
他の原因も検討してみます。写真で仕上がりを見比べると、前回のものよりも今回のほうがピン全体的にハンダの乗りが多いためペースト分量が多かったと考えられます。これに作業プロセスによる影響が大きそうです。
今のところ基板上へ載せるペースト量を抑え気味にし、プラスチックのカードで何度もステンシル面をゴリゴリと往復して各パッドへペーストを詰めるようにしています。これは少々やり過ぎで、ステンシルと基板の間の微妙な隙間へペーストがにじみ出る格好になっているかもしれません。ある程度多めにペーストを置き、プラ片でサッと全体へ塗ったほうがうまくいく可能性が高い気がしてきました。
もう一つ有力な原因として、基板面がステンシル面から浮きやすいというのがあります。この基板は複数の基板を面付けしてミシン目カット用に仕上げたものなので、当然ペーストを塗ったそばから基板を切り離していきます。
今回の作業時点で、本基板からレギュレータ1/2とPIC16Fその1を切り離した後で、基板面が割と空いていました。基板を固定用の基板で囲んだ上にステンシルを載せるというフローを採っていますが、基板面がスカスカだとステンシルが面として安定せず湾曲してしまいます。
こう考えると、ステンシル自体をサブ基板用に切り分けたほうが安定するのかなーという気もしました。しかし0.12mm厚とはいえステンレスの加工は割と鬼門で、たわませずに切り分けるのは結構難しいと思います。最初から切り分け前提でミシン目状に穴あけをしておき、ニッパー/ニブラーで簡単に切り離せるような形状もアリかもしれません。しかしElecrow側で製造上の負荷が大きなものは断られる可能性が高いのに加え、デザインルールに準拠した設計が可能か要確認です。
短期的な方法としては、他のサブ基板を取り外して空いたエリアを適当な基板片で埋める策が考えられます。大体Elecrowで注文すると1-2枚余分に納品されてくるので、それぞれ見比べてシルク印刷がズレているものやスルーホール位置が怪しいものを穴埋め専用基板として使うとよさそうです。

リワーク…

この時は残念ながら手動でリワークのための機材が不足していました。具体的には、致命的なことにハンダ吸い取り線の手持ちを切らしていました。
物は試しとデザインナイフで端子間をブリッジしているハンダをなるべく削り取って再リフローしてみました。あまりハンダ形状は変わっていませんでした。一度目でフラックスが揮発しているのでこのような振る舞いなのかな、と少々興味は湧きましたが。

動作確認

その後、PICkit3互換機を入手してMPLAB IPEを利用したところ、問題なくチップ情報を読み取って書き込みも確認できました。

よなよなリフロー: PIC16F753-I/ML

2016年11月17日木曜日

よなよなリフロー: 極小レギュレータ MIC5524-3.3Vと同じタイミングでリフローしました。
リフローの練習用と割り切れる価格帯のチップを探していて見つけたものです。Mouserで1つ127円でした。100円前後で16ピン程度の小規模QFNパッケージ品を探していてぴったりとマッチしたので購入しました。
基板は図1のとおりで、16/14ピンの電源部分にパスコンを入れたのがほのかな進化ポイントです。本当は300mil幅に仕上げたかったのですが、端子・配線・電源用コンデンサの都合上難しかったため400mil幅にしました。
図1 基板設計

前略リフロー

図2 リフロー結果(+ピンヘッダのハンダ付け)
よなよなリフロー: 極小レギュレータ MIC5524-3.3Vの回に書いた、ステンシル上の位置合わせ用コンデンサ穴が役に立ちました。想像以上にうまくいっています。
可能な限りの接点テストをおこなったところ、電気的にも問題なさそうです。テスターを順に当てていったところ14/15ピンが通電しておらず焦ったのですが、そもそも共にNCなのでピンヘッダ側へ配線を出しておらず問題ないというオチでした。
しかし、基板表面の写真を無理やり撮っていると、だんだんとマイクロスコープが欲しくなってきますね。

動作確認はまだ

さすがにPICライターなしでは手軽に確認できないので、確認は別のタイミングでおこないます。

よなよなリフロー: Lattice iCE40LP384(失敗)

2016年11月16日水曜日

最近中国資本が13億ドルで米Lattice Semiconductorの買収を計画の記事で話題になった、LatticeのFPGAです。
32ピンとFPGAにしては少ないピン数で5mm角というほどほどの扱いやすさを感じたので入手してみました(図1)。Mouserで1つ190円ぐらいです。
図1 iCE40LP384チップの外観

基板

0.5mmピッチQFNパッケージなので手ハンダが厳しく、ステンシルを作ってソルダーペースト塗布→リフローの流れで作ろうと考えました。チップを45度回して四方へいい感じに信号線が伸びる基板に多少のあこがれがあったので、今回はブレッドボード用のブレークアウトボードを作ってみました。
Elecrowで通常注文し、8日ほどで到着しました。
図2 届いたブレークアウトボード

初ステンシル

実は今回のものは私が最初に作ったステンシルです。実際に使う順序はよなよなリフロー: 極小レギュレータ MIC5524-3.3Vのほうが先になりましたが、基板アートワーク作業/発注/到着すべてこちらのほうが早く、しばし寝かせていました。
前回の記事で書いたようにユポ紙ステンシルを使わないと決めています。このため、とにかくKiCad→ステンシル→ソルダーペースト塗り→リフローの流れの不明点を早く潰していかないと先々が不安でした。
多くのPCB製造会社ではステンシル作成費用がかさむようですが、Elecrowは$16.00で15x15cmまでのステンシルを作成してくれます。この値ごろ感もあり、初回注文分は最悪使えなくても勉強になればよし(当然、事前に可能な限りの確認作業はする)という気持ちで注文しました。

パーツ実装

最終的なパーツ配置イメージは図3です。
図3 ソルダーペーストなしで仮位置合わせをした
前回のリフローで多少は経験値がたまったので挑戦してみましたが、難しかったです。前回は基板の端に位置合わせ用の無駄チップコンデンサ(C0603)を配置していましたが、今回使ったステンシルはそのような知恵を見出す前の世代のものです。
5mm角チップとそのパッド位置のみを頼りにしてステンシルの位置を合わせるのはとても難しいと感じました。
図4 1度目
隣同士でベタッとくっついてしまっている場所があります。ペーストを拭ってやり直し。
図5 2度目
やはりくっついてしまっている箇所があるのと、斜めにズレたためやり直し。
図6 3度目
ペーストの量はほどほど良さそうですが、塗れていない(抜けていない)パッドがあったのと斜めになっているのでやり直し。
図7 4度目
完全にズレた。
と、4回失敗しました。このままリフローまで強引に進めても成功する可能性が見えなかったため、撤退しました。
ミシン目カット基板ではなくとも、基板の端っこにある空きスペースへC0603を配置してステンシルを位置合わせできるようにしておくのが良いと感じました。
あと、ステンシルに残ったソルダーペーストをうまく拭き取らないと穴に詰まってしまうので、どうしたものかなと考え中です。ステンシルは0.1mm厚あるので、普通にキッチンペーパーへアルコールを染み込ませて拭うだけでは一部落ちきってくれません…。商用のリフロー環境では溶剤に浸してメンテなどするのかもしれませんが、家庭用の良い方法を探したいところです。

撤退戦

悔しいのは、今回のソルダーペースト塗布直前に一度iCE40LPのパッケージを開封してしまったことです。
多くのLSIパーツにおいて、ハンダ付け前の湿度管理は重要です。今回使ったのはMSL 3のパーツで、基本的に開封後は一定の時間内に実装を終えることが求められます。さもなくばモールド部分にたまった水分によってリフロー時に内部へクラックが入ったり断線したりとややこしい問題が起こり得ます。一旦開封したパーツを規定時間を過ぎて利用する場合は90度あたりでしばらく焼く(ベイクする)ことで水分を抜く必要があり、厄介です。
このあたりはIPC/JEDECによるICパッケージ(MSL)の防湿管理というページがとても参考になります。
このため、撤退を決めてすぐにガムテープで仮の封をしました(図8)。残念な感じになっています。
図8 パッケージをガムテープで再封
パッケージに入っていた乾燥剤の交換もしていないのでダメ感がかなり強いのですが、今回購入したものはあくまでも試作用なので再度開封後にもベイクはしないつもりです。再封に食品パック用のニクロム線シーラーを使えば多少はマシだったかもしれません。

そういうわけで

iCE40LPは位置合わせ用のガイドをつけた基板とステンシルが届くまで一旦保留ということになりました。