NXPチームの皆様、こんにちは。
私はS32K312 Cortex-M7を使い、S32 Design StudioとAUTOSAR RTD 7.0.1 / AUTOSAR 4.9を使って作業しています。
現在、MC_RGMのリセット動作、特にSWT0機能リセット、機能リセットエスカレーション、破壊的リセット、SRAM保持、SBAF/リカバリ動作、およびPower IPリセットAPIのテストを行っています。
1. SWT0機能リセットエスカレーション
私はSWT0タイムアウトを使用して機能リセットを生成しています。
私のMC_RGMの設定は以下のとおりです。
MC_RGM_FRET_FRET((uint32)15U)
MC_RGM_DRET_DRET((uint32)0U)
機能リセットカウンタが増加していることを確認しました。
SWT0機能リセット#1 -> FREC = 1
SWT0機能リセット#2 -> FREC = 2
...
SWT0機能リセット#14 -> FREC = 14
次のSWT0リセット後、FRECはクリア/リセットされますが、期待される動作は確認できませんでした。
DES[MC_RGM_FRE] = 1
私の質問は以下のとおりです。
- SWT0_RSTは、S32K312のMC_RGM機能リセットエスカレーションカウンタ（FREC）に参加しますか？
- FRECがFRET=15に達したとき、MC_RGM_FREを生成し、DES[MC_RGM_FRE]を設定すべきでしょうか？
- エスカレーション直後、FES、DES、FREC、FRET、Power_Ip_GetResetReason() には具体的にどのような値が期待できるでしょうか？
- SWT0がFRETエスカレーションに参加するために、追加の設定は必要ですか？
- SBAFやリカバリーハンドリングはFRETのエスカレーションに支障をきたすことはありますか?
- SWT0/FRETの上昇に関連する既知の不具合やS32K312の挙動はありますか？
- アプリケーションを継続的に実行すると、15回目の機能リセット後にアプリケーションやデバッガが停止し、期待される破壊的なリセットを観察できません。これがリセットシーケンス、SBAFリカバリ、またはデバッガに関連しているかどうかを知りたいです。
2.すべてのSWT0機能リセットを破壊的なものにしたい
テスト目的で、以下のことも達成したいと考えています。
SWT0タイムアウト
↓
機能リセット
↓
即時破壊リセット
15回も機能リセットを待つ代わりに。
以下の設定で実現できますか:
FRET = 1U;
具体的には：
- FRET = 1 の場合、最初の適格な SWT0 機能リセットが破壊的なリセットにエスカレートしますか？
- MC_RGMの追加設定は必要ですか？
- SWT0は、このエスカレーションの対象となる情報源として確実に認められるのでしょうか？
- SBAFや回復行動はこれに影響を与えるのでしょうか?
- これはRTD 7.0.1の設定で直接サポートされていますか？
3. SRAMデータは、機能リセットのたびに消去されます。
私の理解では、S32K3xxリファレンスマニュアルでは、SRAMやシステムメモリは機能リセット後も保持されるべきです。
SRAMテスト変数を作成しました。
#define SRAM_TEST_ADDR ((volatile uint32_t *)0x204007d4U)
そして、それを使って機能リセット後のデータ保持状況を確認する。
しかし、機能リセット後にSRAMデータが消去/ゼロに書き換えられていることを確認しました。
私の質問は以下のとおりです。
- 機能リセットの際にハードウェアがSRAMを保持し、その後ソフトウェアによって上書きされるのでしょうか?
- S32K312において、機能リセット後も内容が確実に保持されるSRAM領域はどれですか？
- 関数リセットを通じてその内容を保持するために、SRAMに変数を配置する推奨される方法は何ですか?
- 専用の.noinitファイルを使うべきでしょうか？または、保持されたSRAMセクション？
- データ保持に必要なMC_RGM/SRAMの特定の構成はありますか？
- 機能リセット間でアプリケーションデータを保持するための推奨されるRTD 7.0.1の方法は何ですか?
4. 直接ソフトウェア破壊的リセット
また、Power IPを使って直接的なソフトウェア破壊リセットもテストしています:
Power_Ip_Init(&Power_Ip_HwIPsConfigPB);
gVar= Power_Ip_GetResetReason();
for (count = 0; count < 10125000; count++);
Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB);
現在のMC_RGM構成には以下が含まれます。
static const Power_Ip_MC_RGM_ConfigType Power_Ip_MC_RGM_ConfigPB =
ヤージュ
(MCU_DEST_RESET)
...
MC_RGM_FRET_FRET((uint32)15U)
MC_RGM_DRET_DRET((uint32)0U)
};
破壊的なリセットが発生するが、デバッガーは通信を繰り返し失い、再確立する。
次のようなメッセージを見かけます。
情報: DAP IDCODE = 0x6BA02477
情報：DAPの電源投入に成功しました。DP CTRL/STAT = 0xF0000000
複数回繰り返され、続いて次のもの：
割り込みコマンドを受信しました。執行を停止します。
理解したいのは以下の点です。
- 破壊的なリセット中に、DAPの再接続が繰り返し発生することは想定されていますか？
- 破壊リセットシーケンス中にCortex-M7に具体的に何が起こるのでしょうか?
- 破壊的なリセット後、CPUはいつ再び使用可能になりますか？
- 単一のソフトウェア破壊リセットをデバッグする推奨される方法は何ですか?
5. Power_Ip_PerformReset() 前のブレークポイント挙動
直前にブレークポイントを確実に到達することはできません:
Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB);
APIの前に遅延を設定し、デバッガがアクセスを得るのに十分な時間があると期待していました。
場合によっては、ターゲットを手動で一時停止してから実行を再開した後に初めてブレークポイントに到達することがあります。
理解したいのは以下の点です。
- リセットAPIの前に遅延があるのに、なぜデバッガはブレークポイントを見逃すのでしょうか?
- これは、ターゲットが繰り返しリセットされ、デバッガーがDAP経由で再接続されることに関係していますか？
- 破壊的なリセットの直前や直後にCPUをキャッチする推奨される方法はありますか?
- RTDのDISABLE_DEBUGGER_TRAPオプションはこの動作に関係していますか？
6. Power IPの初期化とPower_Ip_SetMode()
私のRTDは以下を提供します：
void Power_Ip_Init(
const Power_Ip_HwIPsConfigType *HwIPsConfigPtr);
void Power_Ip_SetMode(const Power_Ip_ModeConfigType *ModeConfigPtr);
void Power_Ip_PerformReset(
const Power_Ip_HwIPsConfigType *HwIPsConfigPtr
);
Power_Ip_ResetType Power_Ip_GetResetReason(void);
Power_Ip_RawResetType Power_Ip_GetResetRawValue(void);
現在使用しているもの：
Power_Ip_Init(&Power_Ip_HwIPsConfigPB);
そして：
gVar = Power_Ip_GetResetReason();
私のモード設定はPOWER_IP_RUN_MODEです。
以下の点についてご説明をお願いします。
- Power IPリセットAPIを使用する前に、Power_Ip_Init(&Power_Ip_HwIPsConfigPB)は正しい初期化方法でしょうか？
- ソフトウェアの機能的/破壊的リセットテストにはPower_Ip_SetMode()が必要ですか?
- 選択したモードがPOWER_IP_RUN_MODEなら、このリセットテストでPower_Ip_SetMode()を省略してもいいですか?
- RTD 7.0.1を使って、ソフトウェアの機能リセットとソフトウェア破壊リセットの設定をどうすればよいですか?
環境
MCU:S32K312
コア:Cortex-M7
S32DS:S32 Design Studio
AUTOSAR:4.9
RTD: 7.0.1
リセット元: SWT0
フレット: 15
DRET: 0
試験用の申請書を全部ご用意できます、Power_Ip_PBcfg.c。リンカー構成、MC_RGMレジスタキャプチャ、および必要に応じてデバッガーログ。
よろしくお願いします。
こんにちは、 @Sharif417 さん。
1. SWT0機能リセットエスカレーション
SWT0_RSTdoes S32K312 FRECに参加し、FRECが15に達するとDES[MC_RGM_FRE]が設定されます。Power_Ip_GetResetReason()を呼び出して「MCU_MC_RGM_FRE_RESET」を返すことで読み取れるはずです。
降格されていない機能リセット源(MCRGM.を通じて)はFERD は FREC のインクリメンションの対象となります。
Power_Ip_Init()はMC_RGMをクリアするので覚えておいてください。DES(値を保存した後)なので、電源モジュールを初期化する前にレジスタ値を取得するか、リセット理由を読み込むようにしてください。
回復モードは、閾値が>8の場合、回復モードがデフォルトで「8」に設定されているため、これに影響を与える可能性があります。sBAFはFRETではなくDRETにも干渉することがあります .「0」の場合、0xFに変わるのがわかります:
アプリケーションを継続的に実行すると、15回目の機能リセット後にアプリケーションやデバッガが停止し、期待される破壊的なリセットを観察できません。これがリセットシーケンス、SBAF復旧、またはデバッガに関連しているのか知りたいです。
デバッガを接続したままにしようとする代わりに、15回目の機能リセット後に接続を試みるか、UARTなどでリセット理由を印刷してみることはできますか?
2. すべてのSWT0機能リセットを破壊的なものにしたい
- はい、FRET=1であれば、すべての機能リセットで破壊リセットを発行するのに十分です。
- 追加のMC_RGMは不要です。
- sBAF/リカバリーモードはこれに影響を与えないはずです。
- はい、POWER モジュール -> 「モジュール設定」 -> 「McuResetConfig」 -> 「機能リセットエスカレーション閾値」で直接設定できます
3. SRAMデータは、機能リセットのたびに消去されます。
- その通りです。SRAMは機能リセット後も保持されます。
- S32K3は、派生モデルによって、スタンバイRAMとして16KB、32KB、または最大64KBを提供する場合があります。
- スタンバイRAMを通じて変数を配置・使用する方法の例をいくつか見つけることができます:
スタンバイRAMがクリア/書き換えられる理由は、デフォルトのstartup_cm7.sによるものです。S32DSによって提供される機能は、リセット理由（POR、破壊的、機能的）に関係なく、SRAM全体を初期化します。機能リセットが発生した際に、割り当てられたスタンバイRAMをSRAMの初期化がスキップするように修正する必要があります。以下のコミュニティ投稿を参照してください: S32K311 スタンバイ RAM 保持。
4. 直接ソフトウェア破壊的リセット
- はい、MCUが機能的/破壊的リセットを発行されると、デバッグサブシステムとクロックはすべて再初期化されるため、デバッガは再びDAPアクセスを再交渉しなければなりません。
- 破壊的なリセットを行うと、一部のモジュールを除いて、チップの大部分がリセットされます。機能リセットを行うと、すべての通信ペリフェラルやコアがリセットされます。通信プロトコルの健全性は保証されておらず、リセット後に再初期化されることが前提とされています。
- 接続を維持しようとする代わりに、デバッガの「ターゲットにアタッチ」オプションを使うことができます:
5. Power_Ip_PerformReset() 前のブレークポイントの動作
- おそらく再接続のウィンドウを見落としているだけです。for()ループを使う代わりに、フラグはデバッガで再接続した後に手動で変更する変数であるwhile(flag)を使い、「Expressions」タブから使うことができます。
6. Power IPの初期化とPower_Ip_SetMode()
- はい、Power APIを使用する前にPower_Ip_Init()を呼び出す必要があります。
- そうすることをお勧めします。リセットはPower_Ip_PerformReset()を通じて行うことができますが、破壊的リセットか機能リセットのどちらかをMcuResetConfigコンテナ内で設定できます。代わりに、機能リセット用と破壊リセット用2つのパワーモードを宣言できます。次に、Power_Ip_SetMode(Functional_Reset) または Power_Ip_SetMode(Destructive_Reset) を呼び出します。
- 省略しても構いませんが、すべてのモジュールが正しくゲート化・設定されているか確認するためにPower_Ip_SetMode(RUN_MODE)を呼び出すと良いでしょう。もしプロジェクトに不要であれば省略しても構いません。
- A6.2を参照してください。
簡単なテストを作成し、FRET=1を設定し、Power_Ip_SetMode( ) APIを通じて機能リセットを行うと報告FRE_RESET確認できました:
よろしくお願いします、
ジュリアン
こんにちは、ジュリアンさん。
ご説明いただきありがとうございます。
S32K312で再度テストを行ったので、2つの点について明確にしておきたいと思います。完全なプロジェクトフォルダを添付しておきますので、設定を確認して動作を再現できます。
1. SWT0機能リセットエスカレーション
設定しました：
FRET = 15U;DRET = 0U;
そして、 125ミリ秒のタイムアウトを設定したSWT0を使用して、機能リセットを生成します。
機能リセットのたびに FREC が増加しているのが観察できます:
SWT0 reset #1 -> FREC = 1
SWT0 reset #2 -> FREC = 2
...
SWT0 reset #14 -> FREC = 14しかし、次のSWT0機能リセットが発生し、 FRET = 15の閾値に達したときに、期待される破壊的リセット状態を観察することができません。
DES[MC_RGM_FRE] = 1また、15回目の機能リセット後もMCUは動作を続け、予想される破壊的なリセット動作は見られません。私のSRAMテストパーティションに保存されているSRAMデータも、そのままの状態を保っています。
以下の方法でリカバリ動作を無効にしました。
IP_DCM_GPR->DCMRWP1 |= (3 << 22);
添付のプロジェクトを確認して、もう少し詳しく教えていただけますか:
- 15回目のSWT0機能リセット後、 DES[MC_RGM_FRE] = 1が観測されないのはなぜですか？
- FRECがFRET = 15に達した後、MCUは確実に破壊的なリセットに入るべきでしょうか?破壊的なリセットが発生した場合、なぜテストパーティションにSRAMの内容が保持されるのでしょうか？
- 他にMC_RGM/SBAFの設定で見落としているものはありますか？
2. 機能リセットおよび破壊リセット後のSRAM保持
専用のSRAMパーティション／セクションを作成し、その領域にテストデータを保存しました。
SWT0機能リセットを繰り返してもSRAMの値が保持されることを確認しました。これは想定どおりです。
しかし、FRETエスカレーションによって破壊的なリセットが発生すると予想される15回目の機能リセット後でも、SRAMの値は依然として残っています。
また、直接的なソフトウェア破壊リセットも試しましたが、リセット後もSRAM値は保持されていました。
したがって、私の見解は以下のとおりです。
SWT0 functional reset
↓
SRAM value retained
15th functional reset / expected FRET escalation
↓
SRAM value still retained
Direct software destructive reset
↓
SRAM value also retainedこのSRAMの挙動がS32K312上で予想されるものなのか、また私のSRAMテスト領域が破壊的なリセットを経ても保持されるメモリ領域にある可能性があるのか、教えていただけますか?
リンカー構成、RTD構成、MC_RGM構成、SWT0構成、テストアプリケーションを含む S32K312プロジェクトフォルダ全体を添付していますので、実際のメモリ配置とリセット設定を確認できます。
再開まで今しばらくお待ちください。
こんにちは、 @Sharif417 さん。
1. SWT0機能リセットエスカレーション
1. 15回目のSWT0機能リセット後、DES[MC_RGM_FRE] = 1が観測されないのはなぜですか？
前述したように、Power_Ip_Init() APIはDESレジスタをクリアするため、リセット理由はPower_Ip_GetResetReason()を使用して読み取る必要があります。
2. FRECがFRET = 15に達した後、MCUは確実に破壊リセットに入るべきか?破壊的なリセットが発生した場合、なぜテストパーティションにSRAMの内容が保持されるのでしょうか？
はい。FRECがFRTで設定された閾値に達している限り、MCUは破壊的なリセットを発行すべきです。破壊的なリセットが行われていないか、変数の位置が間違っているかのどちらかです。
3. 他にMC_RGM/SBAFの設定で不足しているものはありますか？
いいえ。機能リセットエスカレーションの場合、FRETを設定するだけで十分です。
2. 機能リセットおよび破壊リセット後のSRAM保持
1. このSRAMの挙動がS32K312上で予想されるものか、またSRAMテスト領域が破壊的なリセットを経ても保持されるメモリ領域にある可能性があるのか、明確にしていただけますか?
しかし、そうあるべきではありません。破壊的なリセットイベントの後、すべてのSRAMコンテンツは失われます。
直接的なソフトウェア破壊リセットをどのようにテストしているのか教えてもらえますか?
プロジェクトで Power_Ip_PerformReset() API を使用している場合、それは破壊的ではなく機能的なリセットとして構成されています。
実は、値を保存してUARTで共有してテストしました。FRDM-A-S32K312はSW2で機能リセットを発行し、FRETは15に設定され、15回のSW機能リセット後にMCU_MC_RGM_FRE_RESETが生成されるのが見えます。これはRTD 6.0.0で発生しています。以下のログをご覧ください。
[RESET] Reason : MCU_F_EXR_RESET (RGM_FES F_FR0)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 1
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 2
[RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 1
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 2
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 3
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 4
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 5
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 6
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 7
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 8
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 9
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 10
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 11
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 12
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 13
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 14
[RESET] Reason : MCU_MC_RGM_FRE_RESET (RGM_DES F_DR6)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 1RTD 7.0.1では、あなたが言及したのと同じ挙動が見えます(FREが破壊リセットを主張しなかったり、デバッグャが切断されたりするなど):
[RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_DEST_RESET (RGM_DES F_DR29)
[RESET] FRE Counter: 0
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 1
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 2
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 3
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 4
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 5
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 6
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 7
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 8
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 9
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 10
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 11
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 12
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 13
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 14
[RESET] Reason : MCU_SW_FUNC_RESET (RGM_FES F_FR29)
[RESET] FRE Counter: 0これにより、RTD 6.0.0とRTD 7.0.1の間にPower ドライバにいくつかの違いがあり、それがこれらの症状の原因になっているのではないかと考えています。これが設定の問題なのかバグなのか特定できていません。分析の時間をいただき、必要なら社内チームに連絡してください。
よろしくお願いします、
ジュリアン
こんにちは、ジュリアンさん。
ご説明いただきありがとうございます。
ご要望通り、現在使用している ソフトウェアの破壊リセットテストコード/プロジェクト を含むZIPファイルを添付しました。
FRET エスカレーションが RTD 6.0.0で正しく動作するとおっしゃっていましたが、テストで使った RTD 6.0.0の動作するコードやプロジェクト を共有していただけますか?
あなたのRTD 6.0.0の動作コードを参考に、私のRTD 7.0.1プロジェクトと比較して、動作の違いを理解したいと考えています。
また、 RTD 6.0.0とRTD 7.0.1の間でパワードライバーに違いや問題がある可能性があるとおっしゃっていましたが、分析が終わったら RTD 7.0.1 の問題についての調査結果を教えていただけますか?
再開まで今しばらくお待ちください。
よろしくお願いします、
シャリフ
こんにちは、@Sharif417 さん。
Power_Ipドライバーのソースコードを調べたところ、Power_Ip_MC_RGM_GetResetReason()APIで機能リセットエスカレーションカウンタの修正が適用されているのが見えました。そこに3つ目の節が追加され、DESがビットを設定していてFRETレジスタが現在非ゼロを読み取っている場合にFESも入ります。
RTD 6.0.0:
/* If the fields of Destructive Event Status Register (DES) are set then the status of FES register must be ignored */
if (((uint32)0U == ActiveValue) || (MCU_POWER_ON_RESET == ResetReason))
{
...
}RTD 7.0.1:
/* If the fields of Destructive Event Status Register (DES) are set then the status of FES register must be ignored */
/* If functional reset escalation to destructive reset is disabled, then the status of FES register must be ignored if the fields of Destructive Event Status Register (DES) other than DES[F_POR] are set. */
/* If functional reset escalation to destructive reset is enabled and if the fields of Destructive Event Status Register (DES), other than DES[F_POR], are set, then based on these fields user should check if the cause of the destructive reset was due to functional reset escalation or if it was triggered directly by a destructive reset source, in which case FES needs to be ignored */
if (((uint32)0U == ActiveValue) || (MCU_POWER_ON_RESET == ResetReason) || (((uint32)0U != DesResetStatus) && ((uint32)0U != Power_Ip_pxMC_RGM->FRET)))
{
...
}これがFESフラグが上書きされる理由です。私の理解が正しければ、ハードウェアは破壊的リセットを正しく実行しているにもかかわらず、リセットモジュールは代わりに機能的リセットを報告している。これは、15回目の機能リセット直後のIP_MC_RGM->DESレジスタを読むことで確認できます:
有効な方法は、3番目の節を変更して、MCU_MC_RGM_FRE_RESETイベントがすでに起こっているかどうかを確認することかもしれません。
/* -----------------------------------------------------------------------
* Enter the FES block if:
* a) DES is empty (no destructive reset logged), OR
* b) DES has only the Power-On Reset bit, OR
* c) DES has bits set AND FRE escalation is configured (FRET != 0)
* AND the DES reason is NOT already MCU_MC_RGM_FRE_RESET
* ----------------------------------------------------------------------- */
if (((uint32)0U == ActiveValue) ||
(MCU_POWER_ON_RESET == ResetReason) ||
(((uint32)0U != DesResetStatus) &&
((uint32)0U != Power_Ip_pxMC_RGM->FRET) &&
(MCU_MC_RGM_FRE_RESET != ResetReason)))RTDドライバの修正はサポートされていないことを覚えておいてください。正しい方法は、SWチームからの公式修正を待つことです。この件については社内チームに報告し、もしあれば彼らからのフィードバックも伝えます。この問題をご指摘いただきありがとうございます。
最後に、あなたのプロジェクトについてですが、Power_Ip_PerformReset()を通じてリセットを発行しているのが見えます。先ほども述べた通り、リセット設定内で「機能リセット」が設定されており、ソフトウェア破壊リセットを発行するには「破壊的リセット」に変更する必要があります:
または、ModeSettingConf構造体を追加し、DEST_RESETを選択して、代わりにPower_Ip_SetMode()を呼び出します。
よろしくお願いします、
ジュリアン