Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor Hi, I am using the NBP8FD4ST1 pressure sensor with the S32K146 microcontroller. The CS_B/WAKE-UP pin of the sensor is connected to a GPIO pin on the microcontroller. The logic analyzer signal mapping is as follows: D0 → SCLK D1 → CS_B D3 → READY D5 → MISO D7 → MOSI During the communication sequence, when I pull the CS_B pin low to request SPI communication, the READY pin is asserted as expected. After READY goes high, I send the SPIOPS register read command (0x00E1). However, the sensor always returns 0x0000 on MISO. As a result, the firmware validation fails, and the CS_B pin is subsequently driven high to terminate the transaction. Could you please help me understand whether my SPI communication sequence is correct or if I am missing any required step, such as the wake-up sequence, dummy transfer, or SPIOPS handling described in the datasheet? I have also attached the logic analyzer screenshots for reference. Thank you in advance for your support. Best regards, Pratyusha. Pratyusha_0-1783666219816.png Pressure Sensors Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor Hi Pratyusha, Please note that NXP's MEMS Sensors business, including pressure sensors such as the NBP8FD4ST1, has been transferred to STMicroelectronics. Effective February 2, 2026, technical support, product documentation and development activities for these sensors are now handled by STM. As a result, we are unfortunately no longer able to provide technical support for the NBP8FD4ST1. I recommend that you contact STM directly through their support channels or community forum, where the sensor experts can assist you with your implementation and communication troubleshooting. BRs, Tomas Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor from your chart D0 → SCLK, there is no clock signal when you read SPIOPS? Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor @suncongjohnson Thanks for your reply. I have configured the SPI peripheral for 16-bit transfers, so I expect 16 SCLK pulses to be generated for each SPI transaction. However, when issuing the SPIOPS read command, no SCLK signal is generated on the D0 (SCLK) line. const lpspi_master_config_t lpspiCom1_MasterConfig0 = { .bitsPerSec = 1000000U, .whichPcs = LPSPI_PCS0, .pcsPolarity = LPSPI_ACTIVE_LOW, .isPcsContinuous = true, .bitcount = 16U, .lpspiSrcClk = 8000000U, .clkPhase = LPSPI_CLOCK_PHASE_1ST_EDGE, .clkPolarity = LPSPI_SCK_ACTIVE_HIGH, .lsbFirst = false, .transferType = LPSPI_USING_INTERRUPTS, .rxDMAChannel = 255, .txDMAChannel = 255, .callback = NULL, .callbackParam = NULL, };

PTE4ABTE-32GX eMMC We are planning to use this eMMC PTE4ABTE-32GX from PHISON with the IMX8M Processor. Please confirm whether this will support booting. Attaching the datasheet for reference. Re: PTE4ABTE-32GX eMMC Yes, based on the datasheet, the PHISON PTE4ABTE-32GX should support booting on the i.MX8M family (i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP), provided it is connected to a USDHC interface according to the i.MX8M Hardware Design Guide. Re: PTE4ABTE-32GX eMMC Yes, the i.MX8ML (MIMX8ML5CVNKZAB) supports booting from an eMMC device connected through the USDHC interface. The PHISON PTE4ABTE-32GX is an eMMC 5.1 device and is expected to be compatible with the i.MX8ML boot flow when connected and configured according to the i.MX8M Hardware Design Guide. Re: PTE4ABTE-32GX eMMC @yipingwang Thanks for your response. We are using MIMX8ML5CVNKZAB, which is an i.MX8ML device. In your response, only the i.MX8M family (i.MX8MQ / i.MX8MM / i.MX8MN / i.MX8MP) has been mentioned. Could you please confirm whether the PHISON PTE4ABTE-32GX is also supported for booting with the i.MX8ML device when connected to the USDHC interface as per the hardware design guidelines?

有人在使用Kinetis的MCU吗？ 我目前正在评估一些配备 USB 接口的微控制器，Kinetis 系列的功能集引起了我的注意。我有一些样品（我主要想重点研究的是 K22FN1M0VLH12），把它们放在带接头的扩展板上，并且已经找到了一种使用 EzPort/SPI 将引导代码加载到它们上面的方法，但我现在到了需要真正开始进行正式固件开发的阶段。我做过不少软件开发工作，但在嵌入式平台方面经验不多。我喜欢飞思卡尔最近几个月发布的基于 Eclipse 的新工具链和 Processor Expert，因为它处理了很多外围设备初始化工作。然而，我发现关于这方面的信息非常匮乏，也缺乏关于在基于 GCC 的工具链中使用 Kinetis 的信息。目前流传的信息（虽然很少）似乎仅限于他们的 FRDM 板，虽然价格便宜，但仅限于他们可用产品系列的一小部分。 最近有人用过Kinetis吗？如果是的话，你使用了哪条工具链？ 与其它厂商的类似ARM芯片相比，人们对Kinetis的设备/文档/工具的总体印象如何？ 如果我拿到一块 K20 FRDM 板，大家认为我所获得的知识能否相对地迁移到我想在实际应用中使用的 K22F 芯片上？虽然有 K22F FRDM 开发板，但价格是它的两倍，差价还不够买一块 STM32 开发板来和这块板一起评估。 另外，一般来说，将代码从开发板移植到定制板有多容易？从开发板到定制电路，您采取了什么方法？ 如果问题太多，请见谅——我只是希望能请教一些专家意见。 Re: Anybody using Kinetis MCUs? 你好@lukutu ， 感谢你的帖子。 事实上，关于你提到的基于 Eclipse 的工具链，我假设你指的是 Kinetis Design Studio (KDS) 和 Processor Expert。这两个工具现在都是过时产品，不再提供支持。 作为 Kinetis Design Studio 的继任者，NXP 推出了MCUXpresso IDE 。与 KDS 一样，MCUXpresso IDE 也是基于 Eclipse 的，并集成了 GNU 工具链、SDK 示例导入、引脚/时钟/外设配置工具、闪存编程功能以及无缝的 SDK 集成，从而提供了一个更现代化且完全支持的开发环境。 MCUXPresso SDK 可在此处下载： MCUXpresso SDK Builder 您可以参考MCUXpresso IDE 的 MCUXpresso 配置工具来了解配置工具的使用方法。   至于硬件选择，我建议考虑FRDM-K22F主板。因为它与 K20 FRDM 平台有很大不同，而且还有一个额外的好处：购买后，回复您的订单确认电子邮件，即可申请免费的 FRDM-MCXE31B、FRDM-MCXN236、FRDM-MCXA153 或 FRDM-MCXA156 优惠券，用于评估 MCX 微控制器。 Celeste_Liu_0-1783935191572.png MCX 系列是恩智浦最新的 MCU 产品组合，可为新设计提供更长的产品生命周期。您可以考虑FRDM-MCXA156 ，它包含 USB 接口，对于未来的开发和评估来说可能是一个不错的选择。 关于将代码从开发板移植到定制板，使用 MCUXPresso 可以轻松实现，请参考以下帖子： 实践工作坊：为您的设备创建自定义板级 SDK 如何创建自定义板 MCUXpresso SDK 如果您还有其他问题，请告诉我。我很乐意帮忙。 BR 塞莱斯特

圧力センサのSPI通信に関する支援NBP8FD4ST1必要 こんにちは、 S32K146マイクロコントローラでNBP8FD4ST1圧力センサーを使っています。センサーの CS_B/WAKE-UP ピンはマイクロコントローラのGPIOピンに接続されています。 ロジックアナライザの信号マッピングは以下のとおりです。 D0 → SCLK D1 → CS_B D3 → 準備完了 D5 → MISO D7 → MOSI 通信シーケンス中に、 CS_BピンをローレベルにプルダウンしてSPI通信を要求すると、 READYピンは期待どおりにアサートされます。READYがハイになった後、 SPIOPSレジスタ読み取りコマンド(0x00E1)を送信します。しかし、MISOではセンサーは常に 0x0000 戻ってしまいます。その結果、ファームウェアの検証が失敗し、CS_Bピンがハイレベルに駆動されてトランザクションが終了します。 私のSPI通信シーケンスが正しいのか、それともデータシートに記載されているウェイクアップシーケンス、ダミー転送、SPIOPS処理など、必要なステップを見落としているのか教えていただけますか? 参考までに、ロジックアナライザのスクリーンショットも添付しました。 サポートにあらかじめ感謝いたします。 よろしくお願いします、 プラチューシャ。 Pratyusha_0-1783666219816.png 圧力センサ Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor こんにちは、プラティウシャさん。 なお、NXPのMEMSセンサ事業、NBP8FD4ST1などの圧力センサはSTMicroelectronicsに移管されました。2026年2月2日付で、これらのセンサの技術サポート、製品ドキュメント、開発活動はSTMが担当しています。その結果、残念ながらNBP8FD4ST1の技術サポートは提供できません。 サポートチャネルやコミュニティフォーラムを通じて直接STMに連絡することをお勧めします。センサの専門家が実装やコミュニケーションのトラブルシューティングをサポートいたします。 BRs、トーマス Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor あなたのチャートのD0→SCLKから、SPIOPSを読み取る際にクロック信号がないということでしょうか？ Re: Assistance Required with SPI Communication on NBP8FD4ST1 Pressure Sensor @suncongjohnsonご返信ありがとうございます。SPIペリフェラルは16ビット転送に設定しているので、SPIトランザクションごとに16回のSCLKパルスが生成されると予想しています。しかし、SPIOPSの読み取りコマンドを発行しても、D0（SCLK）ラインにはSCLK信号が生成されません。 const lpspi_master_config_t lpspiCom1_MasterConfig0 = { .bitsPerSec= 1000000U、 .whichPcs= LPSPI_PCS0、 .pcs極性= LPSPI_ACTIVE_LOW、 .isPcsContinuous= 真、 .bitcount= 16U、 .lpspiSrcClk= 8000000U、 .clkPhase= LPSPI_CLOCK_PHASE_1ST_EDGE、 .clkPolarity= LPSPI_SCK_ACTIVE_HIGH、 .lsbFirst= 偽、 .transferType= LPSPI_USING_INTERRUPTS、 .rxDMAChannel= 255、 .txDMAChannel= 255、 。折り返し電話= NULL、 .callbackParam= NULL、 };

What Is Model-Based Design? A Practical Introduction for Modern Embedded Systems   Table of Contents Why embedded development needs a better workflow What Model-Based Design is A simple mental model: from idea to executable model to hardware Why engineers use it: the core advantages Verification along the way: MIL, SIL, PIL, HIL How NXP enables this with Model-Based Design Toolbox (MBDT) What comes next in this article series 1 Why embedded development needs a better workflow Modern embedded systems are no longer isolated functions running on a single controller. In today's vehicles and intelligent machines, applications span sensing, communication, control, safety logic, diagnostics, and multiple processing nodes that must work together as one system. As this complexity grows, traditional workflows based mainly on handwritten code and late-stage hardware testing become difficult to scale, hard to validate early in the development cycle, and slow to iterate. Issues are often discovered late, when integration becomes more costly and harder to manage. Model-Based Design offers an alternative approach designed to address these challenges. It enables earlier validation and a more structured development flow, where verification is not an afterthought, but part of every stage of development. 2 What Model-Based Design is   Picture1.png Model-Based Design is a visual way of programming, where you build your functionality by drawing an engineering diagram, and that diagram can be executed—either as a simulation on your computer or as code running on real hardware. In this approach, models become the central engineering artifact used to design, simulate, verify, and deploy embedded systems. Instead of starting from low-level implementation details, engineers create an executable model of the application behavior, simulate, verify, refine it, and then generate code for the target system. This model-centric workflow makes designs easier to understand, easier to reuse, and less prone to errors. It also enables model-based testing, where test cases can be derived directly from system models and used to verify behavior early in development. 3 A simple mental model: from idea to executable model to hardware A simple way to think about Model-Based Design is this: you describe what the system should do in an executable model, validate that behavior in simulation, and then carry the same design through to the final implementation. In this approach, the model is not just documentation—it becomes an active engineering asset used for design, simulation, verification, and code generation. This creates a direct path from idea to application, where requirements, design, prototyping, testing, and deployment are connected in one continuous workflow. 4 Why engineers use it: the core advantages One of the biggest advantages of Model-Based Design is that it changes where engineering effort is spent. Instead of focusing primarily on how to implement functionality at a low level, engineers can focus on what the system should do—its behavior, control strategy, and response to real-world scenarios. This approach also enables early validation. System behavior can be simulated on a PC before the final hardware is available, allowing issues to be detected earlier and reducing costly rework late in the development cycle. In addition, Model-Based Design enables hardware-independent simulation, where algorithms can be developed and validated before being tied to a specific target platform. This allows teams to explore designs faster and reuse validated functionality across different hardware solutions. As a result, teams benefit from: faster iteration during development improved traceability between design and implementation reduced integration risk more consistent validation across development stages Ultimately, this contributes directly to faster time-to-market, as development cycles are shortened and fewer late-stage issues need to be addressed. Some concrete examples can be found in the following articles: From Virtual Vehicle to All-Electric Off-Road UTV in Less Than a Year Dyson Accelerates New Product Development with System-Level Simulation 5 Verification along the way: MIL, SIL, PIL, HIL A key strength of Model-Based Design is that validation happens continuously throughout development. This is typically organized into several stages: Model-in-the-Loop (MIL): the model is tested against a simulated environment Software-in-the-Loop (SIL): generated code is executed on the host PC and compared to model behavior Processor-in-the-Loop (PIL): code runs on the target MCU to verify functional correctness and performance Hardware-in-the-Loop (HIL): the controller is tested against a real-time or emulated system before final deployment These stages provide a structured validation path, ensuring that issues are detected early and confidence is built progressively before running on final hardware. Model-Based Design also supports reuse and scalability. A validated model can be adapted, parameterized, or reused across multiple systems, reducing development effort and improving consistency. 6 How NXP enables this with Model-Based Design Toolbox (MBDT) Picture2.png To make this workflow practical on real embedded hardware, NXP provides the Model-Based Design Toolbox (or MBDT). This acts as a bridge between the MathWorks' and NXP's software ecosystems, and allows the entire workflow to be done from one environment, as depicted in the diagram above. Concretely, this allows engineers to use MATLAB and Simulink to design, simulate, verify, and automatically generate code that can run directly on NXP microcontrollers and processors. MBDT provides: block libraries for hardware access integration with configuration tools for pins, clocks, and peripherals support for PIL workflows code generation and deployment capabilities profiling and runtime monitoring through tools like FreeMASTER This creates a complete end-to-end flow—from model to validated application running on target hardware. Engineers can explore functionality at a high level, validate behavior through simulation, and deploy with confidence onto real systems. 7 What comes next in this article series In the articles that follow, we will move from this general introduction to concrete, real application examples. We will show how Model-Based Design and NXP tools can be applied across a modern system architecture, covering applications such as battery management, motor control, radar, steering, lighting, and parking sensors. Each example will illustrate how functions can be designed, validated in simulation, and deployed onto the appropriate hardware nodes. The key idea is simple: Model-Based Design helps engineers focus on system behavior while reducing the gap between concept, implementation, and validation. With NXP's Model-Based Design Toolbox, this approach can be carried from the modeling environment all the way to a running application on hardware. MBDT  https://www.nxp.com/mbdt https://mathworks.com/nxp 

How to install .MLTBX 1 Table of Contents • Overview • Executive Summary - What is .MLTBX • Context - Where to obtain the .mltbx file • Method 1 - Manual Installation (.mltbx) • Method 2 - Install via NXP Support Package • Method 3 - Automotive Software Package Manager • Conclusion 2 Overview NXP provides a range of MATLAB ® Toolboxes distributed as .mltbx packages to support modeling, simulation, configuration, and code generation for NXP microcontrollers and processors. These toolboxes integrate directly with the MathWorks environment and enable faster development workflows by extending MATLAB/Simulink with NXP-specific blocks, drivers, and examples. The scope of this article is to guide users through the process of installing an NXP .mltbx toolbox obtained from the official NXP website. It explains the prerequisites, where to download the toolbox, and how to install and verify it within MATLAB. The instructions are intended for engineers and developers who have basic familiarity with MATLAB but may be new to installing third-party toolboxes distributed outside of MathWorks Add-Ons. By following this guide, readers will be able to correctly install the NXP toolbox, ensure it is recognized by MATLAB, and prepare their environment for subsequent development and evaluation tasks. 3 Executive Summary - What is .MLTBX An .mltbx file is a MATLAB Toolbox package used to distribute and install MATLAB or Simulink extensions. It is a self-contained archive created by MathWorks that can include functions, Simulink blocks, documentation, examples, and setup scripts. When opened in MATLAB, an .mltbx file is installed using the Add-On Manager, which automatically places the toolbox in the default add-ons folder, and registers the toolbox within the environment. This format allows third-party vendors - such as NXP - to safely deliver toolboxes outside of the MathWorks Add-On Explorer while preserving a standard installation experience. In short, a .mltbx file is the official and recommended way to package, install, update, and uninstall MATLAB toolboxes. 4 Context - Where to obtain the .mltbx file There are multiple ways to get the .mltbx file, as shown below: Manual download and install - from NXP site (.mltbx file) Installation via MATLAB - Add-Ons / toolbox flow (NXP Support Package) Installation via Automotive Software Package Manager - bundle installer All methods are valid and can be used depending on your setup and preferences. The Automotive Software Package Manager approach installs bundles and generates an installer that walks through the steps automatically. Prerequisites Before installing the toolbox, ensure the following: MATLAB is installed on your machine You have access to the toolbox download source Note: The .mltbx file cannot be used without MATLAB. The toolbox is only available for Windows and may require additional prerequisites such as: Embedded Coder MATLAB Coder Simulink Coder 5 Method 1 - Manual Installation (.mltbx) The manual installation flow is simple, once prerequisites are met. Manually download the .mltbx file from the NXP site and install it. Typical install behavior: Open MATLAB → run or double-click the .mltbx file → install → toolbox is added automatically. Installed toolboxes are placed under MATLAB Add-Ons directories and appear in the Add-On Explorer. Step 1 - Select the toolbox family As a first step, on the NXP site, select "Automotive SW - Model-Based Design Toolbox". DragosGherdan_0-1783509904113.png Step 2 - Select the target software In our example, we are selecting "Automotive SW - S32K3 Software". DragosGherdan_0-1783510040745.png Step 3 - Select the S32K3 Model-Based Design Toolbox Select "Automotive SW - S32K3 - Model-Based Design Toolbox". DragosGherdan_1-1783510068634.png Step 4 - Choose Product Information Select the Product Information: "Model-Based Design Toolbox S32K3 1.8.0". DragosGherdan_2-1783510096019.png Step 5 - Accept Software Terms and Conditions The Software Terms and Conditions will appear - select "I Agree". DragosGherdan_3-1783510116661.png Step 6 - Download the .mltbx file After the terms and conditions agreement, you can download the .mltbx file. DragosGherdan_4-1783510144884.png When downloading, save the file under the .zip extension, as shown below. DragosGherdan_5-1783510164522.png Step 7 - Reveal file extensions in Windows To see and change the file extension, follow the next steps: Press the three dots visible below: DragosGherdan_6-1783510184157.png Select "Options". Deselect "Hide extensions for known file types". DragosGherdan_7-1783510204922.png Press Apply and OK. After this update, the file will be visible with its extension. DragosGherdan_8-1783510225221.png Step 8 - Change the file extension to .mltbx Change the file extension from .zip to .mltbx : DragosGherdan_9-1783510245085.png A pop-up will appear - press "Yes": DragosGherdan_10-1783510263844.png View after changing the file from .zip to .mltbx: DragosGherdan_11-1783510283771.png Step 9 - Install the toolbox in MATLAB Double-click the .mltbx file and accept the License Agreement. DragosGherdan_12-1783510305988.png The installation process will start and it will take a few moments to be finalized. DragosGherdan_13-1783510339995.png  Installation Finalized DragosGherdan_14-1783510384722.png   DragosGherdan_16-1783510579970.png Toolbox registered in MATLAB Add-On Manager  DragosGherdan_18-1783510624509.png 6 Method 2 - Install via NXP Support Package The NXP Support Package add-on is a guided installer that: Checks and validates all installation prerequisites Directs users to the page where the required .mltbx package can be downloaded Allows users to select the .mltbx package to install Provides the option to open relevant documentation resources Step 1 - Open MATLAB Launch MATLAB. DragosGherdan_19-1783510663098.png Step 2 - Navigate to Add-Ons Go to: Add-Ons → Get Add-Ons. DragosGherdan_20-1783510707959.png DragosGherdan_21-1783510733459.png Step 3 - Install the toolbox Load the toolbox file or follow your internal download process. Note: Direct download via Add-On Explorer may not always be available, depending on licensing and setup. 7 Method 3 - Automotive Software Package Manager This method uses the Automotive Software Package Manager, which installs bundles and generates an installer that walks through the steps automatically. Step 1 - Access Package Manager Use the Automotive Software Package Manager. DragosGherdan_22-1783510765051.png Step 2 - Select required components Choose: Target platform - e.g. S32K3 Required tools - e.g. FreeMASTER, Model-Based Design Toolbox DragosGherdan_23-1783510858811.png Step 3 - Generate installer The tool generates a bundle installer. DragosGherdan_24-1783510878946.png Step 4 - Run installer Run the generated installer. Follow the step-by-step instructions. 8 Conclusion Installing an NXP .mltbx toolbox is straightforward once the MATLAB prerequisites are in place. Depending on your workflow, you can choose the manual .mltbx installation, the guided NXP Support Package, or the Automotive Software Package Manager bundle installer - all three methods produce a properly registered toolbox inside MATLAB. With the toolbox installed and verified, your environment is ready to start developing, simulating, and generating code for NXP microcontrollers and processors. Stay tuned for the next article, where we will dive into using the newly installed toolbox to build your first Model-Based Design project.

MPC5644Aコアテスト 私はMPC5644Aチップセットのコアテストを実行しようとしています。 現在私が使用している環境はEclipseとWind Riverです。 私はメーカーのライブラリであるe200Zx_ICST_RTMC_3.0.0をダウンロードしました。このライブラリには、複数のアセンブリソースファイル（.sファイル）が含まれています。 これらのうち、vleは正常にコンパイルされました。 しかし、book_eとspeはコンパイルに失敗します。 コンパイル中に、bc、bcl、bclr、xoris、bclrl、bcctrlなどの様々なアセンブリ命令でエラーが発生しました。book_e および spe アセンブリファイルのプロパティを開き、C/C++ ビルド --> 設定 --> Diab アセンブラ --> その他 --> その他のオプションとフラグに -tPPCE200Z4NEG:simple を追加したところ、コンパイルが正常に完了しました。しかし、デバッグ中に、実際にコアテストを実行する`fsl_self_test_icst.c`内の`Fsl_call_test_execution_icst`の直前に到達しました。次のステップに進むと、無限ループに陥ってしまう。 Eclipseの逆アセンブリで確認したところ、アドレス0x51518（`SPE_ICST_int_logical_test`の開始直後）にステップインすると、すぐに0x3f2b90（空き領域）にジャンプすることがわかりました。 どうすればいいですか？どこから始めたらいいのか分からない。 Re: MPC5644A core test こんにちは、 SCSTはMPC56xxファミリの以下のデバイスのみをサポートしています: MPC560xP MPC564xB-C MPC5644AとMPC564xBは同じe200z4 CPUコアを共有しているため、SCSTライブラリのCPU関連部分は互換性がある可能性があります。しかし、統合に関するあらゆる側面を検討する必要がある。 例外ベクターアドレス メモリ・マップ クロック初期化 ペリフェラル依存関係 リンカースクリプトの前提条件 実際のCPUテストアルゴリズムは、同じe200z4アーキテクチャを対象としているため、ほぼポータブルであるはずです。 NXPは、旧型MPC5644Aデバイス用の公式SCSTライブラリを提供していません。しかし、MPC5644A MPC564xBファミリと同じe200z4コアを使用しているため、デバイス固有の統合詳細を確認した後、MPC564xBソリューションからCPU特化した自己テストルーチンを適用することも可能かもしれません。あるいは、MCUの組み込み安全機構(ECC、CRC、ウォッチドッグ、MPU、例外処理)を用いて、プロジェクト固有の機能安全要件を満たすカスタム起動診断実装を開発することも可能です。 どうすればいいですか？どこから始めたらいいのか分からない。 コードが0x51518でSPE_ICST_int_logical_test()に入り、すぐに空のメモリと思われる0x3F2B90に分岐する場合、私の最初の疑いはCPUの故障ではなく、リンカ/ライブラリの統合の問題です。 SCSTライブラリの場合、これは通常、以下のいずれかを意味します。 1. 関数ポインタまたは分岐テーブルが正しくリンクされていません 2. ライブラリオブジェクトが見つかりません 3. メモリモデルの誤り/VLEの不一致 4. 別のデバイス用に構築されたSCSTライブラリ 5. MMU/TLB変換の問題 よろしくお願いいたします。 ピーター

複数の*IPアドレスを1つのイーサネットインターフェースにマッピングする(LWIP) こんにちは、 複数のIPアドレスを1つのイーサネットポートに異なるstruct netif論理インターフェースでバインドしようとしています。現在の実装では、動作させるために1つのインターフェースを無効にしています。 適切なアプローチに関するガイダンスや情報源を求めている。どんなご意見でも歓迎いたします。 ありがとうございます int main ( void ) { struct netif netif1 , netif2 ; 整数ret ; ip4_addr_t netif1_ipaddr 、 netif1_netmask 、 netif1_gw ; ip4_addr_t netif2_ipaddr 、 netif2_netmask 、 netif2_gw ; ethernetif_config_t enet_config = { . phyHandle = & phyHandle , . phyAddr = EXAMPLE_PHY_ADDRESS 、 . phyOps = EXAMPLE_PHY_OPS 、 . phyResource = EXAMPLE_PHY_RESOURCE 、 } ; BOARD_ConfigMPU () ; BOARD_InitPins () ; BOARD_BootClockRUN () ; BOARD_InitDebugConsole () ; BOARD_InitModuleClock () ; SCB_DisableDCache () ; IOMUXC_SelectENETClock () ; BOARD_InitBothEnetPins_test () ; BOARD_ENET_PHY1_RESET ; EnableIRQ ( ENET_1G_MAC0_Tx_Rx_1_IRQn ) ; EnableIRQ ( ENET_1G_MAC0_Tx_Rx_2_IRQn ) ; MDIO_Init () ; g_phy_resource.read = MDIO_Read ;​​ g_phy_resource.write = MDIO_Write ;​​ time_init () ; CRYPTO_InitHardware () ; lwip_init () ; 最初の論理インターフェースとそのIP構成を追加する IP4_ADDR ( & netif1_ipaddr , 192 , 168 , 0 , 102 ) ; IP4_ADDR ( & netif1_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR ( & netif1_gw , 192 , 168 , 0 , 100 ) ; netif_add ( & netif1 , & netif1_ipaddr , & netif1_netmask , & netif1_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_default ( & netif1 ) ; netif_set_up ( & netif1 ) ; 2つ目の論理インターフェースとそのIP構成を追加する IP4_ADDR ( & netif2_ipaddr , 192 , 168 , 0 , 111 ) ; IP4_ADDR ( & netif2_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR ( & netif2_gw , 192 , 168 , 0 , 100 ) ; netif_add ( & netif2 , & netif2_ipaddr , & netif2_netmask , & netif2_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_up ( & netif2 ) ; while ( 1 ) { // 両方のnetifから受信フレームをポーリングする ethernetif_input ( & netif1 ) ; ethernetif_input ( & netif2 ) ; sys_check_timeouts () ; // すべてのコアプロトコルのすべてのシステムタイムアウトを処理します } -1を返す; } Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) LWIPで複数のIPアドレスを単一のイーサネットインターフェースにマッピングすることは、異なるネットワーク識別子やサービスを1つの物理接続で扱う必要があるシステムで有用です。重要なのは、IP設定、ルーティング、ARP処理が適切に管理され、各アドレスが競合なく正しく応答することです。組み込みネットワークソリューションを設計する際には、利用可能なハードウェアオプションや、柔軟なネットワーク構成と信頼性の高い通信をサポートする Explore Networking Products を理解することも役立ちます。異なるネットワークシナリオでの適切なテストは、パケット処理やインターフェース設定に関連する問題を特定するのに役立ちます。 Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) こんにちは。問題を投稿されてからかなり時間が経ちましたが、何か解決策は見つかりましたか？ 現在、TI TMS570LC43 LaunchPadとlwIP 1.4.1バージョンを使用して同じことを試しています。

Gui_Guider在生成C code时会出现卡死的情况 在导入字体文件后生成C代码会出现一直生成的情况，我将页面缩减成一个，去除图标生成一个简单的界面也会一直卡在Generating C code的情况。 Re: Gui_Guider在生成C code时会出现卡死的情况 我发现原因就是我直接在Gui_Guider里导入一个新的字体然后Generating C code就会出现卡死，我如何解决这个问题？ 回复： Gui_Guider在生成C code时会出现卡死的情况 嗨@vettle 请问您导入的是什么字体？ 如果更改字体，还会出现这个问题吗？ BR 哈里

将多个 IP 地址映射到一个以太网接口（LWIP） 你好， 我正在尝试使用不同的 struct netif 逻辑接口将多个 IP 地址绑定到单个以太网端口。我目前的实现方法是禁用其中一个接口才能使其正常工作。 寻求有关正确方法的指导或资源。任何见解都非常感谢。 谢谢！ int main ( void ) { struct netif netif1 , netif2 ; int ret ； ip4_addr_t netif1_ipaddr 、 netif1_netmask 、 netif1_gw ； ip4_addr_t netif2_ipaddr 、 netif2_netmask 、 netif2_gw ； ethernetif_config_t enet_config = { . phyHandle = & phyHandle , .phyAddr = EXAMPLE_PHY_ADDRESS ，​ .phyOps = EXAMPLE_PHY_OPS ，​ .phyResource = EXAMPLE_PHY_RESOURCE ，​ } ； BOARD_ConfigMPU () ; BOARD_InitPins () ; BOARD_BootClockRUN () ; BOARD_InitDebugConsole () ; BOARD_InitModuleClock () ; SCB_DisableDCache () ; IOMUXC_SelectENETClock () ; BOARD_InitBothEnetPins_test () ; BOARD_ENET_PHY1_RESET ； 启用IRQ （ ENET_1G_MAC0_Tx_Rx_1_IRQn ） ； 启用IRQ （ ENET_1G_MAC0_Tx_Rx_2_IRQn ） ； MDIO_Init () ; g_phy_resource.read = MDIO_Read ;​​ g_phy_resource.write = MDIO_Write ;​​ time_init () ; CRYPTO_InitHardware () ; lwip_init () ; // 添加第一个逻辑接口及其 IP 配置 IP4_ADDR （ & netif1_ipaddr ， 192，168，0，102 ） ；​​​​​​ IP4_ADDR ( & netif1_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR （ & netif1_gw ， 192，168，0，100 ） ；​​​​​​ netif_add ( & netif1 , & netif1_ipaddr , & netif1_netmask , & netif1_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_default ( & netif1 ) ; netif_set_up ( & netif1 ) ; // 添加第二个逻辑接口及其 IP 配置 IP4_ADDR （ & netif2_ipaddr ， 192，168，0，111 ） ；​​​​​​ IP4_ADDR ( & netif2_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR （ & netif2_gw ， 192，168，0，100 ） ；​​​​​​ netif_add ( & netif2 , & netif2_ipaddr , & netif2_netmask , & netif2_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_up ( & netif2 ) ; while ( 1 ) { // 轮询两个网络接口以获取传入帧 ethernetif_input （ & netif1 ） ； ethernetif_input （ & netif2 ） ； sys_check_timeouts () ; // 处理所有核心协议的系统超时 } 返回-1 ； } Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) 在 LWIP 中，将多个 IP 地址映射到单个以太网接口，对于需要通过一个物理连接处理不同网络身份或服务的系统来说非常有用。关键在于确保 IP 配置、路由和 ARP 处理得到正确管理，以便每个地址都能正确响应而不会发生冲突。在设计嵌入式网络解决方案时，了解可用的硬件选项并探索支持灵活网络设置和可靠通信的网络产品也很有帮助。使用不同的网络场景进行适当的测试有助于发现与数据包处理和接口配置相关的问题。 Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) 您好，您发布这个问题已经有一段时间了，请问您找到解决方法了吗？ 我目前正在使用TI TMS570LC43 Launchpad和lwIP 1.4.1版本尝试同样的操作。

RT1064 : pin configuration to boot from internal flash Hello, This may sound as a dumb/noob question but I can't determine precisely what must be done on the BOOT_MODE1/BOOT_MODE0 and BT_CFG[11..0] pins to configure the RT1064 to boot from its internal flash memory. Table 9.9 from the reference manual lists only 3 boot sources (NOR flash via FlexSPI, SDCARD and eMMC) but the internal flash is not listed, as if this section has been copied/pasted from RT1060... AN12290 mentions a FlexSPI2 internal bus to this internal flash but does not indicate how to select it over the 3 above-mentionned boot sources. Table 5 from the MIMXRT1060/1064 Evaluation Kit Board Hardware User's Guide indicates that 2 boot modes only are availble (QSPI or SDCARD) and also claims that QSPI boot is not available (note from 2.7 paragraph), leaving SDCARD as the sole boot source... Any help greatly appreciated i.MXRT 106x Re: RT1064 : pin configuration to boot from internal flash Hi @batmat, As mentioned in AN12290, on the MIMXRT1064 it is only possible to boot from FlexSPI2, which is dedicated to the internal QSPI flash. You can still connect the external flash through the FlexSPI1 interface, which can be used to save data or other functions except booting. This is why, Table 9.9 from the reference manual lists only 3 boot sources, NOR flash via FlexSPI, SDCARD or eMMC; NOR flash via FlexSPI2 is the only available FlexSPI for booting, and its already routed to the onboard flash by default. In order to be able to boot from the internal QSPI flash, the boot device switch (SW7) settings should be: SW7-1 OFF, SW7-2 OFF, SW7-3 ON, SW7-4 OFF. BOOT_CFG1[7:4] pins, must be set to 0, to select the Serial NOR boot via FlexSPI as the boot device. And BOOT_CFG2[2:0] pins must be also set to 0, so the internal QSPI Flash is selected. The MIMXRT1064-EVK has these pin settings by default. BR, Edwin. Re: RT1064 : pin configuration to boot from internal flash Hello Edwin, Makes sense indeed. I was confused as both the external flash and the internal are QSPI ones, hard to determine which is which. I'd suggest a documentation evolution for table 9.9 for RT1064. Instead of "NOR flash via FlexSPI" it should be mentionned "Internal NOR flash via internal FlexSPI2" and also adding that "Boot from external NOR flash via FlexSPI is not available on RT1064" This would avoid confusion I think. Again, thanks for your excellent and prompt support.

mapping multiple * IP addresses to one Ethernet interface (LWIP) Hello, I'm attempting to bind multiple IP addresses to a single Ethernet port using different struct netif logical interfaces. My current implementation involves disabling one interface for it to work. Seeking guidance or resources on the correct approach. Any insights appreciated. Thanks, int main(void) { struct netif netif1, netif2; int ret; ip4_addr_t netif1_ipaddr, netif1_netmask, netif1_gw; ip4_addr_t netif2_ipaddr, netif2_netmask, netif2_gw; ethernetif_config_t enet_config = {.phyHandle = &phyHandle, .phyAddr = EXAMPLE_PHY_ADDRESS, .phyOps = EXAMPLE_PHY_OPS, .phyResource = EXAMPLE_PHY_RESOURCE, }; BOARD_ConfigMPU(); BOARD_InitPins(); BOARD_BootClockRUN(); BOARD_InitDebugConsole(); BOARD_InitModuleClock(); SCB_DisableDCache(); IOMUXC_SelectENETClock(); BOARD_InitBothEnetPins_test(); BOARD_ENET_PHY1_RESET; EnableIRQ(ENET_1G_MAC0_Tx_Rx_1_IRQn); EnableIRQ(ENET_1G_MAC0_Tx_Rx_2_IRQn); MDIO_Init(); g_phy_resource.read = MDIO_Read; g_phy_resource.write = MDIO_Write; time_init(); CRYPTO_InitHardware(); lwip_init(); // Add the first logical interface with its IP configuration IP4_ADDR(&netif1_ipaddr, 192, 168, 0, 102); IP4_ADDR(&netif1_netmask, 255, 255, 255, 0); IP4_ADDR(&netif1_gw, 192, 168, 0, 100); netif_add(&netif1, &netif1_ipaddr, &netif1_netmask, &netif1_gw, &enet_config, EXAMPLE_NETIF_INIT_FN, ethernet_input); netif_set_default(&netif1); netif_set_up(&netif1); // Add the second logical interface with its IP configuration IP4_ADDR(&netif2_ipaddr, 192, 168, 0, 111); IP4_ADDR(&netif2_netmask, 255, 255, 255, 0); IP4_ADDR(&netif2_gw, 192, 168, 0, 100); netif_add(&netif2, &netif2_ipaddr, &netif2_netmask, &netif2_gw, &enet_config, EXAMPLE_NETIF_INIT_FN, ethernet_input); netif_set_up(&netif2); while (1) { // Poll both netifs for incoming frames ethernetif_input(&netif1); ethernetif_input(&netif2); sys_check_timeouts(); // Handle all system timeouts for all core protocols } return -1; } Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) Mapping multiple IP addresses to a single Ethernet interface in LWIP can be useful in systems that need to handle different network identities or services through one physical connection. The key is ensuring the IP configuration, routing, and ARP handling are properly managed so each address responds correctly without conflicts. When designing embedded networking solutions, it also helps to understand the available hardware options and Explore Networking Products that support flexible network setups and reliable communication. Proper testing with different network scenarios can help identify issues related to packet handling and interface configuration. Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) Hello, It's been quite some time since you posted the issue but did had any luck figuring this out?  I am currently trying the same thing with a TI TMS570LC43 launchpad and lwIP 1.4.1 version

RT1064:内部フラッシュから起動するためのピン構成 こんにちは、 これは初心者や初心者の質問に聞こえるかもしれませんが、RT1064を内蔵フラッシュメモリから起動させるためにBOOT_MODE1/BOOT_MODE0とBT_CFG[11..0]ピンで何をすべきか正確にはわかりません。 参考マニュアルの表9.9には、3つのブートソース(FlexSPI経由のNORフラッシュ、SDCARD、eMMC)のみが記載されていますが、内部フラッシュは記載されていません。まるでこのセクションがRT1060からコピー&ペーストされたかのようです... AN12290はこの内部フラッシュへのFlexSPI2内部バスについて言及していますが、上記の3つの起動ソースで選択する方法は示していません。 MIMXRT1060/1064 Evaluation Kit Board Hardware ユーザーガイドの表5では、起動モードはQSPIかSDCARDの2種類のみが利用可能であり、QSPIブートは利用できないと主張しています(2.7段落からの注釈)、SDカードのみが唯一の起動源となっています... どんなご支援でも大変ありがたく思います。 i.MXRT 106x Re: RT1064 : pin configuration to boot from internal flash こんにちは、 @batmat さん。 AN12290で述べたように、MIMXRT1064では、内部QSPIフラッシュ専用のFlexSPI2からのみブートが可能です。外部フラッシュはFlexSPI1インターフェース経由で接続でき、起動以外のデータ保存やその他の機能に使えます。このため、リファレンス・マニュアルの表9.9には、3つのブートソースのみが記載されています。NORフラッシュ(FlexSPI、SDCARD、またはeMMC)、FlexSPI2経由のNORフラッシュが起動時に唯一利用可能なFlexSPIで、デフォルトでオンボードフラッシュにルーティングされています。 内部QSPIフラッシュから起動するためには、ブートデバイススイッチ(SW7)の設定は以下の通りであるべきです。 SW7-1 オフ、SW7-2 オフ、SW7-3 オン、SW7-4 オフ。 ブートデバイスとしてFlexSPI経由のシリアルNORブートを選択するには、BOOT_CFG1[7:4]ピンを0に設定する必要があります。また、BOOT_CFG2[2:0]ピンも0に設定しなければならず、内部のQSPIフラッシュが選択されます。MIMXRT1064-EVKは、デフォルトで以下のピン設定になっています。 BR、 エドウィン。 Re: RT1064 : pin configuration to boot from internal flash こんにちは、エドウィンさん。 確かにその通りだ。外部フラッシュと内部フラッシュの両方がQSPI対応なので、どちらがどちらなのか判別しづらくて混乱しました。 RT1064の表9.9のドキュメント進化を提案します。 「FlexSPIを経由したNORフラッシュ」ではなく、「FlexSPI2を経由した内部NORフラッシュ」と記載し、「FlexSPIを経由した外部NORフラッシュからの起動はRT1064では利用できません」と付け加えるべきです。 こうすれば混乱を避けられると思う。 改めて、素晴らしく迅速なサポートに感謝します。

MPC5644A core test I am attempting to perform a core test on the MPC5644A chipset. My current environment is Eclipse and Wind River. I downloaded the manufacturer's library, e200Zx_ICST_RTMC_3.0.0, which contains several assembly source (.s) files. Of these, vle compiles successfully. However, book_e and spe fail to compile. During compilation, errors occurred in various assembly instructions such as bc, bcl, bclr, xoris, bclrl, and bcctrl. I opened the properties of the book_e and spe assembly files and added -tPPCE200Z4NEG:simple to C/C++ Build --> Settings --> Diab Assembler --> Other --> Other options and flags, and successfully completed the compilation. However, during the debugging process, I reach just before `Fsl_call_test_execution_icst` in `fsl_self_test_icst.c`, which actually executes the core test. If I proceed to the next step, I fall into an infinite loop. Checking with Eclipse's disassembly, I found that when I step into address 0x51518 (immediately after the start of `SPE_ICST_int_logical_test`), it jumps immediately to 0x3f2b90 (an empty space). What should I do? I don't know where to start. Re: MPC5644A core test Hello, SCST supports only following devices from MPC56xx family: MPC560xP MPC564xB-C Since MPC5644A and MPC564xB share the same e200z4 CPU core, the CPU-focused portions of an SCST library may be adaptable. However, all integration aspects must be reviewed: Exception vector addresses Memory maps Clock initialization Peripheral dependencies Linker script assumptions The actual CPU test algorithms should be largely portable because they target the same e200z4 architecture. NXP does not provide an official SCST library for the legacy MPC5644A device. However, since MPC5644A uses the same e200z4 core as the MPC564xB family, it may be possible to adapt CPU-focused self-test routines from MPC564xB solutions after reviewing device-specific integration details. Alternatively, a custom startup diagnostic implementation can be developed using the MCU's built-in safety mechanisms (ECC, CRC, watchdog, MPU, exception handling) to satisfy project-specific functional safety requirements. What should I do? I don't know where to start. If the code enters SPE_ICST_int_logical_test() at 0x51518 and then immediately branches to 0x3F2B90, which appears to be empty memory, my first suspicion would not be a CPU failure but rather a linker / library integration issue. For an SCST library, this usually means one of the following: 1. Function pointer or branch table not linked correctly 2. Missing library object 3. Wrong memory model / VLE mismatch 4. SCST library built for another device 5. MMU/TLB translation issue best regards, Peter

S32K3引导加载程序和HSE - 最佳实践？ 您好，NXP团队： 我们正在 S32K312 上实施一个强大的 OTA 更新架构，采用 HSE 全块 A/B 交换。 我们的目标架构是： - S32K312，2 MB PFlash 分为两个 1 MB 物理块。 - HSE AB_SWAP 通过被动块激活服务使用。 - 通过 Modbus/串口接收 OTA 数据包。 - 引导加载程序将签名映像加载到被动 PFlash 块中。 - HSE 验证被动图像/SMR。 - 引导加载程序请求 AP_SWAP。 - RESET后，新更换的银行暂时启动。 - 确认命令可使交换永久生效；否则设备将回滚。 最初我们尝试将一个全局引导加载程序放在 DFlash 中，位于两个 PFlash 存储区之外。该引导加载程序将接收 OTA，对被动 PFlash 存储进行编程，请求 HSE AP_SWAP，然后继续管理确认/回滚。 我们采用这种方法遇到了架构和运行时复杂性方面的问题： 1. HSE AB_SWAP 似乎在完整的 PFlash 块边界上进行操作，而不是在任意应用程序分区上进行操作。 2. 单个 DFlash 引导加载程序位于已交换/已验证的银行映像之外。 3. 交换后，活动的 PFlash 存储体仍然需要有效的启动/IVT/RESET 结构。 4. 当 DFlash 也参与引导加载程序运行时/记录处理时，我们遇到了执行方面的困难。 5.目前还不清楚全局 DFlash 引导加载程序是否与干净的全库 HSE AB_SWAP 生产设计兼容。 因此，我们暂时改用复制的PFlash引导加载程序模式： - 每个 1 MB PFlash 存储区包含自己的 IVT + 引导加载程序 + 应用程序。 - 引导加载程序在每个存储体的底部都有一个预留插槽。 应用程序在引导加载程序槽之后启动。 - 已签名的 OTA 镜像是一个完整的银行镜像，包含引导加载程序和应用程序。 - 在 HSE AB_SWAP 之后，新激活的银行是独立的，可以启动。 对于 HSE 全模块 A/B 更换来说，这似乎要干净得多，但我希望确认其预期/生产安全的方法。这样做并不理想，因为它在一定程度上违背了工厂引导加载程序的初衷。 问题： 1.对于 S32K312 HSE AB_SWAP，在交换后的 PFlash 存储体之外，单个全局 DFlash 驻留引导加载程序是否是一种受支持/推荐的架构？ 2. 或者 HSE AB_SWAP 是否有效地要求/建议每个被交换的 PFlash 块都是可独立启动的，具有自己的 IVT/引导加载程序/RESET 路径？ 3.如果可以使用 DFlash 引导加载程序，那么交换后的引导流程应该如何构建，才能仍然满足 SBAF/HSE 引导预期？ 4. NXP 是否有任何参考示例展示了 DFlash 引导加载程序如何在 S32K3 上管理全块 HSE AB_SWAP？ 5.对于具有回滚/确认语义的生产 OTA，重复的 PFlash 引导加载程序模型是否是更安全的预期设计？ 我们已经看到，通过修改链接器脚本可以将代码和 IVT 链接到 DFlash 中（我们也尝试过），但我们的问题具体是，在使用 HSE 全块 A/B 交换和安全启动/SMR 验证时，这样做是否合适。 谢谢！ Re: S32K3 bootloader and HSE - best practice ? 嗨@coratron 1.对于 S32K312 HSE AB_SWAP，在交换后的 PFlash 存储体之外，单个全局 DFlash 驻留引导加载程序是否是一种受支持/推荐的架构？ 从硬件角度来看，没有任何限制。两种选择都是可行的。如果数据闪存的容量足够大，并且您不打算将其用于存储数据，则可以将引导加载程序放置在数据闪存中。如果您需要将数据闪存用于其他用途，那么在两个分区中分别保存两份引导加载程序副本是一种常见的做法。 2. 或者 HSE AB_SWAP 是否有效地要求/建议每个被交换的 PFlash 块都是可独立启动的，具有自己的 IVT/引导加载程序/RESET 路径？ 不，没有这样的要求。只需在数据闪存（引导加载程序的 IVT）中具有有效的 IVT 即可。通常的做法是，RESET后总是启动引导加载程序，然后引导加载程序跳转到用户应用程序。 3. 如果可以使用 DFlash 引导加载程序，那么交换后的引导流程应该如何构建，才能仍然满足 SBAF/HSE 引导预期？ SBAF 或 HSE 没有提出任何具体要求。启动引导加载程序后，它可以决定是跳转到应用程序，还是下载新应用程序，或者执行回滚等操作，然后它应该重置设备（在回滚/交换的情况下）或跳转到应用程序。 4. NXP 是否有任何参考示例展示了 DFlash 引导加载程序如何在 S32K3 上管理全块 HSE AB_SWAP？ 我们没有这样的例子。 5. 对于具有回滚/确认语义的生产 OTA，复制的 PFlash 引导加载程序模型是否是更安全的预期设计？ 我不认为这两种方法在安全性方面有任何绝对优势。特定架构的适用性取决于整体系统设计、网络安全要求、OTA 工作流程和回滚策略。这两个概念都可以在稳健的生产解决方案中得到实现。 问候， 卢卡斯 Re: S32K3 bootloader and HSE - best practice ? 感谢你的及时回复@lukaszadrapa 。这澄清了问题，并提供了很大的帮助——我们已经能够重新评估 DFlash 中的引导加载程序实现，并且取得了成功。 该团队已经习惯了其他供应商的文档/可访问性，发现 NXP 虽然是汽车应用领域的领导者，但与它们相比，NXP 的文档却出奇地令人困惑。 您的及时反馈弥补了这些不足，再次感谢您的帮助——非常感激。我会将您的回复标记为解决方案，并向您的团队提供以下反馈： - 如果能提供 Dflash 引导加载程序 + HSE 演示，就能节省时间（包括您的时间）。我相信这对于使用 AB_SWAP 的人来说是自然而然的设置。 - NXP 应该统一并整理文档和软件栈（长期来看） - 兼容性/版本分散，没有统一的信息来源，导致混乱。 问候

RT1064：引脚配置，用于从内部闪存启动 你好， 这可能听起来像个愚蠢/新手问题，但我无法确定必须对 BOOT_MODE1/BOOT_MODE0 和 BT_CFG[11..0] 引脚进行哪些操作才能将 RT1064 配置为从其内部闪存启动。 参考手册中的表 9.9 只列出了 3 种启动源（通过 FlexSPI 的 NOR 闪存、SD 卡和 eMMC），但没有列出内部闪存，就好像这部分内容是从 RT1060 复制粘贴过来的一样…… AN12290 提到了 FlexSPI2 内部总线到此内部闪存，但没有说明如何从上述 3 个启动源中选择它。 MIMXRT1060/1064 评估套件板硬件用户指南中的表 5 指出，只有两种启动模式可用（QSPI 或 SD 卡），并且还声称不支持 QSPI 启动（参见 2.7 段），因此 SD 卡是唯一的启动源…… 非常感谢您的帮助！ i.MX RT106x Re: RT1064 : pin configuration to boot from internal flash 嗨@batmat ， 如 AN12290 中所述，MIMXRT1064 只能从 FlexSPI2 启动，FlexSPI2 专用于内部 QSPI 闪存。您仍然可以通过 FlexSPI1 接口连接外部闪存，该接口可用于保存数据或其他功能，但不能用于启动。这就是为什么参考手册中的表 9.9 只列出了 3 个启动源，即通过 FlexSPI 的 NOR 闪存、SDCARD 或 eMMC；通过 FlexSPI2 的 NOR 闪存是唯一可用于启动的 FlexSPI，并且默认情况下它已经路由到板载闪存。 为了能够从内部 QSPI 闪存启动，引导设备开关 (SW7) 设置应为： SW7-1 关闭，SW7-2 关闭，SW7-3 打开，SW7-4 关闭。 BOOT_CFG1[7:4] 引脚必须设置为 0，才能选择通过 FlexSPI 的串行 或非 启动作为引导设备。同时，BOOT_CFG2[2:0]引脚也必须设置为0，以便选择内部QSPI Flash。MIMXRT1064-EVK 默认具有这些引脚设置。 BR， 埃德温。 Re: RT1064 : pin configuration to boot from internal flash 你好，埃德温， 确实有道理。我感到很困惑，因为外部闪存和内部闪存都是 QSPI 接口的，很难确定哪个是哪个。 我建议对 RT1064 的表 9.9 进行文档改进。 应该将“通过 FlexSPI 启动 NOR 闪存”改为“通过内部 FlexSPI2 启动内部 NOR 闪存”，并补充说明“RT1064 不支持通过 FlexSPI 从外部 NOR 闪存启动”。 我认为这样可以避免混淆。 再次感谢您提供的出色且及时的支持。

S32K3 bootloader and HSE - best practice ? Hi NXP team, We are implementing a robust OTA update architecture on an S32K312 using HSE full-block A/B swap. Our target architecture is: - S32K312 with 2 MB PFlash split into two 1 MB physical blocks. - HSE AB_SWAP is used via the passive-block activation service. - OTA package is received over Modbus/serial. - Bootloader stages the signed image into the passive PFlash block. - HSE verifies the passive image/SMR. - Bootloader requests AP_SWAP. - After reset, the newly swapped bank boots provisionally. - A confirm command makes the swap permanent; otherwise the device rolls back. Originally we tried to keep one global bootloader in DFlash, outside the two PFlash banks. That bootloader would receive OTA, program the passive PFlash bank, request HSE AP_SWAP, and then continue to manage confirm/rollback. We ran into architectural and runtime complexity with that approach: 1. HSE AB_SWAP appears to operate on full PFlash block boundaries, not arbitrary app partitions. 2. A single DFlash bootloader is outside the swapped/authenticated bank image. 3. The active PFlash bank still needs valid boot/IVT/reset structure after swap. 4. We had difficult execution hazards when DFlash was also involved in bootloader runtime/record handling. 5. It became unclear whether a global DFlash bootloader is compatible with a clean full-bank HSE AB_SWAP production design. We therefore moved to a duplicated PFlash bootloader mode for now: - Each 1 MB PFlash bank contains its own IVT + bootloader + application. - The bootloader has a reserved slot at the base of each bank. - The application starts after the bootloader slot. - The signed OTA image is a full bank image containing bootloader + application. - After HSE AB_SWAP, the newly active bank is self-contained and bootable. This appears much cleaner for HSE full-block A/B swap, but I would like to confirm the intended/production-safe approach. This is suboptimal as it partially defeats the purpose of a factory bootloader. Questions: 1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture? 2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path? 3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met? 4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3? 5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design? We have seen that code and IVT can be linked into DFlash by modifying the linker script (and we tried that), but our question is specifically about whether that is appropriate when using HSE full-block A/B swap and secure boot/SMR verification. Thank you. Re: S32K3 bootloader and HSE - best practice ? Hi @coratron  1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture? There are no limitations from HW point of view. Both options are possible. If the size of data flash is sufficient and you do not plan to use it for your data, the bootloader can be placed in the data flash. If you need data flash for other purposes then having two copies of the bootloader in both partitions is common practice. 2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path? No, there’s no such requirement. It is sufficient to have valid IVT only in data flash (bootloader’s IVT). Common practice is that bootloader is always started after reset and then then the bootloader jumps to user application. 3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met? There are no specific requirements coming from SBAF or HSE. Once bootloader is started, it can decide if it should jump to application or if it should download new application or if it should do rollback, etc. and then it should reset the device (in case of rollback/swap) or jump to the application. 4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3? We don’t have such example. 5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design? I would not classify either approach as universally safer. The suitability of a particular architecture depends on the overall system design, security requirements, OTA workflow and rollback strategy. Both concepts can be implemented in a robust production solution. Regards, Lukas Re: S32K3 bootloader and HSE - best practice ? Thanks for your prompt reply @lukaszadrapa . That clarifies and helps substantially - we have been able to re-evaluate our bootloader implementation in DFlash and were successful. The team is used to the documentation / accessibility from other vendors and finds NXP to be surprisingly confusing compared to them despite being a leader in automotive applications. Your prompt feedback makes up for these gaps, so thanks again for your help - much appreciated. I will mark your reply as the solution, with the following feedback directed at your team: - A Dflash bootloader + HSE demo would have been great to save time (yours included). I am sure this is the natural setup for people that use AB_SWAP. - NXP should unify and get the documentation and software stack organised (long term) - compatibility / versions are scattered, there is no one source of information which leads to confusion. Regards 

S32K3ブートローダーとHSE - ベストプラクティスとは？ こんにちは、NXPチームの皆様、 当社は、HSEのフルブロックA/Bスワップを使用して、S32K312上で堅牢なOTAアップデートアーキテクチャを実装しています。 我々の目標とするアーキテクチャは以下のとおりです。 - S32K312は、2MBのPFlashを2つの1MBの物理ブロックに分割して搭載しています。 - HSE AB_SWAPは、パッシブブロックのアクティベーションサービスを介して使用されます。 - OTAパッケージはModbus/シリアル経由で受信されます。 - ブートローダーは署名付きイメージをパッシブPFlashブロックに段階化します。 - HSEは受動イメージ/SMRを検証します。 - ブートローダーがAP_SWAPを要求します。 リセット後、新しく交換されたバンクは暫定的に起動します。 確認コマンドを実行すると、スワップが永続的に適用されます。そうでない場合は、デバイスはロールバックされます。 当初は、2つのPFlashバンクとは別に、DFlashに1つのグローバルブートローダーを配置しようと試みました。そのブートローダーはOTAを受信し、パッシブPFlashバンクをプログラムし、HSE AP_SWAPを要求し、その後、確認/ロールバックの管理を継続します。 そのアプローチでは、アーキテクチャと実行時の複雑さという問題に直面しました。 1. HSE AB_SWAP は、任意のアプリケーション パーティションではなく、PFlash ブロックの境界全体で動作するようです。 2. 単一のDFlashブートローダーは、スワップ/認証済みバンクイメージの外にあります。 3. アクティブなPFlashバンクは、スワップ後も有効なブート/IVT/リセット構造を必要とします。 4. DFlashがブートローダーの実行時/レコード処理にも関与していた場合、実行時に重大なハザードが発生しました。 5.グローバルDFlashブートローダーがクリーンなフルバンクのHSE AB_SWAP生産設計と互換性があるかどうかは不明瞭になりました。 そのため、当面はPFlashブートローダーを複製したモードに移行しました。 - 各1MBのPFlashバンクには独自のIVT + ブートローダー+アプリケーションが含まれています。 - ブートローダーは、各バンクの底部に予約済みのスロットを持っています。 - アプリケーションはブートローダースロットの後に起動します。 - 署名付きOTAイメージは、ブートローダー+アプリケーションを含むフルバンクイメージです。 - HSE AB_SWAP実行後、新たにアクティブになったバンクは自己完結型でブート可能です。 HSEのフルブロックA/Bスワップには、この方法の方がはるかにクリーンに見えますが、意図された、かつ生産上安全な方法であることを確認したいと思います。これは、工場出荷時のブートローダーの目的を部分的に損なうため、最適とは言えません。 質問: 1.S32K312 HSE AB_SWAPの場合、スワップされたPFlashバンクの外に単一のグローバルDFlash常駐ブートローダーを配置するアーキテクチャは、サポート/推奨されていますか？ 2. あるいは、HSE AB_SWAPは、交換された各PFlashブロックが、独自のIVT/ブートローダー/リセットパスを持ち、独立してブート可能であることを実質的に要求/推奨しているのでしょうか？ 3.もしDFlashブートローダーが可能なら、SBAF/HSEブートの期待に応えられるように、スワップ後のブートフローはどのように構成すべきでしょうか? 4. S32K3上でDFlashブートローダーがフルブロックHSE AB_SWAPを管理することを示したNXPの参考例はありますか? 5.ロールバックや確認セマンティクスを持つ本番OTAの場合、複製されたPFlashブートローダーモデルの方が安全な設計でしょうか? コードとIVTをリンカースクリプトを改変することでDFlashにリンクできるという話は見ており(私たちも試しました)、しかし私たちの質問は、HSEのフルブロックA/Bスワップやセキュアブート/SMR検証を使う場合にそれが適切かどうかについてです。 よろしくお願いします。 Re: S32K3 bootloader and HSE - best practice ? こんにちは、 @coratron さん。 1.S32K312 HSE AB_SWAPの場合、スワップされたPFlashバンクの外に単一のグローバルDFlash常駐ブートローダーを配置するアーキテクチャは、サポート/推奨されていますか？ ハードウェアの観点からは、何の制限もありません。どちらの選択肢も可能である。データフラッシュのサイズが十分で、データに使う予定がない場合は、ブートローダーをデータフラッシュに配置できます。データフラッシュを他の用途で使用する必要がある場合は、両方のパーティションにブートローダーのコピーを2つずつ用意するのが一般的な方法です。 2. あるいは、HSE AB_SWAPは、交換された各PFlashブロックが、独自のIVT/ブートローダー/リセットパスを持ち、独立してブート可能であることを実質的に要求/推奨しているのでしょうか？ いいえ、そのような要件はありません。データフラッシュ（ブートローダーのIVT）に有効なIVTがあれば十分です。一般的な慣習としては、リセット後にブートローダーが起動され、その後ブートローダーがユーザーアプリケーションにジャンプします。 3. もしDFlashブートローダーが可能なら、SBAF/HSEのブート期待を満たすように、スワップ後のブートフローはどのように構成すべきか? SBAFまたはHSEからの具体的な要件はありません。ブートローダーが起動すると、アプリケーションにジャンプするか、新しいアプリケーションをダウンロードするか、ロールバックを行うかなどを判断し、その後(ロールバックやスワップの場合に)デバイスをリセットするか、アプリケーションにジャンプします。 4. S32K3上でフルブロックHSE AB_SWAPを管理するDFlashブートローダーを示すNXPのリファレンスサンプルはありますか？ そのような例はありません。 5. ロールバック/確認セマンティクスを持つ本番OTAの場合、複製されたPFlashブートローダーモデルは意図された設計の方が安全なのでしょうか? どちらの方法も、普遍的に安全だと断言することはできません。特定のアーキテクチャの適性は、全体のシステム設計、セキュリティ要件、OTAワークフロー、ロールバック戦略に依存します。両概念は堅牢な本番環境で実装可能です。 よろしくお願いいたします。 ルーカス Re: S32K3 bootloader and HSE - best practice ? @lukaszadrapa さん、迅速なご返信ありがとうございます。これにより状況が明確になり、大いに役立ちました。DFlashにおけるブートローダーの実装を再評価することができ、成功しました。 チームは他のベンダーのドキュメントやアクセス性に慣れており、オートモーティブ アプリケーションのリーダーであるにもかかわらず、NXPは意外にも分かりにくいと感じています。 あなたの迅速なフィードバックがこれらの穴を補っています。改めてご助言ありがとうございます。とても感謝しています。あなたの回答を解決策としてマークし、あなたのチームに以下のフィードバックを送ります。 - DflashブートローダーとHSEのデモがあれば、（あなたの時間も含めて）時間を節約できたでしょう。これはAB_SWAPを使用する人にとって自然な設定だと確信しています。 - NXPはドキュメントやソフトウェアスタックを統合し、長期的に整理すべきです。互換性やバージョンが散在しており、情報源が一つにないため混乱が生じます。 よろしくお願いいたします

MPC5644A 核心测试 我正在尝试对 MPC5644A 芯片组进行核心测试。 我目前使用的环境是 Eclipse 和 Wind River。 我下载了制造商的库 e200Zx_ICST_RTMC_3.0.0，其中包含几个汇编源 (.s) 文件。 其中，vle 编译成功。 但是 book_e 和 spe 编译失败。 编译过程中，各种汇编指令（如 bc、bcl、bclr、xoris、bclrl 和 bcctrl）出现错误。我打开了 book_e 和 spe 汇编文件的属性，并将 -tPPCE200Z4NEG:simple 添加到 C/C++ 版本 --> 设置 --> Diab 汇编器 --> 其他 --> 其他选项和标志中，并成功完成了编译。然而，在调试过程中，我到达了 `fsl_self_test_icst.c` 中的 `Fsl_call_test_execution_icst` 之前，而这部分实际上执行的是核心测试。如果我继续进行下一步，就会陷入无限循环。 通过 Eclipse 的反汇编检查，我发现当我单步进入地址 0x51518（紧接在 `SPE_ICST_int_logical_test` 开始之后）时，它会立即跳转到 0x3f2b90（一个空白空间）。 我应该怎么办？我不知道从哪里开始。 Re: MPC5644A core test 你好， SCST 仅支持 MPC56xx 系列中的以下设备： MPC560xP MPC564xB-C 由于 MPC5644A 和 MPC564xB 共享相同的 e200z4 CPU 内核，因此 SCST 库中以 CPU 为中心的部分可以进行调整。但是，所有整合方面都必须进行审查： 异常向量地址 存储器映射 时钟初始化 外围依赖性 链接器脚本假设 实际的 CPU 测试算法应该具有很强的可移植性，因为它们针对的是相同的 e200z4 架构。 NXP 没有为旧款 MPC5644A 设备提供官方的 SCST 库。然而，由于 MPC5644A 与 MPC564xB 系列使用相同的 e200z4 内核，因此在审查特定设备的集成细节后，或许可以采用 MPC564xB 解决方案中以 CPU 为中心的自检例程。或者，可以使用 MCU 的内置功能安全机制（ECC、CRC、看门狗、MPU、异常处理）开发自定义启动诊断实现，以满足项目特定的功能安全要求。 我应该怎么办？我不知道从哪里开始。 如果代码在 0x51518 处进入 SPE_ICST_int_logical_test()，然后立即跳转到 0x3F2B90（看起来像是空内存），我首先怀疑的不是 CPU 故障，而是链接器/库集成问题。 对于 SCST 库而言，这通常意味着以下情况之一： 1. 函数指针或分支表未正确链接 2. 缺少库对象 3. 内存模型错误/虚拟环境不匹配 4. 为另一台设备构建的 SCST 库 5. MMU/TLB 翻译问题 顺祝商祺！ Peter

Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. The compilation logs are attached below. Please advise on how to resolve this issue. DEBUG: Executing python function extend_recipe_sysroot NOTE: Direct dependencies are ['/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rpm/rpm_4.19.1.1.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rsync/rsync_3.2.7.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/unifdef/unifdef_2.12.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-extended/xz/xz_5.4.7.bb:do_populate_sysroot'] NOTE: Installed into sysroot: ['cmake-native', 'openssl-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'dwarfsrcfiles-native', 'elfutils-native', 'file-native', 'libedit-native', 'lua-native', 'make-native', 'perl-native', 'python3-native', 'rpm-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libtirpc-native', 'lzlib-native', 'zstd-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libunistring-native', 'nettle-native'] NOTE: Skipping as already exists in sysroot: ['gettext-minimal-native', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'zlib-native', 'bison-native', 'flex-native', 'gnu-config-native', 'patch-native', 'pkgconfig-native', 'pseudo-native', 'rsync-native', 'unifdef-native', 'xz-native', 'acl-native', 'attr-native', 'popt-native', 'sqlite3-native'] DEBUG: sed -e 's:^[^/]*/:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native/:g' /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/openssl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/ncurses-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/elfutils-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/lua-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/perl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/python3-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/rpm-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/curl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/gmp-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgcrypt-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgpg-error-native/fixmepath | xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot:g; s:FIXMESTAGINGDIRHOST:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native:g' -e 's:FIXME_PSEUDO_SYSROOT:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/pseudo-native:g' -e 's:FIXME_HOSTTOOLS_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/hosttools:g' -e 's:FIXME_PKGDATA_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/pkgdata/s32g399avmcu2.1asc:g' -e 's:FIXME_PSEUDO_LOCALSTATEDIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/pseudo/:g' -e 's:FIXME_LOGFIFO:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/temp/fifo.4087696:g' DEBUG: Python function extend_recipe_sysroot finished DEBUG: Executing python function sstate_task_prefunc DEBUG: Python function sstate_task_prefunc finished DEBUG: Executing python function do_package DEBUG: Executing python function package_setup_pkgv DEBUG: Python function package_setup_pkgv finished DEBUG: Executing python function package_convert_pr_autoinc DEBUG: Python function package_convert_pr_autoinc finished DEBUG: Executing python function package_prepare_pkgdata NOTE: Installed into pkgdata-sysroot: [] DEBUG: Python function package_prepare_pkgdata finished DEBUG: Executing python function perform_packagecopy ERROR: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.10/subprocess.py', lineno: 421, function: check_output 0417: else: 0418: empty = b'' 0419: kwargs['input'] = empty 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): File: '/usr/lib/python3.10/subprocess.py', lineno: 526, function: run 0522: # We don't call process.wait() as .__exit__ does that for us. 0523: raise 0524: retcode = process.poll() 0525: if check and retcode: *** 0526: raise CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/image -p -S . | tar -xf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/ocxl.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/pvpanic.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/xilinx_sdfec.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/cxl.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/fastrpc.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/uacce: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/uacce/uacce.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Okay, thank you very much. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi, @zhijie  Thanks for your reply. I have reproduced the issue, it does not related with current BSP, but from the building system changes I am looking into it and will reply you later once any progress made? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Thanks， @zhijie  Could you also help to share the result of uname -a? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @zhijie  Thanks for your post. May I know the details of your building environment? It is the first time you built the BSP46? or previously it is correct? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi  @zhijie  I am also facing the same issue, if you ressolved it kindly let us know. ERROR: zlib-1.3.1-r0 do_package: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/smurugan8/LWT/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.12/subprocess.py', lineno: 466, function: check_output 0462: else: 0463: empty = b'' 0464: kwargs['input'] = empty 0465: *** 0466: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0467: **kwargs).stdout 0468: 0469: 0470:class CompletedProcess(object): File: '/usr/lib/python3.12/subprocess.py', lineno: 571, function: run 0567: # We don't call process.wait() as .__exit__ does that for us. 0568: raise 0569: retcode = process.poll() 0570: if check and retcode: *** 0571: raise CalledProcessError(retcode, process.args, 0572: output=stdout, stderr=stderr) 0573: return CompletedProcess(process.args, retcode, stdout, stderr) 0574: 0575: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/image -p -S . | tar -xf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address tar: ./usr/lib/libz.so.1: Cannot create symlink to ‘libz.so.1.3.1’: No such file or directory Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello chenyin：     Is there any update on this build failure issue?     Wait for good news, much appreciated. BR Zhijie Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello Chenyin     The problem is resolved, Thanks! BR Zhijie Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @zhijie  Thanks for your reply By checking the logs of the building failure, it seems related with the program changes of the building machine. Would you mind trying the following way? On your ubuntu PC, use the command "sudo apt install tar=1.34+dfsg-1build3" to make a change of tar version used, the clean the BSP and rebuild it again   BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. I was having the same issue and I've figured out the issue is with the tar version build 4 and the downgrading did resolve the error, but the actual issue is the tar and pseudo using openat2() instead of openat for the system call. The poky has already given the patch as far as I've seen, does the NXP has any update on it? I'm currently using LLDP 6.1.22 SDK on the LX2160ARDB_REV2 Board and the same error appears when i try to build rcw using bitbake.  If NXP has upated the pseudo_git.bb to use openat2() instead of openat() as per tar's latest build 4., it will be useful for us as we can update tar to the latest version. Attached the logs for your reference. The bug from yocto-project link is added here  https://bugzilla.yoctoproject.org/show_bug.cgi?id=16117 Regards, PVSN Subhash Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @pvsnsubhash  Thanks for your reply, after my workaround fix for the issue, I had also noticed the pseudo issue and then reported it to our internal team. The corresponding team would review the issue and arrange the schedule for the formal fix. Thanks again for your valuable inputs. BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @Sanjiv_Mns  Thanks for your reply. 1. OK, I understand you are currently using i.MX instead of S32G products 2. You may have a try with the following method:  "sudo apt install tar=1.34+dfsg-1build3" and then clean/rebuild with your Yocto setup 3. If still issues, I suggest waiting for the feedback from your original link, I believe my colleague would help you to solve it based on you i.MX setup BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi @chenyin_h  Have you found anything that could help resolve it? This issue is currently blocking our progress, We would really appreciate any update or guidance you can provide. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. The issue is because of the tar package in linux getting upgraded to build4 from build3. Downgrade the tar package using the below steps and hold the apt upgrade for that package for now and proceed with your compilation. wget http://archive.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1build3_amd64.deb sudo dpkg -i tar_1.34+dfsg-1build3_amd64.deb  sudo apt-mark hold tar After the above steps, you can proceed with your compilation and no such errors will be seen. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi @chenyin_h   I am still facing the same issue. I have already raised a query on the forum, but I haven't received any response yet.Link I am attaching the log below for your reference. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @Sanjiv_Mns  Thanks for your reply. May I know if you met the same issue? would you mind creating a new post with your details logs, we would directly support it ASAP. BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. I solved this issue in NXP iMX BSP 6.6.36-2.1.0 and 6.12.49-2.2.0 bumping the pseudo_git.bb to 1.9.5 and updating the older-glibc-symbols patch... both copied from the corresponding wrynose recipe (6.18.20-2.0.0). git diff... diff --git a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch index c453b5f735..f42b32b8d9 100644 --- a/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch +++ b/meta/recipes-devtools/pseudo/files/older-glibc-symbols.patch @@ -28,10 +28,10 @@ diff --git a/Makefile.in b/Makefile.in @@ -120,7 +120,7 @@ $(PSEUDODB): pseudodb.o $(SHOBJS) $(DBOBJS) pseudo_ipc.o | $(BIN) libpseudo: $(LIBPSEUDO) - $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.o pseudo_ipc.o $(SHOBJS) | $(LIB) + $(LIBPSEUDO): $(WRAPOBJS) pseudo_client.o pseudo_client_scanf.o pseudo_ipc.o $(SHOBJS) | $(LIB) - $(CC) $(CFLAGS) $(CFLAGS_PSEUDO) -shared -o $(LIBPSEUDO) \ + $(CC) $(CFLAGS) -Lprebuilt/$(shell uname -m)-linux/lib/ $(CFLAGS_PSEUDO) -shared -o $(LIBPSEUDO) \ - pseudo_client.o pseudo_ipc.o \ + pseudo_client.o pseudo_client_scanf.o pseudo_ipc.o \ $(WRAPOBJS) $(SHOBJS) $(LDFLAGS) $(CLIENT_LDFLAGS) diff --git a/pseudo_wrappers.c b/pseudo_wrappers.c diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/recipes-devtools/pseudo/pseudo_git.bb index 5f32b3777a..c491f0c97f 100644 --- a/meta/recipes-devtools/pseudo/pseudo_git.bb +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb @@ -1,8 +1,6 @@ require pseudo.inc SRC_URI = "git://git.yoctoproject.org/pseudo;branch=master;protocol=https \ - file://0001-configure-Prune-PIE-flags.patch \ - file://glibc238.patch \ file://fallback-passwd \ file://fallback-group \ " @@ -14,9 +12,9 @@@ SRC_URI:append:class-nativesdk = " file://older-glibc-symbols.patch" SRC_URI[prebuilt.sha256sum] = "ed9f456856e9d86359f169f46a70ad7be4190d6040282b84c8d97b99072485aa" -SRCREV = "e11ae91da7d0711f5e33ea9dfbf1875dde3c1734" +SRCREV = "0bad85523ff71f1a84cea5fdf72e7f560c4aeed4" S = "${WORKDIR}/git" -PV = "1.9.0+git" +PV = "1.9.5+git" # largefile and 64bit time_t support adds these macros via compiler flags globally # remove them for pseudo since pseudo intercepts some of the functions which will be