KW45B41Z EVKが搭載デバッガーMCUリンクでプログラムされていないこと。 こんにちは、 kw45b41zevk_hello_world SDKのサンプルコードを使ってKW45B41Z-EVKをプログラムしようとしています。デバッグを開始すると、オンボードデバッガーは検出されますが、その後、次のエラーが発生します。 検出された利用可能なSWDデバイスは0個です。 デバイスを接続して、もう一度お試しください。 USBケーブルは J14 に接続し、 JP22はオン ボードデバッガでプログラムするために開いたままにしています。また、 KW45UMで述べられているように、 JP28のピン1と2は短絡されています。しかし、その後もサンプルプログラムをプログラミングしたりデバッグしたりすることができません。 kw45b41zevk_led_blinky SDKの例も試しましたが、同じように動作します。 KW45UMで説明されているように、外部デバッガを使用してJP22をショートさせてボードのデバッグも試みましたが、同じ問題が発生します。 発生している問題のスクリーンショットを添付しました。 セキュアプロビジョニングツールを使用して、フラッシュメモリを消去してイメージを書き込むことも試しました。まず、 JP25をショートさせてSW4を有効にし、次にSW4とリセット（SW3）を長押ししてISPモードに入りました。接続テストが成功した後、フラッシュメモリ（位置0x00000000 、サイズ0x100000 ）の消去に成功しました。次に、以下の画像を使用しました。 ${SPT_INSTALL_BIN} \data\sample_data\targets\KW45B41Z8\source_images\kw45b41zevk_led_blinky.s19 画像の構築とプログラムは無事にでき、意図した RGB LED1 も点滅しており、KW45B41Z マイクロコントローラが正常に動作していることを示しています。しかし、それでもなお、基板のプログラミングやデバッグができません。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. こんにちは、 @kaif1 どのIDEを使っていますか? MCUXpresso IDEまたはMCUXpresso for VS Code? 私の方で試してみて、デフォルトのジャンパー設定をお知らせします。 よろしくお願いいたします。 Christine。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. こんにちは、 @kaif1 ジャンパーの設定を参照してください。ローカル側で確認済みで、hello_world例をボードに正常にフラッシュできます。 そして、MCUXpresso IDEとSDK 25.12.00を使っています。 私のジャンパー設定を試してみて、うまくいくかどうか教えてください。 よろしくお願いいたします。 Christine。 Re: KW45B41Z EVK not programming over on board Debugger MCU Link. Secure Provisioning Toolはチップ上でコードを正常にフラッシュ・実行できるため、物理ハードウェアは完全に問題ありません。つまり、「0 SWD デバイスを検出」というエラーは、IDEのデバッグプローブサーバーとオンボードのMCU-Linkファームウェア間の通信ミスマッチに起因しています。これは通常、MCU-LinkファームウェアをIDEs対応の最新バージョンに更新するか、接続中に手動でリセットボタンを押し続けることで解決し、低消費電力のアプリケーション状態がデバッグインターフェースをロックしないようにします。

Experience with vendor's tools Hi guys, I am wondering what's your experience with using vendor's tools while working on their hardware? Let's say we talk about something like Layerscape series from NXP or STM32MP1 series. I've been working on a board based on one of the NXP's Layerscape SoC and I can't wrap my hand around the fact that the only tool they provide to bringup and verify eg. DDR is **bleep**ty IDE based on Eclipse. I mean, given the quality of this tool I wouldn't complain if they provided it for free but they charge hell a lot of money for a license. Want to learn how to do this or that using their IDE? Good luck, "best I can do" is, mostly not 100% accurate outdated, partial documentation, forum where you will always get an answer, that somebody will handle this and 240p video where you can barely see what's on the screen. I hope that I will only use it for DDR bringup and validation and will manage to do the rest without this tool. What's your experience with other vendors? How about TI? I've seen some tools from ST and they really looked much simpler but I don't have any practical experience. Re: Experience with vendor's tools Hello, The Eclipse base is aging, the DDR tooling (DDR Stress Test Tool) is functional but clunky, and the licensing cost vs. quality ratio is a common complaint in embedded communities. The documentation gap is real — AN (Application Notes) are often the better resource than the official tool docs. Many engineers use it purely for DDR PHY init/training as you plan, then move on.   Practical Tips for NXP Layerscape DDR Bringup Since you're stuck with it for now: The DDR Stress Test Tool standalone binary (separate from CodeWarrior) is sometimes available and lighter to use. NXP's i.MX/Layerscape community on GitHub has reference DDR configurations that can shortcut a lot of the tool-guided work. LSDK (Layerscape SDK) scripts sometimes expose DDR init parameters more transparently than the IDE. Regards

Lx2160a用のIbisモデル こんにちは、みんな LX2160A用のIBISモデルをどうやって手に入れられるのか知りたいです。どなたか助けていただけませんか? どうもありがとうございます 元 Re: Ibis model for Lx2160a IBISモデルは公開されていません。こちらでケースを作成してください: https://support.nxp.com/s/?language=en_US  そして、秘密保持契約書（NDA）の内容を共有してください。 よろしくお願いします。

freertos 系统跑不通问题（创建即跑不通） 我的项目项目程序按照规程建立后，发现freertos 系统 无法跑通 (已经调查过不是内存不足问题，应该 也不是优先级的问题)，我的S32DS编译器版本如下图  任务直接建立失败，这个版本不支持freertos 吗？还是配置有什么特殊要求吗？ Re: freertos 系统跑不通问题（创建即跑不通） 你好@sunshine88 ， 应用程序实际上并不是因为 sys_msleep(5000) 调用本身而卡住的。该行为表明 sys_now() 使用的时间基准没有递增。因此， sys_msleep() 中的超时条件永远不会达到。 在 OSIF 配置截图中， OsIfUseSystemTimer 已启用，操作系统类型设置为 FreeRTOS。但是， OsIfCounterConfig_0 下的引用（包括计数器和系统定时器时钟引用）似乎不完整或为空。仅添加 PIT 组件并不能保证 OSIF 时基已正确配置和初始化。 目前请不要修改 TCP/IP 协议栈源代码或实现其他延迟解决方法。我建议如下： 从已安装的 TCP/IP 协议栈软件包中导入原始的 lwip_FreeRTOS_s32K358 示例。 构建并运行原始示例，无需任何修改。 检查原示例中 sys_now() 是否递增。 将 FreeRTOS、BaseNXP/OSIF、PIT、时钟、中断和 TCP/IP 协议栈配置与您的自定义项目进行比较。 验证生成的初始化序列是否包含所需的 BaseNXP/OSIF 和定时器初始化。 我们仍然需要之前请求的信息才能正确分析定制项目： MCU 的确切零件编号； 精确的评估板或定制板； 用作起点的原始示例或项目类型； 未修改的 lwip_FreeRTOS_s32K358 示例是否能在相同的硬件上运行； 生成的 sys_now() 实现； xTaskGetTickCount() 返回的 FreeRTOS tick 计数是否增加。 请先检查 xTaskGetTickCount() 。如果 sys_now() 保持不变而它增加，则说明 FreeRTOS 调度程序和滴答中断正在运行，问题具体出在 OSIF 时基配置或初始化中。如果 xTaskGetTickCount() 也保持不变，则问题更加根本，必须调查 FreeRTOS 滴答中断或调度程序配置。 如果可以，请提供完整的项目存档，而不仅仅是配置截图。如果没有生成的配置和初始化代码，就无法确定 sys_now() 实际使用的是哪个定时器或时钟源。 顺祝商祺！ 帕维尔 Re: freertos 系统跑不通问题（创建即跑不通） 你好，现在我建立了一个LWIP程序例程，但是以太网mainLoopTask任务却卡在 sys_msleep(5000); 无法延时，我单步进入此函数，发现 startTime = sys_now(); sys_now()函数无法计数，现在我的配置页如下，是什么原因造成的那？感觉很迷惑。 Re: freertos 系统跑不通问题（创建即跑不通） 你好@sunshine88 ， 您截图中显示的版本应该支持 FreeRTOS。S32 设计工作室 3.5 更新 14，RTD 4.0.0FreeRTOS 4.0.0 和 TCP/IP 协议栈 1.0.4看起来是预期的软件包组合，所以这似乎不是一般的版本兼容性问题。 根据所示代码，故障直接发生在 xTaskCreate() 中。请您提供以下信息？ 具体的MCU部件号以及所使用的评估板或定制板。您之前提到过 S32K358，但请确认具体的器件型号和主板型号。 用作起点的原始示例的名称。 xTaskCreate() 返回的值。 xPortGetFreeHeapSize() 在调用 xTaskCreate() 之前和之后打印的值。 配置的 configTOTAL_HEAP_SIZE、configSUPPORT_DYNAMIC_ALLOCATION 的值，以及选定的 FreeRTOS 堆实现，例如 heap_4.c。 应用程序停止的确切位置，包括调试器调用堆栈（如果它进入断言、异常或 HardFault 处理程序）。 请注意，MCU 总 RAM 充足并不一定意味着 FreeRTOS 堆内存充足。xTaskCreate() 从 FreeRTOS 堆中动态分配任务控制块和任务堆栈。此外，1024U 堆栈深度参数通常表示堆栈元素而不是字节，因此在 Cortex-M7 上实际分配的内存大于 1024 字节。 作为基准测试，我建议导入并运行原始的 lwIP FreeRTOS 示例，不要做任何修改。一旦原始示例运行正常，请添加一个带有小堆栈、普通优先级和循环内 vTaskDelay() 调用的附加任务。这将有助于区分环境或电路板配置问题与额外任务引入的问题。 我还注意到，您的 xTaskCreate() 调用使用了 1024U 的堆栈深度，而原始工作示例使用了 256U。请恢复原始值 256U，并先测试未修改的示例。请注意，此参数指定栈元素的数量，而不是字节数，因此使用 1024U 需要更多的 FreeRTOS 堆空间。   此致， 帕维尔

熟悉供应商的工具 大家好，我想了解一下你们在使用厂商提供的工具来维护他们硬件时的经验如何？假设我们谈论的是 NXP 的 Layerscape 系列或 STM32MP1 系列之类的产品。我一直在开发一款基于 NXP Layerscape SoC 的电路板，但我无法理解他们提供的唯一用于启动和验证例如 SoC 的工具是什么。DDR 是一个基于 Eclipse 的垃圾 IDE。我的意思是，考虑到这个工具的质量，如果他们免费提供，我不会抱怨，但他们的许可证费用却高得离谱。想学习如何使用他们的 IDE 来完成这个或那个操作吗？祝你好运，“我能做的最好的就是”提供一些不太准确、过时、不完整的文档，以及一个你总能得到答案的论坛，保证有人会处理这个问题，还有一段240p的视频，你几乎看不清屏幕上的内容。我希望我只会用它来启动和验证 DDR，其余工作无需这个工具就能完成。你与其他供应商的合作经验如何？TI 的产品怎么样？我见过 ST 的一些工具，看起来确实简单得多，但我没有任何实际经验。 Re: Experience with vendor's tools 你好， Eclipse 基础架构已经老化，DDR 工具（DDR 压力测试工具）虽然功能齐全但笨拙，而且许可成本与……相比。质量与比例失衡是嵌入式社区普遍抱怨的问题。文档缺失是真实存在的——应用笔记通常比官方工具文档更有价值。许多工程师仅将其用于 DDR PHY 初始化/训练，然后按照计划进行下一步。   NXP Layerscape DDR启动实用技巧 既然你现在只能接受它了： DDR压力测试工具的独立二进制文件（与CodeWarrior分开）有时可用，而且使用起来更轻便。 NXP在 GitHub 上的 i.MX/Layerscape 社区提供了参考 DDR 配置，可以简化许多工具引导的工作。 LSDK（Layerscape SDK）脚本有时比 IDE 更透明地公开 DDR 初始化参数。 此致

FreeRTOS system cannot run (cannot run immediately after creation) After my project program was built according to the specifications, I found that it could not run on the FreeRTOS system (I have investigated and it is not a memory shortage issue, nor should it be a priority issue). My S32DS compiler version is shown in the image below. The task failed to be created. Does this version not support FreeRTOS? Or are there any special configuration requirements? Re: freertos 系统跑不通问题（创建即跑不通） Hello @sunshine88 , The application is not actually stuck because of the sys_msleep(5000) call itself. The behavior indicates that the time base used by sys_now() is not incrementing. Therefore, the timeout condition inside sys_msleep() can never be reached. In the OSIF configuration screenshot, OsIfUseSystemTimer is enabled and the operating system type is set to FreeRTOS. However, the references under OsIfCounterConfig_0 , including the counter and system timer clock references, appear to be incomplete or empty. Adding the PIT component alone does not guarantee that the OSIF time base is correctly configured and initialized. Please do not modify the TCP/IP Stack source code or implement another delay workaround at this point. Instead, I recommend the following: Import the original lwip_FreeRTOS_s32K358 example from the installed TCP/IP Stack package. Build and run the original example without any modifications. Check whether sys_now() increments in the original example. Compare the FreeRTOS, BaseNXP/OSIF, PIT, clock, interrupt, and TCP/IP Stack configurations with your custom project. Verify that the generated initialization sequence includes the required BaseNXP/OSIF and timer initialization. We still need the information requested previously to analyze the custom project correctly: the exact MCU part number; the exact evaluation board or custom board; the original example or project type used as the starting point; whether the unmodified lwip_FreeRTOS_s32K358 example works on the same hardware; the generated implementation of sys_now() ; whether the FreeRTOS tick count returned by xTaskGetTickCount() is increasing. Please first check xTaskGetTickCount() . If it increases while sys_now() remains constant, the FreeRTOS scheduler and tick interrupt are running, and the problem is specifically in the OSIF time-base configuration or initialization. If xTaskGetTickCount() also remains constant, the problem is more fundamental and the FreeRTOS tick interrupt or scheduler configuration must be investigated. If possible, please also provide the complete project archive rather than configuration screenshots only. Without the generated configuration and initialization code, it is not possible to determine which timer or clock source is actually used by sys_now() . Best regards, Pavel Re: freertos 系统跑不通问题（创建即跑不通） Hello, I have created an LWIP program routine, but the Ethernet mainLoopTask task is stuck at sys_msleep(5000); unable to delay. When I step into this function, I find that startTime = sys_now(); the sys_now() function cannot count. My current configuration page is as follows. What could be causing this? I'm very confused. Re: freertos 系统跑不通问题（创建即跑不通） Hello @sunshine88 , The versions shown in your screenshots should support FreeRTOS. S32 Design Studio 3.5 Update 14, RTD 4.0.0, FreeRTOS 4.0.0, and TCP/IP Stack 1.0.4 appear to be the expected package combination, so this does not look like a general version compatibility issue. According to the code shown, the failure occurs directly in xTaskCreate(). Could you please provide the following information? The exact MCU part number and evaluation board or custom board being used. You previously mentioned S32K358, but please confirm the exact device and board. The name of the original example used as the starting point. The value returned by xTaskCreate(). The value printed by xPortGetFreeHeapSize() before and after the xTaskCreate() call. The configured values of configTOTAL_HEAP_SIZE, configSUPPORT_DYNAMIC_ALLOCATION, and the selected FreeRTOS heap implementation, for example heap_4.c. The exact point where the application stops, including the debugger call stack if it enters an assertion, exception, or HardFault handler. Please note that sufficient total MCU RAM does not necessarily mean that sufficient FreeRTOS heap is available. xTaskCreate() dynamically allocates both the task control block and the task stack from the FreeRTOS heap. Also, the 1024U stack-depth argument normally represents stack elements rather than bytes, so the actual allocation is larger than 1024 bytes on the Cortex-M7. As a baseline test, I recommend importing and running the original lwIP FreeRTOS example without modifications. Once the original example works, please add the additional task with a small stack, a normal priority, and a vTaskDelay() call inside its loop. This will help distinguish an environment or board configuration problem from an issue introduced by the additional task. I also noticed that your xTaskCreate() call uses a stack depth of 1024U, while the original working example uses 256U. Please restore the original value of 256U and test the unmodified example first. Note that this parameter specifies the number of stack elements, not the number of bytes, so using 1024U requires significantly more FreeRTOS heap.   Best regards, Pavel

Replacement of MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB Can we replace MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB Re: Replacement of MIMX8QM6AVUFFAB with MIMX8QP6AVUFFAB The replacement is practical if the design does not use the QuadMax-only compute/DSP resources and the QP-specific software and hardware checks pass.

I.MX6ULL ENET1 无法从物理层接收数据 I.M6ULL + 4.19.35 + KSZ 8081rnb  我们现场部署了300台这种设备。大多数情况下它们都能正常运行，业务/服务也能按预期运作。然而，我们偶尔会发现服务无法访问。经调查，我们发现 eth1 (ENET1) 停止接收数据包，即使其 LINK LED 指示灯常亮，ACT LED 指示灯有时闪烁。 此外，我们还验证了在 ENET1 上拔下并重新插入以太网电缆一次后，网络恢复正常。重启设备也能恢复它。请您帮忙分析一下可能的根本原因——是在物理层（PHY）还是媒体访问控制层（MAC）？ 从该寄存器读取的值如下： 我们读取的寄存器列表包括 MAC 寄存器和 PHY 寄存器。由于篇幅较长，全文列于下一页。 命令： phy eth1 0x1读取 PHY 寄存器 1。 内存工具 i.MX6UL Linux Re: I.MX6ULL ENET1 can't recv data from phy 你好@240697273 我们读取的寄存器列表包括 MAC 寄存器和 PHY 寄存器。由于篇幅较长，全文列于下一页。 我找不到这些登记簿。请重新发送。 B,R

KW45B41Z EVK not programming over on board Debugger MCU Link. Hi, I am trying to program the KW45B41Z-EVK using the kw45b41zevk_hello_world SDK example code. When I start debugging, the onboard debugger gets detected, but then I get the following error: 0 Available SWD Devices detected. Connect a device and try again. I have connected the USB cable to J14 and left JP22 open (to program using the onboard debugger itself). Also, JP28 pins 1 and 2 are shorted, as mentioned in the KW45UM. However, even after that, I am unable to program and debug the example. I have also tried the kw45b41zevk_led_blinky SDK example, but it behaves in the same way. I also tried using an external debugger to debug the board by shorting JP22, as mentioned in the KW45UM, but I am getting the same issue. I have attached a screenshot of the issue I am facing. I also tried to erase the flash and write the image using the Secure Provisioning Tool. First, I entered ISP mode by shorting JP25 to enable SW4, then long-pressed SW4 and Reset (SW3). Once the Test Connection passed, I erased the flash (location 0x00000000, size 0x100000) successfully. Then I used the following image: ${SPT_INSTALL_BIN}\data\sample_data\targets\KW45B41Z8\source_images\kw45b41zevk_led_blinky.s19 I was able to build and program the image successfully, and the intended RGB LED1 is also blinking indicating that KW45B41Z microcontroller is working fine. However, even after this, I am still unable to program or debug the board. Re: KW45B41Z EVK not programming over on board Debugger MCU Link. Hi, @kaif1  Which IDE are you using?  MCUXpresso IDE or MCUXpresso for VS Code? Let me have a try on my side, then let you know the default jumper settings. Best regards, Christine. Re: KW45B41Z EVK not programming over on board Debugger MCU Link. Hi, @kaif1  Please refer to my jumper settings, and I verified on my local side, I can flash hello_world example into the board successfully. And I am using MCUXpresso IDE with SDK 25.12.00. Please have a try with my jumper settings and then let me know whether it works for you . Best regards, Christine. Re: KW45B41Z EVK not programming over on board Debugger MCU Link. Since the Secure Provisioning Tool can successfully flash and run code on the chip, the physical hardware is completely fine, meaning the "0 SWD Devices detected" error stems from a communication mismatch between your IDE's debug probe server and the onboard MCU-Link firmware. This is usually resolved by updating the MCU-Link firmware to the latest version compatible with your IDE, or by manually holding down the reset button during the connection sequence to prevent a low-power application state from locking out the debug interface.

S32K3 上的 eTPU 曲柄、凸轮、喷射和点火装置 你好 我需要执行驱动程序，以根据曲柄和凸轮信号相位启动喷油和点火装置。 我需要了解实施该驱动程序的最佳解决方案是什么。 我的疑问是 1) AN4907SW.zip 提供的 API 是否与 S32K3xx 中的 eTPU 兼容？ 2）如果不是，那么将此 API 用于 S32K3xx 是一个好的解决方案，还是使用 ConfigTool 才是最佳解决方案？ S32K3xx 有关于此应用的示例吗？ 敬请期待，弗朗切斯科。 Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@francescovico 将数据从大端转换为小端序涉及通过根据数据类型大小调整位移和掩码来反转字节顺序。 GCC 提供了内置函数来简化这个过程，例如：uint32_t __builtin_bswap32 (uint32_t x)。你可以在 GCC 文档中找到更多细节：7.2.3 字节交换内置函数 Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@VaneB、 如果我理解得不错，汽车功能（CRANK、SPARK......）是为大位微控制器设计的。 要在 S32K364（小二进制）上使用带有汽车功能的 eTPU，我需要下载一个功能集，选择 .NET 和 .NET： francescovico_0-1761136257258.pngfrancescovico_0-1761136257258.png 并更改功能： uint32_t *fs_memcpy32(uint32_t *dest,uint32_t *source,uint32_t size); void fs_memset32(uint32_t *start,uint32_t value,int32_t size)； 交换每个 32 位的值，以读取/写入小端代码和参数，是这样吗？ 敬请期待，弗朗切斯科。 Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@francescovico 用于电气化应用的 S32K39/37/36 微控制器包括 eTPU。但是，目前没有适用于这些设备的与 MPC5634 的 AN4907 相似的专用文档或演示。 也就是说，AN4907 文档、演示和微码适用于 S32K39/37/36 系列，但请注意，这些设备使用小端架构。因此，您需要修改内存访问 API。 您可以参考 CodeWarrior eTPU 功能选择器 中与电机控制相关的模块，该功能 选择器 已更新为 little-endian。 BR、VaneB Re: eTPU crank, cam, injections and Ignitions on S32K3 感谢您指出这一点！ 这是个endianity转换问题。因此，缺齿掩模的配置不正确，每转 350 度，每周期 700 度。 现在，原帖中的演示程序已经修复。 Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@MilanBrejl、 现在，我正在尝试使用 Fuel Cyl 1 etpu 驱动程序。 驱动程序似乎使用 s24AngleNormalEnd 作为"的起始角度" ，并在 s24AngleStop 停止注入。 u24InjectionTime 的持续时间永远不会被遵守。 有可能吗？ 附件中有一个 .rar 文件该文件包含"燃料缸 1" 的 picoscope 采集信息，其中喷油器参数为： Etpu_Fuel_Ip_ConfigType fuel_1_config = { .s24AngleNormalEnd= DEG2TCR2(-180), .s24AngleStop= DEG2TCR2(-360), .s24AngleOffsetRecalc= DEG2TCR2(-30), .u24InjectionTime= USEC2TCR1(1200), .u24CompensationTime= USEC2TCR1(0), .u24InjectionTimeMinimum= USEC2TCR1(0), .u24OffTimeMinimum= USEC2TCR1(0), .eGenerationDisable= etpu_fuel_generation_allowed }； 在 picoscope 采集器中，可以看到注入开始点正好是 180°，注入停止点是 360°，注入持续时间为 30 毫秒（应为 1.2 毫秒）。 敬请期待，弗朗切斯科。 Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@MilanBrejl、 现在，我正在尝试使用 Fuel Cyl 1 etpu 驱动程序。 驱动程序似乎使用s24AngleNormalEnd 作为"的起始角度" ，并在 s24AngleStop 停止所有注入。 u24InjectionTime 的持续时间永远不会被遵守。 有可能吗？ 附件中有一个 .rar 文件文件，其中包含喷油器参数所在的"燃油 1 缸" 的 picoscope 采集结果： Etpu_Fuel_Ip_ConfigType fuel_1_config = { .s24AngleNormalEnd= DEG2TCR2(-180), .s24AngleStop= DEG2TCR2(-360), .s24AngleOffsetRecalc= DEG2TCR2(-30), .u24InjectionTime= USEC2TCR1(1200), .u24CompensationTime= USEC2TCR1(0), .u24InjectionTimeMinimum= USEC2TCR1(0), .u24OffTimeMinimum= USEC2TCR1(0), .eGenerationDisable= etpu_fuel_generation_allowed }； 在 picoscope 采集器中，可以看到注入开始点正好是 180°，注入停止点是 360°，注入持续时间为 30 毫秒（应为 1.2 毫秒）。 敬请期待，弗朗切斯科。 Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@MilanBrejl、 你说得没错，s24AngleOffsetRecalc 必须是正数，但要把它放进去： s24AngleOffsetRecalc = DEG2TCR2(30) 结果还是一样（......）。 我使用的 S32K364 有 2 个 ETPU（A 和 B），共 16 个通道。 在 ETPUA 上使用燃料驱动程序，驱动程序工作正常，但我需要使用 ETPUB 通道 0。 我需要使用 STAC 寄存器将 TCR1 和 TCR2 从 ETPUA 共享到 ETPUB。 可能是 STAC 寄存器没有正确初始化？ 敬请期待，弗朗切斯科。 Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@francescovico， 这是如何配置 STAC_ENG1 和 STAC_ENG2 寄存器，以便从 eTPU1 到 eTPU2 共享 TCR1 和 TCR2： MilanBrejl_0-1770199430269.pngMilanBrejl_0-1770199430269.png 如果有帮助，请告诉我。 致： Milan Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@MilanBrejl、 我的注册表与您的建议完全相同： ETPU_A_B_REGISTER.pngETPU_A_B_REGISTER.png 但问题依然存在。 在所附的皮镜采集中，您可以看到 ETPU A 产生的火花为蓝色，ETPU B 产生的火花为红色。 两个火花的端角都是 180 度，停留时间都是 8000 秒。 敬请期待，弗朗切斯科。   Re: eTPU crank, cam, injections and Ignitions on S32K3 你好，@francescovico、 我在我的网站上复制了你的问题，并找到了根本原因。在两个 eTPU 引擎之间共享 TCR1/TCR2 时间/角度总线是不够的。火花和燃油功能根据发动机的实际转速进行时间到角度的转换。它使用 TRR（跳动速率寄存器）。该寄存器是角度时钟逻辑的一部分，由运行在 eTPU A 上的 Crank eTPU 功能维护。然后，使用 eTPU B TRR 对 eTPU B 进行时间到角度的变换会返回错误的结果。 这是最基本的问题，我可能从未见过有人同时在两个 eTPU 引擎上运行引擎控制，因此这个问题一直没有得到解决。尤其是在新的 S32K3 设备仅限于 16+16 个通道的情况下，这一点变得很重要。感谢您提出这个用例，也感谢您的耐心。 所附的演示程序以之前的程序（在本主题中）为基础，并增加了以下改动： 火花 2 通道从 eTPU 引擎 A 移至 eTPU 引擎 B MilanBrejl_0-1770672522362.pngMilanBrejl_0-1770672522362.png 相应更新通道掩码 MilanBrejl_1-1770672675064.pngMilanBrejl_1-1770672675064.png 通道链接需要支持两个引擎的使用（使用宏 ETPU_IP_CHANNEL_TO_LINK） MilanBrejl_2-1770672729220.pngMilanBrejl_2-1770672729220.png 引脚配置已更新，中断配置已更新 现在是 Crank eTPU FW 的新功能： 更新 eTPU FW 映像。曲柄功能可在两个发动机上运行，并更新另一个 eTPU 发动机的 TRR 值。 这项新功能需要在曲柄配置中设置一个新参数 MilanBrejl_4-1770673143063.pngMilanBrejl_4-1770673143063.png 其中 MilanBrejl_3-1770673103441.pngMilanBrejl_3-1770673103441.png 希望对您有所帮助。 致： Milan Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@MilanBrejl、 现在它工作得很好。 非常感谢你们的支持！ 敬请期待，弗朗切斯科。 Re: eTPU crank, cam, injections and Ignitions on S32K3 您好，我也在研究k396的板子，也想将etpu用于曲轴凸轮轴和喷油，我们可以交流一下嘛 Re: eTPU crank, cam, injections and Ignitions on S32K3 嗨@MilanBrejl 我目前正在开发基于S32K396芯片的V12 ECU项目。 第一个原型我将使用 lqfp176 封装，很高兴看到这个项目也是用这种封装编写的。我想请问一下，是否有办法为 crank_instance 添加更多链接通道？ Etpu_Crank_Ip_InstanceType 曲柄实例= { .u8ChanNum = ETPU_CRANK_CHAN ，​ .u8OtherEngChanNum = ETPU_CRANK_OTHER_ENG_CHAN ,​ . ePriority = ETPU_PRIORITY_HIGH , . ePolarity = ETPU_CRANK_IP_POLARITY_FALLING , .u8TeethTillGap = TEETH_TILL_GAP ，​ .u8TeethInGap = TEETH_IN_GAP ，​ .u8TeethPerCycle = TEETH_PER_CYCLE ，​ . u24Tcr2TicksPerTooth = TCR2_TICKS_PER_TOOTH , .u24Tcr2TicksPerAddTooth = 0 ，​ .eLogToothPeriods = ETPU_CRANK_IP_LOG_TOOTH_PERIODS_ON ,​ .u32LinkCam = ( ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_CAM_CHAN ) << 0 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_CAM_CHAN ) << 8 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_CAM_CHAN ) << 16 ) + （ ETPU_IP_CHANNEL_TO_LINK （ ETPU_CAM_CHAN ） << 24 ） ） .u32Link1 = ( ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_SPARK_1_CHAN ) << 0 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_SPARK_2_CHAN ) << 8 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_SPARK_3_CHAN ) << 16 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_SPARK_4_CHAN ) << 24 )) , .u32Link2 = ( ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_FUEL_1_CHAN ) << 0 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_FUEL_2_CHAN ) << 8 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_FUEL_3_CHAN ) << 16 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_FUEL_4_CHAN ) << 24 )) , .u32Link3 = ( ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_KNOCK_1_CHAN ) << 0 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_KNOCK_2_CHAN ) << 8 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_INJ_BANK_1_CHAN ) << 16 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_INJ_BANK_2_CHAN ) << 24 )) , .u32Link4 = ( ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_INJ_1_CHAN ) << 0 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_INJ_2_CHAN ) << 8 ) + ( ETPU_IP_CHANNEL_TO_LINK ( ETPU_INJ_3_CHAN ) << 16 ) + （ ETPU_IP_CHANNEL_TO_LINK （ ETPU_INJ_4_CHAN ） << 24 ） ） .pCpba = NULL_PTR ，​ . pCpbaToothPeriodLog = NULL_PTR } ； 我想使用 eTPU 发动机 A 来实现 12 缸 DI、12 缸点火和曲轴、右侧进气凸轮轴、右侧排气凸轮轴，使用 eTPU 发动机 B 来实现 12 缸 PI 喷射和左侧凸轮轴。 或者 eTPU 发动机 A 适用于 6DI、6Ignition、6PI、Knock、RH CAMx2，eTPU 发动机 B 适用于 6DI、6Ignition、6PI、Knock、LH CAMx2。 但为此我还需要另外两个链接条目。我还没算上我可能还需要的其他东西呢。我需要WMI，也需要Nitro。我知道这是个大工程，但我真的非常感谢大家的帮助。 我是 eTPU 编程新手，对整个 NXP 生态系统也不熟悉。 感谢您的解答。 理查德 Re: eTPU crank, cam, injections and Ignitions on S32K3 你好@rudikakk11 ， 如果当前参数集 .u32Link1 到 .u32Link4（最多 16 个通道） 扩展至 .u32Link1 到 .u32Link12（最多 48 个通道） 你觉得可行吗？ 问候， 米兰 Re: eTPU crank, cam, injections and Ignitions on S32K3 嗨@MilanBrejl 那真是太好了！ eTPU编译器都是付费使用的吗？以防我需要任何其他修改或自定义功能。 感谢您的回复，也提前感谢您的下次回复！ 理查德

how to read lpddr5's mr with imx95 HI experts:      As title , how to read LPDDR5's MR register with imx95 ?  I have reference to the BSP of imx8mp and imx9,  and found the code " lpddr4_mr_read"  . But I found that they are difference, and there is no mention of how to read MR in reference manual. Best Regards. Yocto Project Re: how to read lpddr5's mr with imx95 HI db16122: I want to read the "manufacturer id" in imx-oei for difference DDR compatible.   Re: how to read lpddr5's mr with imx95 please refer to User Guide for Config Tools for i.MX.-Which MR is most important？ Re: how to read lpddr5's mr with imx95 IMX95 DDR initialized in the oei/ddr. An only MR write is used, no read examples. DDRC->DDR_SDRAM_CFG |= DDRC_DDR_SDRAM_CFG_MEM_EN_MASK; Thanks

i.MX 95:M7とA55間の動的TRDC/システムマネージャーリソース割り当ておよびGPIO共有 こんにちは、チームのみなさん。 私たちは i.MX 95プラットフォームを開発しており、まずM7コアからMIPI DSIペリフェラルを使用し、その後実行時にリソースをA55コアに引き渡したいと考えています。 私たちの理解では、周辺リソースとその所有権は 、 System Managerツール を通じて生成・設定 された mx95evk.cfg ファイル内の各論理マシン/プロセッサごとに最初に定義されています。 以下の点について明確にしておきたいと思います。 動的リソースハンドオーバー: 実行時にM7からA55へMIPI DSIペリフェラルリソースを動的に移すことは可能でしょうか?例えば、M7は最初にMIPI DSIを所有・使用し、その後リリースし、その後A55が所有権を取得し同じペリフェラルを使用します。 動的リソース配分: ランタイムハンドオーバーがサポートされている場合、リソースの所有権やアクセス権限を動的に変更するための推奨されるメカニズムやAPIは何ですか?これはSystem Manager、TRDC、または他の仕組みで処理されるのでしょうか? GPIO共有: 同じGPIOポート/リソースをM7とA55の両方が同時にアクセスすることは可能でしょうか?もし可能なら、GPIOリソースを安全に共有するためにTRDCの設定要件やソフトウェア同期メカニズムを実装する必要がありますか? i.MX 95におけるM7とA55間の動的ペリフェラルハンドオーバーやリソース共有の実装方法について、推奨される方法についてのご指針をいただけるとありがたいです。 Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 こんにちは、 i.MX 95では、MIPI DSIリソースは当初M7で使用され、後にA55に引き継がれます。リソースアクセスと所有権はSystem Manager/TRDCの設定で設定し、実際のランタイムハンドオーバーはソフトウェアで処理すべきです。TRDCはどの論理マシン/ドメインが周辺機器にアクセスできるかを制御しますが、M7とA55間の同期は管理しません。したがって、M7はまずすべてのDSI操作を完了し、ペリフェラルの使用を停止し、A55が制御を取る前にMU/IPCなどのコア間機構を通じてA55に通知すべきです。同様に、GPIOリソースは適切なTRDC構成を通じてM7とA55の両方にアクセス可能ですが、同時アクセスはソフトウェアによる同期が必要です。DSIのユースケースでは、同時に1つのコアだけがペリフェラルをアクティブに使い、ハンドオーバーはMU/IPCで行うのが推奨されます。 Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 AEチームと話し合った結果、以下のアップデート内容をご参照ください。 i.MX 95では、リソース所有権とTRDC権限は、SM構成ファイル（mx95evk.cfg）でビルド時に静的に定義されます。→はconfig_.h)を生成し、MIXが起動するとシステムマネージャー(SM)によって適用されます。*実行時に周辺機器の所有権を論理マシン(LM)から別の論理マシンへ移すSCMI/SMメッセージはありません。 しかし、SMのドキュメントでは「ディスプレイを別のLMへ引き継ぐこと」がSM_SCMI_PERM_EXCLUSIVEモデルの正確な動機として挙げられています。したがって、引き継ぎは可能ですが、所有権を「移動」するだけでは不可能です。 Q1 & Q2 — MIPI DSI M7 → A55 ハンドオーバー:やり方 LMM(論理マシン管理)SCMIプロトコルは、LMの起動・リセット・シャットダウン・サスペンド・ウェイクのみを行い、RESOURCE_ASSIGNやメッセージOWNERSHIP_TRANSFERはありません。代わりに、時間分割ハンドオフを使用してください。 mx95evk.cfgで両方のLMに最初にアクセス権を付与してください。デフォルトでは、EVK の設定により、MIPI_DSI、MIPI_PHY、DC_DISPENG、BLK_CTRL_DISPLAYMIX、ディスプレイのクロック/電源 (PD_DISPLAY、CLK_DISP*)が AP (LM2) の所有者としてのみ割り当てられます。M7 を優先的に使用するには、これらを M7 LM (LM1) にも追加する必要があります。 SM管理リソース(クロック、電源、リセット)をSM_SCMI_PERM_EXCLUSIVE(api=all)としてマークし、2つのLMからのリクエストが静かに集約・上書きされないようにします。 ハンドオーバー時にM7はDSI/DCIFを静止し、アプリケーションレベルのIPC(MUメールボックスまたはSCMI通知)を通じてA55に信号を送ります。A55(Linux/DRM DSI+DPUスタック)は同じIPを表示します。 ハンドオフシーケンスはお客様のソフトウェア責任(時間的区分)です。SMは、両方のLMが事前にアクセス許可されているため、HWがどちら側からも運転可能であることを保証しています。TRDCの所有権は実行時に書き換えられず、SMプログラムのみがTRDCを実行し、MIX電源投入時の静的設定からのみ可能です。 これを制御するTRDC設定（.cfgファイルに記載）： MDAC_am=... — マスタードメイン割り当て(バス・マスタをドメインIDにマッピング) MBC_am=s.b— メモリブロックチェック — ここでペリフェラルアクセスがゲートされます MRC_am=… — メモリ領域チェック（DDRなどの大規模メモリ領域） 各LMはDIDにバインドされます。例：SMは2、AP(LM2)は3、M7(LM1)は4でした。 Q3 — M7とA55の間でGPIOを共有 はい、TRDCはM7ドメインとA55ドメインの両方に同じGPIOインスタンスへの同時アクセスを許可できます(両方のDIDでMBCブロックを有効にすること)。しかし、重要な注意点と、支持される2つのパターンがあります。 注意点:i.MX 95 GPIOにはハードウェア仲裁機能がなく、PDR/DR/GDIRレジスタは物理的に共有されるため、両コアレースから非調整の読み書き・修正・書き込みが可能です。 パターンA（分離ピン＋ソフトウェア同期）：慣例に従って各コアに特定のピンを割り当てます（設定では既にLMごとにピンが分割されています）。データ/方向レジスタバンクは依然として共有されているため、ハードウェアセマフォ/MUを使用して同時RMWを保護するか、コアが同じレジスタバンクに同時にアクセスしないようにしてください。 パターンB(SM仲裁、真に共有されたインスタンスに推奨): SMが所有し、文書化された役割は 「共有アクセスの仲裁 」とされる常時接続 GPIO1 を経由します。IOMUXC/IOMUX_GPRも同様にSMによって調停されます。Pinmux/daisyは、エージェントごとの権限を持つSCMIピン制御プロトコルを介して設定されます。GPIOデータ操作は直接MMIOで行われます。 Re: i.MX 95: Dynamic TRDC/System Manager Resource Allocation and GPIO Sharing Between M7 and A55 チームの皆さん、こんにちは。 私たちは i.MX 95の19x19 EVK を使っており M7とA55/Linux 間のLVDSディスプレイハンドオーバーを以下のアーキテクチャで実装しようとしています。 M7: 当初はLVDSディスプレイを所有し、制御する。 A55/Linux: その後、Linux起動後にディスプレイの制御を奪います。 現在の実装 開発の初期段階として、LVDSディスプレイをM7によって初期化および制御するように設定しました。M7はディスプレイの初期化に成功し、フレームバッファを青色で埋め尽くし、それがLVDSパネルに正しく表示されます。 以下のリソースをデフォルトのA55所有権から M7に変更しつつ、A55へのアクセスは提供しました。 DC DC0 DC1 DC_CMDSEQ DC_DISPENG DC_DISPENG_INT DC_FL0 DC_FL1 DC_INT_CTL DC_PIXENGINE DC_XPC DC_YUV0 DC_YUV1 DC_YUV2 DC_YUV3 BLK_CTRL_DISPLAYMIX LVDS MIPI_PHY LDB_PLL CLOCK_DISP1PIX ビデオPLL1 PIN_I2C2_SCL PIN_I2C2_SDA LPI2C2 観察された行動 現在の動作は以下のとおりです。 M7は起動し、ディスプレイの初期化に成功した。 青色で塗りつぶされたフレームバッファは、LVDSパネル上に正しく表示されます。 M7の動作中は、ディスプレイは表示されたままになります。 その後、A55/Linuxの起動プロセスが始まります。 Linuxカーネルが起動すると、ディスプレイが真っ白になります。 次のデバイスツリーを使用する場合：fdtファイル imx95-19x19-evk-it6263-lvds1.dtbLinuxはカーネル起動時に常に進行が止まります。 カーネルパニックやコンソール上の明確なエラーメッセージは確認されませんでした。起動プロセスが進行しなくなる。 資源所有権調査 私たちの理解によれば、リソース所有権は System Managerの設定 を通じて静的に設定されており、SCMIメッセージを通じて論理マシン間で所有権を動的に移譲することはできません。 そこで、表示資源をM7とA55の両方に割り当てられるかどうかを調査しました。 しかし、重要なDCリソースの中には、二重所有を支持していないものもあります。特に以下の通りです: DC DC_XPC DC_YUV0 DC_YUV1 DC_YUV2 DC_YUV3 DC_FL0 DC_FL1 DC_2DBLIT これにより、LinuxがDRM/DPUやIT6263/LVDSの初期化時にM7専用の表示リソースにアクセスしようとしている可能性が示唆されます。 質問 以下の点を明確にしていただけますか? 1. DC 、 DC_XPC 、 DC_YUV *、 DC_FL* 、または DC_2DBLIT などのリソース がM7独占的に所有されている場合 、Linuxがハングすることは予想されます か?   2. Linuxの起動時およびDRM/DPU、IT6263/LVDSの初期化時にA55/Linuxがアクセスするディスプレイリソースは? 特に、以下の人々が正確にどのようなリソースにアクセスしているのかを理解したいと思います: LinuxのDRM/DPU ディスプレイコントローラ(DC) IT6263ドライバ LVDS/LDBドライバ ディスプレイクロック/PLL構成 3. 以下のシーケンスを可能にするサポートされたSystem マネージャのリソース所有設定はありますか? M7はLVDSディスプレイを初期化し、駆動します。 A55/Linuxは正常に起動します。 その後、A55/Linuxがディスプレイの制御を引き継ぎます。 両方の論理マシンはハンドオーバーに必要なリソースにアクセスできます。 4. DアドレスリソースがM7とA55間で共有できない場合、M7のディスプレイとA55/Linuxの共存またはディスプレイハンドオーバーの推奨アーキテクチャは何でしょうか?   5. A55/Linuxは、起動初期段階でディスプレイを積極的に駆動することを意図していなくても、DCリソース階層全体の所有権を必要とするのでしょうか?   6. このユースケースで、以下の部分で追加の構成変更が必要か? System マネージャリソース構成 TRDCの権限 SCMI構成 Linuxデバイスツリー ディスプレイ/LVDS構成 7. Linuxのブートハングは、特にIT6263/LVDSディスプレイパスの初期化時に、A55/LinuxがM7が所有するディスプレイリソースにアクセスしようとした際に起こる可能性はありますか?     現段階の主な目的は、 早期起動時やDRM/DPU、IT6263/LVDS初期化時にLinuxがアクセスする正確な表示リソース を特定し、それらのリソースがM7の所有権と共存できるかどうかを判断することです。 参照のために System Managerの設定ファイル(.cfg)とLinuxのブートログを添付しています 。 サポートされているリソース所有権構成、表示リソースの依存関係、または実装のための推奨アーキテクチャに関するガイダンス M7/A55 LVDSディスプレイの引き継ぎ 大変ありがたく思います。   よろしくお願いします。  

i.MX95 19x19 EVK – M2-JODY-W6 Wi-Fi 卡的可用性和相机模块兼容性 您好，NXP团队， 我们正在与 NXP i.MX95 19x19 EVK (IMX95LPD5EVK-19) 合作开发 Android Automotive OS 项目。 我们想就以下问题获得澄清： 1. M2-JODY-W6 无线网卡 我们的 i.MX95 EVK 套件中不包含 M2-JODY-W6 Wi-Fi 卡。 请问您能否提供以下信息： - M2-JODY-W6 Wi-Fi 卡的供货情况 - 我们如何获得/购买这张卡 - NXP是否提供样品或推荐的订购渠道 - i.MX95 19x19 EVK 所需的任何文档或兼容性信息 2. 摄像头模块兼容性 我们还希望获得有关 i.MX95 19x19 EVK 官方支持/验证的相机模块的信息。 请问您能否提供以下信息： - 推荐/已验证的摄像头模块 - 确切的模块/零件编号 - 使用的相机传感器 - 硬件连接/接口信息 相关文件 - Linux/Android 驱动程序或软件支持信息 - 任何可用的参考设计或配置信息 板： NXP i.MX95 19x19 EVK 零件编号：IMX95LPD5EVK-19 软件： Android Automotive OS 16 NXP BSP 希望您能就以上问题提供指导。 谢谢，此致敬礼！ 格纳纳·普拉桑纳·古纳卡拉 Re: i.MX95 19x19 EVK – M2-JODY-W6 Wi-Fi Card Availability and Camera Module Compatibility 你好， 第一个问题请提交技术案例，第二个问题请参考以下应用笔记： https://www.nxp.com/docs/en/application-note/AN14853.pdf 此致问候

i.P-384秘密鍵/ブラックブロブの利用ケースにおけるMX8DXL CAAMカバーの制限 こんにちは、NXPチームの皆様、 私たちは、i.MX8DXL CAAMにおけるECDSA P-384ブラックキー/ブロブのサポートを評価しています。 観察された結果 P-256 外部から提供された平文のP-256秘密鍵から開始します。 プレーンテキストキー → カバー → 黒いキーの塊 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：合格 P-384（CAAM生成の黒鍵） ECDSA秘密鍵をKEY_COLOR_BLACKとして生成する COVER操作なしで秘密鍵からブラックブロブを生成する 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：合格 P-384（外部平文秘密鍵） 外部から提供された平文のP-384秘密鍵（48バイト）から開始します。 プレーンテキストキー → カバー → 黒いキーの塊 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：失敗 追加の観察 NXPのパッチに以下のコメントがあることに気づきました。 https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch /* * KEYコマンドは32バイトに制限されているようなので、ロードを使うべきです * コマンドは最大64バイトまで読み込み可能です。 * * TODO: KEYコマンドは、より大きなキーをロードできるようにする必要があることを示しています * 32バイトより小さいが、実際には機能しない * * TODO: LOAD コマンドは最大 96 までロードできるはずです * バイトキーは実際には機能せず、64バイトに制限されています */ 我々も同様の挙動を観察した。 KEYコマンドの代わりにLOADコマンドを使用することで、48バイトのP-384秘密鍵を含む、32バイトを超える鍵を扱うことができます。 しかし、これは上記の問題を解決するものではありません。鍵は覆ってブロブに保存できますが、復元された黒鍵はECDSA署名や検証に成功裏に使用できません。   私たちの質問： CAAM COVER操作において、32バイトを超えるECC秘密鍵に対する既知の制限事項はありますか？ COVER経由で外部のP-384平文秘密鍵をインポートし、それをECDSAのブラックキーとして使うことはサポートされているユースケースでしょうか? 観測された動作は、CAAMハードウェアの制限によるものなのでしょうか？ 外部生成されたP-384平文秘密鍵をインポートし、それをECDSA操作のブラックキーとして使う推奨されるCAAM方法はありますか? 何かアドバイスをいただければ幸いです。 ありがとうございます。よろしくお願いいたします。 ホジャメス。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 補足事項：   私たちの懸念はECDSAのユースケースに限られません。   COVERを介して外部のP-384秘密鍵をインポートすることがECDSAの標準ワークフローではないとしても、COVER操作自体の制限事項を理解しておきたいと考えています。   当社のアプリケーションでは、COVER操作はECDSA秘密鍵だけでなく、一般的な機密データの保護にも利用されることがあります。したがって、32バイトを超えるペイロードサイズのサポートは重要な考慮事項です。 我々のテストに基づくと、LOADコマンドの回避策を用いることで、32バイトを超えるペイロードを処理できることがわかった。約80バイト以下のペイロードは正常に動作するようですが、それより大きいサイズでは動作が不安定になります。これらの観察結果が、実際のCAAMの制限を反映しているのか、それとも実装上の問題を反映しているのかを理解したいと考えています。 また、ECDSAのユースケースとは独立して、COVER操作自体に文書化されたサイズ制限があるかどうかもNXPは明確にしていただけますか?   よろしくお願いします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case このCAAM機能をテストするための環境を構築する必要があります。結果が出次第、ご連絡いたします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case こんにちは、イーピンワンさん ご返信ありがとうございます。 >>この部分で、どのようなCAAMエラーが発生していましたか？ >>エラーコードを教えてもらえますか? ECDSA関連のすべての操作には、以下のコードパッチを使用しています。 " https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0001-linux-imx-4.14.78_1.0.0_ga-ecdsa-primitives-using-caam.patch " 署名検証のために caam_ecdsa_verify() を呼び出すとき、 'ECDSA_VERIFY_FAIL (0)' を返します。 このエラーは「P-384 (external plaintext private key)」の場合のみ発生します。 >> アプリケーションノート「CAAMセキュアキーを用いた公開鍵暗号のAN12838強化」では、ブラックキーを用いたECDSA署名のデモが説明されていますが、同様の実装でテストしていますか? 私たちの成功例については、はい、似ています。 しかし、失敗したケース『P-384(外部平文秘密鍵)』については、 少し違います。鍵は外部から来ています。 よろしくお願いいたします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 「プレーンテキストキー → カバー → 黒キーの塊」 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：失敗 この部分で、どのようなCAAMエラーが発生していましたか？エラーコードを教えてもらえますか?アプリケーションノート「CAAMセキュアキーを用いた公開鍵暗号のAN12838強化」では、ブラックキーを用いたECDSA署名のデモが説明されていますが、同様の実装でテストされていますか?ありがとう。 KEYコマンドの制限については、現在も調査中です。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 失敗した場合、「KEY」コマンドと「FIFO STORE」コマンドを使って、平文の秘密鍵に基づいて黒鍵を生成していますか?失敗時に使われるCAAMの記述子(十六進形の単語)を捨てることは可能ですか?コマンドとパラメータを確認する方が簡単でしょう。ありがとう。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case こんにちは、イーピンワンさん >>失敗したCASEのために、 >>「KEY」コマンドと「FIFO STORE」コマンドを使っていますか? >>平文の秘密鍵に基づいて黒鍵を生成するのですか? いいえ、KEYコマンドではなくLOADコマンドを使用しています。 この場合、キーは48バイト(P384)です。 < https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch > に記載されているとおりです。 「KEYコマンドは32バイトに制限されているようだ。だからロードを使うべきだ * コマンドは最大64バイトまで読み込める。 KEYコマンドで48バイトのキーを使用すると、DECOエラーが報告されます。 ジョブリングステータス: 0x40000106、 DECO、06h - 無効なKEYコマンド そこで、上記のパッチコードと同じLOADコマンドを使うようにコードを変更しました。 ありがとうございます。よろしくお願いいたします。

如何使用 IMX95 读取 LPDDR5 的 MR HI专家： 如题，如何使用imx95读取LPDDR5的MR寄存器？我参考了 imx8mp 和 imx9 的 BSP，并找到了代码“lpddr4_mr_read”。但我发现它们之间存在差异，而且参考手册中也没有提及如何阅读 MR。 顺祝商祺！ Yocto Project Re: how to read lpddr5's mr with imx95 嗨 db16122： 我想读取imx-oei文件中的“制造商ID”，以区分DDR内存是否兼容。 Re: how to read lpddr5's mr with imx95 请参阅 i.MX 配置工具用户指南。MR最重要吗？ Re: how to read lpddr5's mr with imx95 IMX95 DDR 在 oei/ddr 中初始化。 仅使用 MR 写入，没有读取示例。 DDRC->DDR_SDRAM_CFG |= DDRC_DDR_SDRAM_CFG_MEM_EN_MASK; 谢谢！

i.MX95 19x19 EVK – M2-JODY-W6 Wi-Fiカードの入手可能性とカメラモジュールの互換性 NXPチームの皆様、こんにちは。 私たちはAndroid オートモーティブ OSプロジェクトのためにNXP i.MX95 19x19 EVK(IMX95LPD5EVK-19)を使用しています。 以下の点についてご説明をいただきたい。 1. M2-JODY-W6 Wi-Fiカード M2-JODY-W6 Wi-Fiカードは、当社のi.MX95 EVKキットには含まれていません。 以下の情報を教えていただけますか: - M2-JODY-W6 Wi-Fiカードの入手可能性 - カードの取得・購入方法 - NXPがサンプルまたは推奨ご注文チャネルを提供するかどうか - i.MX95 19x19 EVKに必要なドキュメントや互換性情報 2. カメラモジュールの互換性 i.MX95 19x19 EVKで公式にサポート/検証済みのカメラモジュールに関する情報も提供していただけると幸いです。 以下の情報を提供していただけますか: - 推奨/検証済みカメラモジュール - 正確なモジュール/部品番号 - 使用カメラセンサ - ハードウェア接続/インターフェース情報 - ドキュメント - Linux/Androidドライバまたはソフトウェアのサポート情報 - 利用可能なリファレンス・デザインや構成情報 ボード： NXP i.MX95 19x19 EVK 部品番号：IMX95LPD5EVK-19 ソフトウェア: Android オートモーティブ OS 16 NXP BSP 上記の質問について、ご助言いただければ幸いです。 よろしくお願いいたします。 グナナ・プラサンナ・グナカラ Re: i.MX95 19x19 EVK – M2-JODY-W6 Wi-Fi Card Availability and Camera Module Compatibility こんにちは、 最初の質問については技術的なケースを開いてください。2つ目の質問については以下のANを参照してください:https://www.nxp.com/docs/en/application-note/AN14853.pdf  よろしくお願いします。

ubuntu では、mcuxpresso-secure-provisioning パッケージを使用して、固 定ファイルに名前を付けて、コアシートに書き込みます。 まず、私が使用したチップはMCXN947です。 mcuxpresso-secure-provisioning-26.09-1_amd64-ubuntu26.debパッケージをUbuntuシステムにダウンロードしてインストールしました。 では、このソフトウェアを使って署名され暗号化されたSBフォーマットファイルをどうやって生成すればいいのでしょうか? 私はビデオを見て、bin ファイルに署名と暗号化を行い、Windows システムで sb ファイルをチップに正常に書き込みました。 Ubuntuシステムを操作する方法に関するビデオはありますか？バイナリファイルに署名および暗号化するためのコマンドラインに関するドキュメントはありますか？ よろしくお願いします。 Re: 在ubuntu上，怎样使用 mcuxpresso-secure-provisioning 软件给固件签名加密并烧写到芯片 こんにちは、 @justdomyself ドキュメント:https://docs.mcuxpresso.nxp.com/secure/latest/ MCXNデバイスのワークフローを説明する章： https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#n23x-n24x-n52x-n53x-n54x-n94x-device-workflow コマンドラインサポート:https://docs.mcuxpresso.nxp.com/secure/latest/08_command_line_operations.html 関連項目 securep.exe print - cli - examples UbuntuとWindowsのユーザー体験は非常に似ています。問題が発生した場合は、トラブルシューティングのセクションを参照してください。https: //docs.mcuxpresso.nxp.com/secure/latest/09_troubleshooting.html

FreeRTOSシステムは実行できません（作成直後は実行できません）。 仕様書に従ってプロジェクトプログラムを作成した後、FreeRTOSシステム上で実行できないことがわかりました（調査の結果、メモリ不足の問題ではなく、優先度の高い問題でもないことがわかりました）。S32DSコンパイラのバージョンは、以下の画像に示されています。 タスクの作成に失敗しました。このバージョンはFreeRTOSをサポートしていないのでしょうか？それとも、特別な設定要件があるのでしょうか？ Re: freertos 系统跑不通问题（创建即跑不通） こんにちは、@sunshine88 さん。 申請が sys_msleep(5000) コール自体のせいで止まっているわけではありません。この動作は、 sys_now() で使用されている時間ベースが増加していないことを示しています。したがって、 sys_msleep() 内のタイムアウト条件には決して到達できません。 OSIF構成のスクリーンショットでは、 OsIfUseSystemTimer が有効になっており、オペレーティングシステムの種類はFreeRTOSに設定されています。しかし、 OsIfCounterConfig_0 の下の参照、カウンタとシステムタイマークロックの参照を含め、不完全または空であるようです。PITコンポーネントを追加するだけでは、OSIFタイムベースが正しく構成および初期化されることを保証するものではありません。 現時点では、TCP/IPスタックのソースコードを変更したり、別の遅延回避策を実装したりしないでください。代わりに、私は以下のことをお勧めします。 インストールされたTCP/IPスタックパッケージから元の lwip_FreeRTOS_s32K358 例をインポートしてください。 元のサンプルを一切変更せずにビルドして実行してください。 元の例で sys_now() が増加するかどうかを確認してください。 FreeRTOS、BaseNXP/OSIF、PIT、クロック、割り込み、およびTCP/IPスタックの設定を、カスタムプロジェクトと比較してください。 生成された初期化シーケンスに、必要なBaseNXP/OSIFおよびタイマーの初期化が含まれていることを確認してください。 カスタムプロジェクトを正しく分析するためには、以前にご依頼した情報が引き続き必要です。 正確なMCU部品番号; 正確な評価ボードまたはカスタムボード; 出発点として使用された元の事例またはプロジェクトの種類。 変更されていない lwip_FreeRTOS_s32K358 の例が同じハードウェアで動作するかどうか。 sys_now() の生成された実装。 xTaskGetTickCount() によって返される FreeRTOS ティック カウントが増加しているかどうか。 まず xTaskGetTickCount() を確認してください。 sys_now() が一定のままでが増加する場合、FreeRTOSスケジューラとティック割り込みが実行されており、問題は具体的にはOSIFタイムベースの設定または初期化にあります。 xTaskGetTickCount() も一定のままであれば、問題はより根本的なものであり、FreeRTOSのティック割り込みまたはスケジューラ構成を調査する必要があります。 可能であれば、構成スクリーンショットだけでなく、プロジェクト全体のアーカイブも提供してください。生成された構成コードと初期化コードがないと、 sys_now() が実際にどのタイマーまたはクロックソースを使用しているかを判断することはできません。 よろしくお願いいたします。 パベル Re: freertos 系统跑不通问题（创建即跑不通） こんにちは。LWIPプログラムルーチンを作成しましたが、Ethernet mainLoopTaskタスクがsys_msleep(5000);で停止してしまい、遅延させることができません。この関数をステップ実行すると、startTime = sys_now(); と表示されますが、sys_now()関数はカウントできません。現在の設定ページは以下のとおりです。何が原因でしょうか？非常に困惑しています。 Re: freertos 系统跑不通问题（创建即跑不通） こんにちは、@sunshine88 さん。 スクリーンショットに表示されているバージョンはFreeRTOSをサポートしているはずです。S32 Design Studio 3.5 アップデート14、RTD 4.0.0、FreeRTOS 4.0.0、およびTCP/IPスタック1.0.4これは予想されるパッケージの組み合わせのようで、一般的なバージョン互換性の問題とは思えません。 示されているコードによると、エラーはxTaskCreate()関数内で直接発生しています。以下の情報を教えていただけますか? 正確なMCU部品番号と評価ボード、またはカスタムボードが使われているのです。以前S32K358とおっしゃっていましたが、正確なデバイス名と基板名をお知らせください。 出発点として使用された元の例の名前。 xTaskCreate() によって返される値。 xTaskCreate() 呼び出しの前後で xPortGetFreeHeapSize() によって出力される値。 configTOTAL_HEAP_SIZE、configSUPPORT_DYNAMIC_ALLOCATION の設定値、および選択された FreeRTOS ヒープ実装 (例: heap_4.c)。 アプリケーションが停止する正確なポイント、特にアサーション、例外、ハードフォールハンドラに入るデバッガ呼び出しスタックも含まれます。 十分なMCU RAMがあっても、必ずしも十分なFreeRTOSヒープが利用できるとは限りません。xTaskCreate() は、FreeRTOS ヒープからタスク制御ブロックとタスクスタックの両方を動的に割り当てます。また、1024Uのスタック深度引数は通常、バイトではなくスタック要素を表すため、Cortex-M7の実際の割り当ては1024バイトより大きいです。 ベースラインテストとして、オリジナルのlwIP FreeRTOSサンプルを修正せずにインポートして実行することをお勧めします。元のサンプルが正常に動作したら、小さなスタックサイズ、通常の優先度、そしてループ内にvTaskDelay()呼び出しを含む追加タスクを追加してください。これにより、環境やボード構成の問題と、追加タスクによって引き起こされた問題を区別するのに役立ちます。 また、あなたの xTaskCreate() 呼び出しではスタック深度が 1024U であるのに対し、元の動作例では 256U を使用していることに気づきました。まず、元の値である256Uに戻し、変更を加えていないサンプルをテストしてください。このパラメータはバイト数ではなくスタック要素数を指定するため、1024Uを使うには大幅に多くのFreeRTOSヒープが必要です。   よろしくお願いします、 パベル

ベンダーのツールに関する経験 皆さん、こんにちは。ベンダーのハードウェアを扱う際に、ベンダーのツールを使った経験についてお聞かせください。例えば、NXPのLayerscapeシリーズやSTM32MP1シリーズのような製品について話してみましょう。私はNXPのLayerscape SoCの一つをベースにしたボードを作っていましたが、唯一提供されているツールが例えば、DDRはEclipseをベースにした**ピー音**IDEです。このツールの品質を考えれば、無料で提供しても文句は言わないでしょうが、ライセンス料はかなり高いです。IDEを使ってこれやあれをやりたいですか?頑張ってください。「私にできる精一杯」は、ほとんど100%正確ではなく、古い部分的なドキュメント、必ず答えが得られるフォーラム、誰かが対応してくれる、そして画面の内容がほとんど見えない240p動画です。DDRの立ち上げと検証にのみ使用し、残りの作業はこのツールなしで済ませたいと思っています。他のベンダーとの取引経験はいかがですか？TIはどうでしょうか？STのツールもいくつか見たことがありますが、確かにずっとシンプルに見えました。ただ、実際に使った経験はありません。 Re: Experience with vendor's tools こんにちは、 Eclipse ベースは老朽化しており、DDR ツール (DDR ストレス テスト ツール) は機能的ですが扱いにくく、ライセンス コストとの比較。品質比率は組み込みコミュニティでよく見られる不満です。ドキュメントのギャップは現実的で、AN(アプリケーションノート)は公式のツールドキュメントよりも優れたリソースであることが多いです。多くのエンジニアは、計画通りDDR PHYの開始やトレーニングに専念して使い、その後は次に進みます。   NXP Layerscape DDRの立ち上げに関する実践的なヒント 今のところはこれしか選択肢がないので： DDRストレステストツールのスタンドアロンバイナリ（CodeWarriorとは別）が利用可能な場合があり、そちらの方が軽量です。 NXPの i.MX/Layerscape コミュニティ(GitHub)には、ツール誘導作業を省略できるリファレンスDDR設定があります。 LSDK(Layerscape SDK) スクリプトは、DDR initパラメータをIDEよりも透明に公開することがあります。 よろしくお願いします。

Ibis model for Lx2160a Hi guys  I'd like to know  how can i get a ibis model for lx2160a, can anybody can help me with it ? Thanks a lot Yuan Re: Ibis model for Lx2160a IBIS models are not public, please create case here:  https://support.nxp.com/s/?language=en_US  And share your NDA. Thanks