中断在内存中运行，闪存擦除 我发现擦除闪存时无法进入定时器中断。为了满足我的需求，我计划在 RAM 中运行定时器中断。我修改了 linker_flash_s32k388.ld 文件，将 IntCtrl_Ip.o 和 Pit_Ip.o 放入 RAM 中，但是当我擦除闪存时，由于定时器中断的到来，我仍然会遇到错误。请告诉我我遗漏了哪些细节。#s32k388 Re: Pit interrupt runs in ram wen flash erase 你好， 只需放置 IntCtrl_Ip.o 和 Pit_Ip.o仅仅存入内存通常是不够的。在 PFLASH 擦除操作期间，CPU 必须避免对受影响的闪存阵列进行任何访问。 请确认中断向量表、PIT ISR、ISR 调用的所有函数以及 ISR 使用的任何数据/常量也位于 SRAM 中。此外，确保 VTOR 寄存器指向基于 RAM 的向量表。链接器映射文件通常是识别剩余闪存访问的最佳方法。 S32K3 参考手册还指出，当闪存操作需要持续执行时，代码执行必须移至 SRAM。 顺祝商祺！ Peter

i.MX95 OEIおよびDDR PHYファームウェアへのカスタムLPDDR5タイミングの統合に関する説明 NXPチームの皆様、こんにちは。 i.MX9596プロセッサをベースにしたカスタムボードを、i.MX OEIブートローダーを使ってLPDDR5メモリを導入します。 MCUXpresso Config Toolsバージョン26.3を使用して、自作ボード用のDDR構成を生成しました。生成されたファイルは以下のとおりです。 lpddr5_timing.c lpddr5_config.ds ペリフェラル.c ペリフェラル.h pin_mux.c pin_mux.h OEIソースのboards/mx95lp5/ddrディレクトリ内に、以下のファイルが見つかりました。 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c カスタムLPDDR5ボードの正しい統合手順を確認したいのですが。 生成されたlpddr5_timing.cMIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c の代わりにこれを使用し、OEI_DDR_CONFIG を更新して新しいタイミングファイルを参照するようにしますか？ XIMX95LPD5EVK19_6400mbps_train_timing_a1.cはNXPが提供するシリコン専用のトレーニングファイルで、カスタムボードでは変更されないべきでしょうか? OEIは以下のDDR PHYファームウェアバイナリを使用します。 lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin これらの同じファームウェアバイナリは、生成されたDDRのタイミング設定とファームウェアバージョンが一致していれば、カスタムLPDDR5ボード上で再利用できますか? ECC対応タイミングファイルは、LPDDR5 ECCが有効になっている場合にのみ必要ですか？カスタムボードでECCを使用しない場合、通常のタイミングファイルで十分でしょうか？ EVK DDR構成からカスタムLPDDR5ボードに移行する際に、再生成または変更が必要な追加ファイルがあればお知らせください。 よろしくお願いします。 Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage こんにちは、 1. はい、MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c をカスタム構成に置き換える必要があります。 2. それはそのシリコンリビジョンごとに異なる構成なので、あなたのCASEであれば参考にCAN。この構成を使っていない場合は、そのままにしておいても構いません。 3. はい、これらのバイナリは類似の構成に再利用でき、通常のタイミングファイルで十分で、ECCを使わない場合は十分です。 よろしくお願いいたします。

Pit interrupt runs in ram wen flash erase I found that I cannot enter the timer interrupt while erasing flash. To meet my requirements, I plan to run the timer interrupt in RAM. I modified the linker_flash_s32k388.ld file to place IntCtrl_Ip.o and Pit_Ip.o in RAM, but when I erase flash, I still encounter errors due to the arrival of the timer interrupt. Please tell me what details I have overlooked.#s32k388 Re: Pit interrupt runs in ram wen flash erase Hello, Simply placing IntCtrl_Ip.o and Pit_Ip.o into RAM is usually not enough. During a PFLASH erase operation, the CPU must avoid any access to the affected flash array. Please verify that the interrupt vector table, the PIT ISR, all functions called by the ISR, and any data/constants used by the ISR are also located in SRAM. Additionally, ensure that the VTOR register points to a RAM-based vector table. A linker map file is typically the best way to identify remaining flash accesses. The S32K3 Reference Manual also notes that code execution must be moved to SRAM when flash operations require continued execution. Best regards, Peter

How to use LPI2C peripheral with DMA without enabling any interrupts? Hello, I am working with an NXP S32K396 MCU and would like to perform an LPI2C master transaction using eDMA without enabling any interrupts. In my project, I am using the LPI2C1 peripheral. I can successfully perform LPI2C read and write transactions using DMA when the following interrupts are enabled: LPI2C1_IRQn eDMA0_DMATTCD_CH16_CH17_IRQn However, it appears that the RTD LPI2C DMA implementation depends on these interrupts. In Lpi2c_Ip_MasterSendData(), the LPI2C master interrupts are always enabled by the driver: In addition, the DMA TCDs configured for TX and RX by Lpi2c_Ip_MasterTxDmaConfig() and Lpi2c_Ip_MasterRxDmaConfig() always enable the DMA major-loop completion interrupt: Lpi2c_DmaTransferList[9u].Param = DMA_IP_CH_SET_CONTROL_EN_MAJOR_INTERRUPT; Lpi2c_DmaTransferList[9u].Value = 1U; I also noticed that in other function - Lpi2c_Ip_MasterSendDataBlocking() does not appear to configure a DMA TCD for the LPI2C transfer. I would like to perform the complete LPI2C transmit and receive transaction using DMA while keeping LPI2C1_IRQn disabled and the eDMA channel interrupt disabled.   If possible, could NXP provide an example for LPI2C master TX/RX using DMA with both LPI2C and DMA interrupts disabled?   MCU: NXPS32K396 RTD: 6.0.0 NXP Studio: 3.6.1   Any help would be greatly appreciated. Thanks a lot in advance! If needed, I can attach my project. Re: How to use LPI2C peripheral with DMA without enabling any interrupts? Hi@rkhw From the current driver implementation, the “Lpi2c_Ip_MasterSendData()” depend on both LPI2C master interrupts and DMA major-loop completion interrupts for transfer completion and state handling. Therefore, you cannot enable DMA without enabling interrupts. The RTD driver does not support this usage.

FRDM iMX95 上的 JTAG 大家好 我最近刚买了 FRDM iMx95，我很好奇如何使用 JTAG 来调试这个板 根据原理图，JTAG 接口在此处的第 6 个测试点引脚上暴露出来  在板布局上，在这里 我该如何将 JTAG 连接到它，需要进行任何返工吗？那么，这个 JTAG 是否支持对所有 A55、M33 和 M7 核心进行调试？  我应该在这里用哪个设备，看来我们有 6 针但它是 2x3 而不是 1x6 如果有任何设置 JTAG 的指南或文档，我将不胜感激 谢谢！！   Linux Re: JTAG on FRDM iMX95 你好 你的理解是正确的。 如原理图所示，需要添加 DNP 电阻和一个用于调试器的连接器。 顺祝商祺！ Re: JTAG on FRDM iMX95 你好， 感谢您的确认@JorgeCas 摘要：请帮忙解决 JTAG 问题“DAP：无法启动系统功率域。” 我已经对 3 个电阻进行了改造，并测量了引脚，它成功上拉了。 需要注意的是，要启用 JTAG，我需要在设备树中禁用 LPUART5，因为它使用相同的引脚（我按照 imx95-19x19-jtag.dtb 中的修改方式进行修改），否则 TMS（测试点 49）将始终为低电平。 diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts index c45f28efb568..598e16af0ebd 100644 --- a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts +++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts @@ -520,7 +520,7 @@ &lpuart5 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart5>; - status = "okay"; + status = "disabled"; bluetooth { compatible = "nxp,88w8987-bt"; 接下来我需要找到针脚为 1.27mm 的连接器。我花了一些时间才找到这个用弹簧针测试的PCB板，它有6个引脚，完美匹配。 这是我目前的配置。 看起来有点乱，但连接没问题，我检查了硬件状态，看起来不错。 J-Link>ShowHWStatus VTref=3.324V ITarget=0mA TCK=1 TDI=1 TDO=0 TMS=0 TRES=1 TRST=1 Supported target interface speeds: - 120 MHz/n, (n>=8). => 15000kHz, 13333kHz, 12000kHz, ... - Adaptive clocking 我尝试使用这两条命令连接 A55 和 M33，但出现同样的问题，显示“ DAP：无法启动系统功率域”。 zk47@ltu:~$ JLinkExe -device MIMX9516_M33 -if JTAG -speed 200 SEGGER J-Link Commander V9.42 (Compiled May 6 2026 12:36:02) DLL version V9.42, compiled May 6 2026 12:35:00 zk47@ltu:~$ JLinkExe -device MIMX9516_A55 -if JTAG -speed 200 我做错了什么？ 或许是我的JLink设备不好用，MCU-Link Pro可以替代它吗？MCU-Link Pro 可以调试 A55 和 M 内核吗？ 我还是更倾向于通过 JTAG 进行调试，因为我手头已经有了 JTAG。请帮忙 如果你们计划为 FRDM iMX95 添加 JTAG 文档指南，请尽快更新，就像 FRDM iMX93 一样。 Re: JTAG on FRDM iMX95 亲爱的@JorgeCas 有任何更新吗？我可以使用MCU-Link Pro调试所有A55、M33和M7核心吗？ Re: JTAG on FRDM iMX95 你好 很抱歉耽搁了这么久。 我们建议您使用 MACRAIGOR Systems、Wind River 或 ARM 的任何调试器。 NXP 团队使用 Lauterbach Trace32 作为 Cortex-A 内核的调试工具，而 J-link 用于 Cortex-M 内核。 对于 i.MX95，要使用 CM7 或 CA55 脚本，前提是 SM 已经在i.MX设备上运行。它采用 CM33 进行资源管理和网络安全，它是开源的，符合 Arm 的硬件资源管理标准，其代码（在很多情况下）旨在对硬件进行分区，并将资源分配给 Cortex-A 或 Cortex-M7。 您可以将此文档用作参考。 在 i.MX 8M、i.MX 8ULP 和 i.MX 9 上使用 VS Code 调试 Cortex-M 如果经过以上检查后问题仍然存在，请检查适配器是否存在硬件问题。 顺祝商祺！ 

ADC1_MA1ピンをS32K312のADC入力として使えますか? NXPチームの皆様、こんにちは。 S32K312コントローラーを使っていて、ポテンショメーター電圧を読み取るためにADC1_MA1とラベル付けされたピンを使いたいと思っています。 ADC1_MA1 ADCの外部多重化器のアドレス出力ピンであることは理解しています。しかし、SIUL2、ADC、ピンマルチックスの設定で、このピンを通常のADCアナログ入力として使える設定があるかどうか確認したいです。 私の要件は、0V～3.3Vの範囲のポテンショメータのワイパー電圧を接続し、それをADC1で読み取ることです。 確認いただけますか: Is ADC1_MA1 物理的にADCの入力チャネルやサンプル&ホールド回路に接続されていますか? このピンはソフトウェアでADC入力として設定できますか? もしADC入力として使えない場合、PCBがすでにこのピンに接続されたポテンショメータを設計している場合、推奨されるハードウェアの回避策はありますか? ありがとう。 よろしくお願いします、 エサッキ Re: Can ADC1_MA1 pin be used as ADC input on S32K312? こんにちは、エサキさん。 ADC1_MA1はADCマルチプレクサの出力であり、デジタルピンで、出力方向です。このピンの機能は「S32K3 ADC 外部チャネルの利用」で説明されています。 ADC1_MA1ピンには ダイレクトシグナル がなく、ADC入力として使用できません。ダイレクト信号セクションに記載されたADCを持つピンのみがADC入力として使用可能です。 残念ながら、他に信頼できる解決策はなく、ハードウェア回路の変更をお勧めします。 よろしくお願いいたします ロビン Re: Can ADC1_MA1 pin be used as ADC input on S32K312? こんにちは、 @Robin_Shen さん。 分かりやすいご説明とご確認をいただき、ありがとうございます。サポートいただき感謝します。 よろしくお願いします、 エサッキ

关于将自定义 LPDDR5 时序集成到 i.MX95 OEI 和 DDR PHY 固件使用中的说明 您好，NXP团队， 我正在开发一款基于 i.MX9596 处理器和 LPDDR5 内存，并使用 i.MX OEI 引导加载程序的定制电路板。 我使用 MCUXpresso 配置工具 26.3 版为我的定制板生成了 DDR 配置。生成的文件如下： lpddr5_timing.c lpddr5_config.ds 外围设备.c peripherals.h pin_mux.c pin_mux.h 在 OEI 源代码目录 板/mx95lp5/ddr 下，我找到了以下文件： MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c 我想确认一下定制LPDDR5板的正确集成流程。 生成的 lpddr5_timing.c是否可以用此文件代替 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c，并更新 OEI_DDR_CONFIG 以引用新的时序文件？ XIMX95LPD5EVK19_6400mbps_train_timing_a1.ca 是 NXP 提供的芯片专用训练文件，定制板需要保持不变吗？ OEI 使用以下 DDR PHY 固件二进制文件： lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin 只要固件版本与生成的 DDR 时序配置匹配，这些相同的固件二进制文件是否可以在定制的 LPDDR5 板上重复使用？ 是否只有在启用 LPDDR5 ECC 时才需要启用 ECC 的时序文件？如果定制板上未使用 ECC，则普通时序文件是否足够？ 从 EVK DDR 配置迁移到定制 LPDDR5 板时，是否需要重新生成或修改任何其他文件？请告知。 谢谢！ Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage 你好， 1. 是的，您需要将 MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c 替换为您的自定义配置。 2. 这是该特定硅片版本的一种不同配置，如果这是你的情况，可以将其用作参考。如果您不使用此配置，则可以保持不变。 3. 是的，这些二进制文件可以重复用于类似的配置，如果您不使用 ECC，则普通的计时文件就足够了。 顺祝商祺！

FLEXCAN EDMA - 接收 CAN 消息突发时出现 ACK 错误 在 i.MXRT1176 上，我们使用 FLEXCAN 和 EDMA。（SDK 26.03） 我们定义了 DMA 传输完成的回调函数。 这是我们的流程： 1.调用 ` FLEXCAN_TransferReceiveFifoEDMA()` 开始传输。 2. DMA 传输完成后，调用用户定义的回调函数。 3. 从 DMA 缓冲区复制数据，并调用 `FLEXCAN_TransferReceiveFifoEDMA()` 继续接收消息。 4. 重复步骤 2-4 我们注意到，当我们从另一个节点以突发方式发送消息，且帧间间隔仅为最小值时，ACK 错误的数量会增加——iMX 无法确认消息。 从流程来看，每次 DMA 传输完成回调时，FLEXCAN 上的 DMA 都会被禁用。当调用 `FLEXCAN_TransferReceiveFifoEDMA()` 时，DMA 功能会重新启用。这可以通过调用 ` FLEXCAN_EnableRxFifoDMA()` 来实现。启用/禁用 DMA 会更新 FLEXCAN 的 MCR 寄存器中的 DMA 位，并且只能在冻结模式下进行。由于我们以突发方式接收消息，因此当 FLEXCAN 进入冻结模式时，可能正在进行传输，导致它无法确认接收到的消息。   我们确认，移除对 `FLEXCAN_EnableRxFifoDMA()` 的调用可以消除所有 ACK 错误，但同时也会丢弃一些消息。此外，我们还尝试拉开消息之间的间隔，这样也消除了 ACK 错误。请问这是否确实是实现方面的问题，或者我们是否应该采用不同的架构方式？ Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages 嗨@r-uv ， 感谢您提供的详细分析。您的观察结果与SDK的实现一致。 FLEXCAN_TransferReceiveFifoEDMA() 是一个有限长度的事务 API。每次 DMA 操作完成后，驱动程序会禁用 Rx FIFO DMA 请求，下一次调用时会再次启用该请求。由于更改 MCR[DMA] 需要冻结模式，最小 IFS 流量中的下一帧可能在 FlexCAN 恢复正常模式之前到达，从而导致 ACK 丢失。 这也解释了为什么移除重复的 DMA 启用/禁用操作可以消除 ACK 错误，但仍然会导致丢帧：与冻结相关的 ACK 间隙被消除，但 eDMA 传输没有持续重新开始。 对于连续突发流量，我们建议保持 Rx FIFO DMA 请求启用，并使用硬件链式乒乓/分散聚集 TCD，以便自动激活下一个缓冲区。这需要连续的 DMA 接收路径，而不是反复重新启动 FLEXCAN_TransferReceiveFifoEDMA()。 此致， 加文

S32 Design Studio for ARM v2.2许可延期 您好，S32 Design Studio for ARM v2.2提示许可马上到期，Activation Code：FAF2-FCC2-8A8E-87AC，麻烦延期，谢谢！

FRDM i.MX93におけるAP1302 MIPI CSIストリーミングの問題 こんにちは、 私はFRDM i.MX93ボードとX-RPI-CAM-MIPI A1カメラモジュールを使用しています。 私が直面している問題は、この設定からMIPI CSIストリームをキャプチャできないことです。 ファームウェアバイナリap1302_60fps_ar0144_27M_2Lane_awb_tuning.binを次の場所に配置しました: "/lib/firmware" 起動時にAP1302が正常に検出されていることは確認できますが、ビデオストリーミングを開始しようとすると、 VIDIOC_STREAMONが 「パイプが壊れています」という エラー で失敗します 。 以下に、関連するログを示します。 カーネルログ: root@imx93evk:~# dmesg | grep ap1302 [ 0.340980] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.371014] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c ... [ 10.088832] ap1302 2-003c: AP1302 revision 0.2.6 detected ストリーミングテスト: root@imx93evk:~# v4l2-ctl -d /dev/video0 \ --verbose \ --stream-mmap=3 \ --stream-count=10 VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_CREATE_BUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned -1 (Broken pipe) なぜ VIDIOC_STREAMON が「 Broken pipe(パイプ破損) 」エラー で故障しているのか 、教えていただけません か? ストリーミングを正常に開始する前に、AP1302のファームウェア、デバイスツリー、メディアパイプライン、またはセンサの初期化に追加の設定が必要ですか? さらに、現時点では「LF_v6.18.2-1.0.0_images_IMX93EVK」というプリビルドイメージを使用しています。 追加のログや情報が必要な場合はお知らせください。 再開まで今しばらくお待ちください。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 AEチームと話し合っています。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 こんにちは@yipingwang ご返信ありがとうございます。 参考までに、私の回答を以下に記載します。 1. ファームウェアの場所 推奨されているファームウェアのインストール場所と、それぞれの場所を個別に試してみました。カメラプローブは、 ap1302_ar0144_single_fw.binを使用した場合にのみ成功します。 root@imx93evk:~# ls -la /lib/firmware/ap1302_ar0144_single_fw.bin -rw-r--r-- 1 root root 80528 Aug 5 15:36 /lib/firmware/ap1302_ar0144_single_fw.bin root@imx93evk:~# ls -la /lib/firmware/imx/camera/ap1302.fw -rw-r--r-- 1 root root 80528 Aug 5 15:38 /lib/firmware/imx/camera/ap1302.fw AP1302は起動時に正常に検出されました。 root@imx93evk:~# dmesg | grep -i ap1302 ... [ 9.962705] ap1302 2-003c: AP1302 revision 0.2.6 detected しかし、カーネルログにはAP1302に関連するファームウェアの読み込みメッセージは一切見当たりません。 2. ソフトウェア環境 私はFRDM i.MX93ボード用に提供されているプリビルドイメージを使用しています。 root@imx93evk:~# cat /proc/device-tree/model NXP FRDM-IMX93 root@imx93evk:~# cat /proc/cmdline console=ttyLP0,115200 earlycon root=/dev/mmcblk0p2 rootwait rw AP1302は正常に検出され、CSI/ISIデバイスも存在しています。参考までに、ログ全体を添付しました。 3. メディアパイプライン メディアパイプラインは正しく作成されているようです。 root@imx93evk:~# ls /dev/media0 /dev/media0 root@imx93evk:~# ls /dev/video* /dev/video0 /dev/video1 media-ctlの出力はAP1302、CSI、ISIエンティティが有効であることを示しています。参照のために、完全なmedia-ctl出力を添付します。 4. 追加情報 ご依頼いただいた情報については、添付ファイルfourth_point.txtをご参照ください。 5. ストリーミングの失敗 ストリーミングコマンドが失敗した際に、カーネルから追加のメッセージは表示されません。 root@imx93evk:~# dmesg -c root@imx93evk:~# v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=10 VIDIOC_STREAMON returned -1 (Broken pipe) root@imx93evk:~# dmesg 障害後もdmesg出力は空のままなので、根本原因を特定するための追加のカーネルログはありません。 AP1302が正常に検出され、メディアグラフも正しく作成され、VIDIOC_STREAMON中にカーネルエラーも報告されていないので、「 Broken pipe」 エラーでストリーミングが失敗する原因を特定するために、どのような追加のチェックやデバッグステップを教えていただけますか? 再開まで今しばらくお待ちください。 root@imx93evk:~# v4l2-ctl --list-devices mxc-isi-cap (platform:4ae40000.isi): /dev/video0 /dev/video1 /dev/media0 root@imx93evk:~# v4l2-ctl -d /dev/video0 --all Driver Info: Driver name : mxc-isi Card type : mxc-isi-cap Bus info : platform:4ae40000.isi Driver version : 6.18.2 Capabilities : 0xa4201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Device Capabilities Device Caps : 0x24201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Media Driver Info: Driver name : mxc-isi Model : FSL Capture Media Device Serial : Bus info : platform:4ae40000.isi Media version : 6.18.2 Hardware revision: 0x00000000 (0) Driver version : 6.18.2 Interface Info: ID : 0x0300000a Type : V4L Video Entity Info: ID : 0x00000008 (8) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000009 : 0: Sink Link 0x0200000c: from remote pad 0x1000007 of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled, Immutable Priority: 2 Video input : 0 (mxc_isi.0.capture: ok) Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : sRGB YCbCr/HSV Encoding: ITU-R 601 Quantization : Limited Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 flags=0x00001000 vertical_flip 0x00980915 (bool) : default=0 value=0 flags=0x00001000 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 flags=0x00001000 root@imx93evk:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ae40000.isi hw revision 0x0 driver version 6.18.2 Device topology - entity 1: crossbar (3 pads, 3 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 0/0 -> 2/0 [ACTIVE] pad0: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "csidev-4ae00000.csi":1 [ENABLED,IMMUTABLE] pad1: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad2: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] - entity 5: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":2 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 8: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 16: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":1 [ENABLED,IMMUTABLE] - entity 23: csidev-4ae00000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ap1302 2-003c":2 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":0 [ENABLED,IMMUTABLE] - entity 28: ap1302 2-003c (3 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] <- "ar0144 0":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] pad2: SOURCE [stream:0 fmt:UYYVYY8_0_5X24/4224x4092 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] -> "csidev-4ae00000.csi":0 [ENABLED] - entity 32: ar0144 0 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: SOURCE [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb] -> "ap1302 2-003c":0 [ENABLED,IMMUTABLE] よろしくお願いします、 ミラフ Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 AP1302プローブが成功したとしても、カメラパイプライン全体が構成され、ストリーミングが開始されることを保証するものではありません。i.MX93では、VIDIOC_STREAMONが-1(破損パイプ)を返すと、通常、メディアパイプラインのコンポーネント(AP1302→MIPI、CSI-2レシーバ、→ISIキャプチャパス)が有効なストリームを開始または交渉できなかったことを意味します。ログには、AP1302 I²Cデバイスが検出されたという情報しか記録されていません。 ap1302 2-003c: AP1302 リビジョン 0.2.6 が検出されました しかし、それは以下のことを確認するものではありません。 ファームウェアのロードに成功しました。 正しいDTBが使用されました。 メディアグラフが作成されました。 CSIレシーバは受信するMIPIデータにロックされています。 AP1302は、対応する出力フォーマットで設定されています。 まず最初に確認すべきことは、ファームウェアの場所と名前です。 FRDM-i.MX93 AP1302のサポートについては、NXPのドキュメントには以下が記載されています: ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin をダウンロードしてください。 名前をap1302.fwに変更してください。 配置場所： /lib/firmware/imx/camera/ap1302.fw 単に /lib/firmware ではない。 ご確認ください： ls -l /lib/ファームウェア/imx/カメラ/ap1302.fw そしてブートログを確認してください。 dmesg | grep -i firmware dmesg | grep -i ap1302 次のようなメッセージを探してください。 ファームウェアを要求する ファームウェアがロードされました ファームウェアの読み込みに失敗しました 2つ目の確認事項：正しいDTBを使用していますか？ リリースノートによると、AP1302のサポートはi.MX93 EVKデバイスツリーのサポートと関連しています。 確認： cat /proc/device-tree/model cat /proc/cmdline そして、実際にロードされるDTBを特定します。 こちらもご確認ください： dmesg | grep -i ap1302 dmesg | grep -i csi dmesg | grep -i isi 三つ目のチェック:メディアトポロジーの検証 v4l2-ctlを試す前に、メディアグラフが存在するか確認してください: シェル media-ctl -p もっと行を表示 以下のようなエンティティが表示されるはずです。 ap1302 CSI イシ ビデオX /dev/media0が存在しない場合、カメラパイプラインが正しく作成されていません。非常に似たFRDM-i.MX93 AP1302 CASEは以下の通りでした: media-ctl -p /dev/media0 の列挙に失敗しました これはメディアパイプラインがインスタンス化されていないことを示していました。 チェックしてください： ls -l /dev/media* 4つ目の確認事項：交渉済みのフォーマットを検査する 次を実行します。 v4l2-ctl --list-devices そして、 v4l2-ctl -d /dev/video0 --all また： media-ctl -p AP1302のファームウェアは通常、RAWベイヤーではなく、処理済みのYUVフォーマットを出力します。もう一つよくある失敗例は次のとおりです。 AP1302はフォーマットAを出力する ISIはフォーマットB用に構成されています ストリームの起動失敗を引き起こしています。フォーマットの不一致は、STREAMONの失敗やCSIパイプラインのエラーとして現れることが多い。 5回目のチェック：STREAMON実行中のCSIエラーを検査する 別のターミナルを開いて監視します。 dmesg -w そして、以下を実行します。 v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 次のようなメッセージを探してください。 CSIタイムアウト フレーム開始タイムアウト データを受信しませんでした FIFOオーバーフロー MIPIエラー リンクが有効になっていません これらのメッセージは通常、配管破損の本当の原因を明らかにします。

S32 Design Studio for ARM v2.2 许可延期 您好，S32 Design Studio for ARM v2.2提示立即授权，激活码：FAF2-FCC2-8A8E-87AC，麻烦延期，谢谢！

AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 Hello, I am using an FRDM i.MX93 board with the X-RPI-CAM-MIPI A1 camera module. The issue I am facing is that I am unable to capture the MIPI CSI stream from this setup. I have placed the firmware binary ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin in the following location: "/lib/firmware" During boot, I see that the AP1302 is detected successfully, but when I attempt to start video streaming, VIDIOC_STREAMON fails with a "Broken pipe" error. Below are the relevant logs. Kernel log: root@imx93evk:~# dmesg | grep ap1302 [ 0.340980] /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c: Fixed dependency cycle(s) with /soc@0/bus@42800000/csi@4ae00000 [ 0.371014] /soc@0/bus@42800000/csi@4ae00000: Fixed dependency cycle(s) with /soc@0/bus@42000000/i2c@42530000/ap1302_mipi@3c ... [ 10.088832] ap1302 2-003c: AP1302 revision 0.2.6 detected Streaming test: root@imx93evk:~# v4l2-ctl -d /dev/video0 \ --verbose \ --stream-mmap=3 \ --stream-count=10 VIDIOC_QUERYCAP: ok VIDIOC_REQBUFS returned 0 (Success) VIDIOC_CREATE_BUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_G_FMT returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned -1 (Broken pipe) Could you please help me understand why VIDIOC_STREAMON is failing with a "Broken pipe" error? Is there any additional configuration required for the AP1302 firmware, device tree, media pipeline, or sensor initialization before streaming can start successfully? Furthermore, i am using "LF_v6.18.2-1.0.0_images_IMX93EVK" pre-built images for now. Please let me know if you need any additional logs or information. Thank you for your support. Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 Discussing with the AE team. Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 Hello @yipingwang  Thank you for your response. Please find my answers below for your reference. 1. Firmware Location I tried both the recommended firmware locations as well as each location individually. The camera probe is successful only when using ap1302_ar0144_single_fw.bin. root@imx93evk:~# ls -la /lib/firmware/ap1302_ar0144_single_fw.bin -rw-r--r-- 1 root root 80528 Aug 5 15:36 /lib/firmware/ap1302_ar0144_single_fw.bin root@imx93evk:~# ls -la /lib/firmware/imx/camera/ap1302.fw -rw-r--r-- 1 root root 80528 Aug 5 15:38 /lib/firmware/imx/camera/ap1302.fw The AP1302 is detected successfully during boot. root@imx93evk:~# dmesg | grep -i ap1302 ... [ 9.962705] ap1302 2-003c: AP1302 revision 0.2.6 detected However, I do not see any firmware loading messages related to AP1302 in the kernel log. 2. Software Environment I am using the pre-built images provided for the FRDM i.MX93 board. root@imx93evk:~# cat /proc/device-tree/model NXP FRDM-IMX93 root@imx93evk:~# cat /proc/cmdline console=ttyLP0,115200 earlycon root=/dev/mmcblk0p2 rootwait rw The AP1302 is detected successfully, and the CSI/ISI devices are also present. I have attached the complete logs for your reference. 3. Media Pipeline The media pipeline appears to be created correctly. root@imx93evk:~# ls /dev/media0 /dev/media0 root@imx93evk:~# ls /dev/video* /dev/video0 /dev/video1 The outputs from media-ctl show that the AP1302, CSI, and ISI entities are enabled. The complete media-ctl output is attached for your reference. 4. Additional Information Please refer to the attached file fourth_point.txt for the requested information. 5. Streaming Failure I do not see any additional kernel messages when the streaming command fails. root@imx93evk:~# dmesg -c root@imx93evk:~# v4l2-ctl -d /dev/video0 --stream-mmap=3 --stream-count=10 VIDIOC_STREAMON returned -1 (Broken pipe) root@imx93evk:~# dmesg The dmesg output remains empty after the failure, so there are no additional kernel logs to help identify the root cause. Since the AP1302 is detected successfully, the media graph is created correctly, and no kernel errors are reported during VIDIOC_STREAMON, could you please suggest what additional checks or debugging steps I should perform to identify why streaming fails with a "Broken pipe" error? Thank you for your support. root@imx93evk:~# v4l2-ctl --list-devices mxc-isi-cap (platform:4ae40000.isi): /dev/video0 /dev/video1 /dev/media0 root@imx93evk:~# v4l2-ctl -d /dev/video0 --all Driver Info: Driver name : mxc-isi Card type : mxc-isi-cap Bus info : platform:4ae40000.isi Driver version : 6.18.2 Capabilities : 0xa4201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Device Capabilities Device Caps : 0x24201000 Video Capture Multiplanar I/O MC Streaming Extended Pix Format Media Driver Info: Driver name : mxc-isi Model : FSL Capture Media Device Serial : Bus info : platform:4ae40000.isi Media version : 6.18.2 Hardware revision: 0x00000000 (0) Driver version : 6.18.2 Interface Info: ID : 0x0300000a Type : V4L Video Entity Info: ID : 0x00000008 (8) Name : mxc_isi.0.capture Function : V4L2 I/O Pad 0x01000009 : 0: Sink Link 0x0200000c: from remote pad 0x1000007 of entity 'mxc_isi.0' (Video Pixel Formatter): Data, Enabled, Immutable Priority: 2 Video input : 0 (mxc_isi.0.capture: ok) Format Video Capture Multiplanar: Width/Height : 1920/1080 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Number of planes : 1 Flags : Colorspace : sRGB Transfer Function : sRGB YCbCr/HSV Encoding: ITU-R 601 Quantization : Limited Range Plane 0 : Bytes per Line : 3840 Size Image : 4147200 User Controls horizontal_flip 0x00980914 (bool) : default=0 value=0 flags=0x00001000 vertical_flip 0x00980915 (bool) : default=0 value=0 flags=0x00001000 alpha_component 0x00980929 (int) : min=0 max=255 step=1 default=0 value=0 flags=0x00001000 root@imx93evk:~# media-ctl -p Media controller API version 6.18.2 Media device information ------------------------ driver mxc-isi model FSL Capture Media Device serial bus info platform:4ae40000.isi hw revision 0x0 driver version 6.18.2 Device topology - entity 1: crossbar (3 pads, 3 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev0 routes: 0/0 -> 2/0 [ACTIVE] pad0: SINK,MUST_CONNECT [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] <- "csidev-4ae00000.csi":1 [ENABLED,IMMUTABLE] pad1: SINK,MUST_CONNECT <- "mxc_isi.output":0 [ENABLED,IMMUTABLE] pad2: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:srgb xfer:srgb ycbcr:601 quantization:lim-range] -> "mxc_isi.0":0 [ENABLED,IMMUTABLE] - entity 5: mxc_isi.0 (2 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev1 pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range compose.bounds:(0,0)/1920x1080 compose:(0,0)/1920x1080] <- "crossbar":2 [ENABLED,IMMUTABLE] pad1: SOURCE [stream:0 fmt:YUV8_1X24/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range crop.bounds:(0,0)/1920x1080 crop:(0,0)/1920x1080] -> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE] - entity 8: mxc_isi.0.capture (1 pad, 1 link) type Node subtype V4L flags 0 device node name /dev/video0 pad0: SINK <- "mxc_isi.0":1 [ENABLED,IMMUTABLE] - entity 16: mxc_isi.output (1 pad, 1 link) type Node subtype V4L flags 0 pad0: SOURCE -> "crossbar":1 [ENABLED,IMMUTABLE] - entity 23: csidev-4ae00000.csi (2 pads, 2 links, 1 route) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 routes: 0/0 -> 1/0 [ACTIVE] pad0: SINK [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] <- "ap1302 2-003c":2 [ENABLED] pad1: SOURCE [stream:0 fmt:UYVY8_1X16/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] -> "crossbar":0 [ENABLED,IMMUTABLE] - entity 28: ap1302 2-003c (3 pads, 2 links, 0 routes) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev4 pad0: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] <- "ar0144 0":0 [ENABLED,IMMUTABLE] pad1: SINK [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] pad2: SOURCE [stream:0 fmt:UYYVYY8_0_5X24/4224x4092 field:none colorspace:srgb crop.bounds:(0,0)/1280x800 crop:(0,0)/1280x800] -> "csidev-4ae00000.csi":0 [ENABLED] - entity 32: ar0144 0 (1 pad, 1 link, 0 routes) type V4L2 subdev subtype Sensor flags 0 device node name /dev/v4l-subdev3 pad0: SOURCE [stream:0 fmt:SGRBG12_1X12/1280x800 field:none colorspace:srgb] -> "ap1302 2-003c":0 [ENABLED,IMMUTABLE] Best regards, Milav Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 the AP1302 probe succeeding does not guarantee that the complete camera pipeline is configured and streaming. On i.MX93, a VIDIOC_STREAMON returned -1 (Broken pipe) typically means that one of the media pipeline components (AP1302 → MIPI CSI-2 receiver → ISI capture path) failed to start or negotiate a valid stream. Your log only confirms that the AP1302 I²C device was detected: ap1302 2-003c: AP1302 revision 0.2.6 detected but it does not confirm that: the firmware was loaded successfully, the correct DTB was used, the media graph was created, the CSI receiver is locked to incoming MIPI data, the AP1302 has been configured with a matching output format. First thing I would check: firmware location/name For the FRDM-i.MX93 AP1302 support, NXP documentation indicates: Download ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin Rename it to ap1302.fw Place it in: /lib/firmware/imx/camera/ap1302.fw not simply /lib/firmware. Please verify: ls -l /lib/firmware/imx/camera/ap1302.fw and check boot log: dmesg | grep -i firmware dmesg | grep -i ap1302 Look for messages such as: request firmware firmware loaded failed to load firmware Second check: are you using the correct DTB? The release notes indicate AP1302 support is associated with the i.MX93 EVK device tree support. Check: cat /proc/device-tree/model cat /proc/cmdline and determine the actual DTB being loaded. Also check: dmesg | grep -i ap1302 dmesg | grep -i csi dmesg | grep -i isi Third check: verify media topology Before trying v4l2-ctl, verify that the media graph exists: Shell media-ctl -p Show more lines You should see entities similar to: ap1302 csi isi videoX If /dev/media0 does not exist, the camera pipeline is not being created correctly. A very similar FRDM-i.MX93 AP1302 case showed: media-ctl -p Failed to enumerate /dev/media0 which indicated the media pipeline was not instantiated. Please check: ls -l /dev/media* Fourth check: inspect the negotiated formats Run: v4l2-ctl --list-devices and v4l2-ctl -d /dev/video0 --all also: media-ctl -p The AP1302 firmware normally outputs processed YUV formats rather than RAW Bayer. Another common failure is: AP1302 outputs format A ISI configured for format B causing stream startup failure. A format mismatch often surfaces as STREAMON failure or CSI pipeline errors. Fifth check: inspect CSI errors during STREAMON Open another terminal and monitor: dmesg -w then run: v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 Look for messages such as: CSI timeout frame start timeout no data received FIFO overflow MIPI error link not enabled These messages usually reveal the real reason behind the Broken pipe.

FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages On i.MXRT1176 we are using FLEXCAN with EDMA. (SDK 26.03) We have a callback defined for DMA transfer complete. This is our flow: 1. Call `FLEXCAN_TransferReceiveFifoEDMA()` to start the transfer. 2. On DMA transfer completion, user-defined callback is called. 3. Data is copied from DMA buffers, and `FLEXCAN_TransferReceiveFifoEDMA()` is called to continue receiving messages. 4. Repeat Steps 2-4 We noticed that when we transmit messages from another node in a burst with just the bare minimum Inter-Frame Space, we see an increase in number of ACK errors - the iMX is unable to ACK the messages.  Going through the flow, it appears that every time there is a DMA transfer complete callback, DMA is disabled on FLEXCAN. It is re-enabled again when `FLEXCAN_TransferReceiveFifoEDMA()` is called.  This is done by calling `FLEXCAN_EnableRxFifoDMA()`. The enabling/disabling DMA updates the DMA bit in FLEXCAN's MCR register, and it can only be done in Freeze mode. As we are receiving messages in a burst, it is possible that a transmission is actively in progress when FLEXCAN is put it freeze mode. And it is unable to ACK the incoming message.   We confirmed that removing that call to `FLEXCAN_EnableRxFifoDMA()` removes all ACK errors, though now we are dropping some messages. Also, we tried spacing out the messages, and that also got rid of the ACK errors. Can you please confirm if this is indeed an issue with the implementation, or if we should be rearchitecting it in a different way? Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages Hi @r-uv , Thank you for the detailed analysis. Your observation is consistent with the SDK  implementation. FLEXCAN_TransferReceiveFifoEDMA() is a finite-length transactional API. After each DMA completion, the driver disables the Rx FIFO DMA request, and the next call enables it again. Because changing MCR[DMA] requires Freeze mode, the next frame in minimum-IFS traffic may arrive before FlexCAN returns to Normal mode, resulting in a missed ACK. This also explains why removing the repeated DMA enable/disable operation eliminates the ACK errors but still causes dropped frames: the Freeze-related ACK gap is removed, but the eDMA transfer is not continuously rearmed. For continuous burst traffic, we recommend keeping the Rx FIFO DMA request enabled and using hardware-chained ping-pong/scatter-gather TCDs so that the next buffer is activated automatically. This requires a continuous DMA receive path rather than repeatedly restarting FLEXCAN_TransferReceiveFifoEDMA(). Best regards, Gavin

HMAC検証ジョブのリクエスト時にHSEが「HSE_SRV_RSP_INVALID_PARAM」を返す NXPチームの皆様、こんにちは。 HMACのVerifyジョブを使うユースケースがあります。ジョブ暗号ドライバーをトリガーした後、DETを投げると、HSEからの返答は「HSE_SRV_RSP_INVALID_PARAM」でした。 現在の設定のどこが間違っているのか理解できません。添付されたconfig zipファイルを確認していただけますか? 問題解決のためのサポートが必要です。 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @lukaszadrapa さん。 詳細： デバイス: S32K311 HSE FW: HSE_FW_S32K311_0_2_55_0 RTD: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @WagdeoA さん。 どのデバイス、どのRTD、どのHSEファームウェアバージョンを使っているか確認していただけますか? よろしくお願いいたします。 ルーカス

SDK 中未实现 IMXRT EDMA 错误 IRQ 处理程序。 您好， SDK 中的 IMXRT EDMA API 似乎能够正确处理“正常情况”中断。然而，似乎没有任何处理错误中断的机制。不仅如此，似乎所有 DMA 都只有一个全局的 DMA_ERROR_IRQHandler。因此，如果您同时使用 DMA0 和 DMA1，当一切正常时，DMA0/DMA1 IRQHandler 将被调用，SDK 可以区分哪个 DMA 收到了正常中断。但是，如果出现 DMA 错误，由于只有一个全局错误中断处理程序，因此没有简单的方法可以知道错误发生在哪个 DMA（0 或 1 或其他）上。 就像我之前关于 LPUART 错误 IRQ 处理的问题一样。为什么 SDK 没有内置处理 DMA 错误并调用相应回调的功能？现在我必须手动确定错误发生在哪个 DMA 上，并在 SDK 之外调用特殊处理，而不是让它为我调用回调。 对于一个本应在生产代码中使用的 SDK 来说，似乎缺少很多健壮性功能，我敢打赌大多数人只是假设这些错误是由 SDK 在底层处理的，而没有考虑到它们实际上并没有被处理。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 您使用的是哪款 i.MX RT 设备？当您提到 DMA0 和 DMA1 时，您指的是两个 DMA 通道，还是两个 DMA 控制器外设？ 并非所有 i.MX RT 设备都具有两个 eDMA 控制器。例如： i.MX RT1180 包含两个 eDMA 控制器。在启动文件（例如 startup_mimxrt1189_cm33.c）中，您可以找到两个 DMA 错误处理程序：DMA_ERROR_IRQHandler 和 DMA4_ERROR_IRQHandler。 i.MX RT1050 仅包含一个 eDMA 控制器。在启动文件（例如 startup_mimxrt1052.c）中，只有一个 DMA 错误处理程序：DMA_ERROR_IRQHandler。 一般来说，DMA 错误是相对不常发生的事件。从硬件架构的角度来看，通道错误状态被聚合为模块级错误请求，从而触发 DMA 错误中断。因此，该软件必须检查每个通道的错误状态寄存器（例如，CHn_ES），以确定哪个特定通道导致了错误。 顺祝商祺！ 张雪莉

S32K144EVB-Q100 Rev D Schematic Hi. I'm looking for the schematic for S32K144EVB-Q100 Rev D. I cannot seem to make the board send any CAN messages. Is there sample code available to send message on CAN 0 on that board? I was able to use SPI and confirm the CAN transceiver is in forced normal mode so CAN should be working. Re: S32K144EVB-Q100 Rev D Schematic You may check the sample code at S32DS for S32K144EVB... Please share if any since i can not found it... Re: S32K144EVB-Q100 Rev D Schematic Hello @rosejp03, I've sent you a private message on the community regarding the design files. Regarding the CAN functionality, Rev. C (the current board I am using) & Rev. D have the same exact CAN design and transceiver (UJA1169): S32K144EVB-Q100 Rev. DS32K144EVB-Q100 Rev. DS32K144EVB-Q100 Rev. D S32K144EVB Rev. C1S32K144EVB Rev. C1S32K144EVB Rev. C1 Are you using any existing example? Either the AN5413: S32K1xx Series Cookbook or the ones included through the RTD package?  Are you using the 12V jack connector? Change J107 position to 1-2 and power the board with 12V. How are you testing CAN communication? Are you using another EVB, a CAN analyzer, or anything else? Can you try scoping the bus?  Best regards, Julián Re: S32K144EVB-Q100 Rev D Schematic Hi @db16122, If you also need the design files for S32K144EVB Rev. D, please let me know. Best regards, Julián

新規プロジェクトウィザード失敗: FreeRTOSポートが自動的に追加されませんでした 皆さん、こんにちは。 MCUXpresso IDE V24.12を使って、LPC5536向けのfreeRTOSベースのプロジェクトを作ろうとしています。 「Create a new C/C++ project」ウィザード(Quickstart Panelから利用可能)は、プロジェクトにfreeRTOSのサポートを追加する簡単な方法を提供しているようです(下記スクリーンショットのマークアップ参照)。 ご覧の通り、「新しいプロジェクトウィザード」にはfreeRTOSを「オペレーティングシステム」として追加するチェックボックスがあります。このボックスにチェックを入れると、ウィザードは自動的にfreeRTOSのもう一つの重要な部分であるメモリマネージャーを追加します(下記のチェックボックス参照)。 しかし、ウィザードはfreeRTOSで最も重要な部分であるMCU固有のコード(下のスクリーンショットのマークアップ参照)を追加していません。 このコンポーネントを自分で選択しない場合、生成されたプロジェクトでコンパイルエラーが発生します。新規プロジェクトウィザードは常にコンパイル可能なプロジェクトを生成するべきだと私は考えています。さらに、MCUXpresso IDEのマニュアルには明確に「また、コンポーネントを選択すると依存関係も自動的に選択される」と明記されています。(セクション 5.1.1)SDK New Project Wilzard)。 私の意見では、これはバグ、少なくともユーザーエクスペリエンス上のバグです。 次のSDKやMCUXpressoのバージョンでこの問題が修正されることを期待しています。 ありがとう。 ダニエル Re: New Project Wizard fAiL: no freeRTOS port added automatically MCUXpresso IDE v25.6(執筆時点での現行)とSDK for LPC5536(バージョン25.06、manifest 3.15)で試しましたが、FreeRTOSカーネルとcm33ポート間の依存関係 がまだ存在せず 、手動で選択する必要があります。 Re: New Project Wizard fAiL: no freeRTOS port added automatically こんにちは、 @EdwinHz さん。 迅速なサポートに感謝します。 ありがとう。 ダニエル Re: New Project Wizard fAiL: no freeRTOS port added automatically こんにちは、 @danielholala さん、 この問題を再現できました。プロジェクトウィザードはすべての依存関係を自動的に選択するはずなので、これは間違いなくバグです。この問題をIDEチームに報告し、今後のMCUXpressoプロジェクトウィザードのバージョンで修正してもらうつもりです。 この問題を報告していただきありがとうございます。 BR、 エドウィン。

S32DSライセンスの有効期限が切れました。 サポートの皆さん、こんにちは。 有効期限が切れたライセンス番号FF6A-EDA4-CDF0-7186の延長にご協力ください。 よろしくお願いいたします。 マーカス アクティベーション | インストール | ライセンス | インストーラーのダウンロード Re: S32DS License Expired. ライセンスの延長は不可能だと思います。ライセンスを購入する必要があるかもしれません Re: S32DS License Expired. こんにちは、マーカスさん。 お客様のS32DSライセンスが延長されました。以前使用していたコードを使って、S32DSを再度有効化してください。 Re: S32DS License Expired. ジリさん、ありがとうございます！ Re: S32DS License Expired. こんにちは、 これはARM 2018.R1用のS32DS向けです。ライセンスの延長にご協力ください。 よろしくお願いいたします。 マーカス

Yocto wrynose 版本“imx-car-navigation”失败 您好， 尝试在最新的 6.18.20-2.0.0 电路板支持包。 上为 FRDM-IMX93 构建“imx-image-full”时失败，失败情况如下： ERROR: imx-car-navigation-1.0-r0 do_compile: Execution of '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/run.do_compile.1753043' failed with exit code 1 ERROR: Logfile of failure stored in: /media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/log.do_compile.1753043 Log data follows: | DEBUG: Executing shell function do_compile | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode'. Retry scheduled | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode' a second time, aborting | WARNING: exit code 1 from a shell command. ERROR: Task (/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb:do_compile) failed with exit code '1' 请注意，这个问题是 100% 可复现的——在这里总是会失败。另请注意，即使 bitbake 正在执行“编译”步骤，存储库的下载也会失败。目前，我认为这可能与不应该在编译步骤中进行下载有关，也许 bitbake 现在将网络功能限制在了下载步骤中？最近有人试过这个配方吗？ Re: Yocto wrynose build failure for 'imx-car-navigation' 看来我的直觉是对的。以下补丁解决了我的问题： --- sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb.ORIG 2026-07-13 16:02:28.733344421 +0200 +++ sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb 2026-07-13 16:02:11.178539144 +0200 @@ -14,6 +14,7 @@ do_configure[noexec] = "1" +do_compile[network] = "1" do_compile() { cd ${S} 但请注意，这只是一个权宜之计。默认情况下不允许这样做是有原因的——编译步骤不应该进行任何网络访问。

S32K144EVB-Q100 Rev D 回路図 こんにちは。S32K144EVB-Q100 Rev Dの回路図を探しています。ボードにCANメッセージを送らせることができません。そのボードのCAN 0にメッセージを送信するためのサンプルコードはありますか?SPIを使ってCANトランシーバが強制ノーマルモードになっていることを確認でき、CANは動作しているはずです。 Re: S32K144EVB-Q100 Rev D Schematic S32DSのサンプルコードでご確認くださいS32K144EVB...もし見つからなかったら教えてください... Re: S32K144EVB-Q100 Rev D Schematic こんにちは、 @db16122 さん。 もしリバS32K144EVB Dのデザインファイルが必要なら、ぜひお知らせください。 よろしくお願いします、 ジュリアン Re: S32K144EVB-Q100 Rev D Schematic こんにちは、@rosejp03 さん。 デザインファイルについてコミュニティにプライベートメッセージを送りました。 CAN機能についてですが、Rev. C(現在使っているボード)とRev. Dは全く同じCAN設計とトランシーバー(UJA1169)を持っています: S32K144EVB-Q100 Rev. DS32K144EVB-Q100 Rev. D S32K144EVB Rev. C1S32K144EVB Rev. C1 既存の例を使用していますか？AN5413: S32K1xxシリーズの料理本か、RTDパッケージに含まれるもののどちらかですか? 12Vジャックコネクタを使用していますか？J107の位置を1-2に変更し、ボードに12Vの電源を入れてください。 CANコミュニケーションはどのようにテストしていますか?他のEVBやCANアナライザー、その他何かを使っていますか?バスのスコープを試してみてくれない? よろしくお願いします、 ジュリアン