[S32K3] [RTD 7.0.1]BCTUモジュールにおける3つの課題 RTDコードバージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206のBCTUモジュールに3つの問題が見つかりました。詳細な問題点は以下のとおりです。   問題 1:ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの 1558 行目で、現在のコードではビットごとの OR 代入を使用しています: BctuBasePtr->FIFOERR |= FifoWatermarkMask;これを直接代入に変更する必要があります: BctuBasePtr->FIFOERR = FifoWatermarkMask;   問題2：ファイルAdc_TS_T40D34M70I1R0/src/Bctu_Ip.cの567行目と568行目に、既存のコードに誤ったビットシフト演算が含まれています。元のコードは以下のとおりです。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << インデックス) : 0U; これらの2行は、以下のように正しいシフトロジックに修正する必要があります。 ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << (Index * 2u)) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ?(BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (インデックス * 2u)) : 0U;   問題3: MCAL/SDKコード生成ツールとBCTUモジュールの静的ソースコードの間に型の整合性の問題があります。MCAL で生成されたコード ( Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m 、2397行目）では、ヘッダーファイルとCファイルの両方で定義されている配列は、一律にuint32型を採用しています。SDK生成コードでは、ヘッダーファイルとCファイルの型定義が一貫していません。eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.hの配列型は(249行目)は、BctuFifoDmaRawDataオプションが有効になっているかどうかに応じてuint16とuint32を切り替え、対応する配列はeclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.cの対応する配列です（317行目）はuint32型に固定されています。静的コード ( Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c 、1629行目）では、送信長（2バイトまたは4バイト）はBctuFifoDmaRawData構成に基づいて動的に決定されます。BctuFifoDmaRawDataオプションのチェックを外すと、以下の異常な問題がすべて発生します。 1.SDKプロジェクトの場合:ヘッダーファイルとCファイルの配列型が不一致で、直接コン パイル失敗を引き起こします。 2. MCALプロジェクトの場合:コンパイルは成功しますが、固定されたuint32配列定義のため メモリ容量の半分が無駄になります。さらに、各uint32データユニットには2つのADC結果が含まれているため、データ解析時にuint16の高値と低値を手動で分割する必要があります。 上記の3つのバグは、公式バージョンS32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206に存在します。NXPのソフトウェアエンジニアが次回RTDリリースでこれらのBCTUモジュールの欠陥を修正できることを期待しています。 Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module こんにちは、@ chenwilsoft あなたの質問は社内フォーラムにエスカレーションされており、設計チームからの確認を待っています。

小程序 您好，请问。请问有人能帮帮我吗？ 1.在 SE051P 上构建和加载自定义 Java Card 小程序的实际开发路径是什么（需要哪个 SDK、工具和 Java Card / GlobalPlatform 版本）？自定义小程序配置是在工厂完成的（由 NXP 或合作伙伴预加载），还是可以在颁发后通过 GlobalPlatform 安全通道在现场完成的？有哪些密钥管理要求？ 2. 获取 SE051P 部件以及开发和配置定制小程序的能力，是否有许可、保密协议或合作要求，或者最低订购量要求？ B. 支付逻辑与自定义逻辑的共存（一个安全元件与两个安全元件的对比） 3. 单个 JCOP Pay（支付）平台能否同时托管一个经 EMVCo 认证的支付小程序和一个具有独立应用程序逻辑的单独自定义 Java Card 小程序？或者 EMVCo 认证是否要求芯片仅运行支付小程序——这意味着自定义逻辑需要单独的安全元件？ 4. 如果可以在单个芯片上共存，加载自定义小程序是否会影响或使支付小程序的 EMVCo 认证失效？ C. 自定义小程序可使用单调计数器和加密功能 (SE051P) 5. 本地单调计数器安全对象是否可以通过 Java Card API 从自定义小程序访问，还是只能通过预装的 IoT 小程序接口访问？ 6. SE051P 上的自定义小程序可以使用哪些签名算法和 ECC 曲线（例如，ECDSA P-256/P-384、Ed25519）？是否也可以通过自定义小程序对存储在芯片上的值进行内部签名（如使用 POLICY_OBJ_INTERNAL_SIGN 机制）？ D. 纽扣电池（CR2032）设备的功率 7. 单个 ECDSA P-256 签名操作的典型持续时间（以毫秒为单位）是多少？SE051P 在非活动加密操作期间的空闲/待机电流是多少？（以便估算每次运行的能耗和待机能耗。） 8. 对于由高阻抗电源（例如 CR2032 纽扣电池）供电的器件，NXP 是否推荐特定的去耦电容或缓冲器来处理加密操作期间的 16.5 mA 峰值电流？ 9. 在 SE051P 中，免接触式接口能否通过射频供电（从读卡器场汲取能量）来运行自定义小程序操作，还是自定义片上逻辑需要外部电源（例如电池）？如果射频供电操作是可能的，那么在仅使用场功率的情况下，ECDSA 签名、签名验证、单调计数器递增、安全对象更新或其他非易失性存储器写入等操作是否存在限制？ 虚拟测试 Re: Applet 嗨@aaschi ， 感谢您的联系！我的评论如下： 1. 在 SE051P 上构建和加载自定义 Java Card 小程序的实际开发路径是什么（需要哪个 SDK、工具和 Java Card / GlobalPlatform 版本）？自定义小程序配置是在工厂完成的（由 NXP 或合作伙伴预加载），还是可以在颁发后通过 GlobalPlatform 安全通道在现场完成的？有哪些密钥管理要求？// 我们提供有关这些主题的文档，请通过安全文件通道索取。更多详情请参考以下内容。 2. 获取 SE051P 部件以及开发和配置定制小程序的能力，是否有许可、保密协议或合作要求，或者最低订购量要求？是的，需要签署保密协议，并且需要达到最低订购量。请联系您当地的恩智浦代表了解更多详情。 B. 支付逻辑与自定义逻辑的共存（一个安全元件与两个安全元件的对比） 3. 单个 JCOP Pay（支付）平台能否同时托管一个经 EMVCo 认证的支付小程序和一个具有独立应用程序逻辑的单独自定义 Java Card 小程序？或者，EMVCo认证是否要求芯片仅运行支付小程序——这意味着自定义逻辑需要一个单独的安全元件？不，您必须使用两个安全元件——一个经过认证的支付 SE 和一个用于专有逻辑的 SE051P/自定义 SE。 4. 如果可以在单个芯片上共存，加载自定义小程序是否会影响或使支付小程序的EMVCo认证失效？//不，这不可能。 C. 自定义小程序 (SE051P) 可使用单调计数器和加密 // SE05x IoT 小程序文档支持单调计数器安全对象，因此从硬件角度来看，SE051P 也应该支持，但这取决于您的自定义小程序实现。 5. 本地单调计数器安全对象是否可以通过 Java Card API 从自定义小程序访问，还是只能通过预装的 IoT 小程序接口访问？// 您无法在 SE051P 上安装 SE05x 预装的 IoT 小程序，您必须开发自己的自定义小程序。 6. SE051P 上的自定义小程序可以使用哪些签名算法和 ECC 曲线（例如，ECDSA P-256/P-384、Ed25519）？是否也可以通过自定义小程序对存储在芯片上的值进行内部签名（如使用 POLICY_OBJ_INTERNAL_SIGN 机制）？ SE05x IoT 小程序支持多种算法和曲线，因此 SE051P 也可能支持，但这取决于您的自定义小程序实现。 D. 纽扣电池（CR2032）设备的功率 7. 单个 ECDSA P-256 签名操作的典型持续时间（以毫秒为单位）是多少？SE051P 在非活动加密操作期间的空闲/待机电流是多少？（以便估算每次运行的能耗和待机能耗。）//ECDSAP-256 验证记录为 <55 毫秒；未找到签名计时。主动式非对称加密电流高达 16.5 mA。这些信息来自SE05x IoT 小程序，对于自定义小程序，则取决于您自己的实现。 8. 对于由高阻抗电源（例如 CR2032 纽扣电池）供电的器件，NXP 是否推荐使用特定的去耦电容或缓冲器来处理加密操作期间 16.5 mA 的峰值电流？//否确定了 CR2032 缓冲电容的具体值；设计峰值电流约为 16.5 mA，加上工作时间和电池 ESR。 9. 在 SE051P 中，免接触式接口能否通过射频供电（从读卡器场汲取能量）来运行自定义小程序操作，还是自定义片上逻辑需要外部电源（例如电池）？如果射频供电操作可行，那么在仅使用场强的情况下，诸如 ECDSA 签名、签名验证、单调计数器递增、安全对象更新或其他非易失性存储器写入等操作是否存在限制？//射频供电支持 SE051 操作，但必须确认和测试对自定义小程序加密/NVM 更新的 RF 专用支持。 希望对您有所帮助。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: Applet 嗨，Kan， 感谢您的详细解答，非常有帮助。我会将此帖子标记为正确答案。 关于问题 1：我想通过安全文件通道请求您提到的文档（SE051P 的自定义 Java Card 小程序开发路径 — SDK、工具、Java Card / GlobalPlatform 版本和小程序配置）。 请问您能告诉我具体的操作步骤吗？具体来说： 1.我该如何访问安全文件通道？我应该在与此社区帐户关联的 NXP 支持门户上开一个私人支持案例，还是有其他途径？ 2. 在签署保密协议之前，哪些文件可以获取？哪些文件需要通过您在问题 2 中提到的保密协议/当地代表途径获取？ 我现阶段的目标是审查开发路径文档，以规划原型阶段；之后将与当地代表讨论保密协议/最低订购量。 再次感谢， 阿斯基

Applet Hi, please. Can anyone help me? 1. What is the practical development path to build and load a custom Java Card applet on the SE051P (which SDK, tools, and Java Card / GlobalPlatform version)? Is custom-applet provisioning done at the factory (pre-loaded by NXP or a partner), or can it be done post-issuance in the field via a GlobalPlatform secure channel, and what key-management requirements apply? 2. Are there licensing, NDA, or partnership requirements — or a minimum order quantity — to obtain SE051P parts together with the ability to develop and provision custom applets? B. Coexistence of payment and custom logic (one vs. two secure elements) 3. Can a single JCOP Pay (payment) platform host, simultaneously, an EMVCo-certified payment applet AND a separate custom Java Card applet with independent application logic? Or does EMVCo certification require the chip to run only the payment applet — meaning a separate secure element would be required for the custom logic? 4. If coexistence on a single chip is possible, does loading a custom applet affect or invalidate the EMVCo certification of the payment applet? C. Monotonic counter and crypto available to a custom applet (SE051P) 5. Is the native monotonic Counter secure-object accessible from a custom applet via the Java Card API, or only through the pre-installed IoT applet interface? 6. Which signature algorithms and ECC curves are available to a custom applet on the SE051P (e.g., ECDSA P-256/P-384, Ed25519)? Is internal signing of a value stored on-chip (as with the POLICY_OBJ_INTERNAL_SIGN mechanism) available from a custom applet as well? D. Power for a coin-cell (CR2032) device 7. What is the typical duration (in milliseconds) of a single ECDSA P-256 signature operation, and what is the idle/standby current of the SE051P outside active crypto operations? (So that energy per operation and standby drain can be estimated.) 8. For a part powered by a high-impedance source such as a CR2032 coin cell, does NXP recommend a specific decoupling capacitor or buffer to handle the 16.5 mA peak current during a crypto operation? 9. In the SE051P, can the contactless interface operate RF-powered (drawing energy from the reader field) for custom-applet operations, or does custom on-chip logic require external power (e.g., a battery)? If RF-powered operation is possible, are there constraints — under field power alone — on operations such as ECDSA signing, signature verification, monotonic-counter increment, secure-object update, or other non-volatile memory writes? Virtual test Re: Applet Hi @aaschi , Thanks for the reaching out! Please have my comments as below: 1. What is the practical development path to build and load a custom Java Card applet on the SE051P (which SDK, tools, and Java Card / GlobalPlatform version)? Is custom-applet provisioning done at the factory (pre-loaded by NXP or a partner), or can it be done post-issuance in the field via a GlobalPlatform secure channel, and what key-management requirements apply? // We provide docs on these topics, please request them via the secure file channel. please refer to the following for more details. 2. Are there licensing, NDA, or partnership requirements — or a minimum order quantity — to obtain SE051P parts together with the ability to develop and provision custom applets? // Yes, NDA is needed, and MOQ as well. please check with your local NXP representative for more details. B. Coexistence of payment and custom logic (one vs. two secure elements) 3. Can a single JCOP Pay (payment) platform host, simultaneously, an EMVCo-certified payment applet AND a separate custom Java Card applet with independent application logic? Or does EMVCo certification require the chip to run only the payment applet — meaning a separate secure element would be required for the custom logic?// No, you have to use two secure elements — one certified payment SE and one SE051P/custom SE for proprietary logic. 4. If coexistence on a single chip is possible, does loading a custom applet affect or invalidate the EMVCo certification of the payment applet?// No, it is not possible. C. Monotonic counter and crypto available to a custom applet (SE051P)//The SE05x IoT-applet documentation supports monotonic counter secure objects, so from hardware perspective, it should support by SE051P as well, but it depends on your custom applet implementation. 5. Is the native monotonic Counter secure-object accessible from a custom applet via the Java Card API, or only through the pre-installed IoT applet interface? // you can not install the SE05x pre-installed IoT applet on SE051P, you have to develop your own custom applet.  6. Which signature algorithms and ECC curves are available to a custom applet on the SE051P (e.g., ECDSA P-256/P-384, Ed25519)? Is internal signing of a value stored on-chip (as with the POLICY_OBJ_INTERNAL_SIGN mechanism) available from a custom applet as well? // The SE05x IoT applet supports a broad set of algorithms and curves so SE051P can support but it depends on your custom applet implementation D. Power for a coin-cell (CR2032) device 7. What is the typical duration (in milliseconds) of a single ECDSA P-256 signature operation, and what is the idle/standby current of the SE051P outside active crypto operations? (So that energy per operation and standby drain can be estimated.)//ECDSA P-256 verification is documented as <55 ms; signing timing was not found. Active asymmetric crypto current is up to 16.5 mA. Such info is from The SE05x IoT applet, for a custom applet, it depends on your own implementation. 8. For a part powered by a high-impedance source such as a CR2032 coin cell, does NXP recommend a specific decoupling capacitor or buffer to handle the 16.5 mA peak current during a crypto operation?//No specific CR2032 buffer capacitor value was found; design around 16.5 mA peak plus operation time and cell ESR. 9. In the SE051P, can the contactless interface operate RF-powered (drawing energy from the reader field) for custom-applet operations, or does custom on-chip logic require external power (e.g., a battery)? If RF-powered operation is possible, are there constraints — under field power alone — on operations such as ECDSA signing, signature verification, monotonic-counter increment, secure-object update, or other non-volatile memory writes?//RF-powered SE051 operation is supported, but RF-only support for custom applet crypto/NVM updates must be confirmed and tested. Hope that helps, Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: Applet Hi Kan, Thank you for the detailed answers — very helpful. I will mark the post as correct. Following up on question 1: I would like to request the documents you mentioned (custom Java Card applet development path for the SE051P — SDK, tools, Java Card / GlobalPlatform versions, and applet provisioning) via the secure file channel. Could you please let me know the exact procedure? Specifically: 1. How do I access the secure file channel — should I open a private support case on the NXP support portal linked to this community account, or is there another route? 2. Which of these documents are available before an NDA is in place, and which ones require the NDA / local representative path you mentioned in question 2? My goal at this stage is to review the development path documentation to plan the prototype phase; the NDA/MOQ discussion with the local representative would follow. Thank you again, aaschi

S32K348-GPIO EIRQ 到 DMA 请求 尊敬的恩智浦技术支持团队： 我现在尝试的方法，将 GPIO PTD6 设置为 EIRQ14，上升沿检测，我想将此引脚信号映射到 DMA 通道，我尝试从 PIT_1 Timer[0] 获取当前值。这是自由奔跑模式。 看起来 SIUL2 已正确设置为 PTDA，当信号发生器发出的信号 (1Hz) 连接到相关的 MCU 引脚时，我可以看到该引脚切换。 但是DMA对我来说不起作用 我的猜测是，我的问题在于找不到从 PTD6 -> DMAMUX -> DMA 通道 4 的正确链路，也找不到在哪里可以找到这些信息。 从 S32K3xx_DMAMUX_map.xlsx 文件中我得到了以下内容： 我的第一个问题是：哪个源->请求是专用的 PTD6(EIRQ14)？ RM手册中的表44与此有何关联？ 以下是我目前正在编写的部分代码： 设置 PTD6 void Setup_PTD6_EIRQ14_for_DMA ( void ) { /* 1. 通过 MSCR 寄存器配置物理引脚 PTD6 */     // PTD6 对应于索引 MSCR[102]（如您的屏幕截图所示）     IP_SIUL2 -> MSCR [ 102 ] = 0 ； // 清除寄存器     IP_SIUL2 -> MSCR [ 102 ] |= ( 1 << 19 ); // IBE = 1（输入缓冲使能 - 将引脚配置为输入）     IP_SIUL2 -> IMCR [ 542 - ( 512 )] = 3u ;     // 可选：如果信号是浮动的，您可以启用上拉（PUE=1，PUS=1）或下拉（PUE=1，PUS=0） /* 2. 激活 EIRQ[14] 线上的边缘检测 */     我们希望捕获每个上升沿的时间戳     IP_SIUL2 -> IREER0 |= ( 1 << 14 ); // IREER0[EIRE14] = 1 (启用上升沿)     IP_SIUL2 -> IFEER0 &= ~ ( 1 << 14 ); // IFEER0[EIRE14] = 0 (禁用下降沿) /* 3. 请求路由：从中断更改为 DMA */     // 此步骤确保边沿不会唤醒 CPU（NVIC），而是触发 DMA 线路。     IP_SIUL2 -> DIRSR0 |= ( 1 << 14 ); // DIRSR0[DIRS14] = 1 (选择 DMA 请求而不是中断) /* 4. 最终启用 EIRQ[14] 的 DMA 请求生成 */     IP_SIUL2 -> DIRER0 |= ( 1 << 14 ); // DIRER0[EIRE14] = 1 (激活 DMA 请求线) }   并建立DMA通道： void Setup_eDMA_Channel4_Capture_PIT1 ( void ) { /* 1. eDMA 通道 4 的 DMAMUX 初始化 */     // 将 EIRQ14（源 14）映射到 eDMA 通道 4     IP_DMAMUX_1 -> CHCFG [ 4 ] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE ( 7u ); // EIRQ14 是 DMAMUX_1 的源 7     //IP_DMAMUX_0->CHCFG[4] = 0U; /* 2. 通道 4 的 TCD 配置指向 PIT_1（完全符合 S32K3 裸机语法） */     // 来源：PIT_1 定时器 0 的当前值     IP_TCD -> TCD4_SADDR = ( uint32_t ) & ( IP_PIT_1 -> TIMER [ 0 ]. CVAL );     IP_TCD -> TCD4_SOFF  = 0 ; // 源值不递增     IP_TCD -> TCD4_ATTR  = 0x0202 ； // 32 位源，32 位目标     // 次要循环：每次触发传输的字节数     // 在 S32K3 中，这对应于 NBYTES_MLOFFNO 寄存器（无次要循环链接）     IP_TCD -> NBYTES4 . TCD4_NBYTES_MLOFFNO = 4 ; // 每次触发信号传输 4 字节（32 位）     // 目标位置：内存中的数组     IP_TCD -> TCD4_DADDR = ( uint32_t ) dma_timestamps ;     IP_TCD -> TCD4_DOFF  = 4 ; // 每次边沿移动后，RAM 中的数据左移 4 个字节     // 循环缓冲区：填充完整个数组后循环回到数组开头     IP_TCD -> TCD4_DLAST_SGA = - ( BUFFER_SIZE * 4 );     // 主要循环计数器：循环中的总迭代次数     //IP_TCD->CITTER4.TCD4_CITER_ELINKNO = BUFFER_SIZE;     IP_TCD -> CITER4 . TCD4_CITER_ELINKNO = BUFFER_SIZE ;     IP_TCD -> BITER4 . TCD4_BITER_ELINKNO = BUFFER_SIZE ; /* 3. 通过官方宏激活硬件触发信号的 eDMA 通道 */     //IP_TCD->CH4_CSR |= DMA_TCD_CH4_CSR_ERQ_MASK; /* 3. 硬件触发信号的 eDMA 通道激活（启用异步模式） */     // 位 0 (ERQ) = 1 -> 启用硬件触发信号     // 位 2 (EARQ) = 1 -> 启用来自外部引脚的异步请求 (SIUL2 EIRQ)     IP_TCD -> CH4_CSR |= 3u ； // ERQ=1，EARQ=1 }   我想关键就在这里： IP_DMAMUX_1 -> CHCFG [ 4 ] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE ( 7u ); // EIRQ14 是 DMAMUX_1 的源 7 我有点困惑，不知道应该使用哪个 IP_DMAMUX 和哪个 DMAMUX_CHCFG_SOURCE，也不知道哪里可以找到相关的正确信息。 此致 翁德雷   Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK “这是否意味着MCU有32个TCD通道，其中TCD 0到15对DMAMUX_0有效，TCD 15到31对DMAMUX_1有效？ ” 是的，这些信息可以在数据手册中找到，我复制下来供您参考。 Re: S32K348-GPIO EIRQ to DMA request 你好 Senlent， 感谢您的解答。 请问您能否指出您所说的TCD映射的含义是从哪里产生的？ 这是否意味着，MCU 有 32 个 TCD 通道，其中 TCD 0 到 15 对 DMAMUX_0 有效，而 TCD 15 到 31 对 DMAMUX_0 无效？ 对于 DMAMUX_1？ 所以，我对DMAMUX和eDMA的相关信息仍然有些困惑。 此致 翁德雷 Re: S32K348-GPIO EIRQ to DMA request 你好@OndrejK 你的理解是正确的： PTD6->EIRQ14->DMAMUX1.SOURCE 7. IP_DMAMUX_1->CHCFG[4] = DMAMUX_CHCFG_ENBL_MASK | DMAMUX_CHCFG_SOURCE(7u); // EIRQ14 is source 7 for DMAMUX_1 但是，TDC 设置不正确。 我的理解是，它们应该如下所示： IP_DMAMUX_1->CHCFG[0] ->TCD 16 IP_DMAMUX_1->CHCFG[4] -> TCD 20 而不是 TCD4

i.MX8QMマルチディスプレイセットアップでのAAOS 15ユーザースイッチクラッシュ こんにちは、チームの皆さん、 私たちは Android オートモーティブ OS 15(AAOS 15) を i.MX8QuadMax ボード 上で マルチ ディスプレイ 構成( メイン ディスプレイ + 乗客 ディスプレイ)で動かしています。 ユーザー 切り替え 時に デフォルトの Car Launcher に 問題 が発生しています: システムは 正常に 起動し 、 ランチャー は メインディスプレイ と 助手席側 ディスプレイの 両方 に 表示され ます 。 現在の ユーザー から 新規ユーザー や ゲスト ユーザーに 切り替え ると 、 メイン ディスプレイ と 乗客 用ディスプレイ の両方 が クラッシュ し、 使用不能 になります 。 The issue is consistently reproducible after ユーザー switching. 私たちは 以下のこと を 知り たい のです 。 i.MX8QM マルチ ディスプレイ システム での AAOS 15 での ユーザー スイッチ ングに関する 既知 の問題 はありますか? Are there any additional configurations required for passenger display handling during user スイッチ? この 問題 を さらに 分析する ために、 どのような ログ や デバッグ 情報 を 収集 す べきでしょうか ？ 何かご提案やアドバイスがあれば、ぜひお聞かせください。 ありがとうございます。 Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup こんにちは、 @AldoG さん。 ご説明ありがとうございます。   弊社で は、 NXP BSPを搭載したNXP i.MX8QM MEK ボード を 使用 し ています 。この 問題 は Android オートモーティブに関連しているため、 AAOS関連 の適切な サポート チャネル や フォーラム を 教え ていただければ 幸いです 質問はありますか? ありがとうございます。 Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup こんにちは、 NXP MEKボードを使用していますか？ もしそうなら、NXP BSPを使っていますか? なお、当サイトはAndroid オートモーティブをサポートしていませんが、BSPリリースで問題が発生した場合は支援が可能です。 よろしくお願いいたします。 アルド。

Regarding the RTC_XTALI signal processing of MIMX9121CVVXCAA Hello, I am considering using the i.MX91 SOC MIMX9121CVVXCAA. Question: The clock for the RTC uses the clock from the oscillator circuit inside the SOC, eliminating the need for an external oscillator. I'm planning to leave the RTC_XTALI and RTC_XTALO pins unconnected. Should I pull down the RTC_XTALI pin on the board? I look forward to your reply. Re: MIMX9121CVVXCAAのRTC_XTALI信号処理について Recommendation If RTC functionality is required, follow the recommendation in UG10147 and use an external 32.768 kHz crystal (with the appropriate load capacitors), or alternatively provide an external clock to RTC_XTALI with a frequency below 50 kHz and an amplitude not exceeding NVCC_BBSM_1P8. If the RTC is not used, simply leave RTC_XTALI and RTC_XTALO unconnected (NC). Do not add a pull-down resistor. In addition, ensure that the insulation resistance from these traces to power and ground remains greater than 100 MΩ to avoid leakage caused by flux residue, moisture, or coupling to adjacent traces. The i.MX 91 does not have an independently operating internal 32.768 kHz oscillator. Therefore, if RTC functionality is not required, RTC_XTALI and RTC_XTALO should be left NC, and a pull-down resistor should not be added. This is because the datasheet specifies that the leakage path from these pins to power or ground should be greater than 100 MΩ. 推奨事項 RTC機能が必要な場合は、UG10147 の推奨に従い、32.768 kHz水晶発振子（負荷容量を含む）を接続するか、RTC_XTALI に周波数50 kHz未満、振幅が NVCC_BBSM_1P8 を超えない外部クロックを入力してください。 RTC機能を使用しない場合は、RTC_XTALI と RTC_XTALO の両方を NC（未接続） のままとしてください。プルダウン抵抗は追加しないでください。 また、フラックス残渣、湿気、または隣接配線によるリーク電流を防ぐため、これらの配線と電源／GND間の絶縁抵抗が 100 MΩ以上 となるようにしてください。 i.MX 91 には、単独で動作する内蔵32.768 kHz発振器はありません。 したがって、RTC機能を使用しない場合は、RTC_XTALI および RTC_XTALO を NC（未接続） のままとし、プルダウン抵抗を追加しないでください。データシートでは、これらのピンから電源またはGNDへのリーク経路は 100 MΩ以上 であることが要求されています。

S32Kコンパレータの許容差/オフセット S32K116の比較器でテストを行っています。 入力電圧(238mV)をINN(またはINP)に印加し、バンドギャップを基準にしてからVOSELを0から255に上げ、コンパレータ出力の変化を監視します。 入力電圧とバンドギャップの接続を入れ替えると、MCU2で異なる許容誤差/オフセットが見られるという現象が見られます。（詳細はテスト1およびテスト2を参照） 1) これはVAIOのような既知の機能なのでしょうか、それとも他の何かですか? 2) この許容差/オフセットについて安定していますか?また、校正でこれを除去できますか? （例えば、目標電圧におけるトリガーVOSELを記録するなど） テスト1：入力電圧V-、バンドギャップV+ 、低速モード テスト2：入力電圧V+、バンドギャップV- 、低速モード 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があります。 5) ヒステリシス 低速モードでのヒステリシスに関するテストデータはあります。 ここでのテストデータは、入力電圧を固定し、VOSELを増加させるものです。 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のマスクについて教えてくれ。 よろしくお願いいたします ロビン

S32 Design Studio for ARM v2.2のライセンスは期限切れです こんにちは、私のARM v2.2用のS32 Design Studio ライセンスが期限切れになりました。延長してもらえますか? 有効期限：2026年6月29日 製品:ARM v2.2用S32 Design Studio ライセンス：27ED-C7E9-C2B4-9D3E Re: license of S32 Design Studio for ARM v2.2 has expired こんにちは、 お客様のS32DSライセンスが延長されました。

HSE INSTALL S32K311 All the content below is copied from the attachment. S32DS version: S32DS.3.5_b220726_win32.x86_64 (1).exe RTD version: SW32K3_RTD_R21-11_3.0.0_P07_D2306_DS_updatesite.zip S32K311 Support Package Version: SW32K3_S32DS_3.5.6_D2309.zip SBAF version: SBAF_S32K311_0_0_15_0 Bin file: s32k311_Secure_Baf_0.12.0_0.15.0.6_pb230804.bin.pink HSE version: HSE_FW_S32K311_0_2_40_0 The bin file is s32k311_hse_fw_0.12.0_2.40.0_pb230730.bin.pink Use FULL_MEM No safe boot A problem currently encountered The program will get stuck here: `while ( FALSE == HSE_CheckStatus(HSE_STATUS_INIT_OK) );`           Re: HSE INSTALL S32K311 This is supplementary printf information. DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 Current_SBAF_Version-0x4039c020: 0x00000C00 LC configuration word -0x4039C02C: 0x00000000 Lifecycle-related information - 0x402AC200: 0x00000000 HSE Status: 0x00000000 I've looked up information online, and it seems the SBAF that comes with the chip doesn't recognize the HSE firmware I'm currently using. Re: HSE INSTALL S32K311 I suspect that SBAF failed to copy the HSE firmware from the flash memory to the HSE_NVM. If this is the problem, how should I resolve it? Re: HSE INSTALL S32K311 This is the data I printed. DCMROF21: 0x00040000 HSE GPR3: 0x000000C0 HSE Status: 0x00000000 HSE firmware not started (NVM empty or firmware corrupted) Re: HSE INSTALL S32K311 Hi @iiiddd  Could you please share the value of HSE_CONFIG_GPR3 (0x4039C028)? Bit 0 indicates whether the HSE Firmware is present. BR, VaneB Re: HSE INSTALL S32K311 The RTD library I'm using is called when writing UTEST. gHsePort_FlsIf.writeApi(UTEST_BASE_ADDR,(uint8_t*)hseFwFeatureFlag,FW_FEATURE_FLAG_LEN); The FLS_MAX_VIRTUAL_SECTOR definition will be used. My RTD library defaults to 135, but accessing the address 0x1B000000UL requires 136. Is the RTD library I'm using incompatible with HSE?

关于 MIMX9121CVVXCAA 的 RTC_XTALI 信号处理 您好，我正在考虑使用 i.MX91 SoC MIMX9121CVVXCAA。 问题： RTC 的时钟使用 SoC 内部振荡器电路的时钟，无需外部振荡器。 我计划将 RTC_XTALI 和 RTC_XTALO 引脚断开。我是否应该将板上的 RTC_XTALI 引脚拉低？期待您的回复。 Re: MIMX9121CVVXCAAのRTC_XTALI信号処理について 推荐 如果需要 RTC 功能，请按照UG10147中的建议，使用外部 32.768 kHz 晶体（带适当的负载电容），或者为RTC_XTALI提供频率低于 50 kHz 且幅度不超过NVCC_BBSM_1P8 的外部时钟。 如果 RTC 未使用，只需将RTC_XTALI和RTC_XTALO断开连接 (NC) 即可。不要添加下拉电阻。此外，确保这些走线到电源和地线的绝缘电阻大于100 MΩ ，以避免因焊剂残留、湿气或与相邻走线耦合而引起的泄漏。 i.MX 91 没有独立运行的内部 32.768 kHz 振荡器。因此，如果不需要 RTC 功能，则RTC_XTALI和RTC_XTALO应保持NC 状态，并且不应添加下拉电阻。这是因为数据手册规定，这些引脚到电源或地的漏电路径应大于100 MΩ 。 推奨事项 RTC机能が必要な场合は、 UG10147の推奨に従い、32.768kHz水晶発振子（负担负担を含む）を接続するか、 RTC_XTALIに周波数50 kHz未満、振幅がNVCC_BBSM_1P8を超えない外部クロックを入力してください。 RTC机能を使用しない场合は、 RTC_XTALIとRTC_XTALOの両方をNC （未接続）のままとしてください。プルダウン抵抗は追加しないでください。また、furakkusu残渣、湿気、または邻接配线によるリーク电流を防ぐため、これらの配线と电源／GND间の绝縁抗が100 MΩ以上となるようにしてください。 i.MX 91 には、単独で动作する内蔵32.768 kHz発振器はありません。したがって、RTC机能を使用しない场合は、 RTC_XTALIおよびRTC_XTALOをNC （未接続）のままとし、プルダウン抵抗を追加しないでください。データshitoでは、これらのピンから电源またはGNDへのリーク経路は100 MΩ以上であることが要求されています。

Local Access Windows (LAWs), memory overlap About LAW understanding : about the B4860 , just e.g B4860QDS; Local Access Windows (LAWs): in the B4860_QDS_Init.tcl file have set the Local Access Window Registers (as below have defined the phy address 0x000000, size 2Gbytes target to DDR) and in the  dpaa_demo.c of CW_SC_3900FP_v10.8.3\SC\StarCore_Support\SmartDSP\demos add the LAW setting the phy address 0x20000000 target  to  QMAN my query or confusing is  the LAW 10 setting (0x0000000~0x7fffffff target to DDR)   memory overlapped with  QMAN software port  LAW setting the phy address 0x20000000 target  to  QMAN. memory overlapped  between LAW , is it ok? and can explain detail why it can work ? there is not descript memory overlapped situation of LAW  in the reference manual of B4860.  ## LAW10 to DDRC2  # LAWBARH  mem [CCSR_ADDR 0x000CA0] = 0x00000000  # LAWBARL  mem [CCSR_ADDR 0x000CA4] = 0x00000000  # LAWAR  mem [CCSR_ADDR 0x000CA8] = 0x8110001E Re: Local Access Windows (LAWs), memory overlap It’s interesting how local administrative systems handle data integration, especially when managing complex files like local access windows and memory overlap. Navigating these technicalities can sometimes feel as complicated as dealing with a newsportnewscourt.org schedule. Having a reliable, centralized resource to clear up the confusion makes a huge difference. Hopefully, more updates will roll out soon to make these processes much smoother for everyone involved. Re: Local Access Windows (LAWs), memory overlap Thanks for sharing the [RTD200P04 MCAL] S32M244 PWM PDB ADC MCAL demo—really helpful for developers working with embedded systems. For those handling compliance or security logging alongside hardware interfaces, reviewing Missouri offense records could offer useful insights for managing real-world data inputs. Always good to bridge technical applications with broader contextual awareness. Re: Local Access Windows (LAWs), memory overlap Please refer to the B4860 QorIQ Qonverge Multicore Baseband Processor Reference Manual, 2.3.1 Precedence of Local Access Windows.

S32 Design Studio for ARM v2.2 的许可证已过期。 您好，我的 S32 Design Studio for ARM v2.2 许可证已过期。你能帮我延长一下吗？ 有效期至：2026年6月29日 产品：S32 Design Studio for ARM v2.2 许可证：27ED-C7E9-C2B4-9D3E Re: license of S32 Design Studio for ARM v2.2 has expired 你好， 您的S32DS许可证已延期。

ローカルアクセスウィンドウ(LAW)、メモリの重複 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> LAWの理解について：B4860について、例えばB4860QDSなど。 ローカルアクセスウィンドウ(LAW): B4860_QDS_Init.tclファイル内でローカルアクセスウィンドウレジスタを設定しています(以下のように、phyアドレス0x000000、サイズ2GbytesのターゲットをDDRに定義しています) CW_SC_3900FP_v10.8.3\SC\StarCore_Support\SmartDSP\demos の dpaa_demo.c 内 LAW設定をQMANに物理アドレス0x20000000ターゲットとして追加します。 私の疑問や混乱は、LAW 10の設定(0x0000000~0x7fffffff ターゲットをDDRに)メモリがQMANソフトウェアのポートLAWと重なっていて、ターゲット0x20000000のPHYアドレスをQMANに設定したことです。 記憶がLAWで重なっているのですが、大丈夫ですか?そして、なぜそれが機能するのか詳細を説明できますか?B4860の**リファレンス・マニュアル**には、LAWのメモリ重複状況の記述はありません。 ## LAW10からDDRC2へ # ローバー mem [CCSR_ADDR 0x000CA0] = 0x00000000 # LAWBARL mem [CCSR_ADDR 0x000CA4] = 0x00000000 # 戦争 mem [CCSR_ADDR 0x000CA8] = 0x8110001E Re: Local Access Windows (LAWs), memory overlap ローカル管理システムがデータ統合をどのように扱うかは興味深いです。特にローカルアクセスウィンドウやメモリの重複のような複雑なファイルを管理する際には。こうした細かい問題を乗り越えることは、時に、newsportnewscourt.org を扱うのと同じくらい複雑に感じることがありますスケジュール。混乱を解消するための信頼できる一元化された情報源があることは、非常に大きな違いを生む。関係者全員にとってこれらのプロセスがよりスムーズになるよう、近いうちにさらなるアップデートが実施されることを期待します。 Re: Local Access Windows (LAWs), memory overlap [RTD200P04 MCAL] S32M244 PWM PDB ADC MCALのデモを共有していただきありがとうございます。組み込みシステムを開発している開発者にとって非常に役立ちます。コンプライアンスやセキュリティログをハードウェアインターフェースと併用する方にとって、 ミズーリ州のオフェンス記録 を確認することは、実際のデータ入力を管理するための有用な洞察を提供するかもしれません。技術的なアプリケーションとより広い文脈認識をつなぐのはいつも良いことです。 Re: Local Access Windows (LAWs), memory overlap <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> B4860 QorIQ Qonverge マルチコアベースバンドプロセッサリファレンスマニュアル2.3.1「ローカルアクセスウィンドウの優先順位」をご参照ください。

NXPはMC33XS2410のプロトタイピング用にシンプルなTSSOP28ブレークアウト/アダプタボードを提供していますか？ こんにちは、皆さん 現在、12Vの自動車プロジェクトのためのプロトタイピングとテストベンチを設置中です。NXP社の推奨に従い、保護回路にはMC33XS2410（eFuse）を選定しました。 しかし、私たちは組み立て工房で、現時点ではカスタムPCBの**デザイン**や製造ができないため、0.65mmのピッチとサーマルパッドを持つHTSSOP28**パッケージ**の扱いは手配線にとって物理的に難しいです。 フル機能のFRDM-XS2410EVB評価ボードは認識していますが、この特定のテストベンチでの即時のニーズには複雑すぎ、規模も高すぎます。ピンにアクセスするための最小限の方法だけで十分です。 Aries ElectronicsのLCQT-TSSOP28ブレイクアウトボードのような汎用サードパーティアダプターを購入する前に、NXPコミュニティにお聞きしたいと思います。 NXPは、MC33XS2410のHTSSOP28パッケージを標準の2.54mm DIPピンに変換するための、低コストで最小限のブレイクアウトボードやプロトタイピングアダプターを提供していますか? そうでない場合、NXPは、このチップとの互換性が実証されている特定のサードパーティ製アダプタまたはソケットのブランドを公式に推奨していますか（露出した中央パッドの接地および放熱要件を考慮して）？ お時間とご協力、本当にありがとうございました！ 評価ボード StarCore DSP Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping トーマスさん、説明と注意点を教えていただきありがとうございます。私のカードに関しては、それが解決策だと思います。 Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping こんにちは、モハメドさん。 現在、MC33XS2410 HTSSOP28パッケージを標準の2.54 mm DIPスタイルのフットプリントに直接変換する専用の低コストブレイクアウトボードやアダプターボードは提供していません。ご指摘の通り、私たちはFRDM-XS2410EVBを提供しており、これは単純なパッケージ適応ではなく、完全な機能評価を目的としています。 重要な考慮点の一つは、MC33XS2410パッケージの露出したサーマルパッドであり、熱性能と電気性能の両方を考慮してGNDにはんだ付けされるべきです。また、露出パッドをグラウンドプレーンに接続し、生産設計では熱放散を改善するために熱ビアを使用することも推奨しています。 また、汎用ブレークアウトボードは、一般的に機能プロトタイプの作成や低消費電力のベンチテストに適している点にご注意ください。しかし、適切に設計されたPCBで得られる熱性能を通常は提供できず、テスト可能な最大連続電流を制限する可能性があります。 もし用途がデバイスの電流制限付近で動作する必要がある場合は、熱性能を慎重に評価するか、公式の評価ボードを使うことをお勧めします。 BRs、トーマス

S32K312 EVB - SD Card SPI Initialization using LPSPI Hardware PCS0 Hi, I am implementing an SD Card driver over SPI on the S32K312 EVB using RTD 6.0.0 (Non-AUTOSAR Lpspi_ Ip driver). According to the SD Physical Layer Simplified Specification, the SPI initialization sequence is: Keep CS HIGH after power-up. Generate at least 74 clock pulses (I am sending 80 clocks by transmitting 10 bytes of 0xFF). Pull CS LOW. Send CMD0 (0x40 00 00 00 00 95). Keep CS LOW while polling with 0xFF until the card responds with **R1 = 0x01`. My issue is with hardware-controlled PCS0. When using the Lpspi_Ip driver with hardware PCS0, the PCS signal is automatically asserted/deasserted by the LPSPI peripheral during SPI transfers. Because of this, I cannot generate the initial 80 clock pulses while keeping CS HIGH and then CMD0 with CS LOW, as required by the SD specification. I have the following questions: Does the S32K312 LPSPI peripheral support keeping PCS inactive (HIGH) while generating SPI clocks? Is there any Lpspi_Ip API, register configuration, or recommended method to manually control PCS or temporarily disable hardware PCS during the SD card initialization sequence? If not, is the recommended approach to configure the SD card CS pin as a GPIO and manually control it while using LPSPI only for SCK, MOSI, and MISO? Additionally, if NXP has any reference implementation, application note, example project, or SDK/RTD example demonstrating SD card communication over SPI on the S32K3 series, could you please share the reference? Thank you. Re: S32K312 EVB - SD Card SPI Initialization using LPSPI Hardware PCS0 Hi @parvathitp  The PCS (Peripheral Chip Select) signal is designed to be controlled by the LPSPI module. When a hardware PCS is selected, it is automatically asserted and deasserted by the LPSPI peripheral during SPI frame transfers. There is no dedicated API available to manually control a hardware PCS signal while it is assigned to the LPSPI module. Therefore, as you mentioned, the best approach for this case is to configure the CS pin as a GPIO. In this configuration, the CS signal is controlled through the SIUL2/GPIO APIs, and you are responsible for controlling it.  Currently, there is no S32K3-specific application note, example project, or reference document that demonstrates this exact implementation. BR, VaneB

NXP是否提供用于MC33XS2410原型设计的简易TSSOP28分线/适配器板？ 大家好， 我们目前正在为一个 12V 汽车项目搭建原型和测试平台。根据 NXP 的建议，我们为保护电路选择了 MC33XS2410（电子熔断器）。 然而，由于我们身处组装车间，目前无法设计或制造定制PCB，因此对于手工布线而言，处理HTSSOP28封装（间距为0.65mm，带有散热焊盘）在物理上具有挑战性。 虽然我们知道功能齐全的 FRDM-XS2410EVB 评估板，但它对于我们目前在这个特定测试台上的需求来说太复杂、太大、太贵了。我们只需要一种最简便的方法来访问引脚。 在购买通用第三方适配器（例如 Aries Electronics 的 LCQT-TSSOP28 分线板）之前，我们想先咨询一下 NXP 社区： NXP 是否提供低成本、极简的转接板或原型适配器，专门用于将 MC33XS2410 的 HTSSOP28 封装转换为标准的 2.54mm DIP 引脚？ 如果没有，NXP 是否正式推荐任何经过验证可与该芯片良好配合使用的第三方适配器或插座品牌（考虑到裸露中心焊盘的接地和散热要求）？ 非常感谢您抽出时间提供帮助！ 评估板 StarCore DSP Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping 感谢托马斯的解释和注意事项，我想这就是我该如何处理我的卡片的方法。 Re: Does NXP offer a simple TSSOP28 breakout/adapter board for MC33XS2410 prototyping 你好，穆罕默德， 目前我们没有提供专用的低成本转接板或适配器板，可以将 MC33XS2410 HTSSOP28 封装直接转换为标准的 2.54 毫米 DIP 封装。您说得对，我们提供的 FRDM-XS2410EVB 是用于全面功能评估，而不是简单的代码包，软件包适配。 一个重要的考虑因素是 MC33XS2410 封装的裸露散热焊盘，为了保证散热和电气性能，应该将其焊接至 GND。我们还建议将裸露的焊盘连接到接地平面，并且在生产设计中，使用导热过孔来改善散热。 另请注意，通用分线板通常适用于功能原型设计和低功耗台式测试。然而，它们通常无法提供设计合理的 PCB 所能达到的热性能，这可能会限制可以测试的最大连续电流。 如果您的应用需要接近设备的限流运行，我建议您仔细评估其散热性能，或者使用官方评估板。 BRs，托马斯

license of S32 Design Studio for ARM v2.2 has expired Hi, my license of S32 Design Studio for ARM v2.2 has expired. Could you please extend it for me? Expiration Date: Jun 29, 2026 Product: S32 Design Studio for ARM v2.2 license：27ED-C7E9-C2B4-9D3E Re: license of S32 Design Studio for ARM v2.2 has expired Hi,  your S32DS license has been extended. 

本地访问窗口（LAW），内存重叠 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 关于 LAW 理解：关于 B4860，例如 B4860QDS； 本地访问窗口（LAW）： 在 B4860_QDS_Init.tcl 文件中设置了本地访问窗口寄存器（如下所示，定义了物理地址 0x000000，大小 2Gbytes，目标为 DDR）。 在 CW_SC_3900FP_v10.8.3\SC\StarCore_Support\SmartDSP\demos 目录下的 dpaa_demo.c 文件中 将 LAW 设置 phy 地址 0x20000000 添加到 QMAN 我的疑问或困惑是，LAW 10 设置（目标地址为 0x0000000~0x7fffffff 的 DDR 内存）与 QMAN 软件端口 LAW 设置（目标地址为 0x20000000 的 QMAN 内存）重叠。 LAW 内存重叠，这样可以吗？能否详细解释一下为什么可以运行？B4860 参考手册中没有描述 LAW 内存重叠的情况。 ## LAW10 至 DDRC2 # LAWBARH mem [CCSR_ADDR 0x000CA0] = 0x00000000 # 律师协会 内存 [CCSR_ADDR 0x000CA4] = 0x00000000 # LAWAR 内存 [CCSR_ADDR 0x000CA8] = 0x8110001E Re: Local Access Windows (LAWs), memory overlap 本地管理系统如何处理数据集成是一件很有趣的事情，尤其是在管理本地访问窗口和内存重叠等复杂文件时。处理这些技术细节有时会感觉像处理newsportnewscourt.org一样复杂。日程。拥有一个可靠的、集中的资源来消除困惑，会产生巨大的影响。希望后续会有更多更新推出，使这些流程对所有相关人员来说都更加顺畅。 Re: Local Access Windows (LAWs), memory overlap 感谢分享 [RTD200P04 MCAL] S32M244 PWM PDB ADC MCAL 演示——这对从事嵌入式系统开发的开发人员来说真的很有帮助。对于那些负责处理合规性或网络安全日志记录以及硬件接口的人员来说，审查密苏里州的犯罪记录可以为管理现实世界的数据输入提供有用的见解。将技术应用与更广泛的背景知识联系起来总是有益的。 Re: Local Access Windows (LAWs), memory overlap <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 请参阅 B4860 QorIQ Qonverge 多核基带处理器参考手册，2.3.1 本地访问窗口的优先级。

MIMX9121CVVXCAAのRTC_XTALI信号処理について こんにちは、i.MX91 SOC MIMX9121CVVXCAA使用を検討しています。 質問内容： RTC用のクロックはSOC内部の発振回路のクロックを使用することで、外部発振子を未実装にして RTC_XTALIとRTC_XTALOピンは何も接続しないように考えています。RTC＿XTALIのピンは基板側でプルダウンしたほうがいいのでしょうか。回答をお待ちしております。 Re: MIMX9121CVVXCAAのRTC_XTALI信号処理について 推奨事項 RTC機能が必要な場合は、 UG10147の推奨事項に従って、外部32.768kHz水晶発振器（適切な負荷コンデンサ付き）を使用するか、または、周波数が50kHz未満で振幅がNVCC_BBSM_1P8を超えない外部クロックをRTC_XTALIに供給してください。 RTCが使われていない場合は、単にそのまま RTC_XTALI と接続されていない(NC) RTC_XTALO してください。プルダウン抵抗器は追加しないでください。さらに、フラックス残留物、湿気、または隣接する配線との結合による漏洩を防ぐため、これらの配線から電源および接地までの絶縁抵抗が100 MΩ以上であることを確認してください。 i.MX 91には、独立して動作する内部32.768kHz発振器は搭載されていません。したがって、RTC機能が不要であれば、 RTC_XTALI と RTC_XTALO は NCのままにし、プルダウン抵抗を追加すべきではありません。これは、データシートに、これらのピンから電源またはグランドへのリーク経路が100 MΩ以上である必要があると規定されているためです。 推奨事項 RTC機能が必要な場合は、 UG10147の推奨、32.768 kHzの水晶発振子（負荷容量を含む）を接続するか、 RTC_XTALIに周波数50 kHz未満、振幅がNVCC_BBSM_1P8を超えない外部クロックを入力してください。 RTC機能を使用しない場合は、RTC_XTALI と RTC_XTALO の両方を NC(未接続) のままとしてください。プルダウン抵抗は追加しないでください。また、 フラックス残渣、湿気、または隣接配線によるリーク電流を防ぐため、これらの配線と電源/GND間の絶縁抵抗が 100 MΩ以上 となるようにしてください。 i.MX 91 には、単独で動作する内蔵32.768 kHz発振器はありません。したがって、 RTC機能を使用しない場合は、RTC_XTALI および RTC_XTALO を NC(未接続) のままとし、プルダウン抵抗を追加しないでください。データシートでは、これらのピンから電源またはGNDへのリーク経路は 100 MΩ以上 であることが要求されています。

AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup Hello Team, We are running Android Automotive OS 15 (AAOS 15) on the i.MX8QuadMax board with a multi-display setup (Main Display + Passenger Display). We are observing an issue with the default Car Launcher during user switching: System boots normally and the launcher is displayed on both main and passenger displays. When switching from the current user to a new user or guest user, both the main display and passenger display crash and become unusable. The issue is consistently reproducible after user switching. We would like to know: Is there any known issue related to user switching in AAOS 15 on i.MX8QM multi-display systems? Are there any additional configurations required for passenger display handling during user switch? What logs or debug information should we collect to further analyze this issue? Any suggestions or guidance would be appreciated. Thanks. Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup Hi @AldoG, Thanks for the clarification.   We are using the NXP i.MX8QM MEK board with NXP BSP. Since this issue is related to Android Automotive, could you please let us know the correct support channel or forum where we should raise our AAOS-related questions? Thank you. Re: AAOS 15 User Switch Crash on i.MX8QM Multi-Display Setup Hello, Are you using NXP MEK board? If yes, you are using NXP BSP? Please note that we do not support Android Automotive we can provide asistance if issues are found on our BSP release. Best regards/Saludos, Aldo.