Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
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.
記事全体を表示
S32DS ARM 2018 R1 License Expired Hello. 3e3ddc69f7c74134887b48237e8792a5.png My S32DS license: 1F6C-C156-4EFC-CE54 Application for extension/reissuance thank you Re: S32DS ARM 2018 R1 许可证过期 Your S32DS license has been extended.  Re: S32DS ARM 2018 R1 许可证过期 hello: My S32DS license:  3961-E8A1-3B9E-B769 Application for extension/reissuance thank you! 414179465_0-1786263896843.png
記事全体を表示
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
記事全体を表示