Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
ECSPI1 does not generate expected SPI clock on custom board Hi Team, We are working with an i.MX8MP custom board based on the i.MX8MP EVK configuration. On the i.MX8MP EVK, we have an SPI device connected through ECSPI2. With the existing EVK Device Tree configuration, SPI communication is working correctly, and we can observe the expected SCLK waveform on the oscilloscope. On our custom board, the SPI interface is connected to ECSPI1 instead of ECSPI2. We therefore modified the Device Tree configuration to use ECSPI1. However, with ECSPI1, we are not able to observe the expected/correct SPI clock pulses on the SCLK pin. We have tried several different Device Tree configurations, but the issue remains. 1. ECSPI1 configured similar to the existing ECSPI2 configuration We changed the controller from ECSPI2 to ECSPI1 and created the corresponding ECSPI1 pinctrl group, including SCLK, MOSI, MISO and CS. 2. Separate CS pinctrl group We also tried defining a separate pinctrl_ecspi1_cs and using it along with the ECSPI1 pinctrl group. 3. Explicit ECSPI1 pinmux configuration We also tried explicitly defining the ECSPI1 pins. However, with ECSPI1, we are still unable to observe the expected SPI clock pulses. We would like to know when configuring ECSPI1 on i.MX8MP, are there any additional Device Tree or pinctrl changes required apart from enabling &ecspi1 and configuring the ECSPI1 SCLK/MOSI/MISO/CS pins? In particular, is there any ECSPI1-specific pinctrl, clock, IOMUX, or other Device Tree configuration that needs to be added for ECSPI1 to operate correctly? The same SPI setup works on ECSPI2, so we would like to understand whether there is any additional configuration required when moving the interface from ECSPI2 to ECSPI1. Thanks in advance for your guidance. Re: ECSPI1 does not generate expected SPI clock on custom board Hi ,  Please find the dts file attached Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  Please share your dts file about ECSPI1.  B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  I have checked your dts file, I found the following errors: 1. ECSPI pins have been reused, causing a pin usage conflict. Please remove this part or use other pins for reuse.     pinctrl_ecspi1: ecspi1grp {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK       0x48             MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI       0x48             MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO       0x48         >;     };     pinctrl_uart3: uart3grp {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SCLK__UART3_DCE_RX      0x140             MX8MP_IOMUXC_ECSPI1_MOSI__UART3_DCE_TX      0x140             MX8MP_IOMUXC_ECSPI1_SS0__UART3_DCE_RTS      0x140             MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS     0x140         >;     }; 2. The ECSPI1 chip select (CS) configuration is contradictory. Please change it to the following code.     pinctrl_ecspi1_cs: ecspi1cs {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09     0x40000         >;     }; B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi @pengyong_zhang, Please find the below observations 1. Logic analayser result when used the suggested changes SWETHA1_1-1786532293061.pngSWETHA1_1-1786532293061.pngSWETHA1_1-1786532293061.png 2. Another observation when used the below patch on top of the previously attached dts SWETHA1_0-1786532274946.pngSWETHA1_0-1786532274946.pngSWETHA1_0-1786532274946.png the above graph observed with this changes pinctrl_ecspi1: ecspi1grp { fsl,pins = < MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x80 MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x80 MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x80 >; }; With the suggested changes, we could see the clock is not as expected.  Re: ECSPI1 does not generate expected SPI clock on custom board Adding a few more details for the last response Observation 1: The result obtained after applying the suggested DTS changes. However, the SPI clock waveform is still not as expected, and the overall SPI signal behavior does not match the expected result. Observation 2: When MISO is left floating, CS shows two unwanted spikes, which is not the desired behavior. CS is initially driven low. Even when CS is configured to be driven high through the DTS, it is initially driven high as expected; however, after a transaction, CS appears to go low again. Could you please share your insights on this and guide to proceed further Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  1. Please share your latest dts file. 2. How did you test the SPI device? You can use the `spidev_test` tool to run SPI tests. Please share the output of your `ls /dev/` command. B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi  Please find the attached dts files correspoding to shared observations 1 and 2.  The output of ls /dev shows /dev/spidev1.0 As for testing the spidevice , I have used the attached c file , which is verified working in  evk board where the spi is connected to ecspi2 and used the existing pinctrl groups. Now the validation results are taken and shared under the custom board based on evk where spi is connected in ecspi1.
記事全体を表示
Project [Rename] , 造成 整個 Project 丟失 餓死抬頭  S32DS 3.5  面對 相似 新Project  對 舊Project 做 [Rename] 動作  新Project 沒有生出來 就算了  將我 原有的 舊Project 也刪除了 !!  Explorer 已找不到原Project Folder  chkdsk 表示 無錯誤 !   請問,我該如何 救回 原有 舊Project !??  NXPrename.png 另,為什麼 [數字開頭的 Project Name] 不合法? ??   Spoiler (Highlight to read) S32DS-ARM S32DS-S32PLATFORM #rename    #rename  Re: Project [Rename] , 造成 整個 Project 丟失 你好@CY9 , 我不认为这是由于子文件夹数量造成的。从日志元数据中可以看到,在“2026-08-10”执行的重命名操作失败了: !ENTRY com.nxp.s32ds.ext.ide.core 4 0 2026-08-10 08:50:24.109 !MESSAGE Unexpected error during rename !STACK 1 我推断您要重命名的项目是“202503021_App_118”,您尝试将其重命名为“ADB22pxAPP_VR”,对吗?我看到以下错误: org.eclipse.core.internal.resources.ResourceException(/ADB22pxAPP_VR)[374]: java.lang.Exception: Resource '/ADB22pxAPP_VR' already exists. 但是,我不确定这是否是根本原因,因为我尝试将一个项目重命名为一个已存在的项目,但却失败了: Julin_AragnM_1-1786480276599.png Julin_AragnM_0-1786480052303.png 所以,仅凭这些信息,我真的无法得出结论。我唯一能建议的操作是使用 Recuva 扫描整个磁盘,查找 202503021_App_118 和 ADB22pxAPP_VR。如果项目无法恢复,我不确定是否还有其他可行的解决方案。 此致, 朱利安 Re: Project [Rename] , 造成 整個 Project 丟失 是的, 我确信 ` ADB22pxAPP_VR` 不存在。 它确实存在,而且你的程序也找到了它。 是否应该停止重命名功能!? 实际上,它删除了整个目录。 我完全不知道发生了什么事。 Recuva找不到任何文件夹。 我正在尽快抢救一些文件。 谢谢你的关心。
記事全体を表示
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
記事全体を表示
HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 Hi, I am working on HSE-B AB Swap on an S32K312 MINI-EVB with HSE firmware version 0.2.55.0 (ab_swap variant). The board is in OEM_PROD lifecycle and Bank A is currently active. Both banks hold the same HSE firmware version. I have a working reference where a bare-metal main function polls HSE INIT_OK and then submits the activate passive block service. That call returns success and the swap applies on the next reset. Bank B contains a valid IVT with pointers compiled for the lower address space per section 11.3 of RM00286. The same MU submission code, moved into a bootloader after MCAL clock initialization, returns HSE response 55A5A26A (invalid address). HSE INIT_OK stays set. Other HSE services (AES, RSA, SHA) work correctly in this state. The only difference between the working and failing runs is that the bootloader path writes the MC_CGM MUX 0 divider registers during clock initialization, keeping the source on FIRC but changing the AIPS_SLOW to HSE_CLK ratio from 1:1 (SBAF default) to 1:4. My main question: what does the invalid address response refer to for the activate passive block service, since the service takes no data structure? Is there a documented sequence for reconfiguring MC_CGM dividers after HSE has reached INIT_OK, that keeps this specific service usable? I can share the failing binary, register dumps, and clock config on request. Thanks Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 Hi David, Thank you for the guidance about the DCF client. To make sure I set this up correctly on the first attempt, could you please clarify a few things: 1. Point 5 in your list says the MC_CGM MUX 0 source must be PLL_PHI0. Is this a hard requirement — does the activate passive block service require the system clock to be on PLL, or can it also work with the system running on FIRC (48 MHz)? 2. Could you share the earlier points 1 to 4 from the same list? We only have points 5 and 6 in the image and suspect we are missing prerequisites. 3. Point 6 gives the DCF value for a 120 MHz HSE clock scenario. For a 48 MHz FIRC configuration with AIPS slow clock at 12 MHz (1:4 ratio), what value should be programmed into the UTEST_MISC DCF record's clock mode and gasket control bit field? 4. What is the exact UTEST address on S32K312 for this record, and is there a sample or a Design Studio / Cyclone algorithm file we can use to program it safely? Since UTEST is one-time programmable, we want to be certain before writing. 5. Are there any other DCF records required for AB Swap beyond UTEST_MISC — such as an OTA enable marker in UTEST, or OTA indicators inside the active and passive blocks? If yes, please share those as well. Board context: HSE firmware 0.2.55.0 ab_swap variant, OEM_PROD lifecycle, INIT_OK and OEM SU rights bits set. Thanks a lot, Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 I guess you don't have setup DCF client what is necessary for use as you described. davidtosenovjan_0-1786371576770.png Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 1) I didn't want to take a screenshot of point 5, but point 6. 2) It is taken from RM: davidtosenovjan_0-1786445766359.png 3) The key point is ratio 1:4. Also it is described in RM embedded attachment (S32K3xx_DCF_clients.xlsx) davidtosenovjan_1-1786445766362.png 4) DCF record address to be programmed you will have to find out yourself (to find first location with 0xFFFF_FFFF). Specifically is should be around address 0x1B000780, but double check it before programming. See following document to understand DCF records: https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC57xx-DCF-records/ta-p/1114884 Also DCF calculator exists: https://community.nxp.com/t5/S32K-Knowledge-Base/S32K344-DCF-Configurator/ta-p/1986243 I have been using TRACE32 script as follows: ; Program UTEST do ~~\demo\arm\flash\s32k3.cmm prepareonly flash.Program 3. /OTP ;put lines generated by S32K344 DCF configurator data.set 0x1B000780 %QUAD 0x0010000460000101 ;dcf_client_utest_misc flash.Program off Mentioned DCF calculator also allows you to create S-records that may be programmed by any programmer/debugger. 5) OTA flag is programmed automatically when AB_SWAP HSE FW is being installed, user don’t need to care of it. I am not aware of other DCF configurations needed. Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 Hello, Follow-up: I have prepared the DCF record for dcf_client_utest_misc per your instruction (value 0x0010000460000101, target address 0x1B000768 — first free QUAD on my board, verified). However, S32DS + PEmicro Multilink debug configuration silently skips the UTEST write — bytes at 0x1B000768 remain FFFFFFFFFFFFFFFF after the flash session. What is the correct tool/procedure to program a single DCF record into UTEST OTP on S32K312 using PEmicro Multilink (or any tool that ships with S32DS 3.6.4)? Do I need a specific flash algorithm file, a different debug configuration, or the standalone S32 Flash Tool?
記事全体を表示
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.
記事全体を表示
MIMXRT1160 XIP fails randomly I have multiple boards running XIP from octal flash at 166 MHz. One of them fails occasionally  with "undefined instruction" error.  I've suspected signal integrity issues but I do not have test points on the PCB, so the only way to check that has been reducing speed from 166 MHz to 133 MHz, which appears to "fix" the problem with that particular board.  It's probably telling that the error appears most often when chainloading the application from mcuboot. It is more rare during application runtime. I can't find a reliable way to trigger it too - need to power-cycle the board several times until the fault appears.  Is there a way I can diagnose this XIP failure with more precision? Re: MIMXRT1160 XIP fails randomly Hi @tbonkers , The behavior you describe is most likely caused by insufficient read-sampling margin (setup/hold) at 166 MHz, due to tight PCB-routing/signal-integrity headroom on the Flash data lines. This also explains both symptoms: dropping to 133 MHz widens the sampling window so the issue "disappears"; and the mcuboot chainload is the first, dense, cache-cold instruction fetch right after a cold reset, where margin is tightest — hence it fails most often there, while runtime fetches mostly hit cache and rarely trigger it. We suggest the following checks, all software-side and requiring no PCB test points: Start with dummy cycles. Verify that the dummy-cycle count in the read LUT strictly matches your Octal Flash datasheet spec at 166 MHz. If an auto-generated FCB (e.g., from the provisioning tool) uses a lower value, set it to the datasheet-specified value, and you may add 1–2 extra dummy cycles to widen the data-valid window and increase sampling margin. Insufficient dummy cycles place the first data beat in the turnaround/not-yet-settled region — a classic source of intermittent errors. Verify the read sample-clock source . 166 MHz is only in-spec when readSampleClksrc=3 (kFlexSPIReadSampleClk_ExternalInputFromDqsPad: read strobe/DQS provided by the Flash device). If it is currently 0 or 1, 166 MHz is out of spec, which is fully consistent with "133 MHz fixes it." Please confirm a real DQS trace exists on the PCB and use this mode. If intermittent faults persist after these adjustments, you can run at 133 MHz as a safe baseline while isolating the 166 MHz margin bottleneck via steps 1–3 above. And this post may also help: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Octal-flash-IS25WX256-dummy-cycles/m-p/2178828   Best wishes, Gavin Re: MIMXRT1160 XIP fails randomly Error log or schematics sharing could be helpful, how about the failing rate till now? Re: MIMXRT1160 XIP fails randomly Hi @Gavin_Jia , I've tested the read command with different dummy cycles count, and the failure is still there. I've set the number of dummy cycles in the flash volatile register to 20 so that it can support 166 Mhz. According to the flash datasheet it should support up to 200 MHz with 20 dummy cycles. readSampleClksrc=3 is set by the bootROM, confirmed with debugger connected. The DQS trace does exist.  Sometimes the fault happens while application is running, after the first major flash read. Re: MIMXRT1160 XIP fails randomly Hi @tbonkers , Thanks for the detailed testing. Based on your findings, this is most consistent with the 166 MHz Octal DDR XIP read path operating at the edge of its sampling / signal-integrity margin. readSampleClksrc=3 and the DQS trace are necessary but not sufficient conditions: in DDR DQS mode, the RT1160 side still requires the DQS-to-SIO relative skew to stay within ~±1 ns, and 166 MHz is the interface's upper limit, so margin is minimal.  I’ve looked into more resources, and the following solutions may help you resolve the current issue without modifying the PCB: Apply DLL errata ERR011377. The RT1160 errata states that after the DLL lock-status bit is set, an immediate read/write to the external flash may still return wrong data due to a timing issue; the workaround is to wait at least 512 FlexSPI root-clock cycles after the lock bit is set before accessing flash. Please ensure this delay is applied in every path in the bootloader and application that reconfigures FlexSPI/DLL/clock — this fits well with "most frequent at chainload, intermittent at runtime." Run a quantifiable RAM-resident stress test (more effective than repeated power-cycling). Place the test code and fault handler in ITCM/OCRAM, repeatedly read large flash blocks from the AHB memory map with CRC comparison, sweeping 166/133/120 MHz. If the error rate drops sharply as frequency decreases, it confirms a timing/SI-margin issue. For the mcuboot case:  if the bootloader ever erased/programmed the external NOR, you must invalidate I/D-cache before jumping to the application; also confirm the application does not re-initialize FlexSPI with different clock/DLL/LUT/pad settings. If in the end only 166 MHz fails while 133 MHz is stable, we recommend 133 MHz as the safe operating frequency for the current board; if 166 MHz is mandatory for production, the PCB DQS/SCLK/SIO length-matching, impedance, crosstalk, and pad drive strength should be reviewed, with test points added for these signals in the next revision. 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
記事全体を表示
MCX C15/C16 Product Training: Essential MCUs built for cost effective, low-end applications Picture1.pngPicture1.png Welcome to MCX C15 and MCX C16 Product Training! This page provides access to training materials, presentations, demos, recordings, and supporting resources related to the MCX C15 and MCX C16 MCU family. While live Q&A support will be available during the training period, all content will remain accessible for future reference and self-paced learning.  Instructions  To get started with the MCX C15/C16 training, you will need to have your FRDM-MCXC162 in hand and perform the set-up operations according to the FRDM-MCXC162 Getting Started Page which is a pre-requisite.   Step 1. Mandatory pre-work before starting with the labs:  Getting Started with FRDM-MCXC162 Step 2. After completing the pre-work, download the lab guides. Each lab has its own guide document and a video guide you can use as support material in case you have any question at any step:  Lab0: Introduction to MCX C15/C16 and FRDM-MCXC162 Video  Lab1: Low Power is a Superpower Objectives Download and run your first project from VS Code on the FRDM-MCXC16 Explore the basics of low-power modes Description Load the SDK low-power example, walk through the code flow, and review the available wake-up options. You'll also learn how to connect a current meter to the FRDM board to measure power consumption. Lab Guide Document Video Lab2: Low-Power Sensing Demo Objectives Download and run your first ACH example from VS Code on the FRDM-MCXC16 Explore a low-power sensing application Description Access and download examples directly from ACH in VS Code, then run a real-world low-power sensor use case. Lab Guide Document Video Lab3: PWM Lighting Demo Objectives Learn how to load firmware using LinkServer/LinkFlash and simple production-style scripts Explore the timer and PWM capabilities of the MCXC family Description Use a provided binary and step-by-step instructions to program the board. The demo controls the onboard RGB LED using PWM. Source code will also be available in ACH. Lab Guide Document Video *Lab4: Connecting Expansion Boards to FRDM-MCXC162 Objectives Download an ACH example from VS Code Connect and use expansion boards with the FRDM-MCXC16 Description Connect an expansion board, download the example from ACH, and try a low-power sensing application using an external sensor. Lab Guide Document Video *Additional requirements as below:  Qwiic board: SparkFun Qwiic dToF Imager - TMF8820 - SparkFun Electronics  Qwiic board cable: https://www.adafruit.com/product/4210  MikroE OLED: OLED B click - carries 96 x 39px blue monochrome passive matrix OLED display  Step 3. Forum: Use the orange “ASK A QUESTION” button at bottom of this page to submit questions to the forum. Your questions will be answered by our NXP application engineers.  Step 4. Once you have completed the labs and got all your questions and/or concerns solved in the community, please complete a short satisfaction survey:   FRDM-MCXC162 Training Survey  Step 5. Review the support material and useful links to get you up to speed with some product information, FRDM board information and Getting started. Below also includes additional reading material.   MCX C15/C16 Product Page  FRDM-MCXC162 Tool Summary Page  FRDM-MCXC162 Getting Started Page  MCX C1 Family Factsheet  MCX C15/C16 Datasheet   MCX C15/C16 Reference Manual  FRDM-Training Hands-On Training MCXC
記事全体を表示
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
記事全体を表示
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
記事全体を表示
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.
記事全体を表示
BDM driver cw v6.3 my P&E USB multilink Universal Interface MC908JB8 chip needs a BDM driver to download my code to my MCS08QG8 chip. Otherwise I need a P&E USB multilink Universal board to load my MC9S08QG8 chip. And the board runs about $200. I would prefer to get a BDM driver for my Lenovo USB port. U say the BDM driver is in the CW v6.3 dvelopment software code! I loaded the CW v6.3 code but it will not install, because the "OS is wrong". the orginal OS was for my xp computer, but i am running windows 11 now and the cw v6.3 will not install on that OS. HELPPPPPPPPP!!!!!!!!! Re: BDM driver cw v6.3 你好,   CodeWarrior v6.3 与 Windows 11 不兼容;要在 Windows 11 中使用 CodeWarrior,请更新到 v11.1,这就是您无法在 Windows 11 中安装 CW v6.3 的原因。   能否分享一下您的 P&E USB Multilink 连接在设备管理器 > Jungo Connectivity 中显示的内容? 它在其他地方出现过吗?或者有警告标志吗? 例如,我的 P&E USB 多链路设置如下:   luis_maravilla_1-1786386142957.pngluis_maravilla_1-1786386142957.png 在USB Multilink Universal 和 USB Multilink Universal FX 技术概要 [USBMLUNIVERSALFX]文档的第 6 章“驱动程序安装”中提到,如果需要更新驱动程序,可以从 P&E 页面“支持中心”>“下载”下载驱动程序安装程序的副本。   顺祝商祺! Re: BDM driver cw v6.3 我需要MC9s08qg8芯片的BDM接口。我正在尝试在 Windows 11 系统上使用 BDM USB 驱动程序。我能否创建一个虚拟机来完成这项任务,还是说这条路也行不通?
記事全体を表示
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
記事全体を表示
MC9S08QG8 CODE WARRIOR WELL, I WILL HAVE TO SAY GOOD BYE, IF THE DERIVATIVE MC9S08QG8 CAN NOT BE SEEN IN CW V6.3 OR CW 11.1. I HAVE WORKED AT GETTING THIS CODE TO WORK FOR 40 DAYS NOW. U SAID IT WAS OK, BUT I CAN NOT FIND ANY CW V6.3 WINDOWS 11 THAT WILL RUN AND DEBUG IN CW 11.1 OR CD 6.3. IF I AM WRONG , PLEASE LET ME KNOW.  Re: MC9S08QG8 CODE WARRIOR Hello, The MC9S08QG8 device is available in CodeWarrior v11.1 under the section S08>HCS08Q Family>MC9S08QG8 I tested with the following setup: OS: Windows 11 CodeWarrior: 11.1 Device: MC9S08QG8 in board DEMO9S08QG8 Debug Connection: Via the connection in board DEMO9S08QG8 (USB-to-BDM interface) luis_maravilla_1-1786488162478.png Best Regards,
記事全体を表示
Cloud lab Guide Visit Cloud Lab official websites: NXP Cloud Lab | NXP Semiconductors Find answers to common questions along with troubleshooting techniques related to using Cloud lab. 1. Registration How to register a cloud lab account? No additional account is required, you can just use your NXP account to sign in Cloud lab. Learn more about NXP account My NXP Account FAQs | NXP Semiconductors. 2. Sign in How to  log in Cloud lab.com Log in with your NXP Email address and password. Once logged-in, you should be able to access the cloud lab home page 3. Book your favorite EVKs How to book your favorite EVKs? You can book the HARDWARE Take “hardware” for example, all hot hardware will be shown by clicking “HARDWARE”, You can also click on the filter button-“view all boards”, to see all the EVKs in the Cloud Lab. Select one EVK and click “BOOK NOW”. Here, you can use it now by clicking on “USE NOW” or book the time to make an appointment. USE NOW: means you can immediately use this EVK, just need to select an end time and click “CONFIRM BOOK” Reserve an EVK: select the date and time  and click “CONFIRM BOOK” After booked,  pop-up windows will take you to “my book” page. Please note that user can only book one EVKs  in the same period. How can I check my reservation? You can manage your booking in “MY BOOK” page.  Let’s click the “debug” button and experience the cloud lab. 4. Debugging Is there any manual or guide for new cloud lab users? Scroll down to click the  “Download cloud lab manual” button to find more instructions about the cloud lab.  How can I watch the video  during debugging? You can watch the video of EVK board and see the light status. But please note that , the video will be closed in 30s. Pls click “ ” to play the video again. How can I debug my EVK board?  The command line will automatically connect the board serial port, when the camera is turned on. All EVK boards are Linux system, pls login with root.  Can I reset my EVK board when I facing some errors? Sure. Please click “Power Reset EVK” to hard reboot the board and wait several second, the board will be rebooted. Can I reinstall my EVK when I facing some errors? Sure. You can click the “Reinstall the system” button to recover the default setting. (It will take several minutes to reinstall the system , this action will also delete the files you created or modified. Pls save your copy before you reinstall the system.) How  can I upload/download files  during debugging? Click the “upload files to EVK” to upload the file you need. Please note that If you would like to upload files to board's Network File System(NFS),  you will find your files in board's /home/root path. If you would like to upload your own Image or dtb file,  use "TFTP" tab. 5. Support How  can I get supports from NXP engineers? Please go to Cloud lab Forum to raise a ticket for supports. https://community.nxp.com/t5/Cloud-Lab-Forums/ct-p/Cloud-Lab 6. Connect us If you any concern or any suggestion about our cloud lab, please don’t be hesitate to email us [email protected] Cloud Lab-Hardware Cloud Lab-Software Cloud Lab-Solution
記事全体を表示
クラウドラボのログインと使用ガイド NXP Cloud Labsのウェブサイトをご覧ください: NXP Cloud Labs|組み込み設計を容易に行えるワンストップのクラウド開発プラットフォーム。 クラウドラボの利用に関する質問への回答や、クラウドラボ利用中に発生する問題のトラブルシューティングに関するヒントやコツをご覧ください。 1. 登録 クラウドラボのアカウントを登録するにはどうすればよいですか? NXP Cloud Labsにログインするために、追加のアカウント登録は必要ありません。NXPアカウントをお持ちであれば、ログインしてCloud Labsをご利用いただけます。 NXPアカウント登録について| NXPアカウントに関するよくある質問 | NXPセミコンダクターズ 2. ログイン クラウドラボにログインするにはどうすればよいですか? NXP.COMに登録したメールアドレスとパスワードを入力してください。 ログインに成功すると、次のページが表示されます。「ログイン」をクリックすると、Cloud Experimentのホームページに移動します。 3. 予約 興味のある開発ボードを予約するにはどうすればよいですか? 興味のあるハードウェア/ソフトウェア/システムソリューション/アプリケーションの例をクリックしてください。「ハードウェア」を例にとると、現在人気のハードウェアが表示されます。また、クラウド実験で現在オンラインになっているすべての開発ボードを表示することもできます。 興味のある開発ボードを1つ選択し、「今すぐ予約注文」をクリックしてください。すぐに使用するか、試用期間を設定するかを選択できます。 今すぐ利用:現在時刻からサービスをご利用いただけます。終了時刻を選択後、「予約確定」をクリックしてください。 利用予約をするには、希望の日付、開始時間、終了時間を選択し、「予約を確定」をクリックしてください。   予約が完了すると、予約ページに移動します(ただし、お客様お一人につき、デバッグ用の開発ボードは同時に1枚のみ予約可能ですのでご注意ください)。 注文した開発ボードを確認するにはどうすればよいですか? 「マイオーダー」ページでは、ご注文いただいたすべての開発ボードが表示され、注文内容を管理できます。下の「デバッグ」をクリックして、早速お試しください! 4. デバッグ デバッグ画面に入ったら、何をすればいいですか? コマンドボックスの一番下までマウスをドラッグすると、「クラウドラボマニュアルをダウンロード」という項目が表示されます。それをクリックすると、クラウドラボの操作ガイドがダウンロードされます。 デバッグ画面に入った後、どのようにビデオを視聴すればよいですか? 開発ボードのライブ映像を見ると、ボードの状態とインジケーターランプが表示されます。なお、映像は30秒後に自動的に終了します。再生するには、映像右上隅の再生ボタンをクリックしてください。 デバッグ方法は? カメラの電源を入れると、画面下部のコマンドラインが自動的に開発ボードのシリアルポートに接続されます。現在、すべての開発ボードはLinux 6.1.36を使用しており、ネットワークブートに対応しています。 デバッグ中は、Linuxファイルシステムに「root」ユーザーとしてログインしてください。  デバッグ中にいくつか問題が発生しました。予約注文した開発ボードを再起動することはできますか? はい、コマンドラインの右上隅にある「PowerReset EVK」ボタンをクリックすると、開発ボードの電源をオフにして再起動できます。 デバッグ中に、プリインストールされている開発ボードでポートが使用中と表示された場合、どうすればよいですか? 再接続するには、右上隅にある「再接続」ボタンをクリックしてください。 デバッグ中に問題が発生しました。予約注文した開発ボードにシステムを再インストールしたり、 Image/dtb/ファイルシステムを元のバージョンに復元したりすることは可能でしょうか? はい。「システムを再インストール」ボタンをクリックしてください。(この操作には時間がかかりますので、ご注意ください。この操作を行うと、使用中に作成または変更したファイルはすべて削除されます。このボタンをクリックする前に、必要なファイルはすべて保存してください。) デバッグプロセス中に 必要なファイルを アップロード / ダウンロードするにはどうすればよいですか? デバッグプロセス中に必要なすべてのファイルをアップロードするには、「EVKにファイルをアップロード」をクリックしてください。  ご注意ください:テストファイルを開発ボードのネットワークファイルシステム(NFS)にアップロードする場合、アップロードが成功すると、アップロードされたファイルは開発ボードの/home/rootパスに保存されます。独自のコンパイル済みイメージまたはdtbファイルを使用する場合は、TFTPボタンを選択してください。 5. テクニカルサポート NXPのエンジニアから技術サポートを受けるにはどうすればよいですか? ユーザーは、NXPコミュニティのクラウドラボセクション( https://community.nxp.com/t5/Cloud-Lab/bd-p/Cloud-Lab )にログインするか、デバッグウィンドウをクリックすることで、質問をしたり、サポートを受けたりすることができます。「コミュニティQ&A」セクションをクリックすると、NXPコミュニティクラウドラボのエリアに移動し、そこで質問を投稿できます。 6. お問い合わせ クラウドラボのご利用中に問題が発生した場合、またはご提案がございましたら、メールにてご連絡ください。( [email protected] ) クラウドラボ用ハードウェア クラウドラボソフトウェア クラウドラボソリューション
記事全体を表示
云实验室登录使用指南 访问云实验室网站:恩智浦云实验室 | 一站式云上开发平台,助力轻松开展嵌入式设计 查找云实验室使用等相关问题的解答以及在云实验室使用过程中相关的疑难解答技巧。 1. 注册 如何注册云实验室账号? 恩智浦云实验室登录并不需要额外注册账号,拥有恩智浦账号即可登录体验云实验室 了解恩智浦账号的注册 恩智浦账号常见问题解答 | NXP 半导体 2. 登录 如何登录云实验室? 输入您在NXP.COM 注册的电子邮箱地址及密码 登录成功后会有如下的页面提示,点击“登录”后您将进入到云实验的首页。 3. 预定 如何预定您感兴趣的开发板? 点击您感兴趣的硬件/软件/系统方案/应用范例 以“硬件”举例,您将看到当前热门的硬件, 同时您可以点击查看当前云实验所有上线的开发板 选择其中一款您感兴趣的开发板,点击“立即预定”,在这里您可以选择立即使用和预约使用 立即使用:即从当前时间开始使用,选择好结束时间后,点击“确认预定” 预约使用:选择需要使用的日期,开始时间及结束时间,点击“确认预定”   预定成功后,将根据提示前往我的预定界面(请注意,同一时间段,同一客户只能预定一块开发板进行调试。) 如何查看我所预定的开发板? 在“我的预定”页面中,您将看到所有的您预定过的开发板并且管理您的预定,下面点击“调试”开始体验吧 4. 调试 进入调试界面后,我应该如何操作? 将鼠标拖到命令框最下方,可以看到Download cloud lab manual, 点击可下载云实验操作指南 进入调试界面后,如何观看视频? 观看当前开发板的实时视频,可以看到开发板的状态以及指示灯亮灭。需要注意的是,视频30s会自动取消,如果需要重新播放,需要点击视频右上角的播放按键, 如何进行调试? 摄像头打开后下方的命令行会自动进入开发板串口,目前所有开发板系统均为Linux6.1.36,支持网络启动。 调试时请使用“root” 登录Linux 文件系统  在调试过程中,我遇到了一些问题,我可以重启我预定的开发板么? 可以,点击命令行右上角“PowerReset EVK”按钮可以实现开发板的掉电及重启 在调试过程中,如果我预定的开发板能显示端口被占用,我应该如何操作? 点击右上角“Reconnection”按键即可重新连接。 在调试过程中,我遇到了问题,我可以将我预定的开发板进行重装系统或者将将Image/dtb/文件系统恢复为原始版本么? 可以。点击“Reinstall system”按钮。(此操作需要花费较长时间,请谨慎操作。 此操作会删除您在使用过程中新建/ 修改的文件,请在点击此按键前保存您所需要的文件信息)   在调试过程中,我如何上传/下载我所需要的文件? 点击“upload files to EVK”,可以上传您在调试过程中所有需要的文件,  需要注意的是:如果您想上传测试文件到开发板的网络文件系统(NFS),上传成功后,您会在开发板的/home/root路径下找到您上传的文件;如果您想使用自己编译的Image或dtb文件,选择TFTP 按键。 5. 技术支持 如何获得恩智浦工程师的技术支持? 用户可以通过登录恩智浦社区云实验室专区(https://community.nxp.com/t5/Cloud-Lab/bd-p/Cloud-Lab)提问获取帮助,或者点击调试窗口的 “Community Q&A” 跳转到恩智浦社区云实验室专区进行提问。       6. 联系我们 如果您在使用过程中有任何的问题或者您对我们的云实验室有任何的建议,你可以通过邮件的方式联系我们。([email protected]) Cloud Lab-Hardware Cloud Lab-Software Cloud Lab-Solution
記事全体を表示
Cloud Lab Overview Welcome to use the Cloud lab.com. The Cloud lab is NXP’s first global platform where allows users to explore the latest NXP hardware, software or solutions online. Here users can remotely connect an evaluation board and do code debugging or technical evaluation online. All these EVKs are set in our onsite lab, each one is equipped with a high-definition camera, which monitors its status in real time. Users simply book the resource they are interested in, then they can use it within the predetermined period of time. After each usage period ending, the platform will automatically reinstall the system and clear the history to protect the privacy of each user. Our vision is to provide users with open resources, convenient and secure services and a cost-saving and resource-saving R&D experience. The Cloud Lab is willing to be a new fertile ground for every developer to test their ideas on new hardware platforms in time, experience the changes brought about by the latest NXP technologies, and receive real-time and professional technical support from NXP engineers. Let’s go! Explore the Cloud Lab and unlock your potential!  Click to visit :NXP Cloud Lab | NXP Semiconductors 欢迎使用云实验室官网。云实验室是恩智浦在全球范围内第一个可供用户线上使用恩智浦最新硬件、软件或解决方案的平台。 在这里,用户可以远程访问开发板进行线上调试和开发。这些开发板都安装在线下的实验室中,每块板子上方配有一个高清摄像头,可实时监控板子的状态。 用户只需在网站简单的预定其感兴趣的资源,就可在预定时间内尽情使用。每当一段预定时间结束,平台会自动重装系统、清理历史记录来保护每位用户的隐私。 我们的愿景是为用户提供开放的资源、便捷又安全的服务以及节约成本和资源的研发体验。 云实验室愿作每一位开发者的新沃土,让大家可以及时在新的硬件平台上测试他们的想法,体验最新恩智浦技术带来的变化,并获得恩智浦工程师实时和专业的技术支持。 来吧,让我们开启云实验室的大门,解锁无限之可能! 点击访问:恩智浦云实验室 | 一站式云上开发平台,助力轻松开展嵌入式设计 Cloud Lab-Hardware Cloud Lab-Software Cloud Lab-Solution
記事全体を表示
Cloud Lab Login and Usage Guide Visit the NXP Cloud Labs website: NXP Cloud Labs | A one-stop cloud development platform to help you easily conduct embedded design. Find answers to questions related to using the cloud lab, as well as tips and tricks for troubleshooting related problems during the use of the cloud lab. 1. Registration How do I register a cloud lab account? No additional account registration is required to log in to NXP Cloud Labs; you can log in and experience the Cloud Labs with an NXP account. Understanding NXP Account Registration | NXP Account FAQs | NXP Semiconductors 2. Log in How do I log in to the cloud lab? Enter the email address and password you registered with NXP.COM After successfully logging in, you will see the following page prompt. Click "Log in" and you will be taken to the homepage of Cloud Experiment. 3. Reservation How can I reserve the development board that interests me? Click on the hardware/software/system solution/application example that interests you. Taking "hardware" as an example, you will see currently popular hardware. You can also click to view all the development boards currently online in the cloud experiment. Select one of the development boards that interests you and click "Pre-order Now". Here you can choose to use it immediately or schedule a trial period. Use Now: Start using the service from the current time. After selecting the end time, click "Confirm Reservation". To reserve a use: Select the desired date, start time, and end time, then click "Confirm Reservation".   After successful reservation, you will be directed to your reservation page (please note that each customer can only reserve one development board for debugging at the same time). How can I check the development board I ordered? On the "My Orders" page, you will see all the development boards you have ordered and be able to manage your orders. Click "Debug" below to start experiencing it! 4. Debugging Once I enter the debugging interface, what should I do? Drag your mouse to the bottom of the command box, and you'll see "Download cloud lab manual." Click it to download the cloud lab operation guide. How do I watch the video after entering the debugging interface? Watching the live video of the development board will show its status and the indicator lights. Note that the video will automatically cancel after 30 seconds. To replay it, click the play button in the upper right corner of the video. How to debug? Once the camera is turned on, the command line at the bottom will automatically enter the development board's serial port. Currently, all development boards use Linux 6.1.36 and support network boot. Please log in to the Linux file system as "root" during debugging.  During the debugging process, I encountered some problems. Can I restart my pre-ordered development board? Yes, clicking the "PowerReset EVK" button in the upper right corner of the command line can power off and restart the development board. During debugging, if my pre-installed development board shows that the port is occupied, what should I do? Click the "Reconnection" button in the upper right corner to reconnect. During the debugging process, I encountered a problem. Can I reinstall the system on my pre-ordered development board or restore the Image/dtb/ file system to its original version? Yes. Click the "Reinstall system" button. (This operation will take a long time, please proceed with caution. This operation will delete any files you create/modify during use, please save any necessary files before clicking this button.) How do I upload / download the files I need during the debugging process ? Click "upload files to EVK" to upload all the files you need during the debugging process.  Please note: If you want to upload test files to the development board's Network File System (NFS), you will find the uploaded files in the /home/root path of the development board after a successful upload; if you want to use your own compiled Image or dtb files, select the TFTP button. 5. Technical Support How can I get technical support from NXP engineers? Users can ask questions and get help by logging into the NXP Community Cloud Lab section ( https://community.nxp.com/t5/Cloud-Lab/bd-p/Cloud-Lab ), or by clicking the debug window. The "Community Q&A" section will redirect you to the NXP Community Cloud Labs area to ask your questions. 6. Contact Us If you encounter any problems during use or have any suggestions for our cloud lab, please contact us via email: ( [email protected] ) Cloud Lab-Hardware Cloud Lab-Software Cloud Lab-Solution
記事全体を表示