Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
LS1046A DDR4 32GB DDR4 容量支持 你好, 我想知道LS1046A是否支持32GB DDR4内存。它是否兼容DDR3L? Re: LS1046A DDR4 32GB DDR4 Size Support 感谢yipingwang的及时回复,请问LS1034A支持的最大DDR内存容量是多少? Re: LS1046A DDR4 32GB DDR4 Size Support 1. LS1046A 是否支持 32 GB DDR4? 是的。 2. LS1046A 可以与 DDR3L 兼容吗? 不。 LS1043A 支持 32 位 DDR3L/DDR4 控制器,而 LS1046A/LS1088A 支持 64 位 DDR4 控制器。 Re: LS1046A DDR4 32GB DDR4 Size Support 根据 LS1043A 参考手册/产品简介,LS1043A 支持高达 32 GB 的 DDR/主内存。
記事全体を表示
PMIC Safety Configuration by MCU Hello NXP, From the FS26 Safety Manual, we understand that the fault reactions for the output regulators can be configured by the MCU during initialization. Could you please clarify whether this configuration requirement applies only to the output regulator fault reactions, (RSTB , FS0B & 01) of  PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 or whether the fault reactions for the internal voltage monitoring functions (e.g., VANA, VDIG, and other internally monitored supply rails) also need to be configured by the MCU during initialization? If the internal voltage monitoring fault reactions are not configurable by the MCU, can we assume that these reactions are fully managed internally by the FS26 PMIC? can you list which fault reaction does not required to be configured by the MCU and which requires  FSBC+PMIC Functional Safety Re: PMIC Safety Configuration by MCU You can refer to below picture showed: guoweisun_0-1785720521280.png ABIST can check VANA VDIG automatically not need configure. guoweisun_1-1785720570149.png
記事全体を表示
imx93 AHAB SGK サポート セキュア ブート署名用の SGK は imx93 でサポートされるようになりましたか、それとも SRK のみですか? アプリケーションノート12312「AHAB対応デバイスでのセキュアブート」の第3章には次のように書かれています。 注意: i.MX8ULP および i.MX93 の場合、現在リリースされているファームウェアでは SRK のみがサポートされています。 これはまだ当てはまりますか、それとも SGK は現在サポートされていますか?もしSOなら、どのファームウェアリリースからですか? Re: imx93 AHAB SGK support これは今でも真実です。SGK は i.MX93 ではサポートされていません。 よろしくお願いします。 Harvey Re: imx93 AHAB SGK support こんにちは、IMX91はどうですか?SGKをサポートしていますか?(リファレンス・マニュアルはそう示唆しています) [[ ## completed ##]]
記事全体を表示
通过MCU进行PMIC功能安全配置 您好,NXP, 根据 FS26 功能安全手册,我们了解到,输出调节器的故障反应可以在初始化期间由 MCU 配置。 请问此配置要求是否仅适用于输出调节器故障响应(RSTB、FS0B 和 01)? PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 或者, MCU在初始化期间是否也需要配置内部电压监测功能(例如VANA、VDIG和其他内部监控的电源轨)的故障响应? 如果 MCU 无法配置内部电压监控故障反应,我们是否可以假设这些反应完全由 FS26 PMIC 在内部管理? 能否列出哪些故障响应不需要由MCU配置,哪些需要配置? FSBC+PMIC 功能安全 Re: PMIC Safety Configuration by MCU 您可以参考下图: guoweisun_0-1785720521280.png ABIST 可以自动检查 VANA VDIG,无需配置。 guoweisun_1-1785720570149.png
記事全体を表示
SGTL5000XNLA3/R2 部分处于激活状态 大家好, SGTL5000XNLA3/R2 这个部件是否处于激活状态?我们可以把它用于新设计吗? 数据手册中提及的EOL Re: SGTL5000XNLA3/R2 is part is active 好的,谢谢你的回复。 Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 产品信息 | 恩智浦半导体 guoweisun_0-1785821314080.png 数据表显示: guoweisun_1-1785824177846.png
記事全体を表示
SGTL5000XNLA3/R2 is part is active Hi Team, is this part is active SGTL5000XNLA3/R2? Can we use it for new design Datasheet mentioned asEOL Re: SGTL5000XNLA3/R2 is part is active Ok. Thanks for the response Re: SGTL5000XNLA3/R2 is part is active SGTL5000XNLA3 Product Information | NXP Semiconductors guoweisun_0-1785821314080.png datasheet shows : guoweisun_1-1785824177846.png
記事全体を表示
FS6500 IO2_3/FCCU故障在调试模式和正常模式下的行为差异 你好!   FS6500 的 IO2_3 引脚连接到 MCU FCCU。   在调试模式下,单个 FCCU 故障触发会导致立即复位。   在正常运行模式下,单个 FCCU 故障触发信号会导致 SBC 进入深度故障保护 (DFS) 模式。 请问这种现象是否属于预期行为? 我的理解是:IO2_3故障将增加故障错误计数器。只有当故障错误计数器超过配置的阈值(3 或 6)时,才应执行功能安全响应(RSTB 脉冲、FS0B 断言或 DFS 转换)。 FS6500 DEVKIT-MPC5744P Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 嗨,彼得, 非常感谢您的解释。   我还有一个问题。   我仔细查阅了 FS6500 数据手册和 RM,但几乎没有文档介绍由 IO2_3 FCCU 故障触发信号所触发的功能安全机制策略以及相应的 IMPACT 寄存器配置。 之前我以为 IO2_3 故障会使故障错误计数器递增,功能安全措施会在计数器达到阈值后生效。根据您的回复,IO2/IO3故障会直接触发信号安全响应。   请问手册的哪一章介绍了IO2/IO3直接功能安全反应的配置? 顺祝商祺! Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 你好, 如果两次测试中 SBC 的运行条件不同,则可能会出现这种现象。 请区分以下各项: 例如,MCU调试模式,即调试器连接到MPC设备,以及 FS6500 调试模式,通过 FS6500 DEBUG 引脚进入。 当 FS6500 处于调试模式时,看门狗仍在内部运行,但它不会通过置位 RESET 或故障保护引脚来影响设备操作。因此,调试期间观察到的行为可能与独立组网 \(SA\)/正常运行时的行为有所不同。此模式旨在允许进行软件调试,而无需 SBC 不断重置系统。 在正常运行中,FS6500 故障保护状态机监测已配置的功能安全输入/反应。如果 IO_2/IO_3 用于 MCU FCCU 错误输出监控,则 SBC 可以检测到 FCCU 故障,并执行配置的反应,例如根据配置断言 FS0B/RSTB。 因此,调试模式和独立组网 \(SA\)模式之间的不同行为不一定是MCU FCCU的问题。这很可能是由于 FS6500 处于调试模式,或者两种情况下 SBC 初始化/配置存在差异造成的。 故障错误计数器通常与看门狗监控和故障保护状态机处理等机制相关联。FCCU 报告的功能安全关键故障应直接发出触发信号,以触发其配置的反应,而不是累积到计数器达到阈值。 因此,观察到的即时功能安全响应行为与预期的功能安全理念是一致的。 顺祝商祺! Peter Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode 你好, 关键在于,FS6500 对 IO2/IO3 FCCU 监控的处理方式与其他大多数故障源不同。 该描述不在 FCCU 故障反应 (IMPACT) 表中,而是在 FS6500 故障保护故障管理文档中。 根据 FS6500 文档,IO_23 错误检测 (FCCU) 被列为始终递增故障错误计数器的故障源之一,并且无法配置为关闭。文档明确将其与可配置故障源区分开来。 因此,观察到的 IO2/IO3 故障行为并非完全由用于可配置故障保护反应的 IMPACT 寄存器设置所控制。IO2/IO3 FCCU 监测器是 SBC 专用的 FCCU 监视路径的一部分,由故障保护状态机处理。 需要查阅的相关章节是 FS6500 文档中的“故障计数器”章节,其中指出: IO_23 错误检测 (FCCU) 会增加故障错误计数器。 此行为不可配置。 https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html 顺祝商祺! Peter
記事全体を表示
MCUによるPMICセーフティ構成 こんにちは、NXPさん。 FS26セーフティマニュアルから、出力レギュレータの故障反応は初期化時にMCUによって設定できることが理解されています。 この構成要件が出力レギュレーターの故障反応にのみ適用されるのか、明確にしていただけますか(RSTB, FS0B & 01) PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 また、 内部電圧監視機能 (例: VANA、VDIG、その他の内部監視供給レール)の故障反応も初期化時にMCUによって設定される必要があるのか? 内部電圧監視の故障反応がMCUで設定できない場合、これらの反応はFS26 PMICが内部で完全に管理していると考えてよいでしょうか? どの故障反応がMCUで設定不要で、どの回路が設定が必要かをリストアップできますか? FSBC+PMIC 機能安全 Re: PMIC Safety Configuration by MCU 以下の写真を参照してください: guoweisun_0-1785720521280.png ABISTはVANAのVDIGを自動的にCANチェックできます。設定は不要です。 guoweisun_1-1785720570149.png
記事全体を表示
RTC Power Calculation Hello NXP, We are calculating battery life for RTC for which active & sleep current are required for SNVS power domain in RT1176. However refer to datsheet IMXRT1170BIEC - Table13, page 35, only sleep current is given. Please let us know the factors affecting the active current and various calculations related to active current for the SNVS power domain. Re: RTC Power Calculation Hi @specneeraj , Thanks for your interest in NXP MIMXRT series! VDD_SNVS_IN supplies power to the SNVS/RTC domain. This domain is an always-on, low-power domain that primarily maintains the 32 kHz RTC, SNVS logic, and related wake-up and safety functions. Its current consumption is only weakly correlated with the active/sleep states of CM7/CM4; therefore, the VDD_SNVS_IN values for the SNVS mode listed in Table 13 are not omitted “sleep-only” data, but rather baseline values that can be used in RTC backup scenarios. If the coin cell only provides power when the main power source fails → Use the SNVS mode current estimate directly; If the coin cell also supplies power to VDD_SNVS_IN while the system is active, calculate the average current based on the active/SNVS duty cycle. The main factors affecting the SNVS current include temperature,  VDD_SNVS_IN  voltage, process variations, leakage from the 32 kHz RTC crystal/board, external leakage from SNVS-related pins, and whether the device has actually entered SNVS mode. Please refer to AN13104 for more details. Best regards, Gavin
記事全体を表示
Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hi!   The IO2_3 pin of FS6500 is connected to the MCU FCCU.   In DEBUG mode, one single FCCU fault trigger leads to an immediate reset.   In Normal operating mode, one single FCCU fault trigger causes the SBC to enter Deep Fail-Safe (DFS) mode. Could you help confirm whether this behavior is expected? My understanding: The IO2_3 fault will increment the Fault Error Counter. The safety responses (RSTB pulse, FS0B assertion or DFS transition) should only take place once the Fault Error Counter exceeds the configured threshold (3 or 6). FS6500 DEVKIT-MPC5744P  Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hi Peter, Thanks a lot for your clarification.   I have a further question.   I searched the FS6500 datasheet and RM thoroughly, yet there is little documentation introducing the safety mechanism strategy triggered by IO2_3 FCCU fault, as well as the corresponding IMPACT register configuration. Previously I thought IO2_3 fault will increment the Fault Error Counter, and safety actions take effect after the counter hits the threshold. According to your reply, IO2/IO3 fault triggers safety response directly.   Could you tell me which chapter of the manual covers the configuration of direct safety reaction for IO2/IO3? Best regards Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hello, This behavior can be expected if the SBC is not in the same operating condition in both tests. Please distinguish between: MCU debug mode, for example debugger attached to the MPC device, and FS6500 debug mode, which is entered through the FS6500 DEBUG pin. When the FS6500 is in debug mode, the watchdog still runs internally, but it does not affect device operation by asserting reset or fail-safe pins. Therefore, the behavior observed during debug can differ from standalone/normal operation. This mode is intended to allow software debugging without the SBC continuously resetting the system. In normal operation, the FS6500 fail-safe state machine monitors the configured safety inputs/reactions. If IO_2/IO_3 are used for the MCU FCCU error output monitoring, then an FCCU fault can be detected by the SBC and the configured reaction can be executed, for example assertion of FS0B/RSTB depending on the configuration. So the different behavior between debug and standalone mode is not necessarily an MCU FCCU issue. It is most likely caused by the FS6500 being in debug mode, or by a difference in the SBC initialization/configuration between the two cases. The Fault Error Counter is typically associated with mechanisms such as watchdog supervision and fail-safe state machine handling. A safety-critical fault reported by the FCCU should trigger its configured reaction directly rather than being accumulated until the counter reaches its threshold. Therefore, the observed behavior of an immediate safety response is consistent with the intended safety concept. Best regards, Peter Re: Behaviour discrepancy of FS6500 IO2_3/FCCU fault between Debug mode and Normal mode Hello, The key point is that the FS6500 treats IO2/IO3 FCCU monitoring differently from most other fault sources. The description is not located in the FCCU fault-reaction (IMPACT) tables, but rather in the FS6500 fail-safe fault management documentation. According to the FS6500 documentation, IO_23 error detection (FCCU) is listed among the fault sources that always increment the Fault Error Counter and cannot be configured out. The documentation explicitly separates it from the configurable fault sources. Therefore, the behavior observed with an IO2/IO3 fault is not governed solely by the IMPACT register settings that are used for configurable fail-safe reactions. The IO2/IO3 FCCU monitor is part of the dedicated FCCU supervision path of the SBC and is handled by the fail-safe state machine. The relevant section to review is the FS6500 documentation chapter "Fault error counter", which states: IO_23 error detection (FCCU) increments the Fault Error Counter. This behavior is not configurable. https://docs.nxp.com/bundle/FS6500-FS4500-ASILD/page/topics/fault_error_counter.html Best regards, Peter
記事全体を表示
Automotive Steering Control Using FRDM-A-S32K3XX Microcontrollers 1. Overview This module demonstrates how to implement a steering control system using Pulse Width Modulation (PWM) on NXP S32K3 microcontrollers. The application reads an analog input from a potentiometer (simulating a steering wheel) and converts it into a servo motor position. As the input changes, the servo motor reacts in real time, mimicking how steering systems work in modern vehicles. This example is based on Application Code Hub demonstrations for: PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 In this workshop, a POT Click simulates the steering wheel position. When the student rotates it, an analog voltage proportional to the angle is read by the MCU through the ADC, scaled in software, and converted into a PWM duty cycle. The PWM is generated by the Servo Click (configured by the MCU over I²C) and drives a Micro Servo motor SG 180°, whose angle tracks the potentiometer in real time. Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic steering control system and the ideas behind EPS and steer-by-wire. Use the POT Click as a simulated steering-wheel input. Acquire analog values (0–3.3 V) using the ADC and understand analog-to-digital conversion. Perform signal scaling from the ADC range to a servo angle / PWM duty cycle. Generate PWM signals to drive a servo motor. Configure the Servo Click over I²C using the OE (Output Enable) pin. Recognize the actuation data flow: sensor input → MCU processing → PWM actuation. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why steering functions are relevant for functional safety. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Potentiometer (POT Click simulates the steering-wheel position) Processing: S32K3 MCU (reads the ADC, scales the value, commands the actuator) Output: Servo motor controlled via PWM (Micro Servo SG 180°) This matches the classic flow of an embedded actuation system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The potentiometer generates an analog voltage based on its position The ADC converts this voltage into a digital value The application scales this value into a steering angle The system generates a PWM signal based on the angle The servo motor moves accordingly This loop runs continuously to ensure real-time control. Designer.png Steering Monitoring Application Architecture 4. Key Concepts 4.1 ADC (Analog-to-Digital Converter) The POT Click outputs 0–3.3 V depending on the wiper position. The ADC samples this voltage at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). The further the potentiometer is turned, the higher (or lower) the digital sample. ADC acquisition is the foundation of automotive sensing — used for torque, throttle, battery voltage, and many others. 4.2 Signal Scaling — From ADC to Servo Angle The ADC range (for example 0–4095) and the servo range (0°–180°, expressed as a PWM duty cycle) are different. The application performs a linear mapping so that one end of the potentiometer corresponds to one steering extreme and the other end to the opposite. This is the same scaling used in real EPS systems, where a hardware reading is converted into a normalized control command. 4.3 PWM — Pulse-Width Modulation and Servo Control PWM switches a digital output on and off at a fixed frequency, varying the duty cycle (the fraction of time the signal is high). A hobby servo such as the SG 180° interprets this duty cycle as a position command. In this demo, the PWM is not generated by the MCU itself but by the Servo Click's dedicated PWM controller, which the MCU configures over I²C — a typical embedded pattern that offloads time-critical signal generation and keeps the CPU free for application logic. 4.4 I²C — Configuring the Servo Click I²C — Inter-Integrated Circuit is a two-wire serial bus made of SDA (data) and SCL (clock). The S32K3 uses LPI2C1 on PTC6 (SDA) and PTC7 (SCL) to configure the Servo Click — PWM frequency, channel, and duty cycle. The OE — Output Enable pin on PTB17 is an additional control line that enables or disables the PWM outputs without reconfiguring the chip, which is also useful for a quick "safe stop" behavior. 4.5 POT Click as Steering Wheel The POT Click is a simplified, safe stand-in for a real steering sensor. The student rotates it by hand, the voltage changes, the MCU reads it through the ADC, scales it, and the servo reacts. 4.6 Data Flow at a Glance Physical rotation → analog voltage → ADC sample → scaled command (angle / duty cycle) → I²C configuration of the Servo Click → PWM signal → servo angle. This direct chain from the student's hand to the servo shaft is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K312 FRDM-A-S32K312.png Alternative MCU platform used to run the steering application and process steering inputs. FRDM-A-S32K344 S32K344MINI-EVB.png Alternative MCU platform used to run the steering application and control connected peripherals. FRDM-K64 Click Shield frdm-k64-click.jpg mikroBUS expansion board used to connect Click modules to the FRDM platform. Servo Click servo-click.jpg PWM driver board used to control the servo motor position. POT Click pot-click.jpg  Potentiometer module used to simulate steering wheel input. Micro Servo SG 180°                     micro-servo-motor-sg-180-degree.jpg Actuator used to convert control signals into steering movement. USB-C / 12 V supply — Provides power and enables programming and debugging of the system. The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate steering wheel input and actuator control. Steering Control Monitoring on FRDM-A-S32K312 Steering Control Monitoring on FRDM-A-S32K344 S32K312_Steering.png  S32K344_Steering.png     Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import PWM-Based Steering Control for FRDM-A-S32K344 PWM-Based Steering Control for FRDM-A-S32K312 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for the steering demo Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB cable (and 12V supply for S32K312) Attach click boards Verify wiring Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously 5 Functional Validation Rotate the potentiometer Observe servo movement Servo follows potentiometer position in real time 7. Signal Behavior and Control Logic Steering_Control_Signal.png Figure: Steering control signal mapping. The 12-bit ADC value (0–4095) is linearly mapped to a servo angle (0°–180°) and a matching PWM duty cycle (1.0–2.0 ms), with reference points at Left, Center and Right. At startup the servo moves to the neutral position; during operation, any input change produces an immediate, proportional reaction — implementing a basic steer-by-wire behavior. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB cable and drivers Verify debugger connection Restart IDE No Servo Movement Verify PWM configuration Check servo wiring Ensure correct power supply Incorrect Behavior Check ADC configuration Validate scaling function Ensure PWM duty cycle mapping is correct Unstable Movement Add signal filtering Check power stability 9. Extending the Application The basic implementation can be extended in several ways: Steering Range Control Restrict or extend the actuator's range of motion Define software-based limits to protect the mechanics Input Direction Inversion Reverse how the actuator responds to the input Useful for left-hand vs. right-hand drive calibration Noise Filtering Apply software filtering to stabilize readings Avoid jitter near the center position Scaling Logic Exploration Identify and analyze how the input is mapped to the output Connect software math with hardware behavior Fault-Handling Behavior Add a mechanism that reacts to a detected fault Transition the system into a safer state State Machine Implementation A more advanced approach is to implement a state machine: Idle Active Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator control In real systems: Redundancy is required Fault detection mechanisms are implemented Systems must comply with ISO 26262 (functional safety standard) Steer-by-wire systems require high reliability since there is no direct mechanical link. 11. Conclusion This module demonstrates how a simple embedded system can implement steering control using ADC input and PWM output. It shows how: Analog input is acquired Data is processed in real time Actuators are controlled using PWM Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 S32K312_Steering_Demo.gif S32K344_Steering_Demo.gif The course provides a strong foundation for more advanced systems, including filtering, state machines, and safety-oriented designs.
記事全体を表示
Automotive Transmission Control Using FRDM-A-S32K344 Microcontrollers 1. Overview The application demonstrates actuator control concepts commonly encountered in automotive transmission systems using the FRDM-A-S32K344 development platform. The application showcases how analog input acquisition, signal processing, and actuator control can be combined to emulate the behavior of an automotive transmission control module. The solution is based on an Application Code Hub example designed for the FRDM-A-S32K344 platform. Transmission Control Module On FRDM-A-S32K344  The demonstration uses a potentiometer as the primary input device, representing the driver's throttle command. The analog signal is sampled using the ADC peripheral and fed into a transmission model that simulates vehicle speed, automatically selects one of six forward gears or neutral, and estimates engine RPM. The current gear is physically indicated by a servo motor, while a DC motor reflects the throttle input through a variable PWM duty cycle, emulating the drivetrain response of a real vehicle.   The example highlights the interaction between analog sensing, ADC conversion, transmission control algorithms, I²C communication, PWM generation, and actuator control commonly found in automotive embedded systems.   More than a technical course, this program embodies the Eat-Sleep-Code-Repeat approach to learning, where students learn by doing. By repeatedly designing, coding, testing, and refining automotive embedded applications on real hardware platforms, participants build both practical skills and the confidence needed to tackle real-world engineering challenges. 2. Learning Scope This article focuses on both practical implementation and core embedded system concepts: Analog signal acquisition using ADC Potentiometer-based continuous control inputs PWM generation using the eMIOS peripheral I²C communication with an external PWM controller Servo motor position control through an external PWM driver DC motor speed control with a dead-band region Automatic gear selection with shift hysteresis Engine RPM estimation and smoothing Real-time embedded control loops running at a fixed update rate Signal mapping and actuator response The example provides a practical introduction to automotive control systems where continuous sensor values drive actuator behavior through a simulated transmission model. 3. System Architecture The system follows a typical embedded control structure organised around a periodic control loop: Input: Analog throttle signal from the potentiometer Processing: S32K3 microcontroller running the transmission model (vehicle speed, gear selection, RPM) Output: Servo motor position (via I²C to an external PWM controller) and DC motor speed (via eMIOS PWM) Functional Flow The potentiometer voltage is sampled by the ADC and converted into a throttle command The MCU updates the transmission model, computing the simulated vehicle speed and selecting the appropriate gear The current gear is sent to the external PWM controller through I²C, which positions the servo motor accordingly The DC motor speed is updated through an eMIOS PWM channel proportional to the throttle command The entire cycle repeats at a fixed update rate to keep the actuators synchronised Transmission_Control_Architecture.png Transmission Control Application Architecture 4. Key Concepts 4.1 Control Principle Unlike systems based on push buttons or digital switches, this implementation uses a continuous analog input signal. The potentiometer provides a variable voltage level that represents the driver's throttle command. This value is continuously monitored and converted into a digital representation using the ADC peripheral. The processed value feeds a transmission model that simulates vehicle speed, selects a gear, and estimates engine RPM, which are then translated into commands for the servo (gear display) and the DC motor (speed). This approach allows smooth transitions instead of abrupt state changes and better reflects real-world automotive control systems. 4.2 Analog Input Acquisition The potentiometer acts as a variable voltage divider. As the potentiometer position changes, the output voltage changes continuously, the ADC acquires the voltage, and the MCU converts it into a throttle percentage. This value becomes the primary input variable for the transmission model. This process mirrors how many automotive sensors operate, where physical movement or operating conditions are converted into an analog voltage signal that must be processed by the control unit. 4.3 Servo Motor Control via I²C and External PWM Controller Unlike the DC motor, the servo motor is not driven directly by an MCU PWM channel. Instead, the MCU sends I²C commands to an external PWM controller located on the Servo Click board, which in turn generates the PWM pulses required to position the servo shaft. The transmission model computes the current gear and provides it as an input; the MCU translates the gear number into a pulse-width value and sends it to the external controller. Each discrete gear position corresponds to a specific servo angle, so the servo acts as a physical gear indicator on a graduated scale. 4.4 PWM-Based DC Motor Control The DC motor is driven directly by the MCU through the eMIOS peripheral, which generates the PWM signal required by the DC Motor 2 Click H-bridge driver. As the potentiometer value increases, the PWM duty cycle also increases, resulting in higher motor speed. When the throttle is at zero, the motor is stopped; above zero, the duty cycle is clamped to a minimum dead-band value (approximately 20 % of the full range) to guarantee reliable motor start-up, and then scales linearly up to full speed. This mirrors the response of a real drivetrain to a throttle input. 4.5 Automatic Gear Selection with Hysteresis The transmission model implements six forward gears plus neutral. Rather than mapping the throttle directly to a gear, the model maintains an internal simulated vehicle speed, which increases when the throttle is applied and decreases when it is released. Gear selection is performed by comparing the vehicle speed against a set of predefined thresholds: An upshift occurs when the simulated speed rises above the upper threshold of the current gear. A downshift occurs when the speed drops below the lower threshold of the current gear. The distance between the up and down thresholds forms a hysteresis band, preventing rapid oscillation between two gears when the speed hovers near a shift point. When the throttle is held at zero for a sustained period, the model detects idle and gradually downshifts back to neutral, mirroring the behaviour of a real automatic gearbox. 4.6 Engine RPM Estimation In parallel with gear selection, the model estimates an engine RPM value based on the throttle input and the currently engaged gear. On each gear change, the RPM is smoothly adjusted — decreasing on upshifts and increasing on downshifts — to reproduce the characteristic behaviour of an automatic transmission. This smoothing avoids abrupt jumps and gives a more realistic feel to the simulation. 4.7 Signal Mapping The application transforms the continuous throttle input into two coordinated actuator commands: a discrete gear position displayed by the servo, and a continuous PWM level applied to the DC motor. The conceptual mapping is shown below. Throttle Input Transmission State Servo Position (Gear Indicator) DC Motor Speed 0 % (idle) Neutral Rest position Stopped Low 1st – 2nd gear Low-gear positions Dead-band minimum → low speed Medium 3rd – 4th gear Mid-range positions Medium speed High 5th – 6th gear High-gear positions Maximum speed This mapping demonstrates how a continuous sensor input can be transformed into both a discrete state (gear) and a continuous actuator command (motor speed). 4.8 Data Flow at a Glance Physical rotation of the potentiometer → analog voltage → ADC sample → throttle percentage → transmission model (vehicle speed, gear, RPM) → I²C command to the external PWM controller (servo position) and eMIOS PWM signal (DC motor speed). All stages are re-evaluated at a fixed update rate to keep the actuators synchronised. This direct chain from the student's hand to the actuators is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 MCU platform used to run the transmission control application, execute the transmission model, and drive the connected peripherals through ADC, eMIOS PWM, and I²C. FRDM K64 click shield                  frdm-k64-click mikroBUS expansion adapter that connects Click modules to the FRDM board. Servo Click                          servo-click Expansion board carrying an external PWM controller. It receives I²C commands from the MCU and generates the PWM pulses that drive the servo motor. Micro Servo Motor SG 180°                         micro-servo-motor-sg-180-degree Actuator used to physically indicate the currently selected gear on a graduated scale. DC Motor 2 Click   dc-motor2-click Compact add-on board with a PWM-controlled, full-bridge brushed DC motor driver. It receives the eMIOS PWM signal directly from the MCU. DC Motor                       DC MotorDC Motor Simulates the vehicle drivetrain speed, reflecting the throttle input applied by the user. USB-C cable — Provides power and enables programming and debugging. The example application demonstrates how these peripherals are connected to the MCU pins and used to simulate a complete transmission control chain, from throttle input to gear indication and drivetrain speed. Transmission Control Full Setup on FRDM-A-S32K344 Transmission Full SetupTransmission Full Setup The hardware configuration allows simultaneous control of a position actuator (servo motor driven through I²C) and a speed-controlled actuator (DC motor driven through eMIOS PWM). Software Environment S32 Design Studio IDE S32K3 Real-Time Drivers (RTD) Application Code Hub project import Transmission Control Module On FRDM-A-S32K344  6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio Select “Import project from Application Code Hub” Search for transmission control example Use the GitHub link for automatic configuration Select main branch Import project Project appears in workspace 2 Build the Application Compile the project Check for errors Confirm SDK component management Successful build with no errors 3 Connect Hardware Connect the board via USB-C Attach FRDM K64 Click Shield, Servo Click and DC Motor 2 Click Wire the servo motor, DC motor and potentiometer Verify wiring before powering the system Board powers up and is detected by IDE 4 Flash and Run Program the MCU Start execution Application runs continuously 5 Functional Validation Rotate the potentiometer Observe the servo pointer moving between the gear positions Observe the DC motor speed changing proportionally to the throttle Release the potentiometer and observe the transmission gradually downshifting back to neutral Gear indicator and motor speed respond consistently to throttle changes 7. Signal Behavior and Control Logic The following diagram illustrates how the transmission model selects the current gear based on the simulated vehicle speed, applying a hysteresis band to prevent frequent shifting around each threshold.   Transmission_Gear_Selection.png The transmission continuously compares the simulated vehicle speed against a set of predefined speed thresholds, one per gear. An upshift occurs when the vehicle speed rises above the upper threshold of the current gear (blue lines), while a downshift occurs only when the speed drops below the lower threshold of that gear (red dashed lines). The distance between the two thresholds forms a hysteresis band that prevents rapid oscillation between adjacent gears when the vehicle speed hovers near a shift point. When the throttle is held at zero for a sustained period, the transmission detects idle and gradually downshifts back to neutral, mirroring the behaviour of a real automatic gearbox. 8. Troubleshooting Issue Possible Actions Board Not Detected Verify USB connection Check drivers Restart IDE DC Motor Not Responding Check eMIOS PWM configuration Verify motor driver wiring and external power supply Confirm code execution Servo Not Moving Check I²C wiring (SDA / SCL) and pull-up resistors Verify that the external PWM controller is powered Confirm the servo is connected to the correct channel and powered by 5 V Incorrect Behavior Validate the ADC input range Inspect GPIO configuration for motor direction pins Verify transmission control logic implementation Unstable / Jittery Output Add software filtering on ADC readings Check power supply stability Verify grounding between motor drivers and MCU 9. Extending the Application The application can be enhanced by adding: Closed-Loop Control Integrate feedback sensors to dynamically adjust actuator outputs Compare commanded vs. actual position/speed for corrective action Additional Transmission Modes Extend the current six-gear + neutral model with Park and Reverse modes for a full PRND emulation Map potentiometer regions or dedicated inputs to specific transmission states Safety Functions Implement input plausibility checks on the throttle signal Add fault monitoring and safe-state transitions in case of sensor or actuator failure CAN Communication Transmit gear, RPM, and speed information over CAN or CAN FD networks Integrate with larger automotive powertrain systems Continuous Versus Discrete Control Compare button-based (discrete) and potentiometer-based (continuous) input styles Emulate electronic throttle control, position sensing, or actuator positioning applications 10. Safety Context Transmission control is part of vehicle motion systems, requiring: Reliable signal processing Deterministic control behavior Safety-aware design In production systems: Redundant checks are implemented Fault detection is mandatory Standards such as ISO 26262 apply Automotive transmission control units also implement input plausibility checks and safe-state fallback strategies to prevent unintended gear engagement or actuator runaway. 11. Conclusion This transmission control demonstration illustrates how the S32K344 platform can combine analog sensing, ADC conversion, I²C communication, PWM generation, and actuator control to implement a complete embedded control application. Using a potentiometer as a continuous input source, the system processes the throttle signal through a transmission model with six forward gears plus neutral, hysteresis-based gear selection, and RPM estimation, and translates the result into real-time commands for both a servo motor (gear indicator) and a DC motor (drivetrain speed). The project provides practical insight into the operation of automotive control systems and serves as a foundation for more advanced transmission, actuator, and motion-control applications. Result on FRDM-A-S32K344 Transmission resultTransmission result The course provides a strong foundation for more advanced systems, including closed-loop feedback control, additional transmission modes, CAN communication, and safety-oriented designs typical of automotive transmission control modules. The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.
記事全体を表示
LPC55S69 SPI - DMA - リンク転送またはピンポン転送でうまくいかない もう長すぎるよ…。 単一のSPI/DMA転送の例を試してみましたが、これらは正常に動作します。 DMA/リンクメモリ転送のサンプルコードを確認しましたが、これらは正常に動作します。 しかし、どれも私の要件を満たしておらず、試してみても合うものが見つかりません。 最初は、リンク構成または単なるピンポン方式で、DMAを使用したフリーランニングSPI TX/RXが必要です。 きっとここには既にこれを実現した人がいて、その知識を共有してくれる人がいるはずですよね? これまでのところ、私ができた最良の方法は、SPI_DMA用のリンクされた設定のセットを作成することです。これは(最後の設定が最初の設定にリンクしているにもかかわらず)一度だけ実行され、その後停止します。 最悪のケースは、連結された16ビット転送に対して、単一の8ビット転送しか行わない場合だ。 アイデアが尽きてきて、おそらく既に失敗したことを試しているだけだと思う。 誰かいますか…? 全般 LPC55xx ペリフェラル Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers これは古い投稿だと分かっていますが、とにかく...問題は、送信転送の幅に関係しています。FIFOを設定するには、32ビット(16ビットのデータ + 16ビットの設定)である必要があります。そうでない場合、SPIのすべての設定ビットがゼロになり、発生している問題が発生します。 --gra Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers こんにちは、 @IanMcCarthy さん。 遅れてしまい申し訳ありません。最近、異常なほど多くの質問を受けています。辛抱強く待ってくださり、本当にありがとうございます。 ご質問に関してですが、一度手動で起動(デバッグセッションで実行)すると、すべてのコードが無限に実行され、SPIからのSCK信号は2パルス以上(停止ボタンを押すまで連続して)生成されなければなりません。LPC55S69で使用しているSDKのサンプルコードはどれでしょうか?コードにどのような変更を加えましたか?そうすることで、あなたのコードを私のボード上で再現し、何が起こっているのかを確認できます。 ご協力いただき、本当にありがとうございました。他に質問があれば、遠慮なくお尋ねください。 よろしくお願いします。 パブロ・アバロス。 Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 更新情報の投稿、3回目の試みです… スレーブSPIデバイスから一定のレートで継続的にデータを受信する必要があります(手動でトリガーする方法では要件を満たせません)。 以下のコードは現在の私の状態を示していますが、これはSPIクロックのプラス信号を2つ生成するだけで、それ以上何も起こりません。 SPIの設定が完了すれば、リンクされたDMA記述子のセットを設定でき、一度手動で起動すれば、その後は無期限に動作する、という理解で合っていますか?それとも間違っているでしょうか? どなたかお手伝いいただける方がいらっしゃいましたら、大変ありがたいです。 srcClock_Hz = EXAMPLE_SPI_MASTER_CLK_FREQ; SPI_MasterGetDefaultConfig(&masterConfig); masterConfig.sselNum = (spi_ssel_t)EXAMPLE_SPI_SSEL; masterConfig.sselPol = (spi_spol_t)EXAMPLE_MASTER_SPI_SPOL; masterConfig.dataWidth = kSPI_Data8Bits; masterConfig.baudRate_Bps = 8000; SPI_MasterInit(EXAMPLE_SPI_MASTER, &masterConfig, srcClock_Hz); DMA_Init(EXAMPLE_DMA); // Enable channels DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel priorities DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL, kDMA_ChannelPriority3); DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL, kDMA_ChannelPriority2); // Create channel handles DMA_CreateHandle(&masterTxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_CreateHandle(&masterRxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel callbacks DMA_SetCallback(&masterTxHandle, TxCallback, NULL); DMA_SetCallback(&masterRxHandle, RxCallback, NULL); DMA_SetupDescriptor( &dmaTxDescriptors[0], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[1]); DMA_SetupDescriptor( &dmaTxDescriptors[1], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[2]); DMA_SetupDescriptor( &dmaTxDescriptors[2], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[0]); DMA_PrepareChannelTransfer(&dmaChannelConfig, &masterTxData, (void *)&SPI7->FIFOWR, DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), kDMA_MemoryToPeripheral, NULL, // &dmaChannelTrigger, &dmaTxDescriptors[0] ); DMA_SubmitChannelTransfer(&masterTxHandle, &dmaChannelConfig); DMA_StartTransfer(&masterTxHandle); Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers あなたの答えを完全には理解できていませんが、もう少し詳しく説明してもらえますか?転送時のuint8_t型の幅を維持しないのはなぜですか? また、関数 DMA_SetupDescriptor() の 3 番目と 4 番目の入力パラメータの位置が間違っていることにも気づきました。 さらに、各ディスクリプタ宛先アドレスはデータを別のメモリ位置にリダイレクトすべきではないでしょうか?すべてが &masterTxData を指すのではなく。
記事全体を表示
有使用MCUXpresso经验的人请问,PRINTF宏的输出会输出到哪里? 我正在尝试调试 FRDM-KL25Z 上的一些代码,但我无法确定使用此宏时会将输出打印到哪个控制台。我不得不使用串口连接进行调试。 Re: Anyone with experience using MCUXpresso, where does the PRINTF macro print to? 你好@kyoto5 感谢你的帖子。 MCUXpresso SDK 中的 PRINTF 不是标准的 C printf() 函数。这是一个 SDK 调试控制台宏,通常映射到 DbgConsole_Printf,其输出目标取决于项目的 SDK 调试控制台配置。 在 MCUXpresso IDE 中,SDK 项目可以配置为以下两种模式之一: - 半托管控制台 输出通过调试器连接发送到 IDE 半主机/控制台窗口,而不是通过 UART。 - UART 控制台 输出通过板载UART发送。在 FRDM-KL25Z 上,这通常作为 OpenSDA 虚拟 COM 端口暴露给主机 PC,因此您需要 Tera Term 或 PuTTY 等终端程序来查看它。 要在 MCUXpresso IDE 中将 UART 输出切换到 PRINTF,请参阅NXP 社区的“MCUXpresso 通常不会在‘hello world’示例中将 PRINTF 输出到控制台”一文。 希望对您有所帮助。 BR 塞莱斯特
記事全体を表示
sCheck 集成功能安全文档 设备:NXP S32K388 微控制器 元器件:SAF 软件包 - SW32K3_SAF_1.0.6_HF01_D2603,sCheck 插件(SRAM ECC 测试) 可用资料: S32K3xx 参考手册(S32K3XXRM_Rev12_2025_11_11.pdf / S32K3XXRM 1_fullReferenceManual.pdf,sCheck UserManual、sCheck SRAM ECC 测试源代码。 差距:缺乏端到端的技术规范、设备寄存器映射、依赖关系交互和预期结果。 版本说明:明确指出以下版本存在一些限制 所需信息: 假定明确的功能安全目标和ECC方案 S32K388 中哪些 SRAM 实例/存储体/分区在范围内,哪些不在范围内 逐步流程包括初始化、故障注入方法、验证和恢复。 所需运行条件(时钟、MPU/XRDC 设置、缓存/TCM 状态、从 RAM/Flash 运行) 跨插件的前置条件/后置条件;元器件间初始化序列示例 SAF/sCheck/eMcem/SafetyBase 基于 S32K388 的版本兼容性矩阵 及格/不及格标准、结果代码及其解读方法 使用的中断、NMI 或错误报告路径;用于应用程序级处理的钩子/回调 Re: Safety documentation for sCheck integration 你好, 对于 sCheck 集成,请主要参考 sCheck 用户手册,特别是“软件集成”章节。本章包含集成要求、假设、内存段定义、链接器文件更新、MPU 配置要求以及任何特定于测试的先决条件。 除了 sCheck 用户手册外,请查阅相应的 S32K3 功能安全手册,其中列出了 sCheck (SM2.*.SCHECK) 涵盖的功能安全机制,并解释了它们在整体功能安全概念中的作用。 SAF 文档代码包,软件包还包含针对其他 SAF 元器件(sBoot、mSel、eMCEM、BIST 等)的模块特定集成指南。因此,集成要求分散在 SAF 模块用户手册中,而不是集中在一个独立组网 \(SA\) 功能安全集成文档中。 我们至少建议您查看以下内容: sCheck 用户手册 → 软件集成 查看用户手册 → 条件、限制和副作用 S32K3 功能安全手册 → SAF/sCheck 涵盖的功能安全机制 SAF 集成文档,涵盖链接器、MPU、启动和 API 集成要求 [[ ## completed ##]] 这些文档提供了将 sCheck 集成到功能安全应用程序所需的信息。 顺祝商祺! Peter
記事全体を表示
Imx6ull KSZ8041NLイーサネットの問題 こんにちは 、 私たちの潜在的なプロジェクトの一つにデュアルイーサネットを利用するために、Imx6ullプロセッサを搭載した2つのイーサネット物理線を接続しました。 一方のPHYはKSZ8081、もう一方のPHYはKSZ8041です。以下は当社のDTS構成です。 &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; ステータス = "正常"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; ステータス = "正常"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0: イーサネット-phy@1 { reg = <1>; micrel、LEDモード = <1>; クロック = <&CLKS IMX6UL_CLK_ENET_REF>; クロックネーム = 「rmii-ref」; }; ETHphy1: イーサネットphy@3 { reg = <3>; micrel、LEDモード = <1>; クロック = <&clks IMX6UL_CLK_ENET2_REF>; クロックネーム = 「rmii-ref」; }; }; }; pinctrl_enet1: enet1grp { fsl、pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2: enet2grp { fsl、pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; イーサネットの物理はカーネルログで検出され、イーサネットケーブルを接続するとリンクも検出されています。 しかしIPはKSZ8081物理に接続されているイーサネットに届き、IPはKSZ8084NLに接続されているイーサネットに割り当てられていません。 そして、イーサネットKSZ8041NL eth0でrxエラーが観察されます。以下のログは以下の通りです: root@sls-IMX6ull14X14evk:~# ifconfig eth0 リンク encap:イーサネット HWaddr BA:9C:69:1F:76:3A UP放送マルチキャスト MTU:1500 メトリック:1 RXパケット:0 エラー:1065 ドロップ:0 オーバーラン:0 フレーム:1065 送信パケット数:65 エラー数:0 ドロップ:0 オーバーラン数:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:12024(11.7 KiB) eth1 リンク encap:イーサネット HWaddr 42:19:11:7F:5E:89 inet addr:10.20.0.184放送日時: 10.20.1.255マスク:255.255.254.0 inet6 アドレス: fe80::8248:9837:9647:2a00/64 スコープ:リンク UP ブロードキャスト実行中 マルチキャスト MTU:1500 メトリック:1 受信パケット数:18 エラー数:0 ドロップ数:0 オーバーラン数:0 フレーム数:0 送信パケット数:23 エラー数:0 ドロップ数:0 オーバーラン数:0 キャリア数:0 衝突回数:0 txqueuelen:1000 RX バイト:2494 (2.4 KiB) TX バイト:3162 (3.0 KiB) lo Link encap:ローカルループバック インターネットアドレス: 127.0.0.1マスク:255.0.0.0 inet6 アドレス: ::1/128 スコープ:ホスト UPループバック実行中 MTU:65536 メトリック:1 受信パケット数:17 エラー数:0 ドロップ数:0 オーバーラン数:0 フレーム数:0 送信パケット数:17 エラー数:0 ドロップ数:0 オーバーラン数:0 キャリア数:0 衝突回数:0 txqueuelen:1000 RX バイト:2011 (1.9 KiB) TX バイト:2011 (1.9 KiB)   root@sls-IMX6ull14x14EVK:~# ethtool eth0 eth0の設定: 対応ポート:[TP MII ] 対応リンクモード:10baseT/Half、10baseT/Full。 100ベースT/ハーフ 100ベースT/フル サポートされる一時停止フレーム使用:対称 自動交渉を支持:はい 対応FECモード:報告されていません 広告リンクモード:10baseT/ハーフ 10baseT/フル 100ベースT/ハーフ 100ベースT/フル 広告される一時停止フレームの使用:対称 広告された自動交渉:はい 広告されたFECモード:報告されていません リンクパートナーが宣伝しているリンクモード:10baseT/Half、10baseT/Fullです 100ベースT/ハーフ 100ベースT/フル リンクパートナーが一時停止を提示したフレーム使用:いいえ リンクパートナーが自動交渉を宣伝していました:はい リンクパートナーがFECモードを広告している:報告されていません 速度:100Mb/s デュプレックス:フル 自動交渉:オン 移植版:ツイステッドペア ファイアド:3 トランシーバ:外部 MDI-X:不明 ウェイクオン支援:g ウェイクオン:d リンク検出:はい   また、50MHzのクロックも確認しましたが、これは適切に生成され、PHY KSZ8041NLにも入力されています。 要するに、1本のイーサネットは正常に動作していますが、2本目のイーサネットは正常に動作KSZ8081 KSZ8041NL。 解決策をご提案ください。参考までに、両方のイーサネット物理ハードウェアのスクリーンショットも添付しています。 image (1).png image (2).jpg i.MX6 全て i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue NXPチームの皆様、こんにちは。 問い合わせ内容について、何か最新情報があれば教えていただけますか? Re: Imx6ull KSZ8041NL ethernet issue こんにちは、NXPサポートチームの皆さん、 私たちはすでに、私たちが直面しているイーサネットの問題について詳細を共有しています。 ですので、あなたの側で確認して、何か解決があれば教えていただけますか? 必要であれば、お電話にて貴社チームと問題について話し合うことも可能です。 貴社チームからの良いフィードバックをお待ちしております。 よろしくお願いいたします。 リテシュ・プラジャパティ Re: Imx6ull KSZ8041NL ethernet issue こんにちは@HarshilSoni434 @ritesh_prajapat お元気でお過ごしのことと思います。 KSZ8041の回路図のストラップオプションを見てみましょう。 Manuel_Salas_0-1785172670273.png 分離モード:プルアップ(デフォルト)=有効 プルダウン= 無効にする PHYは、RMIIデータピン(RXD0、RXD1、CRS/DV、RX_ER、TXD0、TXD1、TX_EN)をMACから切り離します。 MDIO/MDCは完全に機能しており、PHYも検出され、リンクパルスも生成されています。おそらくこれが、PHYが検出され、リンクがアップ状態に見える理由でしょう。 ISOLATEピンのR37をプルアップ抵抗 (~4.7kΩからGND)に変更してみてもらえますか? 次に確認すべき点はリセットピンです。リセットが正しくアサルされているか確認していただけますか? そして、reset_n信号が以下の接続点に合っているかを確認してください: phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; 次に、CONFIG[2:0] RMII のストラップが物理的に正しく接続されていることを確認してください。 また、KSZ8041の回路図の信号マッピング表には、次の情報が記載されています。 Manuel_Salas_1-1785173206995.png ネット名が入れ替わっているように見えます(MDCはenet_mdioとラベル付けされ、その逆も同様です)。 よろしくお願いいたします。 サラス。 Re: Imx6ull KSZ8041NL ethernet issue @Manuel_Salasさん、ご提案いただきありがとうございます。 お客様からいただいたご提案事項はすべて確認し、結果は大体本日中にご報告いたします。 よろしくお願いいたします。 リテシュ・プラジャパティ Re: Imx6ull KSZ8041NL ethernet issue こんにちは@Manuel_Salas ご返信ありがとうございます。 ご提案通り、プルダウン抵抗の変更を行い、イーサネットの通信も確認しましたが、残念ながら挙動は同じです。 IPネゴシエーション中にRXエラーが発生しています。 また、以下の点についても確認いたしました。 - リセットピンは、imx6ullのピン接続に基づいて適切です。リセットラインに手動でパルスを印加したところ、PHY(KSZ8041NL)はリセットされましたが、動作は同じでした。 - MDIOとMDCのピンの入れ替わりは回路図上の問題であり、実際のハードウェアでは接続は正しく行われています。 つまり、変更後も動作は同じで、両方のPhyは検出されますが、IPはKSZ8081と共に出ていて、KSZ8041NLでは検出されません。以下は更新されたログです: root@sls-IMX6ull14x14evk:~# DMESG |グレップFEC [ 2.124528] FEC 20B4000.イーサネット eth0: 登録済みPHCデバイス0 [ 2.207221 FEC 2188000.イーサネット eth1: 登録済みPHCデバイス1 [ 72.966866] fec 20b4000.イーサネット eth0: リンクは稼働中 - 100Mbps/フル - フロー制御はオフ root@sls-IMX6ull14x14evk:~# DMESG |グレップ eth0 [ 2.124528] FEC 20B4000.イーサネット eth0: 登録済みPHCデバイス0 [ 72.966866] fec 20b4000.イーサネット eth0: リンクは稼働中 - 100Mbps/フル - フロー制御はオフ root@sls-IMX6ull14X14evk:~# ifconfig eth0 リンク encap:イーサネット HWaddr 26:F5:A6:8C:73:42 inet6 addr: FE80::F2af:2D7A:228C:2038/64 Scope:Link UP放送 マルチキャスト実行 MTU:1500 メトリック:1 RXパケット:0 エラー:63 ドロップ:0 オーバーラン:0 フレーム:63 送信パケット:12 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:2093(2.0 KiB) eth1 リンク encap:イーサネット HWaddr 22:81:A6:66:8C:3A UP放送マルチキャスト MTU:1500 メトリック:1 RXパケット:0 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 TXパケット:0 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:0(0.0 B) lo Link encap:ローカルループバック inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host ループバックを走らせる MTU:65536 メトリクス:1 RXパケット:91 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 送信パケット数:91 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 collisions:0 txqueuelen:1000 RXバイト:7797(7.6 KiB) TX バイト:7797(7.6 KiB) root@sls-IMX6ull14x14EVK:~# ethtool eth0 eth0の設定: 対応ポート:[TP MII ] 対応リンクモード:10baseT/Half、10baseT/Full。 100ベースT/ハーフ 100ベースT/フル サポートされる一時停止フレーム使用:対称 車載交渉を支持:はい 対応FECモード:報告されていません 広告リンクモード:10baseT/ハーフ 10baseT/フル 100ベースT/ハーフ 100ベースT/フル 広告される一時停止フレームの使用:対称 広告された車載交渉:はい 広告されたFECモード:報告されていません リンクパートナーが宣伝しているリンクモード:10baseT/Half、10baseT/Fullです 100ベースT/ハーフ 100ベースT/フル リンクパートナーが一時停止を提示したフレーム使用:いいえ リンクパートナーが車載交渉を宣伝していました:はい リンクパートナーがFECモードを広告している:報告されていません 速度:100Mb/s デュプレックス:フル 車載交渉:オン 移植版:ツイステッドペア ファイアド:0 トランシーバ:外部 MDI-X:不明 ウェイクオン支援:g ウェイクオン:d リンク検出:はい ぜひご提案をお願いします。 Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん さらにイーサネットFECドライバ fec_main.Cへのデバッグも行いましたRXエラーの根CASEを特定するために。 その結果、ドライバがCRCの不一致エラー BD_ENET_RX_CRのためにすべてのrxパケットを無視していることがわかりました。 SO これを踏まえて、問題解決のためのご提案をお願いします。 Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん、 前回の観察結果に基づくと、何か最新情報はありますか? CRCエラーのため、すべての受信パケットが無視されることを改めてお知らせします。SO、何がその原因になり得るCANでしょうか? Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん、 おはよう、 すでに共有された問題に関する直近のアップデート@HarshilSoni434確認する機会はありましたか?CRCミスマッチの受信パケットの正確な問題を絞り込むために、何か手がかりや追加の発見があれば教えていただけませんか? 弊社側で何か情報が必要な場合はお知らせください。 よろしくお願いいたします。 リテシュ・プラジャパティ
記事全体を表示
LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers This has dragged on for far too long now... I've been through the examples for single SPI/DMA transfers and these work. I've been through the examples for DMA/Linked memory transfers and these work. But none cover my requirement and try s I might I can't get one to fit. I need a free running SPI TX/RX using DMA with either linked configurations or just ping-pong to start. Surely there must be someone on here that's achieved this already, who'd be willing to share some knowledge? The best I've managed so far is a set of linked configurations for SPI_DMA, which execute just once (despite the last linking back to the first) and then stop. The worse is a single 8-bit transfer for linked 16-bit transfers. I'm running out of ideas and pretty sure I'm now trying things that have already failed. Anybody..? General LPC55xx Peripherals Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers I know this is an old post, but anyway... the problem is related with the width of your tx transfer. To configure the fifo must be 32 bits (16 data + 16 cfg) or you have all the configuration bit in the spi that are zeroes, with the problems you are experiencing. --gra Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers Hi @IanMcCarthy  I would like to apologize for the delay. We are experimenting an anormal volume of questions these days. I really thank you for your patience. Regarding your question, once you do a single manual start (run on debug session), all the code has to run indefinitely, and SCK from SPI has to generate more than 2 pulses (continuosly until you press stop). I would like to ask for you which example from our SDK you are using for LPC55S69? What changes did you make to the code? So I can reproduce your code on my board and see what is going on. Thank you so much for your help. Please let me know if you have more questions. Best Regards. Pablo Avalos. Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers Third attempt to post an update... I need to continuously receive data from a slave SPI device at a fixed rate (manually triggering won't meet the requirements). The code below shows where I'm currently at, but this just generates 2 SPI clock pluses and that's it. I'm assuming once SPI is configured I can configure a linked set of DMA descriptors and after a single manual start, this will run indefinately, or am I mistaken? If someone would be willing to help out, it'd be much appreciated. srcClock_Hz = EXAMPLE_SPI_MASTER_CLK_FREQ; SPI_MasterGetDefaultConfig(&masterConfig); masterConfig.sselNum = (spi_ssel_t)EXAMPLE_SPI_SSEL; masterConfig.sselPol = (spi_spol_t)EXAMPLE_MASTER_SPI_SPOL; masterConfig.dataWidth = kSPI_Data8Bits; masterConfig.baudRate_Bps = 8000; SPI_MasterInit(EXAMPLE_SPI_MASTER, &masterConfig, srcClock_Hz); DMA_Init(EXAMPLE_DMA); // Enable channels DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel priorities DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL, kDMA_ChannelPriority3); DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL, kDMA_ChannelPriority2); // Create channel handles DMA_CreateHandle(&masterTxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_CreateHandle(&masterRxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel callbacks DMA_SetCallback(&masterTxHandle, TxCallback, NULL); DMA_SetCallback(&masterRxHandle, RxCallback, NULL); DMA_SetupDescriptor( &dmaTxDescriptors[0], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[1]); DMA_SetupDescriptor( &dmaTxDescriptors[1], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[2]); DMA_SetupDescriptor( &dmaTxDescriptors[2], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[0]); DMA_PrepareChannelTransfer(&dmaChannelConfig, &masterTxData, (void *)&SPI7->FIFOWR, DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), kDMA_MemoryToPeripheral, NULL, // &dmaChannelTrigger, &dmaTxDescriptors[0] ); DMA_SubmitChannelTransfer(&masterTxHandle, &dmaChannelConfig); DMA_StartTransfer(&masterTxHandle); Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers I haven't totally understood your answer, could you please further explain? Why not keeping the uint8_t width of the transfer? I have also noticed that the 3rd and 4th input parameters of the function DMA_SetupDescriptor() are in the incorrect place. Additionally, shouldn't each descriptor destination address re-direct the data to another memory position, instead of all of them pointing to &masterTxData ?
記事全体を表示
MCUXpressoの使用経験のある方、PRINTFマクロはどこに出力されますか? FRDM-KL25Zのコードをデバッグしようとしているのですが、このマクロを使うときにどのコンソールに印刷されているのか分かりません。デバッグのためにシリアル接続を使わざるを得ませんでした。 Re: Anyone with experience using MCUXpresso, where does the PRINTF macro print to? こんにちは@kyoto5 投稿ありがとうございます。 MCUXpresso SDKのPRINTFは標準のCのprintf()ではありません。これはSDKデバッグコンソールのマクロで、通常DbgConsole_Printfにマッピングされ、その出力先はプロジェクトのSDKデバッグコンソールの設定に依存します。 MCUXpresso IDEでは、SDKプロジェクトは以下のいずれかに設定できます: - セミホスティングコンソール 出力はUART経由ではなく、デバッガ接続を通じてIDEのセミホスティング/コンソールウィンドウに送信されます。 - UARTコンソール 出力は基板上のUARTを介して送信されます。FRDM-KL25Zでは、これは通常OpenSDAバーチャルCOMポートとしてホストPCに公開されるため、Tera TermやPuTTYなどのターミナルプログラムで表示する必要があります。 MCUXpresso IDEでUARTをPRINTF出力に切り替えるには、「MCUXpressoはしばしばPRINTFをコンソールに変換しない」例を「hello world」で参照してください - NXPコミュニティ お役に立てば幸いです。 BR セレステ
記事全体を表示
Imx6ull KSZ8041NL 以太网问题 你好呀 , 为了在我们的潜在项目中利用双以太网,我们将两个以太网PHY芯片连接到了Imx6ull处理器上。 其中一块 PHY 芯片是 KSZ8081,另一块 PHY 芯片是 KSZ8041,以下是我们的 DTS 配置: &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; 状态 = "正常"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; 状态 = "正常"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0:以太网物理层@1 { reg = <1>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET_REF>; clock-names = "rmii-ref"; }; ethphy1:以太网物理层@3 { reg = <3>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET2_REF>; clock-names = "rmii-ref"; }; }; }; pinctrl_enet1:enet1grp { fsl,pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2:enet2grp { fsl,pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; 内核日志中检测到了两个以太网物理层,而且当我们连接以太网电缆时,两个设备上也都能检测到链路。 但是,连接到 KSZ8081 phy 的以太网上可以接收到 IP 地址,而连接到 KSZ8084NL 的以太网上却无法分配 IP 地址。 在KSZ8041NL以太网接口(eth0)上观察到接收错误,以下是日志: root@sls-imx6ull14x14evk:~# ifconfig eth0 链路封装:以太网硬件地址 BA:9C:69:1F:76:3A 上行广播组播 MTU:1500 指标:1 接收数据包:0 个错误:1065 个丢弃:0 个溢出:0 个帧:1065 个 发送数据包:65,错误:0,丢弃:0,溢出:0,载波:0 碰撞次数:0 txqueuelen:1000 接收字节数:0 (0.0 B) 发送字节数:12024 (11.7 KiB) eth1 链路封装:以太网 硬件地址 42:19:11:7F:5E:89 inet addr:10.20.0.184广播地址:10.20.1.255掩码:255.255.254.0 inet6 地址:fe80::8248:9837:9647:2a00/64 范围:链路 广播运行中 多播 MTU:1500 指标:1 接收数据包:18 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:23 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 RX 字节:2494 (2.4 KiB) TX 字节:3162 (3.0 KiB) lo Link encap:本地环回 inet addr:127.0.0.1掩码:255.0.0.0 inet6 地址: ::1/128 范围:主机 环路已启动,运行中,MTU:65536,指标:1 接收数据包:17 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:17 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 RX 字节:2011 (1.9 KiB) TX 字节:2011 (1.9 KiB)   root@sls-imx6ull14x14evk:~# ethtool eth0 eth0 的设置: 支持的端口:[ TP MII ] 支持的链路模式:10baseT/半高、10baseT/全高 100baseT/半成品 100baseT/全成品 支持的暂停帧使用方式:对称 支持自动协商:是 支持的FEC模式:未报告 宣传的连接模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 广告中暂停帧的使用:对称 广告中提及的自动协商:是 已公布的FEC模式:未报告 链路伙伴宣传的链路模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 链接伙伴宣传的暂停帧使用情况:否 链接合作伙伴已宣传自动协商:是 链接伙伴宣传的FEC模式:未报告 速度:100Mb/s 复式:全套 自动协商:开启 端口:双绞线 PHYAD:3 收发器:外部 MDI-X:未知 支持唤醒:g 唤醒:d 检测到连接:是   我们还检查了时钟,它是 50MHz 的,生成正常,并且也输入到 KSZ8041NL 物理层。 简而言之,使用 KSZ8081 的 1 个以太网接口工作正常,但使用 KSZ8041NL 的 2 个以太网接口无法工作。 请给我们提供解决方案。我们还附上了以太网PHY硬件的截图供您参考。 image (1).png image (2).jpg i.MX6 全部 i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue 您好,NXP团队, 我们提出的问题有任何更新吗? Re: Imx6ull KSZ8041NL ethernet issue 您好,NXP支持团队, 我们已经分享了我们这边遇到的以太网问题的详细信息。 所以,请您从您那边检查一下,如果有任何进展,请与我们联系。 如有需要,我们也可以通过电话与您的团队讨论问题。 等待贵团队的积极反馈。 此致, 里特什·普拉贾帕蒂 Re: Imx6ull KSZ8041NL ethernet issue 你好@HarshilSoni434 @ritesh_prajapat 希望你一切都好。 查看您的KSZ8041原理图的跳线选项: Manuel_Salas_0-1785172670273.png 隔离模式:上拉(默认)= 启用 下拉= 禁用 PHY 将其 RMII 数据引脚(RXD0、RXD1、CRS/DV、RX_ER、TXD0、TXD1、TX_EN)与 MAC 断开连接。 MDIO/MDC 仍然完全正常,PHY 已被发现,链路脉冲仍在生成,也许这就是 PHY 被检测到且链路处于 UP 状态的原因。 请尝试将 ISOLATE 引脚上的 R37 从上拉电阻改为下拉电阻(~4.7kΩ 至 GND)? 第二件要检查的事情是RESET引脚。请确认复位信号是否已正确置位? 检查 reset_n 信号是否正确连接到: phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; 然后,请检查 RMII 的 CONFIG[2:0] 绑带是否已物理正确钳位。 此外,在KSZ8041原理图的信号映射表中: Manuel_Salas_1-1785173206995.png 网络名称似乎互换了(MDC 标记为 enet_mdio,反之亦然)。 顺祝商祺! 萨拉斯。 Re: Imx6ull KSZ8041NL ethernet issue 你好@Manuel_Salas , 谢谢你的回复。 根据您的建议,我们更换了下拉电阻并检查了以太网通信,但遗憾的是,情况依旧如此。 IP协商过程中出现RX错误。 我们还核实了以下几点: - 根据 imx6ull 引脚连接判断,RESET 引脚连接正确。我们也尝试在RESET线上施加手动脉冲,PHY(KSZ8041NL)被复位,但行为仍然相同。 - MDIO 和 MDC 引脚互换是原理图问题,实际硬件中的连接是正确的。 所以更改后行为仍然相同,两个 Phy 都能被检测到,但 IP 只能通过 KSZ8081 获取,而无法通过 KSZ8041NL 获取。以下是更新后的日志: root@sls-imx6ull14x14evk:~# dmesg | grep fec [ 2.124528] fec 20b4000.ethernet eth0:已注册 PHC 设备 0 [ 2.207221] fec 2188000.ethernet eth1:已注册 PHC 设备 1 [ 72.966866] fec 20b4000.ethernet eth0:链路已连接 - 100Mbps/全双工 - 流控已关闭 root@sls-imx6ull14x14evk:~# dmesg | grep eth0 [ 2.124528] fec 20b4000.ethernet eth0:已注册 PHC 设备 0 [ 72.966866] fec 20b4000.ethernet eth0:链路已连接 - 100Mbps/全双工 - 流控已关闭 root@sls-imx6ull14x14evk:~# ifconfig eth0 链路封装:以太网 硬件地址 26:F5:A6:8C:73:42 inet6 地址:fe80::f2af:2d7a:228c:2038/64 范围:链路 广播运行中 多播 MTU:1500 指标:1 接收数据包:0 个错误:63 个丢弃:0 个溢出:0 个帧:63 个 发送数据包:12 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 (0.0 B) 发送字节数:2093 (2.0 KiB) eth1 链路封装:以太网硬件地址 22:81:A6:66:8C:3A 上行广播组播 MTU:1500 指标:1 接收数据包:0 个错误:0 个丢弃:0 个溢出:0 个帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 (0.0 字节) 发送字节数:0 (0.0 字节) lo Link encap:本地环回 互联网地址:127.0.0.1 掩码:255.0.0.0 inet6 地址: ::1/128 范围:主机 环路已启动,运行中,MTU:65536,指标:1 接收数据包:91 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:91 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 RX 字节:7797 (7.6 KiB) TX 字节:7797 (7.6 KiB) root@sls-imx6ull14x14evk:~# ethtool eth0 eth0 的设置: 支持的端口:[ TP MII ] 支持的链路模式:10baseT/半高、10baseT/全高 100baseT/半成品 100baseT/全成品 支持的暂停帧使用方式:对称 支持自动协商:是 支持的FEC模式:未报告 宣传的连接模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 广告中暂停帧的使用:对称 广告中提及的自动协商:是 已公布的FEC模式:未报告 链路伙伴宣传的链路模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 链接伙伴宣传的暂停帧使用情况:否 链接合作伙伴已宣传自动协商:是 链接伙伴宣传的FEC模式:未报告 速度:100Mb/s 复式:全套 自动协商:开启 端口:双绞线 PHYAD:0 收发器:外部 MDI-X:未知 支持唤醒:g 唤醒:d 检测到连接:是 请您就此提出建议。 Re: Imx6ull KSZ8041NL ethernet issue 感谢@Manuel_Salas提供的建议。 我们会核实您提出的所有建议,并于今天内公布结果。 此致, 里特什·普拉贾帕蒂 Re: Imx6ull KSZ8041NL ethernet issue 你好@Manuel_Salas 我们对以太网 FEC 驱动程序 fec_main.c 进行了进一步的调试。用于识别 rx 错误根案例。 因此,我们发现驱动程序由于 CRC 不匹配错误 BD_ENET_RX_CR 而忽略了所有接收数据包。 基于以上情况,请您提出解决问题的建议。 Re: Imx6ull KSZ8041NL ethernet issue 你好@Manuel_Salas , 根据我们上次的观察,请问有什么最新消息吗? 再次通知您,由于 CRC 错误,所有接收数据包均被忽略。那么,造成这种情况的原因可能是什么呢? Re: Imx6ull KSZ8041NL ethernet issue 你好@Manuel_Salas , 早上好, 您是否已查看@HarshilSoni434之前分享的关于此问题的最新更新?能否请您查看一下,并与我们联系您是否有任何线索或发现,以帮助我们缩小接收数据包CRC不匹配失败的具体问题范围? [[ ## completed ##]] 如果您需要我们提供任何信息,请与我们联系。 此致, 里特什·普拉贾帕蒂
記事全体を表示
Anyone with experience using MCUXpresso, where does the PRINTF macro print to? I'm trying to debug some code on an FRDM-KL25Z, but I can't figure out which console is printed to when this macro is used. I've had to resort to using a serial connection for debugging. Re: Anyone with experience using MCUXpresso, where does the PRINTF macro print to? Hello @kyoto5  Thanks for your post. PRINTF in the MCUXpresso SDK is not the standard C printf() . It is an SDK Debug Console macro, typically mapped to DbgConsole_Printf , and its output destination depends on the project’s SDK Debug Console configuration. In MCUXpresso IDE, the SDK project can be configured for either: - Semihosting console Output is sent through the debugger connection to the IDE semihosting/console window, not through UART. - UART console Output is sent through the board UART. On FRDM-KL25Z, this is typically exposed to the host PC as the OpenSDA Virtual COM port, so you need a terminal program such as Tera Term or PuTTY to view it. To switch UART to PRINTF output in MCUXpresso IDE, please refer to MCUXpresso often won't do PRINTF to Console in 'hello world' example - NXP Community Hope it helps. BR Celeste
記事全体を表示