[lf_v2026.04]uboot-imx 补丁修复了 fsl_lpspi 中的多块传输问题 你好， 在 i.MX93 上使用 lf_v2025.04 的 uboot-imx 中，通过 fsl_lpspi 进行 SPI 传输 当一个完整的 FIFO 块紧跟在另一个块之后时，例如使用 SPI TPM 时，就会发生故障： => tpm2 获取功能 0x6 0x100 $loadaddr 20 lpspi_xfer_single：接收超时！ 根本原因：spi_xfer_single() 在每个块之后都会额外排队一个 TCR。 该命令占用 TX FIFO 条目，并且只有在延迟一段时间后才会加载。 如果下一个数据块在此之前开始，则一个数据字将不被接受。 RX 循环会一直等待直到超时。 附件中的系列补丁修复了这个问题（也适用于 lf_v2026.04）： 将 FSR TXCOUNT/RXCOUNT 掩码加宽 1/3（适用于 FIFO 更深的器件） 2/3 修复多块传输（实际修复） 3/3 将 spi_xfer_single() 改为静态函数（功能无变化） 在带有 SPI TPM 2.0（GPIO 片选）的 i.MX93 板上进行了测试。 注意：新代码最终仅在片选信号被复用为 GPIO 时才会取消置位。 但我们并未对此进行全面核实。 如果能将此功能纳入未来的 uboot-imx 版本中就太好了。 谢谢，并致以最诚挚的问候！ 第谷·基希纳 -- emlix GmbH 总部：德国哥廷根市，柏林大街12号，邮编37073 电话：+49 (0)551 30664-0，电子邮件：[email protected] 哥廷根地方法院，登记号 HR B 3160 董事总经理：Heike Jordan、Uwe Kracke 博士 增值税号：DE 205 198 055 柏林办事处：Panoramastr.德国柏林 10178 号 1 号 波恩办事处：Bachstr.德国波恩 53115 6 号 慕尼黑办事处：Am Knie 16, 81241 München, 德国 http://www.emlix.com emlix——您的嵌入式Linux合作伙伴 PS： @xiaoningwang似乎是原作者，或许您可以看看。

MCXN547 SC Timer0 SDK 驱动程序问题 我使用的是MCXN547VKL单片机和SDK版本26.06.00。 背景：我使用 SCT timer0 通过分割模式下的 COUNTER 生成两个不同的 PWM 波形，CONFIG[UNIFY] = 0；即 COUNT_L 用于一个 PWM 生成器，COUNT_H 用于另一个 PWM 生成器。 问题：当我使用驱动程序 API " SCTIMER_SetCOUNTValue(SCT0,kSCTIMER_Counter_H,0U);" 加载 COUNTER_H 时，发生总线故障。 我发现问题出在 SDK 驱动程序代码上。驱动程序代码使用 32 位写入同时写入 COUNT_H 和 COUNT_L，而不是仅使用 16 位写入 COUNT_H。在写入 COUNT_H 时，COUNT_L 正在运行，这导致了总线故障。我修改了 SDK 驱动程序代码，使其使用 16 位写入，总线故障就没有发生。我已附上驱动程序代码，并用颜色标记出导致问题的代码行和解决方法。如果这确实是问题所在，可以更新 SDK 驱动程序。- 谢谢 /*! * @brief 设置计数器的值。 * 该功能用于设置计数寄存器的值，写入 COUNT_L、COUNT_H 或统一寄存器。 只有当相应的计数器停止时（CTRL 寄存器中的 HALT 位设置为 1），才允许使用 *。 * * @Param base SCTimer 外设基地址 * @Param whichCounter 要使用的 SCTimer 计数器。在 16 位模式下，我们可以选择 Counter_L 和 Counter_H。 * 在 32 位模式下，我们可以选择 Counter_U。 * @Param value 计数器值更新到 COUNT 寄存器。 */ static inline void SCTIMER_SetCOUNTValue ( SCT_Type *base, sctimer_counter_t whichCounter, uint32_t value) { SCTIMER_StopTimer(base, ( uint32_t )whichCounter); 切换（whichCounter） { case kSCTIMER_Counter_L : assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* 当用户想要设置低计数器时，请使用 Counter_L 位 */ base-> COUNT_ACCESS16BIT.COUNTL = ( uint16_t ) value; 休息; case kSCTIMER_Counter_H : assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* 当用户想要设置高位计数器时，请使用 Counter_H 位 */ // base->COUNT = (uint32_t)base->COUNT_ACCESS16BIT.COUNTL | SCT_COUNT_CTR_H(value); base-> COUNT_ACCESS16BIT.COUNTH = ( uint16_t ) value; //修复 休息; case kSCTIMER_Counter_U : assert(1U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* 当计数器在 32 位模式下运行时，同时使用 Counter_L/Counter_H 位（统一计数器）。*/ 基本->计数= 值； 休息; 默认： /* 修复 MISRA C-2012 问题规则 16.4。*/ 休息; } SCTIMER_StartTimer(base, ( uint32_t )whichCounter); } 时钟|计时器 Re: MCXN547 SC Timer0 SDK driver Issue 你好@JawaharA 感谢您的反馈。您对总线故障原因的分析是正确的：更新 COUNT_H 需要对 COUNT 寄存器进行 32 位写入，但当前函数只会停止 H 计数器。如果 L 计数器仍在运行，则此写入访问会触发 SCT 总线错误。 然而，将对 COUNTH 的访问更改为 16 位写入不符合 SCT 硬件访问要求，因为 COUNT_H 必须与 COUNT_L 一起作为一个字写入。正确的软件解决方案是在对 COUNT 执行 32 位写入之前停止 L 计数器和 H 计数器，然后在之后恢复它们之前的运行状态。我们建议相应地审查和更新 SDK，而不是使用单独的 16 位写入 COUNT_H。 BR 哈里 Re: MCXN547 SC Timer0 SDK driver Issue 嗨，哈里， 感谢您的快速回复。 根据您在回复中引用的手册页，如果 CONFIG[UNIFY] = 0，则在相应的计数器未运行时，可以单独读取或写入 COUNT_L 和 COUNT_H 寄存器。SDK 对 COUNT_L 寄存器使用 16 位写入。无论 CONFIG[UNIFY] 设置如何，COUNT_H 寄存器都应该使用 32 位写入进行写入 - 这是未记录的条件吗？ 谢谢 - 贾瓦哈尔

KW47-EVK板的蓝牙通道发声示例在哪里？ KW47-EVK 板及其子卡 (KW47-001-M10)的蓝牙通道发声示例在哪里？ 我在https://github.com/nxp-mcuxpresso/ 的仓库中查找过，但找不到任何针对 KW47-EVK 开发板的具体示例。我还找到了FRDM-MCXW72的通道探测示例：FRDM-MCXW72：动手实践 8：FRDM 到电话的通道探测。 我还使用了 NXP AI 的帮助功能，但它给出的链接并不存在。 我已经安装了基于 Eclipse 的 MCUXpresso，以及适用于 KW47-EVK 板和子卡 (KW47-001-M10) 的 SDK。 提前致谢！——保罗 Re: Where are Bluetooth Channel Sounding Examples for the KW47-EVK board 你好， 希望你一切都好。感谢您的联系。要访问 KW47-EVK 的通道探测示例，建议使用 MCUXpresso for VS Code 扩展以及 MCUXpresso SDK GitHub 存储库，而不是手动浏览存储库。 步骤如下： 安装适用于 VS Code 的 MCUXpresso 扩展。您可以从 VS Code 应用商店或 NXP 页面下载并安装： https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-for-visual-studio-code :MCUXPRESSO-VSC 从存储库导入 SDK 在 VS Code 中，打开 MCUXpresso 快速入门面板，点击“从存储库导入示例”，然后选择 KW47-EVK 板。该扩展程序将直接从 GitHub 存储库拉取 SDK。 使用 SDK 版本 26.06.00 (LTS) 我们建议使用 SDK 版本 26.06.00，这是当前的 LTS 版本，包含 KW47 的最新 BLE 协议栈更新，包括通道探测支持。   具体来说，我建议您查看以下文档：运行低功耗蓝牙定位场景 — MCUXpresso SDK 文档 希望这能帮到你！ 顺祝商祺！ 里卡多 Re: Where are Bluetooth Channel Sounding Examples for the KW47-EVK board 谢谢你，里卡多！这样就成功了，我可以使用 Visual Studio Code 扩展导入 mcxw72evk_loc_reader_bm。

S32K36x Bootloader Implementation Dear NXP Support Team, I am currently in the process of evaluating your microcontrollers for an application. I would specifically like to use the S32K364 microcontroller model. However, I am uncertain about how to implement a bootloader function for it. Are we supposed to simply adapt the existing "unified bootloader demo" from four years ago made for the original S32K31x/K32x/K34x MCUs if we want to flash our MCU using CAN-FD or is there a more official bootloader example project written specifically for the S32K36x series we could use directly?  Thanks in advance! Re: S32K36x Bootloader Implementation Hi @SewerynP  Please see my summary of the available S32K3 bootloader examples here: https://community.nxp.com/t5/S32K/S32K385-Bootloader/m-p/2367874/highlight/true#M58710 NXP does not provide production-ready bootloader code specifically for every S32K3 derivative. The available bootloader demos are reference software intended as a starting point for developing your own solution and can be adapted to S32K364. For a production-ready solution, you can consider third-party products such as Vector Flash Bootloader. Regards, Lukas

MCU-LINKが動作しません こんにちは、 新しいPC(Windows 10ノートPC)でMCU-LINKを使おうとしているのですが、残念ながらあまりうまくいっていません! mcuxpressoをインストールして、MCU-LINKをUSBポートに差し込むと、例の挙動のような音がしますが、mcuxpressoはプローブを認識できず、Windowsのデバイスマネージャーでは「USBコンポジットデバイス」の横に黄色い警告三角形があり、デバイスステータスに「このデバイスは起動できません(コード10)」というメッセージが表示されます。API を完了するためのシステム リソースが不足しています。 また、NXPのウェブサイトからWindows 10用のMCU-LINKドライバーインストーラーを手動でダウンロードしてみましたが、それでも成功しませんでした。 何かアドバイスをいただけますか？これは比較的新しいノートPCなので、リソース不足はないと思います。 どうもありがとうございました -ニック Re: MCU-LINK not working こんにちは、 私も全く同じ問題に直面しました。 ちょうど解けたので、役に立てればと思います。私は以下のことをしました。 C:\nxp\LinkServer_26.6.137\MCU-LINK_installer\scriptsへ移動します「program_CMSIS」をクリックし、コマンドパネルの指示に従います(つまり、MCUリンクのショートジャンパーJ3 -> USB経由でMCUリンクに接続 -スペースバーを押す>)。 (それ以外の場合は、「CMSIS」と書くか、Windowsの検索バーで「Program MCU-Link CMSIS-DAP」を検索して直接ファイルを探すこともできます。) これを実行すると、デバイスマネージャーで警告なしにデバイスが正しく認識され、ボードのデバッグも正常にできました。 関連があるのか、あるいは動作に役立ったのか(必須ではないかもしれませんが)、mcu-linkのファームウェアアップデートを行う前に、私は以下のことをしました: 1- 「Windows Security」 -> 「App & ブラウザ コントロール」 -> Smart App Control 設定 ->オフになりましたか? 2- LinkServerインストーラーを再インストールしました。nxpのウェブサイトの「LinkServer for マイクロコントローラ」で見つかります。 また、ファームウェアのアップデート後： 1- mcUspresso IDEを「管理者として実行」で開き、プロジェクトエクスプローラーでプロジェクトフォルダを開き、下部のフォルダ「(*project_name*)_ LinkServer Debug.launch」を削除しました。コードをデバッグする前に。 これは私の場合うまくいった方法です。誰かの役に立てば幸いです。 カンザス州より、よろしくお願いいたします。 Re: MCU-LINK not working こんにちは、私もMCU-Linkを使っていますが、ノートPCのポートに直接接続すると問題なく動作しています。しかしUSBハブを使って、そのUSBハブ経由でMCU -Linkを接続すると、デバグがうまくいかずエラーが出ます。どうすればこれを克服すればいいですか?ノートPCにはポートが1つしかないので、ハブ経由で使う必要があります Re: MCU-LINK not working 他に二つの代替案が思い浮かびます。 一つは、アンチウイルスがMCU-LINKを脅威として検知していないか確認し、念のため無効化することです。 2つ目は、別のコンピューターで試してみることです。もし問題が別のマシンでも続くなら、MCU-LINKに関連している可能性があると考えられます。そうでなければ、問題はOSかケーブルに関係している可能性が最も高いと思います。 これがお役に立てば幸いです。 Re: MCU-LINK not working @EdwinHz さん、ありがとうございます。 はい、その場所からドライバをダウンロードしました。 USBハブは使用していません。直接接続です。 別のUSBケーブルを試してみますが、可能性は低いようです。 他に何かご提案があれば教えてください。ありがとう！   Re: MCU-LINK not working こんにちは、 @nickwallis さん。 手動でインストールしたドライバは、MCU-Link Debug Probeのウェブサイトの下部にある「MCU-Link installer for Windows 10」ソフトウェアから来たものですか?もしそうでなければ、このインストーラーを使ってドライバを再インストールすることをお勧めします。 MCU-LINKへの接続を確認してください。USBハブに接続しているなら、直接マシンに接続してみてください。別のUSBケーブルも試してみてください。 よろしくお願いいたします。 エドウィン。

在 macOS 上，RT685 DSP 镜像使用缓存的二进制文件，而不是在 Zephyr sysbuild 中新构建的二进制文件。 平台：MacOS 15.6.1 (24G90) VS Code（版本：1.112.0）（普遍的）） MCUXpresso for VS Code： 26.8.29 Zephyr 工具链：zephyr-sdk-1.0.1，zsdk nxp-v4.4.1.1 应用程序：amp_blinky 已作为zephyr-freestanding导入 开发板：MIMXRT685-EVK 说明： 我正在MacOS上搭建开发环境，同样的步骤在我的Linux机器上运行良好。虽然使用 MCUXpresso进行构建和烧录时没有出现任何严重警告/错误，但应用程序在 Arm 和 DSP 内核上都能正常运行。然后我编辑了 remote/src 和 remote/prj.conf 下的代码，并在全新版本后将其刷入。然而，DSP 核心在编辑之前仍然运行了之前的图像。 以下是一些有趣的行为： 我也尝试修改了 Arm 核心代码，但更改已成功应用。 DSP核心代码的更改可能会触发非初始版本，而不是显示“无需工作”。 禁用 cmake 中的 CCACHE 似乎可以解决问题。 就目前来看，这似乎是一个与缓存相关的问题，编译器在运行 sysbuild 时忽略了 DSP 映像中的更改，并使用了缓存的二进制文件，无论它是否已被重新构建。这可能是由于 nxp_zephyr/zephyr/samples/boards/nxp/adsp/rtxxx/common/src/dspimgs.S 没有更新造成的。另外，这可能只是 macOS 系统的问题，因为我在 Linux 机器上没有发现这个问题。 这是已知问题吗？除了禁用 CCACHE 之外，有没有更优雅的解决方案？ 顺祝商祺！ 岳 ZEPHYR-OS-EDGE i.MX RT600 Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS 尊敬的@YueZ ， 谢谢你的提问。 目前为止，我们这边还没有发现这个问题。 为了帮助找出根本原因，请您检查以下输出是否持续更新？ 远程版本过程生成的 DSP BIN。 由 dspimgs.S 生成的对象文件 最终实际编程到设备上的 Arm BIN。 如果 DSP BIN 已更新，但从 dspimgs.S 生成的目标文件尚未更新，则一个可能的原因是构建系统没有更新 DSP BIN 时间戳。因此，依赖项检查可能跳过了重新编译 dspimgs.S。 我们建议将以下内容添加到负责 dspimgs.S 的CMake配置中，以确保 DSP BIN 中的更改触发重新构建： 设置（DSP_BIN_DIR ${CMAKE_BINARY_DIR} /../remote/zephyr） 设置属性（源） ${CMAKE_CURRENT_SOURCE_DIR} /src/dspimgs.S 属性 OBJECT_DEPENDS ${DSP_BIN_DIR} /zephyr_reset.bin ${DSP_BIN_DIR} /zephyr_text.bin ${DSP_BIN_DIR} /zephyr_data.bin ） （请同时确认文件路径是否正确。） 如有任何疑问，请与我们联系。   顺祝商祺！ 雪莉 Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS 你好，雪莉， 谢谢你的回复！ 我检查了 build/remote/zephy 下的三个 DSP BIN、最终的 Arm BIN 以及 build/amp_blinky/CMakeFiles/app.dir/.../adsp/rtxxx/common/src/ 下的 dspimgs.S.obj 的时间戳，它们都被原始构建或非原始构建更新了。 我还尝试了推荐的 CMake 配置，方法是替换 设置源文件属性（ " ${CMAKE_CURRENT_LIST_DIR} /src/dspimgs.S" 对象依赖项 ${HIFI4_BUILD_DIR} /zephyr.elf ）   （带   设置(HIFI4_BIN_DEPS) " ${HIFI4_BUILD_DIR} /zephyr.elf" " ${HIFI4_BUILD_DIR} /zephyr.reset.bin" " ${HIFI4_BUILD_DIR} /zephyr.text.bin" " ${HIFI4_BUILD_DIR} /zephyr.data.bin" ） 设置源文件属性（ " ${CMAKE_CURRENT_LIST_DIR} /src/dspimgs.S" Properties 对象依赖项 " ${HIFI4_BIN_DEPS} " ） 在 dsp-load.cmake 中，并通过以下方式验证了更改： `ninja -C build/amp_blinky -t query build/.../dspimgs.S.obj`   但遗憾的是，这个问题依然存在。然后我又做了如下测试： 在 remote/src/main.c 中添加 ` printk ( " TESTCCACHE " );` 构建 调用 `strings build/.../dspimgs.S.obj | grep TESTCCACHE` 调用 `strings build/remote/zephyr/zephyr.text.bin build/remote/zephyr/zephyr.data.bin | grep TESTCCACHE` 步骤 3 没有返回任何结果，而步骤 4 找到了字符串。然后，我禁用 CCACHE 后再次运行测试，结果在两次测试中都发现了 TESTCCACHE。看起来，当启用 CCACHE 时，dspimgs.S.obj 的时间戳已更新，但没有加载正确的二进制文件。 欢迎大家就此发表意见。 顺祝商祺！ 岳 Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS 尊敬的@YueZ ， 请尝试： CCACHE_RECACHE=1？   与 CCACHE_DISABLE 完全绕过 ccache 并执行完全重建而不读取或写入任何缓存条目不同，CCACHE_RECACHE=1 强制重新生成所有输出，并使用新构建的结果更新缓存。 如果使用 CCACHE_RECACHE=1 后问题消失，则表明根本原因可能是缓存内容过旧。如果问题仍然存在，则表明问题与 ccache 本身有关，而不是与特定的缓存条目有关。 顺祝商祺！ 雪莉   Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS 你好，雪莉， 是的， CCACHE_RECACHE=1 可以正常工作。 顺便说一下，我通过在 CMakeLists 中将 USE_CCACHE 设置为 0 来禁用 CCACHE。至于 CCACHE_DISABLE，我必须在 West 工作区的终端中显式设置才能使其生效，这对于在 VS Code 中使用 MCUXpresso 来说不太理想。CCACHE_RECACHE 也存在同样的问题，我无法通过将其添加到 CMakeLists 中来使用它。 顺祝商祺！ 岳

SC16IS740 : Need help to configure Auto-RTS SC16IS740_750_760  I'm currently writing a MicroPython library to support the SC16IS740 over SPI. I'm using a breakout for testing the SC16IS740 coupled to a MAX3237. Every basic features works (including RX & TX FiFo) and tested with physical  TX->RX Loopback (and my scope). Now, I want to test/implement the Auto-RTS feature. To check it: I placed a scope with ch1 on RX and ch2 on RTS. I flood the RX buffer and expect the RTS signal to switch High on the scope.... but it doesn't happens. Here follows the MicroPython code with value of halt_trigger & resume_trigger (in chars). Code mainly read & write register for a given channel (the 'ch' parameter). I'm missing something with the datasheet but I'm not able to identify it. Remark: the last instructions force the RTS high for checking manual activation at the scope. It then goes low and never gets activated by auto-RTS.... for sure, the RX FIFO get full. def enable_rts( self, halt_trigger, resume_trigger ): assert 4<=halt_trigger<=60, "RTS trigger must be within 4-60 range" assert 4<=resume_trigger<=60, "RTS trigger must be within 4-60 range" assert (halt_trigger%4) + (resume_trigger%4) == 0, "Trigger level are step by 4!" assert halt_trigger > resume_trigger, "halt_trigger must be greater than resume_trigger!" _halt = halt_trigger//4 _resume = resume_trigger//4 # Set LCR=0xBF to access EFR register _old_lcr = self.owner.bus_wrapper.read_reg( REG_LCR, ch=self.ch ) # store transmission config (eg: 8n1) self.owner.bus_wrapper.write_reg( REG_LCR, 0xBF, ch=self.ch ) # activate enhanced feature _efr = self.owner.bus_wrapper.read_reg(REG_EFR, ch=self.ch) _efr = _efr | 0b00010000 self.owner.bus_wrapper.write_reg(REG_EFR, _efr, ch=self.ch) print( "EFR:" , bin(self.owner.bus_wrapper.read_reg(REG_EFR, ch=self.ch)) , 'Enhanced function activation') # Close access to EFR & restore transmission config (eg:8n1) self.owner.bus_wrapper.write_reg( REG_LCR, _old_lcr, ch=self.ch ) # Enable TCR & TLR register access _mcr = self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch) _mcr = _mcr | 0b00000100 self.owner.bus_wrapper.write_reg(REG_MCR, _mcr, ch=self.ch) print( "MCR:" , bin(self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch)), 'Enable TCR & TLR register') # Set TCR trigger values _tcr = self.owner.bus_wrapper.read_reg(REG_TCR, ch=self.ch) _tcr = _tcr | (_resume<<4) _tcr = _tcr | _halt self.owner.bus_wrapper.write_reg(REG_TCR, _tcr, ch=self.ch) print( "TCR:", bin(self.owner.bus_wrapper.read_reg(REG_TCR, ch=self.ch)), "Transmission Control register (resume & halt levels)") # TLR must be cleared (to use TCR) self.owner.bus_wrapper.write_reg(REG_TLR, 0x00, ch=self.ch) print( "TLR:", bin(self.owner.bus_wrapper.read_reg(REG_TLR, ch=self.ch)), "Disable TLR values (so use TCR)") # Disable TCR & TLR register access _mcr = self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch) _mcr = _mcr & 0b11111011 self.owner.bus_wrapper.write_reg(REG_MCR, _mcr, ch=self.ch) print( "MCR:" , bin(self.owner.bus_wrapper.read_reg(REG_MCR, ch=self.ch)), 'Disable TCR & TLR register') self.owner.bus_wrapper.write_reg( REG_LCR, 0xBF, ch=self.ch ) # Enable auto RTS flow control _efr = _efr | 0b01000000 self.owner.bus_wrapper.write_reg(REG_EFR, _efr, ch=self.ch) print( "EFR:" , bin(self.owner.bus_wrapper.read_reg(REG_EFR, ch=self.ch)) , 'Enable auto RTS') # Close access to EFR & restore transmission config (eg:8n1) self.owner.bus_wrapper.write_reg( REG_LCR, _old_lcr, ch=self.ch ) # Initial State of RTS bit in Modem (MCR) _mcr = self.owner.bus_wrapper.read_reg( REG_MCR, ch=self.ch ) _mcr = _mcr | 0x02 self.owner.bus_wrapper.write_reg( REG_MCR, _mcr, ch=self.ch )   Hint and suggestions would be warmly welcome. Cheers, Dominique Re: SC16IS740 : Need help to configure Auto-RTS Hello, Based on the data sheet, I would suggest checking the following points: Please verify that EFCR[4] = 0. EFCR[4] enables the Auto RS-485 RTS control. When this bit is set, the transmitter takes control of the RTS pin, and this function has precedence over both manual RTS control and the hardware flow-control circuitry. Therefore, EFCR[4] should be cleared when using Auto-RTS hardware flow control. TLR does not define the Auto-RTS halt/resume thresholds. For Auto-RTS, the receiver FIFO trigger levels are taken from TCR, or from FCR if the TCR bits are cleared. TLR is used for the programmable transmit and receive FIFO trigger levels associated with interrupt generation. Therefore, clearing TLR should not be required for Auto-RTS operation.

RT685 DSPイメージは、MacOS上で新たに組み込まれたZephyr sysbuildの代わりにキャッシュバイナリを使用しています プラットフォーム:MacOS 15.6.1 (24G90) VS Code(バージョン:1.112.0)（ユニバーサル） MCUXpresso for VS Code: 26.8.29 Zephyr toolchain: zephyr-sdk-1.0.1, zsdk nxp-v4.4.1.1 用途: amp_blinkyをZephyr-freestandingとしてインポート 基板: MIMXRT685-EVK 説明： 私はMacOSで開発環境を設定していますが、同じ手順はLinuxマシンでも問題なく動作していました。ビルドとフラッシュは MCUXpressoで重大な警告やエラーを出さなかったが、ARMコアとDSPコアの両方でアプリケーションは正常に動作していた。その後、remote/srcとremote/prj.confのコードを編集し、クリーンビルド後にフラッシュしました。しかし、DSPコアは編集前に前の画像を実行していました。 以下に、興味深い行動例をいくつか示します。 Armコアコードの編集も試みましたが、その変更は成功裏に適用されました。 DSPコアコードの変更は「作業なし」と表示される代わりに、非純粋なビルドを引き起こすことがあります。 cmakeでCCACHEを無効にすると問題が解決するようです。 今のところ、コンパイラがsysbuildを実行する際にDSPイメージの変更を無視し、キャッシュされたバイナリを使っているというCAHCE関連の問題のように思えます。これは再構築されているにもかかわらずです。おそらくnxp_zephyr/zephyr/samples/boards/nxp/adsp/rtxxx/common/src/dspimgsが原因です。Sは更新されていません。また、Linuxマシンでは気づかなかったので、MacOSだけの問題かもしれません。 これは既知の問題ですか？CCACHEを無効にする以外の、より洗練された解決策はありますか？ よろしくお願いいたします。 ユエ ゼファー・オス・エッジ  i.MX RT600 Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS こんにちは、シェリーさん。 ご返信ありがとうございます！ build/remote/zephyの3つのDSP BINのタイムスタンプ、最終的なArm BIN、そしてdspimgsを確認しました。build/amp_blinky/CMakeFiles/app.dir/.../adsp/rtxxx/common/src/の項目S.obj、すべて純正または非純正のビルドで更新されていました。 また、推奨されている CMake 設定を置き換えて試してみました。 set_source_files_properties ( " ${CMAKE_CURRENT_LIST_DIR} /src/dspimgs.S" オブジェクトに依存する ${HIFI4_BUILD_DIR}/zephyr.elf ）   with   設定(HIFI4_BIN_DEPS) 「${HIFI4_BUILD_DIR}/zephyr.elf」 「${HIFI4_BUILD_DIR}/zephyr.reset.bin」 「${HIFI4_BUILD_DIR}/zephyr.text.bin」 「${HIFI4_BUILD_DIR}/zephyr.data.bin」 ） set_source_files_properties ( " ${CMAKE_CURRENT_LIST_DIR} /src/dspimgs.S" プロパティ オブジェクトに依存する " ${HIFI4_BIN_DEPS} " ） dsp-load.cmakeでは、そして変更を検証しました `ninja -C build/amp_blinky -t query build/.../dspimgs.S.obj`   しかし残念ながら、この問題は依然として解決していません。次に、以下のように別のテストを行いました。 remote/src/main.c に` printk ( " TESTCCACHE " );` を追加する ビルド `strings build/.../dspimgs.S.obj | grep TESTCCACHE` を実行します。 呼び出し:'strings build/remote/zephyr/zephyr.text.bin build/remote/zephyr/zephyr.data.bin |grep TESTCCACHE' ステップ3では何も返されなかったが、ステップ4では文字列が見つかった。次に、CCACHEを無効にして再度テストを実行したところ、どちらのテストでもTESTCCACHEが検出されました。CCACHEが有効になっている場合、dspimgs.S.objのタイムスタンプは正しいバイナリをロードせずに更新されたようです。 この件について、ご意見をいただければ幸いです。 よろしくお願いいたします。 ユエ Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS @YueZ様、 ご質問ありがとうございます。 今のところ、私たちの側ではこの問題が既知のものではありません。 根本原因を特定するために、以下の出力が一貫して更新されているか確認していただけますか? リモートビルドプロセスによって生成されるDSP BINです。 dspimgs.S から生成されたオブジェクトファイル。 実際にデバイスにプログラムされている最後のArm BINです。 DSP BINは更新されているが、オブジェクトファイルはdspimgsから生成されていない場合Sは更新していないため、ビルドシステムがDSP BINのタイムスタンプを更新しなかった可能性があります。その結果、依存関係チェックでdspimgs.Sの再コンパイルがスキップされた可能性があります。 DSPIMGsを担当する CMake 構成に以下のコンテンツを追加することをお勧めします。DSP BINの変更が再構築を引き起こすようにするために: セット(DSP_BIN_DIR ${CMAKE_BINARY_DIR}/../リモート/ゼファー) set_properte(ソース ${CMAKE_CURRENT_SOURCE_DIR} /src/dspimgs.S プロパティ オブジェクト_依存 ${DSP_BIN_DIR} /zephyr_reset.bin ${DSP_BIN_DIR} /zephyr_text.bin ${DSP_BIN_DIR} /zephyr_data.bin ） （実際のファイルパスが正しいかどうかも確認してください。） ご質問がありましたら、お気軽にお問い合わせください。   よろしくお願いいたします。 シェリー Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS こんにちは、シェリーさん。 はい、 CCACHE_RECACHE=1は機能します。 ちなみに、CMakeListsでUSE_CCACHEを0に設定してCCACHEを無効にしています。CCACHE_DISABLEについては、動作させるにはwest workspace端末で明示的に設定しなければならず、MCUXpresso for VS Codeを使うにはあまり理想的ではありません。CCACHE_RECACHEも同じで、CMakeListsに追加しても使えません。 よろしくお願いいたします。 ユエ Re: RT685 DSP image uses cached binary instead of newly built in Zephyr sysbuild on MacOS @YueZ様、 CCACHE_RECACHE=1を試してみていただけますか?   ccache を完全にバイパスし、キャッシュエントリの読み書きを行わずに完全な再構築を実行する CCACHE_DISABLE とは異なり、CCACHE_RECACHE=1 はすべての出力の再生成を強制し、新しく構築された結果でキャッシュを更新します。 CCACHE_RECACHE=1 にすることで問題が解消される場合、根本原因はおそらく古いキャッシュの内容にあると考えられます。問題が解決しない場合は、特定のキャッシュされたエントリではなく、ccache自体に問題がある可能性が高いと考えられます。 よろしくお願いいたします。 シェリー  

PXP screen rotation issue based on i.MXRT1052 I'm using rt1052PXP to rotate a landscape view to a portrait view, but the overall display shifts downwards when I refresh the page. Why is this happening?   static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { lv_area_t dest_area = { .x1 = 0, .x2 = 480 - 1, .y1 = 0, .y2 = 800 - 1, }; lv_gpu_nxp_pxp_blit(((lv_color_t *)s_inactiveFrameBuffer), area, 800, color_p, area,480, LV_OPA_COVER, LV_DISP_ROT_270); DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)s_inactiveFrameBuffer); s_framePending = true;if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } }   i.MXRT 105x 回复： 基于i.MXRT1052的pxp屏幕旋转问题 I've noticed an offset issue when drawing with PXP. Is it because the default initialization `#define LV_USE_GPU_NXP_PXP_AUTO_INIT 1` generated by guiguider can't be used directly? void lv_disp_drv_init(lv_disp_drv_t * driver) { lv_memset_00(driver, sizeof(lv_disp_drv_t)); driver->hor_res = 320; driver->ver_res = 240; driver->physical_hor_res = -1; driver->physical_ver_res = -1; driver->offset_x = 0; driver->offset_y = 0; driver->antialiasing = LV_COLOR_DEPTH > 8 ? 1 : 0; driver->screen_transp = 0; driver->dpi = LV_DPI_DEF; driver->color_chroma_key = LV_COLOR_CHROMA_KEY; #if LV_USE_GPU_NXP_PXP // driver->draw_ctx_init = lv_draw_pxp_ctx_init; // driver->draw_ctx_deinit = lv_draw_pxp_ctx_deinit; // driver->draw_ctx_size = sizeof(lv_draw_pxp_ctx_t); driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); #else driver->draw_ctx_init = lv_draw_sw_init_ctx; driver->draw_ctx_deinit = lv_draw_sw_init_ctx; driver->draw_ctx_size = sizeof(lv_draw_sw_ctx_t); #endif } 回复： 基于i.MXRT1052的pxp屏幕旋转问题 Hi  @dsd, The LV_USE_GPU_NXP_PXP_AUTO_INIT allows LVGL to leverage the user of PXP for internal widget rendering, which could definitely cause issues when the application also uses this PXP in parallel for whole screen rotation. However, it is likely not the source of the issue. From the initial code, it seems like you are not using dest_area, or rather you are using area as both source and destination for the PXP blit, which means that only the partial dirty region might be getting placed on different absolute positions rather than the intended. 回复： 基于i.MXRT1052的pxp屏幕旋转问题 I used the code generated by guiguider to test it, even without using pxp rotation. static void DEMO_FlushDisplay(lv_disp_drv_t *disp_drv, const lv_area_t *area, lv_color_t *color_p) { DCACHE_CleanInvalidateByRange((uint32_t)color_p, DEMO_FB_SIZE); ELCDIF_SetNextBufferAddr(LCDIF, (uint32_t)color_p); s_framePending = true; if (xSemaphoreTake(s_frameSema, portMAX_DELAY) == pdTRUE) { /* IMPORTANT!!! * Inform the graphics library that you are ready with the flushing*/ lv_disp_flush_ready(disp_drv); } else { PRINTF("Display flush failed\r\n"); assert(0); } } Simply modify the macro /*Use NXP's PXP GPU iMX RTxxx platforms*/ #define LV_USE_GPU_NXP_PXP 1 #if LV_USE_GPU_NXP_PXP /*1: Add default bare metal and FreeRTOS interrupt handling routines for PXP (lv_gpu_nxp_pxp_osa.c) * and call lv_gpu_nxp_pxp_init() automatically during lv_init(). Note that symbol SDK_OS_FREE_RTOS * has to be defined in order to use FreeRTOS OSA, otherwise bare-metal implementation is selected. *0: lv_gpu_nxp_pxp_init() has to be called manually before lv_init() / #define LV_USE_GPU_NXP_PXP_AUTO_INIT 1 #endif /* LV_USE_GPU_NXP_PXP */ The same problem will occur, and the direction of the offset will be the same as after rotation. 回复： 基于i.MXRT1052的pxp屏幕旋转问题 What's even stranger is that there are two different results within the same project, even though I thought the configuration should be the same. No display offset occurred Display offset occurs    

i.MX RT1064 定制板 – SGTL5000 编解码器通过 I2C 无响应 您好， 我设计了一款采用MIMXRT1064处理器和SGTL5000音频编解码器的定制 PCB。 对于 SGTL5000 电路，我遵循了标准/参考 SGTL5000 原理图。 RT1064 和 SGTL5000 之间的连接方式如下： LPI2C1_SCL → GPIO_AD_B1_00 LPI2C1_SDA → GPIO_AD_B1_01 SAI1_MCLK → GPIO_AD_B1_09 SAI1_RXD → GPIO_AD_B1_12 SAI1_TXD → GPIO_AD_B1_13 SAI1_RX_BCLK → GPIO_AD_B1_11 SAI1_RX_LRCLK → GPIO_AD_B1_10 我也附上了原理图的相关部分。 我的主要问题是，在刷写固件后，我没有收到来自 SGTL5000 的任何 I2C ACK 。 我测量了以下电压： SCL ≈ 3.3 V SDA ≈ 3.3 V MCLK 约为1.6 V 为了进行调试，我编写了一个函数，该函数暂时将 I2C 引脚更改为 GPIO，生成 9 个时钟脉冲，执行位操作 I2C 地址扫描，然后将引脚恢复为 LPI2C1。 static void i2c_hw_debug(void) { gpio_pin_config_t 输入 = { kGPIO_数字输入， 0， kGPIO_NoIntmode }; IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_00_GPIO1_IO16, 0U); IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_01_GPIO1_IO17, 0U); IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B1_00_GPIO1_IO16， 0x00B0U); IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B1_01_GPIO1_IO17， 0x00B0U); gpio_pin_config_t out_init = { kGPIO_数字输出， 1、 kGPIO_NoIntmode }; GPIO_PinInit(GPIO1, 16, &out_init); GPIO_PinInit(GPIO1, 17, &in); for (int i = 0; i < 9; i++) { GPIO_PinWrite(GPIO1, 16, 0U); SDK_DelayAtLeastUs(10U, SystemCoreClock); GPIO_PinWrite(GPIO1, 16, 1U); SDK_DelayAtLeastUs(10U, SystemCoreClock); } PRINTF("正在扫描 I2C 地址...\r\n"); for (uint8_t addr = 0x03; addr <= 0x77; addr++) { 如果 (bb_probe(16, 17, addr)) { PRINTF("在 0x%02X 处找到 ACK\r\n", addr); } } IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_00_LPI2C1_SCL， 1U）； IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_01_LPI2C1_SDA， 1U）； } 如何使用 MIMXRT1064 初始化 SGTL5000 编解码器？为什么即使所有硬件连接和配置看起来都正确，我也没有收到来自编解码器的 ACK？ 谢谢。 Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C 嗨@Anushka_SS ， 我建议您以evkmimxrt1064_sai示例代码为基础来开发您的应用程序。该代码示例展示了 RT1064 和 WM8960 编解码器的集成。也就是说，我们也提供了fsl_sgtl5000.c/.h驱动程序文件，可以将其作为元器件导入到项目中，只需取消定义CODEC_WM8960_ENABLE并改为定义CODEC_SGTL5000_ENABLE即可启用该驱动程序。SGTL5000 驱动程序文件包含正确初始化和使用此编解码器所需的例程。 如果这有帮助，或者您还需要任何进一步的帮助，请告诉我。 BR， 埃德温。 Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C 谢谢。我已经完成了这项工作：使用 SDK 的 fsl_sgtl5000 驱动程序和 CODEC_SGTL5000_ENABLE 创建了一个新项目。问题发生在驱动程序初始化之前：SGTL5000 NAK 其地址（0x0A 和 0x2A，LPI2C 状态 902）。运行时验证：音频 PLL = 786.432 MHz，SAI1 MCLK = 12.288 MHz（从 CCM 寄存器读取），LPI2C 时钟 = 10 MHz。我使用 GPIO_AD_B1_00/01 作为 LPI2C1，使用 GPIO_AD_B1_09 作为 MCLK。SGTL5000 模块通过跳线连接到我的定制 RT1064 板。您能否建议一下硬件方面还有哪些需要检查的地方（焊盘设置、MCLK 信号完整性、RT1064 特有的问题等等）？ Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C 我的定制板上同时安装了RT1064和SGTL5000编解码器。我分别测试了每个芯片：用 Teensy 4.1 测试了 SGTL5000，用外部 PJRC SGTL5000 音频扩展板测试了 RT1064。这两个芯片单独使用都没问题，但是当我把它们的引脚焊接在一起时，就无法正常工作，并出现以下输出： === SGTL5000 启动测试 === I2C扫描（Teensy风格）…… 扫描完成：0 个设备 音频锁相环 = 786432000 Hz SAI1 mux=2 prediv=3 div=15 -> MCLK = 12288000 Hz (预期 12288000) LPI2C 时钟频率 = 10000000 Hz（预期值为 10000000） -- 尝试 1 -- CHIP_ID @0x A: status=902 id=0x 0 0 CHIP_ID @0x2A：状态=902 id=0x 0 0 -- 尝试 2 -- CHIP_ID @0x A: status=902 id=0x 0 0 CHIP_ID @0x2A：状态=902 id=0x 0 0 -- 尝试 3 -- CHIP_ID @0x A: status=902 id=0x 0 0 CHIP_ID @0x2A：状态=902 id=0x 0 0 SGTL5000 无应答。停止。 我测量的电压值是： SCL：3.2V SDA：3.2 伏 MCLK：1.5–1.6V

MCU-LINK 无法正常工作 您好， 我尝试在新电脑（Windows 10 笔记本电脑）上使用 MCU-LINK，但很遗憾，并没有取得太大成功！ 我安装了 mcuxpresso，当我将 MCU-LINK 插入 USB 端口时，它会发出像枚举一样的正常声音，但 mcuxpresso 无法识别探针，并且在 Windows 设备管理器中，“USB 复合设备”旁边出现了一个黄色警告三角形，设备状态中显示一条消息，提示“此设备无法启动（代码 10）”。系统资源不足，无法完成 API 请求。 我还尝试从 NXP 网站手动下载适用于 Windows 10 的 MCU-LINK 驱动程序安装程序，但仍然没有成功。 请问有什么建议吗？这是一台比较新的笔记本电脑，我预计它的资源不会不足。 非常感谢 -缺口 Re: MCU-LINK not working 你好， 我发现自己也遇到了完全相同的问题。 我刚刚成功解决了这个问题，希望对大家有所帮助。我做了以下事情： 正在前往C:\nxp\LinkServer_26.6.137\MCU-LINK_installer\scripts点击“ program_CMSIS ”，然后按照命令面板上的说明进行操作（即，短接 MCU-link 的跳线 J3 -> 通过 USB 连接 MCU-link -> 按空格键）。 （或者，您也可以尝试在 Windows 搜索栏中输入“CMSIS”或搜索“Program MCU-Link CMSIS-DAP”来直接找到该文件）。 完成上述操作后，计算机的设备管理器能够正确识别该设备，且没有出现任何警告，我得以成功调试我的板。 不确定是否相关，或者是否有助于正常工作（也许并非必需），但在对 MCU-Link 进行固件更新之前，我做了以下操作： 1- 已将“Windows 安全中心”->“应用和浏览器控制”->“智能应用控制设置”->关闭。 2- 我重新安装了 LinkServer 安装程序，您可以在 nxp 网站上的“LinkServer for Microcontrollers”中找到它。 此外，在进行固件更新后： 1- 以“管理员身份运行”打开 mcuxpresso IDE，然后在项目资源管理器中，打开项目文件夹，并在底部删除文件夹“(*项目名称*)_LinkServer Debug.launch”；在调试代码之前。 对我来说，这种方法很有效。希望对其他人也有帮助。 祝好，堪萨斯。 Re: MCU-LINK not working 您好，我也在使用 MCU-Link，它直接连接到笔记本电脑的 USB 端口时工作正常。但是，当我使用 USB 集线器并通过集线器连接 MCU-Link 时，调试就无法工作，并会报错。请问如何解决这个问题？我的笔记本电脑只有一个 USB 端口，所以必须通过集线器连接。 Re: MCU-LINK not working 我还能想到另外两种替代方案： 首先要确保您的防病毒软件没有将 MCU-LINK 检测为威胁，为了安全起见，最好将其禁用。 第二种方法是换一台电脑试试。如果换一台机器也出现同样的问题，那么我们有理由相信问题可能与 MCU-LINK 有关。否则，我认为问题很可能与操作系统或数据线有关。 希望这能帮到你。 Re: MCU-LINK not working 谢谢@EdwinHz 是的，我们从那个位置下载了驱动程序。 我们没有使用 USB 集线器，这是直接连接。 我会试试换根USB线，但这似乎不太可能。 还有其他建议吗？谢谢！   Re: MCU-LINK not working 嗨@nickwallis ， 您手动安装的驱动程序是否来自 MCU-Link Debug Probe 网站底部的“MCU-Link Windows 10 安装程序”软件？如果不行，我建议使用此安装程序重新安装驱动程序。 检查与MCU-LINK的连接。如果它连接到了 USB 集线器，请尝试将其直接连接到机器。也可以尝试使用不同的USB数据线。 此致， 埃德温。

マーキング仕様書の依頼 - PN# MFS2633HMDA0AD 拝啓 部品番号MFS2633HMDA0ADを受け取りました。入荷部品の検証に必要なチップマーキング情報を取得できません。この部品のマーキング仕様書の提供を手伝ってもらえますか? 皆様のご支援をいただけると大変ありがたいです。 よろしくお願いいたします。 ジョーイ

imx8qxp H265 sample video play I am trying to play the h265 video file and it is not playing.  IMX8QXP - Scarthgap  - L 6.6.52 Can you please check and provide the right command or packages/lib to play h265 video sample files, gst-launch-1.0 -v filesrc location=/root/sample.h265 ! h265parse ! v4l2h265dec ! imxvideoconvert_g2d ! fpsdisplaysink video-sink=waylandsink text-overlay=false sync=false & i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Re: imx8qxp H265 sample video play Hi, Please find the update, root@imx8qxpc0mek:~# root@imx8qxpc0mek:~# gst-launch-1.0 -v filesrc location=/navigation/aa_video_dump.h265 ! h265parse ! v4l2h265dec ! imxvideoconvert_g2d ! fpsdisplaysink video-sink=waylandsink text-overlay=false sync=false Setting pipeline to PAUSED ... ====== V4L2DEC: 1.24.7 build on Oct 23 2024 09:43:13. ====== Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstWaylandSink:waylandsink0: sync = false Redistribute latency... /GstPipeline:pipeline0/GstH265Parse:h265parse0.GstPad:src: caps = video/x-h265, width=(int)1280, height=(int)720, framerate=(fraction)30/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)au, pixel-aspect-ratio=(fraction)1/1, profile=(string)main, tier=(string)high, level=(string)4 /GstPipeline:pipeline0/v4l2h265dec:v4l2h265dec0.GstPad:sink: caps = video/x-h265, width=(int)1280, height=(int)720, framerate=(fraction)30/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)au, pixel-aspect-ratio=(fraction)1/1, profile=(string)main, tier=(string)high, level=(string)4 /GstPipeline:pipeline0/v4l2h265dec:v4l2h265dec0.GstPad:src: caps = video/x-raw, format=(string)NV12_8L128, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, framerate=(fraction)30/1 /GstPipeline:pipeline0/imxvideoconvert_g2d:imxvideoconvert_g2d0.GstPad:src: caps = video/x-raw, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, format=(string)YUY2 /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = video/x-raw, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, format=(string)YUY2 /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstWaylandSink:waylandsink0.GstPad:sink: caps = video/x-raw, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, format=(string)YUY2 /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0.GstGhostPad:sink: caps = video/x-raw, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, format=(string)YUY2 /GstPipeline:pipeline0/imxvideoconvert_g2d:imxvideoconvert_g2d0.GstPad:sink: caps = video/x-raw, format=(string)NV12_8L128, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, framerate=(fraction)30/1 Redistribute latency... root@imx8qxpc0mek:~# gst-inspect-1.0 | grep -i h265 codectimestamper: h265timestamper: H.265 timestamper rtp: rtph265depay: RTP H265 depayloader rtp: rtph265pay: RTP H265 payloader typefindfunctions: video/x-h265: h265, x265, 265 video4linux2: v4l2h265dec: V4L2 H265 Decoder videoparsersbad: h265parse: H.265 parser root@imx8qxpc0mek:~# root@imx8qxpc0mek:~# root@imx8qxpc0mek:~# gst-inspect-1.0 | grep -i v4l2 video4linux2: v4l2deviceprovider (GstDeviceProviderFactory) video4linux2: v4l2h263dec: V4L2 H263 Decoder video4linux2: v4l2h264dec: V4L2 H264 Decoder video4linux2: v4l2h264enc: V4L2 H.264 Encoder video4linux2: v4l2h265dec: V4L2 H265 Decoder video4linux2: v4l2mpeg2dec: V4L2 MPEG2 Decoder video4linux2: v4l2mpeg4dec: V4L2 MPEG4 Decoder video4linux2: v4l2radio: Radio (video4linux2) Tuner video4linux2: v4l2sink: Video (video4linux2) Sink video4linux2: v4l2spkdec: V4L2 SPK Decoder video4linux2: v4l2src: Video (video4linux2) Source video4linux2: v4l2vc1dec: V4L2 VC1 Decoder video4linux2: v4l2vp8dec: V4L2 VP8 Decoder video4linux2: v4l2xviddec: V4L2 XVID Decoder root@imx8qxpc0mek:~# root@imx8qxpc0mek:~# Re: imx8qxp H265 sample video play Hello,  Since you are using Scarthgap (6.6.52), the issues could be: v4l2h265dec not present in the image. The H.265 file is not a raw elementary stream. VPU firmware/driver not loaded. The BSP uses a different decoder element than the one specified in the pipeline. Please provide the output of: Shell gst-inspect-1.0 | grep -i h265 gst-inspect-1.0 | grep -i v4l2 `` and the exact error message from gst-launch-1.0 to try to identify if one of these four cases is occurring. Re: imx8qxp H265 sample video play Hello,  The log shows that H.265 decoding and GStreamer negotiation are working: h265parse detected a valid 1280×720 H.265 Main stream. v4l2h265dec produced decoded NV12_8L128 frames. imxvideoconvert_g2d converted them to YUY2. waylandsink accepted the caps. This is not a missing H.265 package issue. Try the following command and allow it to run without & so errors and pipeline state remain visible in the terminal: gst-launch-1.0  -v filesrc location=/root/sample.h265 ! h265parse ! \ v4l2h265dec ! imxvideoconvert_g2d ! waylandsink sync=false

imx6ull->ADC 您好， 我正在使用基于 i.MX6ULL 的自定义 SOM 模块。根据我们的需求，我们使用i.MX 处理器配置工具来配置引脚。在配置工具中，我选择了“创建独立组网 \\(SA\\) 项目”，然后选择了i.MX 6ULL → (6Y2...05)。 我们的要求是使用配置工具配置引脚，获取生成的.dtsi 文件，并使用同一个文件来版本镜像。然而，这种方法一开始并不奏效。 对于UART ，我了解到我们需要添加相应的设备节点并将其状态设置为正常。同样，生成的 .dtsi 文件也需要进行一些小的修改。文件。 我已附上 .dtsi 文件。由配置工具生成的文件。请看一下。在该文件中，当我注释掉 imx6ull-board 行后，配置就开始正常工作了。 完成 UART 配置后，我开始进行ADC配置。当我在配置工具中检查 ADC 配置时，我注意到ADC似乎使用了同一个GPIO引脚。但是，我发现当我将一个 GPIO 引脚配置为 GPIO，将另一个 GPIO 引脚配置为 ADC 时，生成的 IOMUX 配置看起来是一样的。为什么会这样？这是预期行为吗？ 请问您能否帮我了解一下在我们的i.MX6ULL 定制 SOM上配置和测试 ADC 的正确方法？ 此外，我们最初的要求是使用配置工具配置引脚，获取生成的配置文件，并直接使用该配置文件来构建和烧录镜像。我想确认一下，这种方法是否适用于我们的定制板，或者是否需要在生成的 .dtsi 文件中进行其他修改。文件。 我已附上 .dts 和 .dtsi 文件。该文件由配置工具生成，供您参考。 这句话到底是什么意思？ Re: imx6ull->ADC 你好@Et_MM 这似乎是 i.MX6ULL 配置工具的一个 bug。 请明确您希望哪个GPIO用作ADC，以及哪个GPIO用于其他功能。 我可以帮助你生成正确的 &adc1 节点和正确的引脚复用。 顺祝商祺！ 萨拉斯。 Re: imx6ull->ADC 你好@Et_MM 希望你一切都好。 是的，目前只有ADC1可用。 请根据您的使用场景，将以下内容添加到您的设备树中： &adc1 { num-channels = <10>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_adc1>; status = "okay"; }; &iomuxc { pinctrl_adc1: adc1grp { fsl,pins = < MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x3000 MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0x3000 >; }; }; 这将仅使用 GPIO1_IO03 和 GPIO1_IO04 作为 ADC 通道。 root@imx6ul7d:/sys/bus/iio/devices/iio:device1# cat in_voltage3_raw 75 root@imx6ul7d:/sys/bus/iio/devices/iio:device1# cat in_voltage4_raw 0 root@imx6ul7d:/sys/bus/iio/devices/iio:device1# cat name 2198000.adc 顺祝商祺！ 萨拉斯。 Re: imx6ull->ADC 我希望将GPIO01_IO01、GPIO01_IO02用作GPIO本身，将GPIO01_IO03、GPIO01_IO04用作ADC 。 当我搜索 dtsi 文件时，发现我们只有一个 adc，即 adc1。adc2 不可用。如果我说错了，请指正。 另外，请指导我如何测试和验证我们配置的ADC和GPIO引脚是否正常工作。我该如何测试呢？ 我已经分享了我们正在使用的dts和dtsi文件。希望你已经看到了。其中提到的ADC配置是否有误？

MCXN547 SC Timer0 SDKドライバーの問題 私はMCUとSDK MCXN547VKLバージョン26.06.00を使っています。 コンテキスト: 私は SCT タイマー 0 を使用して、スプリット モードの COUNTER を使用して 2 つの異なる PWM 波形を生成しています。CONFIG[UNIFY] = 0、つまり COUNT_L を 1 つの PWM ジェネレーターに、COUNT_H を別の PWM ジェネレーターに使用しています。 問題はこうです:ドライバーAPI「SCTIMER_SetCOUNTValue(SCT0,kSCTIMER_Counter_H,0U)」でCOUNTER_Hを読み込むと、バスフォールトが発生します。 問題の原因をSDKのドライバーコードに突き止めました。ドライバコードはCOUNT_H単独で16ビットの書き込みではなく、COUNT_HとCOUNT_Lの両方を32ビット書き込みで行います。COUNT_H が書き込まれている間に COUNT_L が実行されていたため、バス障害が発生しました。SDKのドライバーコードを16ビット書き込みに変更したところ、バスの故障は発生しませんでした。ドライバーコードを添付し、問題の原因となったコードラインと修正方法を色で示しました。もし本当にこれが問題なら、SDKドライバーを更新できます。- ありがとう /*! * @brief カウンターの値を設定します。 * * この機能は、カウントレジスタの値を設定することであり、COUNT_L、COUNT_H、または統合レジスタに書き込みます。 * は、対応するカウンタが停止しているとき（CTRL レジスタの HALT ビットが 1 に設定されているとき）にのみ許可されます。 * * @param base SCTimer ペリフェラル ベースアドレス * @param whichCounter SCTimer カウンターを使います。16ビットモードでは、Counter_LとCounter_Hを選択できます。 * 32ビットモードではCounter_Uを選択できます。 * @Param value COUNTレジスタへのカウンタ値の更新。 */ static inline void SCTIMER_SetCOUNTValue ( SCT_Type *base, sctimer_counter_t whichCounter, uint32_t value) { SCTIMER_StopTimer(base, ( uint32_t )whichCounter); スイッチ (whichCounter) { case kSCTIMER_Counter_L: assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* ユーザーがLowカウンターを設定したいときにビットCounter_Lを使います */ base-> COUNT_ACCESS16BIT.COUNTL = ( uint16_t ) value; 壊す; case kSCTIMER_Counter_H: assert(value <= 0xFFFFU); assert(0U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* ユーザーがHighカウンターを設定したいときにCounter_Hビットを使う */ // base->COUNT = (uint32_t)base->COUNT_ACCESS16BIT.COUNTL | SCT_COUNT_CTR_H(value); base- > COUNT_ACCESS16BIT.COUNTH = ( uint16_t )value; //修正 壊す; CASE kSCTIMER_Counter_U: assert(1U == (base-> CONFIG & SCT_CONFIG_UNIFY_MASK)); /* カウンタが 32 ビットモードで動作している場合 (カウンタを統合する場合) は、Counter_L ビットと Counter_H ビットの両方を使用します。*/ base-> COUNT = value; 壊す; デフォルト： /* MISRA C-2012 問題ルール 16.4 を修正します。*/ 壊す; } SCTIMER_StartTimer(base, ( uint32_t )whichCounter); } クロック|タイマー Re: MCXN547 SC Timer0 SDK driver Issue こんにちは、 @JawaharA さん。 ご意見ありがとうございます。バス障害の原因に関するあなたの分析は正しいです。COUNT_H の更新には COUNT レジスタへの 32 ビット書き込みが使用されますが、現在の関数は H カウンタのみを停止します。Lカウンタがまだ動作している場合、この書き込みアクセスはSCTバスエラーを引き起こします。 しかし、COUNTHへの16ビット書き込みへのアクセス変更はSCTハードウェアアクセス要件に適合しません。なぜなら、COUNT_HはCOUNT_L と一緒にワードとして書かなければならないからです。正しいソフトウェアの解決策は、32ビットのCOUNTへの書き込みを行う前にLとHの両方のカウンターを停止し、その後に以前の実行状態を復元することです。別途16ビットの書き込みを使わずにSDKをレビューし、適切に更新することを推奨COUNT_H。 BR ハリー Re: MCXN547 SC Timer0 SDK driver Issue こんにちは、ハリーさん。 迅速なご対応ありがとうございます。 ご回答で参照されたマニュアルページによると、CONFIG[UNIFY] = 0の場合、COUNT_LレジスタとCOUNT_Hレジスタの両方をそれぞれカウンタが動作していない間に個別に読み書きできます。SDKはレジスタに16ビット書き込みCOUNT_L使っています。COUNT_HレジスタはCONFIG[UNIFY]の設定に関係なく32ビット書き込みで書き込む必要がありますが、これは非公式な条件でしょうか？ ありがとう - ジャワハル

i.MX RT1064カスタムボード – SGTL5000コーデックがI2Cで応答しない こんにちは、 MIMXRT1064プロセッサとSGTL5000オーディオコーデックを使ってカスタムPCBを設計しました。 SGTL5000回路については、標準/リファレンスSGTL5000回路図に従いました。 RT1064とSGTL5000間の接続は以下の通りです。 LPI2C1_SCL → GPIO_AD_B1_00 LPI2C1_SDA → GPIO_AD_B1_01 SAI1_MCLK → GPIO_AD_B1_09 SAI1_RXD → GPIO_AD_B1_12 SAI1_TXD → GPIO_AD_B1_13 SAI1_RX_BCLK → GPIO_AD_B1_11 SAI1_RX_LRCLK → GPIO_AD_B1_10 回路図の関連部分も添付しました。 私の主な問題は、ファームウェアをフラッシュした後、 SGTL5000からI2C ACKを受信しないことです。 私は以下の電圧を測定しました。 SCL = 約3.3V SDA = 約3.3V MCLK = 約1.6V デバッグのために、I2Cピンを一時的にGPIOに変更し、9つのクロックパルスを生成し、ビットバンギングによるI2Cアドレススキャンを実行し、その後ピンをLPI2C1に戻す関数を作成しました。 static void i2c_hw_debug(void) ヤージュ gpio_pin_config_t in = ヤージュ kGPIO_デジタル入力、 0、 kGPIO_NoIntmode }; IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_00_GPIO1_IO16, 0U); IOMUXC_SetPinMux(IOMUXC_GPIO_AD_B1_01_GPIO1_IO17, 0U); IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B1_00_GPIO1_IO16、 0x00B0U); IOMUXC_SetPinConfig( IOMUXC_GPIO_AD_B1_01_GPIO1_IO17、 0x00B0U); gpio_pin_config_t out_init = ヤージュ kGPIO_デジタル出力、 1、 kGPIO_NoIntmode }; GPIO_PinInit(GPIO1, 16, &out_init); GPIO_PinInit(GPIO1, 17, &in); for (int i = 0; i < 9; i++) ヤージュ GPIO_PinWrite(GPIO1, 16, 0U); SDK_DelayAtLeastUs(10U, SystemCoreClock); GPIO_PinWrite(GPIO1, 16, 1U); SDK_DelayAtLeastUs(10U, SystemCoreClock); } PRINTF("I2Cアドレスをスキャンしています...\r\n"); for (uint8_t addr = 0x03; addr <= 0x77; addr++) ヤージュ if (bb_probe(16, 17, addr)) ヤージュ PRINTF("ACKが0x%02Xで見つかりました\r\n", addr); } } IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_00_LPI2C1_SCL、 1U); IOMUXC_SetPinMux( IOMUXC_GPIO_AD_B1_01_LPI2C1_SDA、 1U); } MIMXRT1064でSGTL5000コーデックを初期化するにはどうすればよいのでしょうか?また、ハードウェアの接続や設定がすべて正しいのに、なぜコーデックからACKが来ないのでしょうか? ありがとうございます。 Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C こんにちは、 @Anushka_SS さん、 むしろ evkmimxrt1064_sai例コードをベースにアプリケーションを作成することをお勧めします。このコードはRT1064とWM8960コーデックの統合を体現しています。とはいえ、 fsl_sgtl5000.c/.h ドライバーファイルも提供しており、プロジェクトにコンポーネントとしてインポートでき、 CODEC_WM8960_ENABLE をアン定義してCODEC_SGTL5000_ENABLE を定義することで使用可能なコーデックを単に変更するだけで有効になります。SGTL5000ドライバファイルには、このコーデックを正しく初期化し使用するための必要なルーチンが含まれています。 これがお役に立てば幸いです。また、他に何かご不明な点がありましたらお知らせください。 BR、 エドウィン。 Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C ありがとう。すでにこれをやっています:SDKsのfsl_sgtl5000ドライバを使った新しいプロジェクトをCODEC_SGTL5000_ENABLE。問題はドライバが初期化する前に発生します:SGTL5000 NAKはアドレス(0x0Aおよび0x2A、LPI2Cステータス902)を割り当てます。実行時に検証された結果:オーディオ PLL = 786.432 MHz、SAI1 MCLK = 12.288 MHz(CCMレジスタから読み戻し)、LPI2Cクロック = 10 MHz。私はLPI2C1にGPIO_AD_B1_00/01を、MCLKにGPIO_AD_B1_09を使用しています。SGTL5000モジュールはジャンパーワイヤーでカスタムRT1064ボードに接続しています。ハードウェア面で他にチェックすべきこと(パッド設定、MCLK信号強度、RT1064特有の点など)を教えてもらえますか? Re: i.MX RT1064 Custom Board – SGTL5000 Codec Not Responding Over I2C カスタムボードにはRT1064とSGTL5000コーデックの両方を入れています。各チップを個別にテストしました。SGTL5000はTeensy 4.1搭載、RT1064は外部PJRC SGTL5000オーディオシールド搭載です。どちらも単体では問題なく動作しますが、ピンをはんだ付けして接続すると動作せず、次のような出力が出ます: === SGTL5000 育て上げテスト === I2Cスキャン(Teensyスタイル)... スキャン完了:0台のデバイス オーディオPLL = 786432000 Hz SAI1 mux=2 prediv=3 div=15 -> MCLK = 12288000 Hz(12288000 を期待) LPI2Cクロック=10000000Hz(100000000を期待) ――やってみて1―― CHIP_ID @0x A: status=902 id=0x 0 0 CHIP_ID @0x2A: status=902 id=0x 0 0 -- 2を試して-- CHIP_ID @0x A: status=902 id=0x 0 0 CHIP_ID @0x2A: status=902 id=0x 0 0 -- 3回試して -- CHIP_ID @0x A: status=902 id=0x 0 0 CHIP_ID @0x2A: status=902 id=0x 0 0 SGTL5000出ない。停止。 私が測定している電圧は以下のとおりです。 SCL: 3.2V SDA: 3.2V MCLK: 1.5～1.6V

标记规范请求 - PN# MFS2633HMDA0AD 尊敬的先生/女士， 我们已收到零件号为MFS2633HMDA0AD的零件。我们无法获取进货零件验证所需的芯片标记信息。请问您能否提供该零件的标记规范文件？ 非常感谢您的支持。 顺祝商祺！ 乔伊

FRDM-A-S32K144Nのフラッシュプログラミングについて FRDM-A-S32K144Nを使用してデバッグを行っていた際に、以下の症状が発生しました。 フラッシュメモリへの書き込みができません。 書き込みエラー発生以降、電源LEDとリセットLEDが点灯しっぱなしになっています。 私は以下の手順を実行して復旧を試みました。 1. リセットボタンを押しながらUSBケーブルを抜き差しすることでフラッシュメモリへの書き込みを試みました。これは、無限ループが始まる前のタイミングを狙ったものです。 * 数十回試みましたが、成功しませんでした。 2. リセットボタンを押しながらUSBケーブルを接続し、ブートローダーモードに入りました。 * 「BOOTUPDATEAPP_Pemicro_v111.SDA」をフラッシュしました。 * その後、「MSD-DEBUG-EVB-S32K144_PEmicro_v125.SDA」をフラッシュしました。 状況は改善しなかった。 3. 「Kinetis_Recovery_Utility.exe」を使用してフラッシュメモリの復旧を試みました。 * USBケーブルを何度か抜き差ししてみましたが、処理が完了しませんでした。 次に何を試したらいいのか分かりません。 もし基板の修復方法をご存知の方がいれば、手順についてアドバイスをいただけますか? Re: Regarding Flash Programming for the FRDM-A-S32K144N こんにちは、福田さん 新たにリリースされたFRDM-A-S32K144Nの開発ボードは手元にないので、自分でテストしたことはありません。急いでいなければ、今すぐトラブルシューティングをお手伝いし、ボードを受け取ったらテストを行います。ボードは10月中旬に届く予定です。 ケーブルを J1 USB Type-Cポートに差し込んだら、基板の上部の写真を撮って共有してください。 あなたがどの2つのLEDについて言及しているのか分かりません。SPF-96556_B.pdfという文書には、 D5 （赤）とD4 （オレンジ）しか記載されていないからです。 D4ランプが点灯している場合、オンボードのOpenSDAデバッガが正常に動作していることを示します。ただし、 D5が点灯している場合は、S32K144Nがリセット状態にあることを示しています（ RESET_MCU信号がローになる場合があります）。オシロスコープを使用して信号を観察し、周期的なローパルスの周波数を確認してください。 さらに、 S32K144Nに以前どのようなプログラムが書き込まれていたのかも不明です。もしブランクチップで、 RESET_MCU 信号が周期約118μsの高レベルパルスを周期的に示す場合は、SWD/JTAGデバッグインターフェースを通じて「質量消去」コマンドを実行することでMCUを復元できます。 オンボードデバッガはPEMicroが提供しているため、「Multilink Debug Probes」の「サポート & Downloads」カテゴリから最新の「USB Multilink Resources Installer」をダウンロードすることをお勧めします。インストール後、 C:\PEMicro\Multilink_ResourcesのPEFirmwareConfig.exeを開き、ファームウェアのバージョンを確認してください。 ハードウェアタイプを選択してください: マルチリンクACP Embedded - オンボードARMデバッグインターフェース。その後、利用可能なアップデートを確認してください。 あなたは既に「 S32K144 D2 赤色LEDが常に点灯している」という議論を参照されたようですね。以前 PEMicro の Web サイトで提供されていたKinetis_Recovery_Utility (バージョン8.17 ) は正しく動作しませんでした。Kinetis_Recovery_Utility (バージョン1.06 )はそのディスカッションに添付ファイルとしてアップロードしました。問題なく動作しています。 Kinetis_Recovery_Utilityを使用する際は、PEMicroデバッガの電源をオンにしたまま、S32Kチップのみを繰り返し電源オン/オフしてリセットすることをお勧めします。 もしJ3に接続された外部のマルチリンクデバッガがあれば、J1を繰り返し差し入れたり外したりして、外部マルチリンクを稼働させたまま電源をS32K144Nに切り替えることができます。 しかし、外部マルチ リンク がなく、オンボードの OpenSDA デバッガのみに頼っている場合、 FRDM-A-S32K144N の設計には多少の不便があります。S32K144EVBのジャンパーSJ10は、S32K144への電源を繰り返しオン/オフする際には、 J107ほど便利ではありません。SW2ボタンを繰り返し押すだけで、 Kinetis_Recovery_UtilityがS32K144Nを適切なタイミングで停止させることができるかどうかは確信が持てません。 よろしくお願いします、 ロビン

i.MX RT1176 – FlexIO2 并行接收：可实现的最大时钟移位是多少？仅达到约 48 MSPS iMXR1176 SDK 25.09.00 清单 3.15.0 目标 我正在从 i.MX RT1176 上的 LTC2164 16 位 ADC 获取数据。数据路径为： LTC2164（全速率CMOS输出）→ FlexIO2（并行接收）→ eDMA → 外部同步动态随机存取存储器(SDRAM) 硬件设置 LTC2164 配置为全速率 CMOS 输出模式，由外部 100 MHz 振荡器提供时钟信号（即 100 MSPS，16 位并行）。 ADC 数据输出 D0–D15 连接到 GPIO_AD_00 … GPIO_AD_15。 ADC CLKOUT+ 连接到 GPIO_AD_30，用作 FlexIO 定时器时钟（外部引脚时钟源）。 软件设置 FlexIO2 配置为并行接收器，数据锁存到移位器 7；移位器 7->0 串联起来，以便在 DMA 请求钳位之前缓冲 32 字节。 eDMA 由 kDmaRequestMuxFlexIO2Request0Request1 触发，使用两个 TCD 以乒乓（分散/聚集）模式运行。每次主循环完成时都会引发中断，即每 16384 个样本一次。 FlexIO2 功能时钟：120 MHz。 总线时钟（eDMA / SEMC 侧）：240 MHz。 问题 在 100 MSPS 下，采集 16384 个样本需要163.84 µs 。通过测量两个连续 DMA 中断之间的时间（GPIO 切换 + 示波器），我始终得到338 µs ，即 ~2.06 倍。 这相当于大约48 MSPS的有效持续速率，这表明瓶颈在于 FlexIO 端，而不是 ADC 或 SDRAM。 问题 RT1176 上 FlexIO 在并行接收模式下是否有记录在案的最大移位时钟频率？我在参考手册或数据表中都找不到这样的数据。 当定时器时钟源为外部引脚时，FlexIO 功能时钟与外部移位时钟之间所需的比率是多少？我的 FlexIO 时钟 (120 MHz) 只是输入 100 MHz 时钟的 1.2 倍——这足够吗？还是输入同步逻辑需要 2 倍或 4 倍？ 鉴于我观察到的几乎精确的 ×2 比率，这是否可能是由于 FlexIO 定时器在时钟的两个边沿递减（TIMCMP 约定）造成的，这意味着我的定时器比较值实际上将吞吐量减半？ 任何关于 FlexIO + eDMA 在此部分上的最大实际持续吞吐量的指导都将非常有帮助，因为这决定了我是否需要迁移到不同的外设或外部 FIFO。 先行致谢。 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached 您好，谢谢您的回复。我确实达到了预期的性能，但这仅仅是通过超过 Flexio 外设的最大推荐时钟频率来实现的；具体来说，要达到 100 MSps 的采集速率，需要将时钟频率配置为 200 MHz 以上，而不是 120 MHz，而 120 MHz 的配置会导致时钟边沿丢失。问题是，即使它在 200 MHz 下工作（尽管参考手册规定最大频率为 120 MHz），我也无法保证在不同的温度条件下或不同生产批次之间可靠运行。 Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached 你好@azed38 ， 请注意，当使用外部引脚作为时钟源时，会引入较小的同步延迟。根据 RM 第 67.3.3.2 节，此延迟范围为 0.5 至 1.5 个 FlexIO 时钟周期： Habib_MS_1-1788818202534.pngHabib_MS_1-1788818202534.pngHabib_MS_1-1788818202534.png 关于 FlexIO 和 DMA 可达到的最大吞吐量，目前还没有针对 FlexIO 和 DMA 的性能测试。不过，您可能会发现AN12686很有用，因为它演示了使用 FlexIO 和 DMA 的并行通信实现，这可能会为您的用例提供相关指导。 BR 哈比卜 Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached 你好@azed38 ， 我注意到您已经通过其他渠道获得了关于此主题的支持，因此我们将继续通过该渠道提供支持，以保持所有沟通的集中化。我只想补充一点，如果 FlexIO 的运行频率超过其最大规格，可能会导致意外行为，从而影响您的最终应用程序。根据 RM 表 15-4“时钟根”中提供的信息，我建议使用最大频率 120 MHz。 BR 哈比卜 Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached 您好， 这个问题很可能是由于第 67.3.3.2 节中描述的引脚同步延迟造成的。参考手册中的“引脚同步”部分。 考虑到前面提到的设置，问题的根本原因是输入数据频率与 FlexIO 上的工作时钟频率之间的比率，这是由于该模块前面提到的引脚同步延迟造成的。 例如，由于存在引脚同步延迟，FlexIO 模拟外设（如 SPI 主控）只能以 FlexIO 工作时钟频率的四分之一的最大波特率运行。如 RM 第 67.4.3 节所述：“由于同步延迟，串行输入数据的建立时间为 1.5 个 FlexIO 时钟周期，因此最大波特率除以 FlexIO 时钟频率的 4。” 在这种情况下，吞吐量预计会降低，而且由于引脚同步延迟是 FlexIO 模块固有的特性，因此没有解决办法。 因此，为了确保正常运行，FlexIO 模块的最大工作频率为 120MHz，RT1170 无法达到预期的 100MSPS。 BR 哈比卜 Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached 鉴于我观察到的几乎精确的 ×2 比率，这是否可能是由于 FlexIO 定时器在时钟的两个边沿递减（TIMCMP 约定）造成的，这意味着我的定时器比较值实际上使吞吐量减半？ 我只是想提一下，是的，FlexIO 定时器在由引脚或触发信号驱动时，对双边沿敏感。因此，如果你的外部信号包含一个上升沿和一个下降沿，你的定时器就会对其比较值进行两次计数。 另外，根据我目前使用 FlexIO 的经验，我猜测你只能处理频率不超过 FlexIO 时钟频率一半的外部信号。除此之外，它还能如何感知双面边缘？为了检测边沿，它需要在每个时钟周期内对外部引脚进行两次采样。

imx8qxp H265 示例视频播放 我尝试播放h265视频文件，但无法播放。 IMX8QXP - 斯卡思间隙 - L 6.6.52 请您检查并提供播放h265视频示例文件的正确命令或软件包/库。 gst-launch-1.0-v filesrc location=/root/sample.h265 !h265解析！v4l2h265dec！imxvideoconvert_g2d！fpsdisplaysink video-sink=waylandsink text-overlay=false sync=false & i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Re: imx8qxp H265 sample video play 你好， 请查收更新内容。 root@imx8qxpc0mek:~# root@imx8qxpc0mek:~# gst-launch-1.0 -v filesrc location=/navigation/aa_video_dump.h265 ! h265parse ! v4l2h265dec ! imxvideoconvert_g2d ! fpsdisplaysink video-sink=waylandsink text-overlay=false sync=false 将管道设置为暂停状态... ====== V4L2DEC: 1.24.7 版本，构建于 2024 年 10 月 23 日 09:43:13。====== 管道正在预滚动…… /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstWaylandSink:waylandsink0: sync = false 重新分配延迟…… /GstPipeline:pipeline0/GstH265Parse:h265parse0.GstPad:src: caps = video/x-h265, width=(int)1280, height=(int)720, framerate=(fraction)30/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)au, pixel-aspect-ratio=(fraction)1/1, profile=(string)main, tier=(string)high, level=(string)4 /GstPipeline:pipeline0/v4l2h265dec:v4l2h265dec0.GstPad:sink: caps = video/x-h265, width=(int)1280, height=(int)720, framerate=(fraction)30/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)au, pixel-aspect-ratio=(fraction)1/1, profile=(string)main, tier=(string)high, level=(string)4 /GstPipeline:pipeline0/v4l2h265dec:v4l2h265dec0.GstPad:src: caps = video/x-raw, format=(string)NV12_8L128, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, framerate=(fraction)30/1 /GstPipeline:pipeline0/imxvideoconvert_g2d:imxvideoconvert_g2d0.GstPad:src: caps = video/x-raw, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, format=(string)YUY2 /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = video/x-raw, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, format=(string)YUY2 /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0/GstWaylandSink:waylandsink0.GstPad:sink: caps = video/x-raw, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, format=(string)YUY2 /GstPipeline:pipeline0/GstFPSDisplaySink:fpsdisplaysink0.GstGhostPad:sink: caps = video/x-raw, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1, format=(string)YUY2 /GstPipeline:pipeline0/imxvideoconvert_g2d:imxvideoconvert_g2d0.GstPad:sink: caps = video/x-raw, format=(string)NV12_8L128, width=(int)1280, height=(int)720, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, colorimetry=(string)bt709, framerate=(fraction)30/1 重新分配延迟…… root@imx8qxpc0mek:~# gst-inspect-1.0 | grep -i h265 codectimestamper: h265timestamper: H.265 timestamper rtp: rtph265depay: RTP H265 解压加载器 rtp：rtph265pay：RTP H265 有效载荷 typefindfunctions: video/x-h265: h265, x265, 265 video4linux2：v4l2h265dec：V4L2 H265解码器 videoparsersbad: h265parse: H.265 解析器 root@imx8qxpc0mek:~# root@imx8qxpc0mek:~# root@imx8qxpc0mek:~# gst-inspect-1.0 | grep -i v4l2 video4linux2：v4l2deviceprovider（GstDeviceProviderFactory） video4linux2：v4l2h263dec：V4L2 H263解码器 video4linux2：v4l2h264dec：V4L2 H264解码器 video4linux2：v4l2h264enc：V4L2 H.264 编码器 video4linux2：v4l2h265dec：V4L2 H265解码器 video4linux2：v4l2mpeg2dec：V4L2 MPEG2 解码器 video4linux2：v4l2mpeg4dec：V4L2 MPEG4 解码器 video4linux2: v4l2radio: 收音机 (video4linux2) 调谐器 video4linux2：v4l2sink：视频（video4linux2）接收器 video4linux2：v4l2spkdec：V4L2 SPK解码器 video4linux2：v4l2src：视频（video4linux2）源 video4linux2：v4l2vc1dec：V4L2 VC1解码器 video4linux2：v4l2vp8dec：V4L2 VP8 解码器 video4linux2：v4l2xviddec：V4L2 XVID解码器 root@imx8qxpc0mek:~# root@imx8qxpc0mek:~# Re: imx8qxp H265 sample video play 你好， 由于您使用的是 Scarthgap (6.6.52) 版本，问题可能出在以下方面： 图像中不存在 v4l2h265dec。 H.265 文件不是原始基本流。 VPU固件/驱动程序未加载。 BSP 使用的解码器元件与流水线中指定的解码器元件不同。 请提供以下命令的输出结果： 壳 gst-inspect-1.0 | grep -i h265 gst-inspect-1.0 | grep -i v4l2 `` 并获取 gst-launch-1.0 的确切错误消息，以尝试确定是否发生了以下四种情况之一。 Re: imx8qxp H265 sample video play 你好， 日志显示 H.265 解码和 GStreamer 协商功能正常： h265parse 检测到有效的 1280×720 H.265 主码流。 v4l2h265dec 生成解码后的 NV12_8L128 帧。 imxvideoconvert_g2d 将它们转换为 YUY2 格式。 waylandsink 接受了这些盖子。 这不是 H.265 软件包缺失的问题。 尝试运行以下命令，并允许其不带 & 参数运行，以便错误和管道状态在终端中可见： gst-launch-1.0-v filesrc location=/root/sample.h265 !h265解析！\ v4l2h265dec！imxvideoconvert_g2d！waylandsink 同步=false