Automotive Vehicle Comfort Control Using FRDM-A-S32K344 Microcontrollers Overview This article demonstrates the implementation of a vehicle comfort control system using the FRDM-A-S32K344 development platform. The application showcases how embedded peripherals can be used to control multiple vehicle comfort functions, including cabin cooling and electric window operation. The demo operates a DC motor and a stepper motor based on user inputs while providing real-time control through PWM generation and GPIO outputs. The project highlights the interaction between user inputs, control logic, PWM motor control, and stepper motor sequencing commonly found in automotive body electronics and comfort modules. The solution is based on an Application Code Hub example designed for the FRDM-A-S32K344 platform. Vehicle Comfort Control on FRDM-A-S32K344  Learning Objectives This project demonstrates: GPIO-based input handling PWM motor control Direction control techniques Stepper motor sequencing Real-time actuator control Automotive comfort system concepts Multi-actuator control using S32K3 peripherals The example provides a practical introduction to automotive body-control applications involving cooling and window-control systems. System Architecture The application follows a command-and-control architecture:   Plain Text     User Inputs ↓ GPIO Interface ↓ Vehicle Comfort Control Logic ↓ PWM + GPIO Outputs ↓ DC Motor + Stepper Motor Architecture Diagram (Insert Vehicle Comfort Control Architecture Diagram) Figure Caption Figure 1. Vehicle comfort control system architecture. User button inputs are processed by the S32K344 microcontroller. The application determines the desired comfort function and generates either PWM-controlled outputs for the cooling fan or GPIO sequencing signals for the stepper motor representing window movement.  Control Principle The demo operates two independent comfort functions: Cooling System Control A DC motor represents a vehicle cooling fan. The MCU generates PWM signals that regulate: Fan activation Fan speed Cooling-system behavior PWM control allows smooth speed adjustments while minimizing power losses. Window Control System A stepper motor represents an electric window mechanism. The MCU controls the motor through a full-step coil sequencing algorithm. This allows: Upward movement Downward movement Direction control Precise positioning The behavior emulates typical automotive power-window systems. User Input Processing The system uses push-button inputs connected to the FRDM-A-S32K344 board. The button states are continuously monitored through GPIO inputs. Based on the detected command, the application executes the corresponding comfort function. Possible actions include: Increasing fan activity Decreasing fan activity Moving the window upward Moving the window downward The control logic translates user commands into actuator actions in real time. DC Motor Control The DC Motor 2 Click board is used to drive a 5V fan motor. PWM output generated by the S32K344 controls: Motor activation Speed variation As the PWM duty cycle changes, the fan speed changes accordingly. This illustrates a common cooling-system implementation used throughout the automotive industry. Stepper Motor Control The H-Bridge Click board controls a NEMA17 stepper motor using a full-step drive sequence. The MCU energizes the motor coils in a predefined pattern:   Plain Text     A → B → C → D   This enables: Controlled rotation Direction changes Window position simulation The process demonstrates how automotive ECUs control electromechanical comfort systems. Control Behavior The control logic can be represented as a command-response system. Example behavior: User Action System Response Fan Command PWM duty cycle adjusted Window Up Stepper advances forward Window Down Stepper advances reverse No Command Actuators remain idle Control Behavior Diagram (Insert Comfort Control Behavior Diagram) Figure Caption Figure 2. Vehicle comfort control behavior. User commands are translated into specific actuator actions. PWM signals regulate fan speed, while GPIO-driven step sequences determine stepper motor direction and movement. Hardware Setup Required Hardware FRDM-A-S32K344 FRDM-A-S32K344FRDM-A-S32K344 FRDM K64 Click Shield FRDM K64 click shieldFRDM K64 click shield DC Motor 2 Click DC Motor 2 ClickDC Motor 2 Click H-Bridge Click H-Bridge ClickH-Bridge Click 5V Fan Motor 5V Fan Motor5V Fan Motor Stepper Motor NEMA17 Stepper Motor Nema17Stepper Motor Nema17 Full setup: Comfort Full SetupComfort Full Setup This configuration enables simultaneous control of both rotational-speed and positional actuators. Software Environment The example was developed using: S32 Design Studio S32K3 Real-Time Drivers (RTD) Application Code Hub framework The software demonstrates practical usage of GPIO and PWM drivers for actuator control. Implementation Guide Step 1: Import the Project Open S32 Design Studio Import project from Application Code Hub Search for Vehicle Comfort Control example Expected result: Project appears in workspace Step 2: Build the Application Compile the project Check for errors Expected result: Successful build Step 3: Connect Hardware Install: FRDM K64 Click Shield DC Motor 2 Click H-Bridge Click Fan motor NEMA17 stepper motor Verify all wiring before powering the system. Step 4: Flash and Run Program the MCU Start execution Expected result: Application runs continuously Step 5: Functional Validation After startup: Press the control buttons Observe fan operation Observe stepper motor movement Expected result: The system immediately responds to user commands. Comfort System Examples The demonstrated functions correspond to common automotive applications. Cooling Regulation The DC motor represents: Cabin ventilation systems HVAC airflow control Cooling fan operation Electric Window Control The stepper motor represents: Window up/down movement Position control Direction control These systems are examples of comfort-oriented body electronics within modern vehicles. Possible Extensions The application can be enhanced with: Feedback-Based Control Add sensors to provide closed-loop position or speed control. Automatic Comfort Modes Implement predefined comfort profiles. CAN Communication Enable communication with other vehicle ECUs. Diagnostic Functions Add fault detection and actuator monitoring. Position Memory Store and restore window or comfort positions. Conclusion This vehicle comfort control demonstration shows how the S32K344 platform can integrate user inputs, GPIO processing, PWM generation, and electromechanical actuator control into a complete embedded automotive application. By controlling both a DC motor and a stepper motor, the project illustrates the implementation of cooling-system regulation and electric-window operation, providing a practical example of automotive comfort-module design on the S32K3 platform. Comfort ResultComfort Result The course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples.

To complement solution how to printf float number in MCUXpresso IDE Hi: In previous topics there are some discussions how to print float number in MCUXpresso IDE and SDK. To try them and summarize the final solution: 1.PRINTF the float number to UART console set below macro in project configuration->C/C++ build ->setting PRINTF_FLOAT_ENABLE=1 such code will work. float test1 = 0.15; PRINTF("%f\r\n",test1); 2.Transform float number to string by sprintf() function. there is one error in SDK user manual, " Ensure Redlib: Use floating point version of printf is selected " during project creation does not work. The default C library Redlib doesn't support floating, so it couldn't work with redlib. The correct solution are: (1)Change link library to NewLib, it's full C library and support float  printf. But notice need include in related c file, or else sprintf(float) doesn't work as expected. (2)Change link library to NewLib Nano, it's compact C library , and need click "enable print float" to enable float function, which actually add " -u _printf_float" link symbol. But notice need include in related c file, or else sprintf(float) doesn't work as expected. So the solution surely add flash & RAM consumption in project, but for i.MXRT series it's not problem. Attach is one example for RT1020 EVK. Re: To complement solution how to printf float number in MCUXpresso IDE Thank you! That solved my problem.  Re: To complement solution how to printf float number in MCUXpresso IDE Hi @daweiyou  Thank you so much for your contribution. The information was pretty helpful and it might be helpful for many people. Thank you again. Best Regards. Pablo Avalos.

Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Board: Custom S32G399A based module, derived from S32G-VNP-RDB3. PFE_MAC1 connected via RGMII (PE_02–PE_13) to an NXP SJA1110A switch port 2, configured as the DSA CPU port (in-tree sja1105 driver, kernel 6.x BSP43.0). Topology: - PFE_MAC0: SGMII via SerDes1 lane1, Mode 1 - PFE_MAC1: RGMII to SJA1110A port 2 (DSA CPU port) — the port in question - PFE_MAC2: SGMII via SerDes0 lane1 The S32G MACs are configured as follows: +---------+--------------+------------------+ |                    | LANE 0               | LANE 1                        | +---------+--------------+------------------+ | SERDES0    | GMAC (SGMII) | PFE_MAC2 (SGMII)  | | SERDES1      | NOT USED        | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ Full U-Boot hwconfig: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii DTS for port@2 (switch side): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; DTS for pfe_netif1 (MAC side): &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) link state — confirmed up and correctly configured at the Linux/driver level: dmesg at boot: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTB confirms the kernel matches the source DTS: # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a output: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link All SJA1110 DSA slave ports correctly enumerated. This confirms the sja1105 DSA driver bound successfully to pfe1 as the CPU port/DSA master and parsed the static config without error. Clock tree: both TX and RX RGMII clocks enabled and attached to the correct consumer: # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id So pfe1 is UP, LOWER_UP, correctly bound to the SJA1110 as DSA master, running in RGMII mode with both clocks enabled — this rules out pfe1 being down, unbound, or misconfigured at the Linux/driver level. The open question is specifically whether frames actually cross the physical RGMII pins between PFE_MAC1 and SJA1110 port 2. Issue: No traffic appears to cross the RGMII bus between PFE_MAC1 and SJA1110 port 2 in either direction, despite everything on both sides of that bus being independently up: Test 1 — S32G -> switch direction Setup: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 Test 2 — switch -> S32G direction Setup Partner board is a separate SJA1105 switch based board. # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] Port 9 received 9 real frames; the fabric forwarded all 9 toward port 2 — but nothing arrived at pfe1. So the SJA1110's own fabric counters show all 9 frames successfully forwarded from port 9 to port 2's egress. But tcpdump -i pfe1 -e -nn on the S32G during this exact test shows NOTHING received. So the DSA/software layer on the S32G side believes it's sending (case 1). The switch's internal fabric believes it's sending toward the CPU port (case 2). Neither side has any confirmation that the other actually received anything across the physical RGMII bus. Every layer adjacent to this bus works individually; the bus itself has no confirmed successful crossing in either direction. What's been ruled out so far: - pfeng_mode / hwconfig (xpcs_mode) — confirmed correct; EMAC1 mode is RGMII (0x9), not SGMII (it was previously misconfigured as SGMII due to xpcs_mode=both on SerDes1 forcing PFE_MAC1's XPCS into SGMII; corrected to xpcs_mode=0 since PFE_MAC0 alone only needs XPCS0) - PFE_MAC1 TX/RX clock enablement — confirmed enabled at the correct rate (125MHz) in clk_summary - DSA tagging and CPU port binding — confirmed working (port netdevs exist, frames get tagged with the correct destination port in the DSA header) - SJA1110 internal fabric/forwarding — confirmed working between two other ports (9 and 2) using real external traffic - BASE-T1 link partner — confirmed passing real frames into the switch (port 9 n_rxfrm increments from genuine wire traffic) What hasn't been ruled out / open questions: - Whether 1000 Mbps RGMII with zero internal delay on both MAC and switch sides (rx/tx-internal-delay-ps=0, plain "rgmii" not "rgmii-id") is compatible without delay added by board trace length — have not yet tried forcing the link down to 100 Mbps as a timing-margin test 1. Is rx/tx-internal-delay-ps=0 on both ends at 1000 Mbps RGMII expected to work, or does this combination typically require delay compensation unless the PCB explicitly accounts for it? 2. Am I missing any other configuration? Happy to share full register dumps, if required. Appreciate any pointers before we probe the PE_02-13 bus with a logic analyzer (limited probe access due to board layout, so it is not so convenient currently. Thanks. Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z @db16122 I am attaching the relevant sections of the schematics here. The connection flow is as follows: We use PE_02 to PE_13 on the S32G3 chip shown in s32g3_pfe_mac1_connections.png for the PFE_MAC1. They go to a board to board connector (shown in Board_to_board_connector.png) that routes these signals to  a different board that has the switch. The switch connections are shown in SJA1110_A.png and SJA1110_B.png. So the connection is PE_xx pins -> board connectors -> switch (SJA1110) Please let me know if you have any questions. I have also raised a support ticket ( #00990408) with the same details.  Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi,pcentauri92 Thank you for your reply. Please provide me with the schematic diagrams related to your ETH, particularly the ones for PFE_MCA1 and SJA1110 sections. You can create an internal support system case. In the information description, @Joey, then provide your schematic diagram information. Refer to this website: https://support.nxp.com BR Joey Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi @Joey_z , Thank you for the response. The module in question here is a custom design that uses the S32G399A chip along with the NXP SJA1110A ethernet switch. We based this design on the S32G-VNP-RDB3 development platform but we made quite a few changes from the base design. The PFE_MAC1 using RGMII is one of those changes.  I am also attaching the dts file override where we change the PFE_MAC1 mode and pinmux here. PFE_MAC1 mode configuration: /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 pinmux: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; Please let me know if you need any other information.    Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction any schematics sharing from hardware side for RGMII bus between PFE_MAC1 and SJA1110 port 2 ? Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction Hi，pcentauri92 Thank you for your detail information According to my understanding, there seems to be a problem with the communication when using PFE_MAC1 RGMAII and Port 2 of SJA1110A on your development board. Is that correct? The default configuration of S32G-VNP-RDB3 is that PFE_MAC0/1 operates in SGMII mode and is connected to SJA1110. On your development board, why did you consider using RGMII mode? It is recommended to modify the corresponding software configuration. BR Joey

Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings Hi, We are currently testing an application jump from App1 to App2 on the FRDM-S32K344. Our application layout is: App1 Start Address: 0x00400000 App2 Start Address: 0x00500000 For debugging, we are using separate debug configurations with flash memory protection enabled. When debugging App1, the memory protection range is configured as: 0x00500000 to 0x005FFFFF (to protect App2) When debugging App2, the memory protection range is configured as: 0x00400000 to 0x004FFFFF (to protect App1) However, during programming through the debug configuration, we observe that the protected flash region is still being erased, even though the memory protection range has been configured. Could anyone clarify the following? Is the Flash Programmer expected to honor the configured memory protection ranges during erase/program operations? Is there any additional configuration required to prevent the protected flash region from being erased? Has anyone successfully used memory protection to preserve another application while programming only one application on the FRDM-S32K344? Logs and LD files are attached for your ref. we are using on board PE debugger Any guidance or recommendations would be greatly appreciated. Thank you. Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings Hi @Avinpat123  I did quick test in the same version of S32 Design Studio to be sure it is working. I used the same setup – one application forced to 0x40_0000 while 0x50_0000 area is configured to be preserved and second application forced to 0x50_0000 while 0x40_0000 area is configured to be preserved: Here are the logs which shows that this configuration is taken into account: And I can see in the memory that the content is really preserved, so it works as expected. I  saw in your screenshots that you configured the address range but the “Preserve this range” check box is not enabled. Isn’t that the problem? Regards, Lukas

S32K3 ADC 外部チャネルの利用 こんにちは。NXPチーム S32K3 ADCの外部チャネルの使い方 . Re: S32K3 ADC Use of external channels こんにちは、 @VaneBさん これに関して、追加の質問があります。 もし私のデザインにマルチマックスがなくても、例えばセンサ1にADC1_X[0]、センサ2にADC1_X[1]、そしてADC1_Xセンサ3にだけ使いたい場合は、MAピンをGPIO出力ピンなど他の用途で再利用してLEDを駆動することは可能でしょうか? 私のデザインはs32k344をベースにしています Re: S32K3 ADC Use of external channels NPXチームの皆様、こんにちは。 このトピックに関連して、以下の図のようなSCHを実装することが可能かどうか確認していただけますか? サポートありがとうございます。 Re: S32K3 ADC Use of external channels @VaneB ご協力いただき、誠にありがとうございました。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin 各ADCは外部アナログ多重化器の8チャネル中1チャネルを選択するために使う3つの外部デコード信号(MA)を提供し、最大4つのマルチプレクサを設置して32の外部チャネルを接続できます。つまり、これら4つのマルチプレクサは同じMA信号を共有します。 ADCは変換対象の現在のチャネルに基づき、これらの外部アナログ多重化器を制御するよう自動設定します。マスクレジスタのビットに応じて、対応する「X」ピンがサンプリングされ、その結果が「MA」と「X」の組み合わせに対応する場所に格納されます。 当社の開発ボードには外部アナログ多重化装置が設計されていないため、そのような例は実装されていません。 Re: S32K3 ADC Use of external channels こんにちは。ヴェインB あなたのプロンプトによると、RTDで外部チャネルADCを使った例が見つかりません。もし対応するルーティンがあれば、ぜひ送っていただけると嬉しいです。どうもありがとうございます。 Re: S32K3 ADC Use of external channels こんにちは@Niuyanlin RTDで役立つかもしれないADCの実装例が見つかります。 BR VaneB

MBDT中的CAN总线处理 我正在使用 NXP 的 MBDT for S32K344 来配置 FlexCAN0。我想了解 CAN 消息处理的哪些部分由 NXP 模块/工具箱管理，哪些部分需要由应用程序处理。 仲裁和缓冲区处理是否由驱动程序/工具箱管理？例如：如果我先发送 0x18FEF111，那么 0x18FEEF00 都不会出现在总线上。但如果先发送 0x18FEEF00，则两者都会被发送。当两者同时触发信号时，只会显示其中一个。 那么，在同时发送多个帧时，是否需要为每个消息 ID 分配专用的发送硬件对象？ MBDT 或 SDK 是否处理消息优先级，并在未收到 ACK 时自动重试？ 如果高优先级 ID 失败（例如，没有收到 ACK），是否会阻塞其他消息？我们如何检测并从中恢复？ 为了避免阻塞或消息丢失，模型中是否需要手动管理缓冲区分配或传输时序？ 在 MBDT 中配置多个 Tx 消息 ID 的最佳方法是什么？使用动态缓冲区。 请明确哪些是内部处理的，哪些是我们需要在应用程序中处理的。 示例模型 Re: CAN Bus Handling in MBDT 你好@SorinIBancila ， 我遇到了需要发送的帧数超过可用 HTH 硬件对象数量的情况。由于 S32CT 无法利用 CanIf 发送缓冲实现，您能否推荐一种基于 Simulink 的缓冲解决方案来解决此问题？ 谢谢，此致敬礼！ 桑德什 Re: CAN Bus Handling in MBDT 你好， 32 个 Can Hw 对象数量并非限制。根据你所使用的MCU型号，你还可以进一步提高这个限制。您可以修改 Can Hw Object Count 的数量，但如果您输入的数字过大，S32CT 将报错。 顺祝商祺！ 索林·班奇拉 Re: CAN Bus Handling in MBDT 明白了！如果我需要发送超过 32 条消息，是否应该创建额外的发送硬件对象？另外，在 S32K3 中使用 S32CT，单个 CAN 收发器或控制器下最多可以配置多少个硬件对象？ 想了解在限制条件下，如何以最佳方式构建大型消息集的 HOH。 Re: CAN Bus Handling in MBDT 你好， 你认为一次需要发送多少条信息？ 我已在 S32K358 HVBMS 参考设计上测试了以下场景： 使用单个 TX 硬件对象，并将Can 硬件对象计数设置为 32（以允许缓冲区中最多 32 条消息）。 在 Simulink 中，我向消息缓冲区填充了 32 条消息，随着缓冲区填充的进行，消息优先级也随之增加，以验证仲裁过程。 结果： 正如预期的那样，由于消息缓冲区尚未完全填充，因此发送的第一批消息优先级较低。大约在第 6 条消息时，缓冲区已满，我们可以看到优先级较高的消息会先发送。 由于你想使用单个收发器，因此实际上不可能同时发送所有消息。 顺祝商祺！ 索林·班奇拉 Re: CAN Bus Handling in MBDT 索林，你好 感谢您的意见！ 我想说明在使用动态缓冲区时，在 MBDT 中配置多个 Tx 消息 ID 的最佳方法。就我而言，该控制器用于电动汽车应用，采用基于 J1939 的 CAN 设置，涉及数百个循环消息。 在 S32CT 中为每条消息创建单独的硬件对象似乎既不可扩展也不实用。我希望使用单个 Tx 硬件对象来动态处理多个消息，并通过一个 CAN 接口同时传输它们。 请问针对这种使用场景，推荐的配置或最佳实践是什么？另外，请推荐一些我需要参考的文档，以便了解 MBDT 中配置设置的工作原理和相关函数。 Re: CAN Bus Handling in MBDT 你好， 首先，我想指出的是，S32K3xx 的 MBDT 是基于 S32K3 RTD 的版本。外围设备的配置是在 S32 配置工具中完成的，以便您可以灵活地进行所需的设置。因此，要检查 NXP 的 MBDT S32K3xx 是否支持某个功能，您可以检查外设（在 S32K3 RTD 中）使用的源代码及其在 S32 配置工具中的可用设置。 在工具箱中，您可以在此处找到 FlexCAN 外设的实现： {toolboxRoot}/src/S32K3_RTD/SW32K3_S32M27x_RTD_R21-11_6.0.0/eclipse/plugins/Can_43_FLEXCAN_TS_T40D34M60I0R0/ 笔记！根据您使用的 MBDT S32K3 版本不同，S32K3 RTD 的名称可能会有所不同。 你问题的答案是基于我的经验，可能并不完全准确。 1、2 和 5：该工具箱不处理任何仲裁，但我不太确定 SDK 中有哪些选项可用于此目的。在你的示例中，你创建了另一个CanHardwareObject并使用它来发送第二条消息，但这种方法可能难以管理。第二个解决方案可能是增加Can Hw 对象计数，以允许缓冲区中存在更多消息。 3：S32K3 的 MBDT 不处理任何消息优先级。据我所知，FlexCAN 控制器负责重试发送消息，直到收到 ACK 为止，同时将消息阻塞在缓冲区中。 4. 检测消息是否已发送的一种方法是使用硬件中断回调中的CanIf_TxConfirmation中断来标记消息已发送。如果指定的 PDU 没有触发信号中断，则表示该消息未发送。此外，还有一个中断（ CAN_ControllerBusOff ）可用，当满足 CAN 总线关闭的条件时，该中断会产生触发信号。在 S32 配置工具中，有一个选项可以从总线关闭状态自动恢复。 如有任何疑问，请随时回复。 此致， 索林·班奇拉

MC33774 デイジーチェーン デュアルループ接続 こんにちは。 現在、MC33665AとMC33774を使用してダブルチェーンループバック構造を形成するAFEサンプリングシステムを使用しています。MC33665AのPORT0とPORT1はそれぞれMADD0とMADD1として構成されており、すべてのコマンドは現在MADD0経由で送信されています。PORT0とDC1の間だけをデイジーチェーン接続すると、通信は正常です。しかし、PORT1とDC2の間にもデイジーチェーン接続すると、33774が応答フレームで応答できないことがわかりました。これはなぜでしょうか？33665のPORT構成が正しいこと、および33774のSYS_TPL_CFG.RESPCFGが00 SAMEモードに設定されていることは確認済みです。 現在、私はMC33665AとMC33774を組み合わせたデュアルリングループ構成のAFEサンプリングシステムを使用しています。MC33665AのPORT0とPORT1をそれぞれMADD0とMADD1として設定し、現在すべてのコマンドはMADD0経由で送信されています。 PORT0とDC1の間だけをデイジーチェーン接続した場合、通信は正常に動作します。しかし、PORT1とDC2の間にデイジーチェーン接続も行った後、MC33774にリクエストを送信しても応答しなくなりました。 なぜこのようなことが起こるのでしょうか？ MC33665 PORT の設定を読み返して確認したところ、正しいことが分かりました。また、MC33774 で SYS_TPL_CFG.RESPCFG = 00 (SAME モード) を設定しました。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは。 1. MADD=1の位置からDADDの割り当てを反転させる必要があるかどうかを知りたいです。 2. 現在のSYS_PORT0_CFG構成は、TIMEOUT=0、CADD=1、MADD=0、PROTOCOL=1、ALLCHAINS=1、TERM=1、RX=1、EN=1です。 SYS_PORT1_CFG は、TIMEOUT=0、CADD=1、MADD=1、PROTOCOL=1、ALLCHAINS=1、TERM=1、RX=1、EN=1 で構成されています。 Re: MC33774 Daisy Chain Dual Loop Connection こんにちは、 AN13910 TPLループバック推奨によると、2つのMC33665A TPLポートがループバックリングとしてコネクテッドである場合、あなたが見ている挙動を引き起こすいくつかの設定要件があります。 ループバック構成の場合： デバイスアドレス（DADD）は、リングの一方の側からは昇順で、ループバック側からは逆順で割り当てることをお勧めします（あなたの画像にはそれが確認できません）。 2つのポートがループバックとしてコネクテッドされている場合、重複データがMC33665バッファに入るのを防ぐために、どちらか一方のポートはSYS_PORTx_CFG[RX] = 0であるべきです。 さらに、いずれかのポートのSYS_PORTx_CFG[ALLCHAINS]が0である必要があります。両方のループバックポートがALLCHAINSコマンドを受け入れている場合、文書にはこれが信号の競合や通信エラーを引き起こす可能性があると記載されています。 SYS_PORT0_CFGとSYS_PORT1_CFG(特にEN、RX、ALLCHAINS、MADD、CADD)の価値観を共有していただけますか?それは、ループバックポートがAN13910の推奨事項に従って構成されているかどうかを判断するのに役立ちます。

调试 Flash 脚本覆盖“保护内部闪存区域”设置 您好， 我们目前正在测试FRDM-S32K344上从App1到App2的应用程序跳转。 我们的应用程序布局如下： 应用程序1起始地址： 0x00400000 应用程序2起始地址： 0x00500000 为了进行调试，我们使用了启用闪存保护的独立调试配置。 调试App1时，内存保护范围配置如下： 0x00500000 到 0x005FFFFF（用于保护 App2） 调试App2时，内存保护范围配置如下： 0x00400000 到 0x004FFFFF（用于保护 App1） 然而，在通过调试配置进行编程时，我们发现即使已经配置了内存保护范围，受保护的闪存区域仍然会被擦除。 请问有人能解释一下以下问题吗？ Flash Programmer 在擦除/编程操作期间是否应遵守配置的内存保护范围？ 是否需要进行任何额外的配置来防止受保护的闪存区域被擦除？ 有没有人成功地使用内存保护功能，在 FRDM-S32K344 上只编写一个应用程序的同时，保留另一个应用程序？ 日志文件和 LD 文件已附上，供您参考。 我们正在使用板上 PE 调试器 任何指导或建议都将不胜感激。 谢谢！ Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings 你好@Avinpat123 我在相同版本的 S32 Design Studio 中进行了快速测试，以确保它能够正常工作。我使用了相同的设置——一个应用程序被强制使用 0x40_0000 地址，而 0x50_0000 地址区域配置为保留；第二个应用程序被强制使用 0x50_0000 地址，而 0x40_0000 地址区域配置为保留： 以下日志显示此配置已被应用： 而且我可以看到内存中的内容确实被保留了下来，所以它运行正常。 我从你的截图中看到你配置了地址范围，但是“保留此范围”复选框没有启用。问题不就出在这里吗？ 此致， Lukas

MBDTにおけるCANバス処理 FlexCAN0の設定には、NXPのS32K344用MBDTを使用しています。CANメッセージ処理のどの部分がNXPのブロックやツールボックスで管理され、何がアプリケーションで処理されるべきかを理解したいです。 仲裁やバッファの処理はドライバやツールボックスで管理されていますか?例：最初に0x18FEF111を送信すると、0x18FEEF00はバス上に表示されません。しかし、0x18FEEF00を先に送信すると、両方とも送信されます。両方を同時に送信すると、どちらか一方のみが表示されます。 SO、複数のフレームを同時に送信する際、各メッセージIDに専用のTxハードウェアオブジェクトを割り当てる必要がありますか? MBDTやSDKsはメッセージの優先順位付けを処理し、ACKが届かない場合に自動的に再試行しますか? 優先度の高いIDが失敗した場合（例えば、ACKが返ってこなかった場合）、他のメッセージもブロックされますか？これをどのように検知し、復旧すればよいのでしょうか？ ブロックやメッセージの喪失を避けるために、モデル内でバッファの割り当てや送信タイミングを手動で管理する必要がありますか? MBDTで複数のTxメッセージIDを設定する最適な方法は何ですか？動的バッファを使用する場合。 社内で何が処理されるのか、アプリケーションで何が処理されるのかを明確にしてください。 サンプル・モデル Re: CAN Bus Handling in MBDT こんにちは、 @SorinIBancila さん、 利用可能なHTHハードウェアオブジェクトの数よりも多くのフレームを送信する必要がある状況に遭遇しました。CanIf送信バッファリング実装はS32CTでは活用できないため、この問題に対してsimulinkベースのバッファソリューションをおすすめしてもらえますか? ありがとうございます。 サンデシュ Re: CAN Bus Handling in MBDT こんにちは、 32 CANのハードウェアオブジェクト数は制限ではありません。MCUによってはさらに制限を上げることも可能です。CANオブジェクトカウントの上限を変更できますが、数字を大きくするとS32CTがエラーを出します。 よろしくお願いいたします。 ソリン・バンシラ Re: CAN Bus Handling in MBDT 理解した！SO、32以上のメッセージを送信する必要がある場合、追加のTx Hardware Objectを作成するべきでしょうか?また、S32CTを使ったS32K3で単一のCANトランシーバまたはコントローラの下で設定できるハードウェアオブジェクトの最大数はどれくらいですか? 制限内に収まるように、大規模なメッセージセットに対してHOH（階層型ヘッダー）を構成する最適な方法を理解したいと考えています。 Re: CAN Bus Handling in MBDT こんにちは、 一度に何件のメッセージを送信する必要があると思いますか？ S32K358 HVBMSリファレンスデザインで以下のシナリオをテストしました: 単一の送信ハードウェアオブジェクトを使い、Can Hw Objectカウント を32に設定します(バッファ内に最大32メッセージを許可するため)。 Simulinkでは、調停プロセスを検証するために、メッセージバッファに32個のメッセージを格納し、バッファにメッセージが格納されるにつれて優先度を上げました。 結果： 予想通り、メッセージバッファが完全に満たされていないため、最初に送信されるメッセージは優先度が低くなります。6番目のメッセージあたりでバッファが埋められ、CANの優先度の高いメッセージが最初に送信されるのがわかります。 単一のトランシーバを使いたい場合、すべてのメッセージを同時に送信することは実際には不可能です。 よろしくお願いいたします。 ソリン・バンシラ Re: CAN Bus Handling in MBDT こんにちは、ソリンさん。 ご意見ありがとうございます！ 動的バッファを使用する場合に、MBDTで複数の送信メッセージIDを設定する最適な方法を明確にしたいと思いました。私の場合、コントローラはJ1939ベースのCANセットアップでEVアプリケーションに使われており、数百のサイクリックメッセージが関わっています。 S32CTでメッセージごとに個別のハードウェアオブジェクトを作成する方法は、拡張性にも実用性にも欠けるように思われる。単一のTxハードウェアオブジェクトを使って複数のメッセージを動的に処理し、1つのCANインターフェースを通じて同時に送信したいと考えています。 このユースケースで推奨されるセットアップやベストプラクティスについて教えていただけませんか?また、MBDTで使われる設定設定や関連関数の仕組みを理解するために参照しなければならないドキュメントもぜひ教えてください。 Re: CAN Bus Handling in MBDT こんにちは、 まず最初に、S32K3xx用のMBDTはS32K3 RTDをベースに構築されていることを指摘しておきたいと思います。ペリフェラルの設定はS32設定ツールで行い、必要な設定に完全な柔軟性を持たせます。つまり、NXPのMBDT S32K3xxで機能がサポートされているかどうかを確認するには、ペリフェラル(S32K3 RTDで使用されている)のソースコードとS32設定ツールの利用可能な設定を確認できます。 ツールボックスには、FlexCANペリフェラルの実装がこちらにあります: {toolboxRoot}/src/S32K3_RTD/SW32K3_S32M27x_RTD_R21-11_6.0.0/eclipse/plugins/Can_43_FLEXCAN_TS_T40D34M60I0R0/ 注記！S32K3 RTDの名称は、使用するMBDT S32K3のバージョンによって異なる場合があります。 ご質問への回答は私の経験に基づくものであり、必ずしも完全に正確とは限りません。 1 & 2 & 5:ツールボックスは仲裁を扱っていませんが、SDKでこのマターに関してどんなオプションがあるのかはよくわかりません。あなたの例では、別のCanHardwareObjectを作成してそれを使って 2 番目のメッセージを送信していますが、この方法は管理が難しいかもしれません。2つ目の解決策は、バッファにより多くのメッセージを入れるためにCan Hw Object Countを作成することです。 3：S32K3 用の MBDT はメッセージの優先順位付けを処理しません。私の知る限り、FlexCANコントローラの役割は、ACKが受信されるまでメッセージを再送信しつつ、バッファ内でメッセージをブロックすることです。 4. メッセージが送信されたかどうかを検出する方法の1つは、ハードウェア割り込みコールバックで割り込みCanIf_TxConfirmationを使用して、メッセージが送信されたことをマークすることです。指定されたPDUに対して割り込みが発生しない場合、メッセージは送信されなかったことを意味します。さらに、CANバスオフの条件を満たすとトリガーされる別の割り込み(CAN_ControllerBusOff)が利用可能です。S32設定ツールには、バスオフ状態から自動的に復旧するオプションがあります。 ご質問があれば、遠慮なくご返信ください。 よろしくお願いします、 ソリン・バンシラ

定制 S32G399A 板：双向均无帧交叉选择开关面向 RGMII 总线 板：基于 S32G399A 的定制模块，源自 S32G-VNP-RDB3。PFE_MAC1 通过 RGMII (PE_02–PE_13) 连接到 NXP SJA1110A 交换机端口 2，配置为 DSA CPU 端口（树内 sja1105 驱动程序，内核 6.x BSP43.0）。 拓扑结构： - PFE_MAC0：通过 SerDes1 通道 1 的 SGMII，模式 1 - PFE_MAC1：RGMII 到 SJA1110A 端口 2（DSA CPU 端口）——即所讨论的端口 - PFE_MAC2：通过 SerDes0 通道 1 进行 SGMII 传输 S32G MAC地址配置如下： +---------+--------------+------------------+ | | 第 0 道 | 第 1 道 | +---------+--------------+------------------+ | SERDES0 | GMAC (SGMII) | PFE_MAC2 (SGMII) | | SERDES1 | 未使用 | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ 完整的 U-启动 硬件配置： hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii 端口 2（交换机侧）的 DTS： port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; pfe_netif1（MAC 端）的 DTS： &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 (pfe1) 链路状态 — 已确认已启动，并且在 Linux/驱动程序级别配置正确： 启动时 dmesg： [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed 实时 DTB 确认内核与源 DTS 匹配： # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip 输出： 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link 所有SJA1110 DSA从端口均已正确枚举。这证实了 sja1105 DSA 驱动程序已成功绑定。 将 pfe1 作为 CPU 端口/DSA 主设备，并解析静态配置，未出现错误。 时钟树： TX 和 RX RGMII 时钟均已启用并连接到正确的使用者： # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id 因此，pfe1 状态为 UP、LOWER_UP，已正确绑定到 SJA1110 作为 DSA 主设备，并以 RGMII 模式运行。 两个时钟都已启用——这排除了 pfe1 宕机、未绑定或配置错误的可能性。 Linux/驱动程序级别。目前尚不清楚的具体问题是，帧是否真的会跨越 PFE_MAC1 和 SJA1110 端口 2 之间的物理 RGMII 引脚。 问题： 尽管总线两侧的所有设备都已独立启动，但 PFE_MAC1 和 SJA1110 端口 2 之间的 RGMII 总线似乎没有任何流量双向通过： 测试 1 — S32G -> 切换方向 设置： ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 测试 2 — 切换 -> S32G 方向 设置伙伴板是一个独立的基于 SJA1105 交换机的板。 # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] 端口 9 接收到 9 个实际帧；交换矩阵将全部 9 个帧转发到端口 2——但是 pfe1处未收到任何信息。 因此，SJA1110 自身的交换矩阵计数器显示所有 9 个帧都已成功从端口 9 转发到端口 2 的出口。 但是，在本次测试中，S32G 上运行 tcpdump -i pfe1 -e -nn 命令显示没有收到任何数据。 因此，S32G 端的 DSA/软件层认为它正在发送（情况 1）。交换机的内部结构认为它正在向 CPU 端口发送数据（情况 2）。双方都无法确认对方是否真的通过物理 RGMII 总线收到了任何信息。与这条总线相邻的每一层都是独立运行的；这条总线本身在任何方向上都没有确认的成功穿越记录。 目前已排除的可能性： - pfeng_mode / hwconfig (xpcs_mode) — 已确认正确；EMAC1 模式为 RGMII (0x9)，而非 SGMII（之前由于 SerDes1 上的 xpcs_mode=both 强制 PFE_MAC1 的 XPCS 为 SGMII，因此错误地配置为 SGMII；已更正为 xpcs_mode=0，因为 PFE_MAC0 单独只需要 XPCS0）。 - PFE_MAC1 TX/RX 时钟使能 — 已在 clk_summary 中确认以正确的频率 (125MHz) 使能 - DSA 标记和 CPU 端口绑定——已确认工作正常（端口网络设备存在，帧在 DSA 标头中被标记了正确的目标端口） - SJA1110 内部交换矩阵/转发 — 已确认在另外两个端口（9 和 2）之间使用真实外部流量正常工作 - BASE-T1 链路伙伴 — 已确认将真实帧传递到交换机（端口 9 n_rxfrm 从真实的线路流量中递增） 尚未排除的可能性/悬而未决的问题： - 在 MAC 端和交换机端均无内部延迟（rx/tx-internal-delay-ps=0，使用纯“rgmii”而非“rgmii-id”）的情况下，1000 Mbps RGMII 是否兼容，且不考虑板载走线长度带来的延迟——尚未尝试将链路速率强制降至 100 Mbps 进行时序裕量测试。 1. 在 1000 Mbps RGMII 模式下，两端的 rx/tx-internal-delay-ps=0 是否预期可以工作，或者除非 PCB 明确考虑了延迟补偿，否则这种组合通常需要延迟补偿吗？ 2. 我是否遗漏了其他配置？ 如有需要，我很乐意提供完整的寄存器转储文件。在用逻辑分析仪探测 PE_02-13 总线之前，请提供一些建议（由于电路板布局的限制，探针的访问受到限制，因此目前不太方便）。 谢谢。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 嗨@Joey_z @db16122，我把原理图的相关部分附在这里。连接流程如下： 我们使用s32g3_pfe_mac1_connections.png中所示的 S32G3 芯片上的 PE_02 到 PE_13 作为 PFE_MAC1。它们连接到板对板连接器（如图Board_to_board_connector.png所示），该连接器将这些信号路由到具有开关的另一块板。交换机连接如图SJA1110_A.png和SJA1110_B.png 所示。 所以连接方式是：PE_xx 引脚 -> 板连接器 -> 开关 (SJA1110) 如有任何疑问，请随时联系我。我也提交了一份支持工单（ #00990408 ），内容与上述相同。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 你好， pcentauri92 感谢您的回复。 请提供与您的 ETH 相关的原理图，特别是 PFE_MCA1 和 SJA1110 部分的原理图。 您可以创建内部支持系统案例。@Joey ，请在信息描述中提供您的原理图信息。请访问此网站： https://support.nxp.com BR 乔伊 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 嗨@Joey_z ， 谢谢你的回复。 这里提到的模块是一个定制设计，它使用了 S32G399A 芯片和 NXP SJA1110A 以太网交换机。我们以 S32G-VNP-RDB3 开发平台为基础进行设计，但对基础设计做了一些改动。使用 RGMII 的 PFE_MAC1 就是其中一项更改。 我还附上了 dts 文件覆盖，其中我们更改了 PFE_MAC1 模式和引脚复用。 PFE_MAC1 模式配置： /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1 引脚复用： /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; 如果您还需要其他信息，请告诉我。   Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 是否有关于PFE_MAC1和SJA1110端口2之间RGMII总线的硬件原理图可以分享？ Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction 你好， pcentauri92 感谢您提供的详细信息 据我了解，当您在开发板上使用 PFE_MAC1 RGMAII 和 SJA1110A 的端口 2 时，通信似乎存在问题。是这样吗？ S32G-VNP-RDB3 的默认配置是 PFE_MAC0/1 以 SGMII 模式运行并连接到 SJA1110。在你的开发板上，为什么考虑使用 RGMII 模式？建议修改相应的软件配置。 BR 乔伊

カスタムS32G399Aボード:スイッチ面RGMIIバスをクロスフレームなしでいずれの方向にも接続しません 基板： S32G-VNP-RDB3をベースにしたカスタムS32G399Aモジュール。PFE_MAC1 RGMII(PE_02–PE_13)を介してNXPのSJA1110Aスイッチポート2にコネクテッド、DSA CPUポートとして設定されていました(in-tree sja1105ドライバ、カーネル6.x BSP43.0)。 トポロジー： - PFE_MAC0: SerDes1 レーン 1 経由の SGMII、モード 1 - PFE_MAC1: RGMII から SJA1110A ポート 2 (DSA CPU ポート) — 問題のポート - PFE_MAC2: SerDes0レーン1経由のSGMII S32G MACは以下のように構成されています。 +---------+--------------+------------------+ | | レーン0 | レーン1 | +---------+--------------+------------------+ | SERDES0 | GMAC (SGMII) | PFE_MAC2 (SGMII) | | SERDES1 | 未使用 | PFE_MAC0 (SGMII) | +---------+--------------+------------------+ 完全なU-Bootハードウェア構成: hwconfig=pcie0:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=both;pcie1:mode=sgmii,clock=ext,fmhz=100,xpcs_mode=0 pfeng_mode=enable,sgmii,rgmii,sgmii port@2用DTS(スイッチ側): port@2 { reg = <2>; label = "OBC-1"; ethernet = <&pfe_netif1>; phy-mode = "rgmii"; rx-internal-delay-ps = <0>; tx-internal-delay-ps = <0>; fixed-link { speed = <1000>; full-duplex; }; }; pfe_netif1 (MAC側) の DTS: &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1(pfe1)リンク状態 — Linux/ドライバーレベルで確認・正しく設定: 起動時のdmesg: [ 5.264108] pfeng 46000000.pfe: netif name: pfe1 [ 5.274127] pfeng 46000000.pfe: netif(pfe1) linked phyif: 1 [ 5.279692] pfeng 46000000.pfe: netif(pfe1) mode: std [ 5.284853] pfeng 46000000.pfe: netif(pfe1) HIFs: count 1 map 02 [ 6.012884] pfeng 46000000.pfe pfe1 (uninitialized): Subscribe to HIF1 [ 6.019438] pfeng 46000000.pfe pfe1 (uninitialized): Host LLTX disabled [ 6.026270] pfeng 46000000.pfe pfe1 (uninitialized): Enable HIF1 [ 6.032374] pfeng 46000000.pfe pfe1 (uninitialized): setting MAC addr: 00:04:9f:be:ef:01 [ 6.040545] pfeng 46000000.pfe pfe1 (uninitialized): PTP HW addend 0x80000000, max_adj configured to 46566128 ppb [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.070441] pfeng 46000000.pfe pfe1: registered [ 6.207482] pfeng 46000000.pfe pfe1: configuring for fixed/rgmii link mode [ 6.214306] pfeng 46000000.pfe pfe1: Set TX clock to 125000000Hz [ 6.220158] pfeng 46000000.pfe pfe1: Link is Up - 1Gbps/Full - flow control off [ 5.257995] pfeng 46000000.pfe: EMAC0 interface mode: 4 [ 5.290707] pfeng 46000000.pfe: EMAC1 interface mode: 9 [ 5.323320] pfeng 46000000.pfe: EMAC2 interface mode: 4 [ 5.354571] pfeng 46000000.pfe: Interface selected: EMAC0: 0x4 EMAC1: 0x9 EMAC2: 0x4 [ 5.382609] pfeng 46000000.pfe: TX clock on EMAC0 for interface sgmii installed [ 5.390050] pfeng 46000000.pfe: RX clock on EMAC0 for interface sgmii installed [ 5.404998] pfeng 46000000.pfe: TX clock on EMAC1 for interface rgmii installed [ 5.419918] pfeng 46000000.pfe: Defer enabling of RX clock on EMAC1 for interface rgmii (ret: -5) [ 5.434235] pfeng 46000000.pfe: TX clock on EMAC2 for interface sgmii installed [ 5.448374] pfeng 46000000.pfe: RX clock on EMAC2 for interface sgmii installed [ 5.667058] pfeng 46000000.pfe: EMAC timestamp external mode bitmap: 0 [ 5.998447] pfeng 46000000.pfe pfe0 (uninitialized): Registered PTP HW clock successfully on EMAC0 [ 6.060939] pfeng 46000000.pfe pfe1 (uninitialized): Registered PTP HW clock successfully on EMAC1 [ 6.130296] pfeng 46000000.pfe pfe2 (uninitialized): Registered PTP HW clock successfully on EMAC2 [ 6.215040] pfeng 46000000.pfe: RX clock on EMAC1 for interface rgmii installed Live DTBは、カーネルがソースDTSと一致することを確認します。 # cat /proc/device-tree/soc/pfe@46000000/ethernet@11/phy-mode rgmii ip a の出力: 6: pfe1: mtu 1536 qdisc mq state UP group default qlen 1000 link/ether 00:04:9f:be:ef:01 brd ff:ff:ff:ff:ff:ff inet6 fe80::204:9fff:febe:ef01/64 scope link SJA1110 DSAスレーブポートはすべて正しく列挙されました。これにより、sja1105のDSAドライバが正常にバインドされていることが確認されました pfe1をCPUポート/DSAマスターとして設定し、静的設定を誤りなく解析しました。 クロックツリー： TXおよびRXのRGMIIクロックが両方とも有効で、正しいコンシューマーに接続されています。 # cat /sys/kernel/debug/clk/clk_summary | grep pfe1 pfe1_tx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_mii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_rmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_tx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 tx_rgmii pfe1_rx_rgmii 1 1 0 125000000 0 0 50000 Y ethernet@11 rx_rgmii pfe1_tx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id pfe1_rx_sgmii 0 0 0 125000000 0 0 50000 Y deviceless no_connection_id SO pfe1はUP、LOWER_UP、DSAマスターとして正しくSJA1110バインドされ、RGMIIモードで動作しています 両方のクロックが有効になっている場合 — これによりPFE1がダウン、アンバウンド、または誤った設定で Linux/ドライバレベル。未解決の問題は、フレームが実際に PFE_MAC1とSJA1110ポート2間の物理的なRGMIIピン。 問題： PFE_MAC1とSJA1110ポート2間のRGMIIバスでは、バスの両側の機器がすべて独立して稼働しているにもかかわらず、どちらの方向にもトラフィックが流れていないようです。 テスト1 — S32G ->スイッチ方向 セットアップ: ip addr add 192.168.1.100/24 dev EPS-100bt1-9 ethtool -S pfe1 | grep '^ p02_' > before tcpdump -i pfe1 -e -nn -c 20 > capture.txt & arping -c 10 -I EPS-100bt1-9 192.168.1.6 ethtool -S pfe1 | grep '^ p02_' > after # arping -c 10 -I EPS-100bt1-9 192.168.1.6 ARPING 192.168.1.6 from 192.168.1.100 EPS-100bt1-9 Sent 10 probes (10 broadcast(s)) Received 0 response(s) $ cat capture.txt tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes 18:08:36.352535 AF Unknown (4294967295), length 64: 0x0000: ffff 0004 9fbe ef01 dadb 0c09 0806 0001 ................ 0x0010: 0800 0604 0001 0004 9fbe ef01 c0a8 0164 ...............d 0x0020: ffff ffff ffff c0a8 0106 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 ............ [... 9 more identical ARP frames, all correctly DSA-tagged (dadb 0c09) and well-formed, plus one unrelated IPv6 background frame interleaved ...] # diff before after --- before +++ after @@ -1,4 +1,4 @@ - p02_: 1 + p02_: 0 p02_n_runt: 0 p02_n_soferr: 0 p02_n_alignerr: 0 # grep n_rxfrm before after before: p02_n_rxfrm: 0 after: p02_n_rxfrm: 0 テスト2 — スイッチ-> S32G方向 セットアップパートナーボードは別のスイッチベースのSJA1105ボードです。 # ping -c 10 -I t1-6 192.168.1.100 (run on a separate SJA1105/1110-family switch board connected to our port 9 / 100BASE-T1 / EPS-100bt1-9) # diff before after (ethtool -S EPS-100bt1-9) - n_rxfrm: 0 + n_rxfrm: 9 <- port 9 physically received 9 frames from the wire # diff before after - p02_n_txfrm: 0 + p02_n_txfrm: 9 <- switch fabric forwarded all 9 toward the CPU port # tcpdump -i pfe1 -e -nn -c 20 (same window) listening on pfe1, link-type NULL (BSD loopback), snapshot length 262144 bytes [-- nothing captured --] ポート9は9つの実際のフレームを受信しました。ファブリックは9つすべてをポート2に転送しましたが、 pfe1には何も届きませんでした。 SO、SJA1110自身のファブリックカウンターでは、ポート9からポート2の出口へ9フレームすべてが正常に転送されたことが示されています。 しかし、このテスト中にS32Gでtcpdump -i pfe1 -e -nnを実行すると、何も受信されなかったことが示されます。 つまり、S32G側のDSA/ソフトウェア層は送信していると認識しています(CASE 1)。スイッチの内部ファブリックはCPUポートに向かって送信していると認識しています(CASE 2)。どちらの側も、相手側が物理的なRGMIIバスを介して実際に何かを受信したという確証は得ていない。このバスに隣接する各層は個別に機能します。バス自体は、どちらの方向にも正常に通過したことが確認されていません。 これまでに除外されたこと: - pfeng_mode / hwconfig (xpcs_mode) — 正確であることが確認されています。EMAC1モードはRGMII(0x9)であり、SGMIIではありません(以前はSerDes1でxpcs_mode=両方がPFE_MAC1のXPCSSをSGMIIに強制的に入ったためSGMIIとして誤って設定されていました。PFE_MAC0単独でXPCS0が必要なため、xpcs_mode=0に修正します) - PFE_MAC1 TX/RXクロックのイネーブルメント — clk_summaryで正しいレート(125MHz)で有効化が確認されています - DSAタグ付けおよびCPUポートバインディング — 動作確認済み(netdevのポートが存在し、フレームにDSAヘッダーで正しい宛先ポートがタグ付けされる) - SJA1110内部ファブリック/転送 — 実際の外部トラフィックを用いて他の2つのポート(9と2)間で動作が確認されました - BASE-T1リンクパートナー — 実際のフレームをスイッチに渡すことを確認しました(ポート9 n_rxfrm実際のワイヤートラフィックからのインクリメント) まだ排除されていないこと/未解決の疑問: - MAC側とスイッチ側の両方で内部遅延ゼロ(rx/tx-internal-delay-ps=0、単に「rgmii」ではなく「rgmii-id」)の1000 Mbps RGMIIがボードトレース長による遅延なしに互換性があるかどうか — タイミングマージンテストとしてリンクを100 Mbpsに強制的に落とす試みはまだしていません 1. 1000 Mbps RGMII において、両端で rx/tx-internal-delay-ps=0 は正常に動作すると想定されますか？それとも、PCB が明示的に遅延を考慮していない限り、この組み合わせでは通常、遅延補償が必要になりますか？ 2. 他に何か設定漏れはありますか？ 必要であれば、完全なレジスタダンプを提供いたします。PE_02-13バスをロジックアナライザで探査する前に、何かアドバイスをいただけるとありがたいです(基板レイアウトのためプローブへのアクセスが限られているため、現状はあまり便利ではありません)。 ありがとう。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 @Joey_z さん、@db16122 さん。回路図の関連部分をここに添付します。接続の流れは以下のとおりです。 PFE_MAC1には、s32g3_pfe_mac1_connections.pngに示されているS32G3チップ上のPE_02からPE_13を使用します。基板間コネクタ( Board_to_board_connectorに示されています)。png)を使い、これらの信号をスイッチを持つ別のボードにルーティングします。スイッチ接続は SJA1110_Aで示されています。png および SJA1110_B.png。 接続はPE_xxピン - >基板コネクタ - >スイッチ(SJA1110) ご質問があればお知らせください。同じ詳細でサポートチケット( #00990408)も提出しました。 Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 pcentauri92 ご返信よろしくお願いします。 貴社のETHに関する回路図、特にPFE_MCA1およびSJA1110セクションの回路図をご提供ください。 内部サポートシステムのケースを作成することもできます。情報の説明欄に、 @Joey さん、回路図の情報を提供してください。こちらのウェブサイトを参照してください： https://support.nxp.com BR ジョーイ Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 @Joey_z さん。 ご回答ありがとうございます。 ここで扱っているモジュールは、S32G399AチップとNXP SJA1110Aイーサネットスイッチを組み合わせたカスタム設計です。このデザインはS32G-VNP-RDB3の開発プラットフォームを基にしましたが、ベースデザインからかなりの変更を加えました。RGMIIを使用するPFE_MAC1は、そうした変更点の1つです。 また、PFE_MAC1モードとピン多重化を変更するdtsファイルのオーバーライドも添付します。 PFE_MAC1モードの設定： /* pfe_mdio1 is already disabled in the base config in s32gxxxa-rdb.dtsi */ &pfe_mdio1 { /* occupied by GMAC0 */ status = "disabled"; }; /* * pfe_netif1 = PFE_MAC1 — management port to Switch-A port 2. * Overrides the base "sgmii" stub in s32gxxxa-rdb.dtsi. * Plain "rgmii" (no -id/-txid) since both MAC and switch add zero delay. * No phy-handle: the link partner is the SJA1110A switch, described as a * fixed-link on switch port@2. MDIO is not needed for link management here. */ &pfe_netif1 { phy-mode = "rgmii"; status = "okay"; fixed-link { speed = <1000>; full-duplex; }; }; PFE_MAC1ピンマルチプレクサ: /* * PFE_MAC1 RGMII pinmux — management port to Switch-A. * * All RX pad SSS values confirmed from S32G3 IOMUX spreadsheet. * TX path: output pads only, no IMCR needed. * RX path: input pads + IMCR registers to route pads into PFE_MAC1. * * Note: PE_07 (TXD3) uses FUNC3, not FUNC2. Similarly PE_08 (RX_CLK) output uses FUNC3; its IMCR (CR#859) uses FUNC2. */ pfe1rgmii_pins: pfe1rgmii_pins { /* TX outputs: PE_02=TX_CLK, PE_03=TX_EN, PE_04=TXD0, PE_05=TXD1, PE_06=TXD2 PE_07 (TXD3) */ pfe1rgmii_grp0 { pinmux = , /* PE_02: PFE_MAC1_TX_CLK */ , /* PE_03: PFE_MAC1_TX_EN */ , /* PE_04: PFE_MAC1_TXD0 */ , /* PE_05: PFE_MAC1_TXD1 */ , /* PE_06: PFE_MAC1_TXD2 */ ; /* PE_07: PFE_MAC1_TXD3 */ output-enable; slew-rate = ; }; /* RX inputs — pads set to FUNC0 (input mode); routing into PFE_MAC1 is handled by the IMCR entries in pfe1rgmii_grp2 below. NXP input mux pattern: pad=FUNC0 + IMCR=FUNC2 */ pfe1rgmii_grp1 { pinmux = , /* PE_08: input */ , /* PE_09: input */ , /* PE_10: input */ , /* PE_11: input */ , /* PE_12: input */ ; /* PE_13: input */ input-enable; slew-rate = ; }; /* IMCR input mux — selects which pad drives each PFE_MAC1 RX signal. CR#866 routes PE_02 (TX_CLK pad) back into PFE_MAC1_TX_CLK_I; required even for RGMII TX because the MAC samples its own TX_CLK internally. All entries at FUNC2 per S32G3 IOMUX spreadsheet. */ pfe1rgmii_grp2 { pinmux = , /* CR#866: PFE_MAC1_TX_CLK_I ← PE_02 */ , /* CR#859: PFE_MAC1_RX_CLK_I ← PE_08 */ , /* CR#865: PFE_MAC1_RXDV_I ← PE_09 */ , /* CR#861: PFE_MAC1_RXD_I[0] ← PE_10 */ , /* CR#862: PFE_MAC1_RXD_I[1] ← PE_11 */ , /* CR#863: PFE_MAC1_RXD_I[2] ← PE_12 */ ; /* CR#864: PFE_MAC1_RXD_I[3] ← PE_13 */ }; }; 他に何か情報が必要な場合はお知らせください。   Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction PFE_MAC1とSJA1110ポート2間のRGMIIバスに関するハードウェア側の回路図を共有していただけませんか？ Re: Custom S32G399A board: No frames cross switch-facing RGMII bus in either direction こんにちは、 pcentauri92 詳細な情報を提供していただきありがとうございます。 私の理解では、開発ボード上でRGMAIIとポート2を使うPFE_MAC1通信に問題があるようですSJA1110A。それは正しいですか？ S32G-VNP-RDB3のデフォルト構成は、PFE_MAC0/1がSGMIIモードで動作し、SJA1110にコネクテッドです。開発ボードでRGMIIモードを使うことを考えたのはなぜですか?対応するソフトウェア構成を変更することが推奨されます。 BR ジョーイ

MC33774 Daisy Chain Dual Loop Connection HI. 我当前使用MC33665A+MC33774的AFE采样系统组成双链回环的结构，配置MC33665A的PORT0和PORT1分别为MADD0和MADD1，当前发送所有指令均由MADD0发送。当我只连接PORT0到DC1之间的菊花链时，我的通讯都是正常的，但是当我把PORT1和DC2之间的菊花链也连接后，我再去请求33774发现33774无法回复响应帧，这是为什么？我回读确认过33665的PORT端口配置没有错误，并且将33774中的SYS_TPL_CFG.RESPCFG设置为00 SAME模式。 I am currently using an AFE sampling system consisting of the MC33665A + MC33774 in a dual-ring loop configuration. I have configured PORT0 and PORT1 of the MC33665A as MADD0 and MADD1, respectively, and all commands are currently sent through MADD0. When I connect only the daisy chain between PORT0 and DC1, communication works correctly. However, after I also connect the daisy chain between PORT1 and DC2, the MC33774 no longer responds when I send requests to it. Why does this happen? I have read back and verified that the MC33665 PORT configuration is correct, and I have configured SYS_TPL_CFG.RESPCFG = 00 (SAME mode) in the MC33774. Re: MC33774 Daisy Chain Dual Loop Connection HI. 1.我想知道从MADD=1的位置反向分配DADD是必须的吗？ 2.我当前的SYS_PORT0_CFG配置为TIMEOUT=0,CADD=1,MADD=0,PROTOCOL=1,ALLCHAINS=1,TERM=1,RX=1,EN=1 SYS_PORT1_CFG配置为TIMEOUT=0,CADD=1,MADD=1,PROTOCOL=1,ALLCHAINS=1,TERM=1,RX=1,EN=1 Re: MC33774 Daisy Chain Dual Loop Connection 你好， 根据 AN13910 TPL 环回建议，当两个 MC33665A TPL 端口连接成环回环时，存在一些配置要求，可能会导致您看到的行为。 对于环回配置： 我们建议从环的一侧按升序分配设备地址 (DADD)，从环回侧按相反的顺序分配设备地址 (DADD)（我在你的图片中没有看到这一点）。 如果两个端口连接为环回，则其中一个端口应设置 SYS_PORTx_CFG[RX] = 0，以避免重复数据进入 MC33665 缓冲区。 此外，其中一个端口的 SYS_PORTx_CFG[ALLCHAINS] 应为 0。文档指出，如果两个环回端口都接受 ALLCHAINS 命令，则可能导致信号冲突和通信错误。 请问能否提供 SYS_PORT0_CFG 和 SYS_PORT1_CFG 的值（特别是 EN、RX、ALLCHAINS、MADD 和 CADD）？这将有助于确定环回端口是否按照 AN13910 建议进行配置。

「内部フラッシュメモリ領域」設定を上書きするDebug Flashスクリプト こんにちは、 現在、FRDM-S32K344上でApp1からApp2へのアプリケーションジャンプをテスト中です。 私たちのアプリケーションレイアウトは以下の通りです: アプリ1の開始アドレス: 0x00400000 アプリ2の開始アドレス: 0x00500000 デバッグには、フラッシュメモリ保護を有効にした個別のデバッグ構成を使用しています。 App1のデバッグ時、メモリ保護範囲は次のように設定されます。 0x00500000～0x005FFFFF（App2を保護するため） App2のデバッグ時、メモリ保護範囲は次のように設定されます。 0x00400000～0x004FFFFF（App1を保護するため） しかし、デバッグ構成によるプログラミング中に、メモリ保護範囲が設定されているにもかかわらず、保護対象のフラッシュ領域が消去されていることが確認されました。 どなたか次の点をCANしてもらえますか? フラッシュプログラマは、消去／書き込み操作中に、設定されたメモリ保護範囲を尊重することが求められますか？ 保護されたフラッシュ領域が消去されないようにするために、追加の設定が必要ですか？ FRDM-S32K344上で1つのアプリケーションだけをプログラムしながら、メモリ保護を使って別のアプリケーションを保存することに成功した方はいらっしゃいますか? ログファイルとLDファイルを参考資料として添付しました。 私たちは搭載のPEデバッガを使用しています 何かご助言やご提案があれば、大変ありがたく思います。 よろしくお願いします。 Re: Debug Flash Script Overriding "Protect Internal Flash Memory Area" Settings こんにちは、@Avinpat123さん 同じバージョンのS32 Design Studioで動作しているか素早くテストしました。私も同じ設定を使いました。1つのアプリケーションは0x50_0000領域が保持されるように設定されている間に強制的に0x40_0000し、もう1つのアプリケーションは0x50_0000を強制され、0x40_0000領域は保存されるように設定されています: この設定が考慮されていることを示すログを以下に示します。 メモリを見ると、内容が本当に保存されているのがわかり、SO、期待通りに動作します。 スクリーンショットを確認したところ、アドレス範囲は設定されているようですが、「この範囲を保持する」チェックボックスが有効になっていません。問題はそこではないでしょうか？ よろしくお願いいたします。 ルーカス

MC33774 Daisy Chain Dual Loop Connection HI. I'm currently using an AFE sampling system with MC33665A and MC33774 to form a double-chain loopback structure. The MC33665A's PORT0 and PORT1 are configured as MADD0 and MADD1 respectively, and all commands are currently sent via MADD0. When I only connect the daisy chain between PORT0 and DC1, my communication is normal. However, when I also connect the daisy chain between PORT1 and DC2, I find that the 33774 cannot reply with a response frame. Why is this? I have confirmed that the PORT configuration of the 33665 is correct and that SYS_TPL_CFG.RESPCFG in the 33774 is set to 00 SAME mode. I am currently using an AFE sampling system consisting of the MC33665A + MC33774 in a dual-ring loop configuration. I have configured PORT0 and PORT1 of the MC33665A as MADD0 and MADD1, respectively, and all commands are currently sent through MADD0. When I connect only the daisy chain between PORT0 and DC1, communication works correctly. However, after I also connect the daisy chain between PORT1 and DC2, the MC33774 no longer responds when I send requests to it. Why does this happen? I have read back and verified that the MC33665 PORT configuration is correct, and I have configured SYS_TPL_CFG.RESPCFG = 00 (SAME mode) in the MC33774. Re: MC33774 Daisy Chain Dual Loop Connection HI. 1. I want to know if it is necessary to reverse the allocation of DADD from the position where MADD=1? 2. My current SYS_PORT0_CFG configuration is TIMEOUT=0, CADD=1, MADD=0, PROTOCOL=1, ALLCHAINS=1, TERM=1, RX=1, EN=1 SYS_PORT1_CFG is configured with TIMEOUT=0, CADD=1, MADD=1, PROTOCOL=1, ALLCHAINS=1, TERM=1, RX=1, EN=1 Re: MC33774 Daisy Chain Dual Loop Connection Hello, According to the AN13910 TPL Loopback Recommendation, when two MC33665A TPL ports are connected as a loopback ring, there are several configuration requirements that may cause the behavior you are seeing. For a loopback configuration: We recommend assigning device addresses (DADD) in ascending order from one side of the ring and in reverse order from the loopback side (I do not see this in your image). If two ports are connected as loopback, one of the ports should have SYS_PORTx_CFG[RX] = 0 to avoid duplicate data entering the MC33665 buffer. In addition, one of the ports should have SYS_PORTx_CFG[ALLCHAINS] = 0. If both loopback ports accept ALLCHAINS commands, document states that this can cause signal conflicts and communication errors. Could you please share the values of SYS_PORT0_CFG and SYS_PORT1_CFG (especially EN, RX, ALLCHAINS, MADD, and CADD)? That would help determine whether the loopback ports are configured according to the AN13910 recommendations.

S32K3 ADC 使用外部通道 你好。恩智浦团队 如何使用S32K3 ADC的外部通道 . Re: S32K3 ADC Use of external channels 嗨@VaneB 我还有后续问题。 如果我的设计没有多路复用器，但我只想使用例如 ADC1_X[0] 连接传感器 1，ADC1_X[1] 连接传感器 2，ADC1_X[2] 连接传感器 3，我可以将 MA 引脚重复使用于其他用途吗，例如用作 GPIO 输出引脚来驱动 LED？ 我的设计基于s32k344 Re: S32K3 ADC Use of external channels NPX团队，您好！ 关于这个话题，请问是否可以实现如下图所示的SCH？ 非常感谢您的支持。 Re: S32K3 ADC Use of external channels @VaneB 非常感谢您的帮助。 Re: S32K3 ADC Use of external channels 嗨@Niuyanlin 每个 ADC 提供 3 个外部解码信号 (MA)，用于从外部模拟多路复用器的 8 个通道中选择 1 个通道，最多可以有 4 个这样的多路复用器来连接 32 个外部通道，这意味着这 4 个多路复用器共享相同的 MA 信号。 ADC 根据当前选择的转换通道，自动设置 MA 来控制这些外部模拟多路复用器。根据掩码寄存器位，对相应的“X”引脚进行采样，并将结果存储在“MA”和“X”组合的匹配位置中。 由于我们的开发板上没有设计外部模拟多路复用器，因此没有实现这样的示例。 Re: S32K3 ADC Use of external channels 你好。VaneB 根据您的提示，我找不到在RTD中使用外部通道ADC的例子。如果你有相应的日常安排，希望你能发给我。非常感谢。 Re: S32K3 ADC Use of external channels 嗨@Niuyanlin 您可以在 RTD 中找到一些可能对您有用的 ADC 实现示例。 BR VaneB

S32K3 ADC Use of external channels Hello.  NXP Team How to use the external channel of S32K3 ADC . Re: S32K3 ADC Use of external channels Hi @VaneB I have a followup to this. If my design DOES NOT have a MUX but I want to use only for example ADC1_X[0] to sensor1, ADC1_X[1] to sensor2 and ADC1_X[2] sensor 3, can i reuse the MA pins for other purpose like GPIO output pins to drive an LED? My design is based on s32k344 Re: S32K3 ADC Use of external channels Hi NPX Team,  Related with this topic, may you please confirm if  is it possible to implement a SCH like the following diagram? Many thanks for your support. Re: S32K3 ADC Use of external channels @VaneB  Thank you very much for your help. Re: S32K3 ADC Use of external channels Hi @Niuyanlin  Each ADC provides 3 external decode signals (MA) to be used to select 1 channel out of 8 in the external analog multiplexers, and there can be maximum 4 of such multiplexers to connect 32 external channels, it means that these 4 multiplexers sharing the same MA signals. The ADC automatically sets the MA to control these external analog multiplexers, based on the current channel selected for conversion. Depending on the Mask Register bits, the corresponding “X” pin is sampled, and the result is stored in the matching location for the “MA” & “X” combination. Since no external analog multiplexers have been designed on our development board, such an example has not been implemented. Re: S32K3 ADC Use of external channels hello.VaneB According to your prompt, I can't find an example of using external channel ADC in RTD. If you have a corresponding routine, I hope you can send it to me. Thank you very much. Re: S32K3 ADC Use of external channels Hi @Niuyanlin  You can find examples of ADC implementation that may be useful to you in the RTD. B.R. VaneB

PN7220 Android 16 Porting to i.MX95 FRDM EVK Board Introduction Many customers are using PN7220 + Android 16 recently. In this document, I will show you how to porting the PN7220 to Android 16. I use the i.MX95 FRDM board as a reference target board. NOTE :  All the modifications are just for reference. They are NOT a NXP official patches for the newer release of AOSP porting. So the modifications may not be the best solution. Customer please base on their needs to modify the AOSP source code. This is not for production. Customer still need to perform full testing after the porting.  Hardware boards: i.MX95 FRDM Board (FRDM i.MX 95 Development Board | NXP Semiconductors) PN7220 EVK -- PNEV7220BP1 (PNEV7220BP1 Development Board for PN7220 NFC Controller | NXP Semiconductors) There is a 40pins connector on both PN7220 EVK and i.MX95 FRDM board. So PN7220 + i.MX95 FRDM connecting together is like this: Build the Android BSP for i.MX95 FRDM board: The i.MX Android BSP that I used is Android 16.0.0_1.4.0 (L6.12.49_2.2.0 BSP). It could be downloaded from here: Android OS for i.MX Applications Processors | NXP Semiconductors 1. Download the "Documentation" and the "Install Source Package".  2. Follow the steps in Android User's Guide to build the Android BSP for "evk_95" first.  $ export MY_ANDROID=`pwd` $ source build/envsetup.sh $ lunch evk_95-nxp_stable-userdebug $ export TARGET_RELEASE=nxp_stable $ build_build_var_cache $ ./imx-make.sh -j4 2>&1 | tee build-log.txt According to the android_build/.repo/manifests/aosp-android-16.0.0_1.4.0.xml, you will see the AOSP version is android-16.0.0_r4. According to the PN7220 Android 16 porting guide (PN7160/PN7220 – Android 16 porting guide), the patches is for AOSP release android-16.0.0_r2. So fortunately, the AOSP release version between them is not big different.  Now, we start the porting: 1. Kernel Driver To establish connection with the PN7220, the Android stack uses the nxpnfc kernel driver.  You could download the driver from github below: nfcandroid_platform_drivers/drivers at br_ar_16_comm_infra_dev · nxp-nfc-infra/nfcandroid_platform_drivers · GitHub The command is : git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_drivers.git" -b br_ar_16_comm_infra_dev There is driver for Kernel 6.6 and 6.12. So, please download the correct one for your porting. For example, the kernel in i.MX Android BSP Android 16.0.0_1.4.0 is 6.12. So I will use the 6.12 driver for my porting. In your porting, make sure the PATH in Makefile and Kconfig files are setting properly.  For example in my porting: android_build/vendor/nxp-opensource/kernel_imx/drivers/nfc/pn7220$ tree . ├── common.c ├── common.h ├── i2c_drv.c ├── i2c_drv.h ├── Kbuild ├── Kconfig └── Makefile 0 directories, 7 files For simplifying everything, we will only add a support for I2C and not SPI. Replace drivers/nfc/pn7220/Makefile default code with following code (for easier understanding) nxpnfc-i2c-objs = i2c_drv.o common.o obj-$(CONFIG_NXP_NFC_I2C) += nxpnfc_i2c.o The contents of drivers/nfc/Makefile. Add the PN7220 like below: # SPDX-License-Identifier: GPL-2.0 # # Makefile for nfc devices # obj-$(CONFIG_NXP_NFC_I2C) += pn7220/ obj-$(CONFIG_NFC_FDP) += fdp/ obj-$(CONFIG_NFC_PN544) += pn544/ obj-$(CONFIG_NFC_MICROREAD) += microread/ obj-$(CONFIG_NFC_PN533) += pn533/ obj-$(CONFIG_NFC_MEI_PHY) += mei_phy.o obj-$(CONFIG_NFC_SIM) += nfcsim.o obj-$(CONFIG_NFC_PORT100) += port100.o obj-$(CONFIG_NFC_MRVL) += nfcmrvl/ obj-$(CONFIG_NFC_TRF7970A) += trf7970a.o obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/ obj-$(CONFIG_NFC_ST_NCI) += st-nci/ obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci/ obj-$(CONFIG_NFC_S3FWRN5) += s3fwrn5/ obj-$(CONFIG_NFC_ST95HF) += st95hf/ obj-$(CONFIG_NFC_VIRTUAL_NCI) += virtual_ncidev.o The contents of drivers/nfc/Kconfig. Add the PN7220 like below: source "drivers/nfc/microread/Kconfig" source "drivers/nfc/nfcmrvl/Kconfig" source "drivers/nfc/st21nfca/Kconfig" source "drivers/nfc/st-nci/Kconfig" source "drivers/nfc/nxp-nci/Kconfig" source "drivers/nfc/s3fwrn5/Kconfig" source "drivers/nfc/st95hf/Kconfig" source "drivers/nfc/pn7220/Kconfig" endmenu 2. Adding the "nxpnfc" to the i.MX95 FRDM board device tree file android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts We need to check the connection between two boards and then to decide which pins to use in the device tree file. Here is the 40 pins connector on the PN7220: Here is the 40 pins connector on the i.MX95 FRDM board. According to the 40 pins connection between PN7220 EVK and the i.MX95 FRDM board, I decided to use the I2C6 and the GPIO2_20, GPIO2_21 and GPIO2_26. So, in the imx95-15x15-frdm.dts, I added: &lpi2c6 { clock-frequency = <400000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lpi2c6>; status = "okay"; nxpnfc@28{ compatible = "nxp,nxpnfc"; reg = <0x28>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_nfc>; nxp,nxpnfc-irq = <&gpio2 26 0>; nxp,nxpnfc-ven = <&gpio2 21 0>; nxp,nxpnfc-mode_sw = <&gpio2 20 0>; }; }; And the IOMUX settings in the imx95-15x15-frdm.dts. pinctrl_nfc: nfcgrp { fsl,pins = < IMX95_PAD_GPIO_IO26__GPIO2_IO_BIT26 0x39e // IRQ IMX95_PAD_GPIO_IO21__GPIO2_IO_BIT21 0x39e // VEN IMX95_PAD_GPIO_IO20__GPIO2_IO_BIT20 0x39e // MODE_SW >; }; pinctrl_lpi2c6: lpi2c6grp { fsl,pins = < IMX95_PAD_GPIO_IO02__LPI2C6_SDA 0x40000b9e IMX95_PAD_GPIO_IO03__LPI2C6_SCL 0x40000b9e >; }; 3. Modify the imx95_gki.fragment File:  android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/configs/imx95_gki.fragment Add the "CONFIG_NXP_NFC_I2C=m" into the imx95_gki.fragment 4. Add the settings in your corresponding board configuration files in Android - Go to the android_build/device/nxp/imx9/evk_95/  - Modify the BoardConfig.mk. # Add KVM support BOARD_BOOTCONFIG += androidboot.hypervisor.vm.supported=true + # ---- selinux permissive ---- + BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive # -------@block_sepolicy------- BOARD_SEPOLICY_DIRS := \ $(CONFIG_REPO_PATH)/imx9/sepolicy \ $(IMX_DEVICE_PATH)/sepolicy \ + vendor/nxp/nfc/sepolicy \ + vendor/nxp/nfc/sepolicy/nfc +include vendor/nxp/nfc/BoardConfigNfc.mk  - Add the "nxpnfc_i2c.ko" to the ShareBoardConfig.mk. Make sure the path and the filename are correct. ifeq ($(LOADABLE_KERNEL_MODULE),true) IMX_ANDROID_FIRST_STAGE_MODULES += \ $(KERNEL_OUT)/drivers/hwmon/hwmon.ko \ $(KERNEL_OUT)/drivers/hwmon/scmi-hwmon.ko \ .... .... .... $(KERNEL_OUT)/drivers/soc/imx/soc-imx9.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-adp5585.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-pca953x.ko \ $(KERNEL_OUT)/drivers/gpio/gpio-vf610.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7220/nxpnfc_i2c.ko .... .... BOARD_VENDOR_KERNEL_MODULES += \ $(KERNEL_OUT)/drivers/media/i2c/ap1302.ko \ $(KERNEL_OUT)/drivers/media/i2c/ox03c10.ko \ $(KERNEL_OUT)/drivers/media/i2c/max96717_lib.ko \ .... .... $(KERNEL_OUT)/drivers/net/ethernet/freescale/enetc/fsl-enetc-vf.ko \ $(KERNEL_OUT)/drivers/net/ethernet/freescale/enetc/fsl-enetc4.ko \ $(KERNEL_OUT)/drivers/net/phy/realtek.ko \ $(KERNEL_OUT)/drivers/hwmon/pwm-fan.ko \ + $(KERNEL_OUT)/drivers/nfc/pn7220/nxpnfc_i2c.ko - Add the following to the compatibility_matrix.xml netutils-wrapper 1.0 android.hardware.emvco 1 IEmvco default - Add the INxpNfc and IEmvco to the device_framework_matrix.xml nxp.hardware.secureime 1 ISecureIME default nxp.hardware.ele 1 ISecureEnclave default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default vendor.nxp.nxpnfc_aidl 2 INxpNfc default android.hardware.emvco 1 IEmvco default  - Add the following to the evk_95.mk # ------nfc------- $(call inherit-product, vendor/nxp/nfc/device-nfc.mk) $(call inherit-product, vendor/nxp/emvco/device-emvco.mk) PRODUCT_PACKAGES += \ android.hardware.nfc2-service.nxp PRODUCT_PACKAGES += \ com.nxp.emvco \ com.nxp.nfc \ nfc_nci_nxp_pn72xx - Add the nxpnfc_i2c in init.rc exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \ /vendor/lib/modules nxpnfc_i2c write /sys/power/wake_lock nosleep - Add nxpnfc to ueventd.nxp.rc /dev/ttymxc1 0666 nfc nfc /dev/ttymxc2 0666 nfc nfc /dev/nxpnfc 0666 nfc nfc 5. Apply the NXP AOSP patches I write a script to download the patches from the github. The script file and the android_build folder is on the same directory. Run the AOSP_adaptation.sh.  AOSP_adaptation.sh # nfcandroid_nfc_modules git clone "https://github.com/nxp-nfc-infra/nfcandroid_modules_nfc.git" cd nfcandroid_modules_nfc git checkout br_ar_16_comm_infra_dev cp -rf * ../android_build/packages/modules/Nfc cd .. # nfcandroid_nfc_hidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_nfc_hidlimpl.git" cd nfcandroid_nfc_hidlimpl git checkout br_ar_16_comm_infra_dev cp -rf * ../android_build/hardware/nxp/nfc cd .. # nfcandroid_frameworks git clone "https://github.com/nxp-nfc-infra/nfcandroid_frameworks.git" cd nfcandroid_frameworks git checkout br_ar_16_comm_infra_dev mkdir ../android_build/packages/modules/Nfc/framework cp -rf * ../android_build/packages/modules/Nfc/framework cd .. # nfcandroid_emvco_aidlimpl git clone "https://github.com/nxp-nfc-infra/nfcandroid_emvco_aidlimpl.git" cd nfcandroid_emvco_aidlimpl git checkout br_ar_16_comm_infra_dev mkdir ../android_build/hardware/nxp/emvco cp -rf * ../android_build/hardware/nxp/emvco cd .. # nfcandroid_platform_reference git clone "https://github.com/nxp-nfc-infra/nfcandroid_platform_reference.git" cd nfcandroid_platform_reference git checkout br_ar_16_comm_infra_dev cp -rf vendor/nxp/* ../android_build/vendor/nxp/ cd .. Apply a patch. $ cd android_build/system/logging $ patch -p1 < ../../../nfcandroid_platform_reference/build_cfg/build_pf_patches/AROOT_system_logging.patch Add TDA Test support: # Clone repositories for test applications and TDA support # nfcandroid_infra_test_apps git clone https://github.com/nxp-nfc-infra/nfcandroid_infra_test_apps.git cd nfcandroid_infra_test_apps/ git checkout br_ar_16_comm_infra_dev cd test_apps/ cp -rf SMCU_Switch/ ../../android_build/packages/apps/ cp -rf EMVCoModeSwitchApp/ ../../android_build/packages/apps/ cd ../.. # nfcandroid_infra_comm_libs git clone "https://github.com/nxp-nfc-infra/nfcandroid_infra_comm_libs.git" cd nfcandroid_infra_comm_libs git checkout br_ar_16_comm_infra_dev cp -rf nfc_tda/ ../android_build/packages/modules/Nfc/libnfc-nci/ cp -rf emvco_tda/ emvco_tda_test/ ../android_build/hardware/nxp/emvco/ cp -rf NfcTdaTestApp/ ../android_build/packages/apps/ cd .. 6. Put changes into hardwatre/interfaces/compatibility_matrices  File: hardware/interfaces/compatibility_matrices/compatibility_matrix.202504.xml android.hardware.audio.effect 1-3 IFactory default nxp.hardware.imx_dek_extractor 1 IDek_Extractor default nxp.hardware.ele 1 ISecureEnclave default vendor.nxp.nxpnfc_aidl 2 INxpNfc default vendor.nxp.emvco 1 INxpEmvco default android.hardware.authsecret 1 IAuthSecret default 7. Add the firmware $ git clone https://github.com/NXP/nfc-NXPNFCC_FW.git $ cp -r nfc-NXPNFCC_FW/InfraFW/pn7220/64-bit-2.5/pn7220_64bits.so android_build/vendor/nxp/pn7220/firmware/lib64/libpn72xx_fw.so 8. Add the NXPAndroidDTA $git clone https://github.com/NXPNFCProject/NXPAndroidDTA.git $cd NXPAndroidDTA $git checkout br_ar_new_dta_arch cp -r NXPAndroidDTA android_build/vendor/nxp/ 9. Some fixes before build: $ cd android_build $ mv hardware/nxp/nfc/snxxx/Android.bp hardware/nxp/nfc/snxxx/_Android.bp $ mv hardware/nxp/nfc/snxxx/halimpl/power-tracker/Android.bp hardware/nxp/nfc/snxxx/halimpl/power-tracker/_Android.bp $ mv hardware/nxp/secure_element/snxxx/aidl/Android.bp hardware/nxp/secure_element/snxxx/aidl/_Android.bp $ cd hardware/nxp/nfc $ rm pn8x -rf Now, build the Android BSP again. Use "mm" to build the Android source code. After fixed all the errors of the AOSP build, use "imx-make.sh" to build the whole i.MX Android image.  When building the Android, there may have some errors during the build. I listed some errors and the workaround below for your reference. Error: error: packages/modules/Nfc/tests/cts/tests/Android.bp:20:1: "CtsNfcTestCases" depends on undefined module "CtsAppTestStubsShared". Workaround : Comment out "CtsAppTestStubsShared" in packages/modules/Nfc/tests/cts/tests/Android.bp Error: error: hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/Android.bp:17:1: "power_tracker_v2" depends on undefined module "nfc_nci_nxp_snxxx_headers_v2". Workaround: mv hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/Android.bp hardware/nxp/nfc/snxxx/halimpl_v2/power-tracker/_Android.bp Error: error: platform_testing/Android.bp:255:1: module "continuous_native_tests" variant "android_common": depends on //packages/modules/Nfc/NfcNci/nci/jni:libnfc-nci-jni-tests which is not visible to this module You may need to add "//platform_testing" to its visibility error: platform_testing/Android.bp:255:1: module "continuous_native_tests" variant "android_common": depends on //packages/modules/Nfc/libnfc-nci/tests:libnfc-nci-tests which is not visible to this module You may need to add "//platform_testing" to its visibility Workaround: nano packages/modules/Nfc/NfcNci/nci/jni/Android.bp In cc_test {     name: "libnfc-nci-jni-tests", .. ..     visibility: [         "//platform_testing:__subpackages__",     ], Same in packages/modules/Nfc/libnfc-nci/tests/Android.bp Error: FAILED: out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system-stubs.srcjar out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_annotations.zip out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_api.txt out/soong/.intermediates/packages/modules/Nfc/framework/framework-nfc.stubs.source.system/android_common/exportable/framework-nfc.stubs.source.system_removed.txt out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:52: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.emulateNfcTechnologyATag(boolean,byte,byte,byte,byte[],byte,byte[]) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:64: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.overwriteRoutingTable(int,int,int,int,int) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:77: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_FAILED_INTERNAL [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:78: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_FAILED_NFC_NOT_ENABLED [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:79: error: Binary breaking change: Removed field android.nfc.NfcOemExtension.EMULATE_NFC_A_TAG_STATUS_OK [RemovedField] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:120: error: Binary breaking change: Removed method android.nfc.NfcOemExtension.Callback.onRoutingChangeCompleted() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest:160: error: Binary breaking change: Removed method android.nfc.RoutingStatus.getDefaultFelicaRoute() [RemovedMethod] Aborting: Found compatibility problems checking the public API (/home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/d1717a17fe92a8b2da806db0f1cb87830019487b/packages/modules/Nfc/framework/java) against the API in /home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/d1717a17fe92a8b2da806db0f1cb87830019487b/./out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest exit status 255 Workaround: Comment out the lines 52,64,77,78,79,120,160 in out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.system.latest/gen/framework-nfc.api.system.latest Error: out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:77: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isExitFramesSupported() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:80: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isPowerSavingModeEnabled() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:81: error: Binary breaking change: Removed method android.nfc.NfcAdapter.isPowerSavingModeSupported() [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:91: error: Binary breaking change: Removed method android.nfc.NfcAdapter.setPowerSavingMode(boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:196: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.getPollingLoopFiltersForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:197: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.getPollingLoopPatternFiltersForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:202: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.isDeviceScreenOnRequiredForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:203: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.isDeviceUnlockRequiredForService(android.content.ComponentName) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:214: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.setRequireDeviceScreenOnForService(android.content.ComponentName,boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:215: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.setRequireDeviceUnlockForService(android.content.ComponentName,boolean) [RemovedMethod] out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest:248: error: Binary breaking change: Removed method android.nfc.cardemulation.CardEmulation.NfcEventCallback.onOffHostAidSelected(String,String) [RemovedMethod] Aborting: Found compatibility problems checking the public API (/home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/6245059c063e0ae76fa4356a9b840b923ddb8764/packages/modules/Nfc/framework/java) against the API in /home/nxa08017/android16_1.4.0/android_build/out/soong/.temp/sbox/6245059c063e0ae76fa4356a9b840b923ddb8764/./out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest exit status 255 Workaround: Same as the previous workaround. Comment out the lines (error) in out/soong/.intermediates/prebuilts/sdk/framework-nfc.api.public.latest/gen/framework-nfc.api.public.latest. Error: vendor/nxp/nfc/sepolicy/nfc/nfc.te:7:ERROR 'unknown type hal_emvco_service' at token ';' on line 24388: allow nfc hal_emvco_service:service_manager find; allow nfc nfc_vendor_data_file:file { create rename setattr unlink { { getattr open read ioctl lock map watch watch_reads } { open append write lock map } } }; checkpolicy:  error(s) encountered while parsing configuration Workaround: nano vendor/nxp/nfc/sepolicy/nfc/nfc.te # allow NFC process to call into the NFC HAL +type hal_emvco_service, hal_service_type, service_manager_type; +type hal_emvco_default, domain; allow nfc nfc_data_file:dir create_dir_perms; allow nfc nxpnfc_hwservice:hwservice_manager find; allow nfc nfc_vendor_data_file:dir { create_dir_perms add_name search read write create remove_name }; allow nfc nfc_vendor_data_file:file create_file_perms; allow nfc hal_emvco_service:service_manager find; allow nfc hal_emvco_default:binder call; allow nfc hal_emvco_default:binder transfer; allow nfc vendor_hal_nxpnfc_service:service_manager find; Error: FAILED: out/soong/.intermediates/hardware/nxp/nfc/intf/nxpnfc/aidl/vendor.nxp.nxpnfc_aidl_interface/checkhash_2.timestamp if [ $(cd 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2' && { find ./ -name "*.aidl" -print0 | LC_ALL=C sort -z | xargs -0 sha1sum && echo 1; } | sha1sum | cut -d " " -f 1) = $(tail -1 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2/.hash') ]; then touch out/soong/.intermediates/hardware/nxp/nfc/intf/nxpnfc/aidl/vendor.nxp.nxpnfc_aidl_interface/checkhash_2.timestamp; else cat 'system/tools/aidl/build/message_check_integrity.txt' && exit 1; fi ############################################################################### # ERROR: Modification detected of stable AIDL API file                        # ############################################################################### Above AIDL file(s) has changed, resulting in a different hash. Hash values may be checked at runtime to verify interface stability. If a device is shipped with this change by ignoring this message, it has a high risk of breaking later when a module using the interface is updated, e.g., Mainline modules. Workaround: echo $(cd 'hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2' && { find ./ -name "*.aidl" -print0 | LC_ALL=C sort -z | xargs -0 sha1sum && echo 1; } | sha1sum | cut -d " " -f 1) d9e99a62ff5ebed44083a79577ec7ed32d264775 Then,  nano hardware/nxp/nfc/intf/nxpnfc/aidl/aidl_api/vendor.nxp.nxpnfc_aidl/2/.hash replace the value to d9e99a62ff5ebed44083a79577ec7ed32d264775 A runtime error: Problem: You will find the following failed about the permission in the log. java.lang.IllegalStateException: Signature|privileged permissions not in privileged permission allowlist: {com.android.nfc (/apex/com.android.nfcservices/priv-app/[email protected]😞 android.permission.OBSERVE_ROLE_HOLDERS} Workaround: Add :                 To the file : out/target/product/evk_95/system/etc/permissions/privapp-permissions-platform.xml 10. Download the image to the target board: - We use the tool UUU to download the image to the i.MX boards. Download the UUU from here : Releases · nxp-imx/mfgtools - Download the Android 16 BSP i.MX95 EVK demo image from the Android i.MX BSP web page first. There are UUU script and necessary image files already in the demo image package.  - Put the UUU executable file into the demo image folder. uuu_imx_android_flash.bat is the script also in the same folder. - After your Android BSP building is completed and succeed, copy the images to the demo image folder. The image files are located in android_build/out/target/product/evk_95/. - Switch the boot mode to "Download" mode on the i.MX95 FRDM board. - Run the UUU script to download the images to the FRDM board. uuu_imx_android_flash.bat -f imx95 -a -e -u 15x15-frdm -d 15x15-frdm Run the "TagInfo" on the board: - Download the TagInfo apk file from the NXP TagInfo App web page . - Use the "adb install" command to install the TagInfo to the FRDM board. C:\>adb install com.nxp.taginfo-6.2.0-play-release-protected.apk * daemon not running; starting now at tcp:5037 * daemon started successfully Performing Streamed Install Success After TagInfo installed, the TagInfo icon will be available on the GUI. Run the TagInfo, and then put a card on the board. The information of the card will be show on the TagInfo App. Reference: PN7160/PN7220 – Android 16 porting guide PN7220 NFC Frontend IC with Integrated Power Management | NXP Semiconductors Android OS for i.MX Applications Processors | NXP Semiconductors nxp-nfc-infra · GitHub

Safety recommended Compiler setting violation Compiler settings, Assembler setting and the linker setting, recommended by the MCAL SIP provided by the NXP, is not following the safety compiler settings recommended by the Wind River. Need to have a discussion on the settings and check how to align with Wind River compilers safety recommendations. MCAL SIP package Info: -  ->SW32K3_S32M27x_RTD_R21-11_7.0.1_QLP02  ->SW32K3_RTD_R21-11_7.0.1_P05_D2604  ->SW32K3_SAF_1.0.6_D2512  ->SCST_M7_S32K3_RFP_1.0.7 Re: Safety recommended Compiler setting violation Hello, In case you need direct talk to application team please reach out to your assigned NXP representative FAE/Sales, they can setup direct support channel. In case you have any questions do not hesitate to ask. Best regards, Peter

JLinkデバッグ認証 皆さん、こんにちは。 私はMCXN947(frdm_mcxn947ボード)を基にしたプロジェクトを進めており、クライアントにテストのために送る前にデバッグ認証と署名済みファームウェア検証を設定する必要がありますが、2つの点について非常に迷っています。 デバッグ認証は「現場内」のCASEに限定されているのでしょうか?MCUが永久にロックされ、鍵やセキュリティ設定がOTPで焼き込まれている状態ですか?唯一持っているボードを永久に壊してしまうリスクは冒したくない デバッグ認証機能を設定した場合、搭載デバッガと接続してコードをデバッグすることは可能でしょうか?VS Code と Jlink デバッグ .launch を使用してデバッグしています設定、デバッグ認証を有効にするためのセキュリティアーティファクトを追加するにはどうすればいいですか? すでにこの問題に取り組んだ方が、今後の進め方について教えていただけるとありがたいです。なぜなら、私は言及されている AN14162だけで、それ以外のドキュメントはあまり見かけません MCX N セキュリティ（EdgeLock | セキュアブート | OTP） Re: JLink Debug Authentication こんにちは、 @raimbowgeddon さん。 1. デバッグ認証は「インフィールド」ケースに限定されるのか?MCUが永久にロックされ、鍵やセキュリティ設定がOTPで焼き込まれている状態ですか?唯一持っているボードを永久に壊してしまうリスクは冒したくない ->>いいえ、デバッグ認証は「ファイル内」ケースだけのものではありません。開発中にテストCAN。CMPA側で設定してください。OTP側ではありません。 2. デバッグ認証機能を設定した場合、搭載デバッガと接続してコードをデバッグすることは可能でしょうか?VS Code と Jlink デバッグ .launch を使用してデバッグしています設定、デバッグ認証を有効にするためのセキュリティアーティファクトを追加するにはどうすればいいですか? ->>はい。デバッグ認証が有効になった後は、通常は通常、以前のように通常のJ-Linkセッションを開始することはできません。まずデバッグ認証チャレンジ-レスポンスフローを実行し、その後デバッガを接続します。 MCXN947上でデバッグ認証の設定と使用手順を示す動画があります。アクセスCANかはわかりませんが: https://www.bilibili.com/video/BV13EhAzdEzV/?spm_id_from=333.1387.homepage.video_card.click よろしくお願いします。 BR アリス

MiFARE Plus APDU 您好， 我正在开发一个 Windows/Linux 应用程序，该应用程序使用 `winscard`/`pcsc-lite` 库和 HID Global OMNIKEY 5122 读卡器将数据编码到 MIFARE 卡上。我已经成功实现了对经典卡和Ultralight卡的支持，现在我需要添加对Plus卡的支持。 来自 `MF1P(H)x2.pdf`根据公开文档（见下方链接），我知道该卡支持许多原生命令，例如 `GetVersion` 和 `WritePerso`，而且，如果我对第 8.2.3 节的理解正确的话，这些命令可以封装在 APDU 中。那将是理想的，因为我就是这样处理其他卡的：我构建并发送 APDU。 我的问题如下： 1. 哪些文档描述了 MIFARE Plus 的本地命令及其参数？我需要这些信息才能正确地编写这些命令。 2. 据我了解，MIFARE Plus 需要基于 AES 的身份验证和加密才能向卡发送命令。哪份文件对此有详细描述？ 3. 是否有关于如何在 APDU 中封装本地命令的文档？ 4. `MF1P(H)x2.pdf` 包含许多链接，或者看起来像链接的文本，但它们是不可点击的。例如：`CommitReaderID`、`WritePerso`、`CommitPerso` 和 `虚拟卡架构`。我如何才能获取这些文件？是否有办法确定每个链接指向哪个文档？ 我签署了保密协议，并获得了访问我的 NXP 帐户安全部分的一些文件的权限，但这些文件都没有回答我的问题。 https://www.nxp.com/docs/en/data-sheet/MF1P(H)x2.pdf Re: MiFARE Plus APDUs 你好@Codringher 希望你一切都好。 支持 MIFARE Plus EV2 的资源受 NDA 保护，必须通过安全访问权限申请，请按照此页面上的说明进行操作：安全访问权限 | NXP 半导体 。另外，我建议您查看NXP 半导体的“安全访问权限常见问题解答” 。 请查收您的收件箱，我刚刚给您发送了一条社区私信。 问候， 爱德华多。