T2081プロセッサからMT29F64G08AECAB 8GB NANDフラッシュにアクセスできない こんにちは、 私はT2081 NXPプロセッサを、IFC経由で外部NANDフラッシュMT29F64G08AECABに接続しています。 私の目標は、CodeWarrior上でこのNANDフラッシュの診断テストを実行するか、あるいはCodeWarrior上でこのデバイスのデバイスIDと製造元IDを読み取ることです（そのためのコードは既に作成済みです）。 この目標を達成するために、私は既に以下のことを実行しました。 1. 生成されたT2081QDS_init_core.tcl で、0xFF800000 から始まるサイズ 1MB のNAND IFC 用の LAW を設定しました。 ## LAW3からIFCへのNAND # ローバー mem [CCSR_ADDR 0x000C30] = 0x00000000 # LAWBARL mem [CCSR_ADDR 0x000C34] = 0xFF800000 # 戦争 mem [CCSR_ADDR 0x000C38] = 0x81F00013 2. また、以下のようにNANDに対応するCSPRレジスタとFTIMレジスタを設定しました。 NAND_CS 5 を設定 # NANDフラッシュ、アドレス0xFF800000、サイズ1MB、8ビットNAND、ECC無効 # CSPR_EXT mem [CCSR_ADDR [expr 0x12400C + $NAND_CS * 0x0C]] = 0x00000000 # CSPR mem [CCSR_ADDR [expr 0x124010 + $NAND_CS * 0x0C]] = 0xFF800103 #マスク mem [CCSR_ADDR [expr 0x1240A0 + $NAND_CS * 0x0C]] = 0xFFFF0000 # CSOR mem [CCSR_ADDR [expr 0x124130 + $NAND_CS * 0x0C]] = 0x01082100 # IFC_FTIM0 mem [CCSR_ADDR [expr 0x1241C0 + $NAND_CS * 0x30]] = 0x1E0B0507 # IFC_FTIM1 mem [CCSR_ADDR [expr 0x1241C4 + $NAND_CS * 0x30]] = 0x2929090B # IFC_FTIM2 mem [CCSR_ADDR [expr 0x1241C8 + $NAND_CS * 0x30]] = 0x01203819 # IFC_FTIM3 mem [CCSR_ADDR [expr 0x1241CC + $NAND_CS * 0x30]] = 0x15000000 プロセッサからNANDへ向かうチップセレクトが2つあり(CS5とCS6)、今のところ最初の4GBにアクセスしようとしているので、CS5のみの設定をしています。 3. 設定済みのTLB: 細かい 1M TLB エントリ 5 : 0xFF800000 - 0xFF8FFFFF (NAND キャッシュ禁止、ガード付き) reg ${CAM_GROUP} L2MMU_CAM5 = 0x5000000A1C08000000000000FF80000000000000FF800001 4. インストール済みディレクトリにはこのMT29F64G08AECABのサポートが見つからなかったため、マニュアルに従ってこのデバイス用の.xml(4GB分)を作成し、ここに添付しました。 これらすべてを実行した後、CodeWarriorでNANDデバイスの診断テストを実行すると、以下のエラーが表示されます。 Nisarga_R_0-1786096350786.pngNisarga_R_0-1786096350786.pngNisarga_R_0-1786096350786.pngNisarga_R_0-1786096350786.png 代替案として、このデバイスからデバイスIDを読み取るための簡単なC言語コードを書いてみました。そこで、以下のコードをCode Warriorで書き、ここに添付しました。その結果、IFC_NAND_MDRレジスタを読み戻すと、デバイスIDと一致しない0x124E0000が返されます。 診断テストを実行できない、またはデバイスIDを読み取れないのは、私が何か間違ったことをしているか、何かを見落としているからでしょうか。 参考資料として、関連するT2081QDS_init_core.tclファイルと回路図を添付しました。 よろしくお願いいたします。 ニサルガR   QorIQ T2デバイス Re: Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor 現在、社内チームと話し合っています。 よろしくお願いします。 Re: Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor RCW[IFC_GRP_E2_BASE] = 0でNANDデバイスが起動源として使われていない場合、NANDフラッシュのハードウェア接続は推奨される設計ガイドラインに沿っているようです。 とはいえ、IFC_NAND_MDRレジスタから読み取られるデバイスIDの値はどのような値を想定していますか？ デュアルダイNANDデバイスについては試用・テストしたことがなく、その動作については不明です。 シングルダイNANDフラッシュデバイスに関する当社の経験に基づき、以下の点をご確認いただき、結果を当社にご共有ください。今後の調査に役立てさせていただきます。 1) 可能であれば、完全なIFCレジスタダンプを共有してください。 2) IFCインターフェースのピン-多体化構成を共有すること。 3) Codewarriorのデバッグに関するアップデートがあれば、私にも知らせてください。 4) 下記のRMのセクションを参照し、NANDフラッシュの実装がそこに記載されている情報と一致しているかどうかを確認してください。 a) 13.2 外部信号の説明 b) 13.5 NANDフラッシュ制御装置 c) 13.9 初期化/アプリケーション情報 よろしくお願いします。 Re: Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor 何か進展はありましたか？ありがとう Re: Unable to access MT29F64G08AECAB 8GB NAND Flash from T2081 processor CEとCE2は別々に接続されているのに対し、残りピンはALEなどのように一緒に接続されているようです。二層NANDデバイスには適しているかどうかは不明です。NANDデバイスの回路図を確認してください。

S32K312 - 读取安全调试密码时总线故障 你好， 在 S32K312 上，我尝试使用嵌入式软件中的一个例程来激活安全调试功能。 我的代码执行以下操作： - 读取安全调试密码（ CUST_DB_PSWD_A @ UTEST 0x1B00 0080） - 如果密码未设置（所有字节均为 0xFF），则对其进行编程。 我观察到，当设备处于 Lifecycle CUST_DEL 状态时，这段代码可以正常工作。 但是，当生命周期推进到 OEM_PROD 或 IN_FIELD 时，读取CUST_DB_PSWD_A 会触发总线故障异常。 我在参考手册中没有找到关于这是预期行为的说明。 这正常吗？ 如果可以，嵌入式代码如何检查是否已设置自定义的安全调试密码，而不触发异常？ 谢谢 Re: S32K312 - Bus fault when Reading Secure Debug Password 嗨@Bijam 由于生命周期（LC）已经推进，因此无需验证密码是否已被编程。 无论是否使用 HSE 固件，只有在配置了调试密码并且推进了设备 LC 之后，才能启用安全调试访问。除非密码已经预先设置好，否则无法推进LC。 如果仍需确认密码是否存在，最好的方法是先检查当前的 LC 状态。仅当 MCU 处于 CUST_DEL 状态时才尝试读取/编程 CUST_DB_PSWD_A。如果 MCU 已处于 OEM_PROD 或 IN_FIELD 状态，则完全跳过密码验证。密码必须已经预先设置好。 BR，VaneB Re: S32K312 - Bus fault when Reading Secure Debug Password 谢谢@Valval ， 我假设可以使用寄存器“LC 和 LC 控制 (DCMLCC)”读取当前的 LC 状态。 该寄存器内有两个字段：“DCMRLC - 实际 LC”和“DCMCLC - 当前 LC”。 这两个字段有什么区别？我不太明白“真正的LC”是什么意思。 Re: S32K312 - Bus fault when Reading Secure Debug Password 嗨@Bijam 你的理解是正确的。可以从 DCMRLC 和 DCMCLC 场读取 LC。 DCMRLC（真实 LC）反映存储在 UTEST 内存中的实际 LC 值。 DCMCLC（电流LC）代表实际LC和任何模拟LC的组合： VaneB_0-1788192004223.pngVaneB_0-1788192004223.png VaneB_1-1788192011054.pngVaneB_1-1788192011054.png 例如，如果模拟 LC 推进到 HSE_LC_SIMULATED_IN_FIELD 阶段，则 DCMRLC（实际 LC）应保持 CUST_DEL，而 DCMCLC（当前 LC）将报告 IN_FIELD。重置后，模拟状态将被清除，两个字段应再次指示 CUST_DEL。 如果不使用模拟 LC 推进，则 DCMRLC 和 DCMCLC 应始终报告相同的值。

S32 Design Studio for ARM バージョン2.2のライセンスは期限切れです。 私のS32 Design Studio for ARM Version 2.2のライセンスが期限切れになりました。延長を手伝ってもらえますか?ありがとう！ コード:E5D9-256C-525C-C1D6 Re: S32 Design Studio for ARM Version 2.2 license has expired. こんにちは、 お客様のS32DSライセンスが延長されました。

RT600 4mic实时音频流传输和说话人分离是否可以实现 ⽬前我们⽤了nxp rt600做⾳频项⽬，这个芯⽚有降噪 ，说话⼈识别和实时语⾳流传输的功能吗？ 因为我下了你们的例程包，⾥⾯较为完整的功能只有 语⾳回环和⾳质增强还有本地的语⾳识别， 不过这跟我上⾯提的都不想关， 具体这个是要怎么和你们的技术⽀持联系， 可能邮件的⽅式会更详细描述我的问题和需求 Re: RT600 4mic实时音频流传输和说话人分离是否可以实现 Dear @isdin909 , 感谢您对RT600 音频功能的提问。 关于I.MX RT600音频功能说明： 1. 降噪（Noise Reduction）✅ 支持 RT600 支持 AI/ML 降噪，主要通过以下两种方式实现： a. Conversa Voice Suite：包含基于机器学习的噪声消除（MLNR），可有效去除键盘声、狗叫声、警报声等非语音噪音，同时提供全双工回声消除（AEC）和自适应多麦克风波束成形。该方案支持 RT600（HiFi4 DSP），但属于商业授权软件（需付费）。 b.AI Noise Reduction（独立模块）：NXP 也提供独立的 AI 降噪模块，可在 RT600 上部署。 2. 说话人识别（Speaker Identification）⚠️ 非原生支持 RT600 本身没有内置的说话人识别软件。说话人识别功能需要集成第三方软件来实现，且存在授权挑战。 3. 实时语音流传输（Real-time Audio Streaming）✅ 支持 RT600 支持实时音频流传输。硬件层面，HiFi4 DSP 通过 DMA + I²S/SAI 接口实现低 CPU 占用的音频数据传输；软件层面，Conversa 支持全双工实时语音通话（VoIP），并已通过 Microsoft Teams 认证。 此外，RT600 也支持通过 Wi-Fi/BT 模块（如 IW611）进行无线音频流传输（A2DP/HFP）。 关于如何获取技术支持： 1. Voice & Audio 专项邮件（最推荐） 针对 Conversa、说话人识别等语音音频高级功能，直接发邮件至：[email protected] 这是 NXP Voice & Audio R&D 团队的专属邮箱，可以详细描述您的项目需求（降噪、说话人识别、实时流传输），他们会评估是否提供 Conversa 授权或定制方案。 2. NXP 技术支持门户（提交工单） 登录 support.nxp.com 提交 Support Ticket，选择产品 i.MX RT600，可以附上详细的需求描述文档。 3. NXP论坛社区 访问 community.nxp.com， NXP 工程师监看并回复。

S32K1 セーフティ ペリフェラル ドライバ 私の「通常」(つまり、NDAや同様の契約に署名していないのですが、NXPアカウントからK3およびK5ファミリのセーフティ ペリフェラル ドライバにアクセスできます。しかしK1ファミリーでは、Digikeyのような認可された代理店からペイメントでのみ入手できるようです。下記のスクリーンショットをご覧ください。 これにはどのような理由があるのか疑問に思っています。K1は非常に成熟した製品なので、K3よりもソフトウェアが使いやすいはずだと予想していましたが、実際は逆のようです。 私の理解が間違っているのでしょうか？ durga_choudhury_0-1788184794909.pngdurga_choudhury_0-1788184794909.png Re: S32K1 safety peripheral drivers こんにちは、@Julián_AragónM さん サポートありがとうございます。 Re: S32K1 safety peripheral drivers こんにちは、 @durga_choudhury さん、 ご指摘のDigiKey配布用のイメージが見つからないようです。 最近、SAF/SPDの提供表と製品ページにいくつかの変更がありました。S32K1のSPDは標準のSWの一部なので、アクセスに問題はないはずです。 Julin_AragnM_0-1788212683758.pngJulin_AragnM_0-1788212683758.png コミュニティを通じてプライベートメッセージを送りました。 よろしくお願いします、 ジュリアン

The connection between AUTOSAR Network Management sleep/wake-up Hello, I am currently debugging EcuM and Network Management. I have consulted some specification manuals, but I still have some confusion and would like to request guidance. Does the sleep/wake-up of Network Management necessarily require coordination with EcuM (i.e., EcuM validates the wake‑up cause)? During the Network Management sleep/wake‑up process, does the ECU need to go to sleep (i.e., EcuM sleep)? If the answer to question 1 is yes, then EcuM obtains wake‑up events through the interface EcuM_SetWakeupEvent. However, the AUTOSAR EcuM specification SWS_EcuM_04318 states: “Wakeup events that are not associated to the selected sleep mode shall be ignored.” How should I understand this? The AUTOSAR EcuM specification also contains two entries regarding the interface EcuM_ValidateWakeupEvent – SWS_EcuM_02790 and SWS_EcuM_02791. It says that wake‑up sources associated with a ComM channel shall be effective in any phase. Does this mean that in any phase, a wake‑up event can be pended (i.e., successfully pass through EcuM_SetWakeupEvent) and then be validated? Re: The connection between AUTOSAR Network Management sleep/wake-up Hi, 1. Does NM sleep/wake-up require EcuM coordination? Not necessarily. NM/ComM manages network communication, while EcuM manages ECU power states. EcuM wakeup validation is mainly relevant when the ECU actually enters an EcuM sleep state.  2. Does NM sleep mean the ECU must enter EcuM sleep? No. The network can enter Bus-Sleep while the ECU remains in RUN mode and continues executing local functions. 3. How to understand SWS_EcuM_04318? It means EcuM only accepts wakeup events that are configured for the currently selected sleep mode. Wakeup events from sources not enabled for that sleep mode are ignored. It prevents spurious hardware events from waking the ECU unintentionally. 4. Can ComM-related wakeup sources be validated in any EcuM phase? Yes. This is a deliberate special case. Generic wakeup sources are only accepted during SLEEP, but ComM-channel-associated sources (e.g., CAN wakeup frame) can be pended via EcuM_SetWakeupEvent and validated via EcuM_ValidateWakeupEvent in any EcuM phase. This allows a wakeup event to abort an ongoing Go-Sleep sequence — which is the key mechanism linking NM wakeup back to EcuM. In short: NM sleep ≠ ECU sleep, and ComM-linked wakeup sources receive special handling in EcuM, allowing validation outside the normal wakeup sequence.  BR, Petr 回复： The connection between AUTOSAR Network Management sleep/wake-up Hello, thank you for your answer. I still have some questions regarding your response. I apologize for bothering you repeatedly, and I would like to thank you in advance. I understand that the sleep/wake-up of Network Management also seems to require EcuM to validate the wake-up source, because in the passive mode of Network Management, EcuM validation of the wake-up source is required. After the wake-up source associated with the ComM channel is successfully validated, EcuM calls the ComM interface, and then the network can wake up. In your first answer, you said that EcuM's wake-up validation is only necessary when the ECU actually enters the EcuM sleep state. So, I interpret this as meaning that after Network Management sleep/wake-up, the ECU also needs to enter the EcuM sleep state, and then go through the EcuM wake-up validation process. However, this seems to conflict somewhat with your second answer. I'm not sure whether my understanding is correct. In your third and fourth answers, SWS_EcuM_04318 states that EcuM only accepts wake-up events configured for the currently selected sleep mode. In answer 4, you said that ComM-related wake-up sources are a special case. So, can ComM-related wake-up sources simply ignore the constraints of SWS_EcuM_04318, or must I, during the design phase, configure all ComM-related wake-up sources as wake-up events for the sleep mode? Does the wake-up source need to be enabled first? EcuM calls EcuM_EnableWakeupSource for enabling during the sleep phase. Only after enabling can it be pended (successfully pass the EcuM_SetWakeupEvent interface filtering)? If so, regarding the statement in answer 4 that "ComM-channel-associated sources (e.g., CAN wakeup frame) can be pended via EcuM_SetWakeupEvent," does this pend operation only occur during the EcuM sleep phase, and then validation occurs in any phase of EcuM? Or is the enabling step done by other drivers themselves, or are there other scenarios? I look forward to your answers.

关于使用S32K396控制板驱动100kW永磁同步逆变器的咨询 尊敬的恩智浦技术支持团队： 你好， 我们目前正在进行一个项目，旨在开发一款100千瓦级的永磁同步电机逆变器驱动模块。 我们的目标规格大约如下： 直流母线电压：800 伏 电机相电流：250 安培 电机类型：永磁同步电机 功率级：约100千瓦 在研究过程中，我们对恩智浦半导体的“带S32K396的三相永磁同步电机控制开发套件”产生了浓厚的兴趣。 由于我们需要开发自己的 100 kW 功率级，我们的计划是只使用开发套件中的 S32K396 控制板，并自行设计栅极驱动器和 IGBT 功率级。 在审阅了开发套件的原理图后，我们了解到控制板通过外部连接器与功率级连接，这些外部连接器包括： 用于控制三相逆变器的PWM信号 解析器相关信号 三相电流检测信号 直流母线电压检测 直流母线电流检测 请问我们的理解是否正确？ 如果是这样，我们预期的系统配置如下： 使用 NXP S32K396 控制板生成我们定制的 100 kW 逆变器功率级所需的 PWM 信号。 使用霍尔效应电流传感器进行相电流测量，并将相应的模拟信号馈送到控制板。 参考 NXP 开发套件/电源板中使用的旋转变压器电路，实现旋转变压器接口电路。 向控制板的ADC输入端提供所需的直流母线电压和电流检测信号。 换句话说，我们希望使用现有的 S32K396 控制板和电机控制软件平台，同时用我们自己的 800 V / 250 Arms 逆变器硬件替换原有的功率级。 我们非常希望您能就以下问题提供建议： 在这种配置下，使用 S32K396 控制板和定制的大功率逆变器级是否可行？ 将外部栅极驱动器/功率级连接到控制板时，有哪些接口要求、限制或注意事项需要考虑？ 是否有任何应用笔记、参考设计、原理图、软件示例或其他技术文档可以帮助开发基于 S32K396 的 100 kW 级 PMSM 逆变器？ NXP 是否提供，或者 NXP 能否推荐任何用于约 100 kW、800 V PMSM 逆变器的参考设计或评估平台？ 任何补充信息或建议都将不胜感激。 感谢您的支持。 顺祝商祺！ 亨文善 Re: Inquiry About Using the S32K396 Control Board for a 100 kW PMSM Inverter 您好， 你的理解基本正确。只要将所需的反馈信号（相电流、直流母线电压/电流、转子位置、故障信号等）适配到新的功率级接口，S32K396 控制器就可以独立于 MCSPTR2AK396 套件中包含的低压逆变器使用。MCSPTR2AK396 套件主要用作低压电机控制开发平台和软件使能套件。  对于 100 kW 左右的牵引级应用，您可能还需要查看 NXP 的 EV 牵引逆变器参考设计（EV-INVERTERGEN1 / EV-INVERTERGEN2），这些设计是为高压、大功率电动汽车逆变器应用而设计的，并且比 MCSPTR2AK396 评估套件提供了更相关的参考点。S32K39 系列是恩智浦牵引逆变器生态系统中受支持的电机控制平台之一。  MCSPTR2AK396 文档 (AN14481) 仍然可以作为 PMSM FOC 软件架构、外设配置、电流检测、旋转变压器集成和 FreeMASTER/MCAT 支持的参考资料。  您可以在这里找到有关电动汽车牵引逆变器平台的更多信息： NXP 电动汽车电源逆变器解决方案。 BR，彼得

Can the RT600 4mic achieve real-time audio streaming and speaker separation? We are currently using the NXP RT600 for a video project. Does this chip have noise reduction, speaker recognition, and real-time speech streaming capabilities? Because I downloaded your example package, the only relatively complete functions are speech loops, speech quality enhancement, and local speech recognition. However, this has nothing to do with what I mentioned above. Specifically, how do we contact your technical support team about this? An email might provide a more detailed description of my problem and needs. Re: RT600 4mic实时音频流传输和说话人分离是否可以实现 Dear @isdin909 , Thank you for your question about the RT600's audio functions. Audio function description of the I.MX RT600: 1. Noise Reduction✅ support The RT600 supports AI/ML noise reduction, primarily through the following two methods: a. Conversa Voice Suite: Includes machine learning-based noise cancellation (MLNR) to effectively remove non-speech noise such as keyboard clicks, dog barks, and alarm sounds, while also providing full-duplex echo cancellation (AEC) and adaptive multi-microphone beamforming. This solution supports the RT600 (HiFi4 DSP), but is commercial licensed software (requires payment). b. AI Noise Reduction (Standard Module): NXP also offers a standalone AI noise reduction module that can be deployed on the RT600. 2. Speaker Identification⚠️ Non-native support The RT600 does not have built-in speaker recognition software. Speaker recognition functionality requires integration with third-party software, which presents licensing challenges. 3. Real-time Audio Streaming✅ support The RT600 supports real-time audio streaming. On the hardware side, the HiFi4 DSP achieves low CPU usage audio data transmission via DMA + I²S/SAI interfaces; on the software side, Conversa supports full-duplex real-time voice calls (VoIP) and is Microsoft Teams certified. In addition, the RT600 also supports wireless audio streaming (A2DP/HFP) via Wi-Fi/BT modules (such as the IW611). Regarding how to obtain technical support: 1. Voice & Audio Dedicated Email (Highly Recommended) For inquiries about advanced voice and audio features such as Conversa and speaker recognition, please email: [email protected] This is the dedicated email address for the NXP Voice & Audio R&D team. You can describe your project requirements in detail (noise reduction, speaker recognition, real-time streaming) and they will assess whether to provide a Conversa license or a customized solution. 2. NXP Technical Support Portal (Submit a Support Ticket) Log in to support.nxp.com to submit a Support Ticket, select the product i.MX RT600, and you can attach a detailed requirements description document. 3. NXP Forum Community Visit community.nxp.com NXP engineers will review and respond.

在 i.MX 95 上，能否将任何 LPSPI 外设的所有权从 A55 更改为 M7？ Re: Can any LPSPI peripheral be change ownership from A55 to M7 on i.MX 95? 你好， 是的，这是通过系统管理器固件中的 TRDC（可信资源域控制器）配置来实现的。 您可以直接在mx95evk.cfg中进行此操作，或者您可以使用系统管理器工具中的i.MX 配置工具。 顺祝商祺！

Inquiry About Using the S32K396 Control Board for a 100 kW PMSM Inverter Dear NXP Support Team, Hello, We are currently working on a project to develop a 100 kW-class PMSM inverter drive module. Our target specifications are approximately: DC-link voltage: 800 V Motor phase current: 250 Arms Motor type: PMSM Power level: approximately 100 kW During our research, we became very interested in NXP's "3-Phase Permanent Magnet Synchronous Motor Control Development Kit with S32K396." Since we need to develop our own 100 kW power stage, our plan is to use only the S32K396-based control board from the development kit and design the gate-driver and IGBT power stage ourselves. After reviewing the schematics of the development kit, our understanding is that the control board interfaces with the power stage through external connectors, including: PWM signals for controlling the three-phase inverter Resolver-related signals Three-phase current sensing signals DC-link voltage sensing DC-link current sensing Could you please confirm whether our understanding is correct? If so, our intended system configuration would be as follows: Use the NXP S32K396 control board to generate the PWM signals for our custom 100 kW inverter power stage. Use Hall-effect current sensors for phase-current measurement and feed the corresponding analog signals to the control board. Implement the resolver interface circuitry by referring to the resolver circuit used in the NXP development kit/power board. Provide the required DC-link voltage and current sensing signals to the ADC inputs of the control board. In other words, we would like to use the existing S32K396 control board and motor-control software platform while replacing the original power stage with our own 800 V / 250 Arms inverter hardware. We would appreciate your advice regarding the following questions: Is it feasible to use the S32K396 control board in this configuration with a custom high-power inverter stage? Are there any interface requirements, limitations, or precautions that we should consider when connecting an external gate-driver/power stage to the control board? Are there any application notes, reference designs, schematics, software examples, or other technical documents that would be helpful for developing a 100 kW-class PMSM inverter based on the S32K396? Does NXP offer, or can NXP recommend, any reference design or evaluation platform for an approximately 100 kW, 800 V PMSM inverter? Any additional information or recommendations would be greatly appreciated. Thank you for your support. Best regards Hyeong Mun Seon Re: Inquiry About Using the S32K396 Control Board for a 100 kW PMSM Inverter Hi, Your understanding is generally correct. The S32K396 controller can be used independently of the low-voltage inverter included with the MCSPTR2AK396 kit, provided the required feedback signals (phase currents, DC bus voltage/current, rotor position, fault signals, etc.) are adapted to the new power stage interface. The MCSPTR2AK396 kit is primarily intended as a low-voltage motor-control development platform and software enablement kit.  For traction-class applications around 100 kW, you may also want to review NXP's EV traction inverter reference designs (EV-INVERTERGEN1 / EV-INVERTERGEN2), which are intended for high-voltage, high-power electric vehicle inverter applications and provide a more relevant reference point than the MCSPTR2AK396 evaluation kit. The S32K39 family is one of the supported motor-control platforms within NXP's traction inverter ecosystem.  The MCSPTR2AK396 documentation (AN14481) can still be useful as a reference for the PMSM FOC software architecture, peripheral configuration, current sensing, resolver integration, and FreeMASTER/MCAT support.  You can find additional information on the EV traction inverter platforms here: NXP EV Power Inverter Solutions. BR, Petr

AUTOSAR 网络管理睡眠/唤醒之间的连接 您好，我目前正在调试 EcuM 和网络管理功能。我查阅了一些规格手册，但仍然有些困惑，希望得到指导。 网络管理的睡眠/唤醒是否必须与 EcuM 协调（即 EcuM 验证唤醒原因）？ 在网络管理睡眠/唤醒过程中，ECU 是否需要进入睡眠状态（即 EcuM 睡眠）？ 如果问题 1 的答案是肯定的，则 EcuM 通过接口获取唤醒事件。 EcuM_SetWakeupEvent 。然而，AUTOSAR EcuM 规范 SWS_EcuM_04318 指出： “与所选睡眠模式无关的唤醒事件将被忽略。” 我应该如何理解这句话？ AUTOSAR EcuM 规范中还包含两个关于接口的条目。 EcuM_ValidateWakeupEvent – SWS_EcuM_02790 和 SWS_EcuM_02791。它指出与通信通道关联的唤醒源在任何阶段都应有效。这是否意味着在任何阶段，唤醒事件都可以被挂起（即，成功通过）。 然后进行验证（EcuM_SetWakeupEvent）？ Re: The connection between AUTOSAR Network Management sleep/wake-up 您好， 1. NM 睡眠/觉醒是否需要 EcuM 协调？ 未必。NM/ComM 管理网络通信，而 EcuM 管理 ECU 电源状态。ECU唤醒验证主要与ECU实际进入ECU睡眠状态有关。 2. NM睡眠是否意味着ECU必须进入ECUM睡眠状态？ 不。网络可以进入总线睡眠状态，而 ECU 仍处于运行模式并继续执行本地功能。 3. 如何理解 SWS_EcuM_04318？ 这意味着 EcuM 只接受为当前选定的睡眠模式配置的唤醒事件。来自未在该睡眠模式下启用的唤醒源的唤醒事件将被忽略。它可以防止虚假硬件事件意外唤醒 ECU。 4. 在任何 EcuM 阶段，ComM 相关唤醒源是否可以得到验证？ 是的。这是一个特例。通用唤醒源仅在睡眠期间被接受，但通信通道关联的源（例如，CAN 唤醒帧）可以通过 EcuM_SetWakeupEvent 挂起，并通过 EcuM_ValidateWakeupEvent 在任何 EcuM 阶段进行验证。这样，唤醒事件就可以中止正在进行的 Go-Sleep 序列——这是将 NM 唤醒与 EcuM 连接起来的关键机制。 简而言之：NM睡眠≠ECU睡眠，并且与ComM连接的唤醒源在ECUM中会得到特殊处理，从而允许在正常的唤醒序列之外进行验证。 BR，彼得 回复： The connection between AUTOSAR Network Management sleep/wake-up 您好，谢谢您的回复。关于您的回复，我还有一些疑问。对于多次打扰您，我深表歉意，并提前感谢您的帮助。 我了解到，网络管理的睡眠/唤醒似乎也需要 EcuM 验证唤醒源，因为在网络管理的被动模式下，需要 EcuM 验证唤醒源。与 ComM 通道关联的唤醒源验证成功后，EcuM 调用 ComM 接口，然后网络即可唤醒。在你的第一个回答中，你提到只有当 ECU 实际进入 EcuM 睡眠状态时，才需要进行 EcuM 唤醒验证。因此，我的理解是，在网络管理休眠/唤醒之后，ECU 也需要进入 EcuM 休眠状态，然后经过 EcuM 唤醒验证过程。然而，这似乎与你的第二个回答有些矛盾。我不确定我的理解是否正确。 在你的第三个和第四个答案中，SWS_EcuM_04318 表示 EcuM 只接受为当前选定的睡眠模式配置的唤醒事件。在第 4 个答案中，您提到与通信相关的唤醒源是一个特例。那么，ComM 相关唤醒源能否简单地忽略 SWS_EcuM_04318 的限制，还是我必须在设计阶段将所有 ComM 相关唤醒源配置为睡眠模式的唤醒事件？ 是否需要先启用唤醒源？EcuM 调用 EcuM_EnableWakeupSource 以在睡眠阶段启用唤醒功能。只有启用后才能挂起（成功通过 EcuM_SetWakeupEvent 接口过滤）？如果是这样，关于答案 4 中的声明“ComM 通道关联的源（例如，CAN 唤醒帧）可以通过 EcuM_SetWakeupEvent 挂起”，这种挂起操作是否只在 EcuM 睡眠阶段发生，然后在 EcuM 的任何阶段进行验证？或者，启用步骤是由其他驾驶员自行完成的，还是存在其他情况？ 期待您的回复。

im8QMのA72コア上のCNTFRQ_el0の値を変更します。 こんにちは！ im8QMのA72コアのCNTFRQ_el0の値を変更するにはどうすればよいですか？現在は8000000ですが、16Mに変更したいです。 ありがとう！ Re: 修改im8QM的A72核的CNTFRQ_el0的值 i.MX8QMでは、A72のCNTFRQ_EL0に対応する実際のカウント周波数を8MHzから16MHzに変更することは推奨されず、事実上不可能です。その理由は、CNTFRQ_EL0はソフトウェアがシステムカウンタの周波数を「検出」するためのレジスタに過ぎず、ソフトウェアがこのレジスタ値を書き込めたとしても、ハードウェアのシステムカウンタの実際の周波数は変更されないためです。 i.MX8QMの場合、リファレンスマニュアルには、SCU ROMがシステムカウンタを有効にし、24MHzクロックを入力すると記載されています。システムカウンタは内部でこれを分周して8MHzクロックを生成します。関連するクロックルートも、システムコントローラファームウェアによって管理されるクロックドメインに属します。ドキュメントには、SCU_MSLICE0_CLK_ROOT / SCU_MSLICE1_CLK_ROOTをSYS COUNTERのルートクロックとして使用でき、ルートクロックの生成はSC FWによって制御されることが示されています。 もしあなたが今これを読んでいるなら： CNTFRQ_EL0 = 8000000 次のように変更したいです。 CNTFRQ_EL0 = 16000000 区別すべき点が2つある。 CNTFRQ_EL0 レジスタの値 だけを変更すると、一部のソフトウェアはタイマーが16MHzであると「認識」しますが、ハードウェアカウンタは依然として8MHzで動作するため、時間、スケジューリング、レイテンシ、プロファイリングなどにエラーが発生し、すべてが通常の2倍の値になります。 システムカウンタは実際に16MHzに変更されました。 私が調べたi.MX8QMのドキュメントによると、システムカウンタはSCU ROM内で24MHz / 3 = 8MHzに初期化されており、16MHzに変更するための公開されているレジスタや手順は存在しません。i.MX8シリーズに関する同様の議論でも、システムカウンタの周波数はハードウェアで固定されており変更できないことが明確に述べられています。 Linux/RTOSで正しい周波数を使用することが目的であれば、CNTFRQ_EL0を8000000に設定したまま、デバイスツリー/ファームウェア/ブートローダーがタイマー周波数を誤って上書きしていないか確認することをお勧めします。16MHzの要件を満たすためだけにCNTFRQ_EL0を変更しないでください。ただし、意図的に非現実的な周波数で実験を行う場合は除きます。 結論：i.MX8QMのA72 CNTFRQ_EL0レジスタの値を8MHzから16MHzに変更しないでください。実際のシステムカウンタはSCU/SCFWによって初期化され、実際には8MHzです。レジスタ値だけを変更してもハードウェア周波数は変更されず、システムタイムベースが乱れるだけです。 Re: 修改im8QM的A72核的CNTFRQ_el0的值 こんにちは： お返事ありがとうございます！ SCUまたはSCFWでシステムカウンタを16MHzに設定するための方法またはデモコードを提供していただけますか？ ありがとう！ Re: 修改im8QM的A72核的CNTFRQ_el0的值 SCFWでできることは、通常SCFWポーティングキットのボード上でボード固有のファームウェアをカスタマイズすることです。しかし、取得したSCFWのガイダンスは、システムカウンタの周波数変更フックではなく、ボード/クロック/リソースのカスタマイズ全般について説明している。他のNXPプラットフォームの議論では、同じクラスのシステムカウンタ周波数がハードウェア固定とされ、周波数ID / CNTFRQ_EL0スタイルの値を書き込んでも実際のカウンタクロックは変わりません。 ですので、16 MHzをSCFWに書き込むデモコードは提供しません。なぜなら、実際のSystem Counterハードウェアのクロックや分圧器を変更しない限り、ソフトウェア上で誤った周波数が生まれるだけだからです。 安全な診断/デモ方法としては、実際のカウンターレートを確認することです。 コピー /* * A72 上で特権ファームウェアまたは初期のベアメタルコードから実行します。  * これはアーキテクチャカウンタと CNTFRQ_EL0 のみを読み取ります。 * システムカウンターを変更しようとはしません。 */ #include static inline uint64_t read_cntpct_el0(void) { uint64_t v;     __asm__ volatile("mrs %0, cntpct_el0" : "=r"(v));     return v; } static inline uint32_t read_cntfrq_el0(void) { uint64_t v;     __asm__ volatile("mrs %0, cntfrq_el0" : "=r"(v));     return (uint32_t)v; } void check_arch_timer_frequency(void) { uint32_t reported_hz = read_cntfrq_el0();     /* * cntpct デルタを独立した既知の良好な遅延源と比較する      * SCUタイマー、ボードオシロスコープGPIOトグルタイミング、またはその他 * 校正済みタイマー。i.MX8QMでは、約8,000,000カウント/秒が期待できます。      */ uint64_t t0 = read_cntpct_el0();     /* CNTFRQ_EL0 に基づかない、ボードで校正された 1 秒の遅延に置き換えます。*/     external_calibrated_delay_1s(); uint64_t t1 = read_cntpct_el0(); uint64_t measured_counts_per_sec = t1 - t0;     board_print(3,      "CNTFRQ_EL0 は %u Hz を報告し、CNTPCT は %llu カウント/秒を測定しました\n"、         reported_hz、         計測カウント数（1秒あたり） } Linuxや他のOSが正しいタイムベースを使うことを目的とする場合は、CNTFRQ_EL0を実際のカウンター周波数、つまりRMのテキストでi.MX8QMの8 MHzに合わせるように保つようにしてください。ハードウェアの実際のレートを変更せずに16MHzに設定すると、タイマーの遅延や時間計測が正しくスケーリングされなくなります。 要点：i.MX8QMの場合、システムカウンタはSCU ROMによって初期化される8MHzのハードウェアタイムベースとして扱われます。SCFWによるカスタマイズは、これを16MHzに変更するためのサポートされた方法ではありません。

S32K312 - Bus fault when Reading Secure Debug Password Hello, On the S32K312, I'm trying to activate the Secure Debug feature using a routine in my embeded software My code is doing the following : - Read Secure debug Password (CUST_DB_PSWD_A @ UTEST 0x1B00 0080) - if the Password is not set (all bytes @ 0xFF), program it What I'm observing is that when the device is in Lifecycle CUST_DEL, this code is working correctly. However, when the lifecycle is advanced to either OEM_PROD or IN_FIELD, reading  the CUST_DB_PSWD_A triggers a bus fault exception. I was not able to identify in the reference Manual that this was the expected behavior. Is this normal ? And if yes, how can the embedded code check if a custom secure Debug password is programmed or not, without trigerring an exception ? Thank you Re: S32K312 - Bus fault when Reading Secure Debug Password Hi @Bijam  Since the Lifecycle (LC) has already been advanced, there is no need to verify whether the password has been programmed. Whether HSE firmware is used or not, secure debug access can only be enabled after the debug password has been configured and the device LC has been advanced. The LC cannot be advanced unless the password has already been programmed. If you still need to confirm that the password is present, the best approach is to check the current LC state first. Only attempt to read/program CUST_DB_PSWD_A when the MCU is in CUST_DEL. If the MCU is already in OEM_PROD or IN_FIELD, skip the password verification entirely. The password must already be programmed. BR, VaneB Re: S32K312 - Bus fault when Reading Secure Debug Password Hi @Bijam  Your understanding is correct. The LC can be read from the DCMRLC and DCMCLC fields. DCMRLC (Real LC) reflects the actual LC value stored in the UTEST memory. DCMCLC (Current LC) represents a combination of the real LC and any simulated LC: VaneB_0-1788192004223.pngVaneB_0-1788192004223.pngVaneB_0-1788192004223.png VaneB_1-1788192011054.pngVaneB_1-1788192011054.pngVaneB_1-1788192011054.png For example, if a simulated LC advancement is performed to the HSE_LC_SIMULATED_IN_FIELD stage, the DCMRLC (Real LC) should remain CUST_DEL, while the DCMCLC (Current LC) would report IN_FIELD. After a reset, the simulated state is cleared, and both fields should again indicate CUST_DEL. If simulated LC advancement is not used, DCMRLC and DCMCLC should always report the same value. Re: S32K312 - Bus fault when Reading Secure Debug Password Thanks @Valval , I'm assuming I can read the current LC state using the register "LC and LC Control (DCMLCC)". There are two fields inside this register: "DCMRLC - Real LC" and "DCMCLC - Current LC". What is the difference betwen both field ? I don't really understand what "Real LC" means.

S32K1 safety peripheral drivers With my 'regular' (i.e. without having signed any kind of NDA or similar arrangements) NXP account, I can access the Safety Peripheral driver for the K3 and K5 family. But it seems for the K1 family it can only be obtained for payment from authorized agents such as Digikey. Please see the screen shot below. I am wondering about the rationale behind this. I'd have expected that, since the K1 is a very mature product, it's software should be more readily available compared to the K3, but it seems it is the other way around. Or is my understanding incorrect? durga_choudhury_0-1788184794909.pngdurga_choudhury_0-1788184794909.png Re: S32K1 safety peripheral drivers Hello @Julián_AragónM  Thank you very much for your support. Re: S32K1 safety peripheral drivers Hello @durga_choudhury, It seems the image for Digikey distribution you've mentioned is missing. Recently there have been some changes in the SAF/SPD offering table and product page. S32K1's SPD is part of the Standard SW offering, so there should be no issues with access. Julin_AragnM_0-1788212683758.pngJulin_AragnM_0-1788212683758.png I have sent you a private message through community. Best regards, Julián

RT600 4micは、リアルタイムのオーディオストリーミングとスピーカー分離を実現できますか？ 現在、ビデオプロジェクトでNXP RT600を使用しています。このチップには、ノイズリダクション、話者認識、リアルタイム音声ストリーミング機能はありますか？ サンプルパッケージをダウンロードしてみたところ、比較的完成度の高い機能は、音声ループ、音声品質向上、およびローカル音声認識のみでした。 しかし、これは私が上で述べたこととは全く関係ありません。 具体的に、この件について御社の技術サポートチームに連絡するにはどうすればよいですか？ メールであれば、私の抱えている問題やニーズをより詳しく説明できるかもしれません。 Re: RT600 4mic实时音频流传输和说话人分离是否可以实现 @isdin909様、 RT600のオーディオ機能に関するご質問、ありがとうございます。 I.MX RT600のオーディオ機能の説明： 1.騒音低減✅ サポート RT600は、主に以下の2つの方法により、AI/MLノイズリダクションをサポートしています。 a. Conversa Voice Suite：機械学習ベースのノイズキャンセリング（MLNR）を搭載し、キーボードのクリック音、犬の鳴き声、アラーム音などの非音声ノイズを効果的に除去するとともに、全二重エコーキャンセレーション（AEC）と適応型マルチマイクビームフォーミングを提供します。このソリューションはRT600（HiFi4 DSP）に対応していますが、商用ライセンスソフトウェア（有料）です。 b. AIノイズリダクション（標準モジュール）：NXPは、RT600に搭載可能なスタンドアロンのAIノイズリダクションモジュールも提供しています。 2. 話者の特定⚠️ ネイティブ以外のサポート RT600にはスピーカー認識ソフトウェアが内蔵されていません。スピーカー認識機能にはサードパーティ製ソフトウェアとの連携が必要となり、ライセンス上の課題が生じます。 3. リアルタイムオーディオストリーミング✅ サポート RT600はリアルタイムオーディオストリーミングに対応しています。ハードウェア面では、HiFi4 DSPがDMA + I²S/SAIインターフェースを介してCPU使用率を抑えたオーディオデータ伝送を実現し、ソフトウェア面では、Conversaが全二重リアルタイム音声通話（VoIP）に対応し、Microsoft Teamsの認証を取得しています。 さらに、RT600はWi-Fi/BTモジュール（IW611など）を介したワイヤレスオーディオストリーミング（A2DP/HFP）にも対応しています。 技術サポートを受ける方法について： 1. 音声・オーディオ専用メール（強く推奨） Conversaや話者認識などの高度な音声・オーディオ機能に関するお問い合わせは、[email protected]までメールでご連絡ください。 こちらはNXPの音声・オーディオ研究開発チーム専用のメールアドレスです。プロジェクトの要件（ノイズリダクション、話者認識、リアルタイムストリーミングなど）を詳細にご説明いただければ、Conversaライセンスの提供またはカスタマイズソリューションの提供が可能かどうかを評価いたします。 2. NXPテクニカルサポートポータル（サポートチケットの送信） support.nxp.comにログインしてサポートチケットを送信し、製品i.MX RT600を選択して、詳細な要件説明書を添付してください。 3. NXPフォーラムコミュニティ community.nxp.comをご覧ください。NXPのエンジニアが内容を確認し、回答いたします。

100kW PMSMインバータにS32K396制御基板を使用することに関するお問い合わせ 親愛なるNXPサポートチームへ、 こんにちは、 現在、100kW級のPMSMインバータ駆動モジュールの開発プロジェクトに取り組んでいます。 目標とする仕様は概ね以下のとおりです。 DCリンク電圧：800V モーター位数電流:250アーム モータータイプ：PMSM 出力レベル：約100kW 研究中、NXPの「S32K396付き3相永久磁石同期モーター制御開発キット」に非常に興味を持つようになりました。 自社で100kWのパワーステージを開発する必要があるため、開発キットのS32K396ベースの制御基板のみを使用し、ゲートドライバーとIGBTパワーステージは自分たちで設計する予定です。 開発キットの回路図を確認した結果、制御基板は外部コネクタを通じてパワーステージとインターフェースしていると理解しています。 三相インバータを制御するためのPWM信号 リゾルバ関連の信号 三相電流検出信号 DCリンク電圧検出 DCリンク電流検出 私たちの理解が正しいか確認していただけますか? もしそうなら、私たちの想定するシステム構成は以下の通りです。 NXP S32K396制御ボードを使用して、当社独自の100kWインバータ電力段用のPWM信号を生成します。 位相電流測定にはホール効果電流センサを使用し、対応するアナログ信号を制御基板に送ります。 リゾルバインターフェース回路は、NXP開発キット/電源基板で使用されているリゾルバ回路を参照して実装します。 制御基板のADC入力に、必要なDCリンク電圧および電流検出信号を供給してください。 つまり、既存のS32K396制御基板とモーター制御ソフトウェアプラットフォームを使用しつつ、元のパワーステージを自社製の800 V / 250アームズインバーターハードウェアに置き換えたいと考えています。 以下の質問について、ご意見をいただければ幸いです。 この構成で、カスタムの高出力インバータ段にS32K396制御基板を使用することは可能でしょうか？ 外部ゲートドライバー/電源段を制御基板に接続する際に考慮すべきインターフェース要件、制限、注意点はありますか? S32K396を基に100kWクラスのPMSMインバーターを開発するのに役立つアプリケーションノート、リファレンス・デザイン、回路図、ソフトウェア例、その他の技術文書などはありますか? NXPは約100kW、800VのPMSMインバーター向けのリファレンス設計や評価プラットフォームを提供している、または推奨できるのでしょうか? 追加の情報やご提案があれば、大変ありがたく思います。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 ヒョン・ムンソン Re: Inquiry About Using the S32K396 Control Board for a 100 kW PMSM Inverter こんにちは、 あなたの理解は概ね正しいです。S32K396コントローラは、MCSPTR2AK396キットに付属する低電圧インバータとは独立して使用可能で、必要なフィードバック信号(位相電流、直流バス電圧/電流、ローター位置、故障信号など)が新しいパワーステージインターフェースに適応されていれば可能です。MCSPTR2AK396キットは主に低電圧モーター制御開発プラットフォームおよびソフトウェアイネーブルメントキットとして意図されています。  100kW前後の牽引クラス**アプリケーション**については、NXPのEV牽引インバーター**リファレンス・デザイン**(EV-INVERTERGEN1 / EV-INVERTERGEN2)も検討するとよいでしょう。これらは高電圧・高出力の電気**車載**インバーター**アプリケーション**を想定しており、MCSPTR2AK396評価キットよりも参考になります。S32K39ファミリは、NXPの牽引インバーターエコシステム内でサポートされているモータ制御プラットフォームの一つです。  MCSPTR2AK396ドキュメント(AN14481)は、PMSM FOCソフトウェアアーキテクチャ、ペリフェラル設定、電流センシング、リゾルバ統合、FreeMASTER/MCATサポートの参考文献として依然として有用です。  EVトラクションインバータープラットフォームの詳細はこちらでご覧いただけます: NXP EV パワーインバーターソリューション。 BR、ペトル

修改im8QM的A72核的CNTFRQ_el0的值 您好！ 如何修改im8QM的A72核的CNTFRQ_el0的值，目前是8000000, 想改为16M， 谢谢！ Re: 修改im8QM的A72核的CNTFRQ_el0的值 i.MX8QM 上不建议、也基本不能把 A72 的 CNTFRQ_EL0 对应的真实计数频率从 8 MHz 改成 16 MHz 。原因是： CNTFRQ_EL0 只是让软件“发现”System Counter 频率的寄存器；即使软件能写这个寄存器值，也不会改变硬件 System Counter 的实际频率。 对 i.MX8QM，参考手册里说明 SCU ROM 会启用 System Counter，并给它输入 24 MHz 时钟；System Counter 内部再分频生成 8 MHz 时钟。 相关 clock root 也属于 System Controller Firmware 管理的时钟域，文档显示 SCU_MSLICE0_CLK_ROOT / SCU_MSLICE1_CLK_ROOT 可作为 SYS COUNTER 的 root clock，且 root clock generation 由 SC FW 控制。 所以如果你现在读到： CNTFRQ_EL0 = 8000000 想改成： CNTFRQ_EL0 = 16000000 需要区分两件事： 只改 CNTFRQ_EL0 的寄存器值 这可能让部分软件“以为”timer 是 16 MHz ，但硬件 counter 仍按 8 MHz 跑，会导致时间、调度、延时、profiling 等全部按 2 倍比例出错。 真正把 System Counter 改成 16 MHz 从我检索到的 i.MX8QM 资料看，System Counter 是 SCU ROM 初始化为 24 MHz / 3 = 8 MHz ，没有公开的寄存器或流程可以把它改成 16 MHz 。 类似 i.MX8 系列讨论中也明确说过，system counter frequency 是硬件固定的， it can't be changed 。 如果你的目标是让 Linux/RTOS 使用正确频率，建议保持 CNTFRQ_EL0 = 8000000 ，并检查 device tree / firmware / bootloader 是否错误覆盖 timer frequency。不要仅为了满足 16 MHz 需求而伪改 CNTFRQ_EL0 ，除非你明确要做一个非真实频率的实验。 结论：i.MX8QM 的 A72 CNTFRQ_EL0 不应从 8 MHz 改为 16 MHz ；真实 System Counter 由 SCU/SCFW 初始化并实际为 8 MHz ，单独改寄存器值不会改变硬件频率，反而会破坏系统时间基准。 Re: 修改im8QM的A72核的CNTFRQ_el0的值 你好： 谢谢回复！ 能否提供SCU或SCFW里如何使System Counter变为16MHz的方法或Demo代码, 谢谢！ Re: 修改im8QM的A72核的CNTFRQ_el0的值 在 SCFW 中，您可以自定义特定于开发板的固件，通常位于 SCFW 移植套件的 board.c 文件中。但是，检索到的SCFW指南描述的是板级/时钟/资源定制的一般方法，而不是系统计数器频率更改钩子。在其他 NXP 平台讨论中，同一类系统计数器频率被描述为硬件固定，写入频率 ID / CNTFRQ_EL0 样式的值不会改变实际的计数器时钟。 因此，我不会提供向 SCFW 写入 16 MHz 的演示代码，因为除非实际的系统计数器硬件时钟/分频器也发生改变，否则这只会产生一个软件可见的虚假频率。 一个安全的诊断/演示方法是验证实际计数器速率： 复制 /* * 在 A72 上从特权固件或早期裸机代码运行。 * 这只读取架构计数器和 CNTFRQ_EL0。 * 它不会尝试更改系统计数器。 */ #include static inline uint64_t read_cntpct_el0(void) { uint64_t v;     __asm__ volatile("mrs %0, cntpct_el0" : "=r"(v)); 返回 v； } static inline uint32_t read_cntfrq_el0(void) { uint64_t v;     __asm__ volatile("mrs %0, cntfrq_el0" : "=r"(v)); 返回 (uint32_t)v; } void check_arch_timer_frequency(void) { uint32_t reported_hz = read_cntfrq_el0();     /* * 将 cntpct delta 与一个独立的、已知良好的延迟源进行比较 例如 SCU 定时器、板载示波器 GPIO 切换定时或其他 * 校准计时器。在 i.MX8QM 上，预计计数约为 8,000,000 次/秒。 */ uint64_t t0 = read_cntpct_el0();     /* 替换为板载校准的 1 秒延迟，而不是基于 CNTFRQ_EL0。*/ external_calibrated_delay_1s(); uint64_t t1 = read_cntpct_el0(); uint64_t measured_counts_per_sec = t1 - t0; board_print(3, “CNTFRQ_EL0 报告 %u Hz，CNTPCT 测量 %llu 计数/秒\n”         reported_hz,         measured_counts_per_sec); } 如果目标是使 Linux 或其他操作系统使用正确的时基，请保持 CNTFRQ_EL0 与实际计数器频率对齐——即根据 RM 文本，i.MX8QM 上的 8 MHz。如果硬件速率没有实际改变，仅将频率设置为 16 MHz 会导致定时器延迟和计时比例不正确。 要点：对于 i.MX8QM，将系统计数器视为由 SCU ROM 初始化的 8 MHz 硬件时基；不支持通过 SCFW 自定义将其变为 16 MHz。

AUTOSARネットワーク管理のスリープ/ウェイクアップの関連性 こんにちは、現在EcuMとネットワークマネジメントのデバッグを行っています。仕様書をいくつか参照しましたが、まだ不明な点があり、ご指導をお願いしたいです。 ネットワーク**マネジメント**のスリープ／ウェイクアップには、EcuMとの連携が必須ですか（つまり、EcuMがウェイクアップの原因を検証する必要がありますか）？ ネットワーク管理のスリープ/ウェイクアッププロセス中、ECUはスリープ(つまりEcuMスリープ)に入る必要がありますか? 質問1への回答が「はい」の場合、EcuMはインターフェースを介してウェイクアップイベントを取得します。 EcuM_SetWakeupEvent 。ただし、AUTOSAR EcuM 仕様 SWS_EcuM_04318 には次のように記載されています。 「選択されたスリープモードに関連付けられていないウェイクアップイベントは無視される。」 これはどういう意味で理解すればいいのでしょうか？ AUTOSAR EcuM仕様にはインターフェースに関する2つの項目も含まれています EcuM_ValidateWakeupEvent – SWS_EcuM_02790とSWS_EcuM_02791。ComMチャネルに関連するウェイクアップソースは、任意のフェーズで有効であると述べています。これは、どのフェーズでもウェイクアップイベントを保留(すなわち、成功裏に通過 EcuM_SetWakeupEvent)し、その後検証される可能性があるという意味でしょうか? Re: The connection between AUTOSAR Network Management sleep/wake-up こんにちは、 1. NMの睡眠・覚醒にはEcuMの協調が必要ですか？ 必ずしもそうとは限りません。NM/ComMはネットワーク通信を管理し、EcuMはECUの電源状態を管理します。EcuMウェイクアップ検証は、ECUが実際にEcuMスリープ状態に入った場合に主に重要となる。 2. NMスリープとは、ECUがEcuMスリープに移行しなければならないことを意味しますか？ いいえ。ネットワークはECUがRUNモードのままローカル機能を実行し続ける間、バススリープに入ることができます。 3. SWS_EcuM_04318を理解するには？ つまり、EcuMは現在選択されているスリープモードに設定されたウェイクアップイベントのみを受け入れているということです。そのスリープモードで有効になっていないソースからのウェイクアップイベントは無視されます。これは、誤ったハードウェアイベントが意図せずECUを起動させるのを防ぎます。 4. ComM関連のウェイクアップソースは、EcuMのどのフェーズでも検証可能ですか？ はい。これは意図的な特別措置です。汎用ウェイクアップソースはスリープ中にのみ受け入れられますが、ComMチャネルに関連付けられたソース（CANウェイクアップフレームなど）は、EcuM_SetWakeupEventを介して保留し、EcuM_ValidateWakeupEventを介して任意のEcuMフェーズで検証できます。これにより、ウェイクアップイベントによって進行中のGo-Sleepシーケンスを中止することが可能になります。これは、NMウェイクアップをEcuMにリンクさせる重要なメカニズムです。 要するに、NMスリープ≠ECUスリープであり、ComMリンクされたウェイクアップソースはEcuMで特別な処理を受け、通常のウェイクアップシーケンス外での検証が可能となる。 BR、ペトル 回复： The connection between AUTOSAR Network Management sleep/wake-up こんにちは、ご回答ありがとうございます。あなたの回答に関して、まだいくつか疑問点があります。度々お手数をおかけして申し訳ございません。また、事前に感謝申し上げます。 ネットワーク**マネジメント**のスリープ/ウェイクアップも、ウェイクアップソースの検証にEcuMが必要になるように思えます。なぜなら、ネットワーク**マネジメント**のパッシブモードでは、EcuMによるウェイクアップソースの検証が必要だからです。ComMチャネルに関連付けられたウェイクアップソースが正常に検証されると、EcuMはComMインターフェースを呼び出し、ネットワークはウェイクアップできます。最初の回答で、EcuMのウェイクアップ検証は、ECUが実際にEcuMスリープ状態に入った場合にのみ必要だとおっしゃっていましたね。つまり、ネットワークマネジメントのスリープ/ウェイクアップの後、ECUもEcuMスリープ状態に入り、その後EcuMのウェイクアップ検証プロセスを経る必要があると解釈しています。しかし、これはあなたの2番目の回答と多少矛盾しているように思えます。私の理解が正しいかどうか自信がありません。 あなたの3回目と4回目の回答では、SWS_EcuM_04318ではEcuMは現在選択されているスリープモードに設定されたウェイクアップイベント情報のみを受け入れていると書かれています。回答4で、ComM関連のウェイクアップソースは特別なケースだとおっしゃいましたね。では、ComM関連のウェイクアップソースはSWS_EcuM_04318の制約を無視できるのでしょうか?それとも設計段階ですべてのComM関連ウェイクアップソースをスリープモードのウェイクアップイベント情報として設定しなければならないのでしょうか? ウェイクアップソースを最初に有効にする必要がありますか？EcuMは、スリープフェーズ中に有効化するためにEcuM_EnableWakeupSourceを呼び出します。有効化後で初めてペンディング(EcuM_SetWakeupEventインターフェースのフィルタリングを成功裏に通過)できるのでしょうか?もしそうなら、回答4の「ComMチャネル関連ソース(例:CANのウェイクアップフレーム)はEcuM_SetWakeupEventでペンディング可能」という文言についてですが、このペンド操作はEcuMのスリープフェーズ中にのみ発生し、その後の検証はEcuMの任意のフェーズで行われるのでしょうか?それとも、他のドライバ自身が有効化ステップを行っているのか、それとも他にシナリオがあるのでしょうか? ご回答をお待ちしております。

哪里可以获取LPC MCU的ROHS报告？ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 亲爱的， 哪里可以获取以下部件号对应的LPC MCU的ROHS报告？谢谢。 LPC2114FBD64 LPC2136FBD64 P89V51RD2FBC lpc2000 Re: Where to get LPC mcu ROHS report? 像 DigiKey、Mouser Electronics 或 Farnell/Newark 这样的大型电子元器件代理商直接在其产品页面上提供合规性文件。如果您查找零件编号（例如 LPC2136FBD64/01 或 P89V51RD2FBC,557），请在库存清单旁边查找标有“RoHS 认证”、“材料声明”或“环境信息”的链接。

S32DS 扩展和更新程序无法安装 PEmicro 插件 (v6.2.3.202608261238)— ZLIB 输入流 您好，NXP技术支持， 我正在尝试通过 S32 Design Studio 中的S32DS 扩展和更新来安装软件包，但由于 PEmicro 插件工件损坏，安装始终在收集阶段失败。 错误信息： 收集待安装项目时发生错误 会话上下文为：（profile=DefaultProfile，phase=org.eclipse.equinox.internal.p2.engine.phases.Collect，operand=，action=）。 下载工件时出现问题：osgi.bundle,com.pemicro.debug.gdbjtag.pne,6.2.3.202608261238。 ZLIB 输入流意外终止   我尝试过的方法： 搜索了本地 p2 缓存（C:\Users\ \.p2\、S32DS eclipse/p2/ 和系统临时文件夹）——工件 com.pemicro.debug.gdbjtag.pne_6.2.3.202608261238.jar不存在（甚至没有 0 字节的短截线），因此这不是过期的缓存问题。 在不同日期多次尝试安装——每次在完全相同的工件上都会出现相同的错误。 尝试在三台电脑上安装，都遇到了同样的问题。 PEmicro 似乎是我需要的软件包（例如 S32K3xx 开发包、S32 Design Studio 调试器核心）的硬性依赖项，因此我无法在安装向导中取消选择它。 我的环境： S32DS 版本：[S32DS.3.5] 版本号：240924（更新 14） 操作系统：Windows 10 安装路径：D:\NXP\S32DS.3.5\（不含空格或非ASCII字符） 请求：请问您能否： 请验证 NXP/PEmicro 更新服务器上的文件 com.pemicro.debug.gdbjtag.pne_6.2.3.202608261238.jar 是否已损坏？ 请提供 PEmicro GDB 插件先前稳定版本（例如，时间戳较早的 6.2.3 版本或 6.2.2 版本）的下载链接，以便我可以离线安装并绕过损坏的组件？ 感谢您的帮助。 谨致问候， 景元斌 Re: S32DS Extensions and Updates fails to install PEmicro plugin (v6.2.3.202608261238) — ZLIB input 嗨@yuanbin 请尝试将“可用 S32DS 软件站点”下的 URL 从 http 更改为 https： VaneB_0-1787934025894.pngVaneB_0-1787934025894.pngVaneB_0-1787934025894.pngVaneB_0-1787934025894.png 此外，此问题可能与网络或代理限制有关，这些限制可能会中断所需文件的下载。请向您的 IT 部门确认是否有任何防火墙、代理、VPN 或网络安全策略可能会影响对 S32DS 更新存储库的访问。 BR，VaneB Re: S32DS Extensions and Updates fails to install PEmicro plugin (v6.2.3.202608261238) — ZLIB input 嗨@VaneB ， 谢谢你的建议。 我已经尝试在“可用软件站点”设置中将 URL 从 http 更改为 https，但不幸的是，在完全相同的工件上仍然出现相同的“ZLIB 输入流意外结束”错误： osgi.bundle,com.pemicro.debug.gdbjtag.pne,6.2.3.202608261238 关于网络/代理的可能性——我已经确认： 我的机器没有配置代理。 我可以成功安装/更新其他 S32DS 插件，没有任何问题。 只有 PEmicro 插件每次都会出现故障 由于出错的工件具有非常新的构建时间戳（20260826），我怀疑更新服务器上的文件本身可能已损坏或不完整。错误发生在收集阶段，并且工件根本没有出现在我的本地 p2 缓存中，这表明下载流在源头被截断了。 能不能请你： 1. 验证 NXP/PEmicro 更新存储库中 `com.pemicro.debug.gdbjtag.pne_6.2.3.202608261238.jar` 的完整性？ 2. 或者，能否提供之前稳定版本（例如 6.2.2 或更早的 6.2.3 版本）的直接下载链接，以便我可以通过“帮助 → 安装新软件 → 归档”离线安装？ 再次感谢您的帮助。 此致， 元宾 Re: S32DS Extensions and Updates fails to install PEmicro plugin (v6.2.3.202608261238) — ZLIB input 嗨@yuanbin 恐怕我这边无法重现这个问题。我已成功将 S32DS 3.5 安装中的 PEmicro 驱动程序更新到 6.2.3 版本，没有任何问题。基于此，您遇到的问题可能与您的设置有关，而不是插件本身的问题。 但是，由于 PEmicro 插件是专有软件，我无法验证其内部完整性或对插件元器件进行更深入的调查。 我建议您直接联系 PEmicro 支持团队，因为他们可以提供针对其软件的具体指导。 带来不便敬请谅解。