ROMの容量オーバーについて

お世話になっております。誰か知っている方がいたらご助言ください。

現在、ROM容量違いのRX62Tマイコンを使用しています。コンパイラはCS+ FlashツールはE1を使用しています。

ROM容量64Kのマイコンに、間違ってROM容量256Kの容量でコードを作成してしまいました。

そのコードでFlashしたのですが、問題なく動いています。

アドレスマップを確認したら、256Kのアドレス番地から出来ています。

64K:0xFFFF0000     ~0xFFFFFFFF    256K : 0xFFFC0000 ~0xFFFFFFFF  がアドレス番地になっています。

なぜ正常に動くのかわかる方がおられたらご助言頂けないでしょうか?

よろしくお願いいたします。

  • 書き込めて正常に読めているのであれば、実際にそこにはメモリが存在するのでしょう。
    (半導体屋さんが品種を作り分けるやり方には色々なパターンがあります。以下はあくまで一般論です。)
    メモリサイズだけが違って他の機能が同じ品種を途中まで共通の製造工程で作り、最後のマーキングとテストだけ出荷時の品種として通すことがあります。
    それだと256KBあっても64KBの範囲外は未チェックで通っているかもしれません。どのロットがオーバースペックで作られているのかは工場関係者しか分からないので同じ型名でも256KBあるものとないものが混じっていても気付かないかもしれません。
    あるいはメモリが連続しているように見えて間にリザーブ領域が入っていたりして、256KB品と同じものとしては使えないのかもしれません。「使えたらラッキー」ぐらいに考えておくのが無難だと思います。

  • ほやさん、ご助言ありがとうございます。

    私もその可能性と、E1エミュレータで何かしているのではないかと思っています。

    E1エミュレータには、サイズチェックの機能もあり、その機能をパスしているのも気になっています。

    ありがとうございました

  • まんぷく さん、こんにちは。NoMaYと申します。

    > E1エミュレータには、サイズチェックの機能もあり、その機能をパスしているのも気になっています。

    私は、どのように間違えて、64Kのマイコンで256Kのコードを作成したのか、というのが気になります。

    可能性1)

    ・リンクオプションの-startで指定するROM開始番地を間違えていた(デバイス選択は正しく64Kのマイコンだった)

    ⇒ この場合、E1(というかデバッガ)は64Kのマイコンと認識しているわけですので、E1でのダウンロード過程が実際に始まる前に、デバッガのメモリ範囲チェックが行われた時点で、エラーに出来ますね。

    可能性2)

    ・デバイスの選択を間違えていた(256Kのマイコンを選択していた)

    ⇒ この場合、E1(というかデバッガ)は256Kのマイコンと認識しているわけですので、シリコンが同一なことにより、とにかく書き込めてしまう、ということであれば、もうチェック不能かなぁと思うのです。

  • 回答ありがとうございます。コンパイラはCS+を使用しています。

    セクション設定において、ROMのアドレス番地を設定する事が出来ます。

    原因を調べてみたら、やはりE1エミュレータが、勝手にアドレスを変更していました。

    motファイルのアドレスを参照するのではなく、書き込み時に、マイコンの型番を特定し

    先頭アドレス番地を勝手に64KのROM容量時の送っていました。

    なので、E1を使用すると0xFFFF0000に、motファイルのFFFC0000番地の内容をFlashしていました。

    ご回答にご協力頂きありがとうございました。

  • まんぷく さん、こんにちは。NoMaYです。

    ただ、それでプログラムが動いてしまうのか?というのはちょっと不思議な気がします。というのは、リセットベクタは256Kを前提として生成されたプログラムのリセット番地を指している筈だと思うのですけれど、そこにスタートアップルーチンが書き込まれていなければ暴走してしまう筈のようにも思ったのです。

    また、単純にアドレスをずらしただけですと、そもそもリセットベクタの場所もずれてしまう筈で、フラッシュメモリの末尾のリセットベクタの値が壊れている(何が書かれているか不明の状態である)ようにも思ったのです。

    もちろん、丁度良い具合に幾つかの不具合が重なって、うまく動いてしまっていた、という可能性はあります。でも、何か他の要因(単純にE1が書き込みアドレスをずらしたのでは無い何か)があるのではないかなぁ、という気がしてしまうのです。

    そして、ここから先は、直接、ルネサスさんとCS+の不具合(少なくともダウンロードするプログラムのアドレスチェックが機能していないらしい)について話をされるのも、ひとつの方向かも知れない、と思いました。

  • NoMayさん こんにちは。ご助言ありがとうございます。

    ご指摘の通りだと思います。すべて解析が終わってないので何ともいえませんが、歩調同期通信をつかったROMの書き換え機能を行うため、セクションは色々いじっています。書き換えてほしくないコード(リセットプログラム・割込みなど)は下(本来のROMコードアドレス内)に、書き換え可能なコードは上の方(範囲外)にしていたため、偶然ですが、助かったのではないかと思います。現在、メーカーにも問い合わせている最中でもあります。

    E1でmotファイルのアドレスをみてNGを出してもらいたかったです。

  • こんにちは。お話を拝見して、もしや?と思ったのですが、64KのマイコンのROMは0xFFFF0000のイメージが0xFFFE0000,0xFFFD0000,0xFFFC0000にも出るのではないでしょうか?

    ・FFFC0000に書きこんだつもりが実はFFFF0000に書かれている。

    ・64Kに入るコードであればROMの頭と末尾に書かれるので重複するエリアはない。

    ・CPUが動作するときも、FFFC0000へのアクセスは、実はFFFF0000を指している。

    というシナリオなのですが、無理がありますかね?

  • ベクタは絶対アドレスだから、違うアドレスに書かれたら動く訳ないだろうと思いましたが、みかんさんの言うとおりですね

    0xFFFC_0000~64KBのバイナリが0xFFFF_0000に書かれたのなら、実装ROMが64KBなら動作しちゃいますね

    ROMアドレスの上位16bitが無視されるだけなので

    これはなかなか興味深い事例でした

    しかし書込時に勝手に変えてるというのは困りますね

    E1というかRFPの機能でしょうけど、デバッグ時の書き込みはどうなんだろう