S32K3シリーズMCUのDFARS原産国／認定国準拠 こんにちは、皆さん。 私はDFARS準拠の調達が必要なプログラムのためにNXP S32K3ファミリのMCUを評価しており、ここで誰かが正しい方向を教えていただけるか、以前にこの問題に対処したことがある方がいればと思っています。 具体的には、以下の点を確認しようとしています。 製造・組立国(ウェハーファブおよびパッケージ/試験場所)に関する特定のS32K3部品番号 — コンプライアンスは一般的に、部品がDFARSの「認定国」である DFARS 252.225-7002(下請け業者としての適格国)で製造されているかどうかに結びついているため、一般的な「NXPは準州です」という説明ではなく、部品番号やパッケージレベルで必要です。 NXPが特定の部品に対して原 産証明書(COO) または正式な DFARS準拠声明 を発行できるかどうか。 TAA（貿易調整支援法）の遵守証明書が入手可能かどうかも確認したい。というのも、それが当プログラムにも適用される可能性があるからだ。 関心のある部品（同じレベルに該当する代替品も検討可）： S32K344 S32K358 S32K314 私たちは≥512 kBフラッシュ、≥128 kB RAMを搭載したMCUをターゲットにしているので、主に高容量メモリのS32K3バリアントを検討していますが、他のS32K3ファミリ(またはより広範なS32K1/S32K2ライン)がコンプライアンスのためにより詳しいドキュメントがあるかどうかも聞きたいです。 コミュニティへの質問： 誰か、S32K3部品のCOO/DFARSドキュメントをNXPから直接取得することに成功した方はいらっしゃいますか?もしそうなら、誰と仕事をしましたか(FAE、代理店、品質チームなど)? これはNXPが公開するものなのでしょうか?それとも常に部品や日付コードごとにCASEバイCASEでリクエストされるのでしょうか? DFARS資格のある国から調達されているとされる特定のS32K3部品番号やパッケージはありますか?それとも、そうでない国から調達されているのでしょうか? S32K3はオートモーティブやインダストリアルセーフティのアプリケーションに強く位置づけられているため、防衛関連プログラム向けのコンプライアンス文書を入手した経験がある方はいらっしゃいますか? これはコミュニティエンジニアが直接アクセスできないかもしれないと理解していますが、もしより良いチャネル(地域のFAE、代理店コンプライアンスデスクなど)があれば本来ならこのルートをルーティングすべきなので、そちらを教えてください。アドバイスをいただければ幸いです！ よろしくお願いします！ Re: DFARS Country-of-Origin / Qualifying-Country Compliance for S32K3 Series MCUs こんにちは、 @dbow12 さん。 この情報は一般には公開されていません。 COOに関するお問い合わせは [email protected] までお問い合わせください。 輸出管理に関するお問い合わせは、ご連絡ください [email protected]。 ただし、まずは地元の代理店に連絡することをお勧めします。彼らはこの点でサポートしてくれるはずです。 よろしくお願いいたします。 ダニエル

IMX8MP Linux U-Boot 需要使用默认环境变量并添加额外变量进行配置。 IMX8MP linux uboot 在通过 uuu 刷写引导加载程序后，需要设置默认环境和其他一些变量。 使用案例： IMX8MP SoM 出厂时自带厂商提供的默认 uboot。因此，第一次写入需要刷写新的 uboot 镜像时，我们将其设置为默认环境，并在工厂流程中设置了一些板级特定的环境变量。 所以当我使用命令 `uuu -b emmc_all bl-imx8mp.bin image.wic.zst` 时，它使用的是内置脚本。 uuu_version 1.4.149 # @_flash.bin | 引导加载程序，可以从 WIC 镜像中提取 # @_image [_flash.bin]| 将 WIC 镜像刻录到 EMMC。 # 此命令将在 i.MX6/7、i.MX8MM、i.MX8MQ 运行时运行 SDP：启动 -f bl-imx8mp.bin -scanlimited 0x800000 # 当 ROM 支持流模式时，将运行此命令 # i.MX8QXP，i.MX8QM SDPS：boot -scanterm -f bl-imx8mp.bin -scanlimited 0x800000 # 这些命令将在使用 SPL 时运行，如果未使用 SPL 则会跳过。 # SDPU 将被弃用。请使用 SDPV 代替 SDPU # { SDPU：延迟 1000 SDPU：写入 -f bl-imx8mp.bin -offset 0x57c00 SDPU：跳转 -scanlimited 0x800000 # } # 这些命令将在使用 SPL 时运行，如果未使用 SPL 则会跳过。 # 如果（SPL 支持 SDPV） # { SDPV：延迟 1000 SDPV：写入 -f bl-raptor-imx8mp.bin -skipspl -scanterm -scanlimited 0x800000 SDPV：跳转 -scanlimited 0x800000 # } FB：ucmd setenv fastboot_dev mmc FB：ucmd setenv mmcdev ${emmc_dev} FB：ucmd mmc dev ${emmc_dev} FB：flash -raw2sparse 所有 image.wic.zst/* FB：flash -scanterm -scanlimited 0x800000 bootloader bl-imx8mp.bin FB: ucmd 如果环境变量 emmc_ack 存在；则；否则设置环境变量 emmc_ack 为 0；结束； FB：ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB：完成 所以我的要求是 刷写引导加载程序 + 根文件系统/镜像 恢复默认设置。 添加新变量。 使用具有预期环境的正确工作的新引导加载程序重新启动。 但现在是先刷写根文件系统，然后再刷写新的引导加载程序。所以当我执行 env default -f -a 之后，它导致 SoM 板上旧引导加载程序的默认环境。重置后，它会使用新的引导加载程序启动，但会保留旧引导加载程序的默认设置。有什么建议可以解决这个问题吗？ Re: IMX8MP linux uboot need to be set up with the default environment + extra variables 你好@jake4 希望你一切都好。 您可以尝试编写自己的自定义脚本并添加以下内容： FB: ucmd env default -f -a 完整脚本示例： uuu_version 1.4.149 SDP: boot -f bl-imx8mp.bin -scanlimited 0x800000 SDPS: boot -scanterm -f bl-imx8mp.bin -scanlimited 0x800000 SDPU: delay 1000 SDPU: write -f bl-imx8mp.bin -offset 0x57c00 SDPU: jump -scanlimited 0x800000 SDPV: delay 1000 SDPV: write -f bl-imx8mp.bin -skipspl -scanterm -scanlimited 0x800000 SDPV: jump -scanlimited 0x800000 FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all image.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 bootloader bl-imx8mp.bin FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: ucmd env default -f -a FB: ucmd setenv board_version "1.0" FB: ucmd setenv my_custom_var "value" FB: ucmd saveenv FB: ucmd reset FB: done 顺祝商祺！ 萨拉斯。 Re: IMX8MP linux uboot need to be set up with the default environment + extra variables 嗨@Manuel_Salas ， 我们只会在 uboot 中启用 eth fastboot，因此我们不能使用 SDP 的启动开关。请问是否有只使用fastboot命令的选项？ 谢谢！

カメラモジュールの互換性OX05B1S センサーおよび内蔵ISPとi.MX95 FRDM対応 こんにちは、皆さん。 ox05b1sセンサーと内蔵ISPを搭載したカメラモジュール(NVIDIA Jetson AGX Orin用の5MP RGB-IR Global Shutter GMSL2カメラに似たもの)がi.MX95 FRDMボードに対応しているか知りたいです。 i.MX95はポートがMIPI_CSI2しかないので、GMSL2からMIPI_CSI2コンバータを探す必要があるのは理解していますが、私の質問はNXP Linux BSPに含まれる既存ドライバの互換性に関するものです。NXP Linuxリリースのドライバ カメラドライバーはこのカメラモジュールと直接動作しますか? dtbファイルに変更を加える必要はありますか？他に何か変更点や追加作業が必要で、計画しておくべきことはありますか？

关于通过 I2C 进行 PCA9450CHN 电压配置的查询 我们正在使用 PCA9450CHN PMIC，并且了解到它使用默认稳压电压上电，可以通过 I2C 编程进行修改。请您解释一下上电后更改这些电压的完整步骤，包括SoC开始与PMIC通信时的步骤？另外，请告知我们推荐的调试器或工具，以便监测和验证 PMIC 寄存器编程和电压变化。 电路板设计 HW-开源 Re: Query Regarding PCA9450CHN Voltage Configuration Through I2C guoweisun_0-1786078934821.png 您可以参考以上内容，在 POR_B 信号拉高且 PCA9450C 进入 RUN 模式后，您可以更改其电源轨输出值。

如何使用MC33 PT2000集成电路调整SOI-EOI 正如主题所述，我们需要能够建立整个流程的帮助，该流程使用PT2000进行燃油喷射SOI-EOI测量。 H桥驱动器 小型发动机驾驶员 电磁阀控制器 Re: How use adjust SOI -EOI with use MC33 PT2000 IC 谢谢！ Re: How use adjust SOI -EOI with use MC33 PT2000 IC 亲爱的K爱津斌， PT2000 产品页面上提供了 PT2000 注射结束检测应用笔记，可供下载，并附有有效的保密协议。 JozefKozon_0-1786079976443.png 如果您还没有保密协议，并且想要签署一份，请在此处创建一个新工单，我们的保密协议事务代表将协助您完成该流程。 此外，请从FRDMPKPT2000EVM 产品页面下载 PT2000SWUG 和 PT2000-IDEUG。您也可以从同一页面下载 PT2000 Developer Studio IDE 以及峰值保持和 DCDC 软件的软件文件。之后，您可以在FRDMPKPT2000EVM 评估板上测试软件示例。 JozefKozon_1-1786080423866.png 最诚挚的问候， 约瑟夫

PPF0900AMBA1ES 您好，NXP团队： 我正在开发一款基于 i.MX95（MIMX9596，19x19 封装，LPDDR5）的定制板，采用 PPF0900AMBA1ES PMIC。 请您确认一下： 1.该部件号出厂时是否已预先编程了OTP，还是未编程的工程样品？ 2.如果未进行编程，建议如何对 OTP 配置进行编程（或模拟）以进行启动和评估？ 3.是否有适用于 i.MX95 + LPDDR5 (19x19) 实现的参考 OTP 配置文件 (.CFG) 可供我们用作起点？ 作为背景，我们的原理图与 i.MX95 EVK 参考设计（PF09 + PF5301 + PF5302）非常接近，我们目前正在进行初始上电启动。 谢谢！ PMIC Re: PPF0900AMBA1ES PPF0900AMBA1ES 是 OTP 部分，这意味着已经完成了 OTP。 https://www.nxp.com/docs/en/supporting-information/MPF0900AMBA1ES.zip 请从上方链接下载OTP文件。

S32K566 LPUART通信の問題 こんにちは、 S32K566マイクロコントローラの4 Uart_Example_S32K566_M7モジュールを使い、LPUARTモジュールクロックは50MHzです。ボーレートを115200に設定し、UARTからUSBへのコンバータを使ってPCにデータを送0xAAしています。しかし、受信したデータは誤りです（0x00 0x80 0x80）。ボーレートを115200/8 = 14400に設定すると、データは正しく受信されます。9600や19200といった異なるボーレートも試してみました。 私はS32DS 3.6.6とSDK 0.8.0を使っています。 Uart_Example_S32K566_M7のソースコードも添付しておりますので、ご確認ください。 参考資料として、設定ファイルと受信データのスクリーンショットを添付しました。 Manikandan_Aruchamy_0-1786092514163.png レシーバ端子のウィンドウボーレートは115200です: Manikandan_Aruchamy_1-1786092584169.png レシーバ端末のウィンドウボーレートは14400です: Manikandan_Aruchamy_2-1786092633034.png Re: S32K566 LPUART Communication Issue こんにちは、 @Manikandan_Aruchamy さん。 このメールが、あなたがお元気でいらっしゃる時に届くことを願っています。現在お手元にある製品、まだ正式に発売されていないNPI(新製品導入)についてお手伝いしています。 これらの製品の早期アクセス権を得たお客様は、現場エンジニアを割り当てていることにご注意ください。指定されたフィールドエンジニアが、この製品に関する問題や懸念、問い合わせの主要なサポートチャネルとなります。 正式リリース後、オンラインサポートチームはより幅広いサポートを展開していきます。それまでは、私たちは必要な支援を提供する体制が整っていません。 ご理解いただきありがとうございます。 よろしくお願いいたします。 パベル

PPF0900AMBA1ES こんにちは、NXPチームの皆様、 i.MX95(MIMX9596、19x19パッケージ、LPDDR5)をベースにしたカスタムボードをPPF0900AMBA1ES PMICを使って作っています。 確認いただけますか: 1. この部品番号の商品は、OTPが既にプログラムされた状態で出荷されますか、それともプログラムされていないエンジニアリングサンプルですか？ 2. プログラムされていない場合、起動および評価目的でOTP構成をプログラム（またはエミュレート）するための推奨手順は何ですか？ 3.Is 参照OTP設定ファイル(.i.MX95 + LPDDR5(19x19)実装で利用可能なCFG)を出発点として使えるでしょうか? 参考までに、私たちの回路図はi.MX95 EVKのリファレンスデザイン(PF09 + PF5301 + PF5302)に忠実に従っており、現在は初期電源オンの起動作業を行っています。 よろしくお願いします。 PMIC Re: PPF0900AMBA1ES PPF0900AMBA1ESはOTP部分であり、既にOTPが実行されていることを意味します。 https://www.nxp.com/docs/en/supporting-information/MPF0900AMBA1ES.zip OTPファイルは上記のリンクからダウンロードしてください。

FRDM-MCX N947 和 OV5640 相机 我目前正在将一个摄像头流媒体管道（之前在 ESP32-S3 上开发）移植到 FRDM-MCXN947。目标分辨率为 1080p，通过 OV5640 摄像头模块进行捕获，通过 MCXN947 硬件加速器进行处理，并通过 SPI 流传输到 ESP32-C5 进行 Wi-Fi 传输。 硬件流水线： OV5640 摄像头（8 位 DVP）-> MCXN947（FlexIO / SmartDMA）-> 外部 PSRAM -> SPI -> ESP32-C5 -> Wi-Fi 当前进度和设置 SCCB/I2C 控制：功能齐全。相机寄存器读写操作成功，初始化完成。 SmartDMA 基准测试：测试了 OV7670（使用内部 SRAM）的 NXP SDK SmartDMA 示例，结果符合预期。 目标：使用 OV5640、外部 PSRAM 缓冲和 FlexIO 捕获，将其扩展到 1080p 分辨率。 问题 1：FlexIO 引脚重映射 & D4/D5 引脚数据无效 当尝试通过 FlexIO 进行 8 位并行捕获时，数据线 D4 和 D5 无法读取有效的像素数据，而数据线 D0-D3、D6 和 D7 则表现正常。 初始引脚映射： D0-D3：P1_4、P1_5、P1_6、P1_7 D4-D5：P3_4、P3_5（问题：无有效像素数据） D6-D7：P1_10，P1_11 控制：VSYNC > P1_18，HREF > P1_19，XCLK > P2_2 SCCB：SCL > P3_2，SDA > P3_3 已尝试的故障排除方法： 我尝试将 D4 和 D5 重新映射到其他引脚，并更新了相应的 FlexIO 和引脚复用器配置： 重新映射 D4：P2_8 重新映射 D5：P2_9 即使经过重新映射，D4 和 D5 仍然无法捕获有效数据。 问题 2：1080p 的 SmartDMA 路由到外部 PSRAM 由于 1080p 帧缓冲区超过了内部 SRAM 容量，因此必须将帧实时缓冲到外部 PSRAM 中。 我正在寻找最佳实践和配置步骤，以配置 SmartDMA，将传入的 FlexIO 相机数据直接路由到外部 PSRAM，而无需 CPU 干预或帧撕裂。 任何见解、引脚映射建议或参考代码都将不胜感激！ 电路板设计 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） MCX N Re: FRDM-MCX N947 and OV5640 Camera 嗨@DocMonster7 我们已经在 FRDM-MCXN947 板上验证了官方 SDK 示例 frdmmcxn947_smartdma_camera_flexio_mculcd_cm33_core0，该示例通过 J9 摄像头接口连接了 OV7670 相机。在本参考设计中，CAMERA_D4 和 CAMERA_D5 分别映射到 P3_4 和 P3_5，图像捕获工作正常。 根据此验证，P3_4 和 P3_5 似乎作为相机数据输入正常工作。因此，该问题不太可能是由这些MCU引脚本身的限制引起的。 我们建议进一步检查 OV5640 硬件连接、信号完整性、引脚复用配置以及对原始 SmartDMA 相机捕获实现所做的任何修改。 Harry_Zhang_0-1786329719002.pngHarry_Zhang_0-1786329719002.png BR 哈里 Re: FRDM-MCX N947 and OV5640 Camera 嗨，哈里， 感谢您在 J9 上验证 SmartDMA OV7670 SDK 示例。这样就明确了二者的区别。 造成这种差异的原因是所使用的捕获外设不同。 SmartDMA（EZH 引擎）：直接对 GPIO/EZH 端口进行采样（其中 J9 上的 P3_4 和 P3_5 可作为 EZH_LCD_D4/D5 正常工作）。 FlexIO 并行引擎 (fsl_flexio_camera)：需要 8 个连续的 FlexIO 移位器数据引脚（FLEXIO0_D12 至 FLEXIO0_D19）。在 FRDM-MCXN947 上，J9 上的 P3_4 和 P3_5 没有 FlexIO 引脚复用。要获得连续的 FlexIO D16/D17 线，必须将它们路由到 P3_8 (TP16) 和 P3_9 (TP15)。 当将 D4 路由到 P3_8 (TP16) 以进行 FlexIO 捕获时，我们在 P3_8 上遇到了活跃的硬件争用（在 ~0.15V - 1.3V 钳位的主动驱动 GPIO 测试），因为 P3_8 与板载 QSPI Flash (U8 Winbond W25Q64, FlexSPI0_A_DATA0) 共享。

S32K338に関する詳細情報 おはようございます。 S32K388マイクロコントローラがK324のように3つの独立したコアを持っているのか、そしてそのうち2つのコアがLockstepでも使えるのか知りたいです。 シングルコア1つ+ロックステップコア1つが欲しい場合、K358を使うべきでしょうか? ありがとう Re: Detail about S32K338 こんにちは、 @gianpiero_lenta さん、 ロックステップ操作は、独立したコア間で有効化できるソフトウェア設定可能な機能ではありません。それに対し、Lockstepは特定のS32K3派生製品に実装された専用のハードウェア構成である。 したがって、アプリケーションで独立したCortex-M7コアとLockstep Cortex-M7ペアが必要な場合は、このハードウェア構成で設計されたS32K358の使用をお勧めします。 よろしくお願いいたします。 パベル

USBシリアルダウンロードモードが動作するかどうか こんにちは、 現在のプロジェクトでは、製品にはUSB 2.0高速を動作させる「USB-C」ポートが「1つ」のみあります。私たちの目標アプリケーションは、このUSBポートをUSBホストとして使い、USBメモリやソリッドステートドライブを接続してローカル録画を行うことです。 しかし、次の改訂版PCB回路では、以下に示すように、USB-Cの2つのCCピンの両方でVCC_5V0に56KΩのプルアップ抵抗を設ける予定です。つまり、CC構成定義に基づいて、USBポートをUSBホストにハードワイヤリングで固定したということです。ホストとデバイス間でCCピンを切り替えるジャンパー/スイッチ/Type-Cコントローラ(DRP(デュアルロールポート)論理IC)回路は存在しません。 Esther_Liu_0-1786180179443.png この回路に基づいて、i.MX8M+ USB シリアルダウンロードモードはまだ動作するのか知りたいです。i.MX8M+ Boot ROMがUSBシリアルダウンロードモードを有効にすると、ポートは自動的にUSBデバイスとして設定されることは理解しています(USBシリアルダウンロードモードが動作するため)が、それはチップのROMコードが内部USB PHYのみをデバイスモードに制御し、ハードウェアの外部CC抵抗状態(Type-Cポートの役割)を上書きできないことを意味します。その結果、PCはUSB経由で i.MX 8M Plusを列挙することができず(両者ともUSB物理層の視点からハンドシェイク(Type-C Attach)を完了できず)、UUUプログラミングが失敗します。上記の記述が正しい場合、USBシリアルダウンロードモードは起動前に動作不能になり（つまり全く動作しなくなり） 、工場出荷時のフラッシュ書き込み機能やシステム復旧機能が失われます。 私たちの理解は正しいでしょうか？ よろしくお願いいたします。 Re: Whether USB serial download mode can work or not こんにちは、 @Esther_Liu さん おっしゃる通りです。CCをプルアップ接続に強制すると、ホストモードのままになり、UUUが正常に動作しなくなる可能性があります。 B.R

I2Cを介したPCA9450CHNの電圧設定に関する問い合わせ 私たちはPCA9450CHN PMICを使用しており、デフォルトのレギュレーター電圧で電源が動くことを理解しており、I2Cプログラミングで修正可能です。電源オン後の電圧変更の全順、特にSoCがPMICと通信し始めるタイミングについて説明していただけますか?また、PMICレジスタのプログラミングや電圧変化を監視・検証するための推奨デバッガーまたはツールがあれば教えてください。 ボード設計 HW-Open-Source Re: Query Regarding PCA9450CHN Voltage Configuration Through I2C guoweisun_0-1786078934821.png 上記のように、POR_B信号がハイを引き、PCA9450CがRUNモードに入ると、電源レールの出力値を変更できます。

MIMXRT1170-EVK FreeRTOS Hello 示例问题 大家好， 我将 MCUXpresso SDK 中的evkbmimxrt1170_freertos_hello_cm7示例项目导入到 MCUXpresso IDE 中，没有做任何重大修改。 项目构建成功，没有任何错误或警告，并成功下载到 MIMXRT1170-EVK(MIMXRT1176DVMAA) 板。 任务创建成功，但只执行了一次，然后在地址0xDEADBEEE处停止。这种行为每次都会发生。 LED切换任务： 为了验证问题是否与 vTaskSuspend() 有关，我创建了另一个简单的 LED 闪烁任务。 预期行为： LED应该每100毫秒持续切换一次。 实际行为： LED灯只闪烁一次。 第一次执行后，调试器再次停止在： 0xDEADBEEE 请您解答以下疑问： 在 i.MX RT1170 的 MCUXpresso SDK 中，地址0xDEADBEEE表示什么？ 为什么该任务只执行一次而不是定期运行？ MIMXRT1170-EVK 是否需要进行任何额外的配置才能正常工作？ 要使任务按预期定期执行，需要进行哪些更改？ Rosh_0-1786093292545.png Rosh_1-1786093311524.png Rosh_2-1786093339102.png Re: MIMXRT1170-EVK FreeRTOS Hello Example Issue 你好@Rosh ， 我了解到您目前正在使用 MIMXRT1170-EVK。请注意，MIMXRT1170-EVK 的 SDK 与 MIMXRT1170-EVKB 的 SDK 不同。请您使用 MCUXpresso SDK Builder下载并测试专门为 RT1170-EVK 生成的 SDK 好吗？ Habib_MS_0-1786125239179.png 我明白你的意思。SDK 示例旨在为每个外围设备功能提供常见用例。0xDEADBEE 值通常与 HardFault 情况相关。 请您在不做任何修改的情况下运行示例，并使用最新可用的 SDK 版本告诉我结果。 BR 哈比卜 Re: MIMXRT1170-EVK FreeRTOS Hello Example Issue 你好@Habib_MS 我使用 MCUXpresso SDK Builder 下载了专门为 RT1170-EVK 生成的 SDK，并进行了测试。现在运行正常了。 感谢您的支持。

T Embedにはどのようなポートがありますか？ 標準モデルのTエンベッドを持っていますが、どのポートか全く分かりません(もう一つのポートで、USB-Cではありません)。公式サイトではGroveポートと書いてあり、LilygoのWikiサイトではQwiicポートと書かれています。どなたか助けていただけませんか?

imx-95-FRDM でコンパイルエラーが発生しました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/xen/gntdev.h: 開けられない: そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/xen/evtchn.h: 開けません:そのようなファイルやディレクトリはありません Re: Compilation Error on imx-95-FRDM こんにちは、 @Asadedsさん お使いのBSPのバージョンは何ですか？私のImx95 FRDMで確認しましたが、問題はありませんでした。 pengyong_zhang_0-1786413970033.png B.R

スタンバイモードでは、S32K328のピンは高レベルを出力できません 操作マニュアルに記載されている設定手順に従って、S32K328のいくつかのGPIOピンをスタンバイモードでハイレベルに維持するように設定しましたが、失敗しました。以下は私の設定手順です。私はマニュアルに記載されている4番目の手順を実行しませんでした。これは影響がありますか？以前にもS32K312で同様の設定を行ったことがありますが、エラーは発生しませんでした。私の理解では、リセット後にピン保持機能を無効にしなかった場合、ウェイクアップ後にGPIOピンを低レベル出力するように設定しても、出力ピンレベルはスタンバイモードに入る前に設定された高レベルを維持するはずです。現在、実際の測定では、スタンバイモードと実行モードの両方で設定されている複数のGPIOピンは、低いレベルに留まっています。 6ABE3FCC-00F4-4165-B025-E31BB4B1BEBC.png de7ee9ab18af4cbe9fe5a0f4dbd21427.png Re: In standby mode, the pins of the S32K328 cannot output a high level こんにちは、@hhggll23 さん。 私はマニュアルに記載されている4番目の手順を実行しませんでした。これは影響がありますか？ はい、そうです。スタンバイモードに入る前にパッドキーピングを有効にした場合(DCM_GPR->DCMRWF1[STANDBY_IO_CONFIG] = 0と書いてください。これはSIUL2のPKEが設定されていなくてもデフォルトのレジスタ値ですが、ウェイクアップ後に無効化していなければ、SIUL2モジュールは再度初期化できません。MCUがスタンバイモードに入ってウェイクアップする必要がある間にパッドキーピング機能が必要ないなら、このビットに1をどこかに書き込んでそのままにしておく必要があります。 これはPower_Ip_Init() APIを通じて行われます。 Julin_AragnM_3-1786127814879.png これで、I/Oピンは、パッド保持設定に関係なく、スタンバイモード中も実行モードで最後に設定された状態を保持します。 S32K3は起動後に必ずリセットシーケンスを行い、SIUL2モジュールは機能リセット時にGPIOパッドをデフォルト状態にリセットするため、パッドキーピングによりピンの状態はウェイクアップからユーザーが解除されるまで保持されます。 Julin_AragnM_0-1786126733106.png Julin_AragnM_4-1786128871517.png 画像に示されているすべてのピンをスタンバイ時にHIGHに設定しようとしていますか？スタンバイモードに入ると、すべてLOW状態になるのでしょうか？それとも、終了時でしょうか？ よろしくお願いします、 ジュリアン Re: In standby mode, the pins of the S32K328 cannot output a high level ご返信いただき、誠にありがとうございます。プログラムを再確認したところ、スタンバイ前にピンをハイレベルにした後、意図しないルーチンが実行され、すべてのGPIOピンが再初期化されてしまい、スタンバイ中にピンがローレベルのままになってしまうことがわかりました。変更後、スタンバイモードにおいてGPIOピンのレベルが正常にハイレベルに引き上げられるようになりました。新たな問題が発生しました。スタンバイモードでGPIOピンをハイレベルにプルアップした後、スタンバイ電流が増加したようです。現在、スタンバイ条件下では、コントローラーの静止電流は約3 mAで、24V電源で供給されています。他の回路のトラブルシューティングを行った結果、S32K328がこの電流の大部分を消費しているのではないかと推測しています。24 Vの場合、3 mAはコントローラの5V電源に換算すると約14.4 mAに相当します。スタンバイモードで8つのGPIOピンをハイレベルにしました。この待機電流は正常ですか？この問題に対処するために、S32K328のGPIOピンをスタンバイモードで高インピーダンスに設定し、外部プルアップ抵抗がスタンバイ中にピンの高レベルを維持できるようにしますか?

imx-95-FRDM 编译错误 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/xen/gntdev.h：无法打开：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/xen/evtchn.h：无法打开：没有该文件或目录 Re: Compilation Error on imx-95-FRDM 嗨@Asadeds 您的BSP版本是什么？我在 IMX95 FRDM 上检查过了，没有问题。 pengyong_zhang_0-1786413970033.png B.R

T Embed 使用的是哪种接口？ 我有一台标准的 T 型嵌入式开发板，但我不知道它用的是哪种接口（不是 USB-C 接口），因为官方网站说它是 Grove 接口，而 Lilygo Wiki 网站说它是 Qwiic 接口。请问有人可以帮帮我吗？

FRDM-MCX N947およびOV5640カメラ 現在、カメラストリーミングパイプライン（以前はESP32-S3で動作させていたもの）をFRDM-MCXN947に移植しています。目標解像度は1080pで、OV5640カメラモジュールからのキャプチャ、MCXN947ハードウェアアクセラレータによるプロセッシング、そしてSPI経由でESP32-C5へのストリーミングによるWi-Fi伝送が可能です。 ハードウェアパイプライン: OV5640カメラ（DVP 8ビット）→ MCXN947（FlexIO / SmartDMA）→ 外部PSRAM→ SPI→ ESP32-C5→ Wi-Fi 現在の進捗状況とセットアップ SCCB / I2C制御：完全に機能します。カメラレジスタの読み書き操作は成功し、初期化も完了しました。 SmartDMAベースライン:OV7670用の標準NXP SDKスマートDMA例(内部SRAM使用)をテストし、期待通りに動作しました。 目標：OV5640と外部PSRAMバッファリング、FlexIOキャプチャを使用して、これを1080p解像度に拡張する。 問題1：FlexIOピンのリマッピングとD4/D5の無効なデータ FlexIO を介して 8 ビット並列キャプチャを試みると、データライン D4 と D5 は有効なピクセルデータを読み取ることができませんが、ライン D0～D3、D6、および D7 は正しく動作します。 初期ピンマッピング： D0-D3: P1_4、P1_5、P1_6、P1_7 D4-D5: P3_4、P3_5（問題あり：有効なピクセルデータがありません） D6-D7: P1_10、P1_11 制御: VSYNC -> P1_18、HREF -> P1_19、XCLK -> P2_2 SCCB: SCL -> P3_2、SDA -> P3_3 トラブルシューティングの試み: D4とD5を別のピンに再マッピングし、対応するFlexIOとピンマルチプレクサの設定を更新しました。 D4を再マッピング: P2_8 D5を再マッピング: P2_9 この再マッピングを行っても、D4とD5は依然として有効なデータを取得できません。 問題2：1080pにおける外部PSRAMへのSmartDMAルーティング 1080pのフレームバッファは内部SRAMの容量を超えるため、フレームはリアルタイムで外部PSRAMにバッファリングする必要がある。 SmartDMAを設定して、受信したFlexIOカメラデータをCPUの介入やフレームティアリングなしに外部PSRAMに直接ルーティングするための最適な方法と設定手順を探しています。 ご意見、ピン配置に関するご提案、参考コードなどございましたら、ぜひお聞かせください！ ボード設計 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) MCX N Re: FRDM-MCX N947 and OV5640 Camera こんにちは、 @DocMonster7さん 公式SDKの例は、FRDM-MCXN947ボード上でfrdmmcxn947_smartdma_camera_flexio_mculcd_cm33_core0されており、J9カメラインターフェースを通じてOV7670カメラが接続されていることを検証しました。このリファレンスデザインでは、CAMERA_D4とCAMERA_D5がそれぞれP3_4とP3_5にマッピングされ、画像キャプチャは正しく動作します。 この検証に基づくと、P3_4とP3_5はカメラデータ入力として正しく機能しているようです。したがって、この問題はこれらのMCUピン自体の制限による可能性は低いです。 OV5640のハードウェア接続、信号の完全性、ピン多重化構成、および元のSmartDMAカメラキャプチャ実装に加えられた変更点について、さらに確認することをお勧めします。 Harry_Zhang_0-1786329719002.pngHarry_Zhang_0-1786329719002.png BR ハリー Re: FRDM-MCX N947 and OV5640 Camera こんにちは、ハリーさん。 J9のSmartDMA OV7670 SDK例を検証してくれてありがとうございます。これで違いが明確になった。 この不一致の理由は、使用されているキャプチャ ペリフェラルにあります SmartDMA (EZH エンジン): GPIO/EZH ポートを直接サンプリングします (J9 上の P3_4 および P3_5 が EZH_LCD_D4/D5 として正しく機能する場合)。 FlexIOパラレルエンジン（fsl_flexio_camera）：連続する8つのFlexIOシフターデータピン（FLEXIO0_D12～FLEXIO0_D19）が必要です。FRDM-MCXN947では、J9上のP3_4とP3_5にはFlexIOピンの多重化機能がありません。連続したFlexIO D16/D17回線を取得するには、それらをP3_8（TP16）とP3_9（TP15）にルーティングする必要があります。 FlexIOキャプチャのためにD4をP3_8（TP16）にルーティングする際、P3_8がオンボードQSPIフラッシュ（U8 Winbond W25Q64、FlexSPI0_A_DATA0）と共有されているため、P3_8でアクティブなハードウェア競合が発生しました（アクティブドライブGPIOテストは0.15V～1.3Vにクランプされています）。

USB串口下载模式是否可行 您好，先生， 在我们目前的项目中，我们的产品只有一个“USB-C”端口，运行USB 2.0高速。我们的目标应用是将此 USB 端口用作 USB 主机角色，连接 U 盘或固态硬盘进行本地录制。 但是，我们下一版 PCB 电路将在 USB-C 的两个 CC 引脚上将 56K 欧姆电阻上拉至 VCC_5V0，如下图所示。也就是说，我们根据 CC 配置定义，将 USB 端口硬连接到 USB 主机。没有单独的跳线/开关/C型控制器（DRP（双角色端口）逻辑IC）电路可以在主机和设备之间切换CC引脚。 Esther_Liu_0-1786180179443.png 我们想知道，基于这种电路设计，i.MX8M+ USB 串口下载模式是否还能正常工作？我们了解到，当 i.MX8M+ 启动 ROM 激活 USB 串行下载模式时，端口会自动配置为 USB 设备（以便 USB 串行下载模式工作），但这应该意味着芯片的 ROM 代码仅控制内部 USB PHY 处于设备模式，它不能覆盖硬件的外部 CC 电阻状态（Type-C 端口的作用）。因此，PC 完全无法通过 USB 枚举 i.MX 8M Plus（从 USB 物理层的角度来看，两者无法完成握手（Type-C Attach）），这导致 UUU 编程失败。如果上述说法正确，则 USB 串行下载模式将在启动前失效（即完全无法工作） ，导致失去出厂刷写和系统修复功能。 我们的理解是否正确？ 顺祝商祺！ Re: Whether USB serial download mode can work or not 你好@Esther_Liu 你说得对，如果强制 CC 为上拉模式，它将保持在主机模式，而 UUU 可能会出现故障。 B.R