NFCアンテナツール - スキン効果 こんにちは！NFCアンテナツールに関して質問があります。このツールは、アンテナパラメータを計算する際に表皮効果を考慮していますか？ Re: NFC Antenna Tool - Skin effect こんにちは、@lucas_uy_13さん はい、そうです。

S32 デザインスタジオライセンス更新 フルフィルメントID:128143961 有効期限:2026年6月22日 製品:ARM v2018 R1用S32 Design Studio。 起動コード:3E1F-50E5-6F93-F06F Re: S32 Design Studio License Renewal こんにちは、 現在は延長されています。 よろしくお願いいたします。 ピーター

S32KはMPUを無効にした場合のSRAMのデフォルト属性です。 こんにちは、NXPテクニカルチームの皆様。 S32KチップのMPUが有効になっていない場合、SRAMのデフォルト属性はどうなるのでしょうか？具体的に、SRAMのデフォルト設定における「share」と「cache」の属性は何ですか？ ARMv7-mアーキテクチャのリファレンスマニュアルを参照したところ、SRAMのデバイスタイプは「device」とされており、SRAM全体がシェア可能でキャッシュできないことを意味しているようです。次の画像をご覧ください。 私のプロジェクトに戻りますが、MWCT2016s を使用するプロジェクト (つまりS32K312) は、MPU が有効になっていない場合に HSE 機能が異常になるため、SRAM 領域を共有可能かつキャッシュ不可に設定するように MPU を構成する必要があります。しかし、S32K322を使用するプロジェクトでは、MPUが有効になっていない場合でもHSE機能は正常に動作します。 したがって、MPUが有効になっていない場合のS32KチップのSRAM属性、またはSRAM属性に影響を与え、それによって2つのプロジェクト間の違いが生じるような他の設定があるかどうかを知りたいです。 Johnson97_0-1784704528919.png Re: S32K default attribute of SRAM when disable MPU こんにちは、 @Johnson97 さん。 デフォルトのメモリマップを使用します。 https://developer.arm.com/documentation/dui0646/c/Cortex-M7-Peripherals/Optional-Memory-Protection-Unit/MPU-Control-Register?lang=en 「ENABLEビットが0に設定されている場合、システムはデフォルトのメモリマップを使用します。」これは、MPUが実装されていない場合と同じメモリ属性を持ちます。表2.11を参照してください。デフォルトのメモリマップは、特権ソフトウェアと非特権ソフトウェアの両方からのアクセスに適用されます。」 https://developer.arm.com/documentation/dui0646/c/The-Cortex-M7-Processor/Memory-model/Behavior-of-memory-accesses?lang=en#CHDBJAJD 表2.11および表2.12に示されているように、SRAMのメモリタイプはNormal、Non-shareable、WBWAです。 よろしくお願いいたします。 ダニエル

IWTL about in-vehicle network communication I'd love to learn about in-vehicle communication (CAN, LIN, FlexRay, etc) and ECUs and things. Are there any resources that can teach me this? I've looked into MIT OCW and there doesn't seem to be anything that can help there. Switch Re: IWTL about in-vehicle network communication Hello, You can start by looking at this thread: https://community.nxp.com/t5/In-Vehicle-Networking/Where-do-I-learn-about-in-vehicle-networking/m-p/2374280/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufE1QVVZKSzJHVUlaRUxPfDIzNzQyODB8U1VCU0NSSVBUSU9OU3xoSw#M194 But personally I will use AI for learning sources as it can tailor the learning according your needs. Best regards, Peter

关于车载网络通信的IWTL 我很想学习车载通信（CAN、LIN、FlexRay 等）和 ECU 等相关知识。 有什么资源可以教我这个吗？我查阅了麻省理工学院开放课程网站（MIT OCW），但似乎那里没有什么能帮到我的。 开关 Re: IWTL about in-vehicle network communication 你好， 你可以先看看这个帖子： https://community.nxp.com/t5/In-Vehicle-Networking/Where-do-I-learn-about-in-vehicle-networking/mp/2374280/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufE1QVVZKSzJHVUlaRUxPfDIzNzQyODB8U1VCU0NSSVBUSU9OU3xoSw#M194 但我个人会使用人工智能作为学习资源，因为它可以根据你的需求定制学习内容。 顺祝商祺！ Peter

S32K comparator tolerance/offset we are having some test on the comparator of S32K116: we apply an input voltage(238mV) to INN (or INP), use bandgap as reference, then we increase VOSEL from 0 to 255 and monitor when the comparator output changed. Somehow, we see different tolerance/offset on MCU2 when the connection of input voltage and bandgap is swapped.  (Details shown in Test1 and Test2) 1) Is this some kind of known feature like VAIO or something else? 2) For this tolerance/offset, is it stable and can we eliminate this by calibration? (like record the trigger VOSEL at the target voltage) Test1: Input Voltage on V-, Bandgap on V+, Low Speed Mode Sid_Zhou_5-1784193940847.png Test2: Input Voltage on V+, Bandgap on V-, Low Speed Mode Sid_Zhou_6-1784193974436.png Re: S32K comparator tolerance/offset 1) Input Pin CMP0_IN is always set to channel 0. (PIN26, PTA0) Yes, input voltage still being input through the same CMP0_IN Pin26, PTA0. 2) Bandgap The feature I want to figure out is not the difference between two MCU.  It is this different tolerance/offset from the same MCU when INN and INP is swapped. I think the bandgap should not change during this swapped.  (The data of MCU1 here is just use as reference) 3) VDD/VDDA: The two MCU are using same +3.3V network (LDO within 1.25% tolerance).  I am fully understanding there will be difference between MCUs bandgap, but, again, it is the difference during swapped I am checking. 4) test method The test data above is not increasing input voltage, it is using fixed input voltage, and increasing VOSEL. (For decreasing VOSEL, i have not test yet, will check this later.) As for increasing/decreasing input voltage with fixed VOSEL, there is similar -9mV.  IncreaseInput_FixedVOSEL.PNG  5) Hysteresis I do have test data for hysteresis in low-speed mode: Test data here is fixing input voltage and increase VOSEL:  Hysteresis_LowSpeedMode.PNG  6) MCU photos you can refer to attached photo "MCU1.PNG" and "MCU2.PNG" Solder mask is  FS32K11-6LFMFM-ON96V-S12YM16 Re: S32K comparator tolerance/offset Hi Sid_Zhou, Which CMP0_IN pin are you connecting the input voltage to? When swapping INN and INP, is the input voltage still being input through the same CMP0_IN pin? Also, the BandGap voltage range is between 0.97-1.03V. Have you considered temporarily ruling out issues caused by different BandGap voltages on the two MCUs? For example, could you use a different CMP0_IN pin to input a more accurate external voltage reference? Have you checked whether the VDD/VDDA voltages of the two S32K1s are the same? Were OFFSET=1 and HYSTCTR=0 confirmed during debugging? I noticed you increased the input voltage and recorded VOSEL. Have you tested decreasing the input voltage and recording VOSEL? Also, check if the Analog comparator hysteresis is affected, although I see you configured HYSTCTR=0. Take two S32K116 photos and tell me the MCU mask. Best Regards, Robin Re: S32K comparator tolerance/offset Thank you for your detailed explanation. I now understand that you are concerned about the VAIO (Analog Input Offset Voltage) parameter in the S32K1 Datasheet. Internally, I saw the AE team's explanation: The AIO offset is the offset of the comparator itself. the offset between INP and INN. The INL error includes the DNL error since it is an integral over the DNL. The error is then |V_AIO| + |INL| Based on my understanding, directly using two analog voltages from an external signal source to input INP and INN respectively to test VAIO should be more intuitive than using bandgap voltage divider.  Regarding your question:  for the same MCU, VAIO is not a random value that changes arbitrarily from moment to moment , but it can drift with operating conditions, especially temperature. The VAIO value in the datasheet should be understood as a guaranteed/worst-case limit over the full temperature range. When designing the threshold, do not treat VAIO as negligible or as a fixed calibrated-out value . Keep margin based on the full-temperature worst-case |VAIO| , plus the DAC/INL error. I also checked your previous discussion on this: S32K116 comparator tolerance. It seems that CMP's accuracy doesn't meet your needs. Have you considered the feature described in section "44.5.5 Automatic compare function" of S32K1XXRM Rev14.2? "Table 41. 12-bit ADC characteristics (2.7 V to 3 V)" in S32K1 DataSheet Rev15 shows a maximum TUE of ±8 LSB. This appears to be more accurate than CMP. Re: S32K comparator tolerance/offset Thanks for your detailed explanation. I noted that the ADC may have better accuracy in our application. But somehow, we have requirements for using CMP as safety monitor from high level architecture and i am not sure if this can be changed to ADC.

寄存器：S32K eMIOS 编码器在静态转子位置的顺时针/逆时针计数器行为 大家好， 我正在使用 S32K322 微控制器，并实现了编码器接口，以从位置传感器获取转子角度。 我已根据应用笔记配置了所需的 MCAL 模块，包括 TRGMUX、LCU 和 eMIOS。编码器功能正常；但是，我发现 CW 和 CCW 计数器出现了意外情况。 我的问题如下： 在转子静止时（即转子不移动时），顺时针和逆时针计数器是否应表现为自由运转计数器？ 就我而言，顺时针和逆时针计数器都在持续递增，而绝对位置值始终为零。这是预期行为吗？ 如果这是预期行为，那么即使转子静止不动，CW 和 CCW 计数器为何还会递增？ 如果这不是预期行为，请您提出以下建议： MCAL 设置（TRGMUX、LCU 或 eMIOS）是否需要进行任何配置更改？ 是否需要实施任何额外的软件机制或过滤措施来防止转子静止时 CW/CCW 计数器递增？ 附上视频供您参考。 AWS-LIBRARIES-S32K3 此致， 蒂鲁 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 您好， LCn 的 CW 和 CCW 输出本身并不是位置计数器。根据增量编码器的实现方式，所用的 LCn 会在每个 A/B 信号边沿生成 CW 或 CCW 输出脉冲流，具体取决于检测到的正交序列。然后，eMIOS 对这些脉冲进行计数以累积位置信息。这与 S32K3 正交方法相符，其中 PHA/PHB 由 LCU 处理，eMIOS 充当位置累积的计数器。https://community.nxp.com/t5/S32K/Quadrature-decoder-on-S32K344/mp/1507580 如果转子确实静止不动，并且编码器 A/B 输入稳定，则不应持续产生新的 CW/CCW 脉冲。因此，当绝对位置保持为零时，顺时针和逆时针计数器都递增，这不是预期的“理想”行为。 有几件事值得检查： 确认 eMIOS 通道确实在计数 CW/CCW 输入脉冲，而不是内部时钟源。 在调试器中检查所用 eMIOS 通道的 UIN 状态。如果 UIN 在计数器递增时保持不变，则该通道可能未使用预期的外部输入。 如果转子静止时 UIN 发生切换，请检查编码器 A/B 信号、TRGMUX 路由、LCU 输出和输入滤波。 同时在示波器上监测编码器 A/B 信号和 LCU CW/CCW 输出，以排除噪声或故障。 这应该有助于确定问题是编码器信号活动/噪声引起的，还是 eMIOS 配置问题引起的。 BR，彼得 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 您好， 我在S32K322参考手册中找不到与UIN状态对应的任何寄存器。请问您能否帮忙查找并指导我如何验证这一点以便进行进一步分析？ 我调试了用于更新 顺时针 和 逆时针 计数器的 寄存器 。根据参考手册， eMIOS 通道 5 的 UC CNT 对应于顺时针计数器， eMIOS 通道 6 的 UC CNT 对应于逆时针计数器。 然而，我观察到即使转子处于静止状态，两个UC CNT寄存器仍然持续从0 递增到 65535 （自由运转）。请问这种现象是否正常，或者可能是什么原因造成的？ 我已附上相关寄存器值的截图供您参考。 此外，我还验证了 MCAL 配置，其配置与共享的**应用笔记**中所述一致，是正确的。 尽早提供支持 此致， 蒂鲁 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 请回复此查询 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 您好， 我写的是 UIN，但它应该是通道 S 寄存器的 UCIN 位。 根据寄存器视图，我看到控制寄存器设置为 0x20E06D1，这表明使用了正确的模式 0x51，即对外部信号进行计数。 据我了解，LCn 在每个 A/B 信号边沿在 CW 或 CCW 输出端产生脉冲流，因此对于稳定的电机/编码器信号，不应产生脉冲，因此不应计数。 您还可以检查相应的 SIUL IMCR 寄存器，以确保已选择 TRGMUX 输出。 PetrS_0-1784696552579.png BR，彼得  

S32 Design Studio License Renewal Fulfillment ID: 128143961 Expiration Date: Jun 22, 2026 Product: S32 Design Studio for ARM v2018 R1 Activation Code: 3E1F-50E5-6F93-F06F Re: S32 Design Studio License Renewal Hello, It is now extended. Best regards, Peter

Request for Dual-Core Ethernet Example on i.MX RT1176 (One Ethernet per Core) Hello NXP Team, I am currently working on the i.MX RT1176 evaluation board using MCUXpresso IDE v11.9.1 (Build 2170, 2024-04-19). I would like to know whether NXP provides any multicore example project that demonstrates the use of both Cortex-M7 and Cortex-M4 cores with independent Ethernet interfaces. My requirement is as follows: Ethernet Port 1 should be initialized and managed by the Cortex-M7 core. Ethernet Port 2 should be initialized and managed by the Cortex-M4 core. Both Ethernet interfaces should operate simultaneously and independently on their respective cores. If inter-core communication (such as RPMsg or MU) is required, I would appreciate any example or documentation explaining the recommended approach. I have searched the MCUXpresso SDK examples but have not found a project matching this use case. Could you please let me know: Is there any official NXP multicore example demonstrating one Ethernet controller on the M7 core and the other Ethernet controller on the M4 core? If such an example is available, could you please share the project or provide the corresponding SDK example name or repository link? If no such example exists, could you suggest the recommended architecture for implementing this configuration on the i.MX RT1176? Any reference projects, application notes, or documentation would be greatly appreciated. Thank you for your support. Best regards, Aravind Togaralli Re: Request for Dual-Core Ethernet Example on i.MX RT1176 (One Ethernet per Core) Dear @Aravind_Togaralli , Unfortunately, there is currently no official example that demonstrates both the Cortex-M7 and Cortex-M4 running independent Ethernet interfaces simultaneously. However, the recommended architecture is to keep the two Ethernet subsystems completely independent: Assign one Ethernet controller (e.g., ENET/ENET_QOS) to CM7 and the other to CM4. Each core should maintain its own MAC driver, PHY control, lwIP stack, netif instance, DMA descriptors, packet buffers, interrupts, and network configuration. Use RPMsg-Lite, MU, or shared memory only for inter-core control and status communication when needed. Consider using RDC/XRDC2 to isolate Ethernet peripherals and memory resources between the two cores during development. For Ethernet DMA buffers, ensure the selected memory region is accessible by both the corresponding CPU and Ethernet DMA master. A suggested implementation approach is: Start from a working RT1170 multicore example. Bring up Ethernet on CM7 using a standard lwIP example. Bring up Ethernet on CM4 using the second Ethernet controller. Verify both Ethernet interfaces operate simultaneously without IPC. Add RDC/XRDC2 isolation if required. Introduce RPMsg-Lite or MU/shared-memory communication only if the application requires inter-core interaction. You may also find application note AN13264 helpful, as it provides guidance and recommendations for RT1170 multicore application development. Best Regards, Shelly Zhang

NFC Antenna Tool - Skin effect Hello! I have a question regarding the NFC Antenna Tool. Does the tool account for the skin effect when calculating the antenna parameters? Re: NFC Antenna Tool - Skin effect Hello @lucas_uy_13  Yes, it does.

S32K default attribute of SRAM when disable MPU Hi nxp technical team, I would like to know the default attributes of SRAM when the MPU of the S32K chip is not enabled? Specifically, what are the attributes of "share" and "cache" in the SRAM default settings? I have consulted the ARMv7-m architecture reference manual, which indicates that the device type of SRAM is "device", seemingly meaning that the entire SRAM is sharable and non-cacheable. See the following picture. Returning to my project, the project using MWCT2016s (i.e. S32K312) has abnormal HSE function when the MPU is not enabled, and it is necessary to configure MPU to set the SRAM area as sharable and non-cacheable. However, in the project using S32K322, the HSE function is normal when the MPU is not enabled.  Therefore, I would like to know the SRAM attributes of the S32K chip when the MPU is not enabled, or if there are any other settings that affect the SRAM attributes and thereby cause the differences between the two projects? Johnson97_0-1784704528919.png Re: S32K default attribute of SRAM when disable MPU Hi @Johnson97, It uses the default memory map: https://developer.arm.com/documentation/dui0646/c/Cortex-M7-Peripherals/Optional-Memory-Protection-Unit/MPU-Control-Register?lang=en "When the ENABLE bit is set to 0, the system uses the default memory map. This has the same memory attributes as if the MPU is not implemented, see Table 2.11. The default memory map applies to accesses from both privileged and unprivileged software." https://developer.arm.com/documentation/dui0646/c/The-Cortex-M7-Processor/Memory-model/Behavior-of-memory-accesses?lang=en#CHDBJAJD As you can see in Table 2.11 and Table 2.12, the memory type for SRAM is Normal, Non-shareable, WBWA. Regards, Daniel

車載ネットワーク通信についてのIWTL 車内通信(CAN、LIN、FlexRayなど)やECUなどについて学びたいです。 これを教えてくれるリソースはありますか?MITのOCWを調べましたが、役立つものは特に見当たりません。 スイッチ Re: IWTL about in-vehicle network communication こんにちは、 まずはこのThreadをご覧ください: https://community.nxp.com/t5/In-Vehicle-Networking/Where-do-I-learn-about-in-vehicle-networking/mp/2374280/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufE1QVVZKSzJHVUlaRUxPfDIzNzQyODB8U1VCU0NSSVBUSU9OU3xoSw#M194 でも個人的には、学習にはAIを使うつもりです。AIはあなたのニーズに合わせて学習を調整できるからです。 よろしくお願いいたします。 ピーター

GC7000 GPU ハング galcore タイムアウト 問題の概要 NavAppの実行中に、画面表示が完全にフリーズします。カーネルログの調査によると 、これは アプリケーションのクラッシュではなく 、 Vivante GC7000 GPU(Galcore)の ハム です。 観察結果： カーネルは30秒後に GPUタイムアウト を報告します(gpuTimeout = 30000)。 Galcoreは GPU状態ダンプを生成し、以下を呼び出します: gckKERNEL_Recovery() gckHARDWARE_DumpGPUState() 運転手は次のように報告します。 [ガルコア]:運転手を停止させて現場を維持しろ。 GPUの状態ダンプは複数のGPUブロックが詰まっていることを示しています: FEはアイドル状態ではない SHはアイドル状態ではありません TXはアイドル状態ではありません MCはアイドル状態ではありません DMAが停止しているようです ドライバ構成 現在のGalcore構成は以下のとおりです。 リカバリ = 0、GPUタイムアウト = 30000   GPUリカバリーが無効になっている(リカバリー=0)ため、ハングを検出するとドライバーは停止し、最後にレンダリングされたフレームだけが表示されるため、画面がフリーズする現象が確認されます。 GPUメモリの状態: GPUのメモリ統計はメモリの使い尽きを示し ません 。 総GPUメモリ:256MB 使用量：約155MB 無料：約113MB したがって、この問題はGPUのメモリ不足によるものではないようです。 GPUクライアント: GPUデータベースによると、ハング時点で NavAppだけがアクティブなGPUクライアント です。 GPUの状態ダンプは、以下の以下の人から提出された複数のコマンドバッファを参照しています: NavApp これは、NavAppが提出したレンダリングコマンドを実行している間にGPUのハングが発生したことを示しています。   応募スケジュール: アプリケーションログから、GPUがハングする直前に以下のシーケンスが観察されています。 連続的な地図のズームイン/ズームアウト操作 オフラインの地図/タイルアクセス 経路計算 ルート情報表示 GPUのタイムアウトと状態ダンプ GPUのハングは集中的なレンダリング作業の直後に発生します。 結論： 収集された証拠に基づくと： カー ネルパニック 、 OOM、 アプリケーション クラッシュ はありません。 この故障は、Galcoreのウォッチドッグによって検出された GPUコマンドプロセッシングのハング です。 ハングが発生した際はNavAppがレンダリングクライアントですが、GPUドライバー内で障害が観察されます。 GPUのメモリ使用量は制限内であり、リソースの枯渇を示しているわけではありません。 TVSチームへの調査依頼： Vivante GC7000 / Galcore GPUドライバーがレンダリング中にフリーズします。 この問題が既知のGPUドライバーかファームウェアの制限かは不明です。 GPUリカバリー(recovery=1)がこのプラットフォームでサポートされ推奨されているかどうか。 GPU状態ダンプの分析により、どのGPUコマンドまたはハードウェアブロックがタイムアウトを引き起こしたかを特定します。 BSPやGPUドライバー、ファームウェアのリリースなどが更新されていても、同様のGPUタイムアウト問題に対応しています。 Re: GC7000 GPU hang galcore timeout こんにちは@Zhiming_Liu SOC - iMX8qxpComek BSPバージョン - Scarthgap L6.6.5 ネタバレ （ハイライトして読む） ネタバレ （ハイライトして読む）     Re: GC7000 GPU hang galcore timeout こんにちは、 @Ram2さん SOCの部品番号、BSPのバージョン、および再現手順をお知らせください。 よろしくお願いします、 志明 Re: GC7000 GPU hang galcore timeout こんにちは、 @Ram2さん EVK上でこの問題を再現するための手順を教えてください。 よろしくお願いします、 志明 Re: GC7000 GPU hang galcore timeout こんにちは@Zhiming_Liu 再現手順： 画面がフリーズする問題は、ランダムかつ断続的に発生するため、決まった再現手順はありません。しかし、利用可能なシステムメモリが非常に少なくなった場合（通常は60MiB未満）に発生する可能性が高いことが観察されています。 問題の再現性を高めるため、以下の活動を継続的に行いました。 長距離ルートを2～3本作成した。 ナビゲーションを開始し、約1分以内に終了しました。 ホーム、オフィス、ホテルのクイックアクションボタンを使って繰り返しルートを作成しました。 パン操作や頻繁なズームイン／ズームアウト操作を行い、地図上のさまざまな領域を探索した。 これらの作業中に、利用可能なメモリ容量が低レベルまで低下した際に、画面がフリーズする現象が確認された。例えば： メモリ容量：合計1709.5 MiB、空き容量55.8 MiB、使用容量1298.1 MiB、バッファ/キャッシュ容量567.2 MiB MiB スワップ: 合計 0.0、空き 0.0、使用済み 0.0、利用可能メモリ 411.4 これは、空きメモリがほぼ枯渇した状態で継続的に使用した場合に、この問題が発生する可能性が高くなることを示唆している。 Re: GC7000 GPU hang galcore timeout こんにちは@Ram2  NXPがリリースしたLinux BSPにはナビゲーションアプリは含まれていません。テスト用アプリとテスト手順書をご提供ください。 よろしくお願いします、 志明

[S32N55 / HSE2] 调试卡请求 — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR 您好， 后续内容：S32N55 (HSE2) 安全调试。CRS(APP)挑战-响应认证现在可以工作（最终响应0x4A4A4A4A）。我现在正在执行调试卡请求 (HSE_DEBUG_CMD_CARD_REQUEST)，它返回： HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR ((hseDebugError_t)0x20) — "调试卡中的调试功能域映射无效。" 我根据您之前的反馈发送的内容： Packet2 调试功能域信号列表：数组样式，List[22..26] = 每个 0x01（CRS：Cortex-M7、PCIe、CRS NoC/CAN NoC、CANXL0-1、CANXL2-3），所有其他字节为 0x00。 Packet3 enabledDebugDomainMap (uint64_t): 0x07C00000 按照建议（位 22-26）。 AuthScheme：macAlgo = HSE_MAC_ALGO_CMAC = 0x11。 AuthTag：对卡片信息进行 AES256-CMAC 认证，authLen = 16。 我尝试过对 enabledDebugDomainMap（uint64_t，传输 8 字节）进行以下操作： 小端序：00 00 C0 07 00 00 00 00 → 0x20 大端序：00 00 00 00 07 C0 00 00 → 0x20 bit27 (0x08000000，匹配 AUTH 目标 0x1B) → 0x20 所有返回值均为 0x20。 问题： 1.对于 CRS，HSE 期望的 enabledDebugDomainMap (uint64_t) 的确切值是什么，以及其字节顺序是什么？ 2. enabledDebugDomainMap（Packet3 位掩码）是否必须与调试功能域信号列表（Packet2，数组 List[22..26]）一致？它们之间究竟是什么关系？ 3. RM 示例说明“功能域 1,3 已启用 → 0x00..A0”。能否解释一下功能域到位的映射关系，以便我计算 CRS 值？ 4. HSE 是否在验证 AuthTag 之前验证功能域映射？我想确认 0x20 是否仅表示功能域映射错误，还是其他字段（例如 AuthTag / 签名数据范围）也可能导致 HSE 在此停止。 我还想确认卡 AuthTag 的签名数据范围：我目前对卡信息字段（authKeyRef + reserved0 + ownerId + authScheme + signal list + 功能域映射 + UID list）计算 AES256-CMAC。这是要签署的正确数据吗？ 顺祝商祺！ Re: [S32N55 / HSE2] Debug Card Request — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR 你好， @EddiePark 感谢你的帖子。 1.很高兴得知第一阶段顺利通过。关于您提出的第二阶段问题，我仍在核实相关信息以获得更清晰的描述，如有任何有价值的更新，我会稍后回复您。 为了确保信息一致，能否请您再次与我分享最新的日志和相应的脚本？可以像往常一样通过消息分享。 BR 陈银

imx8mp 是否支持 Yocto 6.0？ 你好， imx8mp 是否支持 Yocto 6.0？ 如果属实，预计版本日期是什么时候？ 有顾客询问过这个问题。 谢谢！ Re: Does the imx8mp support Yocto 6.0? 是的，NXP Yocto 6.0 (Wrynose) 电路板支持包。 支持 i.MX8MP，LF6.18.20_2.0.0 版本已于 2026 年 6 月 25 日发布。   https://github.com/nxp-imx/meta-imx Re: Does the imx8mp support Yocto 6.0? 非常感谢

Does the imx8mp support Yocto 6.0? Hello, does the imx8mp support Yocto 6.0? If so, when is the expected release date? We have customers asking about this. Thank you. Re: Does the imx8mp support Yocto 6.0? Yes, i.MX8MP is supported in the NXP Yocto 6.0 (Wrynose) BSP, and the LF6.18.20_2.0.0 release was published on 25 June 2026   https://github.com/nxp-imx/meta-imx Re: Does the imx8mp support Yocto 6.0? thank you very much

GC7000 GPU hang galcore timeout Issue Summary During execution of NavApp, the display freezes completely. Investigation of the kernel logs indicates that this is not an application crash, but a Vivante GC7000 GPU (Galcore) hang. Observations: The kernel reports a GPU timeout after 30 seconds (gpuTimeout = 30000). Galcore generates a GPU State Dump and invokes: gckKERNEL_Recovery() gckHARDWARE_DumpGPUState() The driver then reports: [galcore]: Stop driver to keep scene. The GPU state dump indicates multiple GPU blocks are stuck: FE not idle SH not idle TX not idle MC not idle DMA appears to be stuck Driver Configuration Current Galcore configuration shows: recovery = 0 gpuTimeout = 30000   Since GPU recovery is disabled (recovery = 0), the driver stops after detecting the hang, leaving the last rendered frame on the display, which explains the observed screen freeze. GPU Memory Status: GPU memory statistics do not indicate memory exhaustion. Total GPU memory: 256 MB Used: ~155 MB Free: ~113 MB Therefore, the issue does not appear to be caused by GPU out-of-memory. GPU Client: The GPU database shows that NavApp is the only active GPU client at the time of the hang. The GPU state dump references multiple command buffers submitted by: NavApp This indicates the GPU hang occurred while executing rendering commands submitted by NavApp.   Application Timeline: From the application logs, the following sequence is observed immediately before the GPU hang: Continuous map zoom in/out operations Offline map/tile access Route calculation Route information display GPU timeout and state dump The GPU hang occurs immediately after intensive rendering activity. Conclusion: Based on the collected evidence: There is no kernel panic, OOM, or application crash. The failure is a GPU command processing hang detected by the Galcore watchdog. NavApp is the rendering client when the hang occurs, but the failure is observed inside the GPU driver. GPU memory usage is within limits and does not indicate resource exhaustion. Request to TVS team please investigate: Vivante GC7000 / Galcore GPU driver hang during rendering. Whether this issue is a known GPU driver or firmware limitation. Whether GPU recovery (recovery=1) is supported and recommended on this platform. Analysis of the GPU state dump to identify which GPU command or hardware block caused the timeout. Whether there are updated BSP, GPU driver, or firmware releases addressing similar GPU timeout issues. Re: GC7000 GPU hang galcore timeout Hi @Zhiming_Liu  SOC - iMX8qxpComek BSP version - Scarthgap L6.6.5 Spoiler (Highlight to read) Spoiler (Highlight to read)     Re: GC7000 GPU hang galcore timeout Hi @Ram2  Please provide SOC part number, BSP verison and reproduce steps. Best Regards, Zhiming Re: GC7000 GPU hang galcore timeout Hi @Zhiming_Liu  Reproduce Steps : The screen freeze issue does not have a fixed set of reproduction steps, as it occurs randomly and intermittently. However, I have observed that it is more likely to occur when the available system memory becomes very low (typically below 60 MiB). To increase the likelihood of reproducing the issue, I performed the following activities continuously: Created 2-3 long-distance routes. Started navigation and exited within about a minute. Repeatedly created routes using the Home, Office, and Hotel quick action buttons. Explored different map regions by panning and performing frequent zoom in/out operations. During these activities, the screen freeze was observed when the available memory dropped to a low level. For example: MiB Mem : 1709.5 total, 55.8 free, 1298.1 used, 567.2 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used, 411.4 avail Mem This suggests the issue is more likely to occur under sustained usage when free memory is nearly exhausted. Re: GC7000 GPU hang galcore timeout Hi @Ram2  Please provide steps to reproduce the issue on the EVK. Best Regards, Zhiming Re: GC7000 GPU hang galcore timeout Hi @Ram2  The Linux BSP released by NXP does not include a navigation app. Please provide a test app and testing instructions. Best Regards, Zhiming

NFC天线工具 - 皮肤效果 你好！我有一个关于NFC天线工具的问题。该工具在计算天线参数时是否考虑了趋肤效应？ Re: NFC Antenna Tool - Skin effect 你好@lucas_uy_13 是的，确实如此。

S32Kコンパレータの許容差/オフセット S32K116の比較器でテストを行っています。 入力電圧(238mV)をINN(またはINP)に印加し、バンドギャップを基準にしてからVOSELを0から255に上げ、コンパレータ出力の変化を監視します。 入力電圧とバンドギャップの接続を入れ替えると、MCU2で異なる許容誤差/オフセットが見られるという現象が見られます。（詳細はテスト1およびテスト2を参照） 1) これはVAIOのような既知の機能なのでしょうか、それとも他の何かですか? 2) この許容差/オフセットについて安定していますか?また、校正でこれを除去できますか? （例えば、目標電圧におけるトリガーVOSELを記録するなど） テスト1：入力電圧V-、バンドギャップV+ 、低速モード Sid_Zhou_5-1784193940847.png テスト2：入力電圧V+、バンドギャップV- 、低速モード Sid_Zhou_6-1784193974436.png Re: S32K comparator tolerance/offset 1) 入力ピン CMP0_INは常にチャンネル0に設定されています。(ピン26、PTA0) はい、入力電圧は同じCMP0_INピン26、PTA0を通じて入力されています。 2) バンドギャップ 私が知りたいのは、2つのMCUの違いではありません。INNとINPを入れ替えたときの同じMCUからの許容差やオフセットの違いが原因です。この交換操作の間、バンドギャップは変化しないはずだと私は考えています。(ここでのMCU1のデータはあくまで参考資料として利用しています) 3)VDD/VDDA: 2つのMCUは同じ+3.3Vネットワーク(LDO許容範囲内)を使っています。 MCUのバンドギャップに違いがあることは十分理解していますが、やはり交換時の違いを確認しています。 4) 試験方法 上記のテストデータは入力電圧を上げているのではなく、固定入力電圧を使い、VOSELを上昇させています。(VOSELを減らす方法はまだテストしていませんが、後で確認します。) 固定VOSELで入力電圧を上下に調整する場合、同様の-9mVがあります。 IncreaseInput_FixedVOSEL.PNG 5) ヒステリシス 低速モードでのヒステリシスに関するテストデータはあります。 ここでのテストデータは、入力電圧を固定し、VOSELを増加させるものです。 Hysteresis_LowSpeedMode.PNG 6) MCUの写真 添付の写真「MCU1.PNG」と「MCU2.PNG」を参照してください。 はんだマスクは FS32K11-6LFMFM-ON96V-S12YM16 Re: S32K comparator tolerance/offset こんにちは、Sid_Zhouさん。 入力電圧はどのCMP0_INピンに接続していますか？ INNとINPを入れ替えた場合、入力電圧は依然として同じCMP0_INピンを通して入力されますか？ また、バンドギャップ電圧の範囲は0.97～1.03Vです。2つのMCUのバンドギャップ電圧の違いによって引き起こされる問題を、一時的に除外することを検討しましたか？例えば、より正確な外部電圧基準を入力するために別のCMP0_INピンを使うことはできますか? 2つのS32K1のVDD/VDDA電圧が同じかどうか確認しましたか？ デバッグ中にOFFSET=1およびHYSTCTR=0であることが確認されていましたか？ 入力電圧を上げてVOSELを記録したことに気づきました。入力電圧を下げてVOSELを記録するテストは行いましたか？また、 アナログ比較器のヒステリシス が影響を受けているかも確認してください。ただし、HYSTCTR=0に設定されているようですね。 S32K116写真を2枚撮って、MCUのマスクについて教えてくれ。 よろしくお願いいたします ロビン Re: S32K comparator tolerance/offset 詳しいご説明をありがとうございました。S32K1のデータシートにある VAIO (アナログ入力オフセット電圧)パラメータについてご懸念されていることが理解できました。 内部では、AEチームの説明を見ました: AIOオフセットはコンパレータ自体のオフセットです。INPとINNのオフセットです。 INL誤差はDNLに関する積分であるため、DNL誤差を含みます。 エラーは |V_AIO| + |INL| となります。 私の理解では、外部信号源から直接2つのアナログ電圧を入力 INP と INN にそれぞれ使い、 VAIO をテストする方がバンドギャップ電圧分圧器を使うよりも直感的だと思います。 ご質問についてですが、同じMCUの場合、VAIOは瞬間ごとにランダムに変わる値ではありませんが、動作条件、特に温度によって変動することもあります。データシートのVAIO値は、全温度範囲にわたる保証/最悪ケースの限界として理解すべきです。 しきい値を設計する際には、VAIOを無視できる値、または固定された校正済み値として扱わないでください。マージンは最悪の温度|VAIO|、さらにDAC/INLエラーも加わります。 また、以前の S32K116 コンパレータ許容についての議論も確認しました。 CMPの精度は、お客様のニーズを満たしていないようです。S32K1XXRM Rev14.2の「 44.5.5 自動比較機能 」の項で説明されている機能について検討されましたか？ S32K1データシート Rev15の「 表41. 12ビットADC特性（2.7V～3V） 」には、最大 TUE が±8LSBと記載されています。これはCMPよりも正確であるように思われる。 Re: S32K comparator tolerance/offset 詳しい説明をありがとうございました。 ADCの方が私たちのアプリケーションでは精度が高いかもしれないと指摘しました。 しかし、なぜか高レベルアーキテクチャからCMPをセーフティモニターとして使う要件があり、これをADCに変更できるかはわかりません。

登録:S32K eMIOSエンコーダーのCW/CCWカウンタの静的ローター位置での挙動 チームの皆さん、こんにちは。 私はS32K322マイクロコントローラを使っており、位置センサーからローター角度を得るためのエンコーダーインターフェースを実装しています。 申請ノートに基づいて、TRGMUX、LCU、eMIOSを含む必要なMCALモジュールを構成しました。エンコーダーの機能は正常に動作していますが、CWカウンターとCCWカウンターで予期しない動作が見られました。 私の質問は以下のとおりです。 ローターが動いていない静的なローター位置では、CWおよびCCWカウンターがフリーランニングカウンターとして振る舞うことが期待されますか? 私の場合、CWとCCWカウンターは増加し続けますが、絶対ポジション値はゼロのままです。これは想定される動作ですか？ もしこれが予想されるなら、ローターが静止しているのにCWやCCWカウンターが増加する理由は何ですか? もし予想外の情報があれば、以下の方法を提案していただけませんか: MCALの設定（TRGMUX、LCU、またはeMIOS）において、必要な構成変更はありますか？ ローターが静止しているときにCW/CCWカウンターが増加しないように、追加のソフトウェア機構やフィルタリングを実装すべきでしょうか? 参考のために動画を添付しました。 AWSライブラリS32K3 よろしくお願いいたします。 ティル Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position こんにちは、 LCnからのCWおよびCCW出力は、それ自体で位置カウンターではありません。インクリメンタルエンコーダの実装によれば、使用されるLCnは、検出された直交シーケンスに応じて、A/B信号の各エッジでCWまたはCCW出力にパルスストリームを生成します。eMIOSはこれらのパルスをカウントして位置を蓄積します。これは、PHA/PHBがLCUで処理され、eMIOSが位置蓄積のカウンターとして機能するS32K3の直交方式と一致しています。https://community.nxp.com/t5/S32K/Quadrature-decoder-on-S32K344/mp/1507580 ローターが本当に静的でエンコーダのA/B入力が安定している場合、新しいCW/CCWパルスを連続的に生成すべきではありません。したがって、CWとCCWの両方のカウンターが、絶対位置がゼロのまま増加するのは期待される「理想的な」挙動ではありません。 いくつか確認しておくと良い点があります。 eMIOSチャネルが本当にCW/CCWの入力パルスをカウントしているか、内部クロックソースではないか確認してください。 デバッガで使用されているeMIOSチャネルのUINステータスを確認してください。カウンターが増加してもUINが一定のままであれば、チャネルは意図した外部入力を使っていない可能性があります。 もしローターが静止している間にUINがトグルしている場合は、エンコーダA/B信号、TRGMUXルーティング、LCU出力、入力フィルタリングを調べてください。 また、ノイズやグリッチがないことを確認するために、エンコーダのA/B信号とLCUのCW/CCW出力をオシロスコープで監視してください。 これにより、問題の原因がエンコーダ信号の活動/ノイズによるものか、eMIOSの設定の問題によるものかを判断するのに役立つはずです。 BR、ペトル Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position こんにちは、 I could not find any register corresponding to the UIN status in the S32K322 リファレンス・マニュアル. Could you please check and guide me on how to verify this for further analysis? I debugged the registers that update the CW and CCW counters. According to the 参考マニュアル, eMIOS チャンネル 5 MCU CNT corresponds to the CW counter, and eMIOS チャンネル 6 MCU CNT corresponds to the CCW counter. しかし、MCU CNTのレジスタは、ローターが静的状態でも0から65535(フリーランニング)まで連続的に増加し続けるのを観察しました。この行動が予想されるものなのか、あるいは何が原因なのか教えていただけますか? 参考までに、関連するレジスタ値のスクリーンショットを添付しました。 さらに、MCALの設定も確認しましたが、共有されたアプリケーションノート通りに正しく設定されています。 早くもサポート よろしくお願いいたします。 ティル Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position 質問にお答えください。 Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position こんにちは、 UINと書きましたが、チャネルSレジスタのUCINビットであるはずです。 レジスタビューに基づくと、コントロールレジスタは0x20E06D1に設定されており、これは外部信号のカウントである0x51が使用されている正しいモードを示しています。 私の理解ではLCnはCWまたはCCW出力の各A/B信号エッジでパルスストリームを生成するため、定常モーター/エンコーダ信号ではパルスを発生させず、カウントされることはありません。 また、TRGMUX出力が選択されているかを確認するために、それぞれのSIUL IMCRレジスタも確認できます PetrS_0-1784696552579.png BR、ペトル