Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
How install S32K144EVB SDK in S32 Design Studio Hello, Today, I have installed S32 Design Studio to evaluate a S32K144EVB board. I would like to run a small test, but reading manual, when I create a New Application Project, when I click over "SDK" button, it doesn't appear any S32 SDK. How I can install a SDK for my board Thanks. Re: How install S32K144EVB SDK in S32 Design Studio Hi @ptcaos  First, you need to download the software version that is compatible with your S32DS IDE. The supported IDE version is specified in the software's Release Notes document. For this example, I will use the latest RTD release available for S32K1 devices: Download S32K1_S32M24x_RTD_R21-11_3.0.0_D2503_DesignStudio_updatesite.zip. This package can be found under Real-Time Drivers for S32K1 → Automotive SW - S32K1_S32M24x - Real-Time Drivers for Cortex-M → S32K1_S32M24x Real-Time Drivers AUTOSAR R21-11 Version 3.0.0. In S32 Design Studio 3.6.x, navigate to Help → S32DS Extensions and Updates. In the S32DS Extensions and Updates window, click Add Update Site in the lower-right corner. Select the .zip file downloaded previously. Once added, the package will appear in the list of available extensions and updates. Select the packages you would like to install and click Install/Update. Accept the license agreement and click Finish. Upon successful installation, S32DS will prompt you to restart the IDE for the changes to take effect. Important: When creating a new project, make sure to select a toolchain version that is compatible with the installed RTD package. For example, RTD 3.0.0 was developed and tested using NXP GCC 10.2.0. This information is available in the corresponding Release Notes document.  BR, VaneB Re: How install S32K144EVB SDK in S32 Design Studio Spoiler (Highlight to read) Hello @VaneB  I have installed  S32K1_S32M24X Real-Time Drivers Version 3.0.0 QLP07 doing the same procedure you described but when I create a "New S32DS Application Project", there is no SDK available. I attatch two screenshots: one taken in the processors selection menu and another one taken after pressing "SDK" button. processor.png sdk empty.png Thanks. Hello  I have installed S32K1_S32M24X Real-Time Drivers Version 3.0.0 QLP07 doing the same procedure you described but when I create a "New S32DS Application Project", there is no SDK available.I attatch two screenshots: one taken in the processors selection menu and another one taken after pressing "SDK" button.Thanks. Re: How install S32K144EVB SDK in S32 Design Studio Hello @ptcaos , I had exactly the same problem, and the solution suggested by @VaneB  worked for me as well. I installed NXP GCC for Arm Release version 10.2 build 1728, and then, when creating the project, selected GCC 10.2 as the toolchain. After that, RTD 3.0.0 became available as an SDK option. 2026-08-10_18-14.png 2026-08-10_18-14_1.png So the important point seems to be that installing the RTD alone is not enough — the compatible GCC 10.2 toolchain also needs to be installed and selected. Thanks to NXP TechSupport for the solution! Re: How install S32K144EVB SDK in S32 Design Studio Hi @ptcaos  Please install NXP GCC for Arm Release version 10.2 build 1728. This should make RTD 3.0.0 available as an SDK option when creating a new project, as long as GCC 10.2 is selected as the project's toolchain.
記事全体を表示
MINISASTOCSI Latest Schematics Hi Team, Could you please help to share MINISASTOCSI latest schematics? Re: MINISASTOCSI Latest Schematics Hi @ramkrish, The most recent revision of the MINISASTOCSI board is A1. I have just sent the file to your email address for your reference. Please let me know if you have any trouble receiving it or if you need any additional information related to this board revision. Best regards, Chavira Re: MINISASTOCSI Latest Schematics Hi @Chavira Received, Thanks
記事全体を表示
How to obtain the correct Frame Pointer (FP) for DumpCallStack on S32K3 using the GHS compiler? Hi everyone, I am working on an S32K3 MCU using the Green Hills Software (GHS) compiler, and I am implementing a DumpCallStack function. To obtain the frame pointer (FP), I am using the following inline assembly: __asm volatile ("mov %0, r7" : "=r" (locals.fp)); However, the value I get for locals.fp is 0x02B1, which does not appear to be a valid frame pointer. It is not aligned and does not point to a valid stack location, so the call stack cannot be unwound correctly. My questions are: What is the correct way to obtain the current frame pointer when using the GHS compiler on the S32K3 (Arm Cortex-M7)? Does the GHS compiler always use R7 as the frame pointer, or can it omit the frame pointer or use another register depending on the optimization level? Are there any compiler options that must be enabled to preserve the frame pointer for stack unwinding? Is there a recommended GHS-specific API or intrinsic for retrieving the frame pointer instead of using inline assembly? If anyone has implemented stack unwinding or a DumpCallStack function with the GHS compiler on S32K3, I would appreciate any guidance or examples. Thank you! Re: How to obtain the correct Frame Pointer (FP) for DumpCallStack on S32K3 using the GHS compiler? Hi, I would not assume that R7 is always used as the frame pointer. Depending on the GHS version, optimization level, and compiler options, the compiler may use a different register or omit the frame pointer entirely and use R7 as a general-purpose register. The value 0x02B1 suggests that R7 might not be acting as a frame pointer in your build.  Please check the generated assembly and verify whether GHS is creating frame records at all. If frame pointers are enabled, you should see a consistent function prologue saving/restoring the frame pointer; otherwise stack unwinding based on R7/R11 will not be reliable. Since this is primarily a compiler-specific question, I would also recommend contacting Green Hills Software support. They can advise on: Whether GHS uses R7, R11, or another register as the frame pointer for your target/configuration. Which compiler options preserve frame pointers. Whether there is a recommended intrinsic or API for obtaining the current frame pointer. Preferred methods for implementing call stack unwinding with GHS. They are best positioned to provide guidance specific to your compiler version and settings. BR, Petr Re: How to obtain the correct Frame Pointer (FP) for DumpCallStack on S32K3 using the GHS compiler? Sure
記事全体を表示
PTP over SJA1110 Hi, We are debugging PTP on a PolarFire SoC GEM connected through an SJA1110 switch. We observe that: PTP over Layer 2 (ptp4l -2) is received by the switch (ingress counters increase), but it is not forwarded (egress counters do not increase). PTP over UDP (ptp4l ) is forwarded correctly through the same bridge path. Normal Ethernet traffic (ICMP/ARP) also forwards correctly. Is there any special handling or additional configuration required on the SJA1110 to forward Layer 2 PTP frames (destination MAC 01:1B:19:00:00:00) across bridged ports? Are there any known restrictions on forwarding Layer 2 PTP? Also, is PTP over UDP (ptp4l) fully supported and recommended with the PolarFire SoC GEM, or is Layer 2 the only supported/recommended transport? Any guidance would be appreciated. Re: PTP over SJA1110 Hello @Ankur_pixl , In a typical gPTP / time-aware bridge use case, the switch is not expected to forward all gPTP frames transparently as ordinary multicast traffic. The usual flow is that the switch receives the gPTP frames from the Grandmaster, processes them through the gPTP stack running on the internal Cortex-M7 and then generates its own gPTP frames with the appropriate timestamps towards the connected downstream devices.   SJA1110 is typically configured for the Layer 2 Automotive Profile, where the PTP destination MAC address is 01:80:C2:00:00:0E. This address is used for 802.1AS/gPTP style Layer 2 transport and such frames are normally handled by the switch PTP/gPTP function rather than simply bridged as regular multicast traffic.   Your observation that the ingress counters increase, while the egress counters do not increase, suggests that the Layer 2 PTP frames are received by the switch but are not forwarded through the normal bridge path. One likely explanation is that the used PTP multicast MAC address is matched by the SJA1110 configuration, for example in the General Parameters table, DPI configuration, L2 Lookup Table or another PTP/trap-related configuration item, and the frames are therefore trapped to the host port, most likely to the internal Cortex-M7 host, instead of being forwarded to the expected external egress port.   This would also explain why PTP over UDP and normal Ethernet traffic such as ICMP/ARP are forwarded correctly. These frames do not match the same Layer 2 PTP/gPTP classification rule and are therefore handled as normal bridge traffic.   Please check the following points in your SJA1110 configuration:   1. Which PTP destination MAC address is configured in the switch, especially in the General Parameters table. 2. Whether PTP/gPTP frames are configured to be trapped to the host port. 3. Whether the internal Cortex-M7 host is running a gPTP stack or receiving the trapped PTP frames. 4. Whether the used destination MAC address is 01:1B:19:00:00:00 or 01:80:C2:00:00:0E. 5. Whether the L2 Lookup Table or multicast forwarding configuration contains an entry that forwards this destination MAC to the required external ports. 6. Whether the ingress and egress ports are in the same VLAN and forwarding domain for this traffic.   If your intention is to use SJA1110 as a gPTP/time-aware bridge, then the expected configuration is usually not simple transparent forwarding of the original gPTP frames. The switch should participate in the gPTP timing domain and generate the corresponding gPTP messages towards the connected devices.   If your intention is instead to use SJA1110 only as a plain Ethernet bridge for raw Layer 2 PTP frames, then the PTP trapping/special handling must be disabled or avoided for this traffic, and the corresponding multicast destination MAC address must be explicitly allowed in the L2 forwarding configuration.   Regarding the PolarFire SoC GEM, I cannot make a definitive statement about the recommended or fully supported PTP transport mode for that device. From the SJA1110 point of view, PTP over UDP may be forwarded as ordinary IP/UDP traffic if the bridge path allows it. However, this does not necessarily mean that UDP transport is supported or recommended by the PolarFire GEM driver for hardware timestamping. Please confirm the supported PTP transport and timestamping modes with the PolarFire SoC GEM documentation or with Microchip support.   Best regards, Pavel Re: PTP over SJA1110 Hello @Ankur_pixl , The destination MAC address 01:1B:19:00:00:00 is an IEEE 1588 Layer 2 PTP multicast address. This is different from the 802.1AS / Automotive Profile gPTP destination MAC address 01:80:C2:00:00:0E, which is typically used in the SJA1110 gPTP Automotive Profile configuration.   Based on your description, this does not look like a standard Linux bridge MDB issue. The MDB entries may be correctly installed and even reported as offloaded, but the frame may still not reach the normal multicast forwarding path.   A likely explanation is that the SJA1110 hardware or the SJA1110 DSA driver classifies this destination MAC as a PTP/control frame before the normal L2 multicast forwarding decision is applied. In that case, the frame may be redirected to the CPU/management path instead of being forwarded directly between the two user ports.   This would explain the observed behavior:   - the ingress counter increases, so the frame is received by the switch, - the MDB entries are installed and shown as offloaded, - but the egress counter does not increase, because the frame is likely trapped to the CPU/management route before normal port-to-port forwarding is applied.   If the CPU/management route is not available in your port-to-port forwarding path, the trapped frame may effectively be dropped.   Regarding the Cortex-M7: if you are using the switch through the Linux DSA bridge and you do not run or control a gPTP stack on the internal Cortex-M7, then this should not normally be something configured from the Cortex-M7 application. In this use case, the relevant configuration is owned by the Linux DSA driver and by the switch hardware configuration programmed by that driver.   However, "bridge mdb" may not be sufficient if a dedicated PTP/control-frame trap rule is active for 01:1B:19:00:00:00. To forward this traffic directly in hardware between two user ports, the switch configuration would need to ensure that:   1. the PTP/control-frame trap for 01:1B:19:00:00:00 is disabled or bypassed for this traffic, and 2. a valid L2 multicast forwarding entry exists for 01:1B:19:00:00:00 towards the required user ports.   At this point, I would not expect the standard `bridge mdb` command alone to override a lower-level PTP/control-frame trap rule if such a rule is active in the SJA1110 DSA configuration.   As the next step, please check whether your SJA1110 DSA driver or BSP enables PTP hardware timestamping or installs any MAC filter / PTP trap rule for 01:1B:19:00:00:00. If such a rule is present, the solution will likely require a driver-level change or a switch static configuration change, rather than only a runtime Linux bridge MDB command.   Could you please share the following information?   - Linux BSP/kernel version, - SJA1110 DSA driver source baseline, - full output of "bridge -d mdb show", - the involved DSA port names and physical switch port numbers, - whether PTP hardware timestamping is enabled in the SJA1110 DSA driver, - and, if possible, a packet capture on the DSA master/CPU interface to confirm whether the Layer 2 PTP frames are being trapped to the CPU path.   With this information we can further check whether the frames are being consumed by the PTP/control trap path, or whether there is another L2 multicast forwarding limitation. Best regards, Pavel Re: PTP over SJA1110 Hello, The destination MAC is 01:1B:19:00:00:00. We're using the switch with the Linux DSA bridge and have no control or configuration access over the Cortex-M7 core. How do we allow this traffic through in the L2 configuration? We used bridge mdb, but it doesn't work; the entries install and even show as offloaded, yet the frames still aren't forwarded between the ports. Does this need to be set explicitly on the Cortex-M7 core? Additional context on our setup: Our MAC/port configuration is as follows: bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent bridge mdb add dev br-EPS port t1-6 grp 01:1b:19:00:00:00 permanent These show as offloaded in bridge -d mdb show, but L2 PTP frames arriving on one port are not forwarded out the other. Importantly, one of the switch ports does not have a working CPU port; it operates purely as a route between two ports (port-to-port forwarding), with no host/CPU port in that path. Since the reserved multicast 01:1b:19:00:00:00 appears to be trapped to the management/CPU route by default, and that route is not available here, we suspect the frames are being dropped rather than forwarded. Could you advise how to configure the switch to forward this reserved PTP multicast MAC in hardware between the two user ports, without relying on a CPU/management port? -- Ankur
記事全体を表示
S32K324 write DFlash by FEE Hello, There is a question about S32K324 write DFlash by FEE: I plan to write approximately 50 bytes of data into the DFalsh of S32K324 using the FEE method. Since the hardware power supply on the circuit board has a backup time of around 0.743ms, I need to save the critical data within this time frame. Is it feasible to write to the DFlash using the FEE method? If it is not feasible, are there any other options? Thanks. Re: S32K324 write DFlash by FEE Hi@mmyjh_123 For a power-off backup window of 0.743 milliseconds, FEE is not safe. Even "close to 1 millisecond," the write execution time for a single Fls_MainFunction block already exceeds your available hold time. You could try using C40_Ip. Using Quad-page (1024 bits) program time, a 50-byte write would theoretically take 450 microseconds. However, within 0.743 milliseconds, any erase operation during an emergency hold is impossible; erasing an 8 KB sector could take up to 30 milliseconds. Therefore, when implementing this functionality using C40_Ip, always erase the DFLASH address to be programmed during idle periods. Furthermore, if the board can detect input voltage drops before the MCU power failure, commit operations should begin at the earliest possible threshold. Otherwise, add a large capacity capacitor/backup power to ensure the guaranteed window covers the worst-case software path and flash programming margin. The above is only a theoretical analysis; multiple real-world tests are recommended, ensuring sufficient design margins. Re: S32K324 write DFlash by FEE Ok, thanks a lot.
記事全体を表示
Skid-steer robot state space modelling???? Hey everyone! I'm a beginner and just started working at a decently big lab with a bunch of people and I needed to figure a few things out. We're working on a skid-steer robot. I understand the dynamic and kinematic equations mathematically, but I don't know HOW exactly to convert them into state space. (which was the requirement) My team has the CAD model and they need to extract the Inertial Mass Parameters. They're a very chaotic group and I tried asking them, but they themselves don't have it together.😭 There's no well put resource for this kinda stuff either, and I'm genuinely at a loss of how to proceed with anything meaningful. Any pointers, help, and resources are appreciated! Cheers. Re: Skid-steer robot state space modelling???? Hello @prash, Could you please, provide me the following information? -Which NXP product are you currently using? Are you working with one of our EVKs, a custom board based on NXP MCU/MPU product, or another hardware solution? -Which IDE you are using? BR Habib
記事全体を表示
EasyEVSE 1060 to sigbrd2x interface issues This is a follow up to this post: https://community.nxp.com/t5/Power-Energy/EasyEVSE-signal-board-compatibility-and-availability/m-p/2384517 Short synopsis: I have a RT1060EVKB/Sigbrd2x EVSE, and a RT1064/Sigbrd2x EV running v5.0.8 software that I’m trying to stand up.  This was originally posted as a response to the question above, but I wasn’t sure whether the tech reps followed up on the thread responses. Thank you for your response.  I'm back working on this and am having issues getting EVSE code v5.0.8 that I got from NXP’s Git to work.  It builds fine and displays the GUI, but when I try to use its debug interface and request the version information, I get a correct response for the 1060 code of 5.0.8, but the version of the sigbrd2x shows as hw: v 255, and sw: v255.255.0.  I seem to recall reading a post somewhere that said there was some issue with a communications conflict with the LCD display on the 1060 board.  I can program the sigbrd2x and step code, so I'm pretty confident that that side is executing.  I'm using the EVSE-RT106X-CBL rather than the arduino headers.  My primary symptoms (besides the EV and EVSE sides not talking to each other) are the version reporting above that seems suspect, and I can't get past the "firmware download" status on the EVSE LCD, and the EVSE code on the 1060 won't start if the sigbrd2x is powered up (I'm powering them separately).  It feels like a communications issue.  Is there a patch / workaround for this?  If so, can you point me to documentation on how to resolve it? Best Regards, Chris Edwards Re: EasyEVSE 1060 to sigbrd2x interface issues Hi @chrisedwards , Thanks for your interest in NXP MIMXRT series! It seems the RT1060 is reading an idle/pulled-up SPI bus and getting no valid data back. This means the RT1060 ↔ Sigbrd2x SPI link never established — which also explains why the EVSE stays at "firmware download" and why the two sides don't talk. Suggested steps: - Scope the SPI lines (SCK/MOSI/MISO/CS). If MISO stays high, the board isn't responding → confirms the 0xFF. - Check the EVSE-RT106X-CBL wiring against the connector pinout in the signal-board manual — verify all SPI lines + GPIO are connected correctly. - LCD vs. SPI pin conflict: Temporarily disable the LCD and re-read the version to isolate it. - Follow the power-up order in the user guide, or power the host first. Best regards, Gavin Re: EasyEVSE 1060 to sigbrd2x interface issues Hi Gavin, Check sigboard’s qspi flash:               Powering the boards separately, I don’t see any traffic on the SPI pins of U17 (which is where I believe the switch gets its firmware).  I do see traffic on these pins on U17 of my EV setup (physically different board).  Check sigboard’s host interface SPI:               I don’t see any traffic on the spi pins of the host connector (19,21,23,24) when I have the 1060 powered and then apply power to the sigbrd2x (with the 1060 and sigbrd powered separately), nor when I power the sigbrd via the cable that goes to J32, with J2&J3 appropriately set). From digging into the User Guide (UG10140): I noticed that LEDs D18, D21, and D33 never illuminate.  They do on the sigbrd2x I have in my EV setup.  D24 does not illuminate on either setup.  D19 blinks. End state of debugging steps, after disabling the GUI: Ok with the LCD disabled by setting ENABLE_EVSE_UI to 0 in EVSE_config.h, the 1060 boots while connected to the sigbrd2x, using the cable that powers the sigbrd from J32 on the 1060, I can get a version number for the sigboard hw ( v2), and the sigboard sw v1.2.0.  Still no traffic on sigboard’s U17 nor illumination on LEDs D18, D21, 24, or D33.  D19 blinks.  Still no activity on the SPI pins on the sigboard’s host connector. So… progress, but it feels like the switch is not coming up at all. The user’s guide implies that the LEDs indicate that the switch isn’t working. Thanks and Best Regards,               Chris
記事全体を表示
i.MX 8QXP - LPDDR4 memory compatibility guide Hi Team, We are planning for an alternate for the LPDDR4 for the IMX8QXP. Please let me know if there is any updated list for the compatible LPDDR4 parts. i.MX 8/8X/8XLite - LPDDR4 and DDR3L memory compatibility guide Thanks and regards, Rohith Re: i.MX 8QXP - LPDDR4 memory compatibility guide Hi, Thank you for your interest in NXP Semiconductor products, The list was updated this year, that would be the last compatibility guide. Are you planning to use another memory? Regards Re: i.MX 8QXP - LPDDR4 memory compatibility guide Hi Joseph, We are planning to use a different LPDDR4 due to the lead time and other reasons. Whether NXP will support for validating the Memory? And what is the procedure for validating new memory from NXP side Thanks and regards, Rohith 
記事全体を表示
IMX8MP linux uboot need to be set up with the default environment + extra variables IMX8MP linux uboot need to set up the default environmnet + few more variables after the flashing the bootloader via uuu. Use case: The IMX8MP SoM comes with default uboot from vendor. So for the first time writing need to flash the new uboot image, we set it to the default environment and set few more board specific environment variables on the factory process. So when I'm using the command, uuu -b emmc_all bl-imx8mp.bin image.wic.zst its using the builtin script uuu_version 1.4.149 # @_flash.bin | bootloader, which can extract from wic image # @_image [_flash.bin] | wic image burn to emmc. # This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ SDP: boot -f bl-imx8mp.bin -scanlimited 0x800000 # This command will be run when ROM support stream mode # i.MX8QXP, i.MX8QM SDPS: boot -scanterm -f bl-imx8mp.bin -scanlimited 0x800000 # These commands will be run when use SPL and will be skipped if no spl # SDPU will be deprecated. please use SDPV instead of SDPU # { SDPU: delay 1000 SDPU: write -f bl-imx8mp.bin -offset 0x57c00 SDPU: jump -scanlimited 0x800000 # } # These commands will be run when use SPL and will be skipped if no spl # if (SPL support SDPV) # { SDPV: delay 1000 SDPV: write -f bl-raptor-imx8mp.bin -skipspl -scanterm -scanlimited 0x800000 SDPV: jump -scanlimited 0x800000 # } FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all image.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 bootloader bl-imx8mp.bin FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: done So my requirement is Flash the bootloader + rootfs / image Reset to defaults. Add new variables. Reboot with proper working new bootloader with expected env. But now its first flashing the rootfs and then the new bootloader. So when I executed env default -f -a, after it, it causes the default of environment of old bootloader in the SoM board. When it resetted, it starts then with new bootloader but with old defaults from old bootloader. Is there any suggestion to solve this issue? Re: IMX8MP linux uboot need to be set up with the default environment + extra variables Hello @jake4  Hope you are doing very well. You can try making your own custom script and add the below: FB: ucmd env default -f -a Example of complete script: uuu_version 1.4.149 SDP: boot -f bl-imx8mp.bin -scanlimited 0x800000 SDPS: boot -scanterm -f bl-imx8mp.bin -scanlimited 0x800000 SDPU: delay 1000 SDPU: write -f bl-imx8mp.bin -offset 0x57c00 SDPU: jump -scanlimited 0x800000 SDPV: delay 1000 SDPV: write -f bl-imx8mp.bin -skipspl -scanterm -scanlimited 0x800000 SDPV: jump -scanlimited 0x800000 FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all image.wic.zst/* FB: flash -scanterm -scanlimited 0x800000 bootloader bl-imx8mp.bin FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: ucmd env default -f -a FB: ucmd setenv board_version "1.0" FB: ucmd setenv my_custom_var "value" FB: ucmd saveenv FB: ucmd reset FB: done Best regards, Salas. Re: IMX8MP linux uboot need to be set up with the default environment + extra variables Hi @Manuel_Salas , We would have only eth fastboot enabled in the uboot , so we cant use the boot switch of SDP. Can you please let me know if there is a option with only the fastboot command. Thanks
記事全体を表示
i.MXRT1052和FPGA通讯用SRAM AADM模式,有些信号没有输出 i.MXRT1052和FPGA通讯用SRAM AADM模式,有些信号没有输出。 我现在用的AADM模式。但是在实际配置的时候没有看到WE#,OE#。还是配置的SEMC_ADDR11/SEMC_ADDR12。现在这两个信号在FPGA端没有变化。但是数据和地址是有变化的,ADV#也是有变化的。SEMC_CS0没有变化。 这是为什么?我看到手册上的SEMC Pin Mux。SEMC_ADDR11是WE#,SEMC_ADDR12是OE#,但是在MCUXpresso Config Tools 26.06里面配置的时候没有OE#和WE#。 还是其他什么原因导致没有信号。 Re: i.MXRT1052和FPGA通讯用SRAM AADM模式,有些信号没有输出 Hi @SDFDSFSF ,    请注意,不要用SEMC_CS0做FPGA SRAM的片选。SEMC_CS0是SDRAM CS0, SRAM应该使用SEMC_CSX[3:0], 并在SEMC->IOCR里把对应的MUX_CSXx配置成SRAM CE#。 ShellyZhang_0-1786353236746.png ShellyZhang_1-1786353306649.png      另外,确认外设初始化后,寄存器SRAMCR0.AM= 01 (AADM)。当SRAM工作在AADM模式下,SEMC会自动将SEMC_ADDR11定义为WE#,SEMC_ADDR12定义为OE#。 Best Regards, Shelly
記事全体を表示
Inquiry on Alternative Parts for MW6S010GNR1 Dear  support team  Part number MW6S010GNR1 has been discontinued. Could you please recommend equivalent alternative models? Our application is industrial wideband RF equipment. thanks so much Re: Inquiry on Alternative Parts for MW6S010GNR1 **MW6S010GNR1 Status & Recommended Alternatives** ### Part Overview **MW6S010GNR1** (NXP / former Freescale) is a **10 W, 28 V LDMOS** RF power transistor designed for broadband applications. | Parameter | Value | |------------------------|--------------------------------| | Frequency range | 450 – 1500 MHz | | Output power | 10 W | | Supply voltage | 28 V (qualified up to 32 V) | | Typical gain | ~18 dB @ 960 MHz | | Package | TO-270-2 Gull Wing (GNR1) | | Application | Class A / AB, base station, broadband industrial RF | **Status**: Discontinued / End of Life (part of NXP Radio Power product line ramp-down). Last Time Buy is expected around **30 September 2026**, with final shipments targeted for **2027**. --- ### Recommended Equivalent / Alternative Models There is **no exact pin-to-pin drop-in replacement** from NXP. Below are the closest practical alternatives for industrial wideband RF equipment. All will require matching network re-optimization. | Priority | Part Number | Manufacturer | Key Specs | Package | Notes / Compatibility | |----------|----------------------|--------------|----------------------------------------|--------------|-----------------------| | 1 | **MW6S010NR1** | NXP | Same electrical specs as GNR1 | TO-270-2 | Non-Gull Wing version of the same die. Also discontinued, but may still have residual stock. | | 2 | **BLP15H9S10G** or **BLP15H9S10** | Ampleon | 10 W, 50 V, very wideband (1–2000 MHz) | TO-270 | Excellent wideband industrial alternative. Higher voltage, needs matching redesign. | | 3 | **BLP15M9S30G** / related 28–32 V devices | Ampleon | 30 W class, 1–1500 MHz, 32 V | TO-270 | Higher power option if headroom is acceptable. | | 4 | **AFT27S010N** | NXP | ~10 W, 28 V, broader frequency coverage | Plastic | Newer generation, but different package and matching required. Check current availability. | | 5 | Other 10 W / 28 V LDMOS | Ampleon / Infineon | Various | TO-270 or similar | Search for unmatched wideband LDMOS in 10 W class. | --- ### Practical Recommendations for Industrial Wideband Use 1. **Short-term** - Check remaining stock of **MW6S010GNR1** and **MW6S010NR1** for Last Time Buy. - If pin-out compatibility is critical, prioritize the NR1 version if available. 2. **Medium / Long-term (Recommended)** - Migrate to **Ampleon BLP15H9S10(G)** series. These are modern, wideband, rugged LDMOS devices commonly used in industrial, ISM, and broadband RF applications. - They offer better long-term availability and support. 3. **Design Notes** - Expect to redesign the input/output matching networks. - Verify thermal performance, bias point (IDQ), and VSWR ruggedness in your specific industrial environment. - Confirm package footprint and soldering profile compatibility. --- **Would you like me to:** - Compare detailed electrical parameters (gain, efficiency, capacitances) between MW6S010GNR1 and a specific alternative (e.g. BLP15H9S10G)? - Help search for current stock/pricing of the recommended parts? - Suggest matching circuit references or evaluation boards? Please share your exact frequency band, power requirement, and preferred supply voltage if you need a more targeted recommendation. Email: [email protected]
記事全体を表示
[FRDM-IMXRT1186] Question about ADC Power Sequencing (VDDA_1P8 vs 3P3) I am reviewing the FRDM-IMXRT1186 (SCH-95302 Rev.A4) and the RT1180 Data Sheet Rev.9. The datasheet requires VDDA_ADC_1P8 to be powered prior to VDDA_ADC_3P3. However, on the FRDM board, VDDA_ADC_1P8 comes from an AMS1117-1.8 regulator tied to VDD_3V3, meaning it follows the 3.3V rail's soft-start. Additionally, VDDA_ADC_3P3 is left floating by default (R337=DNP). My questions: 1.Is the FRDM board considered compliant with the datasheet sequence given this implementation? 2.For a production design, is it mandatory to use a PMIC or an LDO with an EN pin to strictly meet the "prior-to" requirement? 3.I have attached a screenshot of the relevant schematic section. I will post my detailed analysis in the comments below to keep this initial post clear. FRDM-Training i.MXRT 106x Re: [FRDM-IMXRT1186] Question about ADC Power Sequencing (VDDA_1P8 vs 3P3) Hi @rejust , Thank you so much for your interest in our products and for using our community. Yes, from the default FRDM-IMXRT1186 schematic, the design is intended to meet this sequencing requirement. R337 is DNP by default, so VDDA_ADC_3P3 is not directly tied to VDD_3V3 through the 0 Ω bypass path. Instead, VDDA_ADC_3P3 is supplied through the U17 MOSFET sequencing circuit. This circuit is controlled by the VDDA_ADC_1P8 / ADC_1V8_IN rail, so VDDA_ADC_3P3 is enabled only after VDDA_ADC_1P8 is established. mayliu1_1-1786335579964.png For production design, a PMIC is not mandatory. Any reliable sequencing method is acceptable, such as a PMIC, LDO/load switch with EN control, or a MOSFET sequencing circuit, as long as the timing at the SoC pins meets the datasheet requirement. mayliu1_0-1786335561512.png Wish it helps you Best Regards May
記事全体を表示
LX2160A get MP key failed Hi NXP, We are building LX2160A secure boot system based on LLDP and verifying MP key function. Install and start up the secure boot system on our LX2160A board are OK and so we think ITS bit value is 1, but get "Device is not initiated" error after execute "mp_app -p" command. 截圖 2026-07-22 15.50.34.png Do you have any advice to check this issue ? Thank you, Jeffrey  Re: LX2160A get MP key failed Did customer follow LLDP document section 6.4.4?   screenshot-1.png Such as Run tee-supplicant & command from the Linux prompt. Depending on the Linux kernel version used insmod securekeydev.ko from right folder Please also let customer enable kernel printk when run 'mp_app', and share their log. echo 8 > /proc/sys/kernel/printk dmesg Re: LX2160A get MP key failed Hi yipingwang, Yes, we start tee-supplicant and load securekeydev.ko before execute mp_app command. 截圖 2026-07-24 14.22.00.png The following is dmesg information. 截圖 2026-07-24 14.22.27.png Jeffrey Re: LX2160A get MP key failed Please refer to the following update from the AE team. From customer's feedback, I can see "error: caam_submit_mp_get_pub_key_op: submit_job", it indicates send job to SEC failed. Please ask customer do below test in their Linux system, 1. run xtest, to see any error report? 2. please run "modprobe caam" to install caam module for LX2160, if install module failed, please update modules compatible with your kernel version. 3. If also report error, apply below patch to check SEC return result to identify the error type, and share their full log. diff --git a/securekeydev/securekey_caam.c b/securekeydev/securekey_caam.c index b82acd3..d657742 100644 --- a/securekeydev/securekey_caam.c +++ b/securekeydev/securekey_caam.c @@ -59,12 +59,14 @@ static int submit_job(struct device *jrdev, uint32_t *desc) /* Call caam_jr_enqueue function for Enqueue a job descriptor head. */ ret = caam_jr_enqueue(jrdev, desc, caam_op_done, NULL); + pr_err("caam_jr_enqueue ret (%d)\n", ret); if (!ret) wait_for_completion_interruptible(&comp); else return ret; ret = job_comp_status; + pr_err("job_comp_status ret (%d)\n", ret); return ret; } Regards, Re: LX2160A get MP key failed About your comments, 1. run xtest, to see any error report? Please refer to attached xtest log. 2. please run "modprobe caam" to install caam module for LX2160, if install module failed, please update modules compatible with your kernel version. We built caam module in kernel already. 3. If also report error, apply below patch to check SEC return result to identify the error type, and share their full log. The dmesg about caam and mp_app return as below. 截圖 2026-07-29 16.03.42.png 截圖 2026-07-29 15.53.07.png   Thank you. Re: LX2160A get MP key failed 1. Please make sure caam job ring work well in Linux kernel, please run below command to check caam jr interrupt increase or not root@localhost:~# cat /proc/interrupts | grep jr 378: 41 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 172 Level 8010000.jr 379: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 173 Level 8020000.jr 380: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 174 Level fsl-jr0 root@localhost:~# root@localhost:~# root@localhost:~# dd if=/dev/hwrng of=/tmp/random.dat bs=1 count=16 16+0 records in 16+0 records out 16 bytes copied, 0.000420759 s, 38.0 kB/s root@localhost:~# root@localhost:~# root@localhost:~# cat /proc/interrupts | grep jr 378: 42 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 172 Level 8010000.jr 379: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 173 Level 8020000.jr 380: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 GICv3 174 Level fsl-jr0 root@localhost:~# 2. In submit_job() the called function caam_jr_enqueue() return (-EINPROGRESS = -115) on success. Please try apply below patch to check caam enqueue return result. https://github.com/nxp-qoriq/linux/commit/4d370a1036958d7df9f1492c345b4984a4eba7f6#diff-8acc41c534456288daba59a125ddb3f779635dc493ff4888545adbf1dd0a17c1R327 diff --git a/securekeydev/securekey_caam.c b/securekeydev/securekey_caam.c index b82acd3..808e8da 100644 --- a/securekeydev/securekey_caam.c +++ b/securekeydev/securekey_caam.c @@ -59,12 +59,14 @@ static int submit_job(struct device *jrdev, uint32_t *desc) /* Call caam_jr_enqueue function for Enqueue a job descriptor head. */ ret = caam_jr_enqueue(jrdev, desc, caam_op_done, NULL); - if (!ret) + pr_err("caam_jr_enqueue ret (%d)\n", ret); + if (ret == -EINPROGRESS) wait_for_completion_interruptible(&comp); else return ret; ret = job_comp_status; + pr_err("job_comp_status ret (%d)\n", ret); return ret; } Re: LX2160A get MP key failed 1. Please make sure caam job ring work well in Linux kernel, please run below command to check caam jr interrupt increase or not Ans: Yes 截圖 2026-07-31 17.33.06.png 2. In submit_job() the called function caam_jr_enqueue() return (-EINPROGRESS = -115) on success. Please try apply below patch to check caam enqueue return result. Ans: Our system uses Linux kernel v5.15.71-rt51 and it seems need not do any additional patches. 3. In addition, after run mp_app -p command, the process stops at wait_for_completion_interruptible() and it is waiting the return so far. 截圖 2026-07-31 17.33.36.png    Re: LX2160A get MP key failed Please double check your kernel source code. caam_jr_enqueue() has update return value in this brach. https://github.com/nxp-qoriq/linux/blob/95448dd0dc9b621ae027cbefedaaa7c3d0d3ad2d/drivers/crypto/caam/jr.c#L565 Re: LX2160A get MP key failed Please refer to the following update from the AE team. Customer can check whether ITS bit enabled by u-boot 'md' command. md 0x1e80200 Can customer share caam_jr_enqueue() function source code? The source code path is "linux/drivers/crypto/caam/jr.c". Or they can share us their source code link. Re: LX2160A get MP key failed We checked all drivers/crypto/caam source files and they are the same. We enable ITS by uboot scripts as below mw.l 0x1e80200 0x4 mw.l 0x1e80020 0x2 Do you think the ITS activation process is incomplete ? Re: LX2160A get MP key failed Register value please see below and jr.c source code please see attached file . list_register.png Re: LX2160A get MP key failed We have patched submit_job() as you mentioned before and the result is stops at  "wait_for_completion_interruptible" after run "mp_app -p". According to the description from LSDK and LLDP user manual, security applications are fully validated and verified on LS1046ARDB platform, we verify this issue on our LS1046 board with LSDK and it's working. lx1046_mp_key.png Verify our another LX2160 product with LSDK and it also stops at "wait_for_completion_interruptible". lx2160_lsdk.png Whether use LSDK or LLDP, we get the some issue on LX2160A platform. Did NXP do security applications validation on LX2160A platform ? Re: LX2160A get MP key failed ITS bit has been blown. Check your jr.c source code, you need to apply the patch for submit_job. diff --git a/securekeydev/securekey_caam.c b/securekeydev/securekey_caam.c index b82acd3..808e8da 100644 --- a/securekeydev/securekey_caam.c +++ b/securekeydev/securekey_caam.c @@ -59,12 +59,14 @@ static int submit_job(struct device *jrdev, uint32_t *desc) /* Call caam_jr_enqueue function for Enqueue a job descriptor head. */ ret = caam_jr_enqueue(jrdev, desc, caam_op_done, NULL); - if (!ret) + pr_err("caam_jr_enqueue ret (%d)\n", ret); + if (ret == -EINPROGRESS) wait_for_completion_interruptible(&comp); else return ret; ret = job_comp_status; + pr_err("job_comp_status ret (%d)\n", ret); return ret; } Re: LX2160A get MP key failed Please refer to the following update from the AE team. 1. Team confirms that this feature just be performed on LS1046A board as LSDK document mentioned. 2. From customer running log for LX2160 and LS1046, both run with LSDK20.04, kernel version 4.19, caam_jr_enqueue() return 0 in this version, not need apply my patch. https://github.com/nxp-qoriq/linux/blob/94e0473db2feed7ed6b84848c8d227faf72297c2/drivers/crypto/caam/jr.c#L408 3. I need further test on my side. Will update when get findings.
記事全体を表示
FS32K144UAT0VLLT哪个Time具备Input capture功能? 经理: 请教问题: (1)FS32K144UAT0VLLT规格书显示具备8个独立TIME,只看到FTM0,FTM1,FTM2,还有哪些也是TIME? (2)FS32K144UAT0VLLT的哪个TIME具备Input capture功能? 谢谢! Re: FS32K144UAT0VLLT哪个Time具备Input capture功能? Robin_Shen 你好,补充问题: 1. S32K-RM Rev14.2的Table 47-1. FTM instances and features 表格里,“Fault inputs"是什么参数? 2. S32K-RM Rev14.2手册多少页显示每个FTM都具备input capture功能? 谢谢! Re: FS32K144UAT0VLLT哪个Time具备Input capture功能? A1. 就是支持几路外部Fault输入,以S32K144为例Table 47-1写了支持4路,你可以在左侧表格看到FTM0_FLT0\1\2\3 这4路。 Table 47-1. FTM instances and features Table 47-2. FTM signal descriptions.png A2. 每个FTM都支持的功能,通常不会特地写出来。你按照Table 47-5. Channel Modes Selection配置寄存器就能实现47.5.5 Input Capture Mode 提到的input capture 模式了。
記事全体を表示
Building NXP Android 16 BSP in AWS or GCP Cloud – Experience, Setup and Build Times Hi everyone, I am currently working on setting up Android 16 for an NXP i.MX 95 and would like to build the NXP BSP in a cloud environment. The release I am using is: Android 16.0.0_2.0.0 (L6.18.20_2.0.0 BSP) I am currently looking into using AWS or Google Cloud Platform (GCP) as the build environment instead of a local workstation. I would therefore like to ask the community: Is there any official NXP documentation or recommendation for building the Android BSP in AWS or GCP? Has anyone already successfully built this Android BSP in AWS or GCP? Which instance/VM configuration did you use (CPU, RAM, storage, etc.)? Approximately how long does a complete BSP build take in your setup? What were the approximate cloud costs per build? Are there any specific issues or limitations to be aware of when building the BSP in a cloud environment? I am especially interested in practical experience, for example which cloud instance type worked well and whether there are any important considerations regarding RAM, disk space, CPU cores, storage performance or build parallelization. Any recommendations, example configurations or lessons learned would be greatly appreciated. Thanks in advance for sharing your experience! Best regards Fb Re: Building NXP Android 16 BSP in AWS or GCP Cloud – Experience, Setup and Build Times Hello @Feevlic  Hope you are doing very well. We do not have documentation for that specific scenario for compiling Android. The process should be the same as a physical machine. Please try following the steps of the UG10156 Android User's Guide. Best regards, Salas.
記事全体を表示
MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH Hi Team, I am working with the MIMXRT1040-EVK and using MCUXpresso IDE with LinkServer/SWD. I am facing an issue where my application works correctly when linked and executed from RAM, but when configured to execute from external FlexSPI NOR Flash, the debugger does not reach main(). Current behavior RAM build: "Link application to RAM" enabled Application downloads successfully Application executes correctly Debugger reaches main() I can debug the application normally Flash/XIP build: "Link application to RAM" disabled Application is linked to external Flash starting at 0x60000000 Build completes successfully .axf is generated When I start debugging, the debugger does not reach main() The CPU does not appear to execute from the expected 0x600xxxxx XIP address range Linker/map information The generated .map file shows the expected XIP layout: .boot_hdr 0x60000000 .boot_hdr.conf 0x60000000 .boot_hdr.ivt 0x60001000 .boot_hdr.boot_data 0x60001020 .text 0x60002000 .isr_vector 0x60002000 ResetISR 0x6000231C main 0x60004EF4 So the application appears to contain the expected FlexSPI NOR boot header, IVT, boot data, vector table, ResetISR, and application code. I also have: XIP_EXTERNAL_FLASH = 1 XIP_BOOT_HEADER_ENABLE = 1 Important observation After attempting to debug/program the Flash image, I checked the memory at: 0x60000000 0x60001000 0x60002000 and the memory window shows 0x00000000/empty data rather than the expected application contents. For example, at: 0x60002000 I expected the application vector table, but the memory appears to contain zeros. The CPU registers after the failed debug attempt also showed: PC = 0x0020E368 SP = 0x20200F70 LR = 0x0020ED49 rather than a PC in the expected 0x600xxxxx XIP region. Debug configuration I am using: Debug Connection: SWD Connect script: RT1040_connect.scp The Debug configuration has: Load image: enabled Use project binary: igpio_led_output.axf Load symbols: enabled Use project binary: igpio_led_output.axf Set breakpoint at: main Request hardware breakpoint: enabled The LinkServer Debug configuration is being used. Project contents The project contains the standard XIP-related files: xip/ ├── evkmimxrt1040_flexspi_nor_config.c ├── evkmimxrt1040_flexspi_nor_config.h ├── fsl_flexspi_nor_boot.c └── fsl_flexspi_nor_boot.h The generated linker script also places the boot header and application into the BOARD_FLASH region beginning at 0x60000000. My question Could someone please help me determine why the external FlexSPI NOR Flash is not being programmed with the generated XIP image when launching the LinkServer debug session? Specifically: Does the MIMXRT1040-EVK + LinkServer require a specific FlexSPI NOR Flash driver/configuration for debugging XIP applications? Is RT1040_connect.scp sufficient for both connecting and programming the external NOR Flash? Is there any additional Flash programming configuration required in the MCUXpresso Debug Configuration? Should the Debug configuration use a specific flexspi_nor Flash driver or Flash Tool configuration? Is there a known issue with LinkServer + MIMXRT1040 + external FlexSPI NOR + XIP debugging where the .axf is loaded as symbols but the external Flash is not actually programmed? Is there a recommended NXP example project/configuration that I can compare against for a working MIMXRT1040-EVK FlexSPI NOR XIP debug session? I would appreciate any guidance on what I should check next. Thank you. Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH Thank you for the response. I checked the MCU Settings → Memory details as you suggested. I have attached the screenshot. The BOARD_FLASH memory is configured as: Location: 0x60000000 Size: 0x800000 Flash Driver: MIMXRT1040_SFDP_QSPI.cfx So, it appears that the specific external Flash driver is already configured for BOARD_FLASH. I also tried the Serial Download Mode + MCU Provisioning Tool procedure. I was able to successfully Build Image and Write Image using the MCU Provisioning Tool. However, after that, I was still unable to get the application programmed/debugged from Flash through the normal MCUXpresso + LinkServer debug flow. Interestingly, when I tried flashing/debugging the code one more time later, it suddenly worked and the application was successfully running from Flash. I did not intentionally change the project configuration, Flash driver, linker configuration, or boot settings between the failed and successful attempts. So, at this point, I suspect there may be some intermittent issue related to the Flash programming/initialization/reset sequence rather than the application/linker configuration itself. Could you please advise what could cause this behavior on the MIMXRT1040-EVK? In particular: Is MIMXRT1040_SFDP_QSPI.cfx the correct Flash driver for the EVK's external FlexSPI NOR? Is the fact that the Default LinkServer Flash Driver field is blank significant, even though BOARD_FLASH has MIMXRT1040_SFDP_QSPI.cfx assigned in the Driver column? Could the external Flash remain in an unexpected state after a previous failed programming/debug attempt, requiring a specific reset or power cycle? Could RT1040_connect.scp or the LinkServer reset/connection sequence cause intermittent Flash programming behavior? Is there any known issue with the MIMXRT1040-EVK, LinkServer and MIMXRT1040_SFDP_QSPI.cfx where Flash programming may fail intermittently? Since the same configuration eventually worked without any intentional change, I would like to understand what could have caused the previous failure so that we can make the Flash debugging/programming reliable. Thank you. Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH Hi @Prashanth1 , Based on the screenshot you provided, the Flash driver configuration appears to be fine. Could you first try putting the board into serial download mode and using the MCUXpresso Secure Provisioning Tool to download the image to Flash by usb/uart? This method isolates the influence of the debugger and can be used to check whether the board has any flash hardware issues. Additionally, please provide me with the log of the failed download attempt using the debugger. On my end, I’ll arrange for an RT1040-EVK as soon as possible and try to reproduce the issue using the project package you previously attached. Best regards, Gavin Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH Hi Gavin Sir, Thank you for the response. I checked the MCU Settings → Memory details as you suggested. I have attached a screenshot. In my project, the BOARD_FLASH memory is configured as: Location: 0x60000000 Size: 0x800000 Driver: MIMXRT1040_SFDP_QSPI.cfx So, it appears that the FlexSPI NOR Flash driver is already associated with the BOARD_FLASH memory region. However, I noticed that the “Default LinkServer Flash Driver” field at the top of the MCU Settings is blank, while the driver column for BOARD_FLASH shows MIMXRT1040_SFDP_QSPI.cfx. Could you please confirm: Is this configuration correct for the MIMXRT1040-EVK? Should I also select MIMXRT1040_SFDP_QSPI.cfx in the Default LinkServer Flash Driver field? Or is the driver shown in the BOARD_FLASH row sufficient for LinkServer to program the external FlexSPI NOR? My main issue is that the application is correctly linked for XIP at 0x60000000, but after launching the LinkServer debug session, I don't see the application contents at 0x60000000 / 0x60002000 in the Memory window. RAM debugging works correctly with the same application. I have attached the MCU Settings screenshot for reference. Thank you. RT1040MCUsettings.png     Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH Hi @Prashanth1 , Thanks for your interest in NXP MIMXRT series! When using an external Flash, a specific Flash driver is required. Please check whether the Flash driver has been loaded correctly in the IDE: (My screenshot uses the RT1170 as an example; the process is similar for the RT1040.) Gavin_Jia_0-1786341203390.png Best regards, Gavin Re: MIMXRT1040-EVK: Debug works from RAM, but it's not working for FLASH Hi @Prashanth1 , Based on the described phenomenon, the most likely cause is that there was dirty data/image in the Flash memory previously. Whether it is an incorrect FCB header or an image that causes the MCU to enter an error state upon execution, such issues can lead to failure when attempting to re-flash the image. The standard recovery method in this scenario is to enter serial download mode. You may want to consult this article: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs-Knowledge/RT-board-recovery-for-debugger-connect-issues/ta-p/1635260 Regarding the selection of the flash loader, you simply need to select the appropriate flash driver in the "Flash" row within the IDE. The *.scp file is provided with the SDK and is used for pre-configuring the link server; You can go into the file to learn more about each line of command. Best regards, Gavin
記事全体を表示
FAQs – NAFEB43388 and NAFEBx3388 Evaluation Board Introduction The NAFEB43388 is a highly configurable, industrial-grade, 8-input universal analog front-end designed for high-precision measurement applications such as PLCs, DCS I/O modules, remote/distributed I/O, data acquisition systems, instrumentation, and industrial automation. It integrates a 24-bit sigma-delta ADC, 13-bit DAC, high-voltage multiplexers, programmable gain amplifiers, precision references, diagnostics, and an integrated sense resistor with protection switch for current measurements. The NAFEBx3388-EVB evaluation board supports evaluation of pin-compatible NAFEB43388/NAFEB73388 family devices and is intended to demonstrate high-precision industrial measurements using the FRDM-MCXN947 MCU platform and a Windows-based GUI. For detailed register settings, timing diagrams, electrical limits, and calibration procedures, please refer to the latest NAFEB43388 product data sheet and the NAFEBx3388-EVB user manual available on nxp.com.  1. What is the NAFEB43388? The NAFEB43388 is a highly configurable multichannel universal-input Analog Front-End intended for precision industrial measurements. It integrates a 24-bit sigma-delta ADC, 13-bit DAC, low-leakage high-voltage multiplexers, low-offset and low-drift PGA stages, internal voltage references, diagnostics, and an integrated current-sense resistor protected by a smart e-fuse circuit. 2. What applications is the NAFEB43388 designed for? Typical applications include PLC and DCS I/O modules, remote and distributed I/O modules, sensor and data acquisition systems, instrumentation, and industrial automation or process-control equipment. 3. How many analog inputs does the NAFEB43388 support? The device provides eight high-voltage analog inputs plus one common input. These inputs can be configured for single-ended, differential, or pseudo-differential measurements depending on the measurement topology and register configuration. 4. What types of signals can the NAFEB43388 measure? The NAFEB43388 supports software-configurable measurement of voltage, current, resistance, RTD, and thermocouple-type sensor signals. The supported input ranges include voltage up to ±12.5 V, current up to ±25 mA, and resistance measurement capability from 1 mΩ to 1 MΩ according to the fact sheet, while the datasheet describes programmable current excitation for resistance and RTD measurements. 5. What is the ADC resolution and data-rate range? The NAFEB43388 integrates a 24-bit sigma-delta ADC. For the low-power NAFEB43388 variant, the ADC data rate is configurable from 7.5 samples per second up to 288k samples per second, depending on the selected data-rate code, SINC filter configuration, and settling mode. 6. What is the DAC resolution and output capability? The integrated DAC has 13-bit resolution and can be configured for voltage output or current output. The DAC supports voltage output up to approximately ±12.5 V full-scale and current output up to approximately ±2.5 mA full-scale, with a DAC data rate up to 100 ksps. 7. What is the difference between NAFEB43388, NAFEB43188, NAFEB73388, and NAFEH73388? The NAFE family includes low-power and high-speed variants, with or without factory calibration and HART modem support. The NAFEB43388 is a low-power, 24-bit, 8-input device with factory calibration and no HART modem. The NAFEB43188 is similar but without factory calibration. The NAFEB73388 is a high-speed 24-bit, 8-input variant with factory calibration, and the NAFEH73388 adds HART modem support. 8. What is the NAFEBx3388-EVB? The NAFEBx3388-EVB is an evaluation board designed to evaluate pin-compatible NAFEB43388 and NAFEB73388 AFE devices. It enables high-precision industrial measurements using the FRDM-MCXN947 MCU platform and includes a GUI for configuring and testing the device. 9. What hardware is included in the NAFEBx3388 evaluation kit? The evaluation kit includes the NAFEBx3388 evaluation board, an FRDM-MCX947 evaluation board with custom firmware, and a USB cable. The EVB is connected to the FRDM-MCX947 board through Arduino-compatible connectors. 10. How is the NAFEBx3388-EVB powered? The EVB can be powered using the supplied 24 V AC-DC adapter connected to J307, with jumpers J308, J309, and J310 set to the 2-3 position. Alternatively, external supplies can be applied: AVDD/DVDD = 3.75 V on J300, HVDD = +15.4 V on J301, and HVSS = -15.4 V on J302, accounting for the voltage drop across the protection diode in the supply path. 11. How does the NAFEB43388 support voltage measurements? The AFE can measure differential, pseudo-differential, and single-ended voltage signals. Single-ended measurements are performed by connecting the positive signal to AIxP or AIxN and the negative signal to AICOM, while differential measurements use the corresponding AIxP and AIxN pair. 12. What voltage input ranges are available? The input range depends on the total programmed channel gain. For single-ended input, the nominal linear ranges include ±10 V at gain 1, ±5 V at gain 2, ±2.5 V at gain 4, ±0.625 V at gain 16, ±0.313 V at gain 32, and ±0.156 V at gain 64. For differential input, the corresponding nominal linear ranges are ±20 V, ±10 V, ±5 V, ±1.25 V, ±0.625 V, and ±0.313 V. 13. How does the NAFEB43388 support current input measurements? The AI1P pin can measure current using the integrated 25 Ω sense resistor and the configurable current-input protection switch, CISW. This supports common industrial current ranges such as ±20 mA, 0 mA to 20 mA, and 4 mA to 20 mA. 14. What protection is available for current input mode? When current input mode is selected on AI1P, the integrated CISW protection switch supports fault handling. The datasheet describes three current levels: approximately 50 mA short-circuit or overcurrent threshold, 30 mA overload threshold, and 12 mA current-limiter level. The overcurrent deglitch time, overcurrent limit time, and limiter delay can be configured. 15. What is the purpose of the programmable gain amplifiers? The NAFEB43388 includes two PGA stages. PGA1 operates in the high-voltage domain and supports gains of 1 and 16, while PGA2 operates in the low-voltage domain and supports gains of 1, 2, and 4. Combining both stages provides total gains from 1 to 64, allowing the input range to be matched to the signal amplitude. 16. What are the available ADC reading modes? The NAFEB43388 supports five conversion modes: Single-Channel Single-Reading, Single-Channel Continuous-Reading, Multichannel Single-Reading, Multichannel Multireading, and Multichannel Continuous-Reading. These modes allow the host to choose between one-shot, continuous, host-driven, semi-autonomous, or autonomous multichannel acquisition. 17. When should normal settling or single-cycle settling be used? Normal settling is better suited for single-channel reading where maximum data rate is preferred, while single-cycle settling is recommended for multichannel systems to avoid settling-time error after switching channels. In normal settling, the ADC output stabilizes after four samples, while in single-cycle settling the output is stable in one cycle, but the effective data rate is four times slower. 18. What factors affect noise performance? Noise performance depends mainly on the selected data rate, PGA gain, digital filter order, and settling mode. Lowering the data rate reduces the equivalent noise bandwidth and therefore reduces noise. Increasing PGA gain can reduce input-referred noise because the PGA contributes less noise than the ADC. Higher-order digital filtering can also reduce noise by narrowing the effective bandwidth. 19. What calibration options are available? The NAFEB43388 includes user-accessible calibration coefficient registers for analog input gain, analog input offset, extra calibration coefficients, and DAC output calibration. Factory-calibrated options load coefficients from nonvolatile memory during power-up or reset, and users can also perform application-specific calibration using the available registers and GUI procedures. 20. What accuracy can be achieved with calibration? For voltage input with user calibration, the datasheet specifies typical room-temperature TUE of 0.002 %FS and maximum ±0.005 %FS under the stated conditions. Across temperature, typical TUE is listed as 0.05 %FS with maximum ±0.1 %FS. For current input using the internal sense resistor and user calibration, the listed typical room-temperature TUE is 0.00125 %FS with maximum ±0.005 %FS. 21. How is an external 4-wire PT100 connected and measured? For the external 4-wire PT100 demo, one red RTD wire is connected to AI2P and one white wire to AI3P to provide the current forcing path, while the other red and white wires are connected to AI3N and AICM for differential voltage sensing. The default GUI configuration uses AI3P-AI3N as the measured input, -2 mA DAC current excitation on AI2P, normal settling, PGA1 = 16x, PGA2 = 4x, 200 SPS, and SINC4_4 filtering. 22. What diagnostics are integrated in the NAFEB43388? The NAFEB43388 includes advanced diagnostics for fault and anomaly detection, including power-supply monitoring, under-/over-range detection on the signal path, redundant voltage-reference monitoring, temperature monitoring, CRC error detection, global alarm functionality, clock-deviation detection, and input/output overcurrent-related status flags. 23. How can multiple NAFEB43388 devices be synchronized? The device supports synchronization through the SYNCADC pin. A host-generated SYNC pulse can be connected to multiple NAFE devices so that conversions start simultaneously on the rising edge of the SYNCADC pulse. The device can also synchronize to the host using SYNCADC, synchronize the host to the NAFE data rate using DRDY, or share an external 18.432 MHz clock with the host for coherent measurements. SPI
記事全体を表示
MCUXpresso for Visual Studio Code - MCX MCUXpresso for Visual Studio Code (VS Code) provides an optimized embedded developer experience for code editing and development. The extension enables NXP developers to use one of the most popular embedded editor tools and provides an easy and fast way to create, build and debug applications based on MCUXpresso SDK or Zephyr projects.   Install it following the next steps: Download Visual Studio Code from Microsoft Store or visual studio code web page Download Visual Studio Code - Mac, Linux, Windows Access to vscode for MCUX wiki and download MCUXpresso Installer  Dependency Installation · nxp-mcuxpresso/vscode-for-mcux Wiki · GitHub Run MCUXpresso Installer: MCUXpresso SDK Developer Arm GNU Toolchain Standalone Toolchain Add ons Linkserver PEmicro neidys_vargas_0-1782232556890.png Installing the FRDM-MCX SDK  Each MCU has its own SDK that includes driver, examples, middleware, docs and other components. To get and build the demo, let’s install the SDK into VS Code. Install the NXP’s GitHub SDK: Once MCUXpresso for Visual Studio Code is installed, open VS Code. Go to MCUXpresso for VS Code extension that is on the tools column at the left. neidys_vargas_1-1782232711167.png Look for INSTALLED REPOSITORIES option and press ‘+’ (Detail steps are described in wiki page. Working with MCUXpresso SDK · nxp-mcuxpresso/vscode-for-mcux Wiki · GitHub).                                               neidys_vargas_2-1782232751534.png Search for the remote option of the Import Repository window. neidys_vargas_3-1782232782659.png Select the MCUXpresso SDK in the repository option to download the GitHub SDK, then in the Revision tab you can select either the “main” revision or to select a specific version), optionally you can change the repository name and location. neidys_vargas_4-1782232886818.png Finally click on the “Import” button. FRDM-Training Hands-On Training
記事全体を表示
MCX C Knowledge Hub The MCX C series MCUs, powered by Arm® Cortex®-M23 up to 72 MHz or Arm® Cortex®-M0+ up to 48 MHz, are designed for cost effectiveness and efficiency, making them ideal for low-end Industrial and IoT applications. Featuring precision analog peripherals as well as USB and segment LCD options, these MCUs cater to diverse needs. The MCX C Series extends the classical IPs within NXP MCUs, providing flexible and scalable memory and packages. MCX C MCUs offer features like USB and segment LCD support, making them ideal for a wide range of general-purpose applications. With a focus on versatility, these MCUs provide the performance and scalability needed for today’s evolving technology demands. Documents: MCX C Series  MCX C Fact Sheet MCX C Series Products MCX C04x:  The MCX C04x microcontrollers, featuring an Arm® Cortex®-M0+ core, offer 32 KB Flash, 2 KB SRAM, and 8 KB boot ROM. Designed as entry-level MCUs, they prioritize simplicity and ease of use for a variety of applications. Key peripherals include a 12-bit ADC, comparator and multiple-channel timer/PWM modules. The enhanced low-power architecture ensures efficiency, with static power consumption as low as 2.2 μA and a 7.5 μs wake-up time for full retention. In deep sleep, static mode power consumption drops to just 77 nA. This series supports scalable memory options and flexible packaging, accommodating diverse application needs. Documents: MCX C041 Sub-Family Reference Manual Data Sheet - MCX C04X Errata: MCXC041 Mask Set MCX C14x/C24x/C44x: The MCX C14x/24x/44x microcontrollers, featuring an Arm® Cortex®-M0+ core, offer a range of memory configurations, from 32KB to 256KB Flash and up to 32KB SRAM, with 16KB Boot ROM. These entry-level MCUs are optimized for cost-sensitive and battery-powered applications requiring low-power USB connectivity and segment LCD support. The FlexIO technology enables customization for various serial peripheral emulation needs. They feature optimized low-power modes, achieving efficiency down to 54uA/MHz in very low-power run mode and 1.96 uA in deep sleep mode with retained RAM and RTC. Documents: Data Sheet - MCX C24x/C14x Data Sheet - MCX C44x Errata:  MCXC - x41 x42  Errata: MCXC - x43 x44 MCX C44x Sub-Family Reference Manual MCX C24x Sub-Family Reference Manual MCX C15/C16: The MCX C15 and MCX C16 microcontrollers (MCUs) are low‑cost, entry‑level devices featuring an Arm® Cortex®‑M23 core running at up to 72 MHz, with memory configurations offering up to 64 KB of flash memory and 16 KB of static random‑access memory (SRAM). These devices bring precision analog and control peripherals into the low‑cost, entry‑level MCU class, making advanced features—such as a 16‑bit analog‑to‑digital converter (ADC), comparator with digital‑to‑analog converter (DAC) and flexible pulse‑width modulation (FlexPWM) for motor control—accessible to cost‑sensitive IoT applications. Designed as an upgrade path from legacy 8‑bit and 16‑bit MCUs, as well as devices based on Arm Cortex‑M0+ cores, this entry‑level 32‑bit MCU series delivers higher performance and greater scalability without increasing costs. Documents: Data Sheet -MCX C151/C161/C162  Fact Sheet - MCX C1 Family Boards: FRDM MCX C444: FRDM-MCXC444 is a compact and scalable development board for rapid prototyping of MCX C444 MCU. It offers industry-standard headers for easy access to the MCU's I/Os, integrated open-standard serial interfaces and onboard MCU-Link debugger.  FRDM-MCXC444 QSG Getting Started with FRDM-MCXC444 FRDM-MCXC444 Board User Manual FRDM MCX C242: FRDM-MCXC242 is a compact and scalable development board for rapid prototyping of MCX C242 MCU. It offers industry standard headers for easy access to the MCU’s I/Os, integrated open-standard serial interfaces and on-board MCU-Link debugger. FRDM-MCXC242 QSG Getting Started with MCXC242  FRDM-MCXC242 Board User Manual  FRDM-MCX C041:  is a compact and scalable development board for rapid prototyping of MCX C041 MCU. It offers industry-standard headers for easy access to the MCU’s I/Os, integrated open-standard serial interfaces and onboard MCU-Link debugger. FRDM-MCXC041 QSG Getting Started with FRDM-MCXC041 FRDM-MCXC041 Board User Manual MCX C to FRDM Board Mapping Supported MCU(s) Recommended Board Best fit for  Key Differentiators MCXC041 (16QFN, 24QFN) FRDM-MCXC041 Ultra-Low-cost entry-level designs  32KB flash - 2KB SRAM- 48MHz Cortex M0+ - LPUART - SPI - I2C - ADC MCX C141/ C142/ C241/ C242 /C441 /C442 / C444 FRDM-MCXC444 General-purpose USB and Segment LCD application Industrial / Consumer Up to 256KB Flash - 32KB SRAM - 48MHz Cortex-M0+ - USB FS 2.0 - SLCD - FlexIO - DMA 0 CAN-FD - Multiple UART/SPI/I2C MCX C151/ C152/ C161/ C162 FRDM-MCXC162 Motor Control Precision analog Power tools    medical devices Up to 64KB flash - 16KB SRAM - 72MHz Cortex-M23 - 16-bit ADC 2.4MSPS - FlexPWM - 4xUART - 45 GPIO   Application Notes: Software, Hardware and Peripherals: AN14321 Using Segment Liquid Crystal Displays (SLCD) Controller on MCX C444 MCU: This document describes the usage of the on-chip SLCD controller by enabling an SLCD device called S401M16KR. The S401M16KR is a four-digit 0.17-inch seven-segment LCD panel. AN14590 Running RT-Thread on MCUXpresso IDE: This document is intended for the users who are familiar with RT-Thread and want to port it to MCUXpressoIDE. It provides steps to streamline the porting process. The porting steps are applicable to other NXP chips also. This document uses FRDM-MCXC444 as an example. AN14319 FlexIO Emulating UART with IRDA: This application note introduces how to use the universal peripheral module FlexIO for emulating the UART bus with IRDA. The FlexIO peripheral, initially introduced on the MCXC242 and MCXC444 family, is a highly configurable module capable of emulating a wide range of different communication protocols. These communication protocols include UART, I2C, SPI, I2S, and so on. AN14322 USB to multi VCOM on MCX C444 Series MCU: This document describes how to implement a USB to functions of multiple VCOMs on MCX C444 series FRDM boards. AN14349 Emulating I2C Bus Controller by using FlexIO on MCX C: This application note lists the steps to use the FlexIO module for emulating the I2C bus controller Power Management:  AN14811 Estimated Power-on Hours for the MCX C04x, MCX C14x, MCX C24x and MCX C44x: This document describes the estimated product power-on hours (PoH) for the MCX C04x, MCX C14x, MCX C24x, and MCX C44x industrial MCUs. It uses the criteria from the qualification process. AN14332 MCX C444 Power Mode Switch Application: This application note focuses on the power management controller (PMC), system mode controller (SMC), Multipurpose Clock Generator Lite (MCG-Lite), and Low-Leakage Wakeup Unit (LLWU). Training: Design without Bounds FRDM Training and Resources FRDM Training Hub Useful Links: FRDM Boards Enclosures (3D Print) MCX C:  How to Enter the ROM Bootloader to Update the firmware MCUXPresso for Visual Studio Code - MCX MCUXpresso Config Tool for MCUXpresso IDE MCUXpresso Config Tool for 3rd party IDE Download Firmware to MCX microcontrollers over USB, I2Cm UART, SPI, CAN Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here    MCXC
記事全体を表示
Himiway: Mid-Drive vs Hub Motor: Pros and Cons If you're shopping for an electric bike, one of the biggest decisions is choosing between a mid-drive motor and a hub motor. Neither design is automatically better. Mid-drive motors are especially good at using the bike's gears to handle steep hills and technical terrain, while hub motors are simpler, usually more affordable, and require less drivetrain maintenance. For many everyday riders, a good hub motor provides more than enough performance. Riders dealing with serious hills, mountain trails, or demanding cargo use may benefit more from a mid-drive system. Here's a practical comparison. Mid-Drive vs Hub Motor at a Glance Feature Mid-Drive Motor Hub Motor Motor Location Around the crank/pedals Front or rear wheel hub Best For Hills, trails, technical riding Commuting, leisure, mixed everyday riding Hill Performance Excellent Good to excellent depending on torque Weight Distribution Very balanced More weight at one wheel Drivetrain Wear Higher Lower Maintenance More involved Generally simpler Flat Tire Repair Usually easier Motor-wheel removal can be harder Pedaling Feel Often very natural Depends heavily on sensor tuning Price Usually higher Usually more affordable What Is a Mid-Drive Motor? A mid-drive motor is positioned near the bottom bracket, where the pedals and crankset meet the frame. Instead of directly turning a wheel, the motor sends power through the bicycle's drivetrain. That means the motor can take advantage of the bike's gears in much the same way the rider does. Shift into a lower gear for a steep climb, for example, and the motor can operate at a more favorable speed while producing strong climbing assistance. This is the biggest reason mid-drive systems are popular on performance-oriented electric mountain bikes and other bikes designed for demanding terrain. Pros of Mid-Drive Motors 1. Excellent Hill-Climbing Performance This is probably the strongest argument for a mid-drive. Because motor power passes through the bicycle's gears, you can select a lower gear when climbing. This helps the motor operate efficiently instead of forcing it to pull the bike uphill at very low motor RPM. For riders living in extremely hilly areas, this can make a noticeable difference. However, don't assume that every mid-drive automatically climbs better than every hub motor. Motor torque, controller tuning, rider weight, gearing, tire size, and total bike weight all matter. A strong 750W geared hub motor with high torque can still be an excellent hill climber for normal roads and moderate trails. 2. Better Weight Distribution A mid-drive motor places its weight low and near the center of the bicycle. That generally gives the bike more neutral handling because there isn't a large motor concentrated inside the front or rear wheel. The advantage becomes especially noticeable during technical mountain biking, quick direction changes, and riding over uneven terrain. 3. Efficient Use of Motor Power Because the motor can use the bicycle's gears, a mid-drive system can keep the motor operating in a more efficient RPM range. This can improve efficiency on routes involving frequent elevation changes. It doesn't necessarily mean a mid-drive will always have longer range, though. Battery capacity, speed, tire pressure, rider weight, temperature, elevation, wind, and assist level can easily have a larger effect on real-world range. 4. Natural Pedaling Experience Many higher-end mid-drive systems are paired with torque sensors. A torque sensor measures how hard you're pushing on the pedals and adjusts motor assistance accordingly. Push harder and you receive more assistance. Pedal gently and the motor responds more gently. The result can feel surprisingly similar to riding a normal bicycle—except that you suddenly have much stronger legs. Cons of Mid-Drive Motors 1. More Drivetrain Wear The same feature that gives a mid-drive its climbing advantage also creates one of its biggest disadvantages. Both the rider and motor are sending power through components such as the: Chain Chainring Cassette Derailleur system High motor torque combined with poor shifting habits can accelerate drivetrain wear. If you regularly shift gears while the motor is delivering maximum power, chains and cassette teeth may wear substantially faster. 2. More Expensive Mid-drive systems generally cost more. The motor must be integrated around the crank area, and the frame often needs to be designed specifically around that drive unit. For riders who mainly travel on pavement or relatively gentle terrain, paying the premium may not provide enough practical benefit. 3. Shifting Technique Matters Mid-drive riders need to think more carefully about gears. Starting a steep hill in a very high gear and then shifting under heavy motor load isn't ideal. Good riding technique involves selecting an appropriate gear before the drivetrain becomes heavily loaded. For experienced cyclists, this quickly becomes natural. For beginners, there can be a learning curve. 4. A Broken Chain Can Become a Bigger Problem Because a mid-drive transfers motor power through the chain, drivetrain failure can potentially leave you unable to use the motor to drive the rear wheel. A throttle-equipped hub-drive bike can have an advantage here because its motor operates independently from the bicycle chain. What Is a Hub Motor? A hub motor is built directly into the center of the front or rear wheel. Rear hub motors are particularly common on modern electric bikes. Instead of sending power through the chain and cassette, the motor directly rotates the wheel. This makes the system mechanically straightforward and separates motor power from the traditional bicycle drivetrain. Several Himiway models use powerful hub-drive configurations. Bikes such as the Himiway D5 2.0 Series demonstrate why hub motors remain popular on practical fat-tire e-bikes: they can combine substantial torque with relatively straightforward operation. Pros of Hub Motors 1. Simple and Low-Maintenance Design One of the biggest advantages is simplicity. The motor doesn't normally send its power through the bicycle chain or cassette. Your drivetrain therefore only has to handle your pedaling force rather than your pedaling force plus motor output. For riders who want an e-bike for commuting, weekend rides, errands, or recreation, this simplicity is valuable. 2. Strong Everyday Performance It's outdated to think that hub motors are only suitable for flat roads. Modern geared hub motors can produce substantial torque. For example, the Himiway D5 2.0 uses a 750W geared hub motor rated at 90 Nm of torque. That's the kind of specification designed to provide strong acceleration and useful climbing assistance rather than simply cruising along perfectly flat bike paths. The D5 2.0 20" combines the same general idea with 20-inch fat tires and full suspension, giving riders a compact platform designed around comfort and maneuverability. For normal hills, neighborhood streets, gravel roads, and recreational trails, a well-designed hub motor can be more than capable. 3. Lower Purchase Cost Hub motors are generally less complicated and less expensive for manufacturers to integrate into an e-bike. That can allow more of the bike's budget to go toward other features such as: Larger batteries Hydraulic brakes Better suspension Integrated lighting Fat tires Higher payload capacity This is one reason hub-drive bikes can offer very attractive specifications for the money. 4. Less Stress on the Chain and Cassette Since motor power goes directly to the wheel, the chain doesn't have to transmit the motor's full torque. That can mean longer drivetrain component life compared with a powerful mid-drive bike, assuming both bikes are maintained properly. 5. Throttle Operation Can Be Useful On compatible hub-drive e-bikes equipped with a throttle, motor operation doesn't necessarily depend on the bicycle drivetrain. This can be convenient when starting from a stop, briefly moving through an intersection, or getting the bike moving when carrying a load. It also provides an important mechanical advantage: a broken chain doesn't necessarily prevent the motor from moving the bicycle. Cons of Hub Motors 1. Less Efficient on Extreme Climbs A conventional hub motor can't take advantage of the bicycle's cassette in the same way a mid-drive can. On a long and very steep climb, the motor may be forced to operate at low speed under heavy load. That can increase heat generation and energy consumption. For occasional hills this might not matter much. For riders climbing steep mountain roads every day, it becomes much more important. 2. Heavier Rear or Front Wheel The motor adds substantial mass to whichever wheel contains it. Most powerful e-bikes use rear hub motors, so the rear of the bicycle can feel heavier when lifting or servicing it. You may notice this more when carrying the bike upstairs than when actually riding it. 3. Flat Tire Repairs Can Be More Complicated A hub-motor wheel isn't quite as easy to remove as an ordinary bicycle wheel. You may need to disconnect the motor cable and deal with a significantly heavier wheel. For that reason, maintaining correct tire pressure and using puncture-resistant tires can be particularly worthwhile on hub-drive e-bikes. What About Himiway eBikes? Himiway ebikes is a useful example because many of its bikes emphasize powerful hub-drive systems rather than automatically using a mid-drive simply because it sounds more premium. Models such as the Himiway D5, D5 Pro, D5 2.0, D5 2.0 ST, D5 2.0 Camo, D5 2.0 20", C3, A7, A7 Pro, D7, and D7 Pro target different types of riding, so the important point is to look at the complete bike rather than judging it solely by motor location. For example, a rider considering a D5 2.0 may care about strong torque, fat-tire traction, suspension comfort, range, and everyday reliability more than achieving the lightest possible drivetrain. The D5 2.0 20" is particularly interesting for riders who value easier maneuverability and comfort. Its smaller 20-inch wheels, 4-inch tires, full suspension, and low center of gravity create a very different riding experience from a traditional large-wheel mountain e-bike. The A7 and A7 Pro, meanwhile, are more relevant to riders prioritizing urban transportation and everyday usability. And the C1 Kids belongs in a completely different category. For younger riders, controllability, appropriate sizing, speed management, braking, and adult supervision are far more important than chasing maximum motor torque. This highlights an important lesson: Don't choose an e-bike based on the motor alone. What Riders Actually Notice Specifications are useful, but everyday riding tends to make the differences much simpler. A well-tuned hub-drive bike often feels effortless during normal commuting. You pedal, assistance arrives, and you keep moving without constantly thinking about gears. A good mid-drive tends to reward riders who actively use their gears. When approaching a hill, shifting down allows the motor and rider to work together efficiently. On technical terrain, the centered weight can also make the bicycle feel more balanced. The difference becomes much less dramatic when you're cruising at moderate speeds on a flat bike path. That's why paying substantially more for a mid-drive isn't automatically worthwhile for every rider. Which Motor Is Better for Hills? Mid-drive wins for serious climbing. If your normal rides include long, steep mountain climbs, a mid-drive's ability to use the bike's gearing is a major advantage. But there's an important distinction between "hills" and "extreme hills." Most people aren't climbing mountain passes every morning. A high-torque geared hub motor can handle typical neighborhood hills, rolling countryside, gravel roads, and moderate trail climbs very well. That's why bikes such as the Himiway D5 2.0 can make sense for riders who want climbing ability without moving to a more expensive mid-drive platform. Which Is Better for Commuting? For typical commuting, I'd give the advantage to the hub motor. It's simple, relatively inexpensive, puts less motor-related stress on the bicycle drivetrain, and provides plenty of assistance for normal urban riding. If your commute involves extremely steep terrain, however, a mid-drive becomes more attractive. Which Is Better for Mountain Biking? For serious technical mountain biking, I'd choose a mid-drive. The centered motor position improves weight distribution, while access to the bike's gearing helps during steep and technical climbs. For gravel roads, forest paths, dirt roads, camping trips, and relatively moderate recreational trails, a powerful fat-tire hub-drive bike can still be an excellent choice. Which Is Better for Beginners? For many beginners, a hub-drive e-bike makes more sense. There's less need to think about keeping the motor in the correct gear, drivetrain maintenance is straightforward, and prices are often more approachable. However, motor type isn't the only factor affecting ease of use. Frame geometry, wheel size, bike weight, standover height, throttle behavior, torque or cadence sensing, brakes, and suspension can make an even bigger difference to rider confidence. Mid-Drive vs Hub Motor: Final Verdict There isn't a universal winner. Choose a mid-drive motor if you: Regularly climb very steep hills Ride technical mountain trails Want balanced weight distribution Prefer a natural, performance-oriented riding feel Don't mind additional drivetrain maintenance Are comfortable paying more Choose a hub motor if you: Commute or ride recreationally Mostly encounter flat to moderately hilly terrain Want lower maintenance Want better value for your budget Prefer a mechanically simpler system Want motor operation independent of the bicycle drivetrain For many everyday riders, a quality geared hub motor offers the better balance of power, simplicity, reliability, and price. A properly designed 750W, high-torque hub-drive e-bike can handle far more than just flat city streets. Mid-drives become particularly valuable when terrain gets genuinely demanding. So instead of asking, "Which motor is better?", ask: "Where will I actually ride this bike?" If the answer is steep mountain trails and demanding climbs, look closely at mid-drives. If it's commuting, weekend rides, gravel roads, errands, and moderate hills, a good hub-drive e-bike—such as several models in Himiway's lineup—may give you everything you need without paying for complexity you won't use.
記事全体を表示