i.MX SDKによるRT1170 SDRAM設定例:自動リフレッシュが無効化されている? NXPチームの皆様、こんにちは。 私たちはMCUXpresso SDKの例を参考に、カスタム i.MX RT1170ベースのハードウェアのSDRAM構成を作成しました: https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/main/_boards/evkbmimxrt1170/demo_apps/shell/shell.mex 私たちの設計は ISSI IS42S16320F SDRAM をSEMCインターフェースに接続しています。 残念ながら、この構成では時折システムの不安定性が発生しています。SDRAM設定を詳しく確認したところ、例の構成では オートリフレッシュが無効になっているように見え ました: Masmiseim_0-1786008762531.png これは驚きでした。なぜなら、私たちの理解ではIS42S16320Fはデータの整合性を維持するために定期的なリフレッシュサイクルが必要であり、したがって自動リフレッシュが有効になっているはずだからです。 以下の点について説明していただけますか? 提供されたSDKの例ではオートリフレッシュが意図的に無効になっているというのは正しいですか? もしそうなら、この構成の根拠は何ですか? SDRAMのリフレッシュサイクルは、SEMCコントローラやソフトウェアの初期化コードが他の場所で処理しているのでしょうか? カスタムハードウェア設計のISSI IS42S16320Fでは、Auto-Refreshを明示的に有効にすることをおすすめしますか? 再開まで今しばらくお待ちください。 よろしくお願いいたします。 i.MXRT 101x Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? こんにちは、 @Masmiseim さん。 例で示されているDCD構成は、RT1170-EVKBで使用されているSDRAM向けに実装されています。ご存知の通り、各SDRAMデバイスには独自のタイミング要件や初期化パラメータがあるため、例に含まれるSEMC構成はあなたの特定のSDRAMと完全に互換性がない場合があります。 この例では、最終的なSDRAM初期化シーケンスの一部として自動リフレッシュ機能が有効化されます。しかし、初期化プロセス中は自動リフレッシュビットが無効化されたままであり、必要なリフレッシュ操作はSEMCのIPコマンドを通じて実行されます。以下の画像に示されています。 Habib_MS_4-1786056205833.png Habib_MS_6-1786056292017.png これらの設定をSDRAMでカスタマイズしたい場合は、MCUXpressoの設定ツールを使ってDCDを生成できます。これにより、次の図に示すように、デバイスの要件に応じてSDRAMパラメータを設定できます。   Habib_MS_7-1786056301151.png 一方で、「semc_cm7」というSDKの例(バージョン26.06)があり、SEMCペリフェラルを外部SDRAMで使う方法を示しています。 最後に、この コミュニティ投稿 ではOmarが有用なSEMCレジスタの設定例を提供しています。 BR ハビブ Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? SDKから使おうとする もの はあくまで 例 として扱うのが賢明なので、 すべてを必ず確認・検証すべきです。

IMX95 は can1 の親子関係の変更に失敗しました can1を有効にしようとしました 私のデバイスツリーのピンはimx95 evkに従い、&micfilを無効にします IMX95_PAD_PDM_CLK__AONMIX_TOP_CAN1_TX  0x39e IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_CAN1_RX  0x39e しかし、以下のエラーが発生しました。 [ 9.968941] CANデバイスドライバインターフェース [ 9.976800] scmi-pinctrl-imx scmi_dev.8:エラー設定 config -13 [ 9.976814] scmi-pinctrl-imx scmi_dev.8:pin_config_set 操作がピン 121 で失敗しました [ 9.976893] clk: can1 を syspll1_pfd1_di に再親付けできませんでした: -1 [ 9.978973] 内部エラー: 同期外部アボート: 0000000096000010 [#1] SMP [ 9.978986] リンクされているモジュール: flexcan(+) can_dev neoisp(+) at24 rpmsg_ctrl rpmsg_char pwm_fan enetc4_uio(O) fsl_ecat_enetc4 fsl_ecat_enetc_core moal(O) mlan(O) furuse [ 9.979017] CPU: 5 UID: 0 PID: 357 Comm: (udev-worker) Tainted: GMO 6.18.2-rt3-1.0.0-1.0.0 #1 PREEMPT_RT [ 9.979026] 汚染: [M]=MACHINE_CHECK、[O]=OOT_MODULE [ 9.979028] ハードウェア名: Axiomtek i.MX95 scm136 ボード (DT) [ 9.979031] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 9.979035] pc : flexcan_read_le+0x0/0x20 [flexcan] [ 9.979060] lr : flexcan_probe+0x454/0x834 [flexcan] [ 9.979067] sp : ffff800086133820 [ 9.979069] x29: ffff800086133850 x28: ffff8000862b0000 x27: ffff000085a182a0 これを直す方法を知っている人はいますか？ Re: IMX95 failed to reparent can1 こんにちは、Zhiming_Liu ご返信ありがとうございます。 おっしゃる通り、システムマネージャーの設定を変更する必要があります。 Re: IMX95 failed to reparent can1 こんにちは、 @HenryHsu さん。 以下は、私が以前i.MX95 EVKで行ったテスト結果です。下記の変更を加えて、ご自身のdtsファイルをご確認ください。   dtsの変更点：     Zhiming_Liu_2-1785995739657.png diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts index ab7bd4fdaadf..5eb3011f0894 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts @@ -380,7 +380,7 @@ &flexcan1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_flexcan1>; xceiver-supply = <&reg_can1_stby>; - status = "disabled"; + status = "okay"; }; &flexcan2 { @@ -623,23 +623,23 @@ spidev0: spi@0 { }; }; -&micfil { - #sound-dai-cells = <0>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&pinctrl_pdm>; - pinctrl-1 = <&pinctrl_pdm_sleep>; - assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>, - <&scmi_clk IMX95_CLK_AUDIOPLL2>, - <&scmi_clk IMX95_CLK_PDM>; - assigned-clock-parents = <0>, <0>, <0>, <0>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>; - assigned-clock-rates = <3932160000>, - <3612672000>, <393216000>, - <361267200>, <49152000>; - status = "okay"; -}; +// &micfil { +// #sound-dai-cells = <0>; +// pinctrl-names = "default", "sleep"; +// pinctrl-0 = <&pinctrl_pdm>; +// pinctrl-1 = <&pinctrl_pdm_sleep>; +// assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2>, +// <&scmi_clk IMX95_CLK_PDM>; +// assigned-clock-parents = <0>, <0>, <0>, <0>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>; +// assigned-clock-rates = <3932160000>, +// <3612672000>, <393216000>, +// <361267200>, <49152000>; +// status = "okay"; +// }; &mu7 { status = "okay"; @@ -960,19 +960,19 @@ IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x4000031e >; }; - pinctrl_pdm: pdmgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e - >; - }; + // pinctrl_pdm: pdmgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e + // >; + // }; - pinctrl_pdm_sleep: pdmsleepgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e - >; - }; + // pinctrl_pdm_sleep: pdmsleepgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e + // >; + // }; pinctrl_ptn5110: ptn5110grp { fsl,pins = <     システムマネージャーの修正: diff --git a/configs/mx95evk.cfg b/configs/mx95evk.cfg index 9250d02..6722097 100755 --- a/configs/mx95evk.cfg +++ b/configs/mx95evk.cfg @@ -389,7 +389,7 @@ SYS ALL # Resources M7P OWNER # CPUs must be first -CAN_FD1 OWNER +// CAN_FD1 OWNER FSB READONLY IRQSTEER_M7 OWNER LPIT1 OWNER @@ -612,6 +612,7 @@ CAMERA5 OWNER CAMERA6 OWNER CAMERA7 OWNER CAMERA8 OWNER +CAN_FD1 OWNER CAN_FD2 OWNER CAN_FD3 OWNER CAN_FD4 OWNER   結果: Zhiming_Liu_3-1785995783165.png  

FRDM-MCXA156:MCUXpresso IDEでSWOトレース(データ、プロファイル、割り込み)が動作しない こんにちは、みんな、 現在、 FRDM-MCXA156 の開発ボードを使っていて、デバッグ中に SWO(シリアルワイヤー出力) で問題が発生しています。 アプリケーションは正常にデバッグされましたが、 SWOトレースウィンドウには以下のようなデータが一切届きません。 SWOデータ SWOプロファイル SWO割り込みトレース SWO ITMコンソール 問題のトラブルシューティングのため、以下の点を既に確認しました。 SWOピンはConfig Toolsを使用して正しく設定されました。 TRACEクロックは有効化され、96 MHzに設定されており、MCUコアクロック(MCXA156 96 MHzで動作)と一致します。 プロジェクトは、オンボードのMCU-Linkプローブを搭載したLinkServerを用いてデバッグされています。 これらの設定にもかかわらず、デバッグ中はすべてのSWOトレースウィンドウが空のままです。 参考までに、 SWOトレース構成、 SWOデータ、 SWOプロファイル、その他のウィンドウのスクリーンショットと、関連するプロジェクト構成を添付しました。 この問題の原因について、またはFRDM-MCXA156でSWOトレースを有効にするために必要な追加の設定手順があるかどうかについて、ご助言やご提案をいただければ大変ありがたいです。 お時間とご協力に感謝いたします。 #swo #frdm-mcxa156 開発ボード MCXA Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 前のスレッドについてですが、 SWO有効化設定とクロックのスクリーンショットを以下に添付します。 よろしくお願いします。 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE こんにちは、 @sidsal FRDM-MCXA156ボードの場合、SWO信号をオンボードデバッガに接続する抵抗R36は、デフォルトではDNP（未実装）となっています。R36を入力して再度テストしてもらえますか? Alice_Yang_0-1786344510075.png よろしくお願いします。 BR アリス Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE ご指摘ありがとうございます、 @Alice_Yang さん。FRDM-MCXA156の回路図を確認し、P0_2/SWO信号をオンボードのMCU-Linkデバッガに接続するR36がDNPとしてマークされていることを確認しました。 また、FRDM-MCXN947では、SWO接続（R130）に相当する部分に0Ωの抵抗器が取り付けられていることにも気づきました。FRDM-MCXA156のR36にも、オンボードのMCU-Linkデバッガを通じたSWOトレーシングを有効にするために0 Ω抵抗を埋め込むべきか確認していただけますか? さらに、なぜR36がFRDM-MCXA156でデフォルトで未入力(DNP)されているのか、説明していただけますか?特定のボード設計上の理由や制限で、そのボードを無人のままにしておく必要があるのでしょうか?つまりSWO機能は使えないのですか? ご協力ありがとうございます。 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE こんにちは、 @sidsal 「CFRDM-MCXA156のR36にも0 Ω抵抗を入れて、オンボードのMCU-Linkデバッガを通じたSWOトレーシングを有効にするべきか確認していただけますか?」" はい。SWO機能を使用する場合は、0Ω抵抗を取り付けるか、それに応じて接続部をはんだ付けする必要があります。 「さらに、なぜR36がFRDM-MCXA156でデフォルトで未登録(DNP)されているのか、説明していただけますか?」 ->>これはすべてのユーザーがSWO機能を必要としているわけではないため、0 Ω抵抗がデフォルトで埋められていないからだと思います。 よろしくお願いします。 BR アリス Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE ご支援ありがとうございます@Alice_Yang。

S32K1 互补型 PWM 您好，NXP专家们 我们在日产的空调压缩机项目中使用了S32K142芯片。然而，日产公司要求了解该芯片的 FTM 如何确保实现互补 PWM 输出。因此，他们希望获得协助，提供解释和支持材料，或测试报告以验证此功能。谢谢。 Chenxu1_0-1785987344020.png Re: S32K1 Complementary PWM 嗨@ Chenxu1 芯片级保护主要体现在架构上：一个通道定义 PWM 时序，伴随通道由内部互补逻辑产生，可选的死区时间/同步更新硬件可保持非重叠和一致的更新。 S32K-RM Rev14.1： Senlent_0-1785999338085.png Re: S32K1 Complementary PWM 你好，Senlent，谢谢你的回复。 我们很清楚 FTM 如何输出互补 PWM。在芯片层面，它如何确保互补波形的位置正确？这是我们的客户最想了解的信息。 Re: S32K1 Complementary PWM 嗨@ Chenxu1 它可以读取和测试 AN5303 及其提供的裸机代码。 https://www.nxp.com/docs/en/application-note/AN5303.pdf Senlent_0-1785997622463.png 以下是我之前测试时记录的一些步骤，供您参考。 我设置了互补 PWM 模式，并插入了 2µs 死区时间（我忘记保存整个项目了，但修改非常简单）。 Senlent_3-1785997707326.png Senlent_1-1785997665931.png Senlent_2-1785997677611.png

Problems encountered during IDE and RTD installation Hello, I have installed S32DSIDE 3.6.6 software. 3859b5427f61973af225339173048fd.png Then I installed the RTD package. YangLuYao_0-1786007576122.png However, the SDK cannot be found when creating a new application project, as shown in the image below. YangLuYao_1-1786007624669.png YangLuYao_2-1786007639499.png This problem has been bothering me for a long time. I look forward to your reply. Thank you. My computer configuration is as follows: YangLuYao_3-1786007691107.png My computer has JDK 8 and JDK 17, and Python versions 13, 14, and 15 installed.   Re: 关于安装IDE和RTD遇到的问题 Thanks, I discovered this problem, and then I wanted to install gcc-10.2. I found a webpage about compilers. YangLuYao_0-1786064846455.png I didn't know which one to use, so I downloaded both of these EXE files to install. YangLuYao_1-1786064901733.png However, after installation, creating a new project in the S32DS software still did not show gcc-10.2. YangLuYao_2-1786065074605.png Then I tried to download it through the extension manager, but I kept getting errors and failing to download it successfully. Could you please guide me on what to do next? Thank you! YangLuYao_3-1786065134265.png Re: 关于安装IDE和RTD遇到的问题 Hello @YangLuYao, I've translated your query, so please let me know if there are any misunderstandings. Please try selecting NXP GCC 10.2 instead. S32K1 RTD does not support GCC 11.4 yet: Julin_AragnM_0-1786049379556.png Julin_AragnM_2-1786049434923.png Best regards, Julián Re: 关于安装IDE和RTD遇到的问题 I've solved the problem, thank you! Re: 关于安装IDE和RTD遇到的问题 Sorry, the past two days were the weekend, and this is the error message I reported this morning after trying to recreate the game. YangLuYao_0-1786325441496.png Re: 关于安装IDE和RTD遇到的问题 Hello @YangLuYao, Sorry for the late reply. From the image, it seems you are trying to install NXP GCC 6.3.1 (build 1620), you should actually install v10.2 (build 1728): Julin_AragnM_0-1786577752319.png Julin_AragnM_1-1786577760152.png If this still does not work, I guess you can try to install it externally: Installing software in S32 Design studio. Things I would check: Unstable network when installing. Proxy / Firewall at your workplace. Antivirus / Security checks. Disk space. Other than that, I'm not sure what could be the root cause. You could try re-installing S32DS and trying to install NXP GCC 10.2 again. Best regards, Julián

S32K312 HSE 安全启动：pInstAuthTag 能否指向存储在 UTEST DCF 记录区域中的签名？ 您好，NXP支持团队， 我们正在 S32K312 上实施基于 HSE 的安全启动和 SMR，并想确认 SMR 签名是否可以永久存储在 UTEST DCF 记录区域中。 我们目前的实施方案如下： 我们在 UTEST 中存储了一个 512 字节的 RSA-4096 签名，起始地址为： 0x1B001A00U 已占用地址范围为： 0x1B001A00 至 0x1B001BFF 该区域属于 UTEST DCF 记录区域。 我们的项目在这个领域不需要任何 DCF 配置。因此，我们目前正在考虑使用未使用的 DCF 记录空间来存储永久网络安全数据，包括公钥和 SMR 签名。 由于我们的使用场景中软件映像及其签名是固定的，因此预计在产品生命周期内签名不会发生变化。 在 SMR 条目中，我们按如下方式配置签名引用： smrEntry.pInstAuthTag[0]= 0x1B001A00U; smrEntry.pInstAuthTag[1]= 0U； 我们预期，在后续的安全启动验证期间，HSE 将直接从 pInstAuthTag[0] 指定的 UTEST 地址读取 512 字节的签名。 通过 HSE_SRV_ID_SMR_ENTRY_INSTALL 安装 SMR 入口时，我们最初将安装服务认证标签配置为引用相同的 UTEST 地址： pSmrEntryInstall->pAuthTag[0] = 0x1B000A00U; 然而，SMR 安装服务返回了 HSE_SRV_RSP_INVALID_PARAM，显然是因为 UTEST 地址被拒绝为该服务的无效输入地址。 作为一种变通方法，在调用 SMR 安装服务之前，我们将 UTEST 中的 512 字节签名复制到共享 RAM 缓冲区中： UTEST 0x1B000A00 | | 复制 512 字节 v 共享 RAM 缓冲区 然后，我们按如下方式配置安装请求： pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; SMR条目本身仍然包含： smrEntry.pInstAuthTag[0]= 0x1B000A00U; 按照此配置，HSE_SRV_ID_SMR_ENTRY_INSTALL 返回成功，SMR 条目已成功安装。 请您澄清以下问题？ 0x1B001A00U 是 S32K312 上 hseSmrEntry_t.pInstAuthTag[0] 的有效地址吗？ 在后续的安全启动过程中，HSE_B 能否直接访问 UTEST DCF 记录区并读取 pInstAuthTag[0] 引用的签名？ 成功的 HSE_SRV_ID_SMR_ENTRY_INSTALL 响应是否确认持久的 pInstAuthTag[0] 地址对后续启动时的 SMR 验证有效，还是安装服务仅验证通过 hseSmrEntryInstallSrv_t.pAuthTag[0] 提供的签名？ 以下哪种内存区域可接受： hseSmrEntryInstallSrv_t.pAuthTag[0] 和： hseSmrEntry_t.pInstAuthTag[0] 在我们的测试中，当直接使用 UTEST 地址作为 pAuthTag[0] 时，UTEST 地址会被拒绝；但是，当将相同的签名复制到 RAM 中，而 pInstAuthTag[0] 仍然指向 UTEST 时，SMR 安装就会成功。 此配置是否可能通过 SMR 安装，但在下次 RESET 或安全启动时失败，因为 HSE 在启动时无法访问 UTEST 地址？ 当项目不需要 DCF 记录时，是否允许将未使用的 UTEST DCF 记录区域存储客户应用程序数据（例如公钥或 SMR 签名）？ 使用此 DCF 记录区域是否会与 HSE 固件、ROM 启动代码、未来的 DCF 处理、生命周期转换、调试配置或设备配置扫描产生任何冲突？ 在 UTEST 区域中存储原始 512 字节签名是否存在任何对齐、记录格式、ECC、编程、锁定或访问限制？ 如果 pInstAuthTag[0] 不支持 UTEST，持久 SMR 签名是否应该始终存储在普通应用程序代码闪存或数据闪存中？ 我们主要想确认的是，以下配置是否得到官方支持，以及是否安全适用于生产环境： /* 安全启动期间使用的持久签名位置/* smrEntry.pInstAuthTag[0] = 0x1B000A00U;   /仅在 SMR 安装期间使用的临时 RAM 副本 */ pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; MCU：S32K312 HSE 类型：HSE_B 签名算法：RSASSA-PSS，采用 RSA-4096 签名长度：512 字节 持久签名地址：0x1B001A00U 谢谢！ Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar 抱歉，签名位置不是 0x1B000A00U。它是 0x1B001A00U。 Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar 嗨@Yiming2 我在我的开发板上进行了测试，因为文档中没有明确说明是否可以使用 UTEST。我的结果也类似。 如果 pAuthTag = pInstAuthTag = 0x1B001A00，则我收到 HSE_SRV_RSP_INVALID_ADDR 响应。 然后我将 pAuthTag 放入 RAM 内存中，同时 pInstAuthTag 仍然指向 UTEST，这样就可以了。一旦通过 BOOT_SEQ 位启用安全启动，安全启动即成功，应用程序即可正常工作。HSE能够读取UTEST DCF区域中的签名。 根据测试结果，HSE 固件显然会检查地址 pAuthTag 是否位于 RAM 或代码/数据闪存中，而 UTEST 中的 pInstAuthTag 则被接受。 虽然没有相关文档记载，但确实有效。 但如果您不打算更新签名，则可以选择将 HSE_SMR_CFG_FLAG_INSTALL_AUTH 保持为零，这样将使用内部验证方案（内部哈希）进行验证。您的签名仅用于安装，pInstAuthTag 将被忽略。 我认为，如果您不打算更新镜像，那么这种设置更有意义。此外，验证速度也会快得多（哈希算法与 RSA 算法相比）。这可能是保持简单并获得更好性能的最佳方法。 如果设置了 HSE_SMR_CFG_FLAG_INSTALL_AUTH 并使用了 pInstAuthTag，则主要针对想要轻松更新应用程序的用例：应用程序和身份验证标签已更新，您无需修改或重新安装该 SMR。 DCF 扫描到停止记录为止（全部为 0xFF），其余部分将被忽略。通常情况下，DCF 区域不应该用于存储用户数据，但我认为这里没有问题。 UTEST 的唯一限制是它必须是 OTP 区域。同样，ECC 的限制也适用于代码或数据闪存——一旦对对齐的双字进行编程，就不应该再次对同一个双字进行编程，因为这会导致 ECC 错误。 此致， Lukas

S32K312 HSEセキュアブート:pInstAuthTagはUTEST DCFレコード領域に保存されている署名を指し示せますか? こんにちは、NXPサポートチームの皆さん、 S32K312上でHSEベースのSecure Boot with SMRを実装しており、SMR署名がUTEST DCFレコード領域に恒久的に保存できるかどうかを確認したいと考えています。 現在の実装は以下のとおりです。 UTESTには、以下のアドレスから始まる512バイトのRSA-4096署名が格納されます。 0x1B001A00U 占有されている住所範囲は以下のとおりです。 0x1B001A00～0x1B001BFF この地域はUTEST DCF記録領域に属します。 当プロジェクトでは、このエリアにおけるDCFの設定は一切必要ありません。そのため、未使用のDCFレコード空間を公開鍵やSMR署名を含む永久的なセキュリティデータを保存することを検討しています。 ソフトウェアイメージとその署名は当社のユースケースで固定されているため、製品のライフ期間中にシグネチャが変更されることは期待されていません。 SMRエントリでは、署名参照を次のように設定します。 smrEntry.pInstAuthTag[0]= 0x1B001A00U; smrEntry.pInstAuthTag[1]= 0U; 我々の予想では、その後のセキュアブート検証中に、HSE は pInstAuthTag[0] で指定された UTEST アドレスから 512 バイトの署名を直接読み取ります。 HSE_SRV_ID_SMR_ENTRY_INSTALLを通じてSMRエントリをインストールする際、最初にインストールサービス認証タグを同じUTESTアドレスを参照するように設定しました。 pSmrEntryInstall->pAuthTag[0] = 0x1B000A00U; しかし、SMRインストールサービスはHSE_SRV_RSP_INVALID_PARAMを返しました。これは、UTESTアドレスがサービスに対する無効な入力アドレスとして拒否されたためと思われます。 回避策として、SMRインストールサービスを呼び出す前に、UTESTから512バイトの署名を共有RAMバッファにコピーします。 UTEST 0x1B000A00 | | 512バイトをコピー V 共有RAMバッファ 次に、インストール要求を以下のように設定します。 pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; SMRエントリ自体には、以下の内容が含まれています。 smrEntry.pInstAuthTag[0]= 0x1B000A00U; この構成では、HSE_SRV_ID_SMR_ENTRY_INSTALL は成功を返し、SMR エントリは正常にインストールされます。 以下の質問について、もう少し詳しく教えていただけますか? S32K312 上の hseSmrEntry_t.pInstAuthTag[0] のアドレスとして、0x1B001A00U は有効ですか？ その後のセキュアブート時に、HSE_B直接UTEST DCFレコード領域にアクセスし、pInstAuthTag[0]で参照されたシグネチャを読み取ることはできますか? HSE_SRV_ID_SMR_ENTRY_INSTALL 応答が成功した場合、永続的な pInstAuthTag[0] アドレスが後の起動時の SMR 検証に有効であることが確認されるのでしょうか、それともインストール サービスは hseSmrEntryInstallSrv_t.pAuthTag[0] を介して提供される署名のみを検証するのでしょうか？ メモリ領域には、以下の用途で受け入れられる違いがありますか？ hseSmrEntryInstallSrv_t.pAuthTag[0] そして： hseSmrEntry_t.pInstAuthTag[0] 私たちのテストでは、UTEST アドレスを pAuthTag[0] として直接使用すると拒否されますが、同じ署名を RAM にコピーし、pInstAuthTag[0] がまだ UTEST を指している場合は SMR のインストールが成功します。 この構成はSMRインストールに合格しても、次のリセットやセキュアブート時にHSEがUTESTアドレスにアクセスできないため失敗する可能性はありますか? プロジェクトでDCFレコードが不要な場合でも、未使用のUTEST DCFレコード領域は公開鍵やSMR署名などのお客様アプリケーションデータを保存することが許されていますか? このDCFレコード領域の使用は、HSEファームウェア、ROMブートコード、FUTURE DCFプロセッシング、ライフサイクルの移行、デバッグ設定、またはデバイス構成スキャンと競合を引き起こす可能性がありますか? このUTEST領域で生の512バイト署名を保存する際、アラインメント、レコードフォーマット、ECC、プログラミング、ロック、アクセス制限などはありますか? もしUTESTがpInstAuthTag[0]でサポートされていない場合、永続的なSMRシグネチャは常に通常のアプリケーションコードフラッシュかデータフラッシュに保存されるべきでしょうか? 確認したい主な点は、以下の構成が公式にサポートされており、本番環境での使用が安全かどうかです。 /* セキュアブート中に使用される永続的な署名場所/* smrEntry.pInstAuthTag[0] = 0x1B000A00U;   / SMRインストール時のみ使用される一時的なRAMコピー */ pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; MCU:S32K312 HSEタイプ:HSE_B シグネチャアルゴリズム:RSA-PSSとRSA-4096 シグネチャ長:512バイト 永続署名アドレス:0x1B001A00U よろしくお願いします。 Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar 申し訳ありませんが、署名位置は0x1B000A00Uではありません。それは0x1B001A00Uです。 Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar こんにちは@Yiming2 UTESTが使えるかどうかがドキュメントに明示的に記載されていないので、ボードでテストしました。そして、私も同様の結果を得ました。 pAuthTag = pInstAuthTag = 0x1B001A00 の場合、HSE_ SRV_ RSP_ INVALID_ ADDR 応答を受け取りました。 その後、pInstAuthTagがまだUTESTを指している状態で、pAuthTagをRAMメモリに配置したところ、うまくいきました。セキュアブートがBOOT_SEQビットで有効化されると、セキュアブートは成功し、アプリケーションは動作します。HSEはUTEST DCFエリア内の署名を読み取ることができます。 テスト結果に基づくと、HSEファームウェアはアドレスpAuthTagがRAMまたはコード/データフラッシュメモリ内にあるかどうかをチェックし、UTESTのpInstAuthTagは受け入れられることが明らかです。 公式には文書化されていないが、効果はある。 しかし、署名を更新する予定がない場合は、HSE_SMR_CFG_FLAG_INSTALL_AUTHゼロのままにするオプションがあり、内部検証方式(内部ハッシュ)が検証に使われます。署名はインストール時のみに使用され、pInstAuthTagは無視されます。 私の意見では、イメージを更新する予定がない場合は、この設定の方が理にかなっています。また、検証もはるかに高速になります（ハッシュアルゴリズムとRSAアルゴリズムの比較）。これが、シンプルさを保ちつつパフォーマンスを向上させるための最良の方法でしょう。 HSE_SMR_CFG_FLAG_INSTALL_AUTHが設定されてpInstAuthTagを使用している場合、これは主にアプリケーションを簡単に更新したい場合のユースケースを対象としています。つまり、アプリケーションタグと認証タグが更新され、SMRを修正・再インストールする必要がなくなります。 DCFは停止レコード（すべて0xFF）までスキャンされ、残りは無視されます。通常、DCFエリアはユーザーデータ用に使われるべきではありませんが、ここでは問題が見当たりません。 UTESTの唯一の制約は、OTPエリアであるということです。また、ECCに関する同様の制限が適用されます（コードフラッシュやデータフラッシュと同様）。一度アラインメントされたダブルワードがプログラムされると、同じダブルワードを再度プログラムするとECCエラーが発生するため、再度プログラムしてはいけません。 よろしくお願いいたします。 ルーカス

S32K3 请求支持在传输完成后始终开启 LPI2C 引脚低电平超时监控 您好，NXP 我们尝试利用 I2C_MASTER_EVENT_PIN_LOW_TIMEOUT 事件来实现从设备 SDA 保持低电平时的恢复。在测试过程中，我们观察到，一旦传输完成或检测到异常情况，引脚低电平超时中断就会关闭。 企业微信截图_17859835472427.png 我们期望此中断能够持续保持启用状态，因为需要对总线进行实时监控，并且在传输结束时不能清除超时中断启用状态。我们认为当前 RTD 7.0.1 对超时中断的处理存在缺陷。 NXP能否就如何正确处理此事提供官方建议或指导？ 此致， 显龙 Re: S32K3 Request to support always-on LPI2C Pin Low Timeout monitoring after transfer completion 你好@wuxianlong ， 感谢您提供的详细描述以及您指出的驱动程序代码。 您的观察是正确的：在当前的 RTD 实现中，LPI2C_IP_MASTER_PIN_LOW_TIMEOUT_INT 作为主传输中断处理的一部分被启用，并在主传输结束时再次被禁用。这意味着 RTD 驱动程序在传输完成后不会将此中断保持启用状态，作为永久总线监视机制。 从硬件角度来看，S32K3 LPI2C 模块支持引脚低电平超时功能。超时阈值由 MCFGR3[PINLOW] 配置，当选定的 SCL 或 SDA 线保持低电平的时间超过配置的阈值时，可以设置 MSR[PLTF] 标志。参考手册还指出，即使 LPI2C 控制器处于空闲状态，也可以设置此标志。 然而，这种硬件功能并不一定意味着 RTD 驱动程序会持续保持相应的中断启用状态。当前的 RTD 实现似乎是在进行主传输的背景下处理此事件的。 对于传输完成后持续的 I2C 总线监控，建议在应用层进行处理，例如在总线恢复逻辑中检查 MSR[PLTF] 状态。另请注意，引脚低电平问题本身必须通过软件解决。当低电平条件仍然存在时，PLTF 标志不能被清除，必须先清除该标志才能生成新的 START 条件。 此致， 帕维尔

IDEおよびRTDのインストール中に発生した問題 こんにちは、S32DSIDE 3.6.6ソフトウェアをインストールしました。 3859b5427f61973af225339173048fd.png 次に、RTDパッケージをインストールしました。 YangLuYao_0-1786007576122.png しかし、下の画像に示すように、新しいアプリケーションプロジェクトを作成する際にSDKが見つかりません。 YangLuYao_1-1786007624669.png YangLuYao_2-1786007639499.png この問題は長い間私を悩ませてきました。ご回答をお待ちしております。ありがとうございます。私のコンピューターの構成は以下のとおりです。 YangLuYao_3-1786007691107.png 私のコンピューターには、JDK 8とJDK 17、そしてPythonのバージョン13、14、15がインストールされています。   Re: 关于安装IDE和RTD遇到的问题 ありがとうございます。この問題に気付いた後、gcc-10.2をインストールしようと思いました。コンパイラに関するウェブページを見つけました。 YangLuYao_0-1786064846455.png どちらを使えばいいのか分からなかったので、両方のEXEファイルをダウンロードしてインストールしました。 YangLuYao_1-1786064901733.png しかし、インストール後、S32DSソフトウェアで新しいプロジェクトを作成しても、gcc-10.2は表示されませんでした。 YangLuYao_2-1786065074605.png その後、拡張機能マネージャーからダウンロードしようとしましたが、エラーが発生してダウンロードに失敗し続けました。次に何をすればよいか教えていただけますでしょうか？よろしくお願いいたします。 YangLuYao_3-1786065134265.png Re: 关于安装IDE和RTD遇到的问题 こんにちは、 @YangLuYao さん。 ご質問の内容を翻訳しましたので、誤解があればお知らせください。 代わりにNXP GCC 10.2を選択してみてください。S32K1 RTDはまだGCC 11.4をサポートし ていません : Julin_AragnM_0-1786049379556.png Julin_AragnM_2-1786049434923.png よろしくお願いします、 ジュリアン Re: 关于安装IDE和RTD遇到的问题 こんにちは@YangLuYaoさん スタンドアロンツールチェーンをダウンロードする必要はありません。S32DSは既にNXP GCC 10.2を提供しています。 Julin_AragnM_0-1786119575796.png ツールチェーンを選択し、「 1項目をインストール/更新」をクリックした後、「次へ」をクリックすると、S32DSが再起動を促します。再起動後、インストールされていることが確認できるはずです。 Julin_AragnM_1-1786119784429.png もし誤りがあれば教えてもらえますか? よろしくお願いします、 ジュリアン Re: 关于安装IDE和RTD遇到的问题 問題を解決できました。ありがとうございました！ Re: 关于安装IDE和RTD遇到的问题 申し訳ありませんが、ここ2日間は週末だったため、今朝ゲームを再現しようとした際に報告したエラーメッセージはこれです。 YangLuYao_0-1786325441496.png Re: 关于安装IDE和RTD遇到的问题 こんにちは、 @YangLuYao さん。 返信が遅くなり申し訳ありません。画像から判断すると、NXP GCC 6.3.1 (ビルド 1620) をインストールしようとしているようですが、実際には v10.2 (ビルド 1728) をインストールする必要があります。 Julin_AragnM_0-1786577752319.png Julin_AragnM_1-1786577760152.png それでも動かなければ、外部インストールを試してみるのも良いかもしれません:S32 Design Studioにソフトウェアをインストールする。 私が確認する項目： インストール時にネットワークが不安定になる。 職場におけるプロキシ／ファイアウォール。 ウイルス対策やセキュリティチェック。 ディスク容量。 それ以外に根本的な原因はわかりません。S32DSを再インストールして、NXP GCC 10.2を再度インストールしてみるのも手です。 よろしくお願いします、 ジュリアン

i.MX RT1170 同步动态随机存取存储器\(SDRAM\) 配置示例（来自 SDK）：自动刷新已禁用？ 您好，NXP团队， 我们参考 MCUXpresso SDK 示例，为我们定制的基于 i.MX RT1170 的硬件创建了 SDRAM 配置： https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/main/_boards/evkbmimxrt1170/demo_apps/shell/shell.mex 我们的设计采用连接到 SEMC 接口的ISSI IS42S16320F SDRAM 。 遗憾的是，使用此配置时，我们偶尔会遇到系统不稳定的情况。在详细检查 同步动态随机存取存储器\(SDRAM\) 设置时，我们注意到示例配置中自动刷新功能似乎已被禁用： Masmiseim_0-1786008762531.png 这让我们感到惊讶，因为根据我们的了解，IS42S16320F 需要定期刷新周期来维护数据完整性，因此我们期望自动刷新功能已启用。 请您澄清以下几点？ 提供的 SDK 示例中是否故意禁用了自动刷新功能？ 如果是这样，这种配置背后的逻辑是什么？ 同步动态随机存取存储器(SDRAM)刷新周期是否由SEMC控制器或软件初始化代码在其他地方处理？ 对于采用定制硬件设计的 ISSI IS42S16320F，您是否建议显式启用自动刷新功能？ 感谢您的支持。 顺祝商祺！ i.MX RT101x Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? 你好@Masmiseim ， 示例中提供的 DCD 配置是为 RT1170-EVKB 上使用的同步动态随机存取存储器(SDRAM) 实现的。您可能知道，每个 SDRAM 设备都有自己的时序要求和初始化参数，因此示例中包含的 SEMC 配置可能与您的特定 SDRAM 不完全兼容。 在本例中，自动刷新功能作为最终 同步动态随机存取存储器(SDRAM) 初始化序列的一部分启用。但是，在初始化过程中，自动刷新位保持禁用状态，所需的刷新操作是通过 SEMC IP 命令执行的，如下图所示： Habib_MS_4-1786056205833.png Habib_MS_6-1786056292017.png 如果您想为 同步动态随机存取存储器(SDRAM) 自定义这些设置，可以使用 MCUXpresso 配置工具生成 DCD。这样，您可以根据设备要求配置 同步动态随机存取存储器(SDRAM) 参数，如下图所示：   Habib_MS_7-1786056301151.png 另一方面，有一个名为“semc_cm7”的 SDK（版本 26.06）示例，演示了如何将 SEMC 外设与外部同步动态随机存取存储器(SDRAM)一起使用。 最后，Omar 在这篇社区帖子中提供了一个配置 SEMC 寄存器的示例，这可能很有用。 BR 哈比卜 Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? 始终将您尝试使用 SDK 中的任何内容视为示例，因此您应该检查并验证所有内容。

S32K322のSPIデューティサイクルは8MHzでは50%ではありません NXPチームの皆様へ           SPIトランザクション内で8MHzのSPI SCLKを周期的にする必要がある改善活動に取り組んでいます。SPI SCLKを8MHzで測定しました(S32K322ではSPI周辺機器のペリフェラルのドライバによって駆動されます)が、50%のデューティは維持されていないことがわかりました。周波数を1/2/4MHzに下げると、これらのSCLK周波数において50%のデューティ比が維持されることが確認できる。 質問 です - これはペリフェラルのドライバの ハードウェア的な制限なのでしょうか?それともドライバ設定を変えれば8MHzで望む50%の稼働率を得られるのでしょうか? 1MHzで当直が維持されて8MHzでないスクリーンショットをPFA(公開ファイル)してください 注: Saleaeのロジックアナライザーを接続しており、SPI信号を測定するためにより高いサンプリング解像度(250MS/s)を持っています Re: The SPI duty cycle of S32K322 is not 50% for 8MHz こんにちは、 LPSPIクロックのデューティサイクルは、SCKSETおよびSCKHLDタイミングパラメータによって決定されます。これらのフィールドが同じ値にプログラムされている場合にのみ、50/50のデューティサイクルが得られます。選択されたLPSPI機能クロックと8MHzを生成するために必要な分周器の値によっては、クロックジェネレータのタイミング分解能により、正確な50/50のデューティサイクルが実現できない場合があります。観測された76ナノ秒/48ナノ秒の高低時間差は、このような除算器の量子化効果と一致しているように見える。 PetrS_0-1786090730852.png ですので、LPSPIの機能クロック周波数、TCR[PRESCALE]、およびCCR/CCR1レジスタ(SCKSET、SCKHLD、SCKDIV)の内容から期待デューティサイクルを計算し、異なるクロックソースやディバイダ構成で50/50に近いデューティサイクルが得られるかどうかを判断してください。   BR、ペトル

EasyEVSE 1060 到 sigbrd2x 接口问题 这是对之前帖子的后续： https://community.nxp.com/t5/Power-Energy/EasyEVSE-signal-board-compatibility-and-availability/m-p/2384517 简要说明：我有一台RT1060EVKB/Sigbrd2x EVSE和一个运行v5.0.8软件的RT1064/Sigbrd2x EV，我正在尝试将它们连接起来。这条回复最初是针对上面的问题发布的，但我不太确定技术代表是否跟进了帖子里的回复。 感谢您的回复。我重新开始研究这个问题，但遇到了一些问题，我从NXP的Git仓库下载的EVSE代码v5.0.8无法正常运行。程序编译正常，图形用户界面也能正常显示，但是当我尝试使用其调试接口并请求版本信息时，对于 1060 代码，我得到了正确的 5.0.8 版本响应，但是 sigbrd2x 的版本显示为硬件版本 255，软件版本 255.255.0。我好像记得在某个地方看到过一篇帖子，说1060板上的液晶显示屏存在通信冲突问题。我会编写 sigbrd2x 和单步执行代码，所以我相当确信这部分功能正在运行。我使用的是EVSE-RT106X-CBL，而不是Arduino的接口。除了电动汽车和电动汽车供电设备（EVSE）之间无法通信之外，我的主要症状是上面报告的版本信息似乎有问题，而且我无法跳过EVSE液晶屏上的“固件下载”状态，如果sigbrd2x通电（我是单独给它们供电的），1060上的EVSE代码也无法启动。感觉像是沟通问题。是否有针对此问题的补丁或变通方案？如果是这样，能否提供一些关于如何解决此问题的文档？ 顺祝商祺！ 克里斯·爱德华兹 Re: EasyEVSE 1060 to sigbrd2x interface issues 嗨@chrisedwards ， 感谢您对 NXP MIMXRT 系列产品的关注！ RT1060 似乎正在读取空闲/上拉的 SPI 总线，但没有收到任何有效数据。这意味着 RT1060 ↔ Sigbrd2x SPI 链路从未建立——这也解释了为什么 EVSE 停留在“固件下载”状态，以及为什么双方无法通信。 建议步骤： - 用示波器测量 SPI 线路（SCK/MOSI/MISO/CS）。如果 MISO 保持高电平，则表示板没有响应 → 确认 0xFF。 - 根据信号板手册中的连接器引脚图检查 EVSE-RT106X-CBL 的接线——确认所有 SPI 线 + GPIO 都已正确连接。 - LCD 与 SPI 引脚冲突：暂时禁用 LCD 并重新读取版本以找出问题所在。 - 请按照用户指南中的开机顺序操作，或者先给主机通电。 此致， 加文 Re: EasyEVSE 1060 to sigbrd2x interface issues 嗨，加文， 检查Sigboard的QSPI闪存： 分别给电路板供电后，我没有在U17的SPI引脚上看到任何数据传输（我认为交换机的固件就是从这里获取的）。我确实在我的电动汽车配置（物理上与U17不同的板）的这些引脚上看到了流量。 检查Sigboard的主机接口SPI： 当给 1060 供电，然后给 sigbrd2x 供电（1060 和 sigbrd 分别供电）时，我在主机连接器的 spi 引脚（19、21、23、24）上看不到任何流量；当我通过连接到 J32 的电缆给 sigbrd 供电，并且 J2 和 J3 设置正确时，也看不到任何流量。 从查阅用户指南（UG10140）可知： 我注意到LED灯D18、D21和D33始终不亮。我的电动汽车充电桩上的 sigbrd2x 确实可以。两种设置下，D24指示灯均不亮。D19 闪烁。 禁用图形用户界面后，调试步骤的最终状态： 通过在 EVSE_config.h 中将 ENABLE_EVSE_UI 设置为 0 来禁用 LCD 后，1060 显卡连接到 sigbrd2x 板后可以正常启动。使用从 1060 显卡 J32 接口为 sigbrd 供电的线缆，我可以获取到 sigboard 硬件的版本号 (v2) 和 sigboard 软件的版本号 (v1.2.0)。 信号板的U17端口仍然没有信号传输，D18、D21、D24和D33指示灯也没有亮起。D19闪烁。信号板主机连接器上的 SPI 引脚仍然没有活动。 所以……算是有进展，但感觉转变根本没有发生。用户指南暗示，LED 指示灯亮起表示开关无法工作。 谢谢，并致以最诚挚的问候！ 克里斯

S32K3 転送完了後の常時接続LPI2Cピン低タイムアウト監視のサポート要請 こんにちは、NXP 私たちはI2C_MASTER_EVENT_PIN_LOW_TIMEOUTイベントを利用して、SDAを低く保つスレーブデバイスの復旧を試みました。テスト中に、転送が完了したとき、または異常状態が検出されたときに、ピンロータイムアウト割り込みがオフになることが確認されました。 企业微信截图_17859835472427.png バスのリアルタイム監視が必要であり、タイムアウト割り込みの有効化は転送終了時に解除されてはならないため、この割り込みは継続的に有効にしておく必要があると考えています。現在のRTD 7.0.1におけるタイムアウト割り込みの処理には欠陥があると考えています。 NXPはこの問題を正しく扱うための公式な推奨や指針を提供できるでしょうか? 敬具 仙龍 Re: S32K3 Request to support always-on LPI2C Pin Low Timeout monitoring after transfer completion こんにちは@wuxianlongさん 詳しい説明とドライバーコードの指摘をありがとうございます。 ご指摘のとおりです。現在のRTD実装では、マスター転送割り込み処理の一環としてLPI2C_IP_MASTER_PIN_LOW_TIMEOUT_INTが有効になり、マスター転送が終了すると再び無効になります。つまり、RTDドライバーは転送完了後にこの割り込みを恒久的なバス監視機構として有効にしないことを意味します。 ハードウェアの観点から見ると、S32K3 LPI2Cモジュールはピンロータイムアウト機能をサポートしています。タイムアウトの閾値はMCFGR3[PINLOW]によって設定され、MSR[PLTF]フラグは選択したSCLまたはSDA回線が設定された閾値より長く低いままの状態で設定できます。リファレンス・マニュアルには、LPI2Cコントローラがアイドル状態でもこのフラグを設定できると記載されています。 しかし、このハードウェア機能があるからといって、RTDドライバーが対応する割り込みを継続的に有効に保つとは限りません。現在のRTD実装は、このイベントをアクティブなマスター転送の文脈で管理しているようです。 転送完了後の連続的なI2Cバス監視では、アプリケーションレベルで処理することが推奨されており、例えばバス復旧ロジックの一部としてMSR[PLTF]の状態を確認するなどです。また、ピンローの状態自体はソフトウェアで解決しなければならないことにもご注意ください。PLTFフラグは低条件がまだ存在している間はクリアできず、新たなSTART条件を生成する前にクリアしなければなりません。 よろしくお願いします、 パベル

IMX95 无法重新父级 can1 我尝试启用 can1 我的设备树引脚遵循 imx95 evk，并禁用 &micfil IMX95_PAD_PDM_CLK__AONMIX_TOP_CAN1_TX 0x39e IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_CAN1_RX 0x39e 但是出现了以下错误。 [ 9.968941] CAN 设备驱动程序接口 [ 9.976800] scmi-pinctrl-imx scmi_dev.8:设置配置错误 -13 [ 9.976814] scmi-pinctrl-imx scmi_dev.8:pin_config_set 操作对引脚 121 失败 [ 9.976893] clk：无法将 can1 重新父级设置为 syspll1_pfd1_di：-1 [ 9.978973] 内部错误：同步外部中止：0000000096000010 [#1] SMP [9.978986]链接的模块：flexcan（+）can_dev neoisp（+）at24 rpmsg_ctrl rpmsg_char pwm_fan enetc4_uio（O）fsl_ecat_enetc4 fsl_ecat_enetc_core moal（O）mlan（O）熔丝 [ 9.979017] CPU: 5 UID: 0 PID: 357 Comm: (udev-worker) Tainted: GMO 6.18.2-rt3-1.0.0-1.0.0 #1 PREEMPT_RT [ 9.979026] 已污染：[M]=MACHINE_CHECK，[O]=OOT_MODULE [ 9.979028] 硬件名称：Axiomtek i.MX95 scm136 板 (DT) [9.979031] pstate：60400009（nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--） [ 9.979035] pc : flexcan_read_le+0x0/0x20 [flexcan] [ 9.979060] lr : flexcan_probe+0x454/0x834 [flexcan] [ 9.979067] sp : ffff800086133820 [9.979069]x29：ffff800086133850 x28：ffff8000862b0000 x27：ffff000085a182a0 有人知道怎么解决这个问题吗？ Re: IMX95 failed to reparent can1 嗨，刘志明 谢谢你的回复。 你说得对，我需要更改系统管理器配置。 Re: IMX95 failed to reparent can1 嗨@HenryHsu 这是我之前在 i.MX95 EVK 上的测试结果，请根据以下修改检查您的 dts 文件。   dts修改：     Zhiming_Liu_2-1785995739657.png diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts index ab7bd4fdaadf..5eb3011f0894 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts @@ -380,7 +380,7 @@ &flexcan1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_flexcan1>; xceiver-supply = <&reg_can1_stby>; - status = "disabled"; + status = "okay"; }; &flexcan2 { @@ -623,23 +623,23 @@ spidev0: spi@0 { }; }; -&micfil { - #sound-dai-cells = <0>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&pinctrl_pdm>; - pinctrl-1 = <&pinctrl_pdm_sleep>; - assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>, - <&scmi_clk IMX95_CLK_AUDIOPLL2>, - <&scmi_clk IMX95_CLK_PDM>; - assigned-clock-parents = <0>, <0>, <0>, <0>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>; - assigned-clock-rates = <3932160000>, - <3612672000>, <393216000>, - <361267200>, <49152000>; - status = "okay"; -}; +// &micfil { +// #sound-dai-cells = <0>; +// pinctrl-names = "default", "sleep"; +// pinctrl-0 = <&pinctrl_pdm>; +// pinctrl-1 = <&pinctrl_pdm_sleep>; +// assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2>, +// <&scmi_clk IMX95_CLK_PDM>; +// assigned-clock-parents = <0>, <0>, <0>, <0>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>; +// assigned-clock-rates = <3932160000>, +// <3612672000>, <393216000>, +// <361267200>, <49152000>; +// status = "okay"; +// }; &mu7 { status = "okay"; @@ -960,19 +960,19 @@ IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x4000031e >; }; - pinctrl_pdm: pdmgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e - >; - }; + // pinctrl_pdm: pdmgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e + // >; + // }; - pinctrl_pdm_sleep: pdmsleepgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e - >; - }; + // pinctrl_pdm_sleep: pdmsleepgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e + // >; + // }; pinctrl_ptn5110: ptn5110grp { fsl,pins = <     系统管理器修改： diff --git a/configs/mx95evk.cfg b/configs/mx95evk.cfg index 9250d02..6722097 100755 --- a/configs/mx95evk.cfg +++ b/configs/mx95evk.cfg @@ -389,7 +389,7 @@ SYS ALL # Resources M7P OWNER # CPUs must be first -CAN_FD1 OWNER +// CAN_FD1 OWNER FSB READONLY IRQSTEER_M7 OWNER LPIT1 OWNER @@ -612,6 +612,7 @@ CAMERA5 OWNER CAMERA6 OWNER CAMERA7 OWNER CAMERA8 OWNER +CAN_FD1 OWNER CAN_FD2 OWNER CAN_FD3 OWNER CAN_FD4 OWNER   结果： Zhiming_Liu_3-1785995783165.png  

EasyEVSE 1060からsigbrd2xへのインターフェースの問題 これは前回の投稿の続報です。 https://community.nxp.com/t5/Power-Energy/EasyEVSE-signal-board-compatibility-and-availability/m-p/2384517 簡単な概要:私はRT1060EVKB/Sigbrd2x EVSEと、v5.0.8ソフトウェアを搭載したRT1064/Sigbrd2x EVを設置しようとしています。これはもともと上の質問への回答として投稿されたものでしたが、技術担当者がスレッドの回答をフォローアップしたかどうか確信が持てませんでした。 ご回答ありがとうございます。作業を再開しましたが、NXPのGitリポジトリから入手したEVSEコードv5.0.8が動作しないという問題が発生しています。ビルドは問題なく、GUIも表示しますが、デバッグインターフェースを使ってバージョン情報を要求しようとすると、1060コードの5.0.8は正しい応答が出てきます。一方、sigbrd2xのバージョンはhw: v 255、sw: v255.255.0と表示されます。どこかの投稿で、1060ボードのLCDディスプレイに通信上の競合問題が発生しているという記事を読んだ記憶がある。sigbrd2xとstepコードのプログラミングはできるので、その側は確実に実行されているとかなり自信があります。ArduinoヘッダーではなくEVSE-RT106X-CBLを使っています。主な症状は(EVとEVSEの両側が連携しない以外に)上で報告されているバージョンで疑わしいこと、そしてEVSE LCDの「ファームウェアダウンロード」状態を突破できず、1060のEVSEコードがsigbrd2xを起動すると起動しません(別々に電源を入れています)。コミュニケーションの問題のように感じられる。この問題に対するパッチや回避策はありますか？もしそうなら、解決方法のドキュメントを教えてもらえますか? よろしくお願いいたします。 クリス・エドワーズ Re: EasyEVSE 1060 to sigbrd2x interface issues こんにちは、 @chrisedwards さん、 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます！ RT1060はアイドル/プルアップされたSPIバスを読み取っているのに有効なデータが返ってこないようです。つまり、RT1060 ↔ Sigbrd2x SPIリンクが確立されなかったことになります。これがEVSEが「ファームウェアダウンロード」のままで、両者が通信しない理由も説明できます。 推奨される手順： - SPIライン（SCK/MOSI/MISO/CS）をスコープします。MISOが高ければ、0xFFが確認される→、委員会は反応しません。 - 信号ボードマニュアルのコネクタピン配置に対してEVSE-RT106X-CBL配線を確認 — すべてのSPIライン+GPIOが正しく接続されていることを確認します。 - LCDとSPIのピン競合：LCDを一時的に無効にして、バージョンを再読み込みして問題を切り分けます。 - ユーザーガイドの電源を入れ順にするか、ホストに先に電源を入れる。 よろしくお願いします、 ギャビン Re: EasyEVSE 1060 to sigbrd2x interface issues こんにちは、ギャビンさん。 sigboardのqspiフラッシュを確認してください。 基板を別々に電源を供給すると、U17のSPIピン(スイッチのファームウェアがここにあると思われます)にはトラフィックが見当たりません。私のEVセットアップ（物理的に異なる基板）のU17のこれらのピンでトラフィックが発生しているのを確認しました。 sigboardのホストインターフェースSPIを確認してください: 1060に電源を供給してからsigbrd2xに電源を供給した場合（1060とsigbrdは別々に電源供給）、またはJ2とJ3が適切に設定されている状態でJ32につながるケーブルを介してsigbrdに電源を供給した場合、ホストコネクタのSPIピン（19、21、23、24）にトラフィックは確認できません。 ユーザーガイド(UG10140)を詳しく調べてみると: LED D18、D21、D33が全く点灯しないことに気づきました。私のEVセットアップに搭載しているsigbrd2xでは、確かに動作します。どちらの設定でもD24は点灯しません。D19が瞬きする。 GUIを無効化した後のデバッグ手順の終了状態： EVSE_config.hでENABLE_EVSE_UIを0に設定してLCDを無効にすると、1060はsigbrd2xに接続している間に起動します。1060のJ32ケーブルでsigbrdを駆動し、sigboardのハードウェア(v2)とsigboard sw v1.2.0のバージョン番号を入手できます。 信号板のU17には依然としてトラフィックがなく、LED D18、D21、24、D33も点灯していません。D19が点滅する。sigboardのホストコネクタ上のSPIピンには、依然として何の反応もありません。 それで...進歩はあるけど、スイッチが全く出てこないように感じる。ユーザーズガイドでは、LEDはスイッチが動作していないことを示しています。 ありがとうございます。よろしくお願いいたします。 クリス

汎用I/O (GPIO) S32K324 MCUに基づく、S32DSを使ってGPIOを高インピーダンス状態に設定する方法。 Re: GPIO ハイ 以前の同様の議論を参照してください: S32K3 GPIO HIGH-Z ピンが以前に内部プルを有効にしていた可能性がある場合、S32K3XXRM のトライステート定義を満たすために、 Siul2_Port_Ip_SetPullSel (..., PORT_INTERNAL_PULL_NOT_ENABLED) を呼び出して PUE=0 を確実にする必要があります。 よろしくお願いいたします ロビン

S32K356 RTD Selection We plan to use the S32K356, but found that only versions 7.0.0 and 7.0.1 are available, but the corresponding autosar...If using autosar R21, which version would you recommend? wenming_0-1786093683425.png Re: S32K356 RTD选择 I also tried SW32K3_S32M27x_RTD_R21-11_6.0.0_P05_D2510, but it failed many times. I suspect it's related to the S32Ds version. I've also tried 3.6.7. So, which version of S32D32 should I use? wenming_0-1786106406261.png Re: S32K356 RTD选择 Hello @wenming , You are right - even if the S32K356 is mentioned in the Supported Derivatives section of the  SW32K3_S32M27x_RTD_R21-11_6.0.0_D2506_ReleaseNotes.pdf , S32K356 project can't be created. The RTD 6.0.0 P05 release notes state that this P05 release adds the S32DS/CT support for the S32K356 derivative.  Best regards, Pavel Re: S32K356 RTD选择 Based on the description of version 6.0.0, it does not support S32K356. wenming_0-1786103361744.png Re: S32K356 RTD选择 Hello @wenming , S32K3 RTD versions 6.0.0 (AUTOSAR R21-11) is the recommended option for S32K356 with AUTOSAR R21. Best regards, Pavel Re: S32K356 RTD选择 Hello @wenming , Thank you for the screenshot. From the error message, this does not look like an S32DS version limitation. The error happens while S32DS is collecting/downloading the items to be installed, and the key message is: Unexpected end of ZLIB input stream The failed items are S32DS platform/debug related artifacts, for example: com.nxp.s32ds.doc.platform.resources com.nxp.s32ds.lrc.gdb.arm64.linux.win32 This usually indicates that one of the artifacts was not downloaded completely or was corrupted during download/extraction. So the issue looks more like an update-site/download/cache problem than a direct RTD 7.0.1 versus S32DS 3.6.7 compatibility limitation. Regarding the Release Note: the listed S32DS version should be understood as the baseline/tested S32DS version for that RTD release. However, S32DS is modular, and the RTD installation may still require related platform, tools, debugger, compiler, or documentation components to be updated or installed if they are missing or outdated in the current installation. Please try the following: Restart S32DS and try the installation again. Make sure the network connection to the NXP update site is stable. If possible, use the official offline update-site ZIP/package instead of relying only on online download during installation. Check that the required GCC 10.2 toolchain is installed in S32DS. If the issue remains, please try a clean S32DS 3.6.x installation and then install the base RTD 7.0.1 package first before applying any additional patch/update package. So based on the current screenshot, I would not conclude that RTD 7.0.1 cannot be used with S32DS 3.6.7. The current error points rather to an incomplete/corrupted download of required S32DS update artifacts. For reference, I was able to install SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip successfully in S32DS 3.6.6. In my setup, I only had to additionally install the GCC 10.2 toolchain required by the S32K3 RTD package.   Best regards, Pavel Re: S32K356 RTD选择 I've upgraded my S32DS version to 3.6.10, which can install RTD 7.0.1 without requiring additional components. We'll use S32DS 3.6.10 + RTD 7.0.1 for development now. If autosar is needed later...If there's news of an update to version R21, please let me know. Thank you. Re: S32K356 RTD选择 wenming_0-1786415389796.png wenming_1-1786415468027.png As shown in the image above, version 6.0.0 QLP01 also fails to install. Another issue is that the RTD release note states that only S32DS 3.6.2 is required for installation. Why is it prompting me to update components when I use version 3.6.7? This is related to the release...The note does not match; what could be the reason? Re: S32K356 RTD选择 How do I resolve the S32DS version incompatibility issue? Why can't I install RTD7.0.1 in S32DS3.6.7, and it keeps prompting me to update? wenming_0-1786513965538.png Re: S32K356 RTD选择 Hello @wenming , Q1: How do I resolve the S32DS version incompatibility issue? Could you please be more specific about the exact incompatibility message you see?   Q2: Why can't I install RTD7.0.1 in S32DS3.6.7, and it keeps prompting me to update? The update prompt itself is not an error. S32DS may ask to update related platform/tool packages when the selected RTD package depends on newer or additional components.   Also, please make sure that the GCC 10.2 toolchain required by the S32K3 RTD package is installed in S32 Design Studio.   Best regards, Pavel Re: S32K356 RTD选择 wenming_0-1786523357428.png This is an error message when installing RTD 7.0.1. Does it seem to be a version limitation? Also, the S32DS version described in the RTD release should, in principle, be ready to install without needing to update the S32DS components. If component updates are still required, it would be better to recommend the newer installation version, which would be easier to use.

S32K1 相補型PWM こんにちは、NXPの専門家の皆様 私たちは日産のエアコンコンプレッサープロジェクトでS32K142チップを使用しました。しかし、日産は、チップのFTMがどのようにして相補的なPWM出力の実現を保証するのかを知りたいと要請した。そのため、この機能の検証のために、説明資料や裏付け資料、またはテストレポートの提供にご協力をお願いしたいと考えております。ありがとう。 Chenxu1_0-1785987344020.png Re: S32K1 Complementary PWM こんにちは@ Chenxu1 チップレベルの保護は主にアーキテクチャ上のもので、1つのチャネルがPWMタイミングを定義し、伴随チャネルは内部補数ロジックによって生成され、オプションのデッドタイム/同期更新ハードウェアにより非重複と整合性のある更新が維持されます。 S32K-RM Rev14.1: Senlent_0-1785999338085.png Re: S32K1 Complementary PWM こんにちは、Senlentさん。ご返信ありがとうございます。 FTMが相補的なPWMを出力する仕組みについては、我々は明確に理解している。チップレベルでは、補完的な波形が位置をずれていないことをどう保証しているのでしょうか?これがお客様が知りたいことです。 Re: S32K1 Complementary PWM こんにちは@ Chenxu1 AN5303および提供されたベアメタルコードを読み取ってテストできます。 https://www.nxp.com/docs/en/application-note/AN5303.pdf Senlent_0-1785997622463.png 参考までに、前回のテスト時に記録した手順をいくつかご紹介します。 相補型PWMモードを設定し、2µsのデッドタイムを挿入しました（プロジェクト全体を保存し忘れましたが、変更は非常に簡単です）。 Senlent_3-1785997707326.png Senlent_1-1785997665931.png Senlent_2-1785997677611.png

FRDM-MCXA156：MCUXpresso IDE 中的 SWO 跟踪（数据、配置文件和中断）功能无法正常工作 大家好， 我目前正在使用FRDM-MCXA156开发板，在调试过程中遇到了SWO（串行线输出）问题。 虽然应用程序调试成功，但我无法在SWO 跟踪窗口中接收任何数据，包括： SWO 数据 SWO概况 SWO中断跟踪 SWO ITM 控制台 为了排查问题，我已经核实了以下内容： 使用配置工具已正确配置SWO 引脚。 TRACE 时钟已启用并配置为96 MHz ，与 MCU 内核时钟匹配（MCXA156 运行频率为 96 MHz）。 该项目正在使用LinkServer和板载MCU-Link探针进行调试。 尽管进行了这些配置，但在调试过程中所有 SWO 跟踪窗口仍然为空。 为了方便参考，我附上了SWO 跟踪配置、 SWO 数据、 SWO 配置文件和其他窗口的截图，以及相关的项目配置。 对于可能导致此问题的原因，或者在FRDM-MCXA156上启用 SWO 跟踪是否需要任何额外的配置步骤，我非常感谢您能提供任何指导或建议。 感谢您抽出时间提供帮助。 #swo #frdm-mcxa156 开发板 MCXA Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 关于之前的帖子， 下面附上 SWO 启用配置和时钟的屏幕截图。 谢谢！ Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 你好@sidsal 对于 FRDM-MCXA156 板，将 SWO 信号连接到板载调试器的电阻 R36 默认情况下为 DNP（未安装）。请您填充 R36 并再次测试一下好吗？ Alice_Yang_0-1786344510075.png 谢谢！ BR 爱丽丝 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 感谢@Alice_Yang指出这一点。我检查了 FRDM-MCXA156 原理图，并确认将 P0_2/SWO 信号连接到板载 MCU-Link 调试器的 R36 标记为 DNP。 我还注意到，在 FRDM-MCXN947 上，等效的 SWO 连接 (R130) 装配了一个 0 Ω 电阻。请问FRDM-MCXA156上的R36是否也应该安装一个0Ω电阻，以便通过板载MCU-Link调试器进行SWO跟踪？ 另外，能否请您解释一下为什么 FRDM-MCXA156 默认情况下 R36 未填充 (DNP)？是否有特殊的电路板设计原因或限制，要求该元件保持空置状态？所以我不能使用SWO功能吗？ 感谢您的帮助。 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 你好@sidsal “请问FRDM-MCXA156上的R36是否也需要连接一个0Ω电阻，才能通过板载MCU-Link调试器进行SWO跟踪？ ” 是的。如果要使用 SWO 功能，则需要安装一个 0 Ω 电阻或相应地焊接连接。 另外，能否请您解释一下，为什么FRDM-MCXA156芯片上的R36插槽默认是空的（DNP）？“ 我认为这是因为并非所有用户都需要 SWO 功能，所以默认情况下没有安装 0 Ω 电阻。 谢谢！ BR 爱丽丝 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 感谢@Alice_Yang的支持。

错误报告模块 MCU：S32K148，144引脚封装 RTD 版本：SW32K1_S32M24x_RTD_4.4_3.0.0_QLP03_D2507 S32 DS 版本：3.6.6 目标操作系统：裸机 主机操作系统：Windows 根据以上信息，我在驱动程序模块中找不到名为“ERM”（或任何类似名称）的模块。我查看了 MCAL 和非 MCAL 模块。 ERM 是否支持作为驱动模块，还是用户需要像以前基于“Processor Expert”的旧框架那样操作原始指针？ Re: Error reporting module 非常感谢您提供的最新信息。 Re: Error reporting module 你好@durga_choudhury 是的，你的理解是正确的。它们作为单独的软件包提供，不包含在 RTD 中。 关于此次分居的原因，我目前正在进行内部审查。但是，值得注意的是，SAF 和 SPD 是根据 ISO 26262 功能安全标准开发的安全导向型软件组件。这使得它们能够集成到需要功能安全支持（最高可达 ASIL D）的应用程序中。 Re: Error reporting module 你好@VaneB 感谢您的跟进。所以你的意思是说，这些模块仅在 SPD 驱动程序中受支持，而不受免费提供的 RTD 支持。是这样吗？ 是否有任何理由不能直接通过位操作模块的寄存器来使用这些模块？我尝试了“Processor Expert”驱动程序模型（使用 S32 DS v2.2）的示例，它似乎可以正常工作。 Re: Error reporting module 你好@durga_choudhury 对于 S32K1 设备，可以使用功能安全外设驱动程序 (SPD)。这些驱动程序包括扩展微控制器错误管理器 (eMCEM)，它支持通过错误注入模块 (EIM) 和错误报告模块 (ERM) 硬件模块进行内存错误注入和检测。 有关 SPD 的更多信息，请联系您的 NXP 代表或您所在地区的授权代理商之一（代理商网络 | NXP 半导体）。 BR，VaneB