mex 配置生成的代码与 Windows 和 Linux 不同 同一个XEM文件在不同的系统中会生成不同的代码。 Windows系统生成的文件代码正常，但Linux系统生成的文件代码异常。 前提条件：与 RTD 和 SDK 版本安装相同 Re: mex config generate code different from windows and linux 嗨@Litten 目前，RTD 仅在 Windows 平台上受支持，Linux 平台尚未获得官方支持。即使您能够在 Linux 上安装它们，在开发和集成过程中也可能会遇到其他问题。 主要原因之一是 Linux 是一个区分大小写的操作系统，有关此情况的详细信息已在 S32DS 上针对 S32K344 的 Lpi2c_Ip_MasterConfig 和 Lpi2c_Ip_SlaveState 结构体生成问题线程中进行了讨论。 BR，VaneB

meter I'm trying to find the meter control within the components, but I can't find it.

S32K328 HSE-B: Mem_43_INFLSを使用したA/Bスワップの推奨アーキテクチャ（Vector FOTAなし） NXPチームの皆様、こんにちは。 現在、S32K328上で動作する既存のアプリケーションにOTA A/Bスワップのサポートを追加する設計・実装段階にあります。 これは、完全なFOTAフレームワークを統合するのではなく、既存のソフトウェアをOTA機能で拡張する初期実装です。 現在の環境 MCU:S32K328(8MB Pフラッシュ) AUTOSARスタック:ベクターMICROSAR RTD: S32K3_RTD_6_0_0_QLP04_D2508_ASR_REL_4_7_REV_0000_20250822 バイナリ転送インターフェース:UART 画像アクティベーションサービス: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK HSE A/B スワップは RTD 設定により有効化されます OTAバイナリは、カスタムOTA CDDによってUART経由で受信されます。 現在のVector構成には、NvM/Fee（D-Flash）専用のMemAccMが含まれています。P-FlashアプリケーションをプログラミングするためのMemAccM設定はなく、Vector OTA/FOTAも使用していません。 そのため、OTA CDDのMem_43_INFLSを使って非アクティブなアプリケーションのフラッシュを直接消去・プログラムすることを検討しています。 以下の点についてご指導いただければ幸いです。 1. 推奨されるアプローチ VectorのOTA/FOTAパッケージを使わない場合、A/Bスワップ環境でOTA画像プログラミングを管理するための推奨される低レベルのドライバーはMem_43_INFLSでしょうか? あるいは、MemAccMは、カスタムOTA実装の場合も含め、P-Flashプログラミングに対応するように拡張されるべきでしょうか？ 2. 非アクティブなフラッシュブロックのアドレス指定 HSE A/Bスワップを有効にした後： 非アクティブなアプリケーションP-Flashブロックは常にメモリレイアウトで定義された固定物理アドレスを通じてアクセスされるのでしょうか? あるいは、HSEはパッシブブロックに対して何らかの論理マッピングや抽象化を提供しているのでしょうか？ 3. 有効化の前提条件 HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK を正常に実行するための必須の前提条件は何ですか？ 例： 画像ヘッダー形式 メタデータの要件 整列制約 認証/署名要件 フラッシュ状態または属性 4. フラッシュコントローラの並行処理 S32K328のC40フラッシュコントローラーはDフラッシュ(Fee/NvM)とPフラッシュ(非アクティブブロック)間の同時操作をサポートしていますか? そうでない場合、推奨される同期戦略は何ですか？ アプリケーションレベルのスケジューリング RTDドライバ仲裁 MemAccM の使用状況 5. 推奨される建築様式 以下のアーキテクチャはNXPの推奨事項に準拠していますか？ UART ↓ カスタムOTA CDD ↓ Mem_43_INFLS（非アクティブなPフラッシュの消去/書き込み） ↓ 画像認証 ↓ HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK ↓ システムリセット ↓ HSE/BAF がパッシブブロックをアクティブ化します 私たちは特に、この軽量化アプローチが適切であり、HSE（環境・安全・衛生）要件に準拠しているかどうかについて、ご助言を求めています。 HSE A/Bスワップ対応のカスタムOTAに関するアプリケーションノート、RTD例、または参考実装があれば、ぜひご指導いただけるとありがたいです。 再開まで今しばらくお待ちください。 よろしくお願いします、 ヴェンカテシュ KV #s32k328 Re: S32K328 HSE-B: Recommended Architecture for A/B Swap using Mem_43_INFLS (without Vector FOTA) こんにちは、 @venkatesh-kv 1.カスタムOTA実装では、パッシブパーティションを消去・プログラムするために直接このMem_43_INFLSを使うことができます。 MemAccMを拡張すべきかどうかはアーキテクチャ上の決定であり、主にアプリケーション内で共通のフラッシュアクセスおよび仲裁レイヤーが望まれるかどうかに依存します。 2. パッシブアプリケーション画像は通常、物理的なP-フラッシュアドレス範囲でプログラムされます。HSEは、パッシブブロック専用の論理アドレス指定抽象化を提供していません。アプリケーション/ブートローダーは新しいイメージを非アクティブなパーティションに書き込む責任があり、その後HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCKを使って次のリセット時にそのパーティションをアクティブにすることができます。 3. セキュアブートを使用する場合、シグネチャは(セキュアブートモードやその他の設定に応じて)更新され、次のリセット後に新しいアプリケーションが正常に認証・実行されるようにすべきです。 旧バージョンのHSEファームウェアでは、サービスHSE_SRV_ID_ACTIVATE_PASSIVE_BLOCKを実行するためにスーパーユーザー権が必要でした。これはファームウェアバージョン0.2.55.0以降では通常のユーザー権限にダウングレードされています。 4. 一度に1つのフラッシュ操作のみが実行可能。フラッシュアクセス仲裁の実装はアプリケーションアーキテクチャに委ねられています。 一般的に、複数のソフトウェアコンポーネントからの同時フラッシュ操作を避け、OTAプログラミング活動とシステム内の他のフラッシュユーザー間の競合を防ぐために、フラッシュアクセスが適切に同期されていることを確認することが推奨されます。 Fee/NvMとMem_43_INFLSの間に同期サポートはありません。 5. はい、その流れで合っています。実際には、交換前に有効なアプリケーションがパッシブパーティションに存在し、署名(またはセキュアブート設定全般)が適切に更新される必要があるという唯一の要件です。 S32K344には基本的なOTAデモ「SW32K3_OTADEMO_0.8.0_D2203」があります。これは新しいアプリケーションをパッシブブロックに書き込み、その後AB SWAPを要求する方法を示しています(これはHSEファームウェアの機能です)。このデモではRTD 1.0.0を使用しています。 次のより高度なデモは「S32K396 OTA Demo version 0.4.0」で、イーサネット経由でファームウェアを更新する方法を示しています。こちらはRTD 3.0.0を使用しています。P07。 両方のデモはS32K3リファレンスソフトウェアで見ることができます: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW32K3-REFSW-D リンクをクリックして「Automotive SW - S32K3 - OTA Demo」で検索してください。 これが唯一のバージョンで、あくまで参考ソフトウェアです。必要に応じて他の派生版や新しいRTDパッケージに移行するのはユーザーが自由に行っています。 そして、以下のOTAトレーニングがあります: https://www.nxp.com/design/design-center/training/TIP-CONNECTS2021-AUT428 https://www.nxp.com/design/design-center/training/TIP-NXP-AUT-T3955A 両者はS32K3のトレーニングセクションでご覧いただけます: https://www.nxp.com/products/S32K3 また、「S32K3XX HSE and OTA Advance トレーニング [TR744101]」もご覧いただけます。これはドキュメント -> Secure files: https://www.nxp.com/products/S32K3 よろしくお願いいたします。 ルーカス

Architectural Overview for the Dual-Motor EV Control System 1 Introduction After introducing the Dual-Motor EV Traction platform and the Software & Hardware environment behind it, this article moves one step closer to the running application. It looks inside the Motor Control System and explains how the Simulink model is structured to control two PMSM motors using the NXP S32K396 MCU as the target hardware. The goal is to provide a clear architectural view of the application before diving into simulation, validation, or deployment details. We will follow the main signal paths, from vehicle-level CAN commands and inverter feedback to FOC execution, PWM generation, ADC measurement, and communication back to the vehicle network. The focus remains intentionally architectural. Instead of covering controller tuning, peripheral configuration, or low-level implementation, this article highlights the building blocks that make the dual-motor application understandable as a complete embedded control system. This article is organized around five architectural views: the application overview, the system interfaces, the CAN communication path, the Simulink model structure, and the peripheral-to-data-flow mapping. Together, these views explain how the dual-motor application receives commands, measures feedback, executes control, drives the inverters, and reports diagnostic information back to the vehicle network.   2 Table of Contents • Introduction • Application Overview • System Inputs and Outputs • Vehicle-Level Communication • Simulink Application Architecture • Peripheral Mapping • Data Flow • Conclusion • References   3 Application Overview The Motor Control System is implemented on the NXP S32K396 microcontroller and runs as a single-core embedded application. The ECU controls two PMSMs, each connected to its own three-phase inverter stage. From a control perspective, the application contains two Field-Oriented Control implementations. Each FOC instance is responsible for one motor and executes independently, based on its own sensing path, control states, and output generation. Both control loops are scheduled from independent interrupt sources and are triggered every 100 microseconds. This execution period supports the fast current-control layer required by traction inverter applications, while the single-core implementation requires both motor-control paths to complete within the available timing budget.   Figure 3-1. Overall Simulink Application At vehicle level, the Motor Control System behaves as a actuating end node. It receives enable and speed commands from the Central Node over CAN and sends back monitoring and diagnostic information at a slower periodic rate. The Motor Control System exchanges CAN data with the vehicle network through the South Zone Controller. 3.1. Control Strategy At the heart of the application is the Field-Oriented Control algorithm, which provides the control structure required to drive each PMSM efficiently and independently. In this architecture, FOC transforms the three-phase motor behavior into a control problem handled in a rotating reference frame, where torque-producing and flux-producing current components are regulated separately. The control strategy is built around speed control. The requested speed comes from the vehicle-level command interface, while the estimated rotor speed is provided by the sensorless observer. The speed controller compares these values and generates the current reference needed to reach the commanded operating point. For each motor, the FOC structure combines an outer speed loop with inner current-control loops. The current PI controllers regulate the direct-axis and quadrature-axis currents in the rotating reference frame, allowing the application to control the electrical behavior of the motor in a deterministic and decoupled way. Sensorless operation is achieved using an Extended EMF Observer. This observer estimates the rotor position and speed from the measured electrical quantities, removing the need for a physical position sensor in the control loop. The estimated position is then used by the Park and inverse Park transformations that connect the stationary and rotating reference frames. The feedback path is based on phase-current reconstruction using the dual-shunt measurement method. The reconstructed phase currents are processed through the Clarke and Park transformations, while the DC bus voltage feedback is used to keep the control and modulation stages aware of the available inverter supply. The two FOC implementations follow the same control structure, but each one operates on its own motor-specific inputs, states, and outputs. This separation allows Motor 1 and Motor 2 to be controlled independently, even though both algorithms execute on the same S32K396 device. Because the control loops are executed every 100 microseconds, the FOC layer must remain compact and deterministic. The model architecture therefore separates the fast control path from slower communication and monitoring tasks, ensuring that current regulation and PWM update remain the highest-priority activities in the application.   Figure 3-2. Sensorless Field-Oriented Control diagram 4 System Inputs and Outputs The application interface can be viewed through two categories of signals. The first category contains vehicle-level commands exchanged over CAN. These signals define how the traction application is started, stopped, and commanded from the rest of the vehicle. The second category contains real-time electrical feedback and actuation signals exchanged with the inverter hardware.   Figure 4-1. Split the Simulink model to Inputs, Outputs and Application layers 4.1. Inputs The main vehicle-level inputs are received from the Central Node over CAN through the South Zone Controller. The command message contains the CCS_EnableMotors signal, used to engage or disengage the motors, and the CCS_SetSpeed signal, used to provide the desired speed reference for the control application.   Figure 4-2. CAN Message Unpack block for receiving the command signals   These CAN inputs are not part of the fast current-control loop, but they directly influence its behavior. Once decoded, the enable command defines whether the control logic is allowed to drive the inverters, while the speed reference becomes the target followed by the outer speed controller. The hardware feedback inputs are acquired from the inverter stages through ADC measurements. For each motor, two phase currents are measured using the dual-shunt method, while the third phase current is reconstructed in software using Kirchhoff’s Current Law. The DC bus voltage is measured for each inverter so the control, modulation, and monitoring logic remain aware of the available supply voltage.   Figure 4-3. Gathering analog quantities via ADC Block   4.2. Outputs The primary real-time outputs are the PWM commands used to actuate the inverter phases for both motors. The FOC algorithm computes the voltage commands required by each PMSM, and these commands are translated into duty cycles for the three-phase inverter. Because each inverter leg requires a high-side and a low-side control signal, the application ultimately drives six PWM signals per motor. These signals are generated from the MCU timing path and routed to the gate-driver stage that controls the external power switches.   Figure 4-4. PWM Actuation Subsystem   In addition to the PWM outputs, the application sends CAN data to the South Zone Controller every 0.1 seconds. These messages are intended for diagnostics, monitoring, and vehicle-level observability. The transmitted CAN data includes the estimated speed of each motor, the fault status reported by each control channel, the measured DC bus voltage for each inverter, the current operating state of each motor-control instance and many more. The following table highlights the output data sent over CAN bus:   Name Description Unit MC_BusVoltageM1 DC Bus Voltage measured by inverter for Motor 1 V MC_BusVoltageM2 DC Bus Voltage measured by inverter for Motor 2 V MC_FaultStatusM1 Fault status reported by Motor 1 true/false MC_FaultStatusM2 Fault status reported by Motor 2 true/false MC_PhACurrentM1 Phase A current – Motor 1 A MC_PhACurrentM2 Phase A current – Motor 2 A MC_PhBCurrentM1 Phase B current – Motor 1 A MC_PhBCurrentM2 Phase B current – Motor 2 A MC_PhCCurrentM1 Phase C current – Motor 1 A MC_PhCCurrentM2 Phase C current – Motor 2 A MC_SpeedEstM1 Motor 1 estimated speed rpm MC_SpeedEstM2 Motor 2 estimated speed rpm MC_SpeedRefM1 Motor 1 desired speed rpm MC_SpeedRefM2 Motor 2 desired speed rpm MCS_StateM1 Motor 1 state. It can be Stand By, Running, Fault - MCS_StateM2 Motor 2 state. It can be Stand By, Running, Fault - MCS_PhAVoltageM1 Phase A Voltage – Motor 1 V MCS_PhAVoltageM2 Phase A Voltage – Motor 2 V MCS_PhBVoltageM1 Phase B Voltage – Motor 1 V MCS_PhBVoltageM2 Phase B Voltage – Motor 2 V MCS_PhCVoltageM1 Phase C Voltage – Motor 1 V MCS_PhCVoltageM2 Phase C Voltage – Motor 2 V   Figure 3-5. Example for CAN Pack Message 5 Vehicle-Level Communication The Motor Control System is part of a distributed EV control architecture. It does not operate as an isolated controller. Instead, it receives high-level commands from the vehicle network and reports measured and estimated values back to the rest of the system. The communication path is organized around the CAN interface between the Central Node, the South Zone Controller, and the Motor Control System Node. Commands such as motor enable and desired speed are received through this path, while feedback messages such as estimated speed, DC bus voltage, phase-current information, and fault status are sent back through the same zonal communication route. CAN receive handling is interrupt-driven. When a command frame is received, the application decodes the enable and speed request signals and updates the internal command variables used by the Simulink control model. This keeps the command interface responsive without placing CAN processing inside the 100 microsecond FOC interrupt.   Figure 4-1. CAN Receive Interrupt block   CAN transmit handling is periodic. A PIT interrupt schedules outgoing monitoring messages every 0.1 seconds. This separates network reporting from the real-time control path and ensures that diagnostics transmission does not disturb the deterministic execution of the motor-control interrupts.   Figure 4-2. Periodic Interrupt for transmitting CAN messages   The CAN database defines the mapping between application variables and network messages. For example, the enable and speed command are grouped in dedicated message, while fault information, estimated speed, DC bus voltage, and phase-current feedback are exposed through dedicated monitoring messages. More information about the CAN database created for organizing the CAN messages and signals will be presented in a dedicated article. 6 Simulink Application Architecture The Simulink model is organized around a dual-control structure. Each motor channel contains the algorithmic blocks required to transform measured currents, estimate rotor position and speed, regulate the control loops, and generate voltage commands for PWM modulation. Although both channels implement the same FOC strategy, they are treated as separate execution paths. This separation makes it easier to scale from a single-motor setup to a dual-motor configuration and to validate each channel independently before running both motors together. 6.1. Real-Time Control Layer The real-time control layer is executed inside the BCTU-triggered interrupt flow. The BCTU is synchronized with the PWM timing generated by eMIOS, so the ADC conversions are requested at the correct moment within the switching period. Once the required current measurements are available, the interrupt allows the control algorithm to run using a coherent feedback set.   Figure 5-1. FOC Implementation   Inside this layer, the application reconstructs the three-phase current set, executes the Clarke and Park transformations, estimates rotor position and speed through the Extended EMF Observer, runs the speed and current PI controllers, and generates the voltage commands required by the modulation stage. The voltage commands are then translated into PWM duty cycles. eMIOS provides the base PWM generation, while the LCU forms the complementary high-side and low-side signals needed by the inverter legs. LCU also adds the necessary dead-time in complementary PWM signals to avoid the DC source damage. TRGMUX routes the required trigger signals between these peripherals, maintaining alignment between actuation and measurement.   Figure 5-2. Fast Loop Subsystem   The same execution concept is applied to the second motor channel. The two FOC instances run on the same S32K396 core, so the application depends on the MCU processing capability and on a carefully scheduled interrupt structure to complete both control paths within the available timing budget. 6.2. Communication and Monitoring Layer The communication and monitoring layer connects the fast control application with the vehicle network. It receives the enable and speed commands from CAN, prepares diagnostic information, and schedules outgoing status messages. This layer runs at a lower rate than the FOC loops. It is intended for command exchange, observability, and integration with the Central Node through the South Zone Controller. 6.3. Hardware Abstraction and Peripheral Layer The hardware abstraction and peripheral layer connects the generated Simulink application to the physical resources of the S32K396 MCU. Its purpose is to keep the control algorithm separated from the low-level hardware access, while still allowing the model to read measurements, update PWM outputs, handle interrupts, and exchange data over communication interfaces. In practice, this layer contains the target-specific blocks used for ADC acquisition, PWM generation, and CAN communication. These blocks provide the interface between the algorithmic part of the model and the peripherals configured on the MCU. This layer also makes the model easier to understand and maintain. The FOC subsystems can remain focused on control behavior, while the peripheral layer handles how signals enter and leave the MCU. As a result, the same architectural structure can be reused when moving between simulation, generated code, and target execution. The NXP Model-Based Design Toolbox provides the Simulink blocks that expose these S32K396 peripherals at model level. This allows engineers to configure and connect hardware-facing functions directly in Simulink, while the generated embedded code uses the corresponding target drivers and configuration. 7 Peripheral Mapping The peripheral mapping is centered on the synchronization between measurement, control execution, actuation, gate-driver communication, and vehicle-level CAN communication. Each peripheral has a specific role in this chain, and together they allow the generated Simulink application to interact deterministically with the inverter hardware. SAR-ADC is used to measure the analog quantities required by the control algorithm. These measurements include the phase-current feedback acquired from the inverter stages and the DC bus voltage used by the modulation and monitoring logic. BCTU (Body Cross Triggering Unit) performs the triggering of the ADC conversions. Instead of sampling the analog signals at an arbitrary moment, BCTU waits for the synchronization event coming from the PWM timing path and then starts the SARADC conversions at the correct point in the switching period. eMIOS (Enhanced Multiple Input Output System) generates the three phase PWM signals for each motor channel. These PWM signals represent the base timing generated from the duty cycles computed by the FOC algorithm. LCU (Logic Control Unit) takes the three PWM signals generated by eMIOS and creates the six PWM outputs required by the inverter. For each motor phase, it generates the complementary high-side and low-side control signals with dead-time insertion used to drive the corresponding inverter leg. TRGMUX provides the internal routing between peripherals. It connects the three PWM outputs from eMIOS to the LCU inputs and also routes the synchronization signal between eMIOS and BCTU. This routing keeps the actuation path and the measurement path aligned. LPSPI is used as the communication layer between the S32K396 controller and the MC33937 gate driver. Through this interface, the application can configure and exchange diagnostic information with the gate-driver device, complementing the direct PWM actuation path. FlexCAN provides the CAN communication controller used by the Motor Control System. It enables reception of command messages from the South Zone Controller and transmission of monitoring and diagnostic data back to the vehicle network. In this mapping, the fast motor-control path is formed by eMIOS, TRGMUX, BCTU, SARADC, and LCU, while LPSPI supports gate-driver interaction and FlexCAN supports vehicle-level communication. This separation helps keep the time-critical control loop independent from slower configuration, diagnostics, and network tasks.   Figure 6-1. Peripherals Mapping Overview   PIT (Periodic Interrupt Timer) peripheral is used for slower periodic activity, such as CAN diagnostics transmission every 0.1 seconds. CAN receive interrupts are used for incoming command messages from the South Zone Controller. 8 Data Flow The data flow starts at the vehicle network and at the analog feedback interface. CAN provides the high-level operating commands, while the inverter sensing path provides the real-time electrical feedback required by the FOC loops. When a CAN command is received, the enable and speed references are decoded and stored as application-level command variables. These signals are then consumed by the motor-control logic during the next control execution. In parallel, synchronized ADC conversions provide the latest phase-current and DC bus voltage values. The control algorithm reconstructs the motor currents, estimates rotor position and speed, transforms the feedback into the rotating reference frame, and computes the required voltage commands. The voltage commands are converted into PWM duty cycles and applied to the inverter actuation path. The resulting gate-drive signals control the external power stage, which drives the PMSM phases. At a slower rate, selected internal variables are packed into CAN monitoring frames. These values allow the South Zone Controller and Central Node to observe the Motor Control System state without interfering with the fast control-loop execution. 9 Conclusion This article described the architectural overview of the Dual-Motor EV Control System application. It presented the main Simulink model structure, the system inputs and outputs, the vehicle-level CAN communication path, the peripheral mapping, and the data flow between command reception, sensing, control, actuation, and monitoring. The architecture is built around two independent FOC control paths running on the S32K396 in a single-core configuration. Each motor channel receives synchronized analog feedback, executes its control algorithm every 100 microseconds, and generates the PWM outputs required by its inverter stage. By combining Model-Based design with target-specific peripheral integration, the application provides a scalable foundation for validating dual-motor traction behavior in simulation and on real hardware. The next article can build on this architecture by focusing on Model-in-the-Loop development and controller validation before deployment. 10 References Developing a Dual-Motor EV Control System with Model-Based Design Toolbox Software & Hardware Enablement for the Dual-Motor EV Control System Sensorless FOC with Motor Control Blockset Extended EMF Observer – Motor Control Blockset NXP Model-Based Design Toolbox for S32K3 NXP S32K396 microcontroller documentation AN14481: MCSPTR2AK396 3-phase PMSM Motor Control Kit with S32K396 Application Note

Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. The compilation logs are attached below. Please advise on how to resolve this issue. DEBUG: Executing python function extend_recipe_sysroot NOTE: Direct dependencies are ['/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rpm/rpm_4.19.1.1.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rsync/rsync_3.2.7.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/unifdef/unifdef_2.12.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-extended/xz/xz_5.4.7.bb:do_populate_sysroot'] NOTE: Installed into sysroot: ['cmake-native', 'openssl-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'dwarfsrcfiles-native', 'elfutils-native', 'file-native', 'libedit-native', 'lua-native', 'make-native', 'perl-native', 'python3-native', 'rpm-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libtirpc-native', 'lzlib-native', 'zstd-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libunistring-native', 'nettle-native'] NOTE: Skipping as already exists in sysroot: ['gettext-minimal-native', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'zlib-native', 'bison-native', 'flex-native', 'gnu-config-native', 'patch-native', 'pkgconfig-native', 'pseudo-native', 'rsync-native', 'unifdef-native', 'xz-native', 'acl-native', 'attr-native', 'popt-native', 'sqlite3-native'] DEBUG: sed -e 's:^[^/]*/:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native/:g' /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/openssl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/ncurses-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/elfutils-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/lua-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/perl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/python3-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/rpm-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/curl-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/gmp-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgcrypt-native/fixmepath /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgpg-error-native/fixmepath | xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot:g; s:FIXMESTAGINGDIRHOST:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native:g' -e 's:FIXME_PSEUDO_SYSROOT:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/pseudo-native:g' -e 's:FIXME_HOSTTOOLS_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/hosttools:g' -e 's:FIXME_PKGDATA_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/pkgdata/s32g399avmcu2.1asc:g' -e 's:FIXME_PSEUDO_LOCALSTATEDIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/pseudo/:g' -e 's:FIXME_LOGFIFO:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/temp/fifo.4087696:g' DEBUG: Python function extend_recipe_sysroot finished DEBUG: Executing python function sstate_task_prefunc DEBUG: Python function sstate_task_prefunc finished DEBUG: Executing python function do_package DEBUG: Executing python function package_setup_pkgv DEBUG: Python function package_setup_pkgv finished DEBUG: Executing python function package_convert_pr_autoinc DEBUG: Python function package_convert_pr_autoinc finished DEBUG: Executing python function package_prepare_pkgdata NOTE: Installed into pkgdata-sysroot: [] DEBUG: Python function package_prepare_pkgdata finished DEBUG: Executing python function perform_packagecopy ERROR: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.10/subprocess.py', lineno: 421, function: check_output 0417: else: 0418: empty = b'' 0419: kwargs['input'] = empty 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): File: '/usr/lib/python3.10/subprocess.py', lineno: 526, function: run 0522: # We don't call process.wait() as .__exit__ does that for us. 0523: raise 0524: retcode = process.poll() 0525: if check and retcode: *** 0526: raise CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/image -p -S . | tar -xf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/ocxl.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/pvpanic.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/xilinx_sdfec.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/cxl.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/fastrpc.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/uacce: Cannot mkdir: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. tar: ./usr/include: Cannot mkdir: Bad address tar: ./usr/include/misc/uacce/uacce.h: Cannot open: No such file or directory got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path include couldn't allocate absolute path for 'include'. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Okay, thank you very much. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi, @zhijie  Thanks for your reply. I have reproduced the issue, it does not related with current BSP, but from the building system changes I am looking into it and will reply you later once any progress made? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Thanks， @zhijie  Could you also help to share the result of uname -a? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @zhijie  Thanks for your post. May I know the details of your building environment? It is the first time you built the BSP46? or previously it is correct? BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi  @zhijie  I am also facing the same issue, if you ressolved it kindly let us know. ERROR: zlib-1.3.1-r0 do_package: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/smurugan8/LWT/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.12/subprocess.py', lineno: 466, function: check_output 0462: else: 0463: empty = b'' 0464: kwargs['input'] = empty 0465: *** 0466: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0467: **kwargs).stdout 0468: 0469: 0470:class CompletedProcess(object): File: '/usr/lib/python3.12/subprocess.py', lineno: 571, function: run 0567: # We don't call process.wait() as .__exit__ does that for us. 0568: raise 0569: retcode = process.poll() 0570: if check and retcode: *** 0571: raise CalledProcessError(retcode, process.args, 0572: output=stdout, stderr=stderr) 0573: return CompletedProcess(process.args, retcode, stdout, stderr) 0574: 0575: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/image -p -S . | tar -xf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address tar: ./usr/lib/libz.so.1: Cannot create symlink to ‘libz.so.1.3.1’: No such file or directory Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello chenyin：     Is there any update on this build failure issue?     Wait for good news, much appreciated. BR Zhijie Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello Chenyin     The problem is resolved, Thanks! BR Zhijie Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @zhijie  Thanks for your reply By checking the logs of the building failure, it seems related with the program changes of the building machine. Would you mind trying the following way? On your ubuntu PC, use the command "sudo apt install tar=1.34+dfsg-1build3" to make a change of tar version used, the clean the BSP and rebuild it again   BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. I was having the same issue and I've figured out the issue is with the tar version build 4 and the downgrading did resolve the error, but the actual issue is the tar and pseudo using openat2() instead of openat for the system call. The poky has already given the patch as far as I've seen, does the NXP has any update on it? I'm currently using LLDP 6.1.22 SDK on the LX2160ARDB_REV2 Board and the same error appears when i try to build rcw using bitbake.  If NXP has upated the pseudo_git.bb to use openat2() instead of openat() as per tar's latest build 4., it will be useful for us as we can update tar to the latest version. Attached the logs for your reference. The bug from yocto-project link is added here  https://bugzilla.yoctoproject.org/show_bug.cgi?id=16117 Regards, PVSN Subhash Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @pvsnsubhash  Thanks for your reply, after my workaround fix for the issue, I had also noticed the pseudo issue and then reported it to our internal team. The corresponding team would review the issue and arrange the schedule for the formal fix. Thanks again for your valuable inputs. BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @Sanjiv_Mns  Thanks for your reply. 1. OK, I understand you are currently using i.MX instead of S32G products 2. You may have a try with the following method:  "sudo apt install tar=1.34+dfsg-1build3" and then clean/rebuild with your Yocto setup 3. If still issues, I suggest waiting for the feedback from your original link, I believe my colleague would help you to solve it based on you i.MX setup BR Chenyin Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi @chenyin_h  Have you found anything that could help resolve it? This issue is currently blocking our progress, We would really appreciate any update or guidance you can provide. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. The issue is because of the tar package in linux getting upgraded to build4 from build3. Downgrade the tar package using the below steps and hold the apt upgrade for that package for now and proceed with your compilation. wget http://archive.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1build3_amd64.deb sudo dpkg -i tar_1.34+dfsg-1build3_amd64.deb  sudo apt-mark hold tar After the above steps, you can proceed with your compilation and no such errors will be seen. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hi @chenyin_h   I am still facing the same issue. I have already raised a query on the forum, but I haven't received any response yet.Link I am attaching the log below for your reference. Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. Hello, @Sanjiv_Mns  Thanks for your reply. May I know if you met the same issue? would you mind creating a new post with your details logs, we would directly support it ASAP. BR Chenyin

BSP46とlinux-libc-headers 6.6の組み合わせでコンパイル失敗が発生します。 BSP46とlinux-libc-headers 6.6の組み合わせでコンパイル失敗が発生します。 コンパイルログを以下に添付します。この問題を解決する方法についてご教示ください。 DEBUG:python関数の実行extend_recipe_sysroot 注意:直接依存関係は ['/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot'、 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rpm/rpm_4.19.1.1.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rsync/rsync_3.2.7.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/unifdef/unifdef_2.12.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-extended/xz/xz_5.4.7.bb:do_populate_sysroot'] 注意:sysrootにインストールした際: ['cmake-native', 'openssl-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'dwarfsrcfiles-native', 'elfutils-native', 'file-native', 'libedit-native', 'lua-native', 'make-native', 'perl-native', 'python3-native', 'rpm-native', 'bzip2-native', 'libarchive-native', 'libbnsl2-native', 'libtirpc-native', 'lzlib-native', 'zstd-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libunistring-native', 'nettle-native'] 注意:sysrootで既に存在しているようにスキップしています: ['gettext-minimal-native', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'zlib-native', 'bison-native', 'flex-native', 'gnu-config-native', 'patch-native', 'pkgconfig-native', 'pseudo-native', 'rsync-native', 'unifdef-native', 'xz-native', 'acl-native', 'attr-native', 'popt-native', 'sqlite3-native'] DEBUG: sed -e 's:^[^/]*/:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native/:g'/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/openssl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/ncurses-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/elfutils-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/lua-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/perl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/python3-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/rpm-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/curl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/gmp-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgcrypt-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgpg-error-native/fixmepath|XARGS sed -i -e 's:FIXMESTAGINGDIRTARGET:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot:g;s:FIXMESTAGINGDIRHOST:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native:g'-E 's:FIXME_PSEUDO_SYSROOT:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/pseudo-native:g'-E 's:FIXME_HOSTTOOLS_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/hosttools:g'-E 's:FIXME_PKGDATA_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/pkgdata/s32g399avmcu2.1asc:g'-E 's:FIXME_PSEUDO_LOCALSTATEDIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/pseudo/:g'-E 's:FIXME_LOGFIFO:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/temp/fifo.4087696:g' デバッグ: Python 関数 extend_recipe_sysroot が完了しました デバッグ: Python関数sstate_task_prefuncを実行中 デバッグ: Python関数sstate_task_prefuncが終了しました デバッグ: Python関数 do_package を実行中 デバッグ: Python関数 package_setup_pkgv を実行中 デバッグ: Python関数 package_setup_pkgv が完了しました デバッグ: Python 関数 package_convert_pr_autoinc を実行中 デバッグ: Python 関数 package_convert_pr_autoinc が完了しました デバッグ: Python関数 package_prepare_pkgdata を実行中 注: pkgdata-sysroot にインストールされました: [] デバッグ: Python関数 package_prepare_pkgdata が完了しました デバッグ: Python関数 perform_packagecopy を実行中 エラー: exec_func_python() で Python 関数を実行中にエラーが発生しました (自動生成)。 この例外/失敗を引き起こしたPython呼び出しのスタックトレースは以下の通りです: ファイル: 'exec_func_python() autogenerated', lineno: 2, function: 0001: 0002:perform_packagecopy(d) 0003: ファイル: '/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[指揮] = "${PKGD}" *** 0363: 0364:Python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = " ${D} " ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 421、関数: check_output 0417: それ以外の場合: 0418: 空 = b'' 0419: kwargs['input'] = 空 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): ファイル: '/usr/lib/python3.10/subprocess.py'、行番号: 526、関数: 実行 0522: # process.wait() は呼び出しませんとして。 __exit__それは私たちのためにやってくれる。 0523: 上げる 0524: retcode = process.poll() 0525: チェックして戻りコードを取得する場合: *** 0526: raise CalledProcessError(retcode, process.args, 0527: 出力=標準出力、標準エラー=標準エラー) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: 例外: subprocess.CalledProcessError: コマンド 'tar --exclude=./sysroot-only'-cf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/image-p -S 。|tar -xf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/package'ゼロ以外の終了ステータス2を返しました。 サブプロセスの出力: 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス TAR: ./USR/Include/MISC:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/ocxl.h: 開けられない:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/pvpanic.h: 開けません:そのようなファイルやディレクトリはありません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/xilinx_sdfec.h: 開けません:そのようなファイルやディレクトリはありません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/cxl.h: 開けません:そのようなファイルやディレクトリはありません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/fastrpc.h: 開けられない:そのようなファイルやディレクトリはありません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス TAR: ./USR/include/misc/uacce:Cannot mkdir:そのようなファイルやディレクトリは存在しません 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パスインクルード 'include' の絶対パスを割り当てられませんでした。 tar: ./usr/include:Cannot mkdir: 悪いアドレス tar: ./usr/include/misc/uacce/uacce.h: 開けられない:そのようなファイルやディレクトリは存在しない 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基線経路、経路には以下が含まれます 「インクルーク」の絶対的な経路を割り当てることができませんでした。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. はい、どうもありがとうございました。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @zhijie ご返信ありがとうございます。 問題を再現しましたが、現在のBSPとは関係なく、ビルディングシステムの変更によるものです 現在調査中です。進展があり次第、後ほどご連絡いたします。 BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. ありがとう、 @zhijie uname -aの結果も教えていただけますか? BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @zhijie 投稿ありがとうございます。 ビルディングの環境について詳しく教えていただけますか? BSP46を組み立てるのは今回が初めてですか？それとも以前にも組み立てたことがありますか？ BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは@zhijie 私も同じ問題に直面しています。もし解決できた方がいらっしゃいましたら、ぜひ教えてください。 エラー: zlib-1.3.1-r0do_package: exec_func_python() で Python 関数を実行中にエラーが発生しました (自動生成) この例外/失敗を引き起こしたPython呼び出しのスタックトレースは以下の通りです: ファイル: 'exec_func_python() autogenerated', lineno: 2, function: 0001: 0002:perform_packagecopy(d) 0003: ファイル: '/home/smurugan8/LWT/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[パッケージ] = "${PKGD}" *** 0363: 0364:Python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = " ${D} " ファイル: '/usr/lib/python3.12/subprocess.py'、行番号: 466、関数: check_output 0462: それ以外の場合: 0463: 空 = b'' 0464: kwargs['input'] = 空 0465: *** 0466: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0467: **kwargs).stdout 0468: 0469: 0470:class CompletedProcess(object): ファイル: '/usr/lib/python3.12/subprocess.py'、行番号: 571、関数: run 0567: # process.wait() は呼び出しませんとして。 __exit__それは私たちのためにやってくれる。 0568: 上げる 0569: retcode = process.poll() 0570: チェックして戻りコードを取得する場合: *** 0571: raise CalledProcessError(retcode, process.args, 0572: 出力=標準出力、標準エラー=標準エラー) 0573: return CompletedProcess(process.args, retcode, stdout, stderr) 0574: 0575: 例外: subprocess.CalledProcessError: コマンド 'tar --exclude=./sysroot-only'-cf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/image-p -S 。|tar -xf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/package'ゼロ以外の終了ステータス2を返しました。 サブプロセスの出力: 不明なディレクトリ、fd 4 に対して *at() システムコールが呼び出されました fd 4 の不明なベースパス、パス lib 'lib' の絶対パスを割り当てられませんでした。 tar: ./usr/lib:Cannot mkdir: 悪いアドレス 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 未知ディレクトリの*at() syscallを取得、fd 4 FD 4の未知の基底パス、パスライブラリ 「リベラル」に絶対的な道を割り当てることができませんでした。 tar: ./usr/lib:Cannot mkdir: 悪いアドレス tar: ./usr/lib/libz.so.1:'libz.so.1.3.1'へのシンムリンクを作成できません:そのようなファイル、又はディレクトリはありません Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、陳音 問題は解決しました。ありがとうございました！ BR 志傑 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、chenyinさん： このビルド失敗問題について、何か進展はありますか？ 良い知らせをお待ちしています。大変ありがたいです。 BR 志傑 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @zhijie ご返信ありがとうございます ビルディングの故障ログを確認すると、建築機械のプログラム変更に関連しているようです。 以下の方法を試していただけますか？Ubuntu PCで、コマンド「sudo apt install tar=1.34+dfsg-1build3 」を使用して使用するtarのバージョンを変更し、BSPをクリーンアップして再度再構築してください。   BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 私も同じ問題に直面していましたが、問題はtarのバージョンビルド4にあることが分かり、ダウングレードすることでエラーは解決しました。しかし、実際の問題はtarとpseudoがシステムコールにopenatではなくopenat2()を使用していることです。 私が知る限り、Pokyは既にパッチをリリースしているようですが、NXPは何かアップデート情報を持っていますか？ 現在、LLDP 6.1.22を使用しています。LX2160ARDB_REV2ボード上でSDKを起動しても、bitbakeでRCWを構築しようとすると同じエラーが出ます。 もしNXPがtarの最新ビルド4のようにopenat()ではなくopenat2()を使ったpseudo_git.bbを更新していれば、tarを最新バージョンにアップデートできるので便利になるでしょう。 参考までにログファイルを添付しました。 yocto-projectのバグはここに追加されています https://bugzilla.yoctoproject.org/show_bug.cgi?id=16117 よろしくお願いいたします。 PVSN スバシュ Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @pvsnsubhash ご返信ありがとうございます。問題の回避策を講じた後、私も同様の疑似問題に気づき、社内チームに報告しました。 担当チームが問題を検討し、正式な修正のためのスケジュールを調整します。 貴重なご意見をありがとうございました。 BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは@chenyin_h 私は依然として同じ問題に直面しています。フォーラムに既に質問を投稿しましたが、まだ返信がありません。リンク 参考までに、ログファイルを以下に添付いたします。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @Sanjiv_Mns ご返信ありがとうございます。 あなたも同じ問題に遭遇しましたか？詳細記録を載せた新しい投稿を作成してもよろしいでしょうか?できるだけ早く直接サポートします。 BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは@chenyin_h 解決に役立つ何か見つけましたか? この問題が現在進行を妨げています。何か進捗やアドバイスをいただけると本当にありがたいです。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. こんにちは、 @Sanjiv_Mns ご返信ありがとうございます。 1. わかりました。現在S32G製品ではなく i.MX を使っていると理解しています 2. 以下の方法で試してみることもできます: "sudo apt install tar=1.34+dfsg-1build3"そしてYoctoのセットアップでクリーン・再構築 3. それでも問題が解決しない場合は、元のリンクからのフィードバックをお待ちください。私の同僚があなたのi.MXの設定に基づいて解決のお手伝いをしてくれると思います。 BR チェイン Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 問題は、Linuxのtarパッケージがbuild3からbuild4にアップグレードされたことです。以下の手順でtarパッケージをダウングレードし、そのパッケージのアップグレードを一旦保留してコンパイレーションを進めてください。 wget http://archive.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1build3_amd64.deb sudo dpkg -i tar_1.34+dfsg-1build3_amd64.deb sudo apt-mark hold tar 上記の手順を踏み終えた後、コンパイルを進めば、そのようなエラーは一切見られません。

使用 BSP46 和 linux-libc-headers 6.6 时会出现编译失败。 使用 BSP46 和 linux-libc-headers 6.6 时会出现编译失败。 编译日志附在下方。请告知如何解决此问题。 调试：正在执行 Python 函数 extend_recipe_sysroot 注意：直接依赖项为 ['/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/参考发行版、系统开发套件。/meta/配方-devtools/pseudo/pseudo_git.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rpm/rpm_4.19.1.1.bb:do_populate_sysroot','virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/rsync/rsync_3.2.7.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-devtools/unifdef/unifdef_2.12.bb:do_populate_sysroot', 'virtual:native:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/poky/meta/recipes-extended/xz/xz_5.4.7.bb:do_populate_sysroot'] 注意：已安装到系统根目录：['cmake-native', 'openssl-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'dwarfsrcfiles-native', 'elfutils-native', 'file-native', 'libedit-native', 'lua-native', 'make-native', 'perl-native', 'python3-native', 'rpm-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'libnsl2-native', 'libtirpc-native', 'lzlib-native', 'zstd-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libunistring-native', 'nettle-native'] 注意：由于 sysroot 中已存在以下项，因此跳过：['gettext-minimal-native', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'zlib-native', 'bison-native', 'flex-native', 'gnu-config-native', 'patch-native', 'pkgconfig-native', 'pseudo-native', 'rsync-native', 'unifdef-native', 'xz-native', 'acl-native', 'attr-native', 'popt-native', 'sqlite3-native'] 调试：sed -e 's:^[^/]*/:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/配方-sysroot-native/:g'/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/openssl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/ncurses-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/elfutils-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/lua-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/perl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/python3-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/rpm-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/curl-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/gmp-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgcrypt-native/fixmepath/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/libgpg-error-native/fixmepath| xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/配方-sysroot:g;s:FIXMESTAGINGDIRHOST:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/recipe-sysroot-native:g'-e 's:FIXME_PSEUDO_SYSROOT:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/sysroots-components/x86_64/pseudo-native:g'-e 's:FIXME_HOSTTOOLS_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/hosttools:g'-e 's:FIXME_PKGDATA_DIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/pkgdata/s32g399avmcu2.1asc:g'-e 's:FIXME_PSEUDO_LOCALSTATEDIR:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/pseudo/:g'-e 's:FIXME_LOGFIFO:/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/temp/fifo.4087696:g' 调试：Python 函数 extend_recipe_sysroot 已完成 调试：正在执行 Python 函数 sstate_task_prefunc 调试：Python 函数 sstate_task_prefunc 已完成 调试：正在执行 Python 函数 do_package 调试：正在执行 Python 函数 package_setup_pkgv 调试：Python 函数 package_setup_pkgv 已完成 调试：正在执行 Python 函数 package_convert_pr_autoinc 调试：Python 函数 package_convert_pr_autoinc 已完成 调试：正在执行 Python 函数 package_prepare_pkgdata 注意：已安装到 pkgdata-sysroot：[] 调试：Python 函数 package_prepare_pkgdata 已完成 调试：正在执行 Python 函数 perform_packagecopy 错误：执行 Python 函数时出错，exec_func_python() 自动生成： 导致此异常/失败的 Python 调用堆栈跟踪如下： 文件：'exec_func_python() autogenerated'，行号：2，函数： 0001： *** 0002:perform_代码包，软件包copy(d) 0003： 文件：'/home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/sources/参考发行版、系统开发套件。/meta/classes-global/代码包，软件包.bbclass'，行号：363，函数：perform_代码包，软件包copy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_代码包，软件包copy[cleandirs] = "${PKGD} " 0362:perform_代码包，软件包copy[dirs] = "${PKGD} " *** 0363： 0364:python populate_代码包，软件包s() { 0365: oe.代码包，软件包.populate_代码包，软件包s(d) 0366:} 0367:populate_packages[dirs] = " ${D} " 文件：'/usr/lib/python3.10/subprocess.py'行号：421，函数：check_output 0417：否则： 0418：空 = b'' 0419: kwargs['input'] = 空 0420: *** 0421: 返回 run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423： 0424： 0425:class CompletedProcess(object): 文件：'/usr/lib/python3.10/subprocess.py'lineno: 526, function: run 0522: # 我们不调用 process.wait()作为。 __exit__它能帮我们做到这一点。 0523：提高 0524: retcode = process.poll() 0525：如果检查并返回代码： *** 0526: 引发 CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: 返回 CompletedProcess(process.args, retcode, stdout, stderr) 0529： 0530: 异常：subprocess.CalledProcessError：命令“tar --exclude=./sysroot-only”-cf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/image-p -S 。| tar -xf - -C /home/ubuntu/develop_bsp46/sw-prj-SDV_HPC_Linux_s32g399a/build_s32g399avmcu2.1asc/tmp/work/cortexa53-crypto-fsl-linux/linux-libc-headers/6.6/package'返回非零退出状态 2。 子进程输出： 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/misc：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/misc/ocxl.h：无法打开：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 fd 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/misc/pvpanic.h：无法打开：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/misc/xilinx_sdfec.h：无法打开：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/misc/cxl.h：无法打开：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/misc/fastrpc.h：无法打开：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/misc/uacce：无法创建目录：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 tar：./usr/include：无法创建目录：地址错误 tar：./usr/include/misc/uacce/uacce.h：无法打开：没有该文件或目录 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径包含 无法为“include”分配绝对路径。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 好的，非常感谢。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 嗨， @zhijie 感谢您的回复。 我已经重现了这个问题，它与当前的 BSP 无关，而是由构建系统变更引起的。 我正在调查此事，一旦有任何进展，我会稍后回复您。 BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 谢谢， @zhijie 您能否也帮忙分享一下 uname -a 的运行结果？ BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好， @zhijie 感谢你的帖子。 请问您的建筑环境有哪些具体情况？ 这是你第一次组装BSP46吗？还是之前组装过？ BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 嗨@zhijie 我也遇到了同样的问题，如果您解决了，请与我们联系。 错误：zlib-1.3.1-r0do_package：执行 Python 函数时出错，exec_func_python() 自动生成： 导致此异常/失败的 Python 调用堆栈跟踪如下： 文件：'exec_func_python() autogenerated'，行号：2，函数： 0001： *** 0002:perform_packagecopy(d) 0003： 文件：'/home/smurugan8/LWT/sources/poky/meta/classes-global/package.bbclass'，行号：363，函数：perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD} " 0362:perform_packagecopy[dirs] = "${PKGD} " *** 0363： 0364:python populate_packages() { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = " ${D} " 文件：'/usr/lib/python3.12/subprocess.py'行号：466，函数：check_output 0462：否则： 0463：空 = b'' 0464: kwargs['input'] = 空 0465： *** 0466: 返回 run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0467: **kwargs).stdout 0468： 0469： 0470:class CompletedProcess(object): 文件：'/usr/lib/python3.12/subprocess.py'行号：571，功能：运行 0567: # 我们不调用 process.wait()作为。 __exit__它能帮我们做到这一点。 0568：提高 0569: retcode = process.poll() 0570：如果检查并返回代码： *** 0571: 引发 CalledProcessError(retcode, process.args, 0572: output=stdout, stderr=stderr) 0573: 返回 CompletedProcess(process.args, retcode, stdout, stderr) 0574： 0575： 异常：subprocess.CalledProcessError：命令“tar --exclude=./sysroot-only”-cf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/image-p -S 。| tar -xf - -C /home/smurugan8/LWT/build/tmp/work/armv8a-poky-linux/zlib/1.3.1/package'返回非零退出状态 2。 子进程输出： 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 tar：./usr/lib：无法创建目录：地址错误 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 获取到未知目录的 *at() 系统调用，文件描述符为 4 文件描述符 4 的未知基本路径，路径库 无法为“lib”分配绝对路径。 tar：./usr/lib：无法创建目录：地址错误 tar：./usr/lib/libz.so.1：无法创建指向“libz.so.1.3.1”的符号链接：没有这样的文件或目录 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好，陈音： 关于版本失败的问题，有什么最新进展吗？ 请耐心等待好消息，非常感谢。 BR 志杰 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好， @zhijie 谢谢你的回复 通过查看建筑物故障日志，似乎与建筑物机器的程序更改有关。 您能否尝试一下以下方法？在你的 Ubuntu 电脑上，使用命令“sudo apt install tar=1.34+dfsg-1build3 ”来更改使用的 tar 版本，然后清理 电路板支持包。 并重新构建它。   BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好，陈音 问题已解决，谢谢！ BR 志杰 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 我也遇到了同样的问题，我发现问题出在 tar 版本 build 4 上，降级确实解决了错误，但真正的问题是 tar 和 pseudo 使用了 openat2() 而不是 openat 来进行系统调用。 据我所见，poky 已经发布了补丁，NXP 方面有什么更新吗？ 我目前使用的是 LLDP 6.1.22 版本。我在 LX2160ARDB_REV2 板上使用 SDK，尝试使用 bitbake 构建 rcw 时出现同样的错误。 如果 NXP 已将 pseudo_git.bb 更新为使用 openat2() 而不是 openat()（如 tar 最新构建 4 中所述），这将对我们很有用，因为我们可以将 tar 更新到最新版本。 附件包含日志文件，供您参考。 yocto-project 链接中的错误已添加到此处 https://bugzilla.yoctoproject.org/show_bug.cgi?id=16117 此致， PVSN Subhash Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好， @pvsnsubhash 感谢您的回复。在我找到解决办法后，我也注意到了这个伪问题，并已将其报告给了我们的内部团队。 相关团队将审查该问题，并安排正式修复的时间。 再次感谢您提供的宝贵意见。 BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好， @Sanjiv_Mns 感谢您的回复。 1. 好的，我了解到您目前使用的是 i.MX 而不是 S32G 产品。 2. 您可以尝试以下方法： "sudo apt install tar=1.34+dfsg-1build3"然后使用您的 Yocto 设置进行清理/重建 3. 如果问题仍然存在，我建议您等待原链接的反馈，我相信我的同事会根据您的 i.MX 设置帮助您解决问题。 BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 问题在于 Linux 中的 tar 软件包从 build3 升级到了 build4。按照以下步骤降级 tar 软件包，暂时不要对该软件包执行 apt upgrade 命令，然后继续进行编译。 wget http://archive.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1build3_amd64.deb sudo dpkg -i tar_1.34+dfsg-1build3_amd64.deb sudo apt-mark hold tar 完成以上步骤后，您可以继续进行编译，不会再出现此类错误。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 嗨@chenyin_h 你找到什么可能有助于解决这个问题的方法了吗？ 这个问题目前阻碍了我们的进展，非常感谢您能提供任何最新信息或指导。 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 你好， @Sanjiv_Mns 感谢您的回复。 请问您是否遇到过同样的问题？请您创建一个新帖子，附上您的详细日志，我们将尽快直接提供支持。 BR 陈银 Re: Compilation failure occurs with BSP46 paired with linux-libc-headers 6.6. 嗨@chenyin_h 我仍然面临同样的问题。我已经在论坛上发帖询问了，但还没有收到任何回复。链接 附件中包含以下日志，供您参考。

LPC-Link2のシリアル番号の一貫性について 複数のLPC-Link2チップのシリアル番号が同一である場合、それらのシリアル番号を変更する方法を教えていただきたいです。よろしくお願いいたします。 Re: 关于lpc-link2 SN码一致 こんにちは@chenwe97 このシリアル番号は変更できません。 複数のLPC-LINK2デバイスを同時に接続する場合は、CMSIS-DAPファームウェアにアップデートすることをお勧めします。これにより、各デバッガに固有のID番号が割り当てられます。 BR アリス

关于lpc-link2 SN码一致 想请问下几块lpc-link2  SN码一致的情况下，怎么更改，谢谢。 Re: 关于lpc-link2 SN码一致 Hi @chenwei97  这个SN 码没办法修改。 如果您是为了同时连接多个LPC-LINK2，建议更新成CMSIS-DAP固件。这样每个调试器会有唯一的ID号。 BR Alice

Regarding the consistency of LPC-Link2 serial numbers I would like to ask how to change the serial number of several LPC-Link2 chips if they are identical. Thank you. Re: 关于lpc-link2 SN码一致 Hi @chenwei97 This serial number cannot be modified. If you are connecting multiple LPC-LINK2 devices simultaneously, it is recommended to update to the CMSIS-DAP firmware. This will give each debugger a unique ID number. BR Alice

RT1176 PWM startup failed I am using PWM + fault + QTimer to implement motor pulse control, but the PWM3 submodule 0 PWM_A channel occasionally fails to start, where after the first high level it remains constant and subsequent pulses do not appear.After the inspection, it was found that the "run" bit of the pwm was not correctly set. Even though repeated startup operations were added in the program later, this anomaly still occurred. Re: RT1176 PWM startup failed Hi @liu626, Are you using a custom board or an EVK? If you are using the EVK, did you make any rework to it? Could you share the configuration you are using for PWM3? Are you using an example as a reference? If so, which one? If you try to replicate the issue using a project with only PWM3, does the problem persist? Does this only happen with PWM3 submodule 0 PWM_A channel? Has this occurred on other PWM modules or submodules? Is there any other task or interrupt that manipulates PWM3 registers and could affect or overwrite the run bit? Best Regards, Pablo Re: RT1176 PWM startup failed hi，I used a custom circuit board. I didn't refer to any examples. This was a problem that was discovered during the official development of the project. I configured six PWM channels for pulse control. Only this channel had problems, while no such issue occurred on the other sub-modules. I checked and found that only this channel was using the PWM3 module. No other interfering factors were detected. Below is my configuration. static axis_ctrl_t g_axes[AXIS_NUM] = { { .id = AXIS_X1, .name = "X1", .pwmBase = PWM1, .pwmModule = kPWM_Module_0, .pwmChannel = kPWM_PwmA, .tmrBase = TMR3, .lowCh = kQTMR_Channel_2, .highCh = kQTMR_Channel_3, .tmrInputsrc=kQTMR_ClockCounter2InputPin, .cascadePcs = 6U, .faultNum = 0U, .hwExactSupported = true, .outTrigMask = kPWM_ValueRegisterMask_3, }, { .id = AXIS_X2, .name = "X2", .pwmBase = PWM2, .pwmModule = kPWM_Module_0, .pwmChannel = kPWM_PwmA, .tmrBase = TMR2, .lowCh = kQTMR_Channel_0, .highCh = kQTMR_Channel_1, .tmrInputsrc=kQTMR_ClockCounter0InputPin, .cascadePcs = 4U, .faultNum = 0U, .hwExactSupported = true, .outTrigMask = kPWM_ValueRegisterMask_3, }, { .id = AXIS_Y, .name = "Y", .pwmBase = PWM3, .pwmModule = kPWM_Module_0, .pwmChannel = kPWM_PwmA, .tmrBase = TMR3, .lowCh = kQTMR_Channel_0, .highCh = kQTMR_Channel_1, .tmrInputsrc=kQTMR_ClockCounter0InputPin, .cascadePcs = 4U, .faultNum = 0U, .hwExactSupported = true, .outTrigMask = kPWM_ValueRegisterMask_3, }, { .id = AXIS_Z, .name = "Z", .pwmBase = PWM4, .pwmModule = kPWM_Module_0, .pwmChannel = kPWM_PwmA, .tmrBase = TMR1, .lowCh = kQTMR_Channel_0, .highCh = kQTMR_Channel_1, .tmrInputsrc=kQTMR_ClockCounter0InputPin, .cascadePcs = 4U, .faultNum = 0U, .hwExactSupported = true, .outTrigMask = kPWM_ValueRegisterMask_3, }, { .id = AXIS_EX1, .name = "EX1", .pwmBase = PWM1, .pwmModule = kPWM_Module_1, .pwmChannel = kPWM_PwmA, .tmrBase = TMR1, .lowCh = kQTMR_Channel_2, .highCh = kQTMR_Channel_3, .tmrInputsrc=kQTMR_ClockCounter2InputPin, .cascadePcs = 6U, .faultNum = 1U, .hwExactSupported = true, .outTrigMask = kPWM_ValueRegisterMask_3, }, { .id = AXIS_EX2, .name = "EX2", .pwmBase = PWM2, .pwmModule = kPWM_Module_1, .pwmChannel = kPWM_PwmA, .tmrBase = TMR2, .lowCh = kQTMR_Channel_2, .highCh = kQTMR_Channel_3, .tmrInputsrc=kQTMR_ClockCounter2InputPin, .cascadePcs = 6U, .faultNum = 1U, .hwExactSupported = true, .outTrigMask = kPWM_ValueRegisterMask_3, }, };static void APP_Init_PWM_QTMR(void) { pwm_config_t pwmConfig; pwm_fault_param_t faultConfig; qtmr_config_t qtmrConfig; PWM_GetDefaultConfig(&pwmConfig); pwmConfig.pairOperation = kPWM_Independent; pwmConfig.reloadLogic = kPWM_ReloadImmediate; PWM_FaultDefaultConfig(&faultConfig); faultConfig.faultLevel = true; faultConfig.enableCombinationalPath = false; faultConfig.faultClearingMode = kPWM_ManualSafety; faultConfig.recoverMode = kPWM_NoRecovery; QTMR_GetDefaultConfig(&qtmrConfig); CLOCK_EnableClock(kCLOCK_Qtimer1); CLOCK_EnableClock(kCLOCK_Qtimer2); CLOCK_EnableClock(kCLOCK_Qtimer3); PWM_StopTimer(PWM1, 0x0FU); PWM_StopTimer(PWM2, 0x0FU); PWM_StopTimer(PWM3, 0x0FU); PWM_StopTimer(PWM4, 0x0FU); pwm_fault_input_filter_param_t faultFilter; faultFilter.faultFilterPeriod = 255U; faultFilter.faultFilterCount = 7U; faultFilter.faultGlitchStretch = false; /* 记录每个 PWM 实例上已配置的 fault channel，避免重复设置 */ uint16_t pwm1FaultDone = 0U, pwm2FaultDone = 0U, pwm3FaultDone = 0U, pwm4FaultDone = 0U; for (uint8_t i = 0U; i < AXIS_NUM; i++) { axis_ctrl_t *ax = &g_axes[i]; PWM_Init(ax->pwmBase, ax->pwmModule, &pwmConfig); PWM_SetupFaults(ax->pwmBase, (pwm_fault_input_t)ax->faultNum, &faultConfig); /* 故障滤波（每个 PWM 实例的每个 fault channel 只设一次） */ { uint16_t *faultDone; if (ax->pwmBase == PWM1) faultDone = &pwm1FaultDone; else if (ax->pwmBase == PWM2) faultDone = &pwm2FaultDone; else if (ax->pwmBase == PWM3) faultDone = &pwm3FaultDone; else faultDone = &pwm4FaultDone; uint16_t faultBit = (uint16_t)(1U << ax->faultNum); if ((*faultDone & faultBit) == 0U) { PWM_SetupFaultInputFilterExt(ax->pwmBase, (pwm_fault_channels_t)ax->faultNum, &faultFilter); *faultDone |= faultBit; } } /* Fault 时输出低电平 */ ax->pwmBase->SM[ax->pwmModule].OCTRL &= ~(PWM_OCTRL_PWMAFS_MASK | PWM_OCTRL_PWMBFS_MASK); APP_PWM_Unmap_Selected_Fault(ax); APP_PWM_ClearFault_Safe(ax); ax->pwmBase->SM[ax->pwmModule].INIT = 0U; ax->pwmBase->SM[ax->pwmModule].VAL0 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL1 = 1U; ax->pwmBase->SM[ax->pwmModule].VAL2 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL3 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL4 = 0U; ax->pwmBase->SM[ax->pwmModule].VAL5 = 0U; ax->pwmBase->SM[ax->pwmModule].TCTRL = PWM_TCTRL_OUT_TRIG_EN(ax->outTrigMask); APP_PWM_Disable_Output(ax); if (ax->hwExactSupported) { qtmrConfig.primarySource = ax->tmrInputSrc; QTMR_Init(ax->tmrBase, ax->lowCh, &qtmrConfig); QTMR_Init(ax->tmrBase, ax->highCh, &qtmrConfig); ax->tmrBase->CHANNEL[ax->lowCh].CTRL = TMR_CTRL_CM(kQTMR_PriSrcRiseEdge) | TMR_CTRL_PCS(ax->tmrInputSrc); ax->tmrBase->CHANNEL[ax->highCh].CTRL = TMR_CTRL_CM(kQTMR_CascadeCount) | TMR_CTRL_PCS(ax->cascadePcs); APP_QTMR_Disable_Low_OFLAG_Output(ax); QTMR_DisableInterrupts(ax->tmrBase, ax->lowCh, 0xFFU); QTMR_DisableInterrupts(ax->tmrBase, ax->highCh, 0xFFU); QTMR_ClearStatusFlags(ax->tmrBase, ax->lowCh, 0xFFU); QTMR_ClearStatusFlags(ax->tmrBase, ax->highCh, 0xFFU); } ax->phase = kAxisIdle; ax->armed = false; ax->running = false; ax->done = true; #if HARD_PWM_STATE_GUARD_ENABLE APP_StateGuard_Reset(ax); #endif } /* 使能 QTMR 中断 */ NVIC_SetPriority(TMR1_IRQn, 2U); NVIC_SetPriority(TMR2_IRQn, 2U); NVIC_SetPriority(TMR3_IRQn, 2U); EnableIRQ(TMR1_IRQn); EnableIRQ(TMR2_IRQn); EnableIRQ(TMR3_IRQn); }static bool APP_PWM_Config_Pulse(axis_ctrl_t *axis, uint32_t highCnt400M, uint32_t lowCnt400M) { pwm_clock_prescale_t prescale; uint16_t periodTicks; uint32_t totalCnt400M = highCnt400M + lowCnt400M; if ((axis == NULL) || (totalCnt400M == 0U)) return false; if (!APP_PWM_SelectPrescaler_FromPeriodCnt400M(totalCnt400M, &prescale, &periodTicks)) return false; uint32_t highTicks32 = (uint32_t)(((uint64_t)periodTicks * (uint64_t)highCnt400M + ((uint64_t)totalCnt400M / 2ULL)) / (uint64_t)totalCnt400M); if (highTicks32 == 0U) highTicks32 = 1U; if (highTicks32 >= periodTicks) highTicks32 = (uint32_t)periodTicks - 1U; uint32_t riseTicks32 = 0U; uint32_t fallTicks32 = highTicks32; #if HARD_PWM_LOW_START_PHASE_ENABLE uint32_t lowTicks32 = (uint32_t)periodTicks - highTicks32; if (lowTicks32 >= (2U * HARD_PWM_LOW_START_PHASE_MIN_TICKS)) { uint32_t desiredLeadCnt400M = highCnt400M; uint32_t minLeadCnt400M = (uint32_t)HARD_PWM_LOW_START_PHASE_MIN_US * 400U; if (desiredLeadCnt400M < minLeadCnt400M) desiredLeadCnt400M = minLeadCnt400M; uint32_t desiredLeadTicks32 = (uint32_t)(((uint64_t)periodTicks * (uint64_t)desiredLeadCnt400M + ((uint64_t)totalCnt400M / 2ULL)) / (uint64_t)totalCnt400M); if (desiredLeadTicks32 < HARD_PWM_LOW_START_PHASE_MIN_TICKS) desiredLeadTicks32 = HARD_PWM_LOW_START_PHASE_MIN_TICKS; uint32_t maxRiseByHalfTicks32 = lowTicks32 / 2U; uint32_t postGuardTicks32 = (uint32_t)(((uint64_t)periodTicks * (uint64_t)(HARD_PWM_VAL3_POST_LOW_GUARD_US * 400U) + ((uint64_t)totalCnt400M / 2ULL)) / (uint64_t)totalCnt400M); if (postGuardTicks32 < HARD_PWM_VAL3_POST_LOW_GUARD_MIN_TICKS) postGuardTicks32 = HARD_PWM_VAL3_POST_LOW_GUARD_MIN_TICKS; uint32_t maxRiseByPostGuardTicks32 = (lowTicks32 > postGuardTicks32) ? (lowTicks32 - postGuardTicks32) : 0U; uint32_t selectedRiseTicks32; if (maxRiseByHalfTicks32 >= desiredLeadTicks32) { selectedRiseTicks32 = desiredLeadTicks32; if (selectedRiseTicks32 > maxRiseByHalfTicks32) selectedRiseTicks32 = maxRiseByHalfTicks32; } else if (maxRiseByPostGuardTicks32 >= desiredLeadTicks32) { selectedRiseTicks32 = desiredLeadTicks32; if (selectedRiseTicks32 > maxRiseByPostGuardTicks32) selectedRiseTicks32 = maxRiseByPostGuardTicks32; } else { selectedRiseTicks32 = maxRiseByPostGuardTicks32; } if (selectedRiseTicks32 >= HARD_PWM_LOW_START_PHASE_MIN_TICKS) { riseTicks32 = selectedRiseTicks32; fallTicks32 = riseTicks32 + highTicks32; } } #endif if (fallTicks32 >= (uint32_t)periodTicks) fallTicks32 = (uint32_t)periodTicks - 1U; uint16_t riseTicks = (uint16_t)riseTicks32; uint16_t fallTicks = (uint16_t)fallTicks32; PWM_SetPwmLdok(axis->pwmBase, APP_PwmModuleMask(axis), false); uint16_t ctrl = axis->pwmBase->SM[axis->pwmModule].CTRL; ctrl &= (uint16_t)(~PWM_CTRL_PRSC_MASK); ctrl |= PWM_CTRL_PRSC(prescale); axis->pwmBase->SM[axis->pwmModule].CTRL = ctrl; axis->pwmBase->SM[axis->pwmModule].INIT = 0U; axis->pwmBase->SM[axis->pwmModule].VAL0 = 0U; axis->pwmBase->SM[axis->pwmModule].VAL1 = (uint16_t)(periodTicks - 1U); if (axis->pwmChannel == kPWM_PwmA) { axis->pwmBase->SM[axis->pwmModule].VAL2 = riseTicks; axis->pwmBase->SM[axis->pwmModule].VAL3 = fallTicks; } else if (axis->pwmChannel == kPWM_PwmB) { axis->pwmBase->SM[axis->pwmModule].VAL4 = riseTicks; axis->pwmBase->SM[axis->pwmModule].VAL5 = fallTicks; } axis->pwmBase->SM[axis->pwmModule].TCTRL = PWM_TCTRL_OUT_TRIG_EN(axis->outTrigMask); PWM_SetPwmLdok(axis->pwmBase, APP_PwmModuleMask(axis), true); PWM_SetPwmLdok(axis->pwmBase, APP_PwmModuleMask(axis), true); axis->pwmConfigValid = true; axis->cachedHighCnt400M = highCnt400M; axis->cachedLowCnt400M = lowCnt400M; return true; } Re: RT1176 PWM startup failed Hi @liu626, Could you help me isolate the configuration and test whether the issue persists when only PWM3 is initialized? After reviewing the configuration, you shared and in order to try to replicate the behavior, I have the following questions: What is the definition of axis_ctrl_t? Are HARD_PWM_LOW_START_PHASE_ENABLE and HARD_PWM_STATE_GUARD_ENABLE enabled in your application? What do the following APP functions do? APP_PWM_Unmap_Selected_Fault APP_PWM_ClearFault_Safe APP_PWM_Disable_Output APP_QTMR_Disable_Low_OFLAG_Output APP_StateGuard_Reset APP_PWM_SelectPrescaler_FromPeriodCnt400M APP_PwmModuleMask Best Regards, Pablo Re: RT1176 PWM startup failed Thank you for your reply. The GPIO pin I'm using is GPIO_EMC_B1_29 of the rt1176."axis_ctrl_t" is the definition related to the motor shaft. * PWM output pulse -> Trigger XBAR signal -> Falling edge of pulse drives the external clock input of QTMR -> * QTMR 32-bit cascaded counter decrements by 1 -> When it reaches 0, triggers QTMR comparison interrupt -> Interrupt internally turns off PWM * At the same time, QTMR triggers the hardware Fault, directly pulling down the physical output pin of PWM. .id = AXIS_Y, .name = "Y", /* Used for serial port logging or breakpoint debugging to identify the Y-axis */ /* ================= PWM Output Resource Allocation ================= */ .pwmBase = PWM3, /* The Y-axis uses the FlexPWM3 module */ .pwmModule = kPWM_Module_0, /* Uses the sub-module 0 of PWM3 (each PWM has 4 sub-modules from 0 to 3) */ .pwmChannel = kPWM_PwmA, /* Uses the output pin of phase A of sub-module 0, corresponding to the physical pin GPIO_EMC_B1_29 */ /* ================= 32-bit QTMR cascaded count resource allocation ================= */ .tmrBase = TMR3, /* The Y-axis uses the QTMR3 peripheral (corresponding to IRQ interrupt number TMR3_IRQn) */ .lowCh = kQTMR_Channel_0, /* 16-bit low counter: uses channel 0 of TMR3 */ .highCh = kQTMR_Channel_1,/* 16-bit high counter: uses channel 1 of TMR3 */ /* 👉 .lowCh and .highCh are paired, and in the hardware level, they are automatically combined into a 32-bit counter */ /* ================= Configuration of Hardware Cascaded Clock Sources (Core Critical) ================= */ .tmrInputsrc=kQTMR_ClockCounter0InputPin, /* The clock source for Channel 0: Set to "External Pin Input 0". In the XBAR configuration, the falling edge of the pulse from PWM3 is connected to the input pin of Channel 0 of TMR3 through the XBAR. Therefore, every time a pulse is output by PWM, Channel 0 (16-bit) will perform a decrement operation once. */ .cascadePcs = 4U, /* Configuration of the clock source (PCS) for the high 16-bit channel (Channel 1). In the QTMR register of i.MX RT, the PCS value corresponds as follows: 0-3 = External pin input; 4 = Overflow/Termination event of Channel 0; 5 = Overflow/Termination event of Channel 1; 6 = Overflow/Termination event of Channel 2; 7 = Overflow/Termination event of Channel 3. Here, it is configured as 4U, meaning: Let "Channel 1 of TMR3" monitor the "Overflow event of Channel 0 of TMR3". HARD_PWM_LOW_START_PHASE_ENABLE and HARD_PWM_STATE_GUARD_ENABLE have been enabled. APP_PWM_Unmap_Selected_Fault Function: Remove the Fault pin mapping corresponding to the current axis. Call the underlying PWM_SetupFaultDisableMap function to disable the Fault. The purpose is: When the hardware Fault is not needed, prevent accidental external interference from causing the PWM to be turned off, facilitating the underlying debugging process. APP_PWM_ClearFault (original code function) Function: Clear the Fault status flag (axis->pwmBase->FSTS) of the PWM module. After triggering a hardware Fault, you must first clear this flag before the PWM can be allowed to restart. APP_PWM_Disable_Output Function: Immediately stop the PWM timer, force the pin to output a low level (PWM_SetPwmForceOutputToZero), and enable the output. Its purpose is to ensure that the pin does not output a high level due to being left floating or in the default state before the motor starts, which could cause the motor to move erratically. APP_QTMR_Disable_Low_OFLAG_Output Function: Disable the OFLAG (status flag) output of QTMR and force the OFLAG to be at a low level. In conjunction with the XBAR hardware, its role is to cut off the path from the QTMR output to the PWM Fault pin, preventing accidental triggering of Fault before startup. APP_StateGuard_Reset Function: Clears the counters and flags of the state guard (watchdog). This function is used to reset these protection variables before stopping or restarting the system if it encounters a long period of no pulse change or a deadlock when HARD_PWM_STATE_GUARD_ENABLE is enabled. APP_PWM_SelectPrescaler_FromPeriodCnt400M Function: This is a very core underlying frequency calculation function. It receives the total 400MHz count value of High + Low, and calculates how many prescalers (PRSC) and PWM periods (PERIOD) should be set in order to fit into the 16-bit PWM register. Please note: If the calculated period exceeds 65535 and the division coefficient is out of range, this function will return false, causing the motor to fail to start. APP_PwmModuleMask Function: Convert the index number of the PWM sub-module (for example, kPWM_Module_0 with the value 0) into a bit mask shifted left by N bits. Many of NXP's PWM registers (such as OUTEN, MCTRL) are controlled bit by bit. This function is responsible for generating the correct binary mask. Re: RT1176 PWM startup failed I have found the cause. It is because the internal load of the PIT interrupt in the cm4 core is too heavy, which has affected the PWM operation of the cm7 core. After I reduced the load of the PIT interrupt, the failure of PWM startup disappeared.

S32DS 3.4 ライセンスの問題 NXPチームの皆様へ S32DS 3.4の再アクティベーションを試みましたが、できず、下の画像のようなメッセージが表示されました。現在、古いコンピューターでライセンスを復元することができません。この問題を解決するお手伝いをしていただけないでしょうか？よろしくお願いいたします。 Re: S32DS 3.4 License Problem こんにちは、 利用可能なライセンス数が増加しました。

KW47 extended advertising Hi, The sdk version I'm using is 26.06 . The routine is kw47loc_loc_reader_freertos . #define gAppIsPeripheral_d                   1U   It was found that the return value of calling BluetoothLEHost_StartExtAdvertising is 4(gBleFeatureNotSupported_c)  I'd like to use extended advertising. Please give me your support.   Thanks!   Re: KW47 extended advertising Hello, Hope you are doing well. What modifications have you made in the example? In order to configure Extended Advertising in an application, the first steps are to set the extended advertising parameters with Gap_SetExtAdvertisingParameters and setting the advertising data by calling Gap_SetExtAdvertisingData. For the full setup sequence and parameter details, please check this guide: Extended advertising — MCUXpresso SDK Documentation   Hope this helps! Best regards, Ana Sofia. Re: KW47 extended advertising Hi, The sdk version I'm using is 26.06. The imported routine is kw47loc_loc_reader_freertos.  Modify the macro definition of gAppIsPeripheral_d in the routine to 1, and at the same time add BleApp_Start() in the BluetoothLEHost_AppInit function;  Nothing else has been modified. It was found that the return value of calling BluetoothLEHost_StartExtAdvertising is 4(gBleFeatureNotSupported_c)    Thanks! Re: KW47 extended advertising Hi @wjw2026 , Could you please confirm if you were able to follow the steps from the Extended Advertising Guide ? There are several required steps involved in the Peripheral configuration for extended advertising, verifying those settings may be helpful in troubleshooting the behavior you're observing. Best regards, Ana Sofia.

i.MX95におけるUSXGMIIマルチレート こんにちは、 i.MX95に以下のイーサネット速度をサポートできるイーサネットポートを実装できるかどうかを評価しようとしています。 10GBASE-T 5GBASE-T 2.5GBASE-T 1000BASE-T 100BASE-TX 10BASE-Te 一般的に、デザイン上に10Gbit対応のイーサネットPHYを設置し、USXGMIIまたはXFIのいずれかのインターフェースを通じてi.MX95イーサネットコントローラに接続する必要があります 私たちの理解では、USXGMIIインターフェースは理論上マルチレートインターフェースであり、1リンクで10Gbitから10bitまでのあらゆる速度を実現できます。 これに対し、XFIインターフェースは単一レートのインターフェースで、10Gbitしか対応できません。 i.MX95のリファレンスマニュアル(例:)セクション104.2、表621)i.MX95はXFIおよび「10G-USXGMII」の両方をサポートしています。最初は、私たちが望むUSXGMIIインターフェースがサポートされているように見えます。 しかし、いくつか私たちを困惑させる点があります。 1.「10G-USXGMII」という宣言は、理論上はインターフェースがUSXGMIIリンクであることを意味するかもしれませんが、実際には10Gbitモードでしか動作しません。 2. NXP評価ボードIMX95LPD5EVK-19は、Marvell AQR113C PHYを使用して10GBase-Tポートを実装しています。 a) 図1のブロック図、セクション1.1では、PHYがUSXGMIIインターフェースに接続されているように見えます: b) 関連するセクション2.11.3「10 Gbitイーサネットインターフェース」では、AQR113Cイーサネットトランシーバーが10Gbitから10bitまでのすべてのデータレートをサポートするとされており、真のUSXGMIIを示唆しています: c) この節では、イーサネットPHYを接続するインターフェースがXFIであることも記載されています。 結論として、i.MX95がフルのマルチレートUSXGMIIに対応しているのか、それとも10Gbit専用バージョンのみ対応しているのか混乱しています。 NXPの評価ボードを参考にしてみましたが、そのボードの10GbEポートがUSXGMII(10Gbitから10bitまでのマルチレート対応)で接続されているのか、XFI(10Gbitのみ)で接続されているのかも分かりません。 教えていただけますか: i.MX95に10Gbitから10Gbitまでの速度をサポートする真のマルチレート10GbEポートを実装することは可能でしょうか? Re: USXGMII multi-rate on i.MX95 詳細なご回答をいただき、誠にありがとうございます。 これで私たちの側の混乱は解消されました！ Re: USXGMII multi-rate on i.MX95 1. 「10G-USXGMII」の意味 「10G-USXGMII」とは、10G専用モードではなく、標準的なマルチレートUSXGMIIプロトコルを指します。「10G」は固定されたSerDesレーン速度を示し、USXGMIIは10M、100M、1G、2.5G、5G、10Gイーサネットの帯内レート適応をサポートしています。 i.MX95では、このモードはPCS_PROT_10G_SXGMII設定で表されます。 2. i.MX95 EVKで使用されたインターフェース i.MX95 EVKは、USXGMIIではなくXFI（10GBASE-R）を使用します。imx95-19x19-evk.dtsでは、enetc_port2 は次のように設定されています。 phy-mode = "10gbase-r"; したがって、搭載されているAQR113CはXFIモードで動作します。 3. 真のマルチレートUSXGMIIはサポートされていますか？ はい。i.MX95 NETCハードウェアはUSXGMIIをサポートし、LinuxのENETC4ドライバはenetc4_set_port_speed()を通じて速度変更を処理します。Marvell AQR113CはUSXGMIIホストインターフェースモードもサポートしています。 4. カスタムボードに必要なものは何ですか？ マルチレート動作を完全に有効にするには： デバイスツリーの設定： phy-mode = "usxgmii"; managed = "in-band-status"; AQR113Cのファームウェアを、XFIではなくUSXGMIIホストモードに設定してください。 EVKは10GbEポートにXFIを使用していますが、カスタムi.MX95設計ではUSXGMIIをAQR113C(または類似のPHY)と組み合わせて、10M/100M/1G/2.5G/5G/10Gを単一のMACからPHYリンクまでサポートできます。 よろしくお願いします。 Re: USXGMII multi-rate on i.MX95 もう一つ追加で質問します:Marv AQR113C ellのドライバはNXP Linux BSPに含まれているのか、それとも自分たちで用意しなければならない外部モジュールですか? Re: USXGMII multi-rate on i.MX95 私は元の投稿者ではありませんが、私もusxgmiiを動作させようとしています。 NXPは、usxgmiiがBSPカーネル上で動作するかどうかを検証したことがありますか？mv-cux3610 PHYで使用しようとしていますが、以下のエラーが発生します。 [ 43.063202] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): MAC returned PCS which does not support usxgmii [ 43.074224] nxp_enetc4 0002:00:10.0 (unnamed net_device) (uninitialized): failed to validate link configuration for inband [ 43.085308] nxp_enetc4 0002:00:10.0: Failed to create phylink [ 43.091726] nxp_enetc4 0002:00:10.0: probe with driver nxp_enetc4 failed with error -22 これは、NetC PCSがUSXGMIIサポートを宣伝しておらず、10Gbase-R、2500-basex、SGMIIのみが原因のようです: (これはLF-6.18.YのLinux-IMXブランチでの話です) Re: USXGMII multi-rate on i.MX95 このドライバーはNXP Linux BSPに含まれています。リンク: https://github.com/nxp-real-time-edge-sw/real-time-edge-linux/blob/linux_6.18.20/drivers/net/phy/aquantia/aquantia_main.c Re: USXGMII multi-rate on i.MX95 お返事ありがとうございます！ 最後に質問です。i.MX95 EVKのenetc_port2とAQR113CをUSXGMIIモードに設定することは可能でしょうか？これにより、EVK上でUSXGMIIインターフェースのマルチレート機能をテストできるのでしょうか? Re: USXGMII multi-rate on i.MX95 EVKで単純に「DTSをusxgmiiに切り替える」のはソフトウェアレベルの試みに過ぎません。 また、USXGMIIファームウェアでAQR113Cを再プロバイニングする必要があり、EVKのXFI向けボード設計のため、マルチレート検証には信頼性が高くありません。 もし目標が真のマルチレートUSXGMII(10M/100M/1G/2.5G/5G/10G)を検証することであれば、USXGMII向けにカスタムボードを作ることを推奨します(USXGMIIホストモードファームウェアではSerDes routing + AQR113C + phy-mode = "usxgmii")。 AQR113C用のUSXGMIIプロビジョニングファームウェアを取得した後、EVKボードを使うことができますが、その制限にはご注意ください。 よろしくお願いします。

eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero I'm using the eFlexPWM module (instance IP_EFLEXPWM_0) on an S32K364 microcontroller to measure the frequency and period of an external signal via input capture. I am using submodule 2 (SM[2]). My configuration is as follows: SM2_CAPTCTRLB->EDGB0 = 0x02; (capture on rising edge for capture circuit 0) SM2_CAPTCTRLB->EDGB1 = 0x02; (capture on rising edge for capture circuit 1) SM2_ARMB = 1; (arm the capture circuits) After running the code, I observe the following: In SM2_CAPTCTRLB, the counter status bits show: CB0CNT = 0x4 CB1CNT = 0x4 In SM2_STS, both flag bits are set: CFB0 = 1 CFB1 = 1 However, the captured values (SM2_CAPTCOMPB) remain 0 for both capture circuits – no data is latched. What could be causing this? Is there any additional configuration needed (e.g., clock enable, input muxing, or counter setup) that I might have missed? The flags indicate that capture events are detected, but the captured values are not updated. Any insight would be greatly appreciated. Feel free to add any additional details (like your pin muxing settings or counter mode) if needed. Good luck! Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero Hi First, I checked the latest S32K3 RTD 7.0.x; however, the S32 Configuration Tool does not yet support the eFlexPWM E-Capture functionality. If it is convenient, could you share your project so I can test it on the S32K396? (Unfortunately, I don’t have the S32K364; I only have the S32K396-BGA-DC1 evaluation board.) Secondly, please review section “56.3.14 Enhanced capture (E-Capture)” in S32K396RM (Rev. 4, 11/2024). Please check the registers mentioned in that section, especially those in Figure 254. E-Capture logic. You can also share screenshots of the eFlexPWM_0 registers with me.  Besides the bits you mentioned in SM2_CAPTCTRLB [EDGB0],[EDGB1],[ARMB], how did you configure the other bits in SM2_CAPTCTRLB?   Since you observed that SM2_CAPTCTRLB[CB0CNT] = 0x4 and [CB1CNT] = 0x4, have you checked the corresponding register values of SM2_CVAL4, SM2_CVAL4CYC, SM2_CVAL5, and SM2_CVAL5CYC?   In addition, if you want to read the value of SM2_CAPTCOMPB[EDGCNTB], please first enable SM2_CAPTCTRLB[EDGCNTB_EN] and SM2_CAPTCOMPB[EDGCMPB]. I’m not sure why you set SM2_CAPTCOMPB[EDGCMPB] to 0, as this seems to prevent the comparator in Figure 254. E-Capture logic from functioning correctly. Best Regards, Robin Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero It appears that the period of submodule2 is too short. Please read "56.3.18.3 Running a submodule at a lower frequency than submodule 0" and try selecting a lower frequency clock source for submodule2, such as AUX_CLK or EXT_CLK. Re: eFlexPWM input capture not capturing on S32K364 – flags set but CAPTCOMPB remains zero Hi@Robin_Shen , I have successfully implemented external frequency measurement by properly configuring the MCTRL and CAPTCTRLB registers. However, testing shows the minimum measurable frequency I can achieve is 5 kHz, while my requirement is to support frequencies as low as 1 Hz. I have attempted adjusting the Prescaler and PrescalerAlt configurations, yet no improvement was observed. Could you please share some suggestions and troubleshooting approaches? Thank you very much for your support.

RF Power Amplifier Design - MRF13750H Hello! I am designing an 805 MHz RF power amplifier using the MRF13750H, and my design is based on the 915 MHz reference circuit found in the datasheet. However, I only have access to Usimmics for simulating the matching networks; I do not have access to the software NXP uses to open their design files. Therefore, to design the matching networks, I am requesting the complete schematic for the MRF13750H 915 MHz reference circuit from NXP, including the microstrip line dimensions, as this information is not provided in the datasheet. If possible, I would also like to request the large-signal model impedances at 805 MHz; otherwise, I will base my design on the values ​​provided for 915 MHz. The reference circuit at 915Mhz and the datasheet is attached below. On the other hand, if anyone knows a different method for designing the matching networks at 805 MHz, I would appreciate the input.

我们能否在 i.mx9 中使用已配置的证书或密钥来设置 HTTPS 连接或 TLS 连接？ i.MX93 上配置的证书和私钥可以直接用于建立 HTTPS/TLS 连接吗？如果可以，那么访问和使用这些凭据进行客户端/服务器身份验证和 mTLS 实现的推荐方法是什么？ 配置完成后，安全对象 blob 会出现在 /etc/ele/ 中，那么在实际的 HTTPS/TLS 连接中使用这些已配置的凭据的推荐工作流程是什么？ Re: can we use provisioned cert or key for setting up in the https connection or tls connection in i 嗨， @Manuel_Salas 谢谢你的回复。 关于 mbedTLS/opaque-key 指南——我们这边已经解决了私钥的问题。 剩下的问题具体是关于证书，该证书通过 EL2GO 配置，并与私钥一起存储在 /etc/ele/ 中。由于证书是公共数据，我们需要将其提取为纯 DER 格式，以便交给 mbedtls_x509_crt_parse_der() 进行 TLS 握手——与密钥不同，它不需要保持不透明。 支持的 SMW/PSA 调用是什么，才能检索已配置证书对象的明文 DER 字节？ 具体来说：它是通过 psa_ps_get() / psa_its_get()（PSA 保护存储/内部可信存储）使用对象 ID 作为 UID 公开，还是通过不同的 SMW API 公开？我们在已安装的 SMW 头文件中看到了 protected_storage.h 和 internal_trusted_storage.h，但在基于它进行构建之前，我们想确认这是否是证书对象的预期路径。 Re: can we use provisioned cert or key for setting up in the https connection or tls connection in i 你好@NEXUSNERD 希望你一切都好。 在 i.MX93 上，配置流程的设计使得私钥始终受到ELE的保护。 因此，存储在 /etc/ele/ 中的 blob 是安全的对象表示，允许 ELE 重新加载或引用已配置的密钥材料，它们不应被视为普通的 TLS 密钥文件。 您可以查看imx-secure-enclave (Mbed-TLS)。 顺祝商祺！ 萨拉斯。

LED 的 IO 扩展 我目前正在设计用于定制测量设备的开关矩阵板。 为了路由信号，我计划使用光中继器，准确地说是 G3VM-61DR1。 所以我需要控制超过 250 个！以某种方式使用 LED（1.5-1.8V 6-8mA）。 同时开启的设备数量将少于25台。 供电电压为3.3V或更低，温度应在40°C左右。 我们只需要打开或关闭它们，不需要调光或PWM调光。 我不想使用LED驱动器，因为它可能会引入噪声。 我无法使用传统的矩阵式电路，因为无法预知哪些开关会同时处于开启状态。 因此，唯一的选择是为每个继电器/LED 提供一个独立的输出，您的 IO 扩展器看起来很有希望实现这一点，例如PCAL6524 。 由于通道数量较多，我希望尽可能减少每个通道的元器件数量，因此我有几个问题： 我能否依赖 Agile IO 设备的 7.5mA 电流设置，而省略 LED 串联电阻？ 如果可以的话，可能会有哪些副作用？ 由于这些设备最初配置为输入，因此当它们用于控制 LED 时，某些设备会经历高电流（例如，PCA9535A数据手册第 14/15 页）。对于这么多通道来说，为每个通道使用上拉电阻的传统解决方法并不理想。这是否也会影响 Agile IO 设备？ 能否通过给 LED 提供 3.3V 电压，给扩展器提供 1.65V 电压来解决这个问题？ 先感谢您 奥托 Re: IO Expansion for LEDs PCAL6524 非常适合驱动大量的光继电器和 LED。然而，敏捷 I/O 驱动能力并不是为了取代所需的串联限流电阻器。为了降低上电时 I/O 仍处于输入状态时出现意外电流的风险，可以考虑使用 VDD(P) 较低的 3.3 V LED 电源，或者实现全局 LED 电源开关等方案。然而，每个 LED 通道都应该始终保留单独的限流电阻。

FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages On i.MXRT1176 we are using FLEXCAN with EDMA. (SDK 26.03) We have a callback defined for DMA transfer complete. This is our flow: 1. Call `FLEXCAN_TransferReceiveFifoEDMA()` to start the transfer. 2. On DMA transfer completion, user-defined callback is called. 3. Data is copied from DMA buffers, and `FLEXCAN_TransferReceiveFifoEDMA()` is called to continue receiving messages. 4. Repeat Steps 2-4 We noticed that when we transmit messages from another node in a burst with just the bare minimum Inter-Frame Space, we see an increase in number of ACK errors - the iMX is unable to ACK the messages.  Going through the flow, it appears that every time there is a DMA transfer complete callback, DMA is disabled on FLEXCAN. It is re-enabled again when `FLEXCAN_TransferReceiveFifoEDMA()` is called.  This is done by calling `FLEXCAN_EnableRxFifoDMA()`. The enabling/disabling DMA updates the DMA bit in FLEXCAN's MCR register, and it can only be done in Freeze mode. As we are receiving messages in a burst, it is possible that a transmission is actively in progress when FLEXCAN is put it freeze mode. And it is unable to ACK the incoming message.   We confirmed that removing that call to `FLEXCAN_EnableRxFifoDMA()` removes all ACK errors, though now we are dropping some messages. Also, we tried spacing out the messages, and that also got rid of the ACK errors. Can you please confirm if this is indeed an issue with the implementation, or if we should be rearchitecting it in a different way? Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages Hi @r-uv , Thank you for the detailed analysis. Your observation is consistent with the SDK  implementation. FLEXCAN_TransferReceiveFifoEDMA() is a finite-length transactional API. After each DMA completion, the driver disables the Rx FIFO DMA request, and the next call enables it again. Because changing MCR[DMA] requires Freeze mode, the next frame in minimum-IFS traffic may arrive before FlexCAN returns to Normal mode, resulting in a missed ACK. This also explains why removing the repeated DMA enable/disable operation eliminates the ACK errors but still causes dropped frames: the Freeze-related ACK gap is removed, but the eDMA transfer is not continuously rearmed. For continuous burst traffic, we recommend keeping the Rx FIFO DMA request enabled and using hardware-chained ping-pong/scatter-gather TCDs so that the next buffer is activated automatically. This requires a continuous DMA receive path rather than repeatedly restarting FLEXCAN_TransferReceiveFifoEDMA(). Best regards, Gavin Re: FLEXCAN EDMA - ACK errors while receiving a burst of CAN messages Thanks for the response. Are there any plans of adding this support in the SDK? A continuous DMA based implementation instead of just the current transactional API implementation? 

求找适用于 PCF8563TS/5,118 的电容 我正在使用 PCF8563TS/5,118 IC，想正确连接 OSCI 引脚上的外部电容。 我正在使用 50k ESR、12.5pF 32.568KHz 的晶体，尽可能短的走线，原理图与数据手册中的应用图完全相同。 我查阅了数据手册和 UM10301，尝试进行计算，以了解该设备。我发现很难找到一种清晰的方法来计算外部电容的值，因为数据表在同一主题的不同页面上提到了并联和串联，即 OSCI 和 OSCO。 我看到外部 OSCI 和 OSCO 引脚并联了一个内部 25pF 电容。数据手册中的表 30 表明 CL 是并联计算的，但有一个注释显示，CL 是串联电容的计算方法。 我找不到能让设备正常工作的外接电容。没有收到 I2C 响应。我尝试了 25pF、22.5pF、20pF、25pF、10pF、8.2pF、6pF。所有 0603 C0G/NP0 帽。 我通过完全不放置电容器，成功地让它在另一块板上工作了。经过计算，这根本说不通。 我想请您举例说明一下如何计算这些输入值（12.5pF 50k ESR 晶体），因为我无论通过计算还是暴力破解都无法使其正常工作。 Re: Help finding capacitor for PCF8563TS/5,118 是的，那是内置电容的数值，我在自己的帖子中也提到过。我已阅读过该文件。 如果你能把你想表达的意思写下来，那会更有帮助。感谢您抽出时间。 Re: Help finding capacitor for PCF8563TS/5,118 UM10301 PCF85x3、PCF85x63、PCA8565、PCF2123 和 PCA21125 用户手册 Re: Help finding capacitor for PCF8563TS/5,118 亲爱的戴维： db16122 正确地指出了UM10301 中的表 3。如果您的目标负载电容为 12.5pF，则需要在 OSCI 引脚上连接一个 25pF 的中间值的微调电容。 这个 25pF 值可以通过表 30 下方的公式计算得出。在PCF8563 数据手册中。 其中 CL 为目标负载电容，在本例中为 12.5pF。 Cosco 是已知的内部电容，25pF。 根据公式，可以推导出 Ctrim 值： CL=Ctrim*Cosco/(Ctrim+Cosco) CL*Ctrim+CL*Cosco=Ctrim*Cosco CL*Cosco=Ctrim*Cosco-CL*Ctrim CL*Cosco=Ctrim*(Cosco-CL) CL*Cosco/(Cosco-CL)=Ctrim 边际贡献 = CL * Cosco / (Cosco - CL) = 12.5 * 25 / (25 - 12.5) = 312.5 / 12.5 Ctrim=25pF 由于内部 Cosco 电容还有余量，因此需要可变微调电容。Cosco 值可能在 15pF 到 35pF 之间波动。 最诚挚的问候， 约瑟夫