使用 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。 顺祝商祺！ 萨拉斯

i.MX95 ISP Camera Compatibility Guide The purpose of this page is to provide supportive information for the selection of suitable camera modules that are supported by the i.MX95. The guide is attached in this page. This helps customers evaluate project feasibility and integration aspects when considering i.MX 95 SoCs for their products. It is strongly recommended to consult with NXP and the camera module vendor before finalizing the choice of the camera part number to ensure compatibility, availability, longevity, and pricing requirements. NXP Supported Sensors: Sensor Vendor Image Sensor Max Resolution Camera Module OmniVision OS08A20 8MP IMX95-OS08A20 | NXP Semiconductors EXPI-OS08A20 OmniVision OX05B1S 5MP OmniVision OX03C10 3MP Onsemi AR0144 1MP AR0144   Partner Enabled Sensors: Partner Sensor Vendor Image Sensor Max Resolution ISP Tuning Camera Module Location FRAMOS Sony IMX662 2MP ✔ FSM:GO Munich, Germany/ Canada/USA Sony IMX678 8MP Sony IMX900 3.2MP Sony IMX676 12MP Onsemi Onsemi AR2020 19MP Module available through Future Electronics Entron OmniVision OS08A20 8MP ✔ EXPI-OS08A20 China Onsemi AR0820 8MP Order with Entron Onsemi AR0823 8MP Technexion Onsemi AR0144 1MP Onsemi AR0145 1MP Onsemi AR0234 2MP Onsemi AR0235 2MP Onsemi AR0236 2MP Onsemi AR0521 5MP Onsemi AR0522 5MP Onsemi AR0544 5MP Onsemi AR0821 8MP   Onsemi AR0822 8MP Onsemi AR0830 8MP Onsemi AR1335 13MP PHYTEC Onsemi AR0144 1MP Germany/ China/India/ USA Onsemi AR0234 2.3MP Onsemi AR0521 5MP E-consystems Sony IMX662 2.4MP Riverside, CA, USA/India Sony IMX900 3.2MP IMX95EVK

For S32G274A multi-core scenario, can the first 0x9100 bytes of fip.bin be neglected? When making ATF image for BSP42, we get information like this: Boot Core: A53_0 IVT Location: QSPI Load address: 0x342f8f00 Entry point: 0x34302000   Entry point - Load address = 0x9100 it's BL2 that sits at offset 0x9100 of fip.bin. So is "Entry point" refering to BL2?   For multi-core scenario, MCU runs bootloader to load BL2 for A53. If BL2 is the entry point, should bootloader just copy from offset 0x9100 of fip.bin(BL2) to 0x34302000 of RAM space(neglect the first 0x9100 bytes)？ GoldVIP Re: For S32G274A multi-core scenario, can the first 0x9100 bytes of fip.bin be neglected? Hello, @wansp  Thanks for your post The bootloader will move the data from QSPI to the Load address(SRAM), they would not be neglected. BR Chenyin

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

您知道 PCA9698 的状态吗？ 我想我可能需要这样的东西。其现状如何？有没有更新的类似产品？ 兰迪 Re: Do you know the status of PCA9698 ? 你好，兰迪、 PCA9698 目前仍在生产，但 HVQFN56 版本 (PCA9698BS) 已经停产。TSSOP56 版本（PCA9698DGG）仍然完全有效并受支持，是新设计的推荐选择。没有较新的恩智浦设备能够在单芯片中提供相同的 40 位 GPIO 数量和电流能力，因此，如果需要该功能，PCA9698DGG 仍然是最合适的解决方案。 BRs, Tomas

ベアメタル用のOSタイマーインターフェース Arm 用の S32DS で動作していた古いドライバ モデルには、ベア メタル実装をサポートするタイマー遅延用の API がありました。新しいリアルタイム・ドライバ モデルでは、同等のものが見つかりません。これを実行しようとするとエラーが発生します。添付のスクリーンショットを参照してください。 それを行う方法はありますか? プロジェクトの詳細: MCU: 144ピン構成のS32K148 システムOS: ベアメタル RTD バージョン: 3.0.0 ドライバー構成: 低レベル (非 Autosar)。スクリーンショットを参照してください。 Re: OS Timer interface for bare metal こんにちは@danielmartynek 更新ありがとうございます。これは私が発見したものと一致しています。いくつかフォローアップがあります: 1.SO、リアルタイム・ドライバには OSIf_TimeDelay() に相当するものはないのでしょうか?ドライバー API の他の部分にも同様のギャップが見られ、既存のコードの移植がやや困難になっています。 2. これらの API はすべての MCAL 実装で統一されていますか?言い換えれば、MCAL 準拠を主張する別のベンダーのハードウェアと MCAL 実装を使用する場合、これらすべての API がそのドライバ実装で利用できると期待できますか?(これを逆に読むこともできます。MCAL 準拠を主張する別のベンダーから NXP に移行する場合、NXP ドライバが他のベンダーのドライバが提供するすべての API を提供すると期待できますか?) よろしくお願いいたします。 ドゥルガー・チョードリー Re: OS Timer interface for bare metal こんにちは、 @durga_choudhuryさん、 OsIf.hを参照してください。以下の機能があります: OsIf_Init()、 OsIf_GetCounter()、 OsIf_MicrosToTicks()、 OsIf_GetElapsed()、 BR、ダニエル Re: OS Timer interface for bare metal こんにちは@durga_choudhuryさん、 1. いいえ、そのような関数はありません。個々のドライバは OsIf API を使用します。たとえば、次のようになります。 2. RTD には以下が含まれます。 AUTOSAR MCALドライバ 低レベルのIPレベルドライバ MCAL の最上位層 (AUTOSAR) のみがポータブルです。 たとえば、Adc_Init()。 しかし、OsIf_GetElapsed() は AUTOSAR API ではなく、NXP 固有のものです。 よろしくお願いいたします。 ダニエル

S32K310 CAN Interrupt Receive S32K310のCANドライバモジュールをCANとCANIFを使って設定しました。CAN_Write()関数を呼び出してメッセージを送信できることは分かっていますが、以下の点について疑問があります。 1. メッセージを受信するにはどうすればよいですか？CanIf_RxIndication()関数を使ってメッセージを受信できるという記事をいくつか見ました。しかし、この関数のロジックは静的コード内で自動的に呼び出されるべきであり、外部メインプログラムで自分で記述するべきではありません。あるいは、この関数は割り込み発生後にデータを保存するので、どのようにデータを読み出せばいいのでしょうか？自分で作成したコールバック関数に置き換えることは可能でしょうか？（MCALルーチンの中に割り込みを使用するCANルーチンは見つかりませんでした。POLLINGモードのルーチンしかないようです。） 2. CANの受信はCANIFを経由する必要があるのに、送信はCANドライバーから直接送信できるのはなぜですか？何か仕様上の制限があるのでしょうか？ 助けてくれてありがとう!! Re:S32K310 CAN割り込み受信 こんにちは@Embedded_novice、 1.FlexCANがドライバーとどのように連携するかについては、次のトレーニングをご覧ください:RTDおよび低レベルドライバーを使用したFLEXCAN。 割り込みモードでメッセージを受信するには、割り込みドライバー(IntCtrl)を設定し、FlexCANデータ情報構造体内でpolling = FALSEを選択し、「FlexCAN_Ip_Receive」を使用する必要があります。 この例は、コミュニティの投稿からガイダンスとして使用できます: TX/RX/EnhanceRXFIFO DMAテストの例S32K344 FlexCAN_Ip S32DS3.5 RTD400 - NXPコミュニティ。 2. CanIf_RxIndication APIのことを言っているのですね。前の回答で述べたように、代わりにFlexCAN_Ip_Receiveを使用できます。 Best regards, Julián