初めて投稿させて頂きます。前順と申します。
現在、RX111マイコン搭載基板でファームウェア開発を行っているのですが、
マイコンをリセットするたびにRTCが約0.5秒程度ずつ遅れていく症状に悩まされています。
RTCの時計カウンタに関わる制御は、
main()関数の先頭で次のレジスタ設定を行っているのみです。
/* Enable ALM interrupt */
IEN(RTC, ALM) = 1U;
/* Enable PRD interrupt */
IEN(RTC, PRD) = 1U;
/* Set the START bit to 1 */
RTC.RCR2.BIT.START = 1U;
RX111のユーザーズマニュアルハードウェア編 [23.2レジスタの説明]には、
「カウント動作時（RCR2.START ビット =“1” のとき）にリセット状態または低消費電力状態
へ遷移した場合、年 / 月 / 曜日 / 日 / 時 / 分 / 秒 /64Hz カウンタは動作を継続します。」
とあり、リセットの度に約0.5秒程度ずつ遅れていくのは正常ではないと考えています。
開発中のボードでは32.768Hzのサブクロックを搭載しており、
同じく32.768Hzサブクロックを搭載した某社製RX111評価ボードでも
同様の症状が発生することを確認しました。
サブクロックの波形を観察していると、どちらのボードでも
RX111マイコンをリセットしたのち、タイミングは失念しましたが、
ユーザプログラムmain()に制御が移るまでの間に乱れが発生していました。
この症状の原因と対処につきまして、何か情報はございますでしょうか？
なおRTCの制御に際し、 [23.5.5 レジスタの書き込み/読み出し時の注意事項]には従っているつもりです。
よろしくお願いします。
RX111のRTCのデータシート説明は誤記修正が出ていますが、修正後の資料で作成されましたか？www.renesas.com/.../rx110-group-rx111-group-errata-users-manual-hardware-regarding-realtime-clock-rtc-0
Shoji Yamamoto様、リプライありがとうございます。
はい、リンク頂きましたテクニカルアップデートには目を通しましたが、
症状の原因・対策を見つけるには至っていません。
なお、最初の投稿で、
＞main()関数の先頭で次のレジスタ設定を行っているのみです。
と記載しましたが、これはスマートコンフィグレータで
生成されたコードを呼び出しており、正確にはこの後に
RTC.RCR2.BIT.STARTの値が1に変わるのを待ってから
次の処理を行っています。
スマートコンフィグレータを使っているということはコンポーネントのリアルタイムクロックを使っていて起こる症状でしょうか？それとも使わずに起こっているのでしょうか？
Shoji Yamamoto様、お世話になっております。
はい、コード生成されるConfig_RTCのコンポーネントを使用しています。
そして、症状の方ですが、リファレンスにしていますRX111評価ボードメーカ様に
サポート頂き解消の目途が立ちました。
原因は、コード生成されたR_Config_RTC_Create()の中で
時計カウンタを停止してのレジスタ制御がリセットの度に実行されているためでした。
そのこと自体は生成されたコードを読んで理解していたのですが、
それが大きな遅れの原因になっているとは、指摘されるまでは疑っていませんでした。
対策としては、R_Config_RTC_Create()を自動実行されないようにして、
必要な初期化処理を時計カウンタ停止の影響を極力抑えるように書くことにします。
ありがとうございました。
電源を通電した時のみ初期化するように分岐を作ればいいのではないかと思います。RXマイコンでRTCを使ったことないですが、RTCが動作状態かチェック、もしくは、リセット要因の解析で切り分けできると思います。www.renesas.com/.../rx-family-changes-reset-status-registers-when-resets-occur
Shoji Yamamoto様、ありがとうございます。
はい、御指南通りの方策で対策できることを確認しました。