”かふぇルネ“はルネサス製品に関してユーザ同士が自由に会話をするツールであり、回答者はルネサス社内外の方たちとなります。ルネサス製品やソリューションに関して正式な回答をご希望の場合は、ルネサス技術サポート問合せをご使用ください。

更新機能を実装した際、リセットすると再起動しません…

お世話になります。

アプリケーションノートR20UT3475JJ0300(https://www.renesas.com/jp/ja/document/mat/rl78-family-c-compiler-package-cc-rl-how-divide-boot-and-flash-areas?language=ja )に沿ってブートローダとアプリケーションに分割し、アプリケーション部分を通信で更新するようなソフトを組んでみたところ、表題のような問題が出ました。  

状況が複雑なのでうまく伝えきれるか不安ですが、詳細を書きますので、何かとっかかりが見つかればと思っております。誰か助けてください…。

<アップデート処理の詳細>

ブートローダにFSLを組込み、

1. 通信で更新バイナリを転送

2. アプリケーション部を消去

3. 更新バイナリを書込み

4. 起動(アプリケーション部のアドレスへジャンプ)

という流れで動作するようにソフトを組みました。

<状況>

ソフトの開発はCS+/E2 Liteという環境で行い、開発中はデバッガを接続して検証しながら開発していました。
機能が確認できた段階で、デバッガを外して動作させてみたところ、「更新後にリセットしたら動かない」という状況になりました。

なお、更新直後はアプリケーションはちゃんと動いていました。
バージョン番号からちゃんと更新されていることも確認しました。
いったん電源を落とすと、うんともすんとも言わないという状況です。

<その後調査したこと>

* ブートローダ起動時にDOポートをHIGHにする処理を入れ、どこまで処理が進んでいるのか確認したところ、
ポートの初期化直後にHIGHにするようにしても、HIGHになりませんでした。
ブートローダの初期化ルーチンにすら進んでいないようです。

* LVD等で電圧低下時のリセットがうまくいっていない可能性を考慮し、通信でソフトウェアリセットを掛けてみましたが、状況は変わりませんでした。
リセットがかかった後、ブートローダの処理に進んでいかないという状況のようです

* 現象発生後、E2 Liteで接続しデバッグ実行したところ、問題なく動作するようになりました
「接続」のみで「ダウンロード」はしていませんが、状況が回復しました

何をしたらいいかもよく分からなくなってきたので相談としてポストしました。

状況がよく分からないとは思うのですが、何かコメントいただければ幸いです。

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

  • mark_n2さん、こんにちは。NoMaYです。

    > 機能が確認できた段階で、デバッガを外して動作させてみたところ、「更新後にリセットしたら動かない」という状況になりました。

    ファームウェアのアップデートという要素が加わっていますが、ひとまず良くあるトラブルの「デバッガから実行すると動作するのに、デバッガを外してRFPで書いて単体で実行させようとすると動作しない」というカテゴリで考えていってみてはどうだろうかと思いました。

    その場合のセオリーでは、「内蔵フラッシュROMを書き換えないモードでデバッガを起動してデバッグしてみる」という作業を行うのですが、この文面でどうやってデバッガを起動すれば良いか伝わりますでしょうか?

  • NoMaY様

    リプライありがとうございます。

    ファームウェアのアップデートという要素が加わっていますが、ひとまず良くあるトラブルの「デバッガから実行すると動作するのに、デバッガを外してRFPで書いて単体で実行させようとすると動作しない」というカテゴリで考えていってみてはどうだろうかと思いました。

    更新前は問題なく単体で動いていたので、更新するという要素が重要なのかなと思っていたのですが、そうですね、カテゴリとしてはそちらのほうが近いのかもしれません。

    「内蔵フラッシュROMを書き換えないモードでデバッガを起動してデバッグしてみる」という作業を行うのですが、この文面でどうやってデバッガを起動すれば良いか伝わりますでしょうか?

    CS+のデバッグメニューで「デバッグ・ツールを接続する」という項目があり、他と違って「ダウンロードする」わけではないため、中身は書き換えないモードなのかと思いましたが、そうではないのでしょうか?

    こちらで動かしたら普通に動いてしまったので、余計に謎が深まっているところなのですが…

  • mark_n2さん、こんにちは。NoMaYです。

    一応自分でも試してみようとしたところ、まずコネクトするだけでも四苦八苦、実行しようとしたらエラーで実行出来ず、という状況に陥ってしまいました。(素性の分かっている簡単なプログラムとしてRL78/G23 COMPort通信デバッグで試そうとしたのが敗因かも知れませんが、、、) もう少し裏を取ってからリプライしたいと思います。

  • mark_n2さん、こんにちは。NoMaYです。

    RL78/G23 COMPort通信デバッグは、内蔵フラッシュメモリを書き換えないモードでのコネクトやプログラム実行にバグがありますね、、、(と思います、、、) RL78/G14 オンボードE2Liteデバッグでは、すんなり出来ましたので、画面コピー等取り直しているところです。

  • mark_n2さん、こんにちは。NoMaYです。

    設定箇所は以下の画面コピーの1枚目の場所です。また、ファームウェアのアップデートが行われて内蔵フラッシュメモリが部分的に書き換わっていても、デバッグしようとしている箇所が書き換わっていないのであれば、2枚目の画面コピーの設定を行うことでソースレベルデバッグも出来ます。なお、これらの場合は、ハードウェアブレークポイント(実行後ブレークポイント/After execution breakpoint)と呼ばれるブレークポイントが1箇所or2箇所だけ使えます。(数はマイコンによって異なりますが、ソフトウェアブレークの最大100箇所とは比較にならないほどに少ないです。) また、ハードウェアブレークポイントでは設定したドンピシャリの位置でブレークせずに、最後の9枚目の画面コピーのように少しズレてブレークします。

    ちなみに、RL78のオンチップデバッグでは、1枚目の画面コピーの設定箇所が [はい] の場合には、デバッグモニタプログラム等を内蔵フラッシュメモリに書き込む為にデバッガが適宜自動的に内蔵フラッシュメモリを書き換えることをしています。書き換える箇所は僅かですので、そういう設定にせずともコネクトするだけで良いのでは?、と仰るとおり言えなくもないのですが、用心して念のため、そういう設定にしておいた方が、状況を考え易くなりそうに思います。

    RL78デバッグ・ツール編 > ウインドウ・リファレンス > 説明 > プロパティ・パネル > [接続用設定]タブ
    tool-support.renesas.com/autoupdate/support/onlinehelp/ja-JP/csp/V8.06.00/CS+.chm/DebugTool-RL78.chm/Output/db_T_ConnectSettings.html

    (6) [フラッシュ]【E1】【E20】【EZ Emulator】【COM Port】
        フラッシュ書き換えに関する詳細情報の表示,および設定の変更を行います。

     

    フラッシュ書き換えを許可する    フラッシュ・メモリの書き換えを許可するか否かを選択します。
                                    デフォルト      はい
                                    変更方法        ドロップダウン・リストによる選択
                                    指定可能値      はい        フラッシュ・メモリの書き換えを許可します。
                                                    いいえ      フラッシュ・メモリの書き換えを許可しません。
                                                                デバッグ・ツールからフラッシュ・メモリ領域への書き換え操作は一切できなくなります。

     
    画面コピー



    デバッグしようとしている箇所が書き換わっていないのであればソースレベルデバッグも出来ます





    ハードウェアブレークポイントでは設定したドンピシャリの位置でブレークせずに少しズレてブレークします




     

  • NoMaY様

    ご確認いただきましてありがとうございます。
    ご教示いただいた方法で接続して、試してみます!

  • NoMaY様

    試すのが遅くなって申し訳ありません。
    書換えないモードでつないでみて、現象を再現してみたところ、スタートアップのアドレスがおかしくなっていることが分かりました。

    本来は0x100からスタートとなるはずが、更新後に書換えないモードで接続しリセットを掛けてみると、0x00D0に飛んでいて、そこには命令がないため止まってしまっていたようです。

    ハードウェアマニュアルでは「起動時のプログラム・カウンタは0x000/0x001のアドレス値が書かれる」となっていて、0x000には0xD0が確かに書かれてはいるようです。
    ただ、それならなぜ書き換える前はちゃんと動いたのかがよく分かりませんし、なぜ変な値が書き込まれるのかも疑問です。

    <正常時>

    <異常時>

    現象としては確認することができ、一歩前進なのですが、なぜこのような状態になったか謎です。
    何か思いつくことがありましたら、コメントいただければ幸いです。

  • mark_n2さん、こんにちは。NoMaYです。

    > なぜ書き換える前はちゃんと動いたのかがよく分かりませんし、なぜ変な値が書き込まれるのかも疑問です。

    画面コピーの異常時の状況というのは、RFPでブートローダを書き込んだものでは無いように見えますね。つまり、デバッガでブートローダをダウンロードした場合のものに見えます。

    ブートローダに限りませんが、RL78のオンチップデバッグでは、デバッガでプログラムをダウンロードした場合、デバッグモニタプログラムを内蔵フラッシュメモリの末尾の部分に書き込んだり、リセット番地を小細工して書き込んで、そのデバッグモニタプログラムへジャンプして行けるようにしたり、ということを行っています。通常、デバッグ時にはデバッグモニタプログラムが書き込まれているので、ユーザ見えには問題無くユーザプログラムが動作するのですが、今回の場合は、デバッガでブートローダの動作確認をした時、ブートローダが内蔵フラッシュメモリの内容を書き変えたタイミングで、内蔵フラッシュメモリの末尾のデバッグモニタプログラムが消去されていたのでは無いかと思うのです。そうなると、デバッグモニタプログラムが存在するものとして小細工されて内蔵フラッシュメモリに書き込まれていたものは、デバッグモニタプログラムが存在しないので動作しなくなります。

    それで、改めて最初の相談内容を読み返したのですが、デバッガを使用してブートローダの動作確認した後、RFPでブートローダを書き込んで(簡素な確認内容だったとしても何かしらの)動作確認をもう一度行った、ということが書かれていないことに気付きました。

    そうだったのであれば、RFPでブートローダを書き込んで、そうして期待したように動作するか試して頂けますか?また、そうだったので無ければ(RFPでブートローダを書き込んでいたのであれば)、その旨、リプライ頂けますか?

    [追記]

    ちなみに、デバッグモニタプログラムが存在していると、以下の画面コピーのようにデバッグモニタプログラムの中へ入って行きますね。(これはROMサイズが512KバイトのRL78/G14 Fast Prototyping Boardの例ですけれども。)




     

  • NoMaY様

    リプライありがとうございます。
    ご助言どおり、Renesas Flash Programmerで書いたら、問題なく動作しました。
    とりあえずうまくいったので、ひとまず解決です。本当にありがとうございました。

    今更ですが、デバッグ接続する際に、モニタプログラムか何かを埋め込んでいるのですね…
    その辺りからして、よく分かっていませんでした。

    ちょっと思ったのですが、CS+からはRFP同様に書き込むことってできないのでしょうか?
    最初にRFPで書いて、フラッシュ書換なしで接続すればいいだけなのですが、そこに面倒くささを感じただけですが…。
    それだと、デバッグ時にハードウェアブレークしか使えなくなり、ちょっとずれた場所で止まってしまうという状況になるのでしょうが、別のプログラムを書き込んでいるというのがちょっとモヤモヤしました。

  • mark_n2さん、こんにちは。NoMaYです。

    > 別のプログラムを書き込んでいるというのがちょっとモヤモヤしました。

    これは、デバッガ開発を柱のひとつにしている会社(SeggerとかP&E MicroとかLauterbachとか)の人達にとっては、猶更その思いが強いだろうなぁ、とか、実は私は思っていたりしますよ。こんなのはオンチップデバッグでは無い、こんなのはROMモニタデバッグだよね、と、きっと思われているに違いない(憤りすら感じられているかも)、と。

    でも、それも、ケチケチ設計のRL78らしさのひとつ、と言えばそうかも知れない、といったところかとも思います。

    逆に、ROMモニタデバッグであるがゆえに工夫されている点もあって、以下が出来るのはRL78ならではのこと、と思います。(出来た筈なのだけれど、、、)

    ● デバッガでユーザプログラムをGoさせている最中にターゲットシステム/マイコンの電源を一旦OFF→再度ONしても構わない

    もっとも、ただのちょっとした便利機能のひとつに過ぎないのでは?、と言われなくも無いですけど、、、

    私はと言えば、CS+自体にRFPと同じフラッシュ書き込み手順を実装するほどの必要性は無いかなぁ、とは思うのですけど、CS+にRFPプロジェクトと簡単に連携が出来てCS+のメニューから簡単にRFPを起動出来る、といったことなどは出来るようになっていると良いかなぁ、とは思ったりすることがありますね。(CS+の外部ツールメニューにRFPを登録してみたりとかゴソゴソやっていた時期もありました。)

  • NoMaY様

    そうですね、よく考えるとCS+で繋がるのはあくまでデバッグのためなので、別に同じである必要はないですね。
    コメントいただいて納得しました。

    デバッグがどのように実行されているのか、この機会に調べてみようと思います。

    ありがとうございました!

  • NoMaYさん

    D70116と申します。ルネサス中の人です。
    何時も書き込みありがとうございます。

    本スレッドで、
    「RL78/G23 COMPort通信デバッグは、内蔵フラッシュメモリを書き換えないモードでのコネクトやプログラム実行にバグがありますね、、、(と思います、、、) 」
    という書き込みをされていらっしゃいましたが、具体的にはどのような点が問題となりましたでしょうか。

    内容によっては、社内で見てみたいと考えております。
    お手数ですがよろしくお願いします。

  • D70116さん、こんにちは。NoMaYです。#V30ですね。

    どうもリプライありがとうございます。では、今日 or 明日ぐらいに書いて投稿します。その際、自分で起こしたRL78/G23 FPBのスレッドがありますので、そちらの方に書こうと思います。(また、書いた投稿のURLは、こちらのスレッドにも投稿してリンクを張るようにします。)

  • NoMaYさん
    ご返信ありがとうございます。

    お手数をお掛けいたしますが、よろしくお願いいたします。

    > #V30ですね。

    はい。その通りです。お気づきになられた通り、uPD70116 V30 から取っています。

  • D70116さん、こんにちは。NoMaYです。

    RL78/G23 COMPort通信デバッグで、内蔵フラッシュメモリを書き換えないモードでのコネクトやプログラム実行にバグがありますね、、、(と思います、、、)、についての詳細を以下に投稿しました。よろしくお願いします。

    RL78/G23 Fast Prototyping Boardを買いました
    japan.renesasrulz.com/cafe_rene/f/forum18/7087/rl78-g23-fast-prototyping-board/40250#40250