Etherもあったのか!

Olimexの新しいESP32評価ボードを見て、少なからぬ違和感を感じました。ESP32というと BT + WiFiのイメージを刷り込まれていたので、RJ45ジャックが付いていることに違和感を感じてしまうのです。最初は、Wiznetとか使ってEtherとつなげているのかと思いましたが、改めてデータシートを確認してみるとESP32がEthernet MACを内蔵しているではありませんか。RJ45のそばにあるのはPHYだったのですね。MII/RMIIをサポートしており10/100MHz対応となっています。

「あれぇ？Etherなんか入っていたっけ?!」と驚いて、2017/1/26の日付が付いている最新のESP32 Technical Reference Manualに目を通してみたものの、Ethernetのセクションがそもそもありません。IO_MUXの章にはピン割り当ての説明があるものの、それ以上の説明が一切ないようです。Olimexもこれからソフトを用意するということなので、Olimexが販売を開始するころには、Ehthernet MACの説明が追加された新しいマニュアルが公開されるのかもしれません。

Aの次はZ

デスマ進行中のため、ブログ記事にするネタも作れずにいます。今日は、仕事で使っているSTM32F767でハマった事について書いておくことにします。

大まかにプロジェクト全体の構成が一通り出来上がって、動き始めたところで、Idle Taskを追加してMCUが走らない時の消費電流を削減するようにしたところ、それまで動いていた通信ができなくなってしまいました。Idle Taskと言ったって、単に__WFI()しているだけのタスクです。これを追加しただけで動かなくなってしまうので、しばらく悩んでいました。スタックのオーバフローが発生しているわけでも無いし、JTAGを使うと問題は再現できません。ソフト的な原因が思い浮かばないので、「もしや」と思って Eratta を読んだところ問題の原因を見つけました。

なんと、「MCUがSleep modeにある期間は、DTCM-RAMに対してのリードアクセスができない」というのです。STM32F767/769ではRAMの最初の128KBがDTCM-RAMとなっており高速にDMAアクセスすることができます。MCUがSleepしている間は、この空間に置いたDMAバッファからデータを読みだして送信しようとしている周辺機器(例えばUART)は、アクセスしてもデータの値として0x00しか読み出せずに、正しい通信が行えないというのです。どうやら書き込みは問題無いようのなので、受信はできるけど送信ができないという問題となって表面化します。「逃げ手」としてDTCM-RAMからのDMA読み出しが必要な場合には、DTCM-RAMではなく、AXI SRAM1またはSRAM2を使うようにと説明されています。これじゃ、せっかくのDTCMが有効活用できませんし、何より今回の用途ではDTCMを使わないと処理が間に合わなくなってしまうのでした。。。仕方ないので、DMAするときにはsleepしないようにすることを考えます....

Erattaシートによれば、このシリコンバグは、Revision Aにはあるけど、Revision Zでは修正されているとのこと。わたしが使っているチップは確かにRev. Aでした。しかし、Revision Aの次が、Revision Zってどういうことよ。残りのバグは今後も修正されず、改版するつもりはないと宣言しているってことですかぁ!?