i.MX8M Plus EXT4-fs error i.MX8M Plus EXT4-fs error  EXT4-fs error (device dm-6): ext4_find_dest_de:2030: inode #228492: block 918033: comm Binder:296_3: bad entry in directory: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, lblk=0, size=4096 fake=1

ls104x higher version of Linux 6.+ Does NXP officially have a higher version of Linux 6.0 or above for the LS104X chip? Can you provide a download link

OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 Hi NXP Team, We are testing an OX05B1S GMSL2 camera on an i.MX95 19x19 EVK running Linux. Setup: OX05B1S camera - MAX96717 - GMSL2 - MX95MBDESER01 MAX96724 - i.MX95 The OX03C10 camera supplied with the MX95MBDES10001 kit works with the same deserializer board and is visible using cam -l. However, the OX05B1S camera with MAX96717 is not listed by cam -l. The BSP contains ox05b1s.ko, max96724.ko, max96717_lib.ko, and OX05B1S DTB files. The OX05B1S DTB appears to describe a direct MIPI connection, while the OX03C10 DTB contains the MAX96724 topology. Does NXP provide a reference device tree configuration for this setup? OX05B1S - MAX96717 - MAX96724 - i.MX95 If not, could you please advise what changes are required to use this OX05B1S GMSL2 camera with the MX95MBDESER01 board? Thank you. Best regards, Tharun Re: OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 Thank you for the clarification. We understand that the current BSP officially supports OX05B1S through the direct MIPI-CSI interface, while MAX96717/MAX96724 SerDes support is provided for OX03C10. We are using an OX05B1S camera module with a MAX96717 serializer connected to the i.MX95 through the MAX96724 deserializer. The GMSL2 link locks successfully, and the MAX96717 is accessible over the remote I2C channel. Is OX05B1S + MAX96717 + MAX96724 currently unsupported by the BSP, meaning that a custom driver/device-tree integration is required? Or is there any reference implementation or patch available for this combination? Re: OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 current bsp supports  OX05B1S with MIPI_CSI miniSAS connector to connect imx95 board directly, The Omnivision OX03C10 sensor is supported on i.MX 95 using serializer/deserializer solutions from the following vendors: • Analog Devices: MAX96717/MAX96724 • Texas Instruments: DS0UB953/DS0UV960 for more detailed information, pls refer to the chapter 6.1.3 Cameras of reference manual https://www.nxp.com/docs/en/reference-manual/RM00293.pdf

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.

Device with MK22FN1M0VLQ12 resetting loop after working for some time Hi guys, I have a device that runs on a MK22FN1M0VLQ12. The thing is that after working for some time it starts to get stuck on a reset loop at startup. First i thought it was a problem with corrupted flash memory (the application saves logs in the flash). I used a ping-pong strategy to resolve that. But some devices returned with a similar problem. I tried to debug one of the devices and without setting any breakpoint it always stops at ASerialLDD2_Init or IntFlashLdd1_Erase, both are functions generated by processor expert. Other devices I used memory dump and was able to see that the memory was indeed corrupted so that's why I fixed how I use the FLASH. Other important note is that some times it happens after some months, other almost after a year. Also i have devices installed over a year and a half that are running ok. Other thing is that I tried to memory dump (with usbdm) this device, and trying to read the same address, sometimes it reads fine, and sometimes it returns ARM Transation Fault. Anyone seem anything like that? Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time Thank you for the reply I will look into it, as the problem is happening at a time that coincides with a memory reading command. Although there's a pin that is setting HIGH when it should not. This pin is initialized as a LOW output. That being said, is there something that would explain why it was pausing in those function while debugging? Before the reading command the only time ASerialLDD2_Init() is called is within PE_low_level_init(). I am using a PE Micro multilink to debug. Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time Hello @Rigolon , Thanks for your post. I think this looks more like a Flash-operation-related fault or Flash-content corruption issue, rather than an issue in ASerialLDD2_Init or IntFlashLdd1_Erase themselves. The RM states that if the MCU reads an FTFE resource while it is being manipulated by an active Flash command, FSTAT[RDCOLERR] is set, and the read data is not guaranteed. You can refer to AN4835 , it also says:" Interruption of an erase or program command can lead to corruption of the flash contents. Interruptions could include reset, loss of power, or a conflict with code running on processor."  This matches the observation that reading the same address sometimes succeeds and sometimes returns an ARM Transaction Fault : if a Flash region is corrupted or in an indeterminate state, reading it may trigger a bus fault; in similar cases, erasing the affected sector, or mass erase if needed, is used to recover the Flash array. Please refer to Solved: Find corruption on internal Flash MK22FX512VLH12 - NXP Community for more details. Hope it helps. BR Celeste Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time Thank you for the reply I will look into it, as the problem is happening at a time that coincides with a memory reading command. Although there's a pin that is setting HIGH when it should not. This pin is initialized as a LOW output. That being said, is there something that would explain why it was pausing in those function while debugging? Before the reading command the only time ASerialLDD2_Init() is called is within PE_low_level_init(). I am using a PE Micro multilink to debug.

T1040 mEMAC TX_FIFO_OVFL on port when another port loses link I'm debugging an Ethernet issue on a T1040 using the 1G mEMAC RGMII interfaces. I am seeing packet loss on an Ethernet port when a different port loses physical link (e.g. the cable is disconnected). This appears to happen most frequently when both ports are operating at high data rates. When the issue occurs, I see the `TX_FIFO_OVFL` bit set in the Interrupt Event Register (`IEVENT`) of the healthy port. My current interpretation is that when an actively transmitting mEMAC loses physical link, something in the FMan/mEMAC transmit path temporarily prevents another mEMAC from draining its TX FIFO quickly enough. The healthy port eventually reports `IEVENT[TX_FIFO_OVFL]` and frames are lost. However, I have not identified the shared resource or mechanism that could cause this behavior. My questions are: * Is this a known T1040 / FMan v3 / mEMAC silicon issue or erratum? * Are there shared resources between the 1G mEMAC ports that could cause loss of carrier on one port while transmitting to temporarily affect another port's TX FIFO? * Is there a required sequence when a PHY loses link, such as stopping QMI dequeue, disabling the BMI TX port, disabling mEMAC TX/RX, or resetting the mEMAC? * Is there any mEMAC or FMan status register that can detect the condition leading to `TX_FIFO_OVFL` before the overflow occurs? * Are there recommended FMan/mEMAC or PHY configuration changes that might prevent `TX_FIFO_OVFL` in this situation? Thanks Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link Hello, There is no publicly documented T1040/FMan v3 silicon erratum that specifically describes TX_FIFO_OVFL on a healthy port triggered by link loss on a peer port. The T1040 Chip Errata document is NDA-controlled and not publicly indexed, but no such cross-port TX FIFO overflow erratum has been identified for the T1040 mEMAC. The behavior you are observing is most likely an architectural interaction within the shared FMan BMI resources rather than a silicon defect.   Regards Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link Thanks. Can you identify which shared BMI resource or arbitration mechanism is expected to cause this behavior? I have tested changes to FMBM_PFS[IFSZ], FMBM_TFP[DPDE], and FMBM_TFP[FLCL] without seeing a meaningful change. I also stop enqueueing and disable mEMAC TX immediately when IF_STATUS[RGLINK] goes low, but the healthy port can still lose packets. Is there a documented or recommended configuration to isolate the ports from this interaction? Also, is there a counter, status register, or debug mechanism that can show which BMI resource is becoming exhausted, blocked, or otherwise preventing the healthy mEMAC from draining its TX FIFO? Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link Hi, The four shared BMI resources are TNUMs (tasks), DMA channels, FIFO (MURAM), and pipeline-depth. Since your FIFO size, pipeline depth ( DPDE ), and FIFO low threshold ( FLCL ) changes produced no improvement, the DMA channel layer is the most likely bottleneck, not MURAM allocation. The T1040 FMan has a fixed pool of DMA channels shared across all active TX ports. The TX path for each port is: CPU → QMI dequeue → BMI opens DMA read (DDR → MURAM) → TX FIFO → mEMAC → wire     When your stalled port loses link and you clear COMMAND_CONFIG[TX_EN] , the mEMAC stops transmitting to the wire, but any frames that are already mid-pipeline — specifically those for which the BMI TX port has already issued a DMA read transaction (DDR → MURAM TX FIFO) — do not immediately complete. The DMA read may have already moved data into the TX FIFO, and the FMan DMA engine is now waiting for a "DMA complete / EBD (external buffer descriptor) release" acknowledgment that depends on the MAC consuming the FIFO. With TX_EN=0 , the MAC is not consuming, so the DMA transaction stays open. Those open DMA transactions on the stalled port hold shared DMA channel slots. Under high load, the healthy port's BMI TX path cannot acquire enough DMA channel slots to fetch data from DDR quickly enough to keep its TX FIFO supplied → the TX FIFO goes empty briefly → then backfills faster than the MAC drain rate → TX_FIFO_OVFL . Regards

S32K358的芯片温度 当S32K358工作在240MHz时，环境温度24℃时，读取到MCU的内部温度达到60℃。这个IC温度是在PCB铺铜散热的情况下测得的。这个温度是否正常？ Re: S32K358的芯片温度 是的，是IC内部温度传感器得测量结果。应用场景为BMS Re: S32K358的芯片温度 在芯片的正常工作温度范围内，你有用这个芯片具体跑什么功能呢？ Re: S32K358的芯片温度 嗨@liyongfeng 局部结温 (Tj) 受芯片上电路当前工作活动和近期活动历史的影响。因此，芯片上传感器测量的温度不仅反映了当前的功率耗散，还反映了先前活动的电路元件产生的残余热量。 因此，测得的结温与环境温度之间存在一些偏差是正常的，并不一定表明设备存在问题。但是，设计必须确保结温不超过数据手册中规定的最大结温。

Profinet porting on iMX95EVK Hi, I am trying to port NXP-Port GMBH provided profinet stack on my iMX95 EVK on linux core I have found access to below link where it is tested on i.MX-RT1180 and also on iMX94. Profinet stack link  My queries are: 1. Please confirm imx95 supports this and this stack can be ported for evaluation purpose. 2. Please also share any documents that I can refer to port this stack on linux. Please let me know if you need any other information from my end. Thanks Gaurav  Re: Profinet porting on iMX95EVK I hope his email finds you well,  At this moment, i.mx95 doesn't support the PROFINET Industrial Ethernet Protocol Software. Only the mentioned devices:  Re: Profinet porting on iMX95EVK Hi @Oswalag , Thanks for the reply. I have checked that imx94 and imx95 are quite similar and if the stack is working on imx94 then with some efforts it should be portable on imx95. I have few queries: 1. Please confirm whether profinet stack is ported on M7 core or linux core  on IMX94. 2. Are there any documents available that can help with porting on IMX94? Thanks, Gaurav

关于RAM空间分配的问题 各位NXP官方的技术人员你们好 我在使用S32K144的过程中遇到了一些问题 在这个地址分配表中 System RAM 空间SRAM_L (extends downwards)和SRAM_U (extends upwards)的大小 对于 S32K144芯片是不是支持用户自定义 对于全局变量地址的分配问题 初值不为零的全局变量存放在SRAM_L  中 初值为零的变量存放在SRAM_U 中 这是为什么  而且  SRAM_L  SRAM_U 如果支持自定义大小的话  他们两个地址段的起始地址和结束地址有规定吗 为什么 全局变量有无初值  芯片分配的地址段不同 我很想了解关于这个芯片的flash分配的相关问题  如果有这方面的教学资料  可以让我知道在哪下载吗？ 衷心期待得到您的回复 万分感谢！ Re: 关于RAM空间分配的问题 嗨@Ni_ 有应用笔记可供参考。虽然它是为 S32K3 设备设计的，但 RTD 中使用的连接器概念对于 S32K1 设备来说本质上是相同的。因此，它应该可以作为理解和配置链接器的有用参考。 AN14893 ：S32K3xx 链接器文件和启动代码

Memory error occurs during flashing in TRACE32 When flashing via TRACE32 scripts, memory cannot be accessed. What could be the root cause? Re: Memory error occurs during flashing in TRACE32 As shown in the attached script, Lauterbach occasionally fails to access RAM. This issue can be resolved by re‑flashing the software via PE. Re: Memory error occurs during flashing in TRACE32 Hello @代码织梦师, Could you share which device you are using? Also verify the flash algorithm path in the .cmm script matches the device derivative.  From the image, I assume you are reading SRAM in S32K3, which does need ECC initialization, can you confirm you, or the startup file is correctly initializing SRAM ECC after POR? Best regards, Julián  Re: Memory error occurs during flashing in TRACE32 Hello @代码织梦师, It could be SRAM ECC initialization, although both the debugger as well as the startup code should initialize the SRAM ECC, if enabled. You can try the init_sram.cmm from demo scripts in T32: Best regards, Julián

lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello! I am working with the 3-Phase Permanent Magnet Synchronous Motor Control Development Kit with S32K396 MCSPTR2AK396. To test the base firmware, I installed the following stack: S32DS_3.6.5_RFP_win32 S32K3_ETPU_SW_4.9_2.0.1_D2512 SW32K3_S32M27x_RTD_R23-11_7.0.0_QLP03_D2512 SW32K3_FreeMASTER_Driver_1.5.0_D2512 S32K3xx_AMMCLIB_RTM_1_1_45_BIN MCSPTR2AK396_SW GCC version 10.2 After several unsuccessful attempts to synchronize all software versions, it finally worked, and the base firmware started functioning. However, I wanted to test the Ethernet communication functionality next, and that’s where I encountered unresolved issues at the moment. I additionally installed: SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603 SW32K3_TCPIP_STACK_4.0.0_D2512 And I took the test project lwip_FreeRTOS_s32k396, but it never compiled without errors; there were always conflicts in descriptions and other issues. I tried using the latest version of SW32K3_TCPIP_STACK_5.0.0_CD01_D2605, and I had to apply a file replacement during the update code process. In the end, the firmware compiled with warnings but no errors. After that, I moved on to testing. I set up the system as follows: personal computer -> GeekStore 100BT1-PRO2 Automotive Converter (http://pinzhi-tech.com.cn/en/home_eng/product_list_100base-t1_eng/100bt1-pro2_eng/) -> MCSPTR2AK396. I aligned the IP addresses of the Ethernet connection on the computer and the one specified in the firmware so they would be in the same subnet. However, attempting to ping the motor's assigned IP from the computer was unsuccessful, although it seems the network polling is ongoing, as indicated by the converter. What could be the issue? Could it be that I shouldn’t have used the latest version of TCPIP_STACK? Are there possible issues with the board itself? On the controller board stickers, revisions B1 and B are indicated. Is it possible to obtain additional documentation specifically for these revisions (on the website, I only saw documentation for revision A)? I would appreciate any advice or clarifying questions. Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello @Anna_Anna, Firstly, I am not sure what errors were present with TCPIP v4.0.0, since it is also compatible with RTD 7.0.0 & FreeRTOS 7.0.0 CD01 packages, however, latest TCPIP stack (v5.0.0) is OK. Can you share what was the file modification? I was able to import, generate and compile the project without problem. My environment: S32DS v3.6.0, RTD v7.0.1, FreeRTOS v7.0.0 CD 01 and TCPIP Stack version 5.0.0 CD 01. It seems that MCSPTR2AK396 has a design oversight. EMAC_MII_RMII_RX_DV (PTD14) is not connected to RX_CTL - CONFIG6: MCSPTR2AK396 EVB ethernet connectivity, CRS_DV signal clarification. That said, is the task and OS is running?  xTickCount — this should be incrementing continuously if the RTOS tick interrupt is active. xSchedulerRunning — this should be set to 1 if the scheduler is running. Best regards, Julián    Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello  Regarding the design files, I can see that the HW Design Package for MCSPTR2AK396 includes revision B2: Best regards, Julián Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello @Anna_Anna, Yes, the fsdata.c and EthIf.c in previous release was reported and fixed; EthIf.c file from RTD is just a stub. We provide our own minimal implementation for EthIf, so the file from RTD can be safely excluded from the project. Secondly, yes, from your description, it seems that the example works properly. The connection is needed and should be done as mentioned (routing/soldering CRS_DV to PTD14).  Best regards, Julián Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello @Julián_AragónM! The issue with building the test project using TCPIP v4.0.0 was resolved by excluding two files, fsdata.c and EthIf.c, from the build. This conflict seems to have been automatically resolved in version 5.0.0. I also checked the values of the variables xSchedulerRunning and xTickCount through the Expressions window in the S32DS debugger. xSchedulerRunning indeed takes the value 1, and the second one increases sequentially (1, 5001, 10001...), leading me to conclude that FreeRTOS is functioning correctly on the board, and the problem is not in the software. If I understand correctly, the only remaining cause is a hardware issue—the absence of a connection between CRS_DV (CONFIG6) on the TJA1103A and pin PTD14? To resolve this, do I need to solder these two contacts together? Please confirm. Best regards, Anna  Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Thanks, I'll try this approach a little later and report back on the results.

mc9s08qg8 drivers device manager: Jungo connectivity WinDriver:      Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)   pemicrowindvr:    This device is working properly.   These r the drivers i have in jungo!!!   ur input:   In USB Multilink Universal and USB Multilink Universal FX Technical Summary [USBMLUNIVERSALFX] documentation Chapter 6 Driver Installation mention that a copy of the driver installation program may be downloaded from P&E page "Support Center">Downloads. if you need an updated driver.   Best Regards,   What do u mean by this. Is this where i can get my BDM driver for my Wiztronics.com P&E interface board? Re: mc9s08qg8 drivers Hello, From the other post, I was referring that, as you are using P&E USB multilink Universal, the support page could redirect you to download a patch or an upgrade to your driver, I found these resources that could maybe help you if you have an incorrectly driver. In these page, its mentioned some patches for CodeWarrior v10.2 or higher and v6.3, to add support for PE hardware if is not detected by the operating system. PEmicro FAQ ID 211 Another option USB Multilink Resources Install Is a resource package for USB Multilink Universal, for when running older software. Also could you help us share which exact version of USB multilink Universal are you using? I could not guarantee this will work, since it’s a partner page, but it could redirect you in how to look for a driver correction for your issue, hope this information was helpful and let me know if that work for you Best Regards.

MC3377ASP1 AFE is Burning Hi Everyone, I am using MC33774SP1 AFE for my BMS application. I am using it for cell voltage measurement, cell balancing [external+internal] on my board. I am using it for 15s battery pack though i have designed it for 18 cells. I am shorting the last three terminals to make it as 15s. I am facing AFE burning issues in which Vbat and ground pins are getting short and fire is getting observed on IC. I am attaching my schematic for your reference as well. Could you please guide me related to this. Also, I am using a wakeup circuitry for my BMS in between VBAT and VSTACK pins. Re: MC3377ASP1 AFE is Burning Hi, Using the MC33774ASP1 in a 15s configuration is possible, but the unused upper channels must be connected correctly. For a 15s stack, the active cell connections should use CT0 to CT15 and CB0 to CB15. The unused upper pins should be connected to the highest used cell node, meaning CT16, CT17 and CT18 should be tied to CT15, and CB16, CB17 and CB18 should be tied to CB15. One important concern from the schematic is the VBAT/VSTACK connection. It appears that VBAT is supplied from VSTACK through diode circuitry. Please note that VBAT must closely track the highest CT/CB cell node. In particular, the voltage difference between VBAT and the highest CB node must remain within the datasheet limits. If the diode path or wake-up circuitry creates a voltage drop or transient difference between VSTACK/highest CT/CB and VBAT, this could overstress the device. Please check the following points before continuing powered tests: 1. Confirm that CT16, CT17 and CT18 are tied locally to CT15, and CB16, CB17 and CB18 are tied locally to CB15 for the 15s configuration. 2. Confirm that VBAT is connected to the actual top-of-stack node through the recommended VBAT filter and that the wake-up circuit does not introduce a diode drop or transient offset between VBAT and the highest CT/CB node. 3. Measure VBAT, VSTACK, CT15 to CT18, and CB15 to CB18 during pack connection, wake-up and power-up. The transient behavior is important, not only the steady-state voltage. 4. Confirm that balancing and measurement are disabled for the unused upper channels. 5. Confirm that the external balancing MOSFET circuitry for the unused channels cannot create any unintended current path. 6. Please also verify the capacitor values on the CT/CB sensing lines. If large capacitors are used on each cell tap, the inrush current during pack connection may cause transient overstress. Based on the destructive nature of the failure, with VBAT and ground becoming shorted and visible IC damage, this should be treated as a possible hardware overstress condition. I recommend stopping further powered tests until the VBAT/VSTACK relationship and the unused-cell connections are verified with measurements. BRs, Tomas Re: MC3377ASP1 AFE is Burning Hi Tomas. Thanks for the prompt reply. One issue I found that the difference between my VBAT and CB18 was around 1.6V, which was more than the recommended value of 0.4V . I am suspecting it might be causing my AFE burning. I am checking it further and will post my results. Thanks and Regards, Abhishek

ECSPI1 does not generate expected SPI clock on custom board Hi Team, We are working with an i.MX8MP custom board based on the i.MX8MP EVK configuration. On the i.MX8MP EVK, we have an SPI device connected through ECSPI2. With the existing EVK Device Tree configuration, SPI communication is working correctly, and we can observe the expected SCLK waveform on the oscilloscope. On our custom board, the SPI interface is connected to ECSPI1 instead of ECSPI2. We therefore modified the Device Tree configuration to use ECSPI1. However, with ECSPI1, we are not able to observe the expected/correct SPI clock pulses on the SCLK pin. We have tried several different Device Tree configurations, but the issue remains. 1. ECSPI1 configured similar to the existing ECSPI2 configuration We changed the controller from ECSPI2 to ECSPI1 and created the corresponding ECSPI1 pinctrl group, including SCLK, MOSI, MISO and CS. 2. Separate CS pinctrl group We also tried defining a separate pinctrl_ecspi1_cs and using it along with the ECSPI1 pinctrl group. 3. Explicit ECSPI1 pinmux configuration We also tried explicitly defining the ECSPI1 pins. However, with ECSPI1, we are still unable to observe the expected SPI clock pulses. We would like to know when configuring ECSPI1 on i.MX8MP, are there any additional Device Tree or pinctrl changes required apart from enabling &ecspi1 and configuring the ECSPI1 SCLK/MOSI/MISO/CS pins? In particular, is there any ECSPI1-specific pinctrl, clock, IOMUX, or other Device Tree configuration that needs to be added for ECSPI1 to operate correctly? The same SPI setup works on ECSPI2, so we would like to understand whether there is any additional configuration required when moving the interface from ECSPI2 to ECSPI1. Thanks in advance for your guidance. Re: ECSPI1 does not generate expected SPI clock on custom board Hi ,  Please find the dts file attached Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  Please share your dts file about ECSPI1.  B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi @SWETHA1  I have checked your dts file, I found the following errors： 1. ECSPI pins have been reused, causing a pin usage conflict. Please remove this part or use other pins for reuse.     pinctrl_ecspi1: ecspi1grp {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK       0x48             MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI       0x48             MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO       0x48         >;     };     pinctrl_uart3: uart3grp {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SCLK__UART3_DCE_RX      0x140             MX8MP_IOMUXC_ECSPI1_MOSI__UART3_DCE_TX      0x140             MX8MP_IOMUXC_ECSPI1_SS0__UART3_DCE_RTS      0x140             MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS     0x140         >;     }; 2. The ECSPI1 chip select (CS) configuration is contradictory. Please change it to the following code.     pinctrl_ecspi1_cs: ecspi1cs {         fsl,pins = <             MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09     0x40000         >;     }; B.R Re: ECSPI1 does not generate expected SPI clock on custom board Hi @pengyong_zhang, Please find the below observations 1. Logic analayser result when used the suggested changes 2. Another observation when used the below patch on top of the previously attached dts the above graph observed with this changes pinctrl_ecspi1: ecspi1grp { fsl,pins = < MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x80 MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x80 MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x80 >; }; With the suggested changes, we could see the clock is not as expected. 

Project [Rename] , 造成 整個 Project 丟失 餓死抬頭  S32DS 3.5  面對 相似 新Project  對 舊Project 做 [Rename] 動作  新Project 沒有生出來 就算了  將我 原有的 舊Project 也刪除了 !!  Explorer 已找不到原Project Folder  chkdsk 表示 無錯誤 !   請問，我該如何 救回 原有 舊Project !??  另，為什麼 [數字開頭的 Project Name] 不合法? ??   Spoiler (Highlight to read) S32DS-ARM S32DS-S32PLATFORM #rename    #rename  Re: Project [Rename] , 造成 整個 Project 丟失 你好@CY9 ， 我不认为这是由于子文件夹数量造成的。从日志元数据中可以看到，在“2026-08-10”执行的重命名操作失败了： !ENTRY com.nxp.s32ds.ext.ide.core 4 0 2026-08-10 08:50:24.109 !MESSAGE Unexpected error during rename !STACK 1 我推断您要重命名的项目是“202503021_App_118”，您尝试将其重命名为“ADB22pxAPP_VR”，对吗？我看到以下错误： org.eclipse.core.internal.resources.ResourceException(/ADB22pxAPP_VR)[374]: java.lang.Exception: Resource '/ADB22pxAPP_VR' already exists. 但是，我不确定这是否是根本原因，因为我尝试将一个项目重命名为一个已存在的项目，但却失败了： 所以，仅凭这些信息，我真的无法得出结论。我唯一能建议的操作是使用 Recuva 扫描整个磁盘，查找 202503021_App_118 和 ADB22pxAPP_VR。如果项目无法恢复，我不确定是否还有其他可行的解决方案。 此致， 朱利安 Re: Project [Rename] , 造成 整個 Project 丟失 是的， 我确信 ` ADB22pxAPP_VR` 不存在。 它确实存在，而且你的程序也找到了它。 是否应该停止重命名功能！？ 实际上，它删除了整个目录。 我完全不知道发生了什么事。 Recuva找不到任何文件夹。 我正在尽快抢救一些文件。 谢谢你的关心。

Inquiry on Alternative Parts for MW6S010GNR1 Dear  support team  Part number MW6S010GNR1 has been discontinued. Could you please recommend equivalent alternative models? Our application is industrial wideband RF equipment. thanks so much Re: Inquiry on Alternative Parts for MW6S010GNR1 **MW6S010GNR1 Status & Recommended Alternatives** ### Part Overview **MW6S010GNR1** (NXP / former Freescale) is a **10 W, 28 V LDMOS** RF power transistor designed for broadband applications. | Parameter | Value | |------------------------|--------------------------------| | Frequency range | 450 – 1500 MHz | | Output power | 10 W | | Supply voltage | 28 V (qualified up to 32 V) | | Typical gain | ~18 dB @ 960 MHz | | Package | TO-270-2 Gull Wing (GNR1) | | Application | Class A / AB, base station, broadband industrial RF | **Status**: Discontinued / End of Life (part of NXP Radio Power product line ramp-down). Last Time Buy is expected around **30 September 2026**, with final shipments targeted for **2027**. --- ### Recommended Equivalent / Alternative Models There is **no exact pin-to-pin drop-in replacement** from NXP. Below are the closest practical alternatives for industrial wideband RF equipment. All will require matching network re-optimization. | Priority | Part Number | Manufacturer | Key Specs | Package | Notes / Compatibility | |----------|----------------------|--------------|----------------------------------------|--------------|-----------------------| | 1 | **MW6S010NR1** | NXP | Same electrical specs as GNR1 | TO-270-2 | Non-Gull Wing version of the same die. Also discontinued, but may still have residual stock. | | 2 | **BLP15H9S10G** or **BLP15H9S10** | Ampleon | 10 W, 50 V, very wideband (1–2000 MHz) | TO-270 | Excellent wideband industrial alternative. Higher voltage, needs matching redesign. | | 3 | **BLP15M9S30G** / related 28–32 V devices | Ampleon | 30 W class, 1–1500 MHz, 32 V | TO-270 | Higher power option if headroom is acceptable. | | 4 | **AFT27S010N** | NXP | ~10 W, 28 V, broader frequency coverage | Plastic | Newer generation, but different package and matching required. Check current availability. | | 5 | Other 10 W / 28 V LDMOS | Ampleon / Infineon | Various | TO-270 or similar | Search for unmatched wideband LDMOS in 10 W class. | --- ### Practical Recommendations for Industrial Wideband Use 1. **Short-term** - Check remaining stock of **MW6S010GNR1** and **MW6S010NR1** for Last Time Buy. - If pin-out compatibility is critical, prioritize the NR1 version if available. 2. **Medium / Long-term (Recommended)** - Migrate to **Ampleon BLP15H9S10(G)** series. These are modern, wideband, rugged LDMOS devices commonly used in industrial, ISM, and broadband RF applications. - They offer better long-term availability and support. 3. **Design Notes** - Expect to redesign the input/output matching networks. - Verify thermal performance, bias point (IDQ), and VSWR ruggedness in your specific industrial environment. - Confirm package footprint and soldering profile compatibility. --- **Would you like me to:** - Compare detailed electrical parameters (gain, efficiency, capacitances) between MW6S010GNR1 and a specific alternative (e.g. BLP15H9S10G)? - Help search for current stock/pricing of the recommended parts? - Suggest matching circuit references or evaluation boards? Please share your exact frequency band, power requirement, and preferred supply voltage if you need a more targeted recommendation. Email: [email protected]

[FRDM-IMXRT1186] Question about ADC Power Sequencing (VDDA_1P8 vs 3P3) I am reviewing the FRDM-IMXRT1186 (SCH-95302 Rev.A4) and the RT1180 Data Sheet Rev.9. The datasheet requires VDDA_ADC_1P8 to be powered prior to VDDA_ADC_3P3. However, on the FRDM board, VDDA_ADC_1P8 comes from an AMS1117-1.8 regulator tied to VDD_3V3, meaning it follows the 3.3V rail's soft-start. Additionally, VDDA_ADC_3P3 is left floating by default (R337=DNP). My questions: 1.Is the FRDM board considered compliant with the datasheet sequence given this implementation? 2.For a production design, is it mandatory to use a PMIC or an LDO with an EN pin to strictly meet the "prior-to" requirement? 3.I have attached a screenshot of the relevant schematic section. I will post my detailed analysis in the comments below to keep this initial post clear. FRDM-Training i.MXRT 106x Re: [FRDM-IMXRT1186] Question about ADC Power Sequencing (VDDA_1P8 vs 3P3) Hi @rejust , Thank you so much for your interest in our products and for using our community. Yes, from the default FRDM-IMXRT1186 schematic, the design is intended to meet this sequencing requirement. R337 is DNP by default, so VDDA_ADC_3P3 is not directly tied to VDD_3V3 through the 0 Ω bypass path. Instead, VDDA_ADC_3P3 is supplied through the U17 MOSFET sequencing circuit. This circuit is controlled by the VDDA_ADC_1P8 / ADC_1V8_IN rail, so VDDA_ADC_3P3 is enabled only after VDDA_ADC_1P8 is established. For production design, a PMIC is not mandatory. Any reliable sequencing method is acceptable, such as a PMIC, LDO/load switch with EN control, or a MOSFET sequencing circuit, as long as the timing at the SoC pins meets the datasheet requirement. Wish it helps you Best Regards May

HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 Hi, I am working on HSE-B AB Swap on an S32K312 MINI-EVB with HSE firmware version 0.2.55.0 (ab_swap variant). The board is in OEM_PROD lifecycle and Bank A is currently active. Both banks hold the same HSE firmware version. I have a working reference where a bare-metal main function polls HSE INIT_OK and then submits the activate passive block service. That call returns success and the swap applies on the next reset. Bank B contains a valid IVT with pointers compiled for the lower address space per section 11.3 of RM00286. The same MU submission code, moved into a bootloader after MCAL clock initialization, returns HSE response 55A5A26A (invalid address). HSE INIT_OK stays set. Other HSE services (AES, RSA, SHA) work correctly in this state. The only difference between the working and failing runs is that the bootloader path writes the MC_CGM MUX 0 divider registers during clock initialization, keeping the source on FIRC but changing the AIPS_SLOW to HSE_CLK ratio from 1:1 (SBAF default) to 1:4. My main question: what does the invalid address response refer to for the activate passive block service, since the service takes no data structure? Is there a documented sequence for reconfiguring MC_CGM dividers after HSE has reached INIT_OK, that keeps this specific service usable? I can share the failing binary, register dumps, and clock config on request. Thanks Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 Hi David, Thank you for the guidance about the DCF client. To make sure I set this up correctly on the first attempt, could you please clarify a few things: 1. Point 5 in your list says the MC_CGM MUX 0 source must be PLL_PHI0. Is this a hard requirement — does the activate passive block service require the system clock to be on PLL, or can it also work with the system running on FIRC (48 MHz)? 2. Could you share the earlier points 1 to 4 from the same list? We only have points 5 and 6 in the image and suspect we are missing prerequisites. 3. Point 6 gives the DCF value for a 120 MHz HSE clock scenario. For a 48 MHz FIRC configuration with AIPS slow clock at 12 MHz (1:4 ratio), what value should be programmed into the UTEST_MISC DCF record's clock mode and gasket control bit field? 4. What is the exact UTEST address on S32K312 for this record, and is there a sample or a Design Studio / Cyclone algorithm file we can use to program it safely? Since UTEST is one-time programmable, we want to be certain before writing. 5. Are there any other DCF records required for AB Swap beyond UTEST_MISC — such as an OTA enable marker in UTEST, or OTA indicators inside the active and passive blocks? If yes, please share those as well. Board context: HSE firmware 0.2.55.0 ab_swap variant, OEM_PROD lifecycle, INIT_OK and OEM SU rights bits set. Thanks a lot, Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 I guess you don't have setup DCF client what is necessary for use as you described. Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 1) I didn't want to take a screenshot of point 5, but point 6. 2) It is taken from RM: 3) The key point is ratio 1:4. Also it is described in RM embedded attachment (S32K3xx_DCF_clients.xlsx) 4) DCF record address to be programmed you will have to find out yourself (to find first location with 0xFFFF_FFFF). Specifically is should be around address 0x1B000780, but double check it before programming. See following document to understand DCF records: https://community.nxp.com/t5/MPC5xxx-Knowledge-Base/MPC57xx-DCF-records/ta-p/1114884 Also DCF calculator exists: https://community.nxp.com/t5/S32K-Knowledge-Base/S32K344-DCF-Configurator/ta-p/1986243 I have been using TRACE32 script as follows: ; Program UTEST do ~~\demo\arm\flash\s32k3.cmm prepareonly flash.Program 3. /OTP ;put lines generated by S32K344 DCF configurator data.set 0x1B000780 %QUAD 0x0010000460000101 ;dcf_client_utest_misc flash.Program off Mentioned DCF calculator also allows you to create S-records that may be programmed by any programmer/debugger. 5) OTA flag is programmed automatically when AB_SWAP HSE FW is being installed, user don’t need to care of it. I am not aware of other DCF configurations needed. Re: HSE AB Swap works from bare metal but fails after MCAL clock setup on S32K312 Hello, Follow-up: I have prepared the DCF record for dcf_client_utest_misc per your instruction (value 0x0010000460000101, target address 0x1B000768 — first free QUAD on my board, verified). However, S32DS + PEmicro Multilink debug configuration silently skips the UTEST write — bytes at 0x1B000768 remain FFFFFFFFFFFFFFFF after the flash session. What is the correct tool/procedure to program a single DCF record into UTEST OTP on S32K312 using PEmicro Multilink (or any tool that ships with S32DS 3.6.4)? Do I need a specific flash algorithm file, a different debug configuration, or the standalone S32 Flash Tool?

Building NXP Android 16 BSP in AWS or GCP Cloud – Experience, Setup and Build Times Hi everyone, I am currently working on setting up Android 16 for an NXP i.MX 95 and would like to build the NXP BSP in a cloud environment. The release I am using is: Android 16.0.0_2.0.0 (L6.18.20_2.0.0 BSP) I am currently looking into using AWS or Google Cloud Platform (GCP) as the build environment instead of a local workstation. I would therefore like to ask the community: Is there any official NXP documentation or recommendation for building the Android BSP in AWS or GCP? Has anyone already successfully built this Android BSP in AWS or GCP? Which instance/VM configuration did you use (CPU, RAM, storage, etc.)? Approximately how long does a complete BSP build take in your setup? What were the approximate cloud costs per build? Are there any specific issues or limitations to be aware of when building the BSP in a cloud environment? I am especially interested in practical experience, for example which cloud instance type worked well and whether there are any important considerations regarding RAM, disk space, CPU cores, storage performance or build parallelization. Any recommendations, example configurations or lessons learned would be greatly appreciated. Thanks in advance for sharing your experience! Best regards Fb Re: Building NXP Android 16 BSP in AWS or GCP Cloud – Experience, Setup and Build Times Hello @Feevlic  Hope you are doing very well. We do not have documentation for that specific scenario for compiling Android. The process should be the same as a physical machine. Please try following the steps of the UG10156 Android User's Guide. Best regards, Salas.

MIMXRT1160 XIP fails randomly I have multiple boards running XIP from octal flash at 166 MHz. One of them fails occasionally  with "undefined instruction" error.  I've suspected signal integrity issues but I do not have test points on the PCB, so the only way to check that has been reducing speed from 166 MHz to 133 MHz, which appears to "fix" the problem with that particular board.  It's probably telling that the error appears most often when chainloading the application from mcuboot. It is more rare during application runtime. I can't find a reliable way to trigger it too - need to power-cycle the board several times until the fault appears.  Is there a way I can diagnose this XIP failure with more precision? Re: MIMXRT1160 XIP fails randomly Hi @tbonkers , The behavior you describe is most likely caused by insufficient read-sampling margin (setup/hold) at 166 MHz, due to tight PCB-routing/signal-integrity headroom on the Flash data lines. This also explains both symptoms: dropping to 133 MHz widens the sampling window so the issue "disappears"; and the mcuboot chainload is the first, dense, cache-cold instruction fetch right after a cold reset, where margin is tightest — hence it fails most often there, while runtime fetches mostly hit cache and rarely trigger it. We suggest the following checks, all software-side and requiring no PCB test points: Start with dummy cycles. Verify that the dummy-cycle count in the read LUT strictly matches your Octal Flash datasheet spec at 166 MHz. If an auto-generated FCB (e.g., from the provisioning tool) uses a lower value, set it to the datasheet-specified value, and you may add 1–2 extra dummy cycles to widen the data-valid window and increase sampling margin. Insufficient dummy cycles place the first data beat in the turnaround/not-yet-settled region — a classic source of intermittent errors. Verify the read sample-clock source . 166 MHz is only in-spec when readSampleClksrc=3 (kFlexSPIReadSampleClk_ExternalInputFromDqsPad: read strobe/DQS provided by the Flash device). If it is currently 0 or 1, 166 MHz is out of spec, which is fully consistent with "133 MHz fixes it." Please confirm a real DQS trace exists on the PCB and use this mode. If intermittent faults persist after these adjustments, you can run at 133 MHz as a safe baseline while isolating the 166 MHz margin bottleneck via steps 1–3 above. And this post may also help: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Octal-flash-IS25WX256-dummy-cycles/m-p/2178828   Best wishes, Gavin Re: MIMXRT1160 XIP fails randomly Error log or schematics sharing could be helpful, how about the failing rate till now? Re: MIMXRT1160 XIP fails randomly Hi @Gavin_Jia , I've tested the read command with different dummy cycles count, and the failure is still there. I've set the number of dummy cycles in the flash volatile register to 20 so that it can support 166 Mhz. According to the flash datasheet it should support up to 200 MHz with 20 dummy cycles. readSampleClksrc=3 is set by the bootROM, confirmed with debugger connected. The DQS trace does exist.  Sometimes the fault happens while application is running, after the first major flash read. Re: MIMXRT1160 XIP fails randomly Hi @tbonkers , Thanks for the detailed testing. Based on your findings, this is most consistent with the 166 MHz Octal DDR XIP read path operating at the edge of its sampling / signal-integrity margin. readSampleClksrc=3 and the DQS trace are necessary but not sufficient conditions: in DDR DQS mode, the RT1160 side still requires the DQS-to-SIO relative skew to stay within ~±1 ns, and 166 MHz is the interface's upper limit, so margin is minimal.  I’ve looked into more resources, and the following solutions may help you resolve the current issue without modifying the PCB: Apply DLL errata ERR011377. The RT1160 errata states that after the DLL lock-status bit is set, an immediate read/write to the external flash may still return wrong data due to a timing issue; the workaround is to wait at least 512 FlexSPI root-clock cycles after the lock bit is set before accessing flash. Please ensure this delay is applied in every path in the bootloader and application that reconfigures FlexSPI/DLL/clock — this fits well with "most frequent at chainload, intermittent at runtime." Run a quantifiable RAM-resident stress test (more effective than repeated power-cycling). Place the test code and fault handler in ITCM/OCRAM, repeatedly read large flash blocks from the AHB memory map with CRC comparison, sweeping 166/133/120 MHz. If the error rate drops sharply as frequency decreases, it confirms a timing/SI-margin issue. For the mcuboot case:  if the bootloader ever erased/programmed the external NOR, you must invalidate I/D-cache before jumping to the application; also confirm the application does not re-initialize FlexSPI with different clock/DLL/LUT/pad settings. If in the end only 166 MHz fails while 133 MHz is stable, we recommend 133 MHz as the safe operating frequency for the current board; if 166 MHz is mandatory for production, the PCB DQS/SCLK/SIO length-matching, impedance, crosstalk, and pad drive strength should be reviewed, with test points added for these signals in the next revision. Best regards, Gavin