i.MX95 LPDDR4x 读取模拟通过/失败标准 大家好 对于 i.MX95 处理器，能否提供 LPDDR4x读取时序裕量和仿真通过/失败标准？ 汽车电子 工业控制

S32DS 为 S32G399A 生成 PCFS ClockSourceFrequency = 0 你好， 在 S32 Design Studio 中生成时钟配置时，我注意到它将 PCFS 源频率设置为 0，即使 Mcu 元器件显示正确的值（附图）。这会导致无效寄存器被编程。 当我在“时钟”选项卡中查看 Clock_Ip_ _PBcfg.c 的预览时，我看到了预期值： /* PCFS initialization. */ { #if CLOCK_IP_PCFS_NO > 0U { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 800000000U, }, #endif #if CLOCK_IP_PCFS_NO > 1U { ACCEL_PLL_PHI1_CLK, 50U, 1U, PFE_PE_CLK, 300000000U, }, #endif { RESERVED_CLK, 0U, 0U, RESERVED_CLK, 0U, }, }, 但是，当实际通过“更新代码”生成代码时，我看到以下输出： /* PCFS initialization. */ { #if CLOCK_IP_PCFS_NO > 0U { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 0U, }, #endif #if CLOCK_IP_PCFS_NO > 1U { ACCEL_PLL_PHI1_CLK, 50U, 1U, PFE_PE_CLK, 0U, }, #endif { RESERVED_CLK, 0U, 0U, RESERVED_CLK, 0U, }, }, 注意，800000000U 和 300000000U 被设置为 0，文件的其余部分保持不变。由于这些值未设置，我遇到了调试器断开连接的问题，因为时钟斜坡没有按预期发生。如果我尝试修改生成的代码，将这些值添加回去，它就能正常工作。 这是已知问题吗？有没有办法在不手动修改文件的情况下，将这些值传递到生成的代码中？ 版本： S32 设计工作室 3.6.0（版本 3.6.0.202411280511） S32 配置工具 1.8.0（时钟 14.0，外设 15.0） RTD 5.0.0 (S32_RTD_5_0_0_D2410)，配置数据 PlatformSDK_S32XX_4_0_0 S32G399A，Cortex-M7_0 谢谢你！ Re: S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A 你好， @cpearson 感谢分享。 1.对于 RTD5.0.0，正如其版本说明中所述，它是作为 S32 Design Studio 的更新站点“S32 Design Studio IDE 3.5 - Update 13”提供的，并且配置元器件是使用“S32 Design Studio IDE 3.5 - Update 13”开发的。请问您是否也在 S32DS3.5.13 或更高版本的 3.5.x 上进行过测试，以确认该问题是否存在？ 2. 如果该问题也出现在 3.5.13 版本中，您能否详细介绍一下触发信号该功能的步骤（可以通过RTD中现有的示例项目或自定义项目来实现）？我会重现并调查此事。 BR 陈银 Re: S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A 陈银你好， 谢谢你的回复。 1. 我没有在 3.5.13 版本上测试过，我们使用的是 S32DS 3.6.0。RTD 5.0.0 是否支持 3.6.0 版本？根据 3.6.0 版本的发布公告来看，应该是支持的。 2. 我可以在 3.6.0 版本上重现这个问题。使用 RTD 5.0.0 示例项目 Mcu_Example_S32G399A_M7 - 在时钟工具中，选择时钟配置 Config1。在 MC_CGM_0_MUX_0 上，将“MCU 控制下的时钟 PCFS12”设置为启用。 在“外设”工具中，依次选择“Mcu_1 > McuModuleConfiguration > McuClockSettingConfig > 选择 1 > McuCgm0SettingConfig > McuCgm0PcsConfig”。检查“MCU 控制下的 PCFS 时钟”是否为 PCFS_12。源频率应显示为 800000000。 之后，时钟工具对 Clock_Ip_PBcfg.c 文件进行了代码预览。应显示 clock_Cfg_1 PCFS 条目为 { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 800000000U }。 运行“更新代码”后，generate/src/Clock_Ip_PBcfg.c 应显示 clock_Cfg_1 PCFS 条目为 { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 0U }。 如果您需要更多重现步骤的说明，请告诉我。 此致， 卡特 Re: S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A 你好， @cpearson 感谢您的详细描述。 我这边已经重现了这个问题，目前正在调查中。 如有任何最新消息，我会及时通知您。       BR 陈银

iMX95 - EMMC 部件确认 大家好， 我们为 128GB EMMC 部件提供了两种替代方案。请问以下部件是否可以与IMX95一起使用？ BIWIN零件 - BWEFMA128GN9KC SANDISK 零件 - SDINBDA6-128G-ZA 此致， 因德拉吉特·S Re: iMX95 - EMMC Part confirmation 你好@indrajith_shanmugam ， 对于 eMMC i.MX95，支持 eMMC 5.1，没有特殊需求。 在这里，您可以根据 i.MX95 usdhc1 的接口需求来修改 emmc 数据表，这样就可以了。 希望这对您有所帮助。 如有任何疑问，请随时与我联系。 祝你今天过得愉快 顺祝商祺！ Rita

iMX95 - EMMC Part confirmation Hi team, We have two alternate part suggestion for 128GB EMMC part. Can you please confirm we can use below parts with IMX95? BIWIN part - BWEFMA128GN9KC SANDISK part - SDINBDA6-128G-ZA Regards, Indrajith S Re: iMX95 - EMMC Part confirmation Hi @indrajith_shanmugam , For the emmc i.MX95 support the emmc 5.1, and do not have special need. Here you make the emmc datasheet fit for the need for the interface of the i.MX95 usdhc1  will be OK. Hope this can do help for you Any questions please contact me freely Wish you have a nice day Best Regards Rita

i.MX95 LPDDR4x READシミュレーションの合否判定基準 こんにちは、チームの皆さん。 プロセッサi.MX95の場合、LPDDR4x の読み取り タイミングマージンとシミュレーションの合格/失敗基準を設定できますか? オートモーティブ インダストリアル

DSP56F807PY80E: 1.6V入力時のADC読み取り値が期待される2048カウントと異なる こんにちは、NXPコミュニティの皆さん、 DSP56F807PY80E を搭載したボードで、ADC オフセットの問題をトラブルシューティングしています 。デバイスのピンで測定された電圧は以下のとおりです。 ピンの機能 測定電圧 102～109 ANA0～ANA7入力 1.60V 99と110 VREFとVREF2 3.20V 88、100、111 VDDA 3.30V オフセット補正のないシングルエンド変換の場合、 入力電圧が基準電圧の半分であるため、 約 2048カウントになると 予想されます。 ADCカウント = (1.60 / 3.20) × 4096 = 2048 しかし、ADCの測定値はこの予想値とは異なっている。 どなたかアドバイスをいただけませんか: どのADC設定レジスタとオフセットレジスタを確認すればよいですか？ この違いは、ADCの結果レジスタの読み込みやシフトの仕方に関係しているのでしょうか? ADCをリセットまたは再初期化し、オフセットを確認するための推奨手順は何ですか？ 何かご指導や初期化コードの例があれば幸いです。 再開まで今しばらくお待ちください。 Re: DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input こんにちは、 @Hari0369 さん。 詳細な情報ありがとうございます。 理想的な12ビット変換の場合、あなたの計算は正しいです。入力電圧が1.60V、基準電圧が3.20Vの場合、予想される結果は約2048カウントです。 まず最初に確認すべきことは、ADCの結果がどのように読み取られるかということです。 DSP56F807では、12ビットADCの結果はADRSLTビット14～13に格納されます。オフセットを適用しない場合、2048カウントは生のADRSLTレジスタでは約0x4000として表示されます。 ですので、2048と比較する前に生の結果を右に3ビットシフトしてください: ADC値 = ADRSLTn > 3 テスト条件では、おおよそ以下の値が表示されるはずです。 生のADRSLT値：0x4000 3 の後 : 0x0800 = 2048 また、以下のADC設定も確認することをお勧めします。 - ADLST1/ADLST2を確認し、正しいアナログ入力が選択されているか確認してください。 - ADCR1.CHNCFG を確認し、シングルエンド動作が選択されていることを確認してください。 - ADSDISを確認し、使用しているサンプルスロットが有効になっていることを確認してください。 - 対応するADOFSレジスタを確認してください。このテストでは、オフセットを0x0000に設定してください。 - ADCR2を確認し、ADCクロックとサンプリング構成が正しいことを確認してください。 - 読み取ったADRSLTレジスタが、設定したサンプルスロットと一致していることを確認してください。   クリーンなテストには、ADCチャネルを1つだけ使うことをおすすめします。 まず、ADCを停止し、ADSTAT.CIPがADCがアイドル状態であることを示すまで待ちます。次に、使われていないサンプルスロットを無効にし、既知のチャネルを1つ設定します。対応するADOFSレジスタを0x0000に設定し、テストしたいサンプルスロットのみを有効にしてください。 その後、変換を1つ開始し、生のADRSLT値を保存します。次に、この値を3ビット右にシフトし、その結果を期待されるADCカウントと比較します。   それでも結果が予想と異なる場合は、以下の値を教えていただければ幸いです。 - ADCR1 - ADCR2 - ADLST1/ADLST2 - ADSDIS - 対応するADOFS値 - 生のADRSLT値 これらの値は、結果フォーマット、ADC構成、オフセット設定、またはアナログ入力経路による差を判断するのに役立ちます。 お役に立てば幸いです。 BR セレステ Re: DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input こんにちは、 @Celeste_Liu さん。 詳細情報とトラブルシューティングのご提案をいただき、ありがとうございます。 同じファームウェアを使って約500台のDSPコントローラをプログラムしました。ほとんどのユニットは期待どおりに動作しますが、約10台のユニットでは、同じテスト条件下で予想されるカウントとは異なるADC値を示します。 データシートには、ADCオフセット電圧の範囲が-90mV～+10mVで、標準値が-25mVであると記載されていることを理解しています。DSPやADCをリセットまたは再初期化することで、1.60V入力と3.20Vの基準で予想される2048カウントに近づけるかどうか、教えていただけますか?もしそうなら、推奨される手順を教えていただけますか? 再開まで今しばらくお待ちください。 Re: DSP56F807PY80E: ADC reading differs from expected 2048 counts at 1.6 V input こんにちは、 @Hari0369 さん。 追加情報ありがとうございます。 ADCを再初期化することでADCの設定や状態の問題を除外するのに役立ちますが、通常はデバイスのADCオフセット自体は変わりません。 データシートでは、ADCオフセット電圧は-90mV～+10mVの範囲で、標準値は-25mVと規定されている。VREF = 3.20 Vの場合、1 LSBは約0.781 mVであり、理想的な2048カウントとは多少の違いが期待されます。 影響を受ける機器については、以下の点を確認することをお勧めします。 ADCを停止し、ADSTAT.CIPがADCがアイドル状態であることを示すまで待ちます。 通常ユニットで使用されている設定と同じ設定でADCを再初期化してください。 対応するADOFSレジスタが0x0000に設定されていることを確認してください。 複数の変換を実行し、再初期化前と再初期化後の平均結果を比較する。 電源を完全に投入してから再度テストを行ってください。 同じユニットで常に同じオフセット値が表示される場合は、入力電圧1.60V、基準電圧3.20Vにおける、正常なユニットと影響を受けているユニットそれぞれの実際のADCカウント値を弊社までお送りください。その差をADC仕様と比較できます。 BR セレステ

Debug interface recommendations for Kinetis and LPC? I do most of my development on the Kinetis series, and potentially some LPC parts in the near future. I've got a drawer full of debug interfaces from P&E Micro, including a Cyclone ACP that I use most. I sometimes find myself switching from the $600 Cyclone to the $20 LPC-Link2 because the Cyclone has so many weird problems with MCUXpresso. Honestly the LPC-Link2 does most of what I need, it's just a bit slow. Should I be looking at Segger interfaces? Can someone recommend a reliable, reasonably fast interface that's well-supported in MCUXpresso (and hopefully CodeWarrior 11 as well) that doesn't cause crashes all of the time, or fail to halt a running target? Trace support would be nice. Thanks! Re: Debug interface recommendations for Kinetis and LPC? Hello @swetie42 , Thanks for your interest in NXP products.  For your use case, I would suggest taking a look at MCU-Link Pro Debug Probe. It works well with MCUXpresso IDE using the standard CMSIS-DAP firmware, and unlike the base MCU-Link, MCU-Link Pro also provides a J-Link LITE firmware option. Since CodeWarrior supports J-Link, this can be useful if you need to work with both MCUXpresso IDE and CodeWarrior on Kinetis devices. MCU-Link Pro also supports SWO profiling and provides additional features such as energy measurement and analog signal monitoring.   Of course, a SEGGER J-Link is also a good option if you prefer the SEGGER ecosystem or need more advanced debug/trace capabilities. The exact trace capability will depend on the probe model and the target device. For more details, I suggest you directly contact Segger support: Ticket | SEGGER - The Embedded Experts   So, in a word, I think MCU-Link Pro would be worth considering first.   Hope it helps.   BR Celeste

S32K358 power supply design with MC33FS6523CAE (FS6500 SBC) Hello I’m designing with the S32K358 and plan to use the MC33FS6523CAE SBC. Is this a supported pairing, and which SBC outputs (VCORE, VCCA) do you recommend for VDD_HV_A/B, VREFH and V15, given the S32K3 internal SMPS?  Thanks https://www.nxp.com/products/FS6500?page=9&nrnd=false Re: S32K358 power supply design with MC33FS6523CAE (FS6500 SBC) Hello Sakshi, The MC33FS6523CAE is a compatible SBC for the S32K358. However, I would like to highlight that our recommended companion SBC for the S32K358 is the FS26, for the reasons outlined below. The FS26 is the purpose-designed safety SBC attach solution for the S32K3 series, including the S32K358. It offers a number of advantages specifically relevant to S32K358 designs: - Dedicated reference documentation: AN13850 (FS26 Implementation and Behaviors) includes an explicit section on FS26 connection to the S32K358.  -ASIL D functional safety coverage: The FS26 family is specifically developed and validated for ASIL D applications with S32K3, with a dedicated RTD software driver and safety application note combination ready for production use. - Higher current LDO outputs: FS26 LDO1 and LDO2 directly supply VDD_HV_A and VDD_HV_B to the S32K358. Our FRDM-A-S32K358 evaluation board uses the FS26 as the companion SBC, with LDO1 supplying VDD_HV_A (+3.3 V) and LDO2 supplying VDD_HV_B (+3.3 V). - Ready-made software: A production-ready RTD package for S32K3 + FS26 is available, significantly reducing software development effort. The MC33FS6523CAE is still a supported and functional SBC choice for S32K358 if you require integrated CAN FD + LIN transceivers in a single SBC package. BRs, Tomas

iMX95 - EMMC部品確認 チームの皆さん、こんにちは。 128GBのeMMC部品については、代替部品を2つご提案できます。以下の部品をIMX95で使えるか確認していただけますか? BIWIN部品番号 - BWEFMA128GN9KC サンディスク部品 - SDINBDA6-128G-ZA よろしくお願いいたします。 インドラジットS Re: iMX95 - EMMC Part confirmation こんにちは、 @indrajith_shanmugam さん。 emmc i.MX95はemmc 5.1をサポートしており、特別な必要性はありません。 ここでは、iのインターフェースのニーズに合ったemmcのデータシートを作ってください。MX95のusdhc1は問題ありません。 これがあなたの役に立てば幸いです ご質問があれば、どうぞお気軽にお問い合わせください 素敵な一日をお過ごしください よろしくお願いいたします。 リタ

S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A Hi, When generating a clock configuration from S32 Design Studio, I'm noticing that it's setting the PCFS source frequency to 0, even though the Mcu component shows the correct value (image attached).  This causes invalid registers to be programmed. When I'm in the Clocks tab and look at the preview of Clock_Ip_ _PBcfg.c, I see the expected values: /* PCFS initialization. */ { #if CLOCK_IP_PCFS_NO > 0U { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 800000000U, }, #endif #if CLOCK_IP_PCFS_NO > 1U { ACCEL_PLL_PHI1_CLK, 50U, 1U, PFE_PE_CLK, 300000000U, }, #endif { RESERVED_CLK, 0U, 0U, RESERVED_CLK, 0U, }, },  However when the code is actually generated via Update Code, I see the following output: /* PCFS initialization. */ { #if CLOCK_IP_PCFS_NO > 0U { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 0U, }, #endif #if CLOCK_IP_PCFS_NO > 1U { ACCEL_PLL_PHI1_CLK, 50U, 1U, PFE_PE_CLK, 0U, }, #endif { RESERVED_CLK, 0U, 0U, RESERVED_CLK, 0U, }, }, Note 800000000U and 300000000U being set to 0, the rest of the file is the same.  Because of these values not being set, I am experiencing an issue where the debugger disconnects because clock ramping does not occur as expected.  If I try modifying the generated code to add the values back, it works fine. Is this a known issue?  Is there a way to get the values into the generated code without hand modifying the files? Versions: S32 Design Studio 3.6.0 (build 3.6.0.202411280511) S32 Configuration Tools 1.8.0 (Clocks 14.0, Peripherals 15.0) RTD 5.0.0 (S32_RTD_5_0_0_D2410), configuration data PlatformSDK_S32XX_4_0_0 S32G399A, Cortex-M7_0 Thank you! Re: S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A Hello, @cpearson  Thanks for the post. 1. For RTD5.0.0,  as what specified in its release notes, it is delivered as an Update Site for S32 Design Studio "S32 Design Studio IDE 3.5 - Update 13" and configuration components were developed using "S32 Design Studio IDE 3.5 - Update 13", may I know if you had also tested on S32DS3.5.13 or later version of 3.5.x to check if the issue also exist? 2. If the issue is also shown on 3.5.13, would you mind introducing more details about the steps for triggering it(via any existing example project in RTD or customized project?) I would reproduce and investigate on it. BR Chenyin Re: S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A Hi Chenyin, Thank you for the reply. 1. I haven't tested on 3.5.13, we use S32DS 3.6.0.  Is 3.6.0 supported with RTD 5.0.0?  According to the 3.6.0 release announcement it seems like it should be. 2. I can reproduce the issue on 3.6.0 with the RTD 5.0.0 example project Mcu_Example_S32G399A_M7   - In Clocks tool, select clock configuration Config1.  On MC_CGM_0_MUX_0, set "Clock PCFS12 under MCU control" to Enabled.   - In Peripherals tool, go to Mcu_1 > McuModuleConfiguration > McuClockSettingConfig > Select 1 > McuCgm0SettingConfig > McuCgm0PcsConfig.  Check "Mcu Clock PCFS under MCU control" for PCFS_12.  Source frequency should show 800000000. After this, the Clocks tool's code preview on Clock_Ip_PBcfg.c should show clock_Cfg_1 PCFS entry as { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 800000000U }. After running "Update Code", generate/src/Clock_Ip_PBcfg.c should show clock_Cfg_1 PCFS entry as { CORE_PLL_DFS1_CLK, 50U, 1U, XBAR_2X_CLK, 0U }. Please let me know if you need more instructions for reproducing. Best regards, Carter Re: S32DS generates PCFS ClockSourceFrequency = 0 for S32G399A Hello, @cpearson  Thanks for your detailed description. I have reproduced the issue on my side and is now investigating on it. I will keep you informed of any updates as they become available.       BR Chenyin

NTAG X DNA AES-128からAES-256へのAppMasterKey ChangeKeyの返0x917E こんにちは、 私はNtag X DNAにRaspberry Pi 4BとAdafruit PN532を使っています。認証済みEV2のセキュアメッセージングセッション下で、ChangeKeyを使って、AppMasterKeyの工場出荷時のAES-128オールゼロキーからAES-256キーに変更しようとしています。 データシートの改訂によると、AppMasterKeyの予定されているアップデートは以下のとおりです。 AuthenticateEV2Firstを使用してAppMasterKey 0x00で認証します。 通信モードをフルに設定してChangeKeyを送信します。 KeyType.AES256 の KeyNo[7:6] を 11b に設定します。 KeyData = NewKey || KeyVer を暗号化します（ターゲットキーは AppMasterKey であるため）。これは32バイトのAES256キーと1バイトのバージョンで構成されるはずです。 ISO/IEC 9797-1方法2の適用:33バイト平文-> 48バイト EV2 CMACの偶数バイト8個を追加する APDUには期待通りの57バイトのデータフィールドが含まれているが、タグは0x917eエラー（LENGTH_ERROR）を返した。 AppMasterKeyを工場出荷時のデフォルトキーであるAES128からゼロ以外の値に変更してみたところ、成功しました。また、PN532の転送サイズ制限が原因ではないようです。なぜなら、最大100バイトのペイロードを持つCryptoRequestコマンドの認証に成功しているからです。さらに、相互認証とEV2セッション鍵の導出は、失敗したChangeKeyコマンドよりも先に成功します。 最後に、タグはGetVersionコマンドを通じてNTAG X DNAとして自己認識します。この件について最善の方法についてアドバイスいただけますか?NTAG X DNAシリーズのキーをAES256に変更することに制限や既知の問題はありますか? 前もって感謝します。 よろしくお願いいたします。 N Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E こんにちは、 LicとLeの拡張長フィールドを使ってテストをもう一度行ってもらえますか? 例：90 C4 00 00 00 00 39 C0<48-byte encrypted data><8-byte CMAC> 00 00 よろしくお願いいたします。 エドゥアルド。 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E こんにちは@n_s あなたの調子が良いといいのですが。 全体的な手順は良好に見える。 それでも、完全な生のAPDUは重要です。送ろうとしているフルフレームをぜひ共有していただけますか? よろしくお願いいたします。 エドゥアルド。 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E こんにちは、 @EduardoZamora さん、 迅速なご返信、ありがとうございました。 送信しようとしている APDU は次のとおりです: 90c4000039c054d419618197a659d7346b7f7869b0a9972216d077258b6a58320d65019663e3695d16e265f93f594d131818ee9d889c7feb8ac85cb442b400 私たちは、K0をすべてゼロのAES128からすべてゼロのAES256に変更しようとしています。 お役に立てば幸いです。他に何か情報が必要な場合はお知らせください。 再度、感謝します。 よろしくお願いいたします。 N Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E こんにちは、@EduardoZamora さん。 返信が遅くなり申し訳ありません。このメッセージに気づいたのはつい最近でした。LcとLeの拡張長さフィールドを試してみましたが、これが生のAPDUです: 90c40000000039c00da764eeb6384a3cc9352d91fd722b4e09e72b90e5ac47447b6a10269c12dd3c9b9a0c7a549c79989c5dc8f90382180cde26d87bc6ca1c420000 長さのエラーは依然として発生します。 現在、AES128を使用していますが、問題なく動作しています。しかし、私たちはAES256が動作することを期待しています。なぜなら、これがNTAG X DNAタグを導入した理由だからです 🙂 他に試せる方法があれば教えてください! ご協力ありがとうございました。 よろしくお願いいたします。 N

i.MX 8ULP SPI 与非 启动：当 FCB0 损坏时，启动 ROM 不会回退到 FCB1。 NXP社区的各位好， 我正在使用 i.MX 8ULP，并从 SPI 与非 闪存（Winbond W25N04LW）启动。 我的理解是，如果 FCB0 损坏，启动 ROM 应该会自动回退到 FCB1。然而，当 FCB0 损坏时，系统却无法启动。具体来说，启动 ROM 似乎根本没有尝试读取 FCB1。 以下是我的“SPI 与非 启动参数”熔丝设置： FlexSPI 与非 搜索步长：00（64 页） FlexSPI 与非 搜索计数：00 (2) FlexSPI 与非 CS 间隔：00 (100ns) FlexSPI 与非列地址宽度：01 (13) 其他所有熔丝均保持默认值。 我使用协议分析仪监测了 SPI 通信。 上电后， i.MX 8ULP 发出页面数据读取 (13h) 请求，读取页面地址 0x000000 处的 FCB0。 由于 FCB0 已损坏，我预期启动 ROM 会读取地址为 0x000040 的 FCB1 （基于 64 页的搜索步长）。然而，它却直接尝试再次读取 FCB0，而没有尝试读取 FCB1。 作为参考，我的SPI 与非存储器映射如下： 0x00000000 ┌──────────────────────────────────┐ │ 区块 0：FCB0 │ 0x00040000 ├──────────────────────────────────┤ │ 区块 1：FCB1 │ 0x00080000 ├──────────────────────────────────┤ │ 模块 2：DBBT0 │ 0x000C0000 ├──────────────────────────────────┤ │ 模块 3：DBBT1 │ 0x00100000 ├──────────────────────────────────┤ │ 第 4–15 块：主固件 │ 0x00400000 ├──────────────────────────────────┤ │ 第 16–31 块：辅助固件 │ 0x00800000 └────────────────────────────────────┘ 我尝试了两种不同的方法来故意破坏 FCB0，但两种情况下行为都相同（FCB1 从未被读取）： 已完全擦除第 0 块。 将 FCB 指纹从“NFCB”修改为“NFC@”。 问：当 FCB0 损坏时，是否需要任何额外的熔丝设置或特定配置才能启用回退机制以读取 FCB1？ 感谢您的支持。 i.MX8ULP Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted 作为更新，我想补充一点后续观察和问题。 如果启动 ROM 读取某个 FCB 失败，它会不会设计成在停止之前重试读取该 FCB 一次？如果这个假设是正确的，增加“FlexSPI 与非 搜索计数”熔丝可能会通过强制启动 ROM 进行更远距离的搜索来解决问题。 虽然 i.MX 8ULP 参考手册中没有明确详细说明，但 i.MX 91 的熔丝图（我认为它采用兼容的 SPI 与非启动架构）对搜索计数的描述如下： FlexSPI 与非 搜索计数 00 - 2 01-2 10 - 4 11 - 8 是否可以假设 i.MX 8ULP 的搜索计数规范与此相同？ 任何见解都将不胜感激。 Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted 嗨，丽塔， 感谢您的及时回复和支持！ 需要澄清的是，我们观察到的问题完全发生在内部 启动 ROM 执行阶段，也就是在任何 电路板支持包。 或用户软件加载或执行之前。因此，电路板支持包。版本不应是造成这种特定行为的因素。 我的核心问题严格来说与内部启动 ROM 规范有关：当 FCB0 损坏时，i.MX 8ULP 启动 ROM 在什么情况下会尝试读取 FCB1？ 另外，正如我在之前的后续问题中提到的，这种回退行为是否与“FlexSPI 与非 搜索计数”熔丝设置有关，类似于它在 i.MX 91 上的工作方式？ 如果您能就此内部逻辑咨询一下启动 ROM 工程团队，我将不胜感激。 再次感谢您抽出时间提供帮助！ 此致， 米佐 Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted 嗨@DaisukeMizobuchi ， 你使用的是哪个版本的电路板支持包？ 祝你今天过得愉快 顺祝商祺！ Rita Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted 嗨，丽塔， 就此帖作个简单的后续补充。您有没有机会向内部工程团队核实一下启动 ROM 回退行为和搜索计数熔丝的相关情况？ 即使仍在调查中，任何快速更新都将不胜感激。 谢谢， 米佐

Query Regarding OTP Programming of FS2643D Blank OTP Variant Hi, I am planning to use the FS2643D variant, specifically the MFS2643HMDA0AD blank OTP variant, for my 24 V application. I understand that the KITFS26SKTEVM socket board can be used for OTP configuration and programming. However, using the socket board may complicate the workflow, as the IC needs to be placed in the socket for programming and then soldered onto the target PCB. Is there an alternative method to configure and program the OTP directly on the target PCB using an external programmer or target board, without requiring the KITFS26SKTEVM socket board? Could you please advise whether this approach is supported and recommend a suitable solution? https://www.nxp.com/part/MFS2643HMDA0AD Thanks. Re: Query Regarding OTP Programming of FS2643D Blank OTP Variant Hi Sakshi, for prototyping, using the socket board, our other hardware and the NXP Ringo GUI is recommended for benchmarking. For designing your prototype board, please follow the FS26 datasheet and our other documents. Especially the AN12995.  To be able to download these confidential documents, you need to have a valid NDA with NXP. If you have not an NDA yet and you would like to sign one, please create a new ticket here and an NXP representative for NDA matters will help you with the process.  Without the FS26 datasheet and other confidential documents would not be possible to work with the FS26. Once you will have your prototype schematic, we can check it for you. Please note, we do not check layouts. Alternatively you can contact our authorized distributors, they have engineers who can also check the schematic for you. With Best Regards, Jozef Re: Query Regarding OTP Programming of FS2643D Blank OTP Variant Hi Jozef, Thank you for the feedback. Since we are currently in the prototyping phase, our initial volume count is low, and we are focused strictly on bench evaluation and system validation. Given that this is a low-volume prototype phase, could you let us know how you recommend we proceed for our initial boards? Do you recommend we work with an authorized distributor (such as Arrow or Avnet) to get a small batch programmed, or is there an alternative path you suggest for early benchmarking? We want to ensure we align with NXP’s safety and validation guidelines while we bring up our custom target prototype. Best regards, Re: Query Regarding OTP Programming of FS2643D Blank OTP Variant Hi Sakshi, please note, that our evaluation boards and socket boards are designed and recommended to be used for evaluation of our components only. OTP programming of our components are allowed only by NXP or by our authorized distributors. Depending on annual volume of the specific component. Please let me know your annual volume for your project using the FS2643D Blank OTP Variant. We do not allow to program the OTP of our components by our customers. If customers will program themselves, then we do not guarantee safe and correct function of such components.  With Best Regards, Jozef

Kinetis 和 LPC 的调试接口有什么建议？ 我目前主要从事 Kinetis 系列芯片的开发工作，未来可能还会开发一些 LPC 芯片。我抽屉里装满了 P&E Micro 的调试接口，其中最常用的是 Cyclone ACP。 我有时会发现自己从 600 美元的 Cyclone 换成了 20 美元的 LPC-Link2，因为 Cyclone 与 MCUXpresso 存在很多奇怪的问题。说实话，LPC-Link2 基本能满足我的需求，只是速度有点慢。 我应该考虑使用Segger接口吗？请问有人可以推荐一款可靠、速度适中、在 MCUXpresso（最好也能在 CodeWarrior 11）中支持良好的接口吗？这款接口不会经常导致程序崩溃，也不会无法停止正在运行的目标。如果能支持追踪功能就更好了。 谢谢您！ Re: Debug interface recommendations for Kinetis and LPC? 你好@swetie42 ， 感谢您对恩智浦产品的关注。 针对您的使用场景，我建议您了解一下MCU-Link Pro Debug Probe。 它与使用标准 CMSIS-DAP 固件的 MCUXpresso IDE 配合良好，而且与基础版 MCU-Link 不同的是，MCU-Link Pro 还提供J-Link LITE 固件选项。由于 CodeWarrior 支持 J-Link，因此如果您需要在 Kinetis 设备上同时使用 MCUXpresso IDE 和 CodeWarrior，这将非常有用。 MCU-Link Pro 还支持 SWO 我的，并提供能量测量和模拟信号监控等附加功能。   当然，如果您更喜欢 SEGGER 生态系统或需要更高级的调试/跟踪功能，SEGGER J-Link 也是一个不错的选择。具体的追踪能力取决于探头型号和目标设备。如需了解更多详情，建议您直接联系 Segger 支持：提交工单 | SEGGER - 嵌入式专家   总之，我认为MCU-Link Pro值得优先考虑。   希望对您有所帮助。   BR 塞莱斯特

FS2643DブランクOTPバリアントのOTPプログラミングに関する問い合わせ こんにちは、 私は24V用途にFS2643Dバリアント、特にMFS2643HMDA0ADブランクOTPバリアントを使う予定です。 KITFS26SKTEVMソケットボードはOTPの設定やプログラミングに使えると理解しています。しかし、ソケットボードを使用すると、ICをプログラミングのためにソケットに挿入し、その後ターゲットのPCBにはんだ付けする必要があるため、ワークフローが複雑になる可能性があります。 外部プログラマーやターゲットボードを使って、KITFS26SKTEVMソケットボードを必要とせずに、OTPを直接ターゲットPCB上で設定・プログラムする代替方法はありますか? この方法が支持されているか、また適切な解決策を提案していただけますか? https://www.nxp.com/part/MFS2643HMDA0AD ありがとうございます。 Re: Query Regarding OTP Programming of FS2643D Blank OTP Variant こんにちは、サクシさん。 プロトタイプ作成には、ソケットボード、その他のハードウェア、およびNXP Ringo GUIを使用したベンチマークテストをお勧めします。試作基板の設計にあたっては、FS26のデータシートおよびその他の関連資料をご参照ください。特にAN12995。 これらの機密文書をダウンロードするには、NXPとの有効な秘密保持契約（NDA）が必要です。まだNDAを持っていなければ、署名を希望される場合は 、こちらから 新しいチケットを作成してください。NDAマターに関するNXP担当者が手続きをサポートします。 FS26のデータシートやその他の機密文書がなければ、FS26を扱うことは不可能です。 試作設計図が手に入ったら、私たちが確認します。レイアウトの確認は行っておりませんので、ご了承ください。あるいは、当社の正規代理店にご連絡いただければ、エンジニアが回路図のチェックも可能です。 敬具、 ヨゼフ Re: Query Regarding OTP Programming of FS2643D Blank OTP Variant こんにちは、ヨゼフさん。 ご意見ありがとうございます。現在プロトタイプ開発段階にあるため、初期の生産量は少なく、ベンチテストとシステム検証に重点的に取り組んでいます。 これは低生産量のプロトタイプ段階であることを踏まえ、初期のボード制作をどのように進めるべきか教えていただけますか?ArrowやAvnetなどの正規販売代理店と協力して小規模なバッチをプログラムすることを勧めますか?それとも早期ベンチマークの代替ルートを提案しますか? カスタムターゲットプロトタイプを提出する際には、NXPのセーフティおよび検証ガイドラインに準拠していることを確認したいと考えています。 よろしくお願いします、 Re: Query Regarding OTP Programming of FS2643D Blank OTP Variant こんにちは、サクシさん。 当社の評価ボードおよびソケットボードは、当社の部品評価のみを目的として設計・推奨されていますのでご注意ください。当社のコンポーネントのOTPプログラミングは、NXPまたは 当社の認可代理店のみが許可しています。特定の部品の年間生産量によって異なります。FS2643DブランクOTPバリアントを使用したプロジェクトの年間生産量をお知らせください。 当社はお客様がコンポーネントのOTPをプログラムすることを許可していません。お客様が自分でプログラムする場合、そのような部品の安全かつ正しい動作を保証するものではありません。 敬具、 ヨゼフ

i.MX 8ULP SPI NANDブート：FCB0が破損した場合、ブートROMはFCB1にフォールバックしない こんにちは、NXPコミュニティの皆さん、 私はi.MX 8ULPを使用しており、SPI NANDフラッシュ（Winbond W25N04LW）からブートしています。 私の理解では、FCB0が破損した場合、ブートROMは自動的にFCB1に切り替わるはずです。しかし、 FCB0が破損すると、システムは起動に失敗します。具体的には、ブートROMはFCB1を読み込もうとすらしないようです。 以下は私の「SPI NANDブートパラメータ」ヒューズ設定です。 FlexSPI NAND検索ストライド :00(64ページ) FlexSPI NAND検索回数 :00(2) FlexSPI NAND CS間隔：00（100ns） FlexSPI NAND 列アドレス幅: 01 (13) その他のヒューズはすべてデフォルト値のままです。 プロトコルアナライザを使用してSPI通信を監視しました。電源投入時に、 i.MX 8ULPはページアドレス0x000000のFCB0を読み取るページデータ読み取り（13h）を発行します。 FCB0が破損しているため、Boot ROMは64ページの検索ストライドに基づくページアドレス0x000040でFCB1を読み取ると思っていました。しかし実際には、FCB1を試さずに再度FCB0を読み込もうとします。 参考までに、私のSPI NANDメモリマップは以下のとおりです。 0x00000000 ┌─────────────────────────────────┐ │ ブロック 0 : FCB0 │ 0x00040000 ├─────────────────────────────────┤ │ ブロック 1 : FCB1 │ 0x00080000 ├─────────────────────────────────┤ │ ブロック 2 : DBBT0 │ 0x000C0000 ├─────────────────────────────────┤ │ ブロック 3 : DBBT1 │ 0x00100000 ├─────────────────────────────────┤ │ ブロック4-15：プライマリファームウェア │ 0x00400000 ├─────────────────────────────────┤ │ ブロック 16～31：セカンダリファームウェア│ 0x00800000 └─────────────────────────────────┘ FCB0を意図的に破損させるために2つの異なる方法を試しましたが、どちらの場合も挙動は同じでした(FCB1は一度も読み取られませんでした): ブロック0を完全に消去しました。 FCBの指紋を「NFCB」から「NFC@」に変更しました。 質問： FCB0が破損した場合にフォールバックメカニズムでFCB1を読み取るために、追加のFuse設定や特定の構成が必要ですか？ サポートありがとうございます。 i.MX8ULP Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted 追記として、追加の観察事項と質問を述べたいと思います。 もしBoot ROMが特定のFCBを読み取れなかった場合、停止する前に同じFCBを一度だけ読み直すように設計されているのかもしれません。もしこの仮説が正しければ、「FlexSPI NAND検索カウント」ヒューズを増やすことで、起動ROMにさらに探索を強制することで問題が解決されるかもしれません。 i.MX 8ULPリファレンスマニュアルには明示的に詳述されていませんが、i.MX 91(互換性のあるSPI NANDブートアーキテクチャを共有していると思われる)のFusemapでは、検索カウントを次のように説明しています。 FlexSPI NAND検索カウント 00 - 2 01 - 2 10 - 4 11 - 8 この検索数の仕様は i.MX 8ULPでも同一であると考えてよいのでしょうか? どんなご意見でも大変ありがたく思います。 Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted こんにちは、リタさん。 迅速なご返信とサポート、ありがとうございます! 念のため確認すると、私たちが観察している問題は内部のBoot ROM実行フェーズのみで発生しており、これはBSPやユーザーソフトウェアが読み込まれたり実行されたりする前の段階です。このため、BSPのバージョンはこの特定の動作には影響しないはずです。 私の核心的な質問は、ブートROMの内部仕様に関するものです。FCB0が破損している場合、i.MX 8ULPブートROMは具体的にどのような条件下でFCB1の読み取りを試みるのでしょうか？ また、前回のフォローアップで述べたように、このフォールバック動作は i.MX 91のように「FlexSPI NAND 検索 Count」ヒューズ設定に関係しているのでしょうか? この内部ロジックについて、Boot ROMのエンジニアリングチームにご相談いただけると大変ありがたいです。 お時間を割いていただき、またご協力いただき、ありがとうございました！ よろしくお願いします、 ミゾ族 Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted こんにちは@DaisukeMizobuchiさん 使用しているBSPのバージョンは何ですか？ 素敵な一日をお過ごしください よろしくお願いいたします。 リタ Re: i.MX 8ULP SPI NAND Boot: Boot ROM does not fall back to FCB1 when FCB0 is corrupted こんにちは、リタさん。 このThreadについて、さっさと続けてお願いします。Boot ROMのフォールバック動作や検索 Countのヒューズについて、社内のエンジニアリングチームに確認する機会はありましたか? たとえまだ調査中であっても、最新情報をお知らせいただければ大変ありがたいです。 ありがとう、 ミゾ族

NTAG X DNA AES-128 转 AES-256 AppMasterKey ChangeKey 返回 0x917E 你好， 我正在使用NTAG X DNA开发板，搭配树莓派4B和Adafruit PN532开发板。我正在尝试使用 ChangeKey 在经过身份验证的 EV2 安全消息会话下，将应用程序 AppMasterKey 从出厂默认的 AES-128 全零密钥更改为 AES-256 密钥。 根据数据表修订版，AppMasterKey 的预期更新如下： 使用 AuthenticateEV2First 和 AppMasterKey 0x00 进行身份验证 在 CommMode.Full 模式下发送 ChangeKey 将 KeyNo[7:6] 设置为 11b，密钥类型为 AES256 Encrypt KeyData = NewKey || KeyVer (因为目标密钥是 AppMasterKey )。这应该是一个 32 字节的 AES256 密钥 + 1 字节版本 应用 ISO/IEC 9797-1 方法 2 填充：33 字节纯文本 -> 48 字节 附加 EV2 CMAC 的 8 个偶数字节。 APDU 包含预期的 57 字节数据字段，但标签返回 0x917e 错误，即长度错误 (LENGTH_ERROR)。 我们尝试将 AppMasterKey 从出厂默认的 AES128 密钥更改为非零值，并且成功了。这似乎也不是 PN532 的传输大小限制，因为它能够验证有效负载高达 100 字节的 CryptoRequest 命令，并且验证成功。此外，在ChangeKey命令失败之前，相互认证和EV2会话密钥派生均已成功。 最后，该标签通过 GetVersion 命令将自身标识为 NTAG X DNA。请问最佳方案是什么？将 NTAG X DNA 系列的密钥更改为 AES256 是否存在任何限制或已知问题？ 提前致谢。 此致， 否 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E 您好， 请您使用 Lc 和 Le 的扩展长度字段重复测试吗？ 例如：90 C4 00 00 00 00 39 C0<48-byte encrypted data><8-byte CMAC> 00 00 问候， 爱德华多。 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E 你好@EduardoZamora ， 非常感谢您的及时回复。 我们尝试发送的 APDU 为：90c4000039c054d419618197a659d7346b7f7869b0a9972216d077258b6a58320d65019663e3695d16e265f93f594d131818ee9d889c7feb8ac85cb442b400 我们只是想把 K0 从全零 AES128 改为全零 AES256。 希望这能帮到你。如果您需要任何其他信息，请告诉我。 再次感谢。 此致， 否 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E 你好@n_s 希望你一切都好。 整个流程看起来不错。 不过，完整的原始 APDU 文件仍然很重要；能否请您分享一下您想要发送的完整帧？ 问候， 爱德华多。 Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E 嗨@EduardoZamora ， 很抱歉回复晚了，我最近才看到这条消息。我尝试了 Lc 和 Le 的扩展长度字段，以下是原始 APDU：90c40000000039c00da764eeb6384a3cc9352d91fd722b4e09e72b90e5ac47447b6a10269c12dd3c9b9a0c7a549c79989c5dc8f90382180cde26d87bc6ca1c420000 无论如何，我仍然会遇到同样的长度错误。 我们目前使用的是 AES128，运行良好。不过，我们仍然希望能够让AES256正常工作，因为这正是我们研发NTAG X DNA标签的原因。 🙂 如果还有其他方法可以尝试，请告诉我！ 非常感谢你的帮助。 此致， 否

NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E Hello, I am using an NTAG X DNA with a Raspberry Pi 4B and an Adafruit PN532. I am trying to change the application AppMasterKey from the factory default AES-128 all-zero key to an AES-256 key using ChangeKey under an authenticated EV2 secure-messaging session. According to the datasheet revision, the intended AppMasterKey update is as follows: Authenticate with AppMasterKey 0x00 using AuthenticateEV2First Send ChangeKey in CommMode.Full Set KeyNo[7:6] to 11b for KeyType.AES256 Encrypt KeyData = NewKey || KeyVer (since the target key is the AppMasterKey ). This should be a 32-byte AES256 key + 1-byte version Apply ISO/IEC 9797-1 method-2 padding: 33-byte plaintext -> 48 bytes Append the 8 even-numbered bytes of the EV2 CMAC The APDU has the expected 57-byte data field but the tag return 0x917e error, which is a LENGTH_ERROR.  We have tried changing the AppMasterKey from the factory key AES128 default to a non-zero value and it succeeds. It also doesn't appear to be a transport size limit of the PN532 as it authenticates CryptoRequest commands with payloads up to 100 bytes and it succeeds. Additionally, the mutual authentication and EV2 session key derivation succeed before the failed ChangeKey command.  Finally, the Tag identifies itself as an NTAG X DNA via the GetVersion command. Could you please advise on the best approach to this? Are there any limitations/known issues with changing the keys to AES256 on the NTAG X DNA Series?  Thanks in advance. Regards, N Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E Hi, Could you please repeat the test using Extended Length fields for Lc and Le? For example: 90 C4 00 00 00 00 39 C0 <48-byte encrypted data> <8-byte CMAC> 00 00 Regards, Eduardo. Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E Hello @EduardoZamora , Thanks a lot for your prompt reply.  The APDU we are trying to send is:  90c4000039c054d419618197a659d7346b7f7869b0a9972216d077258b6a58320d65019663e3695d16e265f93f594d131818ee9d889c7feb8ac85cb442b400 We are trying to simply change K0 from an all-zero AES128 to an all-zero AES256. Hope this helps. Please let me know if you need any additional information. Thanks again. Regards, N Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E Hello @n_s Hope you are doing well. The overall procedure looks good. Still, the complete full raw APDU is important; could you please share the full frame you are trying to send? Regards, Eduardo. Re: NTAG X DNA AES-128 to AES-256 AppMasterKey ChangeKey returns  0x917E Hi @EduardoZamora , I apologise for the late reply, as I only saw this recently. I have tried the extended Length fields for Lc and Le and this is the raw APDU: 90c40000000039c00da764eeb6384a3cc9352d91fd722b4e09e72b90e5ac47447b6a10269c12dd3c9b9a0c7a549c79989c5dc8f90382180cde26d87bc6ca1c420000  I still get the same length error regardless. We're currently using AES128, which works fine. We are, however, hopeful we could get AES256 working, as this is the reason we got the NTAG X DNA tags 🙂 Please let me know if there is anything else I can try! Thanks a lot for your help. Regards, N

Example MCAL S32K312 PIT ADC BTCU DS3.5 RTD300 * ============================================================================ * Detailed Description: * * The purpose of this demo application is to demonstrate the usage of the * ADC High-Level Driver (HLD) on the S32K312 MCU. * * The example uses PIT timers to periodically trigger BCTU conversion lists * through the TRGMUX. Each conversion list consists of five ADC channels. * Conversion results are stored in BCTU FIFOs and automatically transferred * by eDMA into result arrays. * * Trigger paths: * PIT0_CH0 -> TRGMUX -> BCTU Trigger 23 -> ADC0 (5 channels) * -> BCTU FIFO1 -> eDMA (ch0) * * PIT1_CH1 -> TRGMUX -> BCTU Trigger 47 -> ADC1 (5 channels) * -> BCTU FIFO2 -> eDMA (ch11) * * Converted results from the BCTU FIFOs are moved by eDMA into dedicated * ADC result buffers. * * ADC1 channel S10 is connected to the on-board potentiometer. The converted * value is used to adjust the brightness of the BLUE LED * * ============================================================================ * Test HW: S32K312-T172 * MCU: S32K312 * Compiler: S32DS 3.5.x * RTD release: S32K3_RTD_3_0_0 P07 * Debugger: On-Board Debugger * Target: Internal_FLASH * ============================================================================ I used these channels on --> S32K312-T172 eval board ADC results :-- ALso  be sure you enable freeze for both PITs :--  

VCU controller hangs for 110 seconds and then recovers when using s32k312 MCU Dear NXP Technical Support, We have recently been using the S32K312 MCU, and we encountered a strange issue when using DFlash to emulate EEPROM for data read/write: the controller occasionally hangs for 110 seconds and then recovers. We currently suspect that during flash erase or write, for some unknown reason, Fls_GetJobResult is unable to update to the correct status for a long time (we use the following method to wait for the erase/write status): c do { Fls_MainFunction(); Fls_JobResult = Fls_GetJobResult(); } while (Fls_JobResult == MEMIF_JOB_PENDING); Because this occurs in a vehicle and is very sporadic, we cannot capture the exception through debugging. We would like to ask whether you have any good suggestions. Or has anyone else encountered a similar issue where a flash erase/write call hangs? We look forward to your reply. Re: VCU controller hangs for 110 seconds and then recovers when using s32k312 MCU Hi@zhaoning I have found an issue that may be similar to the one you are currently experiencing. https://community.nxp.com/t5/S32K/long-Fee-cluster-swap-times/m-p/1951280#M40791 Based on the information provided, we cannot yet pinpoint the exact cause of the problem; however, you could start your investigation by looking into "Cluster Swap."