Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
IMX6Q U-Boot 您好,我有一台定制相机,搭载IMX6q处理器。 我有一个可以在旧版引导加载程序和旧版内核上运行的固件。 我需要更新引导加载程序和内核。 但我始终无法通过内核加载阶段。 UART 日志始终为空。 请帮忙。 Re: IMX6Q U-BooT 你好@CAT5000 希望你一切都好。 请指定当前 BSP 版本和新版本。 此外,您的软件更改与 UART 相关,其中 UART 已在控制台中定义。 顺祝商祺! 萨拉斯。 Re: IMX6Q U-BooT 您好! 实际上,我们有将我们的处理器移植到最新 BSP 版本的指南。 请参考UG10165 (i.MX 移植指南)。 这里描述了需要在 U-boot 中进行的更改。 另外,如果您有 Sabre 开发板,您可以直接从Embedded Linux for i.MX Applications Processors下载最新版本的预编译镜像,然后刷写到您的开发板上。 此致, 萨拉斯。 Re: IMX6Q U-BooT 工作引导加载程序版本 U-Boot 2018.03(2021年4月22日 - 04:17:10 -0400) CPU:Freescale i.MX6Q rev1.3 996 MHz(运行频率为 792 MHz) CPU:汽车级温度等级(-40℃至125℃),工作温度30℃ 复位原因:POR 型号:飞思卡尔 i.MX6 Quad SABER 智能设备板 板:MX6-SabreSD 已启用看门狗 动态随机存取存储器(DRAM):2 GiB PMIC:PFUZE100!开发版本号=0x10 版本号=0x21 MMC:FSL_SDHC:0,FSL_SDHC:1,FSL_SDHC:2 从MMC加载环境... 卡未响应电压 我的主板是参考板,搭载 SabreSD 卡。 我拥有所有原理图和数据。 我不擅长这类任务,但我很想更新固件,体验一下新功能。
記事全体を表示
セーフティマニュアル、セーフティアプリケーションノート、S32_SPDソース/試験パッケージの請求 NXPサポートチームの皆さん、こんにちは。 私はNDAに署名し、NXPのウェブサイトでセーフティアクセス権を得ています。しかしながら、S32K388に関する以下の文書をまだ見つけることができません。 |# |文書 | |---|----------| |1 |S32K3xx 安全マニュアル | |2 |S32K3xx 安全アプリケーションノート | |3 |S32K3xx FMEDA / DFA(利用可能な場合) | |4 |S32K388 安全補足(該当する場合) | 直接ダウンロードリンクを教えていただけるか、これらの書類を私のメールに送っていただけませんか? ご助言ありがとうございます。 よろしくお願いします、 xlele Re: Request for Safety Manual, Safety Application Note, and S32_SPD Source/Test Packages こんにちは、 xleleさん。 ご不便をおかけして申し訳ありません。ダウンロードリンクや文書自体をお客様に送ることは許可されていません。お客様は NXPのウェブサイトからダウンロードする必要があります。 SECURE ACCESS RIGHTSを取得したことを必ず確認してください。 1. S32K3xx セーフティ マニュアル 4. S32K3xxセーフティマニュアルの添付ファイルからAddendum_S32K3xx.xlsx を探してください。 2. あなたがどの文書について言及しているのか、私にはよく分かりません。同じ場所で「安全アプリケーションノート」に似た文書を探してください。 3. 「S32K388 FMEDA」というキーワードで対応する文書を見つけることができます。 よろしくお願いいたします ロビン
記事全体を表示
请求提供功能安全手册、功能安全应用笔记和 S32_SPD 源/测试软件包 您好,NXP支持团队, 我已经签署了保密协议,并获得了恩智浦网站的功能安全访问权限。但是,我仍然无法找到以下与 S32K388 相关的文档: | # | 文档 | |---|----------| | 1 | S32K3xx 功能安全手册 | | 2 | S32K3xx 功能安全应用说明 | | 3 | S32K3xx FMEDA / DFA(如有) | | 4 | S32K388 功能安全附录(如适用) | 请问能否提供直接下载链接或将这些文件发送到我的邮箱? 感谢您的帮助。 此致, xlele Re: Request for Safety Manual, Safety Application Note, and S32_SPD Source/Test Packages 你好xlele, 带来不便敬请谅解。我们不允许向客户发送下载链接或文件本身。客户需要从恩智浦网站下载。 请确认您已获得安全访问权限。 1. S32K3xx 功能安全手册 4. 请从 S32K3xx 功能安全手册的附件中找到Addendum_S32K3xx.xlsx 。 2. 我不确定您指的是哪份具体文件。请在同一位置查找与“功能安全 应用笔记”类似的文档。 3. 您可以通过搜索关键词“S32K388 FMEDA”找到相应的文档。 此致敬礼, Robin
記事全体を表示
Request for Safety Manual, Safety Application Note, and S32_SPD Source/Test Packages Hi NXP Support Team, I have signed the NDA and been granted Safety Access on the NXP website. However, I am still unable to locate the following documents for S32K388: | # | Document | |---|----------| | 1 | S32K3xx Safety Manual | | 2 | S32K3xx Safety Application Note | | 3 | S32K3xx FMEDA / DFA (if available) | | 4 | S32K388 Safety Addendum (if applicable) | Could you please provide the direct download links or send these documents to my email? Thanks for your help. Best regards, xlele Re: Request for Safety Manual, Safety Application Note, and S32_SPD Source/Test Packages Hi xlele, Sorry for the inconvenience. We are not permitted to send download links or the documents themselves to our customers.  Customers need to download it from the NXP website. Please confirm that you have obtained SECURE ACCESS RIGHTS. 1. S32K3xx Safety Manual 4. Please find the Addendum_S32K3xx.xlsx from the Attachments to the S32K3xx Safety Manual. 2. I'm not sure which specific document you're referring to. Please look for a document similar to "Safety Application Note" in the same place. 3. You can find the corresponding documents by searching for the keywords "S32K388 FMEDA". Best Regards, Robin
記事全体を表示
i.MX943 S2R Resume Time Regression from LF6.12 to LF6.18 BSP: Root Cause and Workaround Platform: i.MX943 | Kernel: Linux 6.18 (LF6.18 BSP) | Category: Power Management Overview If you have migrated from LF6.12 to LF6.18 on i.MX943 and noticed that your board takes significantly longer to resume from Suspend-to-RAM (S2R), this article explains why the behavior changed, what is behind it, and what you can do to reduce the observable latency. Observed Symptom On the IMX943LP5EVK-19, the total resume latency — measured from the ONOFF key (SW5) falling edge to a GPIO toggled in user space — differs noticeably between the two BSP releases: Scenario LF6.18 LF6.12 Default BSP (PCIe enabled) ~3420 ms ~1420 ms PCIe disabled ~1060 ms ~257 ms Delta (PCIe on vs. off) ~2360 ms ~1163 ms The data shows that PCIe is the dominant contributor to the extra resume time in LF6.18. Additionally, a ~500 ms gap was observed between the kernel log messages  Restarting tasks: Done  and  random: crng reseeded on system resumption , indicating a secondary delay in the post-resume path. Root Cause Primary Cause — PCIe FLR Moved to the Resume Path A critical bug fix was introduced in LF6.18 to address a system panic during suspend on i.MX943 when PCIe-attached ENETC Ethernet ports were active. Before the fix (LF6.12): The ENETC driver called  pcie_flr()  (PCIe Function Level Reset) during the suspend phase. Under certain timing conditions,  pci_pm_suspend_noirq()  would access the PCIe device before the FLR had completed, causing a call trace and system reboot. This is a real, critical bug — though not consistently reproducible without specific peripheral configurations. What the fix does (LF6.18): To eliminate the race condition, the FLR was moved from the suspend path to the very beginning of the resume path. This is the correct and safe approach, but it comes with a latency cost: pcie_flr()  internally uses  msleep() , an asynchronous sleep that adds >100 ms of delay per call. On i.MX943, multiple ENETC ports are present. Since these FLR operations execute sequentially, the delays accumulate — resulting in the ~2360 ms overhead observed with PCIe enabled. Important: The LF6.12 resume time measurements were taken against a kernel with a latent suspend panic bug. Those numbers do not represent a stable baseline. The LF6.18 figures reflect correct, stable behavior. Secondary Cause — Post-Resume Entropy Reseeding Delay A ~500 ms delay between  Restarting tasks: Done  and  random: crng reseeded on system resumption  was also identified. This is caused by the kernel's random number generator (CRNG) reseeding process briefly blocking after tasks are unfrozen during resume. Why This Cannot Simply Be Reverted Reverting the PCIe FLR fix to recover the LF6.12 resume speed would re-expose the system to random panics during suspend — an unacceptable trade-off for any production design. The longer resume time is therefore an intentional and necessary consequence of making suspend/resume reliable on i.MX943. Recommended Workaround To address the secondary ~500 ms CRNG reseeding delay, write  1  to  /sys/power/freeze_filesystems  before entering suspend: echo 1 > /sys/power/freeze_filesystems echo mem > /sys/power/state This has been confirmed to eliminate the post-resume entropy delay. Note: Investigation also shows that the PCIe-related portion of the resume overhead (~2360 ms) is attributable to sequential FLR execution across multiple ENETC ports. Parallelizing these operations is a potential future optimization, but no timeline is committed at this point. How to Measure Resume Latency on Your Board Use the following script on i.MX943 to reproduce the measurement: # Configure GPIO_IO31 as output, pull down /unit_tests/memtool -32 0x43810044=0x80000000 /unit_tests/memtool -32 0x43810054=0x80000000 /unit_tests/memtool -32 0x43810040=0x0 # Enter suspend echo mem > /sys/power/state # After wakeup (press ONOFF/SW5), pull GPIO_IO31 high /unit_tests/memtool -32 0x43810040=0x80000000 Measure the interval between the ONOFF falling edge and the GPIO rising edge using an oscilloscope or BCU power tool. Summary Item Detail Affected platform i.MX943 (IMX943LP5EVK-19) Affected BSP LF6.18 and later Primary cause PCIe FLR moved to resume path to fix suspend panic Secondary cause CRNG reseeding delay (~500 ms) post-resume Recommended workaround echo 1 > /sys/power/freeze_filesystems PCIe resume overhead ~2360 ms (sequential FLR across ENETC ports) — by design The increased resume time in LF6.18 is expected behavior resulting from a necessary stability fix. The LF6.12 baseline was measured against a kernel with a latent suspend panic bug and should not be used as a performance reference. Upgrading from LF6.12 to LF6.18 on i.MX943 brings a noticeable increase in S2R resume latency — from ~1420 ms up to ~3420 ms under default BSP configuration. This is not a regression to be fixed, but an intentional consequence of a critical suspend panic fix introduced in LF6.18. This article explains the root cause behind the PCIe FLR timing change, the secondary CRNG reseeding delay, and provides a confirmed workaround to reduce observable resume time. i.MX Processors
記事全体を表示
S32G2 M7 implementation of PFE Ethernet through SerDes and SJA1110 on RDB2 Recently, some customers have requested that PFE be used together with SerDes and SJA1110 Switch on S32G2 M7. However, the existing PFE driver routines do not have the implementation for this function. Therefore, this article mainly aims to achieve this function, mainly completing the configuration and application of SerDes, as well as joint use with SJA1110 Switch application for the S32G2 M7 on the RDB2 board. This document can serve as a reference for customers and developers who intend to apply PFE + SerDes + SJA1110, especially for applications requiring SGMII connectivity between the processor and an external automotive Ethernet switch. This article is based on the PFE driver demo of MasterProject_RDB2 and has made some corresponding application modifications and explanations to achieve it. It is expected that this document will be useful for developers working on similar applications. S32G
記事全体を表示
How to do NAN test on 2 IW612 modules with I.MX93-EVK What is NAN? Neighbor Awareness Networking (NAN), also known as Wi-Fi Aware, is a mechanism defined by the Wi-Fi Alliance. NAN is an additional Wi-Fi interface to micro-AP (uAP), Station (STA), and Wi-Fi direct (wfd) that allows for quick discovery without the connection-association flow. The interface named: nan0.In this demo test, NAN is used to Wi-Fi locate and/or range. NXP Wi-Fi Products Supports NAN: Currently we have our IW612, IW611,AW611 and AW693 support NAN feature on Linux OS, and the remote devices should also be Linux OS or Android OS. Currently we do not support for remote device which running iOS. Below is the Release Notes showing which product in our NXP supports NAN feature. https://github.com/nxp-imx/mwifiex/blob/doc_WCT_release/doc/Release_Notes/Linux_RN/topics/wi_fi_radio.md Caution: There is typo in above release note. Actually IW610 doesn't support NAN feature. Demo setup: In this doc, the test is based on 2 IW612 module: Murata 2EL M.2 module on I.MX93-EVK which is running Linux OS, the Linux kernel is L6.12.49. IW612's driver and FW version is: SDIW612---18.99.8.p3--MM6X18542.p8-(FP92), and the nanapp in this release could not outout wls message, official working nanapp will be in next release, available in the end of March/2026. wifi_mod_para.conf SDIW612 = { cfg80211_wext=0xf max_vir_bss=1 cal_data_cfg=none ps_mode=2 auto_ds=2 host_mlme=1 drv_mode=0x17 fw_name=nxp/sduart_nw61x_v1.bin.se } Copy correct version's nanapp and mlanutl and mlanwls to 2 boards, and add execute permission. root@imx93evk:~# chmod +x nanapp root@imx93evk:~# chmod +x mlanutl root@imx93evk:~# chmod +x mlanwls Copy correct FWand driver: mlan.ko + moal.ko(Cross compiled with L6.12.49 linux kernel BSP, not included in this doc). After the I.MX93-EVK board boot up, need to unload the default L6.12.49's Wi-Fi driver, then load the newer L6.18.2 Wi-Fi driver and FW. The whole process is shown as follow: The generated wls_leader.log and wls_follower.log files contain location information. The Wireshark sniffer contains NAN-related packets. Please see attached .pdf file for more detailed steps and logs outputs. How to configure to use Wireshark capture Sniffer logs On Ubuntu PC 24.04.2 LTS? Below is the commands for your reference. sudo iw dev //Check your Wi-Fi card name. Here is:wlp111s0 for me. sudo ifconfig wlp111s0 down sudo systemctl stop NetworkManager sudo killall wpa_supplicant //Here need to stop NetworkManager and wpa_supplicant, otherwise, after we configure wlp111s0 into monitor mode, these 2 service will automatically change it to managed mode. sudo iwconfig wlp111s0 mode monitor //set wlp111s0 into monitor mode sudo iwconfig //check whether set into monitor mode successfully. Here should show Mode:monitor sudo wireshark //Need to use sudo permission to run Wireshark, otherwise, could not use Wireshark to capture sniffer. Then choose wlp111s0 to capture sniffer. Reference link: Neighbor Awareness Networking (NAN) -Application note (confidential) https://github.com/nxp-imx/mwifiex/blob/doc_WCT_release/doc/Release_Notes/Linux_RN/topics/wi_fi_radio.md Best regards, Christine.
記事全体を表示
Radar - Overview 1 Introduction Radar (Radio Detection and Ranging) is a key sensing technology in modern vehicles, used to perceive the environment by transmitting radio waves and analyzing their reflections from surrounding objects. In automotive systems, radar enables reliable detection under a wide range of weather and lighting conditions. This article introduces the automotive radar node of our demo and explains how it can be integrated into a modern vehicle electronic architecture. 2 Table of Contents •Introduction •Overview •Context •References •Conclusion 3 Overview How radar supports automotive systems Within an automotive system, the radar node plays a central role in advanced driver assistance systems (ADAS) and automated driving functions, such as adaptive cruise control, collision avoidance, and blind-spot detection. It continuously measures object presence and motion in the vehicle’s surroundings, providing robust and real-time perception data. In this implementation, the radar application is developed using NXP’s Model-Based Design Toolbox for Radar, a MATLAB add-on developed by NXP. By using this toolbox, developers can design, simulate, and generate code while leveraging the hardware accelerators available on the target platform to achieve high performance and deterministic execution. The offloading of processing to the accelerators is achieved through the integration of the NXP Radar SDK within the MATLAB environment. Target Audience This series of articles serves a wide range of engineering and technical stakeholders involved in the design, development, and integration of radar systems. This chapter outlines the intended audience: Embedded Software Engineers Radar Engineers System Architects & Vehicle Architecture Engineers Hardware Engineers Model-Based Design and MATLAB Developers Academic and Research Communities 4 Context The radar application is targeted for the NXP S32R45 MCU, a high-performance processor designed specifically for automotive radar signal processing. In the vehicle electronic architecture, the radar node is connected directly to the Central Node, which is responsible for sensor fusion and higher-level decision-making. For each radar frame, the NXP S32R45 MCU detects and processes objects in the field of view and transmits, via CAN, the distance, speed, and direction of each detected object to the Central Node. This structured data exchange enables efficient integration of radar information into the overall vehicle perception and control system.   Figure 1. Example integration of the radar node into a vehicle electronic architecture. 5 References MathWorks Model-Based Design Toolbox for RADAR Community Accelerate the Discrete Fourier Transform with NXP SPT 6 Conclusion In conclusion, the radar node is a fundamental building block of the modern vehicle electronic architecture, providing accurate and reliable perception data that enables advanced safety and automation functions. This introductory chapter has outlined the role of the radar node within the vehicle system and its contribution to environment perception for advanced driving functions. The next chapters will build on this foundation by exploring the radar signal processing chain, the implementation approach, and the main software components that enable the application on the target platform.
記事全体を表示
How to Enable Super Overdrive (SOD) Mode (2.0 GHz) on i.MX95 Some customer wants to know how to enable the SOD for MIMX9596DVZXQAC, commercial qualification in 19mm. They want to test the SOD mode which is A55 running at 2.0GHz, there is no any documentation in our NXP side explaining how to do that. Here this article give the describe and enable the Super Overdrive mode on the i.MX95. 1\Introduction the i.MX95 Voltage Operating Modes The i.MX power architecture is designed with the expectation that a dedicated PMIC supplies all required power rails, ensuring compliance with stringent power-up and power-down sequencing requirements. Majority of the digital logic is supplied with two supplies: VDD_ARM and VDD_SOC. VDD_ARM is for the CORTEXAMIX. VDD_SOC is for the rest of the modules in SoC. The VDD_SOC has following modes: Overdrive mode Nominal mode Underdrive mode Suspend mode The VDD_ARM has following modes: Super Overdrive mode Overdrive mode Nominal mode Underdrive mode Suspend mode The i.MX95 power management architecture is based on multiple performance setpoints controlled by the System Manager (SM). These setpoints control: Cortex-A55 operating frequency VDD_ARM voltage Power consumption Thermal dissipation The available performance modes are:PRK,LOW,NOM,ODV,SOD Where SOD (Super Overdrive) is available only on qualified 2.0 GHz capable devices such as MIMX9596DVZXQAC. In our datasheet we can see that for the part number only MIMX9596DVZXQAC A core support the 2.0 GHz. Details in the naming rules: For the operating ranges in our datasheet can see the details: Only the Cortex-A55 support the super overdrive mode, and for the typical voltage is 1.0V. In our reference design the VDD_ARM and VDD_SOC from different PMIC. And for the frequency of modules can also see in the datasheet, for the default setting is 1.8GHz, the maximum is 2004MHz. 2\ Enable Super Overdrive (SOD) Mode (2.0 GHz) on MIMX9596DVZXQAC Understanding about SOD mode:  The default NXP BSP SM (System Manager) code will automatically detect if the iMX 95 device it is running on is a 2.0 GHz capable device, and then the code will enable operation at 2.0 GHz with Super Overdrive voltage mode.  Linux on the iMX 95 only needs to request 2.0 GHz from the System Manager to enable it. Default BSP support code: In the download source code path : /imx95BSP/tmp/work/imx95_19x19_lpddr5_evk-poky-linux/imx-system-manager/2025q4/git/devices/MIMX95/sm/dev_sm_perf.c Or in our github source can see the code: imx-sm/devices/MIMX95/sm/dev_sm_perf.c at master · nxp-imx/imx-sm · GitHub The NXP BSP already contains logic to detect whether the device supports 2.0 GHz operation /* Check for 2+GHz device */ if (speedGrade >= 2000000000U) { /* 2+GHz devices support PRK, LOW, NOM, ODV, SOD setpoints */ s_perfNumLevels[PS_VDD_ARM] = DEV_SM_NUM_PERF_LVL_ARM; }  When the System Manager reads: speedGrade >= 2000000000 the BSP automatically: Enables the SOD performance level Enables 2.0 GHz OPP Manages required ARM voltage transitions The above code will enable the SOD without changing anything. Then in Linux you can use performance to run at 2.0GHz. Using the following command: echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor Then we can check the frequency and voltage of the VDD_ARM.  3\ Enabling SOD on a Non-2.0 GHz EVK (Evaluation Only) For evaluation on the EVK with the 1.8 GHz i.MX95, the process to enable 2.0 GHz and Super Overdrive voltage mode is to modify a single line of SM (System Manager) code so that 2 GHz is enabled even if the iMX 95 does not report 2 GHz operation is possible. Change this file: /MIMX95/sm/dev_sm_perf.c else { /* All other devices support PRK, LOW, NOM, ODV setpoints */ s_perfNumLevels[PS_VDD_ARM] = DEV_SM_NUM_PERF_LVL_ARM - 1U; }// This the the default running code for the 1.8GHz for the i.MX95 FROM: s_perfNumLevels[PS_VDD_ARM] = DEV_SM_NUM_PERF_LVL_ARM - 1U; TO: s_perfNumLevels[PS_VDD_ARM] = DEV_SM_NUM_PERF_LVL_ARM;//Force to work on the SOD mode.  Then rebuild the imx-system-manager and generate a new image. Write the images to the i.MX95 19x19 lpddr5 EVK board. Run the board and boot up. root@imx95-19x19-lpddr5-evk:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 500000 900000 1404000 1800000 2004000 root@imx95-19x19-lpddr5-evk:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 2004000 BCU tool show that VDD_ARM is 1.0v when "running" at 2.0GHz and VDD_ARM is 0.9v when running at 1.8GHz, so the SOD is working. I did the the above change and tested on NXP imx95 1.8GHz 19x19 lpddr5 EVK board and the SOD worked 4\Summary So For the MIMX9596DVZXQAC the BSP is expected to automatically detect 2.0 GHz capability and enable SOD mode without source code modifications. EVK Modification The forced SM modification described above: DEV_SM_NUM_PERF_LVL_ARM is intended only for evaluation and debug purposes. It bypasses the normal speed-grade detection mechanism and should not be considered a production configuration for non-qualified devices. For the customer's MIMX9596DVZXQAC device: No BSP modification should be required. System Manager automatically checks the speed grade. If the device reports 2.0 GHz capability, SOD is enabled automatically. Linux only needs to request the highest CPU frequency. SOD operation can be verified by: Availability of 2004000 kHz CPU running at 2.0 GHz VDD_ARM increasing from ~0.9 V to ~1.0 V This confirms successful operation in Super Overdrive (SOD) Mode. IMX95EVK
記事全体を表示
OM27642 & TDAEV8035 - Quick Start Guide The TDAEV8035 evaluation board is inserted into the connector slot located on the top side of the PN7642 EVK, as shown in the figure below.   Dedicated jumper settings are required to ensure proper connection and operation of the TDAEV8035 extension board.   J23 - Position 2-3 J65, J63, J64 - Closed  J59 - Closed (Positions 1-2, 3-4, 5-6) Once the jumpers are configured correctly, users can run the example applications provided in the PN7642 MCUXpresso SDK.   After building the example project, select the right card slot (TDA8035) on the board. By default, the SIM card slot (Slot 1) is used. To use the contact card slot instead, modify the slot selection in the following section of the code.   E_AUX_SLOT1 - SIM slot (default)  E_AUX_SLOT2 - Contact card slot  The selected card slot is indicated by a red LED. D1 - SIM slot  D2 - Contact Card slot Once all required settings have been applied, the example application can be started and a contact card can be inserted into the selected card slot.    The results can be viewed in the console.  
記事全体を表示
GUI Guiderの失われたプロジェクト設定ファイルを復元するにはどうすればよいですか? 組み込み型T113ボードには、解像度480×320の液晶画面が使用されました。当初、UI設計はNXP GuiGuiderソフトウェアツールを使用して行われ、自動的にCコードのセットを生成していました。その後、.guiguiderプロジェクトファイルが失われ、GuiGuiderのIDEsソフトウェアで再度開こうとすると、.guiguiderが起動しなかったため読み込みに失敗しましたプロジェクト設定ファイルが見つかりませんでした。今では生成されたCコードを通じてしかインターフェースを変更できず、非常に直感的で非効率的です。皆さんにお伺いしたいのですが、.guiguider を復元する方法はありますか?C言語プロジェクトコードからプロジェクト構成ファイルを取得する? Re: How to recover lost project config files of GUI Guider? こんにちは@wenzhang さん 残念ながら、.guiguider を復元する確実な方法はありません。C言語プロジェクトコードからのプロジェクトファイル。これらは技術的には互いに独立している。.guiguiderファイルは、GUI Guiderアプリケーションが入力として使用するすべての設定を編集可能なプロジェクトとして表示するために使われます。一方、生成されたCコードはGUI Guiderの出力であり、このグラフィックライブラリを使用してGUIを表示するためのLVGL構成として生成されます。 微調整のみが必要な場合は、必要なウィジェットの変更を大まかに設定した新しいプロジェクトを作成し、生成されたコードを参考にして元のプロジェクトのコードを調整するのが最善の方法でしょう。 必要な変更がより大きな場合は、新しいプロジェクトでGUI GuirでGUI全体をやり直し、ツールにコード全体の生成を再度任せる方が良いでしょう。これにより、最新バージョンのGUI Guider(v2.0.0)を使用して、GUIを最新バージョンのLVGL(v9.4.0)にアップデートすることも可能になります。 BR、 エドウィン。
記事全体を表示
MIMRT700ボード上の大規模なデータセットでNPU tfliteモデルを評価するにはどうすればいいですか? 私の質問はタイトルの通りです。 私はtfliteモデルを使っていますが、NPUのTfliteモデルに変換しました。tfliteモデルとNPUのTfliteモデルの予測が場合によっては異なることを確認しました(大きな違いはありません)。そこで、大規模なデータセットに対して評価NPU tfliteモデルを実行したいと考えています。 現在はサンプルtflm_cifar10_cm33_core0 に従って推論NPU tfliteモデルをMIMRT700で実行しており、うまく動作しています。しかし、このサンプルでは、静止画像用にimage_data.hを修正しました(カメラは使用していません)。このサンプルを新しいCASE「大規模データセットで評価NPUのtfliteモデルを実行する」用に修正したいです。 私はSDカードを使用して画像を保存し、推論時にimage_data.hとして読み込む予定です。でも、どこから始めればいいのか分かりません MIMRT700にはデバッグ、eUSB、USB-OTGの3つのマイクロUSBポートがあることがわかりました。 何かおすすめやご提案があれば、ぜひ教えてください。各イメージを手動で実行する(ビルド+フラッシュ)と、非常に時間がかかります。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? @EdwinHz 応援してくださりありがとうございます。 SDカードの方法は良いです。ハードウェアは得意ではないので、チームメイトの提案で。 先ほど挙げたこの方法はどうでしょうか? 現在、私はtflm_cifar10_cm33_core0サンプルを使用して推論を実行するために、以下の手順を踏んでいます。 - image_data.h をサンプルにコピーします - ビルドボタンをクリックします デバッグボタンをクリックし、次に続行ボタンをクリックして推論を実行します。 チームメイトと話し合い、コマンドラインでビルドや推論を実行できるかどうかも話し合いました。とても良いです。もしうまくいけば、毎回image_data.hを変更するスクリプトを作成し、推論を構築し実行し、推論結果をPCに戻すことができます。これについてコメントはありますか? NXPがビルド、フラッシュ、サンプルtflm_cifar10_cm33_core0の実行に関するガイドラインがあれば、より簡単にカスタマイズできるということです。ハードウェアは得意ではないのでこの方法が気に入っています(NXPがこの方法をサポートしていれば、Pythonスクリプトを作成して毎回image_data.hを作成し、ビルドし、フラッシュし、実行して結果をPCに戻し、保存できます.csvファイルなど)。この方法(ビルド、フラッシュ、実行、コマンドライン経由でPCに結果を返す)をサポートするベンダーも多く見かけます。NXPもこの方法をサポートしていると思います。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? こんにちは、 @nnxxpp さん。 ご指摘のとおり、この例では静的ヘッダー方式を採用しています。しかし、SDカードを介してイメージをマウントするパイプラインを構築する方が、大規模なデータセットにははるかに適しているだろう。 画像をSDカードに事前にロードしておき、SDカードをマウントし、画像リストを開いて、各画像に対して次の操作を行います。 - 入力バッファへの読み込み - NPU推論を実行する - 「results.csv」に結果を書き込むファイル 現時点でこれを例示するサンプルコードはありませんが、使用しているtflm_cifar10_cm33_core0 sdcard_fatfsと、すでに初期化やカードマウントを処理し、SDカード利用に関するすべてのAPIを備えたSDKの例の両方を参照できます。 SDカードのサンプルを実行して理解し、バイナリイメージファイルの読み込みをテストすることをお勧めします。次に、tflm サンプルに SD カードのコンポーネントを追加し、SD カードの初期化と FatFs コードをインポートし、最後に静的ファイル image_data.h を置き換えます。f_read() を使用して SD カードから読み取った画像情報を含むバッファを入力として使用します。 画像をあらかじめテンソル形式で保存しておけば、処理が簡素化され、JPEG/PNGのデコード処理が不要になる。 BR、 エドウィン。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? さらに情報を追加したいです。 現在、私はtflm_cifar10_cm33_core0サンプルを使用して推論を実行するために、以下の手順を踏んでいます。 - image_data.h をサンプルにコピーします - ビルドボタンをクリックします デバッグボタンをクリックし、次に続行ボタンをクリックして推論を実行します。 チームメイトと話し合い、コマンドラインでビルドや推論を実行できるかどうかも話し合いました。とても良いです。もしうまくいけば、毎回image_data.hを変更するスクリプトを作成し、推論を構築し実行し、推論結果をPCに戻すことができます。これについてコメントはありますか?本当にありがとうございます。 Re: How to evaluate NPU tflite model on large dataset on MIMRT700 board? また、SDカードMIMRT700表示されているのも見ました。画像を読み込んでtflm_cifar10_cm33_core0してSDカードに保存できるなら、とても良いです。 でも正直に言うと、どう始めたらいいかは分かっています。私はハードウェアに詳しくありません。
記事全体を表示
RD772BJBCANFDEVB、RD-K358BMU、およびRD33774CNC3EVB間の通信フローの理解 こんにちは、NXP チームの皆様、 私たちは以下のNXP BMS評価ボードを評価しています: RD772BJBCANFDEVB (BJB) RD-K358BMU (BMU) RD33774CNC3EVB (CMU) 利用可能なサンプルソフトウェアを検討する中で、BJB、BMU、CMU間の通信全体の流れを理解することはできません。 以下の点についてご説明いただければ幸いです。 3つの委員会間の全体的なコミュニケーションの流れ。 CANメッセージがやり取りされていました。 信号は一方の基板から他方の基板へと流れる。 どのソフトウェアモジュールやファイルがこの通信を実装しているのか。 通信フロー図やアーキテクチャ文書が入手可能かどうか。 ソフトウェアの通信フローを説明するドキュメントやアプリケーションノートがあれば大変ありがたいです。 ありがとう。 RD33774CNC3EVB 、 RD-K358BMU 、 RD772BJBCANFDEVB
記事全体を表示
S32 SDK Releases We need to create SBOMs for devices that have been developed several years ago. As these devices include some code from the SDK, is there an overview available that lists the different releases of the SDK? S32 SDK for S32K1 Re: S32 SDK Releases Hi @ABuelow  Unfortunately, we do not have a complete list of all S32K1 SDK versions that have been released. Also, since some of these releases are quite old, many of them are no longer available. BR, VaneB
記事全体を表示
ETPUを使用したS32K396のデモが必要です。 S32K396用のETPUのデモが必要です。できればRTDから直接生成されたものが望ましいです。 Re: 需要一个s32k396的关于etpu的demo こんにちは@おそらく まず、使用しているRTDのバージョンに応じてeptuコンポーネントをインストールする必要があります。 https://nxp.flexnetoperations.com/control/frse/product?child_plneID=609518&cert_num=822148827 上記のダウンロードページには、EB Tresosをベースにしたサンプルプログラムが既に用意されています。 S32 DSに上記のコンポーネントをインストールすると、S32 DSにルーチンも提供されます。 最後に、弊社のS32K39xシリーズが提供するモーターソリューションもぜひご覧ください。下記のダウンロードリンクには、EPTUの使用例を含むモーターのサンプルコードが掲載されていますので、ご参考になさってください。 https://www.nxp.com/design/design-center/development-boards-and-designs/MCSPTR2AK396
記事全体を表示
RD772BJBCANFDEVB、RD-K358BMUおよびRD33774CNC3EVBの追加ドキュメントの要請 こんにちは、NXP チームの皆様、 以下のNXP評価ボードを調達しました: RD772BJBCANFDEVB RD-K358BMU RD33774CNC3EVB これらの製品に関する追加のドキュメントへのアクセスを教えていただけますか。以下のようなものです: 回路図 ハードウェアドキュメント データ・シート リファレンス・マニュアル ソフトウェアアーキテクチャのドキュメント サンプル・プロジェクト 保護されたアプリケーションノート 追加のお客様ドキュメントは よろしくお願いします。 RD772BJBCANFDEVB 、 RD-K358BMU 、 RD33774CNC3EVB Re: Request for Additional Documentation for RD772BJBCANFDEVB, RD-K358BMU and RD33774CNC3EVB こんにちは @Sanket_dudhmand e your another case: https://community.nxp.com/t5/S32K/Understanding-Communication-Flow-between-RD772BJBCANFDEVB-RD/td-p/2391116   実際、あなたの質問はHVBMSに関連しています。関連するダウンロードリンクを以下に掲載しました。ハードウェアやアプリケーションノートを含むすべての教材は、対応するページからダウンロードできます。   MC33772Cを搭載したHVBMSバッテリ・ジャンクション・ボックス (BJB)(CAN FDを使用) https://www.nxp.com/design/design-center/development-boards-and-designs/RD772BJBCANFDEVB?#design-resources 高電圧バッテリー・マネジメント・システム (HVBMS) リファレンス・デザイン・ボード用のS32K358バッテリー・マネジメント・ユニット(BMU) https://www.nxp.com/design/design-center/development-boards-and-designs/RD-K358BMU?#design-resources MC33774を搭載したCAN (FD) 対応のHVBMS集中型セル・モニタリング・ユニット (CMU) https://www.nxp.com/design/design-center/development-boards-and-designs/RD33774CNC3EVB?#design-resources 自動車ソフトウェアパッケージマネージャー: https://www.nxp.com/design/design-center/development-boards-and-designs/app-autopackagemgr/software-package-manager:AUTO-SW-PACKAGE-MANAGER
記事全体を表示
关于 RD772BJBCANFDEVB、RD-K358BMU 和 RD33774CNC3EVB 的补充文档请求 您好,NXP团队: 我们已采购以下NXP评估板: RD772BJBCANFDEVB RD-K358BMU RD33774CNC3EVB 请问能否提供这些产品的任何其他可用文档,包括: 原理图 硬件文档 数据手册 参考手册 软件架构文档 示例项目 受保护的应用笔记 任何其他客户文件 谢谢! RD772BJBCANFDEVB 、 RD-K358BMU 、 RD33774CNC3EVB Re: Request for Additional Documentation for RD772BJBCANFDEVB, RD-K358BMU and RD33774CNC3EVB 您好@ sanket_dudhmand e 你的另一个案例: https://community.nxp.com/t5/S32K/Understanding-Communication-Flow-between-RD772BJBCANFDEVB-RD/td-p/2391116   事实上,你的问题与HVBMS有关。相关下载链接已放在下方。您可以从相应的页面下载所有资料,包括硬件和应用笔记。   使用CANFD和MC33772C的HVBMS电池接线盒(BJB) https://www.nxp.com/design/design-center/development-boards-and-designs/RD772BJBCANFDEVB?#design-resources S32K358电池管理单元(BMU),用于高压电池管理系统(HVBMS)参考设计板 https://www.nxp.com/design/design-center/development-boards-and-designs/RD-K358BMU?#design-resources 能够通过MC33774进行CAN(FD)通信的HVBMS集中式电芯监测单元(CMU) https://www.nxp.com/design/design-center/development-boards-and-designs/RD33774CNC3EVB?#design-resources 汽车软件包管理器: https://www.nxp.com/design/design-center/development-boards-and-designs/app-autopackagemgr/software-package-manager:AUTO-SW-PACKAGE-MANAGER
記事全体を表示
使用 MC34GD3000 栅极驱动器驱动 24V 无刷直流电机 你好, 我目前使用的是 S32K144 BLDC/PMSM 开发套件,其中包括 MC34GD3000 栅极驱动器 IC。 从应用电路和文档来看,该参考设计似乎是为 12V 无刷直流电机设计的。然而,开发套件中包含的 BLDC 电机实际上是 24V 电机,这让我产生了一些疑问。 我希望您能就以下问题提供建议: 我的理解是,MC34GD3000 门驱动器本身由 12V 门驱动器电源供电,而反向器直流总线可以由 24V 供电,以驱动 24V 无刷直流电机。这是使用 MC34GD3000 的正确方法吗?还是我遗漏了什么? 将 MC34GD3000 与 24V 无刷直流电机一起使用时,是否存在与电压相关的限制或注意事项?例如,是否有任何推荐的操作条件、启动注意事项或其他设计要点需要注意? 如果有人有使用这款开发套件或 MC34GD3000 搭配 24V 电机的经验,我将非常感谢您的建议。 提前谢谢! Re: Using the MC34GD3000 Gate Driver with a 24 V BLDC Motor 你好@ MCmuhyeon0523 您可以参考一下这个解决方案。 MCSXTE2BK142是一款专为三相永磁电机(BLDC/PMSM)设计的开发板,在24V系统下输出功率可达800W,在12V系统下输出功率可达400W。 https://www.nxp.com/design/design-center/development-boards-and-designs/MCSXTE2BK142
記事全体を表示
24V BLDCモーターを搭載したMC34GD3000ゲートドライバーの使用 こんにちは、 現在、S32K144 BLDC/PMSM開発キットを使っており、MC34GD3000ゲートドライバーICが含まれています。 応用回路とドキュメントから、リファレンス・デザインは12 V BLDCモーターを想定しているようです。しかし、開発キットに付属しているBLDCモーターは実は24Vモーターで、いくつか疑問が湧きました。 以下の点について、ご意見をいただければ幸いです。 私の理解では、MC34GD3000ゲートドライバー自体は12Vのゲートドライブ電源から動作し、インバータDCバスは24Vで供給され、24VのBLDCモーターを駆動します。これはMC34GD3000の正しい使い方でしょうか、それとも何か見落としている点があるでしょうか? 24V BLDCモーターでMC34GD3000を使う場合、電圧に関する制限や注意点はありますか?例えば、推奨される動作条件やブートストラップの考慮点、その他注意すべき設計ポイントはありますか? もしこの開発キットや24Vモーター付きのMC34GD3000を使った経験がある方がいれば、ぜひアドバイスをいただけるとありがたいです。 お手数ですが、よろしくお願いいたします。 Re: Using the MC34GD3000 Gate Driver with a 24 V BLDC Motor こんにちは、@ MCmuhyeon0523 この解決策をご覧ください。 このMCSXTE2BK142は、24Vシステムで最大800W、12Vシステムで最大400W出力を持つ3相永久磁石(BLDC/PMSM)モーター向けに設計された開発ボードです。 https://www.nxp.com/design/design-center/development-boards-and-designs/MCSXTE2BK142
記事全体を表示
Using the MC34GD3000 Gate Driver with a 24 V BLDC Motor Hello, I am currently using the S32K144 BLDC/PMSM Development Kit, which includes the MC34GD3000 gate driver IC. From the application circuit and documentation, it appears that the reference design is intended for a 12 V BLDC motor. However, the BLDC motor included with the development kit is actually a 24 V motor, which raised a few questions for me. I would appreciate your advice on the following: My understanding is that the MC34GD3000 gate driver itself operates from a 12 V gate-drive supply, while the inverter DC bus can be supplied with 24 V for driving a 24 V BLDC motor. Is this the correct way to use the MC34GD3000, or am I missing something? Are there any voltage-related limitations or precautions when using the MC34GD3000 with a 24 V BLDC motor? For example, are there any recommended operating conditions, bootstrap considerations, or other design points that I should pay attention to? If anyone has experience using this development kit or the MC34GD3000 with a 24 V motor, I would greatly appreciate your advice. Thank you in advance! Re: Using the MC34GD3000 Gate Driver with a 24 V BLDC Motor Hi@MCmuhyeon0523  you can take a look this solution, The MCSXTE2BK142 is a development board engineered for 3-phase Permanent Magnet (BLDC/PMSM) motor up to 800 W output at 24 V system or up to 400 W at 12 V system. https://www.nxp.com/design/design-center/development-boards-and-designs/MCSXTE2BK142
記事全体を表示