Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
imx93 m33 rpmsg hello_world test Board/Setup CPU: i.MX93  Boot media: SD (mmc 1) Goal: run CM33 RPMsg-Lite string echo demo and communicate from Linux (A55) Problem Summary I’m trying to start the Cortex‑M33 RPMsg demo either: from U‑Boot using bootaux, or from Linux using remoteproc (firmware loaded from firmware) I’m seeing: U‑Boot data aborts when trying to access certain CM33 alias addresses (e.g. 0x1ffe0000 / 0x0ffc0000) Linux remoteproc tries to load rpmsg_lite_str_echo_rtos_remote.bin and fails with error -2 (file not found), then falls back to sysfs fallback. I’m unsure what the correct memory copy address and boot address should be for CM33 on i.MX93 (system vs alias address), and how to align U‑Boot bootaux flow with Linux remoteproc flow. What I tested SD partition layout and boot files U‑Boot shows SD is mmc 1: u-boot=> mmc list FSL_SDHC: 0 (eMMC) FSL_SDHC: 1 (SD) Partition table: u-boot=> part list mmc 1 Partition Map for MMC device 1 -- Partition Type: DOS Part Start Sector Num Sectors UUID Type 1 16384 681574 076c4a2a-01 0c Boot 2 704512 5769534 076c4a2a-02 83 Boot partition contents include DTBs and an mcore-demos/ directory: u-boot=> fatls mmc 1:1 ... mcore-demos/ ... I can load the demo: u-boot=> fatload mmc 1:1 ${loadaddr} mcore-demos/rpmsg_lite_str_echo_rtos_remote.bin 39004 bytes read in 3 ms u-boot=> echo ${loadaddr} 0x80400000 u-boot=> echo ${filesize} 985c The first two words look like a valid CM33 vector table: u-boot=> md.l ${loadaddr} 2 80400000: 2001e000 0ffe0595 Reading 0x1ffe0000 causes abort: Linux side: remoteproc firmware load fails In Linux, when remoteproc0 powers up, it tries to load firmware: [ 84.714629] remoteproc remoteproc0: powering up imx-rproc [ 84.721926] remoteproc remoteproc0: Direct firmware load for rpmsg_lite_str_echo_rtos_remote.bin failed with error -2 [ 84.732549] remoteproc remoteproc0: Falling back to sysfs fallback for: rpmsg_lite_str_echo_rtos_remote.bin here is the reserved memory: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; linux,cma { compatible = "shared-dma-pool"; reg = <0 0x88000000 0 0x04000000>; /* 64 MB @ 0x8800_0000 */ reusable; linux,cma-default; }; /* Ethos-U: move away from the kernel boot (32 MB) */ ethosu_mem: ethosu_region@8c000000 { compatible = "shared-dma-pool"; reg = <0 0x8c000000 0 0x02000000>; no-map; }; vdev0vring0: vdev0vring0@84000000 { reg = <0 0x84000000 0 0x00008000>; no-map; }; vdev0vring1: vdev0vring1@84008000 { reg = <0 0x84008000 0 0x00008000>; no-map; }; vdev1vring0: vdev1vring0@84010000 { reg = <0 0x84010000 0 0x00008000>; no-map; }; vdev1vring1: vdev1vring1@84018000 { reg = <0 0x84018000 0 0x00008000>; no-map; }; rsc_table: rsc-table@2021e000 { reg = <0 0x2021e000 0 0x00001000>; no-map; }; /* OCRAM */ vdevbuffer: vdevbuffer@84020000 { compatible = "shared-dma-pool"; reg = <0 0x84020000 0 0x00100000>; /* 1 MB */ no-map; }; ele_reserved: ele-reserved@90000000 { compatible = "shared-dma-pool"; reg = <0 0x90000000 0 0x00100000>; /* 1 MB @ 0x9000_0000 */ no-map; }; }; ethosu { compatible = "arm,ethosu"; fsl,cm33-proc = <&cm33>; memory-region = <&ethosu_mem>; power-domains = <&mlmix>; }; What is the correct procedure to start CM33 RPMsg demo on i.MX93 from U‑Boot? If CM33 is started by U‑Boot (bootaux), what is the recommended Linux configuration? Re: imx93 m33 rpmsg hello_world test Hi , the BSP version is VERSION="6.6-scarthgap (scarthgap)" I use imx93 custom board with 512MB RAM and there is no hello_world.elf these are under the /lib/firmware   imx93-11x11-evk_m33_TCM_low_power_wakeword.elf imx93-11x11-evk_m33_TCM_power_mode_switch.elf imx93-11x11-evk_m33_TCM_rpmsg_lite_pingpong_rtos_linux_remote.elf  imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf imx93-11x11-evk_m33_TCM_sai_low_power_audio.elf after testing it u-boot=> fatload mmc 1:1 80000000 mcore-demos/rpmsg_lite_str_echo_rtos_remote.bin 39004 bytes read in 3 ms (12.4 MiB/s) u-boot=> cp.b 0x80000000 0x201e0000 0x10000 u-boot=> bootaux 0x1ffe0000 0 ## Starting auxiliary core addr = 0x1FFE0000... it doesnt start, it freezes. Re: imx93 m33 rpmsg hello_world test Hi, Thank you for your interest in NXP Semiconductor products, Using prebuilt cortex-M demos is a great way to start, are you using i.MX 93 EVK or a custom board with the prebuilt image flashed? What BSP are you using? To run Cortex-M demos in U-boot you can use the following snippet: u-boot=> fatload mmc 1:1 80000000 sdk20-app.bin u-boot=> cp.b 0x80000000 0x201e0000 0x10000 u-boot=> bootaux 0x1ffe0000 0 RPMSG has to be ran in Linux RPROC framework since you have to reserve memory in DTB for RPMSG and Cortex-A RPMSG communication is over a Linux driver. root@imx93evk:~# echo hello_world.elf > /sys/class/remoteproc/remoteproc0/ firmware root@imx93evk:~# echo start > /sys/class/remoteproc/remoteproc0/state Regards Re: imx93 m33 rpmsg hello_world test Hi @bora, Please try with imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf That is the binary you are testing, please refer to the available examples in SDK: SDK_24_12_00_MCIMX93-EVK\boards\mcimx93evk\multicore_examples - rpmsg_lite_pingpong_rtos_linux - rpmsg_lite_str_echo_rtos Regards Re: imx93 m33 rpmsg hello_world test Hi , I tried that and this is the result, root@imx93-11x11-lpddr4x-evk:~# echo start > /sys/class/remoteproc/remoteproc0/state [ 105.274513] remoteproc remoteproc0: powering up imx-rproc [ 105.282905] remoteproc remoteproc0: Booting fw image imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.elf, size 59028 [ 105.294019] remoteproc remoteproc0: Registered carveout doesn't fit len request [ 105.301405] rproc-virtio: probe of rproc-virtio.1.auto failed with error -12 [ 105.309101] remoteproc remoteproc0: Registered carveout doesn't fit len request [ 105.316561] rproc-virtio: probe of rproc-virtio.2.auto failed with error -12 [ 105.830361] remoteproc remoteproc0: remote processor imx-rproc is now up Re: imx93 m33 rpmsg hello_world test Hi, I could reproduce with the next steps on LF-6.12.49 EVK Cortex-A U-boot Hit any key to stop autoboot: 0 u-boot=> fatload mmc 0:1 ${loadaddr} mcore-demos/imx93-11x11-evk_m33_TCM_rpmsg_lite_str_echo_rtos.bin 19816 bytes read in 18 ms (1 MiB/s) u-boot=> cp.b ${loadaddr} 0x201e0000 0x20000 u-boot=> bootaux 0x1ffe0000 0 ## Starting auxiliary core addr = 0x1FFE0000... u-boot=> pri mmcargs mmcargs=setenv bootargs ${jh_clk} ${mcore_clk} console=${console} root=${mmcroot} u-boot=> editenv m mfgtool_args mmcargs mmcautodetect mmcboot mmcdev mmcpart mmcroot u-boot=> editenv mmcargs edit: setenv bootargs ${jh_clk} ${mcore_clk} console=${console} root=${mmcroot} clk_ignore_unused u-boot=> boot Cortex-A Linux root@imx93evk:~# lsmod | grep -i imx_rpmsg_tty root@imx93evk:~# modprobe imx_rpmsg_tty Cortex-M from U-boot to Linux. RPMSG String Echo FreeRTOS RTOS API Demo... Nameservice sent, ready for incoming messages... Get Message From Master Side : "hello world!" [len : 12] Regards Re: imx93 m33 rpmsg hello_world test on u-boot I started and worked but in linux via .elf file I get imx_rproc_kick: failed (0, err:-62) Re: imx93 m33 rpmsg hello_world test I tested also but for me no result, I still cant communicate with m33. I use custom board not imx93-11x11-evk , I use uart1 and no uart2, for m33 I have JTAG. Re: imx93 m33 rpmsg hello_world test I also dont see any ttyRPMSG under /dev
View full article
i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello, I am trying to debug firmware for the Cortex-M33 on an i.MX93 using a Segger J-Link and gdb. I established an SWD connection using the patch from NXP for the J-Link software and can halt the processor, read the registers and memory and so on. My problem is, that resetting the processor does not work. The content of the registers does not change so I assume the reset is ignored: (gdb) monitor regs R0 = 40D000C0, R1 = 2001EFE3, R2 = 40D000C0, R3 = 00000000 R4 = 00000000, R5 = 00000000, R6 = FFFFFFFF, R7 = 2001EEE8 R8 = FFFFFFFF, R9 = FFFFFFFF, R10= 2000F000, R11= 00000000 R12= FFFFFFFF, R13= 2001EEE8, MSP= 2001EEE8, PSP= 00000000 R14(LR) = 0FFE219D, R15(PC) = 0FFE2248 XPSR 49000003, APSR 48000000, EPSR 01000000, IPSR 00000003 CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00 Security extension regs: MSP_S = 2001EEE8, MSPLIM_S = 00000000 PSP_S = 00000000, PSPLIM_S = 00000000 MSP_NS = 00000000, MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC, PSPLIM_NS = 00000000 CONTROL_S 00, FAULTMASK_S 00, BASEPRI_S 00, PRIMASK_S 00 CONTROL_NS 00, FAULTMASK_NS 00, BASEPRI_NS 00, PRIMASK_NS 00 (gdb) monitor reset Resetting target (gdb) monitor regs R0 = 40D000C0, R1 = 2001EFE3, R2 = 40D000C0, R3 = 00000000 R4 = 00000000, R5 = 00000000, R6 = FFFFFFFF, R7 = 2001EEE8 R8 = FFFFFFFF, R9 = FFFFFFFF, R10= 2000F000, R11= 00000000 R12= FFFFFFFF, R13= 2001EEE8, MSP= 2001EEE8, PSP= 00000000 R14(LR) = 0FFE219D, R15(PC) = 0FFE2248 XPSR 49000003, APSR 48000000, EPSR 01000000, IPSR 00000003 CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00 Security extension regs: MSP_S = 2001EEE8, MSPLIM_S = 00000000 PSP_S = 00000000, PSPLIM_S = 00000000 MSP_NS = 00000000, MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC, PSPLIM_NS = 00000000 CONTROL_S 00, FAULTMASK_S 00, BASEPRI_S 00, PRIMASK_S 00 CONTROL_NS 00, FAULTMASK_NS 00, BASEPRI_NS 00, PRIMASK_NS 00 The reset strategy from the J-Link is using SYSRESETREQ and not the reset signal since only the Cortex-M33 core is supposed to be reset. Is it possible that the debug controller does not have the necessary security privileges to write the SYSRESETREQ bit? What is the correct way to perform a reset of the Cortex-M33 using a J-Link? Regards, Malte Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello, Can you also share the details on [email protected]? More than a yer already from this topic, and still same issue. Thanks. Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working It worked in the sense I never lost again the processor, but the execution time was heavily affected, which I don't understand why. Each operation took 10x more the time. Does it make sense to perform a cold reset but have by default some code in the ROM (contrary on what is suggested by NXP to have no SD card) and attach the debugger to what is ongoing and overwrite ram? Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello, Is it possible to use this JLink script? https://kb.segger.com/images/8/86/Example_Reset_CortexM_Normal.JLinkScript It is a standard strategy for CortexM. Kind Regards Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello, Can you please share your solution? I am currently facing the same situation. Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello Krzysztof, as stated above, I did manage to work out a way to reset the Cortex-M33 in an i.MX93 using a J-Link. If that is what you are looking for, I will gladly share the details with you. Just tell me your e-mail address or another way of contacting you directly. Regards, Malte Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hi, I just found this topic and was wondering if someone was finally able to find some reliable solution for working with M33 in separation from A55. Recently I have started creating development environment for upcoming project and pretty quickly got into the same trouble with triggering software reset. It's been some time since the thread was opened, SEGGER now (v8.10) provides software with builtin IMX targets, although still seems not capable of performing single core reset. I did some experiments with SCB (SYSRESETREQ) and SCR registers but just can't achieve anything stable. I had also quickly tested MCUXpresso plugin for VSCode and didn't notice any custom, working reset strategy implementation. Regards, Krzysztof Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hi Malkai, I am very much interested in a solution as I get exactly the same problem. Is it possible to send me your solution or advice? Many thanks. [email protected] Best regards Junshu Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hi Malte That would be much appreciated. My mail is [email protected] Best regards Niels Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hi Niels, no thanks to the NXP support, which is less than helpful, I worked out a solution for this problem. If you tell me your e-mail address or any other way of contacting you directly I will be glad to help you. Kind regards, Malte Kaiser Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @Sanket_Parekh  I'm in the exact same situation as the original author. It appears that the JLink script provided by NXP doesn't actually reset the M33 core, but only halts it. This leaves registers and processor state unchanged and if a fault was encountered, I'm not able to continue debugging properly without resetting the core through Linux first. Is there any way that I can trigger such a reset of the M33 core but using the JLink debugger? Best regards Niels Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello Sanket_Parekh, (1) Where can I get the NXP J-Link script patch for i.MX93 Cortex-M33? (2) According to Segger there is no roadmap yet to support i.MX93 in J-Link. But it make come in Q1/Q2. Is there any other possibilities to debug the Cortex-M33? BR Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @malkai , I hope you are doing well. "What is the procedure intended by NXP to reset the Cortex-M33 core in the i.MX93?" ->The System Reset Controller (SRC) is responsible for the generation of all the system reset signals and boot argument latching. ->Its main functions are as follows: • Deals with all global system reset sources from other modules and generates global system reset. • Responsible for power gating of MIXs (Slices) and their memory low power control. ->The SRC takes the POR_B from the PAD and fuse bits to complete the boot sequence and the GPC low power request to complete the power down/up sequence. Please refer to Chapter 33 System Reset Controller (SRC). https://www.nxp.com/webapp/Download?colCode=IMX93RM Thanks & Regards, Sanket Parekh Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @Sanket_Parekhm, thank you for your reply. However, that information does not help to solve the issue. As you know, the Cortex-M33 core in the i.MX93 has the Armv8-M architecture which does not have a VECTRESET bit in the AIRCR register (see D1.2.3 in https://developer.arm.com/documentation/ddi0553/latest/). So the only available reset request is SYSRESETREQ to which there is no reaction by the Cortex-M33 core nor by the entire system. Why is that? I already looked into the reset strategies used by the J-Link. The thing is, that the patch from NXP replaces these with just halting the CPU, as I told you. And the reset line cannot be used here, since it resets the entire SoC. So, the issue still remains: What is the procedure intended by NXP to reset the Cortex-M33 core in the i.MX93? Thank you and kind regards, Malte Kaiser Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @malkai , I hope you are doing well. ->The Reset selection controls the target device reset operation. All reset options apply to Cortex-M processor-based devices, are available in JTAG and SWD mode, and halt the CPU after the reset. ->Core - performs a reset of the Cortex-M core only by setting the VECTRESET bit. On—chip peripherals are not reset. For some Cortex—M devices, this reset method is the only way they may be reset. However, in most cases, this method is not recommended, because most target applications rely on the reset state of some peripherals (PLL, External memory interface, etc.) and may be confused if they boot up, but the peripherals are already configured. ->ResetPin - J-Link pulls its RESET pin low to reset the core and peripherals. Normally, this causes the CPU RESET pin of the device to go low as well, resulting in a reset of the CPU and peripherals. This reset method will fail if the RESET pin of the target device is not pulled low. Please refer to the section reset strategies in the below link. https://community.nxp.com/ pwmxy87654/attachments/ pwmxy87654/kinetis/28743/1/ UM08001_JLink.pdf Thanks & Regards, Sanket Parekh Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @Sanket_Parekh, thank you for your reply. Unfortunately, that information is not helping to solve my problem. In the meantime, I found out multiple things: 1. The J-Link script provided by NXP in the patch for the i.MX93 does not implement a reset. It replaces resetting the CPU with just halting it. 2. Requesting a reset by manually writing AICR.SYSRESETREQ to 1 through the debugger does not result in a reset of the Cortex-M33 core. So, my original question remains: What possibility exits to reset the Cortex-M33 through a debugger? Thanks and regards, Malte Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @malkai, I hope you are doing well. Please refer to this link, It will be helpful. https://community.nxp.com/t5/ i-MX-Processors-Knowledge- Base/All-Boards-JTAG/ta-p/ 1106822 ------------------------------ ------------------------------ ------------------------------ ----------------------------- Note: If this post answers your question, please click the Correct Answer button. ------------------------------ ------------------------------ ------------------------------ ----------------------------- Thanks & Regards, Sanket Parekh
View full article
MathWorks: Complimentary software and hardware support Hello Freescale Cup Teams,   MathWorks is pleased to support the 2015 Freescale Cup EMEA Competition! Take advantage of our: Complimentary Access to MATLAB & Simulink Your team is eligible for an offer of Complimentary Software Licenses. Your team leader or faculty advisor should review and complete the Student Competition Software Request Form http://www.mathworks.com/academia/student-competitions/software/Freescale_Cup_Offer%20of%20Complimentary%20Software%20License(s).pdf to take advantage of our software offer.   Deploy your Simulink models directly to the Freedom board and shield MathWorks is offering hardware support for the Freescale Cup hardware (FRDM-KL25Z, FRDM-MC-SHLD).  Find all relevant information on http://www.mathworks.com/hardware-support/frdm-kl25z.html and install your the package without additional fees. For more information visit the hardware support page http://www.mathworks.de/hardware-support/ and the MakerZone http://makerzone.mathworks.com/ .   Interactive tutorials There are a total of five tutorials, narrated by specialists from MathWorks that include interactive exercises to reinforce learning on our dedicated webpage: http://www.mathworks.de/academia/student-competitions/freescale-cup/ .   Technical support Send an email to [email protected] .   We are looking forward to working with you and wish you all the best.    Best regards, The MathWorks Student Competition Program  
View full article
How do I convert the voltage of digital signals? (Japanese blog) 0. Table of Contents 0. Table of Contents 1. What is a voltage level translator? 2. Digital signals 2.1 Various Digital Signals 2.2 CMOS and TTL: Logic level signals using simple voltage HIGH and LOW 2.3 Input/Output Voltage Specification: VOH/VOL and VIH/VIL 2.3.1 Output voltage specifications: VOH and VOL 2.3.2 Input voltage specifications: VIH and VIL 2.3.3 The relationship between VOH/VOL and VIH/VIL 3. Basic voltage level conversion method: One-way signal conversion 3.1 Examples where conversion is not necessary even if the chip's power supply voltage is different. Column: How are the TTL values VIH(min) = 2.0V and VIL(max) = 0.8V determined? 3.2 Examples requiring conversion 3.2.1 Conversion using open-drain output 3.2.2 Conversion using standard logic (general-purpose logic) chips 4. Conversion of bidirectional signals requiring automatic direction switching. 4.1 Bidirectional conversion using a single MOS transistor 4.2 Bidirectional conversion using dedicated equipment 4.2.1 I²C signal voltage conversion chip 4.2.2 High-speed bidirectional open-drain signal-to-voltage conversion chip 4.2.3 Bidirectional push-pull signal-to-voltage converter chip 4.2.4 I3C signal voltage converter chip 4.2.5 Buffer-based conversion 5. Summary 5.1 Comparison of methods/part numbers introduced in the blog 6. Reference materials 1. What is a voltage level translator? When connecting digital circuits, you can simply connect the signal lines directly... That's not the case; if the " logic level voltage " doesn't match, it may not work, become unstable, or in the worst case, damage the chip. That's where a voltage level translator (also called a voltage level shifter) comes in handy. A voltage level translator is a circuit that allows signals to be exchanged between digital circuits with different power supply voltages. For example, it is needed in the following cases: 3.3V microcontroller ↔︎ 5V sensor connection Connecting a 1.8V FPGA to 3.3V peripheral devices スクリーンショット 2025-08-21 12.39.23.png Figure 1: Differences in signal voltage   This blog explains the differences in voltage levels between various types of logic circuits used in digital circuits (*TTL, *LVTTL, *CMOS), and the important meanings of VOH / VOL / VIH / VIL for determining them. Furthermore, it explains which voltage level translator to choose from among various conversion methods. Furthermore, this blog will look at specific examples of voltage level translators that automatically detect and convert the direction of a signal . NXP also offers voltage level translators for SD cards/SIM cards and application-specific translators such as GTL↔︎TTL level conversion, but this blog will focus on products targeted at general-purpose or serial bus applications. *TTL (Transistor-Transistor Logic) *LVTTL (Low Voltage Transistor-Transistor Logic) *CMOS (Complementary Metal-Oxide-Semiconductor) *GTL (Gunning Transceiver Logic) 2. Digital signals   2.1 Various Digital Signals So-called "digital signals" are electrical representations of logic levels 1 and 0. Historically, there have been various circuit design methods for handling these logic levels 1 and 0. These include methods that represent logic levels with simple voltage HIGH and LOW, and methods that use voltage differences to represent HIGH/LOW. TTL simply represents HIGH/LOW as 5V/0V. Further reducing the voltage of TTL to 3.3V/0V, such as LVTTL , are systems where the voltage level is determined based on a bipolar transistor circuit. Similarly, ECL (Electronic Classification) uses bipolar transistors but employs a negative power supply to implement low-amplitude, differential operation logic levels, resulting in higher speeds. GTL (Global Transistor Lapping) uses a reference voltage to transmit HIGH/LOW signals with low-amplitude single-ended signals, etc. Furthermore, even with a simple HIGH/LOW representation, the 4000 series of CMOS general-purpose logic, developed with the aim of reducing power consumption, allowed the use of 3V to 18V as the HIGH level. https://en.wikipedia.org/wiki/Logic_family This blog will explain how to handle voltage levels in TTL (LVTTL) and CMOS, which represent logic using simple HIGH and LOW voltages , among the various logic levels mentioned above. Other signal conversions utilize dedicated chips and are therefore not covered here. In addition, in recent years, semiconductor technology has become smaller, faster, and more power-efficient, and the voltage used for power supplies has been decreasing. For this reason, voltage level translators, which bridge the signal voltage difference, have become particularly important. スクリーンショット 2025-08-21 12.42.23.png Figure 2: Signal waveform - Voltage levels (HIGH/LOW) represent logic levels.   2.2 CMOS and TTL: Logic level signals using simple voltage HIGH and LOW In digital circuits, simple voltage-based logic level signals using HIGH and LOW typically use the power supply voltage for HIGH and 0V for LOW. As long as the HIGH/LOW voltage levels are the same, the signals can be transmitted even if the power supply voltages are different. For example, TTL (LVTTL) interprets an input signal as HIGH if it is 2.0V or higher, and LOW if it is 0.8V or lower. Because of this convention, the HIGH/LOW voltage levels of TTL signals do not change even if the power supply voltages are different. On the other hand, CMOS defines HIGH/LOW based on half the power supply voltage. Therefore, the HIGH/LOW voltage levels of CMOS change when the power supply voltage is different. スクリーンショット 2025-08-21 12.52.04.png Figure 3: Input signal voltage specification   2.3 Input/Output Voltage Specification: V OH / V OL and V IH / V IL In digital circuits, the voltages output as HIGH and LOW , and the voltage used to determine whether an input signal is HIGH or LOW, are specified. These are defined in the specifications of each chip used, so you need to check the datasheet. V OH : High-level output voltage VOL : Low-level output voltage V IH : High-level input voltage V IL : Low-level input voltage 2.3.1 Output voltage specifications: V OH and V OL When considering the output, you must take into account the current required when outputting HIGH/LOW signals. The current will increase or decrease depending on the load. The voltage that can be guaranteed at the maximum outflow current with HIGH output is called VOH (min) , and the voltage that can be guaranteed at the maximum inflow current with LOW output is called VOL (max) . V OH (min) is the voltage output when the upper transistor in the circuit's output stage is turned ON. This transistor has a resistance called "ON resistance". When a large current flows out of a transistor, a voltage is generated equal to "the transistor's resistance x the current flowing through it". This causes the output voltage to drop below the power supply voltage by that amount, resulting in a low VOH . Therefore, VOH (min) is the minimum voltage that can be guaranteed when the maximum expected outflow current is reached. スクリーンショット 2025-08-21 12.53.04.png Figure 4: Digital signal output circuit (push-pull)   スクリーンショット 2025-08-21 12.53.18.png Figure 5: HIGH output voltage varies depending on the load.   VOL is the opposite. When the lower transistor in the output stage of the circuit is turned ON, if the incoming current is large, the output will rise above 0V due to the voltage generated by the ON resistance of the transistor, as described above. Taking this into consideration, VOL (max) is the maximum voltage that can be guaranteed when the maximum incoming current is anticipated. スクリーンショット 2025-08-21 12.53.31.png Figure 6: LOW output voltage also changes depending on the load.   2.3.2 Input voltage specifications: V IH and V IL The input has voltage levels to determine HIGH and LOW : V IH (min) and V IL (max) . If the voltage is above V IH (min), it is judged as HIGH; if it is below V IL (max), it is judged as LOW. In CMOS inputs, half the power supply voltage serves as the reference for HIGH and LOW, but this is not directly used as V IH (min) and V IL (max). This is because the threshold can fluctuate due to variations between chips. Also, to mitigate glitches caused by noise on slow-rising signals appearing in the output, it is common practice to incorporate hysteresis into the input. For these reasons, V IH (min) and V IL (max) are defined with a certain voltage difference. 2.3.3 The relationship between VOH / VOL and VIH / VIL For normal signal exchange to occur, the relationship between the output and input must satisfy the following equation. HIGH level: V OH (min) > V IH (min) LOW level: VOL (max) < VIIL (max) If this relationship is maintained, the output circuit can correctly transmit HIGH/LOW signals to the next input circuit. Furthermore, the voltage difference between them, "V OH (min) - V IH (min)" and "V IL (max) - V OL (max)," becomes the " noise margin " and serves as a guideline for maintaining high noise immunity. スクリーンショット 2025-08-21 12.55.13.png Figure 7: V OH (min) / V OL (max) and V IH (min) / V IL (max) 3. Basic voltage level conversion method: One-way signal conversion   3.1 Examples where conversion is not necessary even if the chip's power supply voltage is different. Voltage level conversion is generally not necessary when the relationships "V OH (min) > V IH (min)" and "V OL (max) < V IL (max)" hold true. For example, although TTL and LVTTL use different power supply voltages for their respective chips, the input and output voltage specifications are the same . In both TTL (5V) and LVTTL (3.3V), V OH (min) is 2.4V and V OL (max) is 0.4V. Since V IH (min)/V IL (max) are also 2.0V/0.8V in both cases, they can be connected to each other without any problems. However, caution is required if the output voltage is higher than the power supply voltage of the input chip. If the output chip uses a 5V power supply and the input uses a 3.3V power supply, the input must support " 5V tolerant input ". A 5V tolerant input is an input that can operate without problems even when a 5V HIGH signal is connected to the input of a chip that operates on a 3.3V power supply voltage. While typical chip inputs have ESD protection circuits to protect against static electricity, if this ESD protection circuit is configured as shown in the following diagram, a 5V input can cause current to flow back from the input to the 3.3V power supply, potentially damaging the chip. A 5V tolerant input is designed to prevent such problems. Tolerant inputs do not lack ESD protection; they incorporate an ESD protection circuit that is structured to handle signals higher than the power supply voltage without causing problems. ESD protection diodes like the one shown in Figure 7 can also cause problems when the power to the input chip is turned off. In systems where the power to each chip is controlled individually, the output signal may feed back into the power supply even when the input chip is off, causing the input chip to operate. スクリーンショット 2025-08-21 12.57.16.png Figure 7: ESD protection diode - non-tolerant input Column: How are the V IH (min) = 2.0V and V IL (max) = 0.8V determined for TTL? While the input threshold of CMOS is based on the midpoint of the power supply voltage (VCC/2), the V IH (min)/V IL (max) of TTL is 2.0V/0.8V, which is not a particularly neat ratio with respect to the power supply voltage (5V). This is related to the fact that the input stage of TTL is composed of bipolar transistors. スクリーンショット 2026-06-20 6.45.38.png Example of the internal circuit of a standard TTL logic IC: SN7400 (2-input NAND). This information was included in the "Latest General-Purpose Logic Device Specifications Table 1988" (CQ Publishing). A typical TTL gate's input stage consists of a multiple emitter input transistor and a subsequent phase splitter transistor, both connected in series. The "switching threshold," at which the gate actually begins to react, is determined by the forward voltage of the PN junctions in these two stages. Since the forward voltage of a single silicon PN junction is approximately 0.6 to 0.7V, the combined forward voltage of the two stages is approximately 1.3 to 1.5V, which is the effective switching threshold for a TTL gate. However, this value of approximately 1.4V is merely a "typical value," and it will fluctuate from lot to lot and from condition to condition due to individual differences and variations in temperature. Therefore, the specified values V IH (min) and V IL (max) on the datasheet are defined as guaranteed values, with sufficient margins above and below this typical value of approximately 1.4V, meaning that "if it drops to this level, it can be reliably determined to be LOW (V IL (max) = 0.8V)" and "if it rises to this level, it can be reliably determined to be HIGH (V IH (min) = 2.0V)." Furthermore, this value is not determined in isolation, but is designed taking into account the relationship between VOH and VOL , as explained in Section 2.3.3. In standard TTL, due to the output stage configuration, the HIGH output is not the power supply voltage, but a slightly lower voltage (lower by the voltage generated by the 130Ω resistor, transistor, and diode in the circuit example above) (VOH(min)=2.4V). When this is combined with VOL(max)=0.4V, HIGH noise margin: V OH (min) − V IH (min) = 2.4 − 2.0 = 0.4V Low-side noise margin: V IL (max) − V OL (max) = 0.8 − 0.4 = 0.4V As shown, it is designed to ensure a noise margin of 0.4V symmetrically above and below. In other words, the 2.0V/0.8V figures for TTL, which may seem "odd" relative to the power supply voltage, are actually reasonable values derived from two requirements: the physical reality of the bipolar transistor junction voltage and the noise margin design. スクリーンショット 2026-06-20 8.20.24.png This image shows an SN7420 (4-input NAND) with three input pins set to HIGH and one pin receiving a 100kHz triangular wave (ch1). The output under no load (ch2) is less than 4V when HIGH (Vcc=5V). The circuit introduced in this column is an example of a standard TTL without a designation (such as 74 LS 00 or 74 HC 00, without LS/HC prefixes; sometimes called "vanilla TTL" in English), but the reason why the V IH /V IL specifications are the same (bipolar junction characteristics of the input stage) is common to other TTL families such as the 74LS.   3.2 Examples requiring conversion   While TTL and LVTTL connections are possible because the voltage levels are aligned, mismatches in logic levels often occur when connecting CMOS chips with different power supply voltages, or when connecting a CMOS chip to a TTL chip. This occurs when the aforementioned relationship "V OH (min) > V IH (min)" and "V OL (max) < V IL (max)" does not hold true, or when the difference becomes too small, resulting in insufficient noise margin. A voltage level translator solves this problem. スクリーンショット 2025-08-21 12.56.11.png Figure 9: Example of mismatched logic levels (1): Insufficient HIGH voltage input   スクリーンショット 2025-08-21 12.56.20.png Figure 10: Example of mismatched logic levels (2): Insufficient LOW voltage is input.     3.2.1 Conversion using open-drain output There are ways to easily adjust voltage levels without using a voltage level conversion chip. If the signal direction is fixed from the output chip to the input chip and does not switch, then this method involves making the HIGH output an open-drain output to match the input voltage. An open-drain output is a configuration in which the upper transistor of the output stage of a digital circuit is absent, and the HIGH voltage is obtained by a pull-up resistor connected to the power supply voltage of the input chip . スクリーンショット 2025-08-21 12.58.18.png Figure 11: Digital signal output circuit (open drain)   Open drains are a simple and inexpensive method, but there are a few things to keep in mind . First, the output side must be capable of open-drain output. Many microcontrollers' GPIO pins can provide this type of output through configuration. First, the output side must be capable of open-drain output. Many microcontrollers' GPIO pins can provide this output through configuration. If the output is fixed to push-pull output and cannot be configured for open-drain output, an external transistor or similar device will be needed to convert it to open-drain output. Furthermore, the selection of pull-up resistors is also important. A pull-up resistor is necessary to obtain a HIGH voltage, but if the resistance value is too small, the current flowing when the output is LOW will be large (similar to a heavy load), which will increase power consumption and lead to an increase in VOL . Conversely, if the value is too large, it will be affected by the capacitance of the wiring and pins, causing the rise time from LOW to HIGH to be slow, resulting in a decrease in communication speed. 3.2.2 Conversion using standard logic (general-purpose logic) chips For simple voltage level conversion, you can also use standard logic. For example, Nexperia's 74AVCH4T245 is a general-purpose CMOS logic chip that can perform 4-bit bidirectional level conversion. This chip can convert signals from 0.8V to 3.6V, and the signal direction can be switched using the DIR pin. The signal speed depends on the voltage being converted, but it can support speeds of approximately 100M to 380Mbps. スクリーンショット 2025-08-22 3.29.11.png Figure 12: Example of standard logic - 74AVCH4T245 This chip enables high-speed bidirectional voltage conversion of signals, but the direction must be controlled by an external signal. While such control is possible with signals like READ/WRITE on a parallel bus, it is difficult to apply to communications like serial buses where the communication direction switches depending on the protocol. スクリーンショット 2025-08-22 3.29.26.png Figure 13: Example of standard logic. The signal direction must be specified externally. 4. Conversion of bidirectional signals requiring automatic direction switching. The "open-drain output" and "voltage conversion methods using standard logic chips" introduced so far mainly perform conversion in only one direction, or require switching of direction by an external signal. Communication methods like I²C and I3C , where the direction of the signal changes dynamically, require " bidirectional voltage level conversion " that automatically detects and switches the direction. Controlling the direction of such signals externally is difficult, and it is challenging to implement this with the buffer chips mentioned above. Furthermore, since I²C is an open-drain signal, it is not possible to connect standard open-drain logic buffers in opposite directions. Figure 14 shows an example of this, where open-drain buffers are connected in opposite directions. There is no problem when both sides of the buffer are HIGH, but once one of them goes LOW, the buffers will keep pulling the other input LOW and will not be able to return to HIGH. スクリーンショット 2025-08-22 3.29.39.png Figure 14: A typical open-drain buffer cannot automatically switch between bidirectional communication.   4.1 Bidirectional conversion using a single MOS transistor   Until now, simple circuits have sometimes been used for I²C signal-to-voltage conversion. We will present the simplest method, using a MOS transistor, as an example. VLT_by_MOS.png Figure 15: Example of conversion using a MOS transistor   Figure 15 is taken from the I²C specification version 2.1 (2000) and shows an example where two MOS transistors (TR1, TR2) are used to convert 3.3V and 5V signals, respectively. Although such a simple conversion example using only transistors has been removed from the current I²C specification due to the problems described later, it is included here to understand the principle . The I²C signal lines, called SDA and SCL, are both open-drain bidirectional signals. Pull-up resistors are connected to the 3.3V and 5V sides, respectively. In this circuit, when the 3.3V and 5V signals are HIGH, the gate (g) and source (s) of this transistor are at the same potential, so the source (s) and drain (d) are OFF, and the connection between them is broken. When 3.3V changes to LOW in this state, the 3.3V side transistor (between s and d) turns ON , and the 5V side signal also goes LOW . When the 3.3V side changes to HIGH and the 5V side changes to LOW , the parasitic diode (body diode) connecting the 3.3V side to the 5V side first turns ON . When the diode turns ON, the source(s) voltage drops . As a result, the transistor turns ON , and the signal on the 3.3V side also becomes LOW . While this very simple mechanism using a transistor as a switch allows for voltage level conversion, there are problems. Transistor variations affect the threshold voltage for signal conversion. Furthermore, with the increasing need to handle lower signal voltages, for example, at signal voltages of around 1V, such a circuit cannot operate because it cannot obtain a sufficient gate-to-source voltage (Vgs). Addendum: The same circuit as in Figure 15 is still publicly available as application note AN10441 "Level shifting techniques in I²C-bus design" from Nexperia , a company formed when the semiconductor discrete/logic products business was spun off from NXP. The application note was first published in 2007 (Rev.01) separately from the I²C specification, and was revised under the Nexperia brand in 2020 (Rev.2). 4.2 Bidirectional conversion using dedicated equipment   By using a dedicated voltage level translator IC , voltage level conversion for bidirectional communication buses such as I²C and I3C can be easily performed. 4.2.1 I²C signal voltage conversion chip The PCA9306 and NVT20xx series ( NVT2001/02 , NVT2003/06 , NVT2008/10 ) are voltage level translators specifically designed for bidirectional signal conversion. These chips can handle multiple signal lines (multi-bit signal lines) simultaneously. While they are designated as I²C signal voltage conversion chips, they can also be used for other purposes (such as SPI and other push-pull signals) if the signal specifications match . The PCA9306 and NVT20xx series share the same internal structure, and the pull-up resistor only needs to be connected to the higher voltage side if the voltage difference to be converted is 1V or more . Figure 16 shows its internal structure and connection to external chips (excerpted from Fig. 2 of Application Note AN11127 : "Bidirectional voltage level translators NVT20xx and PCA9306" ). This chip contains the number of signal lines (bits) + 1 MOS transistors. Each transistor has a structure in which the source and drain are interchangeable. The transistors in the signal transmission path are called pass transistors , and the remaining one is called a reference transistor . スクリーンショット 2025-08-22 15.56.50.png Figure 16: NVT20xx (PCA9306) - Diagram illustrating chip operation.   Looking at the circuit, the gate and drain of the reference transistor are shorted and connected to the higher voltage power supply via a 200kΩ resistor. The remaining terminal of the reference transistor, the source, is connected to the lower voltage power supply. With this connection, the reference transistor acts as a single diode , and its gate voltage is one diode higher than the lower voltage power supply . The remaining pass transistor has its drain connected to the high-voltage signal line and a 1kΩ pull-up resistor, its source connected to the low-voltage signal line, and its gate connected to the gate of the reference transistor. When both the high and low signals of the pass transistor are HIGH, the high-voltage side becomes the voltage pulled up by the 1kΩ resistor . A pass transistor forms a circuit known as a "source follower." The terminal on the lower voltage side (source terminal) has a voltage that is lower than the voltage applied to the gate by the amount of Vgs required to turn the transistor ON . In other words, it has the same voltage as the low-voltage power supply. The transistor is in a semi-ON state (operating in the linear region), neither ON nor OFF. In this state, when either the high or low signal becomes LOW , the voltage difference between the gate and the signal terminal causes the transistor to turn ON (operating in the saturation region where it is fully ON), and the other terminal also becomes LOW . The signal speed that this series can handle is affected by the pull-up resistor and the capacitance of the signal line. The datasheet states that the PCA9306 can handle up to 2MHz. The NVT20xx series can handle signal speeds up to 33MHz with a 192Ω pull-up resistor and a capacitance of 50pF. For signals around 1MHz, it will work without problems even if you don't worry too much about the pull-up resistor and capacitance (assuming it's within the range typically used for I²C). However, when using this chip to handle higher-speed signals in a push-pull configuration, a thorough understanding of its characteristics and careful component selection are necessary. Details of the operation of this type of voltage level translator are described in the article " The Internals and Operation of the PCA9306 ". 4.2.2 High-speed bidirectional open-drain signal-to-voltage conversion chip We introduce the NTS030x series ( NTS0302JK , NTS0304E ) as high-speed bidirectional open-drain signal conversion chips. This chip can perform 2-bit or 4-bit bidirectional signal conversion and can handle signals up to 2Mbps (1MHz) for open-drain signals and 20Mbps (10MHz) for push-pull signals.   スクリーンショット 2025-08-22 15.59.57.png Figure 17: NTS030x - Internal Chip Block Diagram   Figure 17 shows the internal structure of one signal bit in the NTS030x. In the diagram, transistor T3 is a pass-through transistor , and a gate terminal bias voltage is applied to it, so it turns ON when either the signal labeled A or B goes LOW. When both A and B are HIGH, T3 turns OFF, and since A and B are connected to their respective power supplies with relatively large pull-up resistors (10kΩ), they will have their respective voltages. This chip has T3, as well as T1 and T2 . These T1 and T2 are used for a function called " edge rate accelerator ." We will focus on one of them, T1, and explain its operation. T1 is placed on the A side, with its source terminal connected to the A signal and its drain terminal connected to the A side power supply. The gate terminal is connected to the block labeled "ONE-SHOT AND SLEW RATE CONTROL" that controls it. The "ONE-SHOT AND SLEW RATE CONTROL" block is connected to the B signal on the opposite side and detects the change from LOW to HIGH in the B signal . When this is detected, T1 is temporarily turned ON, bypassing the 10kΩ pull-up resistor and allowing current to flow, thereby accelerating the change from LOW to HIGH in the A signal . By speeding up the rise time of the signal in this way, it becomes possible to handle faster signals. Incidentally, the slew rate when T1 is turned ON is controlled, taking into consideration the suppression of ringing caused by a sudden increase in current. The other T2 uses the same mechanism but in the reverse direction, and is applied to the B-side signal as well. The NTS series has another user-friendly feature . In the case of the MOS transistors and PCA9306/NVT20xx described so far, there was a problem in that if one power supply was turned off, the signal of the other would be set to LOW. To solve this problem, the NTS030x operates so that when both power supplies are not ON, the signal pins are set to a high impedance state to prevent them from affecting each other . By using this function, it becomes possible to partially control the ON/OFF state of the system's power supply . The NTS010x series ( NTS0102 , NTS0104 ) is equivalent to the NTS030x series, but lacks slew rate control functionality to handle higher-speed signals. An evaluation board, NTS0304EUK-ARD, is available for the NTS0304E to allow for quick and simple operational verification. For an overview of the NTS0304EUK-ARD board and how to operate it, please refer to this video , "How to operate the NTS0304EUK-ARD" . 4.2.3 Bidirectional push-pull signal-to-voltage converter chip Furthermore, for use with push-pull signals only, there is the NTB010x series ( NTB0102 , NTB0104 ), which offers a faster option. When stable in a HIGH or LOW state, the signal is driven through a 4kΩ resistor. Similar to the NTS030x series, it has a one-shot function on both the HIGH and LOW sides, and has a mechanism that uses this to change the signal on the opposite side when there is a change in the signal at either terminal. This mechanism enables signal-to-voltage conversion at speeds of 70-80 Mbps while also having an automatic signal direction detection function.   スクリーンショット 2025-08-22 16.04.45.png Figure 17: NTB010x - Internal Chip Block Diagram 4.2.4 I3C signal voltage converter chip I3C has a specification that switches between open-drain and push-pull communication modes . In open-drain mode, it is compatible with I²C and operates at frequencies up to 4MHz . In push-pull mode, a 12.5MHz clock is used. Since the signal voltage is usually in the range of 1V to 3.3V, a voltage level translator that operates according to the signal specifications is required when there is a voltage difference. Figure 18 shows the internal block diagram of one bit of the P3A1604 . As shown in the figure, this chip incorporates a mechanism to accelerate not only the LOW→HIGH change but also the HIGH→LOW change, as well as a pull-up resistor that can be switched ON/OFF.   スクリーンショット 2025-08-22 16.28.46.png Figure 18: P3A1604 - Chip internal block diagram The P3A1604 is a 4-bit I3C voltage level translator. A 2-bit version, the P3A9606 , is also available.   4.2.5 Buffer-based conversion Another method for converting bidirectional signals is to use a dedicated buffer. The primary purpose of a buffer is to enhance driving capability and separate the capacitance of connected signal lines, but there are also products that support voltage conversion. As explained in this blog, simple buffers cannot mutually buffer bidirectional open-drain signals. Therefore, various buffer products with special features for bidirectional open-drain signals are available. I will explain more about buffers on a later occasion. 5. Summary Voltage level translators are essential components for safely and reliably exchanging signals between digital circuits with different power supply voltages. Understanding the definitions of logic levels such as TTL, LVTTL, and CMOS, as well as the relationships between VOH/VOL/VIH/VIL, allows you to select the appropriate connection and conversion method. For unidirectional conversion, open-drain outputs or standard logic ICs can be used, while for bidirectional conversion, MOS transistors or dedicated ICs (such as the PCA9306/NVT/NTS/NTB/P3A series) can be used. Voltage level translators with automatic signal direction detection capabilities are particularly useful for buses requiring bidirectional communication, such as I²C and I3C. Furthermore, recent advancements in semiconductor technology have led to lower voltages and higher speeds, requiring more precise voltage level control. While there are many methods and options for voltage level conversion, it is important to select the optimal method and components according to the application, taking into account signal specifications, speed, and system power management. 5.1 Comparison of methods/part numbers introduced in the blog Method/Part Number Purpose Number of bits Direction change Open wiring compatible Low voltage side [V] High voltage side [V] Bitrate [bps] Conversion with open-drain output General purpose 1 unidirectional - - - - Standard logic (e.g., 74AVCH4T245) General purpose (parallel bus, etc.) 4 + 4 External control Not supported 0.8 ~ 3.6 0.8 ~ 3.6 100M ~ 380M Bidirectional conversion using a single MOS transistor I²C, General Purpose 1 automatic correspondence Depending on the transistor specifications ~ 1M PCA9306 I²C, General Purpose 2 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz, depending on conditions) NVT2001 I²C, General Purpose 1 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2002 I²C, General Purpose 2 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2003 I²C, General Purpose 3 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2006 I²C, General Purpose 6 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2008 I²C, General Purpose 8 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NVT2010 I²C, General Purpose 10 automatic correspondence 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz @ open drain), 66M (33MHz @ optimized conditions) NTS0302JK I²C, SPI, General Purpose 2 automatic correspondence 0.95 ~ 3.6 1.65 ~ 5.5 2M @ Open Drain, 20M @ Push Pull NTS0304E I²C, SPI, General Purpose 4 automatic correspondence 0.95 ~ 3.6 1.65 ~ 5.5 2M @ Open Drain, 20M @ Push Pull NTS0102 I²C, SPI, General Purpose 2 automatic correspondence 1.65 ~ 3.6 2.3 ~ 5.5 50M @ Push-Pull NTS0104 I²C, SPI, General Purpose 4 automatic correspondence 1.65 ~ 3.6 2.3 ~ 5.5 50M @ Push-Pull NTB0102 SPI, General Purpose 2 automatic Not supported 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M NTB0104 SPI, General Purpose 4 automatic Not supported 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M P3A9606 I3C, I²C, SPI, General Purpose 2 automatic correspondence 0.72 ~ 1.98 0.72 ~ 1.98 (12.5MHz) P3A1604 I3C, I²C, SPI, General Purpose 4 automatic correspondence 0.72 ~ 1.98 1.62 ~ 3.63 6.8M @ Open Drain, 40M @ Push Pull Table 1: Comparison of methods/part numbers introduced in the blog   6. Reference materials Product introduction page: Voltage Level Converter NXP System Management I2C, I3C, SPI Selector Guide I2C Bus Specifications and User Manual (Rev5.0) (Japanese version) I2C Bus Specifications and User Manual (Rev7.0) English version) NXP Community Blog: I3C Bus Overview – The Next Serial Bus Japanese Webinar Video: "The Basics of the Next-Generation Interface 'I3C' That You Need to Know Now" Qiita @teddokano: PCA9306's internals and operation Change history: 2025-08-28: First Edition 2025-08-28: Added information about NTS0304EUK-ARD and a link to the blog with the video. 2026-04-10: Correction of low voltage side [V] and high voltage side [V] in Table 1. 2026-06-20: Section 3.1 "Column: VIH (min) of TTL" Added "How are VIL(max) = 2.0V and VIL(max) = 0.8V determined?". Added internal circuit example of standard TTL logic IC: SN7400 (2-input NAND) and output waveform of SN7420. 2026-07-10: Added to Section 4.1 that the circuit in Figure 15 is also published as Nexperia application note AN10441. ========================= We are currently unable to respond to comments left in the "Comment" section of this post. We apologize for the inconvenience, but please refer to " Technical Questions to NXP - How to Contact Us( Japanese Blog) " when making an inquiry. (If you are already an NXP distributor or have a relationship with NXP, you may ask your representative directly.) This blog explains the differences in voltage levels between various types of logic circuits used in digital circuits (*TTL, *LVTTL, *CMOS), and the important meanings of VOH , VOL , VIH , and VIL for identifying them. Furthermore, we will explain which voltage level translator to choose from among the various conversion methods. We will take a closer look at the conversion of bidirectional open-drain signals , which requires special handling. スクリーンショット 2025-08-21 12.52.04.png Interface Introduction Japanese Blog
View full article
TapLinx Package Key & DESFire EV3 Default PICC Key Clarification I recently procured MIFARE DESFire EV3 cards and would like to confirm whether they use a known factory-default PICC master key (e.g. all-zero AES/2K3DES/DES), or if the key is card-vendor dependent. My intention is to verify this via the TapLinx Android sample application by authenticating to the PICC (KeyNo 0). However, to build the sample APK, a valid TapLinx packageKey must be defined in the code:   static final String packageKey = ""; Before proceeding with building the test app, could you please confirm: Whether there is a documented default PICC master key for DESFire EV3 cards, and How to generate or obtain the appropriate TapLinx packageKey for my application. Thank you for your guidance. Code examples Example code Getting Started Licensing Re: TapLinx Package Key & DESFire EV3 Default PICC Key Clarification Hello, Thank you for your interest in our products. As you may already know, MIFARE DESFire is a restricted product and requires to have an NDA in order to get further information. My recommendation is to please contact any of our Distributors. Answering your second question, please take a look at the TapLinx site: TapLinx SDK for MIFARE, NTAG, ICODE and UCODE | NXP Semiconductors In the Documentation section, you will find the relevant User Guide for your development platform. Each document explains how to create your own user and register your application.
View full article
88Q9098: STA モードで ofdma/mu-mimo を有効/無効にすることは可能ですか? 私はこの答えを見つけるためにSO一生懸命努力してきましたが、できませんでした。 私が望んでいたのは、有効/無効にする機能を追加することでした DL-OFDMA、UL-OFDMA、DL-MU-MIMO、次回 AP に接続するときの UL-MU-MIMO これらを有効にするのはAPによって行われることは承知していますが、 しかし、それがどのような形をとるかは気にしません。例えば、能力を変えるとか、 私はこれを次のように動作させたいのです: DL-OFDMAを有効にすると、APがそれを使用しようとすると動作します。 STA で無効にすると、AP が無効にしようとしても機能しなくなります。 可能であれば、それは完璧です。 しかし、たとえそれが不可能であっても、私はSO感謝します。 本当にあなたの助けが必要です。 よろしくお願いします。 Re: 88Q9098: Is it possible to enable/disable ofdma/mu-mimo in STA mode? サポートありがとうございます Re: 88Q9098: Is it possible to enable/disable ofdma/mu-mimo in STA mode? こんにちは@nhk OFDMA/MU-MIMO 機能は AP 側でのみ設定できます。STA はこれを無効にできませんでした。STA は AP によって指定された通信プロトコルを使用して通信します。 よろしくお願いいたします。 ショーン
View full article
TagXplorer - 没有可用的阅读器 我花了几个小时尝试将 TagXplorer 与 Identiv uTrust 3700 阅读器连接起来,但无法成功。我尝试用 OpenJDK 和 Oracle Java 8 运行 TagXplorer。无论我怎么尝试,用户界面(和日志)总是显示"没有可用的阅读器" 。 我已经安装了 Identiv 驱动程序。我使用的是 macOS 11.1,我已经在“安全与隐私”中启用了 java 的启用输入。 有人遇到过这样的问题吗? Re: TagXplorer - No reader available 我在使用 TagXplorer 时也遇到了同样的问题,为了找到可靠的解决方案,我一直很苦恼。我偶然发现了一个有助于简化收入计算的工具,在计划过程中使用加州净工资资源,就更容易准确地估算出实得金额。希望这能帮助其他同样受困于没有阅读器的人。 Re: TagXplorer - No reader available 我曾在 Mac 上试用过一段时间,但在遇到一个又一个问题后,最终改用了 Windows。 Re: TagXplorer - No reader available 你好 我在Mac上遇到了同样的问题,MAC OS Sonoma,也是使用Identiv uTrust 3700读卡器。我直接从Identiv网站上安装了驱动程序 我的 Java 版本是 1.8.0_421,虽然可以通过其他应用程序(如 NFC 工具)访问阅读器,但 "no reader available" 。 有谁在 MAC 上取得了成功? 非常感谢! Re: TagXplorer - No reader available 更新: 我第三次重新安装了驱动程序,现在可以连接标签了。但在我尝试运行的每个操作中(例如"读取 NDEF") 我现在得到的信息是"没有可用的支持阅读器" 。 Re: TagXplorer - No reader available 我用 sudo 命令运行该命令,在 TagXplorer 中找到了阅读器。 但是标签不会出现,当在阅读器上放置 NFC 标签时,LED 会发出一些信号,但是在 TagXplorer 中点击 " Connect Tag " 之后我会收到消息 " 税收不可用 "。 Re: TagXplorer - No reader available 有人解决了这个问题吗? 我这里也有同样的问题 Re: TagXplorer - No reader available 有人在 Mac 上解决了这个问题吗? 在 Windows 10 上,我把 Open FX Directories 放在了与 TagXplorer 相同的目录下,这一切都很完美,但在我的两台 Mac 上,TagXplorer 却无法看到阅读器。 我试着把驱动程序的 symobilc 链接放到与 TagXplorer 相同的目录下,但没有成功。 我可以看到读卡器已插入 USB 上的设备。 似乎与上述问题相同--在 64 Intel 上运行 12.5。 附上 Mac 目录运行时的屏幕截图。 我把 OPen FX 代码放在应用程序的一个文件夹中,然后在终端运行以下命令,成功地在 TagXplorer 目录中运行 TagXplorer: java --module-path /Applications/javafx-sdk/lib --add-modules javafx.controls,javafx.fxml -jar TagXplorer-v1.2.jar   欢迎就如何让 TagXplorer 看到阅读器提出任何想法 🙂   Re: TagXplorer - No reader available 我也遇到了和你完全一样的问题。 Re: TagXplorer - No reader available 您能否更具体地说明您是如何将其与 JavaFX 结合使用的?(安装 + 启动 TagXplorer) Re: TagXplorer - No reader available 更新: 在卡塔琳娜上,在我的一台老式 2013 Macbook Pro 上,阅读器没有通过 USB Adam Elements 6 端口 USB-C HUB 插入,而是直接插入 USB 2.0 端口,并且安装了 Oracle Java 9,阅读器立即就能读取。运行 jar 的输出显示与上述相同。 那么,卡塔利娜与大苏尔的对比可能是?pcsctest 确实检测到了阅读器。 working.png   pcsctest.png   Re: TagXplorer - No reader available @aaronqli @piotr_arteia 我现在已经在 Ubuntu 20.04 上试过了,结果大致相同。我采取的步骤是 在 Virtualbox 上安装 Ubuntu 按照设置指南安装 uTrust 3700 F 的驱动程序 安装 Oracle Java 9,因为其中包括 JavaFx - 检查版本 启动机器-使用 pcsc_scan 检查读卡器是否已连接(参见屏幕截图) 运行 TagXplorer - 结果与 MacOS 上一样,没有连接阅读器 utrust-connected.jpg   java-installed.jpg   run-tagxplorer.jpg   result.jpg   本主题中是否有人对此有其他想法。如果有任何建议,我将不胜感激。我还附上了运行 jar 时的输出结果。 Re: TagXplorer - No reader available @aaronqli非常感谢你的更新。 🙂 我尝试使用 Oracle Java 11,但仍然没有显示。您使用什么命令运行 jar?你引用了 javafx 吗?如果是,是哪个版本?最后是 .jarTagXplorer 1.2?我真的很感谢您的帮助,这让我有点抓狂。 Re: TagXplorer - No reader available 给你们的快速更新:在我安装了 Oracle Java 11 的笔记本电脑(Big Sur,Macbook Pro late 2017)上运行正常。也许罪魁祸首是 OpenJDK / JavaFX Re: TagXplorer - No reader available 最后,我成功地在 Windows 10 电脑上实现了这一功能。 我在上一篇文章中说得不够准确。Windows 机器上的问题是 TagXplorer 无法启动。我成功地使用了这里给出的解决方案 https://community.nxp.com/t5/NFC/TagXplorer-v1-2-jar-cannot-start/m-p/918596#M5608,在第二次尝试启动应用程序时,它确认了设备。 我还是没有办法在 Mac 上做到这一点。 感谢您的回放! Re: TagXplorer - No reader available @piotr_arteia不幸的是,我这边没有。我有点困惑。 Re: TagXplorer - No reader available 这里也有同样的问题。 在 MacOS Catalina、BigSur 和 Windows Home 上检查了最新的 JDK 和驱动程序。 计算机能看到读取器,但 TagXplorer 却看不到。 @aaronqli,@WillHill,@Jonmixnblend你弄明白了吗? @Kan_Li,@IvanRuiz请提供帮助! Re: TagXplorer - No reader available 我的情况与@WillHill完全相同,但安装了 Big Sur 11.2.3、uTrust 3700F、uTrust 驱动程序。 使用: openjdk 15.0.2 2021-01-19 OpenJDK 运行时环境(版本 15.0.2 +7) OpenJDK 64 位服务器虚拟机(版本 15.0.2+7,混合模式、共享) ,我不得不下载并解除对 JafaFX 16 的隔离,才能让 TagXplorer 应用程序正常工作。 我知道 uTrust 已安装并正常运行,因为 pcstest 已成功完成,而且我可以在https://github.com/martinpaljak/GlobalPlatformPro中使用它。 很好。 Re: TagXplorer - No reader available 我遇到了同样的问题, 我使用的是 macOS BigSur 11.1 版 Java 8 更新版 281 我通过 USB 插入了 uTrust 3700 F(指示灯亮起,说明有电) 我从这里安装了驱动程序https://files.identiv.com/products/smart-card-readers/common-drivers/uTrust_MAC_Driver.zip 我已经重新启动了机器。 我正在运行 TagXplorer v1.2,当我按下连接阅读器时,得到的信息是"No Supported reader available" ,而下拉菜单中没有列出阅读器。 Re: TagXplorer - No reader available 在试图访问重要信息时遇到 "没有可用的阅读器 "信息,这听起来令人沮丧。我以前也遇到过类似的问题,仔细检查文件兼容性或尝试在不同的浏览器中打开文件通常会有帮助。当我需要可靠地获取当地房产详细信息时,我通常会参考杰克逊房产查询,因为它将记录整理得井井有条,而且易于浏览。希望访问问题能尽快得到解决,这样每个人都能不受干扰地浏览内容。 Re: TagXplorer - No reader available 感谢您分享这一最新消息!对于想要快速获取详细记录的人来说,您可能会发现布雷沃德县的文件非常有用,因为它以易于访问的格式提供了全面的信息。您可以查看更多详细信息,随时了解最近的申报和官方记录。这是一个方便的资源,可以有效地跟踪当地的房地产事务。     Re: TagXplorer - No reader available 我最近在试图访问一些记录时也遇到了同样的问题,这让我非常沮丧。我发现,使用马萨诸塞州遗嘱认证案例等资源对于浏览不同文件和了解相关流程非常有帮助。它使查找特定信息变得更加容易,尤其是在标准阅读器无法加载的情况下。绝对值得遇到类似情况的人一看。
View full article
VSCode CMake環境でLVGLとRT1060マター開発を統合する こんにちは。RT1060 を使用してマターで開発をしています。 現在、私は CMake 開発環境を使用して VSCode で作業しています。 このセットアップに LVGL を統合する必要があります。 ご指導をお願いします。 Re: Integrating LVGL with RT1060 Matter Development in VSCode CMake Environment こんにちは@pooisonner 、 NXP MIMXRTシリーズにご興味をお持ちいただきありがとうございます。 公式の LVGL 移植ガイドはありませんが、SDK には LVGL の例が含まれているため、lvgl_demo_benchmark から始めることができます。 開発環境との一貫性を保つために、デモをインポートする際には MCUXpressoForVscode プラグインも使用する必要があります。 Gavin_Jia_0-1755593712222.png よろしくお願いします、 ギャビン
View full article
S32K混音器 大家好, 最近,我们完成了S32K Sound Mixer的参考代码和演示,很高兴在这里分享这个演示。 此演示的一些主要特点: - 基于 S32K344/S32K148 + 音频编解码器 SGTL5000 + QSPI 闪存 MX25L6433 的演示硬件。 - 基于 S32K3 RTD RTM 2.0.0 和 S32K1 RTD RTM 1.0.0 的演示软件。 - Demo中提供了2种混音算法的实现代码,以及相应的音频素材和codec SGTL5000驱动。 - 演示展示了如何通过音频存储和播放过程对 QSPI 闪存及其 AHB 访问进行编程。 - 演示使用单声道音频作为处理源,并通过 SAI HW FIFO 组合(Line_Mux)功能输出立体声音频(I2S 格式),几乎没有额外成本。 HMI/Cluster 应用程序需要同时播放多个音频源(通常是警告声音),这就带来了混音能力的要求。但是,S32K1/3 缺乏此 HW/SW 功能支持。 结合本地重点客户的需求,并考虑到潜在客户的需求,我们计划启用一个带有预定外设的SW混音器,以增强S32K系列音频混音能力。在 S32K1/3 上使用/移植应该很容易,并使用 QSPI 闪存(AHB 模式读取)来存储音乐。 附件混音器包包括基于 S32K344 EVB 和 S32K148 T-Box RDB 的 2 个混音示例,以及一些介绍此实现和快速入门指南的幻灯片。 谢谢并欢迎您的任何评论。 顺祝商祺! 李帅林 回复: S32K 混音器 你好,S32K3 RTD RTM2.0的下载连接在哪里?我安装的S32K3 RTD 4.4无法打开项目
View full article
Importing a Wrapped Key Blob into ELS Using NXP_DIE_KEK_SK on RW612 Introduction When provisioning secrets into an RW612 device, one common requirement is to securely load cryptographic keys without ever exposing the plaintext key material to application software. The EdgeLock Secure Subsystem (ELS) provides a secure mechanism for accomplishing this by allowing a wrapped key blob to be imported directly into an ELS key slot. The wrapping key is derived from device-unique root material inside the secure enclave. This article demonstrates how to: Derive the die-specific NXP_DIE_KEK_SK Import and unwrap the blob using ELS Store the resulting key in an ELS keyslot Remove temporary key material after provisioning The imported key never exists in plaintext in application memory, significantly reducing the attack surface compared to software-based key management. Understanding the Key Hierarchy Before looking at the implementation, it is useful to understand the different keys involved. NXP_DIE_MK_SK(NXP_DIE_INT_MK_SK) This is the 256-bit die master key derived from UDF and PUF using the KEYPROV operation. Characteristics: Die unique Not exportable Used as a root-of-trust Occupies key slot 0 on RW612 The key is loaded via dedicated secret key bus from PUF into ELS and XOR with a UDF derived key using KEYPROV, where it is used as a main key for further derivation of all remaining keys used by ROM. Applications never directly access the key material. NXP_DIE_KEK_SK This 256-bit key is derived from the master key using CKDF. It used for the wrapping of RFC3394 blobs stored in the OTP fuse region. Purpose: Acts as a Key Encryption Key (KEK) Used only for wrapping or unwrapping other keys Can be generated dynamically when needed In this example the KEK is stored temporarily in key slot 5. Imported Key The final key imported from the wrapped blob depends on how the blob was originally generated using the HSM provisioning flow (for example, via HSM_STORE_KEY and later loaded with loadkeyblob ). The imported key may represent a customer-defined security asset such as: Customer master key ( CUST_CKDFK_FLAG ) HKDF master key ( CUST_HKDFK_FLAG ) HMAC key ( CUST_HMACK_FLAG ) CMAC key ( CUST_CMACK_FLAG ) AES key ( CUST_AESK_FLAG ) Key unwrap-only key ( CUST_KUOK_FLAG ) Regardless of the key type, the import process remains the same. The key material is never exposed to application software during this process. Once imported, the key can be used directly by ELS for the cryptographic operations associated with its intended purpose, while remaining protected within the secure subsystem. Prerequisites FRDM-RW612 Key blob wrapped using RFC3394 format using HSM_STORE_KEY Key blob programmed to OTP fuses using LoadKeyBlob command. Required Headers: #include "mcux_els.h" #include "mcuxClEls.h" #include "mcux_pkc.h" #include "fsl_romapi_otp.h" Step 1 – Derive NXP_DIE_KEK_SK The wrapped blob is protected using a Key Encryption Key (KEK). On RW612, the KEK can be derived from the device master key ( NXP_DIE_MK_SK ) using the official recipe constants. The derivation operation uses  masterKeyIdx = 0;  which corresponds to NXP_DIE_MK_SK  and produces a new key in the target slot. Example: static const uint8_t derivation_data[12] = { 0x94, 0xbe, 0x03, 0xac, 0x8b, 0x59, 0x32, 0x45, 0x11, 0x7f, 0xf8, 0x3f }; mcuxClEls_Ckdf_Sp800108_Async( masterKeyIdx, target_slot, targetKeyProperties, derivation_data);   Wait for completion: mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR);   Verify that the derived key slot becomes active before proceeding. Step 2 – Retrieve the Wrapped Blob The example reads the blob directly from OTP memory. otp_fuse_read(starting_fuse_index + i, &fuse_word); Each fuse word contains four bytes.   These words are assembled into a contiguous buffer: blob_data[i * 4 + 0] = (fuse_word >> 0) & 0xFF; blob_data[i * 4 + 1] = (fuse_word >> 8) & 0xFF; blob_data[i * 4 + 2] = (fuse_word >> 16) & 0xFF; blob_data[i * 4 + 3] = (fuse_word >> 24) & 0xFF; The resulting buffer contains the RFC3394 wrapped key. Step 3 – Import and Unwrap the Blob Once the KEK exists and the blob has been retrieved, the import operation can begin. Configure ELS for RFC3394 import: mcuxClEls_KeyImportOption_t options; options.word.value = 0; options.bits.kfmt = MCUXCLELS_KEYIMPORT_KFMT_RFC3394; Perform the import: mcuxClEls_KeyImport_Async( options, blob_data, blob_length, kek_slot, target_slot); Parameters: Parameter Purpose blob_data Wrapped key blob blob_length Blob size kek_slot Slot containing NXP_DIE_KEK_SK target_slot Destination keyslot Wait for completion: mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR); If successful, ELS unwraps the blob internally and places the resulting key into the destination key slot. No plaintext key material is exposed to software. Step 4 – Clean Up Temporary KEK After the blob has been imported, delete the temporary KEK: mcuxClEls_KeyDelete_Async(kek_slot); mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR); This leaves only the imported key resident inside ELS. Next Steps At this point, the wrapped key blob has been successfully imported into the target ELS key slot, and the temporary NXP_DIE_KEK_SK has been removed. The imported key is now available for use by ELS-protected cryptographic operations without exposing the underlying key material to application software. The next step is to validate the imported key by performing the operation it was provisioned for. Depending on the key type, this may include: AES encryption or decryption operations HMAC generation or verification CMAC generation or verification HKDF-based key derivation Importing or unwrapping additional key material Secure firmware or data encryption workflows A successful cryptographic operation confirms that: The blob was read correctly from storage. The NXP_DIE_KEK_SK derivation completed successfully. The RFC3394 unwrap operation succeeded. The key was installed into the intended ELS keyslot with the expected properties. For production deployments, this import mechanism provides a secure method for provisioning customer keys generated with the HSM tooling while ensuring that plaintext key material never leaves the ELS security boundary.
View full article
RT685: SDK 25.12 没有 HASHCRYPT 加速功能 你好 我们最近更新到了 SDK 25.12,发现我们的 TLS 解密率降低了一半。 mbedTLS v3.x 不再使用fsl_hashcrypt硬件加速功能。 下面是使用以前的 SDK 25.09 调用mbedtls_ssl_read 的调用堆栈。可以看到,最终使用了HASHCRYPT_AES_EncryptEcb。 hashcrypt_aes_one_block_aligned() at fsl_hashcrypt.c:437 hashcrypt_aes_one_block() at fsl_hashcrypt.c:581 HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,284 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_update() at gcm.c:358 mbedtls_gcm_crypt_and_tag() at gcm.c:456 mbedtls_gcm_auth_decrypt() at gcm.c:491 mbedtls_cipher_aead_decrypt() at cipher.c:1,407 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,613 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,242 ssl_prepare_record_content() at ssl_msg.c:3,667 ssl_get_next_record() at ssl_msg.c:4,551 mbedtls_ssl_read_record() at ssl_msg.c:3,817 mbedtls_ssl_read() at ssl_msg.c:5,237 <...more frames...> 下面是定义了MBEDTLS_USE_PSA_CRYPTO的 SDK 25.12 的调用堆栈。在该版本中,mbedtls_internal_aes_encrypt全部是 C 代码,没有硬件加速。 mbedtls_internal_aes_encrypt() at aes.c:894 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:641 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> 下面是 SDK 25.12 的调用堆栈,其中没有mbedtls_use_psa_crypto定义的调用堆栈。在这个版本中, mbdtls_internal_aes_encrypt全部是 C 代码,没有硬件加速,也不涉及 PSA。 mbedtls_internal_aes_encrypt() at aes.c:899 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_cipher_aead_decrypt() at cipher.c:1,528 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,674 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,639 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> 是否有计划在 mbedTLS 中恢复 RT685 HASHCRYPT 硬件加速?某些 PSA Crypto 驱动程序似乎未被执行。 谢谢! Re: RT685: SDK 25.12 no HASHCRYPT acceleration 嗨,埃德温、 我在 EVK 上重现了这个问题。我修改了两个样本,在其中添加了一个迭代 200 次的循环 mbedtls_gcm_self_test 并使用 RTC 时钟为整个执行过程计时。 evkmimxrt685_mbedtls_selftest_cm33 执行测试的时间为 1087ms 使用此调用栈: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,260 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_starts() at gcm.c:294 mbedtls_gcm_crypt_and_tag() at gcm.c:452 mbedtls_gcm_self_test() at gcm.c:826 evkmimxrt685_mbedtls3x_psatest_cm33 执行测试的时间为 8990ms 使用此调用栈: mbedtls_internal_aes_encrypt() at aes.c:896 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 mbedtls_gcm_starts() at gcm.c:441 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075   evkmimxrt685_mbedtls3x_psatest_cm33 来自 SDK 25.12 的 mbedtls_psa_accel_key_type_aes 定义的测试执行时间为 8744ms 使用此 callstack: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:187 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 mbedtls_gcm_starts() at gcm.c:439 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075 对示例的修改要点如下: BOARD_InitHardware(); test_rtc_init(); psa_crypto_init(); uint64_t ms_start = test_rtc_get_msecs(); for (int i = 0; i < 200; ++i) { PRINTF("test iteration %d\r\n", i+1); mbedtls_gcm_self_test(0); } uint64_t ms_end = test_rtc_get_msecs(); PRINTF("test time = %ums\r\n", (unsigned)(ms_end - ms_start)); ... 其中test_rtc_get_msecs使用亚秒精度返回当前 RTC 时间。 正如您所看到的,使用新的 SDK 加密 GCM/AES 的速度慢了约 8 倍。 如果您需要,我可以附上修改后的示例。 问候, Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration 嗨,埃德温, 我们已经阅读了迁移指南。不过,我们看不出不带 PSA 的 mbedTLS 2.x 或 mbedTLS 3.x 如何在此版本的 SDK 中进行硬件加速。由于 aes_alt.c 已被删除,而 HASHCRYPT 功能仅由 PSA 驱动程序支持。 我们的应用程序在使用 SDK 25.12 时一切正常,我们当然希望在连接时使用 TLS 1.3,但现在的情况会让我们的性能大打折扣。 我们将继续调查此事。我将修改其中一个示例,看看能否重现性能损失。 问候, Amilcar Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好,@hrc-amilcar、 感谢您耐心解答这个问题。我刚刚收到内部团队的回复,请参见下文。 从调用堆栈中我可以看到,您使用的是传统的 mbedtls_xxx 加密 API。事实上,它并没有加速。MbedTLS3.x推出了新的加密应用程序接口,它就是 PSA。mbedtls/docs/psa-transition.md at v3.6.5 - Mbed-TLS/mbedtls - GitHub而且它还被加速了。 MbedTLS4.x 进一步删除了传统加密 API。 我检查了 RT600 SDK 中的 psa_crypto_examples,通过定义PSA_CRYPTO_DRIVER_HASHCRYPT,HASHCRYPT硬件加速在默认情况下是启用的,这使得加密驱动程序封装器可以将加密计算卸载到硬件上。另一方面,MbedTLS3.x+ 更为复杂,也更符合 PSA API 规范,因此可能会出现某些用例性能较低的情况。对于 TLS,我认为非对称加密技术(CASPER 硬件 IP)会成为性能瓶颈,因为该 IP 只能支持少量加速,而且与 PSA API 不兼容,后者希望硬件 IP 实现整个算法。我们已尽全力至少加速了部分 ECC 操作(签名、验证),但其他操作(如 ECDHE 密钥交换过程中的密钥生成)可能会更糟。 现在,如果您能使用 PSA API 进行性能测量,并确认 PSA_CRYPTO_DRIVER_HASHCRYPT 已定义且调用栈使用了它,那将是一件好事。仅供参考:Hashcrypt本身没有提供AES-GCM加速,因此最好对AES-密码块链接(CBC)或AES-CTR进行基准测试,以查看硬件IP的实际收益。 BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好,@hrc-amilcar、 从mbedTLS 2.x(不含 PSA)迁移到 mbedTLS 3.x(含 PSA)必然会导致性能下降: " PSA 驱动程序接口仅部分实现。因此,编写驱动程序的交付内容以及将驱动程序与 Mbed TLS 集成的方法将根据所加速的操作而有所不同。"(https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mbedtls3x/docs/psa-driver-example-and-guide.html) 目前,我所能推荐的最好方法是遵循如何正确从 2.x 迁移到 3.x 的指南:从 Mbed TLS 2.x 迁移到 Mbed TLS 3.0 - MCUXpresso SDK 文档 以及正确过渡到 PSA API 的指南:过渡到 PSA API - MCUXpresso SDK 文档 不便之处,敬请原谅。 BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration 我在 mbedTLS 配置文件中定义了 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES,现在它正在调用 ASHCRY PT,但是我们的 mbedtls_ssl_read 读取速度现在更慢了。我想知道是否还有其他缺失的定义,或者PSA层增加了额外的开销。   通过 TLS 插口从 WiFi 下载 4KB 数据包的速率: SDK 25.09:205KB/秒(没有 PSA 和 ksdk 端口文件的 mbedTLS 2.x) SDK 25.12:138KB/秒(不带 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES) SDK 25.12:125KB/秒(使用 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES 时) 下面是使用 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES 的新调用栈: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:203 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 gcm_mask() at gcm.c:543 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好,@hrc-amilcar、 更新 SDK 后,您是否做了任何更改?您在使用 SDK 示例代码时也看到了这种行为吗?你使用的是独立组网 \\(SA\\) IDE 还是 VS Code 扩展? BR, Edwin. Re: RT685: SDK 25.12 no HASHCRYPT acceleration 你好,@EdwinHz、 我们使用的是 MCUXpresso 集成开发环境。 更新 SDK 后无额外更改: 当我们更新 SDK 时,我们会重新运行 " SDK 管理 "-> " 刷新 SDK 元器件 " 来获取新的和更新的文件。 然后,我们比较 .cproject配置为已启用类似功能的样本之一(例如evkmimxrt685_wifi_wpa_supplicant_cm33) psa_crypto_driver_casper=1 psa_crypto_driver_hashcrypt=1 config_wpa_supp_crypto_mbedtls_psa=1 等等 我们使用默认的mcux_mbedtls_config.h作为主要的 mbedTLS 配置头文件,并使用与evkmimxrt685_wifi_wpa_supplicant_cm33示例中的wpa_supp_mbedtls_config .h几乎相同的用户配置文件。 我将尝试使用 mbedtls3x_examples,看看它们的表现如何。也许我们漏掉了一些定义。 我在浏览代码时注意到,也许需要定义MBEDTLS_BLOCK_CIPHER_C,以便加速 gcm 操作。 看起来头文件mbedtls3x/include/mbedtls/config_adjust_legacy_crypto.h对此负有责任,但由于某些原因最终没有定义该宏。 Re: RT685: SDK 25.12 no HASHCRYPT acceleration 为了他人的利益... 看来 来自 mbedTLS 3.x 的 mbedtls_xor 一次循环遍历 4 字节的数据,并调用 mbed tls_get_unaligned_uint32 和 mbedtls_put_unalign ed_uint32, 它们都使用 memcp y 来处理单个 uint32。 我认识到 MbedTLS 的作者正试图通过一次计算 异或 4 字节块(使用余数循环)来提高性能,但是对 memcpy 的完整调用实际上使代码变慢。 在对反汇编进行一些调查后,我发现我们的项目在编译时使用了 -fno-builtin,导致编译器无法内联小的 memcpys。 移除该选项后,HASHCRYPT 硬件不用于 AES-GCM 操作所造成的性能损失基本得以恢复。因此,我发布的示例执行时间从 8600 毫秒缩短到 2100 毫秒。还没有达到 mbedTLS 2.x + ksdk alt(1087ms)的水平。但修复后的性能已经足够好了。 -阿米尔卡
View full article
带有 S32K5xx RTD 的时钟 IP 发出的 S32DS 警告 0.8.0 使用 S32K5xx RTD 时 0.8.0编译时,我收到了来自时钟 IP 模块的许多警告。 DirkEtzler_0-1771115696535.png 有办法纠正它们吗? 这些警告是否可以忽略? 有计划把它们修好吗? Re: S32DS Warnings from Clock IP with S32K5xx RTD 0.8.0 你好@DirkEtzler、 谢谢您的提问。如前所述,S32K5 系列目前是 NPI(新产品推出)设备。因此,所有支持请求必须直接通过指定的恩智浦 FAE 处理。 或者,请通过以下网址创建支持票据: https://support.nxp.com/s/?language=en_US 系统会自动将您的请求转给相应的 FAE 团队,以便提供进一步帮助。 感谢您的理解。 顺祝商祺! 帕维尔
View full article
ST7701 驱动程序 Hello 我正在尝试与 ST7701 显示控制器通信。 是否有一些例子?如果可能的话,谁能分享一下? 我使用的是 i.MX RT1170 板。在 SDK 示例中,我找到了 HX8394、RM68191 和 RM68200 显示控制器的驱动程序。我想为 ST7701 找到类似的东西。 谁能帮帮我? 谢谢,并致以诚挚的问候、 弗朗切斯科-索利托 Re: ST7701 drivers 你好,@SolitoFrancesco、 目前,我们的 SDK 中没有任何针对ST7701 显示控制器 的驱动程序支持。 与该控制器的集成必须手动完成。 必须调整 LCDIF 模块的分辨率值、同步信号和时钟频率,以便与显示控制器兼容。如果使用 EVK,则可以使用 SDK 驱动程序并调整以下功能的值: BOARD_InitLcdifClock() BOARD_InitMipiDsiClock() BOARD_SetMipiDsiConfig() 这些函数以及同步值的宏都在 " display_support.c " 中引用文件,这是调整显示控制器支持时需要关注的主要文件。   另外,请务必阅读以下应用笔记,因为它详细介绍了液晶显示器设置的工作原理以及其他有用的注意事项:i.MX RT elcDIF RGB 模式用例 (nxp.com)   BR, Edwin. Re: ST7701 drivers 早上好 我按照显示器制造商和驱动程序制造商的指示,修改了你提到的文件。我可以通过 MIPI 对驱动寄存器进行写入和读取。我可以用示波器看到差分 MIPI 波形(也是在"配置" 阶段之后),但仍然无法在显示屏上看到任何东西。我正在使用恩智浦 SDK 中名为"mipi_dsi_compiance_test" 的演示示例。 您能提供更多帮助吗? 谢谢,并致以诚挚的问候、 弗朗切斯科-索利托 Re: ST7701 drivers 你好,@SolitoFrancesco、 您能在运行时调试代码吗?是否打印出任何错误信息?您在数据线上看到了哪些数据模式?这些模式是否与 readme.md 文件中描述的预期模式一致? BR, Edwin. Re: ST7701 drivers 你好 我也遇到了同样的情况(相同的驱动程序和分辨率,基础是在开发板上运行的测试示例)。控制器已配置好,我也可以读取状态(没有任何错误),DSI 线路上的数据也已存在,但屏幕上什么也没显示。 将 dsi_dpi_config 中的 videoMode 从 kDSI_DpiBurst 改为其他模式也没有效果。 看起来屏幕不接受视频流? Re: ST7701 drivers 你好示例项目在显示 DEMO_PANEL_RK055MHD091 时运行正常。然后,我切换到最终应用中必须使用的面板。它的分辨率不同(480x800),因此我调整了定义。然后,我更改了驱动程序(fsl .h和 .c文件),我就能与显示器通信了。我可以写入和回读寄存器。但在配置显示屏后,当示例项目开始发送图像缓冲区时,我能在示波器上看到 MIPI 波形,但显示屏上什么也看不到。假设显示屏没有损坏,因为我尝试通过专用命令打开所有像素,我可以看到屏幕完全白色。我不明白的是,问题是出在显示器的配置上,还是出在示例项目中我必须调整的其他地方。我联系了显示器制造商和控制器制造商,但我需要各方尽可能多的帮助。有可能为安装在显示器上的控制器获取 fsl 驱动程序吗?它是 Sitronix ST7701。请告诉我。谢谢并致以诚挚的问候,弗朗切斯科 Re: ST7701 drivers 您好,Rino 我正在对我的设置和您的设置进行比较(最后我会上传到这里)。 同时,我注意到我使用的是 ST7701,而你使用的可能是 ST7701S(后缀为 S)。我认为它们很相似,但我不确定。 我注意到,现在即使不进行任何初始化,显示屏也能正常工作。"开始时速度很慢," ,硬度也很低,但还是能用。然后,如果我只发送 0xE0 至 0xEF 的设置(ST7701 数据表中没有记录),显示器启动速度非常快,颜色也正确。似乎所有其他设置都没有必要(听起来很奇怪)。 让我们保持联系。完成后,我将与大家分享比较结果。 再次感谢您。 亲切的问候, Francesco Re: ST7701 drivers 你好,Rino 非常感谢你的建议。在我的应用中似乎也是如此。好极了我可能需要更好的设置,但现在我可以在屏幕上看到图像了。 如果可能的话,请与我分享您的配置,以便我与您的配置进行比较,更好地完善配置。如果我看到了不同的东西,我会在这里告诉你。 再次感谢您。您是如何设置 enableNonContinuousHsClk 的? 致以亲切的问候, Francesco Re: ST7701 drivers 你好,弗朗切斯科 、 我设法让显示屏正常工作。 在 DisplayTFT_SetMipiDsiConfig 函数中,添加一行内容: dsiConfig.enableNonContinuousHsClk= true; 例如,在这几行之后: DSI_GetDefaultConfig(&dsiConfig); dsiConfig.numLanes = DISPLAY_MIPI_DSI_LANE_NUM; dsiConfig.autoInsertEoTp= true; 假设你已经正确配置了显示 IC(如果有必要,我可以分享我的屏幕配置)和显示时钟(我的设置大约是 26MHz)。 致以最诚挚的问候,克里斯 Re: ST7701 drivers 你好 文件是根据 SDK 中的其他驱动程序创建的。 您还可以将延迟时间改为更短。 今天上午,我确认了配置顺序,并按照显示器制造商的建议做了一些更改,但没有进一步改善,于是我开始仔细研究 DSI 配置本身。我知道时钟很好,视频模式(突发模式)也是如此,所以剩下的唯一选择是 DSI 本身的选择。 熟悉(以及文档中的其他部分): https://docs.nxp.com/bundle/AN13573/page/topics/continuous_vs_non-continuous_clock.html BR, Chris Re: ST7701 drivers 你好,里诺 按照约定,请在附件中查看您和我的设置对比。我没有细说,但如果我或你会在差异中发现一些有趣的东西,请让我们继续写下去。 此致敬礼, 弗朗西斯科 Re: ST7701 drivers 你好,弗朗切斯科、 抱歉耽搁了。 我浏览了你的对比,发现了很多差异,部分原因是屏幕本身(我们有玻璃/触摸屏/屏幕三明治,对此进行了配置修复——或者至少供应商是这样解释的) 🙂 )。 有些设置(如功率控制)不是启动所必需的,而是为了提高质量(对比度/伽玛设置)。 有趣的是,无论我们是否运行"Sunlight Readable Enhancement" 这个东西,我想他们称之为 "阳光可读增强",都是必需的。根据这些数据,它可以自动设置最佳参数。如果它们不正确或缺失(默认值),则需要一段时间才能自动设置它们 -> 因此,正如你所注意到的,启动速度会很慢。 文档本身可能相当令人恼火,许多命令都没有文档说明,如果没有文档,往往无法完全启动屏幕。不只是这款机型,我在其他几款态龙机型上也遇到过这种情况。 亲切的问候, Chris
View full article
ICODE SLI tag returns a 64 01 error for a write_single_block command I'm using a Windows 11 laptop and and ACS ACR1552 reader.  I'm using the ACS Script Tool (v5.02) to send APDUs to a NXP ICODE SLI tag. I'm creating a transparent session, setting the protocol to 15693/Layer3, and then using transparent exchange encapsulation to the send the APDUs to the tag. GET_SYSTEM_INFO and READ_SINGLE_BLOCK seems to work OK. WRITE_SINGLE_BLOCK returns a "64 01" error but does appear to actually write the data. I have not been able to find any info on the meaning or cause of this 64 01 response. Can anyone shed some light on this? Here's the sequence of APDUs I'm working with. APDU #4 reads block 0 data as 11 22 33 44 APDU #5 writes block 0 data to 12 34 56 78  -  yet gets a 64 01 error APDU #6 reads block 0 data as 12 34 56 78  -  which shows the previous write actually worked? ; (1) establish transparent session < FF C2 00 00 02 81 00 00 > C0 03 00 90 00 90 00 ; (2) transparent exchange - switch protocol to SwitchProtocolRf::ISO15693 SwitchProtocolLayer::PART3 < FF C2 00 02 04 8F 02 02 03 > C0 03 00 90 00 8F 01 00 90 00 ; (3) get sys info < FF C2 00 01 04 95 02 02 2B 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 0F 00 0F 2E 98 5C 8A 00 01 04 E0 00 00 1B 03 01 90 00 ; (4) read user block 0 with security status < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 06 00 00 00 11 22 33 90 00 ; (5) write block 0 with 12 34 56 78 < FF C2 00 01 09 95 07 02 21 00 12 34 56 78 00 > C0 03 01 64 01 90 00 ; (6) read user block 0 with security status < FF C2 00 01 05 95 03 42 20 00 00 > C0 03 00 90 00 92 01 00 96 02 00 00 97 06 00 00 12 34 56 78 90 00 ; (7) end transparent session < FF C2 00 00 02 82 00 00 > C0 03 00 90 00 90 00 Re: ICODE SLI tag returns a 64 01 error for a write_single_block command I had this exact same issue reading/writing icode SLIX/SLIX2 tags, the writes were working but giving the 64 01 timeout.  I was able to solve the problem by adjusting the timeout for the command by including the timer option within the same transaction as the write. Example: Write "00 01 02 03" to block 0 > ff c2 00 01 10 5f 46 04 40 42 0f 00 95 07 02 21 00 00 01 02 03 00 Transparent command Size of command (0x10 = 16 bytes to follow) Timeout command Command To Device As can be seen, the response is now correct. This command is basically the same as shown in the original poster's question, with the addition of the green section, which is, per the docs setting a 1sec timeout (which is probably way excessive). 5f 46 = Timer Data Object 04 = Length 40 42 0f 00 = 1,000,000 (microseconds, LSB first), i.e. 000f4240h = 1,000,000 Probably too late to be useful for the original poster, but maybe this will save someone else the 2-3 hours it cost me. Re: ICODE SLI tag returns a 64 01 error for a write_single_block command Thanks  @jimmychan.  Yes I’ve seen that list of error codes and descriptions, including the 6401.     I’m trying to understand what can cause that error given the APDU sequence I included in my original post.      Do you know reasons the tag wouldn’t respond to a write single block command to user memory?  An example I’ve thought  about is possibly the write operation takes longer than the reader is waiting for.  I’ve experimented with trying to configure the reader to wait longer but so far I haven’t been able to get this to resolve the issue.  Also, I don’t see any reference to this in the SLI or DNA spec sheets so I doubtful this is the issue.     Again, any help in understanding why the tag wouldn’t respond would be much appreciated.    Thanks - Drew Re: ICODE SLI tag returns a 64 01 error for a write_single_block command You could check the reference manual REF-ACR1552U-Series-1.06.pdf. page 43. Re: ICODE SLI tag returns a 64 01 error for a write_single_block command Hi @jimmychan - I have read the documentation for the reader, that's how I got the command syntax I'm using. As far as I can tell I have the command syntax correct. Are you saying the 6401 error is coming from the reader? Do you have any specific area of the documentation that I should look into? I appreciate your help. Drew Re: ICODE SLI tag returns a 64 01 error for a write_single_block command Please read the document of the reader. ACR1552U - USB NFC Reader IV | ACS
View full article
与 MCXN647 的连接问题(Ee(42) 错误) 您好, 我的FRDM-MCXN947遇到了问题。每当我尝试调试或闪存我的项目时,都会收到这样的错误信息 : PeterD_0-1766924466842.png PeterD_1-1766924526627.png 我不知道这是否与此有关,但当我更改 while(1) 循环中的这一行以增加其频率时,问题就开始出现了:SDK_DelayAtLeastUs(30000, SystemCoreClock);-> SDK_DelayAtLeastUs(10000, SystemCoreClock); 问题出现之前我没有更新,但之后我更新了 LinkFlash,但并没有解决任何问题。 我已经试过 SPT 擦除,但没有用。(也许我做错了)。 在 SPT 上,激活 ISP 模式后,我能够执行 “版本映像” 和 “写入映像” 操作,但擦除仍然不起作用。 PeterD_3-1766926202287.png PeterD_4-1766926211594.png 提前感谢您的帮助。 注:请原谅我的英语和专业词汇,我在工程学院刚刚开始这个项目。 启动 ROM | 启动配置 | 闪存 时钟|计时器 MCX N USB Re: Connection problem with MCXN647 (Ee(42) error) 你好@彼得-D 请尝试使用 SPT 工具中的闪存编程器擦除闪烁的 SDK 演示并对其进行编程,检查其是否正常工作。详情请参阅附件中的视频。 如果这些步骤运行良好,但仍无法使用板载调试器进行调试,请使用外部调试器进行测试。 如果您仍有问题,请随时与我联系。 谢谢! BR 爱丽丝 Re: Connection problem with MCXN647 (Ee(42) error) 你好@Alice_Yang, 非常感谢你的答复。 我按照视频中的说明进行了操作,使 LED 闪光灯正常工作。 但是,当我从 MCUXpresso IDE 返回调试器时,却出现了同样的错误。 如果问题出在板载调试器上,我想我不会购买诸如PEMicro或SEGGER J-Link之类的外部调试器(如果你指的是的话),尤其是因为我正在使用的板是在学校借给我的。 如果找不到解决办法,我将继续使用闪存编程器,它也适用于我的项目,我还会问问我的教授们是否有外部调试器。 顺祝商祺! Peter Re: Connection problem with MCXN647 (Ee(42) error) 你好@彼得-D 我不确定你板上的调试器是否真的坏了。请尝试按照以下说明更新调试器固件:https://docs.nxp.com/bundle/UM12018/page/topics/Updating_MCU_Link_firmware.html 更新后,断电重启板,在 MCUXpresso IDE 中创建新工作区,导入新的 SDK 演示,然后再次尝试调试。 如果你能拍摄一段视频与我分享,那就更好了。我帮你检查一下。 谢谢!     BR 爱丽丝 Re: Connection problem with MCXN647 (Ee(42) error) 你好@彼得-D 感谢您的视频。 请删除 .launch 文件(如下图所示),然后再次擦除您的板。 使用下图所示的调试按钮开始调试。 Alice_Yang_0-1767148514011.png 如果还是不行,我建议更换板。 顺便说一下,我将放新年假,1 月 5 日回来。如果您还有问题,请在当天与我联系。 感谢您的理解,祝您新年快乐! BR 爱丽丝 Re: Connection problem with MCXN647 (Ee(42) error) 你好@Alice_Yang 感谢您的回复。 我按照建议更新了 LinkServer,但我想问题出现后我已经更新过了。无论如何,我再次尝试了更新,然后重新启动了板,创建了一个新的工作区,并导入了一个演示项目,但是在尝试调试时我仍然遇到同样的 Ee (42) 错误。 我录制了一段简短的视频,展示了整个过程,现附后。 感谢您的帮助,祝您新年快乐。 致以最诚挚的问候, Peter
View full article
s32m24x PMC_AE 监测自检问题 Wendy123_0-1764833984013.png 问:我按照这个步骤对其进行了配置。但是在完成第 5 步之后设置 触发信号=10,为什么不在这里 RESET? Re: S32M24x PMC_AE Monitor self check question 你好 写入触发信号后,MONCHECK 寄存器的内容是什么? 因为 RESET 应该在写入 TRIGGER 之后立即触发。 顺祝商祺! Peter Re: S32M24x PMC_AE Monitor self check question 感谢您的反馈。 我检查了我的设计,我认为主要问题在于:我无法读取 MONCHECK 的值,也就无法完成功能描述。 详情如下: 开机后,如果我按如下方式读取 MONCHECK,则返回值始终是 E_NOT_OK,我无法检查 DONEF 和触发信号的值。为什么我读不到? ret = Ae_ReadRegister((uint32)&(IP_PMC_AE->MONCHECK),32,&data); 如果我将 MONCHECK 写入 PMC_AE_MONCHECK_TRIGGER(2),如下所示,那么我就可以读取它,并且与我设置的值相同。 /*读取 MONCHECK,检查 DONEF=0 和 触发信号=10*/ ret = Ae_ReadRegister((uint32)&(IP_PMC_AE-)>MONCHECK), 32,&data); 如果((data&(PMC_AE_MONCHECK_DONEF_MASK|PMC_AE_MONCHECK_TRIGGER_MASK))!=PMC_AE_MONCHECK_TRIGGER(2)) { data = PMC_AE_MONCHECK_TRIGGER(2); ret = Ae_WriteRegister((uint32)&(IP_PMC_AE-)>MONCHECK), 32, data); } /*写入触发信号 = 01*/ data = PMC_AE_MONCHECK_TRIGGER(1); ret = Ae_WriteRegister((uint32)&(IP_PMC_AE-)>MONCHECK), 32, data); ret = Ae_ReadRegister((uint32)&(IP_PMC_AE-)>MONCHECK), 32,&data); Re: S32M24x PMC_AE Monitor self check question 你好 开机后,如果我按如下方式读取 MONCHECK,则返回值始终是 E_NOT_OK,我无法检查 DONEF 和触发信号的值。为什么我读不到? 能否通过调试器手动检查? 只需在开始时设置 while/decision 循环,并通过调试器直接读取寄存器,即可确定寄存器的值。 我不熟悉你们的驱动程序,所以无法判断它是否正确检查。 我会在这里进行测试,然后把结果告诉你们。 顺祝商祺! Peter 顺祝商祺! Peter Re: S32M24x PMC_AE Monitor self check question 初始化芯片后,我通过调试器手动进行了如下检查,结果始终是 E_NOT_OK。顺便说一下,我们的驱动程序基于 RTD( SW32K1_S32M24X_RTD_R21-11_3.0.0_D2503)。即使我使用示例项目(Ae_Handler_Faults_Example_DS_001_S32M244)再次进行测试,问题也是一样。 Std_ReturnType ret = E_NOT_OK; while(ret == E_NOT_OK) { ret = Ae_ReadRegister((uint32)&(IP_PMC_AE->MONCHECK), 32,&data); } Re: S32M24x PMC_AE Monitor self check question 你好 我仔细查看了 AE 的编程,但在执行测试时却毫无进展。 这需要更多的时间来创建一个示例。 如需申请支持,请在 NXP.com 上提交申请。 如果有时间,我将在一月份创建一个工作示例,作为我的副业。 顺祝商祺! Peter Re: S32M24x PMC_AE Monitor self check question 谢谢,我已收到,案件编号是:00755819
View full article
恩智浦技术日 - 特拉维夫 - 2016年3月22日 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 确保嵌入式系统安全的QorIQ可信功能的概述 Layerscape多核通信处理器的ARM® v8虚拟化 逻辑抽象和资源管理以及Layerscape管理复合体 家庭自动化的低功耗无线连接解决方案 NFC Everywhere - 为您的客户提供新的 NFC 用例 面向新虚拟网络的强大QorIQ多核处理器 面向工业-航空电子-军事-烹饪-蜂窝市场的射频功率解决方案 (L Gauthier) 可扩展多核QorIQ Layerscape处理器 基于 64 位软件环境的可扩展多核 QorIQ Layerscape 处理器,适用于企业、家庭和工业应用 (H Cohen) 可穿戴设备市场解决方案 面向未来网络的QorIQ Layerscape LS2085/88多核通信处理器 QorIQ LS2系列:AIOP、WRIOP、DPAA2 - 高性能数据路径和网络外设接口 VORTIQA智能虚拟化加速软件(IVAS)
View full article
S32Z RTU0 core0 性能问题 我在 S32Z270 RTU0 内核 0 (R52) 上运行一些测试代码,RTU0_CORE_CLK 设置为 1GHz,执行时间似乎过长。 相比之下,我在 SS32K388 内核 0 (CM7) 上运行相同的代码,内核时钟设置为 320MHz。 鉴于时钟频率的提高,我本以为执行速度会更快一些,但执行时间反而更长了。 两个二进制文件的版本/编译标志保持不变(参见随附的 txt 文件 buildinfo.h) (1) 由于 S32 配置工具中的时钟配置对于 S32Z 来说有点复杂,我如何才能确保 RTU0 内核 0 的时钟频率按计划为 1GHz? 我已经通过 MC_CGM_3_MUX4_CSC(例如,SEL_CTL = 0x3D)将 RTU0_CORE_DIV2_CLK 路由到 CLKOUT_4(BGA594 的 PAD_040),包括 MC_CGM_3_MUX4_DC_0(例如,DIV = 0x9)中为 10 的分频器。另请参见所附的登记册读数。 如果我在 CLKOUT_4 测量到 50MHz,我是否可以假定 (a) RTU0_CORE_DIV2_CLK 为 500MHz,(b) RTU0_CORE_CLK 为 1GHz? CGM_3_MUX_4_Register_Configuration.png CLOCKOUT4_Measurements_RTU0_CORE_DIV2_CLK_50MHz.png (2) 我使用 S32Z RTD2.0.1 测量了引脚写入 GPIO 的执行时间,并测量了示波器通道 CH5 - TESTFLAG 的高/低时间,大约为 3.4us。您是否有可能确认一下它们看起来是正常还是太慢了? Screenshot 2026-04-25 123853.png Setting_GPIO_Low_3.4us.png Setting_GPIO_High_3.4us.png (3) 我不知道我错过了什么。     Re: S32Z RTU0 core0 performance issue 随函附上包装标记的照片。 Scan from 2026-04-27 09_28_21 AM.jpg0   Re: S32Z RTU0 core0 performance issue 你好,@Joey_z、 感谢您的快速回复。 下面是我对这些问题的回答: 1) 我使用的是 S32Z2XX 主板 + S32Z2XX 子板的组合。 a) S32ZXX 主板 X-S32X-MB A 版 b) S32ZXX 子板 SCH-50588 REV B2 / 700-50588 REV A2 S32Z2XX_Complete_Setup.jpg S32Z2XX_Motherboard_Tag.jpg S32Z2XX_Daughterboard_Tag.jpg 2) 代码使用 S32DS 版本 3.6.7 Build 260420 进行编译和链接。使用 S32DS 的先前版本(例如版本 3.6.6 或 3.6.5)时没有任何变化。我正在为 S32Z2XX 使用 RTD2.0.1。 Screenshot 2026-04-27 092032.png Screenshot 2026-04-27 092336.png 3) 我会使用 DM 发送项目副本。 Re: S32Z RTU0 core0 performance issue 你好,德克-埃兹勒 感谢您与我们联系。 1. 你使用开发板还是客户板? 2.您使用的是 S32DS 的 IDE 吗?您测试的 IDE 版本是什么? 3.能否与我分享您的测试代码? BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好,德克-埃茨勒 感谢您的答复和详细资料。 我会帮你检查,并在晚些时候回复你。 BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好,德克-埃茨勒 抱歉,回复晚了。 (1) 我已经通过 MC_CGM_3_MUX4_CSC(例如,SEL_CTL = 0x3D)将 RTU0_CORE_DIV2_CLK 路由到 CLKOUT_4(BGA594 的 PAD_040),包括 MC_CGM_3_MUX4_DC_0 中的分频器 10(例如,DIV = 0x9)。另请参见所附的登记册读数。如果我在 CLKOUT_4 测量到 50MHz,我是否可以假定 (a) RTU0_CORE_DIV2_CLK 为 500MHz,(b) RTU0_CORE_CLK 为 1GHz? >>>关于这个问题,数字 7 被分配给 RTU0_CORE_DIV2_CLK,您还应通过编程 GPR3.CLKOUT4SE 来设置该值。您能确认一下是否设置了这个寄存器吗? Joey_z_0-1777434680768.png BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好@Joey_z 关于这个问题: >>>关于这个问题,数字 7 被分配给 RTU0_CORE_DIV2_CLK,您还应通过编程 GPR3.CLKOUT4SE 来设置该值。 您能确认一下是否设置了这个寄存器吗? 我检查了 GPR3.CLKOUT4SEL[MUXSEL] 的寄存器设置,该寄存器设置为 7,用于在相应的多路复用器中选择 RTU0_CORE_DIV2_CLK。 Re: S32Z RTU0 core0 performance issue 你好,@Joey_z、 我不确定我之前的留言是否已被确认为回复。 我检查了 GPR3.CLKOUT4SEL[MUXSEL]是否设置为 0x7,因此RTU0_CORE_DIV2_CLK 通过多路复用器路由。 使用所述配置并在输出引脚上看到 50MHz,我推测 RTU0 内核的时钟频率为 1GHz。 如果内核频率设置为 1GHz,但我仍然没有看到预期的性能(例如,使用 CoreMark 测试台),还有什么其他不正确的配置吗? 如何检查缓存配置是否正确? 我查看了汇编器启动脚本和使用过的链接器脚本,没有发现任何可疑之处。 Re: S32Z RTU0 core0 performance issue 你好,德克-埃茨勒 感谢您的答复和详细资料。 您可以尝试参考 AN14245 的第 3、4 章来检查缓存配置。 高速缓存机制有助于提高内存性能。您可以下载以下图片。 Joey_z_0-1778036409619.png 此外,GPIO 翻转到测量时间,主要反映了外设的"延迟" 访问路径,但会对 CPU 内核运算性能产生偏差。另外,在此应用程序中包含CoreMark的内容,您可以作为测试的参考。 BR 乔伊 Re: S32Z RTU0 core0 performance issue 你好,@Joey_z、 谢谢,我将阅读上述应用笔记(AN14245 S32ZE 安全可靠的高性能实时处理器)的第 3 章和第 4 章,了解缓存的正确设置。 顺便提一句,获得的 CoreMark 分数太低,这也是支持案例的起因。
View full article
MIMXRT700-EVK block diagram wrong part number reference I’m working with the RT700 evaluation board (MIMXRT700-EVK), and I’ve come across a discrepancy in the documentation. The block diagram mentions a Macronix flash memory part number as MX25UM51345GXDI00 , but this does not match the BOM file where it mentions MX25UW51345GXDI00. Additionally, the part number on the physical board itself differs from the block diagram WhatsApp Image 2026-02-09 at 16.15.15 (2).jpeg   WhatsApp Image 2026-02-09 at 16.15.14 (1).jpeg   . This is causing confusion, especially when trying to reference documentation or locate the correct data sheet. Could you clarify the exact flash part number currently used on the RT700-EVK? Also, if possible, could NXP provide the data sheet for this specific flash IC? That would be extremely helpful for our development. Re: MIMXRT700-EVK block diagram wrong part number reference I only wanted to report this issue so that in the next errata or next revision of the RT700 EVK board manual NXP can take this into consideration. for the datasheet I'll contact macronix.   Re: MIMXRT700-EVK block diagram wrong part number reference Hi @prathamvora, Please follow the BOM for the memory part number. For the datasheet, please contact Macronix. Best Regards, Pablo Re: MIMXRT700-EVK block diagram wrong part number reference Hi, Thank you for bringing this to our attention. For future reference, you can also use the following link to submit technical documentation feedback. Technical Documentation Feedback | NXP Semiconductors Best Regards, Pablo
View full article
RT1021 输入最大电流 您好,请问 GPIO 输入可以承受多大的电流?我使用的是 GPIO_AD_B1_02,通过该引脚的电流为 8mA。 在损坏引脚之前,输入端可承受的最大电流是多少? 如果我没理解错的话,该引脚是默认值,默认配置为带 100k 下拉电阻的输入引脚。 谢谢 Re: RT1021 input max current 你好,@jtrujillo、 一般来说,任何 RT1xxx GPIO 引脚的最大电流都应限制在 25mA,无论它是输出电流还是下沉电流。这是防止可靠性问题(如电迁移造成的潜在损坏)的技术安全极限,如果引脚需要,可以持续很长时间。 BR, Edwin.
View full article