Understanding the PCIe M.2 Key E of iMX95EVK The i.MX95 EVK features an M.2 Key E slot, typically used for WiFi/BT combo cards. While plugging in a module is straightforward, understanding how the PCIe link actually comes up require diving into hardware signals, firmware initialization, and software enumeration.  In this blog, we will: - 1. Examine the M.2 Key E physical connector and identify PCIe signals on it. 2. Understand what those PCIe signals do and why are they needed? 3. What could be the possible routes while debugging PCIe in a system?   Introduction It is worth mentioning that M.2 Key E is not always used for PCIe. Rather it also supports other interfaces like USB 2.0, UART, SDIO. Our focus will specifically be on PCIe.  This blog assumes that you have a basic understanding of PCIe. What is PCIe? Why is it used? What is a link and lane? among other details. For the uninitiated, feel free to pause here and explore the web to get a basic understanding before eventually coming back to this blog. One of the links that prove to be resourceful yet crisp:- Microsoft PowerPoint - 03-05_-_Winkles_-_PCI_Express_Basics At this point, if you have physical access to the board, feel free to inspect and look at the M.2 Key E PCIe slot. M.2 keys are essential notches on connectors. It looks something like this: -   M.2 Key E slotM.2 Key E slot Figure-1 There are several M.2 key types that support PCIe, each designed for different use cases. Some of them are: - Slot type         Common-uses                                                Form Factor Key M :-          NVMe SSDs (supports x4)                             2280, 22110,2260,2242,2230 Key B  :-          SATA, cellular modems (supports x2)        2242,2260, 2280 Key E  :-          Wifi/BT modules (supports x1)                     2230, 1630, 3030 Key A :-           Wifi/BT (supports x2)                                    2230, 1630, 3030 These slots come in different form factors as you can see from the above list. The form factor refers to the width and length of the module. Each M.2 size uses a code that shows these dimensions. For example, “2280” means the module is 22 mm wide and 80 mm long. Similarly, "22110" means 22mm wide and 110mm long. On i.MX 95 evaluation kits and carrier boards, the M.2 Key E slot typically uses the 2230 form factor. For educational purpose we only refer to an illustration of M.2 connector from iMX95EVK schematic. Readers may obtain the schematic/design files from the NXP's official website.  The below image shows the M.2 Key E connector and the PCIe signals coming in and out of the iMX95EVK board's M.2 key E header.   M.2 Key E schematicM.2 Key E schematic Figure-2 From the schematic/file, the M.2 Key‑E slot is the Wi‑Fi/BT connector, and the PCIe-related nets exposed there include the PCIe differential data pair(s), reference clock, reset, clock request, and wake signals. M.2 Key E signals For PCIe bring‑up, the most important signals on this slot are: 1. PCIE1_TX0_P, PCIE1_TX0_N → slot PET_P0, PET_N0 Direction - Output from i.MX95 RC to Endpoint module PCIe transmit pair from host/root complex. With these signals, the root complex (i.MX95 side) transmits toward the Wi‑Fi module In the Image above that shows M.2 Key E connector, please observe that there's a capacitance of 0.22uF on each of the lines of a TX differential pair.   As per the PCIe specification, there are 3 main reasons to place coupling capacitors on the Tx lines: a. DC Isolation: - Since the differential signal is recovered by measuring the potential difference between the pairs, the AC caps remove any DC offset induced on the signal when a driver and receiver run at different voltages. This factors out any ground offset between a motherboard and a PCIe card. b. Detecting plug/unplug events: - Some PCIe endpoints are hot-swappable. The capacitors on a Tx pair allow the driver to use an RC time constant to detect the presence of a receiver at the end of a lane. c. Detecting Lane count: - In components that have multiple PCIe lanes, the plug/unplug events will occur across each lane, and the number of triggered lanes can be sensed by the PCIe-capable device. Note - The capacitors also need to pass as much signal as possible up to high frequencies, meaning they should have high enough self-resonant frequency. 2. PCIE1_RX0_P, PCIE1_RX0_N → slot PER_P0, PER_N0 Direction - Input to i.MX95 RC from module PCIe receive pair to host/root complex. With these signals, the root complex (i.MX95 side) receives from the Wi‑Fi module. TX0_P/N and RX0_P/N are the high-speed differential PCIe lane signals. These are the lines that carry: a. LTSSM training traffic b. configuration transactions c. memory reads/writes d. Interrupts as PCIe messages (MSI/MSIX) In a hardware bring-up, if these pairs are swapped or there's a missing AC coupling, the link will not train properly. As seen in Figure-2, The Key‑E connector exposes a second PCIe lane group (PET_P1/N1, PER_P1/N1, REFCLK_P1/N1, PERST1, CLKREQ1, PEWAKE1), but for a normal M.2 Wi‑Fi module usually x1 PCIe is used. 3. PCIE_WIFI_CLK_P, PCIE_WIFI_CLK_N / PCIE1_CLKIN_P, PCIE1_CLKIN_N → slot REFCLK_P0, REFCLK_N0 Direction - Clock output toward module PCIe needs a stable, low-jitter reference clock. The slot exposes REFCLK sourced from the board PCIe clock path. In PCIe, mainly there are 2 types of clocking :- a. Common reference clock - Both link partners share exact same 100MHz clock source   Figure-3Figure-3 b. Independent reference clock - Link partners using different 100MHz clock source Figure-4Figure-4 iMX95EVK by default uses Common reference clock, meaning that the host[iMX95EVK] and the PCIe endpoint connected to it would be sharing the 100MHz clock source. In the schematic image, PCIE_WIFI_CLK_P and PCIE_WIFI_CLK_N [100MHz] going towards the M.2 Key E slot are coming from the Si5332 clock generator on the board. In other words, it can be said that - the PCIe M.2 Key.E Wi-Fi module expects the iMX95EVK board to provide it the 100MHz reference clock. PCIe uses CDR (Clock Data Recovery), in which the clock is embedded in the data stream itself, not sent as a separate signal. So PCIe TX/RX pairs carry: - a. Data (encoded using 8b/10b or 128b/130b) b. Clock (embedded in signal transitions) Note: - CDR needs a reference frequency to lock onto. Both link partners must operate at the same base frequency, otherwise bit errors and even link failures can occur. Standard Ref clock used - 100MHz Differential clock (+-300ppm) Question - why not just send a separate clock signal instead of CDR? - That's because like in the older parallel buses, there would be clock skew issues at high speeds. More pins would be required. With CDR, fewer signals are used (just RX/TX pairs) and the clock travels with the data itself.   Figure-5Figure-5 Image above indicates that the PCIe link partners have PLL that uses REFCLK to generate the internal clocks. Each device uses their respective PLLs to generate higher-frequency clocks: Gen1: 2.5 GT/s (Giga-transfers/second) Gen2: 5.0 GT/s Gen3: 8.0 GT/s Gen4: 16.0 GT/s   what does it mean? - PLL uses REFCLK to generate internal clocks - A PLL is a frequency multiplier circuit that takes a low-frequency input (reference clock) and generates a higher-frequency output that's phase-locked (synchronized) to the input.   Figure-6Figure-6 Figure-7Figure-7 Figure-8Figure-8 Figure-9Figure-9 Question - Why use PLL internally instead of sending High-Frequency clock directly ? - Following are the reasons: - a. Routing a high frequency clock directly from host's main oscillator to PCIe slot would cause signal degradation, EMI and power loss. b. Difficult to route on the PCB. c. Using PLLs internally is much cheaper. d. At multi-GHz speeds, tiny deviation in clock timing can lead to data transmission errors. The PLL's loop filter continuously aligns the phase of the high-speed output signal with the reference clock.   Question - If CDR embeds clock in data transmission, then why is Reference clock provided as a separate signal?   Figure-10Figure-10 As can be seen from the above image, CDR doesn't work in isolation. It extracts clock from data, but it needs to know what frequency to look for. Without a reference clock, CDR sees transitions in data stream but it doesn't know if it's 2.5, 5.0, 8.0GHz or some other frequency for that matter.   Imagine trying to catch a ball: Without REFCLK (no reference): - You don't know if the ball is coming at 10 mph or 100 mph Question - What would happen if the link partners have even minimal difference in reference clock? - As per the specification, small differences are tolerable (±300 ppm), but larger differences cause link failure. ±300 ppm means: 100 MHz ± 300 ppm = 100 MHz ± 0.03 MHz = 99.97 MHz to 100.03 MHz For 2.5 GHz (after ×25 multiplication): 2.5 GHz ± 300 ppm = 2.5 GHz ± 0.75 MHz = 2,499.25 MHz to 2,500.75 MHz   During link training, devices exchange training sequences: Transmitter sends: 10101010... at 2.5000 GHz Receiver expects: 10101010... at 2.5025 GHz The receiver's CDR tries to lock but phase keeps drifting. -Bit errors accumulate -Link training timeout -Link stays in "Detect" state This ultimately results in PCIe link failures.   4. PCIE1_RST_B -> slot PERST0 (active low reset) - PCIe reset Direction - Output from host to module It is PCIe reset to the endpoint. It is like host indicating to EP - "now you may start PCIe" The endpoint card should stay in reset until: 3.3V rail is valid REFCLK is stable host side PCIe controller is ready Then the host de-asserts PERST# and the endpoint begins PCIe initialization. The firmware/software driver sequencing is wrong if:   reset may be released too early endpoint may boot before clock/power are stable endpoint may remain held in reset host may start LTSSM while endpoint is still not alive And then if you go on debugging such a board, you notice reference clock and power rails are fine at the moment of probing but somehow PCIe never enumerates. So timing of PERST# signal is of utmost importance.   Event Symptom PERST# never deasserts Card stays invisible PERST# deasserts too early Intermittent or no enumeration   5. WiFi_CLKREQ_B / PCIE1_IMX_CLKREQ_B / slot CLKREQ0 - PCIe clock request Direction - Open-drain Bi-directional In PCIe, CLKREQ# is an active-low bidirectional, open drain sideband signal which can be used by root complex and endpoint. It allows multiple devices to share a single wire. Devices can pull the CLKREQ# low to signal state changes and release it to floating state, allowing an external resistance to pull it high. Let's try to understand what open-drain bidirectional signal means:   An open-drain output can do only two things: pull the line low (drive a logic 0), or release the line and become high-impedance (Hi-Z).   It cannot actively drive the line high by itself. So if you want the line to be high when nobody is pulling it low, you must provide a pull-up resistor to a supply rail (for example 3.3 V) Hence electrically the line becomes:-   No one pulls low  --> pull-up resistor makes line HIGH Any device pulls low --> line becomes LOW   Bi-directional open-drain means:- Both connected devices: can observe/read the line state, and can also assert the line by pulling it low. So it is a shared wire where both sides participate. The circuit looks something like this:-   Figure-11Figure-11 One can observe from the above circuit diagram that the host-side PCIE1_IMX_CLKREQ_B and the module-side WiFi_CLKREQ_B are tied together through 0 Ohm links onto a single shared net. A 10K Ohms resistance to pull the line high to VDD_3V3 when nobody is driving it low. Here bi-directional means:-   the SoC side can observe the state of the shared line and can also assert it by pulling LOW, the Wi‑Fi endpoint side can also observe the same shared line and can also assert it by pulling LOW. For PCIe CLKREQ#, that means the two ends of the link (upstream port / downstream port) are connected to the same physical signal, and either side can request “clock” by pulling it low. Why is CLKREQ# used in PCIe ? It is used by link partners to request reference clock for power state coordination. What this means is - with the help of this signal, power consumption can be managed by allowing either link partners to request, start or stop the 100MHz reference clock. Root complex monitors the CLKREQ# pin to detect when an endpoint is requesting a clock to wake up the link. In some SoC designs, the host can also drive this pin to control clock gating or to indicate an exit from low-power state. Endpoint pulls CLKREQ# low to request that the host resume providing the reference clock so the device can transition from a sleep state back to active data transmission. This signal is essential for the software to enable the ASPM/low-power states. If it is not routed on the board correctly :-   link may come up initially but fail in suspend/resume L1/L1SS transitions may break the module may disappear after idle periods Wi‑Fi may fail after runtime PM kicks in Question - What happens if the CLKREQ# signal was implemented as normal push-pull instead of open-drain Bi-directional signal ? - one side could accidentally drive HIGH while the other drove LOW, creating contention and a direct short circuit between the power supply and ground. Open-drain avoids that because nobody ever actively drives HIGH. If either side wants LOW, it simply sinks the line. Otherwise both sides release the line and the pull-up makes it HIGH Question - Why active-low and why not active-high? - In a shared open-drain system, LOW is the easy state to actively assert. Open-drain hardware naturally pulls downward to ground using an NMOS / sink path, while HIGH is simply the released state created by the pull-up resistor. So active-low is the most natural form for such a signal What exactly happens on the wire in different cases ? Considering  an open-drain bi-directional CLKREQ# has pull-up resistance to 3.3V  Case-A : No link partner needs the clock RC releases the line EP releases the line pull-up resistance pulls the wire HIGH results in CLKREQ#=1 de-asserted Case-B: End-point needs the clock endpoint pulls wire LOW host may still be released result: wire goes LOW anyway both sides read CLKREQ# = 0 (asserted) Case-C Host needs the clock host pulls wire LOW endpoint may be released result: wire goes LOW both sides see request asserted Case-D Both sides need the clock both may pull LOW simultaneously no conflict, because both are only sinking the line line stays LOW safely 6. WL_PCIE1_WAKEOUT_B / slot PEWAKE0 - PCIe wake Direction - Input to host from module It is an active-low sideband signal to wake up the host from sleep or low-power state. The hosts go to deep sleep states to conserve power. During this time, the main PCIe clock and data lanes are often completely powered down or disabled. This Wake# signal in M.2 Key E provides a direct out-of-band communication line to alert the host. The M.2 card detects an event that requires the host attention and then pulls the WAKE# low. Upon detecting this transition, the host powers up the necessary rails and re-enable the PCIe clock to fully resume the system. Some use-cases :- a. Wake on Wireless LAN - allows the host to wake up if a Wifi card detects specific network traffic b. Bluetooth Device connection - allows the host to wake up when a paired Bluetooth device attempts to connect   M2_KE_PWREN and M2_KE_PD_B Direction - Output from PCAL IO Expander to load switch   M2_KE_PWREN - M.2 Key E Power Enable It is a board control signal used to enable power to the Key‑E slot / module power path. VCC_KE_3V3 is disabled by default to reduce transient power consumption so this control signal is used to turn that power on when the platform is ready. If M2_KE_PWREN is not asserted, the Wi‑Fi module may look completely dead even if PCIe routing is perfect, because the slot power rail may still be off M2_KE_PD_B - M.2 Key‑E Power-Down, active low if M2_KE_PD_B is driven LOW, the board is intentionally telling the module to stay in a disabled / power-down type condition, and if M2_KE_PD_B is HIGH, the module is allowed to operate normally. PD_B  is different from PWREN: PWREN is about supplying / enabling slot power PD_B is about telling the module whether it should remain powered-down or active The PCAL IO Expander is controlled via I2C and used as one of the board's GPIO control.   If M2_KE_PWREN is not implemented correctly, you may see: no 3.3 V at the socket no current draw from the module no PCIe enumeration   If M2_KE_PD_B is incorrect, you may see: slot rail present, but module still appears dead or partially inactive no PCIe link-up even though REFCLK and PERST# seem okay confusing behaviour where power looks present but the module is effectively held off Note:- As seen in the Image, The Key‑E connector exposes a second PCIe lane group (PET_P1/N1, PER_P1/N1, REFCLK_P1/N1, PERST1, CLKREQ1, PEWAKE1), but for a normal M.2 Wi‑Fi module usually x1 PCIe is used. Debugging lens   Assuming, you have connected the PCIe M.2 Key E Wifi card such as this one - AW693 on iMX95EVK. And booted it up with the latest linux BSP. You notice that on 'lspci', there is no respective device entry for this M.2 module. There are 2 routes of debugging from this point onwards, assuming that the pcie card is not faulty :- Hardware perspective:-   Is VCC_KE_3V3 present and stable? Are the PCIe pairs routed correctly and with the intended controlled impedance? Is REFCLK present at the module? Is PERST# timing sane? Is CLKREQ# behaving or stuck? Is the module actually powered/enabled versus held in M2_KE_PD_B/power control state?   Software perspective:- Is the PCIe RC node enabled in firmware/device tree? Is the controller coming out of reset? Is LTSSM starting? Does the kernel ever detect link up? Does configuration space read succeed? Is ASPM/clock PM breaking early bring-up? So, one of the intuitive debugging steps can be:- 1. Observe link training in the software by checking:- kernel logs PCIe controller status LTSSM state if available whether device appears in config space 2. Check if the module get 3.3V at the slot or not? Check whether PERST# is initially asserted low and later released high. Check whether the 100 MHz PCIe reference clock is present at the slot. Observe CLKREQ# behaviour before/after reset release. 6. Only after you have verified that the PCIe link is stable, move on to debug ASPM, suspend/resume or wake handling logic. There's a reason we start with checking the software first as it doesn't involve physical efforts of connecting probes to the test-points and setting up a scope for it. Debugging the software by putting logs or observing PCIe initialization in 'dmesg' is the quickest way to check what's wrong. If you do not get a clue then you should definitely consider the hardware perspective. That's all for today. This was a rather lengthy blog but rightly so. This will help to build up an understanding of how pcie cards work from a perspective of embedded software engineer so that we move on to understand  how it is brought up via firmware/software. Feel free to DM in case of any doubts/comments. Until next time!   The i.MX95 EVK features an M.2 Key E slot, typically used for WiFi/BT combo cards. While plugging in a module is straightforward, understanding how the PCIe link actually comes up require diving into hardware signals, firmware initialization, and software enumeration.  In this blog, we will: - 1. Examine the M.2 Key E physical connector and identify PCIe signals on it. 2. Understand what those PCIe signals do and why are they needed? 3. What could be the possible routes while debugging PCIe in a system? IMX95EVK

Using S32M2 motor control examples with AMMCLIB 1.1.44 - optimal performance settings This article concerns the motor control examples for S32M2 and it is recommended to apply the following procedure to all SW examples mentioned in this article, S32M2xx - Motor control use cases, provided they are used with AMMCLIB release 1.1.44 (or later, future version). This procedure concerns S32M2 motor control examples installed by the installer version 1.2 (or earlier) and will be fixed in the next S32M2 motor control example installer release. Since AMMCLIB release 1.1.44 uses a slightly different compiler settings compared to the previous version, it is necessary to adjust the settings of the motor control example SW for optimal performance as follows: Right-click on project and choose properties Navigate to C/C++ Build, choose Settings Navigate to Standard S32DS C Linker -> Miscellaneous and add the following to Linker flags field: -fno-lto Apply and close Rebuild the project with these settings Alternatively, you can use AMMCLIB release 1.1.43 (or earlier) without the above-mentioned procedure.

关于 S32K311 的 ECU 核心配置说明 你好，@danielmartynek和团队 我们有一个关于核心配置的问题。在 S32K311（单核）上，生成的代码定义了： DET_NO_ECU_CORES = 4 NUMBER_OF_CORES = 4 鉴于我们面临内存限制： 我们可以安全地将这些简化为1吗？ MCAL/DET 是否有任何副作用？ 另外，有没有办法在 NXP 配置工具或其他配置中进行设置，而无需手动编辑生成的文件？ 谢谢 & 问候， Yusup Khan S32K3 S32DS-ARM S32K31XEVB-Q100 Re: ECU Core Configuration Clarification on S32K311 你好，@yusupkhan241、 请参考 RTD 软件开发团队提供的以下回答： https://community.nxp.com/t5/S32K/RTD-memory-occupation/td-p/2148479 该参数无法通过配置工具进行配置，目前也没有计划支持此类功能。 此致， 丹尼尔

P1013 CPU/CCB/DDRのアンダークロックによる熱および通信安定性の向上 開発ボードには古いP1013NSE2MHBコンポーネントが搭載されています。 コンポーネントの熱負荷を軽減するためにクロック周波数を下げ、PCIeおよびSPI規格の通信クロックとしてP1013NSE2LFBコンポーネントのクロックを使用したいと考えています。これは私が最もよく知っているコンポーネントです。 要するに、P1013NSE2MHBにP1013NXE2LFBのPLLクロック設定を使用させたい、つまりP1013NSE2MHBのCPU/CCB/DDRの最終クロックレートを1067/533/533MHzにしたいのです。 AN4343のセクション6に基づくと、両方のコンポーネントは1067/533/533のクロック速度をサポートできるはずです。 私が唯一懸念しているのは、P1013NSE2MHBのCCB制限が480MHzとされている点です。これには、CCBクロック400MHzと480MHzのみが内蔵PLL設定を使用して最大1200MHzに到達できるという理由以外に、特に根拠が見当たりません。（AN4343のセクション6.2.1、表16を参照） CPUのコアクロックを1067MHzにしたいだけです。 P1013NSE2MHBとP1013NXE2LFBはどちらも全く同じラインに属しており、同じアーキテクチャを共有しているはずです。CPUの最大クロックが1200MHzに向上しても、以前に実装されたCCBアーキテクチャを使用してより低いCPUクロック速度を実現することは妨げられません。CCBバスを再設計しない限り、新しいCPUをサポートすることはできないだろう。再設計は莫大な資源の無駄遣いになるが、新しいCPUは根本的に異なるわけではない。 ご意見をお聞かせいただければ幸いです。 QorIQ P1デバイス Re: P1013 CPU/CCB/DDR Underclocking for Thermal and Communication Stability 以下のデータによると、アーキテクチャが異なる可能性があり、CPU/CCB/DDRは同じ傾向を示さない可能性があるようです。 CPU/CCB/DDR周波数（MHz）LF=1067/533/667 MH=1200/480/800 しかし、これは古いデバイスなので、説明についてはNXPの社内チームに確認する必要があるかもしれません。

S32K344's rx interrupt can't work Hi,     I am working on S32K344's UART. We use this chip's UART0/UART1/UART8, and every UART connect to a RS485 chip and pull out A/B pin to external circuit. I connect UART1 RS485's A to UART8' RS485's A, and UART1 RS485's B to UART8' RS485's B. I set UART1 RS485's DE/RE=1, and UART8 RS485's DE/RE=0. I try to send data from UART1 to UART8, and I observe there is waveform in LPUART1_TX and LPUART8_RX in scope. That means, data has been sent from UART1 to UART8. But there is no rx interrupt in UART8, so the uart8's rx procedure can't run. During Debug, I can see the UART8 CTRL's RE=1/RIE=1 , but STAT's RDRF=0. I switch to UART8 sending and UART1's receiving, but the phenomeno is same. Could you help to check where is the problem? I attach the project. Thanks. Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) S32K344's rx interrupt can't work Hi Julián， Thank you for your reply. Yes, other interrups, such CAN, PIT is OK. Now I comments out all code in callback(that means tx and rx interrupt won't run the rx function in callback), but the code still can't run out of the check receiver status loop and can't get RDRF flag set(see red rectangle in interrupt.png). I don't use Rx FIFO, so, when data is received, the RDRF ought to become 1. But it dosen't. I send char 'R'(ASCII=0x01010010) and 'Q'(ASCII=0x01010001) from UART1 and measure the the UART1's TXD and UART8's RXD, it seems the waveform is correct. Is there any other possible reason to cause this issue? I also attach my SDK version. Re: S32K344's rx interrupt can't work Hi @Jimmybai, I imagine other interrupts work with no issue? (PIT, CAN, etc). Are you pinning breakpoints inside the callback to confirm if interrupt is firing?  From your code, I can see you are using both Lpuart_Uart_Ip_SyncReceive & Lpuart_Uart_Ip_AsyncReceive. SyncReceive uses polling, while AsyncReceive function enables reception and immediately leaves function. The application has to get the receive status to know when the receive is complete. After receiving is completed (defined number of bytes received), you need to call AsyncReceive again to start new reception. However, inside the callback, instead of calling AsyncReceive again, use the Lpuart_Uart_Ip_SyncReceive function for blocking reception. You never re-arm UART's reception.  There are some examples in our community you can refer to:  [RTD600 IP] S32K312-EVB Lpuart interrupt echo - NXP Community Example S32K344 LPUART RX/TX ISR FreeRTOS S32DS36 RTD600 - NXP Community Best regards, Julián Re: S32K344's rx interrupt can't work I wonder why my attachment is missing. re-attach it.

ホストインターフェース（I2C）を備えたPN7642にファームウェアを書き込むことはできません。 こんにちは、 LPC55S16コンパニオンボードを使用して、I2C経由でPN7642にカスタムファームウェアを書き込もうとしています。 Host Crypto Scripts (01.03) を使用してesfwuファイルを生成しました。トランスポートキーにはC101チップ用のものを使用しました（EVKボードを改造して新しいC101チップをはんだ付けしました）。 PN7642のホストインターフェースを介してユーザーファームウェアを更新するためのステップバイステップガイド カスタム（セキュリティ保護されていない）アップデートがエラー0x01で失敗します。 NXP FW（セキュア版）、バージョン03.00をフラッシュすると、正常に動作します。 HostScriptの設定ファイルが、お客様のファイアウォールには適していないのではないかと疑っています。 私が変更したのは、aes_keyをC100トランスポートキーからC101トランスポートキーに変更しただけです。 手伝ってもらえますか？ よろしくお願いいたします。

Simultaneous Ethernet Camera Streaming Solution We are developing a custom i.MX8MP-based board for an automotive camera system. We have a working single-camera H.264 RTP streaming pipeline using the VPU hardware decoder on our 5.15.71 NXP Yocto BSP. We are now planning to scale to 4 simultaneous camera streams via an Ethernet switch.  The switch will aggregate 4x 100BASE-T1 camera ports and connect to the i.MX8MP EQOS MAC via a gigabit RGMII uplink, with each camera isolated on its own VLAN. Our display is 1280x800. For 4-stream simultaneous view each stream only needs to fill a quarter of the display (~640x400 or lower @30 fps), so we can scale camera resolution down as needed. 1. Is there an NXP i.MX8MP reference design or application note covering multi-channel video decode that we can use as a starting point? 2. Can the H.264 VPU decoder handle multiple independent instances from separate sources, or is a pre-decode composition step required to reduce the number of processes and context switches? If composition is required, what is the recommended approach on i.MX8MP? 3. What is the overall recommended software architecture for this use case from NXP's perspective? Our future application is surround view, so scalability and low latency are key requirements. Thanks!

S32k328 HSE DomainID Hello, NXP Technical Team I am writing to inquire about accurately verifying the S32k328 Domain ID. I am currently using an S32k328 board and HSE Firmware.  - Setup Environment:      I am using the HSE Firmware image s32k358_hse_fw_1.14.0_2.40.0_pb230807.bin.      I am currently in a multi-core state and using RM module(only use XRDC).  - Question:     In the HSE FW RM, the S32k328 Domain ID is set to 2 as shown in the attachment. However, in the S32k328 Block Diagram within the S32k3xx RM, the HSE is set to MDAC3, and the DID (Domain ID) of MDAC3 is output as 3.    (1) Register Verification Code:             uint32_t mda[8];             mda[0] = IP_XRDC->MDA_W0_0_DFMT0;             mda[1] = IP_XRDC->MDA_W0_1_DFMT1;             mda[2] = IP_XRDC->MDA_W0_2_DFMT1;             mda[3] = IP_XRDC->MDA_W0_3_DFMT0;             mda[4] = IP_XRDC->MDA_W0_4_DFMT0;             mda[5] = IP_XRDC->MDA_W0_5_DFMT1;             mda[6] = IP_XRDC->MDA_W0_6_DFMT0;             mda[7] = IP_XRDC->MDA_W0_7_DFMT1;             UART_Print("--- MDA Locks ---\n");             for (uint32_t i = 0; i < 8; i++)             {                 uint32_t vld = (mda[i] >> 31) & 1U;                 uint32_t lk1 = (mda[i] >> 30) & 1U;                 uint32_t did = mda[i] & 0x3U;                 UART_Print("MDA%lu=0x%lx VLD=%lu DID=%lu LK1=%lu %s\n",(unsigned long)i, (unsigned long)mda[i],(unsigned long)vld, (unsigned long)did, (unsigned long)lk1,lk1 ? "(LOCKED)" : "");             }    (2) Register Value:            MDA0=0x80000000 VLD=1 DID=0 LK1=0            MDA1=0x20000000 VLD=0 DID=0 LK1=0            MDA2=0x20000000 VLD=0 DID=0 LK1=0            MDA3=0xc0000003 VLD=1 DID=3 LK1=1 (LOCKED)            MDA4=0x80000001 VLD=1 DID=1 LK1=0            MDA5=0x20000000 VLD=0 DID=0 LK1=0 What is the correct S32k328 Domain ID? Re: S32k328 HSE DomainID Hi @dpsdprtmvl  S32K328 has four domains 0-3 and HSE is always assigned to highest available domain – to domain 3 in this case: This is hardwired and it cannot be changed. The Table 136 is little bit confusing because it shows only main derivatives, not all sub-derivatives. That means: S32K32x in the second row stands for S32K322 and S32K324. S32K35x in the third row stands for S32K358, S32K356, S32K348, S32K338, S32K328 and S32K37x and S32K39x derivatives. Regards, Lukas

S32k328 HSE 域标识符 您好，恩智浦技术团队 我写这封信是为了询问如何准确验证 S32k328 功能域 ID。 我目前正在使用 S32k328 板和 HSE 固件。  - 环境设置：      我正在使用 HSE 固件镜像 s32k358_hse_fw_1.14.0_2.40.0_pb230807.bin。      我目前处于多核状态，并正在使用 RM 模块（仅使用 XRDC）。  - 问题： 在 HSE FW RM 中，S32k328 功能域 ID 设置为 2，如附件所示。 但是，在 S32K3xx RM 中的 S32K328 方框图中，HSE 设置为 MDAC3，MDAC3 的 DID（功能域 ID）输出为 3。    (1) 注册验证码：             uint32_t mda[8];             mda[0] = IP_XRDC->MDA_W0_0_DFMT0;             mda[1] = IP_XRDC->MDA_W0_1_DFMT1;             mda[2] = IP_XRDC->MDA_W0_2_DFMT1;             mda[3] = IP_XRDC->MDA_W0_3_DFMT0;             mda[4] = IP_XRDC->MDA_W0_4_DFMT0;             mda[5] = IP_XRDC->MDA_W0_5_DFMT1;             mda[6] = IP_XRDC->MDA_W0_6_DFMT0;             mda[7] = IP_XRDC->MDA_W0_7_DFMT1;             UART_Print("--- MDA 锁 ---\n");             用于 (uint32_t i = 0; i < 8; i++)             {                 uint32_t vld = (mda[i]>> 31)& 1U;                 uint32_t lk1 = (mda[i]>> 30)& 1U;                 uint32_t did = mda[i]& 0x3U;                 UART_Print("MDA%lu=0x%lx VLD=%lu DID=%lu LK1=%lu %s\n",(无符号 long)i, (无符号 long)mda[i],(无符号 long)vld, (无符号 long)did, (无符号 long)lk1,lk1 ？ "(已锁定)" : "");             } (2) 寄存器值：            MDA0=0x80000000 VLD=1 DID=0 LK1=0 MDA1=0x20000000 VLD=0 DID=0 LK1=0 MDA2=0x20000000 VLD=0 DID=0 LK1=0 MDA3=0xc0000003 VLD=1 DID=3 LK1=1 (已锁定) MDA4=0x80000001 VLD=1 DID=1 LK1=0 MDA5=0x20000000 VLD=0 DID=0 LK1=0 正确的 s32k328 功能域 ID 是什么？ Re: S32k328 HSE DomainID 你好@dpsdprtmvl  S32K328 有四个功能域 0-3，HSE 始终分配给最高可用功能域，在本例中分配给功能域 3： 这是固有的，无法更改。 表 136 有些令人困惑，因为它只列出了主要导数，而没有列出所有次导数。这意味着： 第二行中的“S32K32x”代表 S32K322 和 S32K324。 第三行中的 S32K35x 代表 S32K358、S32K356、S32K348、S32K338、S32K328 以及 S32K37x 和 S32K39x 的衍生型号。 此致， Lukas

PN7462AU FreeRTOS：无法从 heap_3 切换到 heap_4，系统卡死 + 堆内存使用情况可见性 大家好，我正在使用搭载 FreeRTOS 的 PN7462AU 平台，SDK 示例已配置为使用 heap_3.c。我目前遇到了内存溢出问题，想更深入地了解堆的配置。 由于 heap_3 使用标准库中的 malloc()/free()，因此无法使用 xPortGetFreeHeapSize() 等函数以及堆统计信息。为了了解堆的使用情况，并可能增加可用堆空间，我尝试通过禁用 heap_3.c 来切换到 heap_4.c并启用 heap_4.c。然而，进行此项更改后，应用程序在启动时会卡住。 我有以下几个问题： 在 PN7462AU 上将 heap_3 切换为 heap_4 是否安全且值得推荐？ 如何确定 heap_3 当前可用的内存量？ 由于 heap_3 不支持 xportgetFreeHeapSize ()，因此推荐使用哪些方法来监测堆使用情况和检测内存耗尽？ 从 heap_3 迁移到 heap_4 时，还需要进行哪些额外的配置更改（例如 configTOTAL_HEAP_SIZE、链接器脚本更改、内存区域等）？ 如果能提供关于 PN7462AU 和 FreeRTOS 的具体指导或示例，将不胜感激。 谢谢 核心与内存

イーサネットカメラ同時ストリーミングソリューション 当社は、車載カメラシステム向けに、i.MX8MPをベースとしたカスタム基板を開発しています。当社では、NXP Yocto BSP 5.15.71上でVPUハードウェアデコーダーを使用した、シングルカメラH.264 RTPストリーミングパイプラインが正常に動作しています。現在、イーサネット・スイッチを介して4台のカメラの映像ストリームを同時に受信できるように拡張する計画を立てています。このスイッチは4つの100BASE-T1カメラポートを集約し、ギガビットRGMIIアップリンクを介してi.MX8MP EQOS MACに接続します。各カメラはそれぞれ独自のVLANに分離されます。 当社のディスプレイの解像度は1280×800です。4ストリーム同時表示の場合、各ストリームはディスプレイの4分の1（約640x400以下、30fps）を占めるだけでよいので、必要に応じてカメラの解像度を下げることができます。 1.NXP i.MX8MPのマルチチャネルビデオデコードに関するリファレンス・デザインやアプリケーションノートで、参考になるものはありますか？ 2. H.264 VPUデコーダは、複数の独立したインスタンスを別々のソースから処理できますか？それとも、プロセス数とコンテキストスイッチ数を減らすために、デコード前の合成ステップが必要ですか？合成が必要な場合、i.MX8MPではどのような方法が推奨されますか？ 3. NXPの視点から見て、このユースケースにおける推奨されるソフトウェアアーキテクチャはどのようなものですか？ 将来のアプリケーションはサラウンドビューなので、拡張性と低レイテンシが重要な要件となります。 ありがとう！

Cannot flash a PN7642 with Host Interface (I2C) Hello, I'm trying to flash a customized FW in a PN7642 via I2c with the LPC55S16 companion board. I've generated the esfwu file with Host Crypto Scripts (01.03), using as Transport Key the one for C101 chip (We have reworked our EVK board to solder a new C101 chip) Step by Step Guide to update user firmware through host interface for PN7642  Custom (not secure) update fails with error 0x01.  If I flash the NXP FW (secure), version 03.00, works OK. I suspect the HostScript configuration file is not OK for a customer FW. I only modified it to change the aes_key from C100 transport key to C101 transport key. Can I get some help? Regards,

PN7462AU FreeRTOS: heap_3からheap_4への切り替えに失敗し、システムが停止しました + ヒープ使用状況の可視化 チームの皆さん、こんにちは。私はFreeRTOSを搭載したPN7462AUプラットフォームを使用しており、SDKのサンプルはheap_3.cを使用するように構成されています。メモリオーバーフローの問題に直面しており、ヒープ構成についてより深く理解したいと考えています。 heap_3は標準ライブラリのmalloc()/free()を使用するため、xPortGetFreeHeapSize()やヒープ統計などの関数は利用できません。ヒープの使用状況を可視化し、利用可能なヒープを増やすために、heap_3.c を無効にして heap_3.c から heap_4.c に切り替えてみました。そしてheap_4.cを有効にする。しかし、この変更を加えた後、アプリケーションが起動中にフリーズしてしまう。 私には以下の質問があります。 PN7462AUでheap_3からheap_4に切り替えるのは安全で推奨されることでしょうか？ heap_3に現在利用可能なメモリ量をどのように確認できますか？ heap_3 は xPortGetFreeHeapSize() をサポートしていないため、ヒープの使用状況を監視し、メモリ不足を検出するための推奨される方法は何ですか？ heap_3からheap_4に移行する際に、他にどのような構成変更が必要ですか（例：configTOTAL_HEAP_SIZE、リンカースクリプトの変更、メモリ領域など）？ PN7462AUとFreeRTOSに特化したガイダンスや事例があれば、ぜひ教えていただきたいです。 ありがとう コアとメモリ

S32k328 HSEドメインID こんにちは、NXPテクニカルチームの皆様 S32k328ドメインIDの正確な検証方法についてお問い合わせいたします。 現在、S32k328ボードとHSEファームウェアを使用しています。 - 環境設定: 私はHSEファームウェアイメージs32k358_hse_fw_1.14.0_2.40.0_pb230807.binを使用しています。 現在、マルチコア環境でRMモジュールを使用しています（XRDCのみ使用）。 - 質問： HSE FW RMでは、添付ファイルに示すように、S32k328ドメインIDは2に設定されています。 しかし、S32k3xx RM 内の S32k328 ブロック図では、HSE は MDAC3 に設定されており、MDAC3 の DID (ドメイン ID) は 3 として出力されます。 （１）登録確認コード：             uint32_t mda [ 8 ];             mda [ 0 ] = IP_XRDC -> MDA_W0_0_DFMT0 ;             mda [ 1 ] = IP_XRDC -> MDA_W0_1_DFMT1 ;             mda [ 2 ] = IP_XRDC -> MDA_W0_2_DFMT1 ;             mda [ 3 ] = IP_XRDC -> MDA_W0_3_DFMT0 ;             mda [ 4 ] = IP_XRDC -> MDA_W0_4_DFMT0 ;             mda [ 5 ] = IP_XRDC -> MDA_W0_5_DFMT1 ;             mda [ 6 ] = IP_XRDC -> MDA_W0_6_DFMT0 ;             mda [ 7 ] = IP_XRDC -> MDA_W0_7_DFMT1 ;             UART_Print ( "--- MDA ロック --- \n " );             for ( uint32_t i = 0 ; i < 8 ; i ++) ヤージュ                 uint32_t vld = ( mda [ i ] >> 31 ) & 1U ;                 uint32_t lk1 = ( mda [ i ] >> 30 ) & 1U ;                 uint32_t did = mda [ i ] & 0x3U ;                 UART_Print ( "MDA %lu=0x% lx VLD= %lu DID= %lu LK1= %lu %s \n " ,( unsigned long ) i , ( unsigned long ) mda [ i ],( unsigned long ) vld , ( unsigned long ) did , ( unsigned long ) lk1 , lk1 ? "(LOCKED)" : "" ); } （２）レジスタ値： MDA0=0x80000000 VLD=1 DID=0 LK1=0 MDA1=0x20000000 VLD=0 DID=0 LK1=0 MDA2=0x20000000 VLD=0 DID=0 LK1=0 MDA3=0xc0000003 VLD=1 DID=3 LK1=1 (ロック済み) MDA4=0x80000001 VLD=1 DID=1 LK1=0 MDA5=0x20000000 VLD=0 DID=0 LK1=0 S32k328の正しいドメインIDは何ですか？ Re: S32k328 HSE DomainID こんにちは、 @dpsdprtmvl S32K328には0～3の4つのドメインがあり、HSEは常に利用可能な最高位のドメイン（この場合はドメイン3）に割り当てられます。 これは固定設定であり、変更できません。 表136は、主要な導関数のみを示しており、すべての副導関数を示していないため、少し分かりにくい。つまり、次のようになるということです。 2行目のS32K32xは、S32K322とS32K324を表します。 3行目のS32K35xは、S32K358、S32K356、S32K348、S32K338、S32K328、およびS32K37xとS32K39xの派生型を表します。 よろしくお願いいたします。 ルーカス

S32K344の受信割り込みは機能しません こんにちは、 私はS32K344のUARTについて研究しています。このチップのUART0/UART1/UART8を使用し、各UARTはRS485チップに接続され、A/Bピンを外部回路に引き出します。UART1のRS485のA端子をUART8のRS485のA端子に、UART1のRS485のB端子をUART8のRS485のB端子に接続します。UART1のRS485のDE/REを1、UART8のRS485のDE/REを0に設定します。UART1からUART8へデータを送信しようとしたところ、スコープ内でLPUART1_TXとLPUART8_RXに波形が観測されました。つまり、UART1からUART8へデータが送信されたということです。しかし、UART8には受信割り込みがないため、UART8の受信処理は実行できません。デバッグ中、UART8 CTRL の RE=1/RIE=1 は確認できますが、STAT の RDRF=0 となっています。UART8を送信、UART1を受信に切り替えてみましたが、現象は同じです。問題箇所を確認するのを手伝っていただけますか？プロジェクトファイルを添付します。ありがとう。 通信および制御（I3C | I2C | SPI | FlexCAN | イーサネット | FlexIO） S32K344's rx interrupt can't work こんにちは、ジュリアンさん、 お返事ありがとうございます。はい、CANやPITなどの他の割り込みは問題ありません。コールバック内のすべてのコードをコメントアウトしました（つまり、tx および rx 割り込みではコールバック内の rx 関数は実行されません）が、それでもコードは受信機ステータスチェックループから抜け出せず、RDRF フラグを設定することができません（interrupt.png の赤い四角を参照）。私はRx FIFOを使用していないので、データを受信するとRDRFは1になるはずです。しかし、そうではない。UART1から文字「R」(ASCII=0x01010010)と「Q」(ASCII=0x01010001)を送信し、UART1のTXDとUART8のRXDを測定したところ、波形は正しいようです。この問題を引き起こす可能性のある他の原因はありますか？ SDKのバージョンも添付します。 Re: S32K344's rx interrupt can't work こんにちは、 @Jimmybai さん。 他の割り込みも問題なく動作すると思いますか？（PIT、CANなど）割り込みが発生しているかどうかを確認するために、コールバック関数内にブレークポイントを設定していますか？ コードを見ると、 Lpuart_Uart_Ip_SyncReceive とLpuart_Uart_Ip_AsyncReceive の両方を使用していることがわかります。SyncReceive はポーリングを使用しますが、 AsyncReceive 関数は受信を開始したらすぐに処理を終了します。アプリケーションは受信完了のタイミングを知るために、受信ステータスを取得する必要があります。受信が完了したら（指定されたバイト数を受信したら）、 AsyncReceive を再度呼び出して新しい受信を開始する必要があります。 ただし、コールバック内では、AsyncReceive を再度呼び出す代わりに、Lpuart_Uart_Ip_SyncReceive 関数を使用して受信をブロックします。UARTの受信機能を再度有効にしてはいけません。 私たちのコミュニティには、参考になる事例がいくつかあります。 [RTD600 IP] S32K312-EVB Lpuart割り込みエコー - NXPコミュニティ S32K344 LPUART RX/TX ISR FreeRTOS S32DS36 RTD600 の例 - NXPコミュニティ よろしくお願いします、 ジュリアン Re: S32K344's rx interrupt can't work 添付ファイルが見つからないのはなぜだろう。再び取り付けてください。

以太网摄像头同步流媒体传输解决方案 我们正在为汽车摄像头系统开发基于i.MX8MP的定制主板。我们在5.15.71恩智浦Yocto BSP上使用VPU硬件解码器，有一条有效的单摄像机H.264 RTP直播流水线。我们目前计划通过以太网交换机将系统扩展至支持4路同时传输的摄像头流。 该交换机将聚合4个100BASE-T1摄像头端口，并通过千兆RGMII上行链路连接至i.MX8MP EQOS MAC，每个摄像头均隔离在各自的VLAN中。 我们的显示屏分辨率为1280x800。要实现4路视频同时显示，每路视频只需占据屏幕的四分之一（约640×400或更低分辨率，30帧/秒），因此我们可以根据需要降低摄像头的分辨率。 1.是否有涵盖多通道视频解码的恩智浦i.MX8MP参考设计或应用说明可以作为起点？ 2。H.264 VPU 解码器能否处理来自不同来源的多个独立实例，还是需要预解码组合步骤来减少进程和上下文切换的数量？如果需要进行图像合成，在 i.MX8MP 上推荐采用什么方法？ 3. 从恩智浦的角度来看，针对此用例，总体推荐的软件架构是什么？ 我们未来的应用是全景视图，因此可扩展性和低延迟是关键要求。 谢谢！

S32K344 的接收中断无法工作 您好，     我目前正在研究 S32K344 的 UART。我们使用该芯片的UART0/UART1/UART8，每个UART都连接到一个RS485芯片，并将A/B引脚引出至外部电路。我将UART1的RS485接口的A引脚连接到UART8的RS485接口的A引脚，并将UART1的RS485接口的B引脚连接到UART8的RS485接口的B引脚。 我将UART1 RS485的DE/RE设置为1，将UART8 RS485的DE/RE设置为0。我尝试将数据从 UART1 发送至 UART8，并在示波器上观察到 LPUART1_TX 和 LPUART8_RX 信号线上有波形。这意味着，数据已从UART1发送至UART8。但 UART8 中没有 rx 中断，因此 uart8 的 rx 处理程序无法运行。在调试过程中，我可以看到 UART8 CTRL 的 RE=1/RIE=1，但 STAT 的 RDRF=0。我将发送端口切换为UART8，接收端口切换为UART1，但现象依然如故。您能帮忙查一下问题出在哪里吗？我将该项目附上。谢谢。 通信& 控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） S32K344's rx interrupt can't work 嗨，胡利安， 谢谢您的答复。是的，其他中断，例如 CAN、PIT 都没有问题。现在我已将回调函数中的所有代码注释掉（这意味着发送和接收中断都不会在回调中执行接收函数），但代码仍然无法脱离检查接收器状态的循环，也无法使 RDRF 标志被设置（参见 interrupt.png 中的红色矩形）。我没有使用 Rx FIFO，因此，当接收到数据时，RDRF 应该变为 1。但事实并非如此。我通过UART1发送字符'R'（ASCII=0x01010010）和'Q'（ASCII=0x01010001），并测量了UART1的TXD和UART8的RXD，波形看起来是正确的。还有其他可能导致此问题的原因吗？ 我同时附上了我的 SDK 版本。 Re: S32K344's rx interrupt can't work 嗨，@Jimmybai， 我想其他中断应该都能正常工作吧？（PIT、CAN 等）。你是否在回调函数中设置了断点，以确认中断是否触发？  从你的代码中我可以看出你同时使用了 LPUART_UART_IP_SyncreCeive & LPUART_UART_IP_Asyncreceiv e lpuart_UART_IP_ Asyncreceive。SyncreCeive 使用轮询，而 AsyncreCeive 功能则支持接收并立即退出功能。应用程序必须获得接收状态才能知道何时完成接收。接收完成后（已定义的接收字节数）， 您需要再次调用 AsyncreCeive 以开始 新的接收。 不过，在回调函数内部，不要再次调用 AsyncReceive，而应使用 Lpuart_Uart_Ip_SyncReceive 函数进行阻塞式接收。你永远不会重新布防 UART 的接收。 我们社区里有一些例子，你可以参考一下：  [RTD600 IP] S32K312-EVB Lpuart 中断回显 - NXP 社区 示例 S32K344 LPUART 接收/发送中断处理程序 FreeRTOS S32DS36 RTD600 - NXP 社区 致以最诚挚的问候， Julián Re: S32K344's rx interrupt can't work 我不知道为什么我的附件不见了。将其重新安装。

P1013 为确保散热和通信稳定性而对 CPU/CCB/DDR 进行降频 我的开发板上有旧的 P1013NSE2MHB 元器件。 我想降低它们的时钟以降低元器件的热负荷，并使用 P1013NSE2LFB 元器件的 PCIe 和 SPI 标准的通信时钟，这是我最熟悉的。 简而言之，我希望让 P1013NSE2MHB 采用 P1013NXE2LFB 的 PLL 时钟配置，即 P1013NSE2MHB 的 CPU/CCB/DDR 最终时钟频率应为 1067/533/533 MHz。  根据 AN4343 第 6 节，两个元器件都应该能够支持 1067/533/533 的时钟速度。 我唯一担心的是，P1013NSE2MHB的CCB限制据说为480MHz。除了只有 CCB 时钟 400 和 480 MHz 才能使用内置的 PLL 设置来达到最大值 1200MHz 之外，我找不到任何理由。（参见AN4343第6.2.1节表16） 我只想让CPU的核心频率达到1067MHz。  P1013NSE2MHB 和 P1013NXE2LFB 均来自同一产品线，应采用相同的架构；因此，即使 CPU 最大时钟频率提升至 1200MHz，也不应妨碍使用先前已实现的 CCB 架构来实现较低的 CPU 时钟频率。除非重新设计CCB总线以支持新的CPU，尽管没有根本的不同，但这将是资源的巨大浪费。 感谢大家提供的见解。 QorIQ P1 设备 Re: P1013 CPU/CCB/DDR Underclocking for Thermal and Communication Stability 根据以下数据，架构似乎有所不同，CPU/CCB/DDR可能不会有相同的趋势 CPU/CCB/D DR 频率 (MHz) LF=1067/533/667 MH=1200/480/800 但这是旧设备，因此可能需要向恩智浦内部团队查询解释

ECU Core Configuration Clarification on S32K311 Hi @danielmartynek and Team We have one question regarding core configuration. On S32K311 (single-core), the generated code defines: DET_NO_ECU_CORES = 4 NUMBER_OF_CORES = 4 Since we are facing RAM constraints: Can we safely reduce these to 1? Any side effects in MCAL/DET? Also, is there a way to configure this in the NXP config tool or any configuration instead of manually editing generated files? Thanks & Regards, Yusup Khan S32K3  S32DS-ARM S32K31XEVB-Q100 Re: ECU Core Configuration Clarification on S32K311 Hi @yusupkhan241, Refer to this answer provided by the RTD SW development team: https://community.nxp.com/t5/S32K/RTD-memory-occupation/td-p/2148479 This parameter cannot be configured via the configuration tool, and there are currently no plans to support such functionality. Regards, Daniel

GD3160 SPI 配置 根据数据手册，如果我要配置 GD3160，需要先将 MODE_2 中的 CONFIG_EN 位设置为 1。既然如此，MODE_2 的第一位（Rb/W）应该是 0 还是 1？ Re: GD3160 SPI 配置 了解后请看下面： 正确的解释确实是： 0 = 读取 1 = 写入   Re: GD3160 SPI 配置 是的，另外除了下图中说的 CONFIG1 to 7 registers, the MODE1 and 2 registers, the RMSK1 and RMSK2 registers, and the MSK1 and 2 registers ，这些寄存器的写受MODE_2的CONFIG_EN控制，其余寄存器只要bit23为1的情况就会进行配置吗？ Re: GD3160 SPI 配置 你说的是bit23吗？