我需要为SPI配置DMA。 我正在使用 S32DS IDE 和 RTD 3.0，请问有人能告诉我如何通过 SPI 启动 DMA 吗？最好能提供详细的步骤说明或示例代码。 Re: I need to configure DMA for SPI 谢谢你的回复 请对 s32k322 MCU 执行此操作 Re: I need to configure DMA for SPI 嗨@ershi RTD 附带两个使用 DMA 进行 SPI 通信的示例代码，一个使用低级驱动程序 (Ip)，一个使用高级驱动程序 (MCAL)。您可以参考主题HOWTO: S32 Design Studio - 从示例创建新的 S32DS 项目，以获取有关如何导入示例的指导。 另外，您可以参考主题“示例 S32K31 SPI 多数据包发送和接收：DMA 缓存问题的解决方案”中提供的示例。 BR，VaneB Re: I need to configure DMA for SPI 嗨@ershi 虽然这些示例并非专门为 S32K322 设计，但除非参考手册另有说明，否则其功能在 S32K3 系列中通常相同。因此，您可以将此项目作为您实现的参考，并根据您的特定设备进行必要的调整。 Re: I need to configure DMA for SPI 我已经配置好了一切，但它仍然无法正常工作。第一次调用 (Lpspi_Ip_AsyncTransmit) 时返回 LPSPI_IP_STATUS_SUCCESS，第二次调用时返回失败 LPSPI_IP_STATUS_FAIL。我可以使用这个 API 通过 SPI 发送数据，而无需使用 DMA 调用 Lpspi_Ip_SyncTransmit()。我附上了一些配置截图。 Re: I need to configure DMA for SPI 嗨@ershi 能否也分享一下RM和IntCtrl_Ip驱动程序的配置图片？ Re: I need to configure DMA for SPI 嗨@VaneB 我已附上 RM 和 IntCtrl_IP 驱动程序配置的屏幕截图，以及一段简短的视频片段，供您详细参考。 我注意到LPSPI配置页面中有一处不同。在SPI常规选项卡中， Spi_Phy_TxDmaChannel下的命名在TX和RX配置中有所不同。 如果您需要任何其他详细信息，请告诉我。 InterruptsInterruptsInterruptsInterruptsInterruptsInterruptsInterruptsInterrupts打断 RMRMRMRMRMRMRMRMRM Lpi.png Re: I need to configure DMA for SPI 嗨@ershi 感谢您分享所有信息。 我只有一点看法。在 Dma_Ip 驱动程序配置中，您已将 DMA_SPI_CALLBACK_0 定义为中断回调。然而，LPSPI DMA 回调函数已由驱动程序提供，可以在 Lpspi_Ip_Irq.c 文件中找到。文件。 对于 LPSPI2，配置的回调函数应为： TX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqTxDmaHandler RX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqRxDmaHandler Re: I need to configure DMA for SPI 嗨@ershi 请问您是如何实现SPI通信的？另外，您是否测试过我之前分享的示例代码？ Re: I need to configure DMA for SPI 嗨@VaneB 谢谢你的解释。 我更新了 Dma_Ip 配置，以便对于 LPSPI2，TX 和 RX DMA 通道现在使用 Lpspi_Ip_Irq.c 中的回调函数： TX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqTxDmaHandler NXP RX DMA 通道的 Lpspi_Ip_LPSPI_2_IrqRxDmaHandler 然而，在我这边，基于 DMA 的 LPSPI 传输仍然没有按预期工作。我附上了当前配置的截图供您参考。如果还有其他设置需要调整，请告诉我。 Re: I need to configure DMA for SPI 嗨@ershi 您是将 LPSPI2 SOUT 信号直接连接到 SIN，还是使用逻辑分析仪来验证发送和接收的数据？ Re: I need to configure DMA for SPI 嗨@VaneB 我已经删除了之前的配置，现在SPI数据正在通过DMA传输，但问题是数据不匹配。 #define RX_MSG_SIZE (15U) #define TX_MSG_SIZE (15U) uint8_t txBuffer_check[TX_MSG_SIZE] = {0x48,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x10,0x11,0x12,0x13,0x14,0x15}; uint8_t rxBuffer_check[]={0}; if(Lpspi_Ip_AsyncTransmit(&Lpspi_Ip_DeviceAttributes_SpiExternalDevice_1_Instance_2_BOARD_InitPeripherals,txBuffer_check,rxBuffer_check,TX_MSG_SIZE,spi_DMA_Function) == LPSPI_IP_STATUS_SUCCESS) { Dma_Ip_ReturnType 状态 = {0},状态1 = {0}; Dma_Ip_LogicChannelStatusType channelStatus ={0},channelStatus1 ={0}; status = Dma_Ip_GetLogicChannelStatus(DMA_LOGIC_CH_0,&channelStatus); status1 = Dma_Ip_GetLogicChannelStatus(DMA_LOGIC_CH_1,&channelStatus1);   返回 SYS_SUCCESS； } Re: I need to configure DMA for SPI 嗨@VaneB ， 我已经重写了代码，现在运行完美。数据输入正确。 谢谢你的帮助。 Re: I need to configure DMA for SPI 嗨@VaneB 在我们之前关于配置 SPI 的 DMA 的讨论中。我注意到接收缓冲区的数据与逻辑分析仪的数据不匹配，而发送缓冲区工作正常。我已在 Dropbox 中添加了详细信息。

S32 Design Studio for ARM v2.2 ライセンス拡張版 こんにちは。S32 Design Studio for ARM v2.2のインストールにおけるアクティベーション期間の延長についてサポートをお願いします。アクティベーションコードはFAF2-FCC2-8A8E-87ACです。よろしくお願いいたします。 こんにちは。S32 Design Studio for ARM v2.2のインストールにおけるアクティベーション期間の延長についてサポートが必要です。アクティベーションコード：FAF2-FCC2-8A8E-87AC。ありがとうございます！ Re: S32 Design Studio for ARM v2.2许可延期 こんにちは、 お客様のライセンス期間を延長いたしました。 よろしくお願いいたします。 ピーター

i.MX8M Plus - SD2_VSELは3.3Vに固定されています チームの皆さん、こんにちは。 SD2の電圧は3.3Vである必要があります。設計に1.8Vは入れたくありません。 では、PDをSD_VSEL(PMICピン)に入れて電圧を3.3Vに固定することはできますか? また、SoCからGPIOピンを1つ保存することもできます ハードウェアコントロールを進めて、ソフトウェアコントロールは提供されませんか? i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Re: i.MX8M Plus - SD2_VSEL fixed at 3.3V こんにちは、@ramkrish。 NXPサポートにご連絡いただきありがとうございます! EVKでは、SDカードの電圧切り替え信号がプロセッサのGPIOに接続されています。 SDドライバーはカード初期化および交渉の過程で自動的に3.3Vと1.8Vを切り替えます。高速microSDカードが検出され、カードとホストの両方が低電圧動作をサポートしている場合、ドライバーは1.8V信号に移行し、高性能モードを有効にします。 必要に応じてSDインターフェース電圧を手動で調整することもできます。しかし、このシステムは、動作条件に応じて電圧変動を自動的に処理するように既に設計されている。 よろしくお願いします、 チャビラ

IMXRT LPUART 非阻塞传输 API 使得错误处理变得困难。 您好， 我一直在研究 LPUART 的“传输”API，用于基于中断的非阻塞传输。它似乎很好地封装了所有“正常情况”下的 LPUART 中断处理等，并提供了一个良好的高级 API，用于在数据准备就绪时接收数据（即）。处理 IDLE、RX 就绪、TX 完成等状态）。然而，这使得处理 UART 错误变得非常困难。 LPUART_TransferHandleIRQ 函数内部没有错误处理，并且在 fsl_lpuart.c 中紧随其后的是一个虚假的空 LPUART_TransferHandleErrorIRQ 函数，其中包含注释“由用户实现”。这看起来完全是半成品。 处理 UART 错误的唯一方法似乎是覆盖默认的 LPUARTx_IRQHandler 函数，这样就不需要调用 LPUARTx_RX_DriverIRQHandler（或 TX），而是需要调用自己的函数来处理错误，并将“正常情况”中断传递给原始的 LPUARTx_RX/TX_DriverIRQHandler，以便它可以调用 LPUART_TransferHandleErrorIRQ。 此外，您还需要在传输 API 之外通过调用 LPUART_EnableInterrupts 来启用这些错误中断，并在错误处理中调用 LPUART_DisableInterrupts 并处理清除它们等操作。 这样处理错误似乎很麻烦。为什么这项功能没有内置到转账 API 中？ -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 ， 感谢您提供的详细反馈。我理解 SDK 可能有点含糊不清，因为这些 SDK 的目的是为每个外围设备功能提供常见的用例。我们也一直在努力改进我们的 API，这也要感谢像这样的建议。感谢您的建议，我们希望 LPUART 的错误处理功能能在未来的版本中得到实现。 另一方面，请问您想处理哪些具体的错误状态，以及您使用的是哪款设备？有了这些信息，我可以向您推荐一些与这些错误状态相关的文档，这些文档可能会对您的实施有所帮助。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 所有可能的错误。这几乎适用于所有具有传输 API 但没有错误处理的外围设备（SPI、I2C 等）。IMXRT1172 上的 LPUART 存在帧错误、奇偶校验错误和噪声错误，这些错误无法得到处理。遗憾的是，目前所有这些外围设备都需要一些破解才能处理使用传输 API 时出现的错误。我必须覆盖默认的 IRQ 处理程序，以便在调用 SDK 处理程序之前检查错误。 谢谢！ -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 ， 我知道这可能需要额外的开发时间，对此我们深表歉意，我们将继续努力改进我们的SDK。作为参考，您可以查看 SDK（版本 26.6）中名为“LPUART_TransferHandleIRQ”的函数的以下结构，并根据您的应用程序需要实现类似的恢复流程。 Habib_MS_1-1784062752001.png BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 你好@nxp16 ， 如果您还有其他问题，请告诉我。 BR 哈比卜 Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 是的，我已经实现了类似的功能。谢谢你发来这个。

MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT Hello NXP Support, We are using an MCXN547VKLT on a custom board with an external MCU-Link probe. The SWD connection fails when starting a debug session: Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. The SWD-DP can be detected correctly: DPID = 0x6BA02477 However, access to CPU0 AHB-AP (AP0) fails with: WIRE ACK FAULT The Debug Mailbox request also fails. LinkServer reports: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR What we have checked: SWD frequency tested from 1 MHz down to 10 kHz SWDIO and SWCLK waveforms look good on an oscilloscope VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDC and I/O supplies = 3.3 V RESET_B works correctly MCU-Link firmware: CMSIS-DAP V3.172 LinkServer version: 26.5.59 The same MCU-Link works with an MCXN947 development board The MCXN547 was replaced with a new chip, but the problem remains USB ISP works correctly with VID/PID 1FC9:014F. Using blhost, we can: Erase internal Flash Program and read internal Flash Run the application successfully Enumerate the application USB composite device The ROM reports: Security State = UNSECURE We also read the PFR through USB ISP: CMPA is completely erased (0xFF) CFPA is erased except for the ROM-generated CMAC No customer SOCU or Debug Authentication configuration is present Could you please advise: What conditions are required before AP0 and AP2 become accessible? Is DM-AP status 0x60F93638 associated with a known power, reset, or hardware configuration issue? Are there any known MCXN547 errata related to SWD or Debug Mailbox access? Which power and reset signals should we check for this symptom? MCXN Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT Hello Luis, We have now been able to establish an SWD debug connection by using the SPSDK Debug Mailbox tool. The procedure we used is as follows: 1. Reset the MCU through the Debug Mailbox: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ tool reset -f mcxn547 2. Start a debug session through the Debug Mailbox: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ cmd -f mcxn547 start-debug-session 3. After the debug session has been opened, we connect to the Cortex-M33 core with LinkServer over SWD. We did not use any authentication keys, passwords, debug credentials, or mass erase commands. It appears that the "start-debug-session" command temporarily enables AP0 through the always-accessible AP2 Debug Mailbox. We also used the GDET register sequence from the NXP LS_preconnect_MCXN5XX.scp script after opening the debug session. The sequence disables the aGDET and dGDET reset routing and disables SPC glitch detection during debugging. Regarding the power supplies: - VDD_VBAT is directly connected to VDD, and both are 3.3 V. - VDD_P4 is directly connected to VDD, and both are 3.3 V. - VDD_ANA is connected to VDD through a ferrite bead. - VDD is 3.3 V. However, we now have another debugging problem. When the board is powered on normally without an SWD debug reset, the firmware runs correctly. However, when we enter the debug session using the Debug Mailbox reset procedure described above, the firmware does not start correctly. The debug connection is lost when single-stepping through the following SDK function: static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_Type *base, spc_dcdc_voltage_level_t voltageLevel) { base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(voltageLevel); } More specifically, the connection is lost when ACTIVE_CFG is written to change the active-mode DCDC voltage level. The behavior is therefore different between the following two cases: 1. Cold power-on: The firmware starts and runs normally. 2. Debug Mailbox reset followed by start-debug-session and SWD connection: The firmware reaches the SPC DCDC configuration, but the debugger loses the target when ACTIVE_CFG is written, and the application cannot start normally. Could the Debug Mailbox reset leave the SPC, DCDC, GDET, or reset status in a different state compared with a full power-on reset? Is there a required sequence before modifying SPC ACTIVE_CFG after starting a Debug Mailbox debug session? For example: - waiting for SPC_SC[BUSY] to clear; - clearing an SPC or GDET status flag; - unlocking or disabling glitch detection; - using a specific reset type; - avoiding a soft reset after start-debug-session; - or applying the complete LS_preconnect_MCXN5XX.scp sequence? Could writing the DCDC voltage level while debugging trigger a GDET event, DCDC protection event, brownout reset, or another system reset? Please also advise which registers we should capture immediately before the ACTIVE_CFG write. We can provide values for registers such as SPC_SC, SPC_CNTRL, SPC_ACTIVE_CFG, SPC_GLITCH_DETECT_SC, CMC_SRS, CMC_SSRS, and the Debug Mailbox CSW. Best Regards, Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT This is a tough one! Debugging connection issues can be really frustrating, especially with custom boards. That "WIRE ACK FAULT" definitely points to a communication breakdown. Have you had any luck trying different SWD clock speeds, or perhaps checking the power supply to the MCU during the debug session? Sometimes a marginal power delivery can cause these kinds of intermittent failures. It reminds me a bit of trying to get a perfect run in Snow Rider 3D – one small misstep can throw everything off! I hope you get to the bottom of it soon!

i.MX8M Plus - SD2_VSEL 固定为 3.3V 大家好， 我需要SD2电压为3.3V。我的设计中不需要1.8V。 那么我可以将PD放置在SD_VSEL（PMIC引脚）上，使电压固定在3.3V吗？ 此外，我还可以从SoC中节省一个GPIO引脚。 只进行硬件控制而不进行软件控制是否可以？ i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Re: i.MX8M Plus - SD2_VSEL fixed at 3.3V 嗨@ramkrish ， 感谢您联系恩智浦技术支持！ 在 EVK 上，SD 卡电压开关信号连接到处理器的 GPIO。 SD 驱动程序在卡初始化和协商过程中自动在 3.3V 和 1.8V 之间切换。如果检测到高速 microSD 卡，并且该卡和主机都支持较低电压运行，则驱动程序将切换到 1.8V 信号以启用更高性能模式。 如有需要，您也可以手动控制 SD 接口电压。但是，该系统已经设计成可以根据运行条件自动处理电压转换。 此致， 查维拉

S32 Design Studio for ARM v2.2许可延期 您好，S32 Design Studio for ARM v2.2，Activation Code：FAF2-FCC2-8A8E-87AC，麻烦帮我延期，谢谢！ Hello, I need help extending the activation period for my S32 Design Studio for ARM v2.2 installation. Activation Code: FAF2-FCC2-8A8E-87AC. Thank you! Re: S32 Design Studio for ARM v2.2许可延期 你好， 我们已延长您的许可证期限。 顺祝商祺！ Peter

LS1088A 上的 DDRv 工具存在问题 您好，我正在尝试在基于 LS1088A SoC 的定制板上验证一种新型 DDR4 SO-DIMM，但我遇到了 DDRv 问题。我之前已经验证过其他几款DDR4内存，没有遇到任何问题。 我正在尝试验证的新型 DDR 芯片是来自 Memphis 的 IMM2G72D4SOD8AG-B075I。它的速度等级为 2,666，但我们希望它的运行速度为 2,100 MT/s。我创建了一个新的 QorQ 配置项目，并通过 SPD 成功读取了 DDR 配置。然而，第一步（时钟居中）在“自动搜索和检测写入均衡起始值”部分始终以 0.04% 的失败率失败。 在测试结果摘要中，我看到测试失败，原因是：“DDR接口故障并非由WRLVL_START值引起，请检查板上的硬件问题。 ” 在“日志”部分，我看到以下信息： ################## ## Result for: wrlvl_searcher ## ## ## Run  1 ## ####################################   测试结果：[ ============================================================ 已更新：WRLVL_CNTL = 0x86550605，WRLVL_CNTL_2 = 0x00000000，WRLVL_CNTL_3 = 0x00000000，SDRAM_CLK_CNTL = 0x02800000     ============================================================ 已更新：WRLVL_CNTL = 0x86550607，WRLVL_CNTL_2 = 0x09060C0F，WRLVL_CNTL_3 = 0x0E110B0E，SDRAM_CLK_CNTL = 0x02800000     ============================================================ 已更新：WRLVL_CNTL = 0x86550607，WRLVL_CNTL_2 = 0x09050C0F，WRLVL_CNTL_3 = 0x1611130E，SDRAM_CLK_CNTL = 0x02800000     DDR接口故障并非由于WRLVL_START值的问题，请检查主板上的硬件问题。 测试失败！ {{DDR interface is failing due to an issue other than WRLVL_START values, please investigate HW issues on the board.}}     错误捕获寄存器： 0xE20, 0x00000000 0xE24, 0x00000000 0xE28, 0x00000000 0xE40, 0x00000080 0xE44, 0x00000000 0xE48, 0x0000001D 0xE4C, 0x00000000 0xE50, 0x00000000 0xE54, 0x00000000 0xE58, 0x00010000     倾倒： 0xF00, 0x00000000 0xF04, 0x00001002 0xF08, 0x0000000A 0xF0C, 0x14000C20 0xF10, 0x00000000 0xF14, 0x00000000 0xF18, 0x00000000 0xF1C, 0x00000000 0xF20, 0x00000000 0xF24, 0x2F003500 0xF28, 0x2A003600 0xF2C, 0x3E004A00 0xF30, 0x44004600 0xF34, 0x3A007000 0xF38, 0x00000000 0xF3C, 0x00000000 0xF40, 0x00000000 0xF44, 0x00000000 0xF48, 0x00000001 0xF4C, 0x94000000 0xF50, 0x0F001300 0xF54, 0x0C001800 0xF58, 0x1F002C00 0xF5C, 0x22002700 0xF60, 0x1C000000 0xF64, 0x00009000 0xF68, 0x00000020 0xF6C, 0x00000000 0xF70, 0x0060007B 0xF74, 0x00000000 0xF78, 0x00000000 0xF7C, 0x00000000 0xF80, 0x00000000 0xF84, 0x00000000 0xF88, 0x00000000 0xF8C, 0x00000000 0xF90, 0x00000000 0xF94, 0x80000000 0xF98, 0x00000000 0xF9C, 0x29002B00 0xFA0, 0x2B002B00 0xFA4, 0x27002D00 0xFA8, 0x28002E00 0xFAC, 0x27000000 0xFB0, 0x10000003 0xFB4, 0x42344241 0xFB8, 0x40334332 0xFBC, 0x43404150 0xFC0, 0x00004133 0xFC4, 0x44424444 0xFC8, 0x44415134 0xFCC, 0x51414251 0xFD0, 0x42414241 0xFD4, 0x50434252 0xFD8, 0x50444342 0xFDC, 0x42413444 0xFE0, 0x43514340 0xFE4, 0x44424444 0xFE8, 0x42514441 0xFEC, 0x40423443 0xFF0, 0x43424342 0xFF4, 0x43415042 0xFF8, 0x51415341 0xFFC, 0x54000D0D       数据： 0x00000005 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000   ]   我还附上了验证失败过程中的详细 CCS 日志。   请问这是什么意思？我们该如何调试这个问题？ QorIQ LS1设备 Re: Problem with DDRv tool on LS1088A 与新型DDR4 SO-DIMM相比，以前使用的是哪种SO-DIMM？新旧版本之间的任何变化 Re: Problem with DDRv tool on LS1088A 你好， 对于您提供的具体转储，最可行的解释是：控制器在训练期间引发了自动校准错误 ( ACE )，DDRv 的写入均衡搜索无法通过调整 WRLVL_START 找到有效的运行区域。首先，这指向 RESET/时钟/配置/DQ-map/SI 检查，其中 DDR RESET 和 DQn_MAP 排在首位，因为在 NXP 调试历史中，两者都反复与此 DDRv 故障类别相关联。因此，在调整裕量之前，请验证 DDR 时钟/RCW、DDR RESET 时序、SPD 衍生的秩/几何、DQ 映射和功耗/SI。 此致

S32 Design Studio for ARM v2.2 license extended Hello, I need help extending the activation period for my S32 Design Studio for ARM v2.2 installation. Activation Code: FAF2-FCC2-8A8E-87AC. Thank you! Hello, I need help extending the activation period for my S32 Design Studio for ARM v2.2 installation. Activation Code: FAF2-FCC2-8A8E-87AC. Thank you! Re: S32 Design Studio for ARM v2.2许可延期 Hello, We have extended your license. Best regards, Peter

i.MX8M Plus - SD2_VSEL fixed at 3.3V Hi Team, I have a requirement of SD2 Voltage at 3.3V. I dont want 1.8V in my design. So Can I place PD in SD_VSEL (PMIC Pin) so that Voltage is fixed at 3.3V? Also I can save one GPIO pin from SoC Is it okay to proceed with HW Control and no SW Control will be provided? i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Re: i.MX8M Plus - SD2_VSEL fixed at 3.3V HI @ramkrish, Thank you for contacting NXP Support! On the EVK, the SD card voltage switching signal is connected to a GPIO of the processor. The SD driver automatically switches between 3.3V and 1.8V during the card initialization and negotiation process. If a high speed microSD card is detected and both the card and host support lower voltage operation, the driver will transition to 1.8V signaling to enable higher performance modes. You can also control the SD interface voltage manually if required. However, the system is already designed to handle the voltage transition automatically whenever the operating conditions require it. Best regards, Chavira

LS1088AのDDRvツールに問題があります こんにちは、LS1088A SoCベースのカスタムボード上で新しいタイプのDDR4 SO-DIMMを検証しようとしているのですが、DDRvで問題が発生しています。過去にいくつかのDDR4モデルを検証しましたが、問題は発生しませんでした。 私が検証しようとしている新しいDDRモデルは、メンフィスのB075I IMM2G72D4SOD8AGです。その速度制限は2,666ですが、2,100MT/sで運行したいと考えています。QorQの新しい構成プロジェクトを作成し、SPD経由でDDR構成を正常に読み込むことができました。しかし、最初のステップ(クロックのセンタリング)は「自動検索と書き込みレベリング開始値の検出」部分で0.04%で一貫して失敗します。 テスト結果の概要を見ると、テストが失敗し、理由は「DDRインターフェースがWRLVL_START値以外の原因で故障しています。ボードのハードウェア問題を調査してください。" ログセクションには、以下の情報が表示されます。 ################## ## Result for: wrlvl_searcher ## ## ## Run  1 ## ####################################   テスト結果: [ ============================================================ 更新: WRLVL_CNTL = 0x86550605、WRLVL_CNTL_2 = 0x00000000、WRLVL_CNTL_3 = 0x00000000、SDRAM_CLK_CNTL = 0x02800000     ============================================================ 更新: WRLVL_CNTL = 0x86550607、WRLVL_CNTL_2 = 0x09060C0F、WRLVL_CNTL_3 = 0x0E110B0E、SDRAM_CLK_CNTL = 0x02800000     ============================================================ 更新: WRLVL_CNTL = 0x86550607、WRLVL_CNTL_2 = 0x09050C0F、WRLVL_CNTL_3 = 0x1611130E、SDRAM_CLK_CNTL = 0x02800000     DDRインターフェースがWRLVL_START値以外の原因で故障しているので、基板のハードウェア問題を調査してください。 <> {{DDR interface is failing due to an issue other than WRLVL_START values, please investigate HW issues on the board.}}     エラーキャプチャレジスタ: 0xE20、0x00000000 0xE24、0x00000000 0xE28、0x00000000 0xE40、0x00000080 0xE44、0x00000000 0xE48、0x0000001D 0xE4C、0x00000000 0xE50、0x00000000 0xE54、0x00000000 0xE58、0x00010000     ごみ： 0xF00、0x00000000 0xF04、0x00001002 0xF08、0x0000000A 0xF0C、0x14000C20 0xF10、0x00000000 0xF14、0x00000000 0xF18、0x00000000 0xF1C、0x00000000 0xF20、0x00000000 0xF24、0x2F003500 0xF28、0x2A003600 0xF2C、0x3E004A00 0xF30、0x44004600 0xF34、0x3A007000 0xF38、0x00000000 0xF3C、0x00000000 0xF40、0x00000000 0xF44、0x00000000 0xF48、0x00000001 0xF4C、0x94000000 0xF50、0x0F001300 0xF54、0x0C001800 0xF58、0x1F002C00 0xF5C、0x22002700 0xF60、0x1C000000 0xF64、0x00009000 0xF68、0x00000020 0xF6C、0x00000000 0xF70、0x0060007B 0xF74、0x00000000 0xF78、0x00000000 0xF7C、0x00000000 0xF80、0x00000000 0xF84、0x00000000 0xF88、0x00000000 0xF8C、0x00000000 0xF90、0x00000000 0xF94、0x80000000 0xF98、0x00000000 0xF9C、0x29002B00 0xFA0、0x2B002B00 0xFA4、0x27002D00 0xFA8、0x28002E00 0xFAC、0x27000000 0xFB0、0x10000003 0xFB4、0x42344241 0xFB8、0x40334332 0xFBC、0x43404150 0xFC0、0x00004133 0xFC4、0x44424444 0xFC8、0x44415134 0xFCC、0x51414251 0xFD0、0x42414241 0xFD4、0x50434252 0xFD8、0x50444342 0xFDC、0x42413444 0xFE0、0x43514340 0xFE4、0x44424444 0xFE8、0x42514441 0xFEC、0x40423443 0xFF0、0x43424342 0xFF4、0x43415042 0xFF8、0x51415341 0xFFC、0x54000D0D       データ： 0x00000005 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000   ]   検証手順が失敗した際の詳細なCCSログも添付しました。   これが何を意味するのか、また問題のデバッグ方法を説明していただけますか? QorIQ LS1デバイス Re: Problem with DDRv tool on LS1088A 新しいタイプのDDR4 SO-DIMMと比べて、以前使われていたSODIMMはどのようなものでしたか?新旧間の変更点 Re: Problem with DDRv tool on LS1088A こんにちは、 あなたの具体的なダンプに関して最も有効な解釈は、コントローラがトレーニング中に自動キャリブレーションエラー( ACE )を発生させ、DDRvの書き込みレベリング検索が調整しても有効な動作領域を見つけられなかった WRLVL_START です。これはまずリセット/クロック/構成/DQマップ/SIチェックを指し示しており、DDRリセットと DQn_MAP は、NXPのデバッグ履歴においてこのDDRv障害クラスに繰り返し関連付けられているため、優先順位が高い。ですので、チューニングマージンを決める前にDDRクロック/RCW、DDRリセットタイミング、SPD由来のランク/ジオメトリ、DQマッピング、パワー/SIを確認してください。 よろしくお願いします。

S32G3 LLCE LIN マスターが「フレームタイムアウトを無効にする」がチェックアウトされているときにRx応答が欠けています NXPのエキスパートの皆様、こんにちは。 現在、S32G3(LINマスターとして動作)でLLCEコンポーネントを使ったLIN実装に取り組んでいます。私たちはS32G_LLCE_1_0_10を使用しています。 LLCE LINファームウェアのフレームタイムアウト構成に関して奇妙な挙動に遭遇しており、ファームウェアのブラックボックスロジックについて内部の詳細や説明を求めたいと思います。 問題の説明: LINチャネルを「Disable Frame Timeout」がUNCHECK(タイムアウト検出が有効)に設定し、Response Timeout値を14に設定した場合: LLCE LINマスターはヘッダー(ブレーク+同期+PID)をバスに正常に送信します。 スレーブノードはヘッダーを受信し、正しいデータとチェックサムを即座に返信します。 しかし、LLCEのLINマスターはランダムまたは継続的にデータの取得・受信に失敗します。データがLLCEファームウェアによって失われたり、破棄されたりしたかのように動作します。 回避策が見つかりました： 他のすべてのハードウェアおよび物理バス環境をまったく同じに保ったまま、設定ツールで「フレームタイムアウトを無効にする」（ファームウェアの内部タイムアウトロジックを無効にする）にチェックを入れるだけで次のようになります。 マスターはデータを一切ドロップせず、スレーブからのすべての応答を正常に受信します。 私たちの質問： LLCE_firmware_user_guide.pdfには内部ステートマシンに関する情報が非常に限られているため、この動作に困惑しています。 LLCEファームウェア内部では、タイムアウト値「14」はどのように正確に計算されるのですか？値14は、特定のGPT/タイマークロックソースに関連する絶対マイクロ秒、ビット時間、またはサイクルを表しますか？ 奴隷が即座に返答したにもかかわらず、なぜ主人はその反応を捉えられないのか？タイムアウトカウンターが早すぎる(例えばヘッダーの送信が終わる前)に始まっている可能性はありますか?それとも「14」という閾値が内部ハードウェアやファームウェアのレイテンシのために小さすぎるのでしょうか? 有効な応答を破棄することなくフレームタイムアウト保護を有効にしたままにしたい場合、このタイムアウト値を適切に計算して設定するための推奨される方法はありますか？ LLCE LINファームウェアの内部タイミングロジックに関するドキュメントやアプリケーションノート、洞察があれば大変ありがたいです。 よろしくお願いいたします！ よろしくお願いします、 cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、 @cjq ご説明ありがとうございます。 1.DisableFrameTimeoutボックスにチェックを入れると、Linドライバーは最大フレーム長より長いフレームを受け入れます。 2. 「LinResponseTimeout」の場合、リセット値は0Eh = 14で、これはT_Response_Maximum = 1.4 x T_Response_Nominalに対応します。これは1バイトの応答タイムアウト時間（ビット時間）です。 BR チェイン   Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、チェンインさん 迅速なご対応ありがとうございます。ご質問への回答と、ファームウェアのバージョンに関する訂正事項を以下にご説明いたします。 ハードウェア：弊社では、NXPの公式リファレンスボードではなく、S32G3をベースにしたカスタムボードを使用しています。 実装：公式のサンプルを直接実行しているわけではありません。これは当社独自の実装ですが、NXPの公式サンプルコードを参考に開発されています。 ファームウェアバージョンの訂正：最初の投稿でバージョンに関して間違いがあったことに気づきました。実際にはS32G_LLCE_1_0_10ではなく、S32G_LLCE_1_0_09を使用しています。 バージョン1.0.09のLIN応答タイムアウトに関連する既知のバグや、この特定のファームウェアバージョンでタイムアウト値「14」がどう解釈されるか確認を手伝ってもらえますか? よろしくお願いいたします、cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、 @cjq 投稿ありがとうございます。 1. NXPのS32G3ベースのカスタムボード、またはリファレンスボードのどちらをお使いでしょうか？ 2. この問題は、お客様独自の実装で発生したものですか、それともNXPが提供するサンプルで発生したものですか？ BR チェイン Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、チェンインさん ご説明いただきありがとうございます。アプリケーションでDisableFrameTimeoutをチェックし続けることに決めたため、特定のタイムアウト計算は問題になりません。 ただし、DisableFrameTimeoutが有効になっている場合のファームウェアの状態マシンに関する特定の動作について確認しておきたいと思います。 LINマスターがヘッダーを送信し、スレーブが応答しない場合、Lin_GetStatus()を呼び出すとチャネルがLIN_TX_BUSY状態に永久に 固定 されます。 この構成において、LIN_TX_BUSY状態が永続的に続くのは、LLCEファームウェアの想定される正常な動作なのでしょうか？ フレームタイムアウトロジックが完全に無効になっているため、内部ステートマシンは応答データを無期限に待ち続け、ビジー状態から自動的に移行することはないだろうと私は推測します。自分の理解が公式設計と一致しているか確認したいだけです。 よろしくお願いいたします、cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked こんにちは、 @cjq ご返信ありがとうございます。 フレームタイムアウトが無効でスレーブ応答がない場合、状態機械LLCE_LIN応答完了イベントもタイムアウトイベントも受け取らないため、問題が生じます。したがって、応答なし検出が必要な場合はフレームタイムアウトを有効にするか、LINチャネルを中止・再初期化するアプリケーションレベルのタイムアウトを実装してください。 BR チェイン

MCXN547：SWD DP ID 可读，但 AP0/AP2 访问返回 WIRE ACK FAULT 错误。 您好，NXP技术支持， 我们使用定制板上的 MCXN547VKLT，并带有外部 MCU-Link 探针。 启动调试会话时，SWD 连接失败： Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. 可以正确检测到SWD-DP： DPID = 0x6BA02477 但是，访问 CPU0 AHB-AP (AP0) 失败，并显示以下错误信息： WIRE ACK FAULT 调试邮箱请求也失败了。LinkServer报告： DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR 我们已核实的内容： SWD频率测试范围从1 MHz到10 kHz 在示波器上，SWDIO 和 SWCLK 波形看起来正常。 VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDC 和 I/O 电源 = 3.3 V RESET_B 工作正常 MCU-Link固件：CMSIS-DAP V3.172 LinkServer 版本：26.5.59 同一个 MCU-Link 可以与 MCXN947 开发板配合使用。 MCXN547芯片已更换为新芯片，但问题仍然存在。 USB ISP 与 VID/PID 1FC9:014F 配合使用正常。使用 blhost，我们可以： 擦除内部闪存 对内部闪存进行编程和读取 应用程序运行成功 枚举应用程序 USB 复合设备 ROM报告： Security State = UNSECURE 我们还通过 USB ISP 读取 PFR： CMPA 已完全擦除 (0xFF) 除了ROM生成的CMAC之外，CFPA已被擦除。 不存在客户 SOCU 或调试身份验证配置 请问您能否提供以下建议： AP0 和 AP2 可访问需要满足哪些条件？ DM-AP 状态 0x60F93638 是否与已知的电源、RESET 或硬件配置问题相关？ 是否存在与 SWD 或调试邮箱访问相关的已知 MCXN547 勘误表？ 我们应该检查哪些电源和 RESET 信号才能发现此症状？ MCX N Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT 你好，路易斯， 现在我们已经能够使用 SPSDK 调试邮箱工具建立 SWD 调试连接。 我们采用的步骤如下： 1. 通过调试邮箱重置MCU： nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ 工具 RESET -f mcxn547 2. 通过调试邮箱启动调试会话： nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ cmd -f mcxn547 start-debug-session 3. 调试会话打开后，我们通过 SWD 使用 LinkServer 连接到 Cortex-M33 内核。 我们没有使用任何身份验证密钥、密码、调试凭据或批量擦除命令。“start-debug-session”命令似乎通过始终可访问的 AP2 调试邮箱暂时启用 AP0。 在打开调试会话后，我们还使用了 NXP LS_preconnect_MCXN5XX.scp 脚本中的 GDET 寄存器序列。该序列禁用 aGDET 和 dGDET 复位路由，并在调试期间禁用 SPC 毛刺检测。 关于电源方面： - VDD_VBAT 直接连接到 VDD，两者均为 3.3 V。 - VDD_P4 直接连接到 VDD，两者均为 3.3 V。 - VDD_ANA 通过铁氧体磁珠连接到 VDD。 - VDD 为 3.3 V。 但是，我们现在又遇到了另一个调试问题。 当电路板正常上电且未进行 SWD 调试复位时，固件运行正常。但是，当我们使用上面描述的调试邮箱重置程序进入调试会话时，固件无法正确启动。 单步执行以下 SDK 函数时，调试连接丢失： static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_Type *base， spc_dcdc_voltage_level_t voltageLevel) { base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(电压等级); } 更具体地说，当写入 ACTIVE_CFG 以更改运行模式 DCDC 电压等级时，连接会丢失。 因此，以下两种情况下的行为有所不同： 1. 冷启动： 固件启动并正常运行。 2. 重置调试邮箱，然后启动调试会话并建立 SWD 连接： 固件到达 SPC DCDC 配置，但写入 ACTIVE_CFG 时调试器丢失目标，应用程序无法正常启动。 与完全上电RESET相比，调试邮箱RESET是否会使 SPC、DCDC、GDET 或 RESET状态处于不同的状态？ 启动调试邮箱调试会话后，修改 SPC ACTIVE_CFG 是否有必要的步骤？例如： - 等待 SPC_SC[BUSY] 清除； - 清除 SPC 或 GDET 状态标志； - 解锁或禁用故障检测； - 使用特定的重置类型； - 避免在启动调试会话后进行软复位； 或者应用完整的 LS_preconnect_MCXN5XX.scp 序列？ 在调试过程中写入 DCDC 电压等级是否会触发 GDET 事件、DCDC 保护事件、欠压 RESET 或其他系统 RESET？ 另外，请告知在写入 ACTIVE_CFG 之前应该立即捕获哪些寄存器。我们可以为 SPC_SC、SPC_CNTRL、SPC_ACTIVE_CFG、SPC_GLITCH_DETECT_SC、CMC_SRS、CMC_SSRS 和调试邮箱 CSW 等寄存器提供值。 顺祝商祺！ Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT 这可真是个难题！调试连接问题可能非常令人沮丧，尤其是在使用定制电路板时。“线路确认故障”肯定表明通信出现故障。您尝试过不同的SWD时钟速度，或者在调试过程中检查MCU的电源，有没有取得什么进展？有时，电力供应不足会导致这类间歇性故障。这让我想起了在《雪地骑士 3D》中追求完美滑行的感觉——一个小小的失误就可能让一切功亏一篑！希望你尽快查明真相！

IMXRT LPUART non-blocking transfer API makes error handling difficult Hi, I've been looking at the "transfer" API for LPUART, for interrupt-based non-blocking transfers.  It seems to do a decent job of wrapping all the "happy case" handling of LPUART interrupts, etc, and providing a good high level API for just receiving data when it's ready (i.e. handling IDLE, RX ready, TX complete, etc).  However, it makes handling UART errors very difficult.  There is no error handling inside the LPUART_TransferHandleIRQ function, and just after that function in fsl_lpuart.c is a bogus empty LPUART_TransferHandleErrorIRQ containing a comment "To be implemented by the user".  This looks completely half-baked. The only way to actually handle UART errors seems to be to override the default LPUARTx_IRQHandler functions so that instead of calling LPUARTx_RX_DriverIRQHandler (or TX), you'd have to call your own function that handles errors and passes on "happy case" interrupts to the original LPUARTx_RX/TX_DriverIRQHandler so it can call into LPUART_TransferHandleErrorIRQ. In addition you'd have to enable those error interrupts yourself outside the transfer API by calling LPUART_EnableInterrupts, and in your error handling also call LPUART_DisableInterrupts and deal with clearing them, etc. This seems like a lot of extra hassle to handle errors.  Why is this not baked into the transfer API itself? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult Hello @nxp16, Thank you for the detailed feedback. I understand that the SDK could be a little ambiguous since these are intended to provide a common use cases for each peripheral functionality. We are constantly working to improve our APIs thanks also of recommendations like this. Thank you for the recommendations, and we hope that LPUART's error handling will be implemented in future releases. On the other hand, could you please let me know which specific error conditions you are interested in handling and which device you are using? With that information, I can suggest documentation related to those error conditions that may help with your implementation. BR Habib Re: IMXRT LPUART non-blocking transfer API makes error handling difficult Hello @nxp16, I understand that this may require additional development time, sorry for that, we continuing working to improve our SDKs. As a reference, you may review the following structure of the SDK (version 26.6) function called "LPUART_TransferHandleIRQ" and implement a similar recovery flow as your application requires. Habib_MS_1-1784062752001.png BR Habib Re: IMXRT LPUART non-blocking transfer API makes error handling difficult All possible errors.  This applies to pretty much all peripherals (SPI, I2C, etc) that have a transfer API but no error handling.  LPUART on IMXRT1172 specifically has framing, parity, and noise errors that aren't handled.  Unfortunately right now all these peripherals require some hacking to handle errors when using the transfer API.  I had to override the actual default IRQ handlers to check for errors before calling the SDK handler. Thanks, -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult Hello @nxp16, Please let me know if you have any further questions. BR Habib Re: IMXRT LPUART non-blocking transfer API makes error handling difficult Yes, I've already implemented something similar.  Thanks for sending that.

IMXRT LPUARTの非ブロッキング転送APIはエラー処理を困難にする こんにちは、 私は、割り込みベースのノンブロッキング転送を行うためのLPUARTの「転送」APIについて調べています。LPUART割り込みなどの「ハッピーケース」処理をうまくラップし、準備ができたときにだけデータを受信できる良い高水準APIを提供しているようです。アイドル状態、受信準備完了、送信完了などの処理。しかし、これによってUARTエラーの処理が非常に困難になる。 LPUART_TransferHandleIRQ関数内にはエラー処理がなく、fsl_lpuart.cのその関数の直後には「ユーザーによって実装される」というコメントを含む偽の空LPUART_TransferHandleErrorIRQがあります。これは完全に未完成に見える。 UARTエラーを実際に処理する唯一の方法は、デフォルトのLPUARTx_IRQHandler関数を上書きし、LPUARTx_RX_DriverIRQHandler(またはTX)を呼び出す代わりに、自分でエラーを処理し、「ハッピーCASE」割り込みを元のLPUARTx_RX/TX_DriverIRQHandlerに渡してLPUART_TransferHandleErrorIRQに呼び出すようにすることのようです。 さらに、転送APIの外部でLPUART_EnableInterruptsを呼び出してエラー割り込みを自分で有効にし、エラー処理の中でLPUART_DisableInterruptsを呼び出してそれらをクリアするなどの処理を行う必要があります。 エラー処理にこれだけの手間をかけるのは、かなり面倒な作業のように思える。なぜこの機能が転送API自体に組み込まれていないのでしょうか？ -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 詳細なフィードバックをありがとうございます。SDKは各ペリフェラル機能の共通ユースケースを提供するためのものなので、少し曖昧な部分もあることは理解しています。このようなご意見も参考にしながら、私たちは常にAPIの改善に取り組んでいます。ご提案ありがとうございます。今後のリリースでもLPUARTのエラー処理が実装されることを願っています。 一方で、どのエラー条件を扱いたいのか、どのデバイスを使っているのか教えていただけますか?その情報をもとに、実装に役立つエラー条件に関するドキュメントを提案できます。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 考えられるすべてのエラー。これは、転送APIはあるがエラー処理がないほぼすべてのペリフェラル(SPI、I2Cなど)に当てはまります。IMXRT1172のLPUARTには、特にフレーミングエラー、パリティエラー、ノイズエラーがあり、これらは適切に処理されていません。残念ながら現状、これらのペリフェラルは転送API使用時のエラー処理にハッキングが必要です。SDKハンドラーを呼び出す前に、エラーを確認するために実際のデフォルトのIRQハンドラをオーバーライドしなければなりませんでした。 ありがとうございます -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 追加の開発期間が必要になる可能性があることは理解していますが、SDKsの改善に引き続き取り組んでいます。参考として、SDK(バージョン26.6)の関数「LPUART_TransferHandleIRQ」の構造を確認し、アプリケーションが必要とする類似の回復フローを実装できます。 Habib_MS_1-1784062752001.png BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 他に質問がありましたら、お気軽にお知らせください。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult はい、既に似たようなものを実装しています。送っていただきありがとうございます。

MCXN547:SWD DP IDは読み取れるが、AP0/AP2アクセスはWIRE ACKフォルトを返す こんにちは、NXPサポートの皆さん、 カスタムボード上のMCXN547VKLTと外部のMCU-Linkプローブを使用しています。 デバッグセッションを開始する際にSWD接続が失敗する： Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. SWD-DPは正しく検出できます: DPID = 0x6BA02477 しかし、CPU0 AHB-AP(AP0)へのアクセスは以下の場合に失敗します: WIRE ACK FAULT デバッグ用メールボックスのリクエストも失敗します。LinkServer のレポート: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR 確認した内容： SWD周波数は1MHzから10kHzまでテスト済み。 SWDIOとSWCLKの波形はオシロスコープ上で良好に見える。 VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDCおよびI/O電源 = 3.3V RESET_Bは正しく動作します MCU-Linkファームウェア:CMSIS-DAP V3.172 LinkServer バージョン: 26.5.59 同じMCU-LinkはMCXN947開発ボードで動作します MCXN547は新しいチップに交換されたが、問題は解決していない。 USB ISPはVID/PID 1FC9:014Fで正しく動作します。blhostを使えば、以下ができます: 内部フラッシュを消す 内部フラッシュのプログラムと読み取り アプリケーションを正常に実行してください アプリケーションのUSBコンポジットデバイスを列挙します ROMの報告によると、 Security State = UNSECURE USB ISP経由でPFRも読み取りました。 CMPAは完全に消去されました（0xFF） CFPAはROMで生成されたCMACを除いて消去されます。 お客様向けのSOCUやデバッグ認証の設定は存在しません 何かアドバイスをいただけますか: AP0とAP2が利用可能になるには、どのような条件が必要ですか？ DM-APステータス0x60F93638は、既知の電源、リセット、またはハードウェア構成の問題に関連していますか？ SWDやDebug Mailboxへのアクセスに関する既知のMCXN547エラタはありますか? この症状を確認するには、どの電源信号とリセット信号をチェックすればよいでしょうか？ MCX N Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT こんにちは、ルイスさん。 SPSDKデバッグメールボックスツールを使用して、SWDデバッグ接続を確立することができました。 私たちが用いた手順は以下のとおりです。 1. デバッグメールボックスを通じてMCUをリセットする: NXPDEBUGMBOX -i MCU-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=真 \ --オペレーションタイムアウト 5000 \ ツールリセット -f mcxn547 2. デバッグメールボックスからデバッグセッションを開始します。 NXPDEBUGMBOX -i MCU-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=真 \ --オペレーションタイムアウト 5000 \ cmd -f mcxn547 start-debug-session 3. デバッグセッションが開かれた後、SWD経由でLinkServerを使ってCortex-M33コアに接続します。 認証キー、パスワード、デバッグ認証情報、一括消去コマンドは一切使用しませんでした。「start-debug-session」コマンドは、常時アクセス可能なAP2デバッグメールボックスを介して、一時的にAP0を有効にするようです。 デバッグセッションを開いた後、NXP LS_preconnect_MCXN5XX.scpスクリプトからGDETレジスタシーケンスも使用しました。このシーケンスは、デバッグ中にaGDETおよびdGDETのリセットルーティングを無効にし、SPCグリッチ検出を無効にします。 電源装置に関して： - VDD_VBATはVDDに直接接続されており、どちらも3.3Vです。 - VDD_P4はVDDに直接接続されており、どちらも3.3Vです。 - VDD_ANAはフェライトビーズを介してVDDに接続されています。 - VDDは3.3Vです。 しかし、今度は別のデバッグ問題が発生しました。 SWDデバッグリセットを行わずにボードを通常通り電源投入した場合、ファームウェアは正しく動作します。しかし、上記のデバッグメールボックスリセット手順を使用してデバッグセッションに入ると、ファームウェアが正しく起動しません。 以下のSDK関数をシングルステップで実行するとデバッグ接続が失われます。 static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_タイプ *ベース、 spc_dcdc_voltage_level_t voltageLevel) ヤージュ base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(voltageLevel); } より具体的に言うと、アクティブモードのDCDC電圧レベルを変更するためにACTIVE_CFGが書き込まれると、接続が失われます。 したがって、以下の2つの場合で挙動が異なります。 1. 電源投入時の冷間状態： ファームウェアは正常に起動し、正常に動作します。 2. デバッグ:メールボックスリセット、続いて開始・デバッグセッションおよびSWD接続: ファームウェアはSPC DCDC構成に到達しますが、ACTIVE_CFGが書き込まれるとデバッガはターゲットを失い、アプリケーションは通常起動できません。 デバッグメールボックスのリセットが、完全な電源オンリセットと異なる状態にしてしまいますか? デバッグメールボックスのデバッグセッションを開始した後、SPC ACTIVE_CFGを変更する前に、必要な手順はありますか？例えば： - SPC_SC[BUSY]がクリアされるのを待っています。 - SPCまたはGDETステータスフラグをクリアする。 - グリッチ検出のロック解除または無効化。 - 特定のリセットタイプを使用する。 - デバッグセッション開始後のソフトリセットを回避する。 または、LS_preconnect_MCXN5XX.scp シーケンス全体を適用する？ デバッグ中にDCDC電圧レベルを書き込むと、GDETイベント、DCDC保護イベント、ブラウンアウトリセット、または別のシステムリセットがトリガーされる可能性はありますか? ACTIVE_CFG書き込みの直前に取得すべきレジスタについてもご教示ください。SPC_SC、SPC_CNTRL、SPC_ACTIVE_CFG、SPC_GLITCH_DETECT_SC、CMC_SRS、CMC_SSRS、そしてデバッグメールボックスCSWなどのレジスタの値を提供できます。 よろしくお願いいたします。 Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT これは難しい問題だ！接続問題のデバッグは特にカスタムボードの場合非常にフラストレーションが溜まります。その「WIRE ACK FAULT」は、間違いなく通信障害を示しています。異なるSWDクロック速度を試したり、デバッグセッション中にMCUの電源を確認したりしてみましたか?時には限界的な電力供給がこのような断続的な故障を引き起こすことがあります。これは Snow Rider 3D で完璧なランを狙うような感覚を少し思い出させます。ほんの小さなミスで全てが狂ってしまうこともあります!早く真相が解明されることを願っています！

当“禁用帧超时”未选中时，S32G3 LLCE LIN 主站缺少接收响应 各位NXP专家，大家好！ 我目前正在使用 S32G3 上的 LLCE 元器件（作为 LIN 主控运行）进行 LIN 实现。我们正在使用 S32G_LLCE_1_0_10。 我们在 LLCE LIN 固件的帧超时配置方面遇到了奇怪的问题，我想了解一些关于固件黑盒逻辑的内部细节或说明。 问题描述： 配置 LIN 通道时，如果“禁用帧超时”未选中（即启用超时检测），并将响应超时值设置为 14： LLCE LIN 主站成功将报头（中断 + 同步 + PID）发送到总线。 从节点接收到头部信息后，立即返回正确的数据和校验和。 但是，LLCE LIN 主站会随机或持续地无法捕获/接收数据。表现得好像数据被 LLCE 固件丢失或丢弃了一样。 找到解决方法： 如果我们在配置工具中仅勾选“禁用帧超时”（禁用固件的内部超时逻辑），同时保持所有其他硬件和物理总线环境完全相同： 主设备从不丢失任何数据，并成功接收从设备的每一个响应。 我们的问题： 由于 LLCE_firmware_user_guide.pdf 提供的关于内部状态机的信息非常有限，我们对这种行为感到困惑： LLCE固件内部是如何精确计算超时值“14”的？值 14 代表的是绝对微秒、比特时间，还是与特定 GPT/定时器时钟源相关的周期？ 为什么即使从设备立即回复，主设备也无法获取响应？超时计数器是否有可能启动过早（例如，在报头传输完成之前），或者由于某些内部硬件/固件执行延迟，“14”作为阈值是否太小？ 如果我们想在不丢弃有效响应的情况下保持帧超时保护处于活动状态，那么正确计算和设置此超时值的推荐方法是什么？ 任何有关 LLCE LIN 固件内部时序逻辑的文档、应用笔记或见解都将不胜感激。 提前感谢！ 此致， cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 你好， @cjq 谢谢你的解释。 1.如果选中“禁用帧超时”框，则 Lin 驱动程序将接受长度超过最大帧长度的帧。 2. 对于“LinResponseTimeout”，重置值为 0Eh = 14，对应于 T_Response_Maximum = 1.4 x T_Response_Nominal。这是 1 字节的响应超时持续时间（以比特时间为单位）。 BR 陈银   Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 陈银你好， 感谢您的快速回复。以下是对您问题的解答，以及关于固件版本的更正： 硬件：我们使用的是基于 S32G3 的定制电路板，而不是 NXP 的官方参考电路板。 实现方式：我们没有直接运行官方示例。这是我们自行开发的，但它与 NXP 官方示例代码密切相关，并在此基础上进行了开发。 固件版本更正：我意识到我在最初的帖子中关于版本信息有误。我们实际使用的是S32G_LLCE_1_0_09 ，而不是S32G_LLCE_1_0_10。 请问您能否帮忙检查一下 1.0.09 版本中是否存在与 LIN 响应超时相关的已知错误，或者该特定固件版本是如何解释超时值“14”的？ 此致敬礼，cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 你好， @cjq 感谢分享。 1. 请问您使用的是基于 S32G3 的定制板还是 NXP 的参考板？ 2. 该问题是在您的自定义实现中发现的，还是在 NXP 配置的任何示例中发现的？ BR 陈银 Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 你好， @cjq 感谢您的回复。 如果帧超时被禁用且没有从设备响应，由于 LLCE_LIN 状态机既没有收到响应完成事件也没有收到超时事件，因此会出现问题。所以，如果需要检测无响应，请保持帧超时启用，或者实现一个应用程序级别的超时，以中止/重新初始化 LIN 通道。 BR 陈银 Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked 陈银你好， 谢谢你的解释。由于我们决定在应用程序中保持 DisableFrameTimeout 选中状态，因此具体的超时计算对我们来说不再是问题。 但是，我想确认启用 DisableFrameTimeout 时固件状态机的一个具体行为： 当 LIN 主设备发送报头而从设备未回复时，调用 Lin_GetStatus() 显示通道永久卡在 LIN_TX_BUSY状态。 在这种配置下，LLCE 固件的这种永久性 LIN_TX_BUSY 状态是否是预期和正常的运行状态？ 我推测，由于帧超时逻辑完全被禁用，内部状态机将无限期地等待响应数据，并且永远不会自动退出忙碌状态。我只是想确认一下我的理解是否与官方设计一致。 此致敬礼，cjq

S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hi NXP Experts, I am currently working on the LIN implementation using the LLCE component on S32G3 (running as a LIN Master). We are using S32G_LLCE_1_0_10. We have encountered a strange behavior regarding the Frame Timeout configuration in the LLCE LIN firmware, and I would like to seek some internal details or clarifications about the firmware's black-box logic. Problem Description: When configuring the LIN channel with "Disable Frame Timeout" UNCHECKED (meaning timeout detection is enabled) and setting the Response Timeout value to 14: The LLCE LIN Master successfully transmits the Header (Break + Sync + PID) to the bus. The Slave node receives the Header and responds with the correct Data + Checksum immediately. However, the LLCE LIN Master randomly or constantly fails to capture/receive the data. It behaves as if the data is lost or dropped by the LLCE firmware. Workaround Found: If we simply CHECK "Disable Frame Timeout" (disabling the firmware's internal timeout logic) in the configuration tool while keeping all other hardware and physical bus environments exactly the same: The Master never drops any data and successfully receives every single response from the Slave. Our Questions: Since the LLCE_firmware_user_guide.pdf provides very limited information about the internal state machine, we are confused by this behavior: How is the timeout value "14" precisely calculated inside the LLCE firmware? Does a value of 14 represent absolute microseconds, bit times, or cycles related to a specific GPT/timer clock source? Why does the Master fail to grab the response even when the Slave replies immediately? Is it possible that the timeout counter starts too early (e.g., before the Header finishes transmitting), or is "14" too small a threshold due to some internal hardware/firmware execution latency? What is the recommended way to properly calculate and set this timeout value if we do want to keep the Frame Timeout protection active without dropping valid responses? Any documentation, application notes, or insights into the LLCE LIN firmware's internal timing logic would be highly appreciated. Thanks in advance! Best regards, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hello, @cjq  Thanks for your clarification. 1. If DisableFrameTimeout box is checked, then Lin driver will accept the frame that is longer than Maximal Frame Length. 2. For "LinResponseTimeout", the reset value is 0Eh = 14, corresponding to T_Response_Maximum = 1.4 x T_Response_Nominal. This is the response timeout duration (in bit time) for 1 byte. BR Chenyin   Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hi Chenyin, Thank you for your quick response. Here are the clarifications to your questions, along with a correction regarding the firmware version: Hardware: We are using a custom board based on S32G3, not the official NXP reference board. Implementation: We are not running the official example directly. It is our custom implementation, but it is closely referenced and developed based on the official NXP sample code. Correction on Firmware Version: I realized I made a mistake regarding the version in my initial post. We are actually using S32G_LLCE_1_0_09, not S32G_LLCE_1_0_10. Could you please help check if there are any known bugs related to the LIN response timeout in version 1.0.09, or how the timeout value "14" is interpreted by this specific firmware version? Best regards, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hello, @cjq  Thanks for the post. 1. May I know if you are working with a S32G3 based custom board or reference board from NXP? 2. Is the issue found in your custom implementation or from any samples provisioned by NXP? BR Chenyin Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hi Chenyin, Thank you for the clarification. Since we have decided to keep DisableFrameTimeout checked for our application, the specific timeout calculation is no longer an issue for us. However, I would like to confirm one specific behavior regarding the firmware's state machine when DisableFrameTimeout is enabled: When the LIN Master transmits a Header and the Slave fails to reply, calling Lin_GetStatus() shows that the channel remains permanently stuck in the LIN_TX_BUSY state. Is this permanent LIN_TX_BUSY state the expected and normal behavior of the LLCE firmware under this configuration? I assume that because the frame timeout logic is entirely disabled, the internal state machine will wait indefinitely for the response data and will never automatically transition out of the busy state. I just want to verify if my understanding aligns with the official design. Best regards, cjq Re: S32G3 LLCE LIN Master missing Rx response when "Disable Frame Timeout" is unchecked Hello, @cjq  Thanks for your reply. With frame timeout disabled and no slave response, since LLCE_LIN state machine receives neither a response-complete event nor a timeout event, there would be issues, so If no-response detection is required, keep frame timeout enabled or implement an application-level timeout that aborts/reinitializes the LIN channel. BR Chenyin

Toolbox workflow 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article provides a high-level overview of the typical workflow for developing an application using the toolbox. It explains how the main development stages fit together, from preparing the environment and selecting the target hardware to configuring the project, generating code, building the application, programming the target, and validating the results. The purpose of this topic is to help users understand the overall process and to guide them toward the related articles that describe each stage in more detail. 3 Overview Workflow Scope The workflow described in this article covers the main steps typically followed when developing an application with the toolbox. After the toolbox and supporting environment are prepared, the user can create a new model or open an existing example, select the target hardware, configure the required software components, prepare the Simulink model, generate code, build the application, program the target device, and debug and validate the behavior on hardware. This article is intended as an overview topic and does not replace the more detailed setup, modeling, and debugging documentation. Target Audience This article is intended for users who want to understand the overall development flow supported by the toolbox. It is useful both for new users who start from supported examples and evaluation boards and for advanced users who need to adapt the workflow to a custom target or project configuration. 4 Context Prerequisites Before following the workflow described in this article, the development environment should already be prepared. The setup process, including toolbox installation and the basic steps required to run an application, is described in the previous article. Depending on the selected project and application requirements, additional tools such as S32 Configuration Tools or EB tresos may be needed, especially when the default project configuration must be modified or when a custom project is created. Toolbox Workflow The development flow typically starts with creating a new project or opening an existing example and then selecting the target hardware. image1.png Figure 1. Opening a Simulink project or toolbox example. The selected target determines the available peripherals, supported examples, software configuration options, and build settings. As part of this step, the user can start from the default project associated with the selected target. This default project provides a ready-to-use baseline configuration and is typically the recommended option for evaluation boards and quick start development. For more advanced use cases, the workflow can also use a custom project configuration adapted to the application requirements. image2.png Figure 2. Selecting a custom project configuration. If the user continues with the default project configuration, additional low-level software changes may be limited. However, when the default project needs to be modified or when a custom project is used, tools such as S32 Configuration Tools or EB tresos may be required. image3.png Figure 3. Low-level software configuration using EB tresos or S32 Configuration Tool.  image4.png Figure 4. S32 Configuration Tool Configuration Template. Once the software stack is prepared, the Simulink model must be configured. This includes adding and parameterizing the relevant toolbox blocks, defining the application behavior, setting the model parameters, and aligning the model with the selected target and software configuration. image5.png Figure 5. Embedded Coder. image6.png Figure 6. Build or Generate Code step. After the model configuration is complete, code can be generated from the Simulink model. This step transforms the model into source code suitable for the selected target platform. The generated output reflects both the model behavior and the configuration settings applied in the previous stages. The generated code is then built using a supported compiler toolchain. The build process compiles and links the generated code together with the required software components and libraries. Build settings may vary depending on the target, compiler version, and selected optimization or debug options. image7.png Figure 7. Generated code. After a successful build, the application can be programmed onto the target hardware and executed. At this stage, the user can debug the application using the supported debug tools, inspect signals and variables, and verify that the application behaves as expected on the real hardware platform. image8.png Figure 8. Programming and debugging the application on target hardware. The final step of the workflow is validation and iteration. If issues are found during testing or debugging, the user may need to update the model, adjust the low-level software configuration, or modify build settings. The workflow is therefore iterative, allowing repeated cycles of configuration, code generation, build, programming, and validation until the desired result is achieved. Related Topics Additional details for each workflow stage are available in related documentation topics. For environment preparation, toolbox setup, and the basic steps required to run an application, refer to the previous article. More detailed information about model creation and configuration is provided in the next article. Other related topics may include examples library, supported boards and derivatives, low-level software configuration, compiler versions and options, and debugger usage. 5 References For more detailed information, refer to the related toolbox documentation and associated setup, modeling, software configuration, compiler, and debugging articles. MathWorks Simulink MathWorks Embedded Coder Generate Code from Simulink Models 6 Conclusion The toolbox workflow provides a structured path from model-based development to execution on the target hardware. Users can start quickly from the default project associated with the selected target, while still having the flexibility to create and use a custom project configuration when required. By following this workflow and using the related detailed documentation, users can iteratively configure, build, program, debug, and validate their applications more efficiently.

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会出现“管道破裂”错误？ 在成功开始流媒体传输之前，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 期间没有报告任何内核错误，请问我应该执行哪些额外的检查或调试步骤来确定为什么流媒体播放失败并出现“管道破裂”错误？ 感谢您的支持。 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/firmware/imx/camera/ap1302.fw 并检查启动日志： dmesg | grep -i 固件 dmesg | grep -i ap1302 查找类似这样的消息： 请求固件 固件已加载 固件加载失败 第二步：你使用的是正确的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 之前，请先验证媒体图是否存在： shell media-ctl -p 显示更多行 您应该会看到类似以下的实体： ap1302 CSI 伊西 videoX 如果 /dev/media0 不存在，则相机管道创建不正确。一个非常相似的FRDM-i.MX93 AP1302案例显示： media-ctl -p 枚举 /dev/media0 失败 这表明媒体管道尚未实例化。 请检查： ls -l /dev/media* 第四项检查：检查协商好的格式 运行： v4l2-ctl --list-devices 以及 v4l2-ctl -d /dev/video0 --all 另外： media-ctl -p AP1302 固件通常输出处理后的 YUV 格式，而不是 RAW Bayer 格式。另一个常见的故障是： AP1302 输出格式 A ISI 配置为 B 格式 导致流媒体启动失败。格式不匹配通常表现为 STREAMON 故障或 CSI 管道错误。 第五项检查：在 STREAMON 期间检查 CSI 错误 打开另一个终端并进行监测： dmesg -w 然后运行： v4l2-ctl -d /dev/video0 \ --stream-mmap=3 \ --stream-count=10 查找类似这样的消息： CSI超时 帧开始超时 未收到任何数据 先进先出溢出 MIPI错误 链接未启用 这些信息通常会揭示管道破裂的真正原因。 Re: AP1302 MIPI CSI Streaming Issue on FRDM i.MX93 在进行捕获之前，需要使用以下命令设置管道。 $ media-ctl -l "'ap1302 2-003c':2 -> 'csidev-4ae00000.csi':0 [1] $ media-ctl -V "'ap1302 2-003c':0 [fmt: UYVY8_1X16/1280x800 field:none] " $ media-ctl -V "'ap1302 2-003c':2 [fmt: UYVY8_1X16/1280x800 field:none] " $ media-ctl -V "'ar0144 0':0 [fmt: UYVY8_1X16/1280x800 field:none] " $ media-ctl -V "'csidev-4ae00000.csi':1 [fmt: UYVY8_1X16/1280x800 field:none] " $ media-ctl -V "'crossbar':2 [fmt: UYVY8_1X16/1280x800 field:none] "