CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA Hello NXP Community  I’m using the CLRC66301B NFC reader IC and trying to activate Power-down mode by driving the PDOWN pin high (3.3 V), as specified in the datasheet. However, the current draw remains at 2 mA, while the datasheet indicates it should be between 8 nA and 40 nA in power-down. Setup Details: PDOWN pin: 3.3 V (constant high) VDDs: VDD(TX), VDD(AUX), VDD(MCU) all at 3.3 V Interface: I²C (idle during test) XTAL: 27.12 MHz crystal connected No communication or activity during current measurement Measured current: ~2 mA Questions: 1. Are any register configurations required before asserting PDOWN? 2. Could IRQ, XTAL, IFSEL, or other GPIOs prevent entry into true power-down mode? 3. Does PDOWN require additional timing or sequencing with VDD or reset? Any insights or suggestions would be appreciated. Thanks, Umasankar NFC Controller Solutions Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA Hi, When you mention that current consumption is reduced when SDA and SCL are physically disconnected, does it mean that you are removing all connections on this pin (removing both Host MCU and pull-up resistors), or is it that those lines are only disconnected from the Host MCU? Also, could you please describe the method, equipment and test point you are using for the measurement? Regards, Eduardo. Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA Dear NXP Team, I conducted power-down current testing using the official CLEV6630ARD board with the CLRC66303B chip. The current reaches ~40 nA only when SDA and SCL are physically disconnected before any I²C communication. If I²C is used even once, current remains above 2 mA, even after asserting PDOWN high. Could you please clarify what should be done with the I²C lines before entering PDOWN? Specifically: Should the MCU set SDA and SCL to high-impedance (input, no pull) before asserting PDOWN? Does any prior I²C communication prevent the chip from entering true hard power-down? Thank you. Follow-Up: CLRC66303 – High Current in Hard Power-Down Mode (CLEV6630ARD-Based Design) Dear NXP Team, I previously raised a query regarding hard power-down current with the CLRC66301HN, and your response recommended migrating to the CLRC663 Plus family (CLRC66303). I have since switched to CLRC66303B, using a custom board based on the CLEV6630ARD reference design, and I would like to follow up with updated test results. Your earlier reply focused on LPCD behavior and AN11783, but this issue concerns only hard power-down via the PDOWN pin, with no RF field or LPCD active. Power-Down Current Measurements (CLRC66303B): >When PDOWN is LOW (chip active, RF field on): ~100 mA >When PDOWN is HIGH and I²C pull-ups are present: ~1.2 mA >When PDOWN is HIGH and I²C lines are driven LOW: ~6.6 mA >When PDOWN is HIGH and I²C lines are physically disconnected before any use: ~40 nA  Only when SDA and SCL are physically disconnected before any I²C communication does the chip draw ~40 nA in PDOWN. If I²C is used even once, current remains high even after PDOWN is asserted HIGH. Hardware Setup Summary: Chip: CLRC66303B, I²C mode. MCU: TI CC2652R7, 100 kHz I²C Voltage: 3.3 V regulated Pull-ups: 4.7 kΩ to 3.3 V on SDA/SCL Unused pins: Pulled as per datasheet No RF or LPCD features enabled Schematic design: Based on CLEV6630ARD (attached) Questions for Clarification: 1. Are SDA/SCL internally biased during PDOWN mode? 2. Does any prior I²C activity prevent true power-down, even if PDOWN is later set HIGH? 3. Is it necessary to set MCU I²C pins to Hi-Z (input, no pull) before asserting PDOWN? 4. Is there an NXP-recommended method to reliably achieve <100 nA in hard PDOWN mode without physically disconnecting I²C lines? We aim to ensure battery longevity and must achieve the datasheet-stated low-power behavior. Any guidance or documentation specifically about PDOWN behavior and I²C leakage would be greatly appreciated. Schematic is attached for reference. Best regards, Umasankar C Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA Hello @Umasankarc Hope you are doing well.  I understand you are using a custom board based on CLRC66301HN (non-plus), is this correct? If so, please consider that we recommend using the CLRC663 plus family (CLRC66303) instead. HIGH level on pin PDOWN should enable a hard power-down. Power-down current (Ipd) stated in the Data Sheet corresponds to the sum of all supply currents in CLRC663 chip; however, additional power might be consumed by external components embedded in the board. Some recommendations for a low power design are described in AN11783 CLRC663 plus Low Power Card Detection, Section 3.4. Regards, Eduardo.

PCA9539 RESET 问题取决于 I²C 连接状态 你好 我正在使用 PCA9539 I/O 扩展器，遇到了意外的 RESET 问题，这似乎取决于 I2C 连接状态。 问题如下： 我通过 I²C 通信将 PCA9539 的所有输出端口配置为高电平。 输出引脚按预期保持高电平。 但是，当我移除 SDA/SCL 探头（用于监控 I2C 总线）时，PCA9539 似乎 RESET 了——输出引脚恢复到默认状态。 在此过程中，VCC 保持稳定，持续供电，RESET 引脚通过上拉电阻器保持高电平。 MCU 没有故意发出 RESET 信号或电源重启 其他说明： 在相同的测试条件下，PCA9538 没有出现这个问题。 存在 I2C 上拉电阻。 电源稳定，可与电容解耦。 RESET 引脚在事件期间未显示异常活动。 我怀疑，断开探测器连接时出现故障或启动/停止状态不完整可能会导致 PCA9539 的内部 I2C 状态机进入故障状态，从而导致类似RESET的行为。但是，我没有找到任何文件可以确认 PCA9539 是否可以在不明确 RESET 或重新通电的情况下清除其输出寄存器。 据我所知，就 I2C I/O 扩展器而言，只要有电源供应，无论是否连接了 I2C 探头，它都应保持其配置。您能确认这种理解是否正确吗？ 问题 在任何情况下，PCA9539 可以在没有 RESET 引脚断言或电源循环的情况下 RESET 其输出寄存器或 I2C 逻辑？ 拆除探头期间 SDA/SCL 出现的故障是否会导致设备进入故障状态并丢失其配置的输出？ 既然 PCA9539 和 PCA9538 的功能相似，为什么 PCA9539 会出现这种行为，而 PCA9538 却不会？ 不管 I²C 总线连接如何，只要有电源，I2C I/O 扩展器都应保持其配置，这是否正确？ 如果您对此行为有任何见解或官方文件，我们将不胜感激。 谢谢！

使用 LCD 针座时相机针座上的可用引脚 - FRDM-MCXN947 我想弄明白，在使用 smartdma 的 LCD-PAR-S035 显示器上使用 LCD 接头（J8）时，相机接头（J9）上的引脚是否可以用作 GPIO？ 在配置工具中，它们并不显示为冲突，但当设置为 GPIO 时，我似乎仍无法正确读取。 有人能确认（J9）引脚不能同时用作 GPIO 吗？ 谢谢   开发板 FRDM 培训 MCX N Re: Available pins on the camera header when using LCD header - FRDM-MCXN947 你好@cyberhelmer、 谢谢您的帖子。 我认为您可以参考 frdm-mcxn947 的用户手册。它列出了 FlexIO 和相机标头的所有潜在冲突。 从技术上讲，J9 上的引脚可以配置为 GPIO。 但是，如果 SmartDMA 正在积极使用 FlexIO for LCD，并且 J9 引脚与 FlexIO 或其他有源外设共享，则由于总线争用或引脚多路复用器冲突，GPIO 读取可能会失败。 我建议您检查项目配置中的引脚复用器，确保 J9 引脚没有同时分配给 FlexIO、CAN、I3C 或以太网。如果需要，还可检查和调整焊接跳线。您可以暂时禁用 SmartDMA，并测试从 J9 读取的 GPIO 数据，以确认它们能独立工作。 希望对你有所帮助。 BR 西莱斯特

S32K312 PLL_PHI0周波数 こんにちは、みんな MCU CLOCK 構成パラメータ PLL_PHI0 周波数を 200MHZ に設定し、プログラムが下の図に示す関数を実行し、PC ポインタが deadbeef と表示されます。周波数構成範囲 PLL_PHI0 は S32K3XX マニュアルに記載されているとおり 25-480MHZ です。 #S32K312 私の疑問に答えて解決策を提供してCAN幸いです！ Re: S32K312 PLL_PHI0 frequency こんにちは@wei_nan データシートに記載されているクロック構成に必ず従ってください。そうしないと、予期しない結果が発生する可能性があります。

NON XIP via JTAG RT1176 According to this application note: https://www.nxp.com/docs/en/application-note/AN14069.pdf , NON XIP images can only be loaded via MCU Boot Utility via UART and USB.  I was looking to confirm that there is no way to load an XIP Image to flash via MCU Link or Jlink within MCUXpresso IDE?  If MCU Link must be used, I'd like to confirm these are the correct UART pins bellow to route out. I do not see an option for Boot through USB on the datasheet: https://www.nxp.com/docs/en/data-sheet/IMXRT1170AEC.pdf (apologies if I missed it). I've seen a few things online mentioning boot via USB is just connecting USB to the same UART Pins? Thanks, Anteo Re: NON XIP via JTAG RT1176 Hi @AnteoJ , Thanks for your interest in NXP MIMXRT series! Non-XIP images such as those booted from SD card need to be flashed with MCUBootUtility or NXP's official MCUXpresso Secure Provisioning tool. If the image is XIP, it can be programmed to flash by debugger such as JLink/DAP. It's easy to do in MCUXpressoIDE or any other IDE. If you are using RT1170-EVK/EVKB, you will find that there is an MCU-Link on the board, which is an on-board debugger, which is convenient for customers to flash programs and debug directly through the on-board debugger without using an external debugger. Moreover, MCU-Link can be changed to JLink or CMSIS-DAP debugger by programming different firmware. For details, you can check EVK/EVKB hardware schematics. Best regards, Gavin

使用 HSE 导入 RSA 中间证书的问题 您好， 我们目前在使用 HSE API 导入和验证 RSA 中间证书时遇到一个问题。 在进行必要的修改以支持 RSA 证书后，我们尝试导入中间 RSA 证书，并使用相应的根公钥对其进行验证。然而，尽管尝试了证书结构中 tbsOffset、tbsLen 和 signOffset 值的各种组合，HSE 始终返回响应代码：hse_srv_rsp_verify_failed 我们已经验证了证书和使用的密钥数据，根公钥的配置似乎是正确的。在不同的偏移配置和证书中，问题依然存在。 能否请您帮助我们找出可能出错的地方，或指导我们如何正确理解 RSA 证书结构中的偏移量（尤其是 rsaModulusOffset、rsaExponentOffset、tbsOffset、tbsLen 和 signOffset）？此外，HSE 内部是否有任何具体要求或检查可能导致核查失败？ 我们采用的方法与 hse_certificate.c 中演示的 ECC 证书导入方法（通过 HSE_ImportECCCert）相同。文件，该文件在 HSE FW 版本 HSE_DEMOAPP_S32G3XX_0_2_64_0 中共享。为了供您参考，我们附上了此文件和我们的请求。 如有需要，我们很乐意提供更多详细信息，如证书内容、根公钥和服务描述符配置。 期待您的支持。 Re: Issue with RSA Intermediate Certificate Import using HSE 你好，@Anup97 谢谢您的帖子。 我已经提到它也被张贴在私人文件夹中，让我直接在那里回复你，因为共享文件更方便。 感谢您的理解。 BR 切宁

uboot 跳转到内核会影响 llce_lin 的输出 你好，恩智浦 我们使用引导加载程序启动 M 核心 + A 内核，M 内核配置了 llce_lin 输出； s32g u-boot 跳转到内核，llce_lin 输出损坏，查询具体代码后找到； u-boot 代码：bootm.c-> announce_and_cleanup ()->cleanup_before_linux (void)-> board_cleanup_before_linux ();-> scmi_reset_agent ()； 我们发现， 由于调用 scmi_reset_agent 函数导致，M 内核配置 lce_lin 停止发送；由于 scmi（系统控制和管理接口）系统控制和管理接口 (SCMI) 是 启动 中的较低级别函数，内核，控制时钟、电源、io、RESET等，其中涉及 s32g 的底层控制逻辑；如何修改或配置为 解决导致 llce_lin 停止的 A-core 初始化问题？ 致以最诚挚的问候 Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 注释掉相应的行只是一种测试，并不是建议的解决问题的方法，因为这可能会影响到多个部分，从而导致像你发现的那样的问题。 我认为还需要进一步分析和测试，为了方便讨论和资源共享，请让我帮助创建一个支持案例来继续提供支持，我会直接通过邮件回复您。 很抱歉给您带来不便。 BR 切宁 Re: uboot jump to kernel affects llce_lin output 嗨，chenyin 我现在有一些关于 S32G 时钟的问题，基本上和图片中的问题类似； 1. tf-a 初始化时钟后 tf-a 不会退出吗？ 2. u-启动 和内核如何初始化或使用时钟，需要与 tf-a 通信？ 3. 你能详细解释一下在 tf-a、u-启动 和内核中是如何使用 clk 的吗？ https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Bootloader-Customzition/tac-p/1771379/emcs_t/S2h8ZW1haWx8bWVudGlvbl9zdWJzY3JpcHRpb258TFBXQUozUkFGRzZFRjl8MTc3MTM3OXxBVF9NRU5USU9OU3xoSw BR. Re: uboot jump to kernel affects llce_lin output 嗨，chenyin 感谢您的回复， 我测试了评论过的 scmi_reset_agent 函数，并确认在 u-启动-> 内核跳转期间 llce_lin 输出正常。 但是，我发现内核启动后有异常，比如无法访问eth0 ping，因为我不确定是否还有其他问题，所以我没有按照这条线索进行调查； 你建议我做这样的调查吗？ BR. Re: uboot jump to kernel affects llce_lin output 从U-Boot到Linux内核的过渡确实会影响外围设备的输出，包括与LLCE-LIN（低延迟通信引擎——本地互连网络）相关的外围设备的输出，尤其是在恩智浦S32G等复杂的嵌入式系统中。 这主要是由于 U-Boot 和 猴子型 Linux 内核管理和初始化硬件资源 的方式不同 。 我们使用引导加载程序启动 M 核心 + A 内核，M 内核配置了 llce_lin 输出；s32g u-boot 跳转到内核，llce_lin 输出损坏，查询... 但是，它们的用途不同，管理方式也大不相同。-> U-boot 设备树用于配置和初始化启动过程中所需的硬件元器件，而 Linux 内核则使用设备树来描述内核启动后的硬件配置 Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 据我了解，U-boot 不会设置时钟，tfa 会在启动期间设置时钟。 对于当前的问题，您是否介意在测试时注释掉源代码中的 scmi_reset_agent，以检查您的测试是否仍然存在问题？ BR 切宁 Re: uboot jump to kernel affects llce_lin output 嗨，nxp 我继续在 u-boot 中追踪代码后发现了以下内容： 调用链：scmi_reset_agent (void)-> devm_scmi_process_msg (dev，& scmi_msg)-> scmi_smccc_process_msg (struct udevice *dev, struct scmi_msg *msg)-> arm_smccc_smc (chan-> func_id, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, &res);-> SMCCC smc 对程序集进行了最后的调用，我不知道相关的细节，那么这部分代码是做什么的？它对 M 核心的运行有何影响，如何才能跳过代码执行的这一部分。 BR. Re: uboot jump to kernel affects llce_lin output 你好，chenyin 请提出一个问题，我们现在按如下方式启动流程 bootloader (M7)-> tf-a (A53)-> u-boot (A53)-> 内核 (A53) 我们已经在引导加载程序中配置了 uart 时钟，tf-a 中没有配置 uart 时钟，也没有在 u-boot 中进行任何修改； u-启动 中会重新配置 uart 模块和时钟吗？ BR. Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 我建议首先尝试检查 TFA 中的 UART 时钟及其来源。 BR 切宁 Re: uboot jump to kernel affects llce_lin output 你好，切尼 我知道现在就是这样运行的。 你还有其他发现吗？ BR. Re: uboot jump to kernel affects llce_lin output 你好，@马松 感谢您的回复。 既然你的 tf-a、u-boot 中只保存 ddr、xbar_2x 时钟，你的意思是说 UART 和外围设备 PLL3 的时钟也被禁用并在启动加载程序中设置，而不是在 TF-A 中设置？（在 TFA/uBoot 中，TFA/uBoot 只能从启动加载程序继承时钟设置来驱动 UART？） BR 切宁 Re: uboot jump to kernel affects llce_lin output 你好，陈怡 u-启动 中的 clk 转储如下所示： => clk dump Rate Usecnt Name ------------------------------------------ 40000000 0 |-- fxosc@40050000 51000000 0 |-- firc 32000 0 |-- sirc 20000000 0 |--ftm0_ext 20000000 0 |-- ftm1_ext 125000000 0 |-- gmac0_ext_rx 125000000 0 |-- gmac0_ext_tx 50000000 0 |-- gmac0_rmii_ref 200000000 0 |-- gmac0_ext_ts 100000000 0 |-- serdes_100_ext 125000000 0 |-- serdes_125_ext 125000000 0 |-- serdes0_lane0_ext_cdr 125000000 0 |-- serdes0_lane0_ext_tx 125000000 0 |--serdes0_lane1_ext_cdr 125000000 0 |-- serdes0_lane1_ext_tx 125000000 0 |-- serdes1_lane0_ext_cdr 125000000 0 |-- serdes1_lane0_ext_tx 125000000 0 |-- serdes1_lane1_ext_cdr 125000000 0 |-- serdes1_lane1_ext_tx 1 0 |-- pfe_mac0_rmii 1 0 |-- pfe_mac1_rmii 1 0 |-- pfe_mac2_rmii 1000000000 0 |-- a53 400000000 1 |-- serdes_axi 51000000 1 |-- serdes_aux 133333333 1 |-- serdes_apb 100000000 1 |-- serdes_ref 80000000 0 |-- ftm0_sys 0 0 |-- ftm0_ext 80000000 0 |-- ftm1_sys 0 0 |-- ftm1_ext 133333333 0 |-- flexcan_reg 133333333 0 |-- flexcan_sys 40000000 0 |-- flexcan_can 200000000 0 |-- flexcan_ts 62500000 0 |-- linflex_xbar 125000000 1 |--linflex_lin 0 0 |-- gmac0_ts 125000000 0 |-- gmac0_rx_sgmii 125000000 0 |-- gmac0_tx_sgmii 125000000 1 |-- gmac0_rx_rgmii 125000000 1 |-- gmac0_tx_rgmii 0 0 |-- gmac0_rx_rmii 0 0 |-- gmac0_tx_rmii 0 0 |-- gmac0_rx_mii 0 0 |-- gmac0_tx_mii 400000000 1 |-- gmac0_axi 0 0 |-- spi_reg 0 0 |-- spi_module 133333333 0 |-- qspi_reg 133333333 0 |-- qspi_ahb 266666666 0 |-- qspi_flash2x 133333333 0 |--qspi_flash1x 400000000 0 |-- usdhc_ahb 133333333 0 |-- usdhc_module 400000000 1 |-- usdhc_core 32000 0 |-- usdhc_mod32k 133333333 0 |-- ddr_reg 800000000 0 |-- ddr_pll_ref 800000000 0 |-- ddr_axi 400000000 0 |-- sram_axi 133333333 0 |-- sram_reg 133333333 0 |-- i2c_reg 133333333 0 |-- i2c_module 66666666 0 |--siul2_reg 51000000 0 |-- siul2_filter 133333333 0 |-- crc_reg 133333333 0 |-- crc_module 100000000 0 |-- eim0_reg 100000000 0 |-- eim0_module 66666666 0 |-- eim123_reg 66666666 0 |-- eim123_module 66666666 0 |-- eim_reg 66666666 0 |-- eim_module 66666666 0 |-- fccu_module 51000000 0 |-- fccu_safe 66666666 0 |-- rtc_reg 32000 0 |-- rtc_sirc 51000000 0 |-- rtc_firc 133333333 0 |-- swt_module 51000000 0 |-- swt_counter 133333333 0 |-- stm_module 133333333 0 |-- stm_reg 133333333 0 |-- pit_module 133333333 0 |-- pit_reg 400000000 0 |-- edma_module 400000000 0 |-- edma_ahb 80000000 1 |-- sar_adc_bus 666666660 |-- cmu_module 66666666 0 |-- cmu_reg 133333333 0 |-- tmu_module 133333333 0 |-- tmu_reg 133333333 0 |-- flexray_reg 0 0 |-- flexray_pe 66666666 0 |--wkpu_module 66666666 0 |-- wkpu_reg 66666666 0 |-- src_module 66666666 0 |-- src_reg 66666666 0 |-- src_top_module 66666666 0 |-- src_top_reg 133333333 0 |-- ctu_module 80000000 0 |-- ctu_ctu 200000000 0 |-- dbg_sys4 400000000 0 |-- dbg_sys2 400000000 0 |-- m7 133333333 0 |-- dmamux_module 133333333 0 |-- dmamux_reg 500000000 0 | -- gic_module 133333333 0 | -- mscm_module 133333333 0 | -- mscm_reg 133333333 0 | -- sema42_module 133333333 0 |-- sema42_reg 66666666 0 |-- xrdc_module 66666666 0 |-- xrdc_reg 0 0 |-- clkout0 0 0 |-- clkout1 100000000 0 |-- usb_mem 32000 0 |-- usb_low 0 0 |--pfe0_rx_sgmii 0 0 ||-- pfe0_tx_sgmii 0 0 |-- pfe0_rx_rgmii 0 0 |-- pfe0_tx_rgmii 0 0 |-- pfe0_rx_rmii 0 0 |-- pfe0_tx_rmii 0 0 |-- pfe0_rx_mii 0 0 |--pfe0_tx_mii 0 0 ||-- pfe1_rx_sgmii 0 0 |-- pfe1_tx_sgmii 0 0 |-- pfe1_rx_rgmii 0 0 |-- pfe1_tx_rgmii 0 0 |-- pfe1_rx_rmii 0 0 |-- pfe1_tx_rmii 0 0 |--pfe1_rx_mii 0 0 |-- pfe1_tx_mii 0 0 |-- pfe2_rx_sgmii 0 0 |-- pfe2_tx_sgmii 0 0 |-- pfe2_rx_rgmii 0 0 |-- pfe2_tx_rgmii 0 0 |-- pfe2_rx_rmii 0 0 |-- pfe2_tx_rmii 0 0 |-- pfe2_rx_mii 0 0 |-- pfe2_tx_mii 300000000 0 |-- pfe_axi 300000000 0 |-- pfe_apb 600000000 0 |-- pfe_pe 0 0 |-- pfe_ts 40000000 0 |-- llce_can_pe 200000000 0 |-- llce_sys 80000000 0 `-- llce_per 1000000000 0 |-- a53 400000000 1 |-- serdes_axi 51000000 1 |-- serdes_aux 133333333 1 |-- serdes_apb 100000000 1 |-- serdes_ref 80000000 0 |-- ftm0_sys 0 0 |-- ftm0_ext 80000000 0 |-- ftm1_sys 0 0 |-- ftm1_ext 133333333 0 |--flexcan_reg 133333333 0 |-- flexcan_sys 40000000 0 |-- flexcan_can 200000000 0 |-- flexcan_ts 62500000 0 |-- linflex_xbar 125000000 1 |-- linflex_lin 0 0 |--gmac0_ts 125000000 0 |-- gmac0_rx_sgmii 125000000 0 |-- gmac0_tx_sgmii 125000000 1 |-- gmac0_rx_rgmii 125000000 1 |-- gmac0_tx_rgmii 0 0 |--gmac0_rx_rmii 0 0 |-- gmac0_tx_rmii 0 0 |-- gmac0_rx_mii 0 0 |-- gmac0_tx_mii 400000000 1 |-- gmac0_axi 0 0 |-- spi_reg 0 0 |-- spi_module 133333333 0 |--qspi_reg 133333333 0 |-- qspi_ahb 266666666 0 |-- qspi_flash2x 133333333 0 |-- qspi_flash1x 400000000 0 |-- usdhc_ahb 133333333 0 |-- usdhc_module 400000000 1 |-- usdhc_core 32000 0 |-- usdhc_mod32k 133333333 0 |-- ddr_reg 800000000 0 |-- ddr_pll_ref 800000000 0 |-- ddr_axi 400000000 0 |-- sram_axi 133333333 0 |-- sram_reg 133333333 0 |-- i2c_reg 133333333 0 |-- i2c_module 66666666 0 |-- siul2_reg 51000000 0 |-- siul2_filter 13333333333 0 |--crc_reg 133333333 0 |-- crc_module 100000000 0 |-- eim0_reg 100000000 0 |-- eim0_module 66666666 0 |-- eim123_reg 66666666 0 |-- eim123_module 66666666 0 |--eim_reg 66666666 0 |-- eim_module 66666666 0 |-- fccu_module 51000000 0 |-- fccu_safe 66666666 0 |-- rtc_reg 32000 0 |-- rtc_sirc 51000000 0 |--rtc_firc 133333333 0 |-- swt_module 51000000 0 |-- swt_counter 133333333 0 |-- stm_module 133333333 0 |-- stm_reg 13333333333 0 |-- pit_module 13333333333 0 |--pit_reg 400000000 0 |-- edma_module 400000000 0 |-- edma_ahb 80000000 1 |-- sar_adc_bus 66666666 0 |-- cmu_module 66666666 0 |-- cmu_reg 133333333 0 |-- tmu_module 133333333 0 |-- tmu_reg 133333333 0 |-- flexray_reg 0 0 |-- flexray_pe 66666666 0 |-- wkpu_module 66666666 0 |-- wkpu_reg 66666666 0 |--src_module 66666666 0 |-- src_reg 66666666 0 |-- src_top_module 66666666 0 |-- src_top_reg 133333333 0 |-- ctu_module 80000000 0 |-- ctu_ctu 200000000 0 |-- dbg_sys4 400000000 0 |-- dbg_sys2 400000000 0 |-- m7 133333333 0 |-- dmamux_module 133333333 0 |-- dmamux_reg 500000000 0 |-- gic_module 133333333 0 |-- mscm_module 133333333 0 |-- mscm_reg 133333333 0 |-- sema42_module 133333333 0 |-- sema42_reg 66666666 0 |--xrdc_module 66666666 0 |-- xrdc_reg 0 0 |-- clkout0 0 0 |-- clkout1 100000000 0 |-- usb_mem 32000 0 |-- usb_low 0 0 |-- pfe0_rx_sgmii 0 0 |-- pfe0_tx_sgmii 0 0 |-- pfe0_rx_rgmii 0 0 |-- pfe0_tx_rgmii 0 0 |-- pfe0_rx_rmii 0 0 |-- pfe0_tx_rmii 0 0 |-- pfe0_rx_mii 0 0 |-- pfe0_tx_mii 0 0 |-- pfe1_rx_sgmii 0 0 |-- pfe1_tx_sgmii 0 0 |--pfe1_rx_rgmii 0 0 ||-- pfe1_tx_rgmii 0 0 ||-- pfe1_rx_rmii 0 0 |-- pfe1_tx_rmii 0 0 |-- pfe1_rx_mii 0 0 |-- pfe1_tx_mii 0 0 |-- pfe2_rx_sgmii 0 0 ||-- pfe2_tx_sgmii 0 0 ||-- pfe2_rx_rgmii 0 0 |-- pfe2_tx_rgmii 0 0 |-- pfe2_rx_rmii 0 0 |-- pfe2_tx_rmii 0 0 |-- pfe2_rx_mii 0 0 |-- pfe2_tx_mii 300000000 0 |-- pfe_axi 300000000 0 |-- pfe_apb 600000000 0 |-- pfe_pe 0 0 |-- pfe_ts 40000000 0 |-- llce_can_pe 200000000 0 |-- llce_sys 80000000 0 |-- llce_per Re: uboot jump to kernel affects llce_lin output 嗨，chenyin 1. Lin 时钟在引导加载程序中配置； 2. 我们使用 bsp42，在 tf-a、u-boot 中只保存 ddr、xbar_2x 时钟，所有其他配置都处于关闭状态，具体取决于启动加载程序的配置； BR. Re: uboot jump to kernel affects llce_lin output 你好，@马松 谢谢您的帖子。 1.我想知道 LIN 时钟是在引导加载程序中配置的，还是在 M7 内核上运行的 LIN 应用程序中配置的？ 2。您的测试设置中使用的是哪个版本的电路板支持包？对时钟设置有任何修改吗？你介意分享你的 u-启动 中的时钟转储吗？ BR 切宁

配置自定义 SCP03 密钥的指南 嗨，@Kan_Li、 我正在使用 ESP32 主机和 SE050C1。环境详情： Plug& Trust: v3.0.6 (Mini) SE050 小程序版本：03 01 01 6F FF 01 0B 我可以使用默认密钥打开安全通道，在 SE 上生成 EC 密钥对，并成功创建 CSR。 现在我想配置一次自己的 SCP03 密钥集（ENC/MAC/DEK、AES-256），将其存储在新密钥版本下的 SE050 上，然后始终使用该版本打开 SCP03 会话。 我需要你做什么 v3.0.6 中 PUT KEY 的应用程序接口/示例（迷你版） 在我的 Mini drop 中，我看到了 INS_GP_PUT_KEY 的定义，但我没有找到类似 Se05x_API_PutKeys()、nxScp03_ChangeKeys() 或 ex_scp03_change_keys 示例这样的高级辅助函数。 能否确认 Mini v3.0.6 是否包含 SCP03 键盘旋转助手？ 如果回答为 "是"：我应该调用哪些源文件和函数，以及包含哪些头文件？ 如果否：请分享使用迷你 APDU 传输（例如，Se05x_API_Transceive/Se05x_API_SendAPDU）通过已打开的 SCP03 会话发送GlobalPlatform PUT KEY（CLA=0x80，INS=0xD8）的推荐方法（和最小代码示例），包括 ENC/MAC/DEK 和KCV计算的预期TLV 格式。 v3.0.6 中的 AES (SCP03) 验证上下文结构 我的启动环境是 gex_ss_boot_ctx.ex_se05x_auth。   ex_se05x_auth.param.scp03.ex_static. Enc/Mac/Dek ex_se05x_auth.param.scp03.keyVer 我通过 argv（--auth aes）选择 AES，并将密钥载入 ex_static.{Enc,Mac,Dek}。和版本号输入 keyVer。 请确认 v3.0.6 Mini 的正确字段名称，这样我就不用靠反复试验来确定了。 参考实现/路径 如果在完整的 Plug& Trust（非迷你版）中有演示 SCP03 密钥更新的示例，能否告诉我确切的路径和函数名称，以便我在迷你版中照搬该逻辑？我寻找的典型名字 examples/sss/ex_scp03_change_keys.* hostlib/hostLib/libCommon/scp/nxScp03.* hostlib/hostLib/libSE05X/src/*scp03* 或任何 INS_GP_PUT_KEY 的用法。 版本& 密钥长度 我计划使用 AES-256（32 字节密钥）和新的密钥版本（例如 0x11）。在小程序03 01 01 6F FF 01 0B 的密钥版本选择或最小密钥长度方面，有什么限制或最佳实践建议吗？ 工具替代品 如果推荐的方法是使用一次配置，然后将我的固件切换为始终使用新密钥打开，那么您能否分享工具名称/命令（以及从何处获取）。 我的直接障碍是 Mini 中缺少 PUT KE Y 的可调用助手；如果你能在此小程序版本中共享 SE050 所期望的确切 APDU 构建和发送顺序，我很乐意实现原始 APDU。 非常感谢你的指导！ 致以最崇高的敬意， Reddy A71CH SE050 Re: Guidance to provision custom SCP03 keys 你好@Rutwik0409、 到目前为止，我们只在MW的完整版和纳米版中提供了PlatformSCP密钥轮换演示，但是我认为您只需要在每个设备生命周期中运行一次此类应用程序，因此您可以尝试将纳米代码包移植到您的平台上作为快速解决方案。请参阅https://github.com/NXPPlugNTrust/nano-package/tree/master/examples/se05x_rotate_scp03_keys了解详情。 希望对你有所帮助、 祝您愉快， Kan ------------------------------------------------------------------------------- 注： - 如果本帖回答了您的问题，请点击"标记正确" 按钮。谢谢！ - 我们会在最后一次发帖后的 7 周内跟踪主题，之后的回复将被忽略 如果您以后有相关问题，请另开新主题，并参考已关闭的主题。 -------------------------------------------------------------------------------

The best way to build a PCB first time right with KW47 (Automotive) or MCX W72 (IoT/Industrial) Please, find the important link to build a PCB using a KW4x or MCX W7x and all concerning the radio performances, low power and radio certification (CE/FCC/IC). “As RF behavior are dependent of PCB layout & manufacturing; PCB prototypes (based on NXP recommendations) will have to be fine-tuned to insure the expected qualified in RF is reached on the final productized platform.” KW47 product NXP web page:  https://www.nxp.com/products/KW47 MCXW72 product NXP web page: https://www.nxp.com/products/MCX-W72 Board pages:  KW47-EVK Evaluation Kit with Bluetooth® Low Energy 6.0 KW47-LOC Localization Reference Design using KW47 MCXW72-LOC Localization Board for MCX W72 Bluetooth Channel Sounding MCU FRDM-MCXW72 Development Board for MCX W72 Wireless MCU   in addition of the product webpages please refer to KW47 Knowledge Hub Do not use pre-production or production board prior to April 2026 KW47-LOC or MCXW72-LOC platform for Channel Sounding certification - contact NXP for further note NXP Channel Sounding PAGE        (Bluetooth ®  SiG Channel Sounding Technical Overview ) More Channel Sounding enablement Available on request to NXP  Channel Sounding Fundamentals for the KW47 and MCX W72[AN14865] Fundamental Steps to Design a Channel Sounding Board - Creating a Simple PCB without Diversity[AN14832] Fundamental Steps to Design a Complex Channel Sounding Board[AN14869]        Printed Channel Sounding Antennas for the KW47 and MCX W72[AN14779] HARDWARE KW47-MCXW72-EVK HW guideline: KW47 Hardware Design Guide[UG10127] MCX W72 Hardware Design Guide[UG10273] HVQFN48 package specification: SOT619-17(D)   pending release of SOT619-17(DD)   KW47-MCXW72-EVK User Manual  KW47-LOC Board User Manual[UM12114] KW47-EVK Board User Manual[UM12094] MCXW72-LOC Board User Manual[UM12113] FRDM-MCXW72 User Manual[UM12222] Minimum BoM (attached file)  DCDC management guide (AN13831) :  Power Management Hardware (nxp.com) - KW45 applicable for KW47 waiting release of KW47/MCXW72  Design-In check list: see attached file at the bottom of this article RF matching: S parameters (attached file) Available on request    How to handle coincell application on PCB:  Coin Cell Hardware Recommendations for Kinetis Bluetooth LE Applications[AN14664] KW47-MCXW72 module can also be handled in standalone:  How to run KW47-M2 standalone RF output power level: Please note it is expected that each final PCB platform, is refine with the right RF matching and filtering, to fit your market and region mandatory certification. For instance the +10dBm at pin level can be exceeded in some configuration. It is final PCB owner responsibility to build a system (incl. all Rf path loss) with the expected target power level fitting with Bluetooth SiG Core spec and European radio certification target. Then the Tx power has to be adjusted at application level.   UFL SMA CABLE: On EVK, to connect M10 module for RF trials a µFL to SMA cable is recommended:  CSH-SGFB-200-UFFR TE Connectivity / Linx Technologies | Mouser France On KW47-LOC or MCXW72-LOC to connect SMA specific connector has to be populated: TE Connectivity Ltd CONSMA021.062-G. Warning to solder SMA connector:  please insure the PCB edge is well cut and right smooth; if not please mill a bit with a sand paper. (risk is to get SMA core line not well soldered on PCB line) Also for higher Harmonics the µFL is not convenient as connector is limited above 6GHz (an SMA has to be soldered to control RF losses ) RF matching component tolerance: Please note, on NXP EVK, FRDM and LOCalization platform the RF matching components (Inductors, Capacitors) are using the HIGH tolerance Muratasets. During your RF board tuning you may need to use low tolerance Murata set to insure all RF limits are passing. Eg: GJM1555C1H3R3CB01D is +/-0.25pF tolerance where GJM1555C1H3R3BB01 with +/-0.1pF tolerance may be preferred Eg2: LQG15HS1N3S02D  is +/-0.3nH tolerance where LQG15HS1N3B02D   with +/-0.1nH tolerance may be preferred KW47 from KW45 hardware porting :  KW47 is pin to pin compatible with KW45. However from HW point of view, some components values will have to be adjusted like RF matching components values. Other components around KW4x are not foreseen as to change based on current silicon validation.  Please also note some new muxing is in place to get new features of KW47 on pins. For instance on KW47 a second Flex CAN is available. See attached file RADIO RF report:  KW47-LOC RF System Evaluation Report for Bluetooth Low Energy Applications Radio co-existence:  Kinetis Wireless Family Products Bluetooth Low Energy Coexistence with Wi-Fi Application (nxp.com) pending release of KW47/MCXW72  Antenna:  Compact Planar Antennas for 2.4 GHz Communication Designs and Applications within NXP EVK Boards Printed Channel Sounding Antennas for the KW47 and MCX W72[AN14779] Return loss (S11) measurement: How to measure the return loss of your RF matching (S11) part of the RF report (AN13728) Loadpull: Loadpull Test Report for KW47[AN14696] SW tools for RF trials:     IoT Tool box (mobile application)     Connectivity test tool for connectivity products (part of the IoT toolbox)     DTM: How to use the HCI_bb on Kinetis family products a... - NXP Community https://community.nxp.com/t5/Wireless-Connectivity-Knowledge/BLE-HCI-Application-to-set-transmitter-... CRYSTAL   Recommended Crystal attached   Articles: KW47/MCX W72 32MHz & 32kHz Oscillation margins - NXP Community  32 kHz Crystal-less Mode on KW47[AN14884]   Please note for Channel Sounding feature with higher 10dBm transmit output, some specific care have to be taken adding to pass all harmonics on all Bluetooth Channels: see "32 MHz crystal harmonics design recommendations" chapter in "AN14826: KW47-LOC RF System Evaluation Report" where an extra inline inductor on Xtal path may be needed. LowPower      All power profiling tools are available in this NXP community web page:              KW35, KW38, KW45, KW47 & MCX W71, MCX W72 & MCX W23 Power Profile Tools (including Localization)      Bluetooth LE power profile estimator Tool               KW45_WK47_MCXW71_MCXW72_BLE_power_profile_calculator vx.x.xls              AN14554 Kinetis KW47 & MCX W72 Bluetooth LE Power profile analysis release.pdf      802.15.4 Matter & Zigbee power profile estimator Tool               MCX W7x 802.15.4 Matter ICD SIT LIT & ZED Power profile vx.x.xls               AN MCX W72 802.15.4 Matter and Zigbee Power profile analysis.pdf      CCC Channel Sounding BLE power profile estimator Tool               KW47 Digital Key CCC CS Power Estimator tool vx.x.xls               AN14628_AN14628_KW47_CCC_CS_Power_Profile_estimator tool_release.pdf CERTIFICATION RF full certification of KW47/MCXW72  available on board product pages KW47 and MCXW72 are Bluetooth 6.x channel Sounding certified!

NXP：蓝牙与信道探测天线 这些幻灯片是为马德里卡洛斯三世大学的欧洲天线学校准备的。内容： - 关于NXP和无线控制器 - 关于信道探测和NXP解决方案 - CS天线设计及功能测试 - CS天线阵列与CS定位

HMB-N1937 接続デバイス用のAndroidベースのBrillio OSの紹介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Brilloは、Androidをベースにした軽量OSで、オープンで拡張性があり、安全な小さなフットプリントを備えたコネクテッドデバイス向けです。Brilloは、Androidプラットフォームを接続されているすべてのデバイスに拡張するため、セットアップが簡単で、相互に連携したり、スマートフォンとシームレスに連携したりできます。Googleの通信API「Weave」が付属しており、Brilloデバイスが相互に通信して交換したり、データをクラウドに保存したりするのを簡単に行うことができます。このクラスでは、Brillo と、NXP が Google と協力して Brillo を i.MX 6UltraLite プロセッサやその他のプラットフォームに導入した方法を紹介します。 ビデオプレゼンテーションを見る <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Brilloは、Androidをベースにした軽量OSで、オープンで拡張性があり、安全な小さなフットプリントを備えたコネクテッドデバイス向けです。Brilloは、Androidプラットフォームを接続されているすべてのデバイスに拡張するため、セットアップが簡単で、相互に連携したり、スマートフォンとシームレスに連携したりできます。Googleの通信API「Weave」が付属しており、Brilloデバイスが相互に通信して交換したり、データをクラウドに保存したりするのを簡単に行うことができます。このクラスでは、Brillo と、NXP が Google と協力して Brillo を i.MX 6UltraLite プロセッサやその他のプラットフォームに導入した方法を紹介します。 ビデオプレゼンテーションを見る スマートホーム&ビル

ESC技术报告.pdf <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 飞思卡尔杯技术报告 韩国ESC团队 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 飞思卡尔杯技术报告 韩国ESC团队

一种检测不精确硬故障源的方法 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 本文档与Dragos Musoiu合作创建 尝试调试基于 ARM Cortex M4 的微控制器 MKW24D512 上的硬故障，我们没有找到太多关于处理不精确硬故障的文档。我们从 Erich Styger 的帖子“调试 ARM Cortex-M 上的硬故障”开始调查。基于此，我们使用Erich的代码来查找硬故障源，但无法找到导致硬故障的指令，因为围绕保存的PC执行的指令看起来是正确的。 之后，我们检查了硬故障状态寄存器，从 ARM Cortex M4 处理器的系统控制块中，我们发现 FORCED 位被设置了。ARM Cortex M4 文档提到，该位表示强制硬故障，由可配置优先级的故障升级产生，由于优先级或被禁用而无法处理。当该位设置为 1 时，HardFault 处理程序必须读取其他故障状态寄存器来查找故障原因。我们检查了其他故障寄存器，发现 ARM Cortex M4 处理器的系统控制块中的可配置故障状态寄存器（总线故障状态寄存器）中的 IMPRECISERR 位被设置。根据 ARM Cortex M4 文档，如果设置了此位，则发生数据总线错误，但堆栈帧中的返回地址与导致错误的指令无关。当处理器将此位设置为 1 时，它不会将故障地址写入 BFAR。所以这就解释了为什么我们没有按照 Erich 的指示找到导致硬故障的指令。此外，这是一个异步错误。因此，如果检测到当前进程的优先级高于 BusFault 优先级，则 BusFault 变为待处理状态，并且只有当处理器从所有更高优先级的进程返回时才会变为活动状态。 Cortex M4 处理器具有写入缓冲区功能，当对可缓冲内存区域进行写入时，处理器可以在传输完成之前继续执行下一条指令。这对于性能来说非常好，但可能会导致调试不精确的总线故障时出现一些复杂性。 通过更好地研究文档，我们发现 ARM Cortex M4 辅助控制寄存器中的 DISDEFWBUF 位在设置为 1 时会禁用默认内存映射访问期间的写入缓冲区使用。这会导致所有 BusFault 都成为精确的 BusFault，但会降低性能，因为任何存储到内存的操作都必须在处理器执行下一条指令之前完成。这样，处理器将不会继续执行下一条指令，直到写入操作完成，因此启用该位并使用 Erich 的代码，保存的 PC 指向导致硬故障的指令。 在其他情况下，如果总线故障是由中断处理程序中执行的指令触发的，且其优先级高于总线故障处理程序，则设置 DISDEFWBUF 在调试过程中很有用，因为即使出现精确错误，BFAR 寄存器值仍然有效。

DwF MCUおよびオートモーティブソリューション - Tianan - 2015-03-19 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 自動車およびコネクテッドカー 車載用マイクロコントローラの概要 : KinetisおよびS12 MagniVミックスド・シグナル・マイクロコントローラを含む BCCおよび高圧センサを搭載した車載用アナログおよびセンサの概要 インサイトとイノベーション Kinetisマイクロコントローラの概要 - Kinetisの性能上の利点とアプリケーション 設計、ソフトウェア、サービス フリースケールMQX™ RTOSの概要 ARM®プロセッサ キネティスCortex®-Mマイクロコントローラー センサ ソフトウェアとツール

汽车模拟和传感器概述，包括 BCC 和高压传感器 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Eric Wu 主讲 2015 年 3 月 19 日，天安 MCU 和汽车解决方案大会 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Eric Wu 主讲 2015 年 3 月 19 日，天安 MCU 和汽车解决方案大会 传感器

S32DS - HOWTO 列表 安装和激活 如何下载、安装、激活并使用 S32 Design Studio 3.6 操作指南：激活 S32 Design Studio 操作指南：S32 Design Studio 扩展与更新的离线安装 S32DS 扩展与更新：功能说明及使用指南 操作指南：将 Lauterbach TRACE32 调试器插件安装至 S32 Design Studio 操作指南：安装 GHS 编译器插件 入门指南 S32 Design Studio 3.6 中的最新动态 S32DS 快速入门指南 S32 Design Studio 3.5 使用技巧和窍门 操作指南：S32 Design Studio - 基于示例创建新的 S32DS 项目 操作指南：S32 Design Studio - 创建新的应用程序项目 HOWTO：使用S32K1xx RTD与AUTOSAR创建一个闪烁LED示例项目 操作指南：在没有 AUTOSAR 的情况下使用 S32K1xx RTD 创建一个闪烁 LED 的示例项目 操作指南：使用不带 AUTOSAR 的 S32 RTD 为 S32G 创建 LED 闪烁应用项目 操作指南：使用带 AUTOSAR 的 S32 RTD 为 S32G 创建 LED 闪烁应用项目 操作指南：使用支持 AUTOSAR 的 S32 RTD 创建 S32M2xx LED 闪烁工程 操作指南：使用不支持 AUTOSAR 的 S32 RTD 创建 S32M2xx LED 闪烁工程 操作指南：使用不支持 AUTOSAR 的 S32 RTD 创建 S32R45 LED 闪烁工程 HOWTO：使用S32 RTD和AUTOSAR为S32R45创建一个闪烁LED应用程序项目 操作指南：使用不支持 AUTOSAR 的 S32 RTD 创建 S32R41 LED 闪烁工程  操作指南：使用 S32 RTD（支持 AUTOSAR）创建 S32R41 LED 闪烁应用工程 操作指南：使用 S32 配置工具创建 S32V2xx 简易 LED 闪烁工程 操作指南：使用不支持 AUTOSAR 的 S32 RTD 创建 S32Z27x LED 闪烁工程 操作指南：在 S32DS 中基于示例创建 APEX2 工程 操作指南：在 S32DS 中基于示例创建 S32 平台的 ISP 工程 操作指南：基于 'RSDK_S32DS_template' 示例创建新工程  构建工具和标准库 如何：将静态库文件添加到 S32 Design Studio GCC 项目中 操作指南：使用 GNU 构建工具将二进制文件链接到应用程序工程   操作指南：在构建结束时显示内存使用百分比  调试与闪存编程 操作指南：配置 S32V234 EVB 以支持 S32DS Vision 和 Linux BSP 调试 在 Eclipse GDB 控制台中使用 GDB Server Monitor 命令 操作指南：使用 GDB PEMicro 调试接口构建工程并配置调试环境 操作指南：为 S32 调试探头配置静态 IP 地址 如何：从 S32G274A EVB 上的 S32 Design Studio 启动 S32 调试器 操作指南：在 S32R45 评估板上从 S32 Design Studio 启动 S32 调试器 操作指南：在 S32R41 评估板上从 S32 Design Studio 启动 S32 调试器 操作指南：使用 S32 调试探头对 S32G2xx 进行命令行 GDB 调试 操作指南：使用 S32 调试探头对 S32R45 进行命令行 GDB 调试  如何：使用 S32 调试探针进行 S32R41 命令行 GDB 调试 HOWTO：使用 S32 调试器和 S32 调试探针对 S32G274A EVB 进行 JTAG Flash 编程 操作指南：使用 S32 调试器和调试探头对 S32R45 评估板进行 JTAG 闪存编程  操作指南：使用 S32 调试器和调试探头对 S32R41 评估板进行 JTAG 闪存编程 操作指南：通过 S32DS IDE 实现安全调试（使用 S32 调试器和调试探头） 操作指南：在 S32G2xx 上使用 S32 调试器和 S32 调试探针启动跟踪 操作指南：在 S32R45 上使用 S32 调试器和调试探头启动跟踪功能 操作指南：在 S32V2xx 上使用 S32 调试器和调试探头启动跟踪功能 与 Eclipse 共享调试配置 使使用 Eclipse 和 GDB 调试启动代码 操作指南：为现有项目添加新的调试器配置 操作指南：在 S32G274A 评估板上使用 S32 调试探针进行命令行 JTAG 闪存编程 操作指南：在 S32R45 评估板上使用 S32 调试探头进行命令行 JTAG 闪存编程 操作指南：在 S32R41 评估板上使用 S32 调试探头进行命令行 JTAG 闪存编程 操作指南：使用 FlashSDK 为 S32 Flash Tool 添加 QuadSPI 闪存设备支持 操作指南：使用 S32 调试探头编程串行 RCON S32K3 安全调试支持 | PEmicro 操作指南：使用 S32 调试器调试 S32R45 的 LAX 操作指南：使用 S32 调试器调试 S32R45 的 SPT HOWTO：使用 S32 调试器在 S32R45 上调试 BBE32 DSP 操作指南：使用 S32 调试器调试 S32R41 的 SPT S32 调试器 Zephyr 线程感知功能用户手册 S32 配置工具 操作指南：使用 DCD 工具创建设备配置数据镜像  如何使用 IVT 工具创建 Blob 图像 操作指南：使用 IVT 工具创建 Blob 图像 S32G274A 操作指南：使用 IVT 工具创建 S32R45 的 Blob 镜像  实时驱动程序 (RTD)、S32 SDK 和其他 SDK 如何下载 RTD 5.0.0 并在 S32 Design Studio 3.6 中安装 操作指南：使用 AMMCLib SDK 操作指南：将自定义 SDK 添加到现有项目 操作指南：将 S32K1xx SDK 项目从 v4.0.1 迁移至 v4.0.2  操作指南：在 S32 调试器和 PEMicro 中使用 FreeRTOS 操作系统感知功能 在 ARM Cortex-M 上实现 FreeRTOS 性能计数器 | MCU on Eclipse 如何：将 FreeRTOS 堆移入 DTCM 内存 - S32K3xx + RTD 通用用法 操作指南：S32 Design Studio 命令行界面 操作指南：生成 S-Record/Intel HEX/二进制文件 操作指南：将应用项目从 S32DS for Vision 2018.R1 迁移至 S32DS 3.x  操作指南：将用户示例添加到 S32DS 故障排除 故障排除：启动 S32 Flash Tool v2.1 时出现 JVM 不兼容错误 故障排除：PEmicro 调试连接 - 目标通信速度 故障排除：头文件索引器错误 故障排除：PEMicro 调试 - 进入调试模式时 PIT 和 STM 模块无法计数 故障排除：PEMicro 调试 - 从 vTaskDelay 断点恢复时出现问题 故障排除：问题视图中的快速修复选项 故障排除：S32 Design Studio 意外退出或安装程序在输入激活码后立即回滚  故障排除：激活失败并显示错误信息 FNP ERROR 0 故障排除：在 S32DS 扩展和更新中找不到 S32K3 的 AMMCLib 故障排除：从命令行使用配置工具时出现 Java 错误

S32K389 AES_ACCEL 在加密 64KB 数据时会挂起/冻结 您好，NXP团队： 我正在使用S32K389并测试AES_ACCEL (ACE/MSC)模块。我在处理大型数据缓冲区时遇到了稳定性问题。 测试设置： 模式： AES-密码块链接(CBC) 案例 1（通过）：加密4KB数据工作正常。 案例 2（失败）：加密64KB数据会导致芯片在执行 AES 服务时立即崩溃/挂起。 观察到的行为： S32DS（S32 设计工作室）在执行 AES 服务期间冻结。 尝试通过调试器连接到 S32K389 完全失败。 问题： 对于每个 AES_ACCEL 事务的最大数据长度，是否存在任何已知的限制？ 此致， 显龙 Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 嗨@wuxianlong 让我查一下。我会尽快回复您。 此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 很抱歉耽搁了，我遇到了一些内部资源访问权限方面的问题，解决起来比预期要花更多时间。我会尽快回复。感谢您的耐心等待。 此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 嗨@wuxianlong CMAC生成验证服务存在以下限制： 我还在确认加密方面是否存在限制。我稍后会通知你。 此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 你好， @lukaszadrapa 非常感谢您的解释。加密和 CMAC 验证可能面临同样的局限性。 此致， 显龙 Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 我了解到大小限制为 512KB - LEN 位域的大小为 19 位。 有趣的是，程序执行完全崩溃了。我预计 AES_ACCEL 在参数无效的情况下会返回一些错误代码。 那不是XRDC引起的吗？XRDC 是否已启用？您能否尝试将其禁用以进行测试？ 此致， Lukas Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 你好， @lukaszadrapa 使用 64KB 进行测试仍然失败。启用 AEC 错误检测后发现，IP 驱动程序宏将限制设置为(1 << 19) - 1​ 位 < 64 KB。 此致， 显龙

S32K344 Mini-EVB 上的以太网引脚冲突 您好，团队、 我正在使用S32K344 Mini-EVB进行以太网连接活动。从用户手册中我可以看到，PTD16 引脚用于 MDC，PTD17 引脚用于 MDIO。但当我在 S32DS 中进行以太网引脚配置时，我看到 PTD16 只能路由到 MDIO，而 PTD17 则路由到 MDC，而且我还从 S32K344_IOMUX 中验证了这一点，从该 excel 中我还可以看到 PTD16 --> MDIO 和 PTD17 --> MDC。 那么，用户手册文件中是否有错误，如果有，是否会影响以太网通信。 Re: Ethernet Pin Conflict on S32K344 Mini-EVB 你好@MySterio_1、 是的，你说得对。引脚 MDC 和 MDIO 对调。我已经报告过——它将在下一个版本的 UM12406 中修复——发布日期尚不清楚。 请随时参考我与此主板相关的 LwIP 示例：示例 S32K344 EMAC LWIP Fre eRTOS miniEVB S32DS 3.6.1 RTD 6.0.0   顺祝商祺！ 帕维尔

iMX8MP MIPI DSI 至 HDMI 转换器（LT9611UXD）调出 您好， 我们设计了一款基于 imx8MP 的主板，用于使用 LT9611UXD 将 MIPI DSI 转换为 HDMI，但该芯片不断报告错误，例如 MIPI DSI 时钟不稳定和无法同步。 我们试图用 LT9611UXC 替换同一块主板上的 LT9611UXD，HDMI 有输出，但是换回来后 LT9611UXD 仍然无法工作。 能否请您指点一二？ 1。恩智浦是否有 LT9611UXD 的解决方案或演示板？ 2.恩智浦是否遇到过 MIPI DSI 时钟不稳定的问题？是如何解决的？    Re: iMX8MP MIPI DSI to HDMI Convertor(LT9611UXD) Bring Up 你好@杨志荣 希望你一切都好。 实际上，我们在 i.MX95 15mm x 15mm EVK DTSO 中使用了 LT9611UXC。 请看一看： https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/arch/arm64/boot/dts/freescale/imx95-15x15-evk-lt9611uxc.dtso 对于 i.MX8MP，我们没有任何示例。 此外，您还可以使用 i.MX8MP 的原生 HDMI 来代替 LT9611UXD。 顺祝商祺！ 萨拉斯

IMX8MP 远程核心共享内存驱动程序 日安 我正在尝试使用 DDR 缓冲区实现内核间的数据交换，以处理大量数据。我在 IMX8MP 上使用的是 Verdin devkit。内核版本 5.15我已经使用"/dev/rpmsg_ctrl0 "通过 RPMSG 实现了通信。 现在，我想从 CMA 空间分配 DDR 中的内存，并通过 RPMSG 消息将地址发送给 CortexM。为此，我使用了恩智浦的 "低功耗音频应用 - AN12195SW "示例。我从补丁中提取了 "rmtcore_shm "驱动程序代码，并通过 devshell 在内核环境中进行了编译。 然后，我在系统中安装了模块 "rmtcore-shm.ko"。 root@verdin-imx8mp-14762892:~# insmod ./rmtcore-shm.ko [ 235.945223] RMTCORE module started! root@verdin-imx8mp-14762892:~# 但是新设备 “/dev/rmtcore_shm” 没有出现在系统中。而当我试图打开它时，却出现了错误： rmtcore_shm_fd = open(RMTCORE_SHM_DEV, O_RDWR); ******************* "Unable to open device /dev/rmtcore_shm" ******************* 我可能需要更改设备文件。现在，我的 RPMSG 覆盖图是这样的： /dts-v1/; /plugin/; #include / { compatible = "toradex,verdin-imx8mp"; rmtcore_shm { compatible = "fsl,rmtcore-shm"; status = "ok"; }; }; &{/} { imx8mp-cm7 { compatible = "fsl,imx8mp-cm7"; clocks = <&clk IMX8MP_CLK_M7_DIV>; mbox-names = "tx", "rx", "rxdb"; mboxes = <μ 0 1 μ 1 1 μ 3 1>; memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>, <&m7_reserved>; rsc-da = <0x55000000>; syscon = <&src>; fsl,startup-delay-ms = <500>; }; }; &i2c3 { status = "disabled"; }; &pwm4 { status = "disabled"; }; &resmem { #address-cells = <2>; #size-cells = <2>; m7_reserved: m7@0x80000000 { no-map; reg = <0 0x80000000 0 0x1000000>; }; vdev0vring0: vdev0vring0@55000000 { no-map; reg = <0 0x55000000 0 0x8000>; }; vdev0vring1: vdev0vring1@55008000 { no-map; reg = <0 0x55008000 0 0x8000>; }; vdevbuffer: vdevbuffer@55400000 { compatible = "shared-dma-pool"; no-map; reg = <0 0x55400000 0 0x100000>; }; rsc_table: rsc_table@550ff000 { no-map; reg = <0 0x550ff000 0 0x1000>; }; }; &sai3 { status = "disabled"; }; &sdma3 { status = "disabled"; }; μ { status = "okay"; }; &uart4 { status = "disabled"; }; 请告诉我需要做哪些更改，才能使 /dev/rmtcore_shm 出现在系统中，并能访问 DDR 中的内存分配？如果有人已经遇到过这种解决方案和示例。 感谢您的帮助。 Re: IMX8MP Remote core share memory driver 你好@Stan88 你查清楚了吗？ 谢谢！ 安迪 Re: IMX8MP Remote core share memory driver 是的，我也试过了 - 我在内核中编译了它，在内核菜单配置中看到了它 -"Remote Core Share Memory Driver" ，并激活了它。编译并部署了内核，构建了镜像并将其安装在板上。 lsmod无法显示该驱动程序，因为它不是动态加载的，而是内置模块。 dmseg也不包含有关该驱动程序的任何信息。尝试卸载模块时会出现错误，提示系统中存在此类模块： root@verdin-imx8mp-14762892:~# modprobe -r rmtcore-shm modprobe: FATAL: Module rmtcore_shm is builtin. Re: IMX8MP Remote core share memory driver 你好 如果你编译模块，你必须编译内核本身才能使其正常运行，并在 dmseg 输出中查看。 此致 Re: IMX8MP Remote core share memory driver 您需要： rmtcore_shm { compatible ="fsl,rmtcore-shm"; status ="ok"; }; 如果有其他人想要 FRDM_IMX8MPLUS 的这个版本，请在这里查看： https://github.com/AndrewCapon/rmtcore-shm/tree/main