S32k344 design studio driver example code Hi Team  I wanted to run basic example codes on S32k344.  I have installed  S32 Design Studio for S32 Platform Version: 3.6.0 Build id: 241128 I am unable to find any diver examples in . I even with S32k extension and update to update s32k3xx package but the installation fails every time. It is stuck at 70%. Please let me know if you require any other information and help with basic examples. Regards Gopal Re: S32k344 design studio driver example code Hi @rathi_tg  To get started, we recommend using the latest version of the tools available, which is currently S32 Design Studio 3.6.10. There is no need to install it as a separate instance, as it can be installed as an update to your existing installation. Detailed instructions for this process can be found in the S32 Design Studio 3.6.10 RFP Installation Guide, which is available on the same download page as the S32DS installer. Regarding examples for S32K3 devices, these are included as part of the RTD packages. A good reference is the video How To Download, Install and Configure the RTD 5.0.0 with S32 Design Studio 3.6.0, which explains in detail what components need to be downloaded, how to install them, and how to create a project based on example. Although the video was created for RTD 5.0.0, the procedure is similar for newer RTD releases. Note: The latest RTD release available for S32K3 devices is RTD 7.0.1. Additionally, you may find useful examples and application projects in NXP's Application Code Hub, which contains a variety of ready-to-use examples for different devices and use cases. BR, VaneB

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.

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

I need RTM 1.5 package for S32 Power architecture Design Studio Project I am working on MPC5746 Target project using S32 Design Studio 2.1. While importing i am facing issue w.r.t Project was created using SDK_S32_PA_15 which is not installed. If i try to forcefully convert the project, i am facing compilation errors in CPU.h files. Please provide a compatible package. Re: I need RTM 1.5 package for S32 Power architecture Design Studio Project Hello, The SDK_S32_PA_15 is also known as S32 SDK 3.0.3. You can install this SDK into S32 Design Studio for PA v2.1 using the S32DS Extensions and Updates menu. This menu is located by: Help -> S32DS Extensions and Updates   If this package is installed correctly, then you shouldn't receive this error message.  Best regards, Peter

Zephyr UAC2 → SAI reference on i.MX RT1020 Hi everyone, I'm trying to get a USB-to-I2S audio pipeline working on the i.MX RT1020 using Zephyr's UAC2 asynchronous explicit feedback sample, but I'm running into issues with the NXP SAI (I2S) driver and eDMA. Before I spend more time debugging DMAMUX and IRQ configuration, does anyone know of a working USB-to-I2S example for the RT10xx series using Zephyr? I'm particularly looking for any reference project that implements a UAC2 to SAI audio path on Zephyr. Thanks in advance! Re: Zephyr UAC2 → SAI reference on i.MX RT1020 Hi @lpc73 , Thanks for your interest in NXP MIMXRT series! There is currently no ready-made UAC2→SAI reference project for the RT10xx in upstream Zephyr. The building blocks are all supported on RT10xx: the SAI/I2S driver (nxp,mcux-i2s), eDMA, and the UAC2 class. DMAMUX routing is done via the devicetree properties nxp,tx-dma-channel / nxp,rx-dma-channel + pinctrl, not manually in C. The main piece you'll need to add is the feedback loop for the RT platform, and be sure to place DMA audio buffers in non-cacheable memory. If Zephyr isn't mandatory, the MCUXpresso SDK's dev_audio_speaker + sai_edma_transfer are the most mature ready-to-use UAC2→SAI examples. Best regards, Gavin

CC-Link IE Field (1 Gbps) and CC-Link IE TSN (Class A and Class B) Support We are planning to implement CC-Link IE Field (1 Gbps) and CC-Link IE TSN (Class A And Class B) remote device communication using Layerscape LS1028A, i.MX 93, i.MX RT1170 Could you please confirm: Whether these controllers support CC-Link IE Field (1 Gps)and CC-Link IE TSN? Whether Nxp provides protocol stacks for these communication protocols? Whether any reference designs or third-party solutions are available? We would appreciate your guidance. Thank you. Re: CC-Link IE Field (1 Gbps) and CC-Link IE TSN (Class A and Class B) Support You may refer to the following announcement: NXP Unleashes CC-Link IE TSN LS1028A and i.MX RT1170 are supported platforms for CC-Link IE TSN solutions. For protocol stack support, Port GmbH provides an Industrial Communication Framework (ICF), including CC-Link IE TSN Master and Remote Station stacks for the LS1028A and i.MX RT1170 platforms. Thanks

S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on specific Device: S32K312 Toolchain: Green Hills ELXR (compiler) HSE Firmware: s32k312_hse_fw_0.13.0_2.55.0_pb250129.bin Debugger: Lauterbach TRACE32 Software: AUTOSAR RTD-based Bootloader (FBL) + Application (APP), two-image structure ISSUE SUMMARY On a subset of production units, the CPU hangs immediately after a Functional (software) reset. The same units always boot correctly after a Destructive (power-on) reset. The hang does not reproduce on our reference/known-good units. EVIDENCE THAT AN NMI OCCURS BEFORE ANY APPLICATION CODE EXECUTES 1) CPU context captured at the hang point (auto-stacked exception frame): - R0-R3 = 0x00000000, R12 = 0x00000000 - LR = 0xFFFFFFFF (reset default -> no BL has executed yet) - PC = 0x00416904 (the very first instruction address of our Reset_Handler) - xPSR = 0x01000000 2) SCB->ICSR = 0x00000802 - VECTACTIVE[8:0] = 2 -> NMI is the currently active exception - RETTOBASE = 1 This confirms the CPU is currently executing inside the NMI handler. 3) Our vector table entry for the NMI offset correctly points to our own default exception handler, so this is a genuine NMI event, not vector table corruption. REGISTERS CHECKED AT THE SAME HANG STATE (all read as clean / inactive) - MC_RGM_DES = 0x00000000 (not a destructive reset) - MC_RGM_FES = 0x20000000 (bit 29 only) (only "software functional reset" flag set, no other functional reset source flagged) - FCCU: STAT, N2AF_STATUS, A2FF_STATUS, N2FF_STATUS, NCF_S0, IRQ_STAT all = 0x00000000 - CMU_FC instances 0, 3, 4: SR = 0x00000000 (no frequency high/low fault) - PMC LVSC = 0x00000000 (no LVD/HVD flag, latched or live) - ERM (0x4025C000): could not be read on either good or failing units (likely clock-gated in our configuration), so ERM status is unverified. QUESTIONS 1. Are there any NMI sources -- other than FCCU / CMU_FC / PMC / MC_RGM -- that could fire before the application's Reset_Handler executes its first instruction? 2. Since the HSE subsystem runs independently of the application core, is it possible for an application-core Functional reset (which does not reset HSE) to create a state mismatch that triggers an NMI on the application core? 3. Is there a known errata for S32K312 matching this symptom (NMI only on functional/software reset, never on power-on reset)? Any guidance on additional registers to check, or documentation covering NMI sources outside FCCU / ERM / CMU_FC / PMC, would be greatly appreciated. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Could you please read registers MU_0.MUB CSSR0 and MU_1.MUB CSSR0 at the hang state, and confirm whether bit 0 (NMIC) is set in either of them? Thank you Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Thank you for pointing us to MU_0.MUB / MU_1.MUB CSSR0. CSSR0 (bit 0, NMIC) on both MU_0.MUB and MU_1.MUB reads 0x00000000 on the failing unit at the hang state, so the MU->NMI request path (CCR0[NMI] / CSSR0[NMIC]) does not appear to be pending. However, while comparing MU registers between a known-good unit and a failing unit (both captured at the identical hang-state address range), we found a consistent difference:                                Good unit Failing unit MU_0.MUB VER 0x0300000F 0x0300000F (identical) MU_0.MUB PAR 0x20200404 0x20200404 (identical) MU_0.MUB CR 0x00000000 0x00000000 (identical) MU_0.MUB SR 0x00000000 0x00000002 <- MURIP set MU_1.MUB VER/PAR/CR: identical between good and failing units MU_1.MUB SR 0x00000000 0x00000002 <- MURIP set So on BOTH MU instances, SR bit 1 (MURIP) is set only on the failing unit, consistently. Per the reference manual, MURIP indicates that "processor A" has issued an MU reset, and can only be cleared by a system reset (not by an MU reset). Since the CPU is frozen inside the NMI handler before executing any application code, it could not have cleared this flag itself, so it must have been set prior to (or as part of) this boot sequence. We'd appreciate your input on the following: 1. For MU_0.MUB and MU_1.MUB, which processor is "processor A" (i.e. who sets MURIP)? Our header only exposes the "MUB" register block at the application-core-accessible address -- does this imply the application core is always "processor B" and HSE is "processor A" for these instances? 2. Does "system reset" (required to clear MURIP) include a Functional/SW reset of the application core, or only a Destructive/POR reset? If MURIP is not cleared by our functional reset, that would explain why it stays set across SW reset while it is clear after power-on. 3. Independent of the NMI question: is a set/stuck MURIP flag itself expected or considered anomalous during normal operation? 4. Since CSSR0[NMIC] currently reads 0, is it possible for hardware to auto-clear NMIC upon NMI exception entry, or does it only clear via an explicit software write (in which case NMIC=0 would mean the MU->NMI channel was never asserted in the first place)? Thanks again for your help so far. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, I'm sorry for the delay. I was out of office for two days. 1. Yes, the HSE_B core controls the MUA interfaces of MU_0 and MU_1. 2. Any system reset should reset MURIP. 3. I would consider this an anomaly, as I do not have much information about it. 4. It requires an explicit write, as it is a W1C register. Can you make sure that HSE_B is inactive at the time the functional reset is triggered? Also, what is the state of HSE_B while the application is stuck in the NMI handler? Can you read the standard HSE GPR (0x4039_C028), FSR, and GSR registers on the MU_0 B side? Do you use the NMI pin in the application? Regards, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi Daniel, Please find three combined register-dump screenshots attached, followed by our findings organized by your questions. -------------------------------------------------------- ATTACHMENTS -------------------------------------------------------- Attachment 1: GOOD unit (Secure Debug enabled, running normally) Attachment 2: FAILING unit, immediately BEFORE the functional reset is triggered (normal operation) Attachment 3: FAILING unit, AFTER the functional reset, stuck in the NMI handler (hang state) -------------------------------------------------------- FINDINGS 1) HSE_B activity at the time the functional reset is triggered, and 2) state of HSE_B while stuck in the NMI handler: Comparing Attachment 2 (before reset) and Attachment 3 (after reset, hang state) on the failing unit, every register we checked reads IDENTICALLY before and after the reset: - MU_0.MUB / MU_1.MUB TSR = 0x0000000F, RSR = 0x00000000 (no pending messages on transmit/receive channels, unchanged by the reset) - MU_0.MUB GSR = 0x00000000 (unchanged) - MU_0.MUB FSR = 0x03600000 (unchanged) - HSE GPR (0x4039C028) = 0x000001C1 (unchanged) - MU_0.MUB / MU_1.MUB SR bit 1 (MURIP) = 0x00000002 -- already set BEFORE the reset is triggered, and remains set, unchanged, after the reset So MURIP was already set prior to this reset cycle, and the functional reset itself does not change any of these HSE-related registers. For reference, on a good unit with the same Secure Debug configuration (Attachment 1), MURIP reads 0x00000000 on both MU_0.MUB and MU_1.MUB, while HSE GPR and WKPU NCR read the same values as the failing unit. 3) Regarding whether a set/stuck MURIP is anomalous: Understood, thank you for confirming. 4) NMI pin usage: We do not use the WKPU-routed NMI path (WKPU_IP_USED is not enabled; no WKPU driver code is compiled into either our bootloader or application image). WKPU NCR (0x402B4008) = 0x60000000 identically across all three attachments. NSR = 0x00000000 in all cases. Since this is unchanged across all units and conditions, we don't believe an external/WKPU-routed NMI source is involved. SUMMARY OF FINDINGS SO FAR MURIP (MU_0.MUB and MU_1.MUB SR bit 1) is already set on the failing unit BEFORE the functional reset is even triggered, and remains unchanged throughout the hang. It reads 0 on a good unit with the same Secure Debug configuration. This is the only consistent, reproducible difference we have found across every register we've compared (FCCU, CMU_FC, PMC, WKPU, and MU CSSR0/GSR/TSR/RSR/GPR/FSR). Since MURIP is set by "processor A" (HSE_B) and should be cleared by "any system reset" per your answer, and since it is already set before our functional reset is triggered (and the reset itself does not appear to change it), this suggests HSE_B issued an MU reset at some earlier point that was never cleared by a "system reset" recognized by HSE_B. QUESTIONS 1. Is there a way to determine, from the HSE side, what would cause HSE_B (processor A) to issue an MU reset in the first place? We'd like to understand why MURIP gets set at all. 2. Is there a recommended way for us to trigger a reset that HSE_B recognizes as a "system reset" (to clear MURIP) from application software, short of a full power cycle? 3. Could a stuck MURIP flag on the application-core side be related to the NMI we are observing, or are these more likely two independent symptoms of the same earlier event? Thanks again for your continued help with this. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @Chibeom, Thank you for the detailed register dumps. I have escalated the questions around MURIP behavior and the potential NMI path between HSE_B and CM7_0 to our internal HSE team, as this seems to be not documented. I will get back to you once I have their input.

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 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 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. 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

CircO2 Nitric Oxide Tablets Review: A Complete Buyer's Guide CircO2 is a nitric oxide support supplement made by Advanced Bionutritionals. Unlike a lot of pills you swallow with water, CircO2 comes in a quick-dissolving tablet (sometimes called a lozenge) that melts in your mouth. This is one of the things that makes it stand out from other CircO2 Tablets on the market. The main idea behind CircO2 Oxygen Booster and Circulation Support is simple: help your body make more nitric oxide, so your blood vessels can relax and widen. When that happens, blood (and the oxygen it carries) can move more freely through your body. That can mean more energy, warmer hands and feet, and better stamina during the day.  

M&P Multilink I have developed approximately 20 projects using S08 processors and CodeWarrior 11.1  with the P&E Multilink Universal FX debugger. I used an Intel-based MAC with Parallels VM running Windows 7. Everything worked Great! I now have a new MAC , again running Parallels VM and Windows 11. (no choice). CodeWarrior loaded, but with a message about no device driver. It works fine, but the debugger is not recognised. On the old Mac, Windows Device Manager showed an entry "Jungo Connectivity/Windriver", but on the new MAC the device manager only showed an entry "MULTILINK".  There are a number of suggested fixes but the proposed files could not be found, Can someone please offer me a working solution, even if it means using a different debug probe. Re: M&P Multilink If you update from Windows 7 to Windows 11, all the related driver may need to reinstall CodeWarrior® for MCUs (Eclipse IDE) could be a good choice to select CodeWarrior® for MCUs (Eclipse IDE) - ColdFire®, 56800/E DSC, Qorivva® 56xx, RS08/S08, S12Z - 11.1 Re: M&P Multilink I hate Windows and I am not updating from W7 to W11 - it is a new machine (Mac M4) and W7 is not compatible so I have no choice.I have been using CodeWarrior for about 25 years. My question was "which drivers do I need for W11 and where can I find them?  Just as a point of interest and nothing to do with this topic, AUTODESK products will no longer run on old Intel-based Macs, so Windows 7 - R.I.P. Re: M&P Multilink Hello, I would recommend on using the OS windows 11 for using CodeWarrior v11.1 this is the supported option, not virtual machines; as we can't guarantee that the CodeWarrior Tool work with Virtual Machines To download the v11.1, Please refer to CodeWarrior for MCUs (Eclipse IDE) v11.1 Best Regards, Luis

KW45B41Z-EVK: BLE clock source and internal clock path for the BLE radio to get 2.4GHz Hello NXP Team, I am working with the KW45B41Z-EVK  and would like to understand the clock architecture used by the BLE subsystem. I have gone through the KW45B41 Reference Manual, KW45B41Z-EVK User Manual, and the SDK clock initialization code, but I could not find a detailed description of the BLE clock source and its internal clock path. Could you please clarify the following: What is the primary clock source used by the BLE (for example, SOSC, FRO, PLL, or another clock source)? What is the complete clock path from the oscillator to the BLE radio to get 2.4GHz? Specifically, which clock modules, multiplexers, dividers, or PLLs are involved before the clock reaches the BLE subsystem? Does the BLE subsystem use different clock sources during advertising, scanning, connected mode, or sleep mode? Is there a clock tree diagram or application note that illustrates the BLE clock architecture for the KW45B41 device? Which sections of the Reference Manual or any other NXP documentation describe this in detail? If possible, a block diagram of the BLE clock path or references to the relevant documentation would be greatly appreciated. Thank you for your support. Best regards, Re: KW45B41Z-EVK: BLE clock source and internal clock path for the BLE radio to get 2.4GHz Hello, Hope you are doing well! The primary clock source for the BLE subsystem is the OSC-RF (RF Oscillator), in conjunction with an external crystal or resonator, generates a reference clock for the KW45 Radio. It supports either 26 MHz or 32 MHz and operates in a completely separate power domain from the main CPU clock domain, serving exclusively as the reference clock for the Radio subsystem. The KW45 Reference Manual includes two figures that might be particularly helpful to visualize the BLE clock architecture: Figure 68. Device clock sources and trees Figure 222. Radio Clocking As described in section 55.4.4 of the RM, the radio uses three clock sources: the Radio XO (OSC-RF), the FRO-192M, and the SOC 32.768 kHz from the CCM32K module. During active operating mode (including advertising, scanning, and connected), all three clock domains are simultaneously active. The OSC-RF and its XCVR PLL are running to support radio TX and RX (this is managed internally by the NBU firmware), the FRO-192M is clocking the NBU CM3 core for Link Layer execution, and the 32K_CLK is running in the background to track connection and advertising intervals. For low-power mode behavior, Table 209 describes how each clock module behaves across the different power states. It might also be helpful to use the Clocks Tab from MCUXpresso Config Tools. There, you can visualize the clock sources routed for each domain, see the interactive clock tree, and change clock sources as needed. It also generates the clock initialization source code, which can be a helpful reference for understanding how each clock domain is configured at startup. Best regards, Sofia.

For S32G399, configure DDR‑based shared memory to be accessed by both A‑Core and M‑Core. For chip S32G399, configure DDR‑based shared memory to be accessed by both A‑Core and M‑Core. Are there any implementation schemes and demos available? Re: For S32G399, configure DDR‑based shared memory to be accessed by both A‑Core and M‑Core. Hello, @zhijie  Thanks for your post. As far as I know, there seems no such similar formal demo/examples existed, you may need to develop it yourself. For communication between M and A cores, currently IPCF is provisioned by NXP, but it is by default based on SRAM. BR Chenyin Re: For S32G399, configure DDR‑based shared memory to be accessed by both A‑Core and M‑Core. Has any developer within the NXP Community completed such an implementation? Relevant documents or experience sharing will be greatly appreciated.

Request for NXP V2X Evaluation Board and Design Files Dear NXP Team, We are evaluating V2X communication solutions for an automotive application supporting V2V, V2I and V2P safety messages. We are interested in NXP’s RoadLINK/SAF5400-based V2X solution and the OrangeBox platform. Kindly provide the following information: Recommended NXP V2X evaluation board or reference platform Evaluation-board ordering part number SAF5400 availability and lifecycle status Reference schematic and hardware design files Bill of materials and PCB layout guidelines RF matching and antenna reference design Hardware user manual and software development kit BSP, drivers and example applications Functional-safety documentation, including ASIL-B support details Security-device recommendations for V2X message signing and verification NDA procedure for accessing controlled technical documents Our intended application is an automotive V2X communication unit operating in the 5.9 GHz band. Please also confirm whether NXP currently offers a solution supporting DSRC/IEEE 802.11p, C-V2X PC5, or both. Kindly share the applicable product documents, commercial contact details and procurement process. Best regards, Renjith Thomas Senior Design Engineer - HW Get My Solutions +91 8015237416

GPIO wakeup triggered by short noise pulses during suspend Hi NXP team, We are using i.MX8MP on a custom board with Linux BSP LF-6.12.20. Several GPIO pins are configured as wakeup sources. Problem: during EMC transient testing (ESD), short noise pulses on these GPIO lines falsely wake the suspended system. We have already confirmed that software debounce cannot solve this: the wakeup decision is made by hardware while the CPU is suspended, and the GPIO interrupt handler — including the gpio-keys debounce — only runs after the system has resumed, so software cannot prevent the wakeup itself. We have also reviewed the Linux drivers (LF-6.12.20) and the i.MX8MP reference manual, and we could not find any hardware filter for the GPIO wakeup path. Please confirm whether this understanding is correct. Questions: 1. Does i.MX8MP have ANY hardware option (in GPIO, GPC, or configurable via ATF) to ignore very short pulses on a wakeup pin — for example a glitch filter or a minimum pulse-width setting? This includes level-trigger mode: does it require the level to be held for a minimum time, or does any instantaneous pulse still trigger wakeup? 2. If no such hardware option exists, what is NXP's recommended solution for this kind of false wakeup? Any application note on ESD protection for GPIO wakeup inputs would be appreciated. 3. Is there any NXP reference design where the Cortex-M7 checks/filters wakeup signals while the A53 stays in suspend? Platform: i.MX8MP custom board, BSP: LF-6.12.20 Best regards, i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: GPIO wakeup triggered by short noise pulses during suspend Hello @Leo_dev  Hope you are doing very well. Q1. Your understanding is correct. The i.MX8MP GPIO/GPC wakeup path has no hardware glitch filter or minimum pulse-width setting or debouncing register. Q2. As there is not an On-chip solution, the recommended design is adding a filter to the PAD. Q3. Yes, you can take a look to the AN13400 "i.MX 8M Low Power Design By M Core Running In System Suspend" is the primary NXP reference for this kind of architecture. Best regards, Salas.

LLCE CAN 在进行LLCE CAN通信时，发现一个问题，当环境是两个can节点直连配有两个终端电阻120欧姆，对端设备处于监听模式时会触发ACKERR，同时LLCE固件会自动重传，这个重传的好像是以总线的最大带宽在发送，想问下是否有什么方式可以配置自动重传的次数或者怎么停止自动重传 回复： LLCE CAN 使用的是RTDSW32G_RTD_4.4_4.0.2_P04_D2312，S32G_LLCE_1_0_9 回复： LLCE CAN 在项目的实际应用上肯定是不希望因为ACKERR或者其他问题导致的重传而出现网络风暴的，所以我想知道能不能关闭自动重传。如果没有对于控制自动重传的选项，是不是就只能软件监控了配置对于策略了 回复： LLCE CAN Hello, @JACK_Q  您好 从我的理解来看，应该和LLCE软件无关，这主要是CAN协议层ACK机制导致的，对端处于 listen-only模式时不发送 ACK，此时S32G LLCE侧发出的帧得不到ACK，就会报 ACKERR，随后控制器继续重传，这符合CAN发送失败后的行为。 以上操作是协议规定的，我没看到有配置可以设置重传次数 BR Chenyin

Modbus RTU communication error I am writing code for MC9S08JM60 to read MODBUS RTU holding registers. I am reading 15 holding registers which gives me a 35 byte frame. So i am expected to get 1 interrupt for each byte but i am getting 1 interrupt for the first byte of the frame and next interrupt is for the first byte of the next frame. So I am losing the rest 34 bytes. Please provide any input for this. I am attaching my code snippets. Re: Modbus RTU communication error Hi @An95  Thank you for your post! There is any documentation of Modbus RTU with the S08. But the issue you are facing could be related to not clear the RDRF. The RDRF (Receive Data Register Full) flag is cleared only by reading SCI1D after reading SCI1S1. If SCI1D is not read in the ISR, the interrupt fires once and then the receiver stalls. Refer to 14.2.4 SCI Status Register 1 (SCIxS1) of the MC9S08JM60 Series Data Sheet. Make sure your code is clearing the flag correctly. BR Re: Modbus RTU communication error Hi @carlos_o , Thank you for your response. The RDRF flag is cleared when it enters the callback function of the interrupt service routine. The 35 byte frame is coming in a single interrupt. If I take a buffer of 35 bytes even then i am not able to read the whole frame. Please share your input regarding this. BR Re: Modbus RTU communication error I have changed my implementation to bare metal code still i am receiving only 1 byte. Please share any input. Re: Modbus RTU communication error Hi @An95  The SCI only could receive 1 byte each time RDRF is trigger. So, you will need to trigger 35 interrupts to read the 35 bytes you are sending.  You could refer to the chapter 14.3.3 Receiver Functional Description The SCI module only has one SCI Data Register (SCIxD) that could save 8 bits each time. 

LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from DT. Hello, I am working on a custom board based on the LS1046A and I am experiencing a boot issue with a Debian image generated using FlexBuild. As a first step, I built the default LS1046AFRWY BSP without making any modifications and tested it on my custom board. During kernel boot, the system always hangs after printing: psci: probing for conduit method from DT. There is no kernel panic or exception; the system simply stops at this point. I found the following NXP forum thread describing a very similar issue: https://community.nxp.com/t5/Layerscape/LS1043A-RDB-Linux-Hangs-At-PSCI/td-p/750075 As a temporary workaround, I can boot Linux manually from U-Boot using the following commands. However, the kernel only boots successfully when I limit the available memory to 1982 MB using the "mem=" boot argument. If I increase this value, the kernel hangs again (sometimes at different points during boot). mmc dev 0 part uuid mmc 0:3 partuuidr load mmc 0:1 0x81000000 Image load mmc 0:1 0x90000000 fsl-ls1046a-frwy-sdk.dtb setenv bootargs "console=ttyS0,115200 earlycon=uart8250,mmio,0x21c0500 root=PARTUUID=${partuuidr} rw rootwait mem=1982M" booti 0x81000000 - 0x90000000 Test environment: SoC: LS1046A DDR: IS43/46QR16512A (4 GB DDR4) Boot media: SD Card BSP: FlexBuild (LSDK 25.12) To rule out a FlexBuild-specific issue, I also built a completely new BSP using Yocto (YP 6.0 / lf-6.18.20) and tested it on the same hardware. The result is exactly the same. The kernel again hangs after printing: psci: probing for conduit method from DT. The relevant part of the bdinfo output is shown below: DRAM bank 0 Start: 0x80000000 Size : 0x7be00000 DRAM bank 1 Start: 0x880000000 Size : 0x80000000 LMB memory regions: memory[0] : 0x80000000 - 0xfbdfffff memory[1] : 0x880000000 - 0x8ffffffff reserved[0] : 0xfac154c0 - 0xfbdfffff reserved[1] : 0x8ffff5000 - 0x8ffffffff Has anyone encountered a similar issue or have any suggestions on what I should investigate next? Any advice would be greatly appreciated. QorIQ LS1 Devices Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from Hello, Root Cause — BL31 Memory Collision The LS1046A boot flow is: Boot ROM → BL2 (DDR Init) → BL31 (stays resident in DRAM) → U-Boot → Linux     BL31 remains permanently resident in DRAM and handles all SMC calls (PSCI: psci_get_version , CPU on/off, etc.). Its typical placement is near top-of-RAM minus ~10 MiB, with a size of up to 2 MiB.   When Linux boots with the full 4 GB DDR map, it allocates pages that physically overlap BL31's region. The first PSCI SMC call ( psci_get_version ) jumps into now-corrupted memory and the system hangs — with no panic, no exception, just silence. Your bdinfo output confirms the exact pattern — DDR Bank 1 ends at 0x8FFFFFFFF , and BL31 is at approximately RAM_END - 10 MiB = 0x8FF600000 : DDR Bank Start End Notes Bank 0 0x80000000 0xFBDFFFFF ~1982 MiB — your working mem= limit Bank 1 0x880000000 0x8FFFFFFFF 2 GB high bank — BL31 lives here The mem=1982M workaround keeps Linux within Bank 0, never touching Bank 1 where BL31 resides — which is precisely why it works. Fix — Reserve BL31 Memory in the Device Tree The correct permanent fix is to add a reserved-memory node to your DTS marking BL31's region as off-limits to the Linux memory allocator. Step 1: Find where BL31 is loaded Check your ATF build configuration ( plat/nxp/soc-ls1046a/.../platform_def.h ) for BL31_BASE and BL31_SIZE . For LSDK/lf-6.x with the FRWY BSP, the typical placement is: BL31_BASE = 0x8FF80000 (top of high DDR bank minus ~512 KB to 2 MB) BL31_SIZE = max 2 MiB     You can confirm at runtime by checking U-Boot output or the ATF build log for BL31: v2.x... Entry point address = ... . Step 2: Add the reserved-memory node to your DTS In your board DTS file (based on fsl-ls1046a-frwy-sdk.dts ), add: / { reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; /* Reserve BL31 runtime region — adjust addresses to match your ATF build */ bl31_reserved: bl31@8ff600000 { reg = <0x8 0xff600000 0x0 0x00200000>; /* 2 MiB at RAM_END - 10 MiB */ no-map; }; }; }; dts   Adjust 0x8ff600000 and size 0x200000 to match your actual BL31 load address from the ATF build. Step 3: Rebuild and test with full memory After adding the reservation, rebuild the DTB and boot without the mem= workaround. The kernel will skip that region, BL31 remains intact, and PSCI will function correctly.   Regards Re: LS1046A Custom Board -image built with FlexBuild hangs at psci: probing for conduit method from Hello, I tried the suggested solution, but unfortunately it did not resolve the issue. First, I verified the BL31 address from the TF-A (ATF) build: - BL31_BASE = 0xFBE00000 - BL31_SIZE = 0x200000 (2 MiB) Next, I added a "reserved-memory" node to the Device Tree to reserve the BL31 runtime region and rebuilt the DTB. After that, I booted the system again without the "mem=1982M" boot parameter. However, the system still hangs at the same point.

SPC5777CCMMO3 pin out reading eepron   What is the pinout to be able to read the eeprom of this micro with the reader?   Re: SPC5777CCMMO3 pin out reading eepron Hello, If the micro is censored, you won't be able to connect to flash without 256-bit censorship password. So trying to connect without valid secure keys is just waste of time, as there are additional protection mechanisms like PASS, and CSE. Its not like it used to be in old days, uC has now advance secure features to prevent unauthorized accesses. Best regards, Peter Re: SPC5777CCMMO3 pin out reading eepron Thanks, what I'm looking for is to read the internal flash to be able to remove an anti-tunig block that doesn't allow writing modified files, only writing the original. Re: SPC5777CCMMO3 pin out reading eepron Hello, The pins are described in IOMUX table as I have mention before: But I am not sure what your intention is. You will need a JTAG properly connect, like it is on evaluation board in order to work. Also if the device is censored you need correct password to unlock its flash. Without it you cannot connect to the device at all. Best regards, Peter Re: SPC5777CCMMO3 pin out reading eepron Hi yes try  reading flash via JTAG. The micro is good. I removed it so I could track and locate where each pin went on the board, and mark points for reading and writing, without having to remove it. Re: SPC5777CCMMO3 pin out reading eepron Hello, Not sure what your intention is, but the pins are explained in IOMUx table attached to reference manul: https://www.nxp.com/webapp/Download?colCode=MPC5777CRM You are probably speaking about reading flash via JTAG. I am confused as your micro looks damaged. So no read of flash is possible if the micro is not working. Best regards, Peter Re: SPC5777CCMMO3 pin out reading eepron where to buy this 256-bit censorship password.

PTP over SJA1110 Hi, We are debugging PTP on a PolarFire SoC GEM connected through an SJA1110 switch. We observe that: PTP over Layer 2 (ptp4l -2) is received by the switch (ingress counters increase), but it is not forwarded (egress counters do not increase). PTP over UDP (ptp4l ) is forwarded correctly through the same bridge path. Normal Ethernet traffic (ICMP/ARP) also forwards correctly. Is there any special handling or additional configuration required on the SJA1110 to forward Layer 2 PTP frames (destination MAC 01:1B:19:00:00:00) across bridged ports? Are there any known restrictions on forwarding Layer 2 PTP? Also, is PTP over UDP (ptp4l) fully supported and recommended with the PolarFire SoC GEM, or is Layer 2 the only supported/recommended transport? Any guidance would be appreciated. Re: PTP over SJA1110 Hello @Ankur_pixl , In a typical gPTP / time-aware bridge use case, the switch is not expected to forward all gPTP frames transparently as ordinary multicast traffic. The usual flow is that the switch receives the gPTP frames from the Grandmaster, processes them through the gPTP stack running on the internal Cortex-M7 and then generates its own gPTP frames with the appropriate timestamps towards the connected downstream devices.   SJA1110 is typically configured for the Layer 2 Automotive Profile, where the PTP destination MAC address is 01:80:C2:00:00:0E. This address is used for 802.1AS/gPTP style Layer 2 transport and such frames are normally handled by the switch PTP/gPTP function rather than simply bridged as regular multicast traffic.   Your observation that the ingress counters increase, while the egress counters do not increase, suggests that the Layer 2 PTP frames are received by the switch but are not forwarded through the normal bridge path. One likely explanation is that the used PTP multicast MAC address is matched by the SJA1110 configuration, for example in the General Parameters table, DPI configuration, L2 Lookup Table or another PTP/trap-related configuration item, and the frames are therefore trapped to the host port, most likely to the internal Cortex-M7 host, instead of being forwarded to the expected external egress port.   This would also explain why PTP over UDP and normal Ethernet traffic such as ICMP/ARP are forwarded correctly. These frames do not match the same Layer 2 PTP/gPTP classification rule and are therefore handled as normal bridge traffic.   Please check the following points in your SJA1110 configuration:   1. Which PTP destination MAC address is configured in the switch, especially in the General Parameters table. 2. Whether PTP/gPTP frames are configured to be trapped to the host port. 3. Whether the internal Cortex-M7 host is running a gPTP stack or receiving the trapped PTP frames. 4. Whether the used destination MAC address is 01:1B:19:00:00:00 or 01:80:C2:00:00:0E. 5. Whether the L2 Lookup Table or multicast forwarding configuration contains an entry that forwards this destination MAC to the required external ports. 6. Whether the ingress and egress ports are in the same VLAN and forwarding domain for this traffic.   If your intention is to use SJA1110 as a gPTP/time-aware bridge, then the expected configuration is usually not simple transparent forwarding of the original gPTP frames. The switch should participate in the gPTP timing domain and generate the corresponding gPTP messages towards the connected devices.   If your intention is instead to use SJA1110 only as a plain Ethernet bridge for raw Layer 2 PTP frames, then the PTP trapping/special handling must be disabled or avoided for this traffic, and the corresponding multicast destination MAC address must be explicitly allowed in the L2 forwarding configuration.   Regarding the PolarFire SoC GEM, I cannot make a definitive statement about the recommended or fully supported PTP transport mode for that device. From the SJA1110 point of view, PTP over UDP may be forwarded as ordinary IP/UDP traffic if the bridge path allows it. However, this does not necessarily mean that UDP transport is supported or recommended by the PolarFire GEM driver for hardware timestamping. Please confirm the supported PTP transport and timestamping modes with the PolarFire SoC GEM documentation or with Microchip support.   Best regards, Pavel

Please help identify the genuine discontinued model MPC8306SCVMAFDCA. We purchased two batches of EOL discontinued component MPC8306SCVMAFDCA for repair spare parts, but the two batches appear to be different. The batch year is missing two letters: one is TCTCJX1901, and the other is TCLB2144. Previously, all products in this series have batch numbers starting with TCTC. We are unsure of the authenticity of these two batches. Could experts please help us identify them? Thank you! We have purchased two batches of EOL (End of Life) discontinued devices, MPC8306SCVMAFDCA, for use as repair spare parts.However, it appears that there are differences between the two batches, specifically the absence of two letters at the beginning of the batch year.One batch is labeled TCTCJX1901, while the other is TCLB2144.Previously, all products of this series we have encountered began with TCTC.We are uncertain about the authenticity of these two batches.We kindly request the assistance of experts in identifying their authenticity.Thank you! Re: 帮忙鉴定真伪停产型号MPC8306SCVMAFDCA， help to check the EOL part MPC8306SCVMAFDCA Please contact the DFAE from whom you purchased the device and ask them to work with the CSR team for confirmation. Thanks