S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Area? Hello NXP Support Team, We are implementing HSE-based Secure Boot with SMR on the S32K312 and would like to confirm whether an SMR signature can be permanently stored in the UTEST DCF record area. Our current implementation is as follows: We store a 512-byte RSA-4096 signature in UTEST, starting at address: 0x1B001A00U The occupied address range is: 0x1B001A00 to 0x1B001BFF This region belongs to the UTEST DCF record area. Our project does not require any DCF configuration in this area. Therefore, we are currently considering using the unused DCF record space to store permanent security data, including the public key and the SMR signature. Since the software image and its signature are fixed in our use case, the signature is not expected to change during the product lifetime. In the SMR Entry, we configure the signature reference as follows: smrEntry.pInstAuthTag[0] = 0x1B001A00U; smrEntry.pInstAuthTag[1] = 0U; Our expectation is that, during subsequent Secure Boot verification, HSE will read the 512-byte signature directly from the UTEST address specified by pInstAuthTag[0]. When installing the SMR Entry through HSE_SRV_ID_SMR_ENTRY_INSTALL, we initially configured the installation service authentication tag to reference the same UTEST address: pSmrEntryInstall->pAuthTag[0] = 0x1B000A00U; However, the SMR installation service returned HSE_SRV_RSP_INVALID_PARAM, apparently because the UTEST address was rejected as an invalid input address for the service. As a workaround, before calling the SMR installation service, we copy the 512-byte signature from UTEST into a shared RAM buffer: UTEST 0x1B000A00 | | Copy 512 bytes v Shared RAM buffer We then configure the installation request as follows: pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; The SMR Entry itself still contains: smrEntry.pInstAuthTag[0] = 0x1B000A00U; With this configuration, HSE_SRV_ID_SMR_ENTRY_INSTALL returns success and the SMR Entry is installed successfully. Could you please clarify the following questions? Is 0x1B001A00U a valid address for hseSmrEntry_t.pInstAuthTag[0] on the S32K312? During a subsequent Secure Boot, can HSE_B directly access the UTEST DCF record area and read the signature referenced by pInstAuthTag[0]? Does a successful HSE_SRV_ID_SMR_ENTRY_INSTALL response confirm that the persistent pInstAuthTag[0] address is valid for later boot-time SMR verification, or does the installation service only verify the signature supplied through hseSmrEntryInstallSrv_t.pAuthTag[0]? Is there a difference between the memory regions accepted for: hseSmrEntryInstallSrv_t.pAuthTag[0] and: hseSmrEntry_t.pInstAuthTag[0] In our test, the UTEST address is rejected when used directly as pAuthTag[0], but the SMR installation succeeds when the same signature is copied to RAM while pInstAuthTag[0] still points to UTEST. Could this configuration pass SMR installation but fail during the next reset or Secure Boot because HSE cannot access the UTEST address at boot time? Is the unused UTEST DCF record area allowed to store customer application data such as a public key or an SMR signature when no DCF records are required by the project? Could using this DCF record area cause any conflict with HSE firmware, ROM boot code, future DCF processing, lifecycle transitions, debug configuration, or device configuration scanning? Are there any alignment, record-format, ECC, programming, locking, or access restrictions for storing a raw 512-byte signature in this UTEST area? If UTEST is not supported for pInstAuthTag[0], should the persistent SMR signature always be stored in normal application Code Flash or Data Flash? The main point we would like to confirm is whether the following configuration is officially supported and safe for production: /* Persistent signature location used during Secure Boot / smrEntry.pInstAuthTag[0] = 0x1B000A00U;   / Temporary RAM copy used only during SMR installation */ pSmrEntryInstall->pAuthTag[0] = PTR_TO_HOST_ADDR(signatureRamBuffer);   pSmrEntryInstall->authTagLength[0] = 512U; MCU: S32K312 HSE type: HSE_B Signature algorithm: RSASSA-PSS with RSA-4096 Signature length: 512 bytes Persistent signature address: 0x1B001A00U Thank you. Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar sorry the Signature location is not 0x1B000A00U. it is 0x1B001A00U. Re: S32K312 HSE Secure Boot: Can pInstAuthTag Point to a Signature Stored in the UTEST DCF Record Ar Hi @Yiming2  I tested it on my board because it is not explicitly mentioned in the documentation if UTEST can be used or not. And I got similar results. If pAuthTag = pInstAuthTag = 0x1B001A00, I got HSE_ SRV_ RSP_ INVALID_ ADDR response. Then I placed pAuthTag into RAM memory while pInstAuthTag was pointing still to UTEST and this works. Once secure boot is enabled by BOOT_SEQ bit, secure boot is successful, application is working. HSE is able to read the signature in UTEST DCF area. Based on the test results, HSE firmware obviously checks if address pAuthTag falls within RAM or code/data flash memory while pInstAuthTag in UTEST is accepted. It’s not documented but it works. But if you do not plan to update the signature, an option is to keep HSE_SMR_CFG_FLAG_INSTALL_AUTH zero, so internal verification scheme (internal hash) would be used for verification. Your signature would be used only for installation and pInstAuthTag would be ignored. In my opinion, this setup makes more sense if you do not plan to update the image. Also the verification would be much faster (hash vs. RSA algorithm). This is probably the best way to keep it simple and to get better performance. If HSE_SMR_CFG_FLAG_INSTALL_AUTH is set and pInstAuthTag is used, this targets mainly a use-case when you want to easily update an application: application and authentication tag is updated and you do not need to modify or reinstall that SMR. DCF is scanned up to stop record (all 0xFF’s), the rest is ignored. Normally the DCF area is not supposed to be used for user data but I can’t see a problem here. The only restriction for UTEST is that it is OTP area. And the same ECC limitations apply (like for code or data flash) – once an aligned double word is programmed, you should not program the same double word again because it would cause ECC error. Regards, Lukas

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

关于安装IDE和RTD遇到的问题 你好，我安装了S32DSIDE 3.6.6软件 然后我又安装了RTD包 但是我在新建application project时找不到SDK，如下图 这个问题困扰我很久了，期待回复，谢谢，我的电脑配置如下 电脑上装了JDK 8和JDK17, Python 13 14 15   Re: 关于安装IDE和RTD遇到的问题 谢谢，我发现了这个问题，然后我就想装gcc-10.2，我找到了关于编译器的网页 我不知道使用哪一个，所以我下载了这两个EXE文件进行安装 但是安装完成之后，在S32DS软件中新建工程发现还是没有gcc-10.2 然后我就想在扩展包管理器中下载，但是我试了很多次下载过程中总是报错，无法下载成功，请指导我下一步该怎么做，谢谢~~~ Re: 关于安装IDE和RTD遇到的问题 抱歉，过去两天是周末，这是我今天早上又试着装了一次报的错 Re: 关于安装IDE和RTD遇到的问题 你好@YangLuYao ， 抱歉回复晚了。从图片来看，您似乎正在尝试安装 NXP GCC 6.3.1（版本 1620），但实际上您应该安装 v10.2（版本 1728）： 如果这仍然不起作用，我想你可以尝试从外部安装它：在 S32 设计工作室中安装软件。 我会检查以下几点： 安装过程中网络不稳定。 工作场所的代理/防火墙。 防病毒/网络安全检查。 磁盘空间。 除此之外，我就不确定根本原因是什么了。您可以尝试重新安装 S32DS，然后再次尝试安装 NXP GCC 10.2。 此致， 朱利安

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

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

Unable to Configure Tasks and ISRs in AUTOSAR OS for S32K144 Hi, I am currently integrating the AUTOSAR OS on the S32K144 MCU and have installed the S32K_AUTOSAR_OS_4_0_98_RTM_1_0_0 DTM package. After importing the OS module into EB tresos, I can only see the OSCounter container in the configuration editor. However, the OS User Manual describes additional configuration elements such as Tasks, ISRs, and other OS objects. Could you please clarify: Why are only OSCounter configurations visible in EB tresos? Is there any additional plugin, license, or configuration step required to enable Task and ISR configuration? What is the correct procedure for creating and configuring Tasks and ISRs for the S32K144 AUTOSAR OS? Also I want to configure task, ISR and OS related configuration. Any guidance or example project would be greatly appreciated. Thanks Re: Unable to Configure Tasks and ISRs in AUTOSAR OS for S32K144 Hi @Julián_AragónM , Thank you for your response. Currently I'm using v29.0.0 version of EB Tresos Could you please suggest the appropriate RTD version that is compatible with this EB tresos release? Thank you for your support. Best Regards, Devi Re: Unable to Configure Tasks and ISRs in AUTOSAR OS for S32K144 Hi @Devi_55, SW32K14-OS401-RTM-1.0.0 b4.0.98 is legacy SW and no longer maintained. It is strongly recommended to transition to the newer RTDs (Real-Time Drivers for S32K1). For any further assistance or support, please reach out to your NXP representative.  After installing SW32K14-OS401-RTM-1.0.0 b4.0.98 RTM, I can see all of the included ones below. The release notes for this SW package mentions EB Tresos v21.0.0, pelase confirm you are using this build.   EB tresos Studio 21.0.0 b160607-0933  Best regards, Julián Re: Unable to Configure Tasks and ISRs in AUTOSAR OS for S32K144 Hi @Devi_55, Latest release of RTD for S32K1 (S32K1_S32M24x Real-Time Drivers AUTOSAR R21-11 Version 3.0.0 QLP07) uses EB Tresos v29.0.0: Best regards, Julián Re: Unable to Configure Tasks and ISRs in AUTOSAR OS for S32K144 Hello  I apologize; this was an oversight by my part.  RTD 3.0.0 QLP07 is the crypto release for the RTD drivers, QLP06 contains all of the base drivers (Adc, Can, Os, etc.): Best regards, Julián Re: Unable to Configure Tasks and ISRs in AUTOSAR OS for S32K144 Hello @Julián_AragónM , I have installed the S32K1_S32M24x Real-Time Drivers AUTOSAR R21-11 Version 3.0.0 QLP07 package, which is compatible with EB tresos v29.0.0. However, after reviewing the available plugins, I could not find several expected modules such as OS, ADC, Port, Dio, Spi, Can, Mcu, and other MCAL components. Could you please suggest which RTD/AUTOSAR package I should use if I need access to the complete set of MCAL drivers along with an AUTOSAR OS? If a different version of EB tresos is required for compatibility, I am willing to install and use the recommended version. I would appreciate your guidance on the appropriate package and toolchain for the S32K144. Thank you. Best Regards, Devi

can we do V/f control of a PMSM? I am making a simulink model for PMSM control by V/f method. This model works for an induction motor but the speed output for PMSM coming oscillating, i think the fields are not synchronizing. Am i missing something?

How to Debug Multi Core with TRACE32 on S32K312? Dear NXP Support, I am currently using TRACE32 to debug an S32K312 device. The S32K312 is configured with two cores (Core 0 and Core 1). I can debug Core 0 without any issues, but I am unable to debug code running on Core 1. As shown in the attached screenshot, I set a breakpoint in the source code executed by Core 1. I also added a counter variable, and I can see that its value keeps increasing, which indicates that the code is indeed running. However, the breakpoint is never hit. Could you please advise how to properly configure TRACE32 to debug both Core 0 and Core 1? If there are any additional settings or initialization steps required for multi-core debugging on the S32K312, I would appreciate your guidance. Here is my file cmm  ; -------------------------------------------------------------------------------- ; @Title: Demo script for S32K312-M7 on S32KXXCVB-176 (FLASH) ; @Description: ; Programs the sieve demo application into the processor internal flash and ; sets up a demo debug scenario. ; This script can be used as a template for flashing an application. ; Prerequisites: ; * Connect Debug Cable to J205 ; or ; Connect Combiprobe/uTrace to J10 ; @Keywords: ARM, Cortex-M7, Flash ; @Author: STK ; @Board: S32KXXCVB-176 ; @Chip: S32K312-M7 ; @Copyright: (C) 1989-2021 Lauterbach GmbH, licensed for use with TRACE32(R) only ; -------------------------------------------------------------------------------- ; $Id: s32k312_sieve_flash.cmm 17943 2021-07-12 15:34:31Z skrausse $ ;WinCLEAR ; -------------------------------------------------------------------------------- ; initialize and start the debugger RESet SYStem.RESet SYStem.CPU S32K312-M7 ;SYStem.CPU MWCT2016S-M7 SYStem.CONFIG.DEBUGPORTTYPE JTAG IF COMBIPROBE()||UTRACE() ( SYStem.CONFIG.CONNECTOR MIPI20T ) SYStem.Option DUALPORT ON SYStem.MemAccess DAP SYStem.JtagClock 10MHz Trace.DISable SYStem.Up ; ECC init for the internal SRAM DO C:\T32\demo\arm\hardware\s32k3\scripts\init_sram.cmm ; -------------------------------------------------------------------------------- ; Flash programming ; prepare flash programming (declarations) DO ~~/demo/arm/flash/s32k3.cmm PREPAREONLY FLASH.ChangeType 0x10016000--0x1003FFFF NOP flash.erase.all FLASH.ReProgram ALL ( Data.LOAD.intelhex "project.hex" ;Data.LOAD.auto * ;Data.LOAD.s1record ; Adding IVT header ;Data.Set 0x00400000++0xF0 %Long 0x0 ; Init table with 0 ;Data.Set 0x00400000 %Long 0x5aa55aa5 ; Magic number ;Data.Set 0x00400004 %Long 0x00000001 ; Boot configuration word (enable M7-0) ;Data.Set 0x0040000C %Long ADDRESS.OFFSET(__nvic_base) ; M7-0 application core start adddress ;Data.Set 0x00400024 %Long 0x00000000 ; LC configuration address ) FLASH.ReProgram OFF ; -------------------------------------------------------------------------------- SYStem.Up Break Data.LOAD.Elf "project.elf" /nocode Go.direct main SYStem.Mode Attach TrOnchip.Set CORERESET OFF ; -------------------------------------------------------------------------------- ; open some windows Mode.Hll Thank you for your support. Re: How to Debug Multi Core with TRACE32 on S32K312? Hi @NghiaLX308  Are we really talking about S32K312? Because this is single core device: Regards, Lukas Re: How to Debug Multi Core with TRACE32 on S32K312? Hello Mr @lukaszadrapa  I’m sorry, that was my mistake. The MCU is S32K322. Re: How to Debug Multi Core with TRACE32 on S32K312? I have two versions in my repository - one for S32K324 which opens two instances of Trace32 and second very simple for S32K396 which uses one instance of Trace32 only and then there are two scripts which can be used to switch between the cores. You can use these scripts as a reference to develop own solution.  Regards, Lukas

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

MIMXRT1064CVL5B Custom PCB Flash Failure Hi everyone, I am bringing up a custom board utilizing the MIMXRT1064CVJ5B processor. The board is powered by an external 5V SMPS power supply fed into a 3.3V LDO regulator. I am using a CMSIS-DAP / DAP-Link debug probe to program and debug via the SWD interface inside MCUXpresso IDE. I am encountering a highly specific, repeatable power state crash when attempting to flash my code.   The Symptoms: Instant Power Drop on Connection: When the board is running independently, it works fine and the power LED stays fully illuminated. However, the exact millisecond I connect my DAP-Link probe harness to the board's SWD header, the 3.3V rail collapses, the power LED turns completely off, and the board powers down. This happens before executing any commands or clicking "Debug" in the IDE. Momentary Power Recovery and Crash During Debug: If I leave the probe connected and click the Debug button in MCUXpresso, the board suddenly gets powered back up and the LED turns back on. However, right when the flashing sequence begins, the system freezes at 3% progress with a Wire ACK Fault and a bus hang-up at memory location 0x2000A750. Immediately after this crash, the board powers down again and the LED turns off.   LinkServer Debug Console Log Output: ============= SCRIPT: RT1064_connect.scp ============= RT1064 Connect Script DpID = 0BD11477 APID = 0x04770041 Disabling MPU Configure FlexRAM for 768KB OC RAM, 128KB I-TCM, 128KB D-TCM Finished ====================================================== ... Writing 1322080 bytes to address 0x70000000 in Flash 70008000 done 3% (32768 out of 1048576) request to clear DAP error failed - status 5 After error Nn(05). Wire ACK Fault in DAP access - Failed to read address register in DAP - Nn(05). Wire ACK Fault in DAP access failed to send op Terminate message - rc Em(17). Debug port inaccessible after access at location 0x2000A750 Target error from Commit Flash write: Em(17). Debug port inaccessible after access at location 0x2000A750   What I have tried so far: Hardwired BOOT_MODE[1:0] to 01 (Serial Downloader mode) via physical solder pads to isolate application interference. Target memory spaces are properly mapped to the internal 4MB QSPI flash baseline region at 0x70000000 within the IDE linker properties. The exact same DAP-Link probe seamlessly programs an official NXP MIMXRT1064-EVK kit using identical code and configuration parameters. Why is the connection causing an immediate power drop, why does the board temporarily wake up during debugging, and why does it consistently deadlock at the 3% flash mark? Any guidance on how to reliably program the chip with this layout behavior would be highly appreciated. Thanks! Evaluation Board Re: MIMXRT1064CVL5B Custom PCB Flash Failure if power drop by connecting the probe，the power supply maybe undervoltage since the cmsis probe absorb energy suddenly during connectting. Can you check the power rail in the system？How many current the debugger need？ Re: MIMXRT1064CVL5B Custom PCB Flash Failure Hi @Anushka_SS , Thanks for your interest in NXP MIMXRT series! All three symptoms (power drop when the probe is plugged in → board wakes up when you click Debug → hang at 3%) point to one single root cause: insufficient 3.3V supply margin on the board combined with an SWD/VTref wiring issue, causing a brown-out shutdown — not a software or flash-driver problem. Why we're confident: You've hard-wired BOOT_MODE to Serial Downloader, so the application never runs — this rules out "app occupying the debug pins." The same probe and configuration work fine on the official EVK, so the difference is purely your custom-board hardware. A plain SWD connection draws almost no current, yet it collapses the entire 3.3V rail — this can only mean the probe is loading/back-feeding the 3.3V rail while the LDO trips into over-current protection. About 0x2000A750: this address sits in DTCM (the 0x20000000 region), where the flash algorithm (flashloader) runs. The 3% mark is exactly when continuous writes to the QSPI flash begin and the core + FlexSPI current peaks — the supply can't hold up, the core browns out and resets, hence the Wire ACK Fault. It's simply where the device died on brown-out, not bad memory or a code bug. Best regards, Gavin Re: MIMXRT1064CVL5B Custom PCB Flash Failure Thank you for you reply! Actually I am facing an issue with the power-up and SWD programming of my custom i.MX RT1064 board. I am using a TLV75733PDBV 3.3 V LDO. The LDO input is stable at 5 V, but sometimes the regulator does not produce 3.3 V because its EN pin remains low or has no voltage. The EN pin is controlled directly by the RT1064 through the PMIC_ON_REQ signal. Sometimes PMIC_ON_REQ/EN suddenly becomes about 3.3 V, the regulator turns ON, the 3.3 V rail comes up correctly, and the board power LED starts glowing. However, this behavior is not consistent — sometimes the board powers up, sometimes it does not. When the board is powered correctly and I then connect my MuseLab CMSIS-DAP probe for SWD programming, the 3.3 V rail drops again and the board powers down. At that point I get SWD errors such as: Wire ACK Fault Debug port inaccessible Could not connect to core The measured behavior is approximately: Without probe: U1 IN = 5.0 V U1 EN = 3.3 V (sometimes) U1 OUT = 3.3 V POR_B = 3.3 V After connecting probe: U1 IN = 5.0 V U1 EN = 0 V U1 OUT = around 1.2–1.8 V POR_B = around 2.1 V So it looks like the LDO itself is not losing input power. Instead, the regulator is being disabled because its EN pin goes low. My main questions are: Why is PMIC_ON_REQ from the RT1064 not consistently going high? Is this random power-up behavior caused by the RT1064 power-sequencing or reset circuit? Why does connecting the SWD probe cause PMIC_ON_REQ/EN to go low? Should the 3.3 V regulator EN be controlled directly from PMIC_ON_REQ, or should it be pulled up/handled differently? What is the recommended way to keep the 3.3 V rail stable so that I can reliably power and program the RT1064? Are there any important requirements for POR_B, DCDC_IN, DCDC_OUT, VDD_SNVS_IN, VDD_HIGH_IN, or boot-mode pins that could cause this behavior? I previously made another custom board based on the Teensy 4.1 power circuit, and that board could be programmed successfully using the same CMSIS-DAP probe. The new PCB uses a very similar power circuit, but I added access to the boot-mode pins and changed the reset/power section slightly. I am attaching my regulator section, reset circuit, power-pin connections, and boot-mode schematic. I would appreciate help checking whether the PMIC_ON_REQ/EN connection or RT1064 power-sequencing circuit is incorrect, and what changes are needed to get stable power and reliable SWD programming. Re: MIMXRT1064CVL5B Custom PCB Flash Failure Hi @Anushka_SS , Thank you for providing the schematic. I took a look at it and found a few issues. 1. VDD_SNVS_IN:  It cannot be floating. VDD_SNVS_IN supply must be turned on before any other power supply or be connected(shorted) with VDD_HIGH_IN supply. (Please strictly follow the power-up sequencing specified in the datasheet/RM and verify it on your board.) 2. Furthermore, this 3.3 V supply must not depend on PMIC_ON_REQ, while at the same time being used to power VDD_SNVS_IN. Otherwise, the SNVS domain will be de-energized during a cold start, and the internal state machine will not have a reliable condition to output PMIC_ON_REQ.  Therefore, your LDO cannot power up reliably. PMIC_ON_REQ can only be driven reliably after the RT1064's SNVS/PMU domain is up and running, and the SNVS domain first requires a valid supply on VDD_SNVS_IN. Since VDD_SNVS_IN is left floating on your board, PMIC_ON_REQ behaves erratically — the board powers up only intermittently, and it unexpectedly powers down the moment you connect the SWD probe. In addition, do not drive the LED directly from PMIC_ON_REQ. A power-indicator LED should be placed on the stable 3.3 V rail, or isolated with a buffer/MOSFET. Hanging an LED + 470 Ω to ground on the PMIC_ON_REQ node effectively adds a significant load / pull-down path on this critical power-request pin. If the pin is in a high-Z or open-drain "ON" state, the LED branch pulls EN toward a low level; and even with a push-pull output, it forces this small SNVS-domain control pin to source the LED current — which is not recommended. Best regards, Gavin

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

RTD update issue - MBDT In the S32 Design Studio version 3.6.1, wanted to update the RTD version 7.0.0 but i could only update it to 5.0.0, its showing error when i try updating RTD version 6.0.0 and further.  Eclipse IDE Usage and Settings SDKs Re: RTD update issue - MBDT i have installed the IDE 3.6.10 version, and tried to download the rtd version 7.0.1 but i couldnt, system network is connected properly, and it shows network issues only with this version and when i was working with the previous version 3.6.0 i didnt face any network issues. whenever i am opening the S32 IDE application the message box attached, pops up. If this is the case with changing network preferences, can you tell wat are the things to enable and disable in the settings? and the RTD gets installed, and when i am trying to check with example project (DIO S32k344) it shows the above error as attached,  in creating a new project i could not find any SDK options.  Re: RTD update issue - MBDT Hi @Rathidevi  First, we recommend updating your S32DS installation to version 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 S32DS installation. Detailed instructions are available in the S32 Design Studio 3.6.10 RFP Installation Guide, which can be found on the same download page as the S32DS installer. This update is recommended because RTD 7.0.1 was developed and validated using S32DS 3.6.4. To ensure compatibility and proper functionality, the IDE version should be the same as or newer than the version used for validation. Additionally, this requirement is noted in the Missing Requirements of the shared image. Regarding the RTD 7.0.1 installation, we recommend first uninstalling the currently installed RTD version and then installing RTD 7.0.1. This helps avoid potential conflicts between different RTD versions. BR, VaneB Re: RTD update issue - MBDT Hi @Rathidevi  It seems that the toolchain required by the RTD is missing from your installation. Please install NXP GCC for Arm Release version 10.2 build 1728. This should fix the problems with the examples and should also make RTD 7.0.1 available as an SDK option when creating a new project, as long as GCC 10.2 is selected as the project's toolchain.

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

i.MX8M Nano PTP clock accuracy We are evaluating IEEE 1588 PTP for synchronizing multiple i.MX8M Nano systems that acquire data through the SAI interface. Our synchronization requirement is for the sampling time across multiple units to remain within 2 µs. On our hardware, ENET1_1588_EVENT0_OUT is routed externally back into GPT_CAPTURE1. The intended architecture is: Synchronize the ENET PTP Hardware Clock on each unit using hardware-timestamped PTP. Generate a periodic timing event using ENET1_1588_EVENT0_OUT. Capture that event with GPT to correlate the PTP clock to a local hardware timer. Use the measured relationship between the PTP timebase and the audio clock to adjust the AudioPLL on each slave unit so that its SAI sampling rate tracks the master unit. Maintain both sample-rate synchronization and a known phase/sample-index relationship between units. We found the NXP presentation “i.MX IEEE 1588 1PPS Test”, which shows how to enable the FEC 1588 output and notes that the general procedure applies to the i.MX8M family. However, the presentation demonstrates signal generation only and does not provide any specification or measured result for synchronization accuracy, PPS skew, output jitter, or unit-to-unit phase error. We have also reviewed the i.MX8M Nano datasheet and reference manual, but have not found a guaranteed timing specification for any of the following: Maximum synchronization error between two i.MX8M Nano ENET PTP hardware clocks when using hardware packet timestamping. Timing accuracy or jitter of ENET1_1588_EVENT0_OUT relative to the programmed ENET PTP timer compare value. Unit-to-unit variation in the latency from the ENET PTP timer compare event to the external EVENT0_OUT pin. Total uncertainty when ENET1_1588_EVENT0_OUT is looped back into GPT_CAPTURE1. Expected practical synchronization performance using the NXP Linux BSP and ptp4l. Could NXP provide any guidance on the following? Is there an undocumented characterization result or expected accuracy for the FEC PTP clock and ENET1_1588_EVENT0_OUT? Is the output edge generated entirely in hardware from the ENET PTP timer, with deterministic latency relative to the timer compare? Is the edge timing quantized only by ENET_TIMER_CLK_ROOT, or are there additional asynchronous clock-domain crossings that introduce variable latency? Is there a known maximum uncertainty for GPT input capture when capturing the looped-back event? Has NXP measured PPS-to-PPS skew between two i.MX8M devices synchronized over PTP? Is synchronization within 2 µs considered a reasonable expectation when using hardware timestamping and a controlled wired Ethernet network? Are there recommended ptp4l, FEC driver, clock-tree, or device-tree settings for obtaining the best synchronization accuracy on i.MX8M Nano? Is there any existing NXP example for disciplining the AudioPLL or an SAI media clock from the ENET PTP clock? We plan to verify the implementation experimentally by placing two boards on the same PTP network and measuring the time difference between their ENET1_1588_EVENT0_OUT signals using a two-channel oscilloscope. We would then separately measure SAI frame-clock or sample-clock alignment after implementing the AudioPLL control loop. Would this be the recommended method for characterizing the achievable PTP synchronization accuracy, or is there another internal signal, register, driver statistic, or NXP test method that would provide a better measurement? Any timing characterization data, internal design guidance, relevant application notes, or BSP examples would be appreciated.         i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8M Nano PTP clock accuracy I searched and consult it, for imx8mn, we only validate the IEEE 1588 PTP support, doesn't do any Timing accuracy or latency testing, we can help customer bring up the IEEE 1588 PTP output setup, but couldn't offer these data since we haven't tested it yet

[i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Environment & Hardware Setup Processor / Platform: NXP i.MX95 FRDM Board Camera Module: RPI-CAM-MIPI (AR0144 Sensor + AP1302 Onboard ISP) Firmware Used: ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin (renamed to ap1302_ar0144_single_fw.bin and placed in /lib/firmware/) Issue 1: Pink / Magenta Color Tint from AP1302 ISP I am experiencing a persistent pink / magenta color cast in the decoded images/video streams coming from the AR0144 camera module via the AP1302 ISP. Despite using this tuned firmware file, the decoded frames still exhibit a noticeable pink cast (sample image attached). Is this a known issue with the AR0144 + AP1302 setup? Is there an updated AP1302 firmware binary available to fix this color balance issue? Issue 2: Bypassing AP1302 to Use the i.MX95 Internal NEO ISP The NXP documentation for the RPI-CAM-MIPI camera module states: "The bypassable onboard ISP chip allows it to be used with a wide range of SoCs." Since the i.MX95 features an integrated hardware NEO ISP, we would like to bypass the AP1302 onboard processing and route the RAW Bayer stream from the AR0144 directly into the i.MX95 internal NEO ISP using libcamera and the neo-ipa-uguzzi pipeline handler. Questions for NXP: Is RAW passthrough (bypassing AP1302 hardware processing to feed RAW Bayer directly to the i.MX95 NEO ISP) officially supported on the i.MX95 FRDM board? If yes, could NXP provide the step-by-step configuration required to enable RAW passthrough? How can we acquire or generate the required DTP / YAML tuning files for the AR0144 sensor under the NEO ISP? Does NXP have a pre-calibrated YAML/DTP file available for AR0144 that can be shared? Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP I reproduce this on my imx95 frdm board, doesn't have any color issue, you should set the correctly since you can bring up the camera, just check if your display has any issue or not 1) set the dtb file as imx95-15x15-frdm-ap1302.dtb   2) your firmware is correct 3) use the command gst-launch-1.0 libcamerasrc ! autovideosink Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Hi, Thank you for testing and providing the feedback on Question 1.  Re: Question 2 — Bypassing AP1302 for the i.MX95 Internal NEO ISP Could you please also address my second question regarding bypassing the onboard AP1302 ISP to utilize the i.MX95's internal NEO ISP? Since the RPI-CAM-MIPI board documentation states that the onboard ISP is bypassable, we want to route the RAW Bayer stream from the AR0144 sensor directly into the i.MX95's internal NEO ISP. Could you please clarify: Is RAW passthrough (bypassing AP1302 hardware ISP processing) supported for the AR0144 on the i.MX95 FRDM board in the Linux 6.12.49_2.2.0 BSP release? Device Tree Changes: What exact Device Tree configuration or overlay is needed to bypass the AP1302 ISP block and capture RAW Bayer frames directly on the MIPI-CSI interface? Tuning & YAML Configuration: Does NXP provide the tuning/DTP configuration files for the AR0144 under the NEO ISP pipeline handler? If available, could you share these files or guide us on how to properly set up libcamera and LIBCAMERA_IPA_MODULE_PATH for this workflow? Thank you for your assistance! Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Is RAW passthrough (bypassing AP1302 hardware ISP processing) supported for the AR0144 on the i.MX95 FRDM board in the Linux 6.12.49_2.2.0 BSP release?>couldn't support it as default bsp, you can find the dtb file named ap1302 only Device Tree Changes: What exact Device Tree configuration or overlay is needed to bypass the AP1302 ISP block and capture RAW Bayer frames directly on the MIPI-CSI interface?> refer to the ap1302 dtso file https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-ap1302.dtso isp_en-gpios = <&adp5585_isp 2 GPIO_ACTIVE_HIGH>; this pin is enable ap1302, you can bypass ap1302 by control this pin, hi is for enable, low is for bypass 3.Tuning & YAML Configuration: Does NXP provide the tuning/DTP configuration files for the AR0144 under the NEO ISP pipeline handler? If available, could you share these files or guide us on how to properly set up libcamera and LIBCAMERA_IPA_MODULE_PATH for this workflow? >you can find all of the SW pacakge here https://github.com/nxp-imx-support/imx-camera-sw-pack Re: [i.MX95 FRDM] AR0144/AP1302 Pink Tint Issue & Bypassing AP1302 for NXP NEO ISP Hi, Thank you for the detailed clarification regarding bypass mechanism. Regarding the color issue, I want to clarify that this is not a display or monitor artifact. To be certain, we did not take a photo of the screen; rather, we dumped the raw image/video file directly from the GStreamer pipeline and inspected the saved file on a separate host machine, where the light reddish/magenta pink tint is clearly present in the pixel data. Since we are using the correct DTB (imx95-15x15-frdm-ap1302.dtb) and the official AWB-tuned firmware (ap1302_60fps_ar0144_27M_2Lane_awb_tuning.bin), could you please help us isolate the root cause? Question: Is there a specific test we can run from user space to verify whether this pink tint is caused by a hardware defect in the specific AR0144 camera module unit we have, or if it is a configuration/software issue? Thank you for your continued support!

i.MX 8QXP - LPDDR4 memory compatibility guide Hi Team, We are planning for an alternate for the LPDDR4 for the IMX8QXP. Please let me know if there is any updated list for the compatible LPDDR4 parts. i.MX 8/8X/8XLite - LPDDR4 and DDR3L memory compatibility guide Thanks and regards, Rohith Re: i.MX 8QXP - LPDDR4 memory compatibility guide Hi, Thank you for your interest in NXP Semiconductor products, The list was updated this year, that would be the last compatibility guide. Are you planning to use another memory? Regards Re: i.MX 8QXP - LPDDR4 memory compatibility guide Hi Joseph, We are planning to use a different LPDDR4 due to the lead time and other reasons. Whether NXP will support for validating the Memory? And what is the procedure for validating new memory from NXP side Thanks and regards, Rohith 

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:  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: d) Table 4.7 (Power consumption) from S32K1xx Data Sheet shows power consumption defined in the attached S32K1xx_Power_Modes_Configuration.xlsx: 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

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