Example SJA1110 FreeRTOS lwIP SJA1110-EVM S32DS 3.5 RTD 1.0.2 ********************************************************************************* * Detailed Description: * Updated the example lwip_FreeRTOS_SJA1110 for board SJA1110-EVM * to enable ping from the command window, from all applicable ports * *ping 192.168.0.200 * *Pinging 192.168.0.200 with 32 bytes of data: *Reply from 192.168.0.200: bytes=32 time=2ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 * *Ping statistics for 192.168.0.200: * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), *Approximate round trip times in milli-seconds: * Minimum = 1ms, Maximum = 2ms, Average = 1ms * * Installed packages to S32DS 3.5 update 14: * SW32SJA11xx_S32DS_3.5.0_RFP_D2206.zip * SJA11XX_RTD_4.4_1.0.1_P02_HF01_D2510_DesignStudio_updatesite.zip * SW32SJA1110_XJA11XX_ETH_PHY_4.4_1.0.8_CD01_D2509_DesignStudio_updatesite.zip * SJA11XX_ETH_SWITCH_4.4_1.0.2_CD01_D2509_DesignStudio_updatesite.zip * SW32SJA11xx_FreeRTOS_11.1.0_0.8.0_CD2_D2411_DesignStudio_updatesite.zip * SJA11XX_TCPIP_2.0.0_CD01_D2510_DesignStudio_updatesite.zip * * EVB: * - Except SW15, All DIP switches accordingly to um575112-AH1901 SJA1110 - EVM User Manual(1.2).pdf * - TJA1101 needs to be in Managed Operation, RMII mode (50 MHz output on REF_CLK) * SW15.1-8: ON OFF ON OFF ON OFF OFF ON * * Configuration: * - Updated switch configuration * - Updated phy configuration * - Fixed Mcu/McuModuleConfiguration/McuPowerControlUnit - 1V8 and 2V5 * - Fixed Eth configuration * * * * - TCPIP stack: enabled UDP_ECHO, etc. * - Added Gpio_Dio * - Added nvm_metadata * - MAC learning is disabled * - Added LED control via I2C GPIO expander * (adopted & fixed from SJA1110_gptp_ds example - SW32SJA11xx_M7_gPTP_1_0_0_D2411_DesignStudio_updatesite.zip) * * main.c * - Updated only the header * device.c/h * - adopted from SJA1110_gptp_ds example * test.c * - Removed the code that shuts down the TCP/IP stack after its predefined timeout * - Added LED ALIVE * - Added debug stuff * /board + /pca950x + /swi2c * - adopted from SJA1110_gptp_ds example * * ----------------------------------------------------------------------------- * Test HW: SJA1110-EVM SCH REV B2 * MCU: SJA1110 * Debugger: Lauterbach TRACE32 * Target: RAM or external FLASH (flash_image.bin generated) * EVB connection: any port (excluding SFP cages) <-> RDDRONE T1ADAPT (on ports where applicable) <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11

S32G-VNP-RDB3: Onchip debugging support Hello, I want to debug my AUTOSAR Operating System based application on following environment. 1) Board Name: S32G-VNP-RDB3 2) Microcontroller Variant: S32G399 3) Cortex-M7 Cores 4) Host: Windows Is there any on-chip debugging support enabled in the mentioned board where I can connect without any external debugger or probe. If on-chip debugging support is not available on this board then can I debug with S32 debug probe (H/W) and s32 design studio IDE (S/W) ? With Regards, Madhusudan Gupta Re: S32G-VNP-RDB3: Onchip debugging support Hello, @madhusudangupta007  Thanks for your post. 1. There is no onchip debugger on RDB3, so it is not supported to directly debug the RDB3 via the USB port. 2. Commonly, the Lauterbach TRACE32 Debug is used for debugging the S32G products, besides, the S32 Debug Probe which is provisioned by NXP(S32 Debug Probe | NXP Semiconductors) is also used. 3. Yes, as mentioned before, the S32 debug probe(HW) and S32 Design Studio(IDE) could be used together for debugging the RDB3 board.    BR Chenyin

i2c problems during wakeup frum suspend A question for the experts out there. I have a circuit in which several push-button switches are connected to a GPIO expander. My current system is based on an IMX8MP, to which this GPIO expander is connected via I²C. This expander has an interrupt line to the IMX8MP. Often, when I put the system into suspend mode and press one of the push buttons (the expander is also marked as a wake-up source in the device tree), I receive this message hundreds or even thousands of times as soon as the system comes out of suspend: [ 117.113106] pca953x 3-0076: failed reading register. I know there was already a patch for a similar issue in the i2c-imx.c driver, and I’ve applied it. However, it isn’t having the desired effect. What can I do about this? P.S. It doesn’t happen all the time, but it can be reproduced relatively quickly. Best regards R. Re: i2c problems during wakeup frum suspend I use Kernel Version 6.6.23 Re: i2c problems during wakeup frum suspend Hi @RRD101  Based on your description, it seems like you could try this commit. Also, which kernel version are you using? Best Regards, Zhiming

ADT7420 temperature sensor can't work with frdm_mcxw72 board Hi, i tried to run the adt7420 sample demo with frdm_mcxw board, but the print message is "sensor: device not ready.“ after i flashed the image into the target . the hardware setup like below picture for reference  anliu114036_0-1786010612902.png i think the hardware wiring is ok which i followed below description. anliu114036_1-1786010728607.png and you can find the overlay file which i added the board folder like below anliu114036_2-1786010818065.png i also attached the build log file which can help get more information from it.  can you check it and help solve the issue Re: ADT7420 temperature sensor can't work with frdm_mcxw72 board Hello, hope you are doing well.   From the image you shared, it looks like you are working with a KW47-LOC board, could you please confirm this is the right device? Which Zephyr repo and version you are working with? As you may know, the KW47-LOC board is not directly supported on Zephyr, only the frdm-mcxw72 is. That said, since the chips are compatible, you can work with the frdm-mcxw72 examples and modify the overlay file to adapt it to the KW47-LOC board pins. Checking your overlay configuration, the KW47-LOC board only supports the LPI2C1 module, so you will have to enable the lpi2c1 node in your overlay instead. For the SCL and SDA pins, these are defined in frdm_mcxw72-pinctrl.dtsi as PTB4 and PTB5 for I2C1, I would recommend keeping those since they match the KW47-LOC pins. In order for J2 pin 6 to connect to the target MCU pin PTB4, place J24 2-3 shorted.   Refer to UM12114 for the MikroBUS I2C pinout: Pin 2: INT (Hardware interrupt) on WUU0_P12/PTC7 Pin 5: SCL (I2C clock) on I2C1_SCL Pin 6: SDA (I2C data) on I2C1_SDA   Please also confirm that you have the following configurations enabled in your prj.conf file: CONFIG_I2C=y CONFIG_SENSOR=y CONFIG_ADT7420=y   Best regards, Ana Sofia. Re: ADT7420 temperature sensor can't work with frdm_mcxw72 board Hi Ana Thanks for your support.  Yes, I did work with a KW47-LOC board and try to run the frdm-mcxw72 examples on this board, the Zephyr repo version is v4.4.1. After change the overlay file from I2C0 into I2C1,  it looks the ADT7420 device initialize is ok, but this sensor is still can't read out the right temperature , you can see  below print message from the serial monitor.  anliu114036_0-1786427779708.png here is the latest overlay file and prj.conf file content. anliu114036_1-1786427965565.png anliu114036_3-1786428011874.png Best regards Liu Wei

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:     Zhiming_Liu_2-1785995739657.png diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts index ab7bd4fdaadf..5eb3011f0894 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts @@ -380,7 +380,7 @@ &flexcan1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_flexcan1>; xceiver-supply = <&reg_can1_stby>; - status = "disabled"; + status = "okay"; }; &flexcan2 { @@ -623,23 +623,23 @@ spidev0: spi@0 { }; }; -&micfil { - #sound-dai-cells = <0>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&pinctrl_pdm>; - pinctrl-1 = <&pinctrl_pdm_sleep>; - assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>, - <&scmi_clk IMX95_CLK_AUDIOPLL2>, - <&scmi_clk IMX95_CLK_PDM>; - assigned-clock-parents = <0>, <0>, <0>, <0>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>; - assigned-clock-rates = <3932160000>, - <3612672000>, <393216000>, - <361267200>, <49152000>; - status = "okay"; -}; +// &micfil { +// #sound-dai-cells = <0>; +// pinctrl-names = "default", "sleep"; +// pinctrl-0 = <&pinctrl_pdm>; +// pinctrl-1 = <&pinctrl_pdm_sleep>; +// assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2>, +// <&scmi_clk IMX95_CLK_PDM>; +// assigned-clock-parents = <0>, <0>, <0>, <0>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>; +// assigned-clock-rates = <3932160000>, +// <3612672000>, <393216000>, +// <361267200>, <49152000>; +// status = "okay"; +// }; &mu7 { status = "okay"; @@ -960,19 +960,19 @@ IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x4000031e >; }; - pinctrl_pdm: pdmgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e - >; - }; + // pinctrl_pdm: pdmgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e + // >; + // }; - pinctrl_pdm_sleep: pdmsleepgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e - >; - }; + // pinctrl_pdm_sleep: pdmsleepgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e + // >; + // }; pinctrl_ptn5110: ptn5110grp { fsl,pins = <     system manager modification: diff --git a/configs/mx95evk.cfg b/configs/mx95evk.cfg index 9250d02..6722097 100755 --- a/configs/mx95evk.cfg +++ b/configs/mx95evk.cfg @@ -389,7 +389,7 @@ SYS ALL # Resources M7P OWNER # CPUs must be first -CAN_FD1 OWNER +// CAN_FD1 OWNER FSB READONLY IRQSTEER_M7 OWNER LPIT1 OWNER @@ -612,6 +612,7 @@ CAMERA5 OWNER CAMERA6 OWNER CAMERA7 OWNER CAMERA8 OWNER +CAN_FD1 OWNER CAN_FD2 OWNER CAN_FD3 OWNER CAN_FD4 OWNER   Result: Zhiming_Liu_3-1785995783165.png  

关于安装IDE和RTD遇到的问题 你好，我安装了S32DSIDE 3.6.6软件 3859b5427f61973af225339173048fd.png 然后我又安装了RTD包 YangLuYao_0-1786007576122.png 但是我在新建application project时找不到SDK，如下图 YangLuYao_1-1786007624669.png YangLuYao_2-1786007639499.png 这个问题困扰我很久了，期待回复，谢谢，我的电脑配置如下 YangLuYao_3-1786007691107.png 电脑上装了JDK 8和JDK17, Python 13 14 15   Re: 关于安装IDE和RTD遇到的问题 谢谢，我发现了这个问题，然后我就想装gcc-10.2，我找到了关于编译器的网页 YangLuYao_0-1786064846455.png 我不知道使用哪一个，所以我下载了这两个EXE文件进行安装 YangLuYao_1-1786064901733.png 但是安装完成之后，在S32DS软件中新建工程发现还是没有gcc-10.2 YangLuYao_2-1786065074605.png 然后我就想在扩展包管理器中下载，但是我试了很多次下载过程中总是报错，无法下载成功，请指导我下一步该怎么做，谢谢~~~ YangLuYao_3-1786065134265.png Re: 关于安装IDE和RTD遇到的问题 抱歉，过去两天是周末，这是我今天早上又试着装了一次报的错 YangLuYao_0-1786325441496.png Re: 关于安装IDE和RTD遇到的问题 你好@YangLuYao ， 抱歉回复晚了。从图片来看，您似乎正在尝试安装 NXP GCC 6.3.1（版本 1620），但实际上您应该安装 v10.2（版本 1728）： Julin_AragnM_0-1786577752319.png Julin_AragnM_1-1786577760152.png 如果这仍然不起作用，我想你可以尝试从外部安装它：在 S32 设计工作室中安装软件。 我会检查以下几点： 安装过程中网络不稳定。 工作场所的代理/防火墙。 防病毒/网络安全检查。 磁盘空间。 除此之外，我就不确定根本原因是什么了。您可以尝试重新安装 S32DS，然后再次尝试安装 NXP GCC 10.2。 此致， 朱利安 Re: 关于安装IDE和RTD遇到的问题 嗨@YangLuYao ， 无需下载独立组网 (SA) 工具链。S32DS 已提供 NXP GCC 10.2： Julin_AragnM_0-1786119575796.png 选择工具链后，点击“安装/更新 1 个项目”，点击“下一步”，S32DS 将提示您重新启动。重启后，您应该可以看到它已安装： Julin_AragnM_1-1786119784429.png 如果发现任何错误，能否告知一下？ 此致， 朱利安 Re: 关于安装IDE和RTD遇到的问题 我已经解决了这个问题，谢谢~~

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

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

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 Devi_55_0-1786076176743.png 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. Julin_AragnM_0-1786054248282.png 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: Julin_AragnM_0-1786119367226.png 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.): Julin_AragnM_1-1786379905338.png 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. Devi_55_0-1786339741286.png Thank you. Best Regards, Devi Re: Unable to Configure Tasks and ISRs in AUTOSAR OS for S32K144 Hello @Julián_AragónM  Thank you for your response. I will verify this with the mentioned RTD version. Thanks 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? Re: can we do V/f control of a PMSM? Hello, Indeed the fields may not be synchronizing properly. With an induction motor, the rotor slip induces currents in the rotor windings which produce a natural electro-magentic damping effect. Within a PMSM there is no slip, no induced rotor current like in an induction motor, therefore no inherent damping. The rotor PMs must lock exactly to the rotating stator field. The angle between rotor and stator fields behaves like an undamped pendulum resulting in any disturbance causes the rotor to oscillate around sync position. Options to address this: 1. Add an active damping to your V/f model - you can inject the missing damping by modulating the output voltage or frequency based on estimated speed error: estimate rotor speed using a sensor or a sensorless technique feed d(w_error)/dt back to modulate the V/f output amplitude This is the simplest fix if you want to stay with V/f method. 2. Other option would be to move to I/f control where you control the stator current magnitude at a commanded frequency. More information about I/f control on the following page I-F Controller Hope this helps! Best regards, Stefan.

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: lukaszadrapa_0-1785996399267.png 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 Re: How to Debug Multi Core with TRACE32 on S32K312? I got it. Thank you Mr @lukaszadrapa . 

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

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

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

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. Screenshot 2026-08-06 161612.png 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. Screenshot 2026-08-07 152409.png Screenshot 2026-08-07 152533.png 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.) Gavin_Jia_0-1786518051860.png 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.  Screenshot 2026-08-06 143602.png Eclipse IDE Usage and Settings SDKs Re: RTD update issue - MBDT Screenshot 2026-08-07 101727.png 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? Screenshot 2026-08-07 095218.png Screenshot 2026-08-07 102413.png 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.  Screenshot 2026-08-07 102457.png 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