Blog2Viewer

以前から製作しているstm32f4xxの装置は全部で7台作ることにした。追加注文した部品も届き、昨日は5枚目stm32f4xx基板を作成。2時間ほどで完成し、電源を投入するとビヤーと電流が流れる。2Aほど。電源装置の電流制限がかかっている感じ。

とりあえず、コネクタなどで簡単に外せる部品は全て外してみるがかわらない。テスターで調べると3.3VのラインとGNDがショートしている。チップコンデンサは故障モードがショートだと聞いたことがあるので、これの故障を疑い、3.3Vのラインのパスコンを全て外してみるが変化なし。

Revision Z　?

ヤニクリーンでフラックスを洗い流し、ハンダ付けを調べ直すが怪しいところは見つからない。ここで一旦諦めかけるが、ピカーンとあることを思い出す。 Revision Z ?

stm32f4xxのErattaを確認した時、PDR_ON端子はRevision Zでは、Vssに繋がっているからね、と書いてあったことを思い出す。ちなみにRevision Zの前はRevision A。なんか最初から最後に飛んでいる気がする。

PDR_ONという端子がわかりにくいのだが、どうも内部の電源レギュレータをパスさせることができる端子らしい。GNDに接続することで電源電圧を1.8Vから1.7Vに下げることができる。しかし、動作保証温度も狭くなるので通常はVddに接続する。と言っても -40～+105℃が0～70℃になるだけ。

今までは Revision Aだったので、3.3Vに接続していた。チップを確認すると"Z"の文字があった。つまり、Vdd(3.3V)に接続されていた端子が内部的にVss(GND)に接続されることになるわけだ。

今回は珍しく基板発注前にErattaに目を通していたし、STM32F4-Discoveryの回路図もチェックしていたので基板はRevision Zに対応している。PDR_ON端子の接続先は0Ωの抵抗で切り替えることにしている。これを付け直すことで無事、3.3VとGNDのショートは解消。電源をつないでも大量の電流が流れることはなくなった。

ST-LINKを接続し、ファームウェアの書き込みを行うとST-LINKで接続できないというエラーになる。うーむ、2Aも流してCPUを壊してしまった。そのうち表面実装取り外しキットで外してCPUを取り替えようということで基板は保管することにした。

そして、今日

ここまでは昨日の話。ここから今日の話。

Revision Zで基板が動いた実績が無いので、今日こそは、ちゃんと1枚作ろうと、また2時間ほどかけて基板を組み立てる。電源を入れても、変な電流はながれない。ST-Linkをつなぎ、ファームウェアの書き込みを行うとエラーになって書き込めない。SWDとJTAGを切り替えてもダメ。何回やってもダメ。

ハンダ付けの確認をやってもダメ。もしかしてチップが、まとめて故障しているのかとか思うが、あまり考えられないし確認する方法も無い。SWD/JTAGなんて、電源さえ繋がっていれば動きそうそうに思える。何が問題なのかわからない。万策尽きて諦めかけるが、このままでは残りの装置がいつまでたっても完成しない。

ここでDFUのことを思い出す。STM32のROMにはboot-loaderのプログラムが内蔵されていて、それを使ってファームウェアを書き込むことができる。私の基板もUARTからDFUを使用するのに対応している。

STmicroのサイトからUART経由のDFUを使用するプログラムをダウンロードし、動かしてみると、CPUは反応しているようだ。ファームウェアを書き込むと動作、ちゃんと動いた。しかし、再度 DFUで書き込もうとすると最初のACKはあるようだが、その後のコマンドの返事が変だ、というようなエラーが出て書き込めない。

ちなみに、昨日作ったボードでDFUを試すと、これもACKは返っているが、その後エラーになる。CPUは死んでいないようだ。しかし、プログラムは書き込めない。

解決

ここで、また諦めかけるがRevision Zでおかしなことが起こっているのではないかと「stm32+revision Z」で検索をかけるといろいろ情報が出てきた。ZではST-LINK Utitityが認識しないらしい。STM32F4-DiscoveryのチップもZになり問題が発生しているそうだ。CPUが返すIDコードが変わったのが原因で、ST-LINKは次のバージョンで対応するらしい。修正のパッチをネットに上げてくれている人がいて、それを使えば解決できるということで、無事解決、ファームウェアの書き込みに成功し、CPUを付け替える必要も無くなった。

メデタシメデタシ。Revision Zにエラく振り回された2日間だった。DFUがおかしい件は解決していないが、これもまた新しい製品にソフトが対応していないとかの話ではないかと思う。

ST-Linkのエラーメッセージが、もう少し配慮してくれていれば解決がもう少し早かったような気がするが、仕方がない。解決できて良かった。

STM32F4モジュールの基板

STM32F4モジュールの基板も昨日到着した。今日、組み立ててみたかったのだが、時間が無くなってしまった。明日へ持ち越しだ。

[caption id="attachment_4590" align="alignright" width="150" caption="pcbcartから到着"][/caption]pcbcartに注文したstm32f405モジュール基板が到着。写真に写っているのは25枚。今回作ったのは50枚。とりあえず組んでみた。




[caption id="attachment_4591" align="alignright" width="150" caption="基板(表)"][/caption]いろいろと不具合が発覚。tDocレイヤーに書いていた文字をシルクに入れるのを忘れていた。ピンヘッダに出している信号を回路図で調べるなければいけない。チップ部品の間隔が狭すぎてハンダ付けに苦労する所、ゴテ先が届かない所が何箇所かある。苦労しながらも何とか組み立てる。



[caption id="attachment_4592" align="alignright" width="150" caption="基板(裏)"][/caption]実験用電源から電源をつなぎ、変な電流が流れないことを確認。ST-LINK/V1を接続するが no target detectedと出る。またか、と思いつつUART経由のDFUも試す。こちらは no response と出る。Revision Zに振り回された時より状態が悪い。



[caption id="attachment_4593" align="alignright" width="150" caption="点滅中"][/caption]いろいろ調べるとRESETがLOWのまま。RESET-SWのタクトスイッチの端子を間違えていて、RESETが常時GNDにショートしていた。とりあえず、RESET-SWを外す。それでも、直ぐにはST-Linkでno targetのままだったが、なんかの拍子に、認識されるようになった。何だったのだろう。まだ何か不安定な問題を抱えているのかもしれない。とりあえずLEDチカチカのプログラムを作成し、ST-Linkで書き込み、点滅を確認した。


[caption id="attachment_4594" align="alignright" width="150" caption="XBee搭載"][/caption]CPUは STM32F405, 64ピンパッケージで、全てのI/Oをピンヘッダに出している。上面にXBee用のコネクタとUSB mini-Bコネクタ。裏面に SDmicroのソケットを実装。上面の6x2のピンヘッダには、JTAG用の端子とArduino Proなどで使われているUSB-シリアルアダプタ用のUSBシリアルアダプタが刺さる。2x3のピンヘッダはBOOT0,外部電源接続(USB, USBシリアルアダプタ)。



[caption id="attachment_4595" align="alignright" width="150" caption="SDmicroとか"][/caption]今後、いろいろと実験に使用して行きたい。


[caption id="attachment_4596" align="alignright" width="150" caption="USBシリアルアダプタ合体"][/caption]
P.S. このブログなんか緑色ぽい。レジストの色を変えるべきか。もっと別の明るい色の記事も増やそう。

自作stm32モジュールとエプソンのS1D13781評価基板,秋月のＴＦＴ液晶モジュールを組み合わせて実験中。
stm32f4xxの内蔵メモリ192kbyteとDMAで480x272dotのTFTを表示させるのは不可能では無いかもしれないが、16bppでやっても 480×272×16÷8 ≒ 261Kbyteで容量的に無理がある。S1D13781を調べると384Kbyteのメモリを内蔵し、480×272の24bpp表示が可能らしい。SPI接続で使用できるし、digikeyで700円ぐらいみたいなので興味を持った。
SPI接続で、どれくらいの更新速度が可能なのか。どんな表示が可能なのかを実験したいということで、実験回路を組んでみた。

秋月のTFTモジュールとSTM32VL-Discoveryを使ったリファレンスデザインが公開されているのでプログラムを見ると、評価ボードのflash-romに画像データを書き込み、それを表示するようなプログラムなので、あまり面白くない。しかし、レジスタの設定値のリストがついてくるのが便利である。

この設定値で初期化するプログラムを作成し、動作させるとTFTにランダムなパターンが表示され「動いた！」と思ったが、なかなか、その先が進まない。メモリーに値を設定しても表示に反映されないのだ。悩みつつレジスタの説明などを見なおしていて気がついた。PIP(Picture In Picture)の機能がOnになっているのに、ずっとメインの表示の方のメモリーを書き換えていた。PIPをDisableにすると、それっぽい表示が現れた。

PIPの機能を使用するとデータ更新が遅くても途中の表示を隠せるので便利そうである。今後、更新速度をどこまで速くできるかとか、スクロール速度とか、いろいろ試したい。

stm32モジュールにつないだTFTに色々表示させようと思ったのだが、表示させるデータが無い。データはSDmicroカードかXBee経由で持ってくるつもりだったので、とりあえずSDmicroカードを読めるようにする。
SDカードの読み出しはstm32f1xxの基板でchanさんのFatFSを動かしたことがある。stm32f4xxでも同じようなものだろうと、とりあえずソースをコピーし適当に修正してコンパイル＆リンクして書き込む。


[caption id="attachment_4620" align="alignright" width="150"] もう１個製作[/caption]SDカードの読み出しを行うと初期化時点でエラー多発。データが不安定な感じ。ハードウェアを疑い、stm32f4xxモジュールを追加で１個製作。ファームを書き込み試すが現象は変わらない。ハンダ付け不良とかではなさそうだ。

どうにも原因がわからないので、ネットで情報を収集。ねむいさんのぶろぐでSTM32F4シリーズでSDIOドライバを実装していて、コードも公開されているのを発見。早速ダウンロードし、読ませてもらう。

で、まず気がついたのが、SDIOの端子(PC8～PC12,PD2)はGPIOx_AFRHとかを設定しSDIO用にするわけだけど、GPIOx_OSPEEDRで100MHzとかの設定もされている。SDIO用の設定がされれば、ドライブ能力は必要に応じて自動で設定されると思っていたのだが、違う？試しに同じように設定を行なってみると、SDカード読み出し時のエラーが無くなった。設定が必要だったのか。

[caption id="attachment_4621" align="alignright" width="150"] 実験しようとしたらSDmicroカードが見つからなかったので、Amazonから4Gbyteクラス10のカードを購入[/caption]でもまだFatFSが動かない。SDカードから１ブロック(512バイト)読み込もうとしても最後の6バイトぐらいが読み込まれていない。理由がわからないので、再度ねむいさんのプログラムを読むと、DMAのFIFOの設定が足りないことが判明。追加するとFatFSが無事動作、SDカードの内容を読み込むことができた。

ねむいさんのブログを読むと、chanさん御謹製のファイラーを動かしているとある。chanさんのおまけのソフトウェアには見当たらないので、どこにあるのかと思っていたのだが、FatFSのサンプルプロジェクトの中にあることに気がついた。これも参考になる部分が多いので読ませてもらっている。