アルファーボード ＡＰ－ＡＨ４Ａ

質問

現在、アルファーボード上のＣＰＵ－ＳＨ４ＡをＣ言語で書いたプログラムから動かす設計をしています。
アルファーボードには８ＭＢのフラッシュＲＯＭが搭載されており、そのフラッシュＲＯＭ上の「あるセクタ」に対して、外部からデータを書き込むルーチンを作成していますが書き込めません。
具体的な動作は、２３２Ｃより取り込んだデータをＲＡＭに蓄えて、フラッシュ１セクタ（３２ｋワード）を丸ごとＲＡＭに展開し、２３２Ｃからのデータとマージし、もとのフラッシュ１セクタへ書きもどしてやる。
「ＲＯＭ化支援機能」を使って、実際の消去、書き込みルーチンはＲＡＭ上で動作させ、処理終了後、ＲＯＭ領域のルーチンへ復帰する。
こんな事を行った経験のある方がいらっしゃったら、ヒントでもサンプルでも良いので御教え頂けないでしょうか？

回答No.1

bug_bug · ベストアンサー

ALPHA PROJECTさんのボードだからと特に注意すべき点は無いと思います。
記述の内容から察するに特に問題の無い設計だと思いますが、どこまでできていて、どこが問題なのか検討がつかないですね。

FlashRomの書き込みについて29LVのJEDEC準拠品であれば、私のユーザプロフィールから過去解答した内２件が参考になるかもしれません。
それほど解答量もないので興味があったら見て下さい。

他気になるとこを挙げるなら、OSレスだと仮定してSH-4ならば、MMUやキャッシュ関連の勘違い、RAM上駆動への遷移をアセンブラで書いているなら遅延分岐等あるとまずいのでパイプラインのフラッシュとか。

(1)RAM上でのプログラム駆動が問題なくできているか
(2)FlashRomへのコマンド発行がきちんとできているか

この２点が確認できれば、問題なくできそうですけどね。
実装する内容はファームウェアのアップデートなどと大して変わらないので、CPU,Flashそれぞれの駆動さえきちんとできれば実現できますね。
どこでトラぶっているのか現状を把握できれば、実のあるアドバイスが可能かもしれません。

お礼

御教えいただき、有難う御座います。過去解答の内容を拝見いたします。

ＯＳレスです。マルチや、スレッドが動くプログラムでもありません。シリーズに上から下へ流れる、テストプログラムです。
(1)RAM上でのプログラム駆動が問題なくできているか
・マップがＲＡＭアドレスになっている点と、ＲＡＭ上プログラムの頭にブレークポイントを仕掛け、アドレスを確認するとＲＡＭアドレスになっています。
(2)FlashRomへのコマンド発行がきちんとできているか
・セクタアドレス上に発行していると思うのですが、確認する手段がわかりません。プログラムを見て頂けませんでしょうか？
ハード上フラッシュＲＯＭは１６ビットアクセスになっていますので、コマンド書き込み、データ書き込みともにアドレスは偶数へセットしなければなりません。マニュアルにあるコマンド発行時のＡＡＡ、５５５番地指定ではアドレスが偶数にならないので１ビット左シフトして使用しています。

//以降ＲＡＭプログラム
srcdata = (USHORT*)FLASHWORK; //RAM WORK:0xD010000
wrtadr = (USHORT*)sctadr; //セクタの先頭アドレス
//Unlock Bypassを使って連続モードにする
adr = (USHORT*)(sctadr); //セクタの先頭アドレス
adr1 = (USHORT*)(sctadr | 0x00000AAA); //1STアドレス + 555
adr2 = (USHORT*)(sctadr | 0x00000554); //2NDアドレス + 2AA
*adr1 = 0xAA;
*adr2 = 0x55;
*adr1 = 0x20;
//連続書込み中、終了アドレスまで以下を繰り返す
for( i=0; i<SECT32KWORD; i++ ) {
*adr = 0xA0; //PROGRAM COMMAND
save = *srcdata;
*wrtadr = save; //データ書き込み
//ポーリング
if( FlashDataPolling( wrtadr, save ) ) {
rtncd = 2; //Fail
break;
}
else{
//ベリファイ
if( *wrtadr != save ) {
rtncd = 3; //Fail
break;
}
}
}
/* 連続モード解除・リセット */
*adr = 0x90;
*adr = 0xF0;
//-------------------------------------------------------
アルゴリズムが妥当だと言うことが判っただけでも助かります。
感謝いたします。

回答No.3

bug_bug

> この様にフラッシュＲＯＭを使うのが始めてでして
では軽くよくあるNOR型FlashRomデバイスの特性でも
・SRAMアクセスと同様にリードは可能
・ビットを0にセットはできるが1を書き込むことは内部構造的に無理
・ビップイレース、セクタイレースを使用して領域単位で0xFFに戻した後書き込むことが必要
以上、FlashRomを使用する以前に把握しておかなければならない内容です。

次に書き込み完了のポーリングの点ですが、DQ6のトグルビットを利用することをお勧めします。
リードアクセスが発生するたびにトグルするDQ6を利用すれば、

//アンチョコ実装
void busy_wait( ULONG addr )
{
volatile USHORT *p, *q;
p = q = (volatile USHORT *)addr;
while ( *p != *q );
}

書き込み完了前はリードするたびにDQ6がトグルするのでwhile条件式は真
書き込み完了後は書き込んだデータがリードできるので条件式は偽となります。
volatile は必須。

内容は２度デバイスにデータを取得しに行って、同じデータが取得できたらFlashRomの処理が終了したと判断しているだけです。

イレースシーケンス、プログラムシーケンスそれぞれの完了確認に利用可能です。
リトライもタイムアップも動作が確認できた後で実装すれば良いでしょう。

> 標準とはどういったコマンドでしょう？
programコマンド(4-cycle)とSector Eraseコマンド(6-cycle)を指しています。

volatileが一切入ってないことに疑問を感じましたが、
アセンブラレベルでレジスタ再利用してないかを調べる必要があったり、手間ばっかり増えちゃいますね

以下、駄文。

余計なアドバイスですが、関数のインターフェイスについて
モジュールの機能的な境界を意識した宣言ができると手間も減りますし可読性も良くなります。

例えば、FlashRomデバイスを駆動するドライバ部分ではアドレス値をULONG型で扱います。
内部でオフセット加算やアドレスインクリメントなど直感的に書けるのがメリットです。それに対して、外部のモジュールへ機能を提供するインターフェイスにはポインタ形式を使用すれば、利用上の制限を型として提示することが可能です。

ドライバの機能を利用する側も、渡すデータのバッファを用意して先頭アドレスさえ渡せばドライバが利用できるので、いちいち型変換を明示的に記述する必要がなくなります。

一応、そんなことを意識しながらサンプルはアクセスするアドレスをULONG型で受けています。
インターフェイスについては全体を俯瞰しないと決定することは難しいですけどね。

回答No.2

bug_bug

一応基板上のFlashRomデバイスの型番を確認しましょう。
ボードのリビジョン違いでデバイスが違ったら動かないだろうなぁって話です。

Web掲載の基板画像から手元ではEN29LVのデータシートを参照していますが、
UnlockBypassコマンドを使った連続書き込みシーケンスとして
//ポーリング コメントまでは問題が無さそうです。

FlashDataPollingの内部処理と戻り値の定義が分かりませんので憶測ですが
タイムアウトで真、トグル完了で偽でしょうか。それ以外なら予期せぬ挙動を起こすと思います。
加えてwrtadr, srcadr共にインクリメントもされていないようです。

前回提示の２点についてですが、
(1)リンク時に出力されるMAPファイル上で該当ラベルがRAM領域に割付けられている
のを確認したら、以降、再度ROMへジャンプするまでの間に呼び出す関数、定数がROM上にあっては
いけません。すべて確認する必要があります。
もっともこのことが原因だった場合、この関数を呼び出した途端プログラムは正常動作しなくなるか
例外でリセットが掛かったりすると思います。

RAMに余裕があるのであれば、スタートアップ内ですべてRAM上へ展開し駆動した方が、リンカ上の設定は楽チンですね。

(2)デバイス依存のプログラムコマンドを使用せず、
標準のセクタイレースコマンド、プログラムコマンドで
デバイスの駆動を確認することをお勧めします。

> セクタアドレス上に発行していると思うのですが、確認する手段がわかりません。
波形を確認するとなるとロジアナが必要になってしまうので、市販のデバッガを用意するか、簡易なシリアルデバッグコマンドを実装することをお勧めします。
FlashRom駆動に限らず、CPUアドレス空間上の情報を外部から参照できる準備をしておくことはデバッグ上必須でしょう。

なんとなくですが、全部いっぺんに実装してしまって、どこが原因か分からない悪循環に陥ってる気配がします。
２度手間ですが、RAM上でのプログラム駆動、FlashRomデバイスの駆動それぞれ順に動作を確認した方が、結果的に問題解決への近道になると思いますよ。

お礼

多くの事を御教えいただき、有難う御座います。
この様にフラッシュＲＯＭを使うのが始めてでして、暗中模索状態です。
貴重なアドバイス、大変、助かります。

ボード上のフラッシュＲＯＭは、仰せのとおり「EN29LV320」です。

「本当だ、インクリメントしていませんね。」
これが原因かなー。せっかく書いた所に上書きしてしまいますよね。

ポーリング確認用の「FlashDataPolling」はプログラムを見て下さい。
ＤＱ７とＤＱ５を使用し、確認失敗時、リトライしています。
ポーリング関数からエラーで抜けてきます。
（またプログラムを見て頂いてすみません）
USHORT FlashDataPolling( USHORT *adr, USHORT data ) {
USHORT dummy[3];
USHORT rtncd = 0;
UCHAR flg = 0;
dummy[0] = *adr;
//データの補数か判定する
while( (dummy[0] & 0x0080) != (data & 0x0080) ) {//DQ7
//タイミングリミットの判定
if( dummy[0] & 0x0020 ) { // DQ5
flg = 1;
break;
}
else {
dummy[1] = *adr;
dummy[0] = dummy[1];
}
}
if( flg ) { //再チェック
dummy[2] = *adr;
if( (dummy[2] & 0x0080) == (data & 0x0080) )
rtncd = 0;
else
rtncd = 1;
}
return rtncd;
}

(1)リンク時に出力されるMAPファイル上で該当ラベルがRAM領域に割付けられているのを確認したら、以降、再度ROMへジャンプするまでの間に呼び出す関数、定数がROM上にあってはいけません。
すべて確認する必要があります。

この文章の意味は、ＲＡＭプログラム（関数）が稼動中はＲＯＭ上の関数や
定数は使ってはいけないと解釈しました、確認致します。
また、ＲＡＭの余裕がありません。（カメラ画像が格納される予定です）

(2)デバイス依存のプログラムコマンドを使用せず、標準のセクタイレース
コマンド、プログラムコマンドでデバイスの駆動を確認することをお勧め
します。

標準とはどういったコマンドでしょう？
御恥ずかしい話、知りません。
使って見たいので御教えいただけないでしょうか？

まだ、取り掛かったばかりなのでＲＯＭ上のプログラムと言っても大した
量が乗っていません、ＲＡＭ上のプログラムに落ちが無いか確認いたしま
す。もう少し、御付き合い下さい。
アドバイスを御願い致します。よろしく御願い致します。