gm300の日記： うつむいて歩くと/V850のフラッシュ 2
日記 by
gm300
v850のフラッシュ。通常モードの時は読めるが書けない といった記述がある。書き込むと外部RAMに書き込まれる。(ユーザマニュアル U17715JJ pp59)
構成図ではflashはプログラム側のバスからはアクセスできるがデータ側にはついていないみたいだ。(
あれ どこだっけ？)
でもずっと読んでいくとセルフプログラムモードで書き込めるとある。その場合、ハード的な制御を行う必要がある。
具体的には reset が復帰した後で FLMD0 を hi にする。(ユーザマニュアル/U17715JJ pp774)
772-3 ページめあたりにはもっと面倒な記述が。曰く「セルフプログラムモードの時には(一切)フラッシュにアクセスできません。書き込みプログラムはRAMに置きましょう。
完全にリロケータブルであればそれほど問題ないような気もするが。
#pragma で RAM のセクションに配置する指示だけでうまくいかないだろうか。無理っぽい。誰がflashか、ROM の部分からコピーしてくれる？
それは rompcrt らしい。obj をパックして hex file にしてから main の中で _rcopy という関数を使うらしい。
(ユーザマニュアル U17293JJ pp207 )あたり。話の都合上か flash ではない本当の rom からの unpack を基準に
書いてある。昔の .exe format みたいだ。
その次の問題は更新できる範囲だな。ブロック単位のみで消去してからのみだと嫌だな。1 は書けるが 0 は書けないくらいであればまだ少しは助かるが。そうでない場合、どうやって複雑なデータを保持するのだろうか。やっぱRAMに退避？それも無駄っぽい。
他のラインで進んでいる「ソフトでハードを破壊できるか？」と合わせるとハード的な操作がないとフラッシュの変更ができないというのは興味深い。v850単体ではflashの書き換えはできない ということだ。セキュアだ。不便だけど。data と code セクションを分離すればいいような感じがするがそういったことはないらしい。ハーバードならできてもいいのに。
構成図ではflashはプログラム側のバスからはアクセスできるがデータ側にはついていないみたいだ。(
あれ どこだっけ？)
でもずっと読んでいくとセルフプログラムモードで書き込めるとある。その場合、ハード的な制御を行う必要がある。
具体的には reset が復帰した後で FLMD0 を hi にする。(ユーザマニュアル/U17715JJ pp774)
772-3 ページめあたりにはもっと面倒な記述が。曰く「セルフプログラムモードの時には(一切)フラッシュにアクセスできません。書き込みプログラムはRAMに置きましょう。
完全にリロケータブルであればそれほど問題ないような気もするが。
#pragma で RAM のセクションに配置する指示だけでうまくいかないだろうか。無理っぽい。誰がflashか、ROM の部分からコピーしてくれる？
それは rompcrt らしい。obj をパックして hex file にしてから main の中で _rcopy という関数を使うらしい。
(ユーザマニュアル U17293JJ pp207 )あたり。話の都合上か flash ではない本当の rom からの unpack を基準に
書いてある。昔の .exe format みたいだ。
その次の問題は更新できる範囲だな。ブロック単位のみで消去してからのみだと嫌だな。1 は書けるが 0 は書けないくらいであればまだ少しは助かるが。そうでない場合、どうやって複雑なデータを保持するのだろうか。やっぱRAMに退避？それも無駄っぽい。
他のラインで進んでいる「ソフトでハードを破壊できるか？」と合わせるとハード的な操作がないとフラッシュの変更ができないというのは興味深い。v850単体ではflashの書き換えはできない ということだ。セキュアだ。不便だけど。data と code セクションを分離すればいいような感じがするがそういったことはないらしい。ハーバードならできてもいいのに。
なるほど (スコア:1)
セルフ書き換えがしたいなら、V850ES/JG2のI/Oピンを１本、抵抗経由でプルダウンしておいた上で
FLMD0端子につないでおけということなんでしょうけど。
でもこれだけで、攻撃する側はチップと共にI/O配線の情報も知らないとFlashを破壊できなくなる。
なかなかよく考えられていると思います。
フラッシュ操作関数ってのをNECは独自に提供してるんですね。
RAMを124バイト、スタックを300バイト消費し、コードそのものは1900バイトですか。
これをリンクしておけば、RAM上にコードを置いてゴニョゴニョするのは全部面倒見てくれると。
スタックもRAM上でしょうから、書き換えのコアになるコードでRAM上に乗る部分は124バイト、
書き込むデータそのものはスタックに積まれて300バイト以内ってことなのかも。
Flashのブロック２とブロック３もブロック０とブロック１が何らかの理由で破壊された時の
バックアップとして予約されているようだし、いっぱいメモリを積んでいる割に予約領域があるので
思ったより自由には使えない。
このV850ES/JG2基版、シリアルUART受信処理が結構難しい [k0hobby.jp]とか言われています。
もしかすると、チップに非公開のバグがあるのかな？
> 次の問題は更新できる範囲だな。ブロック単位のみで消去してからのみだと嫌だな。
> 1 は書けるが 0 は書けないくらいであればまだ少しは助かるが。
Flashは消去こそ大まかにバンクごと消されますが、書き込みはバイト単位でもできたような気がします。
UIVEP-ROMなんかと基本的に同じなら、消去直後はすべてのビットが立って0xffffffffでしょうね。
要らないビットを倒してゼロをどんどん書き込んで行くという感じになると思います。
Re:なるほど (スコア:1)
>もしかすると、チップに非公開のバグがあるのかな？
USBドライバの作りのせいで使い方注意が必要かもしれません。
-ボードがつながっていないとCOMx:のポートでさえ見えません。
つながってから動的にCOMxを定義するみたいで。
- ケーブル接続 -> PC側から2102の設定 -> V850のUART0の設定という順番
そうじゃないと2102がV850から正しくデータ受け取れないみたいです。
という点の他には特に問題ありませんでした。ってまだPC->V850は試していませんが。
チップにバグは12グループくらいあるみたいですね。致命的ななのか、不安定な未定義動作なのかわかりませんが。コンパイラのスイッチで回避を指示できるみたいです。U17293JJ の63ページに記述があります。