i.MX95 PCIe connection with FPGA This article describes a Full-Bridge PCIe reference design that connects an NXP i.MX95 SoC (acting as PCIe Root Complex) to a Lattice CertusPro-NX / Certus-NX FPGA endpoint, together with a Linux kernel driver. Updating the FPGA bitstream over PCIe is demonstrated as the reference use case, built on top of a general-purpose PCIe data-transfer, register-access and MSI-completion interface. Hardware Host / Root Complex: NXP i.MX95 SoC running Linux (DesignWare PCIe controller) FPGA target / endpoint: Lattice CertusPro-NX PCIe Bridge board (Device ID  0x9C25 ) or Certus-NX (Device ID  0x9C1D ) — Lattice Vendor ID  0x1204 PCIe link: 1-lane (x1), single BAR (BAR1) design Interrupt: 1 MSI vector, EP→Host completion signalling   Board ConnectionBoard Connection Architecture The host application talks to the FPGA through the  kernel driver. The driver exposes BAR1 as a character device and manages two host-side DMA-coherent buffers. Because the design is a full bridge, both sides can initiate PCIe transactions: the host issues MWr/MRd to BAR1, and the FPGA (as bus master) issues its own MWr/MRd back into host memory. Driver ArchitectureDriver Architecture Block Role Application (userspace) Issues IOCTLs; supplies payload and DMA target addresses Driver  lattice_nxp_pcie_ep.c BAR1 MMIO window, SRC/DST DMA buffers, MSI completion, char device  /dev/lattice_nxp_pcie_bar1 FPGA (CertusPro-NX / Certus-NX) PCIe endpoint; executes command, performs MRd/MWr, raises MSI on completion Host memory DMA-coherent SRC and DST buffers   What the driver covers The kernel module is a general-purpose PCIe endpoint transport, not a bitstream-specific driver. It contains no bitstream or image parsing — bitstream update is simply the reference application layered on top of these primitives. It provides three planes: FPGA→Host DMA path (EP-initiated bulk transfer): two host DMA-coherent buffers (SRC/DST, default 4 KB, tunable up to 1 MB). The host fills SRC, programs the FPGA SRC/DST mailbox registers and rings a doorbell; the FPGA (bus master) then moves data via its own MRd/MWr and writes results into the host DST buffer. Usable for any payload. Host↔FPGA BAR1 MMIO window: the char-device  read() / write()  path exposes the whole BAR1 aperture as an 8-byte-granular, byte-addressable window ( readq / writeq , or paired  readl / writel  on 32-bit) for register/RAM access and MWr+MRd readback tests. Control + completion plane: arbitrary 32-bit BAR1 register read/write by offset (the "command" and "doorbell" registers are conventions the application chooses), plus MSI-based completion notification (atomic counter + wait/poll IOCTLs). In short, it is a generic data-transfer + register-access + interrupt-notification interface. Bitstream loading is one application built on it; any host↔FPGA bulk transfer or register-control workflow uses the same primitives. Driver overview —  Probe & init: enable the PCIe device and set bus master → configure the DMA mask (32-bit default, 64-bit fallback) → map BAR1 MMIO → allocate SRC + DST coherent DMA buffers → allocate 1 MSI vector → register  /dev/lattice_nxp_pcie_bar1 . IOCTL interface (9 commands): Command Di r  Description IOCTL_GET_INFO R Return BAR1 size, SRC/DST DMA handles, MSI IRQ number IOCTL_FILL_SRC W Copy userspace buffer into the SRC DMA buffer IOCTL_CLEAR_DMA – Zero the DST DMA buffer before a transfer IOCTL_READ_DMA R Read back bytes from the DST DMA buffer after the FPGA copy IOCTL_WAIT_MSI W Block until the next MSI fires (with  timeout_ms ) IOCTL_WAIT_MSI_SINCE W Block until  msi_count  exceeds a given baseline (race-free) IOCTL_GET_MSI_COUNT R Read the current MSI interrupt counter (atomic u64) IOCTL_WRITE_REG W Write one 32-bit MMIO register in BAR1 by offset IOCTL_READ_REG R Read one 32-bit MMIO register from BAR1 by offset   Driver internals BAR1 read/write paths:  pcie_read()  /  pcie_write()  expose BAR1 as a char device. Accesses must be 8-byte aligned; 64-bit uses  readq / writeq , 32-bit uses paired  readl / writel . MSI ISR:  pcie_isr()  atomically increments  msi_count  and wakes the wait-queue, unblocking  WAIT_MSI  /  WAIT_MSI_SINCE  callers. Verbosity level 2 logs each interrupt with its running count. iATU resync workaround ( FORCE_SYNC_IATU  on probe, the driver clears and then restores the root-port Memory Base/Limit registers to force the DesignWare PCIe block to rebuild its inbound iATU translation table. This is required after an FPGA reconfiguration + PCIe remove + rescan cycle. The macro can be commented out if the workaround is not needed. Note that this alters the upstream port and can affect other PCIe devices on the same bus. Vendor ID:  0x1204   |  Device IDs:  0x9C25  (CertusPro-NX),  0x9C1D  (Certus-NX). Module parameters Parameter Type / default / perm Description verbose int / 1 / 0644 0 = minimal (critical errors only); 1 = info (probe steps, DMA sizes, MSI events); 2 = chatty (all IOCTL calls, read/write rejections, MSI interrupts) dma_bits int / 32 / 0644 DMA address width for coherent-buffer allocation. 32 = default (most platforms); 64 = use if probe fails with  -ENOMEM  (-12) on a 32-bit mask dma_buf_bytes uint / 4096 / 0644 Size (bytes) of each DMA coherent buffer (SRC and DST). Min 256, default 4096 All three parameters are adjustable at load time;  verbose  and  dma_bits  can also be changed at runtime via sysfs.   Known limitations — unsupported PCIe transaction types Configuration Read (CfgRd0 / CfgRd1) — PCIe TLP Type 0/1 config reads are not supported Configuration Write (CfgWr0 / CfgWr1) — PCIe TLP Type 0/1 config writes are not supported Legacy I/O Read (IORd) — x86-style I/O reads are not supported; no I/O BARs are mapped Legacy I/O Write (IOWr) — x86-style I/O writes are not supported; all access goes through BAR1 MMIO Supported: Memory Read (MRd), Memory Write (MWr), and MSI interrupt signalling via the BAR1 mailbox. Reference lattice_nxp_pcie_ep.c  — Linux kernel PCIe EP driver IMX95EVK

NXP Trimension® SR250で始めるUWB入門 第1回：UWBの基礎とSR250の概要 (日本語ブログ) はじめに   「スマホをポケットに入れたままドアが開く」「部屋に入ったら自動で照明がつく」「ソファに座った瞬間、サウンドバーが自分の位置に合わせて音場を自動調整してくれる」── こんな体験を実現できるデバイスが NXP Trimension® SR250 です。 SR250は、超高精度な無線測距技術「UWB (Ultra-Wideband：超広帯域無線)」と、相手デバイスなしで人や物体を感知できる「UWBレーダー」を、IoT向けとして世界初となるオンチップ処理付きで1チップに統合したICです。 そんな様々な可能性を秘めたこのSR250が、2026年3月、ついにマスマーケット向けリリースされました！評価ボード SR250UWBSHIELD が NXPのeコマースで購入できます。 SR250UWBSHIELD.jpgSR250UWBSHIELD.jpg 「面白そうだけど、難しそうかな？」と思っていたあなた、今が試してみるチャンスです。 第1回はUWBとはそもそも何かという基礎から、SR250の特徴までをお届けします。本稿を読んで想像をふくらませ、ぜひ評価ボードを入手して一緒にUWBを体験しましょう！ UWBって、昔どこかで聞いたことがある？   「UWBって、昔の高速データ転送技術では？」と思った方、鋭いです！ 2000年代初頭、UWBは高速ワイヤレスデータ転送技術として大きな注目を集めました。WiMediaアライアンスが標準化を進めましたが、Wi-FiやBluetoothの急速な進化に押され、普及しないまま終わりました。 ところが2010年代後半、UWBは全く別の顔で復活します。精密測距・測位の技術として再定義され、IEEE 802.15.4zとして標準化。2019年 iPhone 11への搭載を機に、一気に注目度が高まりました。 UWBが広い帯域幅を持つという本質は変わっていません。ただ、その特性を「通信速度」ではなく「時間分解能」として使うことで、まったく新しい用途が生まれたのです。 UWBとは？ ─ センチメートルの世界へ   UWB (Ultra-Wideband) は、名前の通り周波数軸で見れば超広帯域、逆に時間軸で見ると非常に短いパルス信号を使った無線技術です。IEEE 802.15.4z規格として標準化されており、近距離高精度測位の分野で今まさに急速に普及しています。 Wi-FiやBluetoothの位置精度が±1〜2mであるのに対して、UWBは±5〜10cmのセンチメートル精度を実現できます。これは「どこかにいる」ではなく「ここにいる」を検知できる技術です。 このセンチメートル精度と高いセキュリティの組み合わせが、スマートカーアクセスや精密な屋内測位を可能にしています。Androidスマートフォン・AirTagに加え、*Google Pixel Tagへの搭載も発表され、今後さらなる普及が期待されています。 *Google Pixel Tagは2026年11月発売予定 なぜUWBはマルチパスに強く、セキュアなのか？ ─ 他無線技術との比較   マルチパスとは？   電波は光のように直進するだけでなく、壁・天井・家具などに反射しながら伝わります。受信側には「直進してきた電波」と「あちこちで反射してから届いた電波」が混ざって届きます。これがマルチパスです。特に屋内では反射が多く、マルチパスの環境となります。 マルチパス_イメージ図.jpgマルチパス_イメージ図.jpg BLEやWi-FiのようなRSSI (受信強度) ベースの測距は、この「混ざった電波の強さ」を使って距離を推定するため、反射波に大きく左右されてしまいます。 UWBは非常に短いパルス信号 (数ナノ秒幅) を使っているため、直接届いた信号と反射して後から届いた信号を時間的に分離して識別できます。   なぜUWBの測距はセキュアなのか？ UWBは、 STS (Scrambled Timestamp Sequence：スクランブルされたタイムスタンプシーケンス) と呼ばれる暗号化された信号列を使用しています。STSはAES-128ベースの乱数生成器によって毎回異なる値が生成されます。受信側は事前に共有した鍵から同じSTSを計算し、受信値と照合することで、正規の送信元かどうかを検証します。 STSは毎回異なる値が生成されるため、傍受した信号をそのまま再送したり(リプレイアタック）、中継・偽装して距離を誤認識させたりする攻撃が成立しません。さらにセキュアレンジングでは、STS生成に使うセッション鍵をセキュアな環境で管理し、定期的に再計算します。仮に特定時点の鍵情報が漏洩しても被害範囲を限定できます。これらにより、UWBはBLEやWi-Fiベースのレンジングよりも強固なセキュリティを実現しています。   測距技術の比較   技術 精度 マルチパス耐性 セキュリティ 主な用途 UWB ±5~10 cm 高 (パルスで直接波を分離) 高 (STS暗号化) 精密測位・スマートアクセス BLE Channel Sounding ±0.5 m 中 (位相測定で改善) 中 (RTT+位相で保護) スマートアクセス・IoT Wi-Fi RTT (FTM) ±1〜2 m 低〜中 低 屋内ナビ・フロア判定 BLE RSSI ±1〜5 m 低 (強度ベース) 低 近接検知・ビーコン BLE Channel Soundingなど他技術はコスト・消費電力面での利点もあるため、用途に応じた使い分けやUWBとのハイブリッド構成も増えています。 UWBの測距原理：ToF と AoA   ToF (Time of Flight：飛行時間) TWR (Two Way Ranging) では、InitiatorがパルスをResponderに送り、Responderが折り返すことで、Initiatorが電波の往復時間を計測し距離を算出します。電波は光速で伝わるため、わずかな時間誤差が距離誤差に直結します。広帯域であるほど時間分解能が上がり、距離精度が向上するのです。 また、複数デバイスを組み合わせたTDOA (Time Difference of Arrival) にも対応しており、広いエリアのリアルタイム測位も可能です。 AoA (Angle of Arrival：到達角度) 複数のアンテナで受信した信号の位相差（PDOA, Phase Difference of Arrival）から、デバイスが存在する角度を算出します。SR250は3つの受信ポートを持つため、水平方向と垂直方向を同時に算出する3シングルショット3D AoA が可能です。   UWBレーダーとは？   測距 (Ranging) は2台のUWBデバイスが通信し合うことで距離を測りますが、レーダーはまったく異なるアプローチをとります。送信したパルスが人や物体に当たって反射してくる信号を解析することで、相手がUWBデバイスを持っていなくても距離・方向・存在を検知できるのです。 UWBレーダーは人体のわずかな動きを捉えることができ、プライバシーを守りながら「その場に人がいるか」「動いているか」を感知できます。 UWBレーダー.jpgUWBレーダー.jpg レーダー処理はSR250にお任せ！オンチップ・レーダー処理   レーダーのアルゴリズムは複雑で、独自に構築するのは容易ではありません。SR250は、単一ターゲットの存在・距離・角度検知まではオンチップで処理できるよう設計されており、アルゴリズム開発無しでレーダー機能を使うことができます。もっと複雑なレーダー処理をしたい場合は、反射はデータをホストに送ることでAI/MLを使用した応用も可能です。 SR250が切り拓くアプリケーション   測距とレーダーを1チップに統合したSR250は、スマートロック・スマートスピーカーといった民生機器から、工場・倉庫でのAGV (無人搬送車) やフォークリフトと作業者の衝突防止といった産業用途まで、幅広い分野での活用が期待されています。 「位置を知る」「存在を知る」「動きを知る」─ この3つがカメラなしでできるとしたら、どんな機器が作れるでしょうか。ぜひ想像しながら連載を読み進めてください。 連載の予定   本連載は全4回を予定しています。 第1回（本記事） UWBの基礎とSR250の概要 第2回 SR250評価ボード (SR250UWBSHIELD) のセットアップ 第3回 UWB測距 (Ranging) を試してみる 第4回 UWBレーダー (Radar)を試してみる 次回は評価ボードの入手方法・ハードウェア・ソフトウェア環境の構築を解説します。UWBを動かす準備を一緒に整えましょう！ 参考リンク Trimension SR250 製品ページ（日本語） SR250 評価ボード（TRIMENSION-SR250） UWB Radar Fundamentals (AN13989) UWB Convergence Radar ホワイトペーパー Introducing The Trimension SR250 トレーニング（英語・24分） ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） センチメートル精度の測距と、相手デバイス不要のUWBレーダーを1チップに統合したNXP Trimension® SR250が、2026年3月にマスマーケット向けにリリースされました。本記事では、UWBの基礎原理からSR250の特徴を解説します。 (読了：10分) Security 日本語ブログ

Getting Started with UWB Using NXP Trimension® SR250 - Part 1: UWB Basics and an Overview of the SR250 (Japanese Blog) Introduction   "Doors open with your smartphone still in your pocket," "Lights turn on automatically when you enter a room," "The moment you sit down on the sofa, the soundbar automatically adjusts the sound field to your position"—the NXP Trimension ® SR250 is a device that can make these experiences a reality. The SR250 is the world's first IC for IoT applications to integrate ultra-high-precision wireless ranging technology " UWB (Ultra-Wideband) " and " UWB radar " that can detect people and objects without an external device, all on a single chip with on-chip processing. This SR250, which holds so much potential, was finally released to the mass market in March 2026! The evaluation board SR250UWBSHIELD is available for purchase from NXP's e-commerce site . SR250UWBSHIELD.jpgSR250UWBSHIELD.jpg If you've been thinking, "That sounds interesting, but it might be difficult," now's your chance to give it a try. In this first installment, we'll cover everything from the basics of what UWB is to the features of the SR250. Read this article to expand your imagination, and then get your hands on an evaluation board and experience UWB together! Have you heard of UWB somewhere before?   If you're thinking, "Isn't UWB an old high-speed data transfer technology?", you're very perceptive! In the early 2000s, UWB attracted considerable attention as a high-speed wireless data transfer technology . The WiMedia Alliance worked to standardize it, but it ultimately failed to gain widespread adoption due to the rapid evolution of Wi-Fi and Bluetooth. However, in the late 2010s, UWB made a comeback in a completely different form. It was redefined as a precision distance measurement and positioning technology and standardized as IEEE 802.15.4z. Its inclusion in the iPhone 11 in 2019 brought it a surge in popularity. The fundamental characteristic of UWB—its wide bandwidth—remains unchanged. However, by using this characteristic not as "communication speed" but as "temporal resolution," entirely new applications have emerged. What is UWB? — Into the world of centimeters   UWB (Ultra-Wideband), as its name suggests, is a wireless technology that uses extremely wide bandwidth in terms of frequency, and conversely, very short pulse signals in terms of time. It has been standardized as the IEEE 802.15.4z standard and is currently rapidly gaining popularity in the field of short-range high-precision positioning. While Wi-Fi and Bluetooth have a positioning accuracy of ±1-2m, UWB can achieve centimeter-level accuracy of ±5-10cm. This technology can detect "here" rather than "somewhere." This combination of centimeter-level accuracy and high security enables smart car access and precise indoor positioning. In addition to Android smartphones and AirTag, it has also been announced that it will be integrated into Google Pixel Tag, and further widespread adoption is expected in the future. *Google Pixel Tag is scheduled for release in November 2026. Why is UWB so robust against multipath interference and secure? — A comparison with other wireless technologies   What is multipathing?   Radio waves don't just travel in a straight line like light; they also propagate by reflecting off walls, ceilings, furniture, and other objects. The receiver receives a mixture of radio waves that traveled in a straight line and those that have reflected from various points. This is called multipath. Indoors, in particular, there are many reflections, creating a multipath environment. マルチパス_イメージ図.jpgMultipath_Image.jpg RSSI (Radio Speed Indicator) based ranging methods like BLE and Wi-Fi estimate distance using the "strength of mixed radio waves," making them highly susceptible to reflected waves. Because UWB uses very short pulse signals (a few nanoseconds wide), it can temporally separate and distinguish signals that arrive directly from signals that are reflected and arrive later.   Why is UWB ranging secure? UWB uses an encrypted signal sequence called STS (Scrambled Timestamp Sequence). The STS is generated each time by an AES-128-based random number generator, producing a different value each time . The receiver calculates the same STS using a pre-shared key and verifies the legitimacy of the sender by comparing it with the received value. Because a different STS value is generated each time, attacks that involve retransmitting intercepted signals (replay attacks) or relaying/spoofing signals to misinterpret distance are impossible. Furthermore, in secure ranging, the session key used to generate the STS is managed in a secure environment and recalculated periodically. Even if the key information at a specific point in time is leaked, the scope of damage can be limited. As a result, UWB achieves stronger security than BLE or Wi-Fi-based ranging.   Comparison of distance measurement technologies   technology accuracy Multipath resistance security Main uses UWB ±5~10 cm High ( separates waves directly with pulses) High (STS encryption) Precision positioning and smart access BLE Channel Sounding ±0.5 m Medium (improved by phase measurement) Medium (Protected by RTT+ phase) Smart Access IoT Wi-Fi RTT (FTM) ±1 to 2 m low to medium low Indoor navigation and floor detection BLE RSSI ±1 to 5 m Low (intensity-based) low Proximity detection and beacons Other technologies, such as BLE Channel Sounding, offer advantages in terms of cost and power consumption, leading to an increase in their use depending on the application, as well as hybrid configurations with UWB. UWB ranging principle: ToF and AoA   ToF (Time of Flight) In TWR (Two-Way Ranging), the Initiator sends a pulse to the Responder, which then returns it. The Initiator measures the round-trip time of the radio waves and calculates the distance. Because radio waves travel at the speed of light, even a small time error directly translates to a distance error. The wider the bandwidth, the higher the time resolution and the better the distance accuracy. Furthermore, it supports TDOA (Time Difference of Arrival) by combining multiple devices, enabling real-time positioning over a wide area. AoA (Angle of Arrival) The angle at which a device is located is calculated from the phase difference of arrival (PDOA) of signals received by multiple antennas. Because the SR250 has three receiving ports, it can perform 3-single-shot 3D AoA , simultaneously calculating horizontal and vertical angles.   What is UWB radar?   While ranging measures distance through communication between two UWB devices, radar takes a completely different approach. By analyzing the signals reflected from pulses that hit people or objects, it can detect distance, direction, and presence even if the other party does not have a UWB device . UWB radar can detect even the slightest movement of the human body, allowing you to sense whether there is a person present and whether they are moving, while protecting privacy. UWBレーダー.jpgUWB radar.jpg Leave radar processing to the SR250! On-chip radar processing   Radar algorithms are complex and not easy to develop from scratch. The SR250 is designed to handle the detection of a single target's presence, distance, and angle on-chip , allowing you to use radar functionality without developing your own algorithms. For more complex radar processing, reflections can be sent to a host, enabling AI/ML applications. Applications pioneered by the SR250   The SR250, which integrates ranging and radar into a single chip, is expected to be used in a wide range of fields, from consumer devices such as smart locks and smart speakers to industrial applications such as collision prevention between AGVs (automated guided vehicles) and forklifts and workers in factories and warehouses. "Knowing location," "Knowing presence," and "Knowing movement"—what kind of devices could be created if these three things were possible without a camera? Please read the series while imagining these possibilities. Scheduled serialization   This series is planned to consist of four parts. Part 1 (This article) Basics of UWB and an overview of the SR250 2nd time Setting up the SR250 evaluation board (SR250UWBSHIELD) 3rd Let's try UWB ranging. 4th Try out UWB radar. Next time, we'll explain how to obtain an evaluation board and how to set up the hardware and software environment. Let's get ready to run UWB together! Reference links Trimension SR250 Product Page (Japanese) SR250 Evaluation Board (TRIMENSION-SR250) UWB Radar Fundamentals (AN13989) UWB Convergence Radar White Paper Introducing the Trimension SR250 Training (English, 24 minutes) ========================= 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 an inquiry. (If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) The NXP Trimension® SR250, which integrates centimeter-precision ranging and a UWB radar that does not require a separate device onto a single chip, was released for the mass market in March 2026. This article explains the basic principles of UWB and the features of the SR250. (Reading time: 10 minutes) Security Japanese Blog

使用 NXP Trimension® SR250 入门 UWB - 第一部分：UWB 基础知识和 SR250 概述（日语博客） 介绍   “智能手机还在口袋里时，门就会打开”、“当你进入房间时，灯会自动打开”、“当你坐在沙发上时，条形音箱会自动调整声场以适应你的位置”——NXP Trimension ® SR250是一款能够将这些体验变为现实的设备。 SR250 是世界上首款用于物联网应用的集成电路，它集成了超高精度无线测距技术“ UWB（超宽带） ”和“ UWB 雷达”，无需外部设备即可在单个芯片上通过片上处理检测人和物体。 这款极具潜力的 SR250 终于在 2026 年 3 月面向大众市场发布！评估板SR250UWBSHIELD可从NXP 的电子商务网站购买。 SR250UWBSHIELD.jpgSR250UWBSHIELD.jpg 如果你一直在想，“这听起来很有趣，但可能很难”，那么现在就是你尝试的机会。 在本系列文章的第一部分，我们将涵盖从UWB基础知识到SR250特性的所有内容。阅读本文，拓展您的想象力，然后入手一块评估板，一起体验UWB的魅力吧！ 你之前听说过UWB吗？   如果你在想，“UWB 不是一种老旧的高速数据传输技术吗？”，那你真是太有洞察力了！ 21世纪初，超宽带（UWB）作为一种高速无线数据传输技术引起了广泛关注。WiMedia联盟致力于将其标准化，但由于Wi-Fi和蓝牙的快速发展，最终未能得到广泛应用。 然而，在2010年代后期，UWB以一种截然不同的形式卷土重来。它被重新定义为一种精密距离测量和定位技术，并被标准化为IEEE 802.15.4z标准。2019年，iPhone 11搭载了这项技术，使其人气飙升。 超宽带（UWB）的基本特性——宽带宽——依然不变。然而，通过不再将这一特性视为“通信速度”，而是将其视为“时间分辨率”，全新的应用场景应运而生。 什么是UWB？——走进厘米的世界   超宽带（UWB）顾名思义，是一种无线技术，它使用极宽的频率带宽，相应地，使用极短的脉冲信号。该技术已被标准化为IEEE 802.15.4z标准，目前在短距离高精度定位领域正迅速普及。 虽然 Wi-Fi 和蓝牙的定位精度为 ±1-2 米，但 UWB 可以达到厘米级精度，为 ±5-10 厘米。这项技术可以检测“这里”，而不是“某个地方”。 厘米级的精度和高安全性相结合，实现了智能汽车门禁和精准的室内定位。除了安卓智能手机和AirTag之外，该技术还将集成到谷歌Pixel Tag中，预计未来将得到更广泛的应用。 *谷歌Pixel Tag计划于2026年11月发布。 为什么UWB对多径干扰的抵抗力如此之强且安全性如此之高？——与其他无线技术的比较   什么是多路径？   无线电波的传播方式并非像光一样沿直线传播；它们还会通过墙壁、天花板、家具和其他物体的反射而传播。在接收端，接收到的无线电波既有“沿直线传播的无线电波”，也有“从不同位置反射的无线电波”。这种现象被称为多径效应。尤其是在室内，反射现象更为普遍，从而形成多径环境。 マルチパス_イメージ図.jpgMultipath_Image.jpg 基于 RSSI（无线电速度指示器）的测距方法，如 BLE 和 Wi-Fi，利用“混合无线电波的强度”来估算距离，因此极易受到反射波的影响。 由于超宽带使用非常短的脉冲信号（几纳秒宽），因此它可以将直接到达的信号与反射后稍后到达的信号在时间上分离和区分。   为什么UWB测距是安全的？ 超宽带 (UWB) 使用一种称为STS （加扰时间戳序列）的加密信号序列。STS 每次都由基于 AES-128 的随机数生成器生成，每次生成的值都不同。接收方使用预共享密钥计算相同的 STS，并通过将其与接收到的值进行比较来验证发送方的合法性。 由于每次都会生成不同的STS值，因此涉及重传截获信号（重放攻击）或中继/欺骗信号以错误解读距离的攻击都无法实施。此外，在安全测距中，用于生成STS的会话密钥在安全环境中进行管理并定期重新计算。即使在特定时间点密钥信息泄露，造成的损失范围也有限。因此，UWB测距比基于BLE或Wi-Fi的测距具有更高的安全性。   距离测量技术比较   技术 准确性 多路径电阻 安全 主要用途 超宽带 ±5~10 厘米 高（直接用脉冲分离波） 高（STS加密） 精准定位和智能访问 BLE通道探测 ±0.5 米 介质（通过相位测量改进） 介质（受 RTT+ 相保护） 智能接入物联网 Wi-Fi RTT（FTM） ±1 至 2 米 低至中等 低的 室内导航和楼层检测 BLE RSSI ±1 至 5 米 低（基于强度） 低的 近距离检测和信标 其他技术，如 BLE 通道探测，在成本和功耗方面具有优势，因此根据应用的不同，其使用量有所增加，还可以与 UWB 进行混合配置。 UWB测距原理：飞行时间（ToF）和迎角（AoA）   飞行时间 (ToF) 在双向测距（TWR）中，发起方向响应方发送脉冲信号，响应方随后返回该信号。发起方测量无线电波的往返时间并计算距离。由于无线电波以光速传播，即使是很小的时间误差也会直接转化为距离误差。带宽越宽，时间分辨率越高，距离精度也越高。 此外，它通过组合多个设备支持 TDOA（到达时间差），从而实现大范围的实时定位。 到达角 (AoA) 设备所在位置的角度是通过多个天线接收到的信号的到达相位差 (PDOA) 计算得出的。由于 SR250 具有三个接收端口，因此可以执行3 次单次拍摄的 3D 到达角 (AoA)计算，同时计算水平角和垂直角。   什么是超宽带雷达？   测距是通过两个超宽带（UWB）设备之间的通信来测量距离，而雷达则采用完全不同的方法。它通过分析照射到人或物体上的脉冲反射信号，即使对方没有超宽带设备，也能探测到距离、方向和目标是否存在。 UWB 雷达甚至可以探测到人体最轻微的动作，让您能够感知周围是否有人以及他们是否在移动，同时保护隐私。 UWBレーダー.jpgUWB雷达.jpg 把雷达处理交给SR250吧！片上雷达处理   雷达算法复杂，从零开始开发并非易事。SR250芯片旨在处理单个目标的存在、距离和角度检测，无需自行开发算法即可使用雷达功能。对于更复杂的雷达处理，反射信号可以发送到主机，从而支持人工智能/机器学习应用。 SR250 开创的应用   SR250 将测距和雷达功能集成到单个芯片中，预计将广泛应用于各个领域，从智能锁和智能音箱等消费电子产品到工厂和仓库中 AGV（自动导引车）与叉车和工人之间的碰撞预防等工业应用。 “感知位置”、“感知存在”和“感知移动”——如果无需摄像头就能实现这三件事，那么可以创造出什么样的设备？请在阅读本系列文章的同时，畅想这些可能性。 计划序列化   本系列计划分为四部分。 第一部分（本文） UWB基础知识及SR250概述 第二次 设置 SR250 评估板 (SR250UWBSHIELD) 第三 我们来试试超宽带测距。 第四 试试超宽带雷达。 下次，我们将讲解如何获取评估板以及如何搭建硬件和软件环境。让我们一起准备运行UWB吧！ 参考链接 Trimension SR250 产品页面（日语） SR250 评估板 (TRIMENSION-SR250) 超宽带雷达基础知识（AN13989） 超宽带融合雷达白皮书 Trimension SR250 培训介绍（英语，24 分钟） ========================= 即使您在本文的“评论”栏留言，我们目前也无法回复。 给您带来不便，我们深感抱歉。请在询问时参阅“NXP技术问题-联系方式(日本博客)”。 （如果您已经是NXP的代理商或与其有合作关系，可以直接向负责人咨询。） NXP Trimension® SR250 将厘米级精度的测距和无需单独设备的超宽带雷达集成到单个芯片上，于 2026 年 3 月面向大众市场发布。本文将解释超宽带的基本原理和 SR250 的特性。 （阅读时间：10分钟） 安全 日本博客

eIQ Time Series Studioを使い始める このラボでは、eIQ Time Series Studio（TSS）の使用方法を説明します。この新しいツールはeIQ Tookitに含まれており、埋め込みマイクロコントローラ向けの時系列モデルの作成に使用されます。時系列データをインポートする方法、複数のMLアルゴリズムを生成する方法、生成モデルを開発ボードにデプロイする方法を取りあげます。 ラボではFRDM-MCXN947を使用しますが、eIQ Time Series Studioでサポートされているあらゆるデバイスで同じ手順が適用されます。 MCX FRDM-MCXA153 FRDM-MCXN947 MCX-N9XX-EVK i.MX RT i.MXRT685-EVK i.MXRT595-EVK MIMXRT1060-EVK MIMXRT1170-EVK MIMXRT1180-EVK LPC LPC55S69-EVK Kinetis FRDM-K66F FRDM-KV31F FRDM-K32L3A6 DSC MC56F83000-EVK MC56F80000-EVK   Time Series Studioプロセスの概要をすばやくつかむには、以下の動画もご覧ください。 (マイビデオで視聴) Time Series Studioで使用可能なセンサ・データの収集ツールについては、アプリケーション・コード・ハブのML Universal Datalogger もご覧ください。 i.MX RT

Getting Started with eIQ Time Series Studio This lab will walk through how to use eIQ Time Series Studio (TSS) to create time series models for embedded microcontrollers.  It covers how to import time series data, shows how the tool can generate multiple machine learning (ML) algorithms, and describes how to deploy those generated models to your development board. eIQ Time Series Studio is available as a standalone installer or via a web interface.  This lab uses the FRDM-MCXN947 but the same steps will apply to any of the devices supported by eIQ Time Series Studio. You can also use NXP devices not listed here by selecting the closest related device family while going through the lab: MCX FRDM-MCXA156 FRDM-MCXC444 FRDM-MCXE247 FRDM-MCXN236 FRDM-MCXN947 FRDM-MCXW71 i.MX RT i.MXRT700-EVK i.MXRT685-EVK i.MXRT595-EVK MIMXRT1060-EVK MIMXRT1170-EVK MIMXRT1180-EVK i.MX6 MCIMX6ULL-EVK i.MX8 8MPLUSLPD4-PEVK i.MX9 i.MX93EVK RW FRDM-RW612 LPC LPC55S69-EVK Kinetis FRDM-K66F FRDM-KV31F FRDM-K32L3A6 DSC MC56F83000-EVK MC56F80000-EVK The labs are written for either VS Code or MCUXpresso IDE, but the same concepts can be used for other IDEs.  You can also view the video below for a quick overview of the Time Series Studio process.  (function() { var wrapper = document.getElementById('lia-vid-6390665301112w960h540r485'); 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) Also check out the ML Universal Datalogger on the App Code Hub for a tool to collect sensor data that can be used with the Time Series Studio, as well as the Time Series Studio examples on App Code Hub. Also see this document for details on how to add TSS libraries to existing projects.  --- Updated September 2026 to clarify supported devices.  i.MX RT

eIQ 时间序列工作室入门指南 本实验将指导您如何使用 eIQ 时间序列工作室（TSS），这是一款集成于 eIQ 工具包 的全新工具，用于为嵌入式微控制器开发时间序列模型。实验内容涵盖：时间序列数据导入方法、工具如何生成多种机器学习算法，以及如何将生成的模型部署至开发板。本实验基于 FRDM-MCXN947 开发板，但相同步骤适用于所有 eIQ 时间序列工作室 支持的设备。 MCX FRDM-MCXA153 FRDM-MCXN947 MCX-N9XX-EVK i.MX RT i.MXRT685-EVK i.MXRT595-EVK MIMXRT1060-EVK MIMXRT1170-EVK MIMXRT1180-EVK LPC LPC55S69-EVK Kinetis FRDM-K66F FRDM-KV31F FRDM-K32L3A6 DSC MC56F83000-EVK MC56F80000-EVK   您还可以观看下方的视频，以快速了解 Time Series Studio 的流程。 （在 “我的视频” 中查看） 您还可通过 App Code Hub 获取 ML 通用数据记录器 工具，用于收集可与时间序列工作室配合使用的传感器数据。 i.MX RT

Ara240 DNPU Hands-On Training Ara240 product image.jpgAra240 product image.jpg Welcome to the Ara240 DNPU Training! This page provides access to training materials, presentations, demos, recordings, and supporting resources related to the Ara240 DNPU. While live Q&A support will be available during the training period, all content will remain accessible for future reference and self-paced learning. Required Hardware FRDM i.MX 95 Pro FRDM i.MX 8M Plus Ara240 DNPU Ara240 16GB M.2 Module microSD >= 64GB storage USB-C debug cable Internet (Ethernet) HDMI Monitor 100 W power supply (Anker Charger is recommended) USB mouse USB keyword 1080p USB Camera Instructions Step1. Watch introduction DNPU Training Introduction Step2. Check the Hardware and Software Pre-requisites Getting Started Guide with FRDM-IMX8MPLUS Step3. Run the rest of the Software demo packages After completing the pre-work, each lab has its own guide document and a video guide you can use as support material in case you have any question at any step: Lab1: Running a GStreamer Pipeline for 8 Video Streams with YOLOv8n on Ara240 DNPU Ara Vision Multi-Stream YOLOv8 Object Detection Lab2: Running Unimodal Large Language Models on Ara240 DNPU LLM Edge Studio Lab3: Interacting with Vision-Language Models on Ara240 DNPU VLM Edge Studio Lab4: Enabling REST-Based LLM and VLM Inference on Ara240 DNPU eIQ AAF Connector Additional Resources Take advantage of the resources below to deepen your knowledge and support your development efforts: Ara Software Development Kit (ARA SDK) Ara240 DNPU Six Pack Ara240 Discrete Neural Processing Unit (DNPU) Ara240 16GB M.2 Module FRDM i.MX 95 Pro FRDM i.MX 8M Plus ARA240 DNPU Hands-On Training

bootloader需要fs26安装包 目前我在使用unified_bootloader_demo_v2.1，进行基于s32k344的bootloader工程移植开发，rtd使用2.0，我的控制器使用fs26芯片，fs26 sbc驱动包最低匹配rtd3.0，能提供给我匹配rtd2.0的 sbc包或者手写实现代码？如果能提供rtd3.0以上bootloader工程更好了？ 十分感谢！ 回复： bootloader需要fs26安装包 你好，图片1是需要修改startup_cm7.s启动文件中，关于ram初始化的启动，我为了尽量少的改动，可以bootloader v2.1中只修改extern void Boot_PowerONClearAllFlag(void);这样可以吗？ 回复： bootloader需要fs26安装包 你好， 我现在使用bootloader的 v2.1进行修改，说是ecc校验4字节出现错误，此函数 Boot_PowerONClearAllFlag需要修改，直接进行8字节校验，发现启动函数只有ExchangeInfo区域没有初始化，我这样修改可以吗？ /*when power on, clear all flag in RAM for ECC.*/ void Boot_PowerONClearAllFlag(void) {     uint16 infoCrc = 0u;     uint8 index = 0u;     /*clear RAM with 8 bytes for ECC*/     for(index = 0u; index < (gs_stBootInfo.infoDataLen >> 3u); index++)     {         *((uint64 *)gs_stBootInfo.infoStartAddr + index) = 0u;     }         infoCrc = Boot_CalculateInfoCRC();     SetInforCRC(infoCrc);   } 回复： bootloader需要fs26安装包 Hi 很抱歉，社区分享的Unified bootloader Demo按“原样”提供，没有更高S32K3 RTD版本例程。由此造成的不便，我们深表歉意。 FS26 SBC Autosar 4.4 version 1.0.0 是搭配S32K3 RTD 2.0.0的，我已经向内部团队帮你申请这个旧版本驱动，请等待他们为你账号添加该版本软件下载权限。 顺便提一句，需要注意例程里一个错误。S32K3常见问题检查列表(Check list)分享的 "3.4.3 需要使用8字节写的方式对RAM进行ECC初始化"有提到： 检查RAM（特别注意Standby RAM）进行ECC初始化时是否按照8字节写的方式。 例如：*(uint64 *)0x20400000 = 0; 不遵守可能ECC错误。 在NXP做的BOOTLOADER示例工程中使用了4字节清零的ECC初始化方式， *(uint32 *)0x20400000 = 0; 是错误的，不要参照。 S32K3 sharing data between Bootloader and Application里也有关于此的讨论。 Best Regards, Robin

The bootloader requires the fs26 installation package. I am currently using unified_bootloader_demo_v2.1 to port and develop a bootloader project based on S32K344. The RTD is version 2.0, and my controller uses the FS26 chip.The SBC driver package is at least compatible with RTD 3.0; could you provide one compatible with RTD 2.0?SBC package or handwritten implementation code? Even better if you could provide a bootloader project for RTD 3.0 or higher? Thank you so much! 回复： bootloader需要fs26安装包 Hello, I'm currently modifying bootloader v2.1, and it says there's an error in the ECC checksum of 4 bytes. This function... Boot_PowerONClearAllFlag needs to be modified. Directly performing an 8-byte check reveals that only the ExchangeInfo area in the startup function is not initialized. Is this modification acceptable? /*when power on, clear all flag in RAM for ECC.*/ void Boot_PowerONClearAllFlag(void) { uint16 infoCrc = 0u; uint8 index = 0u; /*clear RAM with 8 bytes for ECC*/ for(index = 0u; index < (gs_stBootInfo.infoDataLen >> 3u); index++) { *((uint64 *)gs_stBootInfo.infoStartAddr + index) = 0u; } infoCrc = Boot_CalculateInfoCRC(); SetInforCRC(infoCrc); } 回复： bootloader需要fs26安装包 Hi We apologize that the Unified bootloader demo shared by the community is provided "as is," without examples of higher S32K3 RTD versions. We sincerely apologize for any inconvenience this may cause. The FS26 SBC Autosar 4.4 version 1.0.0 is designed for use with the S32K3 RTD 2.0.0 . I have already requested this older version driver from the internal team for you. Please wait for them to add download permissions for this version of the software to your account. Incidentally, there's an error in the example code that needs attention. The S32K3 common problem checklist, specifically section 3.4.3 , mentions the need to use 8- byte writes for ECC initialization of RAM. Check whether the RAM (pay special attention to the standby RAM) is written in 8-byte format during ECC initialization. For example: *(uint64 *)0x20400000 = 0; Failure to comply may result in an ECC error. The NXP bootloader sample project uses a 4-byte zeroing ECC initialization method. *(uint32 *)0x20400000 = 0; That's incorrect; don't refer to it. There is also a discussion about this in the section on S32K3 sharing data between Bootloader and Application . Best Regards, Robin 回复： bootloader需要fs26安装包 Hello, in image 1, I need to modify the startup_cm7.s startup file regarding RAM initialization. To minimize changes, can I simply modify `extern void Boot_PowerONClearAllFlag ( void );` in bootloader v2.1?

NTAG 224/223 ドキュメント こんにちは、 223/224 TTタグとNon-TTタグの設定ページのドキュメントを見ているのですが、223 DNA(非TT)構成は他のタグとはかなり異なっているようで、SUNCMAC_KEY 2つの別々の領域に分かれて漂っています。これはドキュメントの誤りのように思われますので、問題を解決するか誤解を解消するためにお知らせしたいと思います。 敬具 ティノ 223 TT223 TT 223223 224224 224 TT224 TT Re: NTAG 224/223 Documentation こんにちは、 @TinoFさん 異なる製品のメモリ配置は必ずしも同じではありません。NTAG 224 DNAは223 DNAより64バイト多いユーザーメモリを持ち、さらにAES相互認証キー領域も追加されています。したがって、SUNCMAC_KEYの出発住所は34時間から44時間に変更されており、これは合理的な製品設計の違いであり、ドキュメントの誤りではありません。

imxrt1024..5A 中的安全启动 Abhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.pngAbhay2080_0-1788352073442.png 我附上了有符号图像和无符号图像（使用 SPT 签名）的十六进制比较截图。 我发现 IVT 有一些我不理解的变化。 在偏移量 0x1000 处 未签名 -> D1 00 20 41 00 20 00 60 00 00 00 00 00 00 00 00 签名 -> D1 00 20 40 DD 22 00 60 00 00 00 00 00 00 00 00 问题 1：我理解 41 是我代码中硬编码的 IVT 版本，如何将其更改为 40？ 问题 2. 另外，我不明白 00 20 如何变成 DD 22 在 0x1010 偏移处 这一点很明显，因为这里的 CSF 指针已经更新了。 在 0x1020 处 无符号 -> 00 00 00 60 00 00 40 00 00 00 00 00 签名 -> 00 00 00 60 00 A0 00 00 00 00 00 00 问题 3：如何将 00 40 更新为 A0 00？ 我之所以问这些问题，是因为据我理解，如果开发团队提供的是可启动二进制文件，那么我只需要追加 CSF.bin 文件并更新 IVT 中的 CSF 指针即可使其签名。但看到差异后，我觉得其中还有更多因素在起作用。 Re: Secure boot in imxrt1024..5A Abhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.pngAbhay2080_0-1788520801299.png 我在之前的帖子中得到了这个答案，所以我认为只要在 IVT 中添加 csf 并更新 vsff 指针就意味着固件已经签名，但是因为我想使用 CST 对镜像进行签名，该怎么做呢？ 我已经有了可启动镜像（FCFB、IVT、BOOTDATA 等）。我只需要签名并打包发货，该怎么做呢？我已经创建了 hab.csf 文件。 [标题] 版本 = 4.0 #可用的引擎有DCP、SW、ANY，适用于IMXRT 引擎 = DCP 发动机配置 = 0 证书格式 = x509 签名格式 = CMS 哈希算法 = sha256 #安装根公钥，以便在后续的 INSTALL CSFK 或 Install KEY 中使用。 #HAB 安装在其内部公钥存储的第 0 个插槽中 # HAB 只是重新哈希表并与熔丝的 SRK 哈希进行比较。 [安装SRK] 文件 = "keys/SRK_1_2_3_4_table.bin" #请指定要使用的SRK，如果此索引的撤销熔丝被烧毁，安装将失败。 源索引 = 0 哈希算法 = sha256 #HAB 在插槽 1 中安装 CSF 密钥的证书 [安装 CSFK] 文件 = "crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem" 证书格式 = x509 #Authenticate CSF 命令用于验证执行该命令的 CSF。 [验证脑脊液] #安装公钥，以便在后续的“安装密钥”或“验证数据”命令中使用。 #HAB 将 IMG 证书安装到密钥插槽 2 中 [安装密钥] #表示此证书已根据 SRK 进行检查。 验证指数 = 0 目标指数 = 2 文件 = "crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem" [验证数据] #应与安装密钥中的目标索引相同 验证指数 = 2 Blocks = 0x60001000 0x1000 0x6580 "evkmimxrt1024_iled_blinky_unsigned_original.bin" Re: Secure boot in imxrt1024..5A 你好@Abhay2080 ， 谢谢你的提问！ 根据 RT1024 IVT / 启动数据定义，您看到的差异是预期的，并且不仅限于 CSF 指针更新。 问题1：为什么 D1 00 20 41 会变成 D1 00 20 40 ？ D1 00 20 41 是 IVT 标头： 0xD1 是 IVT 标签， 0x0020 是固定长度为 32 字节的 IVT，最后一个字节是版本。RT1024 参考手册将 IVT 版本定义为 0x40/0x41 ，因此 0x40 是有效的，不是错误。请查看此在线指南： https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mcu_bootloader/docs/iMXRT1024_Manufacturing_User_Guide/topics/imx_rt_bootable_image.html Q2：为什么 00 20 00 60 会变成 DD 22 00 60 ？ 这是 IVT entry 场。小端字节序格式： 00 20 00 60 = 0x60002000 DD 22 00 60 = 0x600022DD RT1024 RM 将 entry 定义为要从映像中执行的第一条指令的绝对地址。AN12108 还指出，如果默认入口点不是 Reset_Handler ，则应将 entryPointAddress 设置为 Reset_Handler 地址。 因此，SPT 可能将 IVT 条目从 0x60002000 更新为实际的应用程序入口点。请确认映射文件/ELF符号表中的 Reset_Handler 地址。 Q3：为什么 00 00 40 00 会变成 00 A0 00 00 ？ 0x1020 处是启动数据： start 遗迹 0x60000000 length 从 0x00400000 变为 0x0000A000 RT1024 RM 将启动数据定义为包含映像起始地址和映像长度，启动 ROM 从此结构中读取映像地址和长度。 因此，SPT 更新了长度字段，以匹配最终生成的可启动/签名映像布局。 对于 RT 系列 HAB 安全启动，最终签名的映像不仅仅是“附加 CSF.bin + 更新 CSF 指针”。IVT 标头、条目、启动数据长度、CSF 指针以及 CSF 身份验证数据命令所涵盖的地址/长度必须完全一致。HAB 会重新计算闪存中软件的哈希值，并将其与从签名中恢复的参考哈希值进行比较；如果在签名后修改了已认证区域，则验证失败。[0dfe-E1] 建议使用 SPT/CST 生成的最终签名镜像，而不是手动添加 CSF.bin。 希望这个解释能有所帮助！ 此致， 加文 Re: Secure boot in imxrt1024..5A 你好@Abhay2080 ， 问得好。关键在于：CST 不会修改您的图像——它只会计算您指定的区域的哈希值并生成 CSF（签名）。它从不更改 IVT 条目、启动数据长度或版本。 这就是为什么这些字段在 SPT 下发生变化的原因：SPT 从 ELF 重建启动映像，并将 IVT.entry（到真正的 Reset_Handler）和启动数据长度规范化。这些变化源于形象重塑，而非签约环节。使用 CST 直接流程，您无需重新创建它们——如果您的原始映像已在打开/开发状态下启动，则其条目和版本已正确，可以保持不变。 但是，有一个硬性要求。您的 [Authenticate Data] 块 Blocks = 0x60001000 0x1000 0x6580 覆盖整个 IVT，并且 IVT CSF 指针位于此有符号区域内。HAB 会重新哈希该区域并将其与签名进行比较，因此如果在签名后该区域中的任何字节发生更改，则身份验证将失败。 这正是“先签名，然后附加 CSF 并更新 CSF 指针”不起作用的原因——顺序错了。 正确的 CST 签发流程（在运行 cst 之前执行此操作）： 决定 CSF 的位置（附加在应用程序之后）。在你的代码块中，App 在 0x1000 + 0x6580 = 0x7580 处结束，因此 CSF 从文件偏移量 0x7580 （内存 0x60007580 ）开始。 待签名图片已预设： IVT CSF 指针 → CSF 内存地址（例如 0x60007580 ); 启动数据长度 → 包括 CSF 在内的总镜像大小。 保持 FCFB 和条目不变（FCFB 在 HAB 范围之外；ROM 在 HAB 之前读取它）。 运行： cst -i hab.csf -o csf.bin （你的 hab.csf 与 Engine = DCP 对于 RT1024 是正确的）。 连接： cat prepared.bin csf.bin > signed_firmware.bin ，将 CSF 放置在步骤 1 中的地址，并直接刷写。 所以你的 hab.csf 本身没有问题；唯一的解决方法是在签名之前设置 CSF 指针和启动数据长度，而不是之后。 此致， 加文

P71D600 Secure Element SDK ? こんにちは、 SE P71D600を使っているので、チップにどのSDKがプリインストールされているかどうやって確認すればいいのか知りたいです。 SDKのバージョンや詳細の検証方法を教えていただけませんか? ありがとう。 JCOP ID1 JCOP ID2 スマート・カード Re: P71D600 Secure element SDK ? こんにちは、SDKバージョンと言うと、いくつかの意味があります: もしカードのコンプライアンスレベルについて話しているなら、特にJava Card 3.0.5とGlobal Platform 2.3を指しており、おそらく変わることはないと思います(ただし、いくつかの機能や修正は時間とともに変わるかもしれません)。 どのOSレベル、パッチ、モジュールやOS機能などを指しているのか、その多くはJCOP 4.5のユーザーガイダンス&管理マニュアルのNDAに記載されているGET DATA (IDENTIFY)コマンドから取得できます。 もしISDにどのパッケージやライブラリが読み込まれているかを指しているなら、GlobalPlatformのGET STATUSコマンドで読み取ることができます(NDAは不要です)。 Re: P71D600 Secure element SDK ? こんにちは、@Kan_Li さん、 @makinako さん。 ご回答ありがとうございます。 はい、その通りです。@Kan_Li JCOP 4.5です。私の間違いです。質問していたことを明確にさせてください。 私は生体認証マッチングアルゴリズムの開発に取り組んでおり、その中でカード照合（MoC）機能はサードパーティベンダーによって提供されています。NXPは異なるMoC生体認証プロバイダーをサポートする製品を提供しています。例えば、MoCの機能はID3やNeurotechnology(NT)によって提供されることがあります。 質問ですが、特定の カードにすでに登録されているMoCソリューションやバイオメトリクスプロバイダーをどうやって特定すればよいのでしょうか? 両方のプロバイダ用のSDKsを持っており、対応するアプレットやモジュールを構築できます。しかし、プリロードされた部品がどのように動作し、どの溶液がカードに含まれているかをどうやって特定すればよいのか少し混乱しています。 この情報がどのように識別できるのか、詳しく教えていただけますか? よろしくお願いします！ Re: P71D600 Secure element SDK ? こんにちは、 @elgin_1950 さん。 P71D600に基づくと、JCOP 4.5ですか?JCOP 4.5ではSDKsとは呼ばず、モジュールとアプレットがあります。構成はOEF番号を読むか、正確なタイプ名を確認することで識別できます。説明をお願いします。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

HSE: MUインストール後の最初の2回のリセット後にエラーコード0x67030001が発生しました 私はFirmware Reference Manual version 2.7の3.2.3.1節に記載されている通り、FULL_MEMモードでMUインターフェース経由でインストールする手順に従っています。 インストールは説明どおりに正常に動作しますが、機能リセット（手順7）を実行すると、HSEエラーコード0x67030001が表示されます。これは2回目のリセット後も続くが、3回目のリセット後には確実に解消される。 いくつか質問があります。 最上位ビットの値（0x6703）は意味を持つのでしょうか？ HSEドライバーが起動時にエラー状態に入り、正確に2回リセットすると回復する原因は何でしょうか? そもそも、このエラーが発生した最も可能性の高い原因は何でしょうか？ Re: HSE: Error code 0x67030001 after first two resets following MU install こんにちは、 @Emma_G-gbgさん HSE_Bファームウェア リファレンス・マニュアルに記載されているように、GSRレジスタは致命的および警告イベントを16ビットの最下位ビットでログ付けします。 ビット0～7は致命的なエラーを示します。 ビット8～15は警告（致命的ではない障害）を示します。 上位16ビットはNXPの内部エラー用に予約されています。 お使いのデバイスでビット0が設定されている場合、致命的なエラーが発生し、HSEがシャットダウンしたことを示しています。この状態では、シャットダウンモードから復旧して終了するには、デバイスのリセットが必要です。 FSRレジスタとHSE_CONFIG_GPR3(0x4039C028)の値を教えていただけますか?また、リセットを実行した後、GPR3のHSE_STATUS_INIT_OKフラグが設定されるまで待ちましたか？ さらに、 スレッドのS32K3でMU経由でHSEファームウェアをインストールする際の回復問題で、MU経由でHSEファームウェアをインストールするデモも共有されました。参考資料として役立つかもしれません。 BR、VaneB Re: HSE: Error code 0x67030001 after first two resets following MU install 最初の2回のリセット後、値は以下のとおりでした。 HSE_CONFIG_GPR3: 0x10000081 DCMRWP1: 0xA5000400 GSR: 0x67030001 FSR: 0x00400000 そして3回目のリセット後の値は次の通りでした。 HSE_CONFIG_GPR3: 0x000000C1 DCMRWP1: 0xA5000400 GSR: 0x00000000 FSR: 0x09600000   Re: HSE: Error code 0x67030001 after first two resets following MU install こんにちは、 @Emma_G-gbgさん リセット1と2：FSR = 0x00400000。ビット24（HSE_STATUS_INIT_OK）が設定されていないということは、HSEの初期化がまだ完了していないことを示しています。GSR値0x67030001は、ビット0（HSE_ERR_GENERAL）が設定されていることを示しており、これによりHSEサブシステムのシャットダウンがトリガーされました。 リセット 3: FSR = 0x09600000。ビット24（HSE_STATUS_INIT_OK）が設定され、HSEの初期化が正常に完了したことを示します。GSR値0x00000000は、HSEエラー/警告が報告されなかったことを示しています。 この挙動の原因としては、アプリケーションがHSE初期化が完全に完了する前にクロック初期化、XRDC設定、またはフラッシュ操作を行っている可能性があります。

#S32K388 增强型 RX FIFO + eDMA：无需 CPU 中断的连续循环缓冲区接收 您好，NXP技术支持， 我正在使用带有FlexCAN 增强型 RX FIFO和 RTD 的S32K388 。我希望实现基于DMA的连续CAN接收，而无需任何CPU中断。 我的要求是： MCU： S32K388 CAN：传统 CAN ，CAN FD 已禁用 CAN 有效载荷： 8 字节 FlexCAN增强型RX FIFO已启用 DMA接收已启用 我需要接收任何 CAN ID的 CAN 消息，无需过滤。 我希望 DMA 将接收到的每个 CAN 帧自动传输到RAM 软件环形缓冲区中。 我不需要 FlexCAN RX 中断。 我也不希望出现 DMA 主循环完成中断。 DMA 应该继续自动运行，而无需 CPU 再次调用 FlexCAN_Ip_RxFifo()。 理想情况下，每个接收到的 FIFO 元素都应该立即触发 DMA 传输，因此我不想等待较大的 FIFO 水印。 我查看了RTD源代码。在 FlexCAN_StartRxMessageEnhancedFifoData() 函数中，我发现驱动程序对 DMA 的配置大致如下： Source address = Enhanced RX FIFO output Source transfer size = 4 bytes Source offset = 4 bytes Destination transfer size = 4 bytes Destination offset = 4 bytes Minor loop size = 80 bytes Major loop count = num_enhanced_watermark EnMajorInt = TRUE DisAutoHwRequest = TRUE 我了解到，当前的 RTD 实现执行有限的 DMA 传输后便停止，需要再次调用 FlexCAN_Ip_RxFifo()。 我的问题是： 在 S32K388 上，是否可以配置 eDMA TCD，使 FlexCAN 增强型 RX FIFO DMA 请求能够连续地将接收到的 FIFO 元素传输到循环 RAM 缓冲区中，而无需任何 CPU 中断或软件重新激活？ 具体来说，能否使用目标模数和/或其他 eDMA TCD 功能来实现这种连续环形缓冲器？ 如果可以的话，能否提供一个配置示例，或者给我推荐一个 NXP 的示例/参考实现？ 如有必要，我愿意修改 RTD FlexCAN 驱动程序或直接配置 eDMA TCD。 谢谢您！

GMAC0 and Linflexd UART0 cannot work stably at the same time Hello everyone, I am developing software on the M7_0 core of the S32G274A using S32DS3.5 and RTD4.0.0, with FreeRTOS, Linflexd_Uart, and Lwip as components. During debugging, I found that GMAC0 and Linflexd UART0 cannot work stably at the same time. I use Linflexd_Uart to output the content of printf. The logs show that initialization completes and, after the application starts up, it can cyclically print the status of each FreeRTOS task. However, I cannot ping the board's IP address. If I comment out the printf calls or disable the UART transmission in _write, the board becomes pingable after power‑on or reset. What could be the issue here? Does printf cause GMAC0 to fail at receiving data? How should I resolve this problem? Thank you in advance for any suggestions. Re: GMAC0 and Linflexd UART0 cannot work stably at the same time any error log can be shared？ Re: GMAC0 and Linflexd UART0 cannot work stably at the same time Hello, @williams_ww  Thanks for the post. From my understandign, printf() itself should not make S32G274A GMAC0 hardware stop receiving frames . The more likely issue is that your printf -> _write -> Linflexd_Uart path is disturbing the FreeRTOS/lwIP/GMAC software timing Not sure with your detailed implementation, I suggest checking if block inside _write(), Moving UART output to a low-priority logger task, etc, to narrow the possible range BR Chenyin Re: GMAC0 and Linflexd UART0 cannot work stably at the same time 正常.jpg正常.jpg正常.jpg正常.jpg正常.jpg正常.jpg正常.jpg正常.jpg正常.jpg正常.jpg正常.jpg exception.jpgexception.jpgexception.jpgexception.jpgexception.jpgexception.jpgexception.jpgexception.jpgexception.jpgexception.jpgexception.jpg The diagram on the left shows the program running normally, while the diagram on the right shows the behavior after an exception occurs: the board cannot be pinged, and the log output gets stuck at a fixed position. Re: GMAC0 and Linflexd UART0 cannot work stably at the same time what is ip address 192.168.7.200? Is it part of your setting for GMAC? You may also check for AN14063 S32G2 Hardware Design Guidelines when the GMAC related connection is not stable. Which working mode below is fit for your design ? db16122_0-1788253582320.pngdb16122_0-1788253582320.pngdb16122_0-1788253582320.pngdb16122_0-1788253582320.pngdb16122_0-1788253582320.pngdb16122_0-1788253582320.pngdb16122_0-1788253582320.pngdb16122_0-1788253582320.pngdb16122_0-1788253582320.pngdb16122_0-1788253582320.png db16122_1-1788253600524.pngdb16122_1-1788253600524.pngdb16122_1-1788253600524.pngdb16122_1-1788253600524.pngdb16122_1-1788253600524.pngdb16122_1-1788253600524.pngdb16122_1-1788253600524.pngdb16122_1-1788253600524.pngdb16122_1-1788253600524.pngdb16122_1-1788253600524.png Re: GMAC0 and Linflexd UART0 cannot work stably at the same time “After applying the suggested changes, the problem still persists. Re: GMAC0 and Linflexd UART0 cannot work stably at the same time Following the support team's suggested solution, I modified the original printing logic to write data into a buffer, as shown below: static char buffer[64*1024+1]; volatile char buffer_to_print = 0; void my_printf(const char *format , ...) { va_list args; if(1 == buffer_to_print) { return ; } va_start(args,format); vsnprintf(buffer,sizeof(buffer),format,args); va_end(args); buffer_to_print =1; } I created a task with priority 0, which is lower than all other tasks: void my_printf_flush() { if(buffer_to_print) { Linflexd_Uart_Ip_AbortSendingData(0); Linflexd_Uart_Ip_SyncSend(0,(uint8*)buffer,strlen(buffer),3000000); buffer_to_print =0; } } void PrintfTaskDemo(void *pvParameters) { (void)pvParameters; for(;;) { my_printf_flush(); vTaskDelay(pdMS_TO_TICKS(10)); } } // here is the content of print but why only print the PRINT_HEAP_INFO ,the taskInfo not print everytime ????????????????????? for(;;) { ZRSleep(1000);// sleep 1s PRINT_HEAP_INFO; // print the remains heap size vTaskList(taskInfo); // get the freeRTOS all task state ZRLOG(ZRLOG_USER_INFO，taskInfo); // call my_printf to write buffer ZRSleep(1000); //sleep 1s } The current behavior is: the task PrintfTaskDemo can print content normally(not enable DMA), but the IP address on GMAC0 remains unreachable sometimes ,and network functionality is not working stably. The SRAM size in my linker_ram.ld is 3MB ( on S32G274A M7_0), and both the compilation settings and the FreeRTOS heap size appear to be normal. Let me know if you need further clarification or technical advice on resolving the issue. Re: GMAC0 and Linflexd UART0 cannot work stably at the same time Hello, @williams_ww  Thanks for your reply. Seems you were using the blocking method(Linflexd_Uart_Ip_SyncSend), may I know if you had tried the non-blocking API?(Linflexd_Uart_Ip_AsyncSend) BR Chenyin Re: GMAC0 and Linflexd UART0 cannot work stably at the same time The GMAC configuration is basically carried out according to the official example program. ip.jpgip.jpgip.jpgip.jpgip.jpgip.jpg code.jpgcode.jpgcode.jpgcode.jpgcode.jpgcode.jpg dev.jpgdev.jpgdev.jpgdev.jpgdev.jpgdev.jpg Re: GMAC0 and Linflexd UART0 cannot work stably at the same time Hello, @williams_ww  Thanks for your reply. I have the following suggestions: 1. Firstly to confirm what kind of settings of your UART driver, polling or interrupt mode used? 2. If it is polling mode, change it to the interrupt mode, and also, check the priority of the interrupts used both for UART/GMAC, set the UART interrupt lower than GMAC to have another trial BR Chenyin Re: GMAC0 and Linflexd UART0 cannot work stably at the same time Using interrupt mode makes it worse. Re: GMAC0 and Linflexd UART0 cannot work stably at the same time A hardware error may have occurred. I reviewed the internal implementation of the UART synchronous send interface. I commented out SuspendAllInterrupts and related code, and added lock protection before calling the synchronous send interface, but the problem still persists. Therefore, I think it is not strongly related to the UART synchronous send logic. I suspect that a hardware error caused both lwip and UART to crash. Re: GMAC0 and Linflexd UART0 cannot work stably at the same time Hello, @williams_ww  Thanks for your reply. From software perspective, the issue you met is likely caused that frequent UART TX/RX interrupts are preempting Ethernet interrupt handling, which increases RX processing latency and causes packet loss. Besides the tips we had discussed, the priority for interrupt of UART/network would also impact, so I suggest trying setting your UART interrupt, put it lower than the priority of network interrupt to have a try. BR Chenyin

Availability of Quantized (INT8) Model for Latest MediaPipe Face Mesh (478 Landmarks) I am looking to run Google's MediaPipe Face Mesh (478-point landmark model with iris tracking / Attention Mesh) efficiently on iMX Platforms. Does NXP currently provide an official quantized version (e.g., INT8) for the 478-point Face Landmarker model? If not currently available, any Plans to release in future? I have tried to quantize this original model from google using eIQ toolkit, but the accuracy is reducing drastically. When I quantize the Google's old Facemesh model (486 Landmarks) same way, i am able to get decent performance. Has NXP has the same observation? Anyone else has tried quantising Google's latest FaceMesh(478 Landmark) model? Machine Learning Re: Availability of Quantized (INT8) Model for Latest MediaPipe Face Mesh (478 Landmarks) Hello,  It is not currently available but we are testing internally to have an int8 improvement. Regards. 

HSE: Error code 0x67030001 after first two resets following MU install I have followed the install procedure for installing through MU interface in FULL_MEM mode, as described in section 3.2.3.1 in Firmware Reference Manual version 2.7. Installing works exactly as described, but when I perform a functional reset (step 7) I get HSE error code 0x67030001. This persists after a second reset but reliably goes away after a third. I have a few questions: Is the particular value of uppermost bits (0x6703) significant? What could cause the HSE driver to enter an error state on startup but recover following exactly two resets? What is the most likely cause for the error in the first place? Re: HSE: Error code 0x67030001 after first two resets following MU install Hi @Emma_G-gbg  As indicated in the HSE_B Firmware Reference Manual, the GSR register logs fatal and warning events in its 16 least significant bits: Bits 0-7 indicate fatal errors. Bits 8-15 indicate warnings (non-fatal failures). The 16 most significant bits are reserved for NXP internal errors. Since bit 0 is set on your device, this indicates that a fatal error occurred, causing the HSE to shut down. In this state, a device reset is required to recover and exit the shutdown mode. Could you please share the values of the FSR register and HSE_CONFIG_GPR3 (0x4039C028)? Also, after performing the reset, did you wait until the HSE_STATUS_INIT_OK flag in GPR3 was set? Additionally, in the thread S32K3 recovery issue when install HSE fw via MU, a demo for HSE firmware installation via MU was shared. It may serve as a useful reference. BR, VaneB Re: HSE: Error code 0x67030001 after first two resets following MU install Hi @Emma_G-gbg  Resets 1 & 2: FSR = 0x00400000. Bit 24 (HSE_STATUS_INIT_OK) is not set, which indicates that HSE had not yet completed its initialization. The GSR value 0x67030001 shows that bit 0 (HSE_ERR_GENERAL) is set, which triggered an HSE sub-system shutdown. Reset 3: FSR = 0x09600000. Bit 24 (HSE_STATUS_INIT_OK) is now set, indicating that HSE completed its initialization successfully. The GSR value0x00000000 shows that no HSE errors/warnings were reported. A possible cause of this behavior could be that the application is performing clock initialization, XRDC configuration, or Flash operations before HSE initialization is fully completed. Re: HSE: Error code 0x67030001 after first two resets following MU install After the first two resets the values were as follows: HSE_CONFIG_GPR3: 0x10000081 DCMRWP1: 0xA5000400 GSR: 0x67030001 FSR: 0x00400000 Then after the third reset values were: HSE_CONFIG_GPR3: 0x000000C1 DCMRWP1: 0xA5000400 GSR: 0x00000000 FSR: 0x09600000  

[Urgent]S32N55 GrayVIP HSE MAC service returns KEY_EMPTY (0xA5AA5317) when called from SEM task Hello. Could you please check for this issue? Environment: SW32N5_GRAYVIP_1.0.25.0 Trying to re-install SMRs at runtime (for OTA) via a custom SEM task job What I did: Added a custom SEM command that triggers SMR re-installation from Fss_Sem_PerformHSERequests (SEM task context) SMR signing uses AES-256 CMAC via HSE_SRV_ID_MAC (GenerateMAC), key installed in an AES NvmKeyGroup (MuMask = MU_0) The HSE request is sent via Fss_Sem_SendServiceRequest(FSS_SEM_CSSI_MU0, ...), same path as PublishSysImage Problem: The MAC service request is accepted (send returns OK), but the HSE response is 0xA5AA5317 (HSE_SRV_RSP_KEY_EMPTY) The same CMAC key and key slot work correctly during the initial boot-time SMR installation Only when called from the SEM task (runtime) does it return KEY_EMPTY PublishSysImage (read-only, no key) from the same SEM task works fine Question: Is runtime SMR re-installation (after initial provisioning) a supported workflow? If so, what is the recommended approach? Why would the same key slot report KEY_EMPTY only in the SEM task context, when it works at boot time? Is there a MU/partition or key-catalog access restriction after secure boot is enabled? Re: [Urgent]S32N55 GrayVIP HSE MAC service returns KEY_EMPTY (0xA5AA5317) when called from SEM task Hello, @EddiePark  Thanks for your post and glad to support again. From my understanding, the keys linked with a SMR entry will become unavailable after successful installation of the SMR entry. Which may be the reason that the same key could not be used correctly during run time. BR Chenyin

i.MX8M Plus – Is there any way to access MIPI CSI-2 Embedded Data (DT 0x12) together with RAW image Hello NXP Community, we are currently integrating a MIPI CSI-2 RAW image sensor with an i.MX8M Plus and would like to clarify whether there is any supported or technically possible way to make the sensor's CSI-2 Embedded Data (Data Type 0x12) available to software on the target. Our camera stream has the typical CSI-2 structure: Frame Start Embedded Data DT = 0x12 RAW image data DT = 0x2A / 0x2B / 0x2C Frame End The image data is captured through the MIPI CSI-2 receiver → Gasket → ISI → memory/V4L2 path and this part is working correctly. The problem is that we additionally need the Embedded Data belonging to each frame. The metadata contains frame-related sensor information, and therefore it is important that the metadata can be associated with the corresponding captured image. According to the i.MX 8M Plus Applications Processor Reference Manual, the MIPI CSI-2 receiver provides configurable data-type handling through the CSI-2 receiver registers, in particular the MIPI_CSIx_ISP_CONFIG0 / DATAFORMAT configuration. The relevant MIPI CSI-2 Rx / CSIS register descriptions are in Chapter 13.5, MIPI CSI-2, and in older revisions of the Reference Manual the supported image data types are described around Section 13.5.6.13. We also found NXP Application Note AN13857 – i.MX 8M Series MIPI Capture System, especially Section 7, "Embedded data support". AN13857 states that a stream containing Embedded Data with DT=0x12 and image data with another data type is considered data type interleaving, and that the i.MX 8M series capture system does not support this mode. The suggested workaround is to configure the sensor to transmit the embedded data using the same data type as the image data. Unfortunately, this workaround is not possible with our sensor. The sensor transmits standard CSI-2 Embedded Data using DT 0x12, while the image data uses the corresponding RAW data type. The Embedded Data data type cannot be changed to the RAW image data type. However, we found an older NXP Community discussion specifically concerning the i.MX8MP where NXP TechSupport stated that the CSI hardware should support DT=0x12, while the BSP did not support metadata at that time: https://community.nxp.com/t5/i-MX-Processors/I-MX8MP-capture-MIPI-embedded-data/td-p/1383845 There is also an older discussion about accessing CSI-2 Embedded Data on i.MX8M devices: https://community.nxp.com/t5/i-MX-Processors/Does-iMX8M-CSI-support-metadata-embedded-data/m-p/977554 Therefore, we would like to clarify whether the limitation described in AN13857 applies to the complete hardware path, or mainly to the currently supported ISI/V4L2 capture architecture. Our main question is: Is there any way on the i.MX8M Plus to receive or access the payload of CSI-2 packets with Data Type 0x12 while simultaneously capturing the RAW image stream, even if this requires modifications to the Linux driver? For example, would any of the following approaches be technically possible? Route DT=0x12 and the RAW image data through different CSI/ISI paths or channels. Access the Embedded Data before the ISI, directly from the MIPI CSI-2 receiver. Configure an additional CSI-2 receiver channel/interface for DT=0x12. Use another DMA or memory path for the Embedded Data. Extend the NXP Linux CSI/ISI driver to expose the Embedded Data as a V4L2 metadata node or separate /dev/videoX device. Use any undocumented or currently unsupported hardware functionality of the CSI-2 receiver that would allow the DT=0x12 payload to reach memory. We do not necessarily require an officially supported V4L2 metadata implementation. If the i.MX8M Plus hardware is capable of transferring the DT=0x12 payload to memory, we would also be interested in implementing the necessary kernel/driver changes ourselves. Could NXP please clarify whether the restriction described in AN13857 is: a fundamental hardware limitation of the i.MX8M Plus CSI-2 → Gasket → ISI architecture, meaning that the DT=0x12 payload cannot be transferred to memory while RAW image data is being captured, or a software/driver limitation, for which a custom driver implementation could provide access to the Embedded Data? If it is a hardware limitation, is there any alternative mechanism on the i.MX8M Plus to obtain the Embedded Data payload without changing the camera's CSI-2 output format? Thank you for any clarification or implementation hints. Best regards, Peter Re: i.MX8M Plus – Is there any way to access MIPI CSI-2 Embedded Data (DT 0x12) together with RAW im Hello, The limitation in application note is a hardware architecture limitation of the i.MX8M Plus CSI. The downstream ISI block has no mechanism to separate DT=0x12 payload from the RAW stream. Unfortunately, there is no supported or officially workaround that mentioned in application note. Best regards. Re: i.MX8M Plus – Is there any way to access MIPI CSI-2 Embedded Data (DT 0x12) together with RAW im Does the answer change when using the integrated ISP instead of the ISI? Our RAW Bayer stream can alternatively be routed from the MIPI CSI-2 receiver to the integrated ISP. Is there any mechanism in the ISP capture path to receive or preserve CSI-2 Embedded Data packets (DT=0x12)? In particular, can the ISP or its input interface separate the RAW image data and Embedded Data, or provide the Embedded Data to software through an ISP statistics/metadata buffer? If not, are the DT=0x12 packets simply discarded by the CSI-to-ISP pixel interface?