[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 Harry_Zhang_2-1786007232854.png 5. and west flash 6. Harry_Zhang_0-1786007007588.png 7. Harry_Zhang_1-1786007044209.png which confirms that the UART transport, SMP server, MCUmgr, and MCUboot integration are all working correctly. BR Harry

lx2080(yocto image and debug) i need information regarding how to configure lx2080a nxp image build using yocto and if we want use custom bord  then how to make changes Re: lx2080(yocto image and debug) Layerscape Yocto BSP v26.06: The release includes both source code and prebuilt images as listed below: Source Release files are on https://github.com/nxp-qoriq/yocto-sdk/tree/walnascar-lsdk Branch: walnascar-lsdk Linux BSP Supported boards, Features, Known Issues, please refer to Release Notes Layerscape Software Development Kit User Guide for Yocto: UG10374.pdf Layerscape Linux SDK User Guide: UG10381.pdf Please modify RCW, u-boot, ATF and Linux dts for your custom board, and rebuild images. Porting steps: Modify rcw and rebuild rcw: $ bitbake rcw -c patch -f Go rcw source code folder build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/rcw/git/git/lx2160ardb_rev2/, please modify XGGFF_PP_HHHH_RR_19_5_2/rcw_2200_750_3200_19_5_2.rcw according to your custom board. $ bitbake rcw Modify and rebuild u-boot: $ bitbake u-boot -c patch -f Please go to u-boot source code folder build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/*/git/, modify u-boot source code according to your custom board. $ bitbake u-boot Modify and rebuild atf: $ bitbake qoriq-atf -c patch -f Please go to atf source code folder build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/qoriq-atf/*/git/, please modify atf source code according to your custom board. $ bitbake qoriq-atf Modify Linux dts file and rebuild Linux Kernel: $ bitbake virtual/kernel -c patch -f Please go to Linux Kernel folder build_lx2160ardb-rev2/tmp/work/ lx2160ardb_rev2-fsl-linux /linux-qoriq/*/git, please modify dts file arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts according to custom board. $ bitbake virtual/kernel Re: lx2080(yocto image and debug) for lx2080a  yocto (linux 24.04)image building(rcw->tfa->uboot-linux path) and flashing image via sd card or emmc or norflash   . code warrire tap jtag debugger can we use. 

IMX95 failed to reparent can1 I tried to enable can1 my device tree pin is follow imx95 evk, and disable  &micfil IMX95_PAD_PDM_CLK__AONMIX_TOP_CAN1_TX  0x39e IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_CAN1_RX  0x39e , but the following error occurred.  [ 9.968941] CAN device driver interface [ 9.976800] scmi-pinctrl-imx scmi_dev.8: Error set config -13 [ 9.976814] scmi-pinctrl-imx scmi_dev.8: pin_config_set op failed for pin 121 [ 9.976893] clk: failed to reparent can1 to syspll1_pfd1_di: -1 [ 9.978973] Internal error: synchronous external abort: 0000000096000010 [#1] SMP [ 9.978986] Modules linked in: flexcan(+) can_dev neoisp(+) at24 rpmsg_ctrl rpmsg_char pwm_fan enetc4_uio(O) fsl_ecat_enetc4 fsl_ecat_enetc_core moal(O) mlan(O) fuse [ 9.979017] CPU: 5 UID: 0 PID: 357 Comm: (udev-worker) Tainted: G M O 6.18.2-rt3-1.0.0-1.0.0 #1 PREEMPT_RT [ 9.979026] Tainted: [M]=MACHINE_CHECK, [O]=OOT_MODULE [ 9.979028] Hardware name: Axiomtek i.MX95 scm136 board (DT) [ 9.979031] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 9.979035] pc : flexcan_read_le+0x0/0x20 [flexcan] [ 9.979060] lr : flexcan_probe+0x454/0x834 [flexcan] [ 9.979067] sp : ffff800086133820 [ 9.979069] x29: ffff800086133850 x28: ffff8000862b0000 x27: ffff000085a182a0 Does anyone know how to fix this? Re: IMX95 failed to reparent can1 Hi,Zhiming_Liu Thank you for the reply. you are right ,I need to change system manager config. Re: IMX95 failed to reparent can1 Hi @HenryHsu  Here is my previous test on i.MX95 EVK, please check your dts with below modifications.   dts modification:     Zhiming_Liu_2-1785995739657.png diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts index ab7bd4fdaadf..5eb3011f0894 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts @@ -380,7 +380,7 @@ &flexcan1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_flexcan1>; xceiver-supply = <&reg_can1_stby>; - status = "disabled"; + status = "okay"; }; &flexcan2 { @@ -623,23 +623,23 @@ spidev0: spi@0 { }; }; -&micfil { - #sound-dai-cells = <0>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&pinctrl_pdm>; - pinctrl-1 = <&pinctrl_pdm_sleep>; - assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>, - <&scmi_clk IMX95_CLK_AUDIOPLL2>, - <&scmi_clk IMX95_CLK_PDM>; - assigned-clock-parents = <0>, <0>, <0>, <0>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>; - assigned-clock-rates = <3932160000>, - <3612672000>, <393216000>, - <361267200>, <49152000>; - status = "okay"; -}; +// &micfil { +// #sound-dai-cells = <0>; +// pinctrl-names = "default", "sleep"; +// pinctrl-0 = <&pinctrl_pdm>; +// pinctrl-1 = <&pinctrl_pdm_sleep>; +// assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2>, +// <&scmi_clk IMX95_CLK_PDM>; +// assigned-clock-parents = <0>, <0>, <0>, <0>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>; +// assigned-clock-rates = <3932160000>, +// <3612672000>, <393216000>, +// <361267200>, <49152000>; +// status = "okay"; +// }; &mu7 { status = "okay"; @@ -960,19 +960,19 @@ IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x4000031e >; }; - pinctrl_pdm: pdmgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e - >; - }; + // pinctrl_pdm: pdmgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e + // >; + // }; - pinctrl_pdm_sleep: pdmsleepgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e - >; - }; + // pinctrl_pdm_sleep: pdmsleepgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e + // >; + // }; pinctrl_ptn5110: ptn5110grp { fsl,pins = <     system manager modification: diff --git a/configs/mx95evk.cfg b/configs/mx95evk.cfg index 9250d02..6722097 100755 --- a/configs/mx95evk.cfg +++ b/configs/mx95evk.cfg @@ -389,7 +389,7 @@ SYS ALL # Resources M7P OWNER # CPUs must be first -CAN_FD1 OWNER +// CAN_FD1 OWNER FSB READONLY IRQSTEER_M7 OWNER LPIT1 OWNER @@ -612,6 +612,7 @@ CAMERA5 OWNER CAMERA6 OWNER CAMERA7 OWNER CAMERA8 OWNER +CAN_FD1 OWNER CAN_FD2 OWNER CAN_FD3 OWNER CAN_FD4 OWNER   Result: Zhiming_Liu_3-1785995783165.png  

i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hello, Hardware: - i.MX8MQ (REV A0), custom board based on EVK design - QSPI NOR: Micron MT25QL256A (32MB, 3.3V, Quad connected) - BSP: Yocto Scarthgap, NXP BSP, U-Boot 2024.04 (u-boot-imx) Goal: Boot the bootloader (SPL + ATF + U-Boot) from FlexSPI NOR flash. Kernel and rootfs remain on eMMC. What works: - U-Boot (loaded to RAM via uuu SDP/SDPV) runs fine - "sf probe" detects the flash correctly: mt25ql256a, 32 MiB - U-Boot can read and write the flash reliably (verified with read-back tests after "sf protect unlock") - Image is built with IMXBOOT_TARGETS = "flash_evk_flexspi" Flash layout (verified by reading back from the chip): 0x000000: FCFB header - "qspihdr check" reports "Found boot config header in Q(F)SPI" tag = 42464346, version = 56010000 0x001000: IVT - d1 00 20 41, entry = 0x007E1000, boot_data = 0x007E0FE0, self = 0x007E0FC0 0x060000: U-Boot proper FIT (d00dfeed), matches CONFIG_SYS_SPI_U_BOOT_OFFS=0x60000 Problem: With boot switches set to QSPI/FlexSPI boot and the USB cable physically disconnected, the board does not boot. Nothing is printed on the serial console (SPL banner never appears), and the ROM falls back to serial download mode: uuu -lsusb 2:1 MX8MQ SDP: 0x1FC9 0x012B NXP FLASH BT_FUSE_SEL is not blown; boot configuration is done via GPIO boot pins. What I have already tried: - Both header formats: scripts/qspi_header (c0ffee01 tag) and scripts/fspi_header (FCFB tag). Fixed soc.mak so that flash_evk_flexspi uses fspi_header with offset 0. - Varying FCFB parameters: sflashA1Size, serialClkFreq (50MHz -> 20MHz), dataSetupTime/dataHoldTime, sflashPadType - "uuu -b qspi" (the official built-in script) - "qspihdr update safe" and "qspihdr init safe" - Erasing the flash completely vs. writing the full image: boot behaviour is essentially identical (SDP appears after ~1.6s vs ~1.8s), which suggests the ROM may not be reading the flash at all. Questions: 1. Does the i.MX8MQ Boot ROM support booting from serial NOR flash over FlexSPI at all? The Reference Manual section I have lists NAND flash and SD/MMC as boot devices, but I could not find FlexSPI/QSPI NOR listed. i.MX8MM/8MN documentation seems to describe it, but I am unsure about 8MQ. 2. If it is supported, what is the exact expected flash layout? Should the IVT be at offset 0x400 or 0x1000 when an FCFB is present at 0x0? 3. What is the correct BOOT_MODE / BOOT_CFG combination to select FlexSPI NOR boot on i.MX8MQ? 4. Are there any known errata for REV A0 silicon regarding FlexSPI boot? Thank you. Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hello, I'm working on a similar task.  Some sections on the same document mentions some boot options using SPI. Would you like to elaborate further please? onurgoksu_0-1785737312799.png onurgoksu_1-1785737654143.png Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Is there absolutely no way to boot the i.MX8MQ from QSPI NOR Flash while keeping the Linux kernel and root filesystem on eMMC? Our hardware design has already been built around this architecture, so it is very important for us. Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hi, Please refer primarily to the information in the RM; the i.MX8MQ does not support QSPI boot. Zhiming_Liu_0-1785725904605.png Best Regards, Zhiming Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Dear NXP Technical Support Team, We would like to raise a serious concern regarding the documentation of QSPI boot support for the i.MX8MQ. Engineers rely on the Reference Manual as the primary and authoritative source when making hardware design decisions. When a boot source is listed or implied as supported in the Reference Manual, it is entirely reasonable for a development team to design the board around that information. This is not a minor typographical mistake. Boot-source selection directly affects schematic design, PCB layout, component selection, manufacturing, firmware architecture, recovery strategy, and product validation. An incorrect statement regarding QSPI boot capability can therefore result in significant engineering time loss, additional prototype revisions, delayed schedules, and substantial financial cost. It is especially concerning that similar questions and feedback appear to have been raised in the NXP community since approximately 2017–2018, while the documentation has apparently remained unclear or incorrect for many years. If NXP has known that the i.MX8MQ Boot ROM does not support direct boot from QSPI, this limitation should have been clearly stated in the Reference Manual, device errata, application notes, and product documentation. Leaving such a critical ambiguity unresolved for years is unacceptable for a component used in professional and commercial hardware designs. Customers must be able to trust the information provided in the official Reference Manual. We therefore request a clear and formal response to the following points: Does the i.MX8MQ Boot ROM support direct boot from QSPI NOR after power-on reset? If it does not, why was QSPI presented or implied as a supported boot option in the Reference Manual? Has NXP officially classified this as a documentation error? In which document revision will this information be corrected? Will NXP publish an erratum or product notice to warn customers who may have designed hardware based on the existing documentation? Is there any officially supported workaround that allows the Boot ROM to load the initial boot image directly from QSPI without requiring SD or eMMC? We strongly believe this issue requires more than an informal forum response. A formal documentation correction and an explicit technical notice are necessary to prevent other engineering teams from experiencing the same time and financial losses. Please escalate this matter to the i.MX8MQ product engineering and documentation teams and provide an authoritative written clarification. Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hello @Zhiming_Liu, @ayse-yilmaz  I've found the following topic related to this very problem: https://community.nxp.com/t5/i-MX-Processors/Does-i-MX8M-support-boot-from-QSPI/m-p/904429#M136467 But as a solution, tech support mentioned "for development purposes, the eFUSEs used to determine the boot device may be overridden using the GPIO pin inputs" but boot ROM does not support it anyway. I'm a bit confused here. Why even though the HW supports it, boot ROM doesn't? I guess it's impossible to boot from QuadSPI despite of the HW and the documents, due to ROM. Is my understanding right? Please kindly elaborate.  Thx, Onur Regards Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hi @ayse-yilmaz @onur-goksu  Issues with the documentation in Chapter 6  SNVS, Reset, Fuse, and Boot were already reported in 2018, and NXP corrected the relevant documentation on its official website.  For the supported boot device, should refer the 6.1 System boot. About 1.6 Primary Boot Options, it looks like a document residue. Best Regards, Zhiming

S32K1 Complementary PWM Hi，NXP experts We used the S32K142 chip in the air conditioning compressor project of Nissan. However, Nissan requested to know how the FTM of the chip ensures the achievement of complementary PWM output. Therefore, they would like to ask for assistance in providing explanations and supporting materials, or test reports for the verification of this function. Thank you. Chenxu1_0-1785987344020.png Re: S32K1 Complementary PWM Hi@Chenxu1 the chip-level protection is mainly architectural: one channel defines the PWM timing, the companion channel is produced by internal complement logic, and optional dead-time/synchronized-update hardware preserves non-overlap and coherent updates. S32K-RM Rev14.1: Senlent_0-1785999338085.png Re: S32K1 Complementary PWM Hi, Senlent, Tkx for your reply. We are clear about how FTM outputs complementary PWM. At the chip level, how does it ensure that the complementary waveforms are not out of position? This is what our customers are interested in knowing. Re: S32K1 Complementary PWM Hi@Chenxu1 It can read and test AN5303 and its provided bare-metal code. https://www.nxp.com/docs/en/application-note/AN5303.pdf Senlent_0-1785997622463.png These are some steps I recorded during my previous testing, for your reference. I set up complementary PWM mode and inserted a 2µs dead time (I forgot to save the complete project, but the modification is very simple). Senlent_3-1785997707326.png Senlent_1-1785997665931.png Senlent_2-1785997677611.png

EasyEVSE signal board compatibility and availability I’m standing up an EasyEVSE development system and I have a few questions.   From the code revision history (and the 6 May 2026  vs. Dec 2025 versions of CCEVCPGSUG.pdf), it looks it looks like in software version 5.1.2  that support for EVSE-SIG-BRD2X has been removed and the expectation is that the EVSE side will use SIGBRD-HPGP instead.  Is this correct? It looks like software v5.1.2 added much of the support for SIGBRD-HPGP, does the previous version (v5.0.8) still support EVSE-SIG-BRD2X? Is the SIGBRD-HPGP available?  I don’t see it at mouser or digikey, or in NXP’s store. I have two of the EVSE-SIG-BRD2Xs and I’d like to move forward as the SIGBRD-HPGP appears to not be an option right now. Any insights would be appreciated Best Regards,               Chris Re: EasyEVSE signal board compatibility and availability Hi @chrisedwards, As you mention, the updated EVSE platform is designed to leverage the SIGBRD-HPGP on the EVSE side. Currently, the EV side still supports EVSE-SIG-BRD2X, although it can also be implemented using SIGBRD-HPGP. However, considering that you already have both EVSE-SIG-BRD2Xs, and that the SIGBRD-HPGP is still under qualification process (and will likely take some more time for it to be available for the public), I recommend you stick to this setup, and consider the use of a previous SW version before this latest modification. You should be able to use v5.0.8 for support with the two EVSE-SIG-BRD2X setup. BR, Edwin. Re: EasyEVSE signal board compatibility and availability Hi Edwin,  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 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 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 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

Flashing Issue on IMX95EVK's M7 core Hello, I am trying to run an M7 application on IMX95LPD5EVK-19 following AN14748, but I cannot flash flash.bin with UUU. The board is detected briefly, then SDPS boot fails immediately. Hardware: IMX95LPD5BB-19 REV A1 (2024 NXP B.V.) Boot switch (SW7[1:4]): 1001 (Serial Download) Target: eMMC Host: Ubuntu Linux UUU: libuuu_1.5.243-0-g230f1b1 SDKs tried (MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 Both produce the same result. Command: cd IMX95LPD5EVK/build_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo uuu -b emmc flash.bin   Error: Success 0 Failure 1 1:2-E3C50910 1/ 1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -f flash.bin   Steps followed (per AN14748): Set SW7 = 1001 with board powered off Connect USB to host Run sudo uuu -b emmc flash.bin Power-cycle board Fails at SDPS boot every time Please share the steps to flash and the BSP version supported for M7 core for this version of the board. Re: Flashing Issue on IMX95EVK's M7 core Hello, The latest supported BSP for A1 revision is Linux 6.12.20. Also, you could try to build the the whole binary from scratch (Uboot+SPL+ATF+Firmware+M-SDK). #### Download and extract ARM GCC toolchain #### $ sudo tar -xvJf arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt #### Get NXP code necessary for the i.MX95 #### In your case be careful with the latest supported BSP version.  $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-sm -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-oei -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.18.2-1.0.0 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.5-29313e0.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.31-4fa5b46.bin #### Build Uboot #### $ cd uboot-imx $ make -j $(nproc --all) clean $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- imx95_19x19_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build ATF #### $ cd .. $ cd imx-atf $ make -j $(nproc --all) PLAT=imx95 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build SM #### $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk cfg (optional if the associated mx95evk.cfg file has been changed) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk all (Linux+M7) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95alt all (config for MCUXpresso testing) #### Build OEI #### $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=ddr DEBUG=1 $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=tcm DEBUG=1 (for i.MX 95 A1 only) #### Extract Firmware #### $ cd .. $ chmod +x firmware-ele-imx-2.0.5-29313e0.bin $ ./firmware-ele-imx-2.0.5-29313e0.bin --auto-accept $ chmod +x firmware-imx-8.31-4fa5b46.bin $ ./firmware-imx-8.31-4fa5b46.bin --auto-accept #### M7 SDK compilation #### $ unzip SDK_25_12_00_IMX95LPD5EVK-19.zip $ python3 -m venv .venv $ source .venv/bin/activate $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi $ pip install west $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config release -b imx95lpd5evk19 -Dcore_id=cm7 #### For ITCM #### $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config ddr_release -b imx95lpd5evk19 -Dcore_id=cm7 #### For DDR #### $ exit (this will close the terminal so re-open the terminal) #### Copy the resulting binaries to imx-mkimage #### $ cd imx-mkimage $ cp ../uboot-imx/u-boot.bin ./iMX95 $ cp ../uboot-imx/spl/u-boot-spl.bin ./iMX95 $ cp ../imx-atf/bl31.bin ./iMX95 $ cp ../imx-oei/oei-m33-ddr.bin ./iMX95 $ cp ../imx-sm/m33_image.bin ./iMX95 $ cp ../mcuxsdk/build/hello_world_cm7.bin ./iMX95/m7_image.bin $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_v202409.bin ./iMX95 $ cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 $ make SOC=iMX95 OEI=YES flash_all You may use the resulting binary to flash your EVK, we tested this in standalone mode and it is working correctly. Best regards. Re: Flashing Issue on IMX95EVK's M7 core db16122_0-1785222133220.png if boot from EMMC, SW7-3 should be 1 according to Quick Start Guide IMX95LPD5EVK-19 Re: Flashing Issue on IMX95EVK's M7 core Hello, Thank you for the update. Please try with sudo command. Best regards. Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas  I have followed the exact steps given by you. But there is a same flashing error. It goes till 60% and failed after sometime. Can you please check the below screenshots and let me know whether the commands are right. Thanks, Gaurav Screenshot from 2026-07-31 17-31-12.png Screenshot from 2026-07-31 17-31-20.png Re: Flashing Issue on IMX95EVK's M7 core why there is usb error no device？does it happen at 60% booting process？ Re: Flashing Issue on IMX95EVK's M7 core Hello, I found a new resource that suggest use Linux 6.12.3_1.0.0/SDK25.03.00 for A1 silicon revision, please try again with this software versions. What do you see in Cortex-A console when you see the error log? Best regards. Re: Flashing Issue on IMX95EVK's M7 core And I am working on the lf-6.12 version for all the repos. Switch position for download mode is "1 0 0 1" Can you please also confirm the supported version of M7 SDK? Re: Flashing Issue on IMX95EVK's M7 core can this issue be reproduced as failed at 60% process all the time? Re: Flashing Issue on IMX95EVK's M7 core Hi @db16122 , Thanks for replying. Yes while flashing the firmware it is getting failed gets stuck at 60% for sometime and getting failed after that.  Thanks, Gaurav C. Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas , I have tried with sudo command as well but there is no change and it is still failing. Please check the below screenshot. Thanks, Gaurav C. Screenshot from 2026-08-03 09-14-48.png Re: Flashing Issue on IMX95EVK's M7 core Yes, it is happening everytime. Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas  I have tried with SDK 25.03 and i am only getting some failure logs on /dev/ttyUSB3 while flashing the binary. I have also copied the file like below. cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 Do you think there exists a file for mx95a1-ahab-container.img as well? Please also go through the screenshot, it is showing the SOC IMX95(A0) while I am having A1 revision. Thanks Gaurav Screenshot from 2026-08-05 17-49-46.png Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas  I am able to resolve this issue using document AN14748 and SDK25.03.00  Thanks for your suggestions and valuable time. Thanks, Gaurav

I am Using S32K312 and I want to Create New NVM key Catlog with my HSE Firmware I want to store 1 public key of 64 bytes in NVM key Catlog of HSE, but when I am trying to write into the Catlog I am facing issue as HSE_SRV_RSP_NOT_ALLOWED   (brief The operation is not allowed because of some restrictions (in attributes, life-cycle dependent operations, key-management, etc.).   Can you please guide me what should be done in this case ? Re: I am Using S32K312 and I want to Create New NVM key Catlog with my HSE Firmware Hi @Amolniwate  How you are configuring the key catalog? Also, if you have User rights, plain keys can only be imported authenticated. If you have SuperUser rights, the behavior depends on whether the slot is empty or already programmed: Empty slots: Plain key can be imported , with or without authentication. Non-empty slots: Plain/Encrypted key can only be imported (overwritten) authenticated. You can refer to Tables 47 and 48 in the HSE_B Firmware Reference Manual, Rev. 2.7 for more details. BR, VaneB

i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? Hello NXP Team, we created the SDRAM configuration for our custom i.MX RT1170 based hardware using the MCUXpresso SDK example as a reference: https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/main/_boards/evkbmimxrt1170/demo_apps/shell/shell.mex Our design uses an ISSI IS42S16320F SDRAM connected to the SEMC interface. Unfortunately, we are experiencing occasional system instabilities with this configuration. While reviewing the SDRAM settings in detail, we noticed that Auto-Refresh appears to be disabled in the example configuration: Masmiseim_0-1786008762531.png This surprised us, because according to our understanding the IS42S16320F requires periodic refresh cycles to maintain data integrity, and therefore we would expect Auto-Refresh to be enabled. Could you please clarify the following points? Is it correct that Auto-Refresh is intentionally disabled in the provided SDK example? If so, what is the rationale behind this configuration? Are SDRAM refresh cycles handled elsewhere by the SEMC controller or software initialization code? For an ISSI IS42S16320F on a custom hardware design, would you recommend enabling Auto-Refresh explicitly? Thank you for your support. Best regards, i.MXRT 101x Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? Hello @Masmiseim, The DCD configuration provided in the example is implemented for the SDRAM used on the RT1170-EVKB. As you may know, each SDRAM device has its own timing requirements and initialization parameters, so the SEMC configuration included in the example may not be fully compatible with your specific SDRAM. In this example, the Auto Refresh feature is enabled as part of the final SDRAM initialization sequence. However, during the initialization process itself, the Auto Refresh bit remains disabled and the required refresh operations are performed through SEMC IP commands, as shown in the images below: Habib_MS_4-1786056205833.png Habib_MS_6-1786056292017.png If you would like to customize these settings for your SDRAM, the DCD can be generated using the MCUXpresso Config Tools. This allows you to configure the SDRAM parameters according to your device requirements, as illustrated in the following image:   Habib_MS_7-1786056301151.png On the other hand, there is available an SDK (version 26.06) example called "semc_cm7" which demonstrates how use the SEMC peripheral with an external SDRAM. Finally, in this community post Omar provides an example for configure the SEMC registers that could be useful. BR Habib Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? It's always wise to treat anything you attempt to use from the SDK as just an example and therefore you should check & verify everything.

i.MX8MM eMMC sd3 clk dse en slew rate setting The above mentioned pad control settings are not described in the reference manual. Why and how can we test / trim these settings? Re: i.MX8MM eMMC sd3 clk dse en slew rate setting Hello @NLFOHE  Hope you are doing very well. Actually, that pad is under the register's name: IOMUXC_SW_PAD_CTL_PAD_NAND_WE_B. Manuel_Salas_0-1785352172806.png Mux mode register should be configured as uSDHC3 (IOMUXC_SW_MUX_CTL_PAD_NAND_WE_B): Manuel_Salas_1-1785352244434.png Best regards, Salas. Re: i.MX8MM eMMC sd3 clk dse en slew rate setting Hello Salas, Issue not yet solved due holiday period. Is there any application note how to use SCC on this specific clock signal?

need alternative part number for MRF101AN. I would appreciate if anyone could provide me the alternative part number for MRF101AN.?? And idea on availability for the same for next few years. thank you! Re: need alternative part number for MRF101AN. **MRF101AN Status & Alternatives** ### Current Status **MRF101AN** (NXP) is now in **End-of-Life / Last Time Buy**. | Item | Details | |----------------------------|--------------------------------------| | **Lifecycle** | End of Life (EOL) / Last Time Buy | | **Last Time Buy (LTB)** | **30 September 2026** | | **Last Time Delivery (LTD)** | **30 September 2027** | | **Reason** | NXP is ramping down the Radio Power product line | After September 2026 you will no longer be able to place new orders with NXP. Remaining stock will be allocated on a first-come, first-served basis until the final shipment date in 2027. --- ### Closest Alternatives | Part Number | Manufacturer | Key Differences | Compatibility | Recommendation | |------------------|--------------|------------------------------------------|--------------------------------|--------------| | **MRF101BN** | NXP | Mirror pin-out version of MRF101AN | Same package (TO-220), electrical performance almost identical | Best short-term option if pin-out can be flipped | | **MRF300AN / MRF300BN** | NXP | 300 W version (higher power) | Different package (TO-247) | Only if you need higher power and can redesign | | No official drop-in | — | NXP has **not** released a pin-compatible successor | — | — | **Note**: NXP has not published an official pin-to-pin replacement for the MRF101AN. The **MRF101BN** is the closest device (same electrical characteristics, mirrored pin-out). --- ### Third-party / Competitive Alternatives (not pin-compatible) These require board redesign but are still in active production: - Ampleon BLF188XR / BLF189XRG (higher power, different package) - STMicroelectronics STAC2932B or similar LDMOS devices - Other 50 V LDMOS devices in the 100 W class from Infineon or MACOM (need matching for frequency and power) --- ### Availability Outlook (Next Few Years) | Period | Availability Expectation | |---------------------|----------------------------------------------| | Now – Sep 2026 | Still orderable (Last Time Buy window) | | Oct 2026 – Sep 2027 | Only remaining stock / residual shipments | | After Sep 2027 | No new supply from NXP | **Recommendation**: 1. Place a **Last Time Buy** as soon as possible if you still need this exact part. 2. Start evaluating **MRF101BN** (if pin-out change is acceptable) or begin a redesign to a currently active 50 V LDMOS device. 3. Contact : [email protected]. Would you like me to help compare specific electrical parameters of MRF101AN vs MRF101BN, or suggest possible redesign candidates based on your frequency and power requirements?

The 30 Second Cherry Trick for Better Sleep I've been seeing a lot of people talking about the 30 Second Cherry Trick for Better Sleep, so I decided to look into what it's actually about. From what I found, it isn't presented as a medication or a quick fix. The idea revolves around a simple nighttime habit involving tart cherries and natural sleep support. Some people like it because it's easy to add to an evening routine and doesn't require making major lifestyle changes. Of course, everyone's sleep challenges are different, and what works for one person may not work for another. Good sleep habits, reducing caffeine late in the day, and maintaining a consistent bedtime are still important. If you're curious about what the 30 Second Cherry Trick actually is and why so many people have been discussing it recently, I found a page that explains the concept in more detail. Learn more here: https://health.smartdiscoveryhub.com/ys1/

Assistance Required for Flash Programming S32K344 Using USB Multilink Universal FX in S32 Design Stu Dear NXP Technical Support Team, I hope you are doing well. I am currently working with the FRDM-A-S32K344 evaluation board and using S32 Design Studio (S32DS) for application development. I would like to program and debug the S32K344 MCU using a PEmicro USB Multilink Universal FX debugger through the JTAG/SWD interface. I would appreciate your guidance on the correct configuration and setup for this hardware combination. Specifically, I would like assistance with the following: Software and Driver Requirements Required PEmicro drivers and firmware versions. Any additional S32DS packages or device support that must be installed. Recommended version compatibility between S32DS and the USB Multilink Universal FX. S32 Design Studio Debug Configuration Step-by-step instructions for creating a PEmicro GDB Server debug configuration. Recommended settings for the Main, Debugger, Startup, and Common tabs. Any target-specific configuration required for the S32K344. Hardware Connection Confirmation of the correct JTAG/SWD pin connections between the FRDM-A-S32K344 J9 header and the USB Multilink Universal FX (Port B). Whether any special wiring or signal connections are recommended. Board Configuration Required jumper or switch settings on the FRDM-A-S32K344 board. Any configuration related to the FS26 System Basis Chip (SBC) or watchdog that should be considered to prevent resets during programming and debugging. Reference Documentation Any application notes, user guides, or example projects demonstrating the use of the USB Multilink Universal FX with the S32K344 would be greatly appreciated. For your reference, I have also attached a diagram illustrating the JTAG pin connections between the FRDM-A-S32K344 board and the USB Multilink Universal FX. Thank you for your time and support. I look forward to your guidance. Kind regards, Aravind Togaralli Re: Assistance Required for Flash Programming S32K344 Using USB Multilink Universal FX in S32 Design Hi @Aravind_Togaralli, 1. NXP always recommends using the latest SW release available. Right now, the latest release for S32K3 include: S32 Design Studio IDE 3.6.10 S32K3_S32M27x Real-Time Drivers ASR R23-11 Version 7.0.1 S32DS 3.6.10 includes PEmicro interface debugging support version 6.2.1. 2. When importing an example, or creating a new S32DS application project, the respective debug configuration is generated. You can refer to the examples for the recommended settings, however, most important ones are 'C/C++ Application' path, device & port selected, and GDB Client executable path: Julin_AragnM_1-1786048764074.png Julin_AragnM_0-1786048752996.png 3. Yes, if you wish to debug the FRDM-A-S32K344 with an external debugger, you must use the J9 20-pin Cortex Debug + ETM header. 4. As detailed inside the FRDM-A-S32K344 development board user manual (UM12406), to enable this interface, jumper JP11 (OpenSDA voltage) must be removed. 5. You can refer to HOWTO Build a Project and Setup Debugging with GDB PEMicro Debugging Interface. Or you can refer directly to PEmicro: PEmicro NXP_Automotive S32K3xx Device Support. For any specific function/configuration, you can try contacting PEmicro instead. Best regards, Julián

TJA1153 on S32K344EVB The CAN transceiver on S32K344EVB is TJA1153, It need to do configuration for use as the datasheet said. But I find two phenomenon on my side. 1. I just pull high for both EN pin and STB pin of TJA1153, and it can communicate with partner normally, no need to do configuration. 2. I want to do configuration for it with EN pin high and STB pin low, use CAN ID such as 0x555U/0x18DA00F1 as datasheet said, after execute Can_43_FLEXCAN_Write, do while with Can_43_FLEXCAN_MainFunction_Write, but found CanIf_TxConfirmation never called. At next call for Can_43_FLEXCAN_Write, it returned CAN_BUSY. So what's the reason for the two phenomenon? Re: TJA1153 on S32K344EVB Hi, A few comments regarding the observed behavior: 1. Please first verify that the CAN transceiver on your board is really TJA1153. If a standard transceiver (e.g. TJA1043/TJA1042) is populated instead, no secure configuration sequence is required and normal CAN communication should work immediately.  2. For a genuine TJA1153, the behavior depends on its current state: Vanilla state (factory default): configuration is required before normal operation, and entry to local configuration mode requires STB_N = Low.  Open-config/configured state: the transceiver may already allow normal communication. Reconfiguration can be performed without the initial bitrate detection frame (ID 0x555), by sending the prepared Classical CAN frame with the CONFIG_ID extended identifier at the configured baud rate. This configuration message must be ACKed by another node on the bus. Regarding the second issue, if CanIf_TxConfirmation() is never called and the next Can_43_FLEXCAN_Write() returns CAN_BUSY, it indicates that the TX mailbox has not completed transmission. I would recommend checking the FlexCAN status registers (ESR1, ECR, MB CODE field) to determine whether the frame was actually transmitted and acknowledged. BR, Petr

NPU support on the i.MX95 Verdin EVK Hi, I am trying to run my tflite models on the i.MX95 NPU. The models can be converted, I see the acceleration using the benchmark but the output is not usable at all (always the same for several face detection and face landmark models) I then tried to run the example according to this user guide: https://www.nxp.com/docs/en/user-guide/UG10166.pdf root@imx95-19x19-verdin-47:/usr/bin/tensorflow-lite-2.19.0/examples# ./label_image -m mobilenet_v1_1.0_224_quant.tflite -i grace_hopper.bmp -l labels.txt --external_delegate_path=/usr/lib/libneutron_delegate.so INFO: Loaded model mobilenet_v1_1.0_224_quant.tflite INFO: resolved reporter INFO: EXTERNAL delegate created. INFO: NeutronDelegate delegate: 1 nodes delegated out of 4 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-f24d08e5, zerocp enabled. INFO: Applied EXTERNAL delegate. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. INFO: invoked INFO: average time: 0.37 ms -> as you can see the inference ran fine but there is no classification as mentioned in the user guide to check the actual working of the model. I converted the model using the correct converter version of SDK 2.2.2: NeutronSDK_2.2.2+LF_6.12.49_2.2.0/neutron-converter --input input/mobilenet_v1_1.0_224_quant.tflite --target imx95 --output output/mobilenet_v1_1.0_224_quant.tflite --dump-statistics Performance estimates: Clock Frequency: 0.000000 MHz Clock cycles per inference: 0 Latency per inference: -nan ms Inferences per second: -nan Memory footprint: Variables size: 0.000000 MB Constants size: 0.000000 MB Microcode size: 0.000000 MB Statistics for NeutronGraph "subgraph_030": Operators: Number of Neutron operators = 29 Number of builtin operators = 44 Memory: Inputs = 150,528 (bytes) Microcode = 23,944 (bytes) Weights = 4,329,648 (bytes) Kernels = 11,088 (bytes) Outputs = 381,913 (bytes) Scratch = 380,912 (bytes) (Allocation efficiency: 1) Total data = 913,353 (bytes) (Inputs + Outputs + Scratch) Total weights = 4,364,680 (bytes) (Microcode + Weights + Kernels) Total size = 5,278,033 (bytes) (All) Latency: Cycle estimation = 1,066,681 (cycles) Latency estimation = 1.067 (ms) (@ 1000.000 MHz) Overall statistics for graph "": Operators: Number of operators after import = 31 Number of operators after optimize = 47 Number of operators after extract = 4 Number of Neutron graphs = 1 Number of operators total = 47 Number of operators converted = 44 Number of operators NOT converted = 3 Operator conversion ratio = 44 / 47 = 0.93617 Operators converted = 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44, Memory: Total data = 532,448 (bytes) (Inputs + Outputs + Intermediate Variable Tensors) Total weights = 4,364,688 (bytes) (Weights) Total size = 4,897,136 (bytes) (All) Latency: Cycle estimation = 1,066,681 (cycles) (NPU only) Latency estimation = 1.067 (ms) (@ 1000.000 MHz) (NPU only) Conversion time: Optimization = 2.00387 (seconds) Extraction = 0.0308523 (seconds) Generation = 5.56016 (seconds) Total = 7.59489 (seconds) My hardware and BSP setup: SOC: iMX Verdin EVK SoM V1.0C Carrier: iMX Verdin EVK v1.2A (https://www.toradex.com/de/computer-on-modules/verdin-arm-family/nxp-imx95-evaluation-kit?srsltid=AfmBOookfBHOVzIUBJhrVmtYSV45ohtPJy_f2ymYGR956gzD0XzxS0jP) For the build I am using: MACHINE = "imx95-19x19-verdin" I am using this BSP version: https://www.toradex.com/de/news/bsp-layers-reference-images-walnascar?srsltid=AfmBOoqJF2YHULiIe7sA1L4gPBasmZrepuGIRBLrtcIuFPnz39jctBX6 And the NXP layers: meta-imx rel_imx_6.12.49_2.2.0 with kernel version: 6.12.49-lts-next-g759f4038100f -> My main question is if my silicon revision (A0) is even supported or what could be the issue when running the models fails silently and just produces garbage output: Face detection (UltraFace-Ultraslim, [1,128,128,3] int8/uint8 input) outputs a single fused (172,6) tensor of [bg_score, face_score, xmin, ymin, xmax, ymax] per anchor, already NMS'd and normalized to [0,1] — on CPU this yields one clear high-confidence detection (~0.996) tightly bounding the face, while on NPU all 172 anchors collapse to an identical constant (~0.50 score, near-zero-size box at ~0.227,0.227,0.227,0.227). Face landmarks (NXP facial_landmarks_35, [1,60,60,3] uint8 input) output a [1,70] tensor of 35 interleaved (x,y) points normalized to the face crop — on CPU these form a recognizable face-point pattern when overlaid on the image, while on NPU the entire 70-value output likewise collapses to a single repeated constant instead of varying per point. Yocto Project Re: NPU support on the i.MX95 Verdin EVK output with verbose: root@imx95-19x19-verdin-4798be6ce85542d2:/usr/bin/tensorflow-lite-2.19.0/examples# ./label_image -m demo_converted -i grace_hopper.bmp -l labels.txt --external_delegate_path=/usr/lib/libneutron_delegate.so -v 1 -r 5 INFO: Loaded model demo_converted INFO: resolved reporter INFO: tensors size: 11 INFO: nodes size: 4 INFO: inputs: 1 INFO: input(0) name: input INFO: 0: MobilenetV1/Logits/SpatialSqueeze, 1001, 9, 0.166099, -62 INFO: 1: MobilenetV1/Predictions/Reshape_1, 1001, 3, 0.00390625, 0 INFO: 2: input, 150528, 3, 0.0078125, 128 INFO: 3: MobilenetV1/Predictions/Reshape_1/requantize, 1001, 9, 0.00390625, -128 INFO: 4: input, 150528, 9, 0.0078125, 0 INFO: 5: NeutronMicrocode, 23944, 3, 0, 0 INFO: 6: NeutronWeights, 4329648, 3, 0, 0 INFO: 7: NeutronKernels, 11088, 3, 0, 0 INFO: 8: NeutronScratch, 380912, 3, 0, 0 INFO: 9: NeutronProfile, 0, 3, 0, 0 INFO: 10: NeutronDebug, 0, 3, 0, 0 INFO: len: 940650 INFO: width, height, channels: 517, 606, 3 INFO: input: 2 INFO: number of inputs: 1 INFO: number of outputs: 1 INFO: EXTERNAL delegate created. INFO: NeutronDelegate delegate: 1 nodes delegated out of 4 nodes with 1 partitions. INFO: Neutron delegate version: v1.0.0-f24d08e5, zerocp enabled. INFO: Applied EXTERNAL delegate. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. Interpreter has 1 subgraphs. -----------Subgraph-0 has 11 tensors and 5 nodes------------ 1 Inputs: [2] -> 150528B (0.14MB) 1 Outputs: [1] -> 1001B (0.00MB) Tensor ID Name Type AllocType Size (Bytes/MB) Shape MemAddr-Offset Tensor 0 MobilenetV1/Logits/Spa... kTfLiteInt8 kTfLiteCustom 1001 / 0.00 [1,1001] [-1, -1) Tensor 1 MobilenetV1/Prediction... kTfLiteUInt8 kTfLiteArenaRw 1001 / 0.00 [1,1001] [151552, 152553) Tensor 2 input kTfLiteUInt8 kTfLiteArenaRw 150528 / 0.14 [1,224,224,3] [0, 150528) Tensor 3 MobilenetV1/Prediction... kTfLiteInt8 kTfLiteArenaRw 1001 / 0.00 [1,1001] [150528, 151529) Tensor 4 input kTfLiteInt8 kTfLiteCustom 150528 / 0.14 [1,224,224,3] [-1, -1) Tensor 5 NeutronMicrocode kTfLiteUInt8 kTfLiteMmapRo 23944 / 0.02 [23944] [4340768, 4364712) Tensor 6 NeutronWeights kTfLiteUInt8 kTfLiteMmapRo 4329648 / 4.13 [4329648] [11104, 4340752) Tensor 7 NeutronKernels kTfLiteUInt8 kTfLiteMmapRo 11088 / 0.01 [11088] [0, 11088) Tensor 8 NeutronScratch kTfLiteUInt8 kTfLiteArenaRw 380912 / 0.36 [380912] [-1, -1) Tensor 9 NeutronProfile kTfLiteUInt8 kTfLiteArenaRw 0 / 0.00 [0] [-1, -1) Tensor 10 NeutronDebug kTfLiteUInt8 kTfLiteArenaRw 0 / 0.00 [0] [-1, -1) kTfLiteArenaRw Info: Tensor 2 has the max size 150528 bytes (0.144 MB). This memory arena is estimated as[0xaaaafd73ffa9, 0xaaaafd71abc0), taking 152553 bytes (0.145 MB). One possible set of tensors that have non-overlapping memory spaces with each other, and they take up the whole arena: Tensor 2 -> 3 -> 1. kTfLiteArenaRwPersistent Info: not holding any allocation. kTfLiteMmapRo Info: Tensor 6 has the max size 4329648 bytes (4.129 MB). This memory arena is estimated as[0xffff7ec299f8, 0xffff7e800050), taking 4364712 bytes (4.163 MB). One possible set of tensors that have non-overlapping memory spaces with each other, and they take up the whole arena: Tensor 7 -> 6 -> 5. kTfLiteDynamic Info: not holding any allocation. === Beginning of kTfLiteArenaRw Dump: === Total size is 152553 bytes (0.145 MB), holding 3 tensors. tensor 2: life_span: node [0, 4], size: 150528 bytes (0.144 MB). tensor 3: life_span: node [2, 3], size: 1001 bytes (0.001 MB). tensor 1: life_span: node [3, 4], size: 1001 bytes (0.001 MB). 1 tensors are of same max size (150528 B (0.144 MB)): [2] Per-layer-info in the order of op execution: Node 0: 150528 bytes (0.144 MB), utilization rate: 98.673%, 1 live tensors: [2] Node 4: 151529 bytes (0.145 MB), utilization rate: 99.329%, 2 live tensors: [1,2] Node 2: 151529 bytes (0.145 MB), utilization rate: 99.329%, 2 live tensors: [2,3] Node 3: 152530 bytes (0.145 MB), utilization rate: 99.985%, 3 live tensors: [1-3] Top 4 memory-consuming layers: Node 3: 152530 bytes (0.145 MB), utilization rate: 99.985%, 3 live tensors: [1-3] Node 4: 151529 bytes (0.145 MB), utilization rate: 99.329%, 2 live tensors: [1,2] Node 2: 151529 bytes (0.145 MB), utilization rate: 99.329%, 2 live tensors: [2,3] Node 0: 150528 bytes (0.144 MB), utilization rate: 98.673%, 1 live tensors: [2] ===End of kTfLiteArenaRw Dump: === Node 0 Operator Builtin Code 114 QUANTIZE (not delegated) 1 Input Tensors:[2] -> 150528B (0.14MB) 1 Output Tensors:[4] -> 150528B (0.14MB) Node 1 Operator Custom Name NeutronGraph (delegated by node 4) 4 Input Tensors:[4,5,6,7] -> 0B (0.00MB) 4 Output Tensors:[0,8-10] -> 0B (0.00MB) Node 2 Operator Builtin Code 25 SOFTMAX (not delegated) 1 Input Tensors:[0] -> 1001B (0.00MB) 1 Output Tensors:[3] -> 1001B (0.00MB) Node 3 Operator Builtin Code 114 QUANTIZE (not delegated) 1 Input Tensors:[3] -> 1001B (0.00MB) 1 Output Tensors:[1] -> 1001B (0.00MB) Node 4 Operator Custom Name NeutronDelegate 4 Input Tensors:[4-7] -> 4515208B (4.31MB) 1 Output Tensors:[0] -> 1001B (0.00MB) Execution plan as the list of 4 nodes invoked in-order: [0,4,2,3] Among these nodes in the execution plan: Node 4 is a NeutronDelegate node (0xaaaafd6f5c30), which has delegated 1 nodes: [1] --------------Subgraph-0 dump has completed-------------- --------------Memory Arena Status Start-------------- Total memory usage: 152553 bytes (0.145 MB) - Total arena memory usage: 152553 bytes (0.145 MB) - Total dynamic memory usage: 0 bytes (0.000 MB) Subgraph#0 Arena (Normal) 152553 (100.00%) --------------Memory Arena Status End-------------- INFO: invoked INFO: average time: 0.326 ms

iMX95 DRAM speed Hi, The current iMX95 can only support up to 6.4Gbps.  Will NXP release any processor that can support LPDDR5X with speed up to 8.5Gbps? Thanks. Re: iMX95 DRAM speed Hi @pengyong_zhang , Can you provide the model name? What will be the preliminary spec available? Thanks. Re: iMX95 DRAM speed Hi @simonng  Chips after version imx95 will support LPDDR5X 8533MT/s B.R Re: iMX95 DRAM speed hi @simonng  I can't provide you with specific details about the chip because the official website hasn't released any information yet. B.R Re: iMX95 DRAM speed Hi @pengyong_zhang , When will this new version of chip be released? What is the maximum supported speed and density of DRAM? How many CS per channel? Thanks

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.

S32K118 VLPS: I/O retention in the low power mode, plus SIRCSTEN and VLPSA queries Hi, We have VLPS entry and pin wake-up working on the S32K118, verified standalone with no debugger attached: four consecutive clean sleep/wake cycles, SMC_PMCTRL[VLPSA] clear on each, and SMC_PMSTAT confirming VLPR immediately before each WFI. So this is not a question about VLPS failing to work - it is about current consumption during a sleep that is working correctly. Setup: MCU: S32K118, 48-pin LQFP Board: S32K118EVB-Q048 (SCH-47530 Rev A1) Tools: S32 Design Studio 3.6.8, GCC 11.4 Issue: GPIO output state is retained through VLPS, and a driven RGB LED consumes current for the entire sleep. The on-board RGB LED is connected to PTD15 (green), PTD16 (red) and PTE8 (blue) through series resistors. What we observed: Our application drives the RGB LED from a periodic task while running. When the device enters VLPS, whatever level the LED pins were last driven to is still being driven for the whole time the device is asleep. The core is stopped, the clocks are gated, nothing in software is running - but the LED stays lit and keeps sourcing current until the device wakes. The effect on consumption is large. A single lit LED channel draws several milliamps through its series resistor, which is far above the VLPS current specified for this device and dominates the total completely. Our first supply-current measurements at J15 showed no meaningful drop between RUN and VLPS, and the retained LED state turned out to be the entire reason. The failure is silent. There is no flag, no error, and no difference in any status register between a sleep with the LED off and a sleep with the LED lit. The only symptom is that the low-power mode appears not to save any power, which is easily mistaken for VLPS not being entered at all. It cost us a significant amount of investigation time before we identified the cause. Questions: (a) Is this retention of GPIO output state through VLPS the intended behaviour of the device? (b) Is there any configuration on S32K118 that changes it, or must the application drive every pin to its intended sleep state before entry? (c) Is there recommended practice for configuring digital I/O prior to low-power entry - in particular pull-up/pull-down settings on pins tied to external switches or transceivers, where a retained pull is a continuous leakage path for the duration of the sleep? (d) Under what I/O configuration are the specified VLPS current figures for this device measured? Without knowing that, the specified figure cannot be compared against a measurement on a real board. (e) Are there any pins whose retained state can affect VLPS entry itself, or the wake-up path? deep sleep would put the I/O into an inactive state and the LED would go off by itself, since the core is stopped and all the clocks are gated. That is not what we see - the LED stays lit for the whole sleep at full brightness. Please confirm whether the LED is expected to remain lit in VLPS, and if so, whether there is any device setting that makes the output pins go inactive on low-power entry rather than holding their last driven level. Thanks Re: S32K118 VLPS: I/O retention in the low power mode, plus SIRCSTEN and VLPSA queries Hello @autouser, a) Yes. All I/Os are retained upon entering VLPS:  Julin_AragnM_1-1786054875339.png b) It is up to the application to set the required pins to the intended state before entering VLPS. c) This is application dependent. But, if you have unused pins, you can refer to HW Design Guidelines chapter 8 (unused pins).  "For unused digital and analog pins, the pin function should be set to DISABLED by setting the correspondingPORTx_PCRn[MUX] field to 0b000. The DISABLED function is default state for all pins not initialized. For pins with ADC functionality software should not trigger ADC channel conversion on the channel which is multiplexed with the unused pin.” If they are configured as inputs, they should not be left floating, pulled to either VSS or VDD externally or internally (application-dependent). You can also refer to the S32K3 Low Power Management documentation; chapter 10 provides some HW considerations which apply to general MCU power consumption: Julin_AragnM_2-1786055927609.png d) Table 4.7 (Power consumption) from S32K1xx Data Sheet shows power consumption defined in the attached S32K1xx_Power_Modes_Configuration.xlsx: Julin_AragnM_3-1786056046103.png Last row of the attachment shows which IOs were enabled at measurement. Also, foot note 1 mentions: "All output pins are floating, and On-chip pulldown is enabled for all unused input pins." e) Other than the configured wake-up pins, which will either wake the device immediately if asserted, I cannot think of ones which may affect VLPS entry/exit. Best regards, Julián

S32K314 CAN issue I am using S32K314  , and recently I got a issue about CAN when I doing  the test by short-circuiting of the oscillator ; after recovery  ,I monitored  SPI ,ADC ,these modules works OK, but CAN module can not work normally, the debuger show these information,  in this status, CAN can not receive or send any fram, how could this happened, and how to recover this fault by sw? Snipaste_2026-08-04_13-32-47.jpg   Re: S32K314 CAN issue Hi,  Thanks for your  reply . I try to add some test code in "Mcu_ClockSourceFailure_Notification" , but this notification do not be trigged; so from software side , how can we notice this issue happened then reset CAN Module? thanks Below is the value of the registers you mentioned: MCR KidhRobin_0-1785975444257.png CTRL1 KidhRobin_1-1785975470032.png CBT: KidhRobin_2-1785975496485.png FDCBT: KidhRobin_6-1785975801928.png ECR KidhRobin_4-1785975599003.png ESR1 KidhRobin_5-1785975618985.png Re: S32K314 CAN issue Hi, From the provided screenshot, the receive error counter (RXERRCNT) is increasing while TXERRCNT remains 0, which does not fully match a typical transmit-related issue even though ESR1 indicates a transmission attempt is ongoing. The oscillator short-circuit could potentially have affected the clocking, resulting e.g. in incorrect CAN bit timing after recovery. However, the current information is not sufficient to confirm this. Could you please provide: a wider view of the FlexCAN registers (including MCR/CTRL1/CBT/FDCBT, ECR and ESR1), the module and CAN protocol clock configuration after recovery, TX, RX and CAN bus measurements captured during the failure? If the FlexCAN module clock and the CAN protocol clock are running and have the expected frequency, you can also try performing a FlexCAN module software reset followed by a complete module reinitialization and check whether communication is restored. BR, Petr Re: S32K314 CAN issue Hi, If Mcu_ClockSourceFailure_Notification() is not entered, my first assumption would be that the corresponding MCU interrupt/notification path is not configured or enabled in the project. Could you please check: Whether clock monitoring (CMU) is enabled for the affected clock source. Whether the CMU interrupt is enabled. Whether the MCU module is configured to call Mcu_ClockSourceFailure_Notification() upon detection of a clock failure. It may also be useful to inspect CMU and RGM status registers after the oscillator short-circuit event to verify that a clock failure is actually being detected. From the FlexCAN register dump, the module appears enabled and synchronized to the bus (SYNCH=1), while RXERRCNT increases and TXERRCNT remains 0, now without bus activity. I see the bit timing registers shown (CTRL1, CBT, FDCBT) do not contain a valid CAN timing configuration, although this may be expected if Enhanced CAN Bit Timing is used and the actual timing is configured through the respective enhanced CAN bit timing registers. Therefore, before implementing a CAN reset strategy, it would be good to first verify whether the clock failure event is detected at all and whether the notification mechanism is properly configured. BR, Petr

KE18F512VLH16 ECC Memory Cell Autocorrection It's understood that the HW provides automatic correction of single bit ECC errors. However, it's unclear where the corrections are being made. When the hardware autocorrects a single bit ECC error, does it correct on both the read out and the memory cell, or just on the read out? From the AN5335 example figure, is the Read-out Data being corrected from 0->1? That would mean we need to write back the corrected value to RAM to actually clear it within the memory cell. sean_dvorscak_0-1786035276314.png We are concerned if the data in the RAM memory cell is not corrected, a single bit error could degrade to a double bit error. Re: KE18F512VLH16 ECC Memory Cell Autocorrection Hello @sean_dvorscak  1. "When the hardware autocorrects a single bit ECC error, does it correct on both the read out and the memory cell, or just on the read out?" ->>The correction is performed only on readout; the SRAM cell contents are not written back. 2. "We are concerned if the data in the RAM memory cell is not corrected, a single bit error could degrade to a double bit error." ->>Yes, if you want to clear errors in the memory cells and prevent error accumulation, it is recommended that the software perform a read-correct-writeback operation. Thank you. BR Alice