i.mx8mp GPU and GTK4 app: GUI/window present delay and blocking Vivante /dev/galcore ioctl GTK4 Window Startup Delay (~10s) on i.MX8MP with Vivante GPU When using the default GTK4 GL renderer: gtk_window_present(window);​ takes approximately 9-10 seconds before the window becomes visible. The evidence (see attached file) strongly suggests that the startup delay is not caused by GTK application code. The delay appears correlated with a blocking Vivante /dev/galcore ioctl within the GL rendering path. Software rendering (GSK_RENDERER=cairo) avoids the issue. We are looking for guidance on known issues, debugging methods, configuration changes, or fixes for GTK4/OpenGL startup latency on i.MX8MP with the Vivante GPU stack. Re: i.mx8mp GPU and GTK4 app: GUI/window present delay and blocking Vivante /dev/galcore ioctl Hi @jim777  Thank you for sharing such detailed information. Could you provide a minimal, reproducible GTK4 source code example? I need to conduct further testing in the NXP BSP. Best Regards, Zhiming Re: i.mx8mp GPU and GTK4 app: GUI/window present delay and blocking Vivante /dev/galcore ioctl Hi Zhiming, Thanks for your quick response! Attached is a small skeleton but complete source file to test. and the environment variables set before running: #!/bin/sh export XDG_RUNTIME_DIR=/run/user/0 export WAYLAND_DISPLAY=wayland-1 export GDK_BACKEND=wayland export GSK_RENDERER=gl  the relevant from weston.ini: root@nitrogen8mp:~# cat /etc/xdg/weston/weston.ini [core] #gbm-format=argb8888 use-g2d=true repaint-window=16 idle-time=0 xwayland=true #enable-overlay-view=1 [shell] panel-position=none [libinput] touchscreen_calibrator=true #[output] #name=HDMI-A-1 #mode=1920x1080@60 #transform=rotate-90 #[output] #name=HDMI-A-2 #mode=off # WIDTHxHEIGHT Resolution size width and height in pixels # off Disables the output # preferred Uses the preferred mode # current Uses the current crt controller mode #transform=rotate-90 [screen-share] command=/usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize #start-on-startup=true [input-method] path=/usr/libexec/ibus-wayland the running time for the gtk_window_present on a desktop w/o GPU support takes some hundreds msec (< 1sec); and on the i.mx8mp device takes 9970 ms : root@nitrogen8mp:~# gtk4-test A: activate: before _present: 47333 ms B: activate: after _present: 57303 ms, takes: 9970 ms C: activate: after idele_add: 57303 ms D: startup_task_cb: 57315 ms ^C root@nitrogen8mp:~# I have tried render: ngl, which leads to smear image/widgetrs/video, and Vulkan leads to critical errors: Loader Message: vkCreateDevice: Failed to validate extensions in list; Failed to realize renderer of type ‘GskVulkanRenderer’ for surface ‘GdkWaylandToplevel’: Could not find a Vulkan device with the required features. Since out app need GPU support, and the recommended renderer under wayland/weston is still gl (UG10159  11.3.2.1 GL renderer)   , I hope you can help to find a solution. Best regards, Re: i.mx8mp GPU and GTK4 app: GUI/window present delay and blocking Vivante /dev/galcore ioctl Hi @Zhiming_Liu  Besides what shared already, is there anything I can help to resolve the issue? If there is any way to make it work - significantly reduce the startup time, such as configuration changes, env variable settings, different versions, or fixes/patches to the GPU driver, please let me know. Thanks,

driver documentation missing header information I am developing a project for a S32K116 inside S32DS. By now I figured out how the RTD works regarding to IP Drivers vs MCAL/AUTOSAR. I will limit my project to the IP Drivers for now due to possible resource constraints. I also figured out that I can find documentation about an IP Driver component by rightclicking on it inside the Components view.  However, I found that it is not listed inside the documentation which headers to include for each driver when using one of the described functions. How am I supposed to know that information? Is there a different document or list where this is specified? Re: driver documentation missing header information Hello  USually, the top-level public header for each IP driver follows the naming convention _Ip.h (e.g. Flexcan_Ip.h, Lpspi_Ip.h, Clock_Ip.h, Adc_Sar_Ip.h). That header is what you include in your source application code. You can also look at the examples provided inside the RTD for which header files to include: Julin_AragnM_1-1789513358457.pngJulin_AragnM_1-1789513358457.png FlexCAN -> FlexCAN_Ip.h Platform/Interrupt Controller -> IntCtrl_Ip.h Port/Siul2 -> Siul2_Port_Ip.h Dio/Siul2 -> Siul2_Dio_Ip.h You can look for these header files inside the RTD installation path: "C:\NXP\S32DS.3.x.x\S32DS\software\PlatformSDK_S32K1_S32M24\RTD\ _TS_...\include\" Best regards, Julián

KE18F512VLH16 ECC RAM シングルビット訂正 先日@sean_dvorscakさんが投稿された記事（ KE1 ECC RAM シングルビット訂正）に関連して、追加の質問があります。 @Celeste_Liuは答えた。 ->> オプションのスクラブを実装する場合は、アクセスを実際のアクセスサイズやスクラブの粒度に基づいてアライメントし、生の MCM_LMFAR 値に盲目的に合わせないでください。また、アドレスを適切にアラインメントし、アクセスサイズが有効であることを確認しない限り、固定4バイトのアクセスは使わないでください。 MCM_LMFATR[PEFSIZE]を使ってアクセスサイズを判定できますか?もしそうなら、これをMCM_LMFARと組み合わせて読み取り・正解・書き込み操作を実装することは可能でしょうか?例えば、MCM_LMFATR[PEFSIZE]が3'b000で8ビットアクセスを示している場合、MCM_LMFARで示されたアドレスから8ビットの読み込みを行い、同じアドレスに8ビットの書き込みをして誤りを訂正することは可能でしょうか?同様に、MCM_LMFATR[PEFSIZE]が3'b010で32ビットアクセスを示している場合、アライメントを気にせずにMCM_LMFARで示されたアドレスに32ビット書き込みを行うことはできますか? Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 あなたの投稿を拝見しました。この件について少し調査させてください。詳しい情報が分かり次第、改めてご連絡いたします。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは@Celeste_Liu - P7は最終アプリケーションの名前です。 Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、@rseigle77 さん。 ご質問につきましては、社内の担当チームに調査を依頼する必要があります。当社の手続きに従い、 最終的な申請 名を記載してください。 ご協力ありがとうございました。 BR セレステ Re: KE18F512VLH16 ECC RAM Single Bit Correction こんにちは、 @Celeste_Liu さん、この件について何か進展はありますか？

MPC5775B – アプリケーションからRAppIDへのブートローダー移行 こんにちは、NXPチームの皆さん。私はCANフラッシングに RAppIDブートローダーを組み合わせたCAN フラッシングをMPC5775Bしています。 RAppID FBLのソースコードは持っていないので、既存のFBLを修正することはできません。 実行中のアプリケーションが既存のRAppID FBLにプログラミングモードに入るよう要求するサポートされたメカニズムはありますか? もしそうなら、MPC5775Bに必要なアプリケーション→FBLエントリシーケンスは何ですか? これには特定のリセットや起動機構が必要なのでしょうか、それともRAppIDはアプリケーションからFBLを要求する別の方法を提供しているのでしょうか? Re: MPC5775B – Application to RAppID Bootloader transition こんにちは、 RAppID FBLには、実行中のアプリケーションがプログラム的にFBLエントリを要求するための組み込みかつ文書化されたAPIはありません。MPC57xx用のRAppIDブートローダーは、クローズドバイナリでフラッシュ常駐ブートローダー(事前コンパイル済みの.rbfとして配布)ですソースコードが提供されておらず、変更も不可能なファイル） これをトリガーする標準的なメカニズムは、アプリケーションからのランタイム呼び出しではなく、リセット+ブートタイムフラグチェックです。 よろしくお願いいたします。 ピーター Re: MPC5775B – Application to RAppID Bootloader transition ありがとう、ピーター。リセット処理に続いて起動時のフラグチェックが行われる仕組みだと理解しました。RAppID FBLのソースコードがない場合は、MPC5775BチェックのRAppID FBLにどのようなブートタイムフラグや条件があるのか、またアプリケーションがリセット前にどのように設定・要求できるのか、説明していただけますか? これは特定のRAMアドレス/マジック値、リセット原因条件、設定フィールド、または別のメカニズムでしょうか？もしこのフラグを設定するためのアプリケーション側の手順やドキュメントがあれば、ぜひ教えていただけませんか?

Some suggestions for Gui-guider 2.0 I hope Gui-guider 2.0 will add an option in the settings to control whether timestamps in the generated files are enabled or disabled. Then each generated page (screen) will have a corresponding gg_event_screen.c file, even if my page does not register any events. We want to prevent any event content from being generated when no events are registered. Additionally, I would like a mechanism to selectively include some images or resources that are not currently displayed in the project. Although it is possible to include images and fonts from the ghost page into the project, it is not very elegant. Regarding fonts, there is currently a setting in the settings to control the default generation range of all fonts. Hopefully, in the future, we can control the generation range of all fonts. Acknowledgments 回复： Gui-guider 2.0的一些建议 Hi @Xu_556678 , Thank you very much for your feedback. These suggestions are invaluable to us, and we will consider making corresponding optimizations and improvements in future releases. We hope the GUI Guider will be helpful to your work. Please feel free to provide any feedback or suggestions you may have in the future. Best Regards, Wenbin Re: Gui-guider 2.0的一些建议 Hi @Xu_556678, I would like to add an input about a workaround regarding some of your requests, specifically regarding the generation of images and fonts. While adding them to a ghost page technically works to enable GUI Guider to automatically generate the images and fonts, you can also add them to the "resource" panel, and click convert: EdwinHz_1-1789494348483.pngEdwinHz_1-1789494348483.png This Image Converter feature allows you to generate an output file for any supported images. The default path is set to the 'custom' folder, but you can change it to the same one where other images are automatically generated to keep them all together. Even though this is technically a manual process, the advantage is that you can select multiple images and convert them all at once, so if you do so with all of your images at once, you would only need to do this process once. This way, you can skip the current workaround of doing a ghost screen that only adds extra code for screens that won't even be used. EdwinHz_2-1789494766306.pngEdwinHz_2-1789494766306.png Additionally, for the granular control over the generation range of individual fonts, this can be controlled with the Font Converter. When doing the same process described above, just with a font instead of an image. The prompted window panel will show an option to specify the range of the selected font, allowing for the generation of specific ranges on specific fonts. EdwinHz_3-1789494865236.pngEdwinHz_3-1789494865236.png Hopefully this input helps on your current GUI Guider development. If you have any further inquiries or requests, definitely let us know! BR, Edwin.

How to burn HAB firmware on IMX6ULL about USB  We use IMX6ULL and want to implement the secure boot function. The current SD boot mode has been run through, the development board has written SRK, and the firmware has also been signed. Then we also executed the close operation (echo 0x02>HW_OCOTP_CFG5). After burning, the normal print information is as follows: Secure boot enabled HAB Configuration: 0xcc, HAB State: 0x99 However, when the same firmware was placed in the mfgtools tool and burned using USB, it was found that the board could not enter the burning system. The tool stops running, and the debug serial port does not have any print information. rxq_0-1789457007595.pngrxq_0-1789457007595.png The firmware in the red box,% board_file%/u-boot.imx and firmware/zImage are signed firmware. MfgTool.log records that the firmware has been imported. After the normal process Jumping to OS image, it should be the firmware that was started to import, but in fact, there is no print information on the debug serial port rxq_1-1789457333755.pngrxq_1-1789457333755.png Why is it normal for SD card to start, but not for USB？ What should we do to support USB burning? The attachment is the secure boot production process started by our SD

如何使用 USB 将 HAB 固件烧录到 IMX6ULL 上 我们使用 IMX6ULL，并且想要实现安全启动功能。 当前 SD 卡启动模式已运行完毕，开发板已写入 SRK，固件也已签名。然后我们还执行了关闭操作（echo 0x02>HW_OCOTP_CFG5）。 刻录完成后，正常的打印信息如下： 已启用安全启动 HAB 配置：0xcc，HAB 状态：0x99 然而，当将相同的固件放入 mfgtools 工具并使用 USB 进行烧录时，发现电路板无法进入烧录系统。 工具停止运行，调试串口没有任何打印信息。 rxq_0-1789457007595.pngrxq_0-1789457007595.png 红色方框中的固件、%board_file%/u-boot.imx 和 firmware/zImage 都是已签名的固件。 MfgTool.log 记录显示固件已导入。正常跳转到操作系统镜像后，应该开始导入固件，但实际上，调试串口上没有任何打印信息。 rxq_1-1789457333755.pngrxq_1-1789457333755.png 为什么SD卡可以正常启动，而USB却不行？ 我们应该如何做才能支持U盘刻录？附件是我们SD启动的安全启动生产流程。

EL2 Monitor: Simplifying Software Partitioning for Automotive Safety Systems The automotive industry is undergoing a fundamental architectural shift. Where vehicles once relied on dozens of dedicated ECUs — one function, one controller — modern designs are consolidating multiple software functions onto a single, powerful processor. This consolidation reduces cost, weight, and complexity, but it introduces a critical challenge: how do you run a safety-critical AUTOSAR brake control application on the same chip as a less-critical body control stack, and guarantee they can never interfere with each other? Full hypervisors are one answer — but they come with significant drawbacks. They are complex to integrate, expensive to license, difficult to certify to ISO 26262, and introduce latency that real-time systems cannot tolerate. NXP's EL2 Monitor (EL2M) was designed to solve exactly this problem: delivering robust, hardware-enforced software isolation with the simplicity, determinism, and safety pedigree that automotive programs demand. What Is EL2 Monitor? EL2 Monitor is a partitioning hypervisor that runs at Exception Level 2 (EL2) — the hypervisor privilege level defined by the Arm® architecture — on Arm® Cortex®-R52 cores. It sits between the hardware and the application software, acting as a lightweight isolation layer that enforces strict boundaries between software partitions running on the same processor. In simple terms: EL2 Monitor takes a single physical processor and divides it into independent, isolated software environments — called R52 partitions — each running its own RTOS instance with exclusive access to its assigned resources. A fault, crash, or security breach in one partition cannot affect any other. Unlike a full hypervisor, EL2 Monitor does not perform CPU scheduling, device virtualization, or dynamic resource management. Its scope is deliberately narrow: isolate partitions, protect shared hardware resources, and do so in a way that is statically configured, deterministic, and certifiable to ASIL D. This focused design philosophy is what makes it practical for production automotive programs. The Core Problem: The Shared GIC Distributor To understand why EL2 Monitor exists, it helps to understand a specific hardware constraint of the Arm Cortex-R52 architecture. In an R52-based Real-Time Unit (RTU), every two or four cores share a single GIC (Generic Interrupt Controller) Distributor — the hardware block that routes interrupts to cores. Without protection, any software running on one core has direct access to the GIC Distributor and could — accidentally or maliciously — reroute or disable interrupts belonging to another core's partition. This makes true isolation impossible without a dedicated software layer at EL2. EL2 Monitor fills this gap. It intercepts all GIC Distributor accesses from partitions and virtualizes them, giving each partition its own exclusive Virtual GIC Distributor while the real hardware GIC remains protected. nxf94150_1-1789390949734.png How It Works: Two Virtualization Modes   Trap & Emulate GIC Distributor accesses from EL1 software are automatically trapped to EL2, where EL2 Monitor validates and emulates them. The EL1 application is completely unaware of the virtualization — it behaves as if it has exclusive hardware access. Access operations complete in < 3 µs, making this mode suitable for standard AUTOSAR applications that require zero code changes.   Paravirtualization For performance-sensitive applications, EL2 Monitor provides ready-to-use Arm CMSIS GIC Driver APIs. The EL1 software calls these APIs directly instead of accessing GIC hardware registers. This cooperative approach achieves < 1.5 µs latency — half that of full emulation — while also reducing memory usage and development time. nxf94150_2-1789391007259.png Hardware-Enforced Memory Protection Beyond GIC virtualization, EL2 Monitor uses the EL2 Memory Protection Unit (MPU) to enforce strict memory boundaries between partitions in hardware. Each partition is assigned its own memory regions at configuration time. Even if an EL1 guest OS is compromised, it cannot access memory belonging to another partition. This is complemented by NXP's XRDC (Extended Resource Domain Controller) silicon feature, creating a layered hardware + software protection architecture that is unique to NXP's S32 platform. MRU Channel Isolation EL2 Monitor also virtualizes MRU (Messaging Resource Unit) channels within each R52 partition. Each software entity running at a lower privilege level accesses the MRU through its own dedicated virtualized instance — inter-core communication channels cannot be accessed or corrupted by other software entities. MRU handlers are serviced in < 1.5 µs. Static, Deterministic Configuration All partition assignments — CPU cores, memory regions, peripherals, interrupt routing — are defined at build time using the EB Tresos or S32CT configuration plugins. There is no runtime reconfiguration, no dynamic scheduling, and no hidden shared state. This static model makes system behavior fully predictable, simplifies safety analysis, and keeps the trusted computing base small and auditable. Safety and Quality EL2 Monitor is qualified to ASIL D per ISO 26262:2018 — the highest automotive functional safety integrity level. Development follows NXP's Software Development Process, which is Automotive SPICE 3.1 · IATF 16949:2016 · ISO 26262:2018 · ISO 21434:2021 · ISO 9001:2015 compliant. The complete package delivered to customers includes: Quality Package: SW Traceability Matrix (Req → Design → Code → Tests), Test Specs & Reports at all levels, MISRA/CERT-C/CWE Static Analysis, Code Coverage, Benchmark & Memory Reports Safety Package: Safety Manual, FMEA Software Package: Source code, Release Notes, User Manual, SBOM Development teams do not need to perform their own safety analysis of the partitioning layer — NXP provides the complete collateral, significantly reducing the certification effort for the overall system. Developer Experience: Fits Into Your Existing Workflow EB Tresos and S32CT plugins for AUTOSAR-based configuration S32 Design Studio (S32DS) for build, debug, and deployment Multi-compiler support for toolchain flexibility Sample application included to accelerate first-time integration Available via the NXP software distribution portal (Flexera) 6 on-demand training videos on nxp.com: Hello World, Configuration & Build, RTOS Integration, Download & Install, Tools & Compilers, Support Channels Supported Platforms nxf94150_3-1789392707431.png Why EL2 Monitor — and Why Now? The industry trend toward software-defined vehicles and centralized compute is accelerating. Zonal and domain controllers are replacing distributed ECU networks, and the software running on these controllers is growing in both complexity and safety criticality. The need for a reliable, certified, and cost-effective partitioning solution has never been more urgent. ASIL D certified — highest automotive safety integrity level, full collateral included Simpler than a full hypervisor — static, deterministic, minimal trusted computing base Unique NXP HW+SW stack — XRDC hardware isolation + EL2 Monitor software protection Sub-1.5 µs performance — paravirtualized GIC access Production-ready — full safety collateral, AUTOSAR toolchain integration, multi-platform Explore EL2 Monitor and discover how NXP's partitioning software can help you consolidate your automotive software architecture — safely, simply, and at no additional cost. Learn more about EL2 Monitor on nxp.com » Daniel Hermenczi Product Owner, EL2 Monitor — System Services, Automotive & Edge Solutions, NXP Semiconductors Daniel is a software project manager and product owner for EL2 Monitor and IPCF at NXP Semiconductors, driving roadmap execution and customer deliveries for automotive partitioning and inter-platform communication software. He is based in Sibiu, Romania. As vehicles consolidate more software onto fewer chips, keeping safety-critical functions truly isolated is no longer optional. EL2 Monitor delivers hardware-enforced partitioning for Arm® Cortex®-R52 — without the complexity of a full hypervisor.

S32K Examples S32K1xx S32K144 Example S32K144 CMP Round-robin S32DS2.0  Example S32K144 Verify Backdoor Access Key S32DS1.3  Example S32K144 FlexCAN0 RXFIFO DMA nonSDK S32DS13  Example S32K144 PDB ADC trigger DMA ISR S32DS  Example S32K144 Flash RW simple S32DS  Example S32K144 DMA memory copy test S32DS  Example S32K144 EEEPROM usage Example S32K144 EEEPROM usage - No SDK  Example S32K144 RTC VLPS  Example S32K144 WDOG RCM interrupt  Example S32K144 SRAM ECC Injection  Example S32K144 RAM Retention S32DS.R1 Example S32K144 I2C Master MPL3115A2 S32DSR1_v3  Example S32K144 FlexCAN RXFIFO DMA S32DS.ARM.2018.R1  Example S32K144_printf_implementation - S32DS_1.0  Example S32k144 UART printf/scanf under FreeRTOS - S32DS Example S32K144 SDK Function call on configurable period using LPIT timer.  Example S32K144 .noinit section usage Example S32K144 PDB ADC DMA S32DS.ARM.2018.R1   Example S32K144 RAM selftest simple S32DS 2018.R1  Example S32K144 Position Independent Code  Example S32K144 FlexCAN Pretended Networking STOP mode test S32DS.ARM.2.2  Example S32K144 LPIT DMA LPSPI  Example S32K144 FlexCAN TX/RX/Error ISR test S32DS2.2  Example S32K144 FlexIO Idle Detection S32DS2.2 S32K142 Example_S32K142_LMEN_Cache_v1_0_S32DS3.6_RTD300  Lauterbach_Script_For_MDM_AP_Mass_erase_S32K142  S32K146 Example S32K146 Set_whole_FlexRAM-as_RAM S32DS.ARM.2.2 S32K148 Example S32K148 PDB0-PDB1 ring S32DS3.4 RTM4.0.3  Example S32K148 PDB0-PDB1 ring DMA S32DS3.4 RTM4.0.3  Example S32K148 GPIO Interrupt   S32K116 Example S32K116 WDOG Fast Test  Example S32K116 LPUART LIN Slave TXRX ISR S32DS.ARM.2.2  Example S32K116 FlexCAN PN STOP S32DS.ARM.2.2 Example S32K116 FlexCAN VLPR test S32DS.ARM.2.2 S32K118 Example S32K118-SRAM-keep_data_over_SW_reset v0_1 S32DS.ARM.2.2 S32K3xx S32K312 Example S32K312 ADC_IP Continuous Scan DMA S32DS36 RTD600    S32K344 Example S32K344 PIT BTCU ADC DMA DS3.4 RTD100   Example S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFO test S32DS3.4 RTD200     Example Siul2_Port_Ip_Example_S32K344_ITCM_DTCM S32DS3.4 RTD300   Example S32K344 LPUART RX/TX ISR FreeRTOS S32DS36 RTD600    Example_S32K344_MCAL_MCU_ClockMonitor_v1_0_S32DS36_RTD600    Example_S32K314_DTCM1_Backdoor_RTD201_DS34_v3    Example_Reg_Prot_Flash_Controller_S32K344   Example S32K344 PIT SWtrig ADC ANAMUX S32DS 3.6.0 RTD 6.0.0   Example S32K344 EMAC lwIP FreeRTOS miniEVB S32DS 3.6.1 RTD 6.0.0   Example S32K344 EMAC lwIP FreeRTOS MRCANHUB S32DS 3.6.1 RTD600   Example_S32K344_BIST_eMCEM_SPD106_v2_0_S32DS365_RTD700  Example S32K344EVB_T172 UART_ETH_Gateway HLD S32DS368 RTD701   Example_S32K344_CMU_FM_POR_WDG_v1_0_S32DS369_RTD701    S32K358 Example S32K358 FlexCAN TXRX ISR S32DS35 RTD400/500   Example S32K358 GMAC 100M lwIP FreeRTOS S32DS 3.6.1 RTD600   Example S32K358 GMAC 1G lwIP FreeRTOS S32DS 3.6.1 RTD600   Example S32K358 GMAC lwIP FreeRTOS RDBESS S32DS 3.6.1 RTD600   S32K388 Example S32K388 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD600   S32K389 Example S32K389 GMAC0 lwIP FreeRTOS S32DS 3.6.1 RTD 6.0.0   Example S32K389 GMAC1 SABRE lwIP FreeRTOS S32DS 3.6.1 RTD600  

S32K 示例 S32K1xx S32K144 示例 S32K144 CMP 轮询 S32DS2.0 示例 S32K144 验证后门访问密钥 S32DS1.3 示例 S32K144 FlexCAN0 RXFIFO DMA nonSDK S32DS13 示例 S32K144 PDB ADC 触发 DMA ISR S32DS 示例 S32K144 Flash RW simple S32DS 示例 S32K144 DMA 内存复制测试 S32DS S32K144 EEEPROM 使用示例 示例 S32K144 EEEPROM 使用 - 无 SDK 示例 S32K144 RTC VLPS 示例 S32K144 WDOG RCM 中断 示例 S32K144 SRAM ECC 注入  S32K144 RAM 保留示例 S32DS.R1 示例 S32K144 I2C主设备 MPL3115A2 S32DSR1_v3 示例S32K144 FlexCAN RXFIFO DMA S32DS.ARM.2018.R1  示例 S32K144_printf_implementation - S32DS_1.0 示例 S32K144 在 FreeRTOS 下使用 UART printf/scanf - S32DS 示例 使用 LPIT 定时器实现可配置周期函数调用的 S32K144 SDK 示例 S32K144 .noinit章节用法 示例 S32K144 PDB ADC DMA S32DS.ARM.2018.R1 示例 S32K144 RAM 自检简单 S32DS 2018.R1 示例 S32K144 位置无关代码  示例 S32K144 FlexCAN 虚拟网络停止模式测试 S32DS.ARM.2.2 示例 S32K144 LPIT DMA LPSPI 示例 S32K144 FlexCAN TX/RX/Error ISR 测试 S32DS2.2 示例 S32K144 FlexIO 空闲检测 S32DS2.2 S32K146 示例 S32K146 Set_whole_FlexRAM-as_RAM S32DS.ARM.2.2 S32K148 示例 S32K148 PDB0-PDB1 环 S32DS3.4 RTM4.0.3 示例 S32K148 PDB0-PDB1 环 DMA S32DS3.4 RTM4.0.3 示例 S32K148 GPIO 中断 S32K116 示例 S32K116 WDOG 快速测试 示例 S32K116 LPUART LIN 从机 TXRX ISR S32DS.ARM.2.2 示例 S32K116 FlexCAN PN 停止 S32DS.ARM.2.2 示例 S32K116 FlexCAN VLPR 测试 S32DS.ARM.2.2 S32K118 示例 S32K118-SRAM-keep_data_over_SW_reset v0_1 S32DS.ARM.2.2 S32K3xx S32K344 示例 S32K344 PIT BTCU ADC DMA DS3.4 RTD100   示例 S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFO 测试 S32DS3.4 RTD200   示例 Siul2_Port_Ip_Example_S32K344_ITCM_DTCM S32DS3.4RTD300   示例 S32K358 FlexCAN TXRX ISR S32DS35 RTD400/500    

S32Kの例 S32K1xx S32K144 例：S32K144 CMPラウンド・ロビンS32DS2.0  例：S32K144バックドア・アクセス・キー検証S32DS1.3  例：S32K144 FlexCAN0 RXFIFO DMA非SDK S32DS13  例：S32K144 PDB ADCトリガDMA ISR S32DS  例：S32K144 Flash RWシンプルS32DS  例：S32K144 DMAメモリ・コピー・テストS32DS  例：S32K144 EEEPROMの使用方法 例：S32K144 EEEPROMの使用方法 - 非SDK  例：S32K144 RTC VLPS  例：S32K144 WDOG RCM割り込み  例：S32K144 SRAM ECC注入  例 S32K144 RAM 保持 S32DS.R1 例：S32K144 I2CマスタMPL3115A2 S32DSR1_v3  例：S32K144 FlexCAN RXFIFO DMA S32DS.ARM.2018.R1  例：S32K144_printf_implementation - S32DS_1.0  例：FreeRTOS環境でのS32k144 UART printf/scanf - S32DS 例：S32K144 LPITタイマを使用した構成可能期間に対するSDK関数の呼び出し  例：S32K144 .noinitセクションの使用方法 例：S32K144 PDB ADC DMA S32DS.ARM.2018.R1   例：S32K144 RAMセルフテスト・シンプルS32DS 2018.R1  例：S32K144ポジショニング独立コード 例：S32K144 FlexCAN疑似ネットワーキングSTOPモードのテストS32DS.ARM.2.2  例：S32K144 LPIT DMA LPSPI  例：S32K144 FlexCAN TX/RX/エラーISRテストS32DS2.2  例：S32K144 FlexIOアイドル検出S32DS2.2 S32K146 S32K146 Set_whole_FlexRAM-as_RAM S32DS.ARM.2.2の例 S32K148 例：S32K148 PDB0-PDB1リングS32DS3.4 RTM4.0.3  例：S32K148 PDB0-PDB1 ring DMA S32DS3.4 RTM4.0.3  例：S32K148 GPIO割り込み  S32K116 例：S32K116 WDOG高速テスト  例：S32K116 LPUART LINスレーブTXRX ISR S32DS.ARM.2.2  例 S32K116 FlexCAN PN STOP S32DS.ARM.2.2 例：S32K116 FlexCAN VLPRテストS32DS.ARM.2.2 S32K118 例 S32K118-SRAM-keep_data_over_SW_reset v0_1 S32DS.ARM.2.2 S32K3XXシリーズ S32K344 例：S32K344 PIT BTCU ADC DMA DS3.4 RTD100   例：S32K344 FlexCAN_Ip TX/RX/EnhanceRXFIFOテストS32DS3.4 RTD200     例Siul2_Port_Ip_Example_S32K344_ITCM_DTCM S32DS3.4RTD300   例：S32K358 FlexCAN TXRX ISR S32DS35 RTD400/500     

USB init failed: -22 Hi , I have been trying to flash my wic.b2z image to an emmc using uuc tool through a usb port.While flashing an USB init failed: -22 error occured.I am using an imx8mp porcessor. Run bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else booti ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo "Run fastboot ..."; fastboot 0; fi; Hit any key to stop autoboot: 0 ## Checking Image at 43800000 ... Unknown image format! Run fastboot ... USB init failed: -22 u-boot=>     i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Re: USB init failed: -22 Hello,  Please share the complete process and the boot config of your board to analyze what can cause the issue.   Re: USB init failed: -22 U-Boot SPL 2024.04-lf_v2024.04+g6c4545203d1+p0 (Nov 15 2024 - 04:02:13 +0000) DDRINFO: start DRAM init DDRINFO: DRAM rate 4000MTS DDRINFO:ddrphy calibration done DDRINFO: ddrmix config done SEC0:  RNG instantiated Normal Boot Trying to boot from BOOTROM Boot Stage: USB boot Find img info 0x48022fa0, size 1064 Need continue download 1024 NOTICE:  Do not release JR0 to NS as it can be used by HAB NOTICE:  BL31: v2.10.0  (release):automotive-15.0.0_1.1.0 NOTICE:  BL31: Built : 08:52:12, Nov  4 2024 U-Boot 2024.04-lf_v2024.04+g6c4545203d1+p0 (Nov 15 2024 - 04:02:13 +0000) CPU:   i.MX8MP Lite[4] rev1.1 1600 MHz (running at 1200 MHz) CPU:   Industrial temperature grade (-40C to 105C) at 35C Reset cause: POR Model: NXP i.MX8MPlus LPDDR4 EVK board DRAM:  6 GiB tcpc_init: Can't find device id=0x50 setup_typec: tcpc port2 init failed, err=-19 tcpc_init: Can't find device id=0x50 setup_typec: tcpc port1 init failed, err=-19 Core:  284 devices, 36 uclasses, devicetree: separate MMC:   FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from nowhere... OK [*]-Video Link 0adv7535_mipi2hdmi adv7535@3d: Can't find cec device id=0x3c fail to probe panel device adv7535@3d fail to get display timings probe video device failed, ret -19         [0] lcd-controller@32e80000, video         [1] mipi_dsi@32e60000, video_bridge         [2] adv7535@3d, panel adv7535_mipi2hdmi adv7535@3d: Can't find cec device id=0x3c fail to probe panel device adv7535@3d fail to get display timings probe video device failed, ret -19 In:    serial Out:   serial Err:   serial SEC0:  RNG instantiated MMC: no card present Detect USB boot. Will enter fastboot mode! Net:   Could not get PHY for FEC0: addr 1 Could not get PHY for FEC0: addr 1 eth1: ethernet@30bf0000 [PRIME] Fastboot: Normal Boot from USB for mfgtools *** Warning - Use default environment for                                mfgtools , using default environment Run bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else booti ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo "Run fastboot ..."; fastboot 0; fi; Hit any key to stop autoboot:  0 ## Checking Image at 43800000 ... Unknown image format! Run fastboot ... USB init failed: -22 u-boot=> Re: USB init failed: -22 Hello,  Please try again flashing the last pre-build image (Linux 6.18.20_2.0.0) and the last version of the uuu tool.  Regards. 

S32K344 – HSE_BファームウェアをインストールしたアプリケーションでPFLASH Block 2が利用可能ですか? こんにちは、 S32K344 (HSE_FW_S32K344_0_2_55_0、0.2.55.0 ビルド pb150130 (2025 年 1 月 30 日)) を中心とした配電ユニットを開発中です。タイプ：標準FW構成）デュアルバンクブートローダーとセキュアファームウェアアップデート付き。Flashレイアウトのある一点で行き詰まっており、明確な回答をいただけると幸いです。 問題点 NVMの設定領域(アプリケーションが書き込むランタイムパラメータ)は現在、実行中のコードと同じブロック内のPFLASHブロック0に存在しています。実行時にそれらに書き込むと、コア上で書き込み中の読み取り停止が発生し、プログラム/消去操作の間、ユニットがフリーズします。これは私たちのアプリケーションには受け入れられません(PDUはセーフティに関わる負荷を駆動します)。 最も簡単な解決策は、これらの領域を実行コードを含まないブロックに移動することです。ブロック2(0x600000–0x6FFFFF、セクター368–381)が自然な候補です。アプリケーションバンクでは使用されておらず、HSEがデータを保存するブロックでもありません。 これまでに確認したこと – S32K3xxリファレンスマニュアルにはPFLASHブロック構造が説明されていますが、HSE予約については何も触れていません。 – 公開されているHSE Basic FW FAQによると、ブロック0と1はアプリケーションに対して保証されており、HSEファームウェアはブロック3の一部(FULL_MEM構成で176KB)を予約しています。ブロック2については全く言及されていません。 – 私たちが検討したHSEデモアプリケーションやRTDの例もBlock 2を使用していないため、そこから何も推測できません。 – HSEファームウェアリファレンスマニュアルv2.4のNDA/DocStoreアクセス申請を提出しましたが、この内容はこの内容をカバーしていると理解しています。リクエストは保留中です。 質問 HSE_Bファームウェアをインストールした場合、Block 2はFULL_MEM設定のアプリケーション(コードとデータ)に完全に利用可能でしょうか?AB_SWAPについてはどうでしょうか？ アプリケーションコアから実行時にブロック2を消去・プログラミングすることに関して、HSE関連の制限はありますか?HSE、SBAF、またはセキュアブートによってロックまたは監視されているセクター）？ HSEファームウェア、SBAF、アプリケーション間のPFLASHブロックの完全な割り当てを説明した公開文書はありますか?もしなければ、NDA申請が処理される間にHSEファームウェア リファレンス・マニュアルへのアクセスを手伝ってもらえませんか? 確定的な答えが出るまでは、設計は意図的にブロック0と1に限定されており、そのため読み書きの問題が残ります。 ご協力ありがとうございます。 Re: S32K344 – Is PFLASH Block 2 available to the application with HSE_B firmware installed? 共有していただきありがとうございます 😉 Re: S32K344 – Is PFLASH Block 2 available to the application with HSE_B firmware installed? こんにちは、 @manu_fenixecu さん、 A1。はい、ブロック2は完全にユーザーフラッシュです。 S32K344、S32K314、およびS32K324のフラッシュメモリのレイアウトについては、HSE-B FW RM v2.7の図33（FULL_MEM）および図34（AB_SWAP）を参照してください。 A2.HSE-B FW RM v2.7、セクション14.6.4.2(HSE_CONFIG_GPR3)— アプリケーションはビット27を読み取るべきです。 A3。公開されている唯一の参考資料は、S32K3xx RM rev12、表198（「HSE_Bファームウェア使用機能フラグが有効になっている場合の構成の詳細」）です。HSE-B FW RMはNDAなしに共有できません。HSE関連のサポートについては、この公開コミュニティではなくサポートチケットを使用してください。 よろしくお願いいたします。 ダニエル

i.P-384秘密鍵/ブラックブロブの利用ケースにおけるMX8DXL CAAMカバーの制限 こんにちは、NXPチームの皆様、 私たちは、i.MX8DXL CAAMにおけるECDSA P-384ブラックキー/ブロブのサポートを評価しています。 観察された結果 P-256 外部から提供された平文のP-256秘密鍵から開始します。 プレーンテキストキー → カバー → 黒いキーの塊 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：合格 P-384（CAAM生成の黒鍵） ECDSA秘密鍵をKEY_COLOR_BLACKとして生成する COVER操作なしで秘密鍵からブラックブロブを生成する 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：合格 P-384（外部平文秘密鍵） 外部から提供された平文のP-384秘密鍵（48バイト）から開始します。 プレーンテキストキー → カバー → 黒いキーの塊 黒い塊から黒い鍵を復元する ECDSAの署名/確認 結果：失敗 追加の観察 NXPのパッチに以下のコメントがあることに気づきました。 https://github.com/nxp-imx-support/imx_sec_apps/blob/master/caam-ecdsa-blackkey/patch/0002-caam-black-key-blob-feature.patch /* * KEYコマンドは32バイトに制限されているようなので、ロードを使うべきです * コマンドは最大64バイトまで読み込み可能です。 * * TODO: KEYコマンドは、より大きなキーをロードできるようにする必要があることを示しています * 32バイトより小さいが、実際には機能しない * * TODO: LOAD コマンドは最大 96 までロードできるはずです * バイトキーは実際には機能せず、64バイトに制限されています */ 我々も同様の挙動を観察した。 KEYコマンドの代わりにLOADコマンドを使用することで、48バイトのP-384秘密鍵を含む、32バイトを超える鍵を扱うことができます。 しかし、これは上記の問題を解決するものではありません。鍵は覆ってブロブに保存できますが、復元された黒鍵はECDSA署名や検証に成功裏に使用できません。   私たちの質問： CAAM COVER操作において、32バイトを超えるECC秘密鍵に対する既知の制限事項はありますか？ COVER経由で外部のP-384平文秘密鍵をインポートし、それをECDSAのブラックキーとして使うことはサポートされているユースケースでしょうか? 観測された動作は、CAAMハードウェアの制限によるものなのでしょうか？ 外部生成されたP-384平文秘密鍵をインポートし、それをECDSA操作のブラックキーとして使う推奨されるCAAM方法はありますか? 何かアドバイスをいただければ幸いです。 ありがとうございます。よろしくお願いいたします。 ホジャメス。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case 補足事項：   私たちの懸念はECDSAのユースケースに限られません。   COVERを介して外部のP-384秘密鍵をインポートすることがECDSAの標準ワークフローではないとしても、COVER操作自体の制限事項を理解しておきたいと考えています。   当社のアプリケーションでは、COVER操作はECDSA秘密鍵だけでなく、一般的な機密データの保護にも利用されることがあります。したがって、32バイトを超えるペイロードサイズのサポートは重要な考慮事項です。 我々のテストに基づくと、LOADコマンドの回避策を用いることで、32バイトを超えるペイロードを処理できることがわかった。約80バイト以下のペイロードは正常に動作するようですが、それより大きいサイズでは動作が不安定になります。これらの観察結果が、実際のCAAMの制限を反映しているのか、それとも実装上の問題を反映しているのかを理解したいと考えています。 また、ECDSAのユースケースとは独立して、COVER操作自体に文書化されたサイズ制限があるかどうかもNXPは明確にしていただけますか?   よろしくお願いします。 Re: i.MX8DXL CAAM COVER limitation for P-384 private key / black blob use case このCAAM機能をテストするための環境を構築する必要があります。結果が出次第、ご連絡いたします。

NFCチップの書き込み方法 iPhone 12 Pro Maxを使ってNFC 215チップに書き込みを試みています。私はNXPタグライターアプリを使用しています。NXPタグライターアプリで「新規」→「Webサイト」をクリックし、URIタイプとURIデータとともに説明情報を入力します。次に「保存して書き込む」をクリックすると、「NDEF 記録がデータセットに正常に保存されました」という通知が表示されます。アプリを閉じてチップをタップしても何も反応しません。別の電話でも試してみましたが、やはりうまくいきませんでした。何かアイデアや提案はありますか? nfc error.PNGnfc error.PNGnfcエラー.PNG Re: How to write nfc chip こんにちは、@Erik3さん 「データセットに保存されました」というメッセージは、データがアプリ内にローカルに保存されただけで、まだチップに書き込まれていないことを意味します。お試しください： TagWriterで「My Datasets」に行き、エントリを選択して「Write」→タップ→ 書き込み確認が表示されるまで、iPhoneをチップに近づけてください また、NFC TagInfoアプリを使ってチップをスキャンし、その現在の内容や状態を確認できます。

S32DSライセンスの有効期限が切れます こんにちは、 S32DS を開くと次のメッセージが表示されます。   Arm用Design Studio アクティベーションID: 8AEC-51FD-AB5B-6A4D 評価日数: 9 機能バージョン: 2.2 機能のステータス: 評価 (9 日間) ライセンスを延長するには何をする必要がありますか? よろしくお願いいたします。 サンドラ Re: S32DS license expiring こんにちは、 ライセンスを延長するよう管理者に通知しました。 よろしくお願いいたします。 ピーター Re: S32DS license expiring こんにちは、 ライセンスは 2030 年まで延長されました。 よろしくお願いいたします。 ピーター Re: S32DS license expiring こんにちは、 画像の問題でS32DSをアクティベートできませんでした。この問題を解決する方法を教えていただけますか？ HelenLi_0-1778831877838.pngHelenLi_0-1778831877838.pngHelenLi_0-1778831877838.png Re: S32DS license expiring 助けて! 私のS32DS IDEライセンスがもうすぐ期限切れです。使用期間を延長するのを手伝ってもらえますか?ありがとう ！ ライセンス番号：1A99 90A8 2F06 339B Re: S32DS license expiring こんにちは： アクティベーションID: 04E9-8F5A-8B1F-F9C8 ライセンスの有効期間を延長する必要がある。 Re: S32DS license expiring こんにちは! 私のS32DS IDEライセンスがもうすぐ期限切れです。使用期間を延長するのを手伝ってもらえますか?ありがとう ！ ライセンス番号：EA09-8465-A8E8-F07B

S32K322 LCU/Emios I would like to understand the encoder implementation and principle differences between the S32K144 and S32K322. With the S32K144, the initial angle is communicated through the PWM and then provided to the count to the ABI interface for further processing. We also have a fault-detection mechanism to detect A, B, and I signal/wire disconnections using the quadrature decoder functionality through FTM. However, with the S32K322, the same logic is not working as expected, particularly because we are currently unable to detect the direction correctly. For example, when the I-pulse wire is disconnected, the absolute count becomes zero. This results in incorrect switching, after which the absolute count gradually varies and eventually reaches 4095 pulses. In the S32K144, even when the I-pulse is disconnected, the A and B signals with a single output are still able to provide the proper count, allowing us to detect the fault. Could you please provide examples or clarify the expected behavior for the following cases? A-pulse wire disconnected B-pulse wire disconnected I-pulse wire disconnected A and B pulse wires disconnected A, B, and I pulse wires disconnected It would also be helpful if you could explain how the encoder count and direction are expected to behave in each of these scenarios for both the S32K144 and S32K322. Regards, Thiru S32K3 S32K1 BRUSHLESS-DC-MOTOR-CONTROL  Re: S32K322 LCU/Emios Hi, The S32K322 does not include the FTM peripheral that is present on the S32K144. On the S32K3 family, the quadrature encoder functionality is built around the cooperation of the LCU, TRGMUX, and eMIOS modules. This is a fundamentally different architecture from the FTM-based quadrature decoder available on S32K144. On S32K322, PHA and PHB are decoded by the LCU into separate CW and CCW pulse streams, which are counted by two eMIOS channels. The application obtains the incremental position from the difference between these counters. A useful starting point for the S32K3 quadrature decoder design is Application Note AN13767, specifically Section 4.2.5, which describes the LUT truth table used for direction detection, TRGMUX routing, and eMIOS edge-counter configuration. Additional information can be found on the S32K344 motor-control kit page and in the related community discussion: AN13767: Application Note AN13767 S32K344 Motor Control Kit: S32K344 BLDC/PMSM Development Kit Community discussion: Quadrature decoder on S32K344 Based on the LCU LUT implementation, if either the A or B signal is disconnected, the remaining channel can still generate transitions that produce CW or CCW pulses at the LCU output. As a result, the corresponding eMIOS counter continues counting and direction information may still be available. However, the pulse rate is reduced, resulting in approximately four times fewer counts per revolution compared to normal operation. If both A and B signals are disconnected, no valid quadrature transitions are present at the LCU inputs. Consequently, neither CW nor CCW pulses are generated and the eMIOS counters remain unchanged. Regarding the index (I) signal, the NXP motor-control kit implementation does not use the index signal. Position and direction are derived solely from the A and B quadrature signals, while the position offset is calibrated during rotor alignment. Furthermore, the index signal is not connected to the MCU in this implementation. Therefore, the behavior observed when disconnecting the I signal appears to be application-specific. BR, Petr Re: S32K322 LCU/Emios I could not fully understand the LCU LUT logic described in the application note. I have the following questions: 1. Detection of A/B signal disconnection: I understand that detecting A or B signal disconnection based only on the absolute count may not be reliable, since the absolute count can remain at 0 or 4095 when either the A or B signal is disconnected. At the same time, defining a fixed threshold based on the CW/CCW counter also seems difficult because the rotor can rotate forward and backward, causing the counter to roll over. The CW/CCW counter can therefore exceed 4095 and continue up to 65535 (uint16), depending on the rollover condition. In this scenario, what would be the recommended logic or threshold for detecting A/B signal disconnection? Could you please suggest a suitable diagnostic approach for this scenario, considering the counter rollover condition?

IW416 Wi-Fi RF Test Mode – PN9 / Payload Pattern for EN 300 328 Hello, We are evaluating IW416 for EN 300 328 regulatory testing using AN14114 Rev.7.0 Our certification laboratory has requested continuous modulated transmission using a PN9 data sequence. However, in the Wi-Fi TX continuous command, AN14114 only describes a fixed payload pattern: echo "tx_continuous= " and gives this example: echo "tx_continuous=1 0 0xAAA 0 3 0x8" Could you please confirm: 1. Does IW416 Wi-Fi RF Test Mode support direct PN9/PRBS9 generation? 2. If not, what payload pattern does NXP recommend for EN 300 328 testing? 3. Can 0xAAA be used as the recommended alternative to PN9 for Continuous Packet Mode? 4. Are these settings correct for continuous modulated transmission? - transmit mode = 0 - cs mode = 0 - active subchannel = 3 Thank you.

フラッシュドライブ # 今 マーケット で一番良いフラッシュドライブはどれか ## どうか教えて Re: Flash Drives こんにちは、@ reedjhn9 あなたの質問の意味がよく分かりませんでした。具体的に、使用している製品と知りたい具体的な問題について教えていただけますか?

TJA1410_10Base_T1s 您好，NXP 我正在使用 S32K5 和 TJA1410 测试 10BASE-T1S。目前，我可以在 TX 引脚上看到波形，RX 和 ED 引脚上也有波形，这表明 MDI 可以接收到信号。但是，TX 引脚无法向 MDI 发送数据。 TX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmp 此致敬礼。 显龙 以太网 PHY Re: TJA1410_10Base_T1s 你好@wuxianlong ， 你是如何测量MDI的？MDI是差分接口，所以你需要使用差分示波器探头。MDI 需要正确的差分终端匹配 - 请参阅 AN14787 - 应用笔记 10BASE-T1S 以太网 PMD 收发器 TJA1410，修订版 1.0，第 3.3 章。 顺祝商祺！ 帕维尔 Re: TJA1410_10Base_T1s 你好@wuxianlong ， 希望你一切安好。我写信给您是关于您目前拥有的一款产品——NPI（新产品导入）——S32K5——该产品尚未正式发布。 请注意，已获准提前体验此类产品的客户已指派了现场工程师。您指定的现场工程师应作为您解决有关本产品任何问题、疑虑或疑问的主要支持渠道。 我们的在线支持团队将在该产品正式发布后，提供更广泛的支持服务。在此之前，我们将无法提供所需的帮助。 感谢您的理解。 感谢您的理解。 顺祝商祺！ 帕维尔 Re: TJA1410_10Base_T1s 嗨， @PavelL 我没有使用差分探头。当我发射（TX）时，示波器上的 MDI 没有波动——它保持平坦/水平。但是，当 PC 发送数据时，MDI 明显显示出差分波形。感觉TJA1410没有正确切换到发射模式，芯片仍然处于正常模式。是否有方法可以验证PHY的当前模式？目前，我们的 TJA1410 未连接到 SMI 接口——我们应该对此采取哪些预防措施？ 此致， 显龙 Re: TJA1410_10Base_T1s 你好@wuxianlong ， 由于 S32K5 是 NPI 设备，请注意，我们目前无法在我们这边验证完整的 S32K5 和 TJA1410 设置。   TJA1410 的工作模式不是通过 SMI 接口选择的。正常模式和传输模式之间的转换由 TX 引脚上接收到的命令控制。因此，观察 TX 上的数据活动并不一定能确认 TJA1410 已进入发射模式。前面的 TRANSMIT 命令及其时序也必须符合 TJA1410 数据表中规定的时序。   请根据 TJA1410 数据表中的图 10 验证从正常模式到传输模式的转换。特别地，请捕获 TX 命令以及差分 VLINE 信号和 ED 输出。这应该可以确认 TJA1410 是否识别 TRANSMIT 命令并激活其 MDI 发射器。   顺祝商祺！ 帕维尔