Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
PTN3460, PTN3460I FAQs Q1: Why DisplayPort to LVDS adapter? DPRX-LVDS is an (embedded) DisplayPort to LVDS bridge device that enables connectivity between an (embedded) DisplayPort (eDP) source and LVDS display panel. It processes the incoming DisplayPort (DP) stream, performs DP to LVDS protocol conversion and transmits processed stream in LVDS format. NXP offers two eDP-LVDS devices: 1. PTN3460 is commercial grade, 0 – 70 C. It is in 56-pin HVQFN package, 7 mm x 7 mm, 0.4 mm pitch. Supports pixel clock frequency from 25 MHz to 112 MHz. 2. PTN3460I is industrial grade, -40 – 85 C. It is in 56-pin HVQFN package, 7 mm x 7 mm, 0.4 mm pitch. Supports pixel clock frequency from 6 MHz to 112 MHz. Q2. How to configure eDP-LVDS device?   The eDP-LVDS has embedded microcontroller and on-chip Non-Volatile Memory (NVM) to allow for flexibility in firmware updates. Both PTN3460 and PTN3460I have a built in configuration table in internal 1K SRAM, which allows users to program seven EDID and 128 configuration registers through M/S I2C-bus. Please follow the programming guides below for these devices. 1. AN11128 – Programming Guide for PTN3460 2. AN11606 – Programming Guide for PTN3460I Q3. What is maximum resolution DP-LVDS can support? The available bandwidth over a 2-lane HBR DisplayPort v1.4 link limits pixel clock rate support to: 1. 1-lane DP with single LVDS bus supports 800x600 @ 60 Hz display, 40 MHz pixel clock. 2. 1-lane DP with dual LVDS bus supports 1366x768 @ 60 Hz display, 85.5 MHz pixel clock. 3. 2-lane DP with single LVDS bus operation up to 112 mega pixel per second – supports 1440x900 @ 60 Hz resolution display. 4. 2-lane DP with dual LVDS bus operation up to 224 mega pixel per second – supports 1920x1200 @ 60 Hz resolution display. Q4. How to update the FW? FW for eDP-LVDS devices can be updated by the following methods: 1. Flash over AUX (FoA) – This is an executable window utility that can only run under Windows OS. FW is updated through DP AUX channel. AN11133 – PTN3460 FoA utility user’s guide. 2. Flash over DOS (FoD) – This is an executable DOS utility that can run under DOS without OS. FW is updated through M/S I2C bus. 3. Flash over I2C – FW is updated through external I2C device that is plugged in a M/S I2C header. Q5. How to check the FW version? FW version can be read out with DPCD utility that runs under Windows OS. Please follow DPCD Tool User Manual V1.0. Q6. How many DP lanes supported in NXP DP to LVDS bridge device? NXP DP to LVDS bridge device supports 2 lanes HBR/RBR. Q7. What does HBR/RBR mean? HBR means “High Bit Rate”, it runs 2.7 Gbit/s. RBR means “Reduced Bit Rate”, it runs 1.62 Gbit/s. Q8. What is DP AUX channel? DP AUX channel is used for communication channel between DP source and DP sink device. Q9. What is DP source device? DP source device is DP signal transmitter. Q10. What is DP sink device? DP sink device is DP signal receiver.
記事全体を表示
i.MX95 Triple display Linux Patch i.MX95 Triple Display Patches for LF-6.6.52-2.2.0 BSP. iMX95 19x19 EVK. qiang_limpu_se_0-1739859470230.png   Patches files: 0001-iMX95-EVK-IT6263-LVDS-to-HDMI-bridge-chip-combine-it.patch Combine IT6263 with simple panel driver, no EDID is needed, 720P and 1080P display mode had been added as two examples.   0002-IT6263-Always-reported-connected-for-force-output.patch Let IT6263 always report cable connected to force output HDMI signals.   0003-iMX95-EVK-add-LVDS-clone-mode-based-on-IT6263.patch LVDS clone mode is supported on two LVDS ports, they output same content and same timing from one DPU display engine (1920*1080@60fps).   0004-iMX95-EVK-add-dual-LVDS-interleaver-mode-based-on-IT.patch LVDS interleave mode is supported on two LVDS ports, they output different content and same timing from one DPU display engine (3840*1080@60fps).   0005-iMX95-EVK-add-triple-display-support.patch Triple display is supported, 1 MIPI DSI + 2 LVDS.  imx95-19x19-evk-triple-display-lvds-clone.dtb: the two LVDS is in clone mode. imx95-19x19-evk-triple-display-lvds-interleaver.dtb: the two LVDS is in interleave mode.   For 1 MIPI DSI + 2 LVDS display clone mode: qiang_limpu_se_0-1739858854733.png For 1 MIPI DSI + 2 LVDS Interleave mode: qiang_limpu_se_2-1739859096402.png Know issues:  Due to bridge numbers (3) and DPU engine/Pixel link/Pixel Interleaver number (2) is not aligned, during kernel boot up, there will be followed link error log, but there is no real function impact.   [    3.178741] imx95-ldb 4b0c0000.syscon:ldb@4: Failed to create device link (0x180) with 4b010000.syscon:bridge@8 ... [    4.209299] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller [    4.220355] imx95-pixel-interleaver 4b0d0000.bridge: Failed to create device link (0x180) with 4b400000.display-controller ...     2025-8-19 update: Add the patch for L6.12.20_2.0.0 BSP. lf-6.12.20-2.0.0_triple_display_patches.zip   2026-9-7 update: Add patch for L6.18.37_2.1.0 BSP based on FRDM-IMX95.   BL: Auto BL: non-Auto
記事全体を表示
OV5640 Interfacing with i.MX RT1170 (Without Display) Image Capture and Streaming to Desktop Hello, I am using the i.MX RT1170-EVKB board, and my goal is to capture images from the OV5640 camera and view either the captured image or a live video stream on my desktop PC without using an LCD display. I have tried the MIPI CSI SDK examples and was able to capture image data in RAW format. However, I am facing several issues. The captured output is in RAW format, and I could not find any documentation explaining how to properly convert or view these images. The captured images appear to have incorrect colors or filter-like artifacts, making it difficult to verify whether the camera output is correct. I could not find any official documentation, application notes, or video tutorials describing the complete workflow for capturing images from the OV5640 and viewing them on a desktop PC. There is no clear reference explaining how to stream the camera output over Ethernet or USB without using the onboard display. I also tried the sd_jpeg example, but I encountered multiple problems. During integration, the project reported missing JPEG library configuration files such as jconfig.h. After resolving some build issues, I continued to encounter compilation and integration errors while combining the JPEG encoder with the MIPI CSI camera example. I was unable to generate a valid JPEG image from the captured camera frame. My objective is to: Interface the OV5640 camera with the i.MX RT1170-EVKB board without using an LCD display. Capture images and transfer them to my desktop PC for viewing. Stream live video from the camera to my desktop PC over Ethernet, if supported. I would appreciate your guidance on the following questions: Is there an official SDK example or reference project for this use case? Is there any documentation explaining the complete image capture pipeline from the OV5640 through MIPI CSI, memory, JPEG or RAW processing, and Ethernet or USB transfer to a desktop PC? Is live streaming over Ethernet supported on the RT1170-EVKB? If yes, could you recommend the appropriate SDK example or middleware? Are there any known issues with the sd jpeg example or any additional configuration steps required to integrate it with the MIPI CSI camera examples? Any guidance, documentation, or reference projects would be greatly appreciated. Thank you for your support. Re: OV5640 Interfacing with i.MX RT1170 (Without Display) Image Capture and Streaming to Desktop HI @Sureshk123, We don't have an official example project or reference design for your application. That said, from my understanding, I would recommend you tackle the complete application as follows: Camera capture path (OV5640 > MIPI CSI > cameraBuffer) This part we do have an example application, which are the aforementioned MIPI CSI SDK examples. Keep in mind that, as per ERR051248: "Video Mux Controller (VIDEO_MUX), raw data and YUV422 (10 bit) formats to the MIPI_CSI2 block are not supported." Using the parallel CSI is an optional workaround, either that or a video decoder. Once you have the adequate data on your cameraBuffer, you can integrate example projects from our SDK based on USB or lwIP to transport this data to your PC. I would recommend looking into JPEG encoding only after the buffer is known to work. BR, Edwin.
記事全体を表示
Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Board: Custom S32G399A based module, derived from S32G-VNP-RDB3. PFE_MAC1 connected via RGMII (PE_02–PE_13) to an NXP SJA1110A switch port 2, configured as the DSA CPU port (in-tree sja1105 driver, kernel 6.x BSP43.0). Topology: - PFE_MAC0: SGMII via SerDes1 lane1, Mode 1 - PFE_MAC1: RGMII to SJA1110A port 2 (DSA CPU port) — the port in question - PFE_MAC2: SGMII via SerDes0 lane1 The S32G MACs are configured as follows: +---------+--------------+------------------+ |                    | LANE 0               | LANE 1                        | +---------+--------------+------------------+ | SERDES0    | GMAC (SGMII) | PFE_MAC2 (SGMII)  | | SERDES1      | NOT USED        | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ Full U-Boot hwconfig: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii DTS for port@2 (switch side): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; DTS for pfe_netif1 (MAC side): &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) link state — confirmed up and correctly configured at the Linux/driver level: dmesg at boot: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTB confirms the kernel matches the source DTS: # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a output: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link All SJA1110 DSA slave ports correctly enumerated. This confirms the sja1105 DSA driver bound successfully to pfe1 as the CPU port/DSA master and parsed the static config without error. Clock tree: both TX and RX RGMII clocks enabled and attached to the correct consumer: # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id So pfe1 is UP, LOWER_UP, correctly bound to the SJA1110 as DSA master, running in RGMII mode with both clocks enabled — this rules out pfe1 being down, unbound, or misconfigured at the Linux/driver level. The open question is specifically whether frames actually cross the physical RGMII pins between PFE_MAC1 and SJA1110 port 2. Issue: No traffic appears to cross the RGMII bus between PFE_MAC1 and SJA1110 port 2 in either direction, despite everything on both sides of that bus being independently up: Test 1 — S32G -> switch direction Setup: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 Test 2 — switch -> S32G direction Setup Partner board is a separate SJA1105 switch based board. # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] Port 9 received 9 real frames; the fabric forwarded all 9 toward port 2 — but nothing arrived at pfe1. So the SJA1110's own fabric counters show all 9 frames successfully forwarded from port 9 to port 2's egress. But tcpdump -i pfe1 -e -nn on the S32G during this exact test shows NOTHING received. So the DSA/software layer on the S32G side believes it's sending (case 1). The switch's internal fabric believes it's sending toward the CPU port (case 2). Neither side has any confirmation that the other actually received anything across the physical RGMII bus. Every layer adjacent to this bus works individually; the bus itself has no confirmed successful crossing in either direction. What's been ruled out so far: - pfeng_mode / hwconfig (xpcs_mode) — confirmed correct; EMAC1 mode is RGMII (0x9), not SGMII (it was previously misconfigured as SGMII due to xpcs_mode=both on SerDes1 forcing PFE_MAC1's XPCS into SGMII; corrected to xpcs_mode=0 since PFE_MAC0 alone only needs XPCS0) - PFE_MAC1 TX/RX clock enablement — confirmed enabled at the correct rate (125MHz) in clk_summary - DSA tagging and CPU port binding — confirmed working (port netdevs exist, frames get tagged with the correct destination port in the DSA header) - SJA1110 internal fabric/forwarding — confirmed working between two other ports (9 and 2) using real external traffic - BASE-T1 link partner — confirmed passing real frames into the switch (port 9 n_rxfrm increments from genuine wire traffic) What hasn't been ruled out / open questions: - Whether 1000 Mbps RGMII with zero internal delay on both MAC and switch sides (rx/tx-internal-delay-ps=0, plain "rgmii" not "rgmii-id") is compatible without delay added by board trace length — have not yet tried forcing the link down to 100 Mbps as a timing-margin test 1. Is rx/tx-internal-delay-ps=0 on both ends at 1000 Mbps RGMII expected to work, or does this combination typically require delay compensation unless the PCB explicitly accounts for it? 2. Am I missing any other configuration? Happy to share full register dumps, if required. Appreciate any pointers before we probe the PE_02-13 bus with a logic analyzer (limited probe access due to board layout, so it is not so convenient currently. Thanks. Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z @db16122 I am attaching the relevant sections of the schematics here. The connection flow is as follows: We use PE_02 to PE_13 on the S32G3 chip shown in s32g3_pfe_mac1_connections.png for the PFE_MAC1. They go to a board to board connector (shown in Board_to_board_connector.png) that routes these signals to  a different board that has the switch. The switch connections are shown in SJA1110_A.png and SJA1110_B.png. So the connection is PE_xx pins -> board connectors -> switch (SJA1110) Please let me know if you have any questions. I have also raised a support ticket ( #00990408) with the same details.  Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your reply. Please provide me with the schematic diagrams related to your ETH, particularly the ones for PFE_MCA1 and SJA1110 sections. You can create an internal support system case. In the information description, @Joey, then provide your schematic diagram information. Refer to this website: https://support.nxp.com BR Joey Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z , Thank you for the response. The module in question here is a custom design that uses the S32G399A chip along with the NXP SJA1110A ethernet switch. We based this design on the S32G-VNP-RDB3 development platform but we made quite a few changes from the base design. The PFE_MAC1 using RGMII is one of those changes.  I am also attaching the dts file override where we change the PFE_MAC1 mode and pinmux here. PFE_MAC1 mode configuration: /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 pinmux: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; Please let me know if you need any other information.    Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction any schematics sharing from hardware side for RGMII bus between PFE_MAC1 and SJA1110 port 2 ? Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your detail information According to my understanding, there seems to be a problem with the communication when using PFE_MAC1 RGMAII and Port 2 of SJA1110A on your development board. Is that correct? The default configuration of S32G-VNP-RDB3 is that PFE_MAC0/1 operates in SGMII mode and is connected to SJA1110. On your development board, why did you consider using RGMII mode? It is recommended to modify the corresponding software configuration. BR Joey
記事全体を表示
需要 S32K342 FOTA 引导加载程序架构指南(基于 UART 的更新) 您好,NXP团队, 我们正在为 S32K342 开发定制的固件空中升级 (FOTA) 解决方案,希望获得有关推荐的闪存架构和启动流程的指导。 MCU详情 设备:S32K342 PFlash:2 MB 银行 0:1 MB 银行 1:1 MB DFlash:128 KB 当前状态 我们使用UART作为固件更新接口。 目前为止,我们已成功做到: 通过 UART 接收固件(.bin 文件)。 将完整的二进制文件存储到闪存中 确认接收到的图像已正确存储。 我们剩下的挑战是实现引导加载程序架构和应用程序切换机制。 我们希望就以下问题获得澄清: 1. 推荐的FOTA Flash布局 对于 S32K342 双镜像 FOTA 实现,推荐的内存布局是什么? 具体来说,我们想知道以下方面的推荐地点: 引导加载程序 应用插槽 A 应用插槽 B 元数据/启动标志 版本信息 CRC 回滚信息 提供一份包含地址的内存映射示例将非常有帮助。 2. 推荐的启动流程 请问有人能解释一下NXP推荐的完整启动顺序吗? 例如: 重置 引导加载程序启动 检查启动标志 选择活动应用程序 验证图像(CRC/签名) 跳转到应用程序 我们希望能得到流程图或对整个流程的解释。 3. 从引导加载程序跳转到应用程序 对于 S32K342,标准的 Cortex-M7 跳转序列是否足够? 例如: 从应用程序基地址读取 MSP 从基数 + 4 读取 Reset_Handler 设置 MSP 更新 VTOR 跳转到 Reset_Handler 在转移控制权之前,是否有任何 S32K342 特有的要求或初始化步骤? 4. 双应用图像 如果应用 A 和应用 B 位于不同的闪存地址: 每个应用程序都应该有自己的链接脚本吗? 或者,NXP 是否有推荐的构建双槽应用的方法? 5. 闪存库的使用 由于 S32K342 有两个 1 MB 的 PFlash 存储区: 推荐的方法是否是: 从 Bank 0 执行引导加载程序 将新固件编程到 Bank 1 中。 验证成功后切换执行 两个 PFlash 存储体之间是否存在读写限制或擦除/编程限制? 6. 元数据存储 理想的存储地点在哪里? 活动图像标志 图像有效性 Firmware version CRC 回滚状态 这些物品应该存放在: 保留 PFlash DFlash 另一个专用的区域? 7. 基于UART的FOTA 由于我们的更新接口是 UART,我们想知道推荐的工作流程。 以下流程是否正确? 个人电脑 │ UART │ 引导加载程序接收 .bin 文件 │ 将固件存储到非活动闪存插槽中 │ 验证CRC │ 更新启动元数据 │ RESET MCU │ 引导加载程序选择新映像 │ 跳转至应用程序 或者恩智浦是否推荐其他方法? 8. AB_SWAP 与自定义引导加载程序 对于 S32K342 的生产 FOTA 而言,HSE AB_SWAP 是否是强制性的? 或者,具有双应用程序插槽的完全自定义引导加载程序也是一种受支持且常用的架构吗? 如果您有任何专门介绍 S32K342 FOTA、UART 固件更新或双映像引导加载程序的应用笔记、参考项目、引导加载程序示例或文档,我们将非常感谢您提供这些参考资料。 感谢您的支持。 S32K3 S32DS-ARM Re: S32K342 FOTA Bootloader Architecture Guidance Required (UART-Based Update) 你好@bavinkumar_02 1.对于 S32K342,AB_SWAP 只有一种可能的设置。参见“3.5.3.2HSE固件参考手册中提供了“AB_SWAP”模式下闪存布局的图示,该手册可从“文档”->“安全文件”下载: https://www.nxp.com/products/S32K3 就您的情况而言,最方便、最常见的布局是: 必须安装 AB_SWAP 版本的 HSE 固件(交换是 HSE 的一项功能,没有 HSE 固件就无法执行此操作)。固件已安装到两个分区,并且如图所示,它占用了两个分区中最后的 176KB。 因为整个数据块都被交换了,所以两个数据块中必须有完全相同的引导加载程序副本。其余部分分配给申请。 代码始终从活动块运行,因此引导加载程序和所有应用程序都是针对活动块中的地址编译的。 当引导加载程序更新应用程序时,它会将应用程序编程为被动阻塞,因此在闪存编程期间不会出现边读边写的问题。应用程序编程完成后,即可触发 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK HSE 服务。下次RESET后,分区将被交换,引导加载程序将像往常一样跳转到应用程序(跳转到当前活动块中的新应用程序)。 2. 流程取决于应用程序。在现代汽车应用中,简单的基于 CRC 的验证已不再被认为足够。软件的完整性和真实性通常通过安全启动机制来保证。在 S32K3 设备上,这是由硬件网络安全引擎 (HSE) 处理的,它会执行加密验证(例如)。基于签名)在启动过程中自主进行。预计量产汽车系统将利用这些硬件支持的网络安全功能,而不是仅仅依赖 CRC 验证。 我们提供安全启动应用笔记,其中包括演示项目。可从以下网址下载: https://www.nxp.com/products/S32K3 应用笔记请点击此处查看: 文档 -> 安全文件 -> 安全启动应用笔记 v0.1.1.0(AN744511) 相关演示项目可在此处下载: 设计资源 -> 软件 -> 安全文件 -> SecureBootAppNoteDemo (SW745310) 您可以在 HSE 演示示例中找到其他安全启动示例: https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples 三种模式——高级安全启动、基本安全启动和 SHE 安全启动——都有相应的示例。建议启用高级安全启动。 请参阅所有项目中包含的 Readme.md 文件。 3. 是的,这是标准的跳转序列。强烈建议在跳转之前取消初始化引导加载程序初始化的所有资源。 4. 如上所述,代码始终从活动分区执行,因此应用程序始终使用相同的链接器文件。 5. 前面已经讨论过了。 6.这取决于用户。您可以将数据存储在应用程序映像后面,或者存储在数据闪存中。 7. 对于生产汽车用例而言,从数据传输的角度来看,所提出的流程总体上是正确的,但正如前面提到的,我不建议依赖 CRC 作为主要的验证机制。 在汽车应用中,接收到的图像通常会受到加密保护——例如,图像可能会被加密,并且其真实性/完整性会通过数字签名(而不仅仅是 CRC)来验证。 此外,在使用 HSE AB_SWAP 机制时,引导加载程序在 RESET 后不会简单地通过软件元数据选择新映像。新映像被编程到被动分区并成功验证后,应用程序/引导加载程序应调用 HSE 服务 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK。这将激活被动块,因此RESET后设备将从新激活的分区启动。 8. HSE AB_SWAP 并非严格强制要求,但对于 S32K342 上的量产汽车 FOTA 解决方案,强烈建议使用。 如果没有 HSE 就实施 FOTA,那就意味着您没有利用 S32K3 平台的一个关键优势。这些设备的主要优点是内置支持 HSE 处理的 A/B 交换(分区重映射)。如果没有它,引导加载程序就必须手动管理一切。 具体而言,不包括 HSE AB_SWAP: 你需要自己实现一种机制来选择 A/B 图像。 您需要仔细管理地址空间,并将每个应用程序链接到不同的固定位置。 图像之间的切换不会由硬件自动处理,而完全由您的软件处理。 除了 HSE AB 交换功能之外,没有其他硬件支持的重映射机制可用。 此外,您还将失去与 AB_SWAP 集成的安全启动的简洁性和稳健性。借助 HSE,图像激活、验证和分区之间的切换以更加可控和高效的方式进行处理,符合汽车网络安全要求。 总之,虽然不考虑 HSE 也能做到这一点,但这会大大增加复杂性,并消除该平台的关键优势。 您可以查看“S32K3XX HSE 和 OTA 高级培训 [TR744101]”,该培训文档可从以下链接下载:文档 -> 安全文件: https://www.nxp.com/products/S32K3 问候, 卢卡斯
記事全体を表示
Solyball Cooling Ace 专为现代生活而设计 当气温升高时,保持舒适的室内环境成为许多人的首要任务。无论是在家、办公室还是个人工作空间,过高的温度都会影响注意力、放松度和整体舒适度。Solyball 正是为此提供了一个便捷实用的解决方案。Solyball 的设计兼顾便携性、简洁性和现代生活方式,是一款小巧的降温设备,可帮助用户在各种室内环境中营造更舒适的氛围。 Solyball 最显著的特点之一 是其轻巧便携的设计。与笨重难搬或占用大量空间的大型制冷系统不同,Solyball 体积小巧,几乎可以完美融入任何房间。其便携性使用户能够轻松地将其从一个地方搬到另一个地方,从而满足全天候不同需求。无论您是在家办公、在客厅放松,还是准备享受一夜安眠,Solyball 都可以放置在任何您需要额外舒适感的地方。 Solyball 的多功能性 使其成为各种室内环境的理想之选。在卧室里,它有助于在温暖的夜晚营造更舒适的氛围。舒适的睡眠环境对整体健康至关重要,而小巧的降温设备可以提升您的睡眠体验。Solyball 尺寸适中,可轻松放置在床头柜或其他平面上,不会造成空间杂乱。 对于专业人士和远程办公人员来说, Solyball能帮助他们保持舒适的工作空间,从而显著提高工作效率。室内温度过高有时会影响专注力,难以集中精力完成工作。Solyball 提供了一种切实可行的提升工作舒适度的方法,帮助用户在一天中营造更加愉悦的工作环境。其小巧的体积使其可以方便地放置在办公桌或工作台上,而不会占用过多空间。 Solyball的便利性也体现在客厅和家庭共享空间中。这些区域通常是人们聚集的中心场所,他们会在这里看电视、阅读、社交或放松身心。将 Solyball 融入这些空间,用户可以在日常活动中享受更舒适的氛围。其现代外观确保它能与现代家居装饰自然融合。
記事全体を表示
Function of solid plane in the NFC antenna Hello, We have integrated our NFC antenna onto a controller board. Our antenna measures approximately 90 mm x 40 mm and has 3 turns. It is already surrounded by ground planes on two sides. The distance between the ground planes and the antenna is approximately 5 mm. Our PCB manufacturer (of a multi-layer PCB) wants us to fill the antenna area of the inner layers with copper. Since I found NFC demo boards from NXP where this is implemented in a similar way, I think it should work and would like to implement it similarly. Are there any reasons why it was implemented this way on these evaluation boards? To what extent does the copper area affect the range? Does the copper area affect EMC? Is it better or worse? What should be the minimum distance between the copper area and the antenna? Is it better to use a single large area or several small areas? Thank you very much, and best regards, Michael Re: Function of solid plane in the NFC antenna Hello Michael,  The main reason why we use this inner metallization is mainly for a demonstration purpose to simulate a realistic environment around the NFC antenna e.g. in the POS terminal.  Also this metal filling may help to reduce the detuning effect by a different object because the antenna is already tuned with the "metal loading" inside.   However for the real product, I would go for a conventional NFC antenna without any filling inside. BR Tomas  Re: Function of solid plane in the NFC antenna Hi Tomas, Thank you very much for the information. We have since conducted tests by gluing copper tiles (8 mm x 8 mm, spaced 2 mm apart, 2 layers each) to the antenna surface on both the top and bottom. We then measured the antenna and rematched it. We can’t detect any differences in terms of functionality (range, current measurement, and EMI). You wrote that you would recommend a conventional design. Are there reasons for this, and if so, what are they? Maybe several smaller areas with more spacing between them would be better than the 8x8 mm with 2 mm spacing? Thank you very much, Michael Re: Function of solid plane in the NFC antenna Hello @michael_d_1983 , As mentioned, we use the copper tiles to demonstrates a a bit more realistic environment. This means that you may observe a slightly lower reading range, which is more reflecting the reality than an ideal antenna in free space. This because of some energy is absorbed the the metal tiles.  But there is no change in the TX current and EMI, if the tuning stays the same.  Therefore there is no need to implement such design into the "real" product.  BR Tomas  Re: Function of solid plane in the NFC antenna Hi Tomas, Thanks for your feedback! We actually don’t want to include the copper areas at all. The PCB manufacturer wants us to do that. (The reason is that if the copper distribution on the PCB is uneven, problems arise during the lamination process in PCB production—such as air pockets and delamination—because the resin in the prepregs isn’t sufficient to compensate for the missing copper.) We just want to clarify whether there’s any fundamental reason against this that we haven’t considered yet. We’ve tested it (reader functionality). Everything seems to be working as usual. Best regards, Michael
記事全体を表示
使用 i.MX 95 SPSDK 实现安全启动(日本博客) 介绍 本文档描述了使用 安全配置 SDK (SPSDK) 在 i.MX 95 上创建和启动签名容器镜像以进行安全启动的过程。 除了经典的 RSA 和椭圆曲线数字签名 (ECDSA) 之外,i.MX 95 还支持后量子密码 (PQC) ML-DSA 作为安全启动数字签名算法。 在这里,我们将通过一个示例来探讨如何使用混合启动来实现 ECDSA 和 PQC ML-DSA 签名认证。 安全启动过程(概念图) 创建签名图像 SRKH:超级根密钥哈希 i.MX 95 AHAB(高级高精度启动)安全启动流程 本文假设您已经为i.MX 95 构建过一次 Linux BSP。 请参考以下文章了解如何构建该项目。 构建目标必须是 i.MX 95 的机器名称,但方法类似。 【新手指南】如何构建 Yocto Linux BSP - i.MX FRDM 开发板版(日语博客) 【新手指南】如何构建 Yocto Linux BSP - i.MX 8M Plus 版 本次测试所用的环境 硬件: i.MX 95 19x19 LPDDR5 EVK开发板 软件:Linux BSP 版本 L6.18.2-1.0.0 工具:SPSDK 版本 3.9.0Linux 版本 如果您使用 eMMC/SD 启动,则可以对FRDM i.MX 95 开发板(FRDM-IMX95 / LPDDR4X 兼容)执行相同的程序。 目录 1. Linux BSP 的准备工作 2. 安装 SPSDK 3. 密钥创建 4. 准备 YAML 文件 5. 准备工作空间 6. 创建签名图像 7. 引入签名图像 8. SRKH(超级根密钥哈希)eFuse 程序 9. 将生命周期更新为 OEM 关闭。 10. 检查 ELE 事件 11. 直接对引导加载程序进行签名   eMMC/SD启动和FlexSPI NOR启动的准备步骤和命令略有不同。因此,请按照您要测试的启动设备对应的步骤进行操作。 1. Linux BSP 的准备工作 1.1 引导加载程序 FlexSPI NOR 启动 BSP 的默认引导加载程序配置为 eMMC/SD 引导。 对于 FlexSPI NOR 启动,请将以下内容添加到 / /conf/local.conf 文件中。 UBOOT_CONFIG = "fspi" eMMC/SD/FlexSPI NOR启动通用 使用启用了u-boot CONFIG_AHAB_BOOT 的引导加载程序构建。 $ cd $ source setup-environment $ bitbake u-boot-imx -c cleansstate $ bitbake u-boot-imx -c configure $ bitbake u-boot-imx -c devshell 将会打开一个单独的 shell,您可以在其中修改 u-boot 配置。 # make O=../../build/ / menuconfig 使用 O= 指定的构建目录路径应根据您的实际环境进行调整。 ../../build/ /.config然后,确认显示 CONFIG_AHAB_BOOT=y 并返回到原始 shell。 # exit 使用原始 shell 重新构建。 $ bitbake u-boot-imx -c compile -f $ bitbake imx-boot 1.2 Linux 内核和设备树 我们将直接使用用 BSP 构建的二进制文件。 构建好的二进制文件创建在 BSP 的 /tmp/deploy/images/ / 目录中。 2. 安装 SPSDK 请按照SPSDK 安装指南准备和安装 Python 虚拟环境 (venv)。 安装完成后,检查是否可以查看版本信息和帮助。 (venv) $ spsdk --version (venv) $ spsdk --help 我们还将添加 PQC 插件。 (venv) $ pip install spsdk-pqc 3. 密钥创建 我们将为 ECDSA SECP384 创建四对私钥/公钥。 (venv) $ mkdir -p keys/secp384r1 (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk0_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk1_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk2_secp384r1.pem (venv) $ nxpcrypto -v key generate -k secp384r1 -o keys/secp384r1/srk3_secp384r1.pem 我们还将为 PQC ML-DSA 创建四对私钥/公钥。 (venv) $ mkdir keys/mldsa65 (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk0_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk1_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk2_mldsa65.pem (venv) $ nxpcrypto -v key generate -k mldsa65 -o keys/mldsa65/srk3_mldsa65.pem 将公钥哈希(超级根密钥哈希 - SRKH)写入 i.MX 95 的内置 eFuse 后,在重建镜像时,需要使用与该公钥配对的私钥对其进行签名,因此请保存您创建的所有密钥。 我不会将我的私钥透露给任何第三方。 4. 准备 YAML 文件 在 SPSDK 中,YAML 文件指定容器头设置、私钥、公钥以及构成签名镜像的二进制文件的路径。 请同时参考本次操作验证中使用的示例 YAML 文件。 YAML 文件中的容器头部设置和键规范字段如下: 容器头部 YAML 键 内容 srk_set SRK 套装 已使用的 srk_id SRK精选 srk_revoke_mask SRK撤销面具 gdet_runtime_behavior GDET 启用 检查所有签名 请核对所有签名。 口袋 快速启动 熔丝版本 熔丝版 sw_version SW 演化 容器标头中的每个字段都在i.MX 95 参考手册的“容器标头详细信息”部分中进行了描述。 主要规格 YAML 键 内容 签名者 经典私钥 签名者#2 PQC私钥 srk_table 经典公钥表 srk_table_#2 PQC公钥表 在所有 YAML 文件中指定相同的键。 4.1 引导加载程序的 YAML 文件 创建 YAML 文件模板,并准备 spl.yaml 和 uboot.yaml。 (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_template.yaml (venv) $ cp ahab_template.yaml spl.yaml (venv) $ cp ahab_template.yaml uboot.yaml spl.yaml 指定文件,直到它们被加载到 i.MX 95 的内部 SRAM 中,并执行 DRAM 初始化训练等。 YAML 键 内容 二进制容器 ELE 启动固件(特定于掩码版本) lpddr_imem LPDDR4X 或 5 初始化固件 lpddr_imem_qb LPDDR4X 或 5 初始化固件 lpddr_dmem LPDDR4X 或 5 初始化数据 lpddr_dmem_qb LPDDR4X 或 5 初始化数据 oei_ddr OEI 系统管理器 系统管理器 spl U-boot SPL cortex_m7_app(选项) M7图像 image_path(选项) FCB 复制生成 uboot.yaml U-boot SPL 指定要加载到 DRAM 中的文件。 YAML 键 内容 脚气 ARM 可信固件 uboot U-boot T恤(可选) OP-TEE OS(选项) 4.2 移除 FCB - 仅 FlexSPI NOR 启动 用于 FlexSPI NOR 启动的 YAML 文件也指定了 FCB(FlexSPI 配置块)。因此,为 FlexSPI NOR 启动构建的标准未签名引导加载程序 (flash.bin)...接下来,我们将使用 SPSDK 命令提取 FCB。 i.MX 95 内置的 eFuse 的 FCB 位于 FlexSPI_NOR_FCB_Offset(默认值为 0x400)。从该偏移量提取 512 字节以创建 fcb.bin。 (venv) $ nxpimage utils binary-image extract -b flash.bin -a 0x400 -s 0x200 -o fcb.bin 4.3 操作系统容器的 YAML 文件 根据 YAML 文件模板准备 os_cntr.yaml 文件。 (venv) $ cp ahab_template.yaml os_cntr.yaml 在 os_cntr.yaml 中,键image_path设置要使用的 Linux 内核和设备树的路径,并设置其他必要的参数。 4.4 数字签名算法的选择 这将使用 i.MX 95 的内置 eFuse 或容器标头中的标志进行选择。 eFuse 容器头部中的标志字段 通过在容器头的标志字段中设置“位 15:检查所有签名”= 0x1,无论 eFuse 中的 ELE_BOOT_CRYPTO 设置如何,容器内的所有签名都将进行身份验证。 容器标头的 Flags 部分中的“检查所有签名”字段由 YAML 键“check_all_signature”指定。 5. 准备工作空间 在 SPSDK 中创建一个工作区,并将必要的密钥文件、YAML 文件和二进制文件放置在其中。 5.1 创建工作区 (venv) $ nxpimage bootable-image get-templates -f mimx9596 -o workspace 5.2 密钥文件 我会把生成密钥时创建的整个 `keys` 文件夹导入过来。 5.3 YAML 文件示例 用于测试的 YAML 文件附加在imx95-spsdk-yaml-examples.tar.gz中。 5.4 二进制文件 如果您想从 Yocto Linux BSP 获取二进制文件, 构成引导加载程序的二进制文件 从 $ bitbake -e imx-boot | grep ^S= 显示的路径中复制位于 iMX95/ 中的二进制文件。 Linux 内核 / /tmp/deploy/images/ /Image-- - - .bin复制此内容。 设备树 复制位于 / /tmp/deploy/images/ / 目录下的 dtb 文件,选择您想要使用的其中一个。 如果您使用示例 YAML 文件, Linux内核是一个镜像。 设备树文件为 imx95.dtb 它们将被归入这些名称之下。 5.5 eMMC/SD 启动 文件结构如下: 如果使用示例 YAML 文件,请根据 DRAM 类型将 spl.yaml 从 emmc_sd/spl-lpddr4x.yaml 或 spl-lpddr5.yaml 重命名,并将其放置在正确的位置。 在上述示例中,RevC 产品的 ELE 启动固件为 mx95b0-ahab-container.img(B0 掩码)。 5.6 FlexSPI NOR 启动 文件结构如下。此外,还需要 fcb.bin 文件。 如果您想使用示例 YAML 文件,请从 fspi_nor/ 复制 bootable_image_fspi_nor.yaml。 另外,将 spl_fspi_nor-lpddr5.yaml 重命名为 spl.yaml 并将其放置在正确的位置。 在上述示例中,RevC 产品的 ELE 启动固件为 mx95b0-ahab-container.img(B0 掩码)。 6. 创建签名图像 我们将使用 SPSDK 创建已签名的引导加载程序和已签名的操作系统容器镜像。 导航至工作区准备期间创建的目录,并开始在该目录中工作。 (venv) $ cd workspace/imx_boot_flash_all/imx95-19x19-lpddr5-evk/ 6.1 签名引导加载程序 spl.yaml 和 uboot.yaml 文件分别指定密钥文件和二进制文件,它们由 bootable_image.yaml 调用。 将创建一个已签名的引导加载程序 signed_flash.bin 和一个用于 SRKH eFuse 程序的脚本 (*.bcf)。 eMMC/SD启动 (venv) $ nxpimage -v bootable-image export --config bootable_image.yaml -o output/signed_flash.bin 将显示以下信息。 FlexSPI NOR 启动 (venv) $ nxpimage -v bootable-image export --config bootable_image_fspi_nor.yaml -o output/signed_flash.bin 将显示以下信息。 与 eMMC/SD 的一个区别是,它以“FCB”开头。 您可以执行图像验证。 // eMMC / SD ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m serial_downloader // FlexSPI NOR ブート (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/signed_flash.bin -m flexspi_nor 6.2 已签名操作系统容器 os_cntr.yaml 的内容将用于创建已签名的操作系统容器镜像。 (venv) $ nxpimage -v ahab export -c os_cntr.yaml 将显示以下信息。 您可以执行图像验证。 (venv) $ nxpimage -v bootable-image verify -f mimx9596 -b output/os_cntr_signed.bin -m serial_downloader 7. 引入签名图像 本文档解释了如何安装您创建的已签名引导加载程序和已签名操作系统容器。 7.1 签名引导加载程序 将 signed_flash.bin 写入 i.MX95 板的启动设备。 将开发板的调试端口和串口下载端口连接到您的电脑。 如果 u-boot 启动,则切换到 fastboot 模式。 u-boot=> fastboot 0 或者,您可以以串行下载模式启动系统 BOOT_MODE。 我们将使用SPSDK编写程序。 // eMMC (venv) $ nxpuuu write -b emmc -f mimx9596 output/signed_flash.bin // SD (venv) $ nxpuuu write -b sd -f mimx9596 output/signed_flash.bin // FlexSPI NOR (venv) $ nxpuuu write -b qspi -f mimx9596 output/signed_flash.bin 也可以使用标准的 uuu 或 u-boot 命令而不是 SPSDK 的 nxpuuu 命令来刷写设备。 7.2 已签名操作系统容器 将 os_cntr_signed.bin 放入已写入 BSP 映像的 eMMC 或 SD 卡的启动分区中。 u-boot 命令使 i.MX95 连接的 eMMC 或 SD 卡显示为 USB 存储设备,从而可以将其挂载到 PC 上。 串口下载端口必须连接到您的电脑。 // eMMC u-boot=> ums mmc 0 // SDカード u-boot=> ums mmc 1 将 os_cntr_signed.bin 复制到挂载到 PC 上的启动分区后,在 u-boot 中按 Ctrl-C。 或者,您可以使用另一种方法将 os_cntr_signed.bin 放入启动分区。 启动已签名的操作系统容器时,将显示以下消息: CONFIG_AHAB_BOOT 启用u-boot 后,将使用 os_cntr_signed.bin(已签名)镜像,而不是常规的 Linux 镜像(未签名)。 7.3 运行检查 在该阶段,i.MX95 的生命周期状态为 OEM Open,因此 u-boot 或 Linux 将启动,但会在ELE 事件中检测到密钥哈希验证失败。 8. SRKH(超级根密钥哈希)eFuse 程序 8.1 eFuse 写入 将公钥的哈希值写入 i.MX 95 SRKH eFuse。 一旦写入,就无法撤销。 当在写入的设备上更新已签名的引导加载程序或已签名的操作系统容器时,将使用作为写入的 SRKH 底层公钥对的私钥对其进行签名。 如果您想使用不同的密钥对,请撤销当前的 SRKH,并使用您创建的四个未使用的密钥对之一。 将 i.MX 95 板的串行下载端口连接到您的 PC,并事先确保 u-boot 设置为 fastboot 模式。 u-boot=> fastboot 0 SRKH eFuse 编程脚本 (*.bcf) 在创建签名映像期间创建。我们将使用此方法并使用 SPSDK 编写程序。 SRKH eFuse 编程脚本包含 i.MX 95 eFuse 的字索引。 // OEM_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk0_hash_nxpele.bcf // OEM_PQC_SRKH (venv) $ nxpele -f mimx9596 batch output/ahab_oem0_srk1_hash_nxpele.bcf 8.2 检查 eFuse 值 您可以使用 SPSDK 的 nxpele 命令指定 eFuse 的字索引并读取它以检查其值。 // OEM_SRKH[31:0] word index = 128 (venv) $ nxpele -f mimx9596 read-common-fuse -i 128 // OEM_PQC_SRKH[511:480] word index = 463 (venv) nxpele -f mimx9596 read-common-fuse -i 463 など 或者,您可以使用 U-boot 命令或系统管理器监视器命令通过读写操作访问 eFuse,而不是使用 SPSDK。 U-boot u-boot=> 熔丝读取 u-boot=> fuse prog 系统管理器 >$ fuse.H >$ fuse.w 8.3 运行检查 现阶段,i.MX 95 的生命周期状态为 OEM 开放,但由于它已编程为 SRKH,除非被篡改,否则不会检测到ELE 事件。 即使发生篡改,如果该部分不影响操作,它将启动 OEM Open,但身份验证失败将在ELE 事件中检测到。 9. 将生命周期更新为 OEM 关闭。 i.MX 95 在出厂后的生命周期为 OEM 开放式。 调试完成后,将 i.MX 95 生命周期更改为 OEM 关闭。 关闭OEM后需要注意的几点 您无法恢复到OEM Open 模式。 CONFIG_AHAB_BOOT=y 使用包含 u-boot 的引导加载程序启动时,未签名的镜像和签名无效的镜像将无法启动。 CONFIG_AHAB_BOOT=y 如果引导加载程序包含 u-boot 但未进行此设置,则可以使用未签名的 Linux 镜像启动。因此,为确保始终启动操作系统容器 os_cntr_signed.bin,请使用包含 u-boot 且设置了 CONFIG_AHAB_BOOT=y 引导加载程序。 验证功能后,未签名的 Linux 镜像和设备树将从启动分区中删除。 9.1 SPSDK 将 i.MX 95 板的串行下载端口连接到您的 PC,并事先确保 u-boot 设置为 fastboot 模式。 u-boot=> fastboot 0 使用 SPSDK 更新生命周期。 (venv) $ nxpele -f mimx9596 forward-lifecycle-update -l OEM_CLOSED Forward Lifecycle update ends successfully. (venv) $ 9.2 U-boot u-boot=> ahab_close 即使将设备标记为 OEM 关闭,使用 uuu 写入 BSP 映像(wic 文件)时,仍然需要使用签名引导加载程序。 10. 检查 ELE 事件 ELE(Edgelock Secure Enclave)是 i.MX 95 中的一个内置模块,用于在安全启动期间验证容器镜像。 您可以使用 SPSDK、U-boot 和系统管理器命令检查 ELE 状态。 10.1 SPSDK 请先将串口下载端口连接到您的电脑,并使用 U-boot 进入 fastboot 模式,然后再继续操作。 u-boot=> fastboot 0 我们将使用 SPSDK 检索 ELE 事件。 (venv) $ nxpele -f mimx9596 get-events 10.2 U-boot CONFIG_AHAB_BOOT=y 这些是可以与 U-boot 一起使用的命令。 根据设备的生命周期,还会显示它是 OEM 开放式还是 OEM 封闭式。 u-boot=> ahab_status 10.3 系统管理器 >$ ele events 10.4 显示示例 当检测到ELE事件(SRKH值不匹配)时 SPSDK U-boot(当 OEM 打开时) 系统管理器 当未检测到ELE事件时 SPSDK U-boot(OEM 闭环后) 系统管理器   11. 直接对引导加载程序进行签名 也可以使用 SPSDK 直接向现有的未签名引导加载程序二进制文件添加签名。 在这种情况下,SPSDK 会解析来自引导加载程序二进制容器的配置。 虽然不能在 YAML 文件中为每个镜像指定详细设置,但只需指定容器头设置以及私钥和公钥的路径,即可创建签名引导加载程序。 11.1 模板创建 (venv) $ nxpimage ahab get-template -f mimx9596 -o ahab_sign.yaml --sign (venv) $ cp ahab_sign.yaml sign.yaml 11.2 YAML 文件 在 sign.yaml 中指定容器头部设置以及私钥和公钥的路径。 如果您使用的是示例 YAML 文件,请复制 direct_signing/sign.yaml。 11.3 添加签名 现有的引导加载程序二进制文件 flash.bin 将被签名。 // eMMC / SD (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output // FlexSPI NOR (venv) $ nxpimage ahab sign -c sign.yaml -b flash.bin -o output/flash_directsign.bin -fs output -m flexspi_nor output/flash_directsign.bin 和 SRKH eFuse 编程脚本 output/*.bcf这将被创建。 综上所述 本文档介绍了如何使用 SPSDK 为 i.MX 95 安全启动创建签名镜像并启动该镜像,以保护 SoC 启动镜像。本示例演示了如何使用 PQC(i.MX 95 AHAB 中新增的功能)来完成此过程。 ========================= 即使您在本文的“评论”栏留言,我们目前也无法回复。 给您带来不便,我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 (如果您已经是NXP的代理商或与其有合作关系,可以直接向负责人咨询。) 本课程提供实践学习体验,讲解如何使用 安全配置 SDK (SPSDK) 创建和启动签名容器镜像,以便在 i.MX95 上进行安全启动。 本文档提供了一个示例,说明如何在混合启动环境中同时使用椭圆曲线数字签名密码学 (ECDSA) 和后量子密码学 (PQC) ML-DSA 来实现签名认证。 (预计工作时间:半天 *假设 i.MX 95的Linux BSP 构建已经完成一次) i.MX 处理器 安全 日本博客
記事全体を表示
Building AI/ML Devices at the Edge? Start with FRDM From smart sensing and anomaly detection to computer vision, voice recognition, and multimodal GenAI—AI/ML use cases are rapidly moving onto the device. But if you're an engineer getting started, the real questions usually are: What hardware products should I use? What NXP tools actually work for embedded AI applications? Do I need the cloud for anything? Let’s break it down ! Why Edge AI is important? Running AI models directly on-device enables: Real-time decisions (low latency) Better security Offline operation (no cloud dependency) Optimized power consumption That’s exactly where the FRDM development platform comes in Quick Positioning: From MCU to Edge AI Processor Category Boards AI Capability Level Typical Use Case MCU (Low Power Edge ML) FRDM-MCXA156 + ⭐ sensor AI, TinyML MCU + Neural Acceleration FRDM-MCXN947 ++ ⭐⭐ Edge AI with vision/audio, TinyML Application Processor (Entry Edge AI) FRDM-IMX93 +++ ⭐⭐⭐ HMI + AI inference High-Performance Edge AI FRDM-IMX8MPLUS ++++ ⭐⭐⭐⭐ Vision AI, Advanced HMI Next-Gen AI + Safety FRDM-IMX95 / PRO +++++ ⭐⭐⭐⭐⭐ Gen AI, Advanced Edge Computing AI/ML applications can run on general-purpose hardware, but leveraging dedicated hardware acceleration significantly improves performance, enables faster results, and reduces power consumption. Below is a reference list of FRDM development boards that support AI/ML applications, helping you choose the right platform based on your target use case   Board Positioning AI Acceleration Hardware Capabilities (AI-relevant) Best For FRDM-MCXA156 Entry-level MCU (TinyML)  No NPU (CPU-only) Sensors via Expansion headers (Arduino, MikroBUS, Pmod) Parallel display support Sensor ML Anomaly detection Basic TinyML FRDM-MCXN947 MCU with neural acceleration NPU Parallel camera interface (basic) Parallel display Audio (PDM/I2S) Voice AI  Low-res vision Object classification Anomaly Detection FRDM-IMX93 Entry Edge AI MPU NPU  MIPI CSI camera Display (MIPI DSI/LVDS) Audio + connectivity Smart HMI Light vision AI Edge gateways FRDM-IMX8MPLUS Advanced Multimedia + Edge AI platform NPU Multi-camera (MIPI CSI) High-res display (HDMI/DSI)  Audio DSP Connectivity (Wi-Fi, BLE, Ethernet) Some PCIe expansion Computer vision Object detection Industrial AI FRDM-IMX95 Next-gen AI + real-time MPU Next-gen NPU + heterogeneous compute Multi-camera pipelines Advanced HMI Industrial connectivity M.2 expansion(Up to 1 AI accelerators) Robotics Industrial AI Safety applications FRDM-IMX95-PRO Full-featured AI dev platform High-performance NPU + scalable AI (Ara240 Discrete NPU)  Multi-camera Advanced display M.2 expansion (Up to 2 AI accelerators) Advanced AI prototyping Gen AI Edge servers Edge computing  Software and tools for ML/AI applications   GoPoint GoPoint accelerates AI/ML evaluation on FRDM platforms powered by i.MX application processors by providing a ready-to-use, graphical environment with pre-integrated demos. Developers can quickly run applications such as image classification, object detection, and voice recognition directly on the hardware without complex setup. These demos are already optimized for available compute resources—including CPU, GPU, DSP, and NPU—allowing users to immediately visualize performance and understand how AI workloads map to the system. This makes GoPoint an ideal starting point for exploring edge AI capabilities and validating use cases before moving into full application development. Application Code Hub (ACH) Application Code Hub complements rapid evaluation tools by offering a centralized repository of reusable, production-oriented software examples for FRDM boards. It provides full application projects, source code, and documentation that developers can directly import into MCUXpresso IDE or VS Code. With filtering based on use case—such as vision AI, audio processing, or anomaly detection, ACH enables developers to quickly find and customize reference implementations. This helps bridge the gap between proof-of-concept and real product development, significantly reducing development time while enabling scalable AI/ML application design. Application Code Hub Guide eIQ Time Series Studio (TSS) eIQ Time Series Studio is purpose-built for developing AI models based on sensor and time-series data, making it highly relevant for FRDM-based edge intelligence applications. It provides a guided workflow for data collection, labeling, model training, and validation, all optimized for MCU-class devices. Developers can easily transform raw sensor data—such as vibration, motion, or environmental signals—into deployable machine learning models for use cases like predictive maintenance, anomaly detection, and condition monitoring. With built-in analytics and seamless deployment to FRDM boards, TSS simplifies the path from data to intelligent behavior on the edge. eIQ AI/ML Software Environment The eIQ software environment is the foundation that enables AI/ML development across the entire FRDM ecosystem, providing an end-to-end workflow from model creation to on-device inference. It supports importing and optimizing models from popular frameworks such as TensorFlow, PyTorch, and ONNX, and integrates tightly with MCUXpresso and Linux-based environments. eIQ includes tools for model optimization—such as quantization and pruning—as well as runtime engines designed for efficient execution on CPUs, DSPs, and NPUs. By combining these capabilities with hardware acceleration available on FRDM boards, eIQ allows developers to build, deploy, and run real-time AI applications directly on embedded devices with minimal reliance on cloud computing. eIQ Training Curriculum FQA What is an NPU ? A Neural Processing Unit (NPU) in the FRDM platform is a dedicated hardware accelerator integrated into certain microcontrollers (such as the MCX-N family) that is specifically designed to execute machine learning and neural network workloads efficiently. Unlike general-purpose CPUs, the NPU is optimized for the mathematical operations used in AI models, enabling significantly faster inference—up to tens of times higher throughput—while consuming less power. In FRDM boards, the NPU works alongside the CPU and DSP to offload complex AI computations, allowing real-time processing for applications such as image recognition, voice detection, and sensor-based anomaly detection directly on the device. Combined with NXP’s eIQ® software environment, the NPU becomes the core execution engine that transforms FRDM platforms into efficient, low-power edge AI systems capable of running intelligent applications without relying on the cloud What is a Discrete NPU? A Discrete Neural Processing Unit (DNPU) is a standalone AI accelerator designed specifically to execute machine learning and neural network workloads efficiently. Unlike integrated NPUs that are built into a processor, a DNPU exists as a separate chip or module that can be added to a system. It offloads compute-intensive AI operations, such as matrix multiplications and deep learning inference from the main CPU or GPU, delivering significantly higher performance and better energy efficiency. This makes DNPUs ideal for advanced edge AI applications like computer vision, generative AI, and real-time multimodal processing. How do I use Ara modules (DNPU) with FRDM boards? Ara modules, based on NXP’s DNPU technology, can be used with compatible FRDM boards to extend AI processing capabilities. On supported i.MX-based FRDM platforms such as FRDM-IMX95 or FRDM-IMX95-PRO—developers can connect Ara modules (e.g., Ara240) through the M.2 expansion interface. Once connected, the Ara module works alongside the main processor to offload complex AI workloads, enabling faster inference, lower latency, and improved power efficiency. Using the eIQ® AI software environment, developers can prototype and validate models on FRDM, then scale performance by enabling Ara acceleration, creating a seamless path from development to high-performance edge AI deployment. From TinyML to advanced edge AI and GenAI, discover how to build intelligent systems directly on-device with FRDM, no cloud dependency required. FRDM-IMX8 FRDM-IMX8MP FRDM-IMX9 FRDM-MCXN i.MX Application Processors MCU
記事全体を表示
RT1064 I2C 通信异常,频率为 400kHz RT1064 设备的 I2C2 接口连接到模块 A。在 400kHz 频率下出现通信异常,但在 100kHz 频率下工作正常。 1. 将同一系列中不同型号的模块 B 以 400kHz 的频率连接没有问题。 2. 从波形上看,这相当于主机时钟在连接到模块 A 后被拉伸然后恢复时发生的异常情况。 PS:将该设备的 I2C 驱动程序移植到另一台 1064 设备上,测试模块 A,在 400k 功耗下未发现问题。 原因可能是什么? 图 1 模块 A 逻辑分析仪在 400kHz 下的异常波形 图 2:模块 A 在 100kHz 下的逻辑分析仪波形 图3:模块B在400kHz时的波形 i.MX RT106x Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 感谢您的进一步说明——这是一个非常重要的发现。   根据您的观察,该问题似乎更有可能是由于两级 ADUM1251 隔离链路导致的 400 kHz I2C 时序裕量不足,而不是模块 A 本身的异常。 即使上升时间在规格范围内,在 RT1064 上,我们仍然建议检查 LPI2C 主侧 400 kHz 配置,特别是 MCFGR2[FILTSCL/FILTSDA] 和 MCCR0/MCCR1,因为 RT1064 上的主同步延迟不仅受上升时间的影响,还受数字滤波器和定时参数设置的影响。 我们建议您阅读项目中实际使用的配置,并将其与 RT1064 参考手册第 47 章中的表 47-5“LPI2C 示例时序配置”进行比较。 请特别检查以下设置是否与您所选时钟条件的示例值相符: I2C模块时钟源 目标波特率:400Kbps 预分频 FILTSCL/FILTSDA SETHOLD CLKLO CLKHI DATAVD 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 补充信息:昨天在定位方面取得了一些进展: 我们的硬件扩容计划如下: 主板:RT1064--- ADUM1251 3.3V 至 5 V 子板:ADUM1251-模块A 5V转3.3V 经验证,在硬件链路的两层中添加 ADUM1251 后,模块 A 的通信出现异常。但移除 ADUM1251 后,通信在 400k 处恢复正常。造成这种情况的原因可能是什么? PS:我们的硬件工程师认为 ADUM1251 只会增加通信延迟,不会产生其他影响。 Re: RT1064 I2C communication abnormality at 400kHz 你好,@mayliu1 我们的产品即将发布,我们已经调查这个问题好几天了。如果您能尽快回复,我们将不胜感激! Re: RT1064 I2C communication abnormality at 400kHz HI 补充信息 1.我们的两位硬件工程师使用示波器检查了故障波形,上升时间符合要求,在 100ns 以上。 2. 我将 I2C 初始化和读写功能驱动程序移植到另一种 RT1064 设备,并测试了模块 A,没有发现任何问题。 下图显示了另一个设备模块 A 的测试逻辑分析仪的波形。 怀疑: 1.如果时钟在拉伸后恢复异常,还有哪些其他原因可能导致这种情况? 2. 是否有专门的功能来设置上次回复中提到的 MCFGR2 等设置?我没有看到在 I2C 初始化过程中需要设置任何接口。 ----如果上升时间满足要求,我们是否就不需要考虑这些寄存器设置了? Re: RT1064 I2C communication abnormality at 400kHz 嗨@foreverwlh2025 , 非常感谢您对我们产品的关注以及对我们社区的使用。 我认为这很可能不是 A 模块的问题,而是该特定 RT1064 LPI2C2 总线上的 400 kHz 时序裕量问题。 在 RT1064 上,LPI2C 时序受总线上升时间、总线负载、上拉电阻和毛刺滤波器延迟的影响。 RT1064RM 参考手册指出,上升时间越大,同步延迟就越高。(参见第 47.3.1.4 章)时序参数) 主故障滤波器 MCFGR2[FILTSCL/FILTSDA] 必须设置,使其延迟保持在最小 SCL 低/高周期以下,RT1064 在 MCCR0/MCCR1 中提供了 400 kbps 定时设置的示例。请查看表 47-5。LPI2C 示例时序配置 因此,如果模块 A 使总线边沿稍微变慢或改变有效负载,则总线可能在 400 kHz 时发生故障,但在 100 kHz 时仍然可以工作。 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz RT1064 参考手册中没有列出 400 kbps 的 10 MHz LPI2C 功能时钟。 虽然可以使用此时钟生成 400 kbps 波特率,但应根据 I2C 规范仔细验证自动生成的定时参数,特别是 tLOW、tHIGH、建立/保持定时和数据有效定时。 为降低设计风险,建议使用经过验证的时钟源,例如 48 MHz,如参考手册所示。 Re: RT1064 I2C communication abnormality at 400kHz 以下是打印配置。可能需要调整哪个参数? PS:显然是由于自动接口分配造成的 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 您可以尝试直接设置寄存器。 例如,当使用 60 MHz I2C 时钟时,可以采用以下配置。 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 当前的 I2C 时钟是基于 SDK2_13_0-EVK-MIMXRT1064 板 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c 目录中的示例配置进行配置的。 #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); 我该如何修改才能获得精确的 8MHz 或 48MHz 频率?(时钟树似乎看不见) Re: RT1064 I2C communication abnormality at 400kHz 我尝试将频率修改为 60MHz 和 8MHz,但仍然无效。下图中的红色方框显示的是修改后打印的值,这些值与手册中的值不同。 Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 配置 I2C 时钟有多种方法。 建议您尝试 8 MHz 和 60 MHz,因为这两个时钟设置相对容易实现。 我正在使用 SDK 演示版: "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" 方法一:将 LPI2C 时钟源配置为 60 MHz 只需将时钟分频器设置为 0 即可。 方法二:将 LPI2C 时钟源配置为 8 MHz 使用 MCUXpresso IDE 时钟工具并按如下所示进行配置。选择 OSC_CLK 作为时钟源,并将分频器设置为 3,这将为 LPI2C (I2C) 模块生成 8 MHz 时钟。 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 如图所示,我尝试修改寄存器设置以匹配参数,但在 60MHz 下性能没有提升;即使是性能良好的模块在 8MHz 下也无法正常工作。 Re: RT1064 I2C communication abnormality at 400kHz 原因已查明,出现问题的模块将在 400k 时出现时钟拉伸现象。 但是我们使用的隔离器芯片不支持 SCL 双向。更换隔离芯片后, 测试结果正常;此订单可以结案。
記事全体を表示
MCX N947 TFLM モデルランナーによるNeutron変換モデルの推論 TFLM modelrunnerのHTTPを使って、FRDM MCXN947(CPUとNPU)で多数のtfliteモデル(<500KBサイズ)をベンチマークしたいと思っています。 問題は、CPU推論がすべてのモデルで機能せず、NPU推論も全く機能しないことです。 ハードウェア: - FRDM-MCXN947開発ボード(USBとイーサネットでWindowsマシンにコネクテッド) ソフトウェアとツールのセットアップ: - ホスト:Windows 11マシン - eIQ Neutron SDK: eiq-neutron-sdk-windows-3.0.1 - MCUXpresso SDKs:SDK_26_03_00_FRDM-MCXN947 - SDKsからのプロジェクト:frdmmcxn947_tflm_modelrunner_cm33_core0 CPU推論のためのMLモデル: - ad01_int8.tflite - kws_ref_model.tflite - pretrainedResnet_quant.tflite - vww_96_int8.tflite Neutronコンバータ(eIQ Neutron SDKの一部)で変換されたNeutronのMLモデル(NPU推論用): eiq-neutron-sdk-windows-3.0.1\bin neutron-converter --target mcxn94x --input ad01_int8.tflite --output ad01_int8_converted_3_0_1.tflite - ad01_int8_converted_3_0_1.tflite - kws_ref_model_converted_3_0_1.tflite - pretrainedResnet_quant_converted_3_0_1.tflite - vww_96_int8_converted_3_0_1.tflite 実施されたステップ 1. 最新のeIQ Neutron SDKライブラリでeIQプロジェクトを更新する コピー先: eiq-neutron-sdk-windows-3.0.1\target\mcxn94x\common\include\NeutronErrors.h eiq-neutron-sdk-windows-3.0.1\target\mcxn94x\driver\include\NeutronDriver.h eiq-neutron-sdk-windows-3.0.1\target\mcxn94x\mcxn\libNeutronDriver.a eiq-neutron-sdk-windows-3.0.1\target\mcxn94x\mcxn\libNeutronFirmware.a に: frdmmcxn947_tflm_modelrunner_cm33_core0\include\NeutronErrors.h frdmmcxn947_tflm_modelrunner_cm33_core0\driver_include\NeutronDriver.h frdmmcxn947_tflm_modelrunner_cm33_core0\mcxn\libNeutronDriver.a frdmmcxn947_tflm_modelrunner_cm33_core0\mcxn\libNeutronFirmware.a 2. vscodeを使用してプロジェクト「frdmmcxn947_tflm_modelrunner_cm33_core0」をビルドしてフラッシュします。 3. フラッシュ済みのTFLM Modelrunnerを使用してHTTP経由で推論を実行します。 指示: curl -X PUT http://192.168.178.75:10818/v1-F "block_content=@C:\ \ad01_int8.tflite" シリアルモニター経由の出力: .... 実行時間: 6.167000ms 指示: curl -X PUT http://192.168.178.75:10818/v1-F "block_content=@C:\ \vww_96_int8.tflite" シリアルモニター経由の出力: .... 実行時間: 182.042000ms 他のモデルでは動作しません 出力: a) フラッシュ後の推論なし: FLASH 0x104000 消去、プログラム at 104000: 16384 bytes == フラッシュ0x108000消去済み、プログラム108000:16384バイト == フラッシュ0x10c000 消去、プログラム10c000:16384バイト == FLASH 0x110000 消去、プログラム 110000 で:16384バイト == フラッシュ0x114000消去済み、プログラム114000:16384バイト == FLASH 0x118000 消去、プログラム118000:16384バイト == フラッシュ0x11c000消去、プログラム11c000:16384バイト == FLASH 0x120000 消去、プログラム at 120000: 16384バイト == FLASH 0x124000 消去済み、プログラム124000:16384バイト == FLASH 0x128000 消去、プログラム at 128000: 16384 bytes == フラッシュ0x12c000消去、プログラム12c000:16384バイト == FLASH 0x130000 消去、プログラム at 130000: 16384 bytes == フラッシュ0x134000消去済み、プログラム134000:16384バイト == FLASH 0x138000 消去、プログラム 138000:544バイト == b) フラッシュ処理が全くありません c) 誤HardFault_Handler 343行目: ldr r0,=HardFault_Handler で SDK_26_03_00_FRDM-MCXN947\mcuxsdk\devices\MCX\MCXN\MCXN947\gcc\startup_MCXN947_cm33_core0.S デバッガーによって停止されました どんなヒントでも大歓迎です! MCX N Re: MCX N947 TFLM Modelrunner Inference of Neutron Converted Models こんにちは、 @Laurens26さん 問題は純粋な「モデルサイズ」の問題というよりも、バージョンの整合性が混ざっている可能性が高いと思います。 このリンクを参照してもいいと思います。 最新のeIQ Neutron SDKライブラリでeIQプロジェクトを更新する方法 BR ハリー
記事全体を表示
MPC5647 闪存无法访问 我们使用的是 MPC5647 设备。 我们使用Trace32,将一个应用程序编程写入了内部闪存区域。编程过程刚开始(或刚一完成),目标硬件的电源就被切断了。 此事件发生后,便无法再访问应用区域中的闪存。通过Trace32访问Flash时,内存内容显示为"????????" ,或者"FFFFFFFF" 。我们怀疑是在Flash编程操作尚未完全结束之前就切断了电源。 在此情况下,应用闪存区域将无法使用,且只能通过执行 AN4521_MPC56xx C90FL Flash Recovery.pdf 中所述的出厂恢复程序来恢复闪存。执行恢复操作后,闪存即可再次使用。 我们希望了解以下内容: 是什么原因导致了这种现象? 为什么在闪存编程过程中发生意外断电会导致无法访问该闪存块? 为什么不能直接对闪存进行重新编程呢? 为什么在重新对闪存进行编程之前,必须先执行恢复/出厂初始化操作? 这是否与无效的 ECC 状态、不完整的擦除操作,还是其他闪存控制器内部状况有关? 如果能对Flash的内部工作原理进行详细说明,我们将不胜感激。 Re: MPC5647 Flash Inaccessibility 你好 此事件发生后,便无法再访问应用区域中的闪存。通过Trace32访问Flash时,内存内容显示为"????????" ,或者"FFFFFFFF" 。我们怀疑是在Flash编程操作尚未完全结束之前就切断了电源。 这表明闪存可能已损坏。 在此情况下,应用闪存区域将无法使用,且只能通过执行 AN4521_MPC56xx C90FL Flash Recovery.pdf 中所述的出厂恢复程序来恢复闪存。执行恢复操作后,闪存即可再次使用。 这肯定是编程过程中因断电导致的闪存损坏。闪存中存在大量ECC错误,这就是为什么你在跟踪信息中看到“?????”的原因。 为什么在闪存编程过程中发生意外断电会导致无法访问该闪存块? 简而言之,如果您未完成编程或进行了擦除,闪存数据将出现不匹配,并伴随ECC症状。 为什么在重新对闪存进行编程之前,必须先执行恢复/出厂初始化操作? 标准程序命令期望获得一个已彻底擦除的块 中断后: 控制器检测到无效状态 → 拒绝命令 因此: 擦除/编程序列始终无法正确启动 访问可能被阻止或返回虚假数据 这是否与无效的 ECC 状态、不完整的擦除操作,还是其他闪存控制器内部状况有关? 因电源中断而进入ECC状态。 顺祝商祺! Peter
記事全体を表示
Exporting YOLO Models for NXP i.MX Platforms In this post, we will review the YOLO model export process for three popular NXP families: i.MX8MP, i.MX93, and i.MX95. These processors are increasingly used in edge AI applications such as smart vision, industrial automation, robotics, and intelligent HMI systems. Although they all support machine learning deployment, the export path, supported runtimes, and hardware acceleration options may differ depending on the device. The purpose of this guide is to provide a clearer starting point for developers who want to take a trained YOLO model and prepare it for execution on these i.MX platforms. Whether your workflow targets CPU, NPU. YOLO Model Export Workflow for i.MX Processors 1) Install Ultralytics Install or upgrade the Ultralytics package from PyPI: pip install -U ultralytics 2) Export the YOLO Model (TFLite INT8) Export your trained YOLO model to TensorFlow Lite (TFLite) format with INT8 quantization: yolo export model= .pt format=saved_model quantize=8 Example: yolo export model=yolov8n.pt format=saved_model quantize=8 Notes: The model must be exported in TFLite format and fully INT8 quantized. After the export process, a directory named " _saved_model" Inside this directory, you should use the following file as the input for the converter called " _full_integer_quant.tflite "  This is the fully quantized INT8 model required for NPU deployment. Using any other file from the export directory may result in compatibility issues or prevent proper NPU acceleration. After obtaining the *_full_integer_quant.tflite file, you can proceed with the needed conversion workflow to generate the final model optimized for execution on the NPU. For additional valid export options, please refer to the official Ultralytics documentation: https://docs.ultralytics.com/modes/export/ At this stage: The model can run on CPU for: i.MX8MP i.MX93 i.MX95 On i.MX8MP, this TFLite model can also be deployed to the NPU using the appropriate delegate. 3) i.MX93  Compile for Ethos-U NPU (Vela) For i.MX93, an additional compilation step is required to use the Ethos-U NPU. Run the Vela compiler to convert the TFLite model into an optimized format: vela .tflite --output-dir Notes: This step generates a model optimized for the Ethos-U NPU. The resulting output files are required for deployment using the NPU delegate on the i.MX93 platform. Please ensure that the model complies with the Ethos-U operator constraints, as only supported operations can be accelerated by the NPU. This command can be executed directly on the i.MX93 target, or alternatively by using the eIQ Toolkit (please refer to the eIQ Converter documentation for more details). 4)  i.MX95 Convert Model Using Neutron SDK For i.MX95, the model must be converted using the Neutron Converter, depending on the BSP version installed on your board. .\neutron-converter.exe ` --input " .tflite" ` --target imx95 ` --output " .tflite" ` --optimization-level OOpt Notes: The Neutron toolchain prepares the model for i.MX95 NPU acceleration. Supported formats and flags may vary depending on the Neutron SDK version. Always verify compatibility with your BSP release. You can check the compatibility details of the Neutron SDK in the "docs" folder of your downloaded Neutron SDK package. 5) Benchmark the Model After exporting and converting the model, you can validate performance using benchmarking tools. Typical options include: TFLite benchmark tool (CPU / delegate): benchmark_model --graph= .tflite --num_threads=X 6) Results iMX8MP CPU root@imx8mpevk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --mum_threads=4 INFO: STARTING! WARN: Unconsumed cmdline flags: --mum_threads=4 INFO: Log parameter values verbosely: [0] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 86.368ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=1 curr=1029584 p5=1029584 median=1029584 p95=1029584 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=986237 curr=985536 min=983921 max=993982 avg=985863 std=1497 p5=984152 median=985947 p95=986715 INFO: Inference timings in us: Init: 86368, First inference: 1029584, Warmup (avg): 1.02958e+06, Inference (avg): 985863 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=11.207 overall=40.918 root@imx8mpevk:~# NPU root@imx8mpevk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --num_threads=4 --external_delegate_path=/usr/lib/libvx_delegate.so INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [4] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [4] INFO: #threads used for CPU inference: [4] INFO: External delegate path: [/usr/lib/libvx_delegate.so] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Vx delegate: allowed_cache_mode set to 0. INFO: Vx delegate: device num set to 0. INFO: Vx delegate: allowed_builtin_code set to 0. INFO: Vx delegate: error_during_init set to 0. INFO: Vx delegate: error_during_prepare set to 0. INFO: Vx delegate: error_during_invoke set to 0. INFO: EXTERNAL delegate created. INFO: Explicitly applied EXTERNAL delegate, and the model graph will be completely executed by the delegate. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 39.515ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=1 curr=16831746 p5=16831746 median=16831746 p95=16831746 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=67167 curr=67190 min=67048 max=67366 avg=67187 std=64 p5=67094 median=67184 p95=67295 INFO: Inference timings in us: Init: 39515, First inference: 16831746, Warmup (avg): 1.68317e+07, Inference (avg): 67187 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=9.47266 overall=224.398 root@imx8mpevk:~# iMX93 CPU root@imx93evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --num_threads=2 INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [2] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [2] INFO: #threads used for CPU inference: [2] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 57.963ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=3 first=247896 curr=198973 min=198973 max=247896 avg=215381 std=22991 p5=198973 median=199275 p95=247896 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=199533 curr=198880 min=197719 max=205262 avg=199032 std=1005 p5=198344 median=198886 p95=199961 INFO: Inference timings in us: Init: 57963, First inference: 247896, Warmup (avg): 215381, Inference (avg): 199032 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=11.2539 overall=40.9961 root@imx93evk:~# NPU root@imx93evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant_vela.tflite --num_threads=2 --external_delegate_path=/usr/lib/libethosu_delegate.so INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [2] INFO: Graph: [yolov8n_full_integer_quant_vela.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [2] INFO: #threads used for CPU inference: [2] INFO: External delegate path: [/usr/lib/libethosu_delegate.so] INFO: Loaded model yolov8n_full_integer_quant_vela.tflite INFO: Ethosu delegate: device_name set to /dev/ethosu0. INFO: Ethosu delegate: cache_file_path set to . INFO: Ethosu delegate: timeout set to 60000000000. INFO: Ethosu delegate: enable_cycle_counter set to 0. INFO: Ethosu delegate: enable_profiling set to 0. INFO: Ethosu delegate: profiling_buffer_size set to 2048. INFO: Ethosu delegate: pmu_event0 set to 0. INFO: Ethosu delegate: pmu_event1 set to 0. INFO: Ethosu delegate: pmu_event2 set to 0. INFO: Ethosu delegate: pmu_event3 set to 0. INFO: EXTERNAL delegate created. INFO: EthosuDelegate: 8 nodes delegated out of 15 nodes with 8 partitions. INFO: Explicitly applied EXTERNAL delegate, and the model graph will be partially executed by the delegate w/ 8 delegate kernels. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 2.9511 INFO: Initialized session in 638.148ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=7 first=87215 curr=81264 min=81079 max=87215 avg=82056.4 std=2107 p5=81079 median=81187 p95=87215 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=81497 curr=81232 min=80887 max=81783 avg=81153.1 std=178 p5=80921 median=81148 p95=81497 INFO: Inference timings in us: Init: 638148, First inference: 87215, Warmup (avg): 82056.4, Inference (avg): 81153.1 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=7.36328 overall=8.73828 root@imx93evk:~# iMX95 CPU root@imx95evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant.tflite --num_threads=6 INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [6] INFO: Graph: [yolov8n_full_integer_quant.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [6] INFO: #threads used for CPU inference: [6] INFO: Loaded model yolov8n_full_integer_quant.tflite INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.42652 INFO: Initialized session in 35.268ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=7 first=115073 curr=74468 min=74170 max=115073 avg=80310.4 std=14192 p5=74170 median=74581 p95=115073 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=74143 curr=74135 min=73657 max=76392 avg=74346.9 std=447 p5=73829 median=74307 p95=75020 INFO: Inference timings in us: Init: 35268, First inference: 115073, Warmup (avg): 80310.4, Inference (avg): 74346.9 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=11.5195 overall=40.8867 root@imx95evk:~# NPU: root@imx95evk:~# /usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model --graph=yolov8n_full_integer_quant_neutron.tflite --num_threads=6 --external_delegate_path=/usr/lib/libneutron_delegate.so INFO: STARTING! INFO: Log parameter values verbosely: [0] INFO: Num threads: [6] INFO: Graph: [yolov8n_full_integer_quant_neutron.tflite] INFO: Signature to run: [] INFO: #threads used for CPU inference: [6] INFO: #threads used for CPU inference: [6] INFO: External delegate path: [/usr/lib/libneutron_delegate.so] INFO: Loaded model yolov8n_full_integer_quant_neutron.tflite INFO: EXTERNAL delegate created. INFO: NeutronDelegate delegate: 1 nodes delegated out of 33 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-7399a58e, zerocp enabled. INFO: Explicitly applied EXTERNAL delegate, and the model graph will be partially executed by the delegate w/ 1 delegate kernels. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: The input model file size (MB): 3.20989 INFO: Initialized session in 12.756ms. INFO: Running benchmark for at least 1 iterations and at least 0.5 seconds but terminate if exceeding 150 seconds. INFO: count=17 first=31509 curr=27588 min=27555 max=31509 avg=29101.2 std=1166 p5=27555 median=29071 p95=31509 INFO: Running benchmark for at least 50 iterations and at least 1 seconds but terminate if exceeding 150 seconds. INFO: count=50 first=28068 curr=29081 min=26573 max=31340 avg=29104.1 std=1204 p5=27306 median=29141 p95=31171 INFO: Inference timings in us: Init: 12756, First inference: 31509, Warmup (avg): 29101.2, Inference (avg): 29104.1 INFO: Note: as the benchmark tool itself affects memory footprint, the following is only APPROXIMATE to the actual memory footprint of the model at runtime. Take the information at your discretion. INFO: Memory footprint delta from the start of the tool (MB): init=6.98438 overall=12.2344 root@imx95evk:~ Disclaimer: Ultralytics YOLO models have not been officially validated/supported by NXP. Therefore, compatibility with i.MX processors and their corresponding NPUs cannot be guaranteed. Some models or configurations may not work as expected depending on operator support and hardware limitations.
記事全体を表示
s32k322 EMAC RMII 问题 您好, 我们 我们 使用 的 恩智浦 S32K322 微控制器 并 经历 以太网 以太网 接收 问题: TX 传输 正常工作 正常、 但 RX 接收 不 不 功能.关于 硬件 硬件方面 硬件方面、 硬件方面 RMII 接口 是 直接 与 直接连接到 以太网 以太网 交换机、 并且 我们 我们 验证了 开关 电路板 PCB 迹线 长度 匹配 和 阻抗 控制 满足 设计 设计 符合设计要求。用于 功率 排序、 我们 目前 确保 手动 确保 开关 开关 完成 其 开机 之前 在 S32K322。 测试期间 测试期间、 我们 我们 开关 开关 发送 ARP 数据包 并 已 测量到 测量了 与 RX 信号 波形 用 示波器 示波器、 所有 所有 所有 看起来 正确。然而 然而 S32K322 EMAC 不 不 进入 接收 接收 中断 (与 相同 波形 成功 成功 接收到 在 另一个 ECU 平台)。我们 我们还 还 检查了 我们还检查了 EMAC 接收 和 错误 计数器 中的 寄存器中的 和错误计数器、 和 都 读取 为 零.所有 时钟 频率 配置 已 已 时钟频率配置 频率配置 正确。 正确。请 帮助 提供 额外的 故障排除 意见 或 建议。   顺祝商祺! 李永祥 Re: s32k322 EMAC RMII issue 你好@PavelL、 感谢您的答复。我们已经检查了所提供的一些要点。 只有在交换机完全启动并运行(确认与其他端口通信)后,才会接通 MCU 的电源。我们增加了图中所示的延迟,但无济于事。 我们检查了时钟并重新配置了它,但 RX 计数器仍然没有显示新的计数。 在外设配置中选择 RMII 模式。 交换机可以从 TX 方向正确接收和转发 RMII 帧到其他端口,因此交换机配置似乎是正确的。我们还扫描了交换机和 MCU RX0/RX1 信号提供的 TXCLK,波形看起来很好,交换机的帧没有明显问题。 我们正在对照参考示例进行交叉检查。 我们使用的是 RTD 6.0.0。测试项目附后,以供验证(代码混乱,敬请原谅,这是测试固件)。   顺祝商祺! 李永祥 Re: s32k322 EMAC RMII issue 你好@YongxiangLi、 有几个方面看起来值得首先检查。 由于发送工作正常,但 RX 数据包计数器和 RX 错误计数器都保持为 0,我目前怀疑 EMAC 根本无法识别有效的 RMII 接收活动,而不是接收帧后再丢弃它们。   最重要的检查是   1) 初始化期间的 RMII 参考时钟计时 在执行 emac/引脚/时钟初始化之前,请验证来自交换机的外部 50 MHz RMII 参考时钟是否已经存在并稳定在 S32K322 引脚上。很可能需要增加较小的延迟,正如 S32K3-T-BOX 所建议的那样。另请注意下面代码片段的第一行: 2) MCU 内部的 RMII 时钟配置 对于 S32K3 RMII,MAC 在 EMAC_MII_RMII_TX_CLK 上使用 50 MHz 的 RMII 参考时钟,而外部 RX_CLK 引脚不在 RMII 模式下使用。但是,仍需要正确配置内部 EMAC RX/TX 时钟(100 Mbps 通常为 25 MHz,源自 50 MHz RMII 参考时钟)。请仔细检查 EMAC 时钟多路复用器/分频器设置。 用于 S32K3 的 RMII 时钟 3) RMII 模式选择 请确认 gmac 驱动程序(用于 EMAC 外设)确实配置为 RMII 模式(而非 MII),并且在初始化过程中尽早进行了选择。   4) 开关侧 RMII 模式 由于您的 MAC 直接连接到交换机端口,而不是分立的 PHY,因此还请验证交换机端口是否真正配置为 RMII/rev-RMII 运行,并且正在向 MCU 驱动正确的 50 MHz 参考时钟。   5) 或者,您可以将您的项目与我的 S32K344 EMAC lwIP 项目进行比较 S32K 示例   为了缩小范围,请与我们分享一下: - 您使用的是哪个版本的 S32K3 RTD 驱动程序? - 能否至少分享您项目的简约版本或 mex 文件?   顺祝商祺! 帕维尔 Re: s32k322 EMAC RMII issue 你好@YongxiangLi、 我仔细审查了您的项目,对每个细节都格外关注。我实在想不出Rx为什么对你不起作用。虽然有些细节可以调整,但这些调整微乎其微。 您使用的是哪种 VDD_HV_B? 作为诊断步骤,您还可以尝试在 GMAC 驱动程序中启用混杂模式。 这样,MAC 就能接受所有传入帧,而不受目标 MAC 地址过滤的限制,这有助于判断问题是与帧过滤相关,还是接收路径在更底层出现了故障。 如果启用混杂模式后行为未发生改变,且接收计数器仍保持为零,那么问题很可能出在数据包过滤层之下(例如 RMII 时钟、接收路径初始化或 DMA/描述符处理)。 作为另一个有用的调试步骤,我建议您退一步,从标准的 InternalLoopback 示例开始,并根据您的硬件平台进行调整。 首先,请验证 InternalloopBack 示例在您的主板上是否能正常运行。这有助于确认 GMAC 的基本初始化、描述符处理、缓冲区配置以及软件流程在 S32K322 上均按预期运行。 之后,您可以取消勾选“内部环回模式”,并将该项目作为与外部交换机通信的最小基线。换句话说,使示例尽可能接近有效的参考设计,并再次测试帧的传输和接收。 这种方法有助于确定问题是源于与交换机的硬件接口(例如 RMII 时序/时钟),还是由当前项目中更高层级的软件集成差异所导致。 顺祝商祺! 帕维尔 Re: s32k322 EMAC RMII issue 你好@PavelL  感谢您的耐心支持。我们将按照您的建议在周末继续进行调查,并将于下周一或周二给您回复。 顺祝商祺! 李永祥 Re: s32k322 EMAC RMII issue 你好@PavelL、 很抱歉回复晚了。我们根据最近的研究结果进行了进一步的测试。我们测试了混杂模式,但结果没有变化。 我们还有一点观察结果:在重新设计 PCB 并实现外部环回后,MCU 能够接收自己发送的帧。然而,同一台交换机使用相同的配置,通过同一端口,经由 RMII 与另一产品板上的不同 MCU 成功通信。这让我们非常困惑,究竟是什么原因导致了这个问题。 我们将继续进行分析。我们目前的计划是通过让MCU TX和交换机输出相同的包来比较波形。然而,这在实施上具有挑战性,我们仍在努力——交换机转发的帧并不干净,因为它们包含许多其他数据包,会干扰波形捕获。 我们非常感谢您能提供任何其他建议。   顺祝商祺! 李永祥 Re: s32k322 EMAC RMII issue 你好@YongxiangLi、 谢谢你的更新。 根据您最新的观察,下一步的一个有用方法可能是通过交换机本身创建一个更可控的交换机到 MCU 接收测试。   由于 MCU 端的外部环回功能正常,这表明基本的 GMAC TX/RX 路径和软件流程是功能正常的。因此,隔离从开关输出到 MCU RMII 接收接口的特定路径可能很有帮助。   如果你的交换机支持,你可以尝试以下方法之一: 1. 配置一个非常简单的静态 L2 转发路径,以便将已知的测试帧仅转发到 MCU RMII 端口。 2. 或者,如果支持,可以使用端口镜像生成向 MCU 端口的受控出口帧。 如果交换机支持,我还建议暂时禁用所有端口的 MAC 地址学习功能。   无论哪种情况,我都建议禁用或过滤所有其他不必要的流量,如果可能的话,禁用转发到所有其他端口。目标是只让一个已知的帧模式到达 MCU,以便更清晰地捕获 RMII 接收波形(REF_CLK、CRS_DV、RXD0、RXD1)。 顺祝商祺! 帕维尔
記事全体を表示
What are industrial Ethernet protocols? Explanation of EtherCAT, PROFINET, and EtherNet/IP (Japanese blog) table of contents Introduction What is industrial Ethernet? Basic structure of industrial networks 1. EtherCAT (Ultra-high speed, low latency orientation) 2. Profinet (Flexibility/Interoperability) 3. Ethernet/IP (IT affinity/standardization) summary Introduction   Communication in industrial equipment is rapidly shifting from traditional fieldbuses to Ethernet-based systems. At the heart of this shift is the Industrial Ethernet protocol .   This article focuses on three widely used protocols and clearly explains the differences in their technical structure and design philosophy . EtherCAT PROFINET EtherNet/IP (※Evaluation and implementation methods will be explained in a separate article.) What is industrial Ethernet ?   In short, industrial Ethernet is a communication technology that enhances "real-time performance," "robustness," and "diagnostic capabilities" compared to general-purpose Ethernet. Standard Ethernet has the following challenges in industrial applications:   This is a best-effort communication method, and the delay varies depending on the load and switching processes. Frame loss (packet loss) may occur. TCP/UDP/IP is not designed for real-time control. To address these challenges, industrial Ethernet protocols employ unique approaches to achieve the following requirements:   Real-time communication Synchronization control Redundant configuration Diagnostic function   ■ Key points for understanding industrial Ethernet: OSI model   One of the key points in understanding industrial Ethernet is the perspective of "at which layer real-time performance is achieved," and the OSI reference model is helpful in understanding this. The OSI model is a framework that divides communication functions into seven layers, and each layer plays a different role, from the transmission of physical signals to application processing. Industrial Ethernet achieves real-time performance and reliability by using each of the OSI layers as a base and extending and optimizing specific layers for each protocol. OSI reference model in industrial Ethernet: hierarchy name The role of industrial Ethernet 7 application Contents of communication data (device control, status, settings) 6 presentation Data encoding, compression, and encryption 5 session Establishing, maintaining, and terminating communications 4 transport Communication quality control (TCP/UDP), data delivery assurance. 3 network Routing by IP address (determining packet destination) 2 Data Link Data delivery by MAC address, creation of Ethernet frames 1 physics Cables (Cat5e/6, etc.), connectors, and physical signal transmission. Layers used for each industrial Ethernet protocol: Characteristics of each Ethernet protocol: protocol hierarchy Features EtherCAT 2 High speed without using IP PROFINET RT/IRT is L2 NRT L3/4 Differentiated usage between RT and IRT. EtherNet/IP 3/4 Standard Ethernet based These differences in characteristics directly lead to the following: Speed (real-time performance) Implementation cost Applicable use   Basic structure of industrial networks   Industrial Ethernet generally shares a common basic structure regardless of the protocol, and the three protocols discussed in this article (EtherCAT, PROFINET, and EtherNet/IP) are no exception. ■ System and Device Structure   Industrial networks can be broadly divided into the "controller side" and the "device side."   Main device (controller): It plays a central role in controlling the entire network. Starting communication and setting connection parameters Sending output data and receiving input data Communication management and termination process Typical examples: PLCs, industrial PCs Sub-device (device): Respond to connection requests and send and receive necessary data. Receiving output data and transmitting input data Self-notification on the network Alarms sent as needed Typical examples: sensors, servos, actuators ■ Communication method: cyclic communication vs. aperiodic communication Once a connection is established, I/O data is continuously exchanged between the MainDevice and SubDevice at very short intervals. This communication is divided into "periodic communication" and "aperiodic communication" depending on the application. Cyclic communication (periodic communication) Application: For real-time control - Essential for applications requiring real-time performance, such as motor control and I/O control. Acyclic communication Uses: Configuration, diagnostics, and event management. - Used for reading and writing configuration data, diagnostic information, and notifications of unexpected events. ■Key concept supporting real-time performance: Synchronization ( Clock ) In industrial systems, it is extremely important that "all devices operate on the same time standard." For example, if multiple devices acquire data at different times, Δt₁, Δt₂, and Δt₃, as shown in the diagram below, the information received by the controller (PLC) will not be data from the same time, but rather "separate snapshots" that are staggered in time. the result: Occurrence of positional misalignment Incorrect control judgment In particular, critical synchronization errors in motion control This can lead to problems like these. Therefore, in Industrial Ethernet , a mechanism for synchronizing clocks between devices is a crucial element. Summary of the technical comparison of the three protocols   EtherCAT PROFINET EtherNet/IP Operating Organization Bechoff / ETG (EtherCAT Technology Group) Siemens / PNO (PROFIBUS & PROFINET International) Rockwell / OVDA (Open Device Net Vendors Association) Communication method Summary frame (SubDevice reads and writes data as it passes through the frame) Layer 2-based real-time communication (RT/IRT) CIP: Explicit (TCP) / Implicit (UDP) communication model Main use Motion control, ultra-high-speed control General-purpose FA, process control, and a wide range of industrial applications Factory automation, PLC networks, robots Cycle time ~31.25μs level (implementation dependent, very fast) RT: A few milliseconds IRT: 31.25μs (implementation-dependent, TSN/IRT) Generally, 10ms level (UDP-based) Synchronization method Distributed Clock (DC) IRT: Precision Synchronization (PTCP) CIP Sync (IEEE1588) Device Model PDO / SDO (CANopen over EtherCAT) Slot / Subslot (GSDML) Class / Instance / Attribute Object Model topology Line, tree, ring (low latency) Line, Star, Ring (MRP/MRPD) Line, Star, Ring (DLR) advantage In short, high speed and low latency / hardware processing. Various classes and diagnostic functions, high interoperability Widely used in standard Ethernet infrastructure, easy to understand. From here, we will explain the technical characteristics of each. 1. EtherCAT (Ultra-high speed, low latency-oriented) ■ EtherCAT Overview Developed by Beckhoff Automation, managed by ETG. It operates at Layer 2 and has no IP/TCP/UDP overhead. Cycle time: ~ 31.25 μs ( implementation dependent ) Synchronization accuracy: ±1μs or less ■ Network Configuration Main device (master) and  Multiple sub-devices (slaves) The sub-device is equipped with an ESC ( EtherCAT Slave Controller ) and uses dedicated hardware for high-speed processing. While a line configuration is the basic setup, it also supports redundant configurations using a ring structure. Figure: EtherCAT network configuration image The most distinctive feature of EtherCAT is "on-the-fly processing. " A single frame is processed as it passes through all devices, with each device reading and writing data during transit. Because processing is handled by dedicated hardware (ESC) without involving the CPU, it achieves extremely low latency.   Figure: EtherCAT network transfer image ■ Related protocol conversion: EtherCAT (IEC 61784-2-12) • CoE (CAN over EtherCAT): Enables CANopen communication to be used by tunneling it over an EtherCAT frame. • FoE (File over EtherCAT): A protocol for transferring files via EtherCAT. EoE (Ethernet over EtherCAT): A mechanism for encapsulating and transmitting regular Ethernet frames (such as TCP/IP ). Figure: EoE protocol conversion by master device (MDevice) 2. PROFINET (Flexibility/Interoperability) ■ PROFINET Overview Developed by Siemens, managed by PNO. Standard Ethernet based Use RT/IRT/NRT depending on the application. Producer/Consumer Model ■ Network Configuration Flexible support for various topologies such as line, star, and mixed configurations. It also supports ring redundancy via MRP ( Media Redundancy Protocol ) / MRPD (IRT) . PROFINET 's communication performance is classified by " Conformance Class ( CC )". CC-A : Basic real-time, all IT services (e.g., TCP/IP ) can be used without restrictions. CC-B : Adds network diagnostics and other features to the general FA 's RT . CC-C ( IRT 😞 Motion applications in the 31.25 μs class ■ Communication type NRT: Record Read/Write: Sends and receives parameters and settings aperiodicly. Alarms: Notifies of abnormalities from the device. RT: Periodic I/O communication, generally 1ms IRT (Isochronous): Time-synchronized high-speed periodic communication , typically 31.25us. → Achieves high flexibility, detailed diagnostics, and high interoperability. 3. EtherNet/IP ( IT compatibility/standardization) ■ EtherNet/IP Overview EtherNet/IP is managed by ODVA (Open DeviceNet Vendors Association). It adopts CIP (Common Industrial Protocol), which operates at a layer above TCP/UDP/IP (L3/L4). Object-Oriented Model ■ Network Configuration Supports line, star, and ring topologies. Supports high-speed redundancy using DLR ( Device Level Ring ). Main device → Scanner : Functions as a controller and typically initiates requests. Subdevice → Adapter : The device that responds to that request. ■ EtherNet/IP's key feature: "Object-Oriented Model" Each device is defined as a collection of objects consisting of " Class ," " Instance ," " Attribute ," and " Service ." Class : Type of function (e.g., Identity , Assembly ) Instance : A specific instance of that class. Attribute : The specific value that each instance possesses. Service : Operation details such as reading and writing. This results in a very clear structure for the device's functions, enabling high compatibility across manufacturers. ■ Communication type Explicit Messaging Connection Uses TCP , reads and writes configuration values, performs self-diagnosis, and logs. Give instructions such as "Read" and "Write" once each. Implicit Messaging- I/O Connection Using UDP , it enables real-time communication such as cycle I/O , with the scanner sending and receiving I/O data at regular intervals.   The key feature of EtherNet/IP is its ability to enable high-speed I/O communication using implicit ( UDP ) protocols. summary Industrial Ethernet is not just a communication tool; it's a system technology that enables real-time control . The three protocols introduced here each achieve this through a different approach. protocol design philosophy Main uses EtherCAT High speed, low latency Motion control PROFINET Flexibility and Integration General-purpose factory automation (FA) EtherNet/IP IT integration PLC Network   As a future trend, industrial networks will move in the following direction. TSN ( Time Sensitive Networking ) Security (including CRA compliance) Integration with OPC UA In other words, the key lies in the fusion of "real-time × IT integration × security" . Next time, Why is the i.MX RT1180 suitable for industrial Ethernet protocols? Actual implementation and evaluation procedures We will explain this in detail. ============================= We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making inquiries.(If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) Communication in industrial equipment is rapidly shifting from traditional fieldbuses to Ethernet-based systems. At the heart of this shift is the Industrial Ethernet protocol . This article focuses on three widely used protocols and clearly explains the differences in their technical structure and design philosophy . EtherCAT PROFINET EtherNet/IP (※Evaluation and implementation methods will be explained in a separate article.)   This article will cover the three major protocols that dominate industrial Ethernet: EtherCAT, PROFINET, and EtherNet/IP, and provide a clear explanation of the differences in their technical structures and design philosophies.   (Reading time: 15 minutes) i.MX RT Processors Introduction Japanese Blog
記事全体を表示
Mifare Classic クローンをHandyに こんにちは、良い一日を。当ジムでは、Mifare Classic EV1(MF1S50)チップを搭載したリストバンドを使用しています。このチップを複製してモバイルフォンに保存し、代わりにモバイルフォンのNFCセンサを使用する方法はありますか?つまり、リストバンドではなく、スマートフォン本体を使ってログインすることは可能でしょうか?もしそうなら、どうすればいいですか?私は既にNXP TagInfoとNXP TagWriterという2つのアプリを試してみました。残念ながら、それらのツールを使ってもうまく動作させることができませんでした。あるいは、途中でどこかでミスをしてしまったのかもしれません。手伝っていただけませんか?ゲラベルク(テューリンゲン州)より、心からのご挨拶を申し上げます。 タッチ・センサ Re: Mifare Classic clone to Handy こんにちは、 @digamcrown 残念ながら、MIFARE Classic EV1カードを複製してスマートフォンのNFCインターフェースで直接使用することはできません。 主な理由は以下のとおりです。 スマートフォンはMIFARE Classicカードのエミュレーションをサポートしていません(NFCコントローラーではCrypto-1はサポートされていません)。カードUIDはモバイルデバイス上で複製できません。 モバイルオペレーティングシステム(Android/iOS)は、セキュリティ上の理由から低レベルのNFCアクセスを制限しています。 したがって、NXP TagInfoやTagWriterといったツールでは、この機能を実現することはできません。 Re: Mifare Classic clone to Handy こんにちは、 こんにちは、 MIFARE Classicカードはセキュアメモリを搭載しているため、ジムのシステムを提供している業者に連絡して、スマートフォンにデジタルバッジを作成できるソリューションを提供しているかどうかを問い合わせるべきです。 MIFARE 2GOについては、https://www.nxp.com/products/security-and-authentication/secure-service-2go-platform/mifare-2go :MIFARE2GO をご覧ください。
記事全体を表示
Ara Vision Examples Multi-Stream YOLOv8 Object Detection  This post shows a walkthrough of the ARA2 Vision Examples demo and its multi-stream YOLOv8 object detection application. The ara2-vision-examples demo provides vision AI examples for NXP i.MX platforms using Ara240 DNPU acceleration. It demonstrates real-time video processing with AI/ML inference capabilities such as object detection, classification, pose estimation, and semantic segmentation. This walkthrough focuses on the Go Point launch of the application, which uses GStreamer to process up to eight simultaneous video streams, run YOLOv8 object detection on each stream, and display the results in a single mosaic view.   Key Features Multi-stream video processing from 1 to 8 streams YOLOv8 object detection accelerated by Ara240 DNPU Support for YOLOv8n, YOLOv8s, YOLOv8m, YOLOv8l, and YOLOv8x models GStreamer-based video pipeline Mosaic display output with bounding boxes Runtime options for stream count, model selection, synchronization, and endpoint selection FPS and IPS performance overlay per stream   Running the Demo Run the application with the default settings: multistream_yolov8 Run with a specific number of streams: multistream_yolov8 -s 4 Select a different YOLOv8 model: multistream_yolov8 -s 4 --model yolov8s Run eight streams for maximum throughput: multistream_yolov8 -s 8 --sync false Enable synchronized playback: multistream_yolov8 -s 4 --sync true   Walkthrough Video In the attached video, it is shown how to launch the application from GoPoint, configure the number of streams, select different YOLOv8 models, and view the object detection results in the mosaic display.  (function() { var wrapper = document.getElementById('lia-vid-6405447139112w960h540r991'); 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'); }); }); }); } }})(); (view in My Videos) Summary Ara-Vision-Examples is the reference application showcasing edge vision AI on the Ara240 Discrete NPU (DNPU). It runs real-time object detection, classification, pose estimation and semantic segmentation over single or multiple (up to eight) video streams, rendering bounding boxes, labels and confidence scores. Links ARA2 Vision Examples repository: https://github.com/nxp-imx-support/ara2-vision-examples Multi-stream YOLOv8 README: ara2-vision-examples/tasks/object-detection/yolo/multistream-gstreamer/README.md at main · nxp-imx-support/ara2-vision-examples · GitHub ARA2-M2-16G-GT ARA240 Hands-On Training
記事全体を表示
MCUXpresso Config Tools: How to Use the Clocks Tool (Japanese Blog) table of contents Introduction In what situations can Clocks Tool be used? Installing Config Tools Browse Tool screen configuration Basic Terminology for Using Clocks Tool Demonstration: Change the CPU core clock settings and alter the LED blinking speed. Bonus 1 - Clock settings are already available as presets. Bonus 2 - Where are the settings values that were automatically generated by the initialization code? Introduction MCUXpresso is a microcontroller development software platform provided by NXP. In addition to the MCUXpresso IDE, it also offers MCUXpresso for VSC (Visual Studio Code) and Config Tools to assist with peripheral configuration. Config Tools consists of tools such as the " Pins Tool " for setting pins and the " Clocks Tool " for configuring clock settings, and its key feature is that it allows for intuitive and easy initial setup of the microcontroller's peripherals via a GUI . This article will focus on the "Clocks Tool," which is responsible for clock settings. For instructions on using the "Pins Tool," please refer to the following article. MCUXpresso Config Tools: How to Use the Pins Tool (Japanese Blog) Clock settings are a crucial element directly impacting microcontroller performance, power consumption, and the operation of each peripheral. However, the clock tree can be complex, making it difficult to understand which clock is being used where . Clocks Tool allows you to visualize and configure clock sources, frequency division settings, and the clock supply status to each peripheral. It can also automatically generate initialization code based on the settings. When you install the MCUXpresso IDE , Config Tools are also installed, making them available as a built-in feature of the IDE . On the other hand, in the Visual Studio Code ( VSC ) environment, which has become increasingly popular in embedded development in recent years, you can similarly use Config Tools (including Clocks Tool ) by installing MCUXpresso -related extensions. There are no significant differences in the functionality of Config Tools between the IDE version and the VSC version. This article explains how to install Config Tools in the VS Code environment, how to use the tools, and finally demonstrates how to change the CPU clock settings within Clocks Tool and alter the LED blinking speed using the FRDM-MCXN947 . You can also watch a video. Click this link to watch : How to use MCUXpresso Clocks Tool (VS Code environment) In what situations can Clocks Tool be used? When you want to check the existing internal clock settings (clock tree) When you want to adjust and optimize the operating frequency for each module When you want to consider a configuration that lowers the clock frequency with low power consumption in mind. Installing Config Tools This guide explains how to install Config Tools in the VS Code environment. *If you haven't installed MCUXpresso for VS Code yet, please refer to this blog post. Installing MCUXpresso for VSC and SDK (Japanese blog) After launching VS Code , select MCUXpresso from the left-hand panel, and then click Open MCUXpresso Installer from the Quick Start Panel . The installer will launch. Select MCUXpresso Configuration Tools and click Install in the upper right corner. (This blog post describes the installation of MCUXpresso Config Tools v26.03.) You will be prompted to log in to MyNXP as soon as the installation begins. After logging in, the License Agreement will be displayed. Please review its contents and agree to them. *Please restart VS Code after installation. Q. What if the installation fails? A. Please download the installer appropriate for your PC's OS environment from the following website and try it. MCUXpresso Config Tools | Software Development for NXP Microcontrollers (MCUs) | NXP Semiconductors As you proceed with the installation, the following screen will appear on the initial screen. If you do not see anything relevant, you can close it. To access Config Tools from VS Code , install the SDK , import the sample, then right-click on your project. "Open with MCUXpresso Config Tools " will appear; click on it. *This entire process will be explained in detail in the final demonstration, so we will omit it here. Config Tools will start after a short while. If you are using the MCUXpresso IDE, Config Tools are integrated by default and can be launched directly from the top tab. Browse Tool screen configuration After launching Config Tools , you can switch between tools using the panel on the right side of the screen. This time, we'll select " Clocks ". The Clocks Diagram , which is frequently used when changing clock settings , can be selected from the top left of the screen. The Problem view in the lower right corner of the screen displays any errors or warnings related to your settings. If there is an error due to incorrect clock settings, the Problem view will display the location and cause of the error. Additionally, the relevant area will be highlighted in red on the Clock Diagram, allowing you to visually identify the problem. For example, if you set the CPU clock to exceed the specified maximum value, an error message (shown below) will be displayed. Basic Terminology for Using Clocks Tool This section clarifies the basic terminology displayed on the Clock Diagram when using the Clocks Tool . Clock Tree This is a configuration diagram (tree diagram) showing where clocks are generated, how they are distributed and selected, and how they are supplied to each block. Clocks Tool allows you to configure settings while visually viewing this Clock Tree . Clock Source This is the signal source that serves as the starting point for the clock. This includes internal RC clocks, external crystals (oscillators), and external clock inputs, and is located upstream in the clock tree. In the MCX N947, the built-in 48MHz RC clock (FIRC) is used as the clock source by default . PLL ( Phase Locked Loop) This circuit generates a stable high-frequency clock using a clock source as input. The output frequency can be adjusted by setting the multiplier and frequency divider, allowing for flexible creation of clocks for CPUs and high-speed buses . Here, a 300MHz clock (48MHz/8*50=300MHz) is generated based on the 48MHz input clock, which is the Clock Source . DIV (Divider ) This function allows you to divide and adjust the clock frequency. Frequency division settings are available for the CPU , bus, and each peripheral, and are used to adjust to the required operating frequency. In the following example, a 150MHz clock (300MHz/2=150MHz) is generated from a 300MHz clock generated by PLL0. Mux ( Multiplexer ) This mechanism allows you to switch which clock to use from among several potential clocks. Switching the selection changes the clock supplied downstream. In the diagram below, there are two MUXs ; the one on the left selects a 48MHz clock from the internal RC clock, and the one on the right selects a 150MHz clock divided by DIV (PLL0_PDIV) . Demonstration: Change the CPU core clock settings and alter the LED blinking speed. Here, we will actually change the clock supplied to the CPU using Clocks Tool and see if the blinking speed of the LEDs on the evaluation board changes. Hardware Preparation The evaluation board used in this article is the FRDM-MCXN947 Installing the SDK With the MCUXpresso icon selected in the left-hand panel of VS Code , click " Import Repository ". Next, click on " REMOTE ARCHIVE ," the second option from the left, and search for " FRDM-MCXN947 " in the Package section . Entering " 947 " will immediately display FRDM-MCXN947 as a suggestion . The Name , Location , and the "Create Git" checkbox can be set as you wish. *For Name and Location names, it is best to use only lowercase alphanumeric characters and underscores (_) or hyphens (-) , and avoid symbols such as ( \, /, :, *, ?, ", <, >, | ) (which may cause program malfunctions) and spaces. Finally, check the " I agree " box and click " Import " to begin the SDK installation. Please wait a moment. The installation is complete when " Repository successfully imported" is displayed in the lower right corner of the screen. Importing sample code Once the SDK installation is complete, proceed to import the sample code. Click " Import Example From Repository " in the panel on the left. Within each tab displayed on the right, under " Repository ," select the SDK you just imported. Please select FRDM-MCXN947 for " Board ". In this " Template " demonstration, we will be changing the blinking speed of the LED . I'll try it with " driver_examples/gpio/gpio_led_output_cm33_core0 " which appears when I type " led ". Next, select the Toolchain and click " Import" . Open ConfigTools Right-click on the imported sample and select " Open with MCUXpresso Config Tools ". The Config Tools will launch after a short wait. Once Config Tools opens, first check the Overview in the right-hand panel. In this example, both Clocks and Pins are green (ON ) , indicating that both tools are enabled. Now, let's look at the Clock Diagram . The main clock of 150MHz is generated from the clock source FIRC 48MHz via PLL (PLL0) , DIV (PLL0_PDIV) , and MUX (SCSSEL) . Next, scroll down a bit to see the clock supplied to the CPU . In this sample application, " System_clock" corresponds to the CPU core clock. The MAIN Clock at 150MHz passes through a DIV ( Distributed Variable) in between, but is still supplied to the System Clock at 150MHz . Later, we will change the value of this DIV and thereby change the clock signal input to the System Clock , observing the change in the LED blinking speed. Check the LED blinking speed when the CPU Clock is set to 150MHz. First, let's look at the LED blinking speed when the CPU Clock is set to 150MHz without any changes. Close Config Tools and open VS Code . Before building, connect the board ( FRDM-MCXN947) to the PC . Once the connection is established, debug the imported sample (build, write, and run the application). Once the debugging process is complete, the program will have stopped at the breakpoint, so click the "|▶" icon at the top of the screen. As shown in the video, the red LED will start blinking. This is the blinking speed at a clock speed of 150MHz (default setting). (function() { var wrapper = document.getElementById('lia-vid-6395306957112w304h540r743'); 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'); }); }); }); } }})(); (Show My Videos) To stop, click the square icon (even after stopping the debug, the program will continue to run on the board, so the LED will continue to blink, but please ignore this for now ) . Change the CPU clock to 50MHz and check the LED blinking speed. Next, we'll use ClocksTool to change the CPU core clock from 150MHz to 50MHz . Open the Clocks Tool in Config Tools again . Scroll down slightly in the Clocks Diagram and change the DIV (AHBCLKDIV) connected to the System Clock . When changing it, click on the number within the DIV you want to change to select from the dropdown menu. Selecting 1/3 here will change the System Clock to 50MHz . *When changing clock settings, please note that changing the clock settings upstream, which are close to the Clock Source, may affect multiple clock settings downstream. Now, we will rewrite the sample code. First, click "Update Code" in the upper left corner of the Config Tools screen. In the dialog box that appears, select "OK". When you return to VS Code in this state, three checkboxes will appear at the top of the screen. Make sure they are checked and click OK . After a short wait, the changes made in Clocks Tool will be applied to the sample code in VS Code . *This may not be displayed if the SDK version is different. If successful, the following message will be displayed in the lower right corner of the screen. Run the debug test again, and once it's finished, run the sample application using "|▶". The LED will start blinking. This is the blinking speed at a 50MHz clock. It is clearly slower compared to the speed at 150MHz . (function() { var wrapper = document.getElementById('lia-vid-6395308518112w304h540r499'); 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'); }); }); }); } }})(); (Show My Videos) This concludes the demonstration. Thank you for your participation. Bonus 1 - Clock settings are already available as presets. While the previous steps involved changing the clock using DIV , Clocks Tool comes with several clock settings pre-configured. Select Clocks Tool in Config Tools , and then choose your desired clock from the top of the screen : FRO 12MHz / FRO HF 48MHz / FRO HF 144MHz… For example, if you select "BOARD_BootClockPLL_100M " , you will see that the Clock Source , PLL , and DIV are all different from before. For example, the Clock Source is a 24MHz external clock (SOSC) . Bonus 2 - Where are the settings used to automatically generate the initialization code? We will examine how the clock settings are automatically updated (Update Code) using Clock Tools, and how this is reflected in the actual initialization code. Check the C source file (gpio_led_output.c) in the Project Files of the imported sample. If you look inside the C source file, you'll find code that initializes the Pin , Clock , and Debug console . Right-click on BOARD_InitHardware(); and click "Go to Definition" to see more details. There is code to initialize the Pin , Clock , and Debug console . Right-click on BOARD_InitBootClocks(); and select " Go to Definition" (or "fn + F12") to see more details. The destination file (clock_config.c) is FRDM-MCXN947This is the generated code that defines the startup clock configuration. As you scroll down, you will see that, as explained earlier, multiple clock configurations ( FRO 12MHz / FRO HF 48MHz / FRO HF 144MHz / PLL 150MHz / PLL 100MHz ) are available as presets. In the image below, the default value of PLL150MHz is shown, For example, if you change this part to BOARD_BootClockFROHF48M Initialization will be performed using the FRO HF 48M clock configuration, which is prepared as a preset. Next, let's see how the clock configuration and code change when we directly modify the DIV in Clocks Tool while keeping the FRO HF 48M . The text and settings enclosed in the red box will be changed. Furthermore, if you change the DIV connected to the System Clock in Clocks Tool to 1/2 , i.e., from 48 to 24MHz, and then run Update Code, you will see that the red frame has changed due to the change in DIV.   You can also check the differences before and after the changes in Clocks Tool. After changing the clock settings, clicking Update Code will display a dialog box like the one below. Files with differences will have "change" displayed to the right of the file name. Clicking this will allow you to view the differences. clock_config.c Let's check the difference. The left side (Newly generated) shows the modified file, and the right side (On disk) shows the original file. You should be able to see that there is a difference in the System Clock. The areas where differences have occurred are highlighted with a different color, making them visually easy to spot.   Due to the increasing integration of functions in microcontrollers and processors, their internal clock trees have become extremely complex. Without a clock visualization tool like this, designing and evaluating such systems would be practically impossible, so please make use of it.   Reference materials Tutorial video: How to use MCUXpresso Clocks Too (VS Code environment)   =========================​ We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us ( Japanese Blog ) " when making inquiries . (If you are already an NXP distributor or have a relationship with NXP , you may ask your representative directly.) This guide focuses on the "Clocks Tool" within the MCUXpresso Config Tools, explaining the basics and methods of setting the clock. It covers everything from installation in a VS Code environment to a demonstration of LED blinking caused by CPU clock changes. (Estimated time: 10 minutes *Assumes MCUXpresso for VSC (Visual Studio Code) SDK is installed) MCUXpresso MCX Victoria | Downloads Japanese Blog
記事全体を表示
MCUXpresso 配置工具:如何使用时钟工具(日语博客) 目录 介绍 Clocks Tool 适用于哪些情况? 安装配置工具 Minecraft 工具的屏幕配置 时钟工具使用基本术语 演示:更改 CPU 核心时钟设置并改变 LED 闪烁速度。 奖励 1 - 时钟设置已作为预设提供。 附加题 2 - 初始化代码自动生成的设置值在哪里? 介绍 MCUXpresso 是恩智浦半导体 (NXP) 提供的一款微控制器开发软件平台。除了 MCUXpresso IDE 之外,它还提供 MCUXpresso for VSC(Visual Studio Code)和配置工具,以辅助外设配置。 配置工具包含多个工具,例如用于设置引脚的“引脚工具”和用于配置时钟设置的“时钟工具”。其主要特点是可以通过图形用户界面 (GUI)直观便捷地完成微控制器外设的初始设置。本文将重点介绍负责时钟设置的“时钟工具” 。有关“引脚工具”的使用说明,请参阅以下文章。 MCUXpresso 配置工具:引脚工具的使用方法(日语博客) 时钟设置是直接影响微控制器性能、功耗和各外设运行的关键因素。然而,时钟树可能非常复杂,难以理解各个外设正在使用哪个时钟。时钟工具允许您可视化和配置时钟源、分频设置以及每个外设的时钟供电状态。它还可以根据设置自动生成初始化代码。 安装MCUXpresso IDE时,配置工具也会一并安装,使其成为IDE的内置功能。另一方面,在近年来嵌入式开发领域日益流行的Visual Studio Code ( VSC ) 环境中,您也可以通过安装MCUXpresso相关扩展来使用配置工具(包括时钟工具)。IDE版本和VSC版本在配置工具的功能上并无显著差异。 本文 解释了如何在 VS Code 环境中安装 配置工具 ,如何使用这些工具,并最终演示了如何在 时钟工具 中更改 CPU 时钟设置,以及如何使用 FRDM-MCXN947 改变 LED 闪烁速度。 您还可以观看视频。点击此链接观看:如何使用 MCUXpresso 时钟工具(VS Code 环境) Clocks Tool适用于哪些情况? 当您想要检查现有的内部时钟设置(时钟树)时 当您需要调整和优化每个模块的工作频率时。 当您想要考虑一种既能降低时钟频率又能降低功耗的配置时。 安装配置工具 本指南解释了如何在VS Code环境中安装Config Tools 。 *如果您尚未为 VS Code 安装 MCUXpresso ,请参阅此博客文章。 安装适用于 VSC 和 SDK 的 MCUXpresso(日文博客) 启动VS Code后,从左侧面板中选择MCUXpresso ,然后从快速启动面板中单击“打开 MCUXpresso 安装程序” 。 安装程序将启动。选择MCUXpresso 配置工具,然后单击右上角的“安装” 。 (这篇博文介绍了 MCUXpresso 配置工具 v26.03 的安装过程。) 安装开始后,系统会提示您登录MyNXP 。 登录后,将显示许可协议。请阅读并同意其内容。 *安装完成后请重启VS Code。 问:如果安装失败怎么办? A. 请从以下网站下载适合您电脑操作系统环境的安装程序并进行尝试。 MCUXpresso 配置工具 | NXP 微控制器 (MCU) 软件开发 | NXP 半导体 安装过程中,初始屏幕上会出现以下界面。如果您没有看到任何相关信息,可以将其关闭。 要从VS Code访问配置工具,请安装SDK ,导入示例,然后右键单击您的项目。 “使用 MCUXpresso 配置工具打开”将出现;单击它。 *整个过程将在最终演示中详细解释,因此我们在此省略。 配置工具将在短时间内启动。 如果您使用的是 MCUXpresso IDE,则配置工具默认已集成,可以直接从顶部选项卡启动。 Minecraft 工具的屏幕配置 启动配置工具后,您可以使用屏幕右侧的面板在工具之间切换。 这次,我们将选择“时钟”。 时钟图(在更改时钟设置时经常用到)可以从屏幕左上角选择。 屏幕右下角的“问题”视图会显示与您的设置相关的任何错误或警告。 如果由于时钟设置不正确而出现错误,“问题”视图将显示错误的位置和原因。此外,时钟图上的相关区域将以红色突出显示,以便您直观地识别问题。 例如,如果将 CPU 时钟设置为超过指定的最大值,则会显示错误消息(如下所示)。 时钟工具使用基本术语 本节阐明了使用时钟工具时时钟图上显示的基本术语。 时钟树 这是一个配置图(树状图),展示了时钟的生成位置、分配和选择方式,以及如何将它们提供给每个模块。时钟工具允许您在查看此时钟树的同时配置设置。 时钟源 这是作为时钟起始点的信号源。它包括内部RC时钟、外部晶体(振荡器)和外部时钟输入,位于时钟树的上游。 在 MCX N947 中,默认情况下使用内置的48MHz RC时钟(FIRC)作为时钟源。 PLL(锁相环) 该电路以时钟源为输入,产生稳定的高频时钟。 通过设置倍频器和分频器可以调节输出频率,从而为 CPU 和高速总线灵活地创建时钟。 这里,基于48MHz输入时钟(即时钟源)生成300MHz时钟(48MHz/8*50=300MHz) 。 除号 (DIV ) 此功能允许您对时钟频率进行分频和调整。 CPU 、总线和每个外围设备都有分频设置,用于调整到所需的运行频率。 在以下示例中,由 PLL0 生成的 300MHz 时钟生成 150MHz 时钟(300MHz/2=150MHz)。 多路复用器(Mux ) 该机制允许您从几个可选时钟中切换使用哪个时钟。 切换选择项会改变下游提供的时钟信号。 在下图所示的电路中,有两个多路复用器;左边的多路复用器从内部RC时钟中选择48MHz时钟,右边的多路复用器选择150MHz时钟除以DIV(PLL0_PDIV) 。 演示:更改 CPU 核心时钟设置并改变LED闪烁速度。 在这里,我们将使用时钟工具实际改变提供给CPU 的时钟,看看评估板上的LED闪烁速度是否会发生变化。 硬件准备 本文使用的评估板是 FRDM-MCXN947 安装 SDK 在VS Code左侧面板中选择MCUXpresso 图标,然后单击“导入存储库”。 接下来,点击左侧第二个选项“远程存档”,然后在“软件包”部分搜索“ FRDM-MCXN947 ”。输入“ 947 ”后, FRDM-MCXN947 将立即显示为建议。 您可以根据需要设置名称、位置和“创建 Git”复选框。 *对于名称和位置名称,最好只使用小写字母数字字符和下划线(_)或连字符(-) ,并避免使用符号( \、/、:、*、?、"、、| )(这可能会导致程序故障)和空格。 最后,勾选“我同意”复选框,然后点击“导入”开始安装SDK 。请稍候片刻。当屏幕右下角显示“存储库导入成功”时,安装即完成。 导入示例代码 SDK安装完成后,即可导入示例代码。 点击左侧面板中的“从存储库导入示例”。 在右侧显示的每个选项卡中,“存储库”下,选择您刚刚导入的SDK 。 请为“主板”选择FRDM-MCXN947 。 在这个“模板”演示中,我们将改变LED的闪烁速度。 尝试输入“ led ”,然后选择出现的“ driver_examples/gpio/gpio_led_output_cm33_core0 ”。 接下来,选择工具链并点击“导入” 。 打开配置工具 右键单击导入的示例,然后选择“使用 MCUXpresso 配置工具打开”。稍等片刻,配置工具将启动。 配置工具打开后,首先查看右侧面板中的概览。在本例中, “时钟”和“引脚”均显示为绿色(开启) ,表示这两个工具均已启用。 现在,让我们来看一下时钟图。 150MHz 的主时钟由48MHz时钟源FIRC 通过PLL (PLL0) 、 DIV (PLL0_PDIV)和MUX (SCSSEL)生成。 接下来,向下滚动一点,可以看到提供给CPU 的时钟。在本示例应用程序中,“ System_clock”对应于CPU 核心时钟。 主时钟频率为 150MHz ,中间经过一个分频器(分布式变量),但仍然以150MHz的频率提供给系统时钟。稍后,我们将改变这个分频器的值,从而改变输入到系统时钟的时钟信号,并观察LED闪烁速度的变化。 检查 CPU 时钟频率设置为 150MHz 时的 LED 闪烁速度。 首先,我们来看看 CPU 时钟频率设置为150MHz且不做任何更改时的 LED 闪烁速度。关闭配置工具并打开VS Code 。 在组装之前,将电路板( FRDM-MCXN947)连接到电脑。 连接建立后,调试导入的示例(构建、写入和运行应用程序)。 调试过程完成后,程序将在断点处停止,因此请点击屏幕顶部的“|▶”图标。 如视频所示,红色LED灯将开始闪烁。这是时钟频率为150MHz (默认设置)时的闪烁速度。 (function() { var wrapper = document.getElementById('lia-vid-6395306957112w304h540r743'); 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'); }); }); }); } }})(); (显示我的视频) 要停止,请点击方形图标(即使停止调试后,程序仍会在板上继续运行,因此 LED 会继续闪烁,但请暂时忽略这一点) 。 将 CPU 时钟频率改为 50MHz,并检查 LED 闪烁速度。 接下来,我们将使用ClocksTool将 CPU 核心时钟从 150MHz 更改为50MHz 。 再次打开配置工具中的时钟工具。在时钟图中向下滚动一点,然后更改连接到系统时钟的DIV(AHBCLKDIV) 。更改时,单击要更改的 DIV 中的数字,然后从下拉菜单中进行选择。此处选择1/3会将系统时钟更改为50MHz 。 *更改时钟设置时请注意,更改靠近时钟源的上游时钟设置可能会影响下游的多个时钟设置。 现在,我们将重写示例代码。首先,单击“配置工具”屏幕左上角的“更新代码” 。在出现的对话框中,选择“确定”。 在此状态下返回VS Code后,屏幕顶部会出现三个复选框。请确保选中它们,然后单击“确定” 。稍等片刻,时钟工具中所做的更改将应用到VS Code中的示例代码。 *如果 SDK 版本不同,则可能不会显示此内容。 如果成功,屏幕右下角将显示以下消息。 再次运行调试测试,完成后,使用“|▶”运行示例应用程序。 LED灯将开始闪烁。这是50MHz时钟频率下的闪烁速度。显然,它比150MHz时钟频率下的闪烁速度要慢。 (function() { var wrapper = document.getElementById('lia-vid-6395308518112w304h540r499'); 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'); }); }); }); } }})(); (显示我的视频) 演示到此结束。感谢各位的参与。 奖励 1 - 时钟设置已作为预设提供。 之前的步骤需要使用DIV 函数更改时钟,而时钟工具则预配置了多种时钟设置。在配置工具中选择时钟工具,然后从屏幕顶部选择所需的时钟:FRO 12MHz / FRO HF 48MHz / FRO HF 144MHz… 例如,如果您选择“BOARD_BootClockPLL_100M ” ,您会发现时钟源、 PLL和DIV都与之前不同。例如,时钟源是24MHz 的外部时钟(SOSC) 。 附加题 2 - 用于自动生成初始化代码的设置在哪里? 我们将研究如何使用时钟工具自动更新时钟设置(更新代码),以及这如何在实际初始化代码中体现。 检查导入示例的项目文件中的 C 源文件 (gpio_led_output.c)。 如果你查看C源文件,你会发现初始化引脚、时钟和调试控制台的代码。 右键单击BOARD_InitHardware();然后单击“转到定义”以查看更多详细信息。 代码中包含初始化 引脚 、 时钟 和 调试控制台的 功能。 右键单击 BOARD_InitBootClocks(); 并选择“ 转到定义”(或“fn + F12”) 以查看更多详细信息。 目标文件(clock_config.c)是 FRDM-MCXN947这是定义启动时钟配置的生成代码。 向下滚动页面,您会看到,如前所述,有多种时钟配置( FRO 12MHz / FRO HF 48MHz / FRO HF 144MHz / PLL 150MHz / PLL 100MHz )作为预设选项。下图显示的是PLL150MHz的默认值。 例如,如果您将此部分更改为BOARD_BootClockFROHF48M 初始化将使用FRO HF 48M时钟配置执行,该配置已准备就绪。 接下来,我们来看看在保持FRO HF 48M不变的情况下,直接在时钟工具中修改DIV 值时,时钟配置和代码会发生怎样的变化。红色框内的文本和设置将会改变。 此外,如果您将时钟工具中连接到系统时钟的DIV更改为1/2 ,即从48MHz更改为 24MHz,然后运行更新代码,您将看到由于 DIV 的变化,红色帧发生了变化。   您还可以使用时钟工具查看更改前后的差异。 更改时钟设置后,点击“更新代码”将显示如下所示的对话框。存在差异的文件,其文件名右侧会显示“更改”字样。点击此字样即可查看差异。 clock_config.c我们来检查一下区别。左侧(新生成)显示的是修改后的文件,右侧(磁盘上)显示的是原始文件。您应该能够看到系统时钟存在差异。 出现差异的区域用不同的颜色突出显示,使其在视觉上很容易被发现。   由于微控制器和处理器的功能集成度不断提高,其内部时钟树变得极其复杂。如果没有像这样的时钟可视化工具,设计和评估此类系统几乎是不可能的,所以请务必使用它。   参考资料 教程视频:如何在 VS Code 环境下使用 MCUXpresso Clocks Too   =========================​ 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便,我们深表歉意,但 在进行咨询时, 请 参考“ NXP 技术问题 - 如何联系我们 ( 日语博客 ) ” 。 (如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ,您可以直接咨询您的代表。) 本指南重点介绍 MCUXpresso 配置工具中的“时钟工具”,解释其基本原理和设置时钟的方法。内容涵盖从在 VS Code 环境中安装到演示 CPU 时钟变化引起的 LED 闪烁等各个方面。 (预计耗时:10 分钟 *假设已安装 MCUXpresso for VSC(Visual Studio Code)SDK) MCUXpresso MCX SW | 下载 日本博客
記事全体を表示
Ara240 - LPDDR4 Memory Compatibility Guide The purpose of this document is to provide extended guidance for selection of compatible LPDDR4 memory devices that are supported by the Ara240 (aka Ara-2) processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the specific SoC requirement documents. LPDDR4 - maximum supported densities SoC Max Data bus width Maximum density Number of Interfaces Assumed memory organization Notes Ara240 64-bit 128Gb/16GB 2 Dual rank, Dual channel device with 17-row addresses 1   LPDDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes Ara240 64Gb/(8GB) Total 128Gb/(16GB) (2 x 64Gb/8GB) Micron   MT53E2G32D4DE-046 AUT:C  MT53E2G32D4DE-046 WT:C - 64Gb/(8GB) Total 128Gb/(16GB) (2 x 64Gb/8GB)   FORESEE FLXC4008G-30  2 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) Micron MT53E512M32D1ZW-046BAUT:B     - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB)   Micron MT53E1G32D2NP-046 WT:B - 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) SK Hynix H54G46CYRQX053N - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) SK Hynix H54G56CYRB-X247 421Y H54G56CYRB-X247 316A - 4Gb/(512MB) Total 8Gb/1GB (2 x 4Gb/1GB) SK Hynix H54G26AYRBX256 - 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) Samsung K4F6E3S4HB-KHCL      - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) ISSI IS43LQ32K01B 2 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) Samsung K4UBE3D4AB-MGCL - 8Gb/(1GB) Total 16Gb/2GB (2 x 8Gb/1GB)   Winbond W66DP2RQQAHJ 2 Note: This device supports operation with LPDDR4 memories only. LPDDR4x operation is not supported. Dual‑mode memories that support both LPDDR4 and LPDDR4x are allowed as long as the device can operate in LPDDR4 mode, including using LPDDR4 I/O voltage levels and initialization sequences. Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4C (LPDDR4). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 3: Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. Note 4: All memory parts are in production unless stated otherwise. Checked June 2026 Note 5: The processor does not support BYTE Mode (x8) memories.  Re: Ara240 - LPDDR4 Memory Compatibility Guide Cross reference: Ara-240 - NVM Memory Compatibility Guide
記事全体を表示