Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
PNEV5190B does not work After loading Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin from the "Load Secondary Firmware" option on the Extra tab of NFC Cockpit, my PNEV5190B no longer responds and cannot be operated from NFC Cockpit. According to the update log, the firmware download completed successfully without any reported errors. The board became unresponsive only after the update was finished. I found a similar issue in this thread, but I would like to understand the root cause. What could cause the board to become unresponsive even though the firmware update completed successfully? Is it possible that I used an incorrect secondary firmware image for my board or firmware version? Why does loading the secondary firmware result in a state where NFC Cockpit can no longer communicate with the board? Thank you for your support. Re: PNEV5190B does not work Hello @Miyazaki001 Hope you are doing well. Could you please provide more details on your setup? What is the procedure you are following? I tried the following setup: - PNEV5190B - FW v2.0B - NFC Cockpit v9.0.0 - "Extra" tab > "Secondary FW" tab > Load Secondary Firmware - Select NxpNfcCockpit_v9.0.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin NFC Cockpit should indicate to close the COM port and open it again: After reopening the COM port, you should be able to start the Secondary Firmware in "Extra" tab. Regards, Eduardo. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your reply. My setup is as follows: - PNEV5190B (B1 chip) - PN5190 FW v02.05 - NFC Cockpit v7.4 - Extra tab → Secondary FW → Load Secondary Firmware Selected: -NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin The secondary firmware update appears to complete successfully. According to the log, the firmware download finishes without any reported errors. The relevant part of the log is shown below. After the update, NFC Cockpit prompts me to manually close and reopen the Board Connection. I followed this procedure, and I also tried disconnecting and reconnecting the COM port manually. However, after reopening the connection, the board no longer responds to any commands. The log shows a timeout when NFC Cockpit attempts to communicate with the board. I have attached the relevant log for your reference. Could you please advise: - Is PN5190 FW v02.05 compatible with this secondary firmware? - Is there any known issue with NFC Cockpit v7.4 and this secondary firmware? I found a similar issue in this thread, but I would like to understand the root cause. Thank you for your support. Best regards, Re: PNEV5190B does not work Hi, I could not locate any documented instance for an unexpected behavior using this specific setup. NFC Cockpit v7.4.0 is outdated; please update to the latest version available (v9.0.0) and perform FW update on PN5190. After this, let me know your findings. If this behavior persists after updating your setup, please let me know your jumper configuration and power connections (a picture of your board would also be helpful). Regards, Eduardo.
記事全体を表示
MINISASTOCSI Latest Schematics Hi Team, Could you please help to share MINISASTOCSI latest schematics? Re: MINISASTOCSI Latest Schematics Hi @ramkrish, The most recent revision of the MINISASTOCSI board is A1. I have just sent the file to your email address for your reference. Please let me know if you have any trouble receiving it or if you need any additional information related to this board revision. Best regards, Chavira Re: MINISASTOCSI Latest Schematics Hi @Chavira Received, Thanks
記事全体を表示
K312 RTD3.0.0到RTD6.0.0 IIC部分驱动更换 Hi  当前我在RTD3.0.0中遇到了一个IIC  从机时钟挂起的问题,发现与IIC 的时钟延展功能相关,经过FAE的推荐,说6.0.0驱动中没有这个问题,因为项目周期原因,基于最小更改原则,我将 IIC的相关驱动文件从6.0.00中摘出,放到的我3.00 RTD 中,但是我发现无法正常运行。更改完成后,IIC一旦接收到数据,就无法退出中断。 我想请问: 1 、是否有人曾经尝试过这样的操作(3.00RTD 更换部分驱动为6.00),你们是否支持这样的更改,我还有别的关联驱动未移植吗? 2、我发现 在6.0.00中有一个IIC的更改项目, 它在4.00中被修复了 5.00继承了这个修复,但是6.00又恢复到了3.00的逻辑,但是我在6.00的release note中并没有发现它的相关描述,请问6.00是做了其他更改修复了这个bug吗? static void Lpi2c_Ip_SlaveIRQHandlerInternal(uint8 Instance) { LPI2C_Type *BaseAddr; Lpi2c_Ip_SlaveStateType * Slave; boolean StopDetect = FALSE; boolean RepeatStartDetect = FALSE; BaseAddr = Lpi2c_Ip_pxBase[Instance]; Slave = Lpi2c_Ip_pxSlaveState[Instance]; StopDetect = LPI2C_Get_SlaveSTOPDetectEvent(BaseAddr); RepeatStartDetect = LPI2C_Get_SlaveRepeatedStartEvent(BaseAddr); /* Check address valid and tx/rx event */ Lpi2c_Ip_SlaveCheckDataEvent(Instance, BaseAddr, Slave); if (RepeatStartDetect) { Slave->RepeatedStarts++; if ((1U == Slave->RepeatedStarts) && (Slave->Is10bitAddress))  //  此处  在4.00中已修改 { RepeatStartDetect = FALSE; LPI2C_Clear_SlaveRepeatedStartEvent(BaseAddr); } } if ((TRUE == StopDetect) || (TRUE == RepeatStartDetect)) { /* Stop/repeated start detected */ Lpi2c_Ip_SlaveStopDetectHandler(BaseAddr, Slave); if (TRUE == StopDetect) { /* reset repetead starts for a new transfer */ Slave->RepeatedStarts = 0U; } } /* Check for slave errors */ Lpi2c_Ip_SlaveCheckErrorEvent(BaseAddr, Slave); } 关联bug :ARTD-6112
記事全体を表示
ddr_stress_tester cannot work on some DDRs I have been using  ddr_stress_tester tools for many years, this year, I found the tool cannot work well on some newer manufacturing process DDRs, (20nm or 25nm DDRs),  we found that the binary will hang when I select cpu frequency. For example, winbond  w631gu6rb and ISSI IS43TR166640C-125JBLI-TR. by the way  CPU model is mx6solo/dl i.MX6DL Re: ddr_stress_tester cannot work on some DDRs The symptom is more likely tied to the DDR initialization/MMDC setup or board-level margin than to the DDR die process node itself. I could not find an NXP-documented issue that says the i.MX6Solo/DL ddr_stress_tester hangs specifically because the DDR3 is 20 nm/25 nm, nor anything specific to Winbond W631GU6RB or ISSI IS43TR166640C after checking NXP library/community paths by part number, process node, and “CPU frequency” hang wording. What I would check first: Use the i.MX6/7 DDR Tool flow, not an old fixed script The i.MX6/7 DDR tools are intended to generate and test a custom DRAM initialization based on the actual device configuration — density, chip-selects, bus width, board layout/swizzling, etc. — and they explicitly cover i.MX6DL/S devices. If you changed DDR vendors or DDR geometry/timing, regenerate the .inc initialization script using the DRAM Register Programming Aid / DDR tool flow; NXP notes that scripts “may need to be modified for your custom board and memory.” Do not assume old calibration values still apply The stress tool performs write leveling, DQS gating, read/write delay calibration, and stress testing on i.MX6 boards. If it hangs right after selecting frequency, the DDR may already be marginal before calibration can complete. NXP community guidance for similar i.MX6 DDR stress hangs points to incorrect MMDC parameters, power brownout, board noise, or layout issues. Check DDR voltage/mode and frequency selection i.MX6Solo/DualLite DDR pads support LPDDR2 and DDR3/DDR3L modes. For DDR3/DDR3L I/O supply, the i.MX6Solo/DL datasheet excerpt gives OVDD as 1.425–1.575 V for DDR3 and 1.283–1.45 V for DDR3L . The i.MX6 DDR stress tool supports DDR stress testing between 135 MHz and 672 MHz ; select a conservative DDR frequency first, then work upward after calibration passes. Review refresh timing There is an i.MX6 case where low-frequency hang was resolved by correcting MMDC0_MDREF , changing tREFI from 3.9 µs to 7.8 µs . NXP documentation also points to MMDCx_MDREF as the register controlling DDR refresh behavior, and notes that some DDR3 devices require temperature-dependent refresh changes, e.g. 64 ms refresh period at ≤85 °C and 32 ms above 85 °C. Eliminate known tool-environment hang causes If running from U-Boot, disable splash screen / IPU or any DMA that may still access DRAM; NXP notes that active IPU/splash access can make the system hang during the DDR stress flow. Check whether the watchdog fuse/configuration is enabled; NXP notes that on i.MX6Solo the watchdog can reset the device while DDR_Stress_Tester is doing calibration or stress test. If you are using the JTAG version, one reported i.MX6 case stopped after DDR frequency selection, and the guidance was to check JTAG mode/connection and use simple SDK DDR tests plus signal/power probing. My recommendation: regenerate the DDR init script for each new DDR part, start with a lower MMDC/DDR frequency, verify MDREF /timing values against the DDR datasheet, then rerun calibration. If it still hangs at CPU/DDR frequency selection, scope DDR power rails and clocks during that transition and compare MMDC register values between the old working DDR and the new Winbond/ISSI parts. The issue should be treated as an i.MX6Solo/DL DDR initialization and margin problem first; I did not find evidence that NXP identifies 20 nm/25 nm DDR3 process itself as a ddr_stress_tester incompatibility.
記事全体を表示
Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Subject: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hi, I am trying to configure and program the OTP on the FS2400 using the KITFS24SKTFDMEVM evaluation board. Evaluation board: https://www.nxp.com/design/design-center/development-boards-and-designs/KITFS24SKTFDMEVM However, when I connect the board to the NXP GUI, I am unable to establish communication with the device. The GUI reports the error shown below, and no communication takes place. I have previously used the same NXP GUI with the FS26 evaluation board without any issues, so I believe my PC setup and GUI installation are working correctly. The evaluation board is in its default configuration, and I have not intentionally changed any jumper or switch settings. To verify, the current configuration is as follows: S12 (OTP): OFF J30: Pins 1-2 connected SW4 (WAKE2): ON S19 (WAKE3): ON J33: Open J37: Pins 2-3 connected J36: Pins 2-3 connected J10: Pins 2-3 connected SW9: All switches ON J45: Pins 2-3 connected J26: Pins 5-6 and 9-10 connected SW20: All switches OFF S2: ON (I could not locate this switch in the schematic ) SW18: All switches ON SW1 (Main Power Switch): Position 3 (2-3) I have not programmed the S32K144 MCU on the evaluation board. My understanding is that the board is shipped with the required firmware already programmed. Could someone confirm whether this is correct, or whether the MCU needs to be flashed before the GUI can communicate with the FS2400? Below is the error message displayed by the GUI: Any help would be greatly appreciated. Thank you. FS85&FS84 FSBC+PMIC Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hello, Thank you for contacting us. Could you please update the firmware according to Section 5, "Installing and Configuring Software and Tools," of the UM12015 KITFS24SKTFDMEVM User Manual? This procedure should resolve the error you are experiencing. If the issue persists after completing the update, could you please provide a picture of your hardware setup? This will help us review the configuration and investigate the problem further. Thanks! Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hi @ErikaC , Thank you for your response. I checked Section 5, “Installing and Configuring Software and Tools,” of the UM12015 KITFS24SKTFDMEVM User Manual. However, I am unable to find the KITFS2400FRDMEVM_HW_Test_Package_W20.zip file mentioned in the document. Could you please let me know where I can download this .zip file? I need it to update the firmware as described in the manual. I was able to find fs23xx-fw-FS24-v0.86.hex in the NXP GUI. Is this the firmware file that should be used for the update, or is it a different file included in the KITFS2400FRDMEVM_HW_Test_Package_W20.zip? I also checked the link provided in the manual: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=S32DS-IDE-ARM-V2-XI downloaded and installed the executable from there (this was design studio but not the main S31244_Flash File), but I could not find the required .zip package. Could you please provide the download location for KITFS2400FRDMEVM_HW_Test_Package_W20.zip, or let me know where I can find the correct firmware package needed to perform the update? Thank you for your help. Ganesh Bhagwat Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hi @ErikaC  If fs23xx-fw-FS24-v0.86.hex is the correct firmware file, is there any specific procedure required to directly load/flash this .hex file to the KITFS24SKTFDMEVM, or is there a specific tool/setup that needs to be used? If possible, it would also be greatly appreciated if you could provide the KITFS2400FRDMEVM_HW_Test_Package_W20.zip package or the download location for it, as this would make it much easier to follow the firmware update procedure described in the manual. Thank you for your help. Ganesh Bhagwat Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hello, I could not find the KITFS2400FRDMEVM_HW_Test_Package_W20.zip folder. It was likely included in an earlier version of NXPGUI. However, that package only contained the fs23xx-fw-FS24-v0.86.hex file, which is the only file required to program the firmware. Please follow all the steps described in the UM12014 KITFS2400FRDMEVM User Manual. The use of a debugger is required, as shown in Figure 17, and you must also install the S32 Design Studio tool. The firmware update procedure cannot be completed successfully without the required debugger connection and software environment described in the user manual. Hope this helps! Re: Unable to Communicate with FS2400 Using KITFS24SKTFDMEVM and NXP GUI Hi @ErikaC , Thanks for this. It worked, and I am now able to communicate with the NXP-GUI. The only issue was that these two settings were not present by default. As you mentioned, after adding them, everything worked. The command added under Executable was: ${cross_prefix}gdb${cross_suffix} Thanks again for your support. Regards, Ganesh Bhagwat
記事全体を表示
[LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S69 Hi, I've been trying to get Zephyr's MCUboot to work on the LPC55XpressoS69 using core 0. I am running the simple Blinky sample application in Zephyr.  Running the application just fine without any errors. However, I've been trying to send a device firmware update (DFU) over UART using mcumgr and for some reason I can't even establish a connection between mcumgr and my device. I keep getting a "NMP timeout." For context, my directory structure looks like the following: | __boards                 |__ lpcxpresso55s69_lpc55s69_cpu0.overlay __ src                |__main.c __sysbuild               |__mcuboot.conf                __mcuboot.overlay __prj.conf __sysbuild.conf My prj.conf looks as follows:   # Enable MCUMGR subsystem and OS/Image management commands CONFIG_MCUMGR=y CONFIG_MCUMGR_GRP_OS=y CONFIG_MCUMGR_GRP_IMG=y # DIRECT SMP over UART CONFIG_MCUMGR_TRANSPORT_UART=y CONFIG_MCUMGR_TRANSPORT_SHELL=n # Dedicate flexcomm0 to SMP — nothing else on the UART CONFIG_CONSOLE=n CONFIG_UART_CONSOLE=n CONFIG_LOG=n CONFIG_SERIAL=y CONFIG_UART_INTERRUPT_DRIVEN=y # Required for SMP UART processing thread CONFIG_NET_BUF=y CONFIG_ZCBOR=y CONFIG_BASE64=y # Required subsystems for DFU CONFIG_FLASH=y CONFIG_IMG_MANAGER=y CONFIG_MCUBOOT_IMG_MANAGER=y # Dependencies for System/Reboot management via DFU CONFIG_REBOOT=y My sysbuild.conf is as follows:   SB_CONFIG_BOOTLOADER_MCUBOOT=y SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y My mcuboot.conf looks like    CONFIG_LOG=y CONFIG_MCUBOOT_LOG_LEVEL_INF=y CONFIG_MCUBOOT_SERIAL=y CONFIG_BOOT_SERIAL_UART=y CONFIG_UART_CONSOLE=n   My mcuboot.overlay looks like /* Step 3.4 - Configure button and LED for Serial Recovery */ // zephyr,console = &flexcomm0; // zephyr,uart-mcumgr = &flexcomm0; / { chosen { zephyr,code-partition = &boot_partition; zephyr,uart-mcumgr = &flexcomm0; zephyr,shell-uart = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; / { aliases { mcuboot-button0 = &user_button_3; mcuboot-led0 = &blue_led; }; }; &gpio0 { status = "okay"; }; &gpio1 { status = "okay"; }; &blue_led { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; And finally my lpcxpresso55s69_lpc55s69_cpu0.overlay looks like / { chosen { zephyr,code-partition = &slot0_partition; zephyr,mgmt-smp = &flexcomm0; zephyr,uart-mcumgr = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; When I run the following MCUmgr command, I get back an NMP timeout, as seen below: > mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout So the mcumgr definitely realizes that the port is available (it would deny access otherwise), but it keeps getting timed out. I'm pretty sure this is a config option error. I've tried changing the config options numerous times but nothing quite seems to do the trick. I'm also pretty sure I'm missing some config option somewhere which is crucial for this to work.  I've looked through about as many application notes and user manuals out there as I can. None of them seem to help for my particular case: DFU using Zephyr MCUboot on an LPC55Sxx chip running a Zephyr application. Any help would is appreciated, though it may be best if someone tried it out on their board e.g. LPCXpresso55S69 and confirm they can carry out a UART DFU with any simple program. LPC55S6x LPC55S69-EVK  LPC55xx Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @ZQ2  Since mcumgr echo is already returning NMP timeout, I think you can  verify the MCUmgr UART communication before debugging the MCUboot DFU flow. You can  confirm the following: flexcomm0 is the UART connected to COM11 on the LPCXpresso55S69 board. The application is running normally (not staying in MCUboot serial recovery mode). No console, shell, or log output is sharing the same UART used by MCUmgr. As a quick validation, I would recommend starting from Zephyr's smp_svr sample and verifying that the following command works first: mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" BR Harry Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @Harry_Zhang , Coincidentally, I was using Zephyr's smp_svr sample yesterday immediately after posting this question. I get the same exact problem though. I followed the Zephyr documentation for the sample at the following link. I simply created a project for the sample and then built the code successfully, enabling the configs for the Raw UART (serial) smp_svr option from the docs using the following command, as instructed: west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild -- -DEXTRA_CONF_FILE="raw-serial.conf;fs.conf" And then I flashed the code successfully. Nonetheless: C:\Users\Dev>mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout   I even tried changing the debugger probe from Link2 to JLink, after which the debug probe became attached to COM16. I also disabled any mass storage device functionality, just in case, using JLink commander. Then I tried flashing and running: > west flash -r jlink but yet again: C:\Users\Dev> mcumgr --conntype serial --connstring "dev=COM16,baud=115200" echo "test" Error: NMP timeout What could I possibly be missing? I assume it has something to do with the configs? If so, I wonder why the Zephyr official sample for smp_svr isn't compatible with the LPC55S69 and requires modification. Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @Harry_Zhang , Your solution does indeed work. In fact, I was able to strip down the command to merely west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" This also worked. Thank you a ton for replicating my problem, it's deeply appreciated. Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @ZQ2  I was able to reproduce and verify the setup on an LPCXpresso55S69 board. 1. The key point is that MCUmgr must be used together with MCUboot in this configuration. The application is linked to slot0 (not the flash base address), so building and flashing the smp_svr application alone will not work correctly. MCUboot is required to boot and hand over control to the application. 2. i add the overlay file lpcxpresso55s69_lpc55s69_cpu0.overlay in file /c/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards. &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 3. built the project using the following command: west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" -DEXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" -Dmcuboot_EXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" 4. after built it. you can use command  grep -A20 -B5 "boot_partition" build/mcuboot/zephyr/zephyr.dts 5. and west flash 6. 7. which confirms that the UART transport, SMP server, MCUmgr, and MCUboot integration are all working correctly. BR Harry
記事全体を表示
LX2162A USXGMII link never completes Hey all, I have an LX2162A SoM manufactured by Solidrun. I'm using a Clearfog devkit but moving to a custom carrier soon.  Solidrun provides base RCW/DCP/DPL and I've verified functionality. In my case, the DPC for dpmac3 works for the SFP cage and I get an XFI link via SFP DAC cable and various SFP modules. The RCW "rcw_2000_650_2900_3_11_0_auto" sets to SerDes1=3, SerDes2=11 and I'm using a QorIQ kernel (lf-6.6.52-2.2.0) and mc-utils (10.39.0) but with some Solidrun patched applied to both. Uboot and other things are also patched. All patches come from here: https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 I have a MaxLinear GPY245-EKV-1 (and -2) devkit(s) that wants USXGMII over DAC cable to connect the phy to the device. Apparently this is pretty normal. Eventually this phy chip will be integrated into SerDes2=7 Lane6 and Lane7 but I have to use the SFP cage on the Clearfog for testing. Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP I'm only trying to configure dpmac3 to use this USXGMII link via DPC: mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; (I've also tried MAC_LINK_TYPE_BACKPLANE) Confirmed via "restool dpmac info dpmac.3" shows "DPMAC ethernet interface: DPMAC_ETH_IF_USXGMII". In Linux, I added the MaxLinear driver and patched a few things: gpy_update_interface() fix (LKML, Daniel Golle). This was returning -EINVAL for USXGMII interface, crashing phy_state_machine. Patched lynx_pcs_config_usxgmii() in pcs-lynx.c to also write MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) via mdiobus_c45_modify(), since the function only ever wrote MII_ADVERTISE and never enabled AN on the Replicator block itself. This gap matches another post on this forum ("LS1028A 10g-qxgmii phy bring-up") which found the identical symptom (MMD31.0/Replicator control register stuck at 0) and got AN to kick in after manually setting bit 12. This is the DPMAC3 Linux devicetree entry: &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; where `gpy245_0` is the MDIO node. MDIO traffic to the phy is working. I added a printout in the lynx_pcs driver which shows the readback: mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 Question: Given writes to MDIO_MMD_VEND2 registers on this PCS instance don't appear to persist, is there a known additional step (SerDes/PCS block enable, protocol-specific initialization, or similar) required before the USXGMII on the LX2162A family SoCs will accept configuration? Is protocol 3 fully validated for USXGMII on dpmac3, or primarily intended/tested for XFI? Other questions: Maybe I don't understand GPY245 and USXGMII. I see some folks refer to this as QXGMII and I can't tell if the LX2162A is even capable of that working. Maybe I need to reach out to Solidrun, but all of their patches do not seem to limit the LX2162A's capability. Thanks! Re: LX2162A USXGMII link never completes @yipingwang I really appreciate the detailed response! Everything you said makes sense and I've started learning more about the platform. I've started using the advice in AN13329.pdf. Some of the addresses and things aren't working (probably a version mismatch) but at least I can get the MC log as shown below: => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ I've attempted to poke at the PCCC via uboot. Here are the relevant things: crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... I really hope 0x1ea10b0 is the right address. According the LX2162ARM.pdf, that *could* be the right address and decoding the bits shows: A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI Is the right right register address (PCCC) to observe? Is there any other information I can provide? Thanks! Re: LX2162A USXGMII link never completes The LX2162A side is documented to support USXGMII on the paths you are using , but the symptom you show looks less like a missing Linux pcs-lynx write and more like the selected PCS instance is still not actually in USXGMII application mode, or MC firmware is programming the wrong 10G PCS selector. For SerDes1 protocol 3 , the LX2162A reference manual lists all four SerDes1 lanes as USXGMII / XFI , including USXGMII / XFI.3 for the first lane, which corresponds to the DPMAC3 use case you are testing on the Clearfog SFP path . For your future custom-carrier target, SerDes2 protocol 7 also documents lane 6 and lane 7 as USXGMII / XFI.13 and USXGMII / XFI.14 . The important catch is that the USXGMII / XFI entry is not automatically “USXGMII.” The reference manual says that between USXGMII and XFI on a lane, the default is XFI . The mode is selected through PCCC , the Protocol Configuration Register C, and its SXGMII*_XFI bits select 0b = USXGMII and 1b = XFI/SFI . So the first thing I would check is not the Linux BMCR write itself, but whether the specific SXGMII instance for DPMAC3 has its PCCC XFI-select bit cleared after MC/DPC initialization. There is also precedent for this exact class of failure being in MC firmware , not in the Linux PCS driver: one LX2162A ticket shows MC clearing the wrong 10G interface selector in PCCC for a USXGMII configuration, and an MC firmware engineering build, version 10.35.101 , resolved the issue . Another ticket notes that MC settings are done by MC firmware, with NXP providing MC as a binary . Since you are on MC 10.39.0 , you should be beyond that specific old fix, but the failure mode you see is still consistent with “MC did not put the intended PCS into USXGMII mode” or “the wrong PCS instance is being addressed.” What I would do next: Read PCCC before Linux changes anything. After RCW + MC + DPL/DPC load, but before the Linux PCS driver runs, read PCCC and confirm the relevant SXGMII*_XFI bit is 0 . For DPMAC3 / USXGMII/XFI.3 , expect the first SXGMII selector, not the selector for MAC13/14. If that bit remains 1 , the lane is still XFI/SFI and your VEND2/USXGMII PCS writes are not being applied to a live USXGMII PCS path. Check that the MDIO access is hitting the intended PCS management port. The SXGMII protocol-control register has an MDEV_PORT field used to match MDIO accesses, and the manual says software must wait at least 3 platform clocks after changing it before MDIO accesses to the SGMII/PCS target . If the MDIO address decode is wrong, writes can appear to “not persist” because you are reading a different or reset/default PCS window. Confirm the USXGMII AN registers are meaningful only after the mode select is correct. The USXGMII PCS CONTROL register has AUTO_NEGOTIATION_ENABLE at bit 12, and DEV_ABILITY / PARTNER_ABILITY are RW registers . The DEV_ABILITY lower vendor arbitrary speed field must be non-zero, because zero can cause auto-negotiation failure . But if PCCC still selects XFI, these BMCR/ability writes are not the real root problem. Do not treat QXGMII as a separate required external protocol unless the GPY245 board documentation explicitly says so. LX2162A documentation does contain QXGMII protocol-converter registers, including reset/powerdown control bits such as PD_QXGM and RST_QXGM . NXP community material for LS1028A also refers to a 10G_QXGMII Lynx SerDes driver path . But the documented LX2162A DPMAC interface you are selecting is still USXGMII / XFI , and NXP documentation separately states that LX2160-class devices support USXGMII and that “SXGMII” is not the same thing . In other words: “QXGMII” references in driver/community discussions may describe an internal converter/driver naming path, not necessarily a different MAC-to-PHY contract than the USXGMII mode you configured. For this Clearfog SFP test, keep the DPC simple. MAC_LINK_TYPE_PHY with enet_if = "USXGMII" is the more natural model for a managed external PHY over MDIO. I would not expect MAC_LINK_TYPE_BACKPLANE to fix a PHY-facing USXGMII setup unless you are intentionally using a backplane/KR-style flow. I would not conclude that protocol 3 is “primarily XFI-only.” The reference manual documents protocol 3 as USXGMII / XFI for DPMAC3’s SerDes1 lane . What I cannot verify from the retrieved material is a separate validation statement saying “protocol 3 + DPMAC3 + USXGMII was validated with GPY245.” The stronger, evidence-backed statement is: the hardware mode exists, defaults to XFI unless PCCC selects USXGMII, and there is known MC-firmware precedent for programming the wrong 10G PCS selector . For your specific readback: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 that is exactly the kind of result I would expect if the PCS instance is not fully enabled/selected for USXGMII, or the MDIO management window is not addressing the intended PCS instance. I would verify PCCC and the MC log first, before adding more Linux-side writes. LX2162A protocol 3 is documented for USXGMII / XFI on DPMAC3, but USXGMII depends on MC/PCCC selecting the USXGMII PCS; if VEND2/BMCR writes do not persist, first prove the correct PCCC bit is cleared for DPMAC3 and that MDIO is addressing the correct SXGMII PCS instance.
記事全体を表示
IMX8MP On chip RAM memory access Hello, I want to learn how I can access the OCRAM  to read and data to the memory. Can anyone advice how I could achieve that on Linux cortex A-53? On-Chip RAM - OCRAM (576 KB) start address: 0x00900000 => reserved for ROM start address: 0x00918000  =>OCRAM FREE AREA end address: 0x0097FFFF https://www.nxp.com/webapp/Download?colCode=IMX8MPRM  Thank you! IMX8MPLUS  i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: IMX8MP On chip RAM memory access Hi Roman Luz, does this tip works for you? Regards, Stefano Gigli Re: IMX8MP On chip RAM memory access Hi @Roman_Loz , you could try including compatible = "shared-dma-pool"; and it should work. ocram_dma: ocram_dma@970000 { no-map; compatible = "shared-dma-pool"; reg = <0 0x970000 0 0xC00>; // 3KB }; Regards, Samhitha Kashyap Re: IMX8MP On chip RAM memory access Hi, I am trying to use the OCRAM the way you suggested but I get kernel panic when I try to memcpy to/from it. Could you please help me understand what am I doing wrong or missing? dtsi: resmem: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; ocram: ocram@900000 { no-map; reg = <0 0x900000 0 0x70000>; }; ocram_dma: ocram_dma@970000 { no-map; reg = <0 0x970000 0 0xC00>; // 3KB }; ... module init: // Find the OCRAM DMA node by name np = of_find_node_by_name(NULL, "ocram_dma"); if (!np) { pr_err("Failed to find OCRAM DMA node in device tree\n"); return -ENODEV; } // Lookup the reserved memory region rmem = of_reserved_mem_lookup(np); if (!rmem) { pr_err("Failed to lookup reserved memory for OCRAM DMA\n"); return -ENODEV; } // Map the reserved memory region ocram_dma_base = ioremap(rmem->base, rmem->size); if (!ocram_dma_base) { pr_err("Failed to map OCRAM DMA memory\n"); return -ENOMEM; } copy: memcpy(current_address, mv->A, MATRIX_STRUCT_SIZE);   Re: IMX8MP On chip RAM memory access Hi @Samhitha_Kashyap, Please note that the NXP does not recommend the modification in the node for 448 KB OCRAM Space as it is used by other drivers. One can use memory regions after 0x970000 to Support DMA using the compatible = "shared-dma-pool" property. Thanks & Regards Sanket Parekh Re: IMX8MP On chip RAM memory access Hi @Sanket_Parekh, Thanks for the response, it was helpful!  Would it be possible for me to modify the device tree to support DMA within the 448 KB OCRAM space, if I can't use it for the user application? Thanks & Regards, Samhitha Kashyap Re: IMX8MP On chip RAM memory access Hi @Samhitha_Kashyap , I hope you are doing well.   You can determine how much memory in the OCRAM, Linux kernel Reserved for itself by looking into the dtsi file (reserved memory node) of the soc in the case of imx8mp, it is 448 KB.   resmem: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; ocram: ocram@900000 { no-map; reg = <0 0x900000 0 0x70000>; };   ..... .....   }   So here 0x70000 ( 448K) bytes are reserved for Linux usage. and cannot be virtually mapped to the userspace as specified by the no-map property. after 0x7000 bytes you can use it for other applications. But you need to make sure that any  M7 core Application not using OCRAM. which can be determined by looking into the Linker script of a particular application.   Thanks & Regards Sanket Parekh   Re: IMX8MP On chip RAM memory access Hi Sanket, Would it be possible to verify how much memory the Linux utilizes and the rest can be used for the user application. If it is possible, how could I verify the same and allocate the rest of the memory for my application.  Thanks & Regards, Samhitha Kashyap Re: IMX8MP On chip RAM memory access Hi @Samhitha_Kashyap  I hope you are doing well. To access OCRAM First you need to ensure that you don't try to access the region that is used by ATF. in the case of u-boot, one can use md/mw command to access OCRAM directly. It is not recommended to use OCRAM in userspace as Linux itself uses it. Thanks & Regards Sanket Parekh
記事全体を表示
S32K3 ADC Optimize DMA Streaming Hello, When the adc group has only one channel and the Adc Enable Optimize DMA Streaming Groups configuration item is checked, a hard fault occurs when the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink function is executed. In the case of a single channel, if the Adc Group Without Interrupts configuration item is checked and ACCESS_MODE_STREAMING, Select Adc Streaming Dma Channel is enabled. Otherwise, the number of the dma channel in the configuration file is 255, which is reasonable here. But what I don't understand is why when ADC_ENABLE_GROUP_STREAMING_RESULTS_RORDER or ADC_OPTIMIZE_DMA_STREAMING_GROUPS is STD_ON, instead of STD_ON==GroupPtr ->AdcWithoutInterrupt, the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink function will be called. This seems unreasonable, and also because the call to this function leads to hard fault. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 Please do not use your QQ email account next time; please use your company email account instead. I tested this, but I didn't find any problems. I have attached my test project and test result for your reference. Also, i check your code and i found some error in your code. 1.clock init is wrong, your code can't not run successfully, 2."adc_group0_val" should be attribute to "no-cacheable area" also: The usage instructions for Optimize DMA streaming groups are clearly explained in the user manual. RTD_ADC_UM.pdf Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent The optimization level of my project is -O0, and I ran your project (also with -O0). I found that in Adc_Ipw_SetupTcdSingleAdcChannelMajorLink -> ...... -> Dma_Ip_ConvertLogicChToHwCh, the LogicCh value is still 255. In your screenshot, was Dma_Ip_ConvertLogicChToHwCh called as a result of Adc_Ipw_SetupTcdSingleAdcChannelMajorLink? Mcl_Init also calls Dma_Ip_ConvertLogicChToHwCh, and in that case LogicCh is 0, which seems consistent with your screenshot. I ran a test in your project. When Adc_Ipw_SetupTcdSingleAdcChannelMajorLink indirectly calls Dma_Ip_ConvertLogicChToHwCh, I observed that &Dma_Ip_pxInit->ppxLogicChannelConfigArray[LogicCh] is 0x429F28, which matches &Dma_Ip_pxInit->ppxLogicChannelConfigArray[255]. I then modified the value at address 0x429F28 to 0x1FFFFFF0, and executed the code at line 348. A hard fault occurred, and the BFAR value was 0x1FFFFFF6, as expected. This confirms that the out‑of‑bounds access does exist. Whether a hard fault occurs depends on the value at Dma_Ip_pxInit->ppxLogicChannelConfigArray[255]. Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent The picture in the last reply is not clear. I have uploaded the picture again in the form of attachment. I numbered the order of the pictures with numbers. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent Thank you very much for your reply. I have registered a new account using my company email address, and I will use that account after this thread is closed. I ran your project and found that no hard fault occurred. However, my question still remains. As shown in the screenshot below, the function Adc_Ipw_SetupTcdSingleAdcChannelMajorLink configures the DMA_IP_CH_SET_MAJORLOOP_LOGIC_LINK_CH parameter for the DMA channel. When Dma_Ip_ConvertLogicChToHwCh is called, the LogicCh value is 255. Dma_Ip_pxInit->ppxLogicChannelConfigArray points to the Dma_Ip_paxLogicChannelConfigArrayPB array, which has a size of 2. Accessing Dma_Ip_pxInit->ppxLogicChannelConfigArray[255] should be an out‑of‑bounds access. Although no hard fault occurred, I believe this is not reasonable. This out‑of‑bounds access is caused by calling Adc_Ipw_SetupTcdSingleAdcChannelMajorLink, which is another question I have. I have reviewed the relevant content in RTD_ADC_UM.pdf and also checked the driver code. For Optimize DMA Streaming Groups (single channel), the data is transferred directly from the CDR to the user buffer, unlike the multi‑channel case where data is first moved from the CDR to the DmaIntermediateBuffer and then from there to the user buffer. Optimize DMA Streaming Groups (single channel) does not use a Streaming DMA channel. In the configuration file, the values of AdcIpwConfigPtr->Mapping.AdcCountingDmaChanLogicId array are indeed ADC_IPW_INVALID_DMA_CHANNEL_ID (255). I do not understand why Adc_Ipw_SetupTcdSingleAdcChannelMajorLink still needs to be called. The function that really should call this is Without Interrupt Group (single channel), but when ADC_ENABLE_GROUP_STREAMING_RESULTS_RORDER or ADC_OPTIMIZE_DMA_STREAMING_GROUPS is STD_ON, instead of STD_ON == GroupPtr ->AdcWithoutInterrupt, the Adc_Ipw_SetupTcdSingleAdcChannelMajorLink function is called. I have found the issue in my project: when I uncheck "Data sections", the hard fault no longer occurs. However, I do not think this is the key point of the problem. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason07 @Jason22 Please set the optimization build option to -O0 . This is the result I observed during single-step debugging. This is likely because the build optimization (-Os) prevents the debugger from accurately mapping source code variables. Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent Yes, I used your project without any modifications. In your video, the Dma_Ip_ConvertLogicChToHwCh function is called indirectly by Mcl_Init, which is not the intended behavior. The intended behavior is for Adc_Ipw_SetupTcdSingleAdcChannelMajorLink to indirectly call Dma_Ip_ConvertLogicChToHwCh. My video demonstrates this: while running Mcl_Init, I skipped all breakpoints, and after Mcl_Init completed, I re‑enabled the breakpoints. At that point, Dma_Ip_ConvertLogicChToHwCh was entered again, and LogicCh was 255. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 These are my test results. If you are using the project I provided and the optimization level is set to -O0, then our observations should be the same. I don't think there's anything wrong here. If the boundary is exceeded, it should definitely enter a hard fault, but the test results didn't, which can only mean that it's due to the compilation optimization level. There's no need to continue analyzing under an error condition. Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent I'm glad you can see that LogicCh is 255. In your project, it does run correctly, but this is an out‑of‑bounds access, right? Regarding your statement: "If the boundary is exceeded, it should definitely enter a hard fault" – I don't fully agree with that. In C language, there is no runtime boundary checking like in C++. For a pointer array, whether a hard fault occurs depends on the value obtained from the out‑of‑bounds access. Consider a pointer array: uint32* pArr[2] = {0x20400000, 0x20400004}. Suppose the address of pArr is 0x204300A0, then the value of pArr[2] is the value is stored at address 0x204300A8. If 0x204300A8 contains 0x20400008, then *pArr[2] (an out‑of‑bounds access that ultimately reads the value at address 0x20400008) will not cause a hard fault. However, if 0x204300A8 contains 0x1FFFFFF0, then *pArr[2] (which ultimately reads from 0x1FFFFFF0) will cause a hard fault. Both are out‑of‑bounds accesses, but whether a hard fault occurs is a matter of probability. To be precise, the hard fault is not directly caused by the out‑of‑bounds access itself, but rather because the out‑of‑bounds access to the pointer array got an invalid pointer, and accessing that invalid pointer triggers the hard fault. This is exactly why, in your project, accessing Dma_Ip_pxInit->ppxLogicChannelConfigArray[255]->LogicChId.HwChId does not cause a hard fault, but in my project, it does. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 I will send you the design team's feedback. Usually, if it's a bug with significant impact, they will release it in a new version and include it in the release notes.  Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent Thank you very much for reporting this issue to your design team. If there is a final result, where should I check for it? If there is indeed an error, will it be published in a document similar to SW32K3_S32M27x_RTD_R23-11_7.0.0_D2511_ReleaseNotes.pdf? BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent Sorry. Step4 is Click the ‘Step Over’ button. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Senlent I'm not sure if my operation was correct – I tried debugging with your ELF file but it didn't work. Could you please perform the same steps as shown in my video? I believe you will be able to reproduce the issue. Here are the steps: Set a breakpoint at the line Mcl_Init(NULL_PTR);. Run the program until it hits the breakpoint at Mcl_Init(NULL_PTR);. Disable all breakpoints (Click the ‘skip all breakpoints’ button). Step over Mcl_Init(NULL_PTR);(Click the ‘Step All’ button) Re‑enable breakpoints(Click the ‘skip all breakpoints’ button) and Click the ‘resume’ button. You will see that Dma_Ip_ConvertLogicChToHwCh is entered again, and LogicCh is 255. BR, Jason Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 I can forward this issue to the design team for confirmation. Since I wasn't the one who designed the RTD driver, I won't delve into why they designed it this way unless users encounter problems. This feedback process might be lengthy, but I will relay the findings to the relevant design team. Re: S32K3 ADC Optimize DMA Streaming Hi@Jason22 I might still not understand your question. I'd like to ask if this project is running as expected? If it is, is there any problem? I can see LogicCh is showing 255, but the program is running normally. Is there anything wrong with this?
記事全体を表示
Error reporting module MCU: S32K148 in 144 pin package RTD version: SW32K1_S32M24x_RTD_4.4_3.0.0_QLP03_D2507 S32 DS Version: 3.6.6 Target OS: Bare Metal Host OS: Windows With the above, I cannot find a module called "ERM" (or anything similar) in the driver module. I have looked in both both MCAL and Non-MCAL modules. Is the ERM supported as a driver module or should the user manipulate raw pointers, as it used to be with the older 'Processor Expert' based framework? Re: Error reporting module Hello @VaneB  Thank you for the follow up. So what you are saying is that these modules are supported in the SPD drivers only and not the freely available RTD. Is that right? Is there any reason why someone cannot use these modules just by bit-banging the registers of the module directly? I tried an example for the 'Processor Expert' driver model (using S32 DS v2.2) and it seemed to work. Re: Error reporting module Hi @durga_choudhury  For S32K1 devices, the Safety Peripheral Drivers (SPD) are available. These drivers include the Extended Microcontroller Error Manager (eMCEM), which supports memory error injection and detection through the Error Injection Module (EIM) and Error Reporting Module (ERM) hardware modules. For further information regarding the SPD, please contact your NXP representative or one of our authorized distributors in your region (Distributor Network | NXP Semiconductors). BR, VaneB Re: Error reporting module Hi @durga_choudhury  Yes, your understanding is correct. They are provided as a separate software package and is not included as part of the RTD. Regarding the reason for this separation, I am currently reviewing internaly. However, it is important to note that SAF and SPD were developed as safety-oriented software components in compliance with the ISO 26262 functional safety standard. This enables their integration into applications requiring functional safety support up to ASIL D. Re: Error reporting module Thank you very much for the update.
記事全体を表示
新舊硬件版號差別 同樣 ringo 版本,為什麼 左邊是舊的 版號 332 可以使用,右邊新的 B222 不能使用,332/B222 區別 怎麼樣 B222可以正常使用
記事全体を表示
RW612 WiFi Init stuck on HAL_ImuLinkIsUp() I am trying to run the MQTT example on a custom board. The module used is ublox IRIS-W106-30B. I followed the instructions to use j-link to install the wifi fw blob serperatly. However, I am getting stuck in an infinite loop in WPL_Init().   I was also unable to initialize the BLE due to similar issue. SDK 25.09.00 using MCUXpresso  Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Yes, I am able to run my normal application code, log to UART etc.  Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Hi, Are you able to test a simple Hello World example? Also, have you already applied the required modifications to enable your module? Please refer to the following article for guidance. Regards, Daniel. Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Are you using the RD-RW61X-BGA SDK or the FRDM-RW612 SDK? Which files did you modify to port the original example to your module? Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() If I'm understanding correctly, you're able to run the Wi-Fi and Bluetooth examples on your custom board without any issues. The problem appears when you start integrating or porting the networking functionality into your own application. My recommendation is to use the MQTT example as the foundation for your application. If your use case requires Wi-Fi and BT/BLE to run simultaneously, then it would be better to start from one of the coexistence examples and add your application-specific functionality on top of it, rather than trying to add coexistence support to an existing custom application afterward. By the way, SDK 25.09 is already three releases behind. I would recommend upgrading to the latest SDK 26.06 before continuing. Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() SDK_2.x_RW610 From the mqtt example I copied everything from "main_task" and after into my existing project. This leave the hardware init, as a major difference. I am unable to identify which aspects from the example are causing IMU to not initialize.  I can run the base example project on my custom board but am unable to port it into existing project. 
記事全体を表示
Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello. I am currently developing based on the MPC5777C MCU. I have a question regarding the development process. I designed code to perform ECC checks based on the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code. Under normal circumstances, this code performs the ECC checks correctly. However, when running the ECC check code with a debugger like Trace32 connected to the MCU, errors often occur where bit errors are not detected. Is it possible that the "GHS614" example code as a whole does not function correctly when connected to a debugger such as Trace32? Thank you. Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello. Assuming the Trace32 debugger is connected and the dump window is open, and my custom application code is running, is it possible for a case to occur where a bit error is not detected within the ECC check function, which was designed referencing GHS614? Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello, I am not sure what your setup is, but have in mind that any open dump window in the Trace is constantly reading the memory and will rise the ECC fault immediately if detected. ECC errors will never happen on the not corrupted address. As ECC mechanism is also guarded by EDC. Such is simply not possible. Best regards, Peter Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello, If the address which is read by SW or by debugger is corrupted ECC will always rise indepenant of example SW, or any other influences. best regards, Peter Re: Regarding the "MPC5777C-1b+2b_RAM_ECC_error_injection GHS614" example code Hello. I will explain the situation in a little more detail. My ECC check code execution is as follows: (void)FCCU_ClearNCF(); /* 1-bit RAM data Error Injection */ GenerateRam1bitEccError(); uiErmSR0 = ERM.SR0.R; uiErmSR1 = ERM.SR1.R; uiErmSR2 = ERM.SR2.R; /// 4. If a RAM 1-bit ECC Error occurs, perform the following. if((((uiErmSR0 & ERM_SR0_1b_all) == ERM_SR0_1b_PRAMC_1) || ((uiErmSR2 & ERM_SR2_1b_all) == ERM_SR2_1b_Core1_data)) && ((uiErmSR1) == CLEAR)) { /// 4.1. If the value stored in the ERM EAR Register is the same as the address where the error occurred, perform the following. if((UINT32)auiTest == (ERM.ERROR[ERM_chnl_PRAMC_1].EAR.R)) { ucStatus = OK; } /// 4.2. If the value stored in the ERM EAR Register is not the same as the address where the error occurred, perform the following. else if((UINT32)auiTest == (ERM.ERROR[ERM_chnl_Core1_data].EAR.R)) { ucStatus = OK; } else { ucStatus = NOT_OK }; } /// 5. If no RAM 1-bit ECC Error occurred, perform the following. else { ucStatus = NOT_OK }; This structure forcibly injects a 1-bit RAM Data Error and checks whether the ECC error occurred successfully and the address of occurrence was accurately detected. If the Trace32 memory dump window is enabled while the above code is running, could the results of the ECC check be executed abnormally? (i.e., failure to detect ECC error or an error at the ECC occurrence address) Thank you.
記事全体を表示
S32DS ARM 2018 R1 许可证延期申请 你好我的许可证已经过期,因此我想申请延期。 Re: S32DS ARM 2018 R1 许可证延期申请 谢谢
記事全体を表示
Not able to Download S32K3 Standard Software Not able to download  Re: Not able to Download S32K3 Standard Software Hello, I have just download it with no issues. Try different browse, clear cookies, etc... Download itself is working properly on NXP side. Best regards, Peter
記事全体を表示
LPC5514JBD64E Use for WS2812. Hi, Is LPC5514JBD64E suitable for working with WS2812 for a beginner. If yes Where Can I get The Code and other Details.  Thank you. LPC55xx Re: LPC5514JBD64E Use for WS2812. hi @Kishore02  Thank you for your post! There is not information about the implementation of WS2812 for the LPC551x, you could use the Programmable Logic Unit to do it, in another devices there are example using the FlexIO modules like in application code hub for the MCXA366: https://mcuxpresso.nxp.com/appcodehub?search=an-emulating-ws2812-bus-with-flexio-on-mcx366  Also, there is a post of a colleague that implement it for a Kinetis board: NXP FlexIO Generator for the WS2812B LED Stripe Protocol Hope this information help as a reference 
記事全体を表示
Deep Sleep Mode of iMX937 I am using iMX95lpddr5 evk, triggered the deep sleep mode want to know about the state, clock frequency and power consumption of suspended and non suspended cores among A55, M7 and M33. Re: Deep Sleep Mode of iMX937 On i.MX95 LPDDR5 EVK, “deep sleep” maps to the i.MX 95 Suspend / DSM-style low-power cases . The A55 is suspended/power-gated; M33 is not running application workload, typically shown as clock-gated/idle ; M7 depends on whether you suspend it too or keep it as the wake/real-time core. The power numbers in AN14449 are SoC rail/group totals , not per-core power. Low-power case Cortex-A55 state / freq Cortex-M33 state / freq Cortex-M7 state / freq DDR state Reported power System in DSM Suspend; clock not detectable Clock gating; clock not detectable Suspend; clock not provided Retention 25.65 mW GROUP_SOC_FULL total  Linux Suspend + CM7 WFI Suspend / 0 Clock gating or idle / 0 WFI / 400 MHz Retention 178.48 mW GROUP_SOC_FULL total  Linux Suspend + CM7 CoreMark (TCM) Suspend / 0 Clock gating or idle / 0 CoreMark / 400 MHz Retention 197.24 mW GROUP_SOC_FULL total  Linux Suspend + CM7 FlexCAN transaction Suspend / 0 Clock gating or idle / 0 FlexCAN / 800 MHz Active, 6400 MT/s 659.71 mW GROUP_SOC_FULL total  Linux Suspend + CM7 NETC / Ethernet Suspend / 0 Clock gating or idle / 0 NETC / 800 MHz Active, 6400 MT/s 956.17 mW GROUP_SOC_FULL total  Linux Suspend + WoL A55 suspended M33 idle/low-power context wake-capable configuration; exact core table not in the retrieved chunk depends on WoL setup 342.72 mW GROUP_SOC_FULL total  A few interpretation notes: The i.MX 95 Reference Manual describes Suspend as the maximum-power-saving mode where unnecessary clocks/supplies are off, the Cortex-A55 CPU is fully power-gated, PHYs that can be powered down are off, and VDD_SOC is reduced to suspend voltage. In System in DSM , AN14449 explicitly says the usage is CA55=Suspend, CM33=Clock gating, CM7=Suspend, DDR=Retention , and also notes that because CA55 and CM33 are not working, clocks cannot be detected. For Linux suspend with M7 kept active, the non-suspended core is CM7 ; its clock is either 400 MHz for WFI/CoreMark retention cases or 800 MHz for FlexCAN/NETC cases, while A55 and M33 show 0 MHz in the case tables. The published power data is not isolated per A55/M7/M33 core . AN14449 reports rail/group measurements such as GROUP_SOC_FULL and GROUP_DRAM; for example, DSM reports vdd_arm as 0 mW and vdd_soc as 3.85 mW within a GROUP_SOC_FULL sum of 25.65 mW, but that is still rail-level, not individual-core power. Takeaway: if M7 is also suspended, DSM is about 25.65 mW; if M7 stays alive during Linux suspend, total SoC power rises from about 178–197 mW at 400 MHz to about 660–956 mW at 800 MHz depending on the peripheral workload. Re: Deep Sleep Mode of iMX937 For I.Mx95, there are several power mode including RUN mode, Lower power RUN mode, IDLE mode, SUSPEND mode and Battery Backed Secure Module mode. For detailed power consumption data, please refer to IMX95AEC datasheet. For i.Mx937, the device is at preproduction phase and only factsheet is available right now. Not sure about how the test data come from and what the deep sleep mode you refer to...
記事全体を表示
关于GUI Guider v2.0.0的UI编辑器Bug反馈 我在使用GUI Guider v[你的版本号]时,遇到了几个影响开发效率的Bug,想向开发团队反馈一下: 拖动布局导致布局丢失:当我在UI编辑器中拖动控件进行布局调整时,操作偶尔会失败,并且最新的布局改动会丢失,界面回退到之前的状态。 控件名称重复且无法删除:在操作过程中,有时会出现多个控件名称一致的情况,并且这些控件无法通过右键菜单或Delete键删除。唯一能解决的办法是重新登录软件,这些“幽灵”控件才会消失。 Re: 关于GUI Guider v2.0.0的UI编辑器Bug反馈 您好@CN10086 非常感谢您分享这些反馈意见。 如果您能提供更多详细信息,例如屏幕截图、视频或重现步骤,我们将不胜感激。 BR 哈里
記事全体を表示
CodeWarrior for LA1224 plugin Hello,  I am currently In the middle of evaluating LA1224-RDB and I have some questions regarding the software environment. As I understand I can have a Linux app running on the existing NxP image on LX2160A for evaluation purposes. Furthermore I suppose LA1224 is running baremetal with freertos. I saw that I can have firmware for LA1224 in a Linux directory on the LX2160A. Is this given from NxP? What does it support? I suppose that if I want to develop something further than the given firmware I have to get a codewarrior license and TAP. I have downloaded CW_ARMv8_v2020.06_b200629GA_Win_Setup.exe however the LP1224 is not available. After searching the NxP site I read that I need an extra toolchain on top of CW_ARMv8. What is the full url to download the add on?  I read CodeWarrior for LA1224 and only a partial url is given "com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip" Any further information on how to work on those processors is welcome. Kind Regards N. Alexopoulos Re: CodeWarrior for LA1224 plugin Please download pack com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip from the following link. https://support.nxp.com/s/case/500Te00000eF7lOIAS/community-codewarrior-for-la1224-plugin?language=en_US Please prepare a clean installation environment. Please install CW_ARMv8_v2020.06_b200629GA_Win_Offline.exe first. Then open CodeWarrior IDE in a new worksapce path. Then install the service pack com.freescale.armv8.11.5.15.E200.INT.Win.updatesite.230810 1.zip from Help->Install New Software->Add->Archive in CodeWarrior IDE.
記事全体を表示
Display resolution setup on imx8qm with AAOS 15 Hi Team, We are using AAOS 15.0.0_2.1.0 on i.MX8QM MEK. After flashing the board, the physical displays resolution is always set to 1024x600, while we want the display to run at 1920x1080. And we have multi display setup which has android main default display and passenger display. We verified that 1920x1080 is available in the supported display modes, but the active display mode after boot remains 1024x600. We also tried setting the preferred display mode to 1920x1080 from Android, but after reboot the display still comes up in 1024x600. Could you please advise: What determines the default physical display resolution during boot? How can we force the physical display resolution to 1920x1080@60Hz after boot? Is there any configuration required for ro.boot.displaymode, Display HAL, HWC3, or DRM to make 1920x1080 the default active mode? Any guidance would be appreciated. Re: Display resolution setup on imx8qm with AAOS 15 Hello, Please refer to the Android Automotive documentation we have available here: https://www.nxp.com/docs/en/user-guide/UG10176.pdf Especifically have a look to the chapter 8.3.4 Configuring the primary display resolution of the document above. Best regards/Saludos, Aldo.
記事全体を表示