M5Stack Fire: psRAMが有効になってない・・・

(2018/8/9追記:購入時点のファームウェアはpsRAMが無効になっているようです。psRAMが使えるファームウェアはこちらの記事を参照してください)

昨日購入したM5Stack Fireを早速セットアップしてみました。
手順はこちらのm5 Goの場合と全く同じです。(センサ類は付属しませんが。)

M5GOのセットアップから使い方いろいろ | スイッチサイエンス マガジン

そして、早速4MBのメモリ空間を確認しようとしましたが・・・

うーん、ヒープが40KBしか無いですね・・・
psRAMが有効になってないみたいです。
スマホ経由ではまだるっこしいのでシリアル経由でさらに確認しましたが、

MicroPython ESP32_LoBo_v3.2.20 - 2018-06-28 on M5Stack with ESP32
Type "help()" for more information.
>>> help()
Welcome to LoBo MicroPython for the ESP32

For online documentation please visit the Wiki pages:

Home
MicroPython for ESP32 with psRAM support. Contribute to loboris/MicroPython_ESP32_psRAM_LoBo development by creating an ...
Based on official MicroPython, this port brings many new features: - support for two cores and 4MB SPIRAM (psRAM) - improved 'network' module - greatly improved thread support - support for 3 different internal file systems on top of ESP32 VFS - ESP32 native support for SD Card - built-in FTP & Telnet servers - support for OTA updates - many new and improved hardware access modules implemented in C and many more... Control commands: CTRL-A -- on a blank line, enter raw REPL mode CTRL-B -- on a blank line, enter normal REPL mode CTRL-C -- interrupt a running program CTRL-D -- on a blank line, do a soft reset of the board CTRL-E -- on a blank line, enter paste mode For further help on a specific object, type help(obj) For a list of available modules, type help('modules') >>>

MicroPython自体はpsRAMをサポートするloboris portが使われているものの、

>>> import micropython
>>> micropython.mem_info()
stack: 752 out of 19456
GC: total: 80000, used: 33504, free: 46496
 No. of 1-blocks: 374, 2-blocks: 96, max blk sz: 450, max free sz: 1143
>>> import machine
>>> machine.heap_info()
Heap outside of MicroPython heap:
---------------------------------
              Free: 106596
         Allocated: 172424
      Minimum free: 97672
      Total blocks: 203
Largest free block: 99460
  Allocated blocks: 198
       Free blocks: 5
>>>

やはりpsRAMは使われていないようです。

ESP32のデータシートによると、psRAMはメモリマップ上では0x3F800000~0x3FBFFFFFにあるようです。

直接メモリアクセスして書き込んでみます。

>>> hex(machine.mem32[0x3f800000])
'0x2f000000'
>>> machine.mem32[0x3f800000] = 0xa5c33c5a
>>> hex(machine.mem32[0x3f800000])
'0x2f000000'
>>> hex(machine.mem32[0x3f800004])
'-0x1'
>>> machine.mem32[0x3f800004] = 0xa5c33c5a
>>> hex(machine.mem32[0x3f800004])
'-0x1'
>>>

うーん、ダメですね。書き換えられていません。
MMUの設定がおかしいのかもしれません。

一応、箱を開けてボードを見てみましたが、psRAMが搭載される領域はカバーされているので目視確認はできません。(位置的にはこちらの写真のようになるようです。)

この記事を書いていたらM5StackのForumにも書き込みが出ていました。

M5Stack FIRE, faild to init PSRAM | M5Stack Community

現時点ではリプライが付いていませんが、メーカーさんの対応を待つしかなさそうです。

2018/8/5追記:この記事を公開したらm5stackの中の人から「G16/G17をカットするとpsRAM安定するかも」というコメントを頂きました。
esp-idfのコード(esp32/spiram_psram.c)を見ると、確かに

#define PSRAM_CLK_IO      17
#define PSRAM_CS_IO       16

となっていて、G16,G17を使っています。

一方、これらの信号は以前のm5stackではUART2(port C)として使われており、M-BUSへも引き出されています。
線長が長くなるので、port Cに何も接続しない場合でもpsRAMの高速動作には悪影響があるだろうということですが・・・
ためしにバッテリ部分を外して、M-BUSに全く何もつながっていない状態にしてみましたが、変化はありませんでした。
といって、M-BUSソケットのG16/17のところだけをカットするといっても、ちょっと簡単じゃない細かさですので、できればソフトウェア的に何とかしたいところではあります。

ファームウェアのビルド時のオプションの問題じゃないかという気もしているのですが・・・。

コメント