RT685: SDK 25.12 没有 HASHCRYPT 加速功能 你好 我们最近更新到了 SDK 25.12，发现我们的 TLS 解密率降低了一半。 mbedTLS v3.x 不再使用fsl_hashcrypt硬件加速功能。 下面是使用以前的 SDK 25.09 调用mbedtls_ssl_read 的调用堆栈。可以看到，最终使用了HASHCRYPT_AES_EncryptEcb。 hashcrypt_aes_one_block_aligned() at fsl_hashcrypt.c:437 hashcrypt_aes_one_block() at fsl_hashcrypt.c:581 HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,284 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_update() at gcm.c:358 mbedtls_gcm_crypt_and_tag() at gcm.c:456 mbedtls_gcm_auth_decrypt() at gcm.c:491 mbedtls_cipher_aead_decrypt() at cipher.c:1,407 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,613 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,242 ssl_prepare_record_content() at ssl_msg.c:3,667 ssl_get_next_record() at ssl_msg.c:4,551 mbedtls_ssl_read_record() at ssl_msg.c:3,817 mbedtls_ssl_read() at ssl_msg.c:5,237 <...more frames...> 下面是定义了MBEDTLS_USE_PSA_CRYPTO的 SDK 25.12 的调用堆栈。在该版本中，mbedtls_internal_aes_encrypt全部是 C 代码，没有硬件加速。 mbedtls_internal_aes_encrypt() at aes.c:894 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:641 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> 下面是 SDK 25.12 的调用堆栈，其中没有mbedtls_use_psa_crypto定义的调用堆栈。在这个版本中， mbdtls_internal_aes_encrypt全部是 C 代码，没有硬件加速，也不涉及 PSA。 mbedtls_internal_aes_encrypt() at aes.c:899 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_cipher_aead_decrypt() at cipher.c:1,528 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,674 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,639 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> 是否有计划在 mbedTLS 中恢复 RT685 HASHCRYPT 硬件加速？某些 PSA Crypto 驱动程序似乎未被执行。 谢谢！ Re: RT685: SDK 25.12 no HASHCRYPT acceleration 嗨，埃德温、 我在 EVK 上重现了这个问题。我修改了两个样本，在其中添加了一个迭代 200 次的循环 mbedtls_gcm_self_test 并使用 RTC 时钟为整个执行过程计时。 evkmimxrt685_mbedtls_selftest_cm33 执行测试的时间为 1087ms 使用此调用栈： HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,260 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_starts() at gcm.c:294 mbedtls_gcm_crypt_and_tag() at gcm.c:452 mbedtls_gcm_self_test() at gcm.c:826 evkmimxrt685_mbedtls3x_psatest_cm33 执行测试的时间为 8990ms 使用此调用栈： mbedtls_internal_aes_encrypt() at aes.c:896 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 mbedtls_gcm_starts() at gcm.c:441 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075   evkmimxrt685_mbedtls3x_psatest_cm33 来自 SDK 25.12 的 mbedtls_psa_accel_key_type_aes 定义的测试执行时间为 8744ms 使用此 callstack： HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:187 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 mbedtls_gcm_starts() at gcm.c:439 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075 对示例的修改要点如下： BOARD_InitHardware(); test_rtc_init(); psa_crypto_init(); uint64_t ms_start = test_rtc_get_msecs(); for (int i = 0; i < 200; ++i) { PRINTF("test iteration %d\r\n", i+1); mbedtls_gcm_self_test(0); } uint64_t ms_end = test_rtc_get_msecs(); PRINTF("test time = %ums\r\n", (unsigned)(ms_end - ms_start)); ... 其中test_rtc_get_msecs使用亚秒精度返回当前 RTC 时间。 正如您所看到的，使用新的 SDK 加密 GCM/AES 的速度慢了约 8 倍。 如果您需要，我可以附上修改后的示例。 问候， Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration 嗨，埃德温， 我们已经阅读了迁移指南。不过，我们看不出不带 PSA 的 mbedTLS 2.x 或 mbedTLS 3.x 如何在此版本的 SDK 中进行硬件加速。由于 aes_alt.c 已被删除，而 HASHCRYPT 功能仅由 PSA 驱动程序支持。 我们的应用程序在使用 SDK 25.12 时一切正常，我们当然希望在连接时使用 TLS 1.3，但现在的情况会让我们的性能大打折扣。 我们将继续调查此事。我将修改其中一个示例，看看能否重现性能损失。 问候， Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好，@hrc-amilcar、 感谢您耐心解答这个问题。我刚刚收到内部团队的回复，请参见下文。 从调用堆栈中我可以看到，您使用的是传统的 mbedtls_xxx 加密 API。事实上，它并没有加速。MbedTLS3.x推出了新的加密应用程序接口，它就是 PSA。mbedtls/docs/psa-transition.md at v3.6.5 - Mbed-TLS/mbedtls - GitHub而且它还被加速了。 MbedTLS4.x 进一步删除了传统加密 API。 我检查了 RT600 SDK 中的 psa_crypto_examples，通过定义PSA_CRYPTO_DRIVER_HASHCRYPT，HASHCRYPT硬件加速在默认情况下是启用的，这使得加密驱动程序封装器可以将加密计算卸载到硬件上。另一方面，MbedTLS3.x+ 更为复杂，也更符合 PSA API 规范，因此可能会出现某些用例性能较低的情况。对于 TLS，我认为非对称加密技术（CASPER 硬件 IP）会成为性能瓶颈，因为该 IP 只能支持少量加速，而且与 PSA API 不兼容，后者希望硬件 IP 实现整个算法。我们已尽全力至少加速了部分 ECC 操作（签名、验证），但其他操作（如 ECDHE 密钥交换过程中的密钥生成）可能会更糟。 现在，如果您能使用 PSA API 进行性能测量，并确认 PSA_CRYPTO_DRIVER_HASHCRYPT 已定义且调用栈使用了它，那将是一件好事。仅供参考：Hashcrypt本身没有提供AES-GCM加速，因此最好对AES-密码块链接(CBC)或AES-CTR进行基准测试，以查看硬件IP的实际收益。 BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好，@hrc-amilcar、 从mbedTLS 2.x（不含 PSA）迁移到 mbedTLS 3.x（含 PSA）必然会导致性能下降： " PSA 驱动程序接口仅部分实现。因此，编写驱动程序的交付内容以及将驱动程序与 Mbed TLS 集成的方法将根据所加速的操作而有所不同。"(https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mbedtls3x/docs/psa-driver-example-and-guide.html) 目前，我所能推荐的最好方法是遵循如何正确从 2.x 迁移到 3.x 的指南：从 Mbed TLS 2.x 迁移到 Mbed TLS 3.0 - MCUXpresso SDK 文档 以及正确过渡到 PSA API 的指南：过渡到 PSA API - MCUXpresso SDK 文档 不便之处，敬请原谅。 BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration 我在 mbedTLS 配置文件中定义了 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES，现在它正在调用 ASHCRY PT，但是我们的 mbedtls_ssl_read 读取速度现在更慢了。我想知道是否还有其他缺失的定义，或者PSA层增加了额外的开销。   通过 TLS 插口从 WiFi 下载 4KB 数据包的速率： SDK 25.09：205KB/秒（没有 PSA 和 ksdk 端口文件的 mbedTLS 2.x） SDK 25.12：138KB/秒（不带 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES） SDK 25.12：125KB/秒（使用 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES 时） 下面是使用 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES 的新调用栈： HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:203 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 gcm_mask() at gcm.c:543 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好，@hrc-amilcar、 更新 SDK 后，您是否做了任何更改？您在使用 SDK 示例代码时也看到了这种行为吗？你使用的是独立组网 \\(SA\\) IDE 还是 VS Code 扩展？ BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好，@EdwinHz、 我们使用的是 MCUXpresso 集成开发环境。 更新 SDK 后无额外更改： 当我们更新 SDK 时，我们会重新运行 " SDK 管理 "-> " 刷新 SDK 元器件 " 来获取新的和更新的文件。 然后，我们比较 .cproject配置为已启用类似功能的样本之一（例如evkmimxrt685_wifi_wpa_supplicant_cm33) psa_crypto_driver_casper=1 psa_crypto_driver_hashcrypt=1 config_wpa_supp_crypto_mbedtls_psa=1 等等 我们使用默认的mcux_mbedtls_config.h作为主要的 mbedTLS 配置头文件，并使用与evkmimxrt685_wifi_wpa_supplicant_cm33示例中的wpa_supp_mbedtls_config .h几乎相同的用户配置文件。 我将尝试使用 mbedtls3x_examples，看看它们的表现如何。也许我们漏掉了一些定义。 我在浏览代码时注意到，也许需要定义MBEDTLS_BLOCK_CIPHER_C，以便加速 gcm 操作。 看起来头文件mbedtls3x/include/mbedtls/config_adjust_legacy_crypto.h对此负有责任，但由于某些原因最终没有定义该宏。 Re: RT685: SDK 25.12 no HASHCRYPT acceleration 为了他人的利益... 看来 来自 mbedTLS 3.x 的 mbedtls_xor 一次循环遍历 4 字节的数据，并调用 mbed tls_get_unaligned_uint32 和 mbedtls_put_unalign ed_uint32， 它们都使用 memcp y 来处理单个 uint32。 我认识到 MbedTLS 的作者正试图通过一次计算 异或 4 字节块（使用余数循环）来提高性能，但是对 memcpy 的完整调用实际上使代码变慢。 在对反汇编进行一些调查后，我发现我们的项目在编译时使用了 -fno-builtin，导致编译器无法内联小的 memcpys。 移除该选项后，HASHCRYPT 硬件不用于 AES-GCM 操作所造成的性能损失基本得以恢复。因此，我发布的示例执行时间从 8600 毫秒缩短到 2100 毫秒。还没有达到 mbedTLS 2.x + ksdk alt（1087ms）的水平。但修复后的性能已经足够好了。 -阿米尔卡

MPXV5004 Sensor Application question HI, I'm from a Commercial Glass & Dishwasher manufacture & we are looking at replacing our old diaphragm based pressure switches to the MPXV5004 pressure sensor with our control board, with reading the Datasheet it says: "Internal reliability and qualification test for dry air, and other media, are available from the factory. Contact the factory for information regarding media tolerance in your application". so my question is we can provide clean air to the sensor through an Air-Bell, but it wont be dry it will have around 60-70% humidity as we use hot water in the machines. will this affect the sensors reliability or longevity? If so, are there other sensors that could be used? or a recommended way that we could connect the tube from the Air-Bell to the pressure sensor?. Thanks Damien Pressure Sensors Re: MPXV5004 Sensor Application question Hello Damien, Thanks for using our community. You could protect the sensor using a high viscosity silicone. Please, take a look at the following thread: Re: 30% of MPXM2202GS failed within 2 months after installation -Josh

ST7701 驱动程序 Hello 我正在尝试与 ST7701 显示控制器通信。 是否有一些例子？如果可能的话，谁能分享一下？ 我使用的是 i.MX RT1170 板。在 SDK 示例中，我找到了 HX8394、RM68191 和 RM68200 显示控制器的驱动程序。我想为 ST7701 找到类似的东西。 谁能帮帮我？ 谢谢，并致以诚挚的问候、 弗朗切斯科-索利托 Re: ST7701 drivers 你好，@SolitoFrancesco、 目前，我们的 SDK 中没有任何针对ST7701 显示控制器 的驱动程序支持。 与该控制器的集成必须手动完成。 必须调整 LCDIF 模块的分辨率值、同步信号和时钟频率，以便与显示控制器兼容。如果使用 EVK，则可以使用 SDK 驱动程序并调整以下功能的值： BOARD_InitLcdifClock() BOARD_InitMipiDsiClock() BOARD_SetMipiDsiConfig() 这些函数以及同步值的宏都在 " display_support.c " 中引用文件，这是调整显示控制器支持时需要关注的主要文件。   另外，请务必阅读以下应用笔记，因为它详细介绍了液晶显示器设置的工作原理以及其他有用的注意事项：i.MX RT elcDIF RGB 模式用例 (nxp.com)   BR, Edwin. Re: ST7701 drivers 早上好 我按照显示器制造商和驱动程序制造商的指示，修改了你提到的文件。我可以通过 MIPI 对驱动寄存器进行写入和读取。我可以用示波器看到差分 MIPI 波形（也是在"配置" 阶段之后），但仍然无法在显示屏上看到任何东西。我正在使用恩智浦 SDK 中名为"mipi_dsi_compiance_test" 的演示示例。 您能提供更多帮助吗？ 谢谢，并致以诚挚的问候、 弗朗切斯科-索利托 Re: ST7701 drivers 你好，@SolitoFrancesco、 您能在运行时调试代码吗？是否打印出任何错误信息？您在数据线上看到了哪些数据模式？这些模式是否与 readme.md 文件中描述的预期模式一致？ BR, Edwin. Re: ST7701 drivers 你好 我也遇到了同样的情况（相同的驱动程序和分辨率，基础是在开发板上运行的测试示例）。控制器已配置好，我也可以读取状态（没有任何错误），DSI 线路上的数据也已存在，但屏幕上什么也没显示。 将 dsi_dpi_config 中的 videoMode 从 kDSI_DpiBurst 改为其他模式也没有效果。 看起来屏幕不接受视频流？ Re: ST7701 drivers 你好示例项目在显示 DEMO_PANEL_RK055MHD091 时运行正常。然后，我切换到最终应用中必须使用的面板。它的分辨率不同（480x800），因此我调整了定义。然后，我更改了驱动程序（fsl .h和 .c文件），我就能与显示器通信了。我可以写入和回读寄存器。但在配置显示屏后，当示例项目开始发送图像缓冲区时，我能在示波器上看到 MIPI 波形，但显示屏上什么也看不到。假设显示屏没有损坏，因为我尝试通过专用命令打开所有像素，我可以看到屏幕完全白色。我不明白的是，问题是出在显示器的配置上，还是出在示例项目中我必须调整的其他地方。我联系了显示器制造商和控制器制造商，但我需要各方尽可能多的帮助。有可能为安装在显示器上的控制器获取 fsl 驱动程序吗？它是 Sitronix ST7701。请告诉我。谢谢并致以诚挚的问候，弗朗切斯科 Re: ST7701 drivers 您好，Rino 我正在对我的设置和您的设置进行比较（最后我会上传到这里）。 同时，我注意到我使用的是 ST7701，而你使用的可能是 ST7701S（后缀为 S）。我认为它们很相似，但我不确定。 我注意到，现在即使不进行任何初始化，显示屏也能正常工作。"开始时速度很慢，" ，硬度也很低，但还是能用。然后，如果我只发送 0xE0 至 0xEF 的设置（ST7701 数据表中没有记录），显示器启动速度非常快，颜色也正确。似乎所有其他设置都没有必要（听起来很奇怪）。 让我们保持联系。完成后，我将与大家分享比较结果。 再次感谢您。 亲切的问候， Francesco Re: ST7701 drivers 你好，Rino 非常感谢你的建议。在我的应用中似乎也是如此。好极了我可能需要更好的设置，但现在我可以在屏幕上看到图像了。 如果可能的话，请与我分享您的配置，以便我与您的配置进行比较，更好地完善配置。如果我看到了不同的东西，我会在这里告诉你。 再次感谢您。您是如何设置 enableNonContinuousHsClk 的？ 致以亲切的问候， Francesco Re: ST7701 drivers 你好，弗朗切斯科 、 我设法让显示屏正常工作。 在 DisplayTFT_SetMipiDsiConfig 函数中，添加一行内容： dsiConfig.enableNonContinuousHsClk= true； 例如，在这几行之后： DSI_GetDefaultConfig(&dsiConfig); dsiConfig.numLanes = DISPLAY_MIPI_DSI_LANE_NUM; dsiConfig.autoInsertEoTp= true； 假设你已经正确配置了显示 IC（如果有必要，我可以分享我的屏幕配置）和显示时钟（我的设置大约是 26MHz）。 致以最诚挚的问候，克里斯 Re: ST7701 drivers 你好 文件是根据 SDK 中的其他驱动程序创建的。 您还可以将延迟时间改为更短。 今天上午，我确认了配置顺序，并按照显示器制造商的建议做了一些更改，但没有进一步改善，于是我开始仔细研究 DSI 配置本身。我知道时钟很好，视频模式（突发模式）也是如此，所以剩下的唯一选择是 DSI 本身的选择。 熟悉（以及文档中的其他部分）： https://docs.nxp.com/bundle/AN13573/page/topics/continuous_vs_non-continuous_clock.html BR, Chris Re: ST7701 drivers 你好，里诺 按照约定，请在附件中查看您和我的设置对比。我没有细说，但如果我或你会在差异中发现一些有趣的东西，请让我们继续写下去。 此致敬礼， 弗朗西斯科 Re: ST7701 drivers 你好，弗朗切斯科、 抱歉耽搁了。 我浏览了你的对比，发现了很多差异，部分原因是屏幕本身（我们有玻璃/触摸屏/屏幕三明治，对此进行了配置修复——或者至少供应商是这样解释的） 🙂 )。 有些设置（如功率控制）不是启动所必需的，而是为了提高质量（对比度/伽玛设置）。 有趣的是，无论我们是否运行"Sunlight Readable Enhancement" 这个东西，我想他们称之为 "阳光可读增强"，都是必需的。根据这些数据，它可以自动设置最佳参数。如果它们不正确或缺失（默认值），则需要一段时间才能自动设置它们 -> 因此，正如你所注意到的，启动速度会很慢。 文档本身可能相当令人恼火，许多命令都没有文档说明，如果没有文档，往往无法完全启动屏幕。不只是这款机型，我在其他几款态龙机型上也遇到过这种情况。 亲切的问候， Chris

基于 RT1170 通过 USB DFU 更新固件 基于 RT1170 通过 USB DFU 更新固件 基于 RT1170 通过 USB DFU 更新固件 开发环境 准备dfu-util 准备dfu-util 的步骤 运行演示 使用 SDK 中的预建固件 使用自定义固件 无需借助外部编程工具即可在现场执行微控制器 (MCU) 固件升级是一项必要的功能。 对于支持 USB 设备控制器的 MCU，USB 设备固件更新 (DFU) 类提供了一种解决方案。USB_DFU 引导加载程序只需要一台 PC 和一根 USB 电缆。 RT系列也提供了此功能。以 RT1170 为例，SDK 中 USB 类下提供了一个 DFU 项目。该项目基于 MCUXpresso IDE。通过运行 SDK 中的 dev_dfu_freertos_cm7 项目，RT1170 将被枚举为 dfu 设备，并且在通过另一根 USB 电缆将其连接到主机 PC 后，用户可以使用“dfu-util”实用程序将固件下载到该设备。 开发环境 软件环境: SDK版本：2.15.000 IDE: MCUXpresso IDE 演示项目： dev_dfu_freertos_cm7 主机软件： dfu-util 下载链接： dfu-util 对于 Windows 64 位：下载dfu-util-0.9-win64.zip   硬件环境： 主板：RT1170-EVKB   Preparing dfu-util dfu-util用于将固件下载到 DFU 设备，但它不会将 CRC32 添加到固件中。由于 SDK 中的 DFU demo 会验证 CRC32，以确保写入 Flash 的固件没有位错误，因此需要修改dfu-util源代码。 准备dfu-util 的步骤 安装依赖项 sudo apt-get build-dep libusb-1.0-0 dfu-util sudo apt-get 安装 gcc-mingw-w64-x86-64 下载dfu-util和libusb源代码 git克隆https://git.code.sf.net/p/dfu-util/dfu-util git 克隆https://github.com/libusb/libusb.git 修改源代码中的 CRC 代码 修改dfu_file.c中的dfu_store_file函数，将CRC32添加到Firmware后缀。 /* 如果有后缀，则写入 */ 如果（写入后缀）{ uint8_t dfusuffix[DFU_SUFFIX_LENGTH]; dfusuffix[0] = 文件->bcdDevice & 0xff; dfusuffix[1] = 文件->bcdDevice >> 8; dfusuffix[2] = 文件->idProduct & 0xff; dfusuffix[3] = 文件->idProduct >> 8; dfusuffix[4] = 文件->idVendor & 0xff; dfusuffix[5] = 文件->idVendor >> 8; dfusuffix[6] = 文件->bcdDFU & 0xff; dfusuffix[7] = 文件->bcdDFU >> 8; dfusuffix[8] = 'U'; dfusuffix[9] = 'F'; dfusuffix[10] = 'D'; dfusuffix[11] = DFU_SUFFIX_LENGTH; /*crc = dfu_file_write_crc(f, crc, dfusuffix, DFU_SUFFIX_LENGTH - 4);*/ dfusuffix[12] = crc; dfusuffix[13] = crc >> 8; dfusuffix[14] = crc >> 16; dfusuffix[15] = crc >> 24; crc = dfu_file_write_crc（f，crc，dfusuffix + 12, 4); }   构建libusb mkdir -p构建 cd libusb-1.0.24 ./autogen.sh PKG_CONFIG_PATH=$PWD/../build/lib/pkgconfig./configure --host=x86_64-w64-mingw32 --prefix=$PWD/../build 制作 进行安装 光盘 .. Build dfu-util cd dfu-util-0.11 ./autogen.sh PKG_CONFIG_PATH=$PWD/../build/lib/pkgconfig./configure --host=x86_64-w64-mingw32 --prefix=$PWD/../build 制作 进行安装 光盘 .. 完成这些步骤后，新构建的工具将位于/build/bin文件夹中。 打开 Windows 的 cmd。使用新的dfu-suffix.exe运行以下命令，CRC32 将添加到固件中。 dfu-suffix.1 exe -a你的固件 运行演示 使用 SDK 中的预建固件 SDK 提供了一个预编译的固件二进制文件 ( dev_hid_mouse_bm.bin )，其中已包含 CRC32 校验码。请按以下步骤操作： 使用 MCUXpresso IDE 将dev_dfu_freertos_cm7演示刷入 EVKB 板。   通过 USB 将开发板连接到主机 PC。 在 USB 设备描述符中，我们找到供应商 ID 和产品 ID：   运行以下命令下载固件： dfu-util.exe -d <你的视频：进程号> -D <你的固件> 下载后，DFU 演示将验证 CRC32 并在 RAM 中执行新的固件。该设备将被枚举为 USB 鼠标，在屏幕上以矩形图案移动。 使用自定义固件 使用自定义固件时，请确保图像加载到正确的地址（例如，0x10000）。如果偏移量不正确，即使 CRC 校验通过，DFU 演示也将无法加载固件。 构建和加载自定义固件： 将hello_world_cm7项目导入 MCUXpresso IDE。 在托管链接器脚本设置中，启用“将应用程序链接到 RAM”。 调整内存设置以匹配 DFU 项目要求，确保 ITCM 是第一个 RAM 区域。 构建项目并生成二进制文件。 使用修改后的dfu-util工具将 CRC32 附加到二进制文件并将其下载到开发板。验证自定义固件是否正确执行。 CRC 添加： 新固件加载成功： 中文版及演示版请见此链接： https://www.nxpic.org.cn/module/forum/forum.php?mod=viewthread&tid=803149&fromuid=3253523 动手实践培训

中子转换后的 YOLOv8n 模型无法在 i.MX95 中正常输出 您好， ，我从 ultralytics 导出了完全量化的 int8 YOLOv8n 物体检测模型。我已经使用最新的 eIQ Toolkit 版本 1.17 中的中子变流器将其转换成在 NPU 上运行，我曾尝试在 i.MX95 硬件上执行它。 我用 NPU 委托试过转换模型和非转换模型，但似乎只有转换模型上的中子图才能在 NPU 上执行。 当我比较两个模型的原始输出时，转换后的模型给出了多个假阳性，得分超过 95% 。我对已转换和未转换的模型都使用了相同的脚本，但只对已转换的模型有问题。我用多种方法进行了验证，但每次的结果都一样。 当我用 netron 应用程序检查这两个模型时，我发现转换后的模型在结构上发生了重大变化。 在此，我想问几点： 1.eIQ Toolkit 版本 1.17 的 Neutron 变流器是否支持像 YOLOv8 和 YOLOv11 这样的最新物体检测架构？ 2.您在 i.MX95 上使用 NPU 测试过 YOLOv8 和 YOLOv11 吗？如果回答为 "是"，请将模型和后处理步骤一并发送到 3.如果我们要在 i.MX95 中的 Neutron NPU 上执行 Neutron Graph 以外的操作，流程是什么？ 4. 如果我们要在 i.MX95 中的 GPU 上执行上述模型，流程是什么？ 我也翻阅了《机器学习用户指南》，但没有找到相关细节。 谢谢， Vatsal。 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 你好 您遇到的 Neutron 转换 YOLOv8n 模型误报问题是一个已知的难题。目前 i.MX95 NPU 对 YOLOv8 模型的支持仍在优化中，转换过程中的架构变化可能会影响性能。 关于您的具体问题： 1. eIQ 工具包 1.17 中的 YOLOv8 架构支持仍在改进中。推荐的转换工作流程是： - 在导出模型时确保正确的 int8 量化 - 使用最新的 eIQ 工具包 (v1.17) 使用变流器进行转换 - 命令：`./变流器 --input [你的模型].tflite`--target imx95 --use-python-prototype` 2.虽然支持 YOLOv8，但可能尚未完全优化。YOLOv5 与当前的 NPU 实现具有更好的兼容性。恩智浦团队正在积极改进对 YOLOv8/YOLOv11 的支持。 3. 要在 NPU 上执行 Neutron Graph 以外的操作，需要使用 eIQ 或 netron 工具分析模型，以确定哪些运算符已成功转换为在 NPU 上运行（显示为 neutronop 内容）。未转换的运算符将在 CPU 上运行。 4.在 i.MX95 上执行 GPU 运算时，应使用 TensorFlow Lite GPU 委托而不是 NPU 委托。这需要修改推理代码以使用 GPU 委托。 您可以通过在 netron 中检查转换后的模型来验证模型操作的分布情况--任何含有"neutronop" 内容的运算符都在 NPU 上执行，而其他运算符仍在 CPU 上执行。 此致 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 我们再次使用带有自定义数据集的YOLOv5s进行了训练，并尝试进行推断，因为您在之前的聊天中声称YOLOv5使用中子变流器取得了不错的结果。YOLOv5 也仍然存在这个问题。我也附上结果以供参考。在这里，我们尝试了已转换和未转换的 int8 tflite YOLOv5s 模型。 现在，如果你声称 YOLOv5 能够带来良好的效果，那么为什么不与我们分享经过验证的模型呢？请分享从导出、量化到转换的所有步骤，以及后期处理的步骤。这样我们就可以验证您的模型，并在我们这里复制您所遵循的步骤。 如果可以的话，也请与i.MX95共享您的基准测试和我的数据。 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 你好，@Bio_TICFSL！ 我注意到恩智浦团队建议使用 --use-python-prototype 标志，但是我的中子变流器无法识别它。它是在 Windows 上支持的，还是只与 Linux eIQ 版本兼容？ Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 这对我来说也是一个问题。我使用过 Linux eIQ，但效果不佳。因此我跳过了它，尝试只通过目标 arg 转换模型。 Re: Neutron Converted YOLOv8n model is not giving proper output in i.MX95 您好@Bio_TICFSL, 由于时间已久，我仍在等待您的回复。我们被困在这里，我们也有一些紧迫感。请尽快回复。 谨致 Vatsal [i.MX95 NPU] YOLOv5n/v8n/v11n Neutron-converted Models Run but Return No Detections (Zero Output) 问题描述 我正在使用 Neutron 变流器在 i.MX95 NPU 上评估 YOLO 目标检测模型。 虽然 INT8 量化的 TFLite 模型在 Cortex-A55 CPU 上运行成功并能检测到物体，但编译后的 neutron.tflite 版本在卸载到 NPU 时，尽管执行推理时没有崩溃，却产生了零检测结果（空/无输出）。 环境及硬件设置   硬件： i.MX95 19x19 LPDDR5 EVK（A1 版本） 操作系统/内核： Linux 6.12.34-lts-next-gbe78e49cb433 #1 SMP PREEMPT (aarch64) NXP 工具链： MCU-SDK v25.09.00 + Linux 6.12.34_2.1.0 测试型号： YOLOv5nu、YOLOv8n、YOLOv11n（Ultralytics） 工作流程步骤和使用的命令 1. 量化（Ultralytics 导出） 模型导出为 INT8 全整数量化格式，分辨率为 320x320： yolo export model=yolov8n.pt format=tflite int8=True imgsz=320# (Repeated identically for yolov11n.pt and yolov5nu.pt)   状态：在CPU上运行完美。yolovXn_full_integer_quant.tflite 在 A55 内核上能够正确检测对象。 2. 中子汇编 TFLite 模型是使用 MCU_SDK_25.09.00+Linux_6.12.34_2.1.0 中的 Neutron 转换器为 i.MX95 NPU 编译的： ./neutron-converter --input yolov8n_full_integer_quant.tflite --target imx95 --output yolov8n_full_integer_quant_neutron.tflite   状态：无法在 NPU 上检测到对象。编译后的模型可以加载并运行推理，不会抛出语法或执行错误，但对于完全相同的测试图像，输出张量返回零检测结果。 观察到的症状和疑似根本原因   操作回退：变流器是否会针对特定的 YOLO 层（如自定义锚点、SiLU/Swin 激活或非最大值抑制）回退到 CPU？ 量化缩放/不对称性：通过 Ultralytics 导出的 YOLO 模型通常使用不对称量化或具有 Neutron NPU 驱动程序可能误解的特定输出张量缩放。 输出张量格式：推理运行正常，这表明输入管道没有问题，但输出边界框/分数要么为空白，要么完全是垃圾值。 向恩智浦专家提问   中子变流器是否存在针对 Ultralytics YOLO 架构的已知限制或必需的优化标志？ 在将 TFLite 模型传递给 Neutron 转换器之前，是否应该去除 NMS（非极大值抑制）层？ i.MX95 Neutron SDK 是否需要对称量化（per_channel=True 或 False）才能正确解析输出层？ 任何关于 i.MX95 NPU 的指导、参考脚本或 YOLO 部署说明都将不胜感激。        

MCXW716C 在高温下运行 你好 我使用的是 #mcxw71，根据数据表，其工作温度范围为 -40 °C 至 +125 °C。我对无线电和 CAN PHY 都进行了测试，但无法在大约 85 °C 以上实现稳定运行。微控制器似乎进入保护模式，或以其他方式限制其功能。 我还注意到，在 SDK 应用程序接口中有向 NBU 发送内部温度的函数。 我的问题是：NBU 是否需要温度信息来进行热调节或维持系统正常运行？ 一般来说，是否需要任何特定的程序（配置、校准、所需的 API 调用等）来确保 MCXW716C 在最高额定温度下正常运行？ 提前感谢您的帮助。 开发板 Re: MCXW716C operation at high temperature 你好，希望你一切都好。 您使用的是 FRDM 板还是自定义板？您进行了哪些测试，观察到的行为是什么？ 能否请您分享一下您所指的是哪些 SDK API？您是否正在研究一个具体的示例或应用？ 致以最诚挚的问候， Ana Sofia。 Re: MCXW716C operation at high temperature 你好，@sofiaurueta、 我正在使用参考编号为 #MCXW716CMFTAT 的自定义板。我将解释我的测试和配置 我使用 MCXW716CMFTAT 为无线应用设计了 PCB。我已创建了软件，并使用名为"connectivity_test" 的示例程序中的逻辑来使用无线电协议。 我使用的是 SDK SDK_2.X_MCXW716CxxxA 版本 25.09.00。 两个董事会正在一起工作。我已经实施了所有模块。测试时，我使用了热风枪，温度为 80 °C。15 秒后，微控制器停止工作；它似乎被阻塞了，GPIO 被锁定，通信总线停止发送数据，30 秒后，温度下降后，微控制器恢复正常运行。 因此，我研究了监测温度的功能，以了解问题所在。我使用了 SDK 中 fwk_platform_sensors 文件中的 PLATFORM_StartTemperatureMonitor() 函数。 我的目标是知道微控制器堵塞的确切温度，而令人惊讶的是，这解决了问题。现在，我可以在 +120 °C 的温度下进行测试，微控制器工作正常。我甚至尝试删除该功能，以确保问题是否与软件有关，结果问题又出现了。 您能给我更多的解释吗？使用该功能读取温度是否会将数据分发到不同的内核并调整某些参数？ Re: MCXW716C operation at high temperature 你好 您能否确认使用 FRDM 板时是否也会出现这种行为？在未作任何修改的情况下运行 connectivity_test 示例时是否会出现问题，调用 PLATFORM_StartTemperatureMonitor 函数后问题是否会改变？ Ana Sofia。

文本区域错误问题 我创建了几个 Textarea 元器件。当我使用键盘在其中一个输入框中输入内容，然后点击"Finish" 时，键盘会自动切换到另一个文本区进行进一步操作。如何解决这个问题？视频地址为https://github.com/monkeyhorse/guiguider.git Re: Textarea bug issue 嗨，@monkeyhorse、 谢谢你的澄清。我发现这个问题似乎是在模拟过程中出现的。是否只有在模拟时才会出现这种情况？或者在板上运行 GUI 时也是如此？ Re: Textarea bug issue @EdwinHz是的，我使用的是最新版本。 Re: Textarea bug issue 嗨，@monkeyhorse、 感谢您的更新。您使用的是哪个版本的 GUI Guider/LVGL？它们是最新的吗（GUI Guider 1.9.1 和 LVGL 9.2.1）？ Re: Textarea bug issue 现在我发现，setup_scr_screen.c 中 Textarea 的创建顺序是造成这个问题的原因，但我仍然不知道如何解决这个问题。

i.MX RT700 eIQ Neutron NPU 实验室指南 这些实验室指南提供了分步说明，说明如何制作量化的 TensorFlow Lite 模型，并使用 e IQ Neutron SDK 中的中子转换工具将模型转换成在 i.MX RT700 设备上 的 eIQ Neutron NPU 上运行。适用于 i.MX RT700 的 eIQ Neutron NPU 实验指南 文档 重点介绍使用 eIQ Neutron SDK 中的中子转换器工具转换模型，然后将转换后的模型导入 eIQ mcuxPresso SDK 示例。有 VSCode、GCC 和 MCUXpresso IDE 实验室 。 这些实验室旨在在 i.MX RT700 EVK 上运行，但同样的概念也可以应用于 MCX N 主板，类似于 MCX N eIQ Neutron NP U 实验室。您还可以查阅《TFLM 入门指南》，了解如何使用自己的模型和数据进行推理。 此外，请务必查看AN14700 - i.MX RT700 eIQ Neutron NPU Enablement and Performance，其中详细介绍了 i.MX RT700 上的 eIQ Neutron N3-64 NPU。 --- 2026 年 4 月末更新，适用于 MCUXpresso SDK 26.03 和 eIQ Neutron SDK 3.1.0 实践培训

便携式射频烹饪应用的设计挑战 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在设计烹饪设备时，需要充分考虑家庭有线电气系统所需的电力以及维持安全和工作温度所需的性能。NXP 固态射频烹饪团队开发了一种使用固态射频能量的便携式食品加热器具，该加热器具能够依靠电池供电运行。本次会议将讨论通过便携式、便携设备提供能量来加热食物所面临的主要挑战和方法。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 在设计烹饪设备时，需要充分考虑家庭有线电气系统所需的电力以及维持安全和工作温度所需的性能。NXP 固态射频烹饪团队开发了一种使用固态射频能量的便携式食品加热器具，该加热器具能够依靠电池供电运行。本次会议将讨论通过便携式、便携设备提供能量来加热食物所面临的主要挑战和方法。

INS-N2010 批量和带状等离子清洗配置及其在 IC 封装技术中的应用 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 等离子清洗在IC封装行业中得到了广泛的应用，用于清洗组装材料，以提高其后续工艺的清洁度，并提高整体封装或器件的可靠性。其中一个挑战是，当各种材料暴露于等离子体时，如何建立清洁过程的兼容性。随着近年来铜线在 IC 封装中的应用，污染的控制非常重要。已发现焊盘腐蚀对于器件和封装的可靠性至关重要，这是本文要解决的主要问题之一。我们将介绍评估结果，包括使用不同等离子清洗配置进行的表面分析和可靠性测试及其其他应用。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 等离子清洗在IC封装行业中得到了广泛的应用，用于清洗组装材料，以提高其后续工艺的清洁度，并提高整体封装或器件的可靠性。其中一个挑战是，当各种材料暴露于等离子体时，如何建立清洁过程的兼容性。随着近年来铜线在 IC 封装中的应用，污染的控制非常重要。已发现焊盘腐蚀对于器件和封装的可靠性至关重要，这是本文要解决的主要问题之一。我们将介绍评估结果，包括使用不同等离子清洗配置进行的表面分析和可靠性测试及其其他应用。 洞察与创新

MCUXpresso 配置工具：如何使用时钟工具（日语博客） 目录 介绍 Clocks Tool 适用于哪些情况？ 安装配置工具 Minecraft 工具的屏幕配置 时钟工具使用基本术语 演示：更改 CPU 核心时钟设置并改变 LED 闪烁速度。 奖励 1 - 时钟设置已作为预设提供。 附加题 2 - 初始化代码自动生成的设置值在哪里？ 介绍 MCUXpresso 是恩智浦半导体 (NXP) 提供的一款微控制器开发软件平台。除了 MCUXpresso IDE 之外，它还提供 MCUXpresso for VSC（Visual Studio Code）和配置工具，以辅助外设配置。 配置工具包含多个工具，例如用于设置引脚的“引脚工具”和用于配置时钟设置的“时钟工具”。其主要特点是可以通过图形用户界面 (GUI)直观便捷地完成微控制器外设的初始设置。本文将重点介绍负责时钟设置的“时钟工具” 。有关“引脚工具”的使用说明，请参阅以下文章。 MCUXpresso 配置工具：引脚工具的使用方法（日语博客） 时钟设置是直接影响微控制器性能、功耗和各外设运行的关键因素。然而，时钟树可能非常复杂，难以理解各个外设正在使用哪个时钟。时钟工具允许您可视化和配置时钟源、分频设置以及每个外设的时钟供电状态。它还可以根据设置自动生成初始化代码。 安装MCUXpresso IDE时，配置工具也会一并安装，使其成为IDE的内置功能。另一方面，在近年来嵌入式开发领域日益流行的Visual Studio Code ( VSC ) 环境中，您也可以通过安装MCUXpresso相关扩展来使用配置工具（包括时钟工具）。IDE版本和VSC版本在配置工具的功能上并无显著差异。 本文 解释了如何在 VS Code 环境中安装 配置工具 ，如何使用这些工具，并最终演示了如何在 时钟工具 中更改 CPU 时钟设置，以及如何使用 FRDM-MCXN947 改变 LED 闪烁速度。 您还可以观看视频。点击此链接观看：如何使用 MCUXpresso 时钟工具（VS Code 环境） Clocks Tool适用于哪些情况？ 当您想要检查现有的内部时钟设置（时钟树）时 当您需要调整和优化每个模块的工作频率时。 当您想要考虑一种既能降低时钟频率又能降低功耗的配置时。 安装配置工具 本指南解释了如何在VS Code环境中安装Config Tools 。 *如果您尚未为 VS Code 安装 MCUXpresso ，请参阅此博客文章。 安装适用于 VSC 和 SDK 的 MCUXpresso（日文博客） 启动VS Code后，从左侧面板中选择MCUXpresso ，然后从快速启动面板中单击“打开 MCUXpresso 安装程序” 。 安装程序将启动。选择MCUXpresso 配置工具，然后单击右上角的“安装” 。 （这篇博文介绍了 MCUXpresso 配置工具 v26.03 的安装过程。） 安装开始后，系统会提示您登录MyNXP 。 登录后，将显示许可协议。请阅读并同意其内容。 *安装完成后请重启VS Code。 问：如果安装失败怎么办？ A. 请从以下网站下载适合您电脑操作系统环境的安装程序并进行尝试。 MCUXpresso 配置工具 | NXP 微控制器 (MCU) 软件开发 | NXP 半导体 安装过程中，初始屏幕上会出现以下界面。如果您没有看到任何相关信息，可以将其关闭。 要从VS Code访问配置工具，请安装SDK ，导入示例，然后右键单击您的项目。 “使用 MCUXpresso 配置工具打开”将出现；单击它。 *整个过程将在最终演示中详细解释，因此我们在此省略。 配置工具将在短时间内启动。 如果您使用的是 MCUXpresso IDE，则配置工具默认已集成，可以直接从顶部选项卡启动。 Minecraft 工具的屏幕配置 启动配置工具后，您可以使用屏幕右侧的面板在工具之间切换。 这次，我们将选择“时钟”。 时钟图（在更改时钟设置时经常用到）可以从屏幕左上角选择。 屏幕右下角的“问题”视图会显示与您的设置相关的任何错误或警告。 如果由于时钟设置不正确而出现错误，“问题”视图将显示错误的位置和原因。此外，时钟图上的相关区域将以红色突出显示，以便您直观地识别问题。 例如，如果将 CPU 时钟设置为超过指定的最大值，则会显示错误消息（如下所示）。 时钟工具使用基本术语 本节阐明了使用时钟工具时时钟图上显示的基本术语。 时钟树 这是一个配置图（树状图），展示了时钟的生成位置、分配和选择方式，以及如何将它们提供给每个模块。时钟工具允许您在查看此时钟树的同时配置设置。 时钟源 这是作为时钟起始点的信号源。它包括内部RC时钟、外部晶体（振荡器）和外部时钟输入，位于时钟树的上游。 在 MCX N947 中，默认情况下使用内置的48MHz RC时钟(FIRC)作为时钟源。 PLL（锁相环） 该电路以时钟源为输入，产生稳定的高频时钟。 通过设置倍频器和分频器可以调节输出频率，从而为 CPU 和高速总线灵活地创建时钟。 这里，基于48MHz输入时钟（即时钟源）生成300MHz时钟（48MHz/8*50=300MHz） 。 除号 (DIV ) 此功能允许您对时钟频率进行分频和调整。 CPU 、总线和每个外围设备都有分频设置，用于调整到所需的运行频率。 在以下示例中，由 PLL0 生成的 300MHz 时钟生成 150MHz 时钟（300MHz/2=150MHz）。 多路复用器（Mux ） 该机制允许您从几个可选时钟中切换使用哪个时钟。 切换选择项会改变下游提供的时钟信号。 在下图所示的电路中，有两个多路复用器；左边的多路复用器从内部RC时钟中选择48MHz时钟，右边的多路复用器选择150MHz时钟除以DIV（PLL0_PDIV） 。 演示：更改 CPU 核心时钟设置并改变LED闪烁速度。 在这里，我们将使用时钟工具实际改变提供给CPU 的时钟，看看评估板上的LED闪烁速度是否会发生变化。 硬件准备 本文使用的评估板是 FRDM-MCXN947 安装 SDK 在VS Code左侧面板中选择MCUXpresso 图标，然后单击“导入存储库”。 接下来，点击左侧第二个选项“远程存档”，然后在“软件包”部分搜索“ FRDM-MCXN947 ”。输入“ 947 ”后， FRDM-MCXN947 将立即显示为建议。 您可以根据需要设置名称、位置和“创建 Git”复选框。 *对于名称和位置名称，最好只使用小写字母数字字符和下划线(_)或连字符(-) ，并避免使用符号（ \、/、:、*、?、"、、| ）（这可能会导致程序故障）和空格。 最后，勾选“我同意”复选框，然后点击“导入”开始安装SDK 。请稍候片刻。当屏幕右下角显示“存储库导入成功”时，安装即完成。 导入示例代码 SDK安装完成后，即可导入示例代码。 点击左侧面板中的“从存储库导入示例”。 在右侧显示的每个选项卡中，“存储库”下，选择您刚刚导入的SDK 。 请为“主板”选择FRDM-MCXN947 。 在这个“模板”演示中，我们将改变LED的闪烁速度。 尝试输入“ led ”，然后选择出现的“ driver_examples/gpio/gpio_led_output_cm33_core0 ”。 接下来，选择工具链并点击“导入” 。 打开配置工具 右键单击导入的示例，然后选择“使用 MCUXpresso 配置工具打开”。稍等片刻，配置工具将启动。 配置工具打开后，首先查看右侧面板中的概览。在本例中， “时钟”和“引脚”均显示为绿色（开启） ，表示这两个工具均已启用。 现在，让我们来看一下时钟图。 150MHz 的主时钟由48MHz时钟源FIRC 通过PLL (PLL0) 、 DIV (PLL0_PDIV)和MUX (SCSSEL)生成。 接下来，向下滚动一点，可以看到提供给CPU 的时钟。在本示例应用程序中，“ System_clock”对应于CPU 核心时钟。 主时钟频率为 150MHz ，中间经过一个分频器（分布式变量），但仍然以150MHz的频率提供给系统时钟。稍后，我们将改变这个分频器的值，从而改变输入到系统时钟的时钟信号，并观察LED闪烁速度的变化。 检查 CPU 时钟频率设置为 150MHz 时的 LED 闪烁速度。 首先，我们来看看 CPU 时钟频率设置为150MHz且不做任何更改时的 LED 闪烁速度。关闭配置工具并打开VS Code 。 在组装之前，将电路板（ FRDM-MCXN947）连接到电脑。 连接建立后，调试导入的示例（构建、写入和运行应用程序）。 调试过程完成后，程序将在断点处停止，因此请点击屏幕顶部的“|▶”图标。 如视频所示，红色LED灯将开始闪烁。这是时钟频率为150MHz （默认设置）时的闪烁速度。 (function() { var wrapper = document.getElementById('lia-vid-6395306957112w304h540r743'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); （显示我的视频） 要停止，请点击方形图标（即使停止调试后，程序仍会在板上继续运行，因此 LED 会继续闪烁，但请暂时忽略这一点） 。 将 CPU 时钟频率改为 50MHz，并检查 LED 闪烁速度。 接下来，我们将使用ClocksTool将 CPU 核心时钟从 150MHz 更改为50MHz 。 再次打开配置工具中的时钟工具。在时钟图中向下滚动一点，然后更改连接到系统时钟的DIV（AHBCLKDIV） 。更改时，单击要更改的 DIV 中的数字，然后从下拉菜单中进行选择。此处选择1/3会将系统时钟更改为50MHz 。 *更改时钟设置时请注意，更改靠近时钟源的上游时钟设置可能会影响下游的多个时钟设置。 现在，我们将重写示例代码。首先，单击“配置工具”屏幕左上角的“更新代码” 。在出现的对话框中，选择“确定”。 在此状态下返回VS Code后，屏幕顶部会出现三个复选框。请确保选中它们，然后单击“确定” 。稍等片刻，时钟工具中所做的更改将应用到VS Code中的示例代码。 *如果 SDK 版本不同，则可能不会显示此内容。 如果成功，屏幕右下角将显示以下消息。 再次运行调试测试，完成后，使用“|▶”运行示例应用程序。 LED灯将开始闪烁。这是50MHz时钟频率下的闪烁速度。显然，它比150MHz时钟频率下的闪烁速度要慢。 (function() { var wrapper = document.getElementById('lia-vid-6395308518112w304h540r499'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); （显示我的视频） 演示到此结束。感谢各位的参与。 奖励 1 - 时钟设置已作为预设提供。 之前的步骤需要使用DIV 函数更改时钟，而时钟工具则预配置了多种时钟设置。在配置工具中选择时钟工具，然后从屏幕顶部选择所需的时钟：FRO 12MHz / FRO HF 48MHz / FRO HF 144MHz… 例如，如果您选择“BOARD_BootClockPLL_100M ” ，您会发现时钟源、 PLL和DIV都与之前不同。例如，时钟源是24MHz 的外部时钟(SOSC) 。 附加题 2 - 用于自动生成初始化代码的设置在哪里？ 我们将研究如何使用时钟工具自动更新时钟设置（更新代码），以及这如何在实际初始化代码中体现。 检查导入示例的项目文件中的 C 源文件 (gpio_led_output.c)。 如果你查看C源文件，你会发现初始化引脚、时钟和调试控制台的代码。 右键单击BOARD_InitHardware();然后单击“转到定义”以查看更多详细信息。 代码中包含初始化 引脚 、 时钟 和 调试控制台的 功能。 右键单击 BOARD_InitBootClocks(); 并选择“ 转到定义”（或“fn + F12”） 以查看更多详细信息。 目标文件（clock_config.c）是 FRDM-MCXN947这是定义启动时钟配置的生成代码。 向下滚动页面，您会看到，如前所述，有多种时钟配置（ FRO 12MHz / FRO HF 48MHz / FRO HF 144MHz / PLL 150MHz / PLL 100MHz ）作为预设选项。下图显示的是PLL150MHz的默认值。 例如，如果您将此部分更改为BOARD_BootClockFROHF48M 初始化将使用FRO HF 48M时钟配置执行，该配置已准备就绪。 接下来，我们来看看在保持FRO HF 48M不变的情况下，直接在时钟工具中修改DIV 值时，时钟配置和代码会发生怎样的变化。红色框内的文本和设置将会改变。 此外，如果您将时钟工具中连接到系统时钟的DIV更改为1/2 ，即从48MHz更改为 24MHz，然后运行更新代码，您将看到由于 DIV 的变化，红色帧发生了变化。   您还可以使用时钟工具查看更改前后的差异。 更改时钟设置后，点击“更新代码”将显示如下所示的对话框。存在差异的文件，其文件名右侧会显示“更改”字样。点击此字样即可查看差异。 clock_config.c我们来检查一下区别。左侧（新生成）显示的是修改后的文件，右侧（磁盘上）显示的是原始文件。您应该能够看到系统时钟存在差异。 出现差异的区域用不同的颜色突出显示，使其在视觉上很容易被发现。   由于微控制器和处理器的功能集成度不断提高，其内部时钟树变得极其复杂。如果没有像这样的时钟可视化工具，设计和评估此类系统几乎是不可能的，所以请务必使用它。   参考资料 教程视频：如何在 VS Code 环境下使用 MCUXpresso Clocks Too   =========================​ 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便，我们深表歉意，但 在进行咨询时， 请 参考“ NXP 技术问题 - 如何联系我们 （ 日语博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ，您可以直接咨询您的代表。） 本指南重点介绍 MCUXpresso 配置工具中的“时钟工具”，解释其基本原理和设置时钟的方法。内容涵盖从在 VS Code 环境中安装到演示 CPU 时钟变化引起的 LED 闪烁等各个方面。 （预计耗时：10 分钟 *假设已安装 MCUXpresso for VSC（Visual Studio Code）SDK） MCUXpresso MCX SW | 下载 日本博客

[Zephyr ®系列] 第二部分：首次构建并在真机上运行（日文博客） 在 Zephyr 系列的第二部分中，我们将实际搭建一个 Zephyr 开发环境，并创建一个可以进行构建的环境。 接下来，我们将构建 Zephyr 应用程序并将其写入真实设备以检查其是否有效。 别担心，搭建开发环境非常简单。 最后，在第三节课中，我们将创建一个程序来控制 LED 闪烁，并体验 Zephyr 风格的编程。 那么，我们开始吧。 目录 准备 Zephyr 开发环境 安装说明 步骤 1：安装 VS Code 和扩展程序 步骤 2：设置 Zephyr 开发环境 步骤 3：导入 Zephyr 存储库 步骤 4：导入 Zephyr 示例应用程序 构建 HelloWorld 调试和运行检查 总结   准备 Zephyr 开发环境 本文将介绍如何在 Windows 环境下安装 Zephyr 项目并准备构建环境。此外，本次我们将使用 Windows 11 安装 Visual Studio Code。   笔记： 这里我们将介绍 Windows 11 的操作步骤，但您也可以通过安装 VS Code 在其他操作系统上以相同的方式进行设置。   筹备发展评估委员会 这里我们将使用FRDM-MCXA153 。对于 NXP 微控制器（MCX 系列）和跨界微控制器（i.MX RT 系列），也可以遵循相同的步骤。 FRDM-MCXA/C/N/E系列 i.MX RT10xx-EVK系列 LPC系列（部分支持） 安装说明 我们将安装以下物品： VS Code 和 MCUXpresso for VS Code 扩展 Zephyr 开发环境，包括 Zephyr SDK VS Code Zephyr 仓库   步骤 1：安装 VS Code 和“MCUXpresso for VS Code”扩展 如果您尚未安装 Visual Studio Code (VS Code)，请在Microsoft Store中搜索“visual studio code”并进行安装。 接下来，安装“MCUXpresso For VS Code”。 VS Code 中的扩展视图 或者，按 Ctrl+Shift+X。点击扩展视图顶部的搜索字段，然后输入“mcuxpresso” 。 选择 MCUXpresso for VS Code，然后点击“安装”按钮安装该扩展。安装成功后，它将被添加到已安装列表中。 拡張機能ビューボタン扩展功能视图按钮 VS Code 拡張機能 マーケットプレイスVS Code 扩展市场 MCUXpresso for VS Codeのインストール为 VS Code 安装 MCUXpresso     步骤 2：Zephyr 开发环境，包括 Zephyr SDK 打开 MCUXpresso for VS Code 扩展。在快速入门面板中，点击“打开 MCUXpresso 安装程序”。 Quick Startパネル快速启动面板   MCUXpressoツールの選択オプションMCUXpresso 工具选择选项 MCUXpressoツール選択オプション２MCUXpresso 工具选择选项 2   现在点击你需要的工具进行选择。 Zephyr 开发人员 Arm GNU 工具链 链接服务器 这里我们将使用 NXP 板载 ICE 进行调试，因此需要 LinkServer 选项。 尖端： NXP EVK 默认使用 LinkServer。请安装调试探针所需的工具。 LinkServer、Segger JLink 和 PEmicro 工具可供安装。 选择好安装选项后，点击“安装”按钮。底部的状态栏将显示安装状态。 重启 VS Code。   步骤 3：导入 Zephyr 存储库 接下来，导入 Zephyr 仓库。 在 VS Code 中打开 MCUXpresso 视图，然后在快速入门面板中单击“导入存储库”。   リポジトリのインポート导入存储库   Zephyr 是开源的，可以在 GitHub 上找到。您可以导入这个 GitHub 代码库。 发布标签：稳定版本。您可以通过指定标签来指定不同的版本。 主分支：Zephyr 的最新负责人 在这里，我们将导入版本标签 v4.0.0。 位置：选择要导入 Zephyr 存储库的文件夹位置。 代码仓库：选择“Zephyr”作为代码仓库。GitHub URL 也会显示出来。 版本：在版本字段中，使用 v4.0.0。如有必要，请将其更改为其他版本。 输入完信息后，点击“导入”。如果要导入 Zephyr 主分支，请将版本字段更改为 main。 笔记： 导入 Zephyr 存储库需要一些时间，通常大约需要一个小时。 虽然 Zephyr 项目不需要，但也可以导入 MCUXpresso SDK。   步骤 4：导入 Zephyr 示例应用程序 完成前 3 步后，您现在可以开始为 Zephyr OS 开发应用程序了。最终，您将能够导入、构建和调试 Zephyr 示例应用程序。 要从 Zephyr 存储库导入示例应用程序，请从“快速入门”面板中单击“从存储库导入示例”。   レポジトリからExampleのインポート从存储库导入示例 Hello_Worldプロジェクトのインポート导入 Hello_World 项目   应用程序类型：我们选择了仓库式应用程序。我们将使用 Zephyr 仓库中的原始示例项目文件夹。 名称：设置项目名称。 Zephyr SDK：这是一个提供 Zephyr 编译器、库和工具的软件包。选择“默认 Zephyr SDK”。   构建 HelloWorld 要编译和构建程序，请单击“构建”按钮来构建 Hello World 项目。 非常简单。 Zephyr 通常使用命令行构建，构建过程以 West 命令开始，但也可以使用 GUI 中的单个构建按钮进行构建。 无需记住复杂的命令选项。 ビルドボタン构建按钮   构建完成后，将显示内存容量和使用情况。 Hello Worldプロジェクトのビルド結果Hello World 项目构建结果   调试和实际设备操作 现在，我们终于要把 Zephyr 程序写入实际设备并检查其运行情况了。 检查操作前，请按照照片所示将电脑连接到 USB Type-C 线缆。 安装有两个 USB 连接器，但连接到 J15 USB 连接器侧。 FRDM-MCXA153FRDM-MCXA153   要开始调试，请点击播放按钮“▷”。 デバッグ開始开始调试 它会在 main() 函数入口处停止，允许您执行单步执行。 在这里，按下播放按钮即可运行该步骤。 ステップ実行の様子步骤执行   在 VS Code 底部中央的多个选项卡中，有一个串口监视器功能。按照下图所示进行设置，然后单击“开始监视”以检查 Printf 输出（标准输出）。 シリアルモニター串口监视器   总结 这次，我们安装了 Zephyr 开发环境，构建了一个 Hello World 项目，并在实际设备上检查了它的运行情况。 使用“MCUXpresso for VS Code”简化了 Zephyr 开发环境、依赖库和工具的安装，使我能够非常轻松快捷地设置环境。 在下一期中，我们将通过一个 LED 闪烁程序，最终向大家介绍 Zephyr 在软件重用性方面的应用。 （请耐心等待发布。） 点击此处查看上一篇文章 【Zephyr ®系列】第一部分：什么是热门的 Zephyr 操作系统？（日文博客） =========================​ 我们目前无法 回复 此帖子“ 评论”部分的评论。 对于由此造成的不便，我们深表歉意。如有任何疑问， 请 参考“ 如何就 技术问题 联系 NXP （ 日语 博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有业务往来 ，您可以直接联系负责人。 ） 在本期 Zephyr 系列文章的第二篇“首次构建并在真机上运行”中，我们将介绍如何安装 Zephyr 开发环境并进行构建。之后，我们将把构建好的程序刷入真机并进行测试，确保其能够正常运行。 MCX SW | 下载 日本博客

Question about ENEDC(S32K3) Hello Team May I ask about ENEDC of K3? Customer uses MCAL with RTD.  However, I did not find the information of RTD about ENEDC. from MSCM, it is showing only ISR core assign configuration.  May I ask, how to enable ENEDC using RTD(MCAL)? Thank you.  Safety_SW Source: Direct Customer Source: NXP Internal Re: Question about ENEDC(S32K3) Thanks for your explanation! Re: Question about ENEDC(S32K3) Hi @Luke_Chun , as per my understanding from RM description, it is needed to enable these bits if you want to have report path form the gaskets to FCCU active. This is why sCheck is enabling these bits otherwise it would be not possible to test the report path. I have to agree that this is essential setup and maybe a lot of K3 customers are not even aware of this setup (just enabling related FCCU channel, but not these bits). Kind Regards, Radoslav Re: Question about ENEDC(S32K3) Hello @RadoslavB  Thanks for your explanation, but I’m not sure about the ENEDC’s proposal. Could you confirm my understanding?  Does ENEDC need to use only “TEST”? Or Is it need to enable for Safety application? (such as, if User wishes to use the check of eDMA Read, ENEDC’s bit2 will be “set” by manually with FCCU configuration.) Thank you.  Re: Question about ENEDC(S32K3) Hi @Luke_Chun , there is no request for configuring MSCM peripheral registers in SAF. The sCheck tests internally enables these registers when it is testing latent faults in associated EDC gaskets, but enabling those bits for application is not covered by any NXP SW. Therefore, customer shall enable these registers manually. For S32K5 there has been defined sBoot check for enablement these registers but again, AFAIK configuration is not in scope of any NXP SW. Kind Regards, Radoslav Re: Question about ENEDC(S32K3) Hi @Luke_Chun, I don't support issues related to Safety driver. To request support from them, you should remove "RTD" label and keep only "Safety_SW" label in your post. Or you can raise a new post only for Safety_SW. Best regards, Dan Re: Question about ENEDC(S32K3) Hi @DanNguyenDuy  Thanks for your update. I also checked Safety drive but I did not find which one is related with ENEDC... May I ask, how to check about it? Thank you. Re: Question about ENEDC(S32K3) Hi @Luke_Chun, RTD driver is not supported for configurating ENEDC. From my point of view, you should check this feature in modules of Safety driver because this register is related to FCCU. Best regards, Dan Re: Question about ENEDC(S32K3) Adding snippet from K3 HW Safety Manual: So right now it is up to customer to follow this AoU - configuration and check is not supported by NXP at the moment. Kind Regards, Radoslav Re: Question about ENEDC(S32K3) Hi @Luke_Chun , there is support for configuration of the INTM peripheral, you can find it in RTD Platform plugin - Interrupt Monitors. On SAF side, sCheck does have INTM latent faults test, but sBoot is not checking any INTM configuration register. In my opinion if Interrupt is as detection/reaction mechanism for safety related fault, then SM1.INT_MON must be active and customer shall fulfill SM4.INT_CHK, sBoot should double check such a configuration. Kind Regards, Radoslav Re: Question about ENEDC(S32K3) Hi @RadoslavB  may I ask one more question? How about the INTM_MM? Is this same with ENEDC? (RTD or SAF does not support for configuration INTM_MM enable. User has to do the configuration INTM_MM by user code.) Thank you.   

MMA9551 ファームウェアのアップグレードに失敗しました。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 私のボードには、mma9551 用のファームウェアがありません。これに基づいて、コマンドインタープリターを使用して、mma9551 に新しいバージョンをダウンロードします。フラッシュ保護解除モードに入った後、フラッシュを一括消去し、新しいバージョンでフラッシュを書き込みます。ただし、アップグレード プロセスは失敗します。書き込みフラッシュ応答エラー コードは 0xD0 です。リファレンスマニュアルを読んでみると、フラッシュにアクセスする権限がないことがわかりました。しかし、起動時にフラッシュ書き込みの失敗が発生しないのは非常に奇妙に思えます。いくつかのページの書き込みは成功しましたが、特定のページにアクセスする権限がないため、アップグレード プロセスが失敗しました。誰か何かアイデアを持っていますか? さらに奇妙なのは、ファームウェアを搭載した mma9551 を搭載したボードで新しいファームウェア バージョンをアップグレードする場合です。エラーもなく成功しました。 よろしくお願いします。 加速度センサ Re: MMA9551 upgrade firmware failed. <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、レスリー。 MMA9551L ボードに適切な FW がまだフラッシュされていないことに驚きました。詳細を教えていただけますか。このボードは公式デモキット KITMMA9551LEVM からのものですか、それともテープとリールからのデバイスが搭載されているものですか。デバイス パッケージ上の完全なマーキングとは何ですか? MMA955xL デバイスには、それぞれのデフォルトの FW と一部のキャリブレーション パラメータが当社の生産ラインでロードされており、さらに、対応するフラッシュ セグメントが保護されていることに注意してください。 したがって、お客様が NXP 独自の FW のロードを処理することは推奨されません。 デバイスが最初から機能していなかった場合、デバイスを交換して、デフォルトの FW が適切にロードされなかった理由を調査できます。 よろしく、ジャック。

KW45 FlexCAN 可以触发接收中断并接收自己发送的消息 我正在调试 KW45 芯片的 FlexCan 驱动程序，发现当未配置接收过滤器掩码时，FlexCan 模块可以触发信号自己的接收中断并接收自己发送的消息。这种行为正常吗？如果是，根本原因是什么？例如，修改 SDK 中的flexcan_interrupt_transfer代码，如附件所示。 uart log ： ********* FLEXCAN 中断示例 ********* 报文格式： 信息缓冲区 0 用于 Rx。 信息缓冲区 1 用于 Tx。 中断模式：启用 运行模式：TX 和 RX --> 正常 ********************************************* 请选择本地节点 A 或 B： 注：节点 B 应先启动。 节点：A 按任意键触发单发传输 Rx MB ID：0x321，Rx MB 数据：0x0，时间戳：60127 按任意键触发下一次传输！ Rx MB ID：0x321，Rx MB 数据：0x1，时间戳：3624 按任意键触发下一次传输！ Rx MB ID：0x321，Rx MB 数据：0x2，时间戳：18344 按任意键触发信号下一次传输！ Rx MB ID：0x321，Rx MB 数据：0x3，时间戳：56722 按任意键发送下一个触发信号！ Rx MB ID：0x321，Rx MB 数据：0x4，时间戳：55297 按任意键触发下一次传输！ Rx MB ID：0x321，Rx MB 数据：0x5，时间戳：53656 按任意键触发下一次传输！ Rx MB ID：0x321，Rx MB 数据：0x6，时间戳：30470 按任意键触发下一次传输！ Rx MB ID：0x321，Rx MB 数据：0x7，时间戳：22438 按任意键触发下一次传输！ Rx MB ID：0x321，Rx MB 数据：0x8，时间戳：1009 按任意键触发下一次传输！ Re: The KW45 FlexCAN can trigger a receive interrupt and receive the messages sent by itself 你好，我已经解决了问题，需要设置：   flexcanConfig.disableSelfReception = TRUE；

RT1021 input max current Hello, do you know how much current a GPIO input can handle? I'm using GPIO_AD_B1_02 and 8mA are flowing through that pin. What is the maximum current an input can handle before damaging the pin? The pin is on it's default values, if I understood right it is configured as input with 100k pulldown resistor by default Thank you Re: RT1021 input max current Hi @jtrujillo, In general, the maximum current for any RT1xxx GPIO pin should be limited to 25mA whether it is sourcing or sinking current. This is the safe limit for the technology to prevent reliability issues, like latent damage due to electromigration, and can be sustained for long durations if the pin needs to. BR, Edwin.

Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Running MCUXpresso IDE V25.6.136 + evkmimxrt685 board with SDK_25_12_00. When debug starts all debug tool (resume ..) are greyed out and cannot run the project.  Works fine with older SDK_25_03_00 but same problem with SDK_25_06_00 and SDK_25_09_00.  How can i restore the debug tools Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hello Carlos, Posting the screenshot> It happens on all the examples including hello world. It always stops at the first line of the "void ResetISR(void) function i.e. at the line __asm volatile ("cpsid i") (line No 381) in the startup_mimxrt685s.c file in the startup directory. It never get to the main() to start the run.  I am trying to run the evkmimxrt685_dsp_mu_polling_cm33. This example works fine in the 25.03 version. All versions after than (06,09,12) have this problem. Is there some change I should make in the IDE for SDK versions after 24.03 ?.   Thanks  bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hello Carlos, It happens on all the examples including hello world. It always stops at the first line of the "void ResetISR(void) function i.e. at the line __asm volatile ("cpsid i") (line No 381) in the startup_mimxrt685s.c file in the startup directory. I am trying to run the evkmimxrt685_dsp_mu_polling_cm33. This example works fine in the 25.03 version. All versions after than (06,09,12) have this problem. Is there some change I should make in the IDE for SDK versions after 24.03 ?. I do have a screenshot but how do i post it. Thanks @bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hi @bobvr  Could you please share which OS your compute has? Linux, Windows 10, Windows 11? Could you please review the BOOT_SEL of the EVK to be properly selected? Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hi @bobvr  Thanks for sharing the details about your setup. Could you please do a mass erase of the flash, and retry to debug it?  To do it please change the link server action at the QuickStart Panel after that return it to Debug using LinkServer probes. Please share a screenshot if you have any error message in the process.  Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 I am running Windows 11 on a Dell Alder Lake desktop. The boot jumper (JP1) is open which is the default according to the manual (MIMXRT685-AUD-EVKUM Rev 3 - 21 July 2023). I presume this is what you meant by "review BOOT_SEL of the EVK". Thanks bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Carlos, Thanks. Before I do this i wanted to let you know that I have always used the SEGGER J-Link probes and there is "erase flash action using SEGGER J-Link probes" menu option. Should i erase using that or using the link server probes as you mentioned above. Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Carlos,  I tried to do a mass erase with the link server but got an error message - screenshot attached.  Thanks  Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hello Carlos,  I deleted the Flash using the Segger J-Link Probes (not the link server probes as that firmware was overwritten by the Segger firmware).  I understand I must use the Segger probes to debug both the ARM core and HiFi4 DSP.  I also updated the Segger firmware to the latest version 8.98.  I deleted the debug launch file,  deleted the workspace to generate a new one on bootup and also power cycled the board.  Still the same problem.  It says a debug session is running but I'm not able to debug.  As i said this happens with all versions after 03 (06, 09 and 12).  It stops at the startup_mimxrt685s.c file as before.    In the debugger console I do see a warning  message but this is probably harmless.  "warning: could not convert 'main' from the host encoding (CP1252) to UTF-32. This normally should not happen, please file a bug report. monitor exec SetRestartOnClose=1 Please advise next steps. Thanks bobvr. Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 Hi @bobvr  Thanks for sharing that you are using. The issue persists if you try to debug with link server? Please share the error message in case you get one. 

install and updating the SDK for the S32K144 MCU I have installed the S32 Design Studio to create project from the SDK example for the S32K144 MCU i am not able to found the SDK folder to configure the example project i have installed the SDK for the S32 K144 Device below i have share my problem regarding images please refer  thank you in advance  Re: install and updating the SDK for the S32K144 MCU Hi Please install the other two packages, then you will find the S32K1 RTD. I remember that previously, I only needed to select one of them, and the S32K1 RTD-related dependency packages would be installed automatically. Please note that during the Christmas holiday period, our support response times may be longer than usual. In some cases, your request might be addressed after the New Year. Thank you for your understanding. Best Regards, Robin ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

i.MX 93プロセッサ: セキュアブートの署名と認証の仕組みを解説 (日本語ブログ) 昨今、サイバーレジリエンス法(EU)やJC-STAR(日本)等、世界各国で法規制が確立しつつあります。またそれらの技術要件の中には、セキュアブートの要件も入ってきており、みなさまもよく耳にする重要な機能の一つかと思います。 しかしながら、実際にはセキュアブートの仕組みを理解せず使用してるユーザーも多いです。そのため、今回はi.MX 93のセキュアブート(AHAB)を例に仕組みを解説していきたいと思います。 目次 i.MX 93 AHABの署名と認証の仕組み 1. イメージのコンテナ化 2. コンテナに公開鍵と署名を付加 3. 署名付きコンテナの認証 4. U-Bootでの署名付きコンテナの認証 i.MX 93 AHABの署名と認証の仕組み¶ i.MX 93プロセッサのAdvanced High Assurance Boot (AHAB)の署名と認証の仕組みを説明します。 i.MX 93の起動ファイルは固有のコンテナ形式になっています。 AHABを使用したセキュアブートでは、コンテナに公開鍵と署名を付加し、デバイス起動時にはコンテナに含まれている公開鍵を認証し、コンテナの内容が改変されていないか検証することで、不正なソフトウェアの起動を防ぐことができます。 1. イメージのコンテナ化¶ Fig. 1 イメージのコンテナ化¶ i.MX 93のBOOTROMやU-Bootがメモリにロードして使用するイメージは、あらかじめコンテナ形式に変換しておく必要があります。 Note ここでイメージと言っているのは、U-Boot-SPL, U-Boot, ATF, OPTEE, M-Core SW, Kernel, DTB, Ramdisk, その他メモリ上に配置したいデータ等のことです。 コンテナ形式の詳細は i.MX 93 Applications Processor Reference Manual のSystem Bootの章にに記載があります。 イメージをコンテナ化するには、 imx-mkimage と、それに含まれる mkimage_imx8 というツールを使用します。 コンテナを生成すると、コンテナファイルの先頭にはContainer Headerが付加されます。この中には各イメージのオフセット、サイズ、ハッシュ値などを集めたImageArray、セキュアブートのため公開鍵、署名を書き込むSignature Blockなどがあります。Signature Blockは、ほぼ空の状態で生成されます。 複数のイメージを一つのコンテナにすることができます。イメージのデータはコンテナファイルの一番後ろに連結されます。 2. コンテナに公開鍵と署名を付加¶ Fig. 2 コンテナに公開鍵と署名を付加¶ i.MX 93デバイスで意図しないコンテナを使用されないよう、また、コンテナの内容の改変を検知できるよう、Code Signing Tool（以下、CST）を使用して、コンテナに公開鍵と署名を付加します。 最初にSuper Root Key (以下、SRK)を生成します。 CSTに含まれるスクリプト ahab_pki_tree.sh でCAとSRK1～SRK4を生成します。SRKは公開鍵とプライベート鍵のペアとなっていて、プライベート鍵は秘匿しておく必要があります。 CSTに含まれる srktool を使用して、SRK1～SRK4の4つの公開鍵を連結したSRK Tableを生成します。同時にSRK TableのSHA-256であるSRK Hashも生成されます。 SRK Hashは、i.MX 93デバイスのSRK_HASHヒューズに書き込みます。 SRKはi.MX 93デバイスのライフサイクルが終了するまで長期にわたり保存しておく必要があります。 次に、CSTに含まれる cst でコンテナに公開鍵と署名を付加します。 先ほど生成したSRK Tableは、Signature BlockのSRK Tableフィールドに書き込まれます。 Container Headerの先頭からSRK Tableフィールドの末尾の領域に対して、SRKのプライベート鍵の一つを使用して署名されます。 署名データは、Signature BlockのSignatureフィールドに書き込まれます。 3. 署名付きコンテナの認証¶ Fig. 3 署名付きコンテナの認証¶ 最初に、コンテナ上のSRK TableのSHA-256を計算して、i.MX 93デバイスのSRK_HASHヒューズの内容が一致していれば、SRK Tableは署名に使用したSRKと同じ、ということを認証できます。 SRK Tableが認証されれば、次に、SRK Tableの中に含まれるSRK公開鍵と署名データを使用して、Container Headerの先頭からSRK Tableフィールドの末尾の領域が改変されていないかを検証できます。 最後に、Container Headerが改変されていないことが検証できれば、ImageArrayに書かれているHash値と各ImageのHash値を比較することで、イメージが改変されていないかを検証できます。 4. U-Bootでの署名付きコンテナの認証¶ U-Bootでの署名付きコンテナの認証には、U-Bootの auth_cntr コマンドが使用されています。 https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L811-L815 auth_cntr コマンドが実行されると、do_authenticate関数がコールされ、そこからauthenticate_os_container関数がコールされます。 https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L400-L416 authenticate_os_container関数から、ahab_auth_cntr_hdr関数とahab_verify_cntr_image関数がコールされます。 https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L330-L398 ahab_auth_cntr_hdr関数からは、ele_auth_oem_ctnr関数がコールされます。 ahab_verify_cntr_image関数からは、ele_verify_image関数がコールされます。 https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L261-L278 https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/arch/arm/mach-imx/ele_ahab.c#L297-L309 ele_auth_oem_ctnr関数とele_verify_image関数からは、ELEに対してコマンドが送信され、ELEから結果を受信します。 https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/drivers/misc/imx_ele/ele_api.c#L76-L104 https://github.com/nxp-imx/uboot-imx/blob/lf-6.6.36-2.1.0/drivers/misc/imx_ele/ele_api.c#L134-L161 U-Bootの ahab_status コマンドで認証の結果を確認することができます。主要なエラーコードは以下のとおりです。 Table 1 ahab_status コマンドの主要なエラーコード¶ エラーコード エラーの意味 エラーが発生する状況 ELE_NO_AUTHENTICATION_FAILURE_IND (0xEE) 認証は行われなかった。 署名していないコンテナを認証しようとした。 ELE_BAD_KEY_HASH_FAILURE_IND (0xFA) ヒューズSRK_HASHと、署名付きコンテナのSRK TableのHASHがが一致しない。 ・ヒューズSRK_HASHに何も書かれていないデバイスで署名付きコンテナを認証しようとした。 ・ヒューズSRK_HASH生成時に使用したSRK Tableには含まれないSRKで署名したコンテナを認証しようとした。 ・署名付きコンテナのSRK Tableが書き換えられている。 ・署名付きコンテナのSRK Tableが正しくロードできなかった。（メモリ上に正しく書かれていない。） ELE_BAD_SIGNATURE_FAILURE_IND (0xF0) 署名が正しくない。 ・署名付きコンテナのSigned regionが書き換えられている。 ・署名付きコンテナのSignatureが書き換えられている。 ・上記のいずれかが正しくロードできなかった。（メモリ上に正しく書かれていない。） ELE_BAD_HASH_FAILURE_IND (0xF1) ImageのHASHが、Image Arrayに書かれているHASHと異なる。 ・署名付きコンテナのImageが書き換えられている。 ・署名付きコンテナのImageが正しくロードできなかった。（メモリ上に正しく書かれていない。）   Note これらのエラーコードはOEM Openの場合に観測できます。OEM Closedの場合はエラー発生時にデバイスが停止するためエラーコードは表示されません。 本資料はNXP製品を活用していただくための参考資料です。 正式な仕様は製品マニュアル・アプリケーションノートを参照ください。 使用ソフトウェアのバージョンなど諸条件の差異により、記載内容と実際の動作が異なる場合があります。 すべての機能検証を行ったものではありませんので、必ずご使用目的に適合した検証・試験を行ってください。 次回は、セキュアブート(AHAB)の実装・動作方法について、説明したいと思います。 　記事：i.MX 93プロセッサ: セキュアブートの実装方法 - 実践編 (日本語ブログ)   =========================​ 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。​ お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。​ （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。）​ 昨今、サイバーレジリエンス法(EU)やJC-STAR(日本)等、世界各国で法規制が確立しつつあります。またそれらの技術要件の中には、セキュアブートの要件も入ってきており、みなさまもよく耳にする重要な機能の一つかと思います。 しかしながら、実際にはセキュアブートの仕組みを理解せず使用してるユーザーも多いです。そのため、今回はi.MX 93のセキュアブート(AHAB)を例に仕組みを解説していきたいと思います。 i.MX Processors Security 日本語ブログ

嵌入式系统开发的最佳 DevOps 实践 大家好 我想讨论在嵌入式系统开发中实施 DevOps 的最佳实践。我们都知道，嵌入式系统面临着独特的挑战，但结合 DevOps 原则并利用正确的 DevOps 解决方案可以大大改善我们的工作流程。 以下是我发现的一些有用的做法： 自动版本构建和 CI/CD 设置自动构建管道对于嵌入式系统至关重要。借助 CI/CD，我们可以自动测试、刷新和部署到真实设备，从而确保尽早发现错误。 固件和硬件的版本控制 将固件视为软件 — 使用 Git 或类似工具进行版本控制，以及硬件抽象层 (HAL)，有助于同步管理软件和硬件依赖关系。 硬件在环 (HIL) 的持续集成 将 HIL 测试内置到您的 CI 管道中可确保您针对真实场景进行验证，而不仅仅是模拟环境。这有助于发现只有在实际硬件中才会出现的问题。 嵌入式软件的容器化 使用 容器 或类似工具进行软件环境复制可确保开发、测试和部署阶段的一致性，即使在使用嵌入式平台时也是如此。 我很想听听您的想法和其他有效的做法。您如何将 DevOps 内置到嵌入式开发工作流程中？ DSC Re: Best DevOps Practices for Embedded Systems Development 我们正在努力做你所建议的事情。您有什么具体的建议吗？