Top Page [◀◀] 2 3 4 5 6 7 8 9 ... [▶▶] Last Page
いつもお世話になっております。 Mきちです。
RL78/G14 CS+ for CA,CX を使っています。
先日ご教授いただいた資料をもとに、ブートプログラムによる書換の作成を始めました。
１）コード生成を使用して開発済みのプロジェクトに、ブート用のサブプロジェクトを追加
２）ブート側で実装したいシリアル通信やWDT機能のファイルをサブプロジェクトにも追加
３）r_cg_serial_user.c や r_cg_wdt_user.c などのファイルが両プロジェクトでダブったまま、とりあえずビルド実行
４）ブート側のビルドはOKですが、メインプロジェクトのビルドが始まると、当然シンボルがダブっているためエラー発生
この場合のお奨めの回避策を教えてください。
１）ファイルをコピーして、ファイル名と関数名をリネームする？
２）コンパイルスイッチで関数名を切り換える？
３）再リンク機能を使用して、ブート側で使用する機能もメイン側の関数を使用する？
メインプロジェクト側のコード生成を再度使用するならば、１）が良いのか？と考えていますが
工数がかかりそうなので、皆様のお奨めの回避策を教えてください。
Mきちさん、こんにちは。NoMaYです。直感的には、追加の選択肢として、以下が良いのではないかなぁ、と思うのですが、少し試してみます。４）再リンク機能を使用して、ブート/メインで重複するコード生成関数は、ブート側の関数を使用する？以下は以前に関わった「ブート-フラッシュ領域を分割したプロジェクトでのROM化」のプロジェクトを少し変更してコード生成したソースを追加してビルドしてみたところの画面コピーですが、当然ながら、シンボル重複エラーになりますね、、、(あと、モジュール重複エラーもありますね、、、)
Mきちさん、こんにちは。NoMaYです。以前に関わった「ブート-フラッシュ領域を分割したプロジェクトでのROM化」のプロジェクトを少し変更して、コード生成したソースを追加して、更にビルドエラーにならないようにしてみました。モジュール重複エラーやシンボル重複エラーにならないようにする為に、以下のようにしてみました。プロジェクトのファイル一式:issue_20190213.zip●ブート領域側(サブプロジェクト側): 赤文字の部分を追加r_main.c
/******************************************************************************Pragma directive******************************************************************************//* Start user code for pragma. Do not edit comment generated here */#pragma name boot_r_main#define main boot_main#define R_MAIN_UserInit boot_R_MAIN_UserInit/* End user code. Do not edit comment generated here */
r_systeminit.c
/******************************************************************************Pragma directive******************************************************************************//* Start user code for pragma. Do not edit comment generated here */#pragma name boot_r_systeminit#define R_Systeminit boot_R_Systeminit/* End user code. Do not edit comment generated here */
r_cg_serial.c
/******************************************************************************Pragma directive******************************************************************************//* Start user code for pragma. Do not edit comment generated here */#pragma name boot_r_cg_serial/* End user code. Do not edit comment generated here */
r_cg_serial_user.c
/******************************************************************************Pragma directive******************************************************************************/#pragma interrupt INTST0 r_uart0_interrupt_send#pragma interrupt INTSR0 r_uart0_interrupt_receive/* Start user code for pragma. Do not edit comment generated here */#pragma name boot_r_cg_serial_user/* End user code. Do not edit comment generated here */
●フラッシュ領域側(メインプロジェクト側): 赤字の部分を追加r_systeminit.c (なお、フラッシュ領域側の処理の初めでR_Systeminit()を実行しておく必要があります)
/******************************************************************************Pragma directive******************************************************************************//* Start user code for pragma. Do not edit comment generated here */#define R_CGC_Create R_CGC_Create_unused#define hdwinit hdwinit_unused/* End user code. Do not edit comment generated here */
void R_Systeminit(void){ PIOR0 = 0x00U; PIOR1 = 0x00U; R_CGC_Create(); R_SAU1_Create(); IAWCTL = 0x00U;}
void hdwinit(void){ DI(); R_Systeminit();}/* Start user code for adding. Do not edit comment generated here */void R_CGC_Create_unused(void){}/* End user code. Do not edit comment generated here */
r_cg_cgc.c
ビルドから除外
r_cg_cgc_user.c
以下、画面コピーです。[参考]以下、以前に関わった「ブート-フラッシュ領域を分割したプロジェクトでのROM化」にリプライした時の資料の画面コピーの再掲です。容易にフラッシュ領域側からブート領域側の関数と変数を使用することが出来ますので、両方の領域で必要になるコード生成関数は、ブート領域側でコード生成させ、フラッシュ領域側から呼び出すのが良さそうに思います。
Mきちさん、こんにちは。NoMaYです。もう1つ案が思い浮かびましたので、また少し試してみようと思います。概略は以下のような感じです。・ ブート側プロジェクトではコード生成しない。メイン側プロジェクトでのみコード生成する。・ その代わり、ブート側プロジェクトにはメイン側プロジェクトで生成したソースで必要なものを手作業で追加する・ 逆に、メイン側プロジェクトではブート側プロジェクトに追加したソースをビルドから除外する・ なお、コード生成したhdwinit()とR_Systeminit()は使わない(流用元ソースとして使うのみ)・ 上記のhdwinit()とR_Systeminit()を流用してブート側プロジェクトにboot_hdwinit()とboot_R_Systeminit()を手作業で追加する・ 上記のR_Systeminit()を流用してメイン側プロジェクトにapp_R_Systeminit()を手作業で追加する試してみてうまくいったら、またプロジェクトのファイル一式を投稿します。(駄目だったら、その旨を投稿します。)
Mきちさん、こんにちは。NoMaYです。先ほどの案を試してみました。そして、今ひとつだったかも、という点に気付きました。それは、以下のようなことです。・ 例えばUARTとかで、メイン側では2ch使用するけれども、ブート側では1chしか使わないとしても、2chまとめて1つのソース内にコード生成されるので、ブート側に2ch分のコードを置くことになってしまう。(コード生成されたコードなので将来的に変更することは無いと思うけれども。)以下、プロジェクトのファイル一式です。(なお、今朝のファイルもそうですが、ブート側の処理を終えてメイン側へ移るところとか、ブート側の割り込みエントリからメイン側の割り込み処理を呼ぶところとか、ぜんぜん入っていません。)プロジェクトのファイル一式:issue_20190214.zipまた、今回のプロジェクトでは、hdwinit()やR_Systeminit()などは以下のようなソースにしてみました。boot_main.c
void boot_main(void){ EI(); _rcopy(1); _rcopy(2); _rcopy(3); // TODO: Run boot code // TODO: Jump to appmain}void boot_R_Systeminit(void){ PIOR0 = 0x00U; PIOR1 = 0x00U; R_CGC_Get_ResetSource(); R_CGC_Create(); R_SAU0_Create(); R_WDT_Create(); IAWCTL = 0x00U;}void hdwinit(void){ DI(); boot_R_Systeminit();}
app_main.c
void main(void){ DI(); app_R_Systeminit(); EI(); // TODO: Run application code}void app_R_Systeminit(void){ R_SAU1_Create();}
以下、画面コピーです。
Mきちさん、こんにちは。NoMaYです。すみません、昨日の私の投稿で「ブート側の処理を終えてメイン側へ移るところとか、ブート側の割り込みエントリからメイン側の割り込み処理を呼ぶところとか、ぜんぜん入っていません。」と書いたのですが、以下のフォルダのCA78K0Rのランタイムライブラリ(スタートアップルーチンや割り込みベクタテーブル等を含む)のソースコードを見たところ、CA78K0Rのランタイムライブラリが全部面倒を見てくれているようです。フォルダ： CS+のインストールフォルダ\CACX\CA78K0R\V1.72\Src\cc78k0r\srcファイル：cstartb.asmcstartbn.asmcstarte.asmcstarten.asmvect00.asmvect04.asmvect06.asm...vect7c.asmvect7e.asmそれで、ソースコードを見ていて、自分の勘違いを1つ見付けてしまいました。昨日の夜の投稿では、ソースを以下のようにしていたのですが、ブート側でboot_main()からリターンすれば自動的にメイン側のスタートアップルーチンへ移るようになってました。(ちなみに、「ブート-フラッシュ領域の分割方法（R20UT3040JJ0100）」を見直すと、あっ、これがそういう意味であるのだな、という記載が見付りました。)昨日のソース(ちょっとコメントが不適切だった)
void boot_main(void){ EI(); _rcopy(1); _rcopy(2); _rcopy(3); // TODO: Run boot code // TODO: Jump to appmain}
コメントを修正したソース(コードの記述もちょっとだけ修正)
void boot_main(void){ EI(); _rcopy(1); _rcopy(2); _rcopy(3); // TODO: Run boot code // Return to boot's startup routine to jump to appmain's startup routine return;}
In reply to NoMaY:
In reply to Mきち:
Mきちさん、こんにちは。NoMaYです。エラーのdf1166a0.78kというのは78K0R/Kx3というマイコンのデバイス情報定義ファイルですね。ひょっとすると、CS+でFLASH側のプロジェクト設定を変更している際に、うっかり、変えてはいけない or 消してはいけない、そういう設定欄を触ってしまったのかも知れません。もし宜しければ(ソースファイル名がバレるとまずいということが無ければ)、FLASH側のmtpjファイルをzipファイルに圧縮してリプライに添付して頂けると、原因を調べ易いのですが、可能でしょうか？
Mきちさん
スレッドをちゃんと追えていませんけれども、もしかして情報です。f1166a0でピンときましたけれども品名違いのオブジェクトをリンクする際は、コンパイル時の-commonオプションで回避できたかと思います。
詳しくは以下のスレッドのやり取りを見ていただければ。https://renesasrulz.com/rl78/f/the-rl78-forum/5204/bootloader-code-size-questions/16406#16406"-cf1166a0 -common"とかやってました。
Mきちです。
皆様、回答ありがとうございます。
kirin様に教えていただいたスレッド。。。
すみません。日本語でも理解不十分な上に他言語では。。。（汗
作成中の処理を省いて空のプロジェクトを作成してみました。
NoMaY様からの添付プロジェクトの第2弾をもとにマイコンを R5F104FG に変更
その時に変更したディレクティブファイルを使用しています。
添付は初体験ですが、正しくできていますか？
ご指導のほど、よろしくお願いします。
RL78_FSL_test01_20190222.zip
Mきちさん、こんにちは。NoMaYです。どうやら、RAM領域に配置して実行するコードが存在しないのに「ROM化用オブジェクトファイルを出力する」設定になっていた、ことが引き金になっていたようです。CA78K0Rでは、恐らく歴史的事情から、「RAM領域に配置して実行するコードのコピー元データをROM領域に配置する」プロセスだけを特別に「ROM化プロセス」と呼んでいるようです。(初期値付変数の初期値をROM領域に配置することは、恐らく当たり前過ぎて、ROM化プロセスと呼ばないようです。)以下のzipファイはMきちさんのプロジェクトのファイルの内、ファイルを2つ変更したものです。(念の為、ビルド後のファイルを幾つかzipファイルに含めましたので、zipファイル内のファイル数自体はもっと多いです。)RL78_FSL_test01_20190222_to_M.zip変更ファイル及び変更点:RL78_FSL_test01.mtpj・フラッシュ領域側で共通オプションにて「よく使うオプション(ROM化プロセッサ)」→「ROM化用オブジェクトファイルを出力する」を「いいえ」に変更・ブート領域側も同様に変更(今回は単にフラッシュ領域側と整合させておきたかったという理由です)boot_map.dr・ブート領域側で「..\dr\boot_map.dr(12) : RA78K0R error E3116: Memory area 'FLASH' definition out of range」エラーが発生していたので12行目を「MEMORY FLASH : ( 002000H, 01E000H )」→「MEMORY FLASH : ( 002000H, 00E000H )」とした(今回はエラーになる理由までは調べませんでした)