NXP Cup 2026/27: can teams still get the FRDM-MCXN947 and Pixy 2 from the organizers? Hi, We’re a team from Hochschule Bremerhaven (Nordsee Nitro) taking part in the NXP Cup EMEA 2026/27, and we’re building the 3D-printed MCXN947 kit from the Gitbook. The component list on the Gitbook says the FRDM-MCXN947 board and the Pixy 2 camera can be received from the organizers. https://nxp.gitbook.io/nxp-cup/2025-fall-2026-nxp-cup-mcxn947/assembly-and-hardware/component-list Is that still the case this season? And if so, how do we request them? Do we need to be registered first, or does it go through our coordinator? We’re about to order the rest of the parts and don’t want to buy these two twice, so any info helps. Thanks, Ihtisham

S32DS_ARM_Win32_v2018.R1_b180326.exe activation failed. Activation code expired: 8FE5-AD8E-E76D-42C8

S32 Design Studio バージョン v.3.5 ライセンス こんにちは、NXPサポートチームの皆さん、 私のS32 Design Studio バージョン3.5のライセンスは2026年10月19日に期限切れとなりました。ライセンス延長を手伝ってもらえますか? 起動コード:30E0-0F7D-F883-9AFB サポートありがとうございます。 Eclipse IDEの使用と設定

HSE [Wait for Interrupt(WFI)] status understanding Currently, I am working on MCU clock initialization and waiting for the HSE to enter the WFI state (CLOCK_IP_WFI_EXECUTED == 0x80000000U) before proceeding with the clock configuration. The current implementation is shown below. However, my concern is that if the HSE never transitions to the WFI state, the ECU will remain stuck in the waiting loop indefinitely. Could you please suggest a suitable safeguard or timeout mechanism to handle this scenario safely? do { WfiStatus = (IP_MC_ME->PRTN0_CORE2_STAT & MC_ME_PRTN0_CORE2_STAT_WFI_MASK); } while (CLOCK_IP_WFI_EXECUTED != WfiStatus); Re: HSE [Wait for Interrupt(WFI)] status understanding Hi @ManuSharma1  The worst case is HSE firmware installation, update, or recovery, which can take approximately 1 second as mentioned in HSE-B firmware reference manual. Therefore, I would recommend a timeout of approximately 1.3 seconds to provide some margin and avoid an infinite wait if the expected WFI state is not reached. Regards, Lukas

Matter Stack 移植到 MIMXRT700-EVK (MIMXRT798S) — 持久存储初始化失败 您好， 我目前正在使用 MCUXpresso SDK 和 VS Code 将 NXP Matter 协议栈移植到 MIMXRT700-EVK (MIMXRT798S)板上。该板使用基于 IW612 芯片组的外部 Murata Type 2EL 无线模块。 开发设置和变更 我通过 VS Code 下载并设置了 Matter MCUXpresso SDK 工作区。该工作区位于matter_mcuxpresso/mcuxsdk 。 我针对RT700进行了以下方面的修改： Matter:修改了中间件/matter下的文件，用于 RT700 平台集成。 无线框架：增加了对外部 Murata Type 2EL (IW612) 无线模块的 RT700 特定平台支持和集成。 链接器脚本：使用 RT700 SDK 提供的MIMXRT798Sxxxx_cm33_core0_flash.ld作为参考，并根据 Matter 应用程序的内存布局和 NVS 存储配置对其进行了修改。 问题描述 Matter 应用程序构建成功，并且可以使用 LinkServer 进行编程。但是，运行时初始化失败，并在src/platform/nxp/common/NXPConfigNVS.cpp中的以下调用处出现CHIP_ERROR_PERSISTED_STORAGE_FAILED错误： flash_init(fa->fa_dev) CHIP_ERROR_PERSISTED_STORAGE_FAILED 链接器脚本附件 我将附上修改后的MIMXRT798Sxxxx_cm33_core0_flash.ld链接器脚本供您参考。该脚本基于 RT700 SDK 提供的链接器脚本，并针对 Matter 应用程序的内存布局和 NVS 存储配置进行了修改。 需要支持 请问您能否帮忙澄清一下： 如何在RT700-EVK上配置Matter持久存储的闪存设备和驱动程序？ 是否还需要任何针对 RT700 的额外闪存驱动程序或 NVS 集成步骤？ 修改后的链接器脚本或 NVS 内存布局是否会导致flash_init()失败？ 我希望您能指导我如何解决这个问题。 谢谢！ 评估板 Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure 嗨@Aparna1 ， 谢谢你的提问！ 我已审核提供的链接脚本。它目前引用了以下与 FlexSPI 相关的对象： *(EXCLUDE_FILE( ... *fsl_adapter_flexspi_nor_flash.c.o* *mflash_drv.c.o* *fsl_flexspi.c.o* ) .text*) 但是，MIMXRT700 使用的是 XSPI 控制器。请确认该应用程序已链接到正确的 RT700 XSPI 闪存后端，并且 fa->fa_dev 指的是该设备，而不是其他 i.MX RT 平台使用的 FlexSPI 后端。 另请检查映射文件中的 flash_init() 、闪存擦除/编程功能以及相关的 XSPI_* 功能。这些功能及其所需的配置数据应该位于 RAM 中，而不是 XIP 闪存区域中。 我们建议按以下顺序检查端口： 验证 SDK 中的官方 RT700 XSPI 或非 闪存示例； 确认 fa->fa_dev 使用正确的XSPI后端； 验证闪存操作代码是否确实从 RAM 中执行； 然后检查 NVS 地址、扇区对齐方式，以及驱动程序是否期望绝对地址或设备相对偏移量。 此致， 加文

Clock - power relationship : MIMXRT685 - EVK Hello,  For an application I'm shooting the core clock frequency to max possible, i.e., 297MHz from the default 250 MHz. I wanted to know what implications it causes from the power perspective. Although nothing breaks right now, from the static characteristics from the datasheet, I think I need to make some changes, to avoid future hardfaults. I would really appreciate some guidance here.  Thanks in advance! Shri Re: Clock - power relationship : MIMXRT685 - EVK Hi @shri00 , Thank you so much for your interest in our products and for using our community. For 297 MHz operation on the MIMXRT685-EVK, please check the VDDCORE voltage as well as the clock configuration. The fact that the board currently runs without faults does not necessarily mean that VDDCORE meets the operating requirements for your target frequency and temperature range.   When increasing the clock frequency, first set VDDCORE to the level required for the target frequency, and then switch to the higher frequency.   For the relationship between VDDCORE and clock frequency, please refer to Tables 20 and 21 of the RT600 data sheet. Dual-core microcontroller with 32-bit Cortex®-M33 and Xtensa HiFi4 Audio DSP CPUs Have a nice day. Best Regards May Liu

Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar Hello, My name is Eunjin Kwon, and I am a researcher in the Eco-Friendly Building Research Team at GS Engineering & Construction in South Korea. We are currently exploring the application of mmWave radar technology for non-contact fall detection and activity monitoring in residential environments. One of our key technical requirements is to distinguish humans from pets (such as dogs and cats) to prevent false alarms caused by pet movements while ensuring reliable fall detection for human occupants. We are particularly interested in NXP's 77–81 GHz FMCW radar solutions and would appreciate your technical guidance on the following questions: 1. Does NXP have any existing technologies, research results, or application examples related to human versus pet (Human / Non-human) classification using mmWave radar? 2. Is it technically feasible to distinguish humans from pets using radar data, such as point clouds and Doppler information, through AI-based classification algorithms? 3. Are there any relevant reference designs, technical documents, or development resources available for this application? We would also appreciate the opportunity to discuss this topic with an NXP radar technical specialist or Field Application Engineer (FAE) in South Korea. Thank you for your time and assistance. I look forward to your response. Best regards, Eunjin Re: Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar Hello, Let me look closer if we have done something similar as our RADARs are automotive. Best regards, Peter

BCC MC33771C 测量时序 各位同事好，   我们正在使用 MC33771C 电池单元控制器 (BCC)，并观察到使用不同的读取间隔时电压/温度测量读取时间存在差异。   测试观察结果：   配置：与 BCC 配置相同，有 4 个从节点。 读取间隔：10 毫秒：从所有 4 个从站读取温度数据大约需要 40 毫秒。 读取间隔：100 毫秒：从所有 4 个从站读取相同的温度数据大约需要 7.7 毫秒。 我们观察到，即使配置保持不变，当读取间隔设置为 10 毫秒时，总测量读取时间也会明显增加。   请问您能否帮我们理解以下问题？   为什么 10 毫秒和 100 毫秒读取间隔的测量读取时间会有显著差异？ 读取间隔与ADC转换、测量更新或BCC通信时序之间是否存在任何依赖关系？ 使用 4 个 BCC 从设备时，是否有推荐的配置或步骤来实现一致且优化的电压/温度读取时序？ 从多个 MC33771C 设备读取测量数据时，我们是否需要考虑任何特定的时间限制或同步要求？ 如需进一步分析，如需其他配置详情或测量日志，请与我们联系。 Re: BCC MC33771C measurement timing 你好，Nirmal， 感谢您确认ADC配置。这是一个重要的澄清：当 ADC_CFG[AVG] = 0 且分辨率为 16 位时，硬件 tEOC 仅为 ~520 µs。您在 10 毫秒间隔内观察到的 40 毫秒读取时间不可能是 ADC 转换本身造成的，几乎可以肯定是由固件测量序列造成的。 tEOC ≈ 520 µs，因此在两个时间间隔到期之前，数据就已经准备就绪。因此，观察到的读取时间差异源于固件触发信号 SOC 并读取结果相对于该时间间隔的方式和时间。导致这种特定症状的最常见原因是： 1. SYS_CFG1[CYCLIC_TIMER] 在 10 毫秒时激活 如果循环定时器设置为 10 毫秒，则设备每 10 毫秒自动触发信号一次循环转换。但是，循环转换不会更新 MEAS_xxxx 测量寄存器——它们只会更新 OV/UV/OT/UT 故障标志。如果 MCU 固件在发出在线点播 SOC 之前等待循环触发信号，则有效测量周期将与循环周期耦合，每次读取之前最多会增加 10 毫秒的延迟。在 100 毫秒的循环周期下，这种延迟消失了，因为 MCU 可以独立地在线点播发出 SOC。请验证 SYS_CFG1[CYCLIC_TIMER] 的值，如果已激活，请考虑禁用它或将 MCU 读取序列与其完全解耦。 2. 读取前插入固定时间间隔延迟（不等待 EOC） 如果固件发出 SOC 信号，然后等待完整的读取间隔（10 毫秒或 100 毫秒）后再进行读取，而不是轮询 EOC 标志，则其行为将是： 100 毫秒：SOC → 等待 100 毫秒 → 读取（通信时间 7.7 毫秒）→ 测量值 ≈ 7.7 毫秒 ✓ 10 毫秒：SOC → 等待 10 毫秒 → 读取（7.7 毫秒通信） → 但是如果循环重复且时间累积，则有效测量持续时间会增加。 3. SOC 是按从设备发放的，而不是广播发放的。 如果固件分别向每个从设备触发信号 SOC，并强制执行每次读取之间的间隔，则 4 个从设备的总和将是间隔的倍数。 4个奴隶的正确顺序是： - 同时向所有 4 个从设备发出单个广播 SOC。 - 轮询 EOC 标志（或在 16 位时等待至少 520 µs，AVG=0）— 不要使用等于读取间隔的固定延迟。 - 确认 EOC 后，依次读取所有 4 个从属设备。 BRs，托马斯 按您所需的时间间隔重复。 Re: BCC MC33771C measurement timing 你好@TomasVaverka 感谢您的详细解释。 在我们的配置中，我们使用以下设置： ADC_CFG[AVG] = 0 ADC分辨率 = 16位 BCC 从节点数量 = 4 我们对两个测试用例使用了相同的配置（读取间隔分别为 10 毫秒和 100 毫秒）。 但是，我们观察到以下时间差异： 10 毫秒读取间隔：从所有 4 个从站读取温度数据大约需要 40 毫秒。 100 毫秒读取间隔：从所有 4 个从站读取温度数据大约需要 7.7 毫秒。 由于两种情况下 ADC 平均值和分辨率设置相同，请问为什么转换和测量读出时间会有如此大的差异？ 是否存在与 SOC 触发信号间隔、ADC 转换状态或 EOC 标志处理相关的依赖关系，可以解释这种行为？ 您能否也建议一下，如何在 10 毫秒的测量间隔下实现一致的测量读数时间？ Re: BCC MC33771C measurement timing 你好，Nirmal， 时间差异很可能是由您的 ADC_CFG[AVG] 平均设置引起的。 启用平均值后，tEOC（从 SOC 到数据准备就绪的时间）与样本计数成正比。例如，在 16 位分辨率且 AVG=64 的情况下，tEOC ≈ 32.5 毫秒 — 远远超过您的 10 毫秒读取间隔。这就解释了观察到的现象： 每隔 100 毫秒：当 MCU 读取时转换已经完成 → 仅测量通信时间（~7.7 毫秒）。 每隔 10 毫秒：MCU 必须等待转换完成 → 测量时间 = 剩余的 tEOC 等待时间 + 通信时间 ≈ 40 毫秒。 以下几点与您的问题相关： 1. 循环模式 (SYS_CFG1[CYCLIC_TIMER]) 不会更新 MEAS_xxxx 寄存器 — 它只会更新故障标志 (OV/UV/OT/UT)。要获得实际的电压/温度读数，需要在线点播 SOC 信息。循环模式下也不支持平均值计算。 2. 务必等待 EOC 标志出现后再读取结果。除非能保证延迟时间超过 tEOC，否则不要使用等于读取间隔的固定延迟时间。 3. 对于 4 个从设备：同时向所有从设备广播一个 SOC（所有设备并行转换，在 tEOC 完成），然后按顺序读取。在 16 位，AVG=0 时，最小总时间约为 0.52 毫秒 (tEOC) + 4 × 0.7 毫秒 (TPL 通信) ≈ 3.3 毫秒。 4. 有关完整的时序优化框架，请参阅 AN12637：基于 MC33771C 和 MC33772C 的系统时序优化（可在 nxp.com 上获取，需要登录）。 BRs，托马斯

ホールセンサーベースのモータ制御リファレンスウェアおよびトレーニング・マテリアルの要請 NXPチームの皆様へ 私たちは、24V、3.47Aモーターを用いた空冷システムを開発するお客様と協力しています。 センサーレスFOCベースのモータ制御を用いたデモンストレーションを成功裏に完了しました。顧客は現在、FRDM-MCXA156 EVK(制御カード)とFRDM-MC-LVPMSM(電源カード)を用いてローター位置検出用のホールセンサーを統合したいと考えています。 このハードウェアの組み合わせでホールセンサーベースのモーター制御を実装するための適切なリファレンスファームウェアやアプリケーション例を教えていただけますか? GitHubで公開されているLPC55S36用のホールセンサー搭載BLDCモーターのサンプルコードを確認しました。 しかし、この例に対応するFreeMASTER設定ファイル(.pmpx)を見つけることができませんでした。 以下の点についてご協力いただけますか? FRDM-MCXA156とFRDM-MC-LVPMSMのホールセンサー統合に関するリファレンスファームウェア。 利用可能な場合は、対応するFreeMASTERプロジェクト/設定ファイル（.pmpx）。 既存のセンサーレスFOCプロジェクトにホールセンサーフィードバックを統合するための関連するアプリケーションノート、トレーニング・マテリアル、または実装ガイド(FRDM-MCXA156 EVKに基づくもの。 技術的なご指導やご提案をいただければ大変ありがたく存じます。 よろしくお願いします ダルシャン・J・L WPGインド ボード設計 開発ボード FRDMトレーニング ハンズオン・トレーニング MCXA モータ制御 Re: Request for Hall Sensor-Based Motor Control Reference Firmware and Training Material こんにちは、 @Darshan_J_L さん。 投稿ありがとうございます。 MCUXpresso SDKには複数のモーター制御の例プロジェクトが含まれています。FRDM-MCXA156の詳細については、次のページでご覧いただけます。 MCUXpresso モータ制御用SDK |NXP Semiconductors。   FRDM-MCXA156 + FRDM-MC-LVPMSM の組み合わせのpmsm_enc例はSDK v25.06にあります。センサーレスおよびセンサー付きFOCをサポートし、pmsm_float_enc.pmpx FreeMASTERプロジェクトを含んでいます。ご参照くださいUG10247.pdf 詳細については、こちらをご覧ください。   デモ用の対応するFreeMASTER設定ファイル(.pmpx)については、こちらLPC55S36:an-lpc55s36_mc_bldc_whall/LPC5536_mc_bldc_wHall.pmpx at main · nxp-appcodehub/an-lpc55s36_mc_bldc_whall ·GitHub   お役に立てば幸いです。他に何かご質問がありましたら、お気軽にお知らせください。   BR セレステ    

MPC5777C Nexus trace while eTPU A/B clock halted Hi, It was found that if eTPU A/B clock is halted via SIU_HLT1.ETPUA bit, then MDO and MSEO Nexus outputs from Nexus Port Controller (NPC) are stuck to 0V (dead). Even if other Nexus client (e.g. e200) is generating Nexus trace data. If SIU_HLT1.ETPUA is later written with '0' (clock not halted anymore), Nexus trace stream from e200 Nexus client reaches NPC and outside world. After doing some testing it seems that no other clock halt request within HLT1 register seems to produce same behavior on MSEO/MDO pins. So the core problem is that it seems that eTPU A/B clock halt affects Nexus trace operation in general. This happens regardless of clock divider or port width in NPC. Workaround I found by trial and error is that if you firstly disable each (A and B) eTPU engine via respective ECR.MDIS bit and then disable whole module clock via HLT1.ETPUA, MSEO/MDO pins still behave normally if trace is initiated from other Nexus clients (e.g. e200 core).   This workaround however is not optimal as it requires change to the user application. I am interested if something can be done by debugger to mitigate this behavior?  

需要MBD职业建议 5年前我开始从事汽车软件的基于模型的设计工作，现在我觉得这份工作非常单调，而且在工具方面也没有太多学习机会，你是如何应对这种情况的？ 我每月可能参与的工作量可能是：10% 用于 Simulink 建模，50% 用于测试这些模型和报告，其余时间用于手动编写合规性文档。

Number of supported endpoints on the iMX8 The iMX8 uses the DWC3 for USB, which is an xHCI controller. When I read out the register from iMX8 i can figure out, that it may support up to 64 devices. But when I attach a few devices I much earlier on run in xHCI resource error. It seems there is some kind of a limitation on the number of endpoints, and it also seems that it depends on the type of transfer type (Bulk, Control, ...). On the type of devices I use (includsing the hubs) it seem I run after 80 endpoints into the problem. Could you please provide some exact numbers/formula how many endpoints are supported.

Mbd Career Advice needed I started my career on Model Based Design of Automotive software 5 years ago and now I feel that its very monotonous and not much learning on the tools side, how have you tackled this situation? The quantum of work that I might be involved in a monthly basis might be 10% on simulink modelling , 50% on testing these models and reporting and the rest on manual compliance docs.

RTT189 SDK 版本（不含 FDCB） 我正在使用 i.MX RT1180 和 MCUXpresso for VS Code，SDK 版本为 26.03。导入 rledblinky 示例后，我尝试了独立组网 \(SA\)应用程序和存储库应用程序两种应用程序类型。然而，编译后的 .bin 文件该文件不包含 FDCB 数据，导致编程后示例无法正确启动。 相比之下，当我在 MCUXpresso IDE 中导入相同的示例时，生成的二进制文件默认包含 FDCB 内容。 请问在将 MCUXpresso for VS Code 中的示例导入时，有哪些需要特别注意的地方可能会导致这种差异？ Re: RTT189 SDK Build without FDCB 嗨@ChandlerY ， 非常感谢您对我们产品的关注和提问。 RT1180 RAW/POR 图像切换的详细说明如下： 文档指出，XIP_BOOT_HEADER_ENABLE=1 选择 POR 镜像，而 0 选择 RAW 镜像。 https://docs.mcuxpresso.nxp.com/mcuxsdk/latest/boards/RT/evkmimxrt1180/gettingStarted/topics/RAW_POR_image_switch.html 祝你今天过得愉快。 顺祝商祺！ 刘梅

iMX8でサポートされるエンドポイントの数 iMX8はUSB用のDWC3を使っており、これはxHCIコントローラです。iMX8のレジスタを読み上げると、最大64台のデバイスをサポートしている可能性があることがわかりました。しかし、いくつかのデバイスを接続すると、かなり早い段階でxHCIリソースエラーが発生します。エンドポイントの数には何らかの制限があるようで、転送タイプ（バルク、コントロールなど）によっても異なるようです。私が使用しているタイプのデバイス（ハブを含む）では、エンドポイントが80個を超えると問題が発生するようです。サポートされているエンドポイントの数について、正確な数字や計算式を教えていただけますか?

RTT189 SDK Build without FDCB I am using the i.MX RT1180 with MCUXpresso for VS Code,and SDK version 26.03. After importing the rledblinky example, I have tried both Standalone Application and Repository Application as the App type. However, the compiled .bin file does not contain FDCB data, which make the example from booting incorrectly after programing. In contrast, when I import the same example in the MCUXpresso IDE, the generated binary includes FDCB content by default. Could you please help if there are any special points to note when importing examples in MCUXpresso for VS Code that could cause this difference? Re: RTT189 SDK Build without FDCB Hi @ChandlerY , Thank you so much for your interest in our products and foryour question. The RT1180 RAW/POR image switch is described here: The documentation states that  XIP_BOOT_HEADER_ENABLE=1 selects a POR image, while 0 selects a RAW image.   https://docs.mcuxpresso.nxp.com/mcuxsdk/latest/boards/RT/evkmimxrt1180/gettingStarted/topics/RAW_POR_image_switch.html Have a nice day. Best Regards May Liu

关于使用77–81 GHz FMCW雷达进行人和宠物分类的技术咨询 你好， 我的名字是权恩珍，我是韩国GS工程建设公司环保建筑研究团队的研究员。 我们目前正在探索毫米波雷达技术在住宅环境中的非接触式跌倒检测和活动监测方面的应用。 我们的关键技术要求之一是区分人和宠物（如狗和猫），以防止宠物移动引起的误报，同时确保对居住者进行可靠的跌倒检测。 我们对恩智浦半导体的77–81 GHz FMCW雷达解决方案特别感兴趣，希望您能就以下问题提供技术指导： 1. NXP 是否有利用毫米波雷达进行人与宠物（人/非人）分类的现有技术、研究成果或应用实例？ 2. 通过基于人工智能的分类算法，利用雷达数据（如点云和多普勒信息）区分人类和宠物在技术上是否可行？ 3. 是否有与此应用相关的参考设计、技术文档或开发资源？ 我们也希望有机会与恩智浦半导体（NXP）韩国的雷达技术专家或现场应用工程师（FAE）讨论这个话题。 感谢您抽出时间提供帮助。期待您的回复。 顺祝商祺！ 恩真 Re: Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar 你好， 让我仔细看看我们是否做过类似的事情，因为我们的雷达是汽车雷达。 顺祝商祺！ Peter

77〜81GHz FMCWレーダーを用いた人間およびペットの分類に関する技術的調査 こんにちは、 私の名前はクォン・ウンジンで、韓国のGSエンジニアリング&建設の環境に優しいビルディング研究チームの研究者です。 現在、住宅環境における非接触落下検知および活動モニタリングにmmWaveレーダー技術の応用を模索しています。 当社の重要な技術要件の一つは、ペット（犬や猫など）の動きによる誤報を防ぎつつ、人間の転倒を確実に検知するために、人間とペットを区別することです。 特にNXPの77–81 GHz FMCWレーダーソリューションに関心があり、以下の質問について技術的なご指導をいただけるとありがたいです。 1. NXPには、mmWaveレーダーを用いた人間とペット(人間/非人間)の分類に関する既存のテクノロジ、研究成果、またはアプリケーション例はありますか? 2. 点群やドップラー情報などのレーダーデータを使って、AIベースの分類アルゴリズムを使って人間とペットを技術的に区別することは可能でしょうか? 3. このアプリケーションに関連するリファレンスデザイン、技術文書、または開発リソースはありますか? また、韓国のNXPレーダー技術専門家やフィールドアプリケーションエンジニア(FAE)とこのテーマについて議論する機会があればありがたいです。 お時間とご協力に感謝いたします。ご回答をお待ちしております。 よろしくお願いいたします。 ウンジン Re: Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar こんにちは、 もし私たちも同じようなことをしたことがあるなら、もっと詳しく見てみます。私たちのレーダーはオートモーティブです。 よろしくお願いいたします。 ピーター

BCC MC33771Cの測定タイミング こんにちは、チームの皆さん、   私たちはMC33771Cバッテリー・セルコントローラ(BCC)を使って作業しており、異なる読み取り間隔を使うと電圧/温度測定の読み取りタイミングに違いがあることが観察されました。   テスト結果：   構成：スレーブ4台を備えた、BCCと同じ構成。 読み取り間隔：10 ms：4 つのスレーブすべてから温度データを読み取るのに約 40 ms かかります。 読み取り間隔: 100 ms: 4 つのスレーブすべてから同じ温度データを読み取るのに約 7.7 ms かかります。 設定は変更されていないにもかかわらず、読み取り間隔を10msに設定すると、測定全体の読み取り時間が著しく長くなることが観察された。   以下の点についてご理解いただけますか?   10ミリ秒と100ミリ秒の読み取り間隔で、測定値の読み取り時間が大きく異なるのはなぜですか？ 読み取り間隔とADC変換、測定値更新、またはBCC通信タイミングの間には、何らかの依存関係がありますか？ 4台のBCCスレーブを使用する場合、電圧/温度の読み取りタイミングを安定かつ最適化するための推奨構成や手順はありますか？ 複数のMC33771Cデバイスから測定データを読み取る際に考慮すべき、特定のタイミング制約や同期要件はありますか？ さらなる分析のために、追加の設定情報や測定ログが必要な場合はお知らせください。 Re: BCC MC33771C measurement timing こんにちは、ニルマルさん。 ADCの設定をご確認いただきありがとうございます。これは重要な補足事項です。ADC_CFG[AVG] = 0、16ビット分解能の場合、ハードウェアtEOCはわずか約520µsです。10ms間隔で40msの読み出し時間が見られるのはADC変換自体によるものではなく、ほぼ間違いなくファームウェアの測定シーケンスによるものです。 tEOCが約520µsの場合、データはどちらの間隔が満了するよりもかなり前に準備完了となる。したがって、観測される読み出し時間の差は、ファームウェアがSOCをトリガーし、間隔に対して結果を読み取る方法とタイミングに起因する。この特定の症状の最も一般的な原因は以下のとおりです。 1. SYS_CFG1[CYCLIC_TIMER]は10msでアクティブになります 周期タイマーが10msに設定されている場合、デバイスは10msごとに自動的に周期変換をトリガーします。ただし、周期的な変換ではMEAS_xxxx測定レジスタは更新されず、OV/UV/OT/UT障害フラグのみが更新されます。MCUファームウェアがオンデマンドSOCを発行する前にサイクリックトリガーを待つと、実効測定サイクルはサイクル周期と連動し、各読み取りまでに最大10msのレイテンシが加算されます。100msの周期周期でこのレイテンシは消えます。なぜならMCUは独立してオンデマンドSOCを発行するためです。SYS_CFG1[CYCLIC_TIMER]の値を確認し、もし有効であれば無効化するか、MCUのリードシーケンスを完全に切り離すことを検討してください。 2. 読み取り前に固定間隔の遅延を挿入（EOCを待たない） ファームウェアがSOCを発行し、EOCフラグをポーリングするのではなく、読み取り間隔全体（10msまたは100ms）待ってから読み取る場合、動作は次のようになります。 100 ms: SOC → 100 ms待機 → 読み取り (7.7 ms 通信) → 測定値 ≈ 7.7 ms ✓ 10 ms: SOC → 10 ms 待機 → 読み取り (7.7 ms 通信) → しかし、サイクルが繰り返され、タイミングが複合すると、実効測定期間が長くなります。 3. SOCはブロードキャストではなく、スレーブごとに発行される ファームウェアが各スレーブに対して個別にSOCをトリガーし、各スレーブ間の読み取り間隔を強制する場合、4つのスレーブの合計は間隔の倍数になります。 4体の奴隷の正しい順序は次のとおりです。 - 4つのスレーブすべてに同時に単一のブロードキャストSOCを発行します。 - EOCフラグをポーリングする（または16ビットで最低520µs待機する、AVG=0）—読み取り間隔と同じ固定遅延は使用しない。 - EOCが確認された後、4つのスレーブすべてを順番に読み込む。 BRs、トーマス お好みの間隔で繰り返してください。 Re: BCC MC33771C measurement timing こんにちは、 @TomasVaverka さん。 詳しい説明をありがとうございました。 私たちの構成では、以下の設定を使用しています。 ADC_CFG[AVG] = 0 ADC分解能 = 16ビット BCCスレーブの数 = 4 両方のテストCASE(10msと100msの読み取り間隔)で同じ構成を使用しています。 しかしながら、以下のようなタイミングのずれが観察された。 10 ms 読み取り間隔: 4 つのスレーブすべてから温度データを読み取るのに約 40 ms かかります。 100 ms 読み取り間隔: 4 つのスレーブすべてから温度データを読み取るのに約 7.7 ms かかります。 ADCの平均化と解像度の設定は両者で同じですが、なぜ変換と測定表示のタイミングが大きく異なるのか、説明していただけますか? この動作を説明するために、SOCトリガー間隔、ADC変換状況、EOCフラグ処理に何か依存関係があるのでしょうか? また、10msの測定間隔で一貫した測定表示タイミングを実現する方法についても提案していただけますか? Re: BCC MC33771C measurement timing こんにちは、ニルマルさん。 タイミングのずれは、おそらくADC_CFG[AVG]の平均化設定が原因です。 平均化が有効になっている場合、tEOC（SOCからデータ準備完了までの時間）はサンプル数に比例して変化します。例えば、16ビット解像度でAVG=64の場合、tEOCは約32.5msとなり、10msの読み取り間隔をはるかに超えます。これは、観察された挙動を説明するものです。 100 ms間隔で:MCUが読み取り→通信時間のみ(~7.7 ms)を測定した時点で変換は完了しています。 10 ms間隔で:MCUは変換完了を待つ必要があります →測定時間=残りのtEOC待ち時間+通信≈40ms。 ご質問に関連する追加事項をいくつかご紹介します。 1. サイクルモード (SYS_CFG1[CYCLIC_TIMER]) は MEAS_xxxx レジスタを更新しません。障害フラグ (OV/UV/OT/UT) のみを更新します。実際の電圧/温度測定値を取得するには、オンデマンドSOCが必要です。平均化機能は、周期モードでは利用できません。 2. 結果を読む前に、必ずEOCフラグが表示されるまで待ってください。読み取り間隔と同じ固定遅延時間は、tEOCを超えることが保証されている場合を除き、使用しないでください。 3. 4台のスレーブの場合：1つのSOCをすべてのスレーブに同時にブロードキャストし（すべてが並列で変換し、tEOCで完了）、その後、順次読み取ります。16ビット、AVG=0の場合、最小合計時間は約0.52ms（tEOC）+ 4×0.7ms（TPL通信）≈3.3msです。 4. フルタイム最適化フレームワークについては、AN12637 MC33771CおよびMC33772Cベースのシステムタイミング最適化(nxp.com で利用可能、ログインが必要)を参照してください。 BRs、トーマス

eTPU A/Bクロック停止中のMPC5777C Nexusトレース こんにちは、 eTPU A/B クロックがSIU_HLT1 ETPUAビットで停止されると、Nexus Port コントローラ(NPC)からのMDOおよびMSEO Nexus出力が0V(死)に固定されることが判明しました。他の Nexus クライアント (例:e200) は Nexus トレースデータを生成しています。 SIU_HLT1.ETPUA が後で「0」で書き込まれると（クロックが停止しなくなる）、e200 Nexus クライアントからの Nexus トレース ストリームが NPC と外部の世界に到達します。 いくつかのテストを行った結果、HLT1レジスタ内の他のクロック停止要求では、MSEO/MDOピンで同様の動作は発生しないようです。 つまり、eTPUのA/Bクロック停止がNexusのトレース動作全般に影響を与えるように見えるのが核心問題です。 これは、NPCのクロック分周器やポート幅に関係なく発生します。 試行錯誤で見つけた回避策は、まず各 (A と B) eTPU エンジンをそれぞれの ECR.MDIS ビットで無効にし、次に HLT1.ETPUA でモジュール クロック全体を無効にすると、トレースが他の Nexus クライアント (例:e200コア）。   しかし、この回避策はユーザーのアプリケーションを変更する必要があるため最適ではありません。この挙動をデバッガで軽減できるかどうか気になっています。