Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
What Is Model-Based Design? A Practical Introduction for Modern Embedded Systems   Table of Contents Why embedded development needs a better workflow What Model-Based Design is A simple mental model: from idea to executable model to hardware Why engineers use it: the core advantages Verification along the way: MIL, SIL, PIL, HIL How NXP enables this with Model-Based Design Toolbox (MBDT) What comes next in this article series 1 Why embedded development needs a better workflow Modern embedded systems are no longer isolated functions running on a single controller. In today's vehicles and intelligent machines, applications span sensing, communication, control, safety logic, diagnostics, and multiple processing nodes that must work together as one system. As this complexity grows, traditional workflows based mainly on handwritten code and late-stage hardware testing become difficult to scale, hard to validate early in the development cycle, and slow to iterate. Issues are often discovered late, when integration becomes more costly and harder to manage. Model-Based Design offers an alternative approach designed to address these challenges. It enables earlier validation and a more structured development flow, where verification is not an afterthought, but part of every stage of development. 2 What Model-Based Design is   Model-Based Design is a visual way of programming, where you build your functionality by drawing an engineering diagram, and that diagram can be executed—either as a simulation on your computer or as code running on real hardware. In this approach, models become the central engineering artifact used to design, simulate, verify, and deploy embedded systems. Instead of starting from low-level implementation details, engineers create an executable model of the application behavior, simulate, verify, refine it, and then generate code for the target system. This model-centric workflow makes designs easier to understand, easier to reuse, and less prone to errors. It also enables model-based testing, where test cases can be derived directly from system models and used to verify behavior early in development. 3 A simple mental model: from idea to executable model to hardware A simple way to think about Model-Based Design is this: you describe what the system should do in an executable model, validate that behavior in simulation, and then carry the same design through to the final implementation. In this approach, the model is not just documentation—it becomes an active engineering asset used for design, simulation, verification, and code generation. This creates a direct path from idea to application, where requirements, design, prototyping, testing, and deployment are connected in one continuous workflow. 4 Why engineers use it: the core advantages One of the biggest advantages of Model-Based Design is that it changes where engineering effort is spent. Instead of focusing primarily on how to implement functionality at a low level, engineers can focus on what the system should do—its behavior, control strategy, and response to real-world scenarios. This approach also enables early validation. System behavior can be simulated on a PC before the final hardware is available, allowing issues to be detected earlier and reducing costly rework late in the development cycle. In addition, Model-Based Design enables hardware-independent simulation, where algorithms can be developed and validated before being tied to a specific target platform. This allows teams to explore designs faster and reuse validated functionality across different hardware solutions. As a result, teams benefit from: faster iteration during development improved traceability between design and implementation reduced integration risk more consistent validation across development stages Ultimately, this contributes directly to faster time-to-market, as development cycles are shortened and fewer late-stage issues need to be addressed. Some concrete examples can be found in the following articles: From Virtual Vehicle to All-Electric Off-Road UTV in Less Than a Year Dyson Accelerates New Product Development with System-Level Simulation 5 Verification along the way: MIL, SIL, PIL, HIL A key strength of Model-Based Design is that validation happens continuously throughout development. This is typically organized into several stages: Model-in-the-Loop (MIL): the model is tested against a simulated environment Software-in-the-Loop (SIL): generated code is executed on the host PC and compared to model behavior Processor-in-the-Loop (PIL): code runs on the target MCU to verify functional correctness and performance Hardware-in-the-Loop (HIL): the controller is tested against a real-time or emulated system before final deployment These stages provide a structured validation path, ensuring that issues are detected early and confidence is built progressively before running on final hardware. Model-Based Design also supports reuse and scalability. A validated model can be adapted, parameterized, or reused across multiple systems, reducing development effort and improving consistency. 6 How NXP enables this with Model-Based Design Toolbox (MBDT) To make this workflow practical on real embedded hardware, NXP provides the Model-Based Design Toolbox (or MBDT). This acts as a bridge between the MathWorks' and NXP's software ecosystems, and allows the entire workflow to be done from one environment, as depicted in the diagram above. Concretely, this allows engineers to use MATLAB and Simulink to design, simulate, verify, and automatically generate code that can run directly on NXP microcontrollers and processors. MBDT provides: block libraries for hardware access integration with configuration tools for pins, clocks, and peripherals support for PIL workflows code generation and deployment capabilities profiling and runtime monitoring through tools like FreeMASTER This creates a complete end-to-end flow—from model to validated application running on target hardware. Engineers can explore functionality at a high level, validate behavior through simulation, and deploy with confidence onto real systems. 7 What comes next in this article series In the articles that follow, we will move from this general introduction to concrete, real application examples. We will show how Model-Based Design and NXP tools can be applied across a modern system architecture, covering applications such as battery management, motor control, radar, steering, lighting, and parking sensors. Each example will illustrate how functions can be designed, validated in simulation, and deployed onto the appropriate hardware nodes. The key idea is simple: Model-Based Design helps engineers focus on system behavior while reducing the gap between concept, implementation, and validation. With NXP's Model-Based Design Toolbox, this approach can be carried from the modeling environment all the way to a running application on hardware. MBDT  https://www.nxp.com/mbdt https://mathworks.com/nxp 
View full article
How to install .MLTBX 1 Table of Contents • Overview • Executive Summary - What is .MLTBX • Context - Where to obtain the .mltbx file • Method 1 - Manual Installation (.mltbx) • Method 2 - Install via NXP Support Package • Method 3 - Automotive Software Package Manager • Conclusion 2 Overview NXP provides a range of MATLAB ® Toolboxes distributed as .mltbx packages to support modeling, simulation, configuration, and code generation for NXP microcontrollers and processors. These toolboxes integrate directly with the MathWorks environment and enable faster development workflows by extending MATLAB/Simulink with NXP-specific blocks, drivers, and examples. The scope of this article is to guide users through the process of installing an NXP .mltbx toolbox obtained from the official NXP website. It explains the prerequisites, where to download the toolbox, and how to install and verify it within MATLAB. The instructions are intended for engineers and developers who have basic familiarity with MATLAB but may be new to installing third-party toolboxes distributed outside of MathWorks Add-Ons. By following this guide, readers will be able to correctly install the NXP toolbox, ensure it is recognized by MATLAB, and prepare their environment for subsequent development and evaluation tasks. 3 Executive Summary - What is .MLTBX An .mltbx file is a MATLAB Toolbox package used to distribute and install MATLAB or Simulink extensions. It is a self-contained archive created by MathWorks that can include functions, Simulink blocks, documentation, examples, and setup scripts. When opened in MATLAB, an .mltbx file is installed using the Add-On Manager, which automatically places the toolbox in the default add-ons folder, and registers the toolbox within the environment. This format allows third-party vendors - such as NXP - to safely deliver toolboxes outside of the MathWorks Add-On Explorer while preserving a standard installation experience. In short, a .mltbx file is the official and recommended way to package, install, update, and uninstall MATLAB toolboxes. 4 Context - Where to obtain the .mltbx file There are multiple ways to get the .mltbx file, as shown below: Manual download and install - from NXP site (.mltbx file) Installation via MATLAB - Add-Ons / toolbox flow (NXP Support Package) Installation via Automotive Software Package Manager - bundle installer All methods are valid and can be used depending on your setup and preferences. The Automotive Software Package Manager approach installs bundles and generates an installer that walks through the steps automatically. Prerequisites Before installing the toolbox, ensure the following: MATLAB is installed on your machine You have access to the toolbox download source Note: The .mltbx file cannot be used without MATLAB. The toolbox is only available for Windows and may require additional prerequisites such as: Embedded Coder MATLAB Coder Simulink Coder 5 Method 1 - Manual Installation (.mltbx) The manual installation flow is simple, once prerequisites are met. Manually download the .mltbx file from the NXP site and install it. Typical install behavior: Open MATLAB → run or double-click the .mltbx file → install → toolbox is added automatically. Installed toolboxes are placed under MATLAB Add-Ons directories and appear in the Add-On Explorer. Step 1 - Select the toolbox family As a first step, on the NXP site, select "Automotive SW - Model-Based Design Toolbox". Step 2 - Select the target software In our example, we are selecting "Automotive SW - S32K3 Software". Step 3 - Select the S32K3 Model-Based Design Toolbox Select "Automotive SW - S32K3 - Model-Based Design Toolbox". Step 4 - Choose Product Information Select the Product Information: "Model-Based Design Toolbox S32K3 1.8.0". Step 5 - Accept Software Terms and Conditions The Software Terms and Conditions will appear - select "I Agree". Step 6 - Download the .mltbx file After the terms and conditions agreement, you can download the .mltbx file. When downloading, save the file under the .zip extension, as shown below. Step 7 - Reveal file extensions in Windows To see and change the file extension, follow the next steps: Press the three dots visible below: Select "Options". Deselect "Hide extensions for known file types". Press Apply and OK. After this update, the file will be visible with its extension. Step 8 - Change the file extension to .mltbx Change the file extension from .zip to .mltbx : A pop-up will appear - press "Yes": View after changing the file from .zip to .mltbx: Step 9 - Install the toolbox in MATLAB Double-click the .mltbx file and accept the License Agreement. The installation process will start and it will take a few moments to be finalized.  Installation Finalized   Toolbox registered in MATLAB Add-On Manager  6 Method 2 - Install via NXP Support Package The NXP Support Package add-on is a guided installer that: Checks and validates all installation prerequisites Directs users to the page where the required .mltbx package can be downloaded Allows users to select the .mltbx package to install Provides the option to open relevant documentation resources Step 1 - Open MATLAB Launch MATLAB. Step 2 - Navigate to Add-Ons Go to: Add-Ons → Get Add-Ons. Step 3 - Install the toolbox Load the toolbox file or follow your internal download process. Note: Direct download via Add-On Explorer may not always be available, depending on licensing and setup. 7 Method 3 - Automotive Software Package Manager This method uses the Automotive Software Package Manager, which installs bundles and generates an installer that walks through the steps automatically. Step 1 - Access Package Manager Use the Automotive Software Package Manager. Step 2 - Select required components Choose: Target platform - e.g. S32K3 Required tools - e.g. FreeMASTER, Model-Based Design Toolbox Step 3 - Generate installer The tool generates a bundle installer. Step 4 - Run installer Run the generated installer. Follow the step-by-step instructions. 8 Conclusion Installing an NXP .mltbx toolbox is straightforward once the MATLAB prerequisites are in place. Depending on your workflow, you can choose the manual .mltbx installation, the guided NXP Support Package, or the Automotive Software Package Manager bundle installer - all three methods produce a properly registered toolbox inside MATLAB. With the toolbox installed and verified, your environment is ready to start developing, simulating, and generating code for NXP microcontrollers and processors. Stay tuned for the next article, where we will dive into using the newly installed toolbox to build your first Model-Based Design project.
View full article
Designing a CAN-Based Communication Hub with the S32N55 using Model Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction This article presents an automotive system built around a central computer that processes high volumes of data to manage interactions and decisions across the vehicle. Implemented on an NXP S32N55 board, a main node orchestrates peripheral nodes — Lighting, Motor Control, Steering, Radar, and Parking Sensors — over CAN, demonstrated through real-time interactions and Driver-in-the-Loop (DiL) simulations. The same architecture also enables stimuli and scenarios to be injected directly from Simulink/MATLAB via the Model-Based Design Toolbox (MBDT), turning the setup into both a functional prototype and a flexible test bench that shortens the loop between design, validation, and refinement. 3 Overview The communication hub acts as a comprehensive aggregator and decision-maker, serving as the central intelligence of the entire automotive control network. This architectural choice follows industry's best practices by consolidating critical decision-making processes into a single, robust processing unit capable of efficiently managing multiple concurrent data streams and executing time-sensitive commands. Centralizing this logic also simplifies maintenance and traceability, since the rules governing vehicle behavior live in one well-defined place rather than being scattered across multiple ECUs. For a project of this nature, the NXP Model-Based Design Toolbox (MBDT) offers a practical development path: control logic and application behavior can be designed in Simulink/MATLAB and deployed directly onto the S32N55, without a separate hand-coding step. The graphical, model-based workflow makes the system's structure easier to follow and adjust, while built-in support for CAN communication and integration with tools like FreeMASTER for live telemetry simplify both stimulus injection and runtime observation. The result is a smoother path from initial concept to a working prototype that can be iterated on and validated in a controlled, repeatable way. In this specific implementation, the main node hosts an application that fulfills two complementary roles: data aggregator and decision-maker. As an aggregator, it collects, synchronizes, and interprets incoming signals from the sensing nodes; as a decision-maker, it translates that fused view of the environment into concrete commands for the actuators. Practically, our system receives data over CAN from the peripheral sensing nodes (Radar, Parking Sensors) and dispatches commands to the actuator nodes (Motor Control, Lights, Steering). The main node is also designed to make safety-critical decisions based on the incoming inputs — for example, triggering Automated Emergency Braking (AEB) when the Parking Node or the Radar Node detects a hazardous situation. Because these decisions are made centrally, the response logic can take the full context into account (vehicle speed, proximity of obstacles, current steering input) rather than reacting to a single sensor in isolation. 4 Context At its core, the main node receives a continuous stream of data over the CAN bus from peripheral nodes distributed throughout the vehicle. These peripheral nodes include: Radar sensors — provide long-range object detection and relative velocity measurements, making them ideal for highway-speed scenarios and forward collision awareness. Parking sensors — monitor the immediate vicinity of the vehicle for obstacles and potential collision risks, typically at very short range and at low speeds. Fault sensors — for actuator nodes, like the motor control, steering and lighting systems. The CAN bus protocol guarantees the reliable, deterministic communication required to meet the stringent timing demands of automotive safety systems. Its built-in arbitration, error detection, and message prioritization make it a natural fit for a distributed architecture in which safety-relevant signals must always reach the main node within a bounded time window. To streamline communication across components, a CAN Database ( DBC ) file has been created that contains all the signals and messages used throughout the system. The DBC file acts as a single source of truth for the entire network: every node — whether sensing or actuating — references the same definitions for message IDs, signal layouts, scaling factors, and value ranges. This drastically reduces the risk of integration mismatches when multiple boards are developed in parallel. Beyond its data aggregation role, the main node also serves as the command center for the vehicle's actuator systems. After receiving data from the simulation, it is being processed and then it transmits precisely timed control signals to critical subsystems, including the motor control unit, lighting system, and steering mechanism. This bidirectional architecture enables closed-loop control strategies, in which sensor feedback continuously informs actuator commands to achieve the desired vehicle behavior. Each actuator node remains responsible for the low-level handling of its hardware, while the main node provides the high-level command to the actuators. Since the main node is responsible for receiving, analyzing, processing and sending data, it also becomes the one responsible for sharing the telemetry information upstream, either to the cloud, or to real time monitoring tools like FreeMASTER. A particularly valuable aspect of this system is its seamless integration with the Simulink/MATLAB environment, which unlocks extensive possibilities for system validation and scenario testing. Engineers can inject stimuli into the simulation and analyze a wide range of driving conditions and edge cases without requiring a full-scale prototype. This is especially useful for reproducing rare or dangerous situations — such as sudden obstacles or sensor faults — in a fully controlled and repeatable environment. To achieve two-way communication between the main node and the simulation, the CAN bus itself is used to communicate with the Simulink model. This way, the physical prototype can feed stimuli into the simulation — and vice versa — on the same CAN bus that devices are using to communicate, significantly expanding the boundaries of the testing environment. The same DBC file that defines the on-vehicle communication is reused on the simulation side, ensuring that the messages exchanged between the real and virtual worlds remain perfectly consistent. Note: Perhaps one of the most noteworthy features of the main node's active functions is its ability to make safety-critical decisions in real time based on aggregated sensor inputs. The system continuously monitors data from both the parking sensors and the radar node, detecting potentially dangerous situations that require immediate intervention: At low speeds — hazard detection is typically driven by the parking sensors mounted on the front and/or rear of the vehicle, where short-range, high-resolution distance measurements are most relevant. At driving speeds — the radar module takes over, collecting and analyzing data that is then forwarded to the main node for higher-level interpretation. In both scenarios, the main node remains the ultimate decision-maker, fusing all available data to determine the appropriate response. This clear separation between sensing, decision-making, and actuation keeps each component focused on a single responsibility and makes the overall system easier to reason about, extend, and validate. 5 References NXP Model-Based Design Toolbox (MBDT) Community Interacting with Digital Inputs/Outputs on MR-CANHUBK344 Communicating over the CAN Bus S32N Vehicle Super-Integration Processors 6 Conclusion This article has provided an overview of the communication hub's core functionality, offering a high-level perspective on how key systems interact within the overall architecture. The main node was presented both as a data aggregator and as a decision-maker, with a particular emphasis on its role in safety-critical scenarios and its integration with the Simulink/MATLAB environment. Future installments in this series will take a deeper dive into the communication hub — covering the specific board in use, detailed hardware and software requirements, and other technical considerations and implementation nuances. Subsequent articles will also explore individual peripheral nodes in more detail, building up a complete picture of the system one subsystem at a time.
View full article
SE050E2HQ1/Z01Z3Zに必要な熱データ こんにちは、チームの皆さん、 部品番号の熱抵抗データと動作接合部温度情報を探しています。 SE050E2HQ1/Z01Z3Z ありがとうございます。 ひどい スマート・カード Re: Thermal Data required for SE050E2HQ1/Z01Z3Z こんにちは、 @Harsh_Bhavsar さん。 詳細については、 https://www.nxp.com/docs/en/data-sheet/SE051.pdfをご参照ください。それらはほとんど同じです。 心から、 カン Re: Thermal Data required for SE050E2HQ1/Z01Z3Z こんにちは、Kan_Liさん。 ご回答ありがとうございます。データシートは大変参考になりました。 同じ接合部の最大許容温度を教えてもらえますか?それとも動作温度を考慮してもいいですか? ありがとうございます。 ひどい
View full article
关于 RDBESS774A3EVB 的咨询 - 由于连接器(J1_1 和 J1_3)互换导致的板损坏 您好, 我目前正在评估RDBESS774A3EVB电池监控单元 (CMU) 板(采用 MC33774A 电池单元控制器),该板连接到 50 节电池组设置。 最近,我们在测试过程中发生了一起意外的连接错误。我们错误地将J1_1 (上部)和J1_3 (下部)之间的电池连接器组互换了。 事件发生期间观察到以下行为: 初始事件:连接器互换后,第 36 单元立即发生严重短路,导致外部电线/线路烧毁断裂。 后续措施:发现错误后,我们使用正确的连接器位置将电池组重新连接到同一块电路板上。 次要行为:一旦建立了正确的连接,板上的多个平衡电阻器(R_balance)就开始过热并烧毁。 基于以上情况,我们非常希望您能就以下问题提供工程方面的见解: Q1:在第一次事件中,J1_1 和 J1_3 之间的初始连接器互换是否对 MC33774A IC 或相关电路造成了灾难性的内部损坏? Q2:假设在第二次(正确的)连接期间多个平衡电阻烧毁是由于第一次事故造成的 MC33774A IC 内部损坏(例如,内部 FET 击穿或栅极驱动器卡在导通状态)的直接结果,这种假设是否正确? Q3:如果我们更换损坏的MC33774A IC和所有烧毁的平衡电阻,RDBESS774A3EVB板能否恢复到完全功能和安全的工作状态?除了主集成电路之外,是否还有其他重要的配套组件(例如静电放电/齐纳保护二极管或隔离电路元件)需要检查或更换? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 嗨@guoweisun , 我们没有将整个 50 节电池组连接到一个连接器上。相反,我们的 50 单元系统分为三个独立的部分,并配有三个不同的单元连接器。 1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 初始事件错误:连接器交换 2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 后续操作:正常连接 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 你是说你把50*3.6V加错了吗?MC33774 第一部分中 C17 到地之间的电压是多少? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 嗨@guoweisun , 为了确保硬件的功能安全并防止任何潜在的接线问题,我们设计了一个中间“CSU 桥接板” ,将我们的 50S 电池组连接到 RDBESS774A3EVB(采用菊花链连接三个 MC33774A AFE)。 请您查看我们附上的原理图( CSUBridge_Connector.png和CSUBridge_Block Diagram.png ),并确认我们的引脚映射和连接方式是否正确?   Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 似乎没有发现其他问题,但请注意 GDN1 GND2 GND3 的位置。 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 感谢您一直以来的支持。首先,我们想澄清一下我们实际硬件配置中的 AFE 堆叠顺序,以确保我们保持一致: AFE1 (J1_1)指定用于高压级(单元 37–50)。 AFE3 (J1_3)指定用于低电压级(单元 1–18)。 我们附上了一张图片,其中记录了我们最近的发现以及我们目前面临的关键问题。 我们希望您能就之前提出的关于第一次事件的问题,以及新董事会提出的新问题,给出明确的答复: 【第一部分:对第一次板的回顾性问题】 Q1:在第一次事件中,J1_1 和 J1_3 之间的初始连接器互换是否对 MC33774A IC 或相关电路造成了灾难性的内部损坏? Q2:假设在第二次(更正后的)连接过程中多个平衡电阻烧毁是由于第一次事故造成的 MC33774A IC 内部损坏(例如,内部 FET 击穿或栅极驱动器卡在导通状态)的直接结果,这种假设是否正确? Q3:如果我们更换损坏的MC33774A IC和所有烧毁的平衡电阻,RDBESS774A3EVB板能否恢复到完全功能和安全的工作状态?除了主集成电路之外,是否还有其他重要的配套组件(例如静电放电/齐纳保护二极管或隔离电路元件)需要检查或更换? 【第二部分:新董事会带来的新问题】 按照上述正确的堆叠顺序(高压端接 AFE1/J1_1,低压端接 AFE3/J1_3),我们尝试使用全新的 RDBESS774A3EVB 板来测试我们的系统。 然而,一接上电源,就立即冒烟,高压段(37-50 节电池/AFE1)上的平衡 IC(MC33774A)再次损坏。 鉴于连接映射完全按照预期进行(高对高,低对低),请问您能否帮助我们分析一下为什么新板在 AFE1 阶段立即失效? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 嗨@guoweisun , 我们目前遇到一个严重的问题,即在多个电池组依次连接时,均衡IC会损坏。 根据当地 NXP 技术建议,对于我们第 1 组部分(监控 14 个电池单元)上未使用的通道,我们已将未使用的引脚直接连接到平衡 IC 输入端,具体如下: CB15-18 与 CB14 短路 CT15-18 与 CT14 连接短路 以下是我们的测试流程详情及相应结果: 测试 1:单组连接(仅限组 1) 步骤:我们只连接了第 1 组,该组对应于最高电位段:电池 37 至电池 50(共 14 个电池,总电压约为 100 伏)。50V)。 结果:板运行正常。我们能够准确读取所有电池的电压。VBAT_1 相对于 GND_1 的测量电压稳定在约 50V。未发现异常情况。 测试 2:完整的 3 组连接(顺序上电) 步骤:我们将所有 3 个细胞组同时连接起来,但严格按照从下到上的插入顺序,从第 3 组(底部细胞)开始,一直到第 1 组(顶部细胞)。 结果:连接完成后,电阻 R1_1(10 欧姆)附近出现烟雾和可见的烧焦痕迹。我们立即切断电源以防止进一步损坏,并检查了电路板。 事后分析及损害分析: VBAT_1 至 GND_1 短路:电气测试显示 VBAT_1 和 GND_1 之间存在短路。由于这条电源线直接连接到平衡集成电路,我们怀疑是内部硅芯片故障。 电阻器 R1_1:发现 10 欧姆电阻器已烧毁开路(开路)。 CT 和 CB 引脚:检查了 CT 和 CB 引脚;未发现这些引脚有任何物理或电气损坏。 平衡电阻:检查了所有外部电池平衡电阻;所有电阻均完好无损。 IC 根本原因验证:我们从 PCB 上拆焊了平衡 IC,以隔离问题。对未安装的集成电路进行测试,证实 VBAT 和 GND 引脚之间存在永久性内部短路。 向恩智浦技术支持提出的问题: 鉴于单独给第 1 组供电时配置工作完美,当所有三组依次(从下到上)插入时,什么会触发平衡 IC 内部的 VBAT 到 GND 故障? 将未使用的引脚短接(CB15-18 到 CB14,以及 CT15-18 到 CT14)的终端方法是否会在多芯片菊花链热插拔过程中引起意外的瞬态或闩锁情况? 为了缓解这种故障模式,我们需要实施哪些具体的热插拔保护、TVS 调整或上电顺序限制? 请帮助我们分析并提出解决此问题的建议。
View full article
FRDM MCX A266のピン設定ツールが見つかりません サイト内のピン設定ツールが見つかりません。 FRDMトレーニング Re: Can't find pin configuration tool for FRDM MCX A266 こんにちは、 これは、ツールを使い始める際に役立つ情報です。 MCUXpresso設定ツールのクイックスタートガイド MCUXpresso設定ツールユーザーガイド(IDE) 必要な情報やツールがあればお知らせください。 敬具、ルイス Re: Can't find pin configuration tool for FRDM MCX A266 https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-config-tools-pins-clocks-and-peripherals:MCUXpresso-Config-Toolsが見つかりました Re: Can't find pin configuration tool for FRDM MCX A266 ご返信ありがとうございます。 可能であれば、これらのツールのステップバイステップ設定の例を教えていただけると助かります。 Re: Can't find pin configuration tool for FRDM MCX A266 こんにちは、 何を達成したいのかによりますが、どのプロセスにアシスタントが必要なのか確認または説明してもらえますか? また、ユーザーガイドのMCUXpresso設定ツールユーザーガイド(IDE)第3章には、手順や写真が付いており、ツールの機能にリダイレクトして設定に合わせて調整できます。 敬具、ルイス
View full article
Wi-Fiコマンド応答タイムアウト 私はi.MXRT1062クロスオーバーMCUと、NXP IW612チップセットを搭載した村田製作所製2EL M.2ワイヤレスカードを使用したプロジェクトに取り組んでいます。このプロジェクトはMCUXpresso SDKとFreeRTOSを使用しています。現在のSDKバージョンは25.12です。 ファームウェアの動作中に、デバッグコンソールに次のような出力が表示されることがあります。 `[wifi] 警告: コマンド応答がタイムアウトしました。コマンド 0x0、長さ 1514、シーケンス番号 0x16 または `[wifi] 警告: コマンド応答がタイムアウトしました。コマンド 0x0、長さ 66、シーケンス番号 0x16 または `[wifi] 警告: コマンド応答がタイムアウトしました。コマンド 0x0、長さ 190、シーケンス番号 0x16 または `[wifi] 警告: コマンド応答がタイムアウトしました。コマンド 0x0、長さ 60、シーケンス番号 0x16 これらの線が何を意味するのか分かりません。おそらく無線モジュールに何らかの問題があるのでしょう。その後、タスクリストが印刷され、パニックが発生し、ファームウェアが停止します。無線接続のトラフィックが多かれ少なかれ多い状態が約30分経過した後に問題が発生するようです。 SDKファイル内の対応する箇所は、`middleware/wifi_nxp/wifidriver/wifi.c`にある`wifi_wait_for_cmdresp`関数内にあります。これは、前回のデバッグコンソール出力とこの行の間に約20秒の間隔があることをさらに裏付けています。 どうすればこの問題を解決できますか?デバッグに関する追加情報を提供したり、SDKの修正をテストしたりするために、協力させていただきます。 Re: Wi-Fi command response timeout こんにちは、 カスタムアプリケーションを使用していることは理解していますが、どのSDKサンプルを起点として使用しましたか?変更を加えていないSDKのサンプルを使用して同じ動作を再現できれば、問題の特定に大いに役立ちます。 ドライバーはコマンド応答を待っていたようですが、タイムアウトになる前に応答を受信できなかったようです。 wifi_config.h ファイルで、以下のデバッグマクロを有効にしてください。 CONFIG_WIFI_CMD_RESP_DEBUG CONFIG_WIFI_EVENTS_DEBUG CONFIG_WIFI_IO_INFO_DUMP CONFIG_WIFI_EXTRA_DEBUG マクロを有効にしたら、サンプルを再構築して再度テストしてください。出力結果を共有してください。 最新のSDKを使ってテストしてみて、問題がまだ発生するかどうかを確認するのが良いでしょう。 Re: Wi-Fi command response timeout これはファームウェアがハングアップした際のデバッグ出力です。過去のログラインが必要な場合はお知らせください。 2026年6月23日 12:27:48.808 [RX] - [wifi] 警告:コマンド応答タイムアウト。指揮0x0、レン890、セクノ0x16 SDIOの複数ポートグループレジスタの値: ダンプ @ 20218FC0 レン:196 **** 00 00 00 00 FF 00 00 00 c3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 7f 00 01 00 01 00 01 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 03 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 00 00 00 00 00 87 0c 00 00 00 00 00 00 00 00 00 00 00 1c c2 06 c0 F4 DE 09 C0 00 1E FF FF 00 0A 36 01 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 00 00 00 00 00 00 FF FF FF 00 00 00 00 00 00 00 00 00 10 cc F0 FF FF 00 00 FF FF FF FF FF F4 74 04 c0 80 98 04 c0 00 00 00 00 ダンプ*******終了 名前 状態 優先度 スタック Num ================================================== main_task 3 581 6 print_dhcp R 0 683 17 アイドル R 0 92 2 TCP/IP B 3 400 1 Tmr Svc B 4 196 3 supplicant_main_tas B 2 1456 14 nfc_cfg B 0 715 7 dhcpd_task B 3 406 15 HTTPサーバーB 1 888 18 wifi_scan_task B 1 255 11 wlcmgr_task B 3 244 13 wifi_drv_task B 3 228 10 lwip_rx B 3 431 8 wifi_core_task B 3 276 12 [wifi] 処理開始 [wifi] wifi認証解除を開始 [FWダウンロード] S 2026/06/23 12:27:48.824 [RX] - 0x602319fc からファームウェアのダウンロードを開始: 1618224 2026/06/23 12:27:54.807 [RX] - [wifi_io] エラー: SDIO - FW Ready レジスタが設定されていません [wifi] エラー: sd_wifi_reinit が失敗しました。ステータスコード -1 ASSERT: wlan_process_hang: 550 アサート失敗: パニック! ASSERT エラー " 0 ": ファイル "C:/tmp/mcuxsdk/mcuxsdk/middleware/wifi_nxp/wifidriver/incl/mlan_api.h" 行 "65" 関数名 "panic" Re: Wi-Fi command response timeout こんにちは、@DanielRuvalcaba さん、この件について何か進展はありますか?SDK 26.03でも同じことが起きますが、もっとデバッグ情報が必要ですか? Re: Wi-Fi command response timeout どのSDKの例を使っていますか? この行動を再現するために必要な手順を教えていただけますか? カスタムボードを使用していますか、それともNXPのリファレンスボードを使用していますか? この問題が常に発生する特定の行動や状況はありますか? よろしくお願いいたします。 ダニエル。 Re: Wi-Fi command response timeout 最初はSDKの例wifi_setup始めましたが、今はかなり大幅に改変されています。私はカスタム基板を使用しています。 この問題は、無線カードへの受信トラフィック(おそらく送信トラフィックも)が大量(60メガバイト/秒以上)で、同時にファームウェアが無線カードに平均RSSIとSNRを照会するコマンドを送信したときに発生することがわかりました。私たちのコードはそれを1秒に1回実行しており、問題は1分以内、通常はそれよりも短い時間で発生しました。 コマンド送信を無効にすると、この問題は発生しません。 この情報が問題の再現に役立つことを願っています(重要なポイントは、大量の受信トラフィックとコマンド送信が同時に発生することです)。
View full article
IMX8M+ 带 BT+WiFi 模块 (AW-XB583MA-PUR) BT 初始化需要 50-60 秒时间 亲爱的恩智浦团队 我们有基于 iMX8M+ 的定制主板,分别在 PCIe 和 UART 上使用 BT & WiFi(来自 Azurawave 的 AW-XB583MA-PUR 模块)。 我们在初始化 BT 时遇到了问题,这需要大约 50-60 秒(持续时间总是固定的)才能通过 UART 获得对第一个 HCI RESET 命令的响应。我们与 Azurawave 团队进行了检查/调试,他们建议我们也与恩智浦进行检查(因为在他们看来),这可能是恩智浦方面的问题。 以下是 SoC 与模块的连接: 恩智浦:UART1_RXD<---> 模块:UART TXD NXP:UART1_TXD<---> 模块:UART RXD NXP:UART3_T<---> XD 模块:UART RTS <---> 恩智浦:UART CTS 设备树更改我们所做的:& uart1 {/* BT */ < >pinctrl- names = " 默认 ";pinctrl- 0 = < & pinctrl_uart1 >;分配的时钟 = < & clk imx8MP_CLK_UART1 >;分配的时钟父母 = < & clk imx8MP_SYS_PLL1_80M >; /*fsl,uart-has-rtscts;*/ 状态 = " 好吧 ";};p inctrl_uart1:uart1grp {fsl,别针 =;}; i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized 你好@hiteshviradiya 希望你一切都好。 你能分享设备树上的详细信息吗?我只看到了 Pinmux 代码。 此外,还有有关您正在使用的电路板支持包 版本以及用于连接到 WIFI 模块的驱动程序的详细信息。 顺祝商祺! 萨拉斯 Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized 亲爱的@Manuel_Salas , 我们使用的是定制版的Buildroot(版本2024.08)。内核版本:6.6.36。我之前已经分享过与蓝牙相关的设备树代码以及 Pinmux,但下面再次分享: &uart1 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart1>; 分配时钟 = <&clk IMX8MP_CLK_UART1>; 已分配时钟父级 = <&clk IMX8MP_SYS_PLL1_80M>; fsl,uart-has-rtscts; 状态 = "正常"; }; pinctrl_uart1: uart1grp { fsl,pins = < MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140 MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140 MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140 MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140 >; }; 如果您需要其他特定的设备树节点,请告诉我。 Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized 您好。 请指定您正在使用的驱动程序。 这是习俗吗?我们的 电路板支持包 中不直接支持 AW-XB583MA。 顺祝商祺! 萨拉斯 Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized 目前正在使用通用 UART 驱动程序。
View full article
S32 Design Studio バージョン v.3.4 の期限切れ 私のS32 Design Studio for S32 プラットフォーム v.3.4期限切れです。ライセンスを拡大していただけますか? 注文番号: S32DS-3-4_156834637 ライセンス総数: 101 アクティベーションコード: 7F70-B731-EFE8-3F4B ご返信よろしくお願いします。 Re: S32 Design Studio version v.3.4 expired こんにちは、 S32DSのライセンス期間が延長されました。以前のコードを使用してS32DSを再度アクティベートしてください。
View full article
S32K389 AES_ACCEL 在加密 64KB 数据时会挂起/冻结 您好,NXP团队: 我正在使用S32K389并测试AES_ACCEL (ACE/MSC)模块。我在处理大型数据缓冲区时遇到了稳定性问题。 测试设置: 模式: AES-密码块链接(CBC) 案例 1(通过):加密4KB数据工作正常。 案例 2(失败):加密64KB数据会导致芯片在执行 AES 服务时立即崩溃/挂起。 观察到的行为: S32DS(S32 设计工作室)在执行 AES 服务期间冻结。 尝试通过调试器连接到 S32K389 完全失败。 问题: 对于每个 AES_ACCEL 事务的最大数据长度,是否存在任何已知的限制? 此致, 显龙 Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data 嗨@wuxianlong 让我查一下。我会尽快回复您。 此致, Lukas
View full article
MPC5644Aコアテスト 私はMPC5644Aチップセットのコアテストを実行しようとしています。 現在私が使用している環境はEclipseとWind Riverです。 私はメーカーのライブラリであるe200Zx_ICST_RTMC_3.0.0をダウンロードしました。このライブラリには、複数のアセンブリソースファイル(.sファイル)が含まれています。 これらのうち、vleは正常にコンパイルされました。 しかし、book_eとspeはコンパイルに失敗します。 コンパイル中に、bc、bcl、bclr、xoris、bclrl、bcctrlなどの様々なアセンブリ命令でエラーが発生しました。book_e および spe アセンブリファイルのプロパティを開き、C/C++ ビルド --> 設定 --> Diab アセンブラ --> その他 --> その他のオプションとフラグに -tPPCE200Z4NEG:simple を追加したところ、コンパイルが正常に完了しました。しかし、デバッグ中に、実際にコアテストを実行する`fsl_self_test_icst.c`内の`Fsl_call_test_execution_icst`の直前に到達しました。次のステップに進むと、無限ループに陥ってしまう。 Eclipseの逆アセンブリで確認したところ、アドレス0x51518(`SPE_ICST_int_logical_test`の開始直後)にステップインすると、すぐに0x3f2b90(空き領域)にジャンプすることがわかりました。 どうすればいいですか?どこから始めたらいいのか分からない。 Re: MPC5644A core test こんにちは、 SCSTはMPC56xxファミリの以下のデバイスのみをサポートしています: MPC560xP MPC564xB-C MPC5644AとMPC564xBは同じe200z4 CPUコアを共有しているため、SCSTライブラリのCPU関連部分は互換性がある可能性があります。しかし、統合に関するあらゆる側面を検討する必要がある。 例外ベクターアドレス メモリ・マップ クロック初期化 ペリフェラル依存関係 リンカースクリプトの前提条件 実際のCPUテストアルゴリズムは、同じe200z4アーキテクチャを対象としているため、ほぼポータブルであるはずです。 NXPは、旧型MPC5644Aデバイス用の公式SCSTライブラリを提供していません。しかし、MPC5644A MPC564xBファミリと同じe200z4コアを使用しているため、デバイス固有の統合詳細を確認した後、MPC564xBソリューションからCPU特化した自己テストルーチンを適用することも可能かもしれません。あるいは、MCUの組み込み安全機構(ECC、CRC、ウォッチドッグ、MPU、例外処理)を用いて、プロジェクト固有の機能安全要件を満たすカスタム起動診断実装を開発することも可能です。 どうすればいいですか?どこから始めたらいいのか分からない。 コードが0x51518でSPE_ICST_int_logical_test()に入り、すぐに空のメモリと思われる0x3F2B90に分岐する場合、私の最初の疑いはCPUの故障ではなく、リンカ/ライブラリの統合の問題です。 SCSTライブラリの場合、これは通常、以下のいずれかを意味します。 1. 関数ポインタまたは分岐テーブルが正しくリンクされていません 2. ライブラリオブジェクトが見つかりません 3. メモリモデルの誤り/VLEの不一致 4. 別のデバイス用に構築されたSCSTライブラリ 5. MMU/TLB変換の問題 よろしくお願いいたします。 ピーター
View full article
複数の*IPアドレスを1つのイーサネットインターフェースにマッピングする(LWIP) こんにちは、 複数のIPアドレスを1つのイーサネットポートに異なるstruct netif論理インターフェースでバインドしようとしています。現在の実装では、動作させるために1つのインターフェースを無効にしています。 適切なアプローチに関するガイダンスや情報源を求めている。どんなご意見でも歓迎いたします。 ありがとうございます int main ( void ) { struct netif netif1 , netif2 ; 整数ret ; ip4_addr_t netif1_ipaddr 、 netif1_netmask 、 netif1_gw ; ip4_addr_t netif2_ipaddr 、 netif2_netmask 、 netif2_gw ; ethernetif_config_t enet_config = { . phyHandle = & phyHandle , . phyAddr = EXAMPLE_PHY_ADDRESS 、 . phyOps = EXAMPLE_PHY_OPS 、 . phyResource = EXAMPLE_PHY_RESOURCE 、 } ; BOARD_ConfigMPU () ; BOARD_InitPins () ; BOARD_BootClockRUN () ; BOARD_InitDebugConsole () ; BOARD_InitModuleClock () ; SCB_DisableDCache () ; IOMUXC_SelectENETClock () ; BOARD_InitBothEnetPins_test () ; BOARD_ENET_PHY1_RESET ; EnableIRQ ( ENET_1G_MAC0_Tx_Rx_1_IRQn ) ; EnableIRQ ( ENET_1G_MAC0_Tx_Rx_2_IRQn ) ; MDIO_Init () ; g_phy_resource.read = MDIO_Read ;​​ g_phy_resource.write = MDIO_Write ;​​ time_init () ; CRYPTO_InitHardware () ; lwip_init () ; 最初の論理インターフェースとそのIP構成を追加する IP4_ADDR ( & netif1_ipaddr , 192 , 168 , 0 , 102 ) ; IP4_ADDR ( & netif1_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR ( & netif1_gw , 192 , 168 , 0 , 100 ) ; netif_add ( & netif1 , & netif1_ipaddr , & netif1_netmask , & netif1_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_default ( & netif1 ) ; netif_set_up ( & netif1 ) ; 2つ目の論理インターフェースとそのIP構成を追加する IP4_ADDR ( & netif2_ipaddr , 192 , 168 , 0 , 111 ) ; IP4_ADDR ( & netif2_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR ( & netif2_gw , 192 , 168 , 0 , 100 ) ; netif_add ( & netif2 , & netif2_ipaddr , & netif2_netmask , & netif2_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_up ( & netif2 ) ; while ( 1 ) { // 両方のnetifから受信フレームをポーリングする ethernetif_input ( & netif1 ) ; ethernetif_input ( & netif2 ) ; sys_check_timeouts () ; // すべてのコアプロトコルのすべてのシステムタイムアウトを処理します } -1を返す; } Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) LWIPで複数のIPアドレスを単一のイーサネットインターフェースにマッピングすることは、異なるネットワーク識別子やサービスを1つの物理接続で扱う必要があるシステムで有用です。重要なのは、IP設定、ルーティング、ARP処理が適切に管理され、各アドレスが競合なく正しく応答することです。組み込みネットワークソリューションを設計する際には、利用可能なハードウェアオプションや、柔軟なネットワーク構成と信頼性の高い通信をサポートする Explore Networking Products を理解することも役立ちます。異なるネットワークシナリオでの適切なテストは、パケット処理やインターフェース設定に関連する問題を特定するのに役立ちます。 Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) こんにちは。問題を投稿されてからかなり時間が経ちましたが、何か解決策は見つかりましたか? 現在、TI TMS570LC43 LaunchPadとlwIP 1.4.1バージョンを使用して同じことを試しています。
View full article
Gui_Guider在生成C code时会出现卡死的情况 在导入字体文件后生成C代码会出现一直生成的情况,我将页面缩减成一个,去除图标生成一个简单的界面也会一直卡在Generating C code的情况。 Re: Gui_Guider在生成C code时会出现卡死的情况 我发现原因就是我直接在Gui_Guider里导入一个新的字体然后Generating C code就会出现卡死,我如何解决这个问题?
View full article
将多个 IP 地址映射到一个以太网接口(LWIP) 你好, 我正在尝试使用不同的 struct netif 逻辑接口将多个 IP 地址绑定到单个以太网端口。我目前的实现方法是禁用其中一个接口才能使其正常工作。 寻求有关正确方法的指导或资源。任何见解都非常感谢。 谢谢! int main ( void ) { struct netif netif1 , netif2 ; int ret ; ip4_addr_t netif1_ipaddr 、 netif1_netmask 、 netif1_gw ; ip4_addr_t netif2_ipaddr 、 netif2_netmask 、 netif2_gw ; ethernetif_config_t enet_config = { . phyHandle = & phyHandle , .phyAddr = EXAMPLE_PHY_ADDRESS ,​ .phyOps = EXAMPLE_PHY_OPS ,​ .phyResource = EXAMPLE_PHY_RESOURCE ,​ } ; BOARD_ConfigMPU () ; BOARD_InitPins () ; BOARD_BootClockRUN () ; BOARD_InitDebugConsole () ; BOARD_InitModuleClock () ; SCB_DisableDCache () ; IOMUXC_SelectENETClock () ; BOARD_InitBothEnetPins_test () ; BOARD_ENET_PHY1_RESET ; 启用IRQ ( ENET_1G_MAC0_Tx_Rx_1_IRQn ) ; 启用IRQ ( ENET_1G_MAC0_Tx_Rx_2_IRQn ) ; MDIO_Init () ; g_phy_resource.read = MDIO_Read ;​​ g_phy_resource.write = MDIO_Write ;​​ time_init () ; CRYPTO_InitHardware () ; lwip_init () ; // 添加第一个逻辑接口及其 IP 配置 IP4_ADDR ( & netif1_ipaddr , 192,168,0,102 ) ;​​​​​​ IP4_ADDR ( & netif1_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR ( & netif1_gw , 192,168,0,100 ) ;​​​​​​ netif_add ( & netif1 , & netif1_ipaddr , & netif1_netmask , & netif1_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_default ( & netif1 ) ; netif_set_up ( & netif1 ) ; // 添加第二个逻辑接口及其 IP 配置 IP4_ADDR ( & netif2_ipaddr , 192,168,0,111 ) ;​​​​​​ IP4_ADDR ( & netif2_netmask , 255 , 255 , 255 , 0 ) ; IP4_ADDR ( & netif2_gw , 192,168,0,100 ) ;​​​​​​ netif_add ( & netif2 , & netif2_ipaddr , & netif2_netmask , & netif2_gw , & enet_config , EXAMPLE_NETIF_INIT_FN , ethernet_input ) ; netif_set_up ( & netif2 ) ; while ( 1 ) { // 轮询两个网络接口以获取传入帧 ethernetif_input ( & netif1 ) ; ethernetif_input ( & netif2 ) ; sys_check_timeouts () ; // 处理所有核心协议的系统超时 } 返回-1 ; } Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) 在 LWIP 中,将多个 IP 地址映射到单个以太网接口,对于需要通过一个物理连接处理不同网络身份或服务的系统来说非常有用。关键在于确保 IP 配置、路由和 ARP 处理得到正确管理,以便每个地址都能正确响应而不会发生冲突。在设计嵌入式网络解决方案时,了解可用的硬件选项并探索支持灵活网络设置和可靠通信的网络产品也很有帮助。使用不同的网络场景进行适当的测试有助于发现与数据包处理和接口配置相关的问题。 Re: mapping multiple * IP addresses to one Ethernet interface (LWIP) 您好,您发布这个问题已经有一段时间了,请问您找到解决方法了吗? 我目前正在使用TI TMS570LC43 Launchpad和lwIP 1.4.1版本尝试同样的操作。
View full article
Rx sensitivity differs by 10dB between consecutive measurements I am observing unexpected behavior for one of our products using QN9083 BLE SoC. When I measure the device receiver sensitivity, I am seeing deltas up to 10dB between consecutive measurements. I am using a CMW100 in advertiser mode to perform measurement and the device is placed in a shielded RF box. Performing consecutive RxS measurements, without opening the box and/or changing device location, the device responds with up to 10dB difference (i.e., -91dBm and -81dBm) which is unexpected and never happened before. The behavior is random. I am looking for possible causes both hardware and software. Re: Rx sensitivity differs by 10dB between consecutive measurements Hello, A variation of up to 10 dB between consecutive sensitivity measurements is not something we would normally expect. Could you share the software/SDK version currently being used? Also, can you clarify: Does this occur on a single device or multiple products? Have you seen the same behavior across different units? Can the issue be reproduced on an NXP development board using the same measurement setup? This information will help determine whether the issue is specific to the hardware, software, or test environment. Best Regards, Ricardo Re: Rx sensitivity differs by 10dB between consecutive measurements Hello thank you for getting back to me. Here are my answers: Could you share the software/SDK version currently being used?       5.0 based on 156414 (Controller Subsystem) and 156821 (Host Subsystem) Does this occur on a single device or multiple products?       Same product. Never had the issue with different products. Have you seen the same behavior across different units?       Yes but not consistently Can the issue be reproduced on an NXP development board using the same measurement setup?       I will need a dev board with QN9083 and a FW that will set the chip on advertising Thank you,      
View full article
RT1064 : pin configuration to boot from internal flash Hello, This may sound as a dumb/noob question but I can't determine precisely what must be done on the BOOT_MODE1/BOOT_MODE0 and BT_CFG[11..0] pins to configure the RT1064 to boot from its internal flash memory. Table 9.9 from the reference manual lists only 3 boot sources (NOR flash via FlexSPI, SDCARD and eMMC) but the internal flash is not listed, as if this section has been copied/pasted from RT1060... AN12290 mentions a FlexSPI2 internal bus to this internal flash but does not indicate how to select it over the 3 above-mentionned boot sources. Table 5 from the MIMXRT1060/1064 Evaluation Kit Board Hardware User's Guide indicates that 2 boot modes only are availble (QSPI or SDCARD) and also claims that QSPI boot is not available (note from 2.7 paragraph), leaving SDCARD as the sole boot source... Any help greatly appreciated i.MXRT 106x
View full article
CLI/Headless Hello! Does GUI Guider 2.0.0 have any CLI / Headless build features for automating some CI builds of my project? I'd rather not track generated c files in my repo. Re: CLI/Headless I would also like to know this please. Re: CLI/Headless Hi @nbarrett , @znickerson , GUI Guider does not natively support CLI or headless code generation that you could invoke from a CI pipeline. That said, GUI Guider 2.0.0 leverages CMake and Ninja to build and compile the code generated from the GUI Guider project into a flashable .bin or .elf image, so automating this process should be achievable by creating a script that uses these tools. We don't currently have any documented guide or script example of how this would be done, but you can reference the build and compile log from the GUI Guider tool to see in detail the process that GUI Guider 2.0.0 does on an ARMGCC based project. BR, Edwin.
View full article
RDBESS774A3EVBに関するお問い合わせ - コネクタ(J1_1とJ1_3)の入れ替えによる基板の損傷 こんにちは、 現在、 RDBESS774A3EVB セルモニタリングユニット(CMU)ボード(MC33774Aバッテリー・セルコントローラ搭載)を50セルのバッテリーパック構成に接続して評価しています。 先日、テスト中に偶発的な接続ミスが発生しました。誤って、 J1_1 (上側のセット)とJ1_3 (下側のセット)のセルコネクタセットを入れ替えてしまいました。 事件発生時に以下の行動が観察された。 初期イベント: コネクタを交換した直後、セル36で激しいショートが発生し、外部の配線/トレースが焼き切れてしまいました。 その後の行動: ミスが分かった後、正しいコネクタ位置で同じ基板にバッテリーパックを再接続しました。 二次的な挙動:正しい接続が確立されるとすぐに、基板上の複数のバランス抵抗(R_balance)が過熱して焼損し始めました。 このシナリオに基づき、以下の質問に関して貴社の技術的な見識をお聞かせいただければ幸いです。 Q1: 最初の出来事でJ1_1とJ1_3のコネクタが交換され、MC33774A ICや関連回路に壊滅的な内部損傷を引き起こしましたか? Q2: 2回目の(正しい)接続中に複数のバランス抵抗が焼き切れたのは、最初の事故によるMC33774A IC内部の損傷(例:内部FETブレークダウンやゲートドライバーのオン状態の停止)が直接原因と考えてよいのでしょうか? Q3: 損傷したMC33774A ICと焼失したすべてのバランス抵抗を交換すれば、RDBESS774A3EVB基板は完全に機能し安全な状態に戻せるのでしょうか?他に重要な補助部品(ESD/ゼナー保護ダイオードやアイソレータ回路素子など)は、メインICと併用して点検または交換すべきものはありますか? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) こんにちは@guoweisunさん 50個のセルすべてを1つのコネクタに接続したわけではありません。その代わりに、当社の50セルシステムは、3つの異なるセルコネクタを備えた3つの独立したセグメントに分割されています。 1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 Initial Event ERROR: CONNECTOR SWAP1 2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION2 Subsequent Action: NORMAL CONNECTION 初期イベントエラー:コネクタ 交換 2 その後の動作:通常接続 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 50*3.6V を追加したのが間違いだったということですか?MC33774の最初の部分で、C17とグランド間の電圧は? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) こんにちは@guoweisunさん ハードウェアの完全なセーフティを確保し、配線トラブルを防ぐために、50SバッテリーパックをRDBESS774A3EVBに配線する中間の 「CSUブリッジボード」 を設計しました(3つのMC33774A AFEをデイジーチェーンに配置しています)。 添付の回路図(CSUBridge_Connector.png と CSUBridge_Block Diagram.png)を確認して、ピンのマッピングや接続戦略が正しいか確認していただけますか?   Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) これ以上問題は見つからないようですが、GDN1、GND2、GND3のポジショニングに注目してください。 Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) 皆様の継続的なサポートに感謝いたします。まず、実際のハードウェア構成におけるAFEのスタッキング順序を明確にし、認識のずれがないようにしたいと思います。 AFE1(J1_1)は高電圧ステージ(セル37~50)用に指定されています。 AFE3(J1_3)は低電圧ステージ(セル1~18)用に指定されています。 添付の画像は、我々の最近の調査結果と、現在直面している重大な問題点をまとめたものです。 最初の事件に関する以前の質問や、新しいボードに関する新たな問題について、具体的な回答をいただけるとありがたいです。 【パート1:最初のボードに関する回顧的な質問】 Q1: 最初のJ1_1とJ1_3のコネクタ交換が、その最初のイベント情報でMC33774A ICや関連回路に壊滅的な内部損傷を引き起こしましたか? Q2: 2回目の(修正済み)接続時に複数のバランシング抵抗が焼き切れたのは、最初の事故によるMC33774A IC内部の損傷(例:内部FETブレークダウンやゲートドライバーがON状態で固着した)が直接原因と考えてよいのでしょうか? Q3: 損傷したMC33774A ICと焼失したすべてのバランス抵抗を交換すれば、RDBESS774A3EVB基板は完全に機能し安全な状態に戻せるのでしょうか?他に重要な補助部品(ESD/ゼナー保護ダイオードやアイソレータ回路素子など)は、メインICと併用して点検または交換すべきものはありますか? 【パート2:新しいボード】 上記で述べた正しいスタッキング順序(高電圧をAFE1/J1_1、低電圧をAFE3/J1_3)に従って、全く新しいRDBESS774A3EVBボードを使用してシステムをテストしました。 しかし、コネクテッド直後に 煙が発生し、高電圧セグメント(セル37–50 / AFE1)のバランスIC(MC33774A)が再び損傷しました。 接続が意図通りにマッピングされていた(HighからHigh、LowからLow)なのに、なぜ新しいボードがAFE1段階で即座に故障したのか、分析を手伝っていただけますか? Re: Inquiry regarding RDBESS774A3EVB - Board Damage due to Swapped Connectors (J1_1 and J1_3) こんにちは@guoweisunさん 現在、複数のバッテリーセルグループの連続接続中にバランスICが損傷する深刻な問題に直面しています。 グループ1セクション(14セルを監視)の未使用チャネルに関するNXPのローカル技術アドバイスに従い、未使用ピンはバランシングIC入力で直接終了しました: CB15-18をCB14に接続してショート コネクテッド CT15-18がCT14にショートした 以下に、当社の試験手順とそれに対応する結果の詳細を示します。 テスト1:単一グループ接続(グループ1のみ) 手順:グループ1のみを接続しました。これは最も高い電位セグメントであるセル37からセル50にかけて(合計14セル、合計電圧は50V)。 結果:基板は正常に動作しました。私たちはすべての電池の電圧を正確に読み取ることができました。GND_1に対するVBAT_1の測定電圧は約50Vで安定していた。異常は観測されなかった。 テスト2:フル3グループ接続(シーケンシャル電源アップ) 手順:3つの細胞群すべてを同時に接続しましたが、厳格な下から上への挿入順序に従い、グループ3(下のセル)からグループ1(上のセル)へと進みました。 結果:接続が完了すると、抵抗器R1_1(10オーム)付近で煙と目に見える焦げが発生しました。さらなる損傷を防ぐため、直ちに電源を遮断し、基板を点検した。 事後分析および損傷分析: VBAT_1とGND_1間の短絡:電気的テストにより、VBAT_1とGND_1の間に完全な短絡が発生していることが判明しました。この電源ラインはバランス調整ICに直接接続されているため、内部のシリコン故障を疑いました。 抵抗器R1_1:10オームの抵抗器が断線(オープン回路)していることが判明しました。 CTおよびCBピン:CTピンとCBピンの両方を検査しましたが、これらのピンには物理的または電気的な損傷は検出されませんでした。 バランス調整抵抗器:外部セルバランス調整抵抗器をすべて点検しました。すべて損傷なく正常な状態です。 ICの根本原因検証:問題を切り分けるために、バランス調整ICを基板から取り外しました。実装されていないICをテストしたところ、VBATピンとGNDピンの間に恒久的な内部短絡が発生していることが確認された。 NXPサポートへの質問: グループ1が個別に電源を入れると構成が問題なく動作するのを考えると、3つのグループすべてが順番に接続されている場合、バランシングIC内でVBATからGNDへの内部故障を引き起こす原因は何でしょうか? 未使用ピン(CB15-18からCB14、CT15-18からCT14)をショートさせる終端方式が、マルチチップデイジーチェーンのホットプラグ時に予期せぬ過渡状態やラッチアップ状態を引き起こす可能性はありますか? この故障モードを軽減するために、具体的にどのようなホットプラグ保護、TVS調整、または電源投入シーケンスの制約を実装する必要がありますか? この問題の分析と解決策の提案にご協力ください。
View full article
受信感度は連続測定間で10dBの差がある。 QN9083 BLE SoCを使用している当社の製品の一つで予期せぬ挙動を観察しています。機器のレシーバ感度を測定すると、連続した測定間で最大10dBの差が見られます。CMW100を広告モードで測定しており、機器はシールドされたRFボックスに設置されています。箱を開けたり、デバイスの設置場所を変更したりせずに、連続してRxS測定を行ったところ、デバイスは最大10dBの差(-91dBmと-81dBm)を示しました。これは予想外で、これまで一度も発生したことのない現象です。その挙動はランダムである。ハードウェアとソフトウェアの両方の可能な原因を探しています。 Re: Rx sensitivity differs by 10dB between consecutive measurements こんにちは、 連続する感度測定値間で最大10dBものばらつきが生じるのは、通常想定されることではありません。 現在使われているソフトウェアやSDKのバージョンを教えてもらえますか? それと、もう少し詳しく教えていただけますか: これは単一のデバイスで起こるのか、それとも複数の製品で起こるのか? 異なる部署間で同様の行動が見られましたか? 同じ測定セットアップを使ってNXPの開発ボードでも同じ問題を再現できますか? この情報は、問題がハードウェア、ソフトウェア、テスト環境に特有のものかを判断するのに役立ちます。 よろしくお願いいたします。 リカルド Re: Rx sensitivity differs by 10dB between consecutive measurements こんにちは。ご連絡いただきありがとうございます。私の回答は以下のとおりです。 現在使われているソフトウェアやSDKのバージョンを教えてもらえますか? 5.0 は156414(コントローラーサブシステム)および156821(ホストサブシステム)に基づいています これは単一のデバイスで起こるのか、それとも複数の製品で起こるのか? 同じ製品です。他の製品では問題が起きたことは一度もありません。 異なる部署間で同様の行動が見られましたか? はい、ただし一貫しているわけではありません 同じ測定セットアップを使ってNXPの開発ボードでも同じ問題を再現できますか? QN9083を搭載した開発ボードと、チップをアドバタイジングモードに設定するファームウェアが必要です。 ありがとうございました。      
View full article
S32K389 AES_ACCEL が 64KB のデータを暗号化する際にハング/フリーズする こんにちは、NXPチームの皆様、 私はS32K389を使用しており、 AES_ACCEL(ACE/MSC)モジュールをテストしています。大規模なデータバッファをプロセッシング中に安定性の問題に直面しました。 テスト設定: モード:AES-CBC CASE 1(合格):4KBデータの暗号化は正しく動作します。 ケース2(失敗):64KBのデータを暗号化すると、AESサービスが実行されるとチップが即座にクラッシュまたはハングします。 観察された行動: S32DS(S32 Design Studio)はAESサービスの実行中にフリーズします。 デバッガを介してS32K389に接続しようとすると、完全に失敗します。 質問: AES_ACCELトランザクションあたりの最大データ長に関して、既知の制限事項はありますか? よろしくお願いします、 シアンロン Re: S32K389 AES_ACCEL hangs/freezes when encrypting 64KB data こんにちは@wuxianlong 確認させてください。できるだけ早くご連絡いたします。 よろしくお願いいたします。 ルーカス
View full article