Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
调试工具在使用最新版 SDK_25_12_00 时显示为灰色,在使用旧版 SDK_25_03_00 时工作正常 运行 MCUXpresso IDE V25.6.136 版+ 带有 SDK_25_12_00 的 evkmimxrt685 板。调试开始时,所有调试工具(恢复...)都显示为灰色,无法运行项目。 使用旧版 SDK_25_03_00 可以正常工作,但使用 SDK_25_06_00 和 SDK_25_09_00 会出现同样的问题。 如何恢复调试工具 Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 你好,卡洛斯,包括 hello world 在内的所有示例都出现了这种情况。它总是停在"void ResetISR(void) 函数的第一行,即 startup_mimxrt685s.c 中的 __asm volatile ("cpsid i") 行(第 381 行)。文件。我正在尝试运行 evkmimxrt685_dsp_mu_polling_cm33。该示例在 25.03 版本中运行正常。之后的所有版本(06、09、12)都有这个问题。对于 24.03 之后的 SDK 版本,我是否需要在集成开发环境中进行一些更改?我有截图,但如何发布呢?谢谢@bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 你好,卡洛斯,我正在上传截图> 包括 hello world 在内的所有示例都出现了这种情况。它总是停在"void ResetISR(void) 函数的第一行,即启动目录下 startup_mimxrt685s.c 文件中的 __asm volatile ("cpsid i") 行(第 381 行)。它从未进入 main() 开始运行。 我试图运行 evkmimxrt685_dsp_mu_polling_ cm33。cm33。该示例在 25.03 版本中运行正常。之后的所有版本(06、09、12)都有这个问题。对于 24.03 之后的 SDK 版本,我是否需要在集成开发环境中做一些更改? 谢谢 bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 你好@bobvr 能否请您介绍一下您的计算机使用的是哪个操作系统?Linux、Windows 10 还是 Windows 11? 能否请您检查一下 EVK 的 BOOT_SEL 是否选择正确? Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 我正在戴尔 Alder Lake 台式机上运行 Windows 11。启动跳线 (JP1) 处于打开状态,根据手册(MIMXRT685-AUD-EVKUM 修订版 3-2023 年 7 月 21 日),这是默认设置。我想这就是您所说的"查看 EVK" 的 BOOT_SEL 的意思。谢谢 bobvr Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 你好@bobvr 感谢您分享您的设置细节。 能否请您对闪存进行一次大规模擦除,然后重新进行调试? 为此,请在快速启动面板上更改链接服务器操作 然后使用 LinkServer 探测器将其返回到调试模式。 如果在此过程中出现任何错误信息,请分享截图。 Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 卡洛斯,我试图用链接服务器进行大规模清除,但得到了错误信息--截图附后。 谢谢 Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 卡洛斯,谢谢。在此之前,我想让您知道,我一直使用世纪佳缘 J-Link 探头,使用世纪佳缘 J-Link 探头" 菜单选项可进行"清除闪存操作。我应该用它清除还是用你上面提到的链接服务器探针清除? Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 你好,卡洛斯,我使用 Segger J-Link 探头(不是链接服务器探头,因为该固件已被 Segger 固件覆盖)删除了闪存。 我知道我必须使用 Segger 探针来调试 ARM 内核和 HiFi4 DSP。我还将 Segger 固件更新到了最新的 8.98 版本。 我删除了调试启动文件,删除了工作区以在启动时生成一个新文件,还重新启动了板。还是同样的问题。 它说调试会话正在运行,但我无法调试。 正如我所说,03 之后的所有版本(06、09 和 12)都会出现这种情况。 它停在 startup_mimxrt685s.c 处文件。 在调试器控制台中,我确实看到了一条警告信息,但这可能是无害的。 "警告:无法将 "main "从主机编码 (CP1252) 转换为 UTF-32。 这种情况通常不会发生,请提交错误报告。 监测执行器 setrestartonClose=1 请告知下一步措施。谢谢 bobvr。 Re: Debug tools greyed out with latest SDK_25_12_00, work fine with older SDK_25_03_00 你好@bobvr 感谢您分享您正在使用的产品。 如果尝试使用链接服务器调试,问题是否仍然存在?如果您收到错误信息,请与我们分享。
查看全文
S32K344 是否支持用于铁路应用的 EN 50128 / SIL 3/4? 您好, 我正在评估铁路功能安全项目的 S32K344(双核)。我需要知道这种 MCU 是否可用于需要..: EN 50128(铁路软件功能安全标准) SIL 3/SIL 4 功能安全等级 另外: 恩智浦是否有支持 SIL 3/4 设计的指南或文档? 对于在关键任务和非关键任务中安全使用双核有什么建议? 提前感谢! Re: S32K344 will support EN 50128 / SIL 3/4 for railway applications? 请注意,在圣诞假期期间,我们的支持响应时间可能会比平时长。在某些情况下,您的请求可能会在新年后得到处理。感谢您的理解。 Re: S32K344 will support EN 50128 / SIL 3/4 for railway applications? 你好@Yuvashree S32K344 根据 ISO 26262 开发,支持 ASIL D,在功能安全完整性方面,ASIL D 与 SIL 3 大致相当。不过,恩智浦并未提供符合 EN 50128 或 SIL 4 标准的认证或声明。如果您的项目需要 EN 50128,则需要使用可用的功能安全文档(功能安全手册、FMEDA 等)自行进行功能安全评估和流程调整。 此致, Lukas
查看全文
S32K5 SAF 版本时间表 嗨,团队、 客户 PATAC 正在评估我们的 S32K5 SAF。他们知道,目前的 S32K5 SAF 只能提供非常有限的功能,无法满足他们的实际使用要求。因此,他们要求我们提供 S32K5 SAF 的详细时间表。 大概的版本发布时间。 下一个版本将支持哪些功能和模块? 谢谢& ,致以最崇高的敬意、 理查德 优先级:中等 SAFETY_SW 资料来源直接客户 Re: S32K5 SAF release schedule 你好@RaduBraga、 是否有任何更新? BR 理查德 Re: S32K5 SAF release schedule 嗨 @RichardLi,计划 在 2026 年 7 月版本 K5 PRC,我们的目标是涵盖所有 SAF 模块的全部功能。 亲切的问候, Radoslav Re: S32K5 SAF release schedule 嗨 @RichardLi, 我们今年 1 月没有任何 EAR 版本。 EAR 0.8.0 已于 2025 年 12 月发布,功能非常有限,直到 7 月 26 日 PRC 才有其他计划。 亲切的问候, Radoslav Re: S32K5 SAF release schedule 你好@RadoslavB、 感谢您的反馈。计划于今年1月底发布的SAF EAR版本有任何范围吗?它能涵盖大部分功能吗? BR 理查德
查看全文
嵌入式系统开发的最佳 DevOps 实践 大家好 我想讨论在嵌入式系统开发中实施 DevOps 的最佳实践。我们都知道,嵌入式系统面临着独特的挑战,但结合 DevOps 原则并利用正确的 DevOps 解决方案可以大大改善我们的工作流程。 以下是我发现的一些有用的做法: 自动版本构建和 CI/CD 设置自动构建管道对于嵌入式系统至关重要。借助 CI/CD,我们可以自动测试、刷新和部署到真实设备,从而确保尽早发现错误。 固件和硬件的版本控制 将固件视为软件 — 使用 Git 或类似工具进行版本控制,以及硬件抽象层 (HAL),有助于同步管理软件和硬件依赖关系。 硬件在环 (HIL) 的持续集成 将 HIL 测试内置到您的 CI 管道中可确保您针对真实场景进行验证,而不仅仅是模拟环境。这有助于发现只有在实际硬件中才会出现的问题。 嵌入式软件的容器化 使用 容器 或类似工具进行软件环境复制可确保开发、测试和部署阶段的一致性,即使在使用嵌入式平台时也是如此。 我很想听听您的想法和其他有效的做法。您如何将 DevOps 内置到嵌入式开发工作流程中? DSC Re: Best DevOps Practices for Embedded Systems Development 我们正在努力做你所建议的事情。您有什么具体的建议吗?
查看全文
S32K 输入捕获 嗨,团队、 我们使用的是 S32K146 微控制器,我们需要任何一个输入引脚作为输入捕获引脚,你能建议我应该使用哪个模块配置吗? 如果我使用 FTM 作为信号测量,我能否实现输入捕获功能?或者我应该使用 ic_pal 功能? 请支持 谢谢 Shruthi C Re: S32K Input Capture 你好,彼得、 我无法使用 INT_SYS_InstallHandler(FTM0_Ch0_Ch1_IRQn,PWM_InputCapture_IRQHandler,NULL);函数,因为它使用默认处理程序,而不使用FTM0_Ch0_Ch1_IRQn处理程序。 我的配置是 /* flexTimer_ic_1 InitConfig 的全局配置 */ ftm_user_config_t flexTimer_ic_1_InitConfig = {     { true,/* 软件触发信号状态 */ false,/* 硬件触发信号 1 状态 */ false,/* 硬件触发信号 2 状态 */ false,/* 硬件触发信号 3 状态 */ 虚假,/* 最大加载点状态 */ 虚假,/* 最小装载点状态 */ ftm_system_clock、/* INVCTRL 寄存器的更新模式 */ ftm_system_clock、/* SWOCTRL 寄存器的更新模式 */ ftm_system_clock、/* OUTMASK 寄存器的更新模式 */ ftm_system_clock、/* CNTIN 寄存器的更新模式 */ false,/* 自动清除触发信号 */ ftm_update_now、/* 同步点 */ }, ftm_mode_input_capture、/* FTM 的运行模式 */ ftm_clock_divid_by_1、/* FTM 时钟预分频器 */ ftm_clock_source_systemclk、 /* FTM 时钟源 */ ftm_bdm_mode_11、/* FTM 调试模式 */ 虚假, /* 中断状态 */ false /* 初始化触发信号 */ }; /* FlexTimer_IC_1 的输入捕获配置 */ ftm_input_param_t flexTimer_ic_1_InputCaptureConfig = { 1U,/* 通道配置数量 */ 65535U,/* 最大计数值 */ flexTimer_ic_1_InputCaptureChannelConfig/* 通道配置*/ }; /* FlexTimer_IC_1 输入捕获的信道配置结构 */ ftm_input_ch_param_t flexTimer_ic_1_InputCaptureChannelConfig[1] = {     { 0U,/* 通道 ID */ FTM_SIGNAL_MEASUREMENT,/* 输入捕获操作模式 */ ftm_rising_edge、/* 边缘对齐模式 */ ftm_falling_edge_period_measurement、/* 信号测量操作类型 */ 0U,/* 过滤器值 */ 虚假,/* 过滤器状态(启用/禁用) */ true,/* 连续测量状态 */ NULL,/* 通道事件的回调参数向量 */ NULL/* 通道事件的回调向量 */    } }; Re: S32K Input Capture 您好, 是的,这些功能应该足够了。SDK 驱动程序启用了 FTM 通道中断,我认为正确的处理程序应从启动时分配。如果不是正确的处理程序,则为 FTM0_Ch0_Ch1_IRQHandler。 调用 ftm_drv_getInputCaptureMeasuremeasum 以获取捕获的值。 BR, Petr Re: S32K Input Capture 你好,彼得、   感谢您的明确说明。   我可以使用这些函数将 FTM 引脚初始化为输入捕获 `ftm_drv_init () ``ftm_drv_init_initCapture () `ftm_drv_initInputCapture ()`   并安装一个 IRQ 处理器来捕获脉冲发生情况 `INT_SYS_InstallHandler(FTM0_Ch0_Ch1_IRQn, PWM_InputCapture_IRQHandler, NULL)`     请支持   谢谢 Shruthi C Re: S32K Input Capture 您好, 最常见和最有效的方法是在输入捕获模式下配置 FTM 并使用具有 FTM 功能的引脚。每个 FTM 通道均可配置为输入捕获模式,在该模式下,它捕获输入信号边缘(上升、下降或两者兼有)上的计时器值。这通常用于测量:信号周期、脉冲宽度、频率。 IC PAL 驱动器允许检测输入信号并测量通道输入信号的脉冲宽度或周期。其设计目的是使其可移植到支持 FTM、eMIOS、FLEXPWM 和 ETIMER 的所有平台和 IP 上。 因此,如果您想获得全面的控制和性能,请直接使用 FTM。如果您希望代码更简单、更便于携带,请使用 IC PAL。 BR, Petr Re: S32K Input Capture 您好, 您可以直接参考 SDK 示例 (ftm_signal_measurement)。 或共享显示该问题的简化项目。 BR, Petr Re: S32K Input Capture 您好, 在 SDK 示例中,我直接提到(ftm_signal_measurement)。 在这个例子中,他们没有使用中断方法,他们使用了轮询方法,然后他们调用了 ftm_drv_g etInputCap t ureMeasuremeasum 我正在寻找带中断功能的 FTM 信号测量,一旦输入捕获识别出信号,我需要中断才能触发并调用 ISR 中的 ftm_dr v_getInputCaptureMeasuremeasurem ensum 函数 请提供相关代码 谢谢 Shruthi C Re: S32K Input Capture 您好, 如果您需要再次安装处理程序,您应该有 extern void FTM0_Ch0_Ch1_IRQHandler(void); INT_SYS_InstallHandler(FTM0_Ch0_Ch1_IRQn, FTM0_Ch0_Ch1_IRQHandler, NULL); BR, Petr Re: S32K Input Capture 你好, 是的,我确实定义了该函数,但函数调用后会进入无限循环,并继续运行 整个系统将无法运行, 谢谢 Shruthi C Re: S32K Input Capture 你好、 感谢您的支持和代码片段,我将进行检查 T&R、 Shruthi C Re: S32K Input Capture 你好,我 能否获得任何支持中断的 FTM 引脚的输入作为输入捕获 谢谢! Shruthi C Re: S32K Input Capture 您好, 驱动程序使用中断来捕获事件,只是没有直接显示在示例中。 我修改了 FTM IC 设置,使其使用单发模式,并添加了从驱动程序中断调用的回调。 ftm_signal_measurement_s32k146 演示修改后的 main.c 参见附件。 BR, Petr
查看全文
i.MX 8M Plus EVK で M7 の QSPI を使用する方法 皆さん、こんにちは i.MX 8M Plus EVKをQSPI NORで使い始めるのに苦労しています。 「uuu -b qspi firmware.bin」を使用して8M Miniをフラッシュする方法の説明を見つけました。しかし、これはうまくいかないようです 私のEVKには、NORフラッシュにロードされたブートイメージが付属しているようです。 u-boot=> sf probe SF: Detected n25q256ax1 with page size 256 Bytes, erase size 4 KiB, total 32 MiB u-boot=> sf read $loadaddr 0 0x100 device 0 offset 0x0, size 0x100 SF: 256 bytes @ 0x0 Read: OK u-boot=> md $loadaddr 40400000: 412000d1 007e1000 0005fc00 00000000 .. A..~......... 40400010: 007e0fe0 007e0fc0 0080b7c0 00000000 ..~...~......... 40400020: 007e0bc0 0002cc00 00000000 00000000 ..~............. 40400030: 00000000 00000000 00000000 00000000 ................ 40400040: 1400000a d503201f 40200000 00000000 ..... .... @.... QSPIのコードを使用してM7をフラッシュして起動する方法に関するアプリノートはありますか? Re:i.MX 8M Plus EVKでM7のQSPIを使用する方法 オフセット0にflash_debug/hello_world.binでフラッシュをプログラムしました。 u-boot=> load mmc 1 $loadaddr hello_world.bin 18664 bytes read in 4 ms (4.4 MiB/s) u-boot=> sf probe SF: Detected n25q256ax1 with page size 256 Bytes, erase size 4 KiB, total 32 MiB u-boot=> sf erase 0 0x5000 SF: 20480 bytes @ 0x0 Erased: OK u-boot=> sf write $loadaddr 0 $filesize device 0 offset 0x0, size 0x48e8 SF: 18664 bytes @ 0x0 Written: OK Re:i.MX 8M Plus EVKでM7のQSPIを使用する方法 私はそれを理解しました... .binのプログラミング後ファイルをフラッシュに送り、U-Boot で次のコマンドを発行すると、M7 hello_world アプリを実行できます。 u-boot=> sf probe SF: Detected n25q256ax1 with page size 256 Bytes, erase size 4 KiB, total 32 MiB u-boot=> bootaux 0x08000000 ## No elf image at address 0x08000000 ## Starting auxiliary core stack = 0x20020000, pc = 0x0800048D... そして、UART4 (/dev/ttyUSB3) に "hello world." と表示されます。
查看全文
How to Connect the OV7673 Camera Module to the LPCXpresso55S69 Development Board? Hi I am currently in the process of learning to use the LPCXpresso55S69 development board in conjunction with the OV7673 camera module. However, I have found that I cannot find the corresponding pins. According to the documentation in the application note AN12868 from NXP (https://www.nxp.com/docs/en/application-note/AN12868.pdf) and the open-source code on GitHub (https://github.com/nxp-appcodehub/dm-lpc55s69-multi-face-detection), OV7673 D0~D7 need to be connected to P0.0~P0.7, but I found that the P0.0~P0.6 interfaces on the development board are very scattered, such as P0.0 at P19[6], P0.6 at P20[7], but P0.7 is not found, it seems P0.7 is connected to U20[4]/SD0_CLK. In addition, the D0~D7 wire connections in the official documentation image seem to be continuous. If anybody could help me make better decisions it would be highly appreciated.  Regards Mariposa Marina Re: How to Connect the OV7673 Camera Module to the LPCXpresso55S69 Development Board? Hi, @Alice_Yang  Thank you very much for your response. Certainly, changing the pin configuration didn't work. I will try other methods. Regards Mariposa Marina Re: How to Connect the OV7673 Camera Module to the LPCXpresso55S69 Development Board? Hello @Mariposa_Marina  Thank you for your detailed reply. We do not recommend changing the pins. And if you just change the pins configuration like the code above, the application will not work well. So please do not change the pins. Thanks. Best Regards, Alice Re: How to Connect the OV7673 Camera Module to the LPCXpresso55S69 Development Board? Hi, @Alice_Yang  Thank you very much for your response. I have an additional inquiry: Is it feasible to successfully run the application on the LPCXpresso55S69-EVK demo board by altering the pin connections for the OV7670 camera module? For instance, can I modify the camera_pin_Init function within the driver, specifically the IOCON->PIO settings, to change the default pins PIO0_0 to PIO0_7 to alternative pins? I am uncertain about the viability of this approach. void camera_pin_Init(void){ /* Connect trigger sources to camera engine */ INPUTMUX_Init(INPUTMUX); INPUTMUX->CAMERA_ENGINE_INPUTMUX[0] = 13; // set p0_13 as VSYNC input function pin, every edge will be responded INPUTMUX->CAMERA_ENGINE_INPUTMUX[1] = 14; // set p0_14 as HSYNC input function pin, every edge will be responded INPUTMUX->CAMERA_ENGINE_INPUTMUX[2] = 15; // set p0_15 as pixel input function pin, every edge will be responded /* Turnoff clock to inputmux to save power. Clock is only needed to make changes */ INPUTMUX_Deinit(INPUTMUX); // configure camera interface pins IOCON->PIO[0][0] = PINFUNC_CAMERA | 1<<8|1<<10|2<<4| 1<<6; //set p0_0 D0 on the camera port IOCON->PIO[0][1] = PINFUNC_CAMERA | 1<<8|2<<4| 1<<6; //set p0_1 D1 on the camera port IOCON->PIO[0][2] = PINFUNC_CAMERA | 1<<8|2<<4| 1<<6; //set p0_2 D2 on the camera port IOCON->PIO[0][3] = PINFUNC_CAMERA | 1<<8|1<<6; //set p0_3 D3 on the camera port IOCON->PIO[0][4] = PINFUNC_CAMERA | 1<<8|1<<6; //set p0_4 D4 on the camera port IOCON->PIO[0][5] = PINFUNC_CAMERA | 1<<8|2<<4|1<<6; //set p0_5 D5 on the camera port IOCON->PIO[0][6] = PINFUNC_CAMERA | 1<<8; //set p0_6 D6 on the camera port IOCON->PIO[0][7] = PINFUNC_CAMERA | 1<<8; //set p0_7 D7 on the camera port IOCON->PIO[0][18] = PINFUNC_CAMERA | 1<<8| 1<<10; //P0_18 will toggle when camera engine receive every VSYNC dege IOCON->PIO[0][14] = PINFUNC_CAMERA | 1<<8| 1<<10; //P0_14 will toggle when camera engine receive every VSYNC dege } Regards Mariposa Marina Re: How to Connect the OV7673 Camera Module to the LPCXpresso55S69 Development Board? Hello @Mariposa_Marina  Thanks for your interest in NXP Semiconductors products. The LPCXpresso55s69 - evk is just a demo board, not specifically developed for this application. So the used pins are not concentrated. You can place them as you design your hardware. For this demo board, the PIO0_7 is connected to R107 - 1 as below. BR Alice
查看全文
Lear - S32k344 - Mismatch btw. Crypto upper and lower driver Hello Team, I have received the following from Lear: ------------------------------------------------------------------------------------ there is a small problem in the service of “HSE AEAD Service” . I am trying the encrypt in GCM mode : In the Crypto driver the secondary input is a must and is checked against in the Crypto_ProcessJob method (see below array used in Crypto_GetJobErrorForSecondaryInputPtr method) : But in the HSE FW manual the AAD is optional : When I call this : Csm_AEADEncrypt(CsmConf_CsmJob_CsmJob_AES128_ENC_SECCNT_TMP,CRYPTO_OPERATIONMODE_SINGLECALL,&TempPlainTxt[0],16u,NULL_PTR,0u,&TempCipherSecCnt[0],&TagLenPtr,&TempTagSecCnt[0],&TagLenPtr); I get an error that the 2 nd input is a NULL (inside the Crypto_ProcessJob method ..) Can you please check , what to do event if the AAD is optional and not used ? -------------------------------------------------------------------------- BR Stefano Board: S32K344 Component: HSE FW Priority: HIGH SECURITY_CRYPTO Type: ISSUE Re: Lear - S32k344 - Mismatch btw. Crypto upper and lower driver According to AUTOSAR specifications, AEADENCRYPT and AEADDECRYPT require SecondaryInputPointer and SecondaryLength. Under HSE firmware, these parameters may be ignored later depending on its processing logic. Re: Lear - S32k344 - Mismatch btw. Crypto upper and lower driver @MarianVilau  @StefanoGattazzo  As discussed with Marian, I moved this ticket to https://jira.sw.nxp.com/browse/CESSCEP-23 to support from our project I will update the feedback on this community soon Re: Lear - S32k344 - Mismatch btw. Crypto upper and lower driver Hi @StefanoGattazzo , This ticket is more related to Cuong side. He will help you with this. Thanks, Marian Vilau Re: Lear - S32k344 - Mismatch btw. Crypto upper and lower driver Hello, https://jira.sw.nxp.com/browse/FWCRYPTO-198 BR, Marian Re: Lear - S32k344 - Mismatch btw. Crypto upper and lower driver Hi MarianVilau, Pls. let me have the ticket number. BR Stefano Re: Lear - S32k344 - Mismatch btw. Crypto upper and lower driver Hi @StefanoGattazzo , I created a ticket in the FW Crypto Jira project. BR, Marian Vilau Re: Lear - S32k344 - Mismatch btw. Crypto upper and lower driver Hi MarianVilau, what I know, as this is an issue from Lear,  is : JLR ePDU , S32K344 (A/B SWAP HSE FW 0.2.55) I know also they temporary solve the issue with a DummyVariable pointer. BR Stefano Re: Lear - S32k344 - Mismatch btw. Crypto upper and lower driver Hi @StefanoGattazzo , I am analyzing the requirements, will provide response soon. Meanwhile please provide the demo app version and fw version that you use . Regards Marian Vilau
查看全文
SPSDK v3.1 release We are excited to annouce the release of Secure Provisioning SDK (SPSDK) 3.1 Please note this release is a new generation of SPSDK and it is NOT backward compatible to 2.x versions.  A migration guide is provided below: ⭐What's NEW: https://spsdk.readthedocs.io/en/latest/release_notes.html ⚠️Migration Guide: https://spsdk.readthedocs.io/en/latest/migration_guide.html 📦Supported Devices: https://spsdk.readthedocs.io/en/latest/devices_list.html 👇More details: Github PyPi Documentation SPSDK Plugins 3.1: Github (Plugins) PyPi (Plugins) Restricted Data Package for SPSDK 3.1: Please note that the package uses an LA_OPT license. Package will be located in the Download section. announcement
查看全文
HMB-N1905低成本雷达打造安全智能家居 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 先进的技术大大降低了 24 GHz 雷达系统的成本,带来了一系列新的应用。从历史上看,雷达由于应用成本高,一直纯粹用于军事和工业应用。随着最新一代 NXP BiCMOS 技术的出现,这种情况已经发生了改变。24 GHz 雷达前端现在可以完全集成到单个 IC 中,从而将成本和功耗降低到消费者水平。这开辟了一系列以前不可能实现的应用。本次讲座将展示雷达在不同应用领域的可能性,例如存在检测和消费级无人机防撞。将进行基于首批测试芯片与 ARM 处理器相结合的现场演示。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 先进的技术大大降低了 24 GHz 雷达系统的成本,带来了一系列新的应用。从历史上看,雷达由于应用成本高,一直纯粹用于军事和工业应用。随着最新一代 NXP BiCMOS 技术的出现,这种情况已经发生了改变。24 GHz 雷达前端现在可以完全集成到单个 IC 中,从而将成本和功耗降低到消费者水平。这开辟了一系列以前不可能实现的应用。本次讲座将展示雷达在不同应用领域的可能性,例如存在检测和消费级无人机防撞。将进行基于首批测试芯片与 ARM 处理器相结合的现场演示。 智能家居和智能建筑
查看全文
开放工业Linux ® (OpenIL)——安全、稳健、实时的工业和自动化应用_Connects China <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> OpenIL 是专为工业市场设计的 Linux ®发行版。OpenIL 是 PLC、HMI、工业控制和自动化系统的理想部署。OpenIL 是一个基于 buildroot 的开源项目,旨在为工业用途提供紧凑的文件系统,支持 LTS Linux 内核 4.1 和 4.9、Xenomai 钴核、工业 IEEE ® 1588、时间敏感网络等诸多功能。实时裸机框架支持继电器控制和机器人应用。了解 OpenIL、架构、设计目标和路线图。了解如何为 OpenIL 做出贡献并推动社区项目的发展方向。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> OpenIL 是专为工业市场设计的 Linux ®发行版。OpenIL 是 PLC、HMI、工业控制和自动化系统的理想部署。OpenIL 是一个基于 buildroot 的开源项目,旨在为工业用途提供紧凑的文件系统,支持 LTS Linux 内核 4.1 和 4.9、Xenomai 钴核、工业 IEEE ® 1588、时间敏感网络等诸多功能。实时裸机框架支持继电器控制和机器人应用。了解 OpenIL、架构、设计目标和路线图。了解如何为 OpenIL 做出贡献并推动社区项目的发展方向。
查看全文
FTF-ACC-F1259 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 同時マルチスレッド (SMT) は、独立した実行スレッドがスーパースカラー CPU パイプライン編成をより効果的に利用できるようにする高度なプロセッサ マイクロアーキテクチャ機能です。2ウェイ・スーパースカラー・パイプラインでのSMT実装は、動的消費電力の増加が比較的少ないデュアル・スレッドの同時実行性を最大化します。このセッションでは、次世代のPower Architecture e200z9プロセッサ・コアに含まれるSMT機能と、このマイクロアーキテクチャによって達成可能なパフォーマンス/パワー・メトリックの向上に焦点を当てます。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 同時マルチスレッド (SMT) は、独立した実行スレッドがスーパースカラー CPU パイプライン編成をより効果的に利用できるようにする高度なプロセッサ マイクロアーキテクチャ機能です。2ウェイ・スーパースカラー・パイプラインでのSMT実装は、動的消費電力の増加が比較的少ないデュアル・スレッドの同時実行性を最大化します。このセッションでは、次世代のPower Architecture e200z9プロセッサ・コアに含まれるSMT機能と、このマイクロアーキテクチャによって達成可能なパフォーマンス/パワー・メトリックの向上に焦点を当てます。 日時:FTF-ACC-F1259 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 新しいe200z9はいつ発売されますか?
查看全文
USB 输出事务缺少 ACK 我的团队在 USB 输出事务中遇到了 ACK 缺失的问题。 关于我们系统的一些信息: * MCU 型号为 LPC5528 * SDK 版本为 26.03.00。 * 对于 USB_DeviceInit 的调用,我们将 kUSB_ControllerLpcIp3511Fs0 作为第一个参数(controllerId)提供,以便我们使用 USB 全速。 很难对模式做出太多评价。我们可以肯定的是: * 当我们通过 USB 发送大量消息时,偶尔会出现 OUT 事务缺少 ACK 的情况。我们用Ellisys USB分析仪检测到了这个问题。我们可以看到缺少 OUT 信号,然后 PC 进行了 3 次重试,最后通过 USB RESET。 这种情况很少发生。我们编写了一个脚本,重复发送相同的简单 USB 消息(目标只是返回一些数据,没有繁重的计算等)。有时只需几次迭代,有时则需要数千次迭代才会出现错误。 我们想知道这是否是一个已知问题,或者是否有调试技巧。 Re: Missing ACK on USB OUT Transactions 嗨@JacobBerggreen 我们已经检查了 LPC55S2x/LPC552x 的勘误表,没有发现任何与 USB0 全速设备输出直接对应的缺少 ACK 相关的已知问题。目前,USB勘误表主要集中在高速模式上,因此并不直接适用于您的配置。 从这种现象来看,更可能的原因是 OUT 端点在某些时刻没有及时准备接收缓冲区,导致主机发送 OUT 时设备无法响应 ACK,从而触发信号重试甚至 RESET。建议重点确认每次 OUT 完成后是否立即调用 USB_ServiceRecvRequest(),并尽量减少回调中的处理。还建议检查 USB 中断的优先级,避免长时间的关机中断。 BR 哈里
查看全文
Support Needed for Enabling OV5647 Camera on i.MX93 FRDM Hi, I am currently working on enabling the OV5647 camera module on the i.MX93 FRDM board. I have added the OV5647 node in the device tree and configured the appropriate clock source. The camera sensor is detected, and I am able to provide a 25 MHz clock on CCMSRCGPCMIX CLKO3. However, the /dev/video0 and media0 nodes are not appearing on the target board. Could you please assist me in identifying the possible cause of this issue or suggest steps to resolve it? DTS file and some required information snapshot attached in below Thank you for your support. Best regards, Bharath GC Re: Support Needed for Enabling OV5647 Camera on i.MX93 FRDM you can refer to the ov5640 dts file https://github.com/nxp-imx-support/meta-imx-frdm/blob/lf-6.6.36-2.1.0/meta-imx-bsp/recipes-kernel/linux/linux-imx/0009-arm64-dts-add-imx93-11x11-frdm-ov5640-dts.patch pls check if your camera need  PW pin or not Re: Support Needed for Enabling OV5647 Camera on i.MX93 FRDM Hello @joanxie , Thanks for your immediate response, As requested, I am sharing the OV5647 driver currently used in our build. The driver is taken from the kernel source in our Yocto build environment. Please find the attached driver ov5647.c file in the attachment  This is the driver being used for the camera integration on our system based on the i.MX93. driver is enabled for CONFIG_VIDEO_OV5647=y the kernel Version 6.6.36-lts-next-gb1d63f58897b-dirty Regards Bharath GC Re: Support Needed for Enabling OV5647 Camera on i.MX93 FRDM pls send the ov5647 driver you use, let me double check it Re: Support Needed for Enabling OV5647 Camera on i.MX93 FRDM Hello @joanxie , I also tried making some changes by referring to the OV5640 DTS file, but there is still no change on the target side. The same error is appearing. I have attached the updated DTS file, which I modified based on the OV5640 camera module DTS configuration. The power-domain pin is enabled by default, and I confirmed this by forcing it to active-low using a gpio-hog. If I add the below structure, the camera does not come up, which indicates that the power-domain is functioning. pcal6524:gpio@22 { ......        camera_pwdn {             gpio-hog;            gpios = <22 GPIO_ACTIVE_LOW>;            output-high;           line-name = "camera_pwdn";      }; }; Please find the modified DTS file attached for your reference. Kindly help in resolving this issue. Thank you.
查看全文
NXP FRDM Lab at Embedded World 2026 NXP FRDM Lab - Embedded World 2026 Learn. Build. Explore—On Your Own Time. The NXP FRDM Lab at Embedded World 2026 is your hands-on destination to explore embedded development—from Edge AI and Zephyr RTOS to motor control, security, connectivity, and GUIs. Whether you attend live or want to continue learning after the show, all training sessions and demo materials will be available for self‑guided exploration. That means you won’t miss out—before, during, or after the event. 🎓 FRDM Lab Training Sessions Each training session is designed to be practical, reusable, and self‑paced, using the same materials showcased during the event. 🔐 Building Cyber‑Resilient Embedded Systems: CRA Compliance Learn how NXP portfolio help achieve CRA compliance through integrated security features and practical implementation. Download presentation attached in this post:  Cyber Resilience Act (CRA) - A paradigm shift CRA: Step 1 Risk Assessment & Threat Analysis CRA: Step 2 Security by Design CRA: Step 3 Proving Compliance CRA: Step 4 Maintaining Conformity Across the Product Lifecycle ⚙️ Building with Zephyr RTOS: Simplified Development on FRDM Platform Learn about Zephyr RTOS portability and start building with FRDM boards with simplified setup, resources, and demos included. Hands-On Training material. Embedded AI with NXP Edge Processors: Intelligence at the Edge Learn AI/ML fundamentals for embedded systems, explore key use cases, and discover NXP’s ML portfolio and tools for AI development on the edge.  Hands-On Training Material 🎨 Designing Embedded GUIs: GUI Guider in Action Learn how to design and implement graphical user interfaces using LVGL and NXP GUI Guider on FRDM boards Hands-On Training Material MCUXpresso for VS Code: Build Your Embedded Development Environment Discover the benefits of the MCUXpresso extension, turning VS Code into a flexible, unified development environment for any embedded project. Download presentation attached: MCUXpresso for VS Code Build Your Embedded Development Environment Hands-On Training Material 📌 Good to know: Attendees at EW 2026 will use the same training materials live Materials will also be available for self-guided learning, so you can revisit or explore sessions at your own pace 🔬Demos at FRDM Lab  Below is a curated list of demos you’ll find in the FRDM Lab. Each demo highlights a real-world use case, with hardware and software you can explore in detail. Hands‑On Experience: Build the Demo Yourself at the FRDM Lab A set of selected demos will be available as guided hands‑on demo inside the FRDM Lab. With support from NXP experts, visitors can re‑create the full demo flow—from loading the project in MCUXpresso for VS Code, to connecting FRDM boards and expansion modules, to running real firmware on hardware.  Everything customers touch during the demo is fully reproducible at home, using the same boards and open resources. Demo Overview Demo Title Description / Key Highlights Featured Boards   Real‑Time Interactive Control with DOOM Experience responsive real‑time control using MCX MCUs running a fully playable DOOM port. FRDM-MCXN947 Edge AI Vision on Zephyr Showcasing Zephyr OS code abstraction that enables seamless portability across NXP MCUs with different architectures. FRDM-MCXN947 FRDM-RW612 Offline Edge AI Image Analysis Capture or upload images and ask questions that the i.MX processor answers entirely offline using VLM acceleration on Ara‑2. FRDM-IMX8MPLUS Bluetooth® Channel Sounding Measure distance between devices in centimeters or feet using advanced Bluetooth wireless channel sounding technology. FRDM-MCXW72 Interactive Smart Nodes OLED B Click OLED C Click Knob G Click Ping pong Game     Demonstrates the versatility of FRDM boards for building smart sensors, games, PC accessories, industrial controls, and more using displays, knobs, joysticks and additional peripherals. FRDM-MCXC041 FRDM-MCXC242 FRDM-MCXA156 FRDM-MCXN947 Dual PMSM FOC Motor Control One MCU efficiently drives two 3‑phase motors using an integrated motor control subsystem, reducing external components and system cost. FRDM-MCXA346 3-Phase PMSM FOC Motor Control Motor control running on a 5‑V‑tolerant MCU combined with GUI Guider and FreeMASTER visualization for tuning and real‑time phase inspection. FRDM-MCXE31B Wireless Co-Processor Enabled Control FRDM-RW612 acts as a Wi‑Fi co‑processor, enabling remote command transmission from a tablet to control a main MCU‑driven motor system. FRDM-MCXA156 FRDM-RW612 GoPoint i.MX Demo Experience The i.MX93 showcases the full GoPoint experience with available demos integrated into the out‑of‑box environment. FRDM-IMX93 Video Analysis Analyze multiple video streams simultaneously using advanced, edge‑optimized object detection. FRDM-IMX95-PRO NAFE13388 universal analog sensing module with wired connectivity   NAFE13388 analog front end pairs with the FRDM‑MCXN947 to deliver precise, software‑configurable analog sensing. This enables the board to handle demanding industrial automation, smart agriculture, and lab instrumentation use cases where high‑accuracy analog capture, noise robustness, and flexible sensor conditioning are essential FRDM-MCXN947 Learn Beyond the Booth For many demos, collateral material will be available, including: Software and hardware overviews Block diagrams and system architecture Key features and advantages Links to App Code Hub projects This ensures you can replicate, extend, or adapt what you see in the lab—long after Embedded World ends. Explore FRDM and keep learning at FRDM Training Hub #FRDM-Training #Hands-On Training #EW #Embedded World Discover the NXP FRDM Lab at Embedded World 2026 Hands‑on training and real demos across Edge AI, Zephyr, motor control, security, and GUIs Learn live—or later with self‑guided FRDM Lab content FRDM-MCXA FRDM-MCXN FRDM-RW612 FRDM-Training Hands-On Training i.MX Application Processors MCU Wireless
查看全文
如何在S32DS中快速设置S32K1 SDK 本文以中文撰写。主要针对中国本土的地区及大众市场客户。对于刚接触S32K1的开发者很有用,会帮助他们安装S32K1的几个软件,否则可能会浪费很多时间。 S32DS中快速搭建S32K1的开发环境 一.背景 我最近换装了新电脑,需要重新安装S32DS,发现存在很多问题。尤其是对比之前的安装过程,发现官网的很多链接已经失效,甚至有一定的迷惑性。 最新的S32K1安装包比较隐蔽,而且安装存在前后依赖,对于刚接触NXP S32系列的新手非常不友好,所以写这篇文档总结一下典型的问题和解决方法。 同时也希望提供一个check的思路和步骤,在后续新版本发布时,升级IDE的时候更方便找到合适的安装包。 二.S32DS中各个包依赖关系解析 在S32DS中,每一个系列的MCU,总共需要安装两个插件包,一个是基础依赖包,一个是SDK(也叫RTD,同一个意思)。 1.基础依赖包 这个包对应S32DS版本,比如当前的3.4.3,官网可以下载离线版,一般大小在3GB左右,会更新S32DS中的很多组件,如下图1所示:            图1 尤其需要关注图1中红框的内容,没有这个development package的话,是无法进行对应MCU的debug。 图1中安装的包,对应到S32DS中安装的内容如图2所示:            图2 2.RTD安装包(与SDK同义) 这个包对应于RTD版本,也会标识AutoSAR的版本,比如最新的2.0.0,AutoSar 4.4,如图3所示:           图3 基础依赖包与RTD安装包存在前后依赖关系,如果不安装基础依赖包直接安装RTD,在安装时会报错。另外,我们下载的RTD包,即使写明是K3,里面也会包含K1的RTD,这点需要注意。如果此时还没有装K1的development package,就会出错。 三.S32K1开发环境搭建 官网对于S32K3的软件划分为standard software和reference software,其中S32DS和基础依赖包在standard software中,可以很方便的找到。 但S32K1的官网却仅有一个reference software,页面也只能找到几个RTD(或SDK)链接:                                                                             图4 这里面所有的链接都不是我们需要的,全是RTD。问题就出在这里,K1的网页中没有K1的基础依赖包!而前面讲过,缺基础依赖包会导致RTD也无法安装。经过我研究,K1的基础依赖包隐藏的非常深,可以通过两个方法找到: 从S32K1的参考软件进去,然后重新点击产品列表,如下图5所              图5         进入如下页面,如图6所示,这里最能看出来,针对K1的界面很不友好,需要点最底下的NXP Software.              图6 在NXP.com官网首页搜索栏直接搜S32DS,找到S32 Design Studio for S32 Platform(注意不要选成for ARM或或者for PowerPC),从S32DS的主界面进入,然后一直下拉,找到S32DS service pack 1,这个才是K1的,如图7所示:                 图7 这个链接更加隐蔽,要在40多个选项里挨个找。 经过上面两个方法,都可以进入图8所示的界面,然后再按图8所示操作:              图8 这回终于到了最终可以下载S32K1基础依赖包的地方,如图9所示。我们需要重点关注一下命名,SW32开头的,会包含所有S32的development package,包括K1,K3,G;SW32K1开头的,仅有K1,同理如果你在K3的界面中,可以看到SW32K3开头的。            图9 下载最新版本的S32K1基础依赖包,然后再安装RTD,大功告成。
查看全文
linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx linux6.12+imx8mp内核启动时报告: [ 0.057737] /soc@0: Fixed dependency cycle(s) with /soc@0/bus@30000000/efuse@30350000/unique-id@8 [ 0.058809] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.058972] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000 [ 0.059239] /soc@0/interrupt-controller@38800000: Fixed dependency cycle(s) with /soc@0/interrupt-controller@38800000 [ 0.061960] /soc@0/bus@30000000/pinctrl@30330000: Fixed dependency cycle(s) with /soc@0/bus@30000000/pinctrl@30330000/miscgrp [ 0.061986] /soc@0/bus@30000000/pinctrl@30330000: Fixed dependency cycle(s) with /soc@0/bus@30000000/pinctrl@30330000/hoggrp [ 0.062566] imx8mp-pinctrl 30330000.pinctrl: initialized IMX pinctrl driver [ 0.063301] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000 [ 0.064431] /soc@0/bus@30000000/efuse@30350000: Fixed dependency cycle(s) with /soc@0/bus@30000000/clock-controller@30380000 [ 0.065497] /soc@0/bus@30000000/clock-controller@30380000: Fixed dependency cycle(s) with /soc@0/interrupt-controller@38800000 [ 0.074336] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.074446] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000 [ 0.076363] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.076855] /soc@0/bus@32c00000/lcd-controller@32fc6000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000 [ 0.076990] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32fc6000 原因是什么?需要处理吗 Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx Hi @machangbao This is normal, no need to deal with it. Best Regards, Zhiming Re: linux6.12+imx8mp内核报告Fixed dependency cycle(s) with xxx Hi @machangbao This is the patch that was introduced upstream of the kernel, the commit message is: driver core: fw_devlink: Stop trying to optimize cycle detection logic commit bac3b10b78e54b7da3cede397258f75a2180609b upstream. In attempting to optimize fw_devlink runtime, I introduced numerous cycle detection bugs by foregoing cycle detection logic under specific conditions. Each fix has further narrowed the conditions for optimization. It's time to give up on these optimization attempts and just run the cycle detection logic every time fw_devlink tries to create a device link. The specific bug report that triggered this fix involved a supplier fwnode that never gets a device created for it. Instead, the supplier fwnode is represented by the device that corresponds to an ancestor fwnode. In this case, fw_devlink didn't do any cycle detection because the cycle detection logic is only run when a device link is created between the devices that correspond to the actual consumer and supplier fwnodes. With this change, fw_devlink will run cycle detection logic even when creating SYNC_STATE_ONLY proxy device links from a device that is an ancestor of a consumer fwnode. The fw_devlink framework on top of 6.12 is more robust than before, and Fixed dependency cycle(s) with indicates that fw_devlink detected the ring and solved the problem by adjusting the linking policy (e.g., downgrading certain link types or not creating certain links). This is not an error, but an informational note that the system handles potential deadlock risks at boot time. driver core: fw_devlink: Make cycle detection more robust fw_devlink could only detect a single and simple cycle because it relied mainly on device link cycle detection code that only checked for cycles between devices. The expectation was that the firmware wouldn't have complicated cycles and multiple cycles between devices. That expectation has been proven to be wrong. For example, fw_devlink could handle: +-+ +-+ |A+------> |B+ +-+ +++ ^ | | | +----------+ But it couldn't handle even something as "simple" as: +---------------------+ | | v | +-+ +-+ +++ |A+------> |B+------> |C| +-+ +++ +-+ ^ | | | +----------+ But firmware has even more complicated cycles like: +---------------------+ | | v | +-+ +---+ +++ +--+A+------>| B +-----> |C|<--+ | +-+ ++--+ +++ | | ^ | ^ | | | | | | | | | +---------+ +---------+ | | | +------------------------------+ And this is without including parent child dependencies or nodes in the cycle that are just firmware nodes that'll never have a struct device created for them. The proper way to treat these devices it to not force any probe ordering between them, while still enforce dependencies between node in the cycles (A, B and C) and their consumers. So this patch goes all out and just deals with all types of cycles. It does this by: 1. Following dependencies across device links, parent-child and fwnode links. 2. When it find cycles, it mark the device links and fwnode links as such instead of just deleting them or making the indistinguishable from proxy SYNC_STATE_ONLY device links. This way, when new nodes get added, we can immediately find and mark any new cycles whether the new node is a device or firmware node. Best Regards, Zhiming
查看全文
RT1170 使用同步动态随机存取存储器(SDRAM) 处理堆和堆栈 我按照https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/RT1170-debugging-when-application-is-built-for-SDRAM/m-p/1374145/highlight/true#M17210和 RT1170_BriefOverview_v210.pdf 中提到的步骤进行了操作。 我正在开发一个需要大量头部内存的应用程序。 按照提供的步骤,使用 RT1170_BriefOverview_v210.pdf 中提到的修改刷新 hello world,我可以在调试模式下使用同步动态随机存取存储器(SDRAM)。 但是在这种变化之后,同步动态随机存取存储器(SDRAM)也用于存储代码。 在我的应用程序中,我希望代码存储在闪存中,而 BOARD_SDRAM 仅用于堆和堆栈部分。 我将把我的应用程序闪存到闪存中,该应用程序的堆和栈部分将使用 BOARD_SDRAM。 请指导我进行所需的更改。 i.MX-RT1170 MIMXRT1170-EVK Re: RT1170 Use SDRAM for Heap and Stack 按照恩智浦支持中的步骤,我得以在 RT1170 EVKB 上加载多核项目(如何在 RT1176 & [RT1170] 中调试双核项目)。 当我能够从同步动态随机存取存储器(SDRAM)运行后,在 Master/Core M7 项目中,我进入了项目设置-> C/C++ 版本-> 设置-> 托管链接器脚本并禁用了 " 将应用程序链接到 RAM " 设置。 然后我得以刷新二进制文件,并确认应用程序在 RESET 时从闪存运行,并成功地将 M4 应用程序从闪存复制到同步动态随机存取存储器(SDRAM)。 Re: RT1170 Use SDRAM for Heap and Stack 你好@sibrain-himanshu、 感谢您对 NXP MIMXRT 系列的关注! 问题的根本原因在于您使用了这个步骤6: 这会将整个图像加载到 RAM 中执行,也是生成非 XIP 图像的选项。 对于您的应用场景,在启用和配置同步动态随机存取存储器(SDRAM)之后,您只需要在 MCUXpresso IDE 中正确配置 Head/Stack: 致以最诚挚的问候, Gavin Re: RT1170 Use SDRAM for Heap and Stack 你好@Gavin_Jia 在步骤 6 的基础上做了你建议的更改,并在预处理器中使用了 "XIP_BOOT_HEADER_DCD_ENABLE=1" 宏之后,我的固件使用了同步动态随机存取存储器(SDRAM)。 但我的应用程序是用 C++ 编写的,所以我最初对它进行了与 hello world C 应用程序相同的修改,但没有成功。 因此,还在 C++ 预处理器宏中添加了"USE_SDRAM" 和"XIP_BOOT_HEADER_DCD_ENABLE=1" 宏,结果成功了。 C++ 预处理器宏 C 预处理器宏 感谢您的帮助。
查看全文
s32k3xx_dio_s32ct 情報キャッシュフォルダまたはアーティファクトが見つかりません エラー S32K3_Examples s32k3xx_dio_s32ct を実行していますが、このサンプル モデルのコード生成中にエラーが発生します。 添付のビルド概要と以下のログ詳細を確認して、サポートしてください。   ### s32k3xx_dio_s32ct のビルド手順を開始します ### 「モデル固有の」フォルダ構造にコードと成果物を生成する ### ビルドフォルダにコードを生成しています: C:\MATLABAddOns\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\dio\s32k3xx_dio_s32ct\s32k3xx_dio_s32ct_ert_rtw ### s32k3xx_dio_s32ct.rtw でターゲット言語コンパイラを呼び出す ### システムターゲットファイルの使用: C:\MATLAB\R2024b\rtw\c\ert\ert.tlc ### TLC 関数ライブラリを読み込んでいます ........ ### カスタム データ用の TLC インターフェース API を生成しています。 ### ユーザー定義のコードをキャッシュするためのモデルを最初にパススルーします。 ### キャッシュモデルのソースコード ................................................ ### ヘッダーファイル s32k3xx_dio_s32ct_types.h の書き込み ### ヘッダーファイル s32k3xx_dio_s32ct.h を書き込んでいます。 ### ヘッダーファイル rtwtypes.h の書き込み ### ソースファイル s32k3xx_dio_s32ct.c を書き込んでいます ### ヘッダーファイル s32k3xx_dio_s32ct_private.h の書き込み ### ソースファイル s32k3xx_dio_s32ct_data.c を書き込んでいます ### ヘッダーファイル rtmodel.h を書き込んでいます。 ### ソースファイルert_main.cを書き込んでいます ### TLC コード生成が完了しました (12.619 秒かかりました)。 ### バイナリ情報キャッシュを保存しています。 # ## Using toolchain: S32DS GCC ## # 'C:\MATLABAddOns\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\dio\s32k3xx_dio_s32ct\s32k3xx_dio_s32ct_ert_rtw\s32k3xx_dio_s32ct.mk' を作成しています... ### 's32k3xx_dio_s32ct' をビルディングしています: "C:\MATLAB\R2024b\bin\win64\gmake" -f s32k3xx_dio_s32ct.mk -j all C:\MATLABAddOns\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\dio\s32k3xx_dio_s32ct\s32k3xx_dio_s32ct_ert_rtw>PATH=C:\MATLABAddOns\Toolboxes\NXP_MBDToolbox_S32K3\tools\build_tools\gcc_v10.2\gcc-10.2-arm32-eabi\bin;C:\MATLAB\R2024b\bin\win64;C:\Users\hp\AppData\Local\Programs\Python\Python310\Scripts\;C:\Programファイル (x86)\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramFiles\PuTTY\;C:\Users\hp\AppData\Local\Programs\Python\Python310\;C:\Program Files\Microsoft SQL Server\140\Tools\Binn\;C:\Program Files (x86)\Geehy\openocd-20240916\OpenOCD-20240916-0.12.0\bin;C:\Programファイル (x86)\Geehy\xpack-windows-build-tools-4.3.0-1-win32-x64\xpack-windows-build-tools-4.3.0-1\bin;C:\Programファイル (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin;C:\ProgramFiles\Git\cmd;C:\Program Files\dotnet\;C:\MATLAB\R2024b\bin;C:\Program Files\7-Zip;C:\Users\hp\.mcuxpressotools\dtc-1.6.1\tools\usr\bin;C:\Users\hp\.mcuxpressotools\gperf-3.0.1\bin;C:\Users\hp\.mcuxpressotools\wget-1.21.4;C:\Users\hp\.mcuxpressotools\ninja-1.12.1;C:\Users\hp\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin;C:\ProgramFiles\Python\Python310\Scripts\;C:\Program Files (x86)\Vim\vim90;C:\Users\hp\AppData\Local\Programs\Microsoft VS Code\bin C:\MATLABAddOns\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\dio\s32k3xx_dio_s32ct\s32k3xx_dio_s32ct_ert_rtw>cd 。C:\MATLABAddOns\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\dio\s32k3xx_dio_s32ct\s32k3xx_dio_s32ct_ert_rtw>if "all" == "" ("C:\MATLAB\R2024b\bin\win64\gmake" -f s32k3xx_dio_s32ct.mk -j all ) else ("C:\MATLAB\R2024b\bin\win64\gmake" -f s32k3xx_dio_s32ct.mk -j all ) "C:\MATLAB\R2024b\bin\win64\gmake": 割り込み/例外が発生しました (コード = 0xc00000fd、アドレス = 0x41a0c5) C:\MATLABAddOns\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\dio\s32k3xx_dio_s32ct\s32k3xx_dio_s32ct_ert_rtw>echo makeコマンドがエラー255を返しました makeコマンドがエラー255を返しましたC:\MATLABAddOns\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\dio\s32k3xx_dio_s32ct\s32k3xx_dio_s32ct_ert_rtw>exit /B 1   ### s32k3xx_dio_s32ct のビルド手順はエラーのため中止されました。   ビルドの概要   上位モデル ターゲット: モデル ビルド理由 ステータス ビルド期間 =============================================================================================================================================================== s32k3xx_dio_s32ct 情報キャッシュフォルダまたはアーティファクトが見つかりません。ビルドに失敗しました。           「 s32k3xx_dio_s32ct 」のビルディング中にエラーが発生しました             Re: s32k3xx_dio_s32ct Information cache folder or artifacts were missing Error こんにちは、 @mohit2904さん、 ログテキスト全体をコピーして貼り付けていただけますか?そうすれば、問題を特定しやすくなります。また、モデル例もご自由に添付していただければ、確認させていただきます。 よろしくお願いいたします。 ドラゴス
查看全文
コア n のセカンダリ Thread のプログラム エントリを設定する方法は何ですか? コア n の 2 つの Thread (仮想コア) で 2 つの異なる OS を実行したいと考えています。しかし、Thread 0 は 0xffff_fffc からエントリを取得することはわかっています。しかし、Thread 1 の入り口を設定する方法がわかりません。この目的のためのレジスターまたは特別なアドレスはありますか? Re: What's the way to set program entrance of secondary thread of core n? 迅速なサポート誠にありがとうございました。 これをT4240/e6500に実装したいです。ここでは特定のレジスターが見つかりません。これに関して何か提案はありますか。 Re: What's the way to set program entrance of secondary thread of core n? こんにちは、 マルチコア/マルチスレッド プロセッサの場合、コアのThread 0 は通常、ブート時にアドレス 0xFFFF_FFFC からエントリ ポイントを取得します。ただし、Thread 1 の場合は、通常、異なるメカニズムが存在します。 スレッド 1 のプログラム エントリを設定するには: 1.プライマリThread(Thread 0)は、Thread 1のセットアップと起動を担当します。 これは通常、セカンダリThreadのリセットベクターまたはエントリポイントアドレスを制御する特定のレジスタを通じて行われます。 正確な実装は特定の NXP プロセッサによって異なりますが、一般的には次のようになります。 1. Thread 1のアプリケーションコードを適切なメモリ位置にロードする 2. Thread 1のエントリポイントレジスタをこの位置を指すように設定する 3. Thread 1をリセットから解放して実行を開始する Arm Cortex アーキテクチャのプロセッサを使用している場合、多くの場合、次の処理が行われます。 - リセットベクターアドレスを特定のSRC(System Reset Controller)レジスタに書き込む - 制御ビットを設定してセカンダリThreadをリセットから解放する よろしくお願いします。
查看全文