[MCX A153] LPSPI入門ガイド（日本語ブログ） 本記事では、MCX A153 に搭載されている LPSPI（Low Power Serial Peripheral Interface）の基本概念と、MCUXpresso SDK を用いた実装方法を、初めてNXP製品を扱うエンジニア向けに解説します。まずハードウェアの概要を説明し、その後FRDM-MCXA153ボードをベースに、MCUXpresso SDKの使い方をコードスニペットとともに説明します。 (読了：20分) 1. LPSPIモジュール概要   1.1 LPSPIとは   LPSPI は、外部デバイスとの同期シリアル通信を行うための周辺モジュールです。 ここでの "LP（Low Power）" とは「低消費電力で動作できる設計」 を意味します。   通常のSPIとの違い（Low Powerの視点） 一般的なSPIモジュールと比較したときの LPSPI の特徴は以下です。 低消費電力モード（Stop / Sleep）でも動作継続可能 DMA（eDMA）と連携し、CPU介在を減らすことでシステム全体の電力削減 ハードウェアトリガ（HREQなど）でCPUを起こさず通信開始が可能 LPSPI は「単にSPI通信ができる」だけではなく、 「システム全体を低消費電力で運用するための通信モジュール」として設計されています。   1.2 MCX A153における構成 MCX A153 には複数の LPSPI インスタンスがあり、例えば、以下のような信号が使用されます： CS (P1_3) SCK (P1_1) SDI (P1_2) SDO (P1_0) 2. LPSPIの基本動作   2.1 信号の役割 SPI通信では、基本的に以下の4線を使用して、通信します。 SPI通信には極性と位相によって、4つのモードがありますが、例えばモード0の場合、それぞれの信号は、以下のタイミングチャートに従います。   2.2 FIFOの役割 LPSPI は内部に FIFO を持っており、送信データ・受信データを一時的に保持できます。 これにより、CPU が 1 バイトずつ即時にレジスタ操作しなくても、ある程度まとめてデータを処理できます。さらに eDMA を組み合わせることで、FIFO へのデータ供給／取り出しを CPU の代わりに自動化できます。 3. DMA（eDMA）転送の基本概念   3.1 なぜ DMA を使うのか SPI で数バイトだけ送る用途なら単純なポーリングでも動作しますが、実際の組み込み開発では以下の要求が多くあります。 センサデータや表示データなどを連続転送したい CPU を通信待ちで止めたくない 他の制御処理や RTOS タスクと並行動作したい 通信処理の負荷を下げたい   ここで重要になる考え方が「ノンブロッキング（Non-blocking）」です。 ノンブロッキングとは、「処理の完了を待たずにすぐに関数が戻る動作」のことです。 例えば SPI 通信の場合、通常は以下のような2つの動作モデルがあります。 ブロッキング（Blocking） 送信関数を呼ぶと、通信が終わるまでCPUが待ち続ける 通信中は他の処理ができない ノンブロッキング（Non-blocking） 送信開始だけ行い、すぐに関数が戻る 実際の通信はバックグラウンド（DMAなど）で進む CPUはその間に他の処理を実行できる LPSPI + eDMA を使うと、データ転送の大部分をハードウェア側に任せることができるため、ノンブロッキング通信を実現する事が可能となります。   3.2 DMA転送の考え方 DMA 転送では、CPU は最初に「どこから送るか」「どこへ受けるか」「何バイト送るか」を設定し、転送開始を指示します。 その後は、LPSPI の FIFO 要求に応じて eDMA が自動的にデータ転送を進めます。CPU は待機せず、他の処理を続けることができます。   3.3 動作イメージ DMA転送時の流れは概ね以下の通りです。 CPU が LPSPI と eDMA を初期化 送信バッファ / 受信バッファ / サイズを設定 CPU が DMA転送開始を指示 eDMA が FIFO 要求に応じてデータを搬送 転送完了時にコールバックで通知  4. SDKドライバの基本フロー LPSPIを使用するためには、ソフトウェアによって以下の設定が必要となります。 クロック・ピンを設定 LPSPIモジュール初期化 eDMAハンドル定義 LPSPIハンドル生成 転送バッファ設定 転送実行 コールバックで完了確認 MCUXpresso SDKのサンプルプロジェクトを例に、ドライバの使用方法を紹介します。  以下のプロジェクトを参考に、説明します。 参考URL: Hardware requirements — MCUXpresso SDK Documentation mcuxsdk-examples/driver_examples/lpspi/edma_transfer/lpspi_edma_transfer.cc at main · nxp-mcuxpresso/mcuxsdk-examples   4.1 クロック設定・ピン設定 まず、クロック、PORTをLPSPI0に初期化します。 クロック有効化を忘れると物理的に動きません。PORTの割り当て設定（MuxAlt）がLPSPI0に一致している事が重要です。 /* クロック有効化 */ void BOARD_InitHardware(void) { /* Attach peripheral clock */ CLOCK_SetClockDiv(kCLOCK_DivLPSPI0, 1u); CLOCK_AttachClk(kFRO12M_to_LPSPI0); } /* PORT設定 */ /* PORT1: Peripheral clock is enabled */ CLOCK_EnableClock(kCLOCK_GatePORT1); /* PORT3: Peripheral clock is enabled */ CLOCK_EnableClock(kCLOCK_GatePORT3); /* LPSPI0 peripheral is released from reset */ RESET_ReleasePeripheralReset(kLPSPI0_RST_SHIFT_RSTn); /* PORT1 peripheral is released from reset */ RESET_ReleasePeripheralReset(kPORT1_RST_SHIFT_RSTn); /* LPSPI1 peripheral is released from reset */ RESET_ReleasePeripheralReset(kLPSPI1_RST_SHIFT_RSTn); /* PORT3 peripheral is released from reset */ RESET_ReleasePeripheralReset(kPORT3_RST_SHIFT_RSTn); const port_pin_config_t port1_0_pin135_config = {/* Internal pull-up/down resistor is disabled */ .pullSelect = kPORT_PullDisable, /* Low internal pull resistor value is selected. */ .pullValueSelect = kPORT_LowPullResistor, /* Fast slew rate is configured */ .slewRate = kPORT_FastSlewRate, /* Passive input filter is disabled */ .passiveFilterEnable = kPORT_PassiveFilterDisable, /* Open drain output is disabled */ .openDrainEnable = kPORT_OpenDrainDisable, /* Low drive strength is configured */ .driveStrength = kPORT_LowDriveStrength, /* Normal drive strength is configured */ .driveStrength1 = kPORT_NormalDriveStrength, /* Pin is configured as LPSPI0_SDO */ .mux = kPORT_MuxAlt2, /* Digital input enabled */ .inputBuffer = kPORT_InputBufferEnable, /* Digital input is not inverted */ .invertInput = kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ .lockRegister = kPORT_UnlockRegister}; /* PORT1_0 (pin 135) is configured as LPSPI0_SDO */ PORT_SetPinConfig(PORT1, 0U, &port1_0_pin135_config); const port_pin_config_t port1_1_pin136_config = {/* Internal pull-up/down resistor is disabled */ .pullSelect = kPORT_PullDisable, /* Low internal pull resistor value is selected. */ .pullValueSelect = kPORT_LowPullResistor, /* Fast slew rate is configured */ .slewRate = kPORT_FastSlewRate, /* Passive input filter is disabled */ .passiveFilterEnable = kPORT_PassiveFilterDisable, /* Open drain output is disabled */ .openDrainEnable = kPORT_OpenDrainDisable, /* Low drive strength is configured */ .driveStrength = kPORT_LowDriveStrength, /* Normal drive strength is configured */ .driveStrength1 = kPORT_NormalDriveStrength, /* Pin is configured as LPSPI0_SCK */ .mux = kPORT_MuxAlt2, /* Digital input enabled */ .inputBuffer = kPORT_InputBufferEnable, /* Digital input is not inverted */ .invertInput = kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ .lockRegister = kPORT_UnlockRegister}; /* PORT1_1 (pin 136) is configured as LPSPI0_SCK */ PORT_SetPinConfig(PORT1, 1U, &port1_1_pin136_config); const port_pin_config_t port1_2_pin137_config = {/* Internal pull-up/down resistor is disabled */ .pullSelect = kPORT_PullDisable, /* Low internal pull resistor value is selected. */ .pullValueSelect = kPORT_LowPullResistor, /* Fast slew rate is configured */ .slewRate = kPORT_FastSlewRate, /* Passive input filter is disabled */ .passiveFilterEnable = kPORT_PassiveFilterDisable, /* Open drain output is disabled */ .openDrainEnable = kPORT_OpenDrainDisable, /* Low drive strength is configured */ .driveStrength = kPORT_LowDriveStrength, /* Normal drive strength is configured */ .driveStrength1 = kPORT_NormalDriveStrength, /* Pin is configured as LPSPI0_SDI */ .mux = kPORT_MuxAlt2, /* Digital input enabled */ .inputBuffer = kPORT_InputBufferEnable, /* Digital input is not inverted */ .invertInput = kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ .lockRegister = kPORT_UnlockRegister}; /* PORT1_2 (pin 137) is configured as LPSPI0_SDI */ PORT_SetPinConfig(PORT1, 2U, &port1_2_pin137_config); const port_pin_config_t port1_3_pin138_config = {/* Internal pull-up/down resistor is disabled */ .pullSelect = kPORT_PullDisable, /* Low internal pull resistor value is selected. */ .pullValueSelect = kPORT_LowPullResistor, /* Fast slew rate is configured */ .slewRate = kPORT_FastSlewRate, /* Passive input filter is disabled */ .passiveFilterEnable = kPORT_PassiveFilterDisable, /* Open drain output is disabled */ .openDrainEnable = kPORT_OpenDrainDisable, /* Low drive strength is configured */ .driveStrength = kPORT_LowDriveStrength, /* Normal drive strength is configured */ .driveStrength1 = kPORT_NormalDriveStrength, /* Pin is configured as LPSPI0_PCS0 */ .mux = kPORT_MuxAlt2, /* Digital input enabled */ .inputBuffer = kPORT_InputBufferEnable, /* Digital input is not inverted */ .invertInput = kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ .lockRegister = kPORT_UnlockRegister}; /* PORT1_3 (pin 138) is configured as LPSPI0_PCS0 */ PORT_SetPinConfig(PORT1, 3U, &port1_3_pin138_config); const port_pin_config_t port3_10_pin96_config = {/* Internal pull-up/down resistor is disabled */ .pullSelect = kPORT_PullDisable, /* Low internal pull resistor value is selected. */ .pullValueSelect = kPORT_LowPullResistor, /* Fast slew rate is configured */ .slewRate = kPORT_FastSlewRate, /* Passive input filter is disabled */ .passiveFilterEnable = kPORT_PassiveFilterDisable, /* Open drain output is disabled */ .openDrainEnable = kPORT_OpenDrainDisable, /* Low drive strength is configured */ .driveStrength = kPORT_LowDriveStrength, /* Normal drive strength is configured */ .driveStrength1 = kPORT_NormalDriveStrength, /* Pin is configured as LPSPI1_SCK */ .mux = kPORT_MuxAlt2, /* Digital input enabled */ .inputBuffer = kPORT_InputBufferEnable, /* Digital input is not inverted */ .invertInput = kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ .lockRegister = kPORT_UnlockRegister}; /* PORT3_10 (pin 96) is configured as LPSPI1_SCK */ PORT_SetPinConfig(PORT3, 10U, &port3_10_pin96_config); const port_pin_config_t port3_11_pin95_config = {/* Internal pull-up/down resistor is disabled */ .pullSelect = kPORT_PullDisable, /* Low internal pull resistor value is selected. */ .pullValueSelect = kPORT_LowPullResistor, /* Fast slew rate is configured */ .slewRate = kPORT_FastSlewRate, /* Passive input filter is disabled */ .passiveFilterEnable = kPORT_PassiveFilterDisable, /* Open drain output is disabled */ .openDrainEnable = kPORT_OpenDrainDisable, /* Low drive strength is configured */ .driveStrength = kPORT_LowDriveStrength, /* Normal drive strength is configured */ .driveStrength1 = kPORT_NormalDriveStrength, /* Pin is configured as LPSPI1_PCS0 */ .mux = kPORT_MuxAlt2, /* Digital input enabled */ .inputBuffer = kPORT_InputBufferEnable, /* Digital input is not inverted */ .invertInput = kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ .lockRegister = kPORT_UnlockRegister}; /* PORT3_11 (pin 95) is configured as LPSPI1_PCS0 */ PORT_SetPinConfig(PORT3, 11U, &port3_11_pin95_config); const port_pin_config_t port3_8_pin98_config = {/* Internal pull-up/down resistor is disabled */ .pullSelect = kPORT_PullDisable, /* Low internal pull resistor value is selected. */ .pullValueSelect = kPORT_LowPullResistor, /* Fast slew rate is configured */ .slewRate = kPORT_FastSlewRate, /* Passive input filter is disabled */ .passiveFilterEnable = kPORT_PassiveFilterDisable, /* Open drain output is disabled */ .openDrainEnable = kPORT_OpenDrainDisable, /* Low drive strength is configured */ .driveStrength = kPORT_LowDriveStrength, /* Normal drive strength is configured */ .driveStrength1 = kPORT_NormalDriveStrength, /* Pin is configured as LPSPI1_SDO */ .mux = kPORT_MuxAlt2, /* Digital input enabled */ .inputBuffer = kPORT_InputBufferEnable, /* Digital input is not inverted */ .invertInput = kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ .lockRegister = kPORT_UnlockRegister}; /* PORT3_8 (pin 98) is configured as LPSPI1_SDO */ PORT_SetPinConfig(PORT3, 8U, &port3_8_pin98_config); const port_pin_config_t port3_9_pin97_config = {/* Internal pull-up/down resistor is disabled */ .pullSelect = kPORT_PullDisable, /* Low internal pull resistor value is selected. */ .pullValueSelect = kPORT_LowPullResistor, /* Fast slew rate is configured */ .slewRate = kPORT_FastSlewRate, /* Passive input filter is disabled */ .passiveFilterEnable = kPORT_PassiveFilterDisable, /* Open drain output is disabled */ .openDrainEnable = kPORT_OpenDrainDisable, /* Low drive strength is configured */ .driveStrength = kPORT_LowDriveStrength, /* Normal drive strength is configured */ .driveStrength1 = kPORT_NormalDriveStrength, /* Pin is configured as LPSPI1_SDI */ .mux = kPORT_MuxAlt2, /* Digital input enabled */ .inputBuffer = kPORT_InputBufferEnable, /* Digital input is not inverted */ .invertInput = kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ .lockRegister = kPORT_UnlockRegister}; /* PORT3_9 (pin 97) is configured as LPSPI1_SDI */ PORT_SetPinConfig(PORT3, 9U, &port3_9_pin97_config); }   4.2 LPSPI 初期化 LPSPIモジュールの初期化を行います。LPSPI_MasterGetDefaultConfig() で初期値を取得して、用途に応じて変更してください。 lpspi_master_config_t masterConfig; LPSPI_MasterGetDefaultConfig(&masterConfig); masterConfig.baudRate = 500000U; LPSPI_MasterInit(LPSPI0, &masterConfig, CLOCK_GetFreq(kCLOCK_CoreSysClk));   4.3 ハンドル定義 ハンドルは、MCUXpresso SDKのドライバではよく使われる単語であり、あるリソースを間接的に参照・操作するための識別子のことです。eDMAを使用する場合もチャンネルごとにハンドルを作り、それをLPSPIのドライバに渡す必要があります。関数ポインタを渡すことで、コールバック（SPI転送終了時に呼び出される関数）を設定することも出来ます。 edma_handle_t txHandle; edma_handle_t rxHandle; lpspi_master_edma_handle_t lpspiEdmaHandle; EDMA_CreateHandle(&txHandle, DMA0, 0); EDMA_CreateHandle(&rxHandle, DMA0, 1); LPSPI_MasterTransferCreateHandleEDMA( LPSPI0, &lpspiEdmaHandle, lpspi_master_callback, NULL, &txHandle, &rxHandle );   4.4 転送バッファと転送設定 具体的な転送内容（バッファのアドレス、転送サイズ）を指定します。 /*Start master transfer*/ masterXfer.txData = masterTxData; masterXfer.rxData = NULL; masterXfer.dataSize = TRANSFER_SIZE; isTransferCompleted = false;   4.5 SPI転送開始 SPI転送を開始します。この API はノンブロッキングで動作します。関数呼び出し後、CPU はすぐに復帰し、他の処理を継続できます。 LPSPI_MasterTransferEDMALite(EXAMPLE_LPSPI_MASTER_BASEADDR, &g_m_edma_handle,&masterXfer);   4.6 コールバックの考え方 DMA 転送では、処理完了を待つ代わりにコールバックで完了を受け取る設計にします。これにより、メインループ側やタスク側で完了確認が可能です。RTOS 環境ならセマフォやイベント通知に置き換え可能です。 volatile bool g_transferComplete = false; void lpspi_master_callback(LPSPI_Type *base, lpspi_master_edma_handle_t *handle, status_t status, void *userData) { if (status == kStatus_Success) { g_transferComplete = true; } }   5. よくあるつまずき 以下に各項目ごとに、つまずきがちなポイントをまとめました。 (1) データが返らない MOSI / MISO の配線ミス ピン割り当て設定ミス 相手デバイスとのタイミングミスマッチ（スレーブが先に待機しないと、正常に送受信できません） (2) クロックが出ない LPSPI モジュールクロック未有効 PCS が期待どおり制御されていない (3) DMA転送が完了しない DMA チャネル設定ミス コールバック登録漏れ 転送サイズ不一致 (4) CS が制御できない PCS 設定フラグ（configFlags）不備 相手デバイス側の極性設定と不一致 (5) 受信データが崩れる クロック設定が速すぎる FIFO / DMA / バッファサイズの整合が取れていない 配線品質や信号波形に問題がある   6. まとめ   LPSPI は、MCX A153 における SPI 通信を実現するための主要なシリアル通信モジュールであり、低消費電力動作や DMA 連携を考慮して設計されています。実際に使用する際には、LPSPI の設定だけでなく、ピン設定、やクロック設定を正しく行うことが重要です。 また、MCUXpresso SDKを利用することで、eDMA を用いたノンブロッキング通信を容易に実装できます。これにより、CPU は通信処理に拘束されることなく他の処理を実行でき、システム全体の効率向上につながります。 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） 本記事では、MCX A153 に搭載されている LPSPI（Low Power Serial Peripheral Interface）の基本概念と、MCUXpresso SDK を用いた実装方法を、初めてNXP製品を扱うエンジニア向けに解説します。まずハードウェアの概要を説明し、その後FRDM-MCXA153ボードをベースに、MCUXpresso SDKの使い方をコードスニペットとともに説明します。 (読了：20分) MCX 日本語ブログ

[MCX A153] LPUART Introduction Guide (Japanese Blog) This article explains the basic concepts of LPUART ( Low Power Universal Asynchronous Receiver / Transmitter ) on the MCX A153 and how to use it with the MCUXpresso SDK, aimed at engineers who are new to NXP products. First, we will explain the hardware overview, and then, using the FRDM-MCXA153 board as a base, we will explain how to use the MCUXpresso SDK API with code snippets. (Reading time: 20 minutes) 1. LPUART Module Overview LPUART is a module for implementing asynchronous serial communication. Here, we will look at its key features in order.   Asynchronous communication (start bit/stop bit) LPUART does not use a clock line; instead, it determines timing using start and stop bits included in the data. Because it only requires two wires, TX and RX, it is widely used for easily connecting different devices, such as communicating with a PC, connecting to sensors, and outputting debug logs. Interrupt/DMA compatible LPUART features a mechanism where hardware automatically assists with data transfer, rather than the CPU processing data byte by byte. Using interrupts, the CPU only processes data when an event occurs, and using DMA, data can be transferred to and from memory without CPU intervention. Because it's designed with DMA integration in mind, CPU load can be minimized even during high-speed communication. Built-in FIFO (buffer) LPUART has an internal buffer for sending and receiving data, also known as a FIFO. Because it can temporarily store data, it can absorb the difference between the communication speed and the processing speed of the CPU or DMA. When combined with DMA, it makes it easier to achieve uninterrupted, continuous communication. Low power operation Designed to operate with lower power consumption than a standard UART, it can sometimes continue operating even while in sleep mode. Because it works closely with clock control, it is particularly useful for battery-powered devices and IoT applications. Supports multiple instances The MCU has multiple LPUARTs, allowing for simultaneous communication of multiple devices. This enables you to separate roles for each instance, such as separating debugging and sensor communication. 2. Software Configuration (MCUXpresso SDK) The MCUXpresso SDK provides three types of drivers for handling LPUART: polling, interrupt, and eDMA. In practical applications, interrupt-based communication is sufficient for small-scale communications, but eDMA is used for high-speed, continuous communications. For applications where you don't want to burden the CPU, designing with eDMA in mind from the start will minimize future changes. Therefore, this article will proceed on the assumption that DMA is being used. 3. The role of FIFO and DMA To use DMA correctly, it's essential to first understand how FIFOs work. LPUART has an internal FIFO (First-In First-Out buffer) that plays the role of temporarily holding transmitted data, temporarily storing received data, and absorbing the speed difference that occurs between LPUART and DMA. In DMA integration, on the receiving side, data received by the LPUART is stored in the RX FIFO, and when a threshold is reached, the DMA transfers the data from the RX FIFO to memory. On the transmitting side, the DMA writes data from memory to the TX FIFO, and the LPUART sequentially retrieves and transmits the data from the TX FIFO. This mechanism allows for continuous data transfer on the hardware side without waiting for the DMA transfer to complete, enabling continuous communication without interrupting throughput. The operation of DMA can be illustrated as follows: When using LPUART with DMA, you need to configure the channel MUX to determine which eDMA channel the LPUART's TX/RX requests should be routed through. In the MCX A153, there is no separate DMAMUX peripheral as seen in other families. Instead, each channel of the eDMA controller has a built-in channel MUX (CHn_MUX register) that selects which peripheral function's DMA request source it will accept. The SDK assigns request sources to each channel using the EDMA_SetChannelMux() API (the specific calling method is described in Chapter 4). The channel number is not fixed and can be freely switched depending on the application's use. The diagram below illustrates how multiple DMA request sources on the peripheral function side are connected to the channel body via a channel MUX selector built into each eDMA channel. In the diagram above, the solid lines show an example where LPUART0 TX is assigned to Channel 0 and LPUART0 RX to Channel 1 using EDMA_SetChannelMux . The dotted lines represent available connection options, and by rewriting the arguments when calling the API, it is possible to change other assignments, such as assigning LPUART0 TX to Channel 2. 4. Basic Flow of SDK Drivers Next, we will demonstrate how to use the driver using the MCUXpresso SDK sample project "lpuart_edma_transfer" as an example. Reference URL: Hardware requirements — MCUXpresso SDK Documentation mcuxsdk-examples/driver_examples/lpuart/edma_transfer/lpuart_edma_transfer.c The following seven steps are the basic steps when using LPUART and DMA together: Enable the clock. Configure pin MUX Initialize the LPUART. Configure the eDMA channel MUX. Generate a DMA handle Start sending/receiving The next process is controlled by the callback. In the following sections, we will explain each step in detail, including code snippets. 4.1 Clock Port Settings First, enable the clock on the LPUART module. CLOCK_EnableClock(kCLOCK_Lpuart0); Next, we configure the MUX pins used for TX and RX. PORT_SetPinMux(PORTA, 1U, kPORT_MuxAlt2); // TX PORT_SetPinMux(PORTA, 2U, kPORT_MuxAlt2); // RX Aside from GND, the UART wiring consists of only two wires: transmit and receive. In the FRDM-MCXA153 circuit diagram, the TXD and RXD of LPUART0 are connected to the MCU-LINK's Virtual COM, and by connecting the MCU-Link to a PC via USB, debugging via UART communication becomes possible. flowchart LR PC[PC] <-->|USB| MCULINK[MCU-LINK Virtual COM] MCULINK <-->|UART| LPUART0[MCXA153 LPUART0]   4.2 LPUART initialization Initializing the LPUART involves first obtaining the default settings and then modifying the necessary items. lpuart_config_t config; LPUART_GetDefaultConfig(&config); config.baudRate_Bps = 115200; config.enableTx = true; config.enableRx = true; LPUART_Init(LPUART0, &config, CLOCK_GetFreq(kCLOCK_CoreSysClk)); The baud rate depends on the clock frequency supplied to the LPUART, so you need to pass the correct clock source frequency in CLOCK_GetFreq() . Enable TX and RX as needed. 4.3 eDMA Channel MUX Settings Before generating the handle, you specify with EDMA_SetChannelMux which eDMA channel to route the LPUART TX/RX requests to. As explained in Chapter 3, the MCX A153 does not have an independent DMAMUX, and this API sets the request source in the CHn_MUX register for each channel. /* LPUART0 TX を eDMA の任意チャネル(例: CH0)に割り当てる */ EDMA_SetChannelMux(DMA0, LPUART_TX_DMA_CHANNEL, kDma0RequestMuxLPUART0Tx); /* LPUART0 RX を eDMA の任意チャネル(例: CH1)に割り当てる */ EDMA_SetChannelMux(DMA0, LPUART_RX_DMA_CHANNEL, kDma0RequestMuxLPUART0Rx); The channel number specified here must match the channel number passed to txEdmaHandle / rxEdmaHandle when generating the subsequent DMA handle. 4.4 DMA Handle Generation A handle is created to link LPUART and DMA, and a callback function is registered here to be called when communication is complete. lpuart_edma_handle_t g_lpuartEdmaHandle; LPUART_TransferCreateHandleEDMA(LPUART0, &g_lpuartEdmaHandle, lpuart_callback, userData, &txEdmaHandle, &rxEdmaHandle); This handle associates the LPUART and DMA TX/RX channels, which are then used by subsequent transmit and receive APIs. 4.5 Transmission (DMA) Sending is as simple as calling the API with the send buffer and size set to lpuart_transfer_t . lpuart_transfer_t xfer; xfer.data = txBuffer; xfer.dataSize = txSize; LPUART_TransferSendEDMA(LPUART0, &g_lpuartEdmaHandle, &xfer);   4.6 Receiving (DMA) Similarly, receiving is also done by specifying the receive buffer and size when calling the function. lpuart_transfer_t xfer; xfer.data = rxBuffer; xfer.dataSize = rxSize; LPUART_TransferReceiveEDMA(LPUART0, &g_lpuartEdmaHandle, &xfer);   4.7 Callback Implementation The application is notified of the completion of the communication via a callback function. void lpuart_callback(LPUART_Type *base, lpuart_edma_handle_t *handle, status_t status, void *userData) { if (status == kStatus_LPUART_TxIdle) { // 送信完了処理 } else if (status == kStatus_LPUART_RxIdle) { // 受信完了処理 } } kStatus_LPUART_TxIdle kStatus_LPUART_RxIdle indicates completion of transmission via DMA, and indicates completion of reception via DMA. If you want to continue receiving continuously, you can call LPUART_TransferReceiveEDMA() again within this callback to continue receiving without interruption.   4.8 Key Design Points When actually using LPUART and DMA in combination, there are several design considerations that you should keep in mind. First, let's consider the transfer size . If the transfer size is too small, the number of interrupts will increase, reducing CPU efficiency. If it's too large, the latency until the transfer is complete will be high. You need to choose an appropriate value that matches the application's requirements while keeping the FIFO size in mind. Next is the design of the receive buffer . If the receive length is predetermined, a fixed-length buffer is sufficient, but if you are continuously receiving data of an unspecified length, it is common to use a ring buffer. Finally, there's the callback process . Callbacks not only notify the application that the transfer is complete, but they also trigger the reconfiguration of the next DMA transfer. Implementing this part is the most crucial for ensuring stable continuous communication. 5. Common problems   5.1 DMA is not working Possible causes include the DMA clock not being enabled, the request source specified in EDMA_SetChannelMux not matching the LPUART's TX/RX, or the channel number passed to the LPUART driver not matching the channel number set in EDMA_SetChannelMux . The quickest solution is to first enable the clock and check that the channel MUX assignments match. 5.2 Data Loss Typical issues include FIFO overruns and transfer size settings that don't match the actual data volume. Review the relationship between the FIFO threshold and the DMA transfer unit. 5.3 Failure due to high-speed communication As the baud rate increases, factors such as FIFO underrun, insufficient buffer design, degraded waveform quality, and clock errors become apparent. It is necessary to isolate the cause from both the hardware-side signal quality and the software-side buffer supply capability. 6. Summary The most important thing for effectively using LPUART in practice is to correctly understand the role of FIFO and design the data buffer in consideration of its interaction with DMA. By keeping these points in mind, you can achieve stable UART communication with low power consumption and low CPU load. ========================= We are currently unable to respond to comments left in the "Comment" section of this post. We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us (Japanese Blog) " when making inquiries. (If you are already an NXP distributor or have a relationship with NXP, you may contact your representative directly.) This article explains the basic concepts of LPUART (Low Power Universal Asynchronous Receiver/Transmitter) on the MCX A153 and how to use it with the MCUXpresso SDK, aimed at engineers who are new to NXP products. First, we will explain the hardware overview, and then, using the FRDM-MCXA153 board as a base, we will explain how to use the MCUXpresso SDK API with code snippets. (Reading time: 20 minutes) MCUXpresso SDK MCX Japanese Blog

[MCX A153] GPIO Beginner's Guide (Japanese Blog) This article explains the basic concepts of GPIO ( General Purpose Input / Output ) on the MCX A153 . It also explains how to implement software using the MCUXpresso SDK , based on the FRDM-MCXA153 board, for engineers new to NXP products. First, an overview of the hardware is provided, followed by an explanation of how to use the MCUXpresso SDK, along with code snippets. (Reading time: 20 minutes) 1. Overview of the GPIO module   1.1 Role of GPIO GPIO is the most basic interface for controlling microcontroller pins as either "inputs" or "outputs". For example, in the FRDM-MCXA153 , the three RGB LEDs are wired to the following GPIOs , so it is possible to switch the LEDs ON/OFF by controlling the GPIOs. Red : P3_12 Green : P3_13 Blue : P3_0 1.2 Pin control function in MCX A153 In the MCX A153 , pin control functions are managed by the following two modules: (1) PORT module It primarily serves the following roles. Since one pin has multiple functions, PORT configuration is required to use it as a GPIO. Pin function selection ( GPIO / UART / SPI / I2C / PWM , etc. ) Pull-up / Pull-down settings Drive capability settings   (2) GPIO module It primarily serves the following roles: Input/Output Data Control High/Low output of the pin Reading the input state " PORT = pin configuration" and " GPIO = actual input/output operation," and so on.   2. Basic operation of GPIO GPIO modules have output and input modes, and the following operations are possible with each mode: (1) Output mode The following processes are possible: High output Low output Toggle (inverts the current output) (2) Input mode The following processes are possible: Read the pin voltage status (High or Low) Interrupt detection (rising / falling edge)   3. Basic Flow of SDK Drivers   To use GPIO, the following settings are required by the software. - Clock settings - Pin settings (PORT settings) - Input or output settings ( GPIO settings) - Interrupt settings (if necessary) This guide will demonstrate how to use the driver, using a sample project from the MCUXpresso SDK as an example.    3.1 Output Modes I will explain using the following project as an example. Reference URL: Hardware requirements — MCUXpresso SDK Documentation mcuxsdk-examples/driver_examples/gpio/led_output/gpio_led_output.c at main · nxp-mcuxpresso...   3.1.1Initialization First, initialize the clock, port, and GPIO for the red LED. #include "fsl_gpio.h" #include "fsl_port.h" // 赤色LEDに配線されたピンのパラメータ #define BOARD_INITPINS_LED_RED_PORT PORT3 #define BOARD_INITPINS_LED_RED_GPIO GPIO3 #define BOARD_INITPINS_LED_RED_PIN 12 void init_gpio(void) { // クロック有効化 CLOCK_EnableClock(kCLOCK_GateGPIO3); // PORT設定 const port_pin_config_t LED_RED = {/* Internal pull-up/down resistor is disabled */ kPORT_PullDisable, /* Low internal pull resistor value is selected. */ kPORT_LowPullResistor, /* Fast slew rate is configured */ kPORT_FastSlewRate, /* Passive input filter is disabled */ kPORT_PassiveFilterDisable, /* Open drain output is disabled */ kPORT_OpenDrainDisable, /* Low drive strength is configured */ kPORT_LowDriveStrength, /* Normal drive strength is configured */ kPORT_NormalDriveStrength, /* Pin is configured as P3_12 */ kPORT_MuxAlt0, /* Digital input enabled */ kPORT_InputBufferEnable, /* Digital input is not inverted */ kPORT_InputNormal, /* Pin Control Register fields [15:0] are not locked */ kPORT_UnlockRegister}; PORT_SetPinConfig(BOARD_INITPINS_LED_RED_PORT, BOARD_INITPINS_LED_RED_PIN, &LED_RED); // GPIO設定 gpio_pin_config_t LED_RED_config = { .pinDirection = kGPIO_DigitalOutput, .outputLogic = 0U }; GPIO_PinInit(BOARD_INITPINS_LED_RED_GPIO, BOARD_INITPINS_LED_RED_PIN, &LED_RED_config); }   3.1.2Output control ( LED on / off / toggle) The output values can be modified using the following API. GPIO_PinWrite(BOARD_INITPINS_LED_RED_PORT, BOARD_INITPINS_LED_RED_PIN, 1); // High GPIO_PinWrite(BOARD_INITPINS_LED_RED_PORT, BOARD_INITPINS_LED_RED_PIN, 0); // Low GPIO_PortToggle(BOARD_INITPINS_LED_RED_PORT, 1U << BOARD_INITPINS_LED_RED_PIN); // Toggle   3.2 Input Mode I will explain using the following project as an example. Reference URL: Hardware requirements — MCUXpresso SDK Documentation mcuxsdk-examples/driver_examples/gpio/input_interrupt/gpio_input_interrupt.c at main · nxp-mcuxpresso...   3.2.1 Initialization Since it's the same except for the output mode and arguments, I'll omit the details.   3.2.2Input reading The input values can be read using the following API. uint32_t value = GPIO_PinRead(BOARD_SW_GPIO, BOARD_SW_GPIO_PIN); if (value == 0) { // スイッチ押下（プルアップの場合） }   3.2.3Interrupt settings To set the falling edge signal as a GPIO interrupt, use the following API. EnableIRQ is the interrupt enable setting on the Cortex-M side. GPIO_SetPinInterruptConfig(BOARD_SW_GPIO, BOARD_SW_GPIO_PIN, kGPIO_InterruptFallingEdge); EnableIRQ(BOARD_SW_IRQ); Handling interrupts requires a function definition as an interrupt handler. If you don't clear the interrupt flag, the interrupt will continue to occur indefinitely, so be careful. void BOARD_SW_IRQ_HANDLER(void) { /* 割り込みフラグをクリア */ GPIO_GpioClearInterruptFlags(BOARD_SW_GPIO, 1U << BOARD_SW_GPIO_PIN); // 処理 SDK_ISR_EXIT_BARRIER; } The process leading up to an interrupt is shown below. The above explains how to use the GPIO driver with the MCUXpresso SDK.   4. Common pitfalls If you modify the source code and the GPIO doesn't work as expected, please check the following items. The pin is set to a different function → Check the PORT settings to see if the pin is assigned to GPIO. Clock not enabled → Check if CLOCK_EnableClock is being called. Incorrect pin number → Check if it matches the hardware pin number. GPIO interrupts are not being received → Check that interrupts are enabled on the Cortex-M side using EnableIRQ. GPIO interrupts are looping → Check if the interrupt flag has been cleared.   5. Summary   The GPIO pins on the MCX A153 operate in a two-stage configuration: pin configuration via the PORT module and input/output control via the GPIO module. Therefore, when using a pin as a GPIO, you must first configure the pin assignment settings in the PORT module and select the GPIO function. After that, you use the GPIO module to initialize it as an input or output and perform operations such as turning LEDs on and off or reading the state of switches. Using the MCUXpresso SDK, these settings and controls can be implemented concisely via the library API. Furthermore, by utilizing the GPIO interrupt function, it is possible to efficiently detect events such as switch presses. If the GPIO does not work as expected, check whether the PORT setting is enabled, whether the clock is enabled for the target PORT, and whether the pin number setting is correct.   ========================= 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.) This article explains the basic concepts of GPIO ( General Purpose Input / Output ) on the MCX A153 . It also explains how to implement software using the MCUXpresso SDK , based on the FRDM-MCXA153 board, for engineers new to NXP products. First, an overview of the hardware is provided, followed by an explanation of how to use the MCUXpresso SDK, along with code snippets. (Reading time: 20 minutes) MCX Japanese Blog

OpenWrt upgrade for i.MX platforms is ready Processor and Board Support i.MX 8M Mini EVK i.MX 8M Nano EVK i.MX 8M Plus EVK i.MX 8M Quad EVK i.MX 91 EVK i.MX 93 EVK i.MX 93W EVK i.MX 95 15x15 EVK i.MX 95 19x19 EVK FRDM-IMX8MPLUS FRDM-IMX91 FRDM-IMX91S FRDM-IMX93 FRDM-IMX93W FRDM-IMX95 FRDM-IMX95-PRO OpenWrt and Toolchain OpenWrt from mainline (date: 29 Jun 2026, commit: f0a60eee2fe tag: v25.12.5) Toolchain:  ARMV8: GCC 14.3.0, GNU Binutils 2.44 U-Boot Bootloader i.MX SDK release, tag: lf-6.12.49-2.2.0 v2025.04 Linux Kernel OpenWrt kernel 6.12.94 based on IMX SDK release kernel lf-6.12.49-2.2.0 Firmware firmware-imx-8.30 Features Squashfs rootfs support on SD card. Support CLI and web configuration. U-Boot Boot Loader - U-Boot: lf-6.12.49-2.2.0. - Arm Trusted firmware (TF-A) integration. - Boot from SDHC Linux Kernel Core - Linux kernel 6.12.49 - Cortex-A53 (AARCH64), little endian for imx8m platforms - Cortex-A55 (AARCH64), little endian for imx9 platforms - 64-bit effective kernel addressing Linux Kernel Drivers - SDIO 3.0 / eMMC5.1 - USB 3.0/2.0 Dual-Role with PHY type C - 32-bit LPDDR4/LPDDR5 - 2x Gigabit Ethernet with AVB, IEEE 1588, EEE   and 1x w/ TSN - PCIe Gen 3 + WIFI - CAN FD - Dual-ch. QuadSPI (XIP) or 1x OctalSPI(XIP) - RTC - IW610/IW612 WiFi module - Bluetooth Licensing The majority of the software included in the OpenWrt release is licensed under a form of open source license (e.g. GPL, BSD). Some software is licensed under the NXP EULA license.  How to obtain this release The source code of the OpenWrt release can be got from the following link: https://github.com/nxp-imx/imx_openwrt   branch: imx-openwrt-25.12 tag: imx_v25.12_v6.12.49 The user guide can be found in the below link for build and deployment on IMX targets: https://github.com/nxp-imx/imx_openwrt/blob/imx-openwrt-25.12/target/linux/imx/README

Debugging_Bare_Metal_Code_in_NOR_Flash Scope This practical guide records the complete workflow used to build a ROM-target bare-metal image, program it into NOR flash, boot independently from NOR, and attach CodeWarrior with symbols for source-level debugging. Create the bare-metal project and confirm it works with the RAM/JTAG configuration. Create a ROM build configuration and link .intvec at 0xEFF00000 and .reset at 0xEFFFFFFC. Build the ELF. Generate the raw BIN from the same build. Create the Flash Programmer task using T1013RDB_NOR_FLASH.xml. Confirm the S29GL01GP flash range is 0xE8000000 to 0xEFFFFFFF. Configure the BIN destination as 0xEFF00000. Erase the selected sectors, program the image, and enable verification. Select NOR boot and power-cycle or reset the board. Confirm the program starts without JTAG downloading the image. Attach CodeWarrior to the running target. Load the exact matching ELF as symbols only. Confirm the Program Counter, set breakpoints, and begin source-level debugging.

GUI Guider 2.0.1 imageConfig 同时设 RGB565A8 和 RLE，保存后重开工程即卡死 GUI Guider 2.0.1 imageConfig 同时设 RGB565A8 和 RLE，生成代码即卡住，然后退出重开工程即卡死，一直Loading无法进入 Re: GUI Guider 2.0.1 imageConfig 同时设 RGB565A8 和 RLE，保存后重开工程即卡死 Hi @Mike22 , 感谢您关注恩智浦，感谢您反馈此问题。 我们已经知悉 GUI Guider 2.0.1 中的这个问题。当启用 RLE 压缩，并且图片的宽度和高度同时为奇数时，可能会导致代码生成过程卡住，并且重新打开工程后一直停留在 Loading 状态。 作为临时解决方案，如果工程已经无法正常打开，请手动编辑本地的 .guiguider 工程文件，将 ImageConfig 中的 compress 配置从： "compress": "RLE" 修改为： "compress": "" 修改后，工程应该可以正常打开。 此外，在使用 RLE 压缩时，请确保图片的宽度和高度不要同时为奇数，即可避免触发该问题。 此问题将在下一个版本中修复。 对此给您带来的不便，我们深表歉意，也感谢您的理解与配合。 Best Regards May Liu

i.MX95：在定制硬件上 OP-TEE xtest 测试失败 你好， 我最近将基于 i.MX95 (B0 rev) 的自定义硬件的 BSP 从 Linux 6.12.49_2.2.0 移植到了 Linux 6.18.37_2.1.0。突然，OP-TEE 的 xtest 开始出现测试失败的情况（xtest 输出已附上）。 经过一番调查，我发现故障源于 OP-TEE 核心无法验证从文件系统加载的 TA 上的 RSA 签名；这是由于 ELE 总是对 RSA 验证请求响应 ELE_INVALID_MESSAGE 造成的。 以下是 CFG_TEE_CORE_LOG_LEVEL=2 和 CFG_TEE_TA_LOG_LEVEL=2 时 OP-TEE 输出的摘录： E/TC:? 0 imx_ele_signature_verification:391 签名验证失败 res = ffff0006 ETC：？0 do_verify:514 RSA 签名验证失败 E/LD: init_elf:494 sys_open_ta_bin(cb3e5ba0-adf1-11e0-998b-0002a5d5c51b) ETC：？0 ldelf_init_with_ldelf:152 ldelf 失败，返回值为：0xffff000f 有什么建议可以帮助我调查吗？ 先感谢您 Linux 安全 Re: i.MX95: OP-TEE xtest failing on custom hardware 我找到了罪魁祸首：新的 电路板支持包。 启用了 ELE 支持的 ECC 和 RSA，但它们依赖于已加载的 ELE 运行时固件。可以通过以下方式触发负载： echo 1 > /sys/kernel/se/se_load_fw 预期的 dmesg 输出为：   fsl-se secure-enclave-0：正在加载固件 imx/ele/mx95b0runtime-ahab-container.img fsl-se secure-enclave-0：固件已成功加载   Re: i.MX95: OP-TEE xtest failing on custom hardware 你好@fvalla-MTA 是的你是对的。 版本 6.18.37 需要加载 ELE 运行时固件。 B.R

i.MX95: OP-TEE xtest failing on custom hardware Hello, I recently ported the BSP for my custom hardware, based on i.MX95 (B0 rev), from Linux 6.12.49_2.2.0 to Linux 6.18.37_2.1.0 and suddenly OP-TEE's xtest started failing tests (xtest output attached). Some digging led me to determine that failures come from the OP-TEE core not being able to validate RSA signatures on TAs loaded from filesystem; that is caused by the ELE always responding ELE_INVALID_MESSAGE to RSA validation requests. Here is an extract of the OP-TEE output with CFG_TEE_CORE_LOG_LEVEL=2 and CFG_TEE_TA_LOG_LEVEL=2: E/TC:? 0 imx_ele_signature_verification:391 Failure in signature verificaction res = ffff0006 E/TC:? 0 do_verify:514 RSA signature verification failed E/LD: init_elf:494 sys_open_ta_bin(cb3e5ba0-adf1-11e0-998b-0002a5d5c51b) E/TC:? 0 ldelf_init_with_ldelf:152 ldelf failed with res: 0xffff000f Any idea on what should I investigate? Thank you in advance Linux Security Re: i.MX95: OP-TEE xtest failing on custom hardware I found the culprit: the new BSP enables ELE-backed ECC and RSA, but they depend on the ELE runtime firmware being loaded. The load can be triggered with: echo 1 > /sys/kernel/se/se_load_fw The expected dmesg output is:   fsl-se secure-enclave-0: loading firmware imx/ele/mx95b0runtime-ahab-container.img fsl-se secure-enclave-0: Firmware loaded successfully   Re: i.MX95: OP-TEE xtest failing on custom hardware Hi @fvalla-MTA  yes, you are right. Version 6.18.37 requires loading the ELE runtime fw. B.R

mcxa145 编程异常 早上好， 我已将微控制器从 MCXA144VLH 更换为 MCXA145VLL，但使用该微控制器的板遇到了一些问题。 我尝试对一块带有 MCXA145 的板进行编程，当我尝试通过 IDE（使用 Cyclone LC）开始调试时，固件不会在主函数中的断点处停止（如下面的屏幕截图所示）。该板之前从未被编程过。 在我进行的第二次测试中，我直接通过 Cyclone 对微控制器进行编程（没有通过 IDE），编程成功了。 如果在此编程完成后，我立即通过 IDE 再次尝试，调试器会在主函数中的断点处正确停止。 但是，一旦我重新启动固件，IDE 就完全失去了对它的跟踪，调试器也挂起了（如第一张图片所示）。 但是，一旦我重新启动固件，IDE 就完全失去了对主函数的跟踪，调试器崩溃了（如第一张图片所示）。 然而，我发现的问题是，固件实际上并没有被编程——无论是第一种方式还是第二种方式。每次我关闭控制单元再重新启动时，固件就会丢失。 我使用运行相同软件的 MCXA144 时从未遇到过这类问题。 但是，在这种情况下，ISP 模式下的 P0_6 引脚固定为 GND。这会不会是原因？ 先行致谢。 顺祝商祺！ Re: mcxa145 programming anomalies 你好@Transidico ， 请您在MCX 微控制器 - NXP 社区下创建一个新帖子来提出您的新问题吗？它能帮助我们追踪不同的主题。 先行致谢。 BR 塞莱斯特 Re: mcxa145 programming anomalies 非常感谢你，Celeste——你解释得非常清楚。 关于 WWDT0，我还有另一个问题。我的设置如下： 我用它来在固件死机后 250 毫秒内 RESET 固件。 在我的固件的某些部分，我特意加入了一个 `while(1)` 循环，以便进行这种 RESET。 使用窗口式看门狗是正确的选择吗？ 我注意到看门狗在一个硬件上工作正常，但在另一个硬件上却不行——是不是有什么东西阻止了 WWDT，或者我有什么需要注意的吗？ 再次感谢你，塞莱斯特 Re: mcxa145 programming anomalies 你好@Transidico ， MCXA144VLH 和 MCXA145VLL 的情况有所不同。 对于 MCXA145VLL，仅使用 P0_6 作为 ISP 输入引脚。引脚 50 (P3_29) 可用作普通 GPIO。 对于 MCXA144VLH（LQFP64 封装），该设备受勘误 ERR053147 影响： 因此，P0_6 和 P3_29 都需要谨慎处理。为避免意外进入 ISP 模式，请确保在 POR 期间 P0_6 为高电平，在热 RESET 期间 P3_29 为高电平。 希望对您有所帮助。 BR 塞莱斯特 Re: mcxa145 programming anomalies 谢谢 Celeste， 我试过了，现在可以正常进入调试模式了。 我还想知道引脚 50 是否应该保持高电平，或者它是否可以用作普通的 GPIO。 也感谢您提前提供的答案。 顺祝商祺！ Re: mcxa145 programming anomalies 你好@Transidico ， 感谢你的帖子。 是的，这种现象看起来更像是RESET后启动/ISP入口的问题，而不是闪存中已编程的镜像文件丢失。 对于从内部 Flash 正常启动的情况，RESET期间 P0_6 不应保持低电平。由于您的板上的 P0_6 引脚已连接到 GND，请释放此引脚并重复编程、RESET 和上电循环测试。 作为快速检查，您还可以使用MCUXpresso 安全配置工具，并在 RESET 或断电重启后单击“测试连接”。如果通过 ISP 接口连接成功，则表明 MCU 已进入 ISP 模式，而不是从内部 Flash 启动应用程序。 希望对您有所帮助。 BR 塞莱斯特

mcxa145 プログラミング異常 おはようございます。 MCXA144VLHマイクロコントローラからMCXA145VLLに切り替えたのですが、このマイクロコントローラを搭載したボードでいくつか問題が発生しています。 MCXA145を載せたボードをプログラムしてみたところ、IDE(Cyclone LC)でデバッグを始めようとすると、メイン機能のブレークポイントでファームウェアが停止しません(下のスクリーンショットでわかります)。このボードはこれまで一度もプログラムされたことがない。 2回目のテストでは、IDEを経ずにCycloneで直接マイクロコントローラをプログラムし、プログラムは成功しました。 このプログラミング直後にIDEで再度試みると、デバッガはメイン関数のブレークポイントで正しく停止します。 しかし、ファームウェアを再起動すると、IDEsは完全にその追跡を失い、デバッガがフリーズしてしまいます(最初の画像に示されています)。 しかし、ファームウェアを再起動すると、IDEはメイン機能を完全に認識しなくなり、デバッガが潰れてしまいます(最初の画像に示されています)。 しかし、私が気づいた問題は、ファームウェアが実際にはプログラムされていないということです。最初の方法でも、2番目の方法でもです。コントロールユニットをオフにして再度オンにすると、ファームウェアが失われてしまいます。 同じソフトで動くMCXA144ではこんな問題は一度もありません。 しかしこの場合、ISPモードのP0_6ピンはGNDに固定されています。これが原因でしょうか? よろしくお願いいたします。 よろしくお願いいたします。 Re: mcxa145 programming anomalies こんにちは、 @Transidico さん、 新しい質問のために「MCX マイクロコントローラ - NXPコミュニティ」の新しい投稿を作成してもらえますか?これにより、異なるトピックを追跡するのに役立ちます。 よろしくお願いいたします。 BR セレステ Re: mcxa145 programming anomalies セレステ、本当にありがとうございます。とても分かりやすく説明してくれました。 WWDT0についてもう一つ質問があります。これが私の設定です。 フリーズが起きた場合に備えて、250ms後にファームウェアをリセットするために使っています。 ファームウェアの一部では、このリセットを可能にするために、意図的に`while(1)`ループを含めています。 ウィンドウ型ウォッチドッグを使用するのは正しい選択でしょうか？ ウォッチドッグタイマーが、あるハードウェアでは正しく動作するのに、別のハードウェアでは動作しないことに気づきました。WWDTの動作を妨げている可能性のある要因があるのでしょうか、それとも私が注意すべき点があるのでしょうか？ セレストさん、改めてありがとうございました。 Re: mcxa145 programming anomalies こんにちは、 @Transidico さん、 MCXA144VLHとMCXA145VLLの場合は状況が異なります。 MCXA145VLLの場合、ISPエントリピンとして使用されるのはP0_6のみです。ピン50(P3_29)は通常のGPIOとして使用できます。 MCXA144VLH(LQFP64パッケージ)では、装置は訂正ERR053147の影響を受けます: したがって、P0_6とP3_29はどちらも慎重に取り扱う必要がある。意図せずISPモードに入ってしまうことを避けるため、POR中はP0_6がハイレベル、ウォームリセット中はP3_29がハイレベルであることを確認してください。 お役に立てば幸いです。 BR セレステ Re: mcxa145 programming anomalies セレストさん、ありがとう。 試してみたところ、正しくデバッグモードに入るようになりました。 ピン50を高く保つべきか、それとも通常のGPIOとして使えるかも気になっています。 この回答についても、事前に感謝申し上げます。 よろしくお願いいたします。 Re: mcxa145 programming anomalies こんにちは、 @Transidico さん、 投稿ありがとうございます。 はい、その動作は、フラッシュメモリからプログラムされたイメージが実際に失われたというよりも、リセット後のブート/ISPエントリの問題のように見えます。 内部フラッシュからの通常の起動では、リセット中にP0_6を低く保つべきではありません。お使いの基板ではP0_6がGNDに接続されているため、このピンを解放してから、プログラミング、リセット、電源投入のテストを再度実行してください。 簡単な確認として、 MCUXpressoのSecure Provisioning Tool を使ってリセットや電源を入れ直した後に「接続テスト」をクリックすることもできます。ISPインターフェース経由で接続が成功した場合、これはMCUが内部フラッシュからアプリケーションを起動するのではなくISPモードに入ったことを示します。 お役に立てば幸いです。 BR セレステ

i.MX95: カスタムハードウェアでOP-TEEのテストが失敗する こんにちは、 最近、カスタムハードウェア用にi.MX95(B0バージョン)用にBSPをLinux 6.12.49_2.2.0からLinux 6.18.37_2.1.0に移植しましたそして突然、OP-TEEのxtestがテストに失敗し始めました（xtestの出力を添付します）。 調査の結果、OP-TEEコアがファイルシステムからロードされたTA上のRSA署名を検証できないことが障害の原因であることが判明しました。これは、ELEがRSA検証要求に対して常にELE_INVALID_MESSAGEという応答を返すことが原因です。 以下は、CFG_TEE_CORE_LOG_LEVEL=2 および CFG_TEE_TA_LOG_LEVEL=2 の場合の OP-TEE 出力の抜粋です。 E/TC:? 0 imx_ele_signature_verification:391 署名検証に失敗しました res = ffff0006 等：？0 do_verify:514 RSA署名検証に失敗しました E/LD: init_elf:494 sys_open_ta_bin(cb3e5ba0-adf1-11e0-998b-0002a5d5c51b) 等：？0 ldelf_init_with_ldelf:152 ldelf が res: 0xffff000f で失敗しました 何を調べればいいか、何かアイデアはありますか? よろしくお願いします Linux Security Re: i.MX95: OP-TEE xtest failing on custom hardware 原因が判明しました。新しいBSPはELEを基盤としたECCとRSAを有効にしますが、それらはELEランタイムファームウェアがロードされていることを前提としています。負荷は以下の方法でトリガーできます: echo 1 > /sys/kernel/se/se_load_fw 期待されるdmesgの出力は以下のとおりです。   FSL-se セキュア・エンクレーブ-0: loading firmware IMX/ele/MX95B0runtime-ahab-container.img FSL-SE セキュア・エンクレーブ-0:ファームウェアの正常なロード   Re: i.MX95: OP-TEE xtest failing on custom hardware こんにちは、 @fvalla-MTAさん はい、おっしゃる通りです。バージョン6.18.37では、ELEランタイムファームウェアのロードが必要です。 B.R

GUI Guider 2.0.1では、imageConfigでRGB565A8とRLEの両方を設定し、保存してプロジェクトを再起動すると、フリーズします。 GUI Guider 2.0.1を使用してimageConfigでRGB565A8とRLEの両方を同時に設定すると、コード生成プロセスがフリーズします。プロジェクトを終了して再起動すると、再びフリーズし、読み込み状態のまま先に進めなくなります。 Re: GUI Guider 2.0.1 imageConfig 同时设 RGB565A8 和 RLE，保存后重开工程即卡死 こんにちは、 @Mike22 さん。 NXPにご関心をお寄せいただき、またこの件についてご意見をお寄せいただき、ありがとうございます。 GUI Guider 2.0.1 において、この問題が発生することを認識しています。RLE 圧縮が有効になっており、画像の幅と高さが両方とも奇数の場合、コード生成プロセスがフリーズし、プロジェクトを再度開いた後も読み込み状態のままになることがあります。 一時的な解決策として、プロジェクトが正常に開けない場合は、ローカルの.guiguiderファイルを手動で編集してください。プロジェクトファイル内のImageConfigの圧縮設定を以下のように変更します。 「圧縮」: 「RLE」 改訂版： 「圧縮」: 「」 変更後、プロジェクトは正常に起動するはずです。 さらに、RLE圧縮を使用する場合は、この問題を回避するために、画像の幅と高さが両方とも奇数にならないようにしてください。 この問題は次期バージョンで修正されます。ご迷惑をおかけして誠に申し訳ございません。ご理解とご協力をお願いいたします。 よろしくお願いします メイ・リウ

mcxa145 programming anomalies Good morning, I’ve switched from using the MCXA144VLH microcontroller to the MCXA145VLL and am experiencing some issues with boards featuring this microcontroller. I tried programming a board with the MCXA145 on it, and when I try to start debugging via the IDE (using Cyclone LC), the firmware does not halt at the breakpoint in the main function (as you can see from the screenshot below). The board has never been programmed before. In a second test I carried out, I programmed the microcontroller directly via Cyclone (without going through the IDE), and the programming was successful. If, immediately after this programming, I try again via the IDE, the debugger stops correctly at the breakpoint in the main function. However, as soon as I restart the firmware, the IDE completely loses track of it and the debugger hangs (as shown in the first image). However, as soon as I restart the firmware, the IDE completely loses track of the main function and the debugger crushes(as shown in the first image). The problem I’ve noticed, however, is that the firmware isn’t actually being programmed – neither in the first way nor in the second. Whenever I switch the control unit off and on again, the firmware is lost.  I’ve never had this sort of problem with the MCXA144, which runs on the same software. In this case, however, the P0_6 pin in ISP mode is fixed to GND. Could this be the cause? Thanks in advance. Best regards. Re: mcxa145 programming anomalies Hello @Transidico , Could you please create a new post under MCX Microcontrollers - NXP Community for the new question? It helps us track different topic. Thanks in advance. BR Celeste Re: mcxa145 programming anomalies Thank you so much, Celeste – you’ve explained it very clearly. I have another question about the WWDT0. These are my settings: I use it to reset the firmware after 250 ms in case it freezes. In certain parts of my firmware, I deliberately include a `while(1)` loop to allow for this reset. Is it the right choice to use the windowed watchdog? I’ve noticed that the watchdog works correctly with one piece of hardware but not with another – is there anything that might be blocking the WWDT, or is there anything I need to be aware of? Thanks again, Celeste Re: mcxa145 programming anomalies Hello @Transidico , The situation is different for MCXA144VLH and MCXA145VLL. For MCXA145VLL, only P0_6 is used as the ISP entry pin. Pin 50 (P3_29) can be used as a normal GPIO. For MCXA144VLH(LQFP64 package), the device is affected by erratum ERR053147: Therefore, both P0_6 and P3_29 need to be handled carefully. To avoid unintentionally entering ISP mode, please ensure that P0_6 is high during POR and P3_29 is high during a warm reset. Hope it can help you. BR Celeste Re: mcxa145 programming anomalies Thanks Celeste, I tried it, and now it enters debug mode correctly. I was also wondering if pin 50 should be kept high, or if it can be used as a normal GPIO. Thanks in advance for this answer as well. Best Regards. Re: mcxa145 programming anomalies Hello @Transidico , Thanks for your post. Yes, the behavior looks more like a boot/ISP-entry issue after reset rather than the programmed image actually being lost from Flash.  For normal boot from internal Flash, P0_6 should not be held low during reset. Since P0_6 is tied to GND on your board, please release this pin and repeat the programming, reset, and power-cycle tests. As a quick check, you can also use MCUXpresso Secure Provisioning Tool and click "Test connection" after a reset or power cycle. If the connection succeeds through the ISP interface, this would indicate that the MCU has entered ISP mode rather than booting the application from internal Flash. Hope it can help you. BR Celeste

In GUI Guider 2.0.1, setting both RGB565A8 and RLE in imageConfig, saving and restarting the project causes it to freeze. When using GUI Guider 2.0.1 to simultaneously set both RGB565A8 and RLE in imageConfig, the code generation process freezes. Exiting and restarting the project then causes another freeze, stuck in a loading state and unable to proceed. Re: GUI Guider 2.0.1 imageConfig 同时设 RGB565A8 和 RLE，保存后重开工程即卡死 Hi @Mike22 , Thank you for your interest in NXP and for providing feedback on this issue. We are aware of this issue in GUI Guider 2.0.1. When RLE compression is enabled and the width and height of the image are both odd numbers, the code generation process may freeze, and the project may remain in the Loading state after being reopened. As a temporary solution, if the project cannot be opened normally, please manually edit your local .guiguider file.In the project files, change the compress configuration in ImageConfig from: "compress": "RLE" Revised to: "compress": "" After the modifications, the project should open normally. In addition, when using RLE compression, ensure that the width and height of the image are not both odd numbers to avoid triggering this problem. This issue will be fixed in the next version. We sincerely apologize for any inconvenience this may cause and thank you for your understanding and cooperation. Best Regards May Liu

LS1043A 安全启动 4x 4096 密钥导致启动挂起 使用 1 个 1024 位密钥（包含 1 个元素的密钥表）可以正常实现安全启动。 尝试更改为 4 个 4096 位密钥（包含 4 个元素的密钥表） 常规输出卡在： 注意：高效密码学标准\(SEC\) 已初始化并配置完成。 调试输出卡在： 详细信息：表键 3 哈希 然后是 8 行哈希值 不确定是否为巧合，但最后一行的值为：VERBOSE: 642dead0 谷歌/Gemini 似乎认为放置 4 个 4096 位密钥导致了越界或错位。 上面表键 0、1 和 2 的其他几行似乎都没问题。 QorIQ LS1设备 Re: LS1043A Secure Boot 4x 4096 keys hangs boot 我觉得我已经找到问题所在了。当更换为更大的密钥和 HSM 时，我不得不修改一些构建脚本，导致它无法正确生成带有标头/签名等的二进制有效负载。我希望稍后能够确认，并将此问题标记为已解决，因为我没有看到删除帖子/移除帖子的选项。 Re: LS1043A Secure Boot 4x 4096 keys hangs boot 尝试将密钥数量减少到 2 个 4096 键，但仍然卡在了第一个键上，情况和之前一样。把它降到 1 个 4096 键，然后也挂起来了。 使用由 CST 2.x 生成和签名的 1x 1024 密钥时。我尝试使用的 4096 个密钥是通过 NitroKey HSM2 生成的，然后我使用 cst 为 srk 表/公钥生成映像哈希，然后使用 openssl 和 pkcs11 对文件进行签名，最后调用 cst sign_embed 实用程序来附加签名。

RT798S HiFi4 TRAX TraceRAM 在 AP 3 和 DSP ERI 上读取零值 我正在研究使用 RT798S HiFi4 在 MIMXRT700-EVK 上捕获 TRAX 指令。RI-2023.11 核心配置报告 XCHAL_HAVE_TRAX=1 和 XCHAL_TRAX_MEM_SIZE=8192。XOCD 14.11 通过 DAP AP 3 到达 HiFi4；观察到的 TRAXID 为 0x0d43eff2。 在跟踪不活动 (TRAXSTAT.TRACT=0) 和内存启用 (TRAXCTRL.TMEN=1) 的情况下，我使用 AP 3 xdmreg-wr/xdmreg-rd 命令将四个模式写入 TRAXDATA 并将它们读出来。TRAXADDR 按预期推进，但所有四个读取操作均返回零。DSP 端 libtrax ERI 写入/读取测试也返回零。XOCD 写入输出会回显所提供的值，因此我不将其视为 TraceRAM 已接受写入的确认。 CM33 端只读快照显示 DSP 功率域已开启，SRAM 分区 14-17 已通电，HiFi4 仲裁器-1 时钟已启用，HiFi4 仲裁器-0 访问掩码为 0x3fffffff。我没有任何文档将这些共享 SRAM 仲裁寄存器与 TRAX TraceRAM 联系起来。 请问您能否澄清一下： HiFi4 TRAX 及其 8 KiB TraceRAM 是否已在此 RT798S 芯片版本上完全实现和支持？是否存在相关的勘误或已知局限性？ 通过调试 AP 验证 TRAXDATA 写入/读取的推荐步骤是什么？除了 TRAXADDR 递增之外，我是否还应该检查 APB/JTAG 事务接受或错误状态？ TraceRAM 接口是否有 RT798S 特有的电源、时钟、RESET、网络安全或集成控制，而这些控制并未在标准 PMC SRAM 分区控制或 HiFi4 RAM 仲裁器中记录？ NXP 是否有示例或已知可靠的调试器/工具版本可以捕获和读取此板上的 HiFi4 TRAX TraceRAM？ 除了 Cadence libtrax API 之外，DSP 端 ERI 访问是否需要任何 RT798S 特有的排序或访问条件？ 我可以提供 POC 源代码和日志：trax_poc.c，AP 3 测试日志和 DSP ERI 测试日志。 评估板

S32K388 GMAC0 Eth_43_GMACドライバ送信支援 こんにちは、 私は以下の設定を使用しています。 S32K388EVB-Q289 S32DS 3.6.8 RTD 7.0.1 以前の投稿で述べたように、GMAC0 Eth_43_GMACドライバ S32K388 RX割り込みを受け取れません。提供されたEth_InternalLoopback_S32K388例プロジェクトをベースにし、PCからメディアコンバーター経由でフレームを受け取れるように改良しました。 今は逆方向に進めようとしています。つまり、評価ボードからイーサネットフレームをPCに戻すというS32K388です。PC上でwiresharkを使ってフレームをキャプチャしています。送信しようとしているフレームは、MACアドレスFF:FF:FFのブロードキャストフレームです。しかし、PC上で複数回試みても1フレームしか受信できず、一貫性がありません。 @PavelL、この問題についてもう一度助けていただけませんか?ありがとう。 Re: S32K388 GMAC0 Eth_43_GMAC driver transmitting help こんにちは、 @James_Zhang_SE さん、 あなたのプロジェクトを確認したところ、いくつかの細かな設定の違いしか見つかりませんでしたが、イーサネット伝送には影響しないようです。   複数回の試行で1フレームしか受信できないというのはどういう意味でしょうか?例えば、ボードの電源投入サイクルが完了するたびに1フレームが観測されるのか、それとも複数回の電源投入サイクル後やデバッグセッション後に時折しか観測されないのか、といった点です。また、デバッガでアプリケーションを継続的に実行していますか?それとも送信のたびに再起動していますか?   アプリケーションはEth_43_GMAC_Transmit()を一度だけ呼び出し、その後無限ループに入ります 。したがって、アプリケーション実行ごとに送信フレームは1つだけです。   この不整合な挙動は、送信リクエスト時にイーサネットPHYリンクが確立されていないことが原因かもしれません。フレームはGMACコントローラがアクティブモードに設定された直後に送信され、PHYリンクの状態は確認されません。TJA1120リンクがまだ確立されていない場合、送信された唯一のフレームが失われる可能性があります。   PHYがリンクアップを報告するまで待ってから、Eth_43_GMAC_ProvideTxBuffer()と Eth_43_GMAC_Transmit()を呼んでください。TJA1120リンクの状態を読み取る例は、device.cでbool get_device_link_status(uint8_t u8TrcvIdx)を使って確認できます。   この関数は、 SW32K3xx_M7_gPTP_1.1.0_CD01_D2602_DesignStudio_updatesite.zipに含まれるS32K388_gptp_dsサンプルで使用されており、S32K3 RTD 7.0.1 に適しています。   簡単な初期テストとして、送信前に十分長い遅延を設けることもできます。これによりフレームが安定して表示されるようになれば、問題がPHYリンクの確立に関連していることが確認できるだろう。 よろしくお願いいたします。 パベル Re: S32K388 GMAC0 Eth_43_GMAC driver transmitting help こんにちは、パベルさん。 迅速なご対応ありがとうございます！ 今日はいくつか試してみました。 TCP/IPスタックのサンプルを使用して、同じハードウェア構成でテストを行いました。その例では、すべて正常に動作し、S32K388評価ボードからPCでエコー応答を受け取ることができます。 私のアプリケーションでは、すぐにブレイクポイントを付けました: Eth_43_GMAC_SetControllerMode(EthConf_EthCtrlConfig_EthCtrlConfig_0, ETH_MODE_ACTIVE); ブレークポイントに到達した後、しばらく待ってから、Eth_43_GMAC_ProvideTxBuffer() を手動で実行して処理を続行しました。残念ながら、PC側では送信されたフレームをまだ受信していません。 先ほど説明した挙動についてですが、アプリケーションをテストするたびにメディアコンバーターと評価ボードの両方を電源サイクルしています。その後、組み込みデバッガを使ってアプリケーションを読み込み、実行を開始します。 これまでに 2回の成功した送信を観察しましたが、その2つのCASEで何が違ったのか、なぜフレームが成功したのかは判明できません。今日行ったテストを含め、これまでの試みはすべて失敗に終わった。 これまでのご協力に本当に感謝しています。この現象の原因をまだ解明しようとしているところです。何かご助言やご提案があれば、ぜひお聞かせください。 Re: S32K388 GMAC0 Eth_43_GMAC driver transmitting help こんにちは、 @James_Zhang_SE さん、 詳細なアップデートをありがとうございます。TCP/IPスタックの例が同じハードウェアセットアップで正しく動作していることは、基本的なハードウェアパス、GMACインターフェース、イーサネットリンクが正常に動作していることを裏付けています。 main.cを修正しましたフレームを送信する前に明示的にリンクアップを待つように、内部ループバックの例のファイル。この実装をS32K388EVB-Q289でテストしたところ、電源を入れるたびにWiresharkで送信フレームが一貫して確認できます。 以下の手順もテストしました。 GMAC0とメディアコンバーターの間のケーブルを外してください。 S32K388評価ボードを起動してアプリケーションを開始してください。 ケーブルをメディアコンバーターに再接続してください。 ケーブルを再接続すると、アプリケーションはリンクを検出し、送信されたフレームがWiresharkに期待通り表示されます。 私のハードウェア構成は以下のとおりです。 S32K388EVB-Q289 GMAC0 ↔ TE-1402メディアコンバータ(1 Gbit/sおよびフォロワーモード↔対応、USB to-イーサネットアダプター↔対応、Dell ノートPC、Windows 11搭載) 修正した main.c と対応する .mex ファイルを共有します。設定ファイルとmex_diff.htmlを用意して、私の設定とあなたの設定をより簡単に比較できるようにしてください。提供されたファイルを適切に置き換え、S32 Design StudioでUpdate Codeを実行し、テスト前にプロジェクトを再構築してください。 私の.mexファイルにはまだ設定の詳細が残っている可能性があります。信頼性の高い伝送に重要なファイル。したがって、まずは共有設定を一切変更せずにテストすることをお勧めします。お使いの環境で動作するのであれば、mex_diff.html を使用して、2 つの設定間の関連する差異を特定できます。 よろしくお願いいたします。 パベル

PXO 是否是现代高可靠性电子系统的理想灵活时钟解决方案？ 在科技飞速发展的时代，电子设备的性能和可靠性至关重要。来自全球领先晶振（晶体振荡器）元器件供应商的可编程晶振（晶体振荡器） (PXO) 能否为人工智能、汽车电子、通信（路由器、交换机、5G 基站）、医疗、工业自动化、消费电子和物联网提供强大的支持，从而推动现代技术发展？ PXO 是一种有源晶振（晶体振荡器），其输出频率可通过数字方式配置。它基于传统的晶振（晶体振荡器）架构，并集成了可编程控制电路，将晶体设备的高精度与数字可配置性相结合。这种“硬件精度+软件配置”解决方案为系统时钟设计带来了卓越的灵活性，是多品种和快速周转产品开发的理想选择。 主要技术亮点 重新定义精确计时 凭借精密制造工艺和自适应温度补偿算法，新型 PXO 系列在 -40 ° C 至 +85 ° C 的温度范围内可保持 ± 25ppm 的频率稳定性，在 -40° C 至 +105 °C的扩展温度范围内可保持 ± 50ppm 的频率稳定性。先进的晶体和振荡器电路设计实现了业界领先的低相位噪声。该系列产品在 100Hz、1kHz 和 10kHz 偏移频率下均具有出色的相位噪声性能，典型相位抖动（12kHz – 20MHz）低于 70fs，可满足通信和测试仪器等高精度应用的需求。 无限频率，用户可编程 它覆盖了 1MHz 至 1.5GHz 的宽频率范围，调谐分辨率可达 1Hz 或更高。部分型号支持可配置输出逻辑（LVPECL、LVDS、HCSL）、供电电压（1.8V/2.5V/3.3V），并启用/禁用控制以适应各种电路设计，消除了与传统固定频率晶体相关的较长交付周期。 微型外形尺寸 提供标准的 3.2× 2.5mm 和 2.5 × 2.0mm 封装。紧凑的尺寸适用于空间受限的设计，例如智能手机和高密度工业 PCB，可简化硬件集成。 超低功耗 针对低功耗运行进行了优化，降低了运行电流和待机电流。它可以延长电池寿命高达 40%，使其非常适合物联网和便携式设备。

S32G3 或非 Flash 从 M7 启动失败 您好，NXP， 目前我使用的是 GoldVIP-S32G3-1.16.0 中的示例引导加载程序。 我的设备是 S32G399 金盒版，BSP 版本为 48.0.0 我已配置好使用或非 Flash 和 M7 作为启动核心进行启动。 M7_bootloader 启动成功 -> M7 应用程序启动正常，但 A53 卡住了。 我正在使用 S32 Flash Tools 刷写 或非 固件。 1. fsl-image-flash-s32g399ardb3.flashimage 位于 0x00 -> 启动成功 -> 进入 Linux 系统成功 2. 将引导加载程序刷写到 0x00 (bootloader_0x000000.bin)。大小：154kb 3. 将 BootLoader_Configuration.bin 刷写到 0x1f0000 4. 将 a53_bl2_0x300_0000_DebugLevel5.bin 烧录到 0x300_0000 地址 BL2 无法启动 BL31 -> 那么 Linux 就无法启动，您能帮我解决这个问题吗？ 谢谢 金VIP Re: S32G3 NOR Flash booting from M7 fail 您好， 为确保您的问题及所有相关疑虑得到我们技术支持团队的妥善审查和跟踪，请通过 NXP 支持门户创建支持工单。 您可以点击此处查看教程： https://www.nxp.com/company/about-nxp/smarter-world-videos/NCP-VIDEO 登录您的 NXP 帐户后，打开帐户菜单并选择“支持工单” ，如附图所示。 请在工单中包含您的问题的全部细节以及任何相关的日志、配置文件或屏幕截图。 提交工单后，技术支持团队将审核您的咨询，并通过该工单给出相应的回复。 此致， 阿尔多。

ISP1564 EHCI 间歇性 PCI/DMA 故障，异步断开连接后可能出现 QH/qTD 写回。 我们正在调查仅在部分相同系统上发生的间歇性 ISP1564 EHCI 故障（该故障发生在 USB 流量下）。我们怀疑存在 PCI DMA/EHCI 异步 QH 解链时序问题，涉及 IAA 之后的 QH/qTD 写回。由于有记录的 PCI 吞吐量考虑因素，我们还在评估 BAR+0x6C 处的 ISP1564 系统调优寄存器，特别是 RBD 和 WMD。是否存在已知的 ISP1564 芯片错误，涉及异步调度取消链接、IAA、QH/qTD 写回、PCI DMA、环形缓冲或水印操作？