デスマ進行中のため、ブログ記事にするネタも作れずにいます。今日は、仕事で使っている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ってどういうことよ。残りのバグは今後も修正されず、改版するつもりはないと宣言しているってことですかぁ!?
大まかにプロジェクト全体の構成が一通り出来上がって、動き始めたところで、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ってどういうことよ。残りのバグは今後も修正されず、改版するつもりはないと宣言しているってことですかぁ!?