Keil MDK/uVision を使用したデモの実行 CMSISデバイス・パックのインストール MDK ツールをインストールした後、デバッグの観点からデバイスを完全にサポートするには、Cortex ®マイクロコントローラ ソフトウェア インターフェイス標準 (CMSIS) デバイス パックをインストールする必要があります。これらのパックには、メモリ マップ情報、レジスタ定義、フラッシュ プログラミング アルゴリズムなどが含まれています。適切な CMSIS パックをインストールするには、次の手順に従います。MDK-Arm マイクロコントローラ開発キット (Keil) ®バージョン 5.38.1 以上を使用してください。 µVision と呼ばれる MDK IDE を開きます。IDE内で「Pack Installer」アイコンを選択します パック インストーラー ウィンドウで、「MCXW」を検索して、MCXW71 ファミリを起動します。MCXW7XX の名前をクリックすると、右側に NXP が表示されます。  MCXW71_DFP  パック。パックの横にある「インストール」ボタンをクリックします。このプロセスを正常に完了するにはインターネット接続が必要です インストールが完了したら、［Pack Installer（パック・インストーラ）］ウィンドウを閉じて、µVision IDEに戻ります サンプル・アプリケーションのビルド 以下の手順に従って、  hello_world  応用。一部のアプリケーションではパス内に追加のフォルダー層が存在する可能性があるため、他のサンプル アプリケーションではこれらの手順が若干異なる場合があります。 目的のデモ・アプリケーション・ワークスペースをまだ開いていない場合は以下で開きます。 /boards/ / / /mdk デバッグ構成を選択 プロジェクトを右クリックして、プロジェクト オプションを選択します。 次に、デバッグ オプションに移動し、CMSIS-DAP ARMv8-M デバッガーを選択します。OKボタンをクリックします デモプロジェクトをビルドするには、赤くハイライトされた「リビルド」ボタンを選択します。 ビルドが正常に完了します

S32K144 CSEc 安全启动-设备处于安全状态，无法解除安全保护 硬件 ：S32K144 开发板 IDE ：S32 设计工作室 编程 ：直接通过 S32DS 问题描述： 我通过以下步骤成功在 S32K144 上实现了 cSec 安全启动： 配置密钥 -安装 MASTER_ECU_KEY 和 BOOT_MAC_KEY 闪存区域中的闪存应用程序 - 通过 S32DS 使用 Debug_FLASH 配置 设置安全启动 -通过 S32DS 使用 DEBUG_RAM 配置来存储 BOOT_MAC 重置后 -安全启动工作正常 应用程序工作 - 通过 LED 指示灯确认，BOK=1 问题： 在测试否定情况（失败情景）时： 尝试在闪存区域刷新不同的应用程序 → " 设备是安全的。擦除到不安全？"出现对话框 点击"是" 删除 → 同一对话框不断重复出现 尝试恢复出厂设置 → 还是同样的错误 无法闪存任何新应用程序 问题 点击"Yes" 是否应该自动执行批量删除？ 为什么对话框总是重复出现？ 如何仅使用 S32DS 正确解除设备的安全？正确的程序是什么？ 可以在 S32DS 中使用大量擦除命令吗？ 如果是，具体程序是什么？ 设备永久锁定了吗？或者有通过 S32DS 恢复的方法吗？ 当前状态： 设备似乎处于安全状态。无法使用 S32DS 闪存任何应用程序。需要逐步恢复程序才能解除设备的安全。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 您配置了哪种安全启动模式？有顺序模式、并行模式或严格顺序模式。 如果顺序或并行启动模式失败，则唯一的后果是无法使用受启动保护的密钥。这是唯一的影响，不会影响您的应用程序，它仍然会被执行。 如果严格的顺序启动模式失败，设备将永远处于 RESET 状态，并且无法恢复。 答： 使用 来自 an5401SW 的 s32k144_csec_secure_boot_boot_boot_mac_mac_mac_mac_mac_mac_manual 示例，我们在 BOOT_DEFINE () 函数中将串行安全启动配置为 启动模式。如果启动模式 1 对应 于严格的顺序启动模式 ，这将解释我们遇到的永久 RESET 行为。 " /* 第 3 步定义安全启动模式和 BOOT_SIZE*/ csec_error = BOOT_DEFINE(128*1024*8,1)； " 你检查过RESET信号了吗？它是在开机后版本吗？ 答：是的，我已经检查了 RESET 信号。开机后 RESET 信号保持活动状态（RESET LED 保持亮起），表明设备仍处于 RESET 状态 此外，一旦启用 CSEc，大规模擦除（擦除所有块命令）将被锁定： 要启用批量擦除，必须通过 CMD_DBG_CHAL 和 CMD_DBG_AUTH 命令擦除所有按键，并了解 MASTER_ECU_KEY。 答： 尝试刷新 an5401_s32K144_csec_resetting_flash_to_flash_to_factory_State 时 ，我收到 " 设备是安全的。擦除到不安全？" 对话框。即使在单击 " 是 " 之后，同样的对话框仍会重复出现 S32DS 有 " 通过全芯片擦除进行紧急 Kinetis 设备恢复 " 选项。我们应该用它来恢复设备吗？ 注： 我们没有设置闪存和擦除的调试器。我们使用 S32DS 进行闪存和调试。因此，需要在大规模擦除方面得到帮助。   Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 你好@Kishore_14 您配置了哪种安全启动模式？有顺序模式、并行模式或严格顺序模式。 如果顺序或并行启动模式失败，则唯一的后果是无法使用受启动保护的密钥。这是唯一的影响，不会影响您的应用程序，它仍然会被执行。 如果严格的顺序启动模式失败，设备将永远处于 RESET 状态，并且无法恢复。 你检查过RESET信号了吗？它是在开机后版本吗？ 此外，一旦启用 CSEc，大规模擦除（擦除所有块命令）将被锁定： 要启用批量擦除，必须通过 CMD_DBG_CHAL 和 CMD_DBG_AUTH 命令擦除所有按键，并了解 MASTER_ECU_KEY。 此致， Lukas Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 当 Boot Flavor 参数设置为 0 时，将配置严格的顺序启动模式： 但是，如果你保留原来的顺序启动，那就没有意义了： /* 第 3 步定义安全启动模式和 BOOT_SIZE*/ csec_error = BOOT_DEFINE (128*1024*8, 1); 即使顺序启动失败，也绝对不会导致永久RESET。您是用示波器检查信号，还是只观察 LED 指示灯？RESET信号不是在切换吗？ 如果永久断言重置信号，恐怕就无法恢复。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 直接观察，LED 并非切换，而是常亮。 如果是顺序启动模式，刷新应用程序时设备持续处于 RESET 状态的可能性有多大？ 当示例中的所有 Flashconfig 设置如下所示时，设备将如何获得安全保护： /* 闪存配置 */ .section.FlashConfig,"a" .long0xFFFFFFFF /* 8 字节后门比较密钥 */ .long 0xFFFFFFFF /* */ .long0xFFFFFFFF /* 4 字节程序闪存保护字节 */ .long 0xFFFF7FFE /* FDPROT:FEPROT:FOPT:FSEC(0xFE = 无担保) */ 由于无法使用直接调试器闪存，我能否尝试使用 Kinetis 选项进行大量擦除？ 注意：我们还在另一块板上也观察到了这种情况，并发布在下面的链接中： 错误：设备是安全的。擦除到不安全-恩智浦社区 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 切换 RESET 引脚可能非常快，以至于肉眼可能看不见。所以我才问你是否用示波器试过。 我只能看到永久RESET的两个原因： 1.严格的顺序启动模式失败。 2。硬件问题-通常电压不足，因此电压监测器不允许启动设备... 无法通过（错误的）应用程序强制设备永久RESET。这只能通过某种自毁方式来实现，例如将GPIO设置为短路或类似的方式。 消息 " 设备是安全的。" 。大多数情况下，这通常意味着调试器无法建立连接。在这种情况下，即使设备处于安全状态，也无法对其进行解除保护，因为启用的 CSec 模块会阻止大规模擦除操作。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 你好， 切换 RESET 引脚可能太快了以至于肉眼可能看不见。所以我才问你是否用示波器试过。 你检查过RESET信号了吗？它是在开机后版本吗？ 答：我们观察到 RESET 引脚正在切换。 这是否意味着先前闪存的应用程序在任何 SW /WDG RESET 中都卡住了？ 能否通过 SWD 调试器闪烁恢复？     Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 遗憾的是，我们没有用于闪存的 JLink 或 PE Micro。 我们使用 S32DS OpenSDA 进行调试。 下面是 AN12130 中提到的 在启动程序分区命令 (PGMPART) 时，请务必将 CSEc 键的大小分配为不同于零的值。 - 编程 CSEc 键，至少是 MASTER_ECU_KEY。 - 通过发出 CMD_DBG_CHAL 和 CMD_DBG_AUTH 命令擦除密钥。CMD_DBG_AUTH 命令将擦除 数据 IFR，从而擦除分区代码并允许再次进行大规模擦除。 如果任何 CSec 密钥受到 “写保护”，则上述步骤将不起作用，因此无法用上市大规模擦除。 问题：当我们闪存不同的应用程序时，第一次尝试就闪存成功了。 由于没有遵循上述顺序，下次 RESET 时，新应用程序可能会进入连续 RESET 状态吗？这样做对吗？ Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure 您有读取 MDM-AP 的 Segger J-Link 探头或劳特巴赫调试器吗？遗憾的是，Pemicro 无法做到这一点。 在极少数情况下，设备可以被锁定。请查看此主题： https://community.nxp.com/t5/S32K/Unbricking-S32K146/m-p/937227 要确认这一点，有必要阅读 MDM-AP。 Re: S32K144 CSEc Secure Boot - Device Stuck in Secure State, Cannot Unsecure OpenSDA 也来自 Pemicro。 通常情况下，即使启用了 CSEc，即使某些键受写保护等，也可以通过 OpenSDA 对新应用程序进行编程。这是因为它是逐块擦除闪存，而不是通过大规模擦除。我的意思是，AN12130 谈到了这样的问题： 因此，当编程过程中出现问题时（意外RESET或类似的情况），这些都是相当大的问题。 遗憾的是，确认这种状态的唯一方法是读取提及的 MDM_AP 寄存器。然后我们可以说出设备是否被永久锁定。但 OpenSDA 无法读取寄存器。 此致， Lukas

PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors Hi, We are using an ATH12K Wi‑Fi module on an i.MX95‑based system, connected via the PCIe2 instance. On a kernel based on linux-imx lf‑6.12.y this setup fails, whereas with a kernel based on lf‑6.6.y it works as expected. The kernel driver successfully requests and receives 16 MSI interrupts. However, it subsequently fails to bring up the Wi‑Fi module: [ 5.888139] ath12k_pci 0001:01:00.0: Adding to iommu group 5 [ 5.888506] ath12k_pci 0001:01:00.0: BAR 0 [mem 0xa10000000-0xa101fffff 64bit]: assigned [ 5.888553] ath12k_pci 0001:01:00.0: enabling device (0000 -> 0002) [ 5.889315] ath12k_pci 0001:01:00.0: MSI vectors: 16 [ 5.889334] ath12k_pci 0001:01:00.0: Hardware name: wcn7850 hw2.0 [ 6.475718] ath12k_pci 0001:01:00.0: chip_id 0x2 chip_family 0x4 board_id 0xff soc_id 0x40170200 [ 6.475743] ath12k_pci 0001:01:00.0: fw_version 0x110cffff fw_build_timestamp 2025-06-25 09:26 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 [ 7.647106] ath12k_pci 0001:01:00.0: failed to receive control response completion, polling.. [ 8.675241] ath12k_pci 0001:01:00.0: Service connect timeout [ 8.681002] ath12k_pci 0001:01:00.0: failed to connect to HTT: -110 [ 8.692180] ath12k_pci 0001:01:00.0: failed to start core: -110 There was a related discussion on the kernel mailing list [1] with a different PCIe device, but it has not yet led to a working configuration for our system. What would be the best way to proceed? Thank you for your support. Max [1] https://lore.kernel.org/all/1819305.VLH7GnMWUR@steina-w/ Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors Hello, The i,MX95 is in early stage and some configuration are not in design. However your i.MX95 with ATH12K via PCIe2 failing on lf-6.12.y but working on lf-6.6.y suggests a regression or driver interaction change in newer kernel's PCIe or Wi-Fi stack, likely involving PCIe power management (ASPM), MSI mapping, or specific PCIe endpoint quirks for the ATH12K, often resolved by kernel patches or disabling ASPM in boot args for newer kernels; check dmesg for PCIe errors, compare devicetree, and look for related commits in NXP/Linux kernel mailing lists.  Here's a breakdown of potential causes and troubleshooting steps: 1. Check Kernel Logs ( dmesg ) Look for PCIe Errors: Search for "PCI", "MSI", "ATH12K", "Error", "Firmware", or "Timeout" messages in dmesg on the failing lf-6.12.y kernel. Firmware Loading: Verify the ath12k firmware is loaded correctly and if there are any errors during initialization.  2. PCIe Power Management (ASPM) Common Issue: Newer kernels often enable Active State Power Management (ASPM) by default, which can cause issues with PCIe devices like the ATH12K on embedded systems, especially older firmware/hardware. Try Disabling ASPM: Add pcie_aspm=off to your kernel boot arguments (e.g., in U-Boot or GRUB) and test again.  3. Devicetree/DTB Differences Compare DTBs: Generate and compare the Device Tree Blobs (DTBs) used with both kernels ( .dtb files). Look for changes in the PCIe node for pci2 , especially related to interrupts, power domains, or compatibility properties.  4. Kernel Driver/Firmware Regressions Specific Commits: The ATH12K driver ( ath12k ), mac80211 , or core PCIe/ARM code in lf-6.12.y might have introduced a change breaking your setup. Search Mailing Lists: Check the Linux Kernel Mailing Lists (LKML) and NXP's lists for related patches or discussions around ath12k , i.MX95 , and newer kernels (6.12+).  5. MSI Handling Interrupt Remapping: While you receive interrupts, the way they are handled (MSI-X vs. MSI, interrupt remapping) might have subtle changes. Check Interrupts in proc/interrupts : See if the interrupt distribution or count differs between kernels.  6. Firmware Blobs Firmware Version: Ensure you are using the correct firmware for the ATH12K, compatible with the newer kernel's driver. Sometimes newer drivers require newer firmware.  In summary, start with dmesg and try disabling ASPM; these are the most frequent culprits for PCIe Wi-Fi failures in newer kernels on embedded platforms   Regards Re: PCIe: i.MX 95: Allocate Multiple MSI IRQ Vectors While the suggestions were good pointers to debug the issue I couldn't find the solution, i.e. not all MSI IRQ vectors triggered the IRQ routines in the driver. I ended up working around the issue by changing the ath12k driver to only request one MSI IRQ. Note that current Linux master does not have the issue. Regards Max

S32 Design Studio での S32K344 SDK のインストール 「S32 Design Studio に S32K344 SDK をインストールしましたが、S32DS アプリケーション プロジェクトを作成するときに SDK を選択できません。なぜ？" Re: S32K344 SDK installation in S32 Design Studio こんにちは@ganavi1さん、 @DirkEtzler さんは正しいです。 例えばS3K3 RTD 7.0.0 は、NXP GCC 10.2.0 20200723 を使用して開発およびテストされています (SW32K3_S32M27x_RTD_R23-11_7.0.0_D2511_ReleaseNotes.pdf の第 2.7 章に記載されているとおり)。したがって、GCC10.2を使用する必要があります。 よろしくお願いいたします、 パベル Re: S32K344 SDK installation in S32 Design Studio こんにちは@ganavi1さん、 どのようなツールチェーンを使用していますか?「NXP GCC 10.2 for Arm 32-bit Bare Metal」を選択した場合、SDK が表示されます (下記参照)。ツール チェーンとして「NXP GCC 11.4 for Arm 32 ビット ベア メタル」を選択した場合、SDK は表示されません。

i.MX RT1170 DVFS デモ ダイナミック電圧および周波数スケーリング(DVFS)は、電源電圧とCPU周波数を動的にスケールダウンすることで、CPUの消費電力を動的に削減できる電力管理手法です。i.MX RT1170の内部DCDCは、125°Cの接合部温度で必要な最大電流要件をカバーできないため、DVFS技術を使用して電流ドレインを低減し、内部DCDCとの互換性を確保できます。プロセッサの周波数を動的に下げると、チップの入力電流需要を減らし、チップが125°Cの接合部温度で動作し続けることができます。 デモが添付されています。IAR と armgcc のバージョンのみが有効になります。 対応するアプリケーションノートは、以下のリンクからダウンロードできます。 https://www.nxp.com/docs/en/application-note/AN13267.pdf

MX95 on DT8MCustomBoard MIPI-DSI out Hi, I have a MX95 on DT8MCustomBoard and custom LVDS connected in dual channel mode to LVDS connectors on board. Display is working nicely and all the other peripherals. Now I want to get an external HDMI display connected and thought I would use MIPI-HDMI converter on DT8MCustomBoards's J11 (MIPI-CSI) connector. Then I would just route video from in to midi_dsi and it would eventually be routed out of J11 connecter on onwards to the MIPI-HDMI bridge. Bridge is adv7535 based thus readily supported by the kernel. However, I'm seeing following in kernel logs: root@imx95-var-dart:~# dmesg|grep mipi [ 0.482259] platform 4ad30000.csi: Fixed dependency cycle(s) with /soc/bus@42000000/i2c@42530000/ov5640_mipi0@3c [ 2.426467] imx95-mipi-dsi 4acf0000.dsi: No valid input endpoint found [ 2.433017] imx95-mipi-dsi: probe of 4acf0000.dsi failed with error -22 so clearly there is an issue in display_pixel_link <-> mipi_dsi connection. Has anyone here succesfully demonstrated MIPI-DSI on MX95 + DT8MCustomBoard v3.0 combo? I'd like to see device tree samples as the ones provided in kernel tree are not directly meant for DT8MCustomBoard but to some other EVK. How should I map dpu ports to further in chain if they need customization, any fixed clocks to set etc. So are there some pins to pull down, up or anything? As DSI is muxed with CSI then does CSI need explicit disabling or is it enough to enable mipi_dsi in device tree? Thanks for any pointers and cheers from Finland. Re: MX95 on DT8MCustomBoard MIPI-DSI out Based on our analysis of the kernel code there are exactly two output ports on i.MX 95 and if dual channel LVDS is used, in a mode where even and off pixel rows are routed to different channels, then LVDS reserves both of the ports and MIPI-DSI cannot possibly work. However, datasheets state that i.MX 95 can handle up to three independent displays. What does this mean? Based on our tests we can run one single channel LVDS and MIPI-DSI which makes up two displays or we can run one dual channel LVDS only which kind of makes two displays. So what is the configuration where i.MX 95 can have three independent displays? What ports and connectors should be used? Does dual channel LVDS count as two displays already? Re: MX95 on DT8MCustomBoard MIPI-DSI out Ok, it is now evident (based on the kernel source code) that i.MX 95 SoC has two, and only two, independent output ports in its display processing unit. Dual channel LVDS needs both of these leaving MIPI path disconnected. This means that dual channel LVDS + MIPI-HDMI is not possible on i.MX 95. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hi, an update. I've managed to get MIPI-DSI working so video is routed on MIDI-DSI bus, out from J11 connector on DT8MCustomBoard, over to ADV7535 bridge and in to external HDMI display. However, I'm not able to enable internal LVDS display at the same time with MIPI-DSI. If I enable LVDS display, the ldb node in device tree, it seems to hijack video stream so that it displays on LVDS but not on external display. When this happens I get errors in kernel log stating that imx95-mipi-dsi could not get valid input. I can get either internal LVDS enabled or external HDMI over MIPI-DSI but not both at the same time. This must be something with the device tree but the endpoints I'm using are the ones provided in kernel tree. Device. tree I'm using is imx95 + adv7535 additions with mipi and hdmi nodes. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hello, Did you try to use only MIPI-DSI out? It can handle up to 3 simultaneous displays: 1x 350 MHz MIPI-DSI (4-lane, 2.5 Gbps/lane) supporting 4kp30 or 3840 x 1440p60. Up to 1080p60 LVDS Tx (2x 4-lane or 1x 8-lane). 16 kByte of SRAM, but it is available for other SoC usage when not using for 2D blitter purposes. Best regards. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hi, and thanks for the quick reply. It seems that just enabling mipi_dsi in device tree leads to [ 2.426467] imx95-mipi-dsi 4acf0000.dsi: No valid input endpoint found [ 2.433017] imx95-mipi-dsi: probe of 4acf0000.dsi failed with error -22 so I was wondering is it possible to enable MIPI-DSI functionality and at the same time run LVDS in dual channel mode? mipi_dsi inputs are connected exactly as in device tree samples. What we have here is a custom LVDS panel that needs dual channel (lvds-0 and lvds-1) input and at the same time we want to have external display on MIPI-DSI. So LVDS panel would show desktop 1 and MIPI-DSI, via adv7535 converter, would show desktop 2. Or is it so that MX95 is only capable of one channel LVDS if MIPI-DSI is used at the same time? I've looked all the possible .dts samples in the kernel tree, read documentation and it is not clear to me is dual channel LVDS and MIPI-DSI possible at the same time. Re: MX95 on DT8MCustomBoard MIPI-DSI out Hello, You can use our EVK as reference: linux-imx/arch/arm64/boot/dts/freescale/imx95-19x19-evk-adv7535.dtso at dfaf2136deb2af2e60b994421281ba42f1c087e0 · nxp-imx/linux-imx Best regards.

MPX4115AP 端口 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> MPX4115 系列的数据表将MPX4115AP 列为"端口元件"。谁能帮我弄明白这意味着什么，端口的具体用途是什么。 Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 非常感谢您！ Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，梅加、 零件号中的字母 “A” 表示 “绝对”，因此施加在 P1 上的压力是根据密封在 P2 侧的真空参考测量的： 我们的压差传感器可通过部件编号中的字母 "D "来识别（例如MPX5100DP）和两个输入端口： 请仔细阅读这篇文章，以便更好地了解恩智浦压力传感器的压力测量和集成水平。 顺祝商祺！ 托马斯 Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，托马斯、 非常感谢你的答复。再澄清一点。与软管/导管连接的接口是否意味着传感器可以用作差分传感器？ Re: MPX4115AP port <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨，梅加、 移植版本（带有 AP、AS 或 ASX 后缀）允许通过软管/管道连接将压力连接到设备。 顺祝商祺！ 托马斯

从 STM32Cube IDE 到 MCUXpresso IDE 移植ST应用程序 本节概述了使用恩智浦目标MCU的兼容SDK将在STM32Cube IDE中开发的应用迁移到恩智浦MCUXpresso IDE的过程。 对于熟悉STM32Cube IDE的用户来说，保持类似的开发环境可以简化过渡并降低学习曲线。在本例中，最初为STM32设备开发的I2C应用将重新创建并适配恩智浦MCU。 要完成迁移，首先应在MCUXpresso IDE中创建包含必要I2C驱动程序的最小项目。原始ST应用使用两个I2C实例实现同一块开发板中元器件间的通信。要复制此功能，必须初始化两组I2C引脚。此外，该应用使用按钮输入和LED输出来演示行为变化，需要借助MCUXpresso引脚配置工具配置相应的GPIO。 要开始迁移，原ST项目的主源文件以及任何不属于标准ST驱动集的自定义源文件应被整合进新的NXP项目中。 以下步骤概述了MCUXpresso IDE中的初始项目设置： 选择“创建新的C/C++项目”。 选择目标MCU（例如，MCXA156）。 单击“下一步”。 展开驱动程序部分。 选择 I2C。 单击“下一步”。 单击“完成”。 项目创建时会包含一个基本的“Hello World”示例。此模板可用作起点。主源文件中的所有内容（除初始宏定义外）可以逐步替换以集成应用逻辑，从而实现模块化且受控的迁移过程。 下一步是将原始ST项目中的主源文件传输到新创建的MCUXpresso项目中。在此过程中，除非需要自定义头文件，否则将包含标准ST和驱动程序引用。此时不会使用自定义标头，因此仅迁移核心应用逻辑。 ST源文件中的许多函数调用都依赖于STM32特定的HAL API。请对这些功能进行审查，并使用恩智浦SDK中的同等功能进行替换。此方法包括分析main()例程中的每个函数以理解其目的，然后利用恩智浦环境中的相应实现进行替换。   ST项目功能快速概览： 中断优先级配置 配置微控制器的中断系统，以便在多个中断同时发生时管理优先级。 电源外设时钟实现 激活电源(PWR)外设的时钟，这是配置电源管理设置的前提条件。 电源管理设置 初始化STM32U5xx微控制器的电源管理功能，以优化内部元器件的能效和性能。 系统时钟配置 设置微控制器的定时系统，将其配置为以160MHz的频率运行。 外设初始化 确定外设的引脚配置和功能设置。在此应用中，I2C1会配置为从机，I2C3则配置为主机。 LED初始化 将LED配置为低电平有效状态，并开启LED以指示初始状态或通信反馈。 GPIO轮询按钮按下 持续监测GPIO输入引脚的状态。如果未按下按钮，LED将快速闪烁。按下按钮后，环路会退出，LED则保持点亮状态。 I2C通信启动 从主端发起I2C通信流程，触发两个I2C接口间的数据传输。 恩智浦SDK如何处理这一流程？ 中断优先级配置 此功能由CMSIS核心NVIC功能支持，且可直接重复使用。它需要定义宏来确定所需的抢占优先级。 时钟与电源配置 这些功能都会整合至BOARD_InitBootClocks函数（位于开发板文件夹的clock_config.c下）。此函数可初始化恩智浦MCU的系统时钟和电源设置。 外设和引脚初始化 外设设置分为两个函数： BOARD_InitBootPins（位于pin_mux.c中）负责处理I2C和GPIO的引脚配置。 BOARD_InitBootPeripherals（位于peripherals.c中）则负责管理I2C外设初始化和GPIO中断设置。 LED 初始化 GPIO 引脚可根据所需的初始状态配置为高电平或低电平输出。可以使用 GPIO_PinWrite 来切换或设置 LED。 GPIO轮询按钮按下 此行为可以借助自定义轮询函数来复制，该函数利用GPIO_PinRead监测按钮状态。 I2C通信开始 I2C主通信通过LPI2C_MasterStart启动，开始与指定从设备的数据传输过程。 使用时钟配置工具解决时钟初始化问题 MCUXpresso IDE包含集成的配置工具，可通过项目浏览器从界面右上角的下拉菜单中选择相应选项进行访问。 要配置系统时钟，请在 MCUXpresso IDE 中打开 Clocks 工具。 时钟图显示了所选 MCU 支持的配置。在此示例中，设备的最大核心时钟频率为 96 MHz。由于这符合应用程序的要求，因此不需要修改默认时钟设置。 要启用I2C实例的外设时钟，请在MCUXpresso配置工具中导航至时钟配置图。滚动浏览图表以定位可用的外设，并选择适当的时钟源来激活I2C模块。 要配置I2C0和I2C3外设的时钟源，请双击时钟配置图中与每个实例关联的CLKSEL字段。在此设置中，请选择FRO_HF_DIV作为I2C0和I2C3的时钟源。 接下来，在时钟配置图中选择相应的字段以配置时钟分频器。详细信息将显示在界面的右上角面板中。要启用通往I2C外设的时钟路径，请确保选择 “分频器时钟正在运行” 选项。 此时，I2C外设时钟已成功启用。 要应用配置更改并将其集成到项目中，请点击“更新代码”。此操作将生成相应的源文件，并确保新设置反映在项目结构中。 使用引脚配置工具解决引脚初始化问题 MCUXpresso IDE 包含集成的配置工具，可通过项目浏览器从界面右上角的下拉菜单中选择相应选项进行访问。 要开始配置I2C引脚，请从MCUXpresso IDE的配置工具菜单中选择“打开引脚”。 利用筛选功能，搜索与I2C实例0兼容的可用引脚。在查看开发板原理图后，选择P0_16和P0_17引脚，因为这两个引脚可以通过标头访问。在配置选项中选择LPI2C0:SDA和LPI2C0:SCL，为这些引脚分配相应的I2C功能。 重复I2C实例3的配置过程。根据开发板电路图，为此实例选择引脚P3_27和P3_28。在引脚配置工具中选择LPI2C3:SDA和LPI2C3:SCL来分配相应功能。 一旦选择了引脚，就会生成一个配置表，显示每个引脚的布线和设置。根据此表中的布线详情，按需配置引脚。对于I2C引脚，启用内部上拉电阻，以确保通信过程中信号的完整性。 除了配置I2C引脚外，还需要安装两个GPIO引脚——一个用于输入，一个则用于输出。在此开发板中， SW2 (P1_7)指定为按钮输入功能，而P3_0则指定为LED输出。 在引脚配置表的路由详情中，定义输入和输出GPIO的行为。根据应用需求，输出引脚应初始化为逻辑低电平状态（选择逻辑0）以激活LED。对于输入引脚，在下降沿启用中断检测以准确记录按钮按下操作。 要完成配置并将更改集成到您的项目中，请点击“更新代码”。此操作将生成必要的源文件，并将所选设置应用于项目结构。 使用外设配置工具解决外设初始化问题 MCUXpresso IDE包含集成的配置工具，可通过项目浏览器访问。要启动这些工具，请使用位于界面右上角的下拉菜单。 要开始外设配置，请在MCUXpresso IDE的配置工具菜单中选择 “打开外设” 。 在此视图中，重点是初始化每个实例的GPIO和I2C设置。要继续操作，请选择“外设驱动程序”以访问目标设备支持的驱动程序列表 GPIO1 配置 要筛选可用的外设选项，请在外设驱动程序视图的搜索栏中输入“GPIO”。显示相关选项后，点击“确定”以继续进行GPIO配置。 要启用分配给按钮输入的P1_7 的中断功能，首先要选择一个新的外设驱动程序。使用过滤器搜索GPIO，然后选择适当的驱动程序激活GPIO1 中断处理程序。 I2C3主机/主设备配置 要配置I2C外设，请在外设驱动程序视图的搜索栏中输入“I2C”来筛选可用选项。显示相关驱动程序后，为您的应用选择合适的驱动程序，然后点击“确定”以继续操作。 将I2C3配置为主设备（主机），并启用中断驱动的数据传输。此设置允许I2C3实例发起通信并通过中断机制处理数据传输，以提高响应速度和效率。 此外，启用 I2C3 外设的中断处理程序。配置相应的优先级并激活传输数据就绪标志，以支持中断驱动的数据传输。 I2C0从机/从设备配置 要配置I2C从机外设，请在外设驱动程序视图的搜索栏中输入“I2C”来筛选可用的驱动程序。显示相关驱动程序后，选择合适的驱动程序，然后点击“确定”以继续进行配置。 将I2C0配置为从设备（从机）。启用中断驱动的传输方式，并指定用于通信的从设备地址。此设置允许I2C0实例响应主设备请求，并通过中断处理数据接收。 此外，启用I2C0外设的中断处理程序。配置适当的优先级，验证分配的从机地址，并激活接收数据就绪标志，以支持中断驱动的数据接收。 要应用配置的设置并将其集成到项目中，请点击 “更新代码”。此操作将生成必要的源文件，并确保所有外设和引脚配置都反映在项目结构中。 配置工具生成的文件 MCUXpresso配置工具会根据所选设置自动生成源代码，从而简化与主应用的集成。生成的代码包括在前几个步骤中配置的时钟、引脚和外设的初始化例程。所有生成的文件都会放入项目结构的开发板目录下。 board.c 使用恩智浦开发板创建项目时，默认配置包括调试UART引脚的初始化以实现串行终端通信。在这种情况下，无需使用UART功能以及board.c中的对应函数。 clock_config.c 此文件包含所有系统时钟配置。使用BOARD_InitBootClocks函数来初始化时钟频率和电源模式设置。对于此应用，系统会配置为以96MHz的频率运行。 peripherals.c 此文件包含通过配置工具配置的外设初始化代码。在本例中，它包含I2C实例和GPIO中断的设置例程。虽然可以使用BOARD_InitPeripherals函数，但有选择性地将生成的代码集成到应用的特定位置，以匹配所需的执行顺序，往往更为有效。 pin_mux.c 该文件可定义为应用选择的所有引脚配置，包括I2C和GPIO分配。虽然默认情况下包含UART引脚，但本项目中并未使用这些引脚。使用BOARD_InitBootPins函数应用引脚设置。 此外，原始ST应用包含缓存初始化函数(MX_ICACHE_Init)。在恩智浦SDK中，缓存配置由启动代码处理。具体信息可通过设备文件夹下system_MCU.c中的SystemInit函数查看。 替换初始化函数 时钟和引脚初始化 在恩智浦项目的主函数中，系统时钟和引脚配置使用配置工具生成的函数进行初始化： BOARD_InitBootClocks BOARD_InitBootPins 外设初始化 外设初始化代码来源于peripherals.c文件（该文件由配置工具生成）。第一段代码可设置GPIO中断处理程序，包括其优先级和NVIC配置。 随后，对I2C主设备和从设备实例及其对应的中断处理程序和优先级进行初始化。在此阶段，中断标志尚未启用；它们将在数据传输函数内部稍后激活，以确保正确的执行顺序并避免过早触发中断。 peripherals.c文件中包含一个代码片段，专门用于初始化LPI2C0外设以进行从设备操作。这段代码可以选择性地集成到主函数或应用内的其他适当位置，以匹配所需的执行流程。 虽然MCUXpresso IDE中的配置工具能够有效生成必要的初始化代码，但开发人员仍应负责确定此代码在应用中最合适的位置。这一决策应依据所实现的特定协议或外设所需的操作顺序来指导。 例如，在I2C通信中，数据传输通过中断进行管理。如果在使用LPI2C0_Init函数时不考虑时序，中断可能会过早触发，导致事务不完整或管理不善。 为确保正确执行，建议的顺序如下： 初始化外设及其相关的中断处理程序。 启动I2C事务。 启用主设备和从设备操作的中断。 在此应用中，初始化在main()函数内执行，中断标志则在稍后的Handle_I2C_Master函数中选择性启用，以保持正确的时序和控制。 替换操作函数 SYSTICK初始化 SYSTICK定时器会配置为支持应用内的延迟操作，例如控制LED闪烁率。有关初始化SYSTICK的详细说明，请参阅以下小节。 按钮轮询和LED控制 此功能是通过一个自定义函数实现的，该函数会不断轮询按钮输入。在等待用户交互时，LED会切换以显示准备就绪。按下按钮后，LED保持稳定亮起，提示进入I2C数据传输阶段。 I2C主设备处理 Handle_I2C_Master函数通过恩智浦SDK中为I2C外设提供的驱动程序API实现。此函数可启动I2C事务并管理通信序列。 主设备和从设备I2C实例的中断处理程序均来自外设初始化代码。在此阶段，相关中断标志会选择性启用，以支持应用所需的具体行为。 WaitForUserButtonPress函数 要开始自定义GPIO中断处理程序，请在MCUXpresso IDE中打开外设配置工具。然后，你可以复制GPIO自动生成的IRQ处理程序，作为可靠的起点。然后可以修改此代码以满足您应用程序的特定要求。 配置完外设后，点击位于 MCUXpresso IDE 右上角的 “开发” 按钮，返回代码编辑器。在开发环境中，将复制的 IRQ 处理程序代码粘贴到主源文件中——最好放在顶部——以便更容易访问和组织。 已进行修改，在while循环中加入控制变量，确保此应用能够暂停执行，直至检测到按钮按下。此操作可确保程序仅在用户交互后才能继续进行，以匹配应用的预期流程。 WaitForUserButtonPress 函数利用 GPIO 切换和写入操作来控制 LED 状态，并通过延迟机制管理轮询循环期间的闪烁间隔。为了实现延迟，SYSTICK 定时器被初始化并进行相应配置。 此外，引入了一个全局计数器变量，以及相应的SYSTICK中断处理程序，以支持应用程序内的基于时间的操作。 在main()函数中，SYSTICK定时器初始化应在按钮轮询逻辑之前添加。此操作可确保在进入等待用户输入的循环之前，延迟机制已完全运行。 最终版的 WaitForUserButtonPress 函数将包含： GPIO操作可切换和控制LED状态。 持续检查按钮状态的while循环，只有在检测到按键事件时才会继续执行。 GPIO_* API是恩智浦GPIO驱动程序库的一部分，用于执行初始化、引脚控制和中断处理等各种操作。代码中高亮显示的宏（通常在IDE中以粉红色显示）由配置工具生成，并在pin_mux.h头文件。 应用中使用的延迟功能通过基于SYSTICK的自定义函数实现，如前所述。 要了解所有可用的GPIO API，请参阅fsl_gpio.h头文件。此文件为GPIO操作提供全面支持，包括端口和引脚级控制、配置以及中断管理。 自定义I2C中断处理程序 要以类似 GPIO 处理程序的方式定制 I2C 中断处理程序，首先要在 MCUXpresso IDE 中打开外设配置工具。从中找到并复制自动生成的I2C0 IRQ 处理程序。这是一个基础模板，可根据应用的具体要求进行修改。 要返回代码编辑器，请点击位于MCUXpresso IDE右上角的“开发”按钮。进入开发环境后，将复制的I2C中断处理程序代码粘贴到主源文件中（最好放在顶部），以便整理和访问。 复制外设配置工具中自动生成的中断处理程序，对I2C3重复同样的过程。然后，此处理程序可用作定制基础，类似于I2C0采用的方法。 整合I2C中断处理程序 在原始ST项目中，每个I2C实例都使用两个独立的中断处理程序：一个用于执行标准操作，另一个则用于处理错误。然而，此次迁移中使用的恩智浦MCU会为每个I2C实例提供单一中断向量，用于处理标准和错误状态。 因此，必须将原始的四个处理程序功能合并为两个，每个I2C实例各分配一个功能。此操作需要仔细审查原始中断逻辑，以确保所有相关标志和行为在合并实现中得以保留。 例如，原始项目中的从设备处理程序可检查地址匹配标志，并在检测到标志后验证就绪度以接收数据。在恩智浦环境中，等效行为通过监测统一中断处理程序内的相应状态标志来实现，以确保正确处理地址识别和数据接收。 从设备处理程序 当主设备以0x7E寻址从设备时，就会触发I2C从设备中断处理程序。检测到此地址匹配后，从设备会确认请求并准备接收传入数据。 处理程序的第二部分负责管理数据接收过程。它能处理主设备传输的每个字节，监测NACK（未确认）状态以指示传输结束，并将接收的数据存储到指定的缓冲区。此操作可确保从设备正确处理通信序列，并在所有数据接收完毕后轻松终止传输。 主设备处理程序 I2C主设备中断处理程序可监测主设备传输就绪标志，此标志用于指示外设已准备就绪，可传输下一个字节的数据。检测到此条件后，处理程序会检查传输缓冲区，以确定是否还有其他数据需要发送。计数器用于跟踪传输进度。 处理程序会使用适当的主设备发送操作，发送下一个字节并推进缓冲区指针。当最后一个字节发送后，处理程序会发出终止条件，以指示数据传输序列完成。 Handle_I2C_Master 函数 Handle_I2C_Master函数负责启动和管理I2C通信过程。它首先发出MasterStart命令，以启动与指定地址从设备的通信。从设备成功确认后，数据传输将通过相应的中断例程进行处理。 此函数还会初始化主设备和从设备I2C实例的中断处理程序。如前所述，必须在主设备发起通信后启用中断，以防止过早触发中断，从而干扰事务序列。 数据传输完成且从设备接收到所有预期的字节后，此函数会将LED设为稳定状态：表示执行成功，应用流程结束。 结束语 使用MCUXpresso IDE将应用从STM32开发环境迁移到恩智浦MCX平台，需要采用条理清晰的结构化方案。借助集成的配置工具并理解STM32与恩智浦SDK元器件间的功能等效性，开发人员可以在维持性能和功能的同时有效过渡其应用。 本指南概述了复制I2C应用的关键步骤，包括项目设置、外设配置、引脚和时钟初始化以及中断处理。虽然这些工具通过自动生成代码提供了坚实的基础，但必须谨慎考虑初始化和运行时逻辑的序列和集成，以确保稳定运行。 通过清晰理解两种环境并审慎调整应用逻辑，开发人员可以简化迁移流程，同时充分利用恩智浦MCX平台所提供的功能。

PN7160 PN7220 Android 15のi.MX8MN EVKへの移植 はじめに 当社では、PN7160/PN7220 Android 15公式ポーティングガイド（PN7160/PN7220 – Android 15ポーティングガイド）をご用意しております。ただし、パッチはAndroid 15 AOSP r1（android-15.0.0_r1）専用です。AOSP最新版へのポーティングを希望する場合、ソースコードのコンパイル中でエラーが頻発します。このドキュメントを参考に、エラーを一つずつ解決してください。 注：変更はすべて参考目的で提供されており、AOSP最新版へのポーティング向けのNXP公式パッチではありません。変更が最善の解決策ではない可能性がありますので、AOSPソースコードを自社のニーズに基づいて変更してください。これは製品向けではありません。ポーティング後は、お客様側で引き続き完全なテストを実施する必要があります。 ハードウェアボード： i.MX8MN EVK (i.MX 8M Nano評価キット | NXP Semiconductors) PN7160 EVK （OM27160｜PN7160 プラグアンドプレイ NFC コントローラ用開発キット｜NXP Semiconductors） i.MX8MN EVKとPN7160 OM29110ARD-Bの接続 i.MX8M ナノ EVK ピン PN7160 ピン 3.3V J1003-1 VDD（3.3V） J1-4 5V J1003-2 VBAT（5V） J1-5 I2C3 SDA J1003-3 SDA J2-2 I2C3 SCL J1003-5 SCL J2-1 GPIO3_22 J1003-37 IRQ J2-10 GPIO3_21 J1003-38 REQ J4-2 GND J1003-39 GND J1-6 GPIO3_20 J1003-40 N/A J4-1 i.MX8MN EVK向けAndroidの構築 ここで使用したi.MX Android BSPはAndroid 15.0.0_2.0.0(L6.12.20_2.0.0 BSP)で、こちらからダウンロードしていただけます：i.MX アプリケーション・プロセッサ向けAndroid OS | NXP Semiconductors 1. 「ドキュメント」と「インストールソースパッケージ」をダウンロードします。 2. まず、Androidユーザーガイドの手順に従って、i.MX8MN EVK用のAndroid BSPをビルドします。  android_build/.repo/manifests/aosp-android-15.0.0_2.0.0.xmlによると、表示されるAOSPバージョンはandroid-15.0.0_r32です。 ポーティングに関する参考文献： PN7160/PN7220 – Android 15 移植ガイド  i.MX8M NanoボードでPN7160をAndroid 14に移植 さて、移植を始めましょう。  1. カーネル・ドライバ PN7220またはPN7160との接続を確立するために、Androidスタックはnxpnfcカーネルドライバを使用します。以下のGitHubからドライバをダウンロードできます: br_ar_16_comm_infra_dev · nxp-nfc-infra/nfcandroid_platform_d... の br_ar_16_comm_infra_dev の nfcandroid_platform_drivers/drivers コマンドは次のとおりです。 git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_drivers.git" -b br_ar_16_comm_infra_dev カーネル6.6および6.12用のドライバがありますので、ポーティングに適したドライバをダウンロードしてください。例えば、i.MX Android BSP Android 15.0.0_2.0.0のカーネルは6.12ですので、ポーティングには6.12ドライバを使用します。 ポーティングする際は、MakefileとKconfigファイルのパスが正しく設定されていることを確認してください。 例えば、ここでは以下のようにポーティングします。 . ├── Kconfig ├── Makefile └── pn7160 ├── common.c ├── common.h ├── i2c_drv.c ├── i2c_drv.h ├── Kbuild ├── Kconfig ├── Makefile ├── spi_drv.c └── spi_drv.h すべてを簡素化するため、I2Cのみをサポートし、SPIはサポートしません。ドライバ/nfc/pn7160/Makefile のデフォルトコードを以下のコードに置き換えてください（理解しやすくするため）。 nxpnfc-i2c-objs = i2c_drv.o common.o obj-$(CONFIG_NXP_NFC_I2C) += nxpnfc_i2c.o ドライバ/nfc/Kconfig の内容。PN7160を以下のように追加してください。 source "drivers/nfc/pn7160/Kconfig" source "drivers/nfc/fdp/Kconfig" source "drivers/nfc/pn544/Kconfig" source "drivers/nfc/pn533/Kconfig" source "drivers/nfc/microread/Kconfig" source "drivers/nfc/nfcmrvl/Kconfig" source "drivers/nfc/st21nfca/Kconfig" source "drivers/nfc/st-nci/Kconfig" source "drivers/nfc/nxp-nci/Kconfig" source "drivers/nfc/s3fwrn5/Kconfig" source "drivers/nfc/st95hf/Kconfig" endmenu The contents of ドライバ/nfc/Makefile. Add the PN7160 like below: # SPDX-License-Identifier: GPL-2.0 # # Makefile for nfc devices # obj-$(CONFIG_NXP_NFC_I2C) += pn7160/ obj-$(CONFIG_NFC_FDP) += fdp/ obj-$(CONFIG_NFC_PN544) += pn544/ obj-$(CONFIG_NFC_MICROREAD) += microread/ obj-$(CONFIG_NFC_PN533) += pn533/ obj-$(CONFIG_NFC_MEI_PHY) += mei_phy.o obj-$(CONFIG_NFC_SIM) += nfcsim.o obj-$(CONFIG_NFC_PORT100) += port100.o obj-$(CONFIG_NFC_MRVL) += nfcmrvl/ obj-$(CONFIG_NFC_TRF7970A) += trf7970a.o obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/ obj-$(CONFIG_NFC_ST_NCI) += st-nci/ obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci/ obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5/ obj-$(CONFIG_NFC_ST95HF) += st95hf/ obj-$(CONFIG_NFC_VIRTUAL_NCI) += virtual_ncidev.o 2. i.MX8MN EVKデバイスツリーファイルに「nxpnfc」を追加します。 &i2c3 { clock-frequency = <100000>; pinctrl-names = "default", "gpio"; pinctrl-0 = <&pinctrl_i2c3>; pinctrl-1 = <&pinctrl_i2c3_gpio>; scl-gpios = <&gpio5 18 GPIO_ACTIVE_HIGH>; sda-gpios = <&gpio5 19 GPIO_ACTIVE_HIGH>; status = "okay"; nxpnfc@28{ compatible = "nxp,nxpnfc"; reg = <0x28>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_nfc>; nxp,nxpnfc-irq = <&gpio3 22 0>; nxp,nxpnfc-ven = <&gpio3 20 0>; nxp,nxpnfc-fw-dwnld = <&gpio3 21 0>; }; The GPIO settings in the IOMUXC: &iomuxc { pinctrl_nfc: nfcgrp { fsl,pins = < MX8MN_IOMUXC_SAI5_RXC_GPIO3_IO20 0X19 // VEN MX8MN_IOMUXC_SAI5_RXD0_GPIO3_IO21 0X19 // FW-DWNLD MX8MN_IOMUXC_SAI5_RXD1_GPIO3_IO22 0X19 // IRQ >; }; 3.  imx8mn_gki.fragmentを変更します。 ファイル:android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/imx8mn_gki.fragment "CONFIG_NXP_NFC_I2C=m" を  imx8mn_gki.fragment に追加します。 4. Androidの対応するボード設定ファイルに設定を追加してください。 - android_build/device/nxp/imx8m/evk_8mn/ に移動してください  BoardConfig.mkを修正します。 # selinux permissive + BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive BOARD_SEPOLICY_DIRS := \ $(CONFIG_REPO_PATH)/imx8m/sepolicy \ $(IMX_DEVICE_PATH)/sepolicy \ + vendor/nxp/nfc/sepolicy \ + vendor/nxp/nfc/sepolicy/nfc + include vendor/nxp/nfc/BoardConfigNfc.mk - ShareBoardConfig.mkに”nxpnfc_i2c.ko”を追加します。パスとファイル名が正しいか確認します。 $(KERNEL_OUT)/drivers/net/phy/realtek.ko \ $(KERNEL_OUT)/drivers/pps/pps_core.ko \ $(KERNEL_OUT)/drivers/ptp/ptp.ko \ $(KERNEL_OUT)/drivers/net/ethernet/freescale/fec.ko + $(KERNEL_OUT)/drivers/nfc/pn7160/nxpnfc_i2c.ko endif $(KERNEL_OUT)/drivers/trusty/trusty-core.ko \ $(KERNEL_OUT)/drivers/trusty/trusty-log.ko \ $(KERNEL_OUT)/drivers/trusty/trusty-ipc.ko \ $(KERNEL_OUT)/drivers/trusty/trusty-virtio.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7160/nxpnfc_i2c.ko else BOARD_VENDOR_RAMDISK_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/input/touchscreen/goodix_ts.ko \ $(KERNEL_OUT)/drivers/input/touchscreen/synaptics_dsx/synaptics_dsx_i2c.ko Endif - Compatibility_matrix.xmlに以下を追加します netutils-wrapper 1.0 android.hardware.emvco 1 IEmvco default -  device_framework_matrix.xmlに以下を追加します。 nxp.hardware.secureime 1 ISecureIME default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default vendor.nxp.nxpnfc 2.0 INxpNfc default android.hardware.emvco 1 IEmvco default - evk_8mn.mkに以下を追加します。 # ------nfc------- $(call inherit-product, vendor/nxp/nfc/device-nfc.mk) $(call inherit-product, vendor/nxp/emvco/device-emvco.mk) PRODUCT_PACKAGES += \ android.hardware.nfc-service.nxp PRODUCT_PACKAGES += \ com.nxp.emvco \ com.nxp.nfc \ nfc_nci_nxp_pn72xx - init.rcにnxpnfc_i2cを追加します。 # Grant permission for fetching available_pages info of statsd chown system system /proc/pagetypeinfo chmod 0440 /proc/pagetypeinfo exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \ /vendor/lib/modules nxpnfc_i2c write /sys/power/wake_lock nosleep on post-fs-data && property:vendor.skip.charger_not_need=0 setprop vold.post_fs_data_done 1 - ueventd.nxp.rc に nxpnfc を追加します。 /sys/devices/virtual/thermal/thermal_zone* trip_point_0_hyst 0660 system system /sys/devices/virtual/thermal/thermal_zone* trip_point_1_hyst 0660 system system /dev/dmabuf_imx 0664 system system /sys/class/backlight/* brightness 0660 system system /dev/ttymxc1 0666 nfc nfc /dev/ttymxc2 0666 nfc nfc /dev/nxpnfc 0666 nfc nfc # for libcamera /dev/media* 0660 system camera /dev/v4l-subdev* 0660 system camera 5. NXP AOSPパッチの適用 NXP公式のNFCパッチはAOSP android-15.0.0_r1のみで、 android-15.0.0_r1と android-15.0.0_r32では大きな違いがあります。このため、パッチを適用する前に、Android-15.0.0_r1からNFCフォルダをコピーして、Android-15.0.0_r32のNFCフォルダを置き換えます。 まず、GitHubからAOSP android-15.0.0_r1をダウンロードしてください。 $ mkdir android-15.0.0_r1 $ cd android-15.0.0_r1 $ repo init -u https://android.googlesource.com/platform/manifest -b android-15.0.0_r1 $ repo sync 次に、以下のフォルダをandroid-15.0.0_r32から削除します。そして、Android-15.0.0_r1から次のNFCフォルダをコピーして、Android-15.0.0_r32の同じフォルダを置き換えます。 パッケージ/apps/Nfc frameworks/base/nfc frameworks/base/nfc-extras システム/NFC 以下にその例をご紹介します。 $ rm -rf android_build/packages/apps/Nfc $ cp -ra android-15.0.0_r1/packages/apps/Nfc android_build/packages/apps/ 私はGitHubからパッチをダウンロードするスクリプトを作成します。お客様は以下のスクリプトを、android_buildと同じディレクトリに配置できます。 AOSP_adaptation.sh # nxp_nci_hal_nfc git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_nfc.git" cd nxp_nci_hal_nfc git checkout br_ar_15_comm_infra_dev cp -rf * ../android_build/packages/apps/Nfc/ cd .. # nxp_nci_hal_libnfc-nci git clone "https://github.com/nxp-nfc-infra/nxp_nci_hal_libnfc-nci.git" cd nxp_nci_hal_libnfc-nci git checkout br_ar_15_comm_infra_dev cp -rf * ../android_build/system/nfc/ cd .. # nfcandroid_nfc_hidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_nfc_hidlimpl.git" cd nfcandroid_nfc_hidlimpl git checkout br_ar_15_comm_infra_dev cp -rf * ../android_build/hardware/nxp/nfc cd .. # nfcandroid_frameworks git clone "https://github.com/nxp-nfc-infra/nfcandroid_frameworks.git" cd nfcandroid_frameworks git checkout br_ar_15_comm_infra_dev mkdir ../android_build/vendor/nxp/frameworks cp -rf * ../android_build/vendor/nxp/frameworks cd .. # nfcandroid_emvco_aidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_emvco_aidlimpl.git" cd nfcandroid_emvco_aidlimpl git checkout br_ar_15_comm_infra_dev mkdir ../android_build/hardware/nxp/emvco cp -rf * ../android_build/hardware/nxp/emvco cd .. # nfcandroid_platform_reference git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_reference.git" cd nfcandroid_platform_reference git checkout br_ar_15_comm_infra_dev cp -rf vendor/nxp/* ../android_build/vendor/nxp/ cd .. # nfcandroid_infra_test_apps git clone https://github.com/nxp-nfc-infra/nfcandroid_infra_test_apps.git cd nfcandroid_infra_test_apps/ git checkout br_ar_15_comm_infra_dev cd test_apps/ cp -rf SMCU_Switch/ ../../android_build/packages/apps/ cp -rf EMVCoModeSwitchApp/ ../../android_build/packages/apps/Nfc/ cp -rf load_unload/ ../../android_build/hardware/nxp/nfc/ cp -rf SelfTestAidl/ ../../android_build/hardware/nxp/nfc/ cd ../.. # nfcandroid_infra_comm_libs git clone "https://github.com/nxp-nfc-infra/nfcandroid_infra_comm_libs.git" cd nfcandroid_infra_comm_libs git checkout br_ar_15_comm_infra_dev cp -rf nfc_tda/ ../android_build/system/ cp -rf emvco_tda/ emvco_tda_test/ ../android_build/hardware/nxp/emvco/ cp -rf NfcTdaTestApp/ ../android_build/packages/apps/Nfc/ cd .. Apply_patches.sh cd android_build/build/bazel/ patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_bazel.patch cd ../release patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_build_release.patch cd ../../external/libchrome patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_external_libchrome.patch cd ../../frameworks/base patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_frameworks_base.patch cd ../../system/logging patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_system_logging.patch このため、 AOSP_adaptation.shを実行し、その後、 Apply_patches.shを実行します。 6. hardware/interfaces/compatibility_matrices に変更を加えます Androidのバージョンごとに互換性マトリックスが異なります。 ファイル: android_build/hardware/interfaces/compatibility_matrices/compatibility_matrix.202404.xml android.hardware.audio.effect 1-2 IFactory default + + nxp.hardware.imx_dek_extractor + 1 + + IDek_Extractor + default + + + + vendor.nxp.nxpnfc + 2.0 + + INxpNfc + default + + + + vendor.nxp.emvco + 1 + + INxpEmvco + default + + android.hardware.audio.sounddose 1-3 7. デバイス固有の .mk を変更 pn7160の場合、 NXP_NFC_HWはpn7160と等しくなる必要があります。 pn7220の場合、 NXP_NFC_HWはpn7220_i2csと等しくなる必要があります。 File : android_build/vendor/nxp/nfc/device-nfc.mk ##### ##### NXP NFC Device Configuration makefile ###### NXP_NFC_HOST := $(TARGET_PRODUCT) ifndef TARGET_NXP_NFC_HW NXP_NFC_HW := pn7160 else NXP_NFC_HW := $(TARGET_NXP_NFC_HW) endif NXP_NFC_PLATFORM := pn54x NXP_VENDOR_DIR := nxp NXP_I2CM_S := $(TARGET_NXP_I2C_M_S) ファイル: android_build/vendor/nxp/emvco/device-emvco.mk NXP_VENDOR_DIR := nxp NXP_NFC_HW := $(TARGET_NXP_NFC_HW) ifeq ($(strip $(TARGET_NXP_NFC_HW)),) NXP_NFC_HW := pn7160 endif # Nfc service has dependency with EMVCo JAR PRODUCT_PACKAGES += \ com.nxp.emvco 8. これで、Android BSPの構築を始めることができます。 i.MX8MN EVKの場合、  $ source build/envsetup.sh $ lunch evk_8mn-nxp_stable-userdebug $ export TARGET_RELEASE=nxp_stable $ build_build_var_cache $ ./imx-make.sh -j4 2>&1 | tee build-log.txt BSPをビルディングする際には、ビルド中に多くのエラーが発生します。以下にいくつかの誤りと参考解決策を挙げておきます。  エラー リファレンス・ソリューション nfc_aconifg_flagsについて苦情を申し上げます。 packages/apps/Nfc/flags/Android.bp aconfig_declarations { // name: "nfc_aconfig_flags", name: "com.android.nfc.flags-aconfig", package: "com.android.nfc.flags", container: "system", srcs: ["nfc_flags.aconfig"], } java_aconfig_library { // name: "nfc_aconfig_flags_lib", // aconfig_declarations: "nfc_aconfig_flags", name: "com.android.nfc.flags-aconfig-java", aconfig_declarations: "com.android.nfc.flags-aconfig", min_sdk_version: "33", apex_available: [ "//apex_available:platform", "com.android.nfcservices", ], } java_library { name: "nfc_flags_lib", sdk_version: "system_current", min_sdk_version: "33", srcs: [ "lib/**/*.java", ], static_libs: [ "com.android.nfc.flags-aconfig-java", ],  android.hardware.nfc-V2-ndk に関して苦情を伝える ファイル: hardware/interfaces/nfc/aidl/vts/functional/Android.bp android.hardware.nfc-V2-ndk を変更しますandroid.hardware.nfc-V1-ndkへ platform_testing/build/tasks/tests/native_test_list.mk: error: continuous_native_tests：モジュール 'libnfc-nci-jni-tests' のインストールされたファイルが不明です。 'libnfc-nci-jni-tests' を削除します。  native_test_list.mk error: パッケージ/apps/Nfc/tests/instrumentation/Android.bp:6:1:モジュール「NfcNciInstrumentationTests」バリアント「Android_common」は、java_sdk_library「android.test.runner」に直接依存することはできません。「android.test.runner.stubs」に頼ってみて、「android.test.runner.stubs.system」「android.test.runner.stubs.test」または「android.test.runner.impl」その代わり ヒントはエラーメッセージに記載されています。 "android.test.runner" を  "android.test.runner.stubs"、"android.test.runner.stubs.system""android.test.runner.stubs.test"または"android.test.runner.impl"に変更します。 エラー: vendor/nxp/frameworks/nfc/Android.bp:12:1:モジュール "com.nxp.nfc"バリアント"android_common"は、このモジュールから見えない //frameworks/base/nfc:framework-nfc.impl に依存しています。 "//vendor/nxp/frameworks/nfc"を可視性に追加する必要があるかもしれません。 ファイル: frameworks/base/nfc/Android.bp permitted_packages: [ "android.nfc", "com.android.nfc", ], impl_library_visibility: [ "//frameworks/base:__subpackages__", "//cts/hostsidetests/multidevices/nfc:__subpackages__", "//cts/tests/tests/nfc", "//vendor:__subpackages__", "//packages/apps/Nfc:__subpackages__", ], packages/apps/Nfc/nci/src/com/android/nfc/dhimpl/NativeT4tNfceeManager.java:20: エラー:重複クラス:com.android.nfc.dhimpl.nativet4tnfceemanager ファイルを編集してください。 パッケージ/apps/Nfc/nci/src/com/Android/nfc/dhimpl/NativeT4tNfceeManager.java そして重複したクラスをコメントアウトします。 android/R.java:12483:エラー: フィールド FLAG_NFC_ASSOCIATED_ROLE_SERVICES を解決できません     @android.注釈。FlaggedApi(android.nfc.Flags.FLAG_NFC_ASSOCIATED_ROLE_SERVICES) 編集 frameworks/base/nfc/java/android/nfc/flags.aconfig 下のフラグを追加してください。 flag { name: "nfc_associated_role_services" is_exported: true namespace: "nfc" description: "Share wallet role routing priority with associated services" bug: "366243361" } 失敗： platform_testing/build/tasks/tests/native_test_list.mk: エラー: continuous_native_tests: モジュール 'libnfc-nci-tests'のインストールされたファイルが不明です。  native_test_list.mkのlibnfc-nci-testを削除します。 prebuilts/clang/host/linux-x86/clang-r536225/include/c++/v1/string:780:43: error: implicit instantiation of undefined template 'std::char_traits '   780 |   static_assert((is_same<_CharT, typename traits_type::char_type>::value)、       |                                           ^ packages/apps/Nfc/nci/jni/NativeNfcTda.cpp:32:35: note: ここで要求されるテンプレートクラス「std::basic_string 」のインスタンス化    32 | 静的 std::basic_string sRxTdaDataBuff;       |                                   ^ パッケージ/アプリ/Nfc/nci/jni/NativeNfcTda.cppを編集してください using android::base::StringPrintf; extern bool nfc_debug_enabled; SyncEvent sCtLibSyncEvt; //static std::basic_string sRxTdaDataBuff; static std::basic_string sRxTdaDataBuff; packages/apps/Nfc/nci/jni/NativeT4tNfcee.cpp:493:21: エラー: 'append'への呼び出しに一致するメンバー関数がありません。  493 |      sRxDataBuffer.append(data.p_data,data.len);       |       ~~~~~~~~~~~~~~^~~~~~ パッケージ/アプリ/Nfc/nci/jni/NativeT4tNfcee.cppを編集してください void NativeT4tNfcee::t4tReadComplete(tNFA_STATUS status, tNFA_RX_DATA data) { mT4tOpStatus = status; if (status == NFA_STATUS_OK) { if (data.len > 0) { sRxDataBuffer.insert(sRxDataBuffer.end(), data.p_data, data.p_data + data.len); LOG(DEBUG) << StringPrintf("%s: Read Data len new: %d ", __func__, data.len); } } SyncEventGuard g(mT4tNfcEeRWCEvent); mT4tNfcEeRWCEvent.notifyOne(); } frameworks/base/core/java/android/provider/Settings.java:2351: エラー: フィールド FLAG_NFC_ACTION_MANAGE_SERVICES_SETTINGS を解決できませんでした @FlaggedApi(android.nfc.Flags.FLAG_NFC_ACTION_MANAGE_SERVICES_SETTINGS) ファイル: frameworks/base/nfc/java/android/nfc/flags.aconfig flags.aconfig に以下を追加します flag { name: "nfc_action_manage_services_settings" is_exported: true namespace: "nfc" description: "Add Settings.ACTION_MANAGE_OTHER_NFC_SERVICES_SETTINGS" bug: "358129872" } エラーメッセージには、エラーを修正するためのヒントがいくつか含まれているため、表に記載されていないエラーもあります。お客様はヒントに従い、ニーズに応じてソースコードを変更することができます。 時々、お客様はr1とr32のソースコードを比較できます。こちらは AOSP ソースコード android-15.0.0_r32 と android-15.0.0_r1です。 9. 画像をi.MX8MN EVKボードにダウンロードします - 8MN EVKボード上でダウンロードモードに切り替えます - まず、Android BSP WebページからAndroid 15 BSP i.MX8MN EVKデモイメージをダウンロードします。UUUスクリプトと必要なイメージファイルはすでにデモイメージパッケージに入っているためです。  - ここから UUU をダウンロードします： リリース · nxp-imx/mfgtools - UUU実行ファイルをデモイメージフォルダに配置します。 uuu_imx_android_flash.batが同じフォルダに配置されているスクリプトです。 - ビルドに成功した後、画像をデモイメージのフォルダにコピーします。画像は、android_build/out/target/product/evk_8mn/ に位置しています - UUUスクリプトを実行して、画像をEVKボードにダウンロードします。 参考情報： Yocto Linux + PN7160を実行しているi.MX6ULL EVK i.MX8M NanoボードでPN7160をAndroid 14に移植 i.MXアプリケーション・プロセッサ用Android OS | NXP Semiconductors PN7160/PN7220 – Android 15 移植ガイド プラグ・アンド・プレイNFCフロントエンド、統合ファームウェア搭載 | NXP Semiconductors

将 EdgeLock® SE05X 集成到 MIMXRT1180-EVK 本文档内容免责声明： NXP 提供的任何支持、信息和技术（“材料”）均按“现状”提供，不附带任何明示或暗示的保证，且 NXP 在适用法律允许的最大范围内，否认与材料相关的所有直接或间接责任和损害。NXP 对任何与应用或产品设计相关的协助不承担任何责任。材料仅可用于与 NXP 产品相关联。NXP 可以不受限制地使用您对材料提供的任何反馈。 摘要 本文档旨在指导开发人员在 NXP MIMXRT1180EVK 开发板上集成 EdgeLock® SE050 安全芯片，以实现硬件级别的安全增强。安全元件可以轻松连接到任何系统，要求极低——只需电源和两个 I2C 引脚。此外，由于主机软件支持 Plug&Trust 中间件，因此集成起来非常容易。 硬件先决条件 主机平台：MIMXRT1180EVK 扩展板： OM-SE050X 硬件设置 1. 按如下方式配置 OM-SE05xARD 跳线[1]： 2. 将 MIMXRT1180-EVK 上的跳线配置为默认[2]： 3.将 OM-SE05xARD 安装到 MIMXRT1180-EVK 上 软件集成 有两种方法将 OM-SE05xARD 集成到 MIMXRT1180-EVK：一种基于 SDK，另一种基于 Zephyr。用户可以根据自己的需求选择其中任一。 SDK集成： 平台文件生成。 nano 软件包为在任意 MCU 平台上集成 MW 提供了非常简便的方式。用户只需在 simw-nanopkg/lib/platform 文件夹中添加或修改对应平台的特定文件即可。 应用随附的补丁后，您即可轻松实现上述配置。 导入I2C演示项目作为起点 我们建议以 SDK 的 I2C 演示项目为集成起点，因为该项目已包含 SDK 所需的 I2C 驱动代码。以 RT1180 为例，我们导入：evkmimxrt1180_lpi2c_polling_b2b_master_cm33。 然后排除板级文件，并改用 nano 软件包中的对应文件。 接着导入 nano 软件包中的源文件， 并加入示例代码，这里选择：ex_se05x_crypto.c和 main.c。 添加如下定义用于 nano 软件包构建，以及包含路径。 正在构建项目： 调试： Zephyr 集成： 集成比 SDK 集成简单得多，因为平台特定文件已经存在，用户只需手动添加 MIMXRT1180-EVK 的板覆盖文件。附加的覆盖文件应放在类似于“workspace/modules/crypto/nxp-plugandtrust/examples/se05x_crypto/zephyr/boards/”的文件夹中。 请注意:Zephyr 集成指南已在 https://github.com/NXPPlugNTrust/nano-package/blob/master/zephyr/readme.rst 上发布，而测试的 Zephyr 版本仍停留在 v3.7.0，尚未支持 MIMXRT1180-EVK。为了支持 MIMXRT1180-EVK，我们必须使用最新的 Zephyr，并修改过 west.yml 文件。 以下是我们需要执行的步骤： $ rm workspace/ -rf $ mkdir -p workspace $ cd workspace/ $ git clone https://github.com/NXPPlugNTrust/nano-package.git //Edit ~/workspace/nano-package/zephyr/west.yml as below $ cd .. $ west init -m https://github.com/NXPPlugNTrust/nano-package.git --mf ~/workspace/nano-package/zephyr/west.yml ~/workspace/ $ cd workspace $ west update 版本示例： $ cd workspace/ $ west build -b mimxrt1180_evk/mimxrt1189/cm33 modules/crypto/nxp-plugandtrust/examples/se05x_crypto/zephyr/ --pristine 编程和运行：   参考资料： [1]基于树莓派的 EdgeLock SE05x 快速入门指南 [2]i.MX RT1180 EVK 快速入门指南

i.mx93 上の m33 コアに対する OpenAMP サポート おい、 この質問は既にここで聞かれていると思います 解決済み: Re: i.mx93 上の m33 コアに対する RPMsg サポート - NXP コミュニティ しかし、私は受け入れられた答えを理解していません。NXP のリアルタイム エッジ ソフトウェア フレームワークでは、RPSMG サポートは FreeRTOS に対してのみリストされています。 ただし、i.mx95 A7 コアは最近すでに追加されていますhttps://github.com/zephyrproject-rtos/zephyr/pull/86923 私の質問は、NXP が m33 のサポートも追加する予定があるかどうかです。そうでない場合、手動でサポートを追加するには何が必要ですか? Re: OpenAMP support for m33 core on i.mx93 Linux (A コアで実行) と Zephyr (M33 コアで実行) 間のコア間通信を有効にするには、Zephyr のopenamp_rsc_tableサンプルを出発点とすることをお勧めします。 このサンプルでは以下を活用しています: - Zephyr 上の OpenAMP - Linux上のremoteprocとrpmsg 前提条件 Linuxのセットアップ Linux BSP: NXP の公式 BSP を使用しますhttps://github.com/nxp-imx/linux-imx/tree/lf-6.12.y デバイスツリー: `-rpmsg` バリアントを使用します。例:imx93-11x11-evk-rpmsg.dts U-Boot: Linux を起動する前に `prepare_mcore` を実行する Zephyr セットアップ(M33 コア) openamp_rsc_table サンプルを正常に実行するには、DTS オーバーレイの `zephyr,ipc_shm` プロパティを使用して、ホスト コアとリモート コア間の共有メモリを定義する必要があります。 次に、 nxp_imx93_m33.dtsiに MU ノードを追加します。 「」 mu1: mu1@44220000 { 互換性 = "nxp、imx-mu"; reg = <0x44220000 DT_SIZE_K(64)>; 割り込み = <21 0>; }; 「」 次に、リンカー スクリプトを更新し、`linker.ld` にリソース テーブル セクションを追加します。 「」 #定義されている場合(CONFIG_OPENAMP_RSC_TABLE) セクション { SECTION_PROLOGUE(.resource_table,,サブアライン(8)) { KEEP(*(.resource_table*)) } GROUP_LINK_IN(ROMABLE_REGION) } #endif 「」 i.MX93の設定調整 i.MX93 の RX および TX ID は他のボードとは異なります。`.conf` オーバーレイ ファイル内のデフォルト値を上書きする必要があります。 「」 CONFIG_IPM_IMX_MAX_DATA_SIZE_16=n CONFIG_IPM_IMX_MAX_DATA_SIZE_4=y CONFIG_OPENAMP_WITH_DCACHE=y CONFIG_LOG=y CONFIG_OPENAMP_RSC_TABLE_IPM_RX_ID=1 CONFIG_OPENAMP_RSC_TABLE_IPM_TX_ID=0 「」 サンプルPR https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table/boards https://github.com/zephyrproject-rtos/zephyr/pull/86923 https://github.com/zephyrproject-rtos/zephyr/pull/79220/commits Linuxパッチ要件 i.MX93 で適切に動作させるには、次の Linux パッチを適用してください: https://lore.kernel.org/imx/CAEnQRZDoYvK-YXLjqbXsRAWDkHrWNOoR1OCCWxs+AfNUDuPB_w@mail.gmail.com/T/ 実行前の最終ステップ アプリケーションを起動する前に: U-Boot で `prepare_mcore` を実行します。 `-rpmsg` デバイス ツリー BLOB を使用します。 アプリケーションノート AN5317の手順に従ってください。 関連リソース i.MX Linux ユーザーガイド - https://www.nxp.com/docs/en/user-guide/UG10163.pdf アプリケーションノート AN5317 - https://www.nxp.com/docs/en/application-note/AN5317.pdf remoteproc、rpmsg、mailbox、OpenAMP フレームワークの詳細。DTS および構成オーバーレイを作成する方法の例が含まれています。これはi.MX 8M PlusのHiFi4コアの例であることに注意してください。 https://www.youtube.com/watch?v=JqwPljnm2_k&t=14s DTS API、`zephyr,ipc_shm` 上 - https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/build/dts/api/api.rst?plain=1#L421 Re: OpenAMP support for m33 core on i.mx93 すべての Zephyr IPC サポートはここにあります (メイン プロセッサ上の Linux カーネル OS とコプロセッサ上の Zephyr アプリケーション) https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table/boards 社内チームから確認したところ、現時点では MPU cm33 をサポートする予定はありません。 ただし、お客様の要件を社内チームに送信しましたので、更新があればお知らせいたします。 それは申し訳ありません。

RT685: SDK 25.12 no HASHCRYPT acceleration Hello, We recently updated to SDK 25.12 and noticed that our TLS decryption rate has been cut in half. mbedTLS v3.x is no longer accelerated using the fsl_hashcrypt hardware features. Here is the callstack of calling mbedtls_ssl_read using the previous SDK 25.09. As you can see, HASHCRYPT_AES_EncryptEcb is eventually used. hashcrypt_aes_one_block_aligned() at fsl_hashcrypt.c:437 hashcrypt_aes_one_block() at fsl_hashcrypt.c:581 HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,284 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_update() at gcm.c:358 mbedtls_gcm_crypt_and_tag() at gcm.c:456 mbedtls_gcm_auth_decrypt() at gcm.c:491 mbedtls_cipher_aead_decrypt() at cipher.c:1,407 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,613 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,242 ssl_prepare_record_content() at ssl_msg.c:3,667 ssl_get_next_record() at ssl_msg.c:4,551 mbedtls_ssl_read_record() at ssl_msg.c:3,817 mbedtls_ssl_read() at ssl_msg.c:5,237 <...more frames...> Here is the callstack of SDK 25.12 with MBEDTLS_USE_PSA_CRYPTO defined. In this version, mbedtls_internal_aes_encrypt is all C code with no HW acceleration. mbedtls_internal_aes_encrypt() at aes.c:894 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:641 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> And here is the callstack of SDK 25.12 withoutMBEDTLS_USE_PSA_CRYPTO defined. In this version,  mbedtls_internal_aes_encrypt is all C code with no HW acceleration and PSA is not involved. mbedtls_internal_aes_encrypt() at aes.c:899 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_cipher_aead_decrypt() at cipher.c:1,528 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,674 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,639 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Are there plans to restore RT685 HASHCRYPT hardware acceleration to mbedTLS? It seems certain PSA Crypto drivers are not implemented. Thank you. Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi Edwin, I reproduced the issue on the EVK. I modified two samples by adding a loop of 200 iterations of mbedtls_gcm_self_test and timed the overall execution using the RTC clock. evkmimxrt685_mbedtls_selftest_cm33 from SDK 25.09 executed the tests in 1087ms with this callstack: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,260 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_starts() at gcm.c:294 mbedtls_gcm_crypt_and_tag() at gcm.c:452 mbedtls_gcm_self_test() at gcm.c:826 evkmimxrt685_mbedtls3x_psatest_cm33 from SDK 25.12 executed the test in 8990ms with this callstack: mbedtls_internal_aes_encrypt() at aes.c:896 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 mbedtls_gcm_starts() at gcm.c:441 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075   evkmimxrt685_mbedtls3x_psatest_cm33 from SDK 25.12 with MBEDTLS_PSA_ACCEL_KEY_TYPE_AES defined executed the test in 8744ms with this callstack: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:187 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 mbedtls_gcm_starts() at gcm.c:439 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075 The gist of the modifications to the examples is the following: BOARD_InitHardware(); test_rtc_init(); psa_crypto_init(); uint64_t ms_start = test_rtc_get_msecs(); for (int i = 0; i < 200; ++i) { PRINTF("test iteration %d\r\n", i+1); mbedtls_gcm_self_test(0); } uint64_t ms_end = test_rtc_get_msecs(); PRINTF("test time = %ums\r\n", (unsigned)(ms_end - ms_start)); ... where test_rtc_get_msecs returns the current RTC time using subsecond accuracy. As you can see, there is an ~8x slow down for encrypting GCM/AES with the new SDK. I can attach the modified examples if you'd like. Regards, Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi Edwin, We have looked over the migration guide. However, we don't see how mbedTLS 2.x or mbedTLS 3.x without PSA would be hardware accelerated in this version of the SDK. Since aes_alt.c was removed and HASHCRYPT functionality is only supported by the PSA drivers. Everything works in our app with SDK 25.12, and we would definitely like to use TLS 1.3 for our connections, but we would suffer a large performance loss as it is. We will continue to look into this. I will modify one of the examples to see if I can reproduce the performance loss. Regards, Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @hrc-amilcar, Thanks for your patience with this question. I just received the response from the internal team, please see below. From the call stack I can see you are using legacy mbedtls_xxx crypto API. Indeed, it is not HW accelerated. MbedTLS3.x introduced new API for Crypto, and it is PSA. mbedtls/docs/psa-transition.md at v3.6.5 · Mbed-TLS/mbedtls · GitHub and it is accelerated. Legacy crypto API is further removed in MbedTLS4.x. I checked our psa_crypto_examples in SDK for RT600 and HASHCRYPT HW acceleration is enabled by default by having the PSA_CRYPTO_DRIVER_HASHCRYPT defined which enables crypto driver wrappers to offload crypto computation to HW. On the other hand, MbedTLS3.x+ is more complex and aligned with PSA API specification so it may happen that some use-cases are indeed producing lower performance. In case of TLS I would expect rather asymmetric cryptography (CASPER HW IP) to be bottleneck of performance, since this IP can support only bignum acceleration and it is not well compatible with PSA API that expect HW IP to implement whole algorithm. We did our best to accelerate at least some ECC operations (sign, verify) but it may happen that other operation like keygen during ECDHE key exchange may be worse. Now it would be good if you can use the PSA API for performance measurement and confirm that PSA_CRYPTO_DRIVER_HASHCRYPT is defined and call stack uses it. FYI: Hashcrypt did not offer AES-GCM acceleration natively, so it is better to benchmark AES-CBC or AES-CTR to see real gain of HW IP. BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @hrc-amilcar, Migrating from mbedTLS 2.x (without PSA) to mbedTLS 3.x (with PSA) is bound to have performance drops, considering that: "The PSA Driver Interface has only been partially implemented. As a result, the deliverables for writing a driver and the method for integrating a driver with Mbed TLS will vary depending on the operation being accelerated." (https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mbedtls3x/docs/psa-driver-example-and-guide.html) At the moment, the best I can recommend is to follow the guidelines on how to properly migrate from 2.x to 3.x: Migrating from Mbed TLS 2.x to Mbed TLS 3.0 — MCUXpresso SDK Documentation As well as the guide to properly transition to the PSA API: Transitioning to the PSA API — MCUXpresso SDK Documentation I apologize for the inconvenience. BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @hrc-amilcar, Did you make any changes after updating the SDK? Do you also see this behavior with the SDK's example code? Are you using the standalone IDE or the VS Code extension? BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration I defined MBEDTLS_PSA_ACCEL_KEY_TYPE_AES in our mbedTLS configuration file and now it's calling through to HASHCRYPT, but our mbedtls_ssl_read read rate is even slower now. I wonder if there are other missing defines or the PSA layer is adding extra overhead.   Rates downloading 4KB packets from WiFi via a TLS socket: SDK 25.09: 205KB/sec (mbedTLS 2.x without PSA and with ksdk port files) SDK 25.12: 138KB/sec (without MBEDTLS_PSA_ACCEL_KEY_TYPE_AES) SDK 25.12: 125KB/sec (with MBEDTLS_PSA_ACCEL_KEY_TYPE_AES) Here's the new callstack using MBEDTLS_PSA_ACCEL_KEY_TYPE_AES: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:203 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 gcm_mask() at gcm.c:543 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Re: RT685: SDK 25.12 no HASHCRYPT acceleration Hi @EdwinHz, We're using MCUXpresso IDE. No extra changes after updating the SDK: When we update the SDK, we re-run the "SDK Management" -> "Refresh SDK components" to get new and updated files. Then we compare the .cproject configuration to one of the samples that has similar features enabled (e.g. evkmimxrt685_wifi_wpa_supplicant_cm33) PSA_CRYPTO_DRIVER_CASPER=1 PSA_CRYPTO_DRIVER_HASHCRYPT=1 CONFIG_WPA_SUPP_CRYPTO_MBEDTLS_PSA=1 etc... We're using the default mcux_mbedtls_config.h as the main mbedTLS configuration header and our own user configuration file that is nearly identical to wpa_supp_mbedtls_config.h from the evkmimxrt685_wifi_wpa_supplicant_cm33 example. I will try the mbedtls3x_examples to see how they behave. Perhaps we're missing some defines. As I was stepping through the code, I noticed that perhaps MBEDTLS_BLOCK_CIPHER_C needs to be defined so that the gcm operation can be accelerated. It looks like the header mbedtls3x/include/mbedtls/config_adjust_legacy_crypto.h is responsible for this but doesn't end up defining that macro for some reason. Re: RT685: SDK 25.12 no HASHCRYPT acceleration For others' benefit... It appears that mbedtls_xor from mbedTLS 3.x is looping over data 4-bytes at a time and calling mbedtls_get_unaligned_uint32 and mbedtls_put_unaligned_uint32 which both use memcpy for a single uint32. I recognize that the authors of mbedTLS are trying to improve performance by calculating blocks of XOR 4-bytes at a time (with a remainder loop), but the full calls to memcpy are actually making the code slower. After some investigation into the disassembly, it turns out that our project was being compiled with -fno-builtin, preventing small memcpys from getting inlined by the compiler. Removing that option restored much of the performance loss of HASHCRYPT hardware not being used for AES-GCM operations. So, the example I posted went from executing in 8600ms down to 2100ms. Not quite at the level of mbedTLS 2.x + ksdk alt (at 1087ms). But the restored performance is good enough. -Amilcar

One Time Programable (OTP) Memory Legacy 8-bit MCUs Understanding EPROM Erasure and Package Types If a microcontroller (MCU) does not have a quartz window, its EPROM cannot be erased and effectively functions as OTPROM (One-Time Programmable ROM). This is because the quartz window is essential for allowing ultraviolet (UV) light to erase the EPROM contents. How to Identify Erasable EPROMs You can determine whether an EPROM is erasable by checking the part number and package type: If the package has a windowed ceramic dual in-line package the EPROM can be erase. For example, on the HC05 family you can see this window being mentioned on the order numbers of the datasheet

GD31xx Altium and Cadence models The attached GD3100 and GD3160 models may be used by customers in developing their schematic and PCB layout.

【恩智浦微控制器简介】【电机控制】【基础知识（三）】永磁同步电机的工作原理及控制方法（日语博客） 目录   【恩智浦微控制器简介】【电机控制】【基础知识（三）】永磁同步电机的机理及控制方法 幕后英雄！克拉克变形和帕克变形是什么？ 这一切都始于三相交流电的复杂波形。 第一步：克拉克变换——将三维图形简化为二维图形 第二步：公园改造——“旋转木马的魔力”——定格动态世界 为什么要经历如此繁琐的转换过程？这样做有什么巨大好处？ 摘要：数学如何运用强大的力量随意操控复杂波形 【恩智浦微控制器简介】【电机控制】【基础知识（三）】永磁同步电机的机理及控制方法 幕后英雄！克拉克变形和帕克变形是什么？ 你好！ 当电动汽车平稳起步，高性能空调运行异常安静时，微型计算机以超高速执行复杂的计算，并巧妙地控制电机。 这一次，让我们通过下面的 GIF 动画来揭开“克拉克变换”和“帕克变换” （以两位在控制技术核心“矢量控制”领域工作的伟大专家的名字命名的变换）的奥秘吧！ (function() { var wrapper = document.getElementById('lia-vid-6377224605112w540h540r855'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); （查看我的视频） 这一切都始于三相交流电的复杂波形。 首先，我们来看最上面一行。这是三相交流电的世界，也是驱动电机所需的基本能量。 右图（三相正弦波） ：三个波 A、B 和 C 在传播过程中，其幅值和方向都在不断变化。这三个波相互关联，但正因如此，很难凭直觉判断在任何给定时刻应该对电机施加多大的力。这就像试图指挥三个同时演奏不同乐曲的音乐家一样。 左图（旋转矢量） ：然而，当这三个波的力叠加在一起时，会发生一些有趣的事情。会产生一个单一的力（旋转矢量），它平滑且持续地旋转，同时保持恒定的大小。从物理角度来看，这就是定子线圈产生的“旋转磁场”。正是这个旋转磁场吸引着转子磁铁，并成为驱动电机旋转的力的来源。 问题：如何使用微控制器轻松准确地控制这“三个不断变化的波”？ 第一步：克拉克变换——将三维图形简化为二维图形 第一个魔法是“克拉克变换”，它将复杂的 3D 世界转化为更容易理解的 2D 世界。 计算公式如下： 在正常的运动控制中，假设幅值不变变换（K=2/3）和平衡三相（i_a+i_b+i_c=0），则使用以下简化公式。   ​ 右侧的图表（两相正弦波 α-β） ：看！三个波形已经合并成两个波形，α（α）和 β（β）。波形（交流电）仍然存在，但少了一个变量，使其更容易观察。 左侧图表（克拉克变换 α-β） ：它展示了从两个轴（α，β）观察到的世界，这两个轴与从三个轴（A，B，C）观察到的旋转矢量垂直相交。这就像将从一定角度观察到的立体物体转换成从正上方观察到的平面视图。旋转矢量本身仍然以相同的方式旋转，没有任何变化。 [克拉克转换的关键点] 在不丢失任何信息的情况下，我们将处理起来有些困难的三相坐标系转换为数学中熟悉的笛卡尔坐标系（α-β 静止坐标系），从而简化了问题。 第二步：公园改造——“旋转木马的魔力”——定格动态世界 α 和 β 的值仍然像波浪一样变化，很难跟踪它们。这就是矢量控制的精髓——“帕克变换”发挥作用的地方！ 计算公式如下： ​​ 这是一个重大的思维转变：“让我们不再从静止的地面（α-β 坐标）观察旋转矢量，而是跳上一个与旋转矢量以相同速度旋转的旋转木马！”这个新的旋转坐标系被称为“ dq 旋转坐标系”。 右图（两相值 dq） ：多么惊人的结果！之前变化如此剧烈的两个波现在已经变成了**几乎恒定的值（直流）**，分别称为 d 和 q！ 左图（Park变换dq） ：可以看到dq坐标与旋转矢量完美同步旋转。如果你站在旋转木马上的马旁边，你会看到马静止不动，对吧？原理完全相同。从旋转物体的角度来看，它看起来是静止的。 【关于公园改建的注意事项】 通过与旋转矢量以相同速度旋转的坐标系（dq 坐标）进行观察，可以将交流值视为直流值。 为什么要经历如此繁琐的转换过程？这样做有什么巨大好处？ 通过这两步转变，我们获得了巨大的好处：控制的极大简化。 控制不断变化的交流电数值很困难，但直流电数值呢？如果高于目标值，就降低它；如果低于目标值，就提高它。通过这种即使是小学生也能理解的简单操作（PID控制），就可以实现对电机的完美控制。 d 和 q 的直流值各自具有重要的物理意义。 q轴值（正交轴）：它直接控制电机的扭矩（旋转力）。当您踩下电动汽车的油门时，车辆会迅速加速，这是因为微电脑提高了q轴的目标值。它就像一个“动力旋钮”。 d轴值（直轴）：控制电机的磁通量（磁体强度）。对于永磁电机，转子磁体的强度是恒定的，因此基本上将d轴电流控制在零是最有效的。它真可谓是一个“效率调节旋钮”。 换句话说，克拉克和帕克变换的神奇之处在于，它们将电机的“功率”和“效率”元素（通常混合在一起）分离成两个独立的直流旋钮（d 和 q） 。 摘要：数学如何运用强大的力量随意操控复杂波形 三相交流电的复杂波形会在电机内部产生旋转力（旋转矢量）。 克拉克变换通过将三维世界重新绘制成二维（α-β）来简化问题。 公园改造包括乘坐旋转木马（dq 坐标）并将交流值转换为直流值。 使用 PID 控制器可以轻松准确地控制直流转矩 (q) 和磁通量 (d) 值！ 这一系列精妙的数学运算是“矢量控制”的基础，而矢量控制正是现代高性能电机的基石。正是这项神奇的技术，让我们得以尽享动力强劲、静音高效、节能环保的电机所带来的种种益处。 感谢您阅读到最后！ 如果您想阅读下一章基础内容，请点击这里↓ 【基础知识 第4部分】练习！让我们用框图来了解矢量控制的工作原理！ 点击这里查看具体的安装方法以及如何运行示例代码的说明。 【恩智浦微控制器简介】【电机控制】【实践篇1】永磁同步电机的机理及控制方法（日文博客） 这是一个汇总了有关恩智浦电机控制文章的网站： NXP电机控制 - 概要页面 - （日语博客） =========================​ 我们目前无法 回复 此帖子“ 评论”部分的评论。 对于由此造成的不便，我们深表歉意。如有任何疑问， 请 参考“ 如何就 技术问题 联系 NXP （ 日语 博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有业务往来 ，您可以直接联系负责人。 ） 本文将以浅显易懂的方式讲解如何使用NXP FRDM控制板“FRDM-MCXA156”进行电机控制。文章分为基础知识部分和实践部分，希望您能参考感兴趣的部分。 ・基础知识①～⑦，实践①～③ 这次，作为基础知识的第三部分，我们将使用 NXP 微控制器来解释永磁同步电机的工作原理和控制方法。 MCUXpresso MCUXpresso IDE MCUXpresso SDK MCX 电机控制 技术聚焦 日本博客

RT1170 MIPI-CSI Camera - YUV422 (8 bit) support Hello, Do you have any reference designs, application notes, or example projects demonstrating the use of a camera module outputting YUV422 (8-bit) with the i.MX RT1170 MIPI-CSI interface? I have reviewed the RT1170 errata (https://www.nxp.com/docs/en/errata/IMXRT1170ACE.pdf) and understand that YUV422 10-bit formats are not supported, but I have not been able to find any published examples or confirmation specifically showing YUV422 8-bit operation. Any guidance, known-working configurations, or example camera modules would be greatly appreciated.  Re: RT1170 MIPI-CSI Camera - YUV422 (8 bit) support Hi @mtreloar , Thanks for your interest in NXP MIMXRT series! RT1170 MIPI-CSI supports YUV422 (YUYV 8-bit) format. You can refer to this sample project in the SDK: Best regards, Gavin

如何构建示例项目的版本 — S32K1 AUTOSAR 您好，NXP团队， 我目前正在使用 S32K1 AUTOSAR RTD 2.0.0 示例项目。 我创建了一个 GPIO_DIO_LP_example_s32K118 项目并成功构建了 Debug_Flash 版本 。 不过，该示例项目默认情况下似乎只支持在调试模式下构建。 你能告诉我如何配置项目来构建发布版本吗？ 感谢您的支持！ Re: How to Build Release Version of Example Project – S32K1 AUTOSAR 你好，彼得斯 谢谢您的建议。 Re: How to Build Release Version of Example Project – S32K1 AUTOSAR 您好， 你可以进入项目的属性并添加新的版本配置 输入新名称并从现有调试配置中复制 最后删除调试标记 然后应用并版本 BR, Petr

CI/CD 最佳实践 以前也有过几个类似的帖子，但答案都有点过时了，而且我的问题也略有不同，所以也许值得再问一次。我有两个问题： 1。每隔一段时间，在 S32DS (v 3.6.2) 中进行版本时，操作系统是 Windows 11），版本失败是因为它找不到某些标准头文件。只需重新打开项目的 .mex文件，执行 "更新代码"（尽管实际上不应该更新任何内容）并重建后，问题就解决了。我的问题是：为什么会出现这种情况？这种情况似乎是随机发生的，所以我无法提供任何 "重现步骤"，但这种情况经常发生，如果你至少没有意识到这一点，我会很惊讶。我看到其他一些人也在论坛上提到这个问题。 2。我们正在努力将要编程到闪存的整个代码库（而仅限于我们的应用程序代码）放入 git 中，并在 IDE 之外的无头环境中使用 CI/CD 管道来创建映像版本。我们使用的是运行在 RHEL 上的 gitlab。 有没有这方面的 "最佳实践 "建议？特别是，由于 RTD、C 标准库等都在项目之外，而且 IDE 安装了很多连接，因此在 CI/CD 环境中应该如何处理这个问题以及如何安装独立的工具链？ Re: Best practices for CI/CD 谢谢@petervlna提供的提示。关于 CI/CD 管道，我还有一个问题： 如何在 Linux 环境中安装独立于 IDE 的版本工具链？ Re: Best practices for CI/CD 你好 1。每隔一段时间，在 S32DS (v 3.6.2) 中进行版本时，操作系统是 Windows 11），版本失败是因为它找不到某些标准头文件。只需重新打开项目的 .mex文件，执行 "更新代码"（尽管实际上不应该更新任何内容）并重建后，问题就解决了。我的问题是：为什么会出现这种情况？这种情况似乎是随机发生的，所以我无法提供任何 "重现步骤"，但这种情况经常发生，如果你至少没有意识到这一点，我会很惊讶。我看到其他一些人也在论坛上提到了这个问题。 这个问题在 S32DS 等基于 Eclipse 的集成开发环境中比较常见。以下是最可能的原因： 索引/路径解析故障 S32DS 依赖 Eclipse 的 CDT 索引器和项目元数据来解析包含路径。有时，索引器或内部版本配置会不同步，尤其是在更改.mex 或环境变量之后。重新打开 .mex文件和重新生成代码会强制集成开发环境刷新路径并重建索引。 临时工作区损坏 集成开发环境在工作区中存储了大量状态。如果工作区缓存变得不一致（例如，在版本中断或 IDE 崩溃之后），则在刷新之前可能无法识别包含路径。 Windows 文件系统定时 在 Windows 上，防病毒或文件锁定会在并行版本步骤中延迟对头文件的访问，从而导致间歇性故障。 2。我们正在努力将要编程到闪存的整个代码库（而仅限于我们的应用程序代码）放入 git 中，并在 IDE 之外的无头环境中使用 CI/CD 管道来创建映像版本。我们使用的是运行在 RHEL 上的 gitlab。 有没有这方面的 "最佳实践 "建议？特别是，由于 RTD、C 标准库等都在项目之外，而且 IDE 安装了很多连接，因此在 CI/CD 环境中应该如何处理这个问题以及如何安装独立的工具链？ 处理 RTD 和外部 SDK 版本控制或工件库： 将 RTD 和 SDK 代码包存储在 Git（如果允许）或 Nexus/Artifactory 等工件存储库中。 环境变量： 在 CI/CD 管道中定义 RTD_PATH 和 SDK_PATH 等变量。 在 Makefile 或版本脚本中使用这些变量，而不是硬编码路径。 导出项目以进行无头版本 在 S32DS 中，将项目导出为 Makefile 项目（项目 → 生成 Makefile）。 这样，您就可以得到一个可以在集成开发环境之外使用的 Makefile。 或者，使用 s32ds.exe --build 进行基于 Windows 的无头版本，但对于 Linux CI/CD，首选 Makefile。 避免集成开发环境依赖性 不要依赖 .mex在 CI/CD 中再生。 确保在 Makefile 或 CMake 配置中捕获所有包含路径和编译器标志。 我不知道除了一般性建议之外还有没有其他建议。 顺祝商祺！ Peter Re: Best practices for CI/CD 你好@petervlna 谢谢您的建议。我需要更多这方面的信息。在 S32 Design studio 页面上，我看到了整个集成开发环境的下载选项，似乎工具链已作为集成开发环境安装的一部分安装。我没有看到工具链作为单独的下载提供。 我确实看到，在 Windows11（我目前使用的操作系统）上，工具链安装在 C:\NXP\S32DS.3.6.2\S32DS\build_tools 你的意思是 1.在 Linux 桌面上安装 Linux 版本的集成开发环境 2.将已安装的工具链从本机复制到无头 CI/CD 服务器 3.按照上述步骤操作 请予以澄清。 Re: Best practices for CI/CD 你好 如何在 Linux 环境中安装独立于 IDE 的版本工具链？ 遗憾的是，我不了解 Linux 环境，所以只能提供一般性的帮助： 官方步骤摘要： 从 S32DS 下载页面下载适用于 ARM 的恩智浦 GCC 工具链（Linux 版本）。 将压缩包解压缩到 /opt/armgcc 等目录。 将工具链 bin 目录添加到 PATH。 在 Linux 系统上安装编译工具（make、cmake）。 使用从 S32DS 导出的 Makefile 进行无头版本。 我建议有关 Linux 的问题另起一个主题。 顺祝商祺！ Peter Re: Best practices for CI/CD 你好、 你可以从恩智浦页面下载独立组网 \(SA\) gcc 例如这个 https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true 或任何其他版本 https://www.nxp.com/search?keyword=gcc% 2520 &start=0 Re: Best practices for CI/CD 你好@petervlna @jiri_kral 很抱歉延迟回复已关闭的单子，但我终于有机会解决这个问题了。 彼得的建议对我来说非常合理；但是，我在 S32 IDE（v3.6.6）中找不到 “项目 → 生成 Makefile” 选项。我可以尝试复制生成的生成文件，但是它有一些不太好的地方： 1.这不是一个独立的 makefile，它依赖于其他 .mk文件也会生成。 2。生成文件是按版本目标生成的（与 .cproject 不同）文件），这使得它有点笨重。理想情况下，我想要的是一个Makefile，其中版本目标是 “制作” 的参数。 我有点惊讶其他人以前没有问过这个问题，或者你没有关于这个问题的 “操作方法” 文档；鉴于该处理器非常受欢迎并且对功能安全至关重要，我本以为在 CI/CD Linux 环境中进行版本会很常见。

i.MX8Qを例に、gpioget/gpiosetでGPIO（libgpiod）を使用する方法 GPIO制御におけるgpiogetおよび「cat /sys/class/gpio」の違い。 gpioget : これは、 libgpiod ライブラリが提供するコマンドライン・ユーティリティです。最新のLinux GPIOキャラクタ・デバイス・インターフェース（ /dev/gpiochipN ）を介して、GPIOラインとやり取りするように設計されています。 /sys/class/gpio : これは、LinuxのGPIO制御のためのsysfsレガシー・インターフェースを指します。このインターフェースは、かつて広く使用されていましたが、Linuxカーネルバージョン6.0以降、 libgpiod キャラクタ・デバイス・インターフェースが採用され、正式に非推奨になりました。 以下は、i.MX8Q-MEK、L6.12.3 BSPでテストされたlibgpiodの例です。 デバイスツリーの設定： この例では、GPIO1-05およびGPIO1-06を使用します。GPIO pinctrlを「gpio_test」のような特定のグループ、または「gpio-keys」のようなドライバの下に置くことができます。 gpio_test: gpio-test { pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_gpio_test_default>; pinctrl-1 = <&pinctrl_gpio_test_sleep>; status = "okay"; }; gpio-keys { compatible = "gpio-keys"; pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_gpio_example_default>; pinctrl-1 = <&pinctrl_gpio_example_sleep>; key_wakeup2{ label = "wakeup_key"; gpios = <&lsio_gpio2 1 GPIO_ACTIVE_LOW>; linux,code = ; wakeup-source; }; pinctrl_gpio_test_default: gpiotestgrp_default { fsl,pins = < IMX8QM_LVDS0_I2C0_SDA_LSIO_GPIO1_IO07 0x06000061 IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26 0x06000041 IMX8QM_MIPI_CSI1_I2C0_SCL_LSIO_GPIO2_IO00 0x06000021 IMX8QM_LVDS0_I2C0_SCL_LSIO_GPIO1_IO06 0x06000021 >; }; pinctrl_gpio_test_sleep: gpiotestgrp_sleep { fsl,pins = < IMX8QM_LVDS0_I2C0_SDA_LSIO_GPIO1_IO07 0x07800061 IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26 0x07800041 IMX8QM_MIPI_CSI1_I2C0_SCL_LSIO_GPIO2_IO00 0x07800021 IMX8QM_LVDS0_I2C0_SCL_LSIO_GPIO1_IO06 0x07800021 >; }; pinctrl_gpio_example_default: gpioexamplegrp_default { fsl,pins = < IMX8QM_LVDS0_GPIO01_LSIO_GPIO1_IO05 0x06000021 IMX8QM_MIPI_CSI1_I2C0_SDA_LSIO_GPIO2_IO01 0x06000021 >; }; pinctrl_gpio_example_sleep: gpioexamplegrp_sleep { fsl,pins = < IMX8QM_LVDS0_GPIO01_LSIO_GPIO1_IO05 0x07800021 IMX8QM_MIPI_CSI1_I2C0_SDA_LSIO_GPIO2_IO01 0x07800021 >; }; GPIO機能をテストするためのカーネル・コマンド： gpiodetect および gpioinfo コマンド： root@imx8qmmek:~# gpiodetect gpiochip0 [5d080000.gpio] (32 lines) gpiochip1 [5d090000.gpio] (32 lines) gpiochip2 [5d0a0000.gpio] (32 lines) gpiochip3 [5d0b0000.gpio] (32 lines) gpiochip4 [5d0c0000.gpio] (32 lines) gpiochip5 [5d0d0000.gpio] (32 lines) gpiochip6 [5d0e0000.gpio] (32 lines) gpiochip7 [5d0f0000.gpio] (32 lines) root@imx8qmmek:~# gpioinfo -c 1 gpiochip1 - 32 lines: line 0: unnamed input line 1: unnamed input line 2: unnamed input line 3: unnamed input line 4: unnamed input line 5: unnamed input line 6: unnamed output line 7: unnamed output line 8: unnamed input line 9: unnamed input line 10: unnamed input line 11: unnamed input line 12: unnamed input line 13: unnamed output consumer=regulator-pcie line 14: unnamed input line 15: unnamed input line 16: unnamed input line 17: unnamed input line 18: unnamed input line 19: unnamed input line 20: unnamed input line 21: unnamed input line 22: unnamed input line 23: unnamed input line 24: unnamed input line 25: unnamed input line 26: unnamed input line 27: unnamed input line 28: unnamed input line 29: unnamed input line 30: unnamed input line 31: unnamed input GPIO1-05およびGPIO1-06が設定される前の現在のGPIO設定を表示するには、 cat /sys/kernel/debug/gpio を使用します。 root@imx8qmmek:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 512-543, parent: platform/5d080000.gpio, 5d080000.gpio: gpio-526 ( |scl ) out lo gpio-527 ( |sda ) in lo gpiochip1: GPIOs 544-575, parent: platform/5d090000.gpio, 5d090000.gpio: gpio-557 ( |regulator-pcie ) out hi gpiochip2: GPIOs 576-607, parent: platform/5d0a0000.gpio, 5d0a0000.gpio: gpio-577 ( |wakeup_key ) in hi ACTIVE LOW gpiochip3: GPIOs 608-639, parent: platform/5d0b0000.gpio, 5d0b0000.gpio: gpio-618 ( |spi1 CS0 ) out hi ACTIVE LOW gpiochip4: GPIOs 640-671, parent: platform/5d0c0000.gpio, 5d0c0000.gpio: gpio-641 ( |enable ) out hi ACTIVE LOW gpio-643 ( |regulator-usbotg1-vb) out lo gpio-647 ( |usdhc2-vmmc ) out hi gpio-667 ( |enable ) out lo ACTIVE LOW gpio-668 ( |host-wake ) in hi ACTIVE LOW gpio-669 ( |PCIe reset ) out hi ACTIVE LOW gpiochip5: GPIOs 672-703, parent: platform/5d0d0000.gpio, 5d0d0000.gpio: gpio-673 ( |mux ) out hi gpio-693 ( |wp ) in lo gpio-694 ( |cd ) in lo ACTIVE LOW gpiochip6: GPIOs 704-735, parent: platform/5d0e0000.gpio, 5d0e0000.gpio: gpiochip7: GPIOs 736-767, parent: platform/5d0f0000.gpio, 5d0f0000.gpio: gpioset コマンドを使用してGPIO出力を設定します。また、GPIOの方向を変更することもできます（入力→出力）。 #set gpiochip1-5 and 1-6 root@imx8qmmek:~# gpioset -c gpiochip1 6=1 & [1] 700 root@imx8qmmek:~# gpioset -c gpiochip1 5=1 & [2] 702 上記のコマンドの変更点を cat /sys/kernel/debug/gpio および gpioinfo -c 1 で確認してください。 root@imx8qmmek:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 512-543, parent: platform/5d080000.gpio, 5d080000.gpio: gpio-526 ( |scl ) out lo gpio-527 ( |sda ) in lo gpiochip1: GPIOs 544-575, parent: platform/5d090000.gpio, 5d090000.gpio: gpio-549 ( |gpioset ) out hi gpio-550 ( |gpioset ) out hi gpio-557 ( |regulator-pcie ) out hi gpiochip2: GPIOs 576-607, parent: platform/5d0a0000.gpio, 5d0a0000.gpio: gpio-577 ( |wakeup_key ) in hi ACTIVE LOW gpiochip3: GPIOs 608-639, parent: platform/5d0b0000.gpio, 5d0b0000.gpio: gpio-618 ( |spi1 CS0 ) out hi ACTIVE LOW gpiochip4: GPIOs 640-671, parent: platform/5d0c0000.gpio, 5d0c0000.gpio: gpio-641 ( |enable ) out hi ACTIVE LOW gpio-643 ( |regulator-usbotg1-vb) out lo gpio-647 ( |usdhc2-vmmc ) out hi gpio-667 ( |enable ) out lo ACTIVE LOW gpio-668 ( |host-wake ) in hi ACTIVE LOW gpio-669 ( |PCIe reset ) out hi ACTIVE LOW gpiochip5: GPIOs 672-703, parent: platform/5d0d0000.gpio, 5d0d0000.gpio: gpio-673 ( |mux ) out hi gpio-693 ( |wp ) in lo gpio-694 ( |cd ) in lo ACTIVE LOW gpiochip6: GPIOs 704-735, parent: platform/5d0e0000.gpio, 5d0e0000.gpio: gpiochip7: GPIOs 736-767, parent: platform/5d0f0000.gpio, 5d0f0000.gpio: root@imx8qmmek:~# gpioinfo -c 1 gpiochip1 - 32 lines: line 0: unnamed input line 1: unnamed input line 2: unnamed input line 3: unnamed input line 4: unnamed input line 5: unnamed output consumer=gpioset line 6: unnamed output consumer=gpioset line 7: unnamed output line 8: unnamed input line 9: unnamed input line 10: unnamed input line 11: unnamed input line 12: unnamed input line 13: unnamed output consumer=regulator-pcie   レガシーGPIO SYSFS（L6カーネル以上ではデフォルトで無効）を有効にする方法 このコミットのコメントを参照してください。 https://github.com/nxp-imx/linux-imx/commit/3b4feb21158f873269ff3fbe2fe8d23a88d64b24 commit 3b4feb21158f873269ff3fbe2fe8d23a88d64b24 Author: Linus Walleij Date: Tue Nov 10 15:27:24 2020 +0100 gpio: sysfs: Enforce character device If users select sysfs support they get the character device as well so that end-users cannot complain that they "only have sysfs on my system". They should have the character device at all times. If someone is in so dire need of stripping out the character device while still enabling the sysfs ABI they can very well patch the kernel. Also only show this obsolete option to expert users. Signed-off-by: Linus Walleij Link: <> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 5d4de5cd6759..4dd566f7ea39 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -59,8 +59,9 @@ config DEBUG_GPIO that are most common when setting up new platforms or boards. config GPIO_SYSFS - bool "/sys/class/gpio/... (sysfs interface)" + bool "/sys/class/gpio/... (sysfs interface)" if EXPERT depends on SYSFS + select GPIO_CDEV # We need to encourage the new ABI help Say Y here to add the legacy sysfs interface for GPIOs. パッチから、GPIO_SYSFSを有効にするための最良の方法は、CONFIG_EXPERT= y、次に、CONFIG_GPIO_SYSFS= Yを有効にします。パッチを元に戻す必要はありません。 SYSFSは、LinuxのGPIO制御のためのレガシー・インターフェースです。このインターフェースは、かつて広く使用されていましたが、Linuxカーネルバージョン6.0以降、libgpiodキャラクタ・デバイス・インターフェースが採用され、正式に非推奨になりました。 i.MX Processors

MIIT (China) sharpened Homologation on FRDM-KW38 & KW36 The homologation requirements in China (MIIT [2002]353) obviously are planned (end of December 2022) to be sharpened (MIIT publication from 2021-01-27: “Notice on Matters Related to Radio Management in the 2400MHz, 5100MHz and 5800MHz Bands”). A modification register is need on the KW38 and KW36 to pass the new Chinese  requirement with acceptable margin: PA_RAMP_SEL value must be set to 0x02h (2us) instead of 0x01h (1us default value) Modification SW: XCVR_TX_DIG_PA_CTRL_PA_RAMP_SEL(2) in the nxp_xcvr_common_config.c All the details are in the attached file. Note: This SW modification is for China country only. BLE Software KW KW35 | 36