RXシュミレータでの最小プログラムの作成について

はじめまして。

テレワーク対応として、既存プログラムをシミュレータで動かしたく思っています。

移行の第一歩として、

int a=0;
void main (void)
{
    a = a + 1;
    a = a + 1;
}

新規プロジェクトで上記だけ書いたプログラムをデバッグツールへダウンロードしたところ

「不正なメモリ・アクセスにより停止しました。」と表示されました。

初歩的なミスだと思うのですが、原因等ご教示いただけないでしょうか。。。

(また、見るべきマニュアルがあれば提示して頂けるとありがたいです。)

以下選択環境です。

・R5F563NBDxFC

・CC-RX(ビルドツール)

・RXシュミレータ

・PCからマイコンには繋げてないです。

  • 太郎さん、こんにちは。NoMaYと申します。

    使われているのは、CS+でしょうか、e2 studioでしょうか?あと、既存プログラムをシミュレータで動かしたいとのことですが、どのようなプログラムでしょうか?ルネサスさんはRXシミュレータの他にRL78シミュレータも提供しているのですが、両者で出来ることには大きな違いがありまして、RL78シミュレータに関するニュースやブログからの情報はRXシミュレータに殆ど当てはまらず参考にならなかったりします。具体的には、マイコンの内蔵周辺を扱うプログラムはRXシミュレータでは動かないのです、、、ですので、念の為、なのですけど、、、

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

    CS+を使用しています。

    PDG2を使用し、汎用ポートやIO、SCI、TPU等でシーケンサーやモーター等を動かすプログラムです。

    (「どのようなプログラム?」の回答になっているでしょうか。。。)

    古いソフトかつ、有識者も身近に居ないのでその箇所は諦め、模擬動作するプログラムを作ろうかと考えていました。。。

  • チョコです。

    RXは使ったことはありませんが、main関数の実行が終わったらどうなるのでしょうか?

    RL78ではmain関数を呼び出したスタートアップルーチンに戻りますが。

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

    組込プログラムの初歩が理解できていなかったようです。

    main関数に辿り着けていない状態でした。スタートアップルーチンの設定・記述が必要だったのですね。

    チョコさんのお話からウェブ検索し、手持ちのプログラム内をみたところ、FITというフォルダがありました。

    (だからサンプルソースにあるようなスタートアップルーチンの記載が、主ロジックに記載されていなかったのですね)

    前任者はスマート・コンフィグレータを使用していた?のですかね。。。導入できるか試してみます。

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

    あぁっ、すみません、RX63N,631ではRXスマートコンフィグレータは使えないのです。あと、もう少し知りたいのですが、テレワークとして何が出来るか、の前に、そのテレワークの話の元々の仕事のゴールは、どのようなものなのですか?例えば、モータ制御の効率向上とか、別の(或いは新世代)モータへの対応とか、シーケンサの操作性向上とか、、、(あぁっ、でもどうかな、お尋ねしてどうなるものでもないかなぁ、、、)

    その、何と言うか、たぶん、ほどなくして、出来ないことだらけ、であることに気付いてしまうと思うのです。以下のような場合には良いのですが、

    ・ルネサスさんの開発環境を手軽に触る第一歩として、とか、、、
    ・開発環境なんてCS+とかe2 studioとかひとつでお腹いっぱいでそれ以上もう受け付けられない、とか
    ・(内蔵周辺と無関係な)プログラムの動作をルネサスさんのコンパイラ(or GNU, IAR)の生成コードで動作確認したい、とか
    ・(内蔵周辺と無関係なプログラムであるが)プログラムにアセンブリ言語コードが含まれている、とか
    ・(内蔵周辺と...略...)プログラムの動きをトレース機能とかを使って調べたい、とか

    もしVisual StudioのCコンパイラが既に使えるようになっているなら、

    ・これって(苦労してやったことは)Visual StudioのCコンパイラでサクっと確認出来たんじゃね?

    みたいな顛末になる可能性も少なくないかなぁ、と私は思っていたりするからです。

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

    >>あぁっ、すみません、RX63N,631ではRXスマートコンフィグレータは使えないのです。
    今ちょうど、動かしてみてそこに行き当たったところでした(笑)
    FITフォルダが既存プログラムに存在する +  生成された風の見た目の「rx63n」フォルダと中身があるので、開発当時は対応してたんですねきっと。。。

    >>テレワークの話の元々の仕事のゴール
    月1回ほど、保守のお仕事(内蔵周辺とは無関係な微改造)が入ってくるので、その対応をしたい状態です。
    ・通信で出力している文字の内容変更
    ・IO出力番号の変更
    ・処理内繰り返しの変更 等

    現状Visual Studioでは動作させられない状態です。(おそらくインポートのパスやCS+内定義の物を使用している等)
    ソースコード量が多く、CS+内でそのままある程度動作させられればと考えていたのですが
    Visual Studioで動作させれるように、インターフェースを外だしする方が楽ですかね。。。

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

    以前のRX63N,631に関しては、以下のようになっていました。(最近のFITでは、デバイス自体がサポート対象から外れています。)

    (1) e2 studioではFIT ConfiguratorというFIT組み込みGUIがありました。
    (2) CS+では手作業で組み込むことになっていました。(そういう手引書が出ていました。)

    それで、繰り返しになりますけれど、RXシミュレータでは内蔵周辺機能が動作しませんので(正確にはCMTとINTの一部やMPU(メモリプロテクションユニット)は動作します)、「そのままある程度動作させられれば」というのは目論見通りに行かないと思うのです。(また、内蔵周辺機能が動作したとしても、多くの場合で、マイコンと外部回路/外部機器との間のやり取り(High/Lowのやり取りや通信のコマンド送信/リプライ受信など)が必要だったりしますので、依然、なかなか難しいことだと思います。)

    おそらく、シミュレータの実行が、太郎さんの改造箇所に到達する、ようになるには、既存のソースのかなりのif文/while文をコメントアウトなり#if 0~#endifなり条件の変更なりをする必要があるかと思うのです。加えて既存のソースのかなりの関数呼び出しにおいて同様な処置をすることにもなるかと思います。

    そうこうしているうちに、いっそmain()から直接改造箇所(や一~二階層上の箇所)を呼んで改造箇所の大まかなデバッグだけ済ませる、ことが現実的なんじゃないのかな、という話になって来そうな気がするのです。

    それから、Visual StudioのCコンパイラを使うといっても、「そのままある程度動作させられれば」というのはまったくもって無理です。RXシミュレータを使っても改造箇所の直近部分しか確認出来ないので、そうであればVisual StudioのCコンパイラでも出来たよね、ということになりそうな気がする、という意味でした。

    ただ、テレワークで、少しでも動く確度の高いコードにしておきたい?ということで、RXシミュレータより現実味がありそうなこととして思い浮かんだのですが、RX63N,631に関してはGR-SAKURAという比較的安価なボードが出ていますので、それとE2 Liteエミュレータを繋いで(多少半田付けなりが必要らしいです)、通信部分ぐらいでも「文字列が送れた」ことまでは確認出来るかも知れないです。(既存のソースから、必要部分だけ抜き出す方がやりやすいか、不要箇所を#if 0~#endifで除く方が現実的か(そして除く箇所は一体どこまで減らせるか、とか)、そこは分からないですけれど。)

    [追記]

    でも、文章で書いても分からない、ですよね。たぶん、既存のソースをそのままCS+でビルドして、素朴にRXシミュレータにダウンロードして、とすると、いきなり実行状態のままになって、困惑すると思うのです。そこで、実行中断ボタンを押すと、スタートアップルーチンの中で何かの内蔵周辺レジスタを読んでチェックしているwhile文で止まっていると思うのです。

    そして、そのwhile文をスキップするように暫定的に書き換えても、Reset&Go(リスタート)ボタンを押すと、それとは別のwhile文でまた止まっていて、何箇所か書き換えた後、ようやくmain()の先頭に来るようになる、筈だと思います。

    とりあえず、そこまでやってみると、文章で書いたことが何となく分かって貰えるかな、と思ったのでした。

  • NoMaYさん、太郎さん

    こんにちは、シェルティです。ルネサスの中の人です。

    マイコンのソフト開発のリモートワーク対応、興味深い話題ですね。

    太郎さん向けの情報としては、NoMaYさんも仰る通りひとまずはRX63Nの廉価なボードを買ってきて実機でデバッグするのが良い、ということでしょうかね。もしマイコンがRX65Nでもよければ、エミュレータがオンボードになったタイプで安く買えるRX65N Target Boardがおすすめです。

    https://www.renesas.com/jp/ja/products/microcontrollers-microprocessors/rx-32-bit-performance-efficiency-mcus/rtk5rx65n0c00000br-target-board-rx65n

    ルネサスもリモートワークが進みました。シェルティは1か月に1回くらいしか出社する機会がありません。社内のソフト開発体制もこの2年くらいで劇的に変革させました。GitLabというDevOps向けのツールを使ってRX Driver Package等のソフトウェアのテストを定常的に実行させておき遠隔地からモニタ出来る仕組みを構築したり、少し専門的な話になりますが統合開発環境e2 studioを開発者の自宅で起動、e2 studio内部のGDBというデバッグを司る部分のクライアント側をインターネット経由でルネサスの事務所のGDBのサーバ側にTCP/IP接続、そのGDBサーバにマイコンボードを繋いでおき、開発者がルネサスに出社しなくても、ルネサスの事務所に置いてあるマイコンボードで実機デバッグできる環境を構築したりなど、リモートワークをきっかけに一気にネットワーク経由で設計を完結させる取り組みが進みました。

    このあたり「組み込みシステムのDevOps/リモートワーク推進方法」としてアプリノート化を考えています。特にGitLabは組み込みシステムに関わらずソフトウェア開発全般に対して劇的に生産性をあげてくれる非常に良いDevOpsツールと考えております。#偉そうに言ってますが、GitLabはルネサスアメリカのソフト開発チームから教えてもらいました。

    太郎さんにおいてもさまざまな形でリモートワークを効率化するためのアイデアが身近にあると思いますので多角的な面からシステム構成を検討されると良いかと思います。

    NoMaYさん向けの情報としては、シミュレータでFITを動かした際にBSPのクロック設定部分で止まってしまうというのが課題、ということですよね。BSPが「自分がシミュレータで動いている」と検知できればifdefでコードを分けておけばシミュレータでもmain()まで到達して何かしら(CMTなどは動かせないにして)CPU動作のシミュレーションはできると思いました。何かこの検知する手段がないか社内を嗅ぎまわってみます。

    以上です

  • シェルティさん、こんにちは。NoMaYです。

    > シミュレータでFITを動かした際にBSPのクロック設定部分で止まってしまうというのが課題

    一応、起動までは現実的策を実用化させました。(たぶん、以前に投稿しているような気がします。そして、以前の投稿の発展系で、GitHubの私のリポジトリのRX72N Renesas RX SimulatorによるFreeRTOS Demo、でも使っています。) BSPのソース上は無変更です。トリッキーな#defineマクロを作りました。もっとも、細工をするという点では不便なことに変わりが無いので、もちろん、より一層使い易くなるのが良い、と思います。

    ただ、太郎さんの場合は、たとえ、main()の先頭に辿り着いても、その先でもまだまだいろいろな内蔵周辺レジスタで同様のことになるのが大変ですね。(なぜならRXシミュレータでは内蔵周辺機能が動作しません、というかそもそもRL78シミュレータのようにそういう使い方までを意図してはいないものだからですね。)

  • NoMaYさん、シェルティさん、こんにちは。太郎です。

    >>以前のRX63N,631に関しては~
    なるほど、やはり。納得できました。

    >>でも、文章で書いても分からない、ですよね。
    いえ、イメージはつきました。
    とても丁寧に書いていただいてるので分かりやすいです。ありがとうございます。

    地道な#ifdefが必要なのは前提で、会社から時間は結構もらえました。


    【GR-SAKURA / RX65N Target Board 】
    実ボードを買うのが良さそうですね。情報ありがとうございます。
    エミュレーターも1台しかないので、RX65N Target Boardを購入し、
    N63とN65の差異部分を吸収できるよう、リモートワーク用のソースコードを書いてみます。
    (特徴欄に「e2 studio使用可能」のみ書いてありますが、
     NoMaYさんの3年前投稿のツリーを見るにCS+でも行けそうですね。重ねて感謝します。)


    シェルティさん
    返信ありがとうございます。

    >>社内のソフト開発体制もこの2年くらいで劇的に変革させました。
    スケールが大きくとても面白いですね!
    確かに、固定観念を捨てて冷静に考えれば私の状況でも他にも手は考えられそうですね。
    会社に動作用の1台PC置いておいて、リモートデスクトップで画面だけ持ってくるとか。
    (開発者分の台数が必要 + コンプラ/セキュリティ等の問題は別途あるかもですが)

    以上です。

  • 太郎さん

    こんにちは、シェルティです。

    DevOps本当に面白いですね。少し前にNoMaYさんと一緒に開発したAmazon FreeRTOSのRXマイコンへの移植開発と同じくらい面白いテーマです。シェルティの環境でも単なるリモートデスクトップも実現したく、SSHポートで待ち受けを行うRaspberry Piを事務所に置いておき、Raspberry Pi上でポートフォワードして事務所内のリモートデスクトップに接続できるようにしてます。こうすることで社外にはセキュリティポリシーで許容する外部接続ポート(SSH)のみ使用していることになりますし、Raspberry Piのログインパスワードを知っている適切なメンバのみがリモートデスクトップが使えるようになります。またRaspberry Piが危険な状態になったときに強制終了できるようにリモートで電源OFFできるアダプタみたいなのを買ってきてGitLab経由でRaspberry Piを強制電源OFFしたりできるようにしました。既存のルールを守ることも大事なのでIT部門のメンバともよく会話して適切なシステム構築をしていく必要がありますね。GitHubへのソースコード流出事件みたいなことを起こさないよう開発メンバに対する啓蒙活動も重要ですね。

    DevOpsについてはダイキン殿の以下解説記事の上の方にある動画がものすごく参考になりました。

    https://techplay.jp/column/1501

    以上です

  • 少し話がずれますが、マイコンのソフト開発のリモートワーク対応で重要なことは、CS+も、エミュレーターも、PCも高価だということです。10人のプログラマーが職場に10セットのコンパイラとシミュレータが基本ですが、テレワークだと20セットになります。10台のノートPCで10セットの開発環境はPCそのものが高価で紛失などのリスクもあります。できれば、自宅のやオフィースの安価なデスクトップPCからテキストエディターでテストベクターとコードを書いて職場に用意した強力なコンピュータの1セットのコンパイラとシミュレータでバッチで起動できると良いです。漫才ではないですが、「コマンドプロンプトに時を戻そう」です。

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

    別スレッドを立ててみてはどうでしょう。(私が立ててもよいのですけれども。)

    [追記]

    私がスレッドを立てるならこんなタイトルの感じかな、と頭に思い浮かびました。

    「テレワークで組み込みソフトウェア開発をお金を掛けずに楽ちんにやる方法は何でしょうか?」

  • 太郎さん

    ご参考までに
    自分は、CS+/e2 studioのシミュレータは使わずに動かせるものをつくりました。
    マイコンのアドレスを適当なアドレスに置き換えて
    タイマーはWindowsのタイマーに置き換えて
    割り込みはマルチスレッドで再現して...
    かなり苦労しましたが、疑似的な通信(対向とのコマンドのやり取り)もできるようになりました。
    MinGWでビルドした、普通のWindowsアプリケーションです。

    周辺機能が使えないのが不便ですよね。
    使えても、シリアルの入力が面倒だったりで
    シミュレータでテストの自動化ができればと思ったけれど難しそうで
    上記のようになりました。

  • testさん、こんにちは

    返信ありがとうございます。
    だいぶ・・・苦労しそうですね・・・。
    こちらも、30年物のプログラムなので根気よく対応しようと思います。