Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
Separating Control Plane and Data Plane between GPP and AIOP on LS2085 This document introduces a method to separate control plane and data plane between GPP(ARM) and AIOP based on different L4 protocols implemented in the AIOP software. So far, in the current MC version, this scenario could not be implemented from WRIOP using DPDMUX, so it is a good choice for users to separate the traffic in AIOP.   1. Basic Concept of DPAA2 Objects   2. AIOP Application to Implement Control in ARM and Data Plane in AIOP   3. Build AIOP Application Project with CodeWarrior   4. Running AIOP Application Program on LS2085ARDB QorIQ LS2 Devices
記事全体を表示
场景工具就在这里!(适用于 Windows 的处理器专家软件)~ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您是CodeWarrior用户但还没有许可证,那么这篇文章对您和您的设计将非常有用! 您可能还在使用Power Architecture技术和QorIQ 处理器。如果我没记错的话,我会向您介绍 QorIQ 处理器的新优化套件。 整个 QorIQ 优化套件利用 QorIQ 处理器的片上硬件来帮助优化您的应用程序,从而提供数百个片上硬件事件的增强可视性,您将在这里找到的第一个包含的工具是场景工具,它包含以下新的有趣的功能: 采用下列工具提取测量信息: 飞思卡尔TAP TCP/IP,如果运行飞思卡尔SDK,且TCF连接器启用。 把数据作为平均值或一组时间序列值 选择数据子集进行绘制或求平均值 保存样本数据,供以后查看 多个窗口,可显示多个测量 采样时基 由主机确定 现在您知道它通过利用“测量场景”提供可见性,您将不再“盲目”设计,并且您将能够立即测试您的创作的潜力。这些测量场景包括CPU场景、内存和流量场景以及DPAA和外设场景。 要求: 主机系统要求 Microsoft® Windows® 7 Microsoft Windows Vista (SP2)(32 位)家庭普通版、家庭高级版、商业版、企业版、旗舰版 Microsoft Windows XP专业版(SP3) 32位和64位 Red Hat企业版Linux 5.4,32位和64位 Ubuntu 8.0.4,32位,9.10,32位和10.04,64位 SuSE 11,32位(采用11.1版进行测试) 目标系统要求 兼容QorIQ器件(见“支持的器件”) 连接方法(您只需其中一种) 运行飞思卡尔的TCF连接器的Linux系统 (含在面向支持器件的飞思卡尔SDK中) 飞思卡尔USB TAP或Gigabit TAP 在 概述 中获取 更多信息 或立即开始并 下载 适用于 Windows 的场景工具 ! 而是Linux 版本? 组件开发环境
記事全体を表示
wxWidgetsベースの分散情報および制御システム <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> そこで開発されたのは、i.MX53+Linuxを使用したコントローラーです。 分散情報・制御システムを構築するためのソリューションを開発しました。 Prototmpyは1年以上運用されています。 例: - 制御電磁攪拌(ミキサー) http://ontecom.com/en/catalog/ems /ルサール、クラスノヤルスク。 - ポンプ場の管理と管理。 - 気候制御システムの監視と制御。 スマートホームシステムやIoTを作ることができます。PLC(Power Line Communication)Qualcomm/Atherosの経験があります。 余暇には、PLC(電力線通信)制御/監視コンポーネントのスマートホーム用の予算ソリューションを開発しています。 標準IEC 61131-3に基づいて開発されたソフトウェア-分散情報管理システム。 解決策はクロスプラットフォームです。単一のシステムには、異なるアーキテクチャとさまざまなオペレーティングシステムのコンピューターが含まれる場合があります。 このような信号は、ARM/Linuxの同期コントローラ、およびx86サーバ(Win、Linux、VMSなど)です。 wxWidgets を使用します。 このテーマに関する記事は、ロシア語です。
記事全体を表示
关于Keil 无法正确下载程序问题的总结   当我们在使用Keil 时,经常会遇到无法下载程序的问题,以下对两种常见的情况进行总结:    1. 在我们需要将某工程代码移植到同系列其他型号器件上使用时,如果只是更改了器件型号,这时可能会导致无法正确下载。需要注意的是不仅要在Device中更换型号,还需要在Flash Download栏中选择正确的flash loader 并且设置正确的RAM起始地址。   举个例子:假设我们需要将FRDM_KL26的Sample code中的hello_world工程移植到256K flash的KL26上使用。打开FRDM_KL26的Sample code中hello_world工程,我们可以看到Device中器件为MKL26Z128xxx4,        在Target中可以看到Flash和RAM的起始地址和大小信息。          如果使用Jlink调试接口,选择J-LINK/J-TRACE Cortex  ,之后选择Setting,可以看到flash loader的相关信息。         将此工程移植到到256K flash的器件上,我们需要做的事情是:      在device中进行修改,选择MKL26Z256xxx4               在Target中可以看到这时flash和RAM的起始地址和大小信息已经自动做了更改。不需要再手动修改了。         但是在Flash Download中的设置还是之前的设置,并没有改变。           所以这时是无法正确下载程序的,需要我们手动去修改这里的两处配置。     一是 RAM for Algorithm中的Start应该设置为0x1FFFE000(从Target栏中可以获取该值),Size不用更改。      二是Program Algorithm 删除掉128k的flash loader ,添加256K的flash loader。       2.第二种可能遇到的情况是:本来可以正常下载的程序当复制到另外一台电脑时就无法正常下载了。遇到这种现象时,需要检查一下Flash Download中的相关配置是否正确,很可能会遇到 Program Algorithm中flashloder为空的情况,发生这种情况的原因可能是两个电脑的Keil版本不同,所以flash loader所在路径就会不同,这样flash loader就会变成空白,这时需要自己手动添加一下即可。
記事全体を表示
MCUXpresso Config Tools: How to Use the Clocks Tool (Japanese Blog) table of contents Introduction In what situations can Clocks Tool be used? Installing Config Tools Browse Tool screen configuration Basic Terminology for Using Clocks Tool Demonstration: Change the CPU core clock settings and alter the LED blinking speed. Bonus 1 - Clock settings are already available as presets. Bonus 2 - Where are the settings values that were automatically generated by the initialization code? Introduction MCUXpresso is a microcontroller development software platform provided by NXP. In addition to the MCUXpresso IDE, it also offers MCUXpresso for VSC (Visual Studio Code) and Config Tools to assist with peripheral configuration. Config Tools consists of tools such as the " Pins Tool " for setting pins and the " Clocks Tool " for configuring clock settings, and its key feature is that it allows for intuitive and easy initial setup of the microcontroller's peripherals via a GUI . This article will focus on the "Clocks Tool," which is responsible for clock settings. For instructions on using the "Pins Tool," please refer to the following article. MCUXpresso Config Tools: How to Use the Pins Tool (Japanese Blog) Clock settings are a crucial element directly impacting microcontroller performance, power consumption, and the operation of each peripheral. However, the clock tree can be complex, making it difficult to understand which clock is being used where . Clocks Tool allows you to visualize and configure clock sources, frequency division settings, and the clock supply status to each peripheral. It can also automatically generate initialization code based on the settings. When you install the MCUXpresso IDE , Config Tools are also installed, making them available as a built-in feature of the IDE . On the other hand, in the Visual Studio Code ( VSC ) environment, which has become increasingly popular in embedded development in recent years, you can similarly use Config Tools (including Clocks Tool ) by installing MCUXpresso -related extensions. There are no significant differences in the functionality of Config Tools between the IDE version and the VSC version. This article explains how to install Config Tools in the VS Code environment, how to use the tools, and finally demonstrates how to change the CPU clock settings within Clocks Tool and alter the LED blinking speed using the FRDM-MCXN947 . You can also watch a video. Click this link to watch : How to use MCUXpresso Clocks Tool (VS Code environment) In what situations can Clocks Tool be used? When you want to check the existing internal clock settings (clock tree) When you want to adjust and optimize the operating frequency for each module When you want to consider a configuration that lowers the clock frequency with low power consumption in mind. Installing Config Tools This guide explains how to install Config Tools in the VS Code environment. *If you haven't installed MCUXpresso for VS Code yet, please refer to this blog post. Installing MCUXpresso for VSC and SDK (Japanese blog) After launching VS Code , select MCUXpresso from the left-hand panel, and then click Open MCUXpresso Installer from the Quick Start Panel . The installer will launch. Select MCUXpresso Configuration Tools and click Install in the upper right corner. (This blog post describes the installation of MCUXpresso Config Tools v26.03.) You will be prompted to log in to MyNXP as soon as the installation begins. After logging in, the License Agreement will be displayed. Please review its contents and agree to them. *Please restart VS Code after installation. Q. What if the installation fails? A. Please download the installer appropriate for your PC's OS environment from the following website and try it. MCUXpresso Config Tools | Software Development for NXP Microcontrollers (MCUs) | NXP Semiconductors As you proceed with the installation, the following screen will appear on the initial screen. If you do not see anything relevant, you can close it. To access Config Tools from VS Code , install the SDK , import the sample, then right-click on your project. "Open with MCUXpresso Config Tools " will appear; click on it. *This entire process will be explained in detail in the final demonstration, so we will omit it here. Config Tools will start after a short while. If you are using the MCUXpresso IDE, Config Tools are integrated by default and can be launched directly from the top tab. Browse Tool screen configuration After launching Config Tools , you can switch between tools using the panel on the right side of the screen. This time, we'll select " Clocks ". The Clocks Diagram , which is frequently used when changing clock settings , can be selected from the top left of the screen. The Problem view in the lower right corner of the screen displays any errors or warnings related to your settings. If there is an error due to incorrect clock settings, the Problem view will display the location and cause of the error. Additionally, the relevant area will be highlighted in red on the Clock Diagram, allowing you to visually identify the problem. For example, if you set the CPU clock to exceed the specified maximum value, an error message (shown below) will be displayed. Basic Terminology for Using Clocks Tool This section clarifies the basic terminology displayed on the Clock Diagram when using the Clocks Tool . Clock Tree This is a configuration diagram (tree diagram) showing where clocks are generated, how they are distributed and selected, and how they are supplied to each block. Clocks Tool allows you to configure settings while visually viewing this Clock Tree . Clock Source This is the signal source that serves as the starting point for the clock. This includes internal RC clocks, external crystals (oscillators), and external clock inputs, and is located upstream in the clock tree. In the MCX N947, the built-in 48MHz RC clock (FIRC) is used as the clock source by default . PLL ( Phase Locked Loop) This circuit generates a stable high-frequency clock using a clock source as input. The output frequency can be adjusted by setting the multiplier and frequency divider, allowing for flexible creation of clocks for CPUs and high-speed buses . Here, a 300MHz clock (48MHz/8*50=300MHz) is generated based on the 48MHz input clock, which is the Clock Source . DIV (Divider ) This function allows you to divide and adjust the clock frequency. Frequency division settings are available for the CPU , bus, and each peripheral, and are used to adjust to the required operating frequency. In the following example, a 150MHz clock (300MHz/2=150MHz) is generated from a 300MHz clock generated by PLL0. Mux ( Multiplexer ) This mechanism allows you to switch which clock to use from among several potential clocks. Switching the selection changes the clock supplied downstream. In the diagram below, there are two MUXs ; the one on the left selects a 48MHz clock from the internal RC clock, and the one on the right selects a 150MHz clock divided by DIV (PLL0_PDIV) . Demonstration: Change the CPU core clock settings and alter the LED blinking speed. Here, we will actually change the clock supplied to the CPU using Clocks Tool and see if the blinking speed of the LEDs on the evaluation board changes. Hardware Preparation The evaluation board used in this article is the FRDM-MCXN947 Installing the SDK With the MCUXpresso icon selected in the left-hand panel of VS Code , click " Import Repository ". Next, click on " REMOTE ARCHIVE ," the second option from the left, and search for " FRDM-MCXN947 " in the Package section . Entering " 947 " will immediately display FRDM-MCXN947 as a suggestion . The Name , Location , and the "Create Git" checkbox can be set as you wish. *For Name and Location names, it is best to use only lowercase alphanumeric characters and underscores (_) or hyphens (-) , and avoid symbols such as ( \, /, :, *, ?, ", <, >, | ) (which may cause program malfunctions) and spaces. Finally, check the " I agree " box and click " Import " to begin the SDK installation. Please wait a moment. The installation is complete when " Repository successfully imported" is displayed in the lower right corner of the screen. Importing sample code Once the SDK installation is complete, proceed to import the sample code. Click " Import Example From Repository " in the panel on the left. Within each tab displayed on the right, under " Repository ," select the SDK you just imported. Please select FRDM-MCXN947 for " Board ". In this " Template " demonstration, we will be changing the blinking speed of the LED . I'll try it with " driver_examples/gpio/gpio_led_output_cm33_core0 " which appears when I type " led ". Next, select the Toolchain and click " Import" . Open ConfigTools Right-click on the imported sample and select " Open with MCUXpresso Config Tools ". The Config Tools will launch after a short wait. Once Config Tools opens, first check the Overview in the right-hand panel. In this example, both Clocks and Pins are green (ON ) , indicating that both tools are enabled. Now, let's look at the Clock Diagram . The main clock of 150MHz is generated from the clock source FIRC 48MHz via PLL (PLL0) , DIV (PLL0_PDIV) , and MUX (SCSSEL) . Next, scroll down a bit to see the clock supplied to the CPU . In this sample application, " System_clock" corresponds to the CPU core clock. The MAIN Clock at 150MHz passes through a DIV ( Distributed Variable) in between, but is still supplied to the System Clock at 150MHz . Later, we will change the value of this DIV and thereby change the clock signal input to the System Clock , observing the change in the LED blinking speed. Check the LED blinking speed when the CPU Clock is set to 150MHz. First, let's look at the LED blinking speed when the CPU Clock is set to 150MHz without any changes. Close Config Tools and open VS Code . Before building, connect the board ( FRDM-MCXN947) to the PC . Once the connection is established, debug the imported sample (build, write, and run the application). Once the debugging process is complete, the program will have stopped at the breakpoint, so click the "|▶" icon at the top of the screen. As shown in the video, the red LED will start blinking. This is the blinking speed at a clock speed of 150MHz (default setting). (function() { var wrapper = document.getElementById('lia-vid-6395306957112w304h540r743'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (Show My Videos) To stop, click the square icon (even after stopping the debug, the program will continue to run on the board, so the LED will continue to blink, but please ignore this for now ) . Change the CPU clock to 50MHz and check the LED blinking speed. Next, we'll use ClocksTool to change the CPU core clock from 150MHz to 50MHz . Open the Clocks Tool in Config Tools again . Scroll down slightly in the Clocks Diagram and change the DIV (AHBCLKDIV) connected to the System Clock . When changing it, click on the number within the DIV you want to change to select from the dropdown menu. Selecting 1/3 here will change the System Clock to 50MHz . *When changing clock settings, please note that changing the clock settings upstream, which are close to the Clock Source, may affect multiple clock settings downstream. Now, we will rewrite the sample code. First, click "Update Code" in the upper left corner of the Config Tools screen. In the dialog box that appears, select "OK". When you return to VS Code in this state, three checkboxes will appear at the top of the screen. Make sure they are checked and click OK . After a short wait, the changes made in Clocks Tool will be applied to the sample code in VS Code . *This may not be displayed if the SDK version is different. If successful, the following message will be displayed in the lower right corner of the screen. Run the debug test again, and once it's finished, run the sample application using "|▶". The LED will start blinking. This is the blinking speed at a 50MHz clock. It is clearly slower compared to the speed at 150MHz . (function() { var wrapper = document.getElementById('lia-vid-6395308518112w304h540r499'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (Show My Videos) This concludes the demonstration. Thank you for your participation. Bonus 1 - Clock settings are already available as presets. While the previous steps involved changing the clock using DIV , Clocks Tool comes with several clock settings pre-configured. Select Clocks Tool in Config Tools , and then choose your desired clock from the top of the screen : FRO 12MHz / FRO HF 48MHz / FRO HF 144MHz… For example, if you select "BOARD_BootClockPLL_100M " , you will see that the Clock Source , PLL , and DIV are all different from before. For example, the Clock Source is a 24MHz external clock (SOSC) . Bonus 2 - Where are the settings used to automatically generate the initialization code? We will examine how the clock settings are automatically updated (Update Code) using Clock Tools, and how this is reflected in the actual initialization code. Check the C source file (gpio_led_output.c) in the Project Files of the imported sample. If you look inside the C source file, you'll find code that initializes the Pin , Clock , and Debug console . Right-click on BOARD_InitHardware(); and click "Go to Definition" to see more details. There is code to initialize the Pin , Clock , and Debug console . Right-click on BOARD_InitBootClocks(); and select " Go to Definition" (or "fn + F12") to see more details. The destination file (clock_config.c) is FRDM-MCXN947This is the generated code that defines the startup clock configuration. As you scroll down, you will see that, as explained earlier, multiple clock configurations ( FRO 12MHz / FRO HF 48MHz / FRO HF 144MHz / PLL 150MHz / PLL 100MHz ) are available as presets. In the image below, the default value of PLL150MHz is shown, For example, if you change this part to BOARD_BootClockFROHF48M Initialization will be performed using the FRO HF 48M clock configuration, which is prepared as a preset. Next, let's see how the clock configuration and code change when we directly modify the DIV in Clocks Tool while keeping the FRO HF 48M . The text and settings enclosed in the red box will be changed. Furthermore, if you change the DIV connected to the System Clock in Clocks Tool to 1/2 , i.e., from 48 to 24MHz, and then run Update Code, you will see that the red frame has changed due to the change in DIV.   You can also check the differences before and after the changes in Clocks Tool. After changing the clock settings, clicking Update Code will display a dialog box like the one below. Files with differences will have "change" displayed to the right of the file name. Clicking this will allow you to view the differences. clock_config.c Let's check the difference. The left side (Newly generated) shows the modified file, and the right side (On disk) shows the original file. You should be able to see that there is a difference in the System Clock. The areas where differences have occurred are highlighted with a different color, making them visually easy to spot.   Due to the increasing integration of functions in microcontrollers and processors, their internal clock trees have become extremely complex. Without a clock visualization tool like this, designing and evaluating such systems would be practically impossible, so please make use of it.   Reference materials Tutorial video: How to use MCUXpresso Clocks Too (VS Code environment)   =========================​ We are currently unable to respond to comments left in the " Comment " section of this post . We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us ( Japanese Blog ) " when making inquiries . (If you are already an NXP distributor or have a relationship with NXP , you may ask your representative directly.) This guide focuses on the "Clocks Tool" within the MCUXpresso Config Tools, explaining the basics and methods of setting the clock. It covers everything from installation in a VS Code environment to a demonstration of LED blinking caused by CPU clock changes. (Estimated time: 10 minutes *Assumes MCUXpresso for VSC (Visual Studio Code) SDK is installed) MCUXpresso MCX Victoria | Downloads Japanese Blog
記事全体を表示
VDD(INTF)のみが存在し、VDDPに電源が供給されていない場合のTDA8035の動作 以下の場合に TDA8035 がどのように動作するかを知りたいです。 VDD(INTF)=3.3V VDDP= 0V(電源なし) TDA8035 はリセットモードになっているようですが、よく分かりません... 確認していただけますか? この状態は長期間(数時間以上)許容されますか? この場合の VDD(INTF) の消費量はどのくらいでしょうか? よろしくお願いいたします。 よろしくお願いいたします。 シルヴァン 接触型スマートカードリーダーIC Re: TDA8035 behaviour when only VDD(INTF)is present, not powered VDDP こんにちは@sylvainbouriot VDD(INTF) = 3.3V、VDDP = 0Vで電源投入時: TDA8035 はリセット状態のままとなり、スマート カードの起動を試行しません。 この状態は、チップを損傷したり異常な動作を引き起こしたりすることなく、長期間にわたって継続できます。 VDDP = 0 でチップがリセット/パワーダウンモードの場合: VDD(INTF) の標準的な電流は非常に小さく、通常は数 µA から数十 µA の範囲です。消費電流は主にデジタル保持に使用されます。 Re: TDA8035 behaviour when only VDD(INTF)is present, not powered VDDP カイリーさん、非常に正確な答えをありがとう。 TDA8035 がアクティブ モードの場合、VDD(INTF) = 3.3 V のときの VDD(INTF) の消費量はどのくらいですか? よろしくお願いいたします。 シルヴァン Re: TDA8035 behaviour when only VDD(INTF)is present, not powered VDDP VDDP = 3.3V または 5V の場合...
記事全体を表示
[不正使用] 記事作成者: @jeremyzhou / ナレッジベース: imxrt@tkb / 報告者: eikewp eikewp は、 @jeremyzhou が投稿した記事 「マイクロコントローラ使用の認識モデル」を 以下の理由で報告しました。 理由:ヌードまたは性行為 詳細: CANゼニカルを注文します 安いゼニカル 土曜日配送 インターネット ジェネリックゼニカル 購入安いゼニカル60mg ロイズ薬局のゼニカル インドにおけるゼニカルの価格 次のゼニカルをどこで注文できるか ゼニカルの割引 ゼニカルを購入したい 一般ゼニカル錠 CANゼニカルを注文します 注文ゼニカル 安いゼニカル錠 ゼニカルはどこで買える? ゼニカルアメックスの迅速な配達 ゼニカルの割引 ゼニカルイギリスでオンライン購入 ゼニカルを購入したい ジェネリックゼニカル ゼニカルを注文する ゼニカルを注文したい ゼニカルイギリスでオンライン購入 できるゼニカルを購入しました ゼニカルを次に注文する場所 ゼニカルの購入方法 ゼニカル肥満 スクリプトなし バジルドン 一般ゼニカル錠 一般ゼニカル薬の割引 ゼニカルヴァイタイジェネリック フィナステリド ゼニカルのオンライン購入情報 ジェネリックゼニカル薬の割引 購入安いゼニカル60mg ゼニカルブランド 安い kchge ジェネリックゼニカル錠 安いゼニカル 英国 オンライン ゼニカルブランド 安い kchge 欲しいゼニカルを注文する ジェネリックゼニカル錠 ゼニカル オンライン購入 5bdvi ロイズ薬局のゼニカル 記事リンク: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/Recognition-model-for-microcontroller-use/ta-p/1103364 記事の著者: @jeremyzhou |メールアドレス 報告者: eikewp |メールレポーター 報告された記事には 8 件のコメントがあります。
記事全体を表示
カスタムボードの Yocto BSP の DDR バイナリを置き換えるにはどうすればよいでしょうか? こんにちは、 カスタム ボードの Yocto BSP 内の DDR バイナリを置き換えようとしています。 新しいマシンが作成され、必要なファイルを含むレシピ ddr-firmware のディレクトリもカスタム メタ レイヤーに作成されます。しかし、SRC_URI に新しい値を割り当て、レシピ追加で元の値を削除しても、Bitbake が評価ボードの元のパスを検索するのを止めることはできません。レシピ追加を使用しない場合も、この検索については何も変わりません。 唯一機能する方法は、元のレシピをマスクし、カスタム レイヤーに新しいレシピを作成することです。 しかし、それは好ましい方法ではないと思います。これは、カスタム マシン用に作成された DDR バイナリを使用するのに簡単に実行できるはずです。ここで何が見逃される可能性があるでしょうか? よろしくお願いします! クレーン Re: How to replace DDR binaries in Yocto BSP for the custom board? はい、うまくいきました。NXP_FIRMWARE_LOCAL_DIR に設定されているフォルダーと正確に一致しないようです。しかし、いずれにせよ、それは機能します。 もう 1 つ質問があります。カスタム レイヤーの .bbappend で NXP-EULA ライセンスを閉じるにはどうすればよいでしょうか? よろしくお願いいたします。 クレーン Re: How to replace DDR binaries in Yocto BSP for the custom board? こんにちは、鶴 ご返信よろしくお願いします。 お客様の DDR にも DDR ファームウェアが含まれている必要があります。Yocto で BSP をビルドするときに、S32G3_LinuxBSP_44.0_User_Manual.pdf を参照して DDR ファームウェアを追加していただけますか。 BR ジョーイ Re: How to replace DDR binaries in Yocto BSP for the custom board? こんにちは、ジョーイ。 ご返信よろしくお願いします。 S32G3で、BSPは「bsp44.0」です。 よろしくお願いいたします。 クレーン Re: How to replace DDR binaries in Yocto BSP for the custom board? こんにちは、クレーン お問い合わせいただきありがとうございます。 使用している BSP のバージョンはどれですか? S32G3 または S32G2 チップを使用していますか? BR ジョーイ Re: How to replace DDR binaries in Yocto BSP for the custom board? こんにちは、クレーン フォルダ(fsl-車載-Yocto-bsp/build_s32g274ardb2/conf)内のlocal.confファイルを変更してみてください。 ACCEPT_FSL_EULA = "1" BR ジョーイ Re: How to replace DDR binaries in Yocto BSP for the custom board? こんにちは、ジョーイ。 .bbappend を追加しようとしましたが機能しませんでしたカスタムボード用。 ERROR: /home/crane/work/yocto/sources/meta-alb/meta-alb-bsp/recipes-bsp/ddr-firmware/ddr-firmware.bb: Unable to get checksum for ddr-firmware SRC_URI entry NXP-EULA: file could not be found The following paths were searched: .bbappendを試してみたLICENSE = "CLOSED"、LIC_FILES_CHKSUM = "" で、SUMMARYのみ、.bbappendも試しませんでした。すべて同じエラーメッセージが表示されます。 元のレシピに基づいてレシピを追加するのではなく、NXP からの元のレシピをマスクしてカスタム レシピを作成するのが、カスタム DDR バイナリを処理する唯一の方法ですか? よろしくお願いいたします。 クレーン Re: How to replace DDR binaries in Yocto BSP for the custom board? こんにちは、クレーン フォルダーに NXP-EULA ファイルを追加しましたか? BR ジョーイ Re: How to replace DDR binaries in Yocto BSP for the custom board? こんにちは、ジョーイ。 このファイルを元のレシピまたはカスタムレシピにコピーしようとしましたが、どちらも機能しません。ファイルは両方の方法で見つかりますが、どちらも以下のエラー メッセージを生成します。 ERROR: No recipes in default available for: /home/crane/work/yocto/sources/meta-crane/recipes-bsp/ddr-firmware/ddr-firmware_%.bbappend 私は NXP の DDR バイナリを使用していないので、NXP によって生成された NXP-EULA を使用するのは意味がないと思います。NXP-EULA のチェックを無効にするのが合理的ですよね? よろしくお願いいたします。 クレーン Re: How to replace DDR binaries in Yocto BSP for the custom board? こんにちは、クレーン ご返信よろしくお願いします。 この問題の根本原因を見つける必要があります。NXPのDDRファームウェアとNXP-EULAファイルを使用するには、YoctoでBSP44をビルドしてみてください。BSP44を正常にビルドできた場合は、DDRファームウェアを交換してから再度ビルドしてみてください。 BR ジョーイ
記事全体を表示
如何使用 HSE 固件二进制文件对恩智浦 S32K344 MCU 进行编程?需要哪种调试器? 我正在使用 S32K344 MCU,并希望在其中使用 HSE。 我从 nxp flexnet 下载了 HSE Fw 可执行文件。 在解压缩 exe 文件时,我得到了 hse 粉色文件。 但是无法得到,我应该如何将这个二进制文件转储到 S32K344 MCU? 他们是否需要像 lauterback 这样的外部调试器来刷新二进制粉色文件?或者我也读过他们的 HSE_demo_App,我们可以通过它对 HSE 固件进行编程。如果是,我们可以从哪里获得 S32K344 MCU 的 HSE 演示应用程序? Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? #I 正在开发 S32K3X4EVB-T172 板并尝试安装 HSE 固件 HSE 固件刷新成功,但我的应用程序总是停在: if (FALSE == checkHseFwFeatureFlagEnabled()) { /* Stuck here */ } 因此,HSE FW 初始化无法进行。 我检查了 UTEST 区域 (0x1B000080),得到的值是0XFFFFFFFF ,请查看我们的项目和图像,并帮助我们解决这个问题。 谢谢 Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? 你好@Kunal_Gettobyte 最新版本的 HSE 固件中引入了 HSE_SRV_ID_ERASE_FW 服务。该服务将清除 HSE 固件、备份和 SYS-IMG (HSE 数据)固件,但仅限于生命周期仍处于 CUST_DEL 时。您可以参考下面的社区主题,我的一位同事在其中简要介绍了如何做到这一点。 安装 HSE 固件 Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? 嗨,恩智浦技术团队,关于我上一条评论有什么新进展吗? 因此,在通用 HSE 演示示例 中,我得到了 HSE Fw 安装示例。 但是,如果要删除 HSE Fw,并使用不带 HSE Fw 的芯片,又该怎么办呢?那我怎样才能做得更好? 是否也有删除 HSE Fw 的例子? 如果我想删除 HSE Fw,该怎么做? Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? 您好, 好吧,我知道了。 因此,在通用 HSE 演示示例 中,我得到了 HSE Fw 安装示例。 但是,如果要删除 HSE Fw,并使用不带 HSE Fw 的芯片,又该怎么办呢?那我怎样才能做得更好? 是否也有删除 HSE Fw 的例子? 谢谢并致以诚挚的问候 库纳尔-古普塔 Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? 你好@Kunal_Gettobyte HSE 演示应用程序可以从 S32K3 标准软件 → 汽车软件-S32K3-HSE 固件 → S32K358 HSE FW 0.2.40.0 RTM 版本中下载。此外,用于通用 HSE 演示示例的 S32K3 MCU 可在 S32K3 设备页面(适用于汽车通用的 S32K3 微控制器)的设计资源 → 软件下找到。版本说明随软件一起提供,可以在下载的文件中找到。 关于 RTD 版本,HSE 演示应用程序或非用于通用的 HSE 演示示例的 S32K3 MCU 都不是使用 RTD 开发的,其运行也不需要 RTD。 Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? 好的,您从哪里下载HSE 演示应用程序和用于通用 HSE 演示示例的 S32K3 MCU? 因为我想知道我需要安装哪个 RTD 版本。 还需要用于环境设置的 HSE 演示的发行版本说明文档。 Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? 你好@Kunal_Gettobyte 如果我之前的回答不够清楚,请原谅。 HSE 演示 APP 和通用 HSE 演示示例 S32K3 MCU 都提供了以 FULL_MEM 或 A/B_SWAP 方式安装 HSE 固件的示例。这些应用程序设计用于T32 Lauterbach或PEMicro,因为这些是我们直接支持的设备。但是,该过程可以由任何与我们的设备兼容的程序员执行。 此外,我们还有一份应用笔记,解释了安装 HSE 固件的步骤,该固件也可以在安全文件中找到。如前所述,有关更多详细信息,建议查阅《HSE参考手册》。 Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? 您好, 啊哈,你的回答没有准确回答我的问题。 我最关心的是,有什么方法可以将 HSE 固件编程到我的控制器 S32K344 中? 将 HSE 固件编程到 S32K344 MCU 需要什么调试器? 我们只能通过劳特巴赫 对 HSE 固件进行编程吗?如果是,那么没有劳特巴赫的用户如何编程 HSE FW(因为劳特巴赫 相当昂贵)。 PeMicro 或 Segger Jlink 调试器是否不支持 HSE FW 编程? 使用 HSE 演示应用程序可以闪存 HSE Fw 吗?如果是,那么使用相应的 HSE 演示应用程序是否需要劳特巴赫(lauterbach),或者通过 PeMicro 是否也可以使用 HSE 演示应用程序,然后从中进一步闪存 HSE Fw? 主要问题是如何将 HSE Fw 闪存到我的 S32K344 MCU 中,有哪些方法/调试器可供选择(除了直接/间接使用劳特巴赫)。 Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? 你好@Kunal_Gettobyte HSE DEMO APP 需要 T32 Lauterbach 才能运行。不过,如果您没有 T32 Lauterbach,也可以通过S32K3 MCU for General Purpose HSE Demo Examples 找到替代方案。两者都提供了不同的用例场景和示例,以演示 HSE 固件在各种设备上的功能。关键区别在于,后者是专门为与 PEmicro 和 S32 Design Studio 配合使用而开发的,因为这两个工具可以很好地相互集成,允许使用 IDE 进行直接调试。 有关在 S32K3 中使用 HSE 的更多信息,建议查阅安全文件中提供的 HSE 参考手册以及每个 HSE 固件版本附带的 API 参考。 BR、VaneB Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? 你好@VaneB请提供有关我们的问题的最新消息......请问我们没有问题的原因是什么? Re: How to Program NXP S32K344 MCU with HSE Firmware Binary? Which debugger is needed? # 你好@VaneB 请提供有关我们的问题的任何最新消息......请问我们不是什么原因?
記事全体を表示
Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Hello, I’m trying to establish communication between two Imx95 verdin EVK A1 Silicon version boards, through their Aquantia 10 Gbps interfaces. Both boards are running Debian 12 ( linux kernel 6.12.3) with the aquantia10 G firmware (AQR-G4_v5.6.D-AQR_Marvell_NoSwap_XFI_ID44834_VER2068.cld ) properly installed using the nxp installer (aquantia-firmware-utility/aq_api_2_9_7 at master · nxp-qoriq/aquantia-firmware-utility · GitHub). They are physically connected using a Cat6a Ethernet cable. When I run performance tests using iperf3, I get around 5 Gbps in TCP and 1.2 Gbps in UDP with 0% of loss, even when specifying a target bandwidth of 7 Gbps: # TCP Test iperf3 -s # on the first board iperf3 -c -t 30 # on the second board # UDP Test iperf3 -s iperf3 -c -u -b 7G -t 30 when i try to activate jumbo frame with ip link set dev enp1s0 mtu 9000 but i get an error that i exceded the limit (it’s weird that a 10Gbps interface does not accept jumbo frames) also i tried to to increase the UDP buffer size, but i get the same bitrame the CPU load does not exceed 40% when i run iperf3 in both sides Are there any specific n configurations to apply or additional tools to install in order to reach the maximum throughput (close to 10 Gbps)? is the Aquantia FW version is good? the linux kernel version? the FW installer version??? SOmeone have already tried to use the 10Gbps interface on this Targets??? Regards, Abdelmonaem Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 1. Try configuring following settings on both of your systems: cpufreq-set -g performance sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216' sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216' 2. If possible use a different reference system as iperf server (e.g. Intel Xeon) 3. iperf3 itself is single-threaded per test stream, try using  -P option: e.g. iperf3 -c -u -b 10G -t 30 -P 6 (6 streams) 4. Check both forward and reverse stream (-R) iperf3 -c 192.168.1.1 -t 10 -b 10G -u -R Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Hi, Thank you for your feedback, applying your configuration: cpufreq-set -g performance sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216' sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216' Now i'm able to achieve 10Gbps some times 8,8 or 9,8Gbps on emitter side only and with only iperf and not iperf3, on the receiver side i can only achieve 5.59Gbps with 36% of loss frames, could you help to resolve this issue Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp it will be a minor version upgrade to 6.12.49 BTW, you may also want to consider DPDK or AF_XDP for better throughput?  Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp => TCP vs UDP send performance When you are using iperf3 to send TCP packets, each TCP packet is 128KB, and the packet will be fragmented by the LSO feature of ENETC Hardware. So you see higher TCP transfer performance. iperf3 does not enable UDP_SEGMENT when creating UDP sockets. Therefore: - Each UDP packet is approximately MTU-sized (≈1500 bytes). - For the same data size, UDP requires to send many more packets than TCP. More packets → more kernel processing → lower performance compared to TCP with LSO. => Why receive is much lower in comparison to send for TCP? - The TX and RX paths are not symmetrical in the Linux kernel, so the processing time for each RX packet and each TX packet in the kernel is different. Also TCP is using LSO offload in send. - RSC is not enabled by default in kernel; We need to disable TCP timestamp so that the RSC of ENETC can work properly. Currently, the RSC of i.MX95 is disabled by default. a) Enable RSC of i.MX95 (receiver side): ethtool -K eth1 large-receive-offload on b) Disabled TCP timestamp (sender side) : sysctl -w net.ipv4.tcp_timestamps=0 sysctl -p /etc/sysctl.conf After enabling RSC, you will see the TCP performance at receiver side will be increased. Additionally you can try using Jumbo frames to get higher throughput. (Hope you are running latest release). # Change MTU to 9000 on both side ip link set dev eth1 mtu 9000 # Change RX buffer length in the ethernet driver. ethtool -G eth1 rx-buf-len 16384 We can see between 8 to 10 Gbps UDP RX/TX with multi-stream mode. Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Hi, I'm interested only on UDP for the moment and not TCP and i think that the offload mecanisms are not applicable for UDP I tried to activate the jumbo frames by setting mtu to 9000 but i get an error that i exceeded the limits which is 1500 (im using the kernel version 6.12.3) Regards, Abdelmonaem Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Ok i will try this and told you what i get, Could you precise the linux kernel version for LF-Q4?? As i told you i'm on 6.12.3 and i cannot go to a superior version because i have a A1 silicon revision, i need to know if i have to upgrade to B0 revision or not Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp The RSC settings will also improve UDP performance. The changes/fixes for Jumbo frames in ENETC should be available in upcoming LF-Q4 release in two weeks.  Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp With i don't have an issue i can go to 10Gbps sometime 9, 8Bps with iperf in parallel flows with only one flow i'm at 5Gbps , but my big issue is the Udp, in mono flow i'm at 2Gbps with no lost frame it's ok, but in parallel flows i'm at 5,5Gbps with 42% of loss Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp i don't think that AF_XDP or DPDK will help to reduce a 46% of loss to 0%, i verified also the IRQ affinty and i can see that on the 10G interface i have 6 IRQ each one is affected to a CPU, and i don't see any CPU load issue during the test, the maximum CPU load for 1 CPU is 40%, i still don't understand why i keep loosing frames , maybe the fact that the kernel version used does not support jumbo frames , did you have any performance tests on the 10G interface in your Side (NXP) i think you should test in your side and see if you have the same issue than mine Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp AF_XDP or DPDK do not use kernel networking stack.  DPDK specially have a different driver and work in userspace only. It is highly optimized for networking and packet processing.  It can provide really fast performance for all IP packets.  you may check it out at;  Chapter 10: https://www.nxp.com/docs/en/reference-manual/RM00293.pdf Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp this test is performed on which silicon revision A1 or B0?? do you confirm that the kernel version used for this test 6.12.49 is applicable only for B0 or could be applicable on A1??? i'm not seeing this kernel version in your bsp delivery, the last one is 6.12.34 https://www.nxp.com/pages/alpha-beta-bsps-for-microprocessors:IMXPRERELEASES Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp The new kernel tree and changes are available at: https://github.com/nxp-imx/linux-imx/commits/lf-6.12.49-2.2.0 A1 support has been dropped from newer LF release.  You have following options; 1.  Just build the kernel independently and replace the kernel only in your build. (It may work)   2. Ask your marketing contact to replace your boards with B0 - so that you can run LF-Q4'2025 release.  Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp Ok got it, but just to be sure, could you do the test with MTU = 1500 at reception side i need to know if you have the same result than me on this new version and also i see on your test you put TX at 1500 and reception at 9000 but this does not change anything it's like you are in 1500 in both side if you need to test jumbo frames you need to be at 9000 in both sides , please redo the tests with following configuration: 1- RX/TX with MTU = 1500 in both sides with mono and muti streams 2- RX/TX with MTU = 9000 in both sides with mono and muti streams thank you in advance Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp i don't understand that frome those lines: Single UDP Stream send (1500 MTU): 2 Gbps(this seems at tx with MTU 1500 in single stream you are at 2Gbps) Multi UDP stream send (1500 MTU): 10 Gbps (this seems at tx with MTU 1500 in multi streams you are at 10Gbps) Single UDP Stream send (9000 MTU): 8.2 Gbps(this seems at tx with MTU 900 in single stream you are at 8.2Gbps) Single UDP Stream receive(9000 MTU): 3.9 Gbps(this seems at Rx with MTU 9000 in single stream you are at 3.9Gbps) Multi UDP Stream receive(9000 MTU): 10Gbps(this seems at Rx with MTU 9000 in Multi streams you are at 2Gbps) for me i don't see : Single UDP Stream receive(1500 MTU) Multi UDP Streams receive(1500 MTU) Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp yes, this how the results were tested. MTU was same on both side in all cases (either both 1500 or both 9000) Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp see attached,  Also note that I am also running it on A1 SOC UBOOT logs: -  U-Boot 2025.04-g8c1de2e1deca (May 09 2025 - 15:29:26 +0000) CPU:   i.MX95 rev1.1 at 1800MHz CPU:   Automotive temperature grade (-40C to 125C) at 30C LM Boot reason: sw, origin: 2, errid: 1 LM shutdown reason: sw, origin: 2, errid: 1 Model: NXP i.MX95 19X19 board DRAM:  15.8 GiB --- SM logs >$ info SM Version = Build 633, Commit c37b26da SM Config = mx95evk, mSel=0 Board = i.MX95 EVK, attr=0x00000000 Silicon = i.MX95 A1 Boot mode = normal Boot device = MMC1 Boot stage = primary Boot set = 1 ECID = 0x6E5F04BA0000000500041D0899123F81 PMIC 0 (0x08) = 0x20, 0x09, 0x10, 0x00, 0x01 PMIC 1 (0x2A) = 0x54, 0x22, 0x00, 0x0B PMIC 2 (0x29) = 0x55, 0x22, 0x00, 0x0A Compiler = gcc 14.2.1 20241119
記事全体を表示
S32K3X4EVB-T172 上的 PEmicro 连接助手问题 我无法连接到 S32K3X4EVB-T172,尽管遵循了《快速入门指南》: https://www.nxp.com/document/guide/quick-start-guide-for-s32k3x4evb-board:GS-S32K3X4EVB-Q172 板和 LED: 尝试调试时,会显示 PEmicro 连接助手。 设备驱动程序: 调试设置: 已经尝试过更换数据线、更换电脑、重新安装 S32DS、重新安装驱动程序、尝试 P&E Micro Utilities。 Windows 11,在 S32DS 3.6.4 上试用& 3.6.1 S32K3X4EVB-T172 S32DS-S32PLACE OPENSDA Re: PEmicro Connection Assistant Issue on S32K3X4EVB-T172 这是第一次尝试连接 EVB 吗?之前是否上传过任何项目? 该板是全新的,似乎有一些出厂预装的程序,即按下 SW5 和 SW6 会改变 USER_LED_0 的颜色 从图中可以看到,RESET_K3 和 RST_OSDA 两个 LED 都亮着。给板供电时 RESET_K3 是否一直处于开启状态? 你能测量吗?通常,当RESET LED 亮起时,线路会定期在很短的时间内被拉动,从而保持 MCU 处于RESET状态。 当我按照开机程序连接板时,RESET_K3 和 RST_OSDA 最初处于关闭状态。尝试调试时,RST_OSDA(有时是 RST_K3)LED 灯亮起,同时弹出 PEmicro 连接助手。 此外,如果我按下 SW4 键,然后重新尝试调试,就会出现不同的弹出窗口: 此外,测量电压源,如果电压源没有提供预期值,则意味着 MCU 可能已损坏。 我已经尝试过两种不同的适配器:12V-4A 和 12V-5A,得到的结果是一样的。适配器电压输出稳定。 -如果你的意思是 S32K3 MCU 已损坏:默认应用程序(LED 颜色变化)仍在板上运行。 -如果你的意思是恩智浦 K26 受损了:我还能使用 " Multilink 固件配置实用程序 " 将固件升级到 usbmlacpembeddedens.1098 如果您有任何可用的外部调试器(PEmicro、JLink、Latuerbach 等),可以尝试使用它们来查看是否可以连接。 下周我将得到一个 JLink 和一个新的 EVB。这次将是 S32K344MINI EVB。 如果还需要什么来确定根本原因,请告诉我。 Zaigham Re: PEmicro Connection Assistant Issue on S32K3X4EVB-T172 嗨,@zaighamkhawaja、 感谢您分享安装细节。看来 S32K3x Dev.软件包和 peMicro 插件已正确安装。这是第一次尝试连接 EVB 吗?之前是否上传过任何项目? 从图中可以看到,RESET_K3 和 RST_OSDA 两个 LED 都亮着。给板供电时 RESET_K3 是否一直处于开启状态?你能测量它吗? 通常,当RESET LED 亮起时,线路会定期在很短的时间内被拉动,从而保持 MCU 处于RESET状态。 此外,测量电压源,如果电压源没有提供预期值,则意味着 MCU 可能已损坏。 如果您有任何可用的外部调试器(PEmicro、JLink、Latuerbach 等),可以尝试使用它们来查看是否可以连接。 致以最诚挚的问候, Julián Re: PEmicro Connection Assistant Issue on S32K3X4EVB-T172 感谢您关注我们的产品并为我们的社区做出贡献。 请让我们先退一步。 请提供您的 "安装详细信息" 的屏幕截图,您可以在 IDE 的 "税务摊销收益" 中找到该屏幕截图。 Re: PEmicro Connection Assistant Issue on S32K3X4EVB-T172 当然,就在这里: C/C++ Common GDB Support 11.4.0.202309142347 org.eclipse.cdt.gdb.feature.group Eclipse CDT C/C++ Development Platform 11.4.0.202311271618 org.eclipse.cdt.platform.feature.group Eclipse CDT C/C++ Development Tooling Native Utilities 11.4.0.202311271618 org.eclipse.cdt.native.feature.group Eclipse CDT C/C++ Development Tools 11.4.0.202311271618 org.eclipse.cdt.feature.group Eclipse CDT C/C++ DSF GDB Debugger Integration 11.4.0.202309151124 org.eclipse.cdt.gnu.dsf.feature.group Eclipse CDT C/C++ GCC Cross Compiler Support 11.4.0.202309151124 org.eclipse.cdt.build.crossgcc.feature.group Eclipse CDT C/C++ GDB Hardware Debugging 11.4.0.202309151124 org.eclipse.cdt.debug.gdbjtag.feature.group Eclipse CDT C/C++ GNU Toolchain Build Support 11.4.0.202311121705 org.eclipse.cdt.gnu.build.feature.group Eclipse CDT C/C++ GNU Toolchain Debug Support 11.4.0.202309151124 org.eclipse.cdt.gnu.debug.feature.group Eclipse CDT C/C++ Memory View Enhancements 11.4.0.202309151124 org.eclipse.cdt.debug.ui.memory.feature.group Eclipse CDT C/C++ Remote Launch 11.4.0.202309142347 org.eclipse.cdt.launch.remote.feature.group Eclipse CDT Core Server Feature 1.15.200.v20231110-1900 org.eclipse.equinox.server.core.feature.group Eclipse Equinox Project e(fx)clipse - IDE - Basic 3.9.0.202210170554 org.eclipse.fx.ide.basic.feature.feature.group Eclipse.org ECF Apache Httpclient 5 FileTransfer Provider 1.1.702.v20231114-1017 org.eclipse.ecf.filetransfer.httpclient5.feature.feature.group Eclipse.org - ECF ECF Core Feature 1.6.2.v20231021-2127 org.eclipse.ecf.core.feature.feature.group Eclipse.org - ECF ECF Filetransfer Feature 3.14.1900.v20230715-1945 org.eclipse.ecf.filetransfer.feature.feature.group Eclipse.org - ECF ECF Filetransfer SSL Feature 1.1.402.v20231021-2127 org.eclipse.ecf.filetransfer.ssl.feature.feature.group Eclipse.org - ECF Eclipse Help System 2.3.1600.v20231201-0110 org.eclipse.help.feature.group Eclipse.org Eclipse Platform 4.30.0.v20231201-0512 org.eclipse.platform.feature.group Eclipse.org Eclipse RCP 4.30.0.v20231201-0512 org.eclipse.rcp.feature.group Eclipse.org Eclipse XML Editors and Tools 3.31.0.v202308200343 org.eclipse.wst.xml_ui.feature.feature.group Eclipse Web Tools Platform Embedded C/C++ J-Link Debugging 6.4.0.202307251916 org.eclipse.embedcdt.debug.gdbjtag.jlink.feature.group Eclipse Embedded CDT EMF - Eclipse Modeling Framework Core Runtime 2.36.0.v20231002-1156 org.eclipse.emf.ecore.feature.group Eclipse Modeling Project EMF Common 2.30.0.v20230916-0637 org.eclipse.emf.common.feature.group Eclipse Modeling Project EMF Ecore Edit 2.16.0.v20230211-1150 org.eclipse.emf.ecore.edit.feature.group Eclipse Modeling Project Equinox p2, headless functionalities 1.7.0.v20231112-1314 org.eclipse.equinox.p2.core.feature.feature.group Eclipse.org - Equinox Equinox p2, minimal support for RCP applications 1.4.2200.v20231112-1314 org.eclipse.equinox.p2.rcp.feature.feature.group Eclipse.org - Equinox GDB Client for Arm Embedded Processors 15.1 Build 1703 1.0.0.202511261537 com.nxp.s32ds.brc.gdb.tools.feature.feature.group NXP GEF Classic Draw2d 3.18.0.202311222042 org.eclipse.draw2d.feature.group Eclipse GEF GEF Classic GEF (MVC) 3.18.0.202311222042 org.eclipse.gef.feature.group Eclipse GEF GEF Classic Zest 3.18.0.202311222042 org.eclipse.zest.feature.group Eclipse GEF Git integration for Eclipse 6.8.0.202311291450-r org.eclipse.egit.feature.group Eclipse EGit GNU ARM PEMicro Interface Debugging Support 6.0.9.202509241532 com.pemicro.debug.gdbjtag.pne.feature.feature.group P&E Microcomputer Systems Inc. Memory Analyzer 1.15.0.202311170814 org.eclipse.mat.feature.feature.group Eclipse Memory Analyzer Nebula Grid Widget 1.1.0.202303072132 org.eclipse.nebula.widgets.grid.feature.feature.group Eclipse Nebula net.sourceforge.ehep 1.1.0 net.sourceforge.ehep.feature.group Randallco and EHEP Team NXP GCC for Arm Embedded Processors 10.2 Build 1728 1.0.0.202508270740 com.nxp.s32ds.brc.arm.tools.gcc102.feature.feature.group NXP NXP GCC for Arm Embedded Processors 11.4 Build 1763 1.0.0.202508271006 com.nxp.s32ds.brc.arm.tools.gcc114.feature.feature.group NXP PEmicro ARM Device Expansion Plugin 6.0.9.202509241532 com.pemicro.debug.gdbjtag.pne.expansion.feature.feature.group P&E Microcomputer Systems Inc. Remote Services 11.4.0.202309142347 org.eclipse.remote.feature.group Eclipse CDT Remote System Explorer End-User Runtime 4.5.500.202305261020 org.eclipse.rse.feature.group Eclipse TM Project RTD S32K3XX 6.0.0.202506161748 com.nxp.RTD.S32K3XX.feature.feature.group NXP Semiconductors, Inc. RTD S32K3XX 6.0.0.202506161748 com.nxp.RTD.S32K3XX.root.feature.feature.group NXP Semiconductors, Inc. S32 Debugger Core 3.6.5.202511272018 com.nxp.s32ds.brc.debugger.core.feature.feature.group NXP S32 Design Studio CLE S32CT 1.8.9.202511261304 com.nxp.s32ds.cle.uct.feature.feature.group NXP S32 Design Studio for S32 Platform 3.6.5.202511272206 com.nxp.s32ds.platform.ide.feature.feature.group NXP S32 Design Studio for S32 Platform Tools 3.6.5.202511272206 com.nxp.s32ds.platform.ide.tools.feature.feature.group NXP S32DS Product 3.6.4.202509291703 com.nxp.s32ds.platform.ide.product NXP S32G development package 3.6.4.202509291633 com.nxp.s32ds.s32g2.dev.feature.feature.group NXP S32K1xx development package 3.6.5.202511272256 com.nxp.s32ds.s32k1.dev.feature.feature.group NXP S32K3 FreeMASTER Serial Communication Driver 1.4.2.202412201001 com.nxp.s32ds.s32k3.sdk.freemaster.feature.feature.group NXP S32K3xx development package 3.6.4.202509291639 com.nxp.s32ds.s32k3.dev.feature.feature.group NXP S32M2xx development package 3.6.4.202509291626 com.nxp.s32ds.s32m2.dev.feature.feature.group NXP S32N5 development package 3.6.4.202509291626 com.nxp.s32ds.s32n.dev.feature.feature.group NXP S32R41 development package 3.6.4.202509291624 com.nxp.s32ds.s32r41.dev.feature.feature.group NXP S32R45 development package 3.6.4.202509291624 com.nxp.s32ds.s32r45.dev.feature.feature.group NXP S32R47 development package 3.6.4.202509291625 com.nxp.s32ds.s32r47.dev.feature.feature.group NXP S32Z2/E2 development package 3.6.4.202509291631 com.nxp.s32ds.s32esz.dev.feature.feature.group NXP SAF85xx development package 3.6.4.202509291625 com.nxp.s32ds.saf85.dev.feature.feature.group NXP SAF86xx development package 3.6.4.202509291626 com.nxp.s32ds.saf86.dev.feature.feature.group NXP SECRDR S32K1 3.0.0.202508081221 com.nxp.SECRDR.S32K1.feature.feature.group NXP Semiconductors, Inc. Terminal (Console) View 11.4.0.202311142324 org.eclipse.tm.terminal.view.feature.feature.group Eclipse CDT TM Terminal 11.4.0.202309142347 org.eclipse.tm.terminal.feature.feature.group Eclipse CDT TM Terminal Control 11.4.0.202311142253 org.eclipse.tm.terminal.control.feature.feature.group Eclipse CDT TM Terminal Local Connector Extensions 11.4.0.202309142347 org.eclipse.tm.terminal.connector.local.feature.feature.group Eclipse CDT TM Terminal SSH Connector Extensions 11.4.0.202309142347 org.eclipse.tm.terminal.connector.ssh.feature.feature.group Eclipse CDT Xtend Library 2.33.0.v20231121-0955 org.eclipse.xtend.lib.feature.group Eclipse Xtext   Re: PEmicro Connection Assistant Issue on S32K3X4EVB-T172 嗨,@zaighamkhawaja、 感谢您提供的补充信息。 如果您能连接外部调试器,请向我提供最新信息。 空白项目或示例项目会出现这种情况吗?作为最后的机会,您是否尝试过连接 MCU 而不是尝试调试/擦除? 这让我相信,要么安装了 HSE,要么调试端口被锁定,需要通过密码或 "挑战/响应 "来解除安全保护。PEmicro 提供 Python 脚本,用于 在每次会话开始时验证 调试器;但 需要输入密码。 最后一个资源可以是交换 MCU 以确认调试接口是否有故障,或者 MCU 是否处于安全/禁用调试引脚。 致以最诚挚的问候, Julián Re: PEmicro Connection Assistant Issue on S32K3X4EVB-T172 - 外部 JTAG 调试器正常工作。 - 空项目或样本项目也不起作用。 - 附加到运行目标不起作用。 我还购买了另一块板,它可以与板载调试器一起使用,因此与 IDE 或配置设置无关。
記事全体を表示
CLRC66301B 掉电模式仍消耗 2 mA 而不是 nA 您好,恩智浦社区 我正在使用 CLRC66301B NFC 读卡器IC 并尝试通过将 PDOWN 引脚设为高电平来激活掉电模式 (3.3)V),详见数据手册。但是,电流消耗保持在2 mA,而数据表显示掉电时电流消耗应在8 nA至40 nA之间。 设置详情: PDOWN 引脚:3.3 V(恒定高电平) VDDs:VDD(TX)、VDD(AUX)、VDD(MCU)电压均为 3.3 V 接口:I²C(测试期间空闲) XTAL:连接 27.12 MHz 晶体 当前测量期间无通信或活动 测量电流: ~2 mA 问题 1.在断言 PDOWN 之前是否需要对寄存器进行配置? 2。IRQ、XTAL、IFSEL 或其他 GPIO 能否阻止进入真正的掉电模式? 3.PDOWN 是否需要使用 VDD 或 RESET 进行额外的定时或排序? 如有任何见解或建议,我们将不胜感激。 谢谢! 乌玛桑卡尔 NFC 控制器解决方案 Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA 您好, 当您提到当 SDA 和 SCL 物理断开时电流消耗会降低时,是指您移除了该引脚上的所有连接(同时移除主机 MCU 和上拉电阻器),还是指这些线路仅与主机 MCU 断开? 另外,能否请您描述一下测量所用的方法、设备和测试点? Eduardo。 Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA 亲爱的恩智浦团队 我使用带有 CLRC66303B 芯片的官方 CLEV6630ARD 板进行了掉电电流测试。只有在进行任何 I²C 通信之前物理断开 SDA 和 SCL 时,电流才会达到 ~40 nA。如果使用一次 I²C,即使将 PDOWN 设为高电平,电流也会保持在 2 mA 以上。 请说明在进入 PDOWN 之前,I²C 线路应该做些什么?具体来说 在断言 PDOWN 之前,MCU 是否应将 SDA 和 SCL 设置为高阻抗(输入,无拉)? 之前的任何 I²C 通信是否会阻止芯片进入真正的硬掉电? 谢谢! Follow-Up: CLRC66303 – High Current in Hard Power-Down Mode (CLEV6630ARD-Based Design) 亲爱的恩智浦团队 我之前曾就 CLRC66301HN 的硬掉电电流提出过问题,你的回复建议迁移到 CLRC663 Plus 系列 (CLRC66303)。此后我改用 CLRC66303B,使用基于 CLEV6630ARD 参考设计的定制板,我想继续提供最新的测试结果。 你之前的回复侧重于 LPCD 行为和 AN11783,但这个问题仅涉及通过 PDOWN 引脚进行硬掉电,没有RF场或 LPCD 处于活动状态。 掉电电流测量 (CLRC66303B): > 当 PDOWN 处于低电平时(芯片处于活动状态,RF场 开启):~100 mA >当 PDOWN 为高电平且存在 I²C 上拉时:~1.2 mA >当 PDOWN 为高且 I²C 线路被驱动为低时: ~6.6 mA >当 PDOWN 为高电平且 I²C 线路在使用前已物理断开时:~40 nA 只有在进行任何 I²C 通信之前物理断开 SDA 和 SCL 连接时,芯片才会在 PDOWN 模式下消耗 ~40 nA 电流。如果只使用一次 I²C,则即使在 PDOWN 钳位高电平之后,电流仍保持高电平。 硬件设置摘要: 芯片:CLRC66303B,I²C 模式。 微控制器:TI CC2652R7,100 kHz I²C 电压:3.3 V 调节 上拉:SDA/SCL 上 4.7 kΩ 至 3.3 V 未使用的引脚:按照数据表拉动 未启用射频或 LPCD 功能 方案设计:基于 CLEV6630ARD(附后) 需要澄清的问题: 1.在 PDOWN 模式期间,SDA/SCL 是否内部偏置? 2。即使后来将PDOWN设置为高电平,之前的任何I²C活动是否会阻止真正的掉电? 3.在断言 PDOWN 之前,是否有必要将 MCU I²C 引脚设置为 Hi-Z(输入,无拉)? 4.是否有恩智浦推荐的方法,可在硬 PDOWN 模式下可靠地实现<100 nA,而无需物理断开 I²C 线路? 我们的目标是确保电池的使用寿命,并且必须实现数据手册中规定的低功耗性能。如果有任何专门关于 PDOWN 行为和 I²C 漏电流的指导或文档,我们将不胜感激。 附上示意图以供参考。 顺祝商祺! Umasankar C Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA 你好@Umasankarc 希望你一切顺利。 我知道你使用的是基于 CLRC66301HN(非增强版)的自定义板,对吗?如果是,请考虑我们建议改用 CLRC663 plus 系列 (CLRC66303)。 引脚 PDOWN 的高电平应启用硬掉电。数据手册中描述的掉电电流 (Ipd) 相当于 CLRC663 芯片中所有电源电流的总和;但是,嵌入在板中的外部元器件可能会消耗额外的功率。 AN11783 CLRC663 plus《电源卡检测》第 3.4 节中描述了一些低功耗设计建议。 Eduardo。
記事全体を表示
i.MX RT700 eIQ Neutron NPU Lab Guides These lab guides provide step-by-step instructions on how to take a quantized TensorFlow Lite model and use the Neutron Compiler Tool found in eIQ Neutron SDK to convert the model to run on the eIQ Neutron NPU found on i.MX RT700 devices.  The eIQ Neutron NPU for i.MX RT700 Lab Guide documents focus on using the Neutron Compiler tool found inside eIQ Neutron SDK  to convert a model and then import that converted model into an eIQ MCUXpresso SDK example. There are labs for VSCode, GCC, and MCUXpresso IDE.  The labs were designed to run on the i.MX RT700 EVK, but the same concepts can be applied to MCX N boards as well and are similar to the MCX N eIQ Neutron NPU labs. You can also explore the TFLM Getting Started Guide for information on how to use your own model and data for inference.  Also be sure to check out AN14700 - i.MX RT700 eIQ Neutron NPU Enablement and Performance which goes into more details on the eIQ Neutron N3-64 NPU found on i.MX RT700.  The VS Code is copied below but is also included as an attached PDF below as well as labs for using ARM GCC and MCUXpresso IDE.  1                 Lab Overview This document will cover how to convert models using NXP’s eIQ Neutron SDK and will also highlight the performance improvements that can be achieved with the eIQ Neutron NPU. This version of the lab will use VSCode. If using command line GCC or MCUXpresso IDE see those versions of the lab. 2               Software and Hardware Installation This section will cover the hardware and software needed for this lab. 2.1 Hardware The i.MX RT700 EVK is used in this lab. 2.2 NXP Software Installation Download the latest eIQ Neutron SDK Install VSCode. Install the latest MCUXpresso for VSCode plugin. Run the MCUXpresso Installer tool and install three key components: MCUXpresso SDK Developer Arm GNU Toolchain LinkServer anthony_huereca_0-1786510346209.png anthony_huereca_0-1787639704899.png Download a quantized Mobilenet TFLite model that can be found here and rename it to mobilenet_quant.tflite on your hard drive. Install the latest LinkServer CMSIS-DAP debug firmware on your board by putting a jumper on JP20, unplugging and plugging in the micro-USB cable on J54, and running the C:\NXP\LinkServer_ \MCU-LINK_installer\scripts\program_CMSIS.cmd script. Then remove the jumper and do a power on reset. 3               Label Image Example This section will use the eIQ Label Image example found in the MCUXpresso SDK to showcase how the eIQ Neutron NPU can significantly decrease inference times for quantized models. 3.1 Convert Models Use eIQ Neutron SDK to convert a pre-existing Mobilenet model into a Neutron optimized model. Download a quantized Mobilenet TFLite model that can be found here and rename it to mobilenet_quant.tflite on your hard drive. Unzip the eIQ Neutron SDK package in a directory of your choosing. Optionally add \eIQ_NeutronSDK_ \bin to your executable path so that the neutron-compiler utility can be directly called from the command line.        Then use the following command to do the conversion (all one line): neutron-compiler --dump-header-file-output --dump-header-file-input  --target imxrt700 --use-sequencer --input mobilenet_quant.tflite --output mobilenet_npu.tflite anthony_huereca_1-1786510372263.png These options will generate a C array of both the converted model and the input model, which we’ll use to compare the performance of them. In typical situations you would only need the dump-header-file-output option though. This command also directed the convertor to use sequencer mode which can result in faster inference times with the tradeoff of a larger model. Also note that starting in eIQ Neutron SDK 3.2.1, the neutron-converter tool was renamed to neutron-compiler. 3.2 View Models After conversion, you can explore the models using a tool like Netron. Take a moment to look at the original model compared to the new converted model. The original TFLite file: mobilenet_quant.tflite anthony_huereca_2-1786510380913.png The Neutron converted file: mobilenet_npu.tflite anthony_huereca_3-1786510387349.png You can see how almost all the operators in the original model were replaced with a NeutronGraph operator. Those NeutronGraph operaters are what will be executed on the eIQ Neutron NPU when this model is ran on the i.MXRT700. Any layers that were not converted to a NeutronGraph operator will instead be ran on the Cortex-M33 core. Take a look at the file size of each of the .tflite files and you can see that, in general, the NPU converted file will take up less flash space. Note that this might be counter-acted by the slightly increased size required for using the eIQ Neutron libraries. During the conversion process the dump-header-file-output argument generated the .h header file for the NPU optimized model that can be used in the eIQ MCUXpresso SDK projects. The dump-header-file-input argument generated the .h header file for the original non-converted model. This will be used so the inference time of the original model that only runs on the Cortex-M33 core can be compared to the NPU converted model that makes use of the eIQ Neutron NPU. So let’s run these models to see the performance improvements.   3.3 Modify an eIQ Example to Run Models Now let’s use the MCUXpresso SDK eIQ Label Images example to run the models and see how long the inference time is. Open VSCode Go to the MCUXpresso for VSCode plugin and click on Import Repository anthony_huereca_4-1786510398165.png Go to the Remote Archive tab. It may take a bit for the list of packages to populate. Once it does, type in for RT700 in the Package field to select the MIMXRT700-EVK. Select the latest SDK version and then select a directory to download the MCUXpresso SDK into. Agree to the license and then finally click on Import. It will take several minutes to download and extract the SDK package. This time can be reduced by unchecking the Create Git repository option if not needed. Also ensure MUCXpresso SDK 26.06 or later is used as there are several important VS Code issues fixed in that version. anthony_huereca_5-1786510404488.png Next import an eIQ example project. In the Quickstart Panel, select Import Example from Repository anthony_huereca_6-1786510411278.png Then on the screen that pops up, select the RT700 repository that was downloaded in the previous step. In the Template field type in label_image to search for the eiq_examples/tflm_label_image_cm33_core0 project. Then change the App type to Freestanding application. Then select a directory location to import the project into. And then select the Arm GNU Toolchain that was installed as part of the MCUXpresso Installer. Finally click on Import. anthony_huereca_7-1786510418890.png A pop-up will come up that asks if you trust the authors of the files in this folder. Click on Yes. anthony_huereca_8-1786510425633.png It should look like the following when done. Make sure the Project Files looks similar to the image below which should be the case if the Freestanding option was used when importing the project: anthony_huereca_9-1786510432167.png Now we need to import the models that were generated in the last section into this project. Navigate down to the Project Files folder and inside the tflm folder right click on model.cpp and then select Reveal in File Explorer to open the location of that file on your hard drive. anthony_huereca_10-1786510437757.png Now copy and paste the two .h header files that were generated in the previous section into this file location. It should look like the following when complete: anthony_huereca_11-1786510444462.png Back in VSCode, hover your mouse over the Projects name and then hit the Refresh icon to get the two new header files to appear in the Project Files list. anthony_huereca_12-1786510454038.png Note that simply having the files in the Project Files view does not mean they will automatically be included in the project. As they are header files no further changes are needed, but if C or CPP files are added to a VSCode project then other configuration files would also need to be updated. No change is needed here. This is just for informational purposes only. Now we need to slightly modify those two header files to add some information for the eIQ MCUXpresso SDK project that describe how much memory this model will require and to describe some of the normalization values that this model uses: In the pcq_npu folder open model_data.h, which contains the default model for this example. anthony_huereca_13-1786510459397.png In model_data.h and find the following section of code and copy it. Be sure to include the array declaration. anthony_huereca_14-1786510470892.png Then in mobilenet_quant.h copy that code above the array, overwriting the default #defines above the array. Make sure not to erase the commented lines at the top of the file as those comments will be used later.          anthony_huereca_15-1786510489494.png Do the same steps to update mobilenet_ npu.h as well After changing both files, now double click on model.cpp to open it. anthony_huereca_16-1786510501059.png Go to line 27 and change it to point to the non-NPU accelerated model in mobilenet_quant.h. It should look like the following after changed:  anthony_huereca_17-1786510506933.png Next look at line 55 in that same model.cpp file to find where the model is loaded by the TFLM inference engine using the C array name model_data. Because the model array name in the new header file is the same as the original header file we replaced, no change is needed here. This is just for informational purposes only. anthony_huereca_18-1786510512561.png Likewise, the image data that will be fed into the model can be found in source image_data.h file contains an array of the binary data from the Stopwatch image found in stopwatch.bmp. No change is needed here. This is just for informational purposes only. anthony_huereca_19-1786510521373.png 3.4 Compile and Run Compile the project by hovering your mouse over the project name and then clicking on the Build Project icon.   anthony_huereca_20-1786510525894.png Connect a USB micro B cable from your computer to the USB port on the i.MX RT700 EVK at J54. Also ensure that JP1 and JP3 are shunted on the board and that SW10 has pin 1 OFF and pin 2 ON anthony_huereca_21-1786510535725.png anthony_huereca_22-1786510540192.png Open TeraTerm or other serial terminal program, and connect to the virtual COM port that board enumerated as when you plugged in the USB cable (your COM number will likely be different than the screenshot). Use 115200 baud, 1 stop bit, no parity. There is a built-in serial terminal in VSCode that can be used for this. Click on Start Monitoring to connect:      anthony_huereca_23-1786510547583.png Then in VSCode hover your mouse over the project name and click on Debug anthony_huereca_24-1786510554219.png You should see VSCode connect and download the program to your board in the Console tab. Once complete, it will pause at the start of main(). Hit the Resume icon  to run the program and look at the Serial Monitor tab. anthony_huereca_25-1786510561242.png When you run the project, if you look at the terminal output, it looks like there’s an error that we’ll fix in the next step: Didn't find op for builtin opcode 'CONV_2D' anthony_huereca_26-1786510567902.png Stop the debugger by clicking on the red square in the debug panel anthony_huereca_27-1786510573274.png This error was done on purpose in this lab, to demonstrate that when changing models, the list of operators needs to be updated as well. To fix the error, open the model_mobilenet_ops_npu.cpp file in the pcq_npu folder                 anthony_huereca_28-1786510578901.png Inside the MODEL_GetOpsResolver function is a list of operators. If you open the mobilenet_quant.h header file you’ll also find a list of operators used by the model in the comment block at the top of the file. anthony_huereca_29-1786510584088.png Copy that list from mobilenet_quant.h into the MODEL_GetOpsResolver function in model_mobilenet_ops_npu.cpp to replace the variable declaration and the original list. anthony_huereca_30-1786510602975.png Recompile and reprogram the board using the previous steps. You should now see the following on the serial terminal: anthony_huereca_31-1786510608936.png Stop the debugger by clicking on the red square anthony_huereca_32-1786510615586.png Now we’ll run the program again, but this time with the Neutron NPU accelerated version of the model. Re-open model.cpp and this time change line 27 to point to the Neutron NPU converted version of the model in the mobilenet_ npu.h file: anthony_huereca_33-1786510622508.png Re-open model_mobilenet_ops_npu.cpp and update the MODEL_GetOpsResolver function with the variable declaration and the operators listed in the comment block of the mobilenet_npu.h file. Note that the operators needed here may change depending on the Neutron Compiler version. anthony_huereca_34-1786510631401.png Build and program the program as before. However there’s now another error with a “Microcode version mismatch”. The model output also has the wrong answer for the image. This is because the Neutron libraries included by default in MCUXpresso SDK 26.06 are for eIQ Neutron SDK 3.1.1 but we used a newer eIQ Neutron SDK to convert our model. anthony_huereca_35-1786510645979.png The default library version can be confirmed by looking at the default model data in model_data.h where it shows it was converted using an older version.  anthony_huereca_36-1786510650993.png But the model that was converted as part of this lab used a newer Neutron Compiler version anthony_huereca_37-1786510654472.png To fix this error, the Neutron libraries used by this project need to be updated to the newer eIQ Neutron SDK version. Go to where eIQ Neutron SDK was unzipped and navigate to the eIQ_NeutronSDK_ \target\imxrt700 folder Then use VSCode to open the directory to copy those files by right clicking on the Project Files->mimxrt700evk_cm33_core0->cm33  folder and then select Reveal in File Explorer to open the location of that file on your hard drive.   anthony_huereca_2-1787639778651.png Then overwrite the files from the eIQ Neutron SDK folder into your project: File Name Source Directory in eIQ Neutron SDK Target Directory in Project libNeutronDriver.a target\imxrt700\rt700\cm33 \mimxrt700evk_cm33_core0\cm33 libNeutronFirmware.a target\imxrt700\rt700\cm33 \mimxrt700evk_cm33_core0\cm33 NeutronDriver.h target\imxrt700\driver\include\ \mimxrt700evk_cm33_core0\driver_include NeutronErrors.h target\imxrt700\common\include\ \mimxrt700evk_cm33_core0\include   Note: The target\imxrt700\driver\include\NeutronEnvConfig.h file and the libraries in target\imxrt700\cmodel are used by the ExecuTorch inference engine and so are not needed for this TFLM example. After the new Neutron libraries are copied over, clean the project to ensure the new libraries will be used Then recompile and debug the project as done before This time you should see the following on the terminal. That’s over a 100x improvement in inference time, with the same confidence percentage on this static image.   The decrease in inference time is very model dependent depending on how well that specific model could be optimized for the NPU. Due to the changes made as part of this lab inside the Repository directory, which is shared among SDK projects, other eIQ examples will also use the newer Neutron library now. This means those examples will not properly work as the default eIQ projects use a model converted with that earlier version of eIQ Neutron SDK. 4              Further Optimizations There are several items that can be further optimized for your particular model The terminal output also shows the TensorArena Size used for this model. The kTensorArenaSize variable that is set in mobilenet_npu.h can be adjusted accordingly to reduce the memory usage. This kTensorArenaSize variable is used to determine the size of the TensorArena memory buffer required by the model for scratch data during calculation. It is also estimated and printed out during the neutron-compiler output in the Total data field. However this estimate is often slightly smaller than the actual amount used, which is printed in the serial terminal during inference:     The power used while inferencing can be further reduced from the eIQ projects by turning off unnecessary clocks in active mode. See the power_comp_only SDK example. The NPU clock can also be turned off while not actively inferencing with: CLKCTL0->PSCCTL5_CLR |= (1UL << CLKCTL0_PSCCTL5_NPU0_SHIFT); The NPU module clock can be turned on right before the call to MODEL_RunInference() with: CLKCTL0->PSCCTL5_SET |= (1UL << CLKCTL0_PSCCTL5_NPU0_SHIFT); Always make sure to use the newest Neutron Compiler and libraries found in the most recently released eIQ Neutron SDK to get the latest performance improvements and model support. 5              Conclusion This lab demonstrated how the eIQ Neutron NPU can significantly decrease inference time on quantized models. These same steps can be used to benchmark other quantized models to see the performance improvements that the eIQ Neutron NPU can have.   --- Updated August 2026 for change of neutron-converter to neutron-compiler in eIQ Neutron SDK 3.2.1 release Hands-On Training
記事全体を表示
更新固件并擦除并重新编程 FRDM-KV31F <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我已经包含了批量擦除 MCU 闪存和重新编程另一个二进制文件所需的文件。 该过程显示在“ FRDM-KW31_FAT_added_2019 ”文件夹中 总结一下你... 1)使用引导加载程序模式更新调试器(按下重置并插入 USB 电缆)拖放 .sdaMSD 引导加载程序上的文件。 2)拔下并重新插入USB。通过将二进制文件拖放到虚拟大容量存储设备 FRDM-KV31 上来对 flashloader_loader_mkv31f512.bin 进行编程,当您将 USB 电缆从 FRDM-KV31 插入 PC 时,该设备就会出现。 3)打开 CMD 提示符窗口并导航到文件解压缩到的文件夹。 4)使用设备管理器确定COM端口 5)从 CMD 提示符运行批处理文件 Erase_KMS_program_bubble.bat COMX <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我已经包含了批量擦除 MCU 闪存和重新编程另一个二进制文件所需的文件。 该过程显示在“ FRDM-KW31_FAT_added_2019 ”文件夹中 总结一下你... 1)使用引导加载程序模式更新调试器(按下重置并插入 USB 电缆)拖放 .sdaMSD 引导加载程序上的文件。 2)拔下并重新插入USB。通过将二进制文件拖放到虚拟大容量存储设备 FRDM-KV31 上来对 flashloader_loader_mkv31f512.bin 进行编程,当您将 USB 电缆从 FRDM-KV31 插入 PC 时,该设备就会出现。 3)打开 CMD 提示符窗口并导航到文件解压缩到的文件夹。 4)使用设备管理器确定COM端口 5)从 CMD 提示符运行批处理文件 Erase_KMS_program_bubble.bat COMX
記事全体を表示
DwFシリコンバレー - 2015-03-26 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> オープニングセッション IoT エンド ノードの概念 設計、ソフトウェア、サービス スマートインダストリー " modifiedtitle="true" title="モータ制御のための効率的な熱管理 ヘルスケア&ウェアラブル " modifiedtitle="true" title="ウェアラブルを市場に投入する:プロトタイプから製品化まで スマートシティ " modifiedtitle="true" title="フリースケール・ワイヤレス・コネクティビティ・ポートフォリオの概要 スマートホームとスマートビルディング i.MX 6シリーズ用のビデオおよび画像コーデックとデータパイプライン 次世代 i.MX アプリケーションプロセッサ上のヘテロジニアスマルチプロセッシング(ARM® Cortex-A® + Cortex-M)の概要 Yocto プロジェクト™と i.MX アプリケーション プロセッサ向けの Linux® ソフトウェア開発 スマートネットワーク QorIQ LS1024A Consumer Network Attached Storage(cNAS)ソリューションによるパーソナル・クラウドの起動 デジタル・ネットワーキングのセキュリティ 101: QorIQ Communications Platform、QorlQ Qonverge Platform、C29x Crypto Coprocessor Family、Layerscape Architecture セキュリティ・エンジンとそのソフトウェア・イネーブルメントの概要 QorIQ T4240通信プロセッサの詳細 QorIQ LSシリーズ・プロセッサを使用した電力効率の設計方法 QorIQ Platformのトラスト・アーキテクチャの概要: ネットワーク・システムおよびネットワーキング・システムへのトラストの追加 Power Architecture®とARM®テクノロジのプログラム・モデルの違い QorIQプロセッシング・プラットフォームにおけるDDRの基礎 Sneak Peak: QorIQプロセッサの新機能 QorIQ通信プラットフォームおよびC29x暗号化コプロセッサ・ファミリ上のOpenSSL QorIQ T102xおよびLS10xxプロセッサを搭載した次世代IEEE® 802.11ac WLANシステム設計 ソフトウェア・デファインド・ネットワーキングとモノのインターネット(IoT)
記事全体を表示
Developing a Dual-Motor EV Control System with Model-Based Design Toolbox 1 Introduction This article series presents the Motor Control System (MCS) within an electric vehicle (EV) architecture. It introduces the end-to-end development flow, from controller and plant modeling to simulation, code generation, hardware deployment, and integration with the rest of the vehicle network. This opening article establishes the technical foundation for a series focused on the architecture, implementation, and integration of a dual-motor control system for EV traction applications. The series also shows how MathWorks tools can be used together with NXP software and hardware to support a Model-Based Design workflow. This approach helps engineers develop, verify, and deploy motor control applications more efficiently while maintaining traceability across the development cycle. Figure 1-1. Role of the Motor Control System within the EV traction domain 2 Table of Contents • Introduction • Overview • Context • References • Conclusion 3 Overview 3.1. What will this series of articles cover? The articles in this series define the development roadmap for the Motor Control System within a broader EV architecture. The series covers the following topics: Software and Hardware Environment - Overview of the MathWorks and NXP tools used to develop, test, and validate a dual-motor control system. Architecture and Model Description - Description of the model architecture, signal interfaces, and core control algorithms implemented in the Motor Control System. Model-in-the-Loop Development - Simulation of the controller and plant in Simulink to validate algorithms before code generation. Software-in-the-Loop Validation - Code generation for the validated controller and comparison of the generated software against the Model-in-the-Loop baseline. Processor-in-the-Loop Validation - Execution of the controller on NXP hardware while the plant remains simulated on the host system. Deployment and Validation on Real Hardware - Integration with physical hardware, scaling from single-motor to dual-motor operation, and configuration of the NXP MCU peripherals required for motor control. CAN Integration - Definition of the CAN communication interface, including database design and integration on the target NXP platform. Results and System Validation - Presentation of the final implementation results and validation of the complete system behavior. 3.2. What is the Motor Control System? Electric vehicles depend on traction systems that deliver efficient propulsion, accurate torque control, and safe operation. At the center of this functionality is the Motor Control System (MCS), which combines real-time control software, power electronics, sensing, actuation, and communication interfaces into a tightly coordinated embedded system. Figure 3-1. PMSM motor and controller as core elements of the traction system In modern EVs, the traction system delivers the torque and power needed to propel the vehicle. It is typically composed of the following elements: Electric motor - converts electrical energy from the battery into mechanical power at the wheels. Inverter system - converts DC energy from the battery into the controlled AC waveforms required by the motor. Transmission system - transfers the generated torque from the motor to the wheels. At its core, the Motor Control System regulates motor torque, speed, and position by controlling the voltage and current applied to the motor phases. A typical MCS includes the following functional layers: Control Algorithm - implements torque and current control strategies such as Field-Oriented Control (FOC). Sensing and Feedback - measures motor currents, voltages, rotor position, and temperature. Power Electronics - inverter circuitry that switches DC power into AC waveforms for motor drive. Embedded Processor - microcontroller executing real-time control loops. Communication Interfaces - CAN, LIN, or Ethernet for integration with other system modules. Together, these layers form a closed-loop control system that operates at high switching frequencies and under strict real-time constraints. Figure 3-2. Field-Oriented Control (FOC) architecture EV traction systems can be implemented using different architectures depending on the required balance of efficiency, performance, cost, and system complexity. A single-motor architecture uses one traction motor to drive either the front or rear axle. This approach reduces hardware complexity and cost, and it often improves vehicle range because of lower mass and lower overall energy consumption. A dual-motor architecture uses two independent traction machines that can be arranged in several drivetrain topologies. This configuration enables higher total power, better traction, improved vehicle dynamics, and stronger acceleration. The tradeoff is increased electrical and mechanical complexity, together with higher system cost. Figure 3-3. Example dual-motor traction architecture Advantages & Disadvantages of Dual Motor: Acceleration faster due to torque from both motors Superior traction and handling, especially in snow, rain or off-road conditions Slightly lower range due to increased weight and power consumption More expensive but can include AWD and performance benefits Advantages & Disadvantages of Single Motor: Slightly better range due to less energy consumption More affordable Moderate traction, suitable for most road conditions Slower acceleration Note: The example used throughout this series is based on a dual-motor rear-axle architecture, where each rear wheel is driven by its own motor. 3.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric drive systems, including the following audiences: Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Hardware Engineers Model-Based Design and Simulink Developers Academic and Research Communities 4 Context In the electric vehicle architecture presented in this series, the Motor Control System is located in the rear zone of the vehicle. Each rear wheel is driven by an independent Permanent Magnet Synchronous Motor (PMSM). The Motor Control System ECU coordinates both motors and exchanges real-time data with the rest of the vehicle over the CAN network. Figure 4-1. Motor Control System highlighted within the EV architecture The traction ECU is built around NXP's S32K396 microcontroller, which supports both single 6-phase motor control and dual 3-phase motor configurations. The inverter stage is driven by the MC33937 pre-driver, which provides three high-side and three low-side FET pre-drivers for automotive motor control applications. Note: The inverter receives DC power from the vehicle battery, while battery operation and safety are supervised by the Battery Management System. The Motor Control System communicates over CAN with the Zone Node controller, which in turn exchanges commands and status information with the main vehicle control node responsible for speed and torque requests. 5 References PMSM Control Workshop BLDC Control Workshop A Model-Based Design (MBDT) Environment for Motor Control Algorithm Development Deploy Motor Control Algorithms on NXP S32K3 from Simulink Motor Control Rapid Prototyping on NXP S32M2 with MathWorks and Model-Based Design Toolbox Next Generation of NXP EV Traction Inverter with S32K39 MCU and FS26 SBC AN14326: 3-phase Motor Control Kit with S32K396 Application Note AN13884: 3-phase Sensorless PMSM Motor Control Kit with S32K344 using RTD AUTOSAR API Application Note Advancing Motor Control Performance with Digital Twins Extended Range Dual-Motor Electric Vehicle Model 6 Conclusion This article introduced the Motor Control System within an EV architecture and established the technical context for the rest of the series. It explained the role of the Motor Control System, compared single-motor and dual-motor traction topologies, and outlined how a Model-Based Design workflow can be applied using MathWorks tools together with NXP software and hardware. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the Motor Control System using MathWorks and NXP solutions.
記事全体を表示
Choosing the Right FRDM Board for MCX A Series Selecting the Right FRDM Platform for MCX A Series A technical guide for mapping application requirements to MCX A evaluation hardware The MCX A series spans a wide range of MCU variants optimized for real-time control, precision sensing, motor control, and industrial connectivity. Because peripheral combinations and acceleration features vary significantly across subfamilies, selecting the appropriate FRDM board is critical for accurate prototyping and performance validation. This guide provides a device-to-board mapping along with architectural considerations to help engineers align hardware selection with system requirements. Design Considerations for Board Selection When choosing a FRDM platform for MCX A devices, evaluate: 1. Compute and Real-Time Requirements Use of SmartDMA for offloaded data movement Deterministic latency requirements (motor control, control loops) Availability of hardware accelerators (e.g., MAU) 2. Analog and Sensing Capabilities 16-bit ADC resolution and sampling throughput Dual ADC configurations for simultaneous sampling Sensor interface (UART/I2C/I3C/SPI) 3. Connectivity and System Integration CAN-FD for industrial/automotive networks FS USB for host/device applications and debug access Emerging interfaces (e.g., I3C) for modern sensor integration 4. HMI and Security Requirements SLCD support for low-power display use cases Hardware-based security features for connected edge nodes MCX A to FRDM Board Mapping Supported MCU(s) Recommended Board Best Fit For Key Differentiators MCX A13, A142, A143, A152, A153 FRDM-MCXA153 Cost-sensitive smart sensing and motor control FS USB, 16-bit ADC, compact entry platform MCX A144, A145, A146, A154, A155, A156 FRDM-MCXA156 Connected control, smart sensing, industrial HMI 1 MB Flash, FS USB, CAN-FD, FlexIO, 2x 16-bit ADC, I3C MCX A173, A174 FRDM-MCXA174 Balanced real-time control and connected sensing CAN-FD, SmartDMA, ADC, compact mid-tier platform MCX A175, A176, A185, A186, A255, A256, A265, A266 FRDM-MCXA266 Industrial HMI, secure connected sensing, USB-enabled control FS USB, SLCD, CAN-FD, FlexIO, SmartDMA, advanced security MCX A343, A344 FRDM-MCXA344 Cost-optimized motor control and smart sensing CAN-FD, MAU, SmartDMA/LCD expansion MCX A345, A346 FRDM-MCXA346 Advanced motor control and high-performance real-time designs 2x FlexPWM, MAU, SmartDMA, CAN-FD MCX A355, A356, A365, A366 FRDM-MCXA366 Industrial HMI, secure connected sensing, high-performance control FS USB, SLCD, CAN-FD, MAU, SmartDMA, FlexIO, advanced security Not all MCX A devices expose the same combination of ADCs, SmartDMA, MAU, or connectivity interfaces—and choosing the wrong evaluation board can limit what you can prototype. This article provides a clear mapping between MCX A families and FRDM platforms, helping you align hardware capabilities with system requirements. FRDM-MCXA MCU
記事全体を表示
FXTH87xx 最低功耗 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 大家好 我正在调试 FXTH870911 的功耗。 目前的最小电流为 98-115μA。 经过计算,目前的耗电量无法满足需求。 我想知道该芯片的最小工作电流是多少,以及它是如何实现的。 提前感谢! Re: FXTH87xx minimum power consumption <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好, 下面是 25°C 时的典型电流消耗: 您可以在设备数据表中找到停止模式的详细描述。 在项目中,如果选择了 LF_COMMUNICATION(通信)模式,则在 STOP1 中启用 LF 块。   模式的选择应在项目的 user_configuration.h 文件中进行。 在该文件中,可以选择三种不同的模式,一种使用 LF(LF_COMMUNICATION),另两种不使用 LF。 我建议选择 NO_LF_PWU 模式:在该模式下,FXTH 会定期唤醒以发送 RF 帧,在两次发送之间,FXTH 会转到 STOP1 并禁用低频。在这种模式下,两次射频传输之间的功耗应为 500nA。 顺祝商祺! 托马斯 PS:如果此答案有助于解决您的问题,请标记为"正确" 或 "有帮助"。谢谢。
記事全体を表示
S32K344 悬挂问题 MCU:S32K344 OS:FreeRTOS S32Design Studio:3.4.3 问题:MCU 因 I2C 写阻塞(无超时)而挂起 嗨,团队、 我们正在使用基于 S32K344 MCU 的定制板。我们面临的问题是,在某些I2C错误状态下,MCU在运行时挂起。 我们有一个通过 I2C 接口连接的 IMU 从属设备。偶尔,当 IMU没有供电,或 I2C 写入操作失败(例如,没有 ACK /总线卡住), I2C 写入 API不会返回或进入超时状态。结果,执行 I2C 事务的 FreeRTOS 任务被无限期地卡住,最终导致应用程序挂起。 意见: 当从机没有响应或总线保持在低电平时,就会出现问题。 I2C 驱动程序似乎阻塞,等待传输完成。 在 RTOS 或驱动程序级别上不会触发超时或恢复机制。 请求支持: 如何在 S32K344 上添加或强制执行I2C 事务超时? 有没有推荐的方法来恢复卡住的 I2C 总线(SDA/SCL 保持在低电平)? 在 S32K3 设备上的 FreeRTOS 下安全使用 I2C 的最佳做法是什么? 恩智浦是否有稳健处理这种情况的驱动程序配置或示例? 任何指导或参考将不胜感激。 谢谢& , Vinay Re: S32K344 Hanging issue 嗨,@vinaykl、 你的 RTD 已经很老了。 有什么原因吗? 从 RTD 2.0.0 到当前的 RTD 7.0.0,已经修复了许多错误。 我猜您使用的是 I2C 驱动程序的阻塞 API。 请使用异步传输 API 以及 GetStatus() 和超时。 如果从设备一直将 SDA 保持在较低水平,则可以将其恢复,请参阅 I2C 用户手册: 第 3.1.16 节总线畅通 https://www.nxp.com/docs/en/user-guide/UM10204.pdf   RTD 驱动程序没有用于恢复的 API。 AN4803 中的一个例子 I2C 恢复功能定义 https://www.nxp.com/docs/en/application-note/AN4803.pdf 此致, 丹尼尔
記事全体を表示
i.MX 91 - LPDDR4 内存兼容性指南 本文档的目的是为选择 i.MX 91 系列处理器支持的兼容 LPDDR4 内存设备提供扩展指导。在所有情况下,强烈建议遵循恩智浦硬件开发者指南中针对特定 SoC 概述的动态随机存取存储器(DRAM)布局指南。 二进制密度(例如 1 GB、2 GB、4 GB)的内存设备是首选,因为它们通过与系统寻址方案保持一致并降低软件复杂性来简化内存管理。 LPDDR4 - 最大支持密度 SoC 最大数据总线宽度 最大密度 假定内存组织 说明 i.MX 91 (i.MX 91xx) 16 位 16GB / (2GB) 具有 17 行地址的单列单通道设备(R0-R16) 1, 2, 3 LPDDR4 - 经过验证的存储器列表 验证过程是一项持续性工作--预计将定期更新表格。 SoC 密度 内存供应商 经过验证的内存部件编号 说明 i.MX 91 16GB / (2GB) 美光 MT53E1G16D1FW-046 AAT:A MT53E1G16D1ZW-046 AAT:C 5 2 Gb/(256 MB) Winbond W66BP6NBHAHJ 4 8GB / (1GB) 南亚 NT6AN512M16AV-J1I   4 Gb/(512 MB) 南亚 NT6AN256M16AV-J1I 4 8GB / (1GB) ISSI IS43LQ16512B-046BLI 4 12GB / (1.5GB) 美光 MT53E768M16D1ZW-046 4 16GB / (2GB) 智能存储器 IMAG16L4KBBG 4 2 Gb/(256 MB) 南亚 NT6AN128M16AV-J1 4 4 Gb/(512 MB) 联合信息中心 SCB11N4G160BF-04ZI 4 4 Gb/(512 MB) ISSI IS43LQ16256B-053BLI 4 4 Gb/(512 MB) Winbond W66CP6RBHAHJ 4 Note: This device supports operation with LPDDR4 memories only. LPDDR4x operation is not supported. Dual‑mode memories that support both LPDDR4 and LPDDR4x are allowed as long as the device can operate in LPDDR4 mode, including using LPDDR4 I/O voltage levels and initialization sequences. 注意:某些内存供应商的 LPDDR4 设备可能不支持低速运行,此外,DQ ODT 可能未处于活动状态,这可能会影响这些速度下的信号完整性。如果在用例中计划低速运行,请向内存供应商咨询内存设备的配置方面和可能的自定义,以确保功能正确。 注 1: 这些数字完全基于DDR控制器和DDR PHY的IP文档、为将其集成到SoC而选择的实现参数设置、SoC参考手册以及JEDEC标准 JESD209-4B(LPDDR4)。因此,除非另有说明,否则它们没有经过验证,也不能保证存储器供应商提供的 SoC 具有特定的密度和/或所需的内部结构。如果客户选择使用最大密度,并将其用于预期用途,则风险自负。 注 2: 不支持任何密度的字节模式 LPDDR4 设备(在两个芯片之间内部分配 x16 通道,每个 x8),因此,这些数字仅适用于内部组织 x16 的设备(在 JEDEC 规范中称为 " 标准 ")。 注 3: SoC 还支持双列单通道设备,因此,使用具有 16 行地址(R0-R15)的双列单通道设备也可以实现 16GB/2GB 的密度。 注 4: 该内存部件号没有经过 JEDEC 的全面验证,但通过了所有功能测试项目。 注 5: 该内存部件号不推荐用于新设计,已被新部件号取代
記事全体を表示