Clarifications required regarding Fail safe oscillator drift Fault(FS_OSC_DRIFT) Hi Nxp, I have been using FS2613 SBC chip and I found safety requirement (SM48) which is related to Fail safe oscillator drift Fault (FS_OSC_DRIFT). But ASIL level information is not available in reference manual. So, kindly clarify that, this fault comes under either ASIL B/ ASIL D/ QM? Thanks, Sivahari G Re: Clarifications required regarding Fail safe oscillator drift Fault(FS_OSC_DRIFT) Hello Sivahari Good day! The FS_OSC_DRIFT fault (SM48) corresponds to the monitoring of the independent fail-safe oscillator used by the FS26 fail-safe state machine. According to the FS26 Safety Manual, this mechanism is implemented within the ASIL D fail-safe domain. You can find this representation in Figure 8. Safety architecture. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck.

IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hello,     we are bringing up Bluetooth on a Verdin i.MX95 WB running the NXP Android 15 BSP (Linux 6.6.58). The onboard wireless module is a u-blox MAYA-W260 based on NXP IW612. Wi-Fi works correctly over SDIO, and the combo firmware is successfully loaded: Request firmware: sduart_nw61x_v1.bin.se Wlan: FW download over WLAN FW is active ,Bluetooth instead does not appear to work. Whenever we enable it on Android settings, the UI switch is frozen and no BT device is found. Bluetooth is connected to LPUART6 (/dev/ttyLP5). The NXP vendor HAL opens the UART successfully. We initially found that hardware flow control blocked transmission; after temporarily disabling CRTSCTS, the HAL sends the four-byte HCI Reset command: 01 03 0c 00 The UART counters then show: tx:4 rx:0 No response is received from the IW612. The same result occurs with a direct manual UART test at 115200 baud, 8N1, without hardware flow control. Our current configuration is: mchar_port = /dev/ttyLP5 baudrate_fw_init = 115200 enable_download_fw is left disabled because the combo firmware is already downloaded by the Wi-Fi driver. Could you please clarify: After loading sduart_nw61x_v1.bin.se through SDIO, should the IW612 Bluetooth UART respond directly to an HCI Reset at 115200 baud? Is a boot-sleep trigger, wake command, vendor command, or another initialization sequence required first? Is hardware flow control mandatory for IW612, and what should the expected CTS state be after firmware initialization? Should we use the UART firmware-download path with uartspi_n61x_v1.bin.se instead of relying on the combo firmware loaded by Wi-Fi? Is there a recommended bt_vendor.conf for IW612 on i.MX95? Any reference configuration or expected UART trace would be very helpful. Best regards. Android Linux Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  1. After loading sduart_nw61x_v1.bin.se through SDIO, should IW612 Bluetooth UART respond directly to HCI Reset at 115200? In principle, yes — once the combo firmware is active and the BT UART block is awake/ready, the controller should respond to HCI Reset with a Command Complete event. 2. Is a boot-sleep trigger, wake command, vendor command, or other initialization sequence required first? For normal Android bring-up, do not rely only on manually sending HCI Reset. Let the NXP vendor HAL or NXP UART driver perform the initialization sequence. 3. Is hardware flow control mandatory for IW612? What should CTS state be? For a production IW612 BT UART design, hardware flow control should be enabled and correctly wired. Disabling CRTSCTS is useful only as a diagnostic step; it should not be considered the final fix. 4. Should we use uartspi_n61x_v1.bin.se instead of combo firmware loaded by Wi-Fi? You  can have a try with the seperate FW to debug the issue, but it should not the root cause. With combo FW, should also work as expected. 5.Let me have a try on my local side then share to you a worked on my side conf file to you. Please allow me some time. Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  How is your side? I took some time to prepare the environment to build Android 16 source code. Now I can build it, it will need some time to finish building, please allow me some more time. Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi， @vins-idg  Sorry for my late reply and thanks for your patience. I already finished the local test on my side, and now IW612 can work fine on my I.MX95-19*19-EVK. Because there is no Verdin board，I use I.MX95-19*19-EVK to finish the test. Below is the bt_vendor.conf screenshot and also you can see BT can work fine on the right side. In fact, I just use the default bt_vendor.conf and do not modify anything in it. Hope it can help you somehow. bt_vendor.conf.png If it still could not work on your side, please help to provide me your dts and also dmesg logs for further checking. Because here, the community is a public place, to save your security info, you can send your dts file to my private working email: [email protected].  Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  Did you get any chance to read my above comment? How is it going on your side? Please let me know if need any further info from my side. Best regards, Christine. Re: IW612 Bluetooth UART not responding on i.MX95 after combo firmware download Hi, @vins-idg  How is it going on your side? Please let me know if need any further info from my side. Best regards, Christine.

i.MX95 FRDM + OX05B1S: Blue/Purple AR coating reflection on eyeglasses under indoor lighting Board/Setup:  - SoC: NXP FRDM i.MX95   - Camera Sensor: OmniVision OX05B1S (connected via MIPI CSI)  - Pipeline / Software: libcamera (v0.5.2) + NXP Neo IPA (nxpneo) + GStreamer (imxvideoconvert_g2d)  - BSP: i.MX Linux BSP Description: When streaming live video from the OX05B1S camera on the FRDM i.MX95, some of the eyeglasses exhibit a dark blue/purple glare spot under indoor office lighting (see attached images). How can we resolve this dark blue/purple glare artifact on reflective surfaces (like glasses)? What are the recommended Neo ISP tuning parameters or tuning tool version available for i.MX95 to fix this? photo_04.jpg photo_07.jpg Re: i.MX95 FRDM + OX05B1S: Blue/Purple AR coating reflection on eyeglasses under indoor lighting Hi @JosephAtNXP, Thank you for the quick response and the insights regarding the lens flare, tone mapping, and black level configurations. We do not currently use a third party for ISP tuning. We are using the tuning file provided by NXP for the OX05B1S sensor, which we found located at /usr/share/libcamera/ipa/nxp/neo/ox05b1s.yaml in our BSP. Is it possible for NXP to provide a newly updated tuning file for the OX05B1S that mitigates this specific lighting artifact? If an updated file isn't available, could you guide us on the exact parameter changes we should manually adjust in our existing ox05b1s.yaml file to fix this issue? Looking forward to your guidance. Regards, Akash H Re: i.MX95 FRDM + OX05B1S: Blue/Purple AR coating reflection on eyeglasses under indoor lighting Hi, Thank you for your interest in NXP Semiconductor products, From the attached image, the dark spots seem like lens flares captured from a specific angle and reflected probably by blue light filters in your glasses. Dark tones might be product of ISP tone mapping or black level configs. I would suggest ISP tuning the sensor, JosephAtNXP_0-1785175157838.png In your projects, are sensors tuned by you or third parties? Regards Re: i.MX95 FRDM + OX05B1S: Blue/Purple AR coating reflection on eyeglasses under indoor lighting Hi @akashhalli, Could you please try with uGuzzi IPA and share the results? Please share the BSP you are using as well. Try with latest BSP and share if you see any different results. Regards, Re: i.MX95 FRDM + OX05B1S: Blue/Purple AR coating reflection on eyeglasses under indoor lighting Hi @akashhalli, Did you get any chance to test my suggestions? Could you please create a technical case for follow up? Regards, Re: i.MX95 FRDM + OX05B1S: Blue/Purple AR coating reflection on eyeglasses under indoor lighting Hi @JosephAtNXP , The current BSP we are using is Linux 6.12.49_2.2.0. Regarding testing with uGuzzi IPA, the camera we were using has unfortunately gone bad, so we are currently unable to perform the requested test. We will repeat the test with a working camera setup and share the results once it is available. We will also check with the latest BSP and update you if we observe any differences. Regards, Akash

S32K144W SDK installed but not available when creating a project Hello, I am having the same problem described in this topic. I am working with an S32K144W. My S32 Design Studio version is: S32 Design Studio for S32 Platform Version: 3.6.10 Build id: 260720 When I create a new S32DS Application Project, select the S32K144W processor, and click the SDK button, no SDK is available. The strange thing is that I have already installed the SDK. It does appear in the SDK Management, so apparently the installation was successful. micael_arkmeds_0-1786395593570.png Figure 1 – SDK Management showing that the SDK is installed. However, when I create a new S32DS Application Project and select the S32K144W, the SDK is not available. micael_arkmeds_2-1786395688395.png Figure 2 – S32K144W selected in the New S32DS Application Project wizard. When I click the SDK button, the list is completely empty: micael_arkmeds_3-1786395712528.png Figure 3 – SDK selection window showing no available SDK. I have been looking for a solution to this problem for quite some time. I also followed the official offline installation procedure described here: https://community.nxp.com/t5/S32-Design-Studio-Knowledge-Base/HOWTO-offline-install-S32K3-RTD-4-0-0-in-S32DS-v3-5/ta-p/1968014 However, this did not solve the problem. So, I would like to understand what exactly is required for an SDK to become available in the project creation wizard for the S32K144W. Is there a specific SDK/RTD version that is compatible with S32 Design Studio 3.6.10 and the S32K144W? Is there any additional package or configuration that I need to install? The fact that the SDK appears in SDK Management, but does not appear when creating a project, makes me think that the SDK is installed but is not being recognized as compatible with the selected processor/project. If anyone has already solved this issue with the S32K144W, I would really appreciate it if you could explain the exact steps. Thank you! Re: S32K144W SDK installed but not available when creating a project Solved! I finally found the solution to this issue. Even though the RTD 3.0.0 was already installed and appeared in SDK Management, it was not available when creating a new project. The solution was to install: NXP GCC for Arm Release version 10.2 build 1728 Then, when creating the project, I selected GCC 10.2 as the project's toolchain. After doing this, RTD 3.0.0 appeared correctly as an available SDK option. 2026-08-10_18-14.png 2026-08-10_18-14_1.png My environment is: S32 Design Studio for S32 Platform 3.6.10 Build id: 260720 S32K144W RTD 3.0.0 NXP GCC for Arm 10.2 build 1728 So, if someone has the same problem where the SDK appears in SDK Management but does not appear in the project wizard, make sure that the corresponding NXP GCC 10.2 toolchain is installed and selected. This solved the problem for me.

S32K144如何开辟一段内存地址 实现独立变量的存储 恩智浦官方的技术人员你们好 我在开发S32K144芯片的过程中遇到了一个问题 Ni__0-1786350352171.png 以上述地址说明为例  我想单独开辟出一段地址 来存放一些全局变量 1.可以实现掉电保存 擦除和改写的功能 2.还有在程序运行的过程中还要可以参与逻辑运算 3.在编译生成srec文件后 可以将这段地址内容数据截取出来 我不清楚  将这些变量放在哪个地址段合适 地址分配的编程语法该怎么写  应该怎么改写工程内部的 Linker_files文件夹中的.ld文件 有没有  这方面的参考资料 提供学习 我对  S32K144芯片的开发还存在不懂的地方 对于 Linker_files文件夹中的.ld文件 flash分配  用语法该怎么写  为什么这么写  我还不知道 我想能得到这方面的知识  能有一个官方明确 正确的 语法规范和内部逻辑说明 以提供学习 衷心期待您的回复    万分感谢！ Re: S32K144如何开辟一段内存地址 实现独立变量的存储 Hi@Ni_ 请下次务必使用贵司的邮箱账户进行提问，对于通用邮箱，例如QQ,163,GMAIL等邮箱账户，我们不会优先处理。 我先回答你的第一个问题： 我以RTM版本提供的链接文件为例，其实在该链接文件中已经告知该如何实现划分独立的地址空间用于自定义数据存储。 细看“m_data_2”,其先在MEMORY定义地址空间范围 （这里你可以自己划分内存，例如你可以把m_text再划分为更多的其它自定义空间，注意其实地址和范围） /* Specify the memory areas */ MEMORY { /* Flash */ m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000400 m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010 m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x0007FBF0 /* SRAM_L */ m_data (RW) : ORIGIN = 0x1FFF8000, LENGTH = 0x00008000 /* SRAM_U */ m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00007000 } 其次在SECTIONS中定义：".customSection"，其属于m_data_2。 /* Custom Section Block that can be used to place data at absolute address. */ /* Use __attribute__((section (".customSection"))) to place data here. */ .customSectionBlock ORIGIN(m_data_2) : { __customSection_start__ = .; KEEP(*(.customSection)) /* Keep section even if not referenced. */ __customSection_end__ = .; } > m_data_2 最后使用“customSection”的时候，可在程序中定义变量： __attribute__((section (".customSection"))  unsigned int i = 0; 变量“i”会被放置在“customSection”中，可以通过编译后的xx.map文件来查看变量“i‘所在的地址是否正确。 你的第二个问题是关于掉电保存数据，这个你完全可以通过S32K1的EEPROM实现，可参考该链接文章。 https://mp.weixin.qq.com/s?__biz=MzI0MDk0ODcxMw==&mid=2247486584&idx=1&sn=3b8651b928edd19c642b17838a8c75bd&chksm=e91248fede65c1e87214ce913baab45431f816d0bfd0362e00aea1ed4232f200d5ae2720cd71&scene=21#wechat_redirect

Can I use the same IRQ for multi core Hi helper I am using S32K358 multi core. Using Eirq for io interrupt. I have a question: I want core0 use eirq0 and core2 use eirq1 But the two irq channel trigger the same IRQ handler SIUL2_EXT_IRQ_0_7_ISR So there is the problem. If eirq0 and eirq1 both come. The Both core trigger  SIUL2_EXT_IRQ_0_7_ISR. Both core operate the same register. It will be cause bad software expectation.It will clear other non-init channel.   Do I understand OK?   please give me a help. Brs   Re: Can I use the same IRQ for multi core Hello @Licunhao , Your understanding is partially correct. On S32K3 devices, the SIUL2 external interrupt inputs are grouped into interrupt vectors. Therefore, EIRQ0 and EIRQ1 belong to the same interrupt group and are handled by the same grouped interrupt handler, for example SIUL2_EXT_IRQ_0_7_ISR. So, EIRQ0 and EIRQ1 cannot be used as two fully independent interrupt vectors. If the same SIUL2 interrupt group is routed or enabled on more than one core, both cores may enter the same interrupt handler and access the same SIUL2 registers. This can lead to unexpected behavior if the software does not implement proper multicore synchronization and ownership of the SIUL2 interrupt group. However, the SIUL2 interrupt flags are still available per individual EIRQ channel. A correct interrupt handler should check which EIRQ flag is pending and clear only the corresponding flag bit. The status flags should not be cleared globally or with an incorrect mask, otherwise another pending EIRQ flag could be affected. For a multicore application, I would recommend one of these approaches: Assign the whole SIUL2 interrupt group, for example EIRQ0 to EIRQ7, to one core only. This core should handle the grouped ISR and, if needed, notify another core by software or inter-core communication. If you need independent interrupt routing to different cores, use EIRQ channels from different SIUL2 interrupt groups, for example one channel from EIRQ0 to EIRQ7 and another channel from EIRQ8 to EIRQ15, if this is possible with your pin configuration. If both cores must access the same SIUL2 registers, the access must be protected by a proper multicore synchronization mechanism. But in general, a single-owner model for the SIUL2 interrupt group is cleaner and safer. Best regards, Pavel

S32K322 could not view registers when an error occurs Hi NXP Technology Team, The current software version of my project will malfunction after running for a period of time. However, when I try to view the registers, I am unable to do so and the simulation has been disconnected. The screenshot from Lautbach is attached below. I have checked that the 3v3 and 1v5 power supplies for the chips are all normal and show no abnormal waveforms. My situation seems to be similar to that of a previous post.@https://community.nxp.com/t5/S32K/S32K3-core-power-down-error-amp-running-bus-error/m-p/1853122 Could you please tell me how to troubleshoot and solve this problem? RTD version is SW32K3_S32M27x_RTD_4.4_4.0.0_P24_D2405, and it is located in the EB Tresos AUTOSAR. Johnson97_0-1786334605174.jpeg

External Data Abort when calling Clock_Ip_Init() Hi there, I'm attempting to initialise some peripheral clocks using the RTD and S32 DS mex tool. (Note im generating the code in a M7 project, but actually building and running for a A53 project) However, an external data abort occurs inside Clock_Ip_Init(). Specifically, the call stack looks like this: Clock_Ip_Init -> Clock_Ip_InitClock() -> Clock_Ip_DisableCmuFcFceRefCntLfrefHfref(). This appears to be the first attempt to actually write to the CMU peripheral memory. The fault occurs on a LDR instruction on memory 0x4005'C028 which according the S32G3 memory map correctly resides within the CMU memory area. At this stage, the MMU is not enabled, but my understanding is an external data abort occurs outside the CPU/MMU and is probably linked to secure access or a "locked" peripheral. Am i right in saying the CMU needs to be made "accessible" from the A53 core in some manner prior calling Clock_Ip_Init()? If so, could you advise on the steps to do so? Best regards, Jonny Device = S32G399A Compiler = S32DS_GCC _11_4 Core = Cortex A53 Re: External Data Abort when calling Clock_Ip_Init() Hi，jonnyWHIS Thank you for contacting us. Do you intend to create bare-metal code running on the S32G A53 core in the S32DS IDE? BR Joey

DSPI Communication timeout issue I am using the MPC5775B microcontroller with an SPI EEPROM. In my application, CAN messages are received continuously using interrupts, and SPI communication with the EEPROM is also interrupt-driven. Under heavy CAN bus traffic (e.g., five CAN IDs are received every 1 ms), any EEPROM read operation starts timing out. I am using the DSPI_MasterTransferBlocking() API with a timeout of 10 ms. I also tried increasing the timeout value significantly, but the read operation still fails. Interestingly, the behavior depends on the amount of data being read. When I attempt to read only a few bytes from the EEPROM, the SPI transfer times out. However, when I read an entire EEPROM page (256 bytes), the read operation completes successfully. I also observed that if CAN traffic is stopped, the EEPROM read operation succeeds without any issues. I verified the interrupt priorities, and both the CAN and SPI interrupts are configured with the same priority level (priority 0). I would like to understand: Why do small SPI EEPROM read operations time out under heavy CAN interrupt load, while larger (256-byte) page reads complete successfully? Could this be related to interrupt starvation, the implementation of DSPI_MasterTransferBlocking(), or the interaction between the CAN and DSPI interrupt handlers? Is there any known limitation or recommended configuration for using interrupt-driven DSPI transfers concurrently with high-frequency CAN interrupts on the MPC5775B? Additionally i debugged the issue by placing break points inside the DSPI_MasterTransferBlocking(),during the debug  status_t DSPI_MasterTransferBlocking(dspi_instance_t instance, const void * sendBuffer, void * receiveBuffer, uint16_t frames, uint32_t timeout) { DEV_ASSERT((uint32_t)instance < (SPI_INSTANCE_COUNT + DSPI_INSTANCE_COUNT)); status_t status; dspi_state_t * state = DSPI_state[instance]; if (state->status == DSPI_IN_PROGRESS) { return STATUS_BUSY; } state->isBlocking = true; (void)OSIF_SemaWait(&(state->dspiSemaphore), 0); status = DSPI_MasterTransfer(instance, sendBuffer, receiveBuffer, frames); if (status == STATUS_SUCCESS) { status = OSIF_SemaWait(&(state->dspiSemaphore), timeout); if (status != STATUS_SUCCESS) { (void)DSPI_AbortTransfer(instance); state->status = DSPI_TRANSFER_FAIL; return status; } } return STATUS_SUCCESS; } dspi transfer status getting success, but "OSIF_SemaWait" after dspi transfer getting timeout. Re: DSPI Communication timeout issue Hello, Based on the description, the DSPI transfer itself appears to be started successfully, because DSPI_MasterTransfer() returns STATUS_SUCCESS. The timeout occurs later while DSPI_MasterTransferBlocking() is waiting on OSIF_SemaWait() for the transfer-complete notification. Therefore, this symptom is more likely related to the interrupt/completion handling path than to a basic DSPI start failure. In the blocking DSPI API, the transfer is started and the caller waits until the DSPI interrupt/callback path releases the semaphore. If the semaphore is not released before the timeout expires, the API reports timeout and aborts the transfer. The fact that the issue appears only under heavy CAN interrupt load is an important clue. If CAN and DSPI interrupts are configured with the same priority, continuous CAN interrupt activity can delay DSPI interrupt servicing. For short EEPROM reads, the DSPI transaction completes very quickly, so the final DSPI interrupt and semaphore release are timing-sensitive. A longer 256-byte page read keeps the DSPI transaction active for longer and may allow the driver’s interrupt handling path to progress differently, which can explain why the larger transfer completes while the short transfer times out. Recommended checks: Configure the DSPI interrupt with higher priority than the CAN RX interrupt and repeat the test. Keep the CAN ISR as short as possible. Move CAN frame processing out of the ISR into a task/main-loop context if possible. Verify that the DSPI ISR is entered in the failing case. Verify that the DSPI transfer-complete callback or completion path releases state->dspiSemaphore. Toggle GPIOs or use trace points in: CAN RX ISR entry/exit DSPI ISR entry/exit DSPI transfer-complete callback before and after OSIF_SemaWait() Check that the blocking DSPI API is not called from an ISR or from any context where the DSPI interrupt cannot run. As a diagnostic experiment, try a polling-based DSPI transfer or DMA-based DSPI transfer. If polling/DMA works under the same CAN load, it further supports that the issue is in interrupt scheduling/completion handling rather than in the SPI bus itself. For EEPROM accesses, also confirm that the small-read sequence keeps the required command/address/dummy/read phase and chip-select behavior according to the EEPROM protocol. However, since the failure is reported at the semaphore wait, the first focus should be the DSPI completion interrupt path. In summary, the most likely direction is interrupt starvation or missed/delayed DSPI completion handling under high CAN interrupt load. The first practical test should be to raise the DSPI interrupt priority above CAN and instrument whether the DSPI ISR/callback posts the semaphore in the failing case. Best regards, Peter Re: DSPI Communication timeout issue Hello Peter, I tried changing the interrupt priorities as suggested. I configured the CAN interrupt priority to 10 and the DSPI interrupt priority to 1, but I am still seeing the same issue. Could you please help me with implementing DMA for SPI on the MPC5775B? If possible, could you share an example implementation or reference code for this MCU, along with the required DMA/SPI configuration settings? An example with the relevant configuration would be very helpful for us to understand the correct implementation. Thanks in advance for your support.

PPF0900AMBA1ES Hi NXP team, I'm working on a custom board based on the i.MX95 (MIMX9596, 19x19 package, LPDDR5), using the PPF0900AMBA1ES PMIC. Could you please confirm: 1.Does this part number ship with OTP already programmed, or is it a non-programmed engineering sample? 2.If it is non-programmed, what is the recommended procedure to program (or emulate) the OTP configuration for bring-up and evaluation purposes? 3.Is a reference OTP configuration file (.CFG) available for an i.MX95 + LPDDR5 (19x19) implementation that we could use as a starting point? For context, our schematic closely follows the i.MX95 EVK reference design (PF09 + PF5301 + PF5302), and we're currently doing initial power-on bring-up. Thank you. PMIC Re: PPF0900AMBA1ES  PPF0900AMBA1ES is OTP part which mean had already done OTP. https://www.nxp.com/docs/en/supporting-information/MPF0900AMBA1ES.zip OTP file please download from above link.

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

FRDM-MX95 PRO software packages? I was wondering what OS software packages will be available for the MX95 PRO?  Will Android AAOS be available for it as a demo image?  Is there anyone we can communicate with about what will specifically be available? Re: FRDM-MX95 PRO software packages? currently, only linux 6.18.20_2.0.0 demo images for imx95 frdm pro Embedded Linux for i.MX Applications Processors | NXP Semiconductors you can download demo images from the link above, for android, I checked the board file, the latest android 16.0.0_2.0.0 is based on kernel 6.18.20_2.0.0, so should support frdm pro, but this version android hasn't verified on this board yet, only 19x19 evk and 15x15 frdm joanxie_0-1785570929815.png Re: FRDM-MX95 PRO software packages? Any news if we will get android automotive on the frdm-mx95 or would we have to upgrade to frdm-mx95 pro version? Re: FRDM-MX95 PRO software packages? let me confirm auto android team again, the owner is on vacation, and come back office in next week, any update I will let you know it Re: FRDM-MX95 PRO software packages? refer to the link as below https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/android-automotive-os-for-i-mx-applications-processors:ANDROID-AUTO auto android demo images are only for imx95 19x19 evk Re: FRDM-MX95 PRO software packages? Are there any plans for android or AAOS?  Seems weird that the FRDM MX95 Pro wouldn't have an AAOS version especially since the Evaluation board 19x19 has been discontinued and benched.  Is there a reason the pro being a 19x19 processor wouldn't work as the evaluation board. Re: FRDM-MX95 PRO software packages? Thanks. There seems to be a genuine lack of Android automotive support. The frdm has a lot of potential but without additional support from nxp we are left on our own. From my understanding the evk has been dropped from support from toradex and discontinued. With the frdm pro having the same hardware there should be some support. We need the BSP which would make building the images a lot easier. Re: FRDM-MX95 PRO software packages? Is there any way i can contact them to ask a question? Or could they give us some instructions on how to compile the new frdm pro board, maybe they can provide the board package file to make it easier for us to compile? Re: FRDM-MX95 PRO software packages? unfortunately, got information from auto android team that they haven't any plan to support any imx95 frdm board Re: FRDM-MX95 PRO software packages? since they don't have plan to support this yet, I don't think they can offer any packages to build

Error reporting module MCU: S32K148 in 144 pin package RTD version: SW32K1_S32M24x_RTD_4.4_3.0.0_QLP03_D2507 S32 DS Version: 3.6.6 Target OS: Bare Metal Host OS: Windows With the above, I cannot find a module called "ERM" (or anything similar) in the driver module. I have looked in both both MCAL and Non-MCAL modules. Is the ERM supported as a driver module or should the user manipulate raw pointers, as it used to be with the older 'Processor Expert' based framework? Re: Error reporting module Hello @VaneB  Thank you for the follow up. So what you are saying is that these modules are supported in the SPD drivers only and not the freely available RTD. Is that right? Is there any reason why someone cannot use these modules just by bit-banging the registers of the module directly? I tried an example for the 'Processor Expert' driver model (using S32 DS v2.2) and it seemed to work. Re: Error reporting module Hi @durga_choudhury  For S32K1 devices, the Safety Peripheral Drivers (SPD) are available. These drivers include the Extended Microcontroller Error Manager (eMCEM), which supports memory error injection and detection through the Error Injection Module (EIM) and Error Reporting Module (ERM) hardware modules. For further information regarding the SPD, please contact your NXP representative or one of our authorized distributors in your region (Distributor Network | NXP Semiconductors). BR, VaneB Re: Error reporting module Hi @durga_choudhury  Yes, your understanding is correct. They are provided as a separate software package and is not included as part of the RTD. Regarding the reason for this separation, I am currently reviewing internaly. However, it is important to note that SAF and SPD were developed as safety-oriented software components in compliance with the ISO 26262 functional safety standard. This enables their integration into applications requiring functional safety support up to ASIL D. Re: Error reporting module Thank you very much for the update.

DUOX PKOC Good afternoon, I am trying to get a DUOX card to support the PKOC credential format.  Is there any doucumentation available for this?  I have the NFC Document from PKOC but it only shows the APDU structure to get the credential.  I cannot find any documentation for how the actual chip has to be programmed.  I have tried many steps and they all have failed.  The one that I am trying now uses the AppMasterTempKey in the application so the application can be a true ECC only application.  I was able to create the tempkey but the documentation is kind of confusing on how to disable it. Under Section 7.8.5.2.2 AppMasterTmpKey of the documentation the following is what is confusing.  Under section KeyChange it states in the first line it states that the temp key is not changeable with ChangeKey or ChangeKeyEV2.  So my question is how do I disable this TempKey so that it is a true ECC Application? I have tried changing the key to disable it as the docuentation states but I keep getting a 9D error.  Any help would be greatly appreciated. Steve Re: DUOX PKOC Have you tried the NXP RFIDDiscover software? Re: DUOX PKOC unfortunately, the information about the PKOC credentials on the DUOX is not available now. 

How install S32K144EVB SDK in S32 Design Studio Hello, Today, I have installed S32 Design Studio to evaluate a S32K144EVB board. I would like to run a small test, but reading manual, when I create a New Application Project, when I click over "SDK" button, it doesn't appear any S32 SDK. How I can install a SDK for my board Thanks. Re: How install S32K144EVB SDK in S32 Design Studio Hi @ptcaos  First, you need to download the software version that is compatible with your S32DS IDE. The supported IDE version is specified in the software's Release Notes document. For this example, I will use the latest RTD release available for S32K1 devices: Download S32K1_S32M24x_RTD_R21-11_3.0.0_D2503_DesignStudio_updatesite.zip. This package can be found under Real-Time Drivers for S32K1 → Automotive SW - S32K1_S32M24x - Real-Time Drivers for Cortex-M → S32K1_S32M24x Real-Time Drivers AUTOSAR R21-11 Version 3.0.0. In S32 Design Studio 3.6.x, navigate to Help → S32DS Extensions and Updates. In the S32DS Extensions and Updates window, click Add Update Site in the lower-right corner. Select the .zip file downloaded previously. Once added, the package will appear in the list of available extensions and updates. Select the packages you would like to install and click Install/Update. Accept the license agreement and click Finish. Upon successful installation, S32DS will prompt you to restart the IDE for the changes to take effect. Important: When creating a new project, make sure to select a toolchain version that is compatible with the installed RTD package. For example, RTD 3.0.0 was developed and tested using NXP GCC 10.2.0. This information is available in the corresponding Release Notes document.  BR, VaneB Re: How install S32K144EVB SDK in S32 Design Studio Spoiler (Highlight to read) Hello @VaneB  I have installed  S32K1_S32M24X Real-Time Drivers Version 3.0.0 QLP07 doing the same procedure you described but when I create a "New S32DS Application Project", there is no SDK available. I attatch two screenshots: one taken in the processors selection menu and another one taken after pressing "SDK" button. processor.png sdk empty.png Thanks. Hello  I have installed S32K1_S32M24X Real-Time Drivers Version 3.0.0 QLP07 doing the same procedure you described but when I create a "New S32DS Application Project", there is no SDK available.I attatch two screenshots: one taken in the processors selection menu and another one taken after pressing "SDK" button.Thanks. Re: How install S32K144EVB SDK in S32 Design Studio Hello @ptcaos , I had exactly the same problem, and the solution suggested by @VaneB  worked for me as well. I installed NXP GCC for Arm Release version 10.2 build 1728, and then, when creating the project, selected GCC 10.2 as the toolchain. After that, RTD 3.0.0 became available as an SDK option. 2026-08-10_18-14.png 2026-08-10_18-14_1.png So the important point seems to be that installing the RTD alone is not enough — the compatible GCC 10.2 toolchain also needs to be installed and selected. Thanks to NXP TechSupport for the solution! Re: How install S32K144EVB SDK in S32 Design Studio Hi @ptcaos  Please install NXP GCC for Arm Release version 10.2 build 1728. This should make RTD 3.0.0 available as an SDK option when creating a new project, as long as GCC 10.2 is selected as the project's toolchain.

MINISASTOCSI Latest Schematics Hi Team, Could you please help to share MINISASTOCSI latest schematics? Re: MINISASTOCSI Latest Schematics Hi @ramkrish, The most recent revision of the MINISASTOCSI board is A1. I have just sent the file to your email address for your reference. Please let me know if you have any trouble receiving it or if you need any additional information related to this board revision. Best regards, Chavira Re: MINISASTOCSI Latest Schematics Hi @Chavira Received, Thanks

How to obtain the correct Frame Pointer (FP) for DumpCallStack on S32K3 using the GHS compiler? Hi everyone, I am working on an S32K3 MCU using the Green Hills Software (GHS) compiler, and I am implementing a DumpCallStack function. To obtain the frame pointer (FP), I am using the following inline assembly: __asm volatile ("mov %0, r7" : "=r" (locals.fp)); However, the value I get for locals.fp is 0x02B1, which does not appear to be a valid frame pointer. It is not aligned and does not point to a valid stack location, so the call stack cannot be unwound correctly. My questions are: What is the correct way to obtain the current frame pointer when using the GHS compiler on the S32K3 (Arm Cortex-M7)? Does the GHS compiler always use R7 as the frame pointer, or can it omit the frame pointer or use another register depending on the optimization level? Are there any compiler options that must be enabled to preserve the frame pointer for stack unwinding? Is there a recommended GHS-specific API or intrinsic for retrieving the frame pointer instead of using inline assembly? If anyone has implemented stack unwinding or a DumpCallStack function with the GHS compiler on S32K3, I would appreciate any guidance or examples. Thank you! Re: How to obtain the correct Frame Pointer (FP) for DumpCallStack on S32K3 using the GHS compiler? Hi, I would not assume that R7 is always used as the frame pointer. Depending on the GHS version, optimization level, and compiler options, the compiler may use a different register or omit the frame pointer entirely and use R7 as a general-purpose register. The value 0x02B1 suggests that R7 might not be acting as a frame pointer in your build.  Please check the generated assembly and verify whether GHS is creating frame records at all. If frame pointers are enabled, you should see a consistent function prologue saving/restoring the frame pointer; otherwise stack unwinding based on R7/R11 will not be reliable. Since this is primarily a compiler-specific question, I would also recommend contacting Green Hills Software support. They can advise on: Whether GHS uses R7, R11, or another register as the frame pointer for your target/configuration. Which compiler options preserve frame pointers. Whether there is a recommended intrinsic or API for obtaining the current frame pointer. Preferred methods for implementing call stack unwinding with GHS. They are best positioned to provide guidance specific to your compiler version and settings. BR, Petr Re: How to obtain the correct Frame Pointer (FP) for DumpCallStack on S32K3 using the GHS compiler? Sure

PTP over SJA1110 Hi, We are debugging PTP on a PolarFire SoC GEM connected through an SJA1110 switch. We observe that: PTP over Layer 2 (ptp4l -2) is received by the switch (ingress counters increase), but it is not forwarded (egress counters do not increase). PTP over UDP (ptp4l ) is forwarded correctly through the same bridge path. Normal Ethernet traffic (ICMP/ARP) also forwards correctly. Is there any special handling or additional configuration required on the SJA1110 to forward Layer 2 PTP frames (destination MAC 01:1B:19:00:00:00) across bridged ports? Are there any known restrictions on forwarding Layer 2 PTP? Also, is PTP over UDP (ptp4l) fully supported and recommended with the PolarFire SoC GEM, or is Layer 2 the only supported/recommended transport? Any guidance would be appreciated. Re: PTP over SJA1110 Hello @Ankur_pixl , In a typical gPTP / time-aware bridge use case, the switch is not expected to forward all gPTP frames transparently as ordinary multicast traffic. The usual flow is that the switch receives the gPTP frames from the Grandmaster, processes them through the gPTP stack running on the internal Cortex-M7 and then generates its own gPTP frames with the appropriate timestamps towards the connected downstream devices.   SJA1110 is typically configured for the Layer 2 Automotive Profile, where the PTP destination MAC address is 01:80:C2:00:00:0E. This address is used for 802.1AS/gPTP style Layer 2 transport and such frames are normally handled by the switch PTP/gPTP function rather than simply bridged as regular multicast traffic.   Your observation that the ingress counters increase, while the egress counters do not increase, suggests that the Layer 2 PTP frames are received by the switch but are not forwarded through the normal bridge path. One likely explanation is that the used PTP multicast MAC address is matched by the SJA1110 configuration, for example in the General Parameters table, DPI configuration, L2 Lookup Table or another PTP/trap-related configuration item, and the frames are therefore trapped to the host port, most likely to the internal Cortex-M7 host, instead of being forwarded to the expected external egress port.   This would also explain why PTP over UDP and normal Ethernet traffic such as ICMP/ARP are forwarded correctly. These frames do not match the same Layer 2 PTP/gPTP classification rule and are therefore handled as normal bridge traffic.   Please check the following points in your SJA1110 configuration:   1. Which PTP destination MAC address is configured in the switch, especially in the General Parameters table. 2. Whether PTP/gPTP frames are configured to be trapped to the host port. 3. Whether the internal Cortex-M7 host is running a gPTP stack or receiving the trapped PTP frames. 4. Whether the used destination MAC address is 01:1B:19:00:00:00 or 01:80:C2:00:00:0E. 5. Whether the L2 Lookup Table or multicast forwarding configuration contains an entry that forwards this destination MAC to the required external ports. 6. Whether the ingress and egress ports are in the same VLAN and forwarding domain for this traffic.   If your intention is to use SJA1110 as a gPTP/time-aware bridge, then the expected configuration is usually not simple transparent forwarding of the original gPTP frames. The switch should participate in the gPTP timing domain and generate the corresponding gPTP messages towards the connected devices.   If your intention is instead to use SJA1110 only as a plain Ethernet bridge for raw Layer 2 PTP frames, then the PTP trapping/special handling must be disabled or avoided for this traffic, and the corresponding multicast destination MAC address must be explicitly allowed in the L2 forwarding configuration.   Regarding the PolarFire SoC GEM, I cannot make a definitive statement about the recommended or fully supported PTP transport mode for that device. From the SJA1110 point of view, PTP over UDP may be forwarded as ordinary IP/UDP traffic if the bridge path allows it. However, this does not necessarily mean that UDP transport is supported or recommended by the PolarFire GEM driver for hardware timestamping. Please confirm the supported PTP transport and timestamping modes with the PolarFire SoC GEM documentation or with Microchip support.   Best regards, Pavel Re: PTP over SJA1110 Hello @Ankur_pixl , The destination MAC address 01:1B:19:00:00:00 is an IEEE 1588 Layer 2 PTP multicast address. This is different from the 802.1AS / Automotive Profile gPTP destination MAC address 01:80:C2:00:00:0E, which is typically used in the SJA1110 gPTP Automotive Profile configuration.   Based on your description, this does not look like a standard Linux bridge MDB issue. The MDB entries may be correctly installed and even reported as offloaded, but the frame may still not reach the normal multicast forwarding path.   A likely explanation is that the SJA1110 hardware or the SJA1110 DSA driver classifies this destination MAC as a PTP/control frame before the normal L2 multicast forwarding decision is applied. In that case, the frame may be redirected to the CPU/management path instead of being forwarded directly between the two user ports.   This would explain the observed behavior:   - the ingress counter increases, so the frame is received by the switch, - the MDB entries are installed and shown as offloaded, - but the egress counter does not increase, because the frame is likely trapped to the CPU/management route before normal port-to-port forwarding is applied.   If the CPU/management route is not available in your port-to-port forwarding path, the trapped frame may effectively be dropped.   Regarding the Cortex-M7: if you are using the switch through the Linux DSA bridge and you do not run or control a gPTP stack on the internal Cortex-M7, then this should not normally be something configured from the Cortex-M7 application. In this use case, the relevant configuration is owned by the Linux DSA driver and by the switch hardware configuration programmed by that driver.   However, "bridge mdb" may not be sufficient if a dedicated PTP/control-frame trap rule is active for 01:1B:19:00:00:00. To forward this traffic directly in hardware between two user ports, the switch configuration would need to ensure that:   1. the PTP/control-frame trap for 01:1B:19:00:00:00 is disabled or bypassed for this traffic, and 2. a valid L2 multicast forwarding entry exists for 01:1B:19:00:00:00 towards the required user ports.   At this point, I would not expect the standard `bridge mdb` command alone to override a lower-level PTP/control-frame trap rule if such a rule is active in the SJA1110 DSA configuration.   As the next step, please check whether your SJA1110 DSA driver or BSP enables PTP hardware timestamping or installs any MAC filter / PTP trap rule for 01:1B:19:00:00:00. If such a rule is present, the solution will likely require a driver-level change or a switch static configuration change, rather than only a runtime Linux bridge MDB command.   Could you please share the following information?   - Linux BSP/kernel version, - SJA1110 DSA driver source baseline, - full output of "bridge -d mdb show", - the involved DSA port names and physical switch port numbers, - whether PTP hardware timestamping is enabled in the SJA1110 DSA driver, - and, if possible, a packet capture on the DSA master/CPU interface to confirm whether the Layer 2 PTP frames are being trapped to the CPU path.   With this information we can further check whether the frames are being consumed by the PTP/control trap path, or whether there is another L2 multicast forwarding limitation. Best regards, Pavel Re: PTP over SJA1110 Hello, The destination MAC is 01:1B:19:00:00:00. We're using the switch with the Linux DSA bridge and have no control or configuration access over the Cortex-M7 core. How do we allow this traffic through in the L2 configuration? We used bridge mdb, but it doesn't work; the entries install and even show as offloaded, yet the frames still aren't forwarded between the ports. Does this need to be set explicitly on the Cortex-M7 core? Additional context on our setup: Our MAC/port configuration is as follows: bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent bridge mdb add dev br-EPS port t1-6 grp 01:1b:19:00:00:00 permanent These show as offloaded in bridge -d mdb show, but L2 PTP frames arriving on one port are not forwarded out the other. Importantly, one of the switch ports does not have a working CPU port; it operates purely as a route between two ports (port-to-port forwarding), with no host/CPU port in that path. Since the reserved multicast 01:1b:19:00:00:00 appears to be trapped to the management/CPU route by default, and that route is not available here, we suspect the frames are being dropped rather than forwarded. Could you advise how to configure the switch to forward this reserved PTP multicast MAC in hardware between the two user ports, without relying on a CPU/management port? -- Ankur

S32K324 write DFlash by FEE Hello, There is a question about S32K324 write DFlash by FEE: I plan to write approximately 50 bytes of data into the DFalsh of S32K324 using the FEE method. Since the hardware power supply on the circuit board has a backup time of around 0.743ms, I need to save the critical data within this time frame. Is it feasible to write to the DFlash using the FEE method? If it is not feasible, are there any other options? Thanks. Re: S32K324 write DFlash by FEE Hi@mmyjh_123 For a power-off backup window of 0.743 milliseconds, FEE is not safe. Even "close to 1 millisecond," the write execution time for a single Fls_MainFunction block already exceeds your available hold time. You could try using C40_Ip. Using Quad-page (1024 bits) program time， a 50-byte write would theoretically take 450 microseconds. However, within 0.743 milliseconds, any erase operation during an emergency hold is impossible; erasing an 8 KB sector could take up to 30 milliseconds. Therefore, when implementing this functionality using C40_Ip, always erase the DFLASH address to be programmed during idle periods. Furthermore, if the board can detect input voltage drops before the MCU power failure, commit operations should begin at the earliest possible threshold. Otherwise, add a large capacity capacitor/backup power to ensure the guaranteed window covers the worst-case software path and flash programming margin. The above is only a theoretical analysis; multiple real-world tests are recommended, ensuring sufficient design margins. Re: S32K324 write DFlash by FEE Ok, thanks a lot.

Skid-steer robot state space modelling???? Hey everyone! I'm a beginner and just started working at a decently big lab with a bunch of people and I needed to figure a few things out. We're working on a skid-steer robot. I understand the dynamic and kinematic equations mathematically, but I don't know HOW exactly to convert them into state space. (which was the requirement) My team has the CAD model and they need to extract the Inertial Mass Parameters. They're a very chaotic group and I tried asking them, but they themselves don't have it together.😭 There's no well put resource for this kinda stuff either, and I'm genuinely at a loss of how to proceed with anything meaningful. Any pointers, help, and resources are appreciated! Cheers. Re: Skid-steer robot state space modelling???? Hello @prash, Could you please, provide me the following information? -Which NXP product are you currently using? Are you working with one of our EVKs, a custom board based on NXP MCU/MPU product, or another hardware solution? -Which IDE you are using? BR Habib