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，托马斯 Re: BCC MC33771C measurement timing 你好@TomasVaverka ， 我使用广播消息进行 SoC 通信，但仍然遇到时序差异问题。

Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download Hi NXP Support Team, I would like to request download access for SW32K14-MCAL421-RTMC-1.0.1. Currently, the “Previous” tab in my NXP Software Licensing page appears greyed out and I cannot access this version. My account username is Chefanqf. This version is needed for compatibility with an existing project based on S32K14x MCAL 4.2. Could you please help enable the entitlement for this software under my account? Thank you very much for your support! Best regards, Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download Hi @812311483  The content of this inquiry is identical to the request: "Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download" Could you please clarify whether it is this account that requires the software, or if it was the previous account—"Chefanqf"—that needed it? Best Regards, Robin Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download Yes, it is my account that needs to download SW32K14-MCAL421-RTMC-1.0.1 for learning and use. Could you please grant me the download permission for this account? Thank you Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download I have emailed my colleagues at FlexNet and asked them to enable download access for this version of the software on your account.

overtemperature hi  i want to know if the S32K32 has the internal temperature sensor to monitor the self chip temperature? Assume the S32K32 has the internal temperature sensor how to set and process for the software? tanks. Re: overtemperature Hi @qiaoqin_wang  Yes. Please refer to Example S32K344 TempSenser S32DS36 RTD600/500/400_p24 Best Regards, Robin

RTD R21-11 AUTOSAR EB:どのモジュールがフルでスタブですか? こんにちは、NXPコミュニティの皆さん、 私はSW32K1_S32M24x_RTD_R21-11_3.0.0_D2503パッケージ(S32K1/S32M24x リアルタイム・ドライバ、AUTOSAR R21-11)をEBのtresos環境で使用しています。私たちのプロジェクトには 、サードパーティのサプライヤー(例:Vector、ETAS、EB)からの商用AUTOSAR BSWスタックは存在せず、NXP RTDパッケージとEB構成のみに依存しています。 RTDパッケージ内の一部のモジュールは完全なAUTOSAR実装を意図していないことを承知しています。例えば、RTDリリースノートには 「Dem、Det、EcuC、EcuM、Rteおよびインターフェースプラグインに含まれる機能はサンプルスタブ関数であり、 これらのスタブは対応するAUTOSAR基本ソフトウェアモジュールが利用できない場合にアプリケーションがコンパイル・実行できるようにするためのみ存在する」と記載されています。また、RTEはサポートスタブとしてのみ提供されており、完全に機能し設定可能なRTEソリューションにはサードパーティパッケージが必要であることも理解しています。 しかし、EB tresos の設定可能なモジュールのリスト (スクリーンショットを添付) を見ると、残りのモジュールの状態を明確にしたいと思います。具体的には、以下のモジュールについて知りたいです。 これは完全な本番環境の実装(例:完全なMCALドライバや完全なAUTOSARサービスモジュール)ですか? それとも本番環境向けのサンプルスタブやリファレンス実装で、ユーザーコードやサードパーティ製BSWに置き換えるべきでしょうか? 問題となっているモジュール（EB構成ビューより）： サービス/ECUマネジメント層: Dem、 Det、 EcuM、 EcuC、 BswM (存在する場合)、 ComM (存在する場合) メモリスタック: Mem 、 Mem_43_EEP 、 Mem_43_EXFLS 、 Mem_43_INFLS 、 Fee 、 NvM (存在する場合) MCALドライバ: ADC、 Can_43_FLEXCAN、 CanIf (インターフェース)、 Spi、 I2c、 I2s、 Uart、 Lin_43_LPUART_FLEXIO、 Pwm、 GPT、 ICU、 Wdg、 Mcl、 Crc、 Dio、 Port、 MCU、 プラットフォーム その他: Eth_43_ENET 、 EthIf 、 EthSwt 、 EthTrcv 、 CanTrcv_43_AE 、 LinTrcv_43_AE 、 Ea / Eep (存在する場合)、 Rte (既にスタブとして認識されている) MCALドライバ(例: Port、 Adc、 Spi、 CAN)は通常完全な実装であることは理解しています。私の主な不確実性は サービス層およびインターフェースモジュール 、特に Dem、 Det、 EcuM、 EcuC、 Mem、 Fee、 CANIf、 EthIf、 そして*Trcv/EthSWTモジュールについてです 。これらもスタブなのでしょうか、それともNXPが提供する機能実装ですか? 🙏 視覚的な説明に関する特別な要望： 可能であれば、このThreadに返信しているNXPのエンジニアが添付された2枚のスクリーンショットに直接注釈を付けて、各モジュールの状態を示せていただけると非常にありがたいです。 分かりやすくするために、画像にシンプルな色分け凡例を使用することをお勧めします。 🟢緑色（または太字の枠）：完全実装（本番環境対応）。 🟠オレンジ色（または点線の枠）：サンプルスタブ／参照コード（本番環境では使用しないでください）。 ⚪ グレー(または線が引かれている状態): サードパーティ製BSWパッケージ(例:RTE、OS、NvM)が必要です。 注釈をモジュールリストに直接表示することで、手動でクロス・リファレンスする時間を節約でき、プロジェクトの開発範囲を正確に把握するのに役立ちます。お時間とサポートを本当にありがとうございます! 添付ファイル： EB tresosモジュールの設定リストを示すスクリーンショット2枚。 Re: RTD R21-11 AUTOSAR EB: Which modules are Full vs. Stubs? こんにちは、 @lukaszadrapa さん。 詳しい説明をありがとうございます。 多くのことが明確になりました。表3のドライバが「RFP品質」であり、サービス/インターフェースモジュールがスタブであることを知っているのがまさに必要な情報でした。 私自身も表3を確認したいです。しかし、NXPのウェブサイトで言及されたSW32K1_S32M24x_RTD_R21-11_3.0.0_D2503パッケージの正確な「リリースノート」文書を見つけるのに苦労しています。 正確なドキュメント番号(例:ドキュメントID/Rev番号)または、このリリースノートPDFへの直接ダウンロードリンクを教えていただけますか?もし都合が良いなら、PDFファイルを返信に直接添付していただけると助かります。 ご協力いただき本当に感謝しています。書類を探すのに手間取らせてしまい、申し訳ありませんでした。 よろしくお願いします、 チャオファン Re: RTD R21-11 AUTOSAR EB: Which modules are Full vs. Stubs? こんにちは@チャオファン 要求された情報はリリースノートの表3にすでにまとめられており、パッケージに含まれるソフトウェアコンポーネントが一覧で、各コンポーネントがドライバとして提供されるかスタブとして提供されているかを示しています。以下に例を示します。 Dem、Det、EcuC、EcuM、Rte、インターフェースプラグインに含まれる機能は統合をサポートするためのサンプルスタブ関数であり、対応するユーザー開発またはサードパーティ製のBSW実装に置き換えるべきです。 したがって、EB Tresos構成のどのモジュールが実際のRTDドライバで、どのモジュールがスタブとしてのみ提供されているかを識別する際に、表3を参考にすることをおすすめします。 表3に記載されているドライバはRFP品質を持ち、リリースノートに記載されている通り、完全にテストされ、量産車載での使用を想定しています。 よろしくお願いいたします。 ルーカス

RW612 的 32.768kHz 晶体 你好， 我目前正在进行一个PCB设计项目，其中包括来自u-blox的IRIS-W10模块，该模块内部有一个RW612芯片。这是我第一个使用恩智浦MCU的设计。 我不太确定应该如何设计RTC外部晶振的电路。根据其他MCU（例如STM32）的经验，我知道它们需要在晶振的两个引脚上都连接一个外部负载电容。但对于 NXP MCU 来说，似乎有些型号具有内部可配置的负载电容。在 RW612 寄存器列表中，我偶然发现了 RTC CTRL 寄存器，特别是字段 RTC_OSC_LOADCAP。在我看来，这表明该 MCU 实际上具有内部负载电容，但我找不到任何关于此领域的文档。 所以我的问题是：要在该寄存器中设置一个特定的电容值，位格式是什么？ 产品：WiFi RW6XX Re: 32.768kHz Crystal for RW612 以下是 32k 晶振的相关寄存器。RTC_OSC_LOADCAP 寄存器看起来很神秘，因为它可能不适用于此产品。 Re: 32.768kHz Crystal for RW612 感谢您的回复。 RTC晶体的结构似乎分为两个部分。你给我看的那个是PMU的。让我头疼的是RTC部分。 从下面的屏幕截图中可以看到，没有外部电容，但我也没有看到任何内部电容。 在这张截图中，你可以看到我在问题中提到的那个具体的寄存器。 你说的可能是对的，这个 MCU 根本没有内部电容，但如果是这样，RTC_OSC_LOADCAP 字段在寄存器文档中就不应该可见。 另一方面，FRDM-RW612 的这款晶体电路出厂时没有负载电容。 Re: 32.768kHz Crystal for RW612 嗨@Niwo ，希望你一切都好。 请问您是否已经选定了32kHz的晶体？这一点很重要，因为每个晶体都需要其数据手册中定义的特定负载电容。 此外，强烈建议与晶体制造商合作，确定晶体电路周围的合适特性。 Re: 32.768kHz Crystal for RW612 你好@RomanVR ， 感谢您的反馈， 我还没订购任何零件，但我打算用这个： https://eu.mouser.com/de/ProductDetail/ECS/ECS-.327-6-16-TR3?qs=A6eO %2BMLsxmSq6P7XbVvfvw% 3D%3D 顺祝商祺！ Re: 32.768kHz Crystal for RW612 @Niwo你好，很抱歉回复晚了。 根据共享的晶体数据手册，所需的负载电容为 12pF，因此应以此作为配置任何外部电路的指导，并与晶体制造商进一步分析以获得最佳性能建议。 关于上述寄存器，它不应用于配置外部晶体负载电容，这一意见已提交给相关团队采取进一步行动。对于 XTAL32K 功能和晶体相关要求，UM11865 的第 10 章是正确的参考资料。 希望这能帮到你！ Re: 32.768kHz Crystal for RW612 你好@RomanVR ， 我想对文档提出一些修改建议，我认为这将使其他人更容易理解 32.768kHz 晶体的设计： 从 RM00278 和 MCUXpressoSDK 驱动程序中移除 RTC CTRL 寄存器中的 RTC_OSC_LOADCAP 字段 在 UM11865 的图 71 中添加外部负载电容，或者更好的是，在第 10 章中添加一个原理图，显示晶体和负载电容连接到 GPIO[22] 和 GPIO[23]。 在 UM11865 的第 10 章第 2 节中，我不明白“外部电容：18 pF”应该告诉读者什么。请详细说明一下。 希望我的反馈对您有所帮助。 顺祝商祺！

PN5190 Hi, I've implemented a card reader module using the PN5190. After upgrading and debugging our software, it stopped reading cards after a while, although it can recognize USB cards. Also, I've found that this chip is easily damaged by manually blowing it with a heat gun and is difficult to install successfully. Could you please check if there are any design flaws and what precautions should be taken when using it? Thank you. RF

S32DS 2018 license 过期 hi： S32 Design Studio for ARM v2018 R1 license 过期，麻烦帮忙处理一下，谢谢！ Re: S32DS 2018 license 过期 Hi,  your S32DS license has been extended.  回复： S32DS 2018 license 过期 hi： S32 Design Studio for ARM v2018 R1 license 过期，麻烦帮忙处理一下，谢谢！ @jiri_kral 

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 地址、扇区对齐方式，以及驱动程序是否期望绝对地址或设备相对偏移量。 此致， 加文 Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure 嗨@Gavin_Jia 我已根据建议修改了链接器文件（ MIMXRT798Sxxxx_cm33_core0_flash.ld ），并更新了与 XSPI 相关的配置。但是，问题仍然存在， flash_init()函数仍然失败。 我已将修改后的MIMXRT798Sxxxx_cm33_core0_flash.ld文件分享给您审核。请您检查一下链接器配置，并指导我还需要做哪些更改才能解决 XSPI 闪存初始化问题？ 谢谢！

PCF85263AT/AJ——屏幕上显示的分钟数为任意值。 在代码迁移任务中，我们遇到了 BSF 标志被设置的问题。由于 BSF 标志被设置，分钟寄存器中的 EMON 位也被设置。 因此，屏幕上显示的分钟数是一个任意值。此外，年份值无法正确保存，即使在设置了 RTC 日期和时间之后，年份值仍然持续显示 2000。 我尝试测试了下面提到的条件，但问题仍然存在。 我将标志寄存器（0x43）设置为 0x00 并立即读取它；它显示 0x00。然而，3秒后我再次读取寄存器时，其值又被设置为0x08（或0x00）。 Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 你好 Ris_eek 再会！ BSF 标志并非只是无法清除。相反，RTC 检测到新的电池切换事件，并再次设置 BSF。根据数据手册，当电池切换逻辑检测到电源转换事件时，BSF 将被设置。 它在大约 3 秒后重新确立的事实意味着 VDD 电源反复降至电池切换阈值以下，导致反复出现 VDD>VBAT>VDD 转换。每次转换都会重置 BSF。 RafaR_0-1788887610951.pngRafaR_0-1788887610951.pngRafaR_0-1788887610951.pngRafaR_0-1788887610951.png 这种持续的电压波动导致 RTC 不断 RESET，这就是为什么它只显示 2000 年的原因。我建议检查一下电源信号是否存在问题。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。 Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 亲爱的拉法尔； 谢谢你的来信。   在硬件方面，VDD（4.93 VDC）和VBAT（3.02 VDC）电压是恒定的。为防止电压波动，在电池电源两端并联了一个 100 nF 的电容。 电池开关寄存器（26h）设置为 0x00。因此，BSM（电池开关模式）配置为在 Vth 电平进行切换。Vth 电平为 1.5 V，因为 BSTH（电池开关阈值电压）位设置为 0。 如图 25 所示（如前一封邮件中所述）： 当 VDD < Vth 时，BSF 设置为 1。 当 VDD > VBAT 时，BSF 应被清除。 然而，在通电状态下，测得的电压为 VDD = 4.93 VDC，大于 VBAT = 3.02 V。即使如此，边防部队也未能通过清剿。 请问为什么即使 VDD 大于 VBAT，BSF 仍然保持设置状态？ Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 你好 Ris_eek 再会！ 数据手册上写着： 声明标志 BSF（寄存器标志，地址 2Bh）可用于在引脚 INTA 和 INTB 上产生中断。中断可以生成为脉冲信号，也可以生成为持续有效的信号，该信号遵循位 BSF 的条件。BSF 保持设置状态，直至接到命令解除。 我发送的参考图像还显示以下内容：“通过接口清除。” 这不会自动完成，你需要手动清除。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。 Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 好的，拉法尔 谢谢。 但是，BSF 标志在软件中被清除，但过一段时间后，它会再次被设置，正如我在之前的帖子中描述的那样。 Re: PCF85263AT/AJ -- Minutes value displayed on the screen is showing an arbitrary value 谢谢， 现在我的 PCF85263AT/AJ 代码迁移已经完成。我们现在想使用 RTC 中的偏移寄存器来提高时钟精度，并且我们正在将其设置为 OFFM=1（快速模式）。在测试为偏移校正而构建的固件时，我们观察到 DSO 上 INTA(CLK) 引脚信号的频率在 32.68kHz 到 32.80kHz 之间变化。请查看附图。我们的微控制器也读取到了相同的数据。 根据数据手册7.8.3节图20，计算32.68kHz的偏移值： A) 考虑：CLKOUT fmeas = 32680 Hz，因此 Tmeas = 30.599755 微秒 B) Dmeas = 30.517578 usec - 30.599755 usec = -0.082176微秒 C) Eppm = 10^6 x (-0.082176/30.599755)= -2685.51169 ppm D) 偏移值（当 OFFM=1 时，即快速模式）= -2685.51169/2.0345= -1319.98 ≈ -1320 根据表格编号。24 在数据手册的 7.8 节中，演示仅显示了 -127 到 +128 的十进制偏移值。但就我们目前的情况而言，当计算出的值为 -1320 时，我们无法理解应该向 OFFSET[7:0] 寄存器写入什么值。因此，我们不确定如何在应用程序代码中编写或编写什么内容来测试偏移校准。请指导我们下一步该怎么做。

s32k2018.R1没办法延期 麻烦帮我给这个激活码延下期，谢谢。 Activation Code D870-0066-E5E6-ACC7

S32G 多核 eMCEM 初始化时序 你好， 在 S32G399A 上，Cortex-M7_0 是我们的启动核心。它调用 eMcem_Init，然后使用 Mcu_SetMode 启动 M7_1/2/3。每个辅助核心在其启动代码中初始化自己的 DTCM，但 eMcem_Init 已经为这些核心启用了 ERM 不可纠正通知，因此在启动期间对其未初始化的 DTCM 进行推测性读取会在冷启动时锁存 NCF 5/8/51。 我尝试让 M7_0 等待 M7_1/2/3 报告它们的启动代码已运行，然后调用 eMcem_Init。其他核心在启动应用程序任务之前会等待 M7_0。按照这个命令，故障就不会再发生了。 在 S32G3 上，在所有核心都启动后初始化 FCCU/eMCEM 是否是推荐的顺序？ 谢谢你， 卡特

PN5190 Hi  我用pn5190做了读卡模块  升级我们调试后的软件用了第一段时间后不能读卡了  usb可以识别  而且发现这个芯片手工用热风枪吹的话 很容易坏掉 也比较难贴成功   请看下设计是否有问题 使用有什么注意事项  thank you RF

S32 デザインスタジオのライセンスが切れました こんにちは、 私のS32デザインスタジオライセンスはもうすぐ期限切れになります。 免許の更新は可能ですか? ライセンスコードは085B-C474-AA78-FC99です。 ご回答をお待ちしています。 Re: s32 design studio license expired こんにちは、 お客様のS32DSライセンスが延長されました。 Re: s32 design studio license expired こんにちは、 今あなたのアカウントを確認したところ、ライセンスは2030年まで有効です。ライセンスが本当に期限切れでないまで待つか、既存のライセンスを返却して古いコードで再度有効化することもできます。 Re: s32 design studio license expired こんにちは、 ssong_0-1789444671642.png まだ延長されていないようです。もう一度確認してもらえますか?ありがとう。 Re: s32 design studio license expired こんにちは、NXPサポートの皆さん。このメッセージがあなたの元に無事届くことを願っています。私のS32DSライセンスが期限切れになり、現在の開発作業が妨げられています。延長を手伝ってもらえますか? 私の認証ID： 406C-B408-57DB-0C62 製品:ARM v2.2用のS32 Design Studio。 ご返信よろしくお願いします。

MatterスタックのMIMXRT700-EVK(MIMXRT798S)への移植 — 永続的なストレージ初期化の失敗 こんにちは、 現在、MCUXpresso SDKとVS Codeを使ってNXP MatterスタックをMIMXRT700-EVK(MIMXRT798S)に移植する作業を進めています 。このボードはIW612チップセットをベースにした外付けのMurata Type 2EL無線モジュールを使用しています。 開発環境のセットアップと変更 VS Codeを通じてマター MCUXpresso SDKワークスペースをダウンロードし、セットアップしました。ワークスペースはmatter_mcuxpresso/mcuxsdkにあります。 以下の点において、RT700専用の変更を加えました。 マター:RT700プラットフォーム統合のためにミドルウェア/マター上でファイルを修正しました。 ワイヤレスフレームワーク: 外部村田タイプ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のマター永続保存ストレージ用にフラッシュデバイスとドライバーはどのように設定すべきでしょうか? 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フラッシュバックエンドとリンクされており、他のRTプラットフォームで使われるFlexSPIバックエンドではなく、このデバイスを指している i.MX fa->fa_dev 確認してください。 また、マップファイルで flash_init() 、フラッシュ消去/プログラム機能、および関連する XSPI_* 機能を確認してください。これらの機能およびそれらに必要な設定データは、XIPフラッシュ領域ではなく、RAMに配置する必要があります。 ポートの確認は以下の順序で行うことをお勧めします。 SDKの公式RT700 XSPI NORフラッシュ例を確認してください。 fa->fa_dev 正しいXSPIバックエンドを使用していることを確認してください。 フラッシュ操作コードが実際にRAMから実行されることを確認する。 次にNVSアドレス、セクターアライメント、ドライバが絶対アドレスかデバイス相対オフセットを期待しているかを確認します。 よろしくお願いします、 ギャビン Re: Matter Stack Porting to MIMXRT700-EVK (MIMXRT798S) — Persistent Storage Initialization Failure こんにちは、 @Gavin_Jia ご提案いただいた変更に基づいてリンカーファイル（ MIMXRT798Sxxxx_cm33_core0_flash.ld ）を修正し、XSPI関連の設定を更新しました。しかし、問題は依然として解決せず、 flash_init()関数が引き続き失敗します。 修正済みのMIMXRT798Sxxxx_cm33_core0_flash.ldファイルを共有してご覧いただきます。リンク設定を確認し、XSPIフラッシュの初期化問題を解決するために追加で何の変更が必要か教えていただけませんか? よろしくお願いします。

eMCEM initialization timing for S32G multicore Hi, On S32G399A, Cortex-M7_0 is our boot core. It calls eMcem_Init and then starts M7_1/2/3 with Mcu_SetMode. Each secondary core initializes its own DTCM in its startup code, but eMcem_Init has already enabled the ERM non-correctable notifications for those cores, so speculative reads of their uninitialized DTCM during startup latched NCF 5/8/51 on cold boots. I tried having M7_0 wait until M7_1/2/3 report that their startup code has run, then call eMcem_Init. The other cores wait for M7_0 before starting their application tasks. With this order the faults no longer occur. Is initializing FCCU/eMCEM after all cores have started the recommended order on S32G3? Thank you, Carter

过温 hi 我想知道S32K32是否有内置温度传感器来监测芯片自身温度？ 假设S32K32带有内部温度传感器，软件该如何设置和处理？ 坦克。 Re: overtemperature 嗨@qiaoqin_wang 是的。 请参考示例 S32K344 温度传感器 S32DS36 RTD600/500/400_p24 此致敬礼， Robin

The s32k2018.R1 cannot be postponed. Could you please extend this activation code for the next period? Thank you. Activation Code D870-0066-E5E6-ACC7

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 Re: Technical Inquiry Regarding Human and Pet Classification Using 77–81 GHz FMCW Radar Hello, 1. Does NXP have any existing technologies, research results, or application examples related to human versus pet (Human / Non-human) classification using mmWave radar? NXP does not currently offer a ready-to-use 77–81 GHz reference solution specifically for residential fall detection and human-versus-pet classification. NXP’s 77–81 GHz radar portfolio is primarily intended for automotive radar applications. 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? Human/pet classification using radar is technically feasible in principle. Machine-learning models can use features such as range, velocity, Doppler or micro-Doppler characteristics, spatial distribution and movement over time. Nevertheless, this would require customer-specific data collection, model training and validation under representative residential conditions. Robust performance cannot be guaranteed based on point-cloud data alone; lower-level range-Doppler or range-angle data may be beneficial. 3. Are there any relevant reference designs, technical documents, or development resources available for this application? NXP can provide radar evaluation hardware and signal-processing resources based on the SAF85xx platform to support feasibility evaluation and custom development. These resources do not include a finished fall-detection or pet-classification algorithm. We would also appreciate the opportunity to discuss this topic with an NXP radar technical specialist or Field Application Engineer (FAE) in South Korea. Please get in touch with NXP representative Sales/FAE assigned to your company or with your distributor so the separate support channel can be established. Best regards, Peter

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、トーマス Re: BCC MC33771C measurement timing こんにちは、 @TomasVaverka さん、 SOCにブロードキャストメッセージを使用していますが、それでもタイミングのずれが発生しています。

请求启用 SW32K14-MCAL421-RTMC-1.0.1 下载权限 您好，NXP支持团队， 我想申请下载SW32K14-MCAL421-RTMC-1.0.1 。 目前，我的 NXP 软件许可页面中的“上一版本”选项卡显示为灰色，我无法访问此版本。 我的账号用户名是Chefanqf 。 为了与基于S32K14x MCAL 4.2的现有项目兼容，需要此版本。 请问您能否帮我激活我账户下这款软件的使用权限？ 非常感谢您的支持！ 顺祝商祺！ Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download 你好@812311483 本次查询的内容与请求“请求启用SW32K14-MCAL421-RTMC-1.0.1下载权限”完全相同。 请问是这个账户需要安装该软件，还是之前的账户“Chefanqf”需要安装该软件？ 此致敬礼， Robin Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download 是的，我的账户需要下载 SW32K14-MCAL421-RTMC-1.0.1 用于学习和使用。请问您能否授予我此账户的下载权限？谢谢 Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download 我已经给 FlexNet 的同事发了邮件，请他们为您的帐户启用此版本软件的下载权限。