S32K 比较器公差/偏移 我们正在对S32K116比较器进行一些测试： 我们向 INN（或 INP）施加输入电压（238mV），以带隙为参考，然后我们将 VOSEL 从 0 增加到 255，并监测比较器输出何时发生变化。 不知何故，当输入电压和带隙的连接互换时，我们在 MCU2 上观察到了不同的容差/偏移。（详情请参见测试1和测试2） 1）这是像VAIO那样已知的某种功能，还是其他什么功能？ 2）对于这种公差/偏差，它是否稳定，我们可以通过校准消除它吗？ （例如，记录目标电压下的触发信号） 测试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。（PIN26，PTA0） 是的，输入电压仍然通过相同的 CMP0_IN 引脚 26、PTA0 输入。 2）带隙 我想弄清楚的特性并不是两个MCU之间的区别。当 INN 和 INP 互换时，同一个 MCU 的容差/偏移量就会不同。我认为在这种交换过程中带隙不应该发生变化。（此处MCU1的数据仅供参考） 3) VDD/VDDA： 这两个MCU使用相同的+3.3V网络（LDO容差在1.25%以内）。 我完全理解MCU的带隙会有所不同，但是，我再次强调，我检查的是交换后的带隙差异。 4）测试方法 上述测试数据并非增加输入电压，而是使用固定输入电压，并增加 VOSEL 值。（关于降低 VOSEL 值，我尚未测试，稍后会进行检查。） 对于固定 VOSEL 的增加/减少输入电压的情况，有类似的 -9mV。 IncreaseInput_FixedVOSEL.PNG 5）滞后现象 我确实有低速模式下磁滞现象的测试数据： 此处的测试数据是固定输入电压并增加 VOSEL： Hysteresis_LowSpeedMode.PNG 6）MCU照片 您可以参考附件照片“MCU1.PNG”和“MCU2.PNG”。 阻焊层是 FS32K11-6LFMMF-ON96V-S12YM16 Re: S32K comparator tolerance/offset 你好 Sid_Zhou， 您将输入电压连接到了哪个 CMP0_IN 引脚？ 当交换 INN 和 INP 时，输入电压是否仍然通过同一个 CMP0_IN 引脚输入？ 此外，带隙电压范围在 0.97-1.03V 之间。您是否考虑过暂时排除两个 MCU 的带隙电压不同所导致的问题？例如，能否使用不同的 CMP0_IN 引脚来输入更精确的外部电压基准？ 你检查过两个 S32K1 的 VDD/VDDA 电压是否相同吗？ 调试过程中是否确认 OFFSET=1 和 HYSTCTR=0？ 我注意到您提高了输入电压并记录了 VOSEL。你试过降低输入电压并记录VOSEL值吗？另外，检查一下模拟比较器的迟滞是否受到影响，虽然我看到你已将 HYSTCTR 配置为 0。 拍摄两张 S32K116 照片，并告诉我 MCU 掩模。 此致敬礼， Robin Re: S32K comparator tolerance/offset 感谢您的详细解释。我现在明白您关心的是 S32K1 数据手册中的VAIO （模拟输入偏移电压）参数。 我在内部看到了AE团队的解释： AIO偏移量是比较器本身的偏移量，即INP和INN之间的偏移量。 由于 INL 误差是对 DNL 的积分，因此 INL 误差包含了 DNL 误差。 错误为 |V_AIO| + |INL| 根据我的理解，直接使用来自外部信号源的两个模拟电压分别输入INP和INN来测试VAIO应该比使用带隙分压器更直观。 关于您的问题：对于同一个 MCU，VAIO 不是一个随机值，不会随意地随时间变化，而是会随着工作条件（尤其是温度）而漂移。数据表中的 VAIO 值应理解为整个温度范围内的保证/最坏情况极限。 在设计阈值时，不要将 VAIO 视为可忽略不计或固定的校准值。保持裕量基于全温最坏情况 |VAIO|，加上 DAC/INL 误差。 我还查看了您之前关于此问题的讨论： S32K116 比较器容差。 看来CMP的精度无法满足您的需求。您是否考虑过 S32K1XXRM Rev14.2 的“ 44.5.5 自动比较功能”部分中描述的功能？ S32K1 数据手册 Rev15 中的“ 表 41. 12 位 ADC 特性 (2.7 V 至 3 V) ”显示最大 TUE 为 ±8 LSB。这似乎比CMP更准确。 Re: S32K comparator tolerance/offset 感谢您的详细解释。 我注意到，在我们的应用中，ADC 可能具有更高的精度。 但是，从高层架构来看，我们有使用 CMP 作为功能安全监视器的要求，我不确定是否可以将其更改为 ADC。

S32 设计工作室许可证续期 订单号：128143961 有效期至：2026年6月22日 产品：S32 Design Studio for ARM v2018 R1 激活码：3E1F-50E5-6F93-F06F Re: S32 Design Studio License Renewal 你好， 现在已扩展。 顺祝商祺！ Peter

Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position Hi Team, I am using the S32K322 microcontroller and have implemented the encoder interface to obtain the rotor angle from a position sensor. I have configured the required MCAL modules, including TRGMUX, LCU, and eMIOS, based on the application note. The encoder functionality is operational; however, I have observed unexpected behavior with the CW and CCW counters. My questions are as follows: During a static rotor position (i.e., when the rotor is not moving), is it expected for the CW and CCW counters to behave as free-running counters? In my case, both the CW and CCW counters continue to increment, while the absolute position value remains at zero. Is this expected behavior? If this is expected, what is the reason for the CW and CCW counters incrementing even though the rotor is stationary? If this is not expected, could you please suggest: Any configuration changes required in the MCAL setup (TRGMUX, LCU, or eMIOS)? Any additional software mechanism or filtering that should be implemented to prevent the CW/CCW counters from incrementing when the rotor is stationary? Attached the video for your reference AWS-LIBRARIES-S32K3  Regards, Thiru Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position Hi, The CW and CCW outputs from LCn are not position counters by themselves. According to the incremental encoder implementation, used LCn generates pulse streams on the CW or CCW output at every A/B signal edge, depending on the detected quadrature sequence. eMIOS then counts these pulses to accumulate position. This matches the S32K3 quadrature approach where PHA/PHB are processed by LCU and eMIOS acts as the counter for position accumulation. https://community.nxp.com/t5/S32K/Quadrature-decoder-on-S32K344/m-p/1507580 If the rotor is truly static and the encoder A/B inputs are stable, then new CW/CCW pulses should not be continuously generated. So both CW and CCW counters incrementing while the absolute position remains zero is not the expected “ideal” behavior. A few things are worth checking: Verify that the eMIOS channel is really counting the CW/CCW input pulses and not an internal clock source. Check the UIN status of the used eMIOS channel in the debugger. If UIN remains constant while the counter increments, the channel may not be using the intended external input. If UIN is toggling while the rotor is stationary, investigate encoder A/B signals, TRGMUX routing, LCU outputs, and input filtering. Also monitor the encoder A/B signals and LCU CW/CCW outputs on a scope to rule out noise or glitches. This should help determine whether the issue is caused by encoder signal activity/noise or by an eMIOS configuration issue. BR, Petr Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position Hi, I could not find any register corresponding to the UIN status in the S32K322 Reference Manual. 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 Reference Manual, eMIOS Channel 5 UC CNT corresponds to the CW counter, and eMIOS Channel 6 UC CNT corresponds to the CCW counter. However, I observed that both UC CNT registers keep incrementing continuously from 0 to 65535 (free-running), even when the rotor is in a static condition. Could you please let me know whether this behavior is expected, or suggest what could be causing it? I have attached a screenshot of the relevant register values for reference. Additionally, I verified the MCAL configuration, and it is configured correctly as per the application note that was shared. Support at earliest Regards, Thiru Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position Please reply for the query Re: Reg: S32K eMIOS Encoder CW/CCW Counter Behavior in Static Rotor Position Hi, I wrote UIN, but it should be UCIN bit of the channel S register. Based on register view I see Control register is set to 0x20E06D1, which indicate correct mode used 0x51, counting of external signal. Per my understanding LCn generates pulse streams on the CW or CCW output at every A/B signal edge, so with steady motor/encoder signals, no pulses should be generated and so counted. You can also check respective SIUL IMCR registers to be sure TRGMUX output is selected PetrS_0-1784696552579.png BR, Petr  

禁用 MPU 时 SRAM 的 S32K 默认属性 您好，NXP技术团队， 我想知道当S32K芯片的MPU未启用时，SRAM的默认属性是什么？具体来说，SRAM 默认设置中的“共享”和“缓存”属性分别是什么？ 我查阅了 ARMv7-m 架构参考手册，其中指出 SRAM 的设备类型为“device”，这似乎意味着整个 SRAM 是可共享的且不可缓存的。请看下图。 回到我的项目，该项目使用了 MWCT2016s（即当 MPU 未启用时，S32K312) 的 HSE 功能异常，需要配置 MPU 将 SRAM 区域设置为可共享且不可缓存。但是，在使用 S32K322 的项目中，当 MPU 未启用时，HSE 功能正常。 因此，我想知道在未启用 MPU 的情况下 S32K 芯片的 SRAM 属性，或者是否存在其他设置会影响 SRAM 属性，从而导致两个项目之间的差异？ 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 的存储器类型为普通型、不可共享型、WBWA 型。 此致， 丹尼尔

[S32N55 / HSE2] Debug Card Request — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR Hi, Following up on S32N55 (HSE2) Secure Debug. CRS(APP) challenge-response authentication now works (final response 0x4A4A4A4A). I am now on the debug card request (HSE_DEBUG_CMD_CARD_REQUEST), and it returns: HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR ((hseDebugError_t)0x20) — "invalid debug domain map in debug card." What I send (per your earlier feedback): Packet2 Debug Domain Signal List: array style, List[22..26] = 0x01 each (CRS: Cortex-M7, PCIe, CRS NoC/CAN NoC, CANXL0-1, CANXL2-3), all other bytes 0x00. Packet3 enabledDebugDomainMap (uint64_t): 0x07C00000 as advised (bits 22-26). AuthScheme: macAlgo = HSE_MAC_ALGO_CMAC = 0x11. AuthTag: AES256-CMAC over the card info, authLen = 16. What I have tried for enabledDebugDomainMap (uint64_t, 8 bytes on the wire): Little-endian: 00 00 C0 07 00 00 00 00 → 0x20 Big-endian: 00 00 00 00 07 C0 00 00 → 0x20 bit27 (0x08000000, matching AUTH target 0x1B) → 0x20 All return the same 0x20. Questions: 1. For CRS, what is the exact enabledDebugDomainMap (uint64_t) value HSE expects, and in what wire byte order? 2. Must enabledDebugDomainMap (Packet3 bitmask) be consistent with the Debug Domain Signal List (Packet2, array List[22..26])? What is the exact relationship? 3. The RM example states "domain 1,3 enabled → 0x00..A0." Could you clarify the domain-to-bit mapping so I can compute the CRS value? 4. Does HSE validate the domain map before verifying the AuthTag? I want to confirm whether 0x20 indicates only the domain map is wrong, or whether other fields (e.g. the AuthTag / signed data range) could also be causing HSE to stop at this point. I also want to confirm the signed data range for the card AuthTag: I currently compute AES256-CMAC over the card info fields (authKeyRef + reserved0 + ownerId + authScheme + signal list + domain map + UID list). Is this the correct data to sign? Best regards, Re: [S32N55 / HSE2] Debug Card Request — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR Hello, @EddiePark  Thanks for your post. 1. It is pleased to hear that the phase1 has been passed without issues.2.  For your phase2 queries, I am still checking with it for a more clear description, and would reply you later if there are any valuable updates To make it aligned, would you mind sharing with me the latest logs and corresponding scripts used again, which could be shared via message as usual. BR Chenyin  

[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 + domain map + UID list）に対してAES256-CMACを計算しています。これは署名するデータとして正しいですか？ よろしくお願いいたします。 Re: [S32N55 / HSE2] Debug Card Request — HSE_DEBUG_INVALID_DEBUG_DOMAIN_MAP_ERR こんにちは、 @EddiePark 投稿ありがとうございます。 1.フェーズ1が問題なく通過したと聞いて嬉しく思います。2.フェーズ2に関するご質問につきましては、より明確な説明を得るために現在確認中です。何か有益な情報が得られ次第、後ほどご連絡いたします。 整合性を合わせるために、最新のログと対応するスクリプトを再度共有してもらえますか?通常通りメッセージで共有できます。 BR チェイン

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 陈银