Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
TFC 2015 Wordwide Championship Rules These are the 2015 Freescale Cup Worldwide Challenge Rules. The Finals will take place in Erlangen Germany on September 14-15, 2015. The Worldwide Rules are to be used for all challenges unless the University Programs Coordinator modifies the rules for your specific region. Update on Rules V6: highlighted the fact that no wireless connectivity is allowed during the race. Any wireless connectivity module must be removed before the technical inspection These are the 2015 Freescale Cup Worldwide Challenge Rules. The Finals will take place in Erlangen Germany on September 14-15, 2015. The Worldwide Rules are to be used for all challenges unless the University Programs Coordinator modifies the rules for your specific region. Update on Rules V6: highlighted the fact that no wireless connectivity is allowed during the race. Any wireless connectivity module must be removed before the technical inspection Freescale Cup Content Re: TFC 2015 Wordwide Championship Rules Hi, Regarding question #1: The tires must be unaltered, this includes the treads. Rules read as follows: "The original and unaltered equipment must be used as the entry. Outer tire treads and rim." Regarding question #2: You can create your own motor control interface within the rules listed: The High Voltage Motor Control and Interface it is required to use Freescale technology. A Freescale 32-bit Microcontroller must be used. One processor - No auxiliary processor or other programmable device is allowed. Freescale Motor Driver Integrated Circuits must be used. The car must use an optical sensor to navigate. DC-DC boost may not exceed battery voltage. Total capacity of all capacitors should not exceed 2000 uF. No Wireless connectivity is allowed during the race. Any wireless connectivity modules/technology must be removed from the vehicle before the technical inspection If your description of "motor drive chip" is for H-bridges, there are 2 motors on the car so the assumption is that you would be using max 2 H-bridges but there is nothing in the rules that says that you can't use more than 2. Just remember to document all changes per the rules' requirements. Re: TFC 2015 Wordwide Championship Rules Hi organizers, We have two questions regarding the Rules: Question 1 Pertaining to the Rule in Section 1 Mechanical: 1. The original and unaltered equipment must be used as the entry. a. Outer tire treads and rim. Is grinding/shaving the treads of the tire allowed as shown in the pictures below? Question 2 Pertaining to the Rule in Section 1 Electrical point 3: The High Voltage Motor Control and Interface it is required to use Freescale technology. Is there any limit on the number of Motor Driver chips to be used? Thanks. Looking forward for your reply. Re: TFC 2015 Wordwide Championship Rules Hello Joshua, There is no penalty for running over the line. The only penalty is when the car is out of the track with more than 2 wheels. This means: 2 wheels out of the track, you are ok, car can continue with the current lap. But when 3 wheels are out of the track, car is out of the track. Penalty: Lap is not recorded. You can check this on section 7. Re: TFC 2015 Wordwide Championship Rules If the car touches the line during the course of it's run is that considered a failure? Is there a distinction between touching a line and crossing over a line? I am currently registered for the RIT Regional competition, has a start time been decided for that event? Thank you.
查看全文
飞思卡尔常用调试工具 1. USB Multilink Universal    支持 Kinetis, HCS08, HC(S)12(X), S12Z, RS08, ColdFire V1/+V1, ColdFire V2-4*, Qorivva 5xxx, DSC.    PE Micro, http://www.pemicro.com/ 2. USB Multilink Universal FX    支持 Kinetis, Qorivva MPC5xxx, ColdFire +V1/ColdFire V1, ColdFire V2/3/4, HC(S)12(X), S12Z, HCS08, RS08, DSC, 683xx, HC16.    PE Micro, http://www.pemicro.com/ 3. J-Link    支持飞思卡尔ARM based Microcontroller Kinetis.    可以配合PC端的软件JFlash对目标板进行烧写。    Segger, http://www.segger.com 4. ULink2    支持飞思卡尔ARM based Microcontroller Kinetis.    Keil, http://www.keil.com/arm/ulink/ 5. USBDM    开源调试器    可以配合PC端的上位机对目标板进行烧写。    http://usbdm.sourceforge.net/    https://github.com/podonoghue    http://sourceforge.net/projects/usbdm/ 6. CMSIS-DAP    ARM公司开源调试器    仿真器相关介绍页: http://mbed.org/handbook/cmsis-dap-interface-firmware    仿真器的源码下载: https://github.com/mbedmicro/CMSIS-DAP 7. OpenSDA     P&E Microcomputer Systems Kinetis Hardware Support
查看全文
How to handle issue on “Waiting for devices” when downloading android images to i.MX8MQ MEK via UUU Tools Descriptions on the issue: running “uuu uuu-android-mx8mq-evk-emmc.lst” No any problem, downloading images is OK. running “uuu_imx_android_flash.bat -f imx8mq -a -e” Below lines will be showed on windows console: flash the file of u-boot-imx8mq.imx to the partition of bootloader0             Then downloading operation stopped. ------------------------------------------------------------------------                 In order to help uses save development time, I tested above 2 commands for downloading images on windows 7 64bit and windows 10 64bit respectively.                 Below is detailed steps for the operation: Hardware Preparations (1) Switch SW802 on i.MX8MQ EMEK, set 1-4 off, 2-3 on i.MX8MQ is at usb serial download mode. (2) Connecting J1701 to PC USB by a USB OTG cable. (3) Connecting J901(usb type c) to PC USB by a USB 3.0 cable. (4) Plugging [email protected] adapter into Power Jack (J902) (5) Power on I.MX8MQ board via SW701 Switch Software Preparations (1) Related windows drivers for i.MX8MQ MEK                 Windows 7 64bit or windows 10 64bit will find new devices and begin to search and install corresponding drivers, like below:                 Probably windows 10 64bit can’t automatically install CP2105 driver from official website of manufacture: https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers                 Then installed it manually. (2) Power off i.MX8MQ MEK (3) Installing winusb driver by zadig                 According to method described in uuu.pdf, download zadig tool from https://zadig.akeo.ie/, and install it to windows 7 64bit . [Note] windows 10 64bit doesn’t need to install winusb driver. Press “Install WCID Driver” Button (4) Downloading Android SDK Manager Download SDK Manager from : http://visualgdb.com/android/install_redir?item=SDK After downloading it, decompress it, and run SDK Manager application: Press OK. Then press “Close” Close SDK Manager Installation Guide . Find the directory of SDK Manager installation, and enter into “platform-tools”, like below: D:\i.MX8-Projects\IMX8MQ-MEK-windows-drivers\android-sdk_r24.4.1-windows\android-sdk-windows\platform-tools Copy items in blue rectangle to C:\windows\system Copy items in red rectangle to C:\windows\system32 Beginning to download android images to I.MX8MQ MEK via UUU Tool (1) Downloading android DEMO images for i.MX8MQ MEK https://www.nxp.com/support/developer-resources/software-development-tools/i.mx-developer-resources/evaluation-kit-for-the-i.mx-8m-applications-processor:MCIMX8M-EVK?tab=Design_Tools_Tab After downloading it, decompress it to a directory.  Like below: (2) Downloading UUU Tool https://github.com/NXPmicro/mfgtools/releases After downloading uuu.exe,  copy it to the directory of android 9.0 demo image , see above. (3) Run command “uuu_imx_android_flash.bat -f imx8mq -a -e” ----Power on i.MX8MQ MEK. ----open a command line window ---open Hyper terminal ( set it 115200 bps) ---run “uuu_imx_android_flash.bat -f imx8mq -a -e”           For windows 10 64bit, downloading images will be done without any errors.    But for windows 7 64bit, downloading images will stop at “ waiting for any devices”.    It means Android ADB driver will be needed. Follow the steps below to solve the problem. Right button, click “update driver” Close it.           Then downloading operations will be automatically continued. OK, done. NXP TIC team Weidong Sun 02-25-2019 i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: How to handle issue on “Waiting for devices” when downloading android images to i.MX8MQ MEK via UUU Tools According to this file, the problem of imx8mq evk platform is still not solved on my windows10 64-bit. It's still "waiting for any devices"!!
查看全文
トレーニング:MCUXpresso for VS Codeのウォークスルー このビデオ・シリーズでは、利用を開始するための手順を示します。これは、「MCUXpresso for VS Codeのインストール手順」で詳述した手順を視覚的に理解するためのビデオ・ウォークスルーです。 パート1:MCUXpresso for Visual Studio Code NXPは、開発者がVisual Studio CodeでNXPのマイクロコントローラをより簡単に扱えるようにしました。NXPのサポートの概要については、www.nxp.com/vscodeを参照してください。 以下のソフトウェアが必要です。 MCUXpressoインストーラ(Windows、MacOS、Linux) Microsoft Visual Studio Code(ダウンロード) (マイビデオで視聴) パート2:MCUXpressoインストーラが準備する内容 なぜMCUXpressoインストーラを使用する必要があるのでしょうか。Visual Studio Code内で組み込み開発に対応するには、多数のツールが必要になります。このインストーラは必要なツールをインストールします。ユーザーは、さまざまな環境を構成するための複雑な依存関係について理解する必要がありません。 (マイビデオで視聴) パート3:MCUXpresso for VS Code Extensionの追加 NXPの拡張機能は、最終的にはVisual Studio Codeの拡張機能マーケットプレイスからインストールできるようになります。2023年7月の一般公開までは、[Extensions(拡張機能)] メニューの中で、拡張機能の検索バーの右側にある省略記号をクリックすることにより、拡張機能を手動で追加できます。 最新の拡張機能が必要です。ダウンロード:mcuxpresso-0.5.60.vsix (マイビデオで視聴) パート4:MCUXpressoのパースペクティブの確認 NXP拡張機能は、必要な情報やリソース、ツールをVisual Studio Codeの中で簡単に参照できるようにするパースペクティブを提供します。 (マイビデオで視聴) パート5:ソフトウェア・リポジトリ/SDKの追加 NXP 拡張機能は、人気のあるソースからソフトウェアリポジトリをインポートするツールを提供します。開発者は、リモートリポジトリ、NXPアーカイブファイル、または既存のローカルリポジトリからインポートできます。 (マイビデオで視聴) パート6:最初のプロジェクトのインポート NXP拡張機能はプロジェクトインポートツールを提供します。利用可能なプロジェクトをすばやく簡単に閲覧し、現在のワークスペースに追加することができます。ユーザーはリポジトリまたは既存のローカルプロジェクトからインポートできます。 (マイビデオで視聴) パート7:VS Codeでプロジェクトをビルドする NXPインストーラと拡張機能は、使用するプラットフォーム用のツールチェーンを準備します。インストーラと拡張機能の導入が完了していれば、NXPプロジェクトは正しくビルドされるはずです。 (マイビデオで視聴) パート8:デバッグ・セッションの開始 NXP拡張機能を導入したことにより、VS Codeの中でデフォルト・ツールを起動して、一般的なデバッグ・プローブを使用できるようになりました。Segger J-Link、NXP LinkServer、PE Microのデバッグ・プローブが識別され、構成されます。デバッグ・セッションが起動し、ユーザーはプロジェクトを分析できます。 (マイビデオで視聴) ドキュメント VS Code Re: トレーニング:MCUXpresso for VS Codeのウォークスルー @sourabhmoitra うまくいってよかったです。また、パスにスペースが含まれていると問題が生じることを確認しました。こうしたエラーが発生するディレクトリをユーザーがツールで選択したときに「警告」を出せるよう、チームは作業に取り組んでいます。 Re: トレーニング:MCUXpresso for VS Codeのウォークスルー @kyledandoさん、親切なご助言ありがとうございます。Gitフォルダを変更してみたら、実際にうまくいきました。ただどういうわけか、階層の深さが3レベルを超えるGitフォルダ(例:C:/folder1/folder2/folder3)は選択できませんでした。python/westのパス名の長さに関する制限が原因かもしれません(一部のWindowsマシンで発生しています)。あらためてお礼申し上げます。 Re: トレーニング:MCUXpresso for VS Codeのウォークスルー @sourabhmoitra 別のドライブの場所を試されましたか?私のところでも、古いgitフォルダを使用するwestで同様のエラーが発生したことがあります。フォルダを新しい場所に変えたら、エラーは出なくなりました。 古いgitフォルダでwestコマンドがエラーになる原因を解決するためにチケットを発行しましたが、別のフォルダを選択(フォルダ・パスの問題を排除するためにC:/mcux-sdkを選択)したところ、ウィザードでmcux-sdkをインポートできました。 Re: トレーニング:MCUXpresso for VS Codeのウォークスルー とてもよくできました! ビデオは明確で、短く、有益です。 この拡張は、私たちの開発にとって大きな資産となるでしょう。 Re: トレーニング:MCUXpresso for VS Codeのウォークスルー 素晴らしいコンテンツです!すぐに理解できました!
查看全文
S32DS for Power - 操作指南列表 安装和激活 操作指南:将 Wind River 编译器的 Eclipse 插件安装到 S32 Design Studio 中 操作指南:将 Lauterbach TRACE32 调试器插件安装到 S32 Design Studio 中  如何将 PLS UDE 调试器插件安装到 S32 Design Studio 中 操作指南:激活S32 Design Studio 入门指南 操作指南:创建闪烁的 LED 项目 (MPC5748G) 如何:在 S32 Design Studio 中构建项目并设置调试配置以进行调试 构建工具和标准库 操作指南:在 S32 Design Studio 中从 RAM 运行例程 操作指南:使用 printf() 函数和 EWL 库 操作指南:将 S32DS Power v1.x 中创建的项目迁移到 v1.2+ 操作指南:将静态库文件添加到 S32DS GCC 项目中  操作指南:使用 GNU 构建工具将二进制文件链接到应用程序项目中 操作指南:使用 GNU 构建工具从 RAM 内存执行库函数  新! 调试与Flash编程 操作指南:使用 S32 Design Studio 将单独的 elf/srec/hex 文件下载到微控制器 操作指南:在 S32 Design Studio for Power 中编程数据闪存 (DFLASH) 操作指南:在 S32 Design Studio for Power 中将 DCF 记录编程到 UTEST 闪存中 操作指南:在 S32 Design Studio 中调试多核项目 操作指南:在 EVB 上更新 OpenSDA 固件 操作指南:MPC5777C - 通过 PE Micro 执行低/中区块 Flash 擦除 操作指南:使用 RappID BL 工具与 MPC5744P EVB 操作指南:在 S32 Design Studio 中调试多个 ELF 文件  操作指南:在 S32 Design Studio 调试器(Pemicro/OpenSDA 接口)中重置 MCU  操作指南:在单次调试会话中烧录多种类型的存储器 更新! SDK 操作指南:使用 AMMCLib SDK 操作指南:使用 FreeMASTER SDKs 操作指南:将自定义 SDK 添加到现有项目 操作指南:将基于 SDK 的示例代码作为独立代码使用(可用于 GIT、SVN... 更新! 通用用法 操作指南:S32 Design Studio 命令行界面 操作指南:将用户示例添加到 S32DS 操作指南:生成 S-Record/Intel HEX/二进制文件 操作指南:更新 S32 Design Studio 如何将生成的代码导出到 S32 Design Studio IDE(适用于 MPC5744P v2.0 的 MBDT) 操作指南:安装来自第三方供应商的更新 S32 Design Studio for Power 架构 v2.1 迁移指南 操作指南:设置项目优化级别 故障排除 故障排除:从“快速入门”页面打开文档时出现问题 故障排除:PEmicro 调试连接 - 目标通信速度 故障排除:头文件索引器错误 S32 Design Studio 离线激活问题修复补丁 故障排除:安装程序在输入激活码后立即回滚 故障排除:激活失败并显示错误信息 FNP ERROR 0
查看全文
i.MX6SX寄存器编程辅助工具 重要提示:如果您有任何疑问或想要报告有关 DDR 工具或支持文档的任何问题,请在i.MX 社区中创建支持工单。请注意,任何私人消息或直接邮件不会被监控,也不会收到回复。 这是针对与 MMDC 初始化相关寄存器的详细编程辅助资料。最后一张表格格式化寄存器设置以便与 ARM RealView ICE 一起使用。它还可以与 DDR 压力测试的 Windows 可执行文件一起使用。此编程辅助工具用于内部 NXP 验证板。 i.MX6SoloX 回复:i.MX6SX LPDDR2 寄存器编程辅助工具 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 初始化脚本通常不会对 MMDC_MAARCR 寄存器进行编程。Freescale 建议保留其默认值。 这是给决定更改此登记簿中某些字段的客户的建议。 已发现 ARCR_GUARD 字段存在一个缺陷。该字段应始终保持默认的 0x0 值。若将其编程为其他值,可能会导致不可预测的行为。
查看全文
Radar - SW & HW Environment 1 Table of Contents • Introduction • Reference Architecture • Hardware Environment • Software Environment • Radar Signal Chain • From Simulation to Target • Installing the NXP Toolchain • Next Article in the Series • References 2 Introduction This article presents the NXP hardware platforms and the MathWorks and NXP software tools used to build an automotive radar application. The development workflow is anchored in the MathWorks example "Radar Signal Simulation and Processing for Automated Driving," which provides a reference architecture spanning driving-scenario simulation, radar modeling, and signal processing. The resulting signal-processing chain is then adapted and deployed onto NXP radar hardware using NXP-specific toolboxes and hardware accelerators. This article is part of the Radar Application Development Series, which describes the complete workflow for developing, deploying, and optimizing automotive radar applications on NXP radar platforms. The purpose of this article is to introduce the overall software and hardware environment and show how the different tools, hardware components, and processing engines fit together within a radar development workflow. The next article in this series, "Radar - Processing Chain," will explore in depth each processing block presented in the Radar Signal Processing section: Range FFT, Doppler FFT, Non-Coherent Combining, CFAR Detection, Clustering, and Direction-of-Arrival (DoA) estimation. 3 Reference Architecture The starting point for the radar application is the MathWorks reference example, which models a complete automotive radar system end to end. The workflow begins by defining a highway driving scenario using the Automated Driving Toolbox ( drivingScenario ), where vehicles and traffic participants are modeled. The ground-truth generated data then feeds the radar model. Automated Driving - Bird's-Eye Plot.png   Figure 1: MathWorks example bird's-eye plot with Radar detections A 77 GHz FMCW radar is parameterized from high-level system requirements such as: Maximum detection range, typically 250-300 m for long-range radar Range resolution, around 1 m Velocity resolution Maximum relative target velocity, up to around 230 km/h The example then builds a transceiver model with antenna arrays, transmitter/receiver components, and signal-propagation effects, generating synthetic detections that estimate the position and velocity of surrounding vehicles. For the NXP application, the reference architecture is divided into two domains: Environment Simulation Executes entirely within MATLAB, and is responsible for: Driving scenario generation Vehicle motion simulation Target ground-truth generation FMCW signal generation Radar channel and propagation modeling Radar Signal Processing Contains the processing chain deployed on the S32R45 platform: Range FFT processing Doppler FFT processing Non-Coherent Combining CFAR detection Clustering Direction-of-Arrival (DoA) estimation The Radar Signal Processing domain forms the basis of the embedded radar application deployed on the S32R45 Evaluation Board. 4 Hardware Environment 3.1 S32R45 Evaluation Board The primary processing platform is the NXP S32R45 Evaluation Board, a development platform for high-performance 77 GHz radar applications such as adaptive cruise control, autonomous emergency braking, and cascaded imaging radar. It integrates several specialized processing engines optimized for radar workloads. Processing engine Role 4x Arm® Cortex®-A53 cores Application-level processing, radar control, clustering, and object management SPT Accelerator Optimized FFTs and high-throughput radar signal-processing kernels BBE32 DSP Vectorized signal processing, detection algorithms, and custom radar kernels LAX Accelerator Matrix and linear-algebra operations for accelerated angle estimation S32R45 Radar MPU Block Diagram.png   Figure 2: S32R45 block diagram 3.2 TEF82xx Customer Application Board The TEF82xx is a fully integrated 76-81 GHz RFCMOS automotive radar transceiver providing the RF front end for signal generation and capture. It integrates 3 transmit channels, 4 receive channels, ADCs, a low-phase-noise VCO, and a phase rotator, and is fully compatible with the S32R45. In the current application, the input signal is sourced from simulation rather than hardware, so the TEF82xx is not actively used. It is included as a placeholder for future hardware-in-the-loop and real-sensor integration. 5 Software Environment The radar application combines MathWorks toolboxes for algorithm development with NXP toolboxes and tools for deployment and accelerator integration. 4.1 MathWorks Tools Tool Role in the workflow Radar Toolbox FMCW waveform generation, propagation modeling, detection, and analysis Automated Driving Toolbox Scenario modeling, road/vehicle simulation, and ground-truth generation 4.2 NXP Tools Tool Version Role in the workflow S32 Design Studio for S32 Platform 3.5 IDE, compiler, debugger, and deployment environment for the S32R45, including its accelerators NXP Model-Based Design Toolbox for SPT 1.9.0 Bit-exact SPT simulator integration and rapid prototyping in MATLAB NXP Model-Based Design Toolbox for RADAR 1.0.0 MATLAB integration for S32R45; SPT/LAX kernel execution, code generation, and PIL workflows NXP Radar SDK (S32R45) 1.2.0 Optimized radar algorithms, accelerator libraries, SPT/LAX kernels, and embedded deployment infrastructure Together, these tools act as the gateway between the MathWorks and NXP ecosystems, enabling algorithm development, simulation, code generation, deployment, and SIL/PIL validation within a common workflow. 6 Radar Signal Chain Once the FMCW echoes are generated or captured, the signal-processing chain transforms the radar cube into a list of detected objects. The application currently implements the following stages. # Stage What it does Runs on 1 ADC Acquisition Digitizes the beat signal into a radar data cube, using samples x chirps x antennas TEF82xx ADCs → S32R45 2 Range FFT Fast-time FFT converts beat frequency into target range SPT accelerator 3 Doppler FFT Slow-time FFT resolves velocity, producing the processed radar cube SPT accelerator 4 Non-Coherent Combining Combines the magnitude of the range/Doppler-processed radar cube across channels, producing the range-Doppler magnitude matrix SPT accelerator 5 CFAR Detection Applies Constant False Alarm Rate thresholding on the range-Doppler magnitude matrix to detect possible targets BBE32 DSP 6 Clustering Groups neighboring detections, for example using DBSCAN, into physical objects Cortex-A53 cores 7 Angle / DoA Estimation Estimates azimuth/elevation across the antenna array, using methods such as beamforming or MUSIC LAX accelerator The output of the chain is a list of detected objects with range, relative velocity, and angle of arrival. Future Improvements The current application focuses on signal processing and object detection. Planned enhancements include: Multi-target tracking, including Kalman filtering and track-to-track association Hardware-in-the-loop testing using the TEF82xx front end 7 From Simulation to Target The MathWorks reference example executes entirely within MATLAB. During deployment, the example is partitioned into the Environment Simulation block and the Radar Signal Processing block, where the computationally intensive signal-processing functions are replaced with NXP-optimized implementations from the Radar SDK. This delivers faster execution, reduced CPU utilization, and accelerator offloading on the S32R45. 8 Installing the NXP Toolchain 7.1 Installation Order The development tools must be installed in the following order to ensure that all external dependencies required by the NXP MBDT for RADAR are available before it is configured: S32 Design Studio for S32 Platform 3.5 S32R45 Radar SDK 1.2.0 NXP Model-Based Design Toolbox for SPT 1.9.0 NXP Model-Based Design Toolbox for RADAR 1.0.0 7.2 Integrating the Development Environment After NXP MBDT for RADAR is installed, the integration of S32 Design Studio and S32R45 Radar SDK is performed using the MATLAB Live Script: mbd_lax_dependencies_path.mlx The script is located at the root of the NXP MBDT for RADAR installation. Running this script configures the required dependency paths and establishes the connection between MATLAB, the NXP Model-Based Design Toolbox for RADAR, S32 Design Studio, and the S32R45 Radar SDK. Once the script is completed successfully, the environment is ready for simulation, code generation, accelerator kernel execution, and Processor-in-the-Loop (PIL) validation. 7.3 Installation Methods The NXP toolboxes ship as MATLAB Toolbox packages (.mltbx) and can be installed in three ways: Manual install (.mltbx) - Double-click the .mltbx file, or right-click and select Install in MATLAB. The Add-On Manager installs and registers the toolbox automatically. Via NXP Support Package - Install NXP_Support_Package_RADAR from MATLAB Add-Ons, then follow the guided steps to download and install MBDT for RADAR and generate/activate the free license. Via the Automotive Software Package Manager - A bundle installer that walks through toolbox installation, dependency configuration, and license activation. 9 Next Article in the Series This article introduced the software environment, hardware environment, deployment workflow, and high-level radar signal-processing architecture. The next article, "Radar - Processing Chain - RSDK," will provide a detailed analysis of each processing block presented in Section 5: Range FFT Doppler FFT Non-Coherent Combining CFAR Detection Clustering Direction-of-Arrival (DoA) Estimation It will also explain how these algorithms are mapped onto the S32R45 processing resources and how the NXP Radar SDK accelerates the execution of each stage. 10 References MathWorks Radar Signal Simulation and Processing for Automated Driving Radar Toolbox Automated Driving Toolbox NXP S32R45 High-Performance Processor for Imaging Radar S32R45 Evaluation Board TEF82xx 77 GHz Radar Transceiver Model-Based Design Toolbox MBDT for RADAR - Knowledge Base NXP Support Package for RADAR How to install .MLTBX
查看全文
8MPLUSLPD4-EVK - 自動電源オン こんにちは、チームのみなさん。 8MPLUSLPD4-EVKは電源供給時に起動(起動)します。 私たちの理解と仮定によれば、搭載をオンにするにはONOFFボタン(SW1)を押す必要があります。 しかし実際には、EVKはONOFFボタン*SW1を押さずにONがオンになります。 この自動電源オンの動作とONOFFボタンの使い方について説明してもらえますか? 私の理解が間違っていたら訂正してください。 🙂 Re: 8MPLUSLPD4-EVK - Autopower ON こんにちは、 @ramkrishさん お元気でお過ごしのことと思います。 実際、その行動は正しい。 SW3の電源を入れると、ボードの電源が入るはずです。 ソフトウェアで基板の電源を切ったら、SW1で再度オン(ONオフ)できます。 よろしくお願いいたします。 サラス。
查看全文
Developing a Parking Sensor System with Model-Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion   2 Introduction Parking assistance systems are a familiar feature in modern vehicles, helping drivers detect nearby obstacles and maneuver the vehicle more safely. In our Hello World with MBDT project, the parking sensor subsystem provides this capability by measuring the distance to nearby objects and supplying that information to the rest of the system. Figure 1 - Physical concept.png Figure 1 - Physical concept This article introduces the parking sensor system and leads into the next articles in the series, where we will examine how this part of the project is developed. The Parking Sensors System (PSS) focus is set on how Model‑Based Design (MBD) enables the subsystem to be designed, simulated, tested, and deployed rapidly using MATLAB/Simulink and the NXP Model-Based Design Toolbox (MBDT).   3 Overview The role of this subsystem within the overall project describes the main elements that make up the parking sensor application and explains its purpose and behavior at a conceptual level. The article outlines how NXP's MBDT supports the development of this component and how a single model is reused for both front and rear parking modules. It also clarifies how this component fits into the larger project and how it connects to the rest of the components. The importance of this subsystem lies not only in its functional role of acquiring and processing distance information but also in how it demonstrates the efficiency of model‑based workflows. Rather than relying on traditional hand‑written embedded code, the entire application — logic, algorithms, peripheral drivers, timing behavior — can be designed graphically in Simulink. This accelerates development in several ways: Behavior can be simulated on the PC, without flashing hardware. The same model drives both simulation and embedded implementation. Peripheral interactions like Analog‑to‑Digital Converter (ADC) and Local Interconnect Network (LIN) are handled through dedicated blocks, not hand‑written code. Parameter tuning and validation are simplified through FreeMASTER, providing real-time visualization of the embedded system parameters. This accelerates development and ensures that the final embedded behavior matches the tested model. Developing an embedded sensor node application typically involves writing extensive low‑level code, configuring peripherals manually, and iterating slowly through hardware tests. This slows down development, limits experimentation, and creates fragmentation between design and implementation. The parking sensor subsystem demonstrates how Model-Based Design in Simulink solves this problem by enabling the entire feature to be built directly in Simulink. Engineers can model ADC acquisition, LIN communication, filtering logic, and threshold detection using graphical blocks rather than manual code. They can simulate the behavior instantly, refine algorithms quickly, and deploy the design to the microcontroller through automatic code generation. The MBD approach significantly improves the efficiency and reliability of developing, testing, and refining the complete parking sensor application. This series is intended for: Engineers learning Model‑Based Design with MATLAB/Simulink Developers working with NXP automotive microcontrollers Teams building rapid prototypes of embedded measurement and control features Students and researchers studying vehicle architectures Anyone interested in a full, reproducible example of embedded system development using MBDT Readers will gain a clear, step‑by‑step understanding of how a complete embedded feature is designed and implemented using a unified model‑based workflow.   4 Context A key aspect of the design is that the same PSS application developed in Simulink is used for both front and rear parking. Two separate S32K144 boards run the identical autogenerated code — one at the front of the vehicle and one at the rear. This showcases one of the major advantages of MBD: a single validated model can be scaled, cloned, and reused across multiple hardware nodes with minimal parametrization. Figure 2 - Parking System Architecture.png Figure 2 - Parking System Architecture The purpose of the parking sensor subsystem is to provide a clean, consistent, and rapidly developed interface that delivers accurate distance information to the rest of the system. In the implemented setup, each ultrasonic sensor outputs an analog voltage proportional to distance. This signal is sampled by the ADC (Analog‑to‑Digital Converter) of the S32K144 microcontroller. The embedded application running on the S32K144 performs the acquisition sequence, processes the ADC values to compute distance measurements, and formats the results into a communication frame. The prepared data is then transmitted over the LIN bus to the zonal controller, where it can be further used by higher‑level vehicle functions. All functional aspects — ADC acquisition configuration, signal processing, communication formatting, and diagnostic handling — are defined directly in the Simulink model, enabling rapid refinement and immediate validation through simulation. During development, FreeMASTER is used to monitor live ADC samples from the ultrasonic sensors, observe processed distance values, and validate the behavior of the embedded application before integrating the component into the full system. The parking sensor component (front and rear) is highlighted to show its position in the project setup: Figure 3 - Parking System highlighted within the project.png Figure 3 - Parking System highlighted within the project Related articles in the series Note: Additional articles in the series, including topics such as Software & Hardware Environment, Architecture & Model Description, Deploy & Validate on Hardware, Final Results and Challenges, will be added here as they become available. Each will explore individual technical details such as ADC acquisition, model structure, filtering logic, and communication behavior introduced in this overview. 5 References Software & Hardware Environment for Parking Sensor System MathWorks Model-Based Design Toolbox for S32K Community Model-Based Design Toolbox for S32K How To NXP Support Package for S32K1xx NXP Model-Based Design Toolbox for S32K1 Toolbox Download These resources provide deeper insight into the tools and methods used to build the subsystem. 6 Conclusion The parking sensor subsystem demonstrates how Model-Based Design accelerates the development of embedded automotive features. By modeling the sensing logic in Simulink, validating behavior through simulation, downloading it automatically using MBDT and monitoring it on hardware with FreeMASTER, the entire application can be developed and deployed from within a single environment. Rather than duplicating the parking sensors logic, the application is implemented as a parameterized Simulink model. Using MBDT, the same model instance can be configured for the front or rear module by adjusting parameters such as communication identifiers. This approach enables consistent behavior across parking modules while minimizing duplication and simplifying maintenance. This article introduced the component's behavior, purpose, and development workflow. The next articles in the series will expand on specific technical aspects, building a complete understanding of the subsystem from model to deployment.
查看全文
Hello World with the Model-Based Design Toolbox — Model. Generate. Drive. 1 Every great build starts with "Hello World" Every engineer remembers their first “Hello World” — that small, satisfying moment when an idea typed on a screen suddenly comes to life on a real machine. This series is a take on that same feeling, only this time the “machine” is a car. It’s a demonstrator that looks and behaves like a real vehicle, showcasing the combined use of tools from both the NXP and MathWorks ecosystems. This demo has been showcased at several events, including most recently at the MathWorks booth during Embedded World 2026 and MathWorks Automotive Conference, where the demo video that accompanies this series was filmed. Think of these articles as a guided tour through how the whole thing comes together, piece by piece. ▶ Watch the demo in action — presented at the MathWorks booth, Embedded World 2026 2 Table of Contents • Every great build starts with Hello World • From a model on a laptop to silicon on the bench • From the steering wheel to every node • And it grew up along the way • Built to be rebuilt — and learned from • A demonstrator, not a blueprint • The article series — one domain at a time 3 From a model on a laptop to silicon on the bench How does a car end up running on NXP silicon, starting from a model on a laptop? That’s where the NXP Model-Based Design Toolbox (MBDT) comes in. It acts as the bridge between the MathWorks ecosystem — Simulink and MATLAB — and NXP’s processors and embedded tools. An application is designed and modeled in Simulink, MBDT generates optimized code for the chosen NXP target, and that code is deployed straight onto the hardware. The main advantage of this approach is what it allows before any board is involved: an application can be validated and tuned in simulation first, and hardware that isn’t physically present can simply be simulated in its place. The results: early issue detection, shorter development cycles, and a faster time to market — backed by a toolchain that has been validated end to end. _MBDT_One_Slider_2026.jpg Figure 1. NXP Model-Based Design Toolbox One Pager 4 From the steering wheel to every node At the heart of the demo is a driver-in-the-loop setup: a physical steering wheel and a set of foot pedals feed signals directly into the simulation, where a virtual car is driven in simulation, into an environment developed through a RoadRunner simulated environment. From there, a clear hierarchy carries every input down to the hardware. The main node — an S32N processor — sits at the center: it communicates with the host PC running the simulation and makes the vehicle-level decisions. It then hands those decisions to a zonal node that acts as a gateway, fanning the signals out to the end nodes that handle each function — the front and rear lights, the front and rear parking sensors, the radar, and the steering rack, and, on the traction side, the battery management system and motor control. The effect is immediate and physical: steering and acceleration in the virtual world set the model on the table moving; shifting into reverse spins the motors up in the right direction; and when an obstacle appears behind the physical car, it stops on its own, with the rear lights turning red across every node — just like a production vehicle. Throughout, a live dashboard built with NXP’s FreeMASTER Lite shows the vehicle state as it happens, from the reverse camera to the parking sensors, blending signals from the virtual world with readings from the physical hardware. [02.16]NXP AutoWorks Tools Suite 26.jpg Figure 2. Demo architecture — main node (S32N), zonal gateway, and end nodes. 5 And it grew up along the way Behind all of these are the core functions of a real car — lighting, parking sensors, steering rack, motor control, and battery management — spread across roughly ten microcontrollers and processors and sixteen NXP evaluation boards and reference designs. There’s no need to unpack every component here, because each one earns its own dedicated article series later on. What’s worth knowing is how it all grew: this didn’t start as today’s car. It began as a battery management system (BMS), then gained cloud connectivity, then motor control — which evolved into a full traction inverter demo — and from there the remaining vehicle domains, from body and lighting to chassis and parking, were layered on one by one until it became a complete vehicle topology. In other words, existing MathWorks and model-based examples were assembled, domain by domain, into a car. 6 Built to be rebuilt — and learn from Why go to all this trouble? Mostly to document the work, share the thinking behind it, and show how to actually use MBDT. A big part of the appeal is that everything runs on NXP evaluation boards, which means the whole thing can be reproduced. There’s no need to redo a complex custom hardware design before starting; the same boards can be picked up to get going right away. That also makes the demo a hands-on learning platform: a place to explore the model-based workflow by doing one domain at a time. Note: A word on scope — this is a proof of concept that demonstrates the development workflow, not production firmware as it stands today. A great path forward is NXP’s CoreRide, which you can read more about on this page: Software-Defined Vehicle Development: NXP CoreRide Platform — but that part will not be covered in this series. Whether the field is automotive, electrification, industrial automation, or robotics — or simply an interest in model-based development — there should be something here worth taking away. 7 A demonstrator, not a blueprint One last note on how to read all of this. This car is a demonstrator, not a reference design. It was built with the hardware that happened to be on hand, so some of the boards and NXP solutions used aren’t necessarily the optimal fit for a given function — for a specific job, a different microcontroller might serve better. The point was never to say “use exactly these parts.” The point is the steps and the approach: the workflow itself, and how the pieces fit together. With that in mind, the articles below each take a part of this build and show how it’s done. Welcome to “Hello World” with the Model-Based Design Toolbox. 8 The article series — one domain at a time Each part of the demo car gets its own dedicated write-up, grouped into the twelve tracks below. As articles go live, the placeholders will be replaced with links. Bookmark this page — it will keep growing. NXP MBDT — How-To & Introduction What is Model-Based Design Toolbox? How to install Model-Based Design Toolbox? MBDT Setup and How-to run an application Develop an MBDT application workflow Create a new model and configure it for NXP Hardware Create a new configuration project using the S32CT How to MBDT Dio Port/Pins FreeMASTER & FreeMASTER Lite Introduction to FreeMASTER Using FreeMASTER block in Simulink Visualize and control variables in FreeMASTER Create web dashboard with FreeMASTER Lite Parking sensors Overview SW & HW Environment Logic Control (Main model overview) Front & Rear Lights System Overview SW & HW Environment Logic Control (Main model overview) Motor Control Overview SW & HW Environment Logic Control Architecture (Main model overview) Battery Management Systems Overview SW & HW Environment Logic Control (Main model overview) Steering Overview SW & HW Environment Logic Control (Main model overview) Radar Overview SW & HW Environment Processing Chain - NXP Radar SDK Main Node Overview SW & HW Environment Logic Control (Main model overview) Zone Node Overview SW & HW Environment Logic Control (Main model overview) Software & Integration Creating virtual vehicle with MathWorks Overview SW & HW Environment Logic Control Creating Virtual Scenes & Scenarios with MathWorks (RoadRunner & Unreal Engine)  Processor-in-the-Loop (PIL) What is next? Export to & Debug generated code to S32 Design Studio IDE Other Guides Getting Started with FRDM-A-S32K312 using Model-Based Design  A1: Interacting with Digital Inputs Outputs on MR-CANHUBK344 A2: Sending data via UART and monitoring signals with FreeMASTER A3: Controlling LED intensity with ADC and PWM A4: Communicating over the CAN Bus   Note: This index is updated as new articles are published.
查看全文
To complement solution how to printf float number in MCUXpresso IDE Hi: In previous topics there are some discussions how to print float number in MCUXpresso IDE and SDK. To try them and summarize the final solution: 1.PRINTF the float number to UART console set below macro in project configuration->C/C++ build ->setting PRINTF_FLOAT_ENABLE=1 such code will work. float test1 = 0.15; PRINTF("%f\r\n",test1); 2.Transform float number to string by sprintf() function. there is one error in SDK user manual, " Ensure Redlib: Use floating point version of printf is selected " during project creation does not work. The default C library Redlib doesn't support floating, so it couldn't work with redlib. daweiyou_0-1647929545419.png The correct solution are: (1)Change link library to NewLib, it's full C library and support float  printf. But notice need include in related c file, or else sprintf(float) doesn't work as expected. daweiyou_1-1647929662327.png (2)Change link library to NewLib Nano, it's compact C library , and need click "enable print float" to enable float function, which actually add " -u _printf_float" link symbol. But notice need include in related c file, or else sprintf(float) doesn't work as expected. daweiyou_2-1647929807476.png So the solution surely add flash & RAM consumption in project, but for i.MXRT series it's not problem. Attach is one example for RT1020 EVK. Re: To complement solution how to printf float number in MCUXpresso IDE Thank you! That solved my problem.  Re: To complement solution how to printf float number in MCUXpresso IDE Hi @daweiyou  Thank you so much for your contribution. The information was pretty helpful and it might be helpful for many people. Thank you again. Best Regards. Pablo Avalos.
查看全文
MCXA153: LPSPI data burst transfer. Hello, The Reference Manual MCXA153 contains a description of the TDBRn and RDBRn LPSPI registers: "TDBRn and RDBRn registers supports burst transfers of data to the transmit FIFO for use with the DMA controller". Can anyone share sample code for a burst transfer using these registers? best regards Bogdan Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) MCXA Re: MCXA153: LPSPI data burst transfer. Hi @bogdan_u  Sorry, there are currently no relevant examples available. The closest MCXA153 example I found uses LPSPI_MasterTransferEDMALite() with eDMA, but the driver targets TDR/RDR via LPSPI_GetTxRegisterAddress() / LPSPI_GetRxRegisterAddress() , not the burst alias window. But i think you can try to use. typedef struct { uint32_t cmd; uint32_t data[128]; } lpspi_burst_tx_t; static inline uint32_t LPSPI_TCBR_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TCBR_OFFSET); } static inline uint32_t LPSPI_TDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TDBR0_OFFSET); } static inline uint32_t LPSPI_RDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_RDBR0_OFFSET); } void LPSPI_StartTxBurstDMA(LPSPI_Type *base, edma_handle_t *txDmaHandle, uint32_t *cmd_plus_data, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = (uint32_t)&cmd_plus_data[0]; cfg.destAddr = LPSPI_TCBR_Address(base); cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords + 1u; EDMA_ResetChannel(txDmaHandle->base, txDmaHandle->channel); EDMA_SetTransferConfig(txDmaHandle->base, txDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(txDmaHandle); LPSPI_EnableDMA(base, kLPSPI_TxDmaEnable); } void LPSPI_StartRxBurstDMA(LPSPI_Type *base, edma_handle_t *rxDmaHandle, uint32_t *rx_words, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = LPSPI_RDBR0_Address(base); cfg.destAddr = (uint32_t)&rx_words[0]; cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords; EDMA_ResetChannel(rxDmaHandle->base, rxDmaHandle->channel); EDMA_SetTransferConfig(rxDmaHandle->base, rxDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(rxDmaHandle); LPSPI_EnableDMA(base, kLPSPI_RxDmaEnable); } BR Harry
查看全文
LX2160A 对 FlexSPI DDR/DTR 模式的支持 - 需要 DQS 说明 你好, 我们正在开发 LX2160A-RDB 板的 FlexSPI 驱动程序,并且对 DDR(八进制 DTR)模式支持有一个疑问。 我们的板上有两个 MT35XU512ABA 闪存芯片连接到 FlexSPI 控制器。从板原理图可以确认,XSPI_A_DQS 信号从闪存(引脚 C3)路由到 LX2160A。 处理器(引脚 E23)。 但是,当我们尝试使用 DTR 模式时,闪存读取返回无效数据(全为零)。SDR八进制模式(1-8-8)在各种频率下都能正常工作。 我们还注意到,在 Linux 内核中,LX2160A FlexSPI 驱动程序设置了 FSPI_QUIRK_DISABLE_DTR。 https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html 请问您能否澄清一下: 1. LX2160A FlexSPI 控制器是否支持 DTR/DDR 模式下的基于 DQS 的数据采样,还是这是已知的芯片限制? 2. 如果芯片不支持 DQS,那么 RDB 板上的 XSPI_A_DQS 引脚布线的目的是什么? 3. 是否有任何配置或勘误表可以让 DTR 模式在 LX2160A 上运行? 电路板:LX2160A-RDB Rev B 闪存:MT35XU512ABA(*2,八进制) 参考手册:LX2160A 参考设计板参考手册,修订版 5,2021 年 9 月 28 日 云实验室 在线调试 在线实验室 虚拟测试 Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed MT35XU512ABA 将具有特定的 SPI 协议,称为 Xccela。不确定LX 2160A是否支持。 Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed 你好, 实际的解决方法是:除非 NXP 确认有针对特定芯片版本的变通方案,否则 Linux/LSDK 中对 LX2160A-RDB 上的八进制 DTR 不予支持。最有力的实现证据是您找到的 NXP Linux 补丁:它为 LX2160A 添加了 FSPI_QUIRK_DISABLE_DTR 因为“lx2160a 没有实现 DQS”,并指出这会导致八进制 DTR 模式下的闪存探测失败。 针对您的具体问题: LX2160A FlexSPI 是否支持基于 DQS 的 DTR/DDR 采样? 参考手册将 FlexSPI IP 描述为具有 DQS/读取选通采样模式: MCR0[RXCLKSRC] = 0x3 选择“闪存提供的读取选通和来自 DQS 焊盘的输入”,并且输入时序部分明确描述了使用闪存提供的读取选通进行采样。然而,LX2160A 的 Linux 平台数据明确禁用了 DTR,因为该平台“不实现 DQS”。因此,我不会依赖通用的 FlexSPI IP 描述来证明 LX2160A 芯片可以使用外部 DQS 进行八进制 DTR。 为什么 XSPI_A_DQS 被路由到 LX2160A-RDB? DQS 引脚不仅仅是闪光灯提供的读取频闪信号。该手册将 A_DQS 描述为具有多种可能功能的 I/O:外部读取选通、延迟信息和环回虚拟读取选通;它还指出,可以在此引脚上进行板级加载,以补偿环回模式下的 DATA/SCLK 加载。同一个 FlexSPI 模块还使用 DQS/RWDS 作为某些写入操作的写掩码相关信号。因此,RDB 布线与 FlexSPI 引脚/功能集和板兼容性一致,但这本身并不能证明 LX2160A 支持基于外部 DQS 的八进制 DTR 读取。 LX2160A 是否有任何配置或勘误表可以启用 DTR? 我找到了 DQS 模式的文档配置 MCR0[RXCLKSRC] = 0x3 ,当使用闪存提供的读取选通时,DLL 设置如下: SLVDLYTARGET=0xF , DLLEN=1 , OVRDEN=0 ;对于低于 100 MHz 的串行根时钟,手册建议使用 DLL 覆盖模式, OVRDEN=1 ,并调整 OVRDVAL ,其中 N = 18 是一个推荐值,可能需要调整。但LX2160A特有的Linux问题指出,由于LX2160A未实现DQS,因此DTR功能被禁用。我查阅了LX2160A参考手册/数据手册、RDB参考手册、NXP/Linux补丁文本以及公开的勘误表,均未找到任何关于重新启用DQS/DTR的LX2160A勘误或已记录的解决方法。 https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html 推荐的驱动程序位置:对 LX2160A 保持 FSPI_QUIRK_DISABLE_DTR ,并使用 SDR 八进制 1-8-8 。您的症状——SDR 八进制工作,DTR 读取返回零——与上游决定阻止此 SoC 上的 DTR 一致,而不是简单的板布线问题。 此致
查看全文
i.MX8MP RAW 捕获最大几何尺寸 NXP社区的各位好, 我们正在尝试在 i.MX8MP 上使用特定的图像传感器。 我们正在尝试将 RAW12 捕获从 MIPI 推送到 RAM。看来唯一的方法是通过如下所述的 ISI 模块: hraducu_1-1782239762964.png 问题在于,关于几何限制的文档含糊不清,我们正在尝试确定 i.MX8MP 是否适合我们的应用。 图像的高度和宽度在 ISI 中使用 CHNL_IMG_CFG[WIDTH/HEIGHT] 寄存器定义。这些条目是 13 位的,理论上将我们限制在 8191 x 8191 的几何尺寸。 宽度似乎受到硬件的限制,因为行缓冲区实际上只能容纳 2K 像素,但文档概述了通过组合其他通道的行缓冲区来实现 4K 的方法。文档中没有说明是否可以达到 8191 像素的线宽寄存器限制。我们可以绕过 ISI 处理,我们的目标是直接将 RAW MIPI 捕获的数据推送到 RAM 中。 此外,与宽度限制不同,高度限制似乎并非由物理硬件引起。 是否有任何证据表明我们可以支持 CHNL_IMG_CFG[HEIGHT] 寄存器 13 位最大值所定义的 8191 行高度? 任何支持都将不胜感激。我已阅读过其他类似帖子,例如以下这些: https://community.nxp.com/t5/i-MX-Processors/Direct-MIPI-CSI2-to-memory-access-on-i-MX8MP/mp/2158946 https://community.nxp.com/t5/i-MX-Processors/I-MX8MP-ISI-maximum-supported-width/mp/1224069 但是,目前尚未确认是否支持 8191 宽度,我想知道这方面是否有任何更新。 此外,高度限制也没有明确规定。 谢谢 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP Maximum Geometry for RAW Capture i.MX8MP 的 ISI 驱动程序限制在 2K 分辨率,但如果使用链式缓冲区,ISI 可以支持高达 4K 的分辨率,但不支持 8191 像素宽。在 i.MX8MP 上,单个摄像头最高可支持 4K@30Hz 的分辨率。 Re: i.MX8MP Maximum Geometry for RAW Capture 感谢您的回复。 所以宽度限制与我最初的发现相符。 请问ISI模块的高度限制是多少?我们能否通过 ISI 实现 8191 车道高度? 谢谢 Re: i.MX8MP Maximum Geometry for RAW Capture 请参考驾驶员说明,最大高度为 8191。 #define MXC_ISI_MIN_WIDTH 1U #define MXC_ISI_MIN_HEIGHT 1U #define MXC_ISI_MAX_WIDTH_UNCHAINED 2048U #define MXC_ISI_MAX_WIDTH_CHAINED 4096U #define MXC_ISI_MAX_HEIGHT 8191U https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
查看全文
EdgeLock SE050/SE051 Capability Inquiry for Ed25519/X25519-Based IoT Device Hello NXP Team, We are evaluating the EdgeLock SE050/SE051 family for a Raspberry Pi based IoT device and would appreciate guidance on the most suitable part number. Our primary requirements are secure storage and hardware execution of cryptographic operations. The device is a Raspberry Pi 4 - running Raspberry Pi OS (Linux). We would like clarification on the following points: 1. Key Storage       - Can the SE050/SE051 securely store non-exportable private keys?    - Can certificates and public keys be stored in the secure element? 2. Key Generation       - Can the secure element generate key pairs internally?    - Specifically, does it support generation of Ed25519 and X25519 key pairs within the secure element? 3. Ed25519 Operations       - Can Ed25519 signing and signature verification be supported inside the secure element? 4. X25519 Operations       - Can X25519 key agreement (ECDH shared secret computation) be performed inside the secure element using a non-exportable private key? 5. AES Operations       - Does the secure element support AES encryption and decryption operations?    - If so, which AES modes are supported?   6. Storage read/write    - Storing/removing/accessing files like wifi passwords? 7. Linux / Raspberry Pi Integration       - Is there an SDK or middleware available for Raspberry Pi OS?    - Are there example applications demonstrating the above operations? 8. Product Selection       - Which EdgeLock SE050/SE051 variant would you recommend for the above requirements?    - What are the major differences between the recommended variants?    - Are there any newer EdgeLock products that would be a better fit for these requirements? Our intended use case is: - Ed25519 signing for device authentication / JWT generation - X25519 key agreement for mobile-device provisioning - AES encryption/decryption using derived session keys - Storage and handling of security files like Wifi passwords etc - Large-scale deployment of IoT devices If available, we would also appreciate links to any of these: - Relevant datasheets - Application notes - SDK documentation - Evaluation boards - Linux/Raspberry Pi examples Thank you for your assistance. Best regards, Sahil Pai Re: EdgeLock SE050/SE051 Capability Inquiry for Ed25519/X25519-Based IoT Device Hi @SahilPai , Please kindly have my comments as below: 1. Key Storage       - Can the SE050/SE051 securely store non-exportable private keys? //Yes, private keys are non-exportable on SE05x.    - Can certificates and public keys be stored in the secure element? // Yes, certs are stored as binary files within the SE , and public key can be stored standalone or together with the private key in SE05x. 2. Key Generation       - Can the secure element generate key pairs internally?// Yes, it supports.    - Specifically, does it support generation of Ed25519 and X25519 key pairs within the secure element?// Yes, Ed25519 and X25519 key pairs are supported. 3. Ed25519 Operations       - Can Ed25519 signing and signature verification be supported inside the secure element?// Yes, Ed25519 signing and signature verification are supported inside the SE05x. 4. X25519 Operations       - Can X25519 key agreement (ECDH shared secret computation) be performed inside the secure element using a non-exportable private key? //Yes, ECDH is performed with a private key within SE05x and an external  public key which can be stored in SE05x as well. 5. AES Operations       - Does the secure element support AES encryption and decryption operations? //Yes,    - If so, which AES modes are supported?// Support for AES Modes:CBC, ECB, CTR, GCM, CCM.   6. Storage read/write    - Storing/removing/accessing files like wifi passwords?//Yes, SE050/SE051 can store binary objects in its secure object store, including Wi-Fi credentials. 7. Linux / Raspberry Pi Integration       - Is there an SDK or middleware available for Raspberry Pi OS?// Yes, please refer to https://www.nxp.com/webapp/Download?colCode=SE05x-PLUG-TRUST-MW&appType=license for details.    - Are there example applications demonstrating the above operations?//Yes. 8. Product Selection       - Which EdgeLock SE050/SE051 variant would you recommend for the above requirements?// Either SE050E2 or SE051C2 can be used.    - What are the major differences between the recommended variants?// They both have the latest applet version, but SE051 supports applet upgrade while SE050 doesn't.    - Are there any newer EdgeLock products that would be a better fit for these requirements?//not yet so far.   Please kindly refer to https://www.nxp.com/products/SE050 and https://www.nxp.com/products/SE051 for more details.   Hope that helps,   Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------
查看全文
关于 S32K311 的 ECU 核心配置说明 你好,@danielmartynek和团队 我们有一个关于核心配置的问题。在 S32K311(单核)上,生成的代码定义了: DET_NO_ECU_CORES = 4 NUMBER_OF_CORES = 4 鉴于我们面临内存限制: 我们可以安全地将这些简化为1吗? MCAL/DET 是否有任何副作用? 另外,有没有办法在 NXP 配置工具或其他配置中进行设置,而无需手动编辑生成的文件? 谢谢 & 问候, Yusup Khan S32K3 S32DS-ARM S32K31XEVB-Q100 Re: ECU Core Configuration Clarification on S32K311 你好,@yusupkhan241、 请参考 RTD 软件开发团队提供的以下回答: https://community.nxp.com/t5/S32K/RTD-memory-occupation/td-p/2148479 该参数无法通过配置工具进行配置,目前也没有计划支持此类功能。 此致, 丹尼尔
查看全文
Looking for guidance on building a production programming fixture for NTAG213 Hi all, We are integrating NTAG213 chips into our own product and are currently in the testing phase. As we move toward mass production, we plan to build a programming fixture (or test fixture) to handle the full inline production flow: chip installation → write → read/verify → ship. We're looking for advice or documentation on the following: Best practices for designing and operating a production NFC programming fixture for NTAG213 Key considerations or common pitfalls during write/verify cycles in a production environment Any recommended tools, reference designs, or NXP resources we should be aware of before building the fixture How to reliably detect and handle write failures or defective chips at the production stage Any guidance from those who have experience with NTAG213 in production settings would be greatly appreciated. We are still in early stages, so foundational pointers are very welcome. Thank you. Re: Looking for guidance on building a production programming fixture for NTAG213 Hello @Lee0130  NTAG213 documentation is publicly available, which can be downloaded from product page. we would recommend RFID Discover to you, which is a convenient software tool for NFC tag configuration, programming, and data verification, helping streamline development and production testing. You can also development yourself application using Taplinx TapLinx SDK for MIFARE, NTAG, ICODE and UCODE | NXP Semiconductors
查看全文
JTAG on FRDM iMX95 Hi all,  I just bought FRDM iMX95 recently, i am curious about how to use JTAG to debug this board  As check in schematic it has JTAG exposed at 6 test point pin here  Zk47T_0-1781286344908.png At board layout it here  Zk47T_1-1781286419335.png How should i connect jtag to it, do i need any rework ? And does this JTAG support to debug all A55, M33, and M7 core ?  Which device should i use here, it seem we have 6 pin needle but it 2x3 not 1x6  I would appreciate any guide or docment to set up JTAG  Thank you !!   Linux Re: JTAG on FRDM iMX95 Hello, Your understanding is correct. As you can see in schematic is needed to add the DNP resistors and a connector for the debugger. Best regards. Re: JTAG on FRDM iMX95 Hello, Thank you for your confirmation @JorgeCas  Summary : Please help with JTAG problem ""DAP: Could not power-up system power domain."" I have done the rework for 3 resistor and measure the pin, it successfully pull up. One note that to enable JTAG, i need to disable LPUART5 in device tree  because it use the same pin (i follow the same modify as imx95-19x19-jtag.dtb ) or else TMS (Test point 49) will always LOW) diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts index c45f28efb568..598e16af0ebd 100644 --- a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts +++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts @@ -520,7 +520,7 @@ &lpuart5 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart5>; - status = "okay"; + status = "disabled"; bluetooth { compatible = "nxp,88w8987-bt"; After this i need to find the connector with 1.27mm pin. It take me some time to find this pcb test by pogo pin, it has 6 pin, perfectly fit.  Zk47T_0-1782485750558.png Here is my current setup  95a82f536c8bedd5b49a.jpg It seem a mess but the connection is not problem, i check the HWStatus and it look good  J-Link>ShowHWStatus VTref=3.324V ITarget=0mA TCK=1 TDI=1 TDO=0 TMS=0 TRES=1 TRST=1 Supported target interface speeds: - 120 MHz/n, (n>=8). => 15000kHz, 13333kHz, 12000kHz, ... - Adaptive clocking I try connect it by these 2 command for A55 and M33 but same issue show is "DAP: Could not power-up system power domain." zk47@ltu:~$ JLinkExe -device MIMX9516_M33 -if JTAG -speed 200 SEGGER J-Link Commander V9.42 (Compiled May 6 2026 12:36:02) DLL version V9.42, compiled May 6 2026 12:35:00 zk47@ltu:~$ JLinkExe -device MIMX9516_A55 -if JTAG -speed 200 What could i do wrong here ? Maybe it fall to my JLink device is not good, can MCU-Link Pro replace it ? Can MCU-Link Pro debug both A55 and M core ?  I would still prefer do the debug through JTAG because i already had it. Please help  If you guy plan to add document guide for JTAG on FRDM iMX95, please update it soon like FRDM iMX93.   Re: JTAG on FRDM iMX95 Dear @JorgeCas  Any update ? Can i use MCU-Link Pro to debug all core A55, M33 and M7 core ?  Re: JTAG on FRDM iMX95 Hello, I apologize for the delay. We suggest you any debugger from MACRAIGOR Systems, Wind River or any of ARM. NXP team uses Lauterbach Trace32 as debugger tool for Cortex-A cores, J-link is for Cortex-M cores. In the case of i.MX95, as prerequisite to use the CM7 or CA55 scripts the SM should be already running on the i.MX device. it has the CM33 for resource management and security reasons, it's open source, it's compliant to a HW resource management standard by ARM, and its code it's meant (between a lot of them) to partition hardware, assign resources to either Cortex-A or Cortex-M7. You can use this document as reference. Debugging Cortex-M with VS Code on i.MX 8M, i.MX 8ULP, and i.MX 9 If you still having issues after this considerations, please look for hardware issues in your adapter. Best regards.  Re: JTAG on FRDM iMX95 Dear @JorgeCas  Thank you for your reply.  Okay so the hardware could be the problem, but i am still wonder these thing  Can i have a picture for your setup debug ? I am not sure what is the official way to connect to these test point. does we need to use kind of this  Zk47T_0-1783994808434.png 2. The docs only for Debug core M, not core A. Can you give me more guide for "Debug core A linux using Trace32 or JLink or MACRAIGOR " as you said ?  3. Not relate to this thread, but can i have the estimated release date for FRDM iMX95 Pro ?  Re: JTAG on FRDM iMX95 Hello, 1. Our available boards for testing are not modified since if JTAG is needed, we use EVK instead FRDM boards. The recommended approach is use shorter wires as possible between the boards and debugger to warranty a good connection and signal integrity. As you can see in this post, the issue was solved with shorter cables soldered to the board. 2.  This information is in probe manual since each manufacturer uses their process and scripts to connect with the processor. There is no documentation in our side regarding these probes connection. 3. Unfortunately we do not have this information, I suggest you check our official web site for further updates. Best regards.
查看全文
在 SPC563 (e200z3) 上集成 ERIKA RTOS-将程序集 (.S) 转换到时出现编译错误 大家好, 我目前正在使用 CodeWarrior 2.9 开发 SPC563XX(Power Architecture e200Z3),该芯片与 MCP563xx 微控制器功能相当。 在尝试整合 MCP56xx 系列的 ERIKA RTOS 时,我遇到了以下编译错误: mwldeppc:未定义:'EE_hal_terminate_savestk'  mwldeppc:引自 ee_tstub.o 中的 “ee_oo_thread_stub” 经调查,我发现函数 EE_hal_terminate_savestk() 定义在一个汇编 (.S) 文件中,而该文件似乎并未被纳入编译过程。 我的工具链能够编译 .c 文件文件,所以我尝试通过将 .S 文件重命名为 .c 来解决这个问题文件,并将汇编代码封装在 C 风格函数中(例如:asm void Fun(){})。 我最初的意图是重用相同的汇编实现,只调整函数定义以匹配 C 语法,这样我就可以避免修改生成文件。然而,这种做法导致了多个编译错误,这让我感到意外。 以下是我遇到的一些错误: 非法函数定义  未定义的标识符 'rlwinm'  未定义的标识符 'addis'  未定义的标识符 'stw'  未定义的标识符“stmw”  未定义的标识符“mtlr”  未定义的标识符 'bl'  未定义的标识符 'lwz'  未定义的标识符“addi”  声明语法错误  预期为 ';' 看起来 CodeWarrior 编译器无法识别 C 文件中的若干 PowerPC 汇编指令。 请帮我解释一下: 为什么编译器无法识别这些汇编指令? 这种方法(将汇编代码嵌入到 .c 文件中)该文件是否适用于此工具链? 我该如何正确解决这些编译错误? 感谢您的支持。 此致, 纳格恩德拉·波图拉 软件架构师 AVL ITC 印度 Re: Integrating ERIKA RTOS on SPC563 (e200Z3)- Compilation Error While When Converting Assembly (.S) 您遇到的编译错误是由于 PowerPC 汇编代码被当作 C 代码进行编译所导致的。通过将原始的 .S 文件重命名为 .c 文件,并将汇编代码嵌入到 C 函数中,编译器会尝试将 rlwinm、addis、stw 等汇编指令解释为 C 语法,从而导致出现“未定义标识符”和“非法函数定义”等错误。此方法对 CodeWarrior 无效,因为这些指令只有在由汇编器处理时才会被识别。 正确的解决方案是保留原始的 .S 文件并确保它正确包含在编译系统中,以便由汇编器编译并与项目的其余部分链接。这种形式的内联汇编无法替代 RTOS 所使用的完整汇编模块。 请注意,ERIKA Enterprise是第三方开源实时操作系统(类似于OSEK/AUTOSAR),不是恩智浦的产品,因此其集成和构建配置不在恩智浦的范围内,需要由您自己处理。 作为参考,以下文档可能会对你有所帮助: 飞思卡尔 PPC e200 (mPC56xx) 支持页面:https://erika.tuxfamily.org/wiki/index.php?title=Freescale_PPC_e200_%28MPC_56xx% 29 感谢您的理解。 Re: Integrating ERIKA RTOS on SPC563 (e200Z3)- Compilation Error While When Converting Assembly (.S) 谢谢回复。 请问哪里可以找到NXP MPC5634M的启动代码? Re: Integrating ERIKA RTOS on SPC563 (e200Z3)- Compilation Error While When Converting Assembly (.S) 大家好, 你是对的。发布问题后,我意识到我犯了一个错误,只是简单地将文件从 *.s 更改为 *.c。 然后我使用如下所示的内联汇编实现了相同的功能,这样就解决了所有编译器和链接器错误: void Func(void) { 汇编 { /* 此处填写汇编代码 */ } }
查看全文
关于 S32K146 LPI2C MCFGR1 寄存器中 PINCFG 字段配置的咨询 大家好 我正在使用 S32K146 上的 LPI2C 模块,对 MCFGR1(主配置寄存器 1)寄存器中的 PINCFG 字段有一些疑问。 根据参考手册,PINCFG 字段用于配置 I2C 引脚工作模式。不过,我需要了解以下具体信息: PINCFG 的 8 个不同配置值(000 至 111)各自适用于哪些应用场景? 每个配置值的引脚输出类型是什么?这是开漏输出还是推挽输出? 如果您能分享任何应用笔记、参考代码或实践经验,我们将不胜感激。 谢谢! Re: Inquiry about PINCFG Field Configuration in S32K146 LPI2C MCFGR1 Register 你好@GXY  PINCFG 字段定义了 LPI2C 引脚的电气驱动和使用方式,具体取决于是需要标准的 2 引脚 I2C 总线还是单独的 4 引脚配置。 000 – 标准模式:双向开漏 001 – 两个信号均配置为仅输出开漏模式 010 – 双向推挽 011 – SCL/SDA 用作输入;SCLS/SDAS 用作推挽输出 100 – SCL/SDA:主设备用的双向开漏;SCLS/SDAS:从设备用的双向开漏 101 – SCL/SDA:主设备专用的只读开漏输出;SCLS/SDAS:从设备专用的只读开漏输出 110 – SCL/SDA:主设备双向推挽;SCLS/SDAS:从设备双向推挽 111 – SCL/SDA:仅输入、开漏;SCLS/SDAS:仅反相输出、推挽 有关更多信息,请参阅 UM10204:I2C 总线规格和用户手册。 此外,S32K1 软件包中还提供了演示标准 I2C 引脚配置的示例代码。 BR、VaneB Re: Inquiry about PINCFG Field Configuration in S32K146 LPI2C MCFGR1 Register 我知道这个字段的含义,但我想问的是这些字段的应用场景。例如,000 用于标准双线 I2C 传输;001 用于超速模式下的双线传输;010 用于高速模式下的通信;011 和 111 用于四线通信; 我对如何灵活使用其余三种配置感到困惑。如果我错了,请指正。此外,手册中指出 S32K146 不支持 HS 模式和 ULTRA 模式,但通过修改 PINCFG 寄存器,我能够实现 HS 模式 3.4M(先低速,后高速)与 ULTRA 模式(实测 4M)之间的相互通信 之间实现相互通信(主从双方均为 S32K146)。我想知道是书中有错,还是我的试题有误。 Re: Inquiry about PINCFG Field Configuration in S32K146 LPI2C MCFGR1 Register 你好@GXY  如前所述,LPI2C 外设中的 PINCFG 字段定义了所使用的引脚数量及其电气特性。它并不直接决定 I2C 速度模式。 关于工作模式,LPI2C 模块在逻辑上可以支持不同的模式。但是,您可以实现的实际波特率还取决于多个因素,例如焊盘的实现、外部负载以及总线上使用的上拉电路。 对于 S32K1 设备,SCL 和 SDA 信号使用标准的 GPIO 焊盘而不是高驱动焊盘,因此可实现的最大波特率在一定程度上受到限制。 此外,表 52-9 仅提供了寄存器设置的示例。这些配置仅供参考,并不能保证在实际应用中可以达到相应的波特率。 Re: Inquiry about PINCFG Field Configuration in S32K146 LPI2C MCFGR1 Register 我越来越感到困惑。我现在最担心的是,通过更改 PINCFG,S32K146 可以直接以 FASTPLUS、HS 和 ULTRAFAST 模式的速度相互通信。然而,实际上,S32K146 无法在这三种模式下与其他标准 I2C 设备通信(如手册中所述)。首先让我解释一下我是如何让两个 146(一个主设备和一个从设备)在以下三种模式下通信的:1. FASTPLUS(1M)将主设备和从设备的 PINCFG 调整为 010。2. HSMODE(配备 2M,经测试为 2M)将主设备和从设备的 PINCFG 调整为 010。3. ULTRAFAST(配备 5M,经测试为 4M)将主设备的 PINCFG 调整为 001,将从设备的 PINCFG 调整为 000。 我想知道 FASTPLUS (1M)、HS (3.4M) 和 ULTRAFAST (5M) 模式的标准设备是推挽输出还是开漏输出。
查看全文