S32DS K116编译问题 NXP 工程师，你好！ 我刚开始使用MCSPTE1AK116, 我安装了MCSPTE1AK116-SW；S32K11x_AMMCLIB_RTM_1_1_45_BIN；S32DS-IDE-ARM_2.2.2_D2312；以及FMASTERSW32；我在使用S32DS 导入MCSPTE1AK116_PMSM_FOC_1Sh样例工程并编译，然后把.srec直接复制E盘，并断电重启，使用freemaster连接并运行，可以通讯上，给定速度也可以运行，但是跑一会（几秒钟）就停止，并报PDB0错误。我直接把原始SW下的.srec文件拷贝到E盘，就能正常运行。是我编译的时候哪里设置有误吗？ Re: S32DS K116编译问题 Hi 如果你测试原始文件夹下的.srec可以运行，但你编译后的.srec运行却遇到错误。 那么建议下载较老版本的Automotive Math and Motor Control Library Set for S32K11x试一下。 比如安装MCSPTE1AK116-SW过程中提到的版本S32K11X_AMMCLIB_RTM_1_1_29_BIN S32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.pngS32K116 Motor Control Development Kit AMMCLIB.png MCSPTE1AK116_ReleaseNotes.txt里能看到该项目是基于以下版本开发的： The Development Kit application was built and tested using the following IDE, Drivers and Tools: ===================================================================================== - S32 Design Studio (S32DS) for ARM 2.2 - S32 Software Development Kit (SDK) for S32K1xx 3.0.3 - FreeMASTER 3.1.4.5 请确认S32K1 SDK已经安装了上述3.0.3版本 Best Regards, Robin 回复： S32DS K116编译问题 很奇怪的问题，我使用配套的BLDC_6Steps和PMSM_FOC_2Sh工程直接下载和编译后下载都能正常运行，使用PMSM_FOC_1Sh工程直接下载也可以，就是编译后再下载就不行。 Re: S32DS K116编译问题 Hi Robin 我现在不知道为啥，所有的.srec都跑不起来了。。。没有办法试你的程序。 你能告诉我清空评估板的方法吗？ 我这个S32K116EVB是本月才购买的，如何确认其外观？ Re: S32DS K116编译问题 以下是旧版本不支持电机套件的S32K116EVB-Q048，最明显的区别是少了一排插座(J5)。 S32K116EVB-Q048.pngS32K116EVB-Q048.pngS32K116EVB-Q048.pngS32K116EVB-Q048.pngS32K116EVB-Q048.pngS32K116EVB-Q048.pngS32K116EVB-Q048.png 以下是 S32K116EVB2Q048 的截图: S32K116EVB2Q048.pngS32K116EVB2Q048.pngS32K116EVB2Q048.pngS32K116EVB2Q048.pngS32K116EVB2Q048.pngS32K116EVB2Q048.pngS32K116EVB2Q048.png 建议先拔掉套件，只测试S32K116EVB。 建议使用 P&E Recovery Utility 工具halt CPU 然后下载新程序。 Re: S32DS K116编译问题 Hi 1. 我删除了其余版本，只安装了S32K11x_AMMCLIB_v1.1.29 2. 我身边目前没有这个硬件平台测试，所以附上了基于 S32K11x_AMMCLIB_v1.1.29 编译出的.SREC 文件供你测试。(私信发给你了) 3. 如果能运行正常的话，我将向软件团队为你的账号申请S32K11x_AMMCLIB_v1.1.29 版本软件。 4. 另外可能需要检查一下硬件区别，你的S32K116EVB是S32K116EVB2Q048外观吗？   最早还有个S32K116EVB-Q048板子。 Re: S32DS K116编译问题 Hi Robin 前几天忙别的事情去了，我的是S32K116EVB2Q048。 我之前下载官方例程的.srec都是能正常跑的，现在下载官方的三个工程，运行电机都有问题，具体是下载没问题，通讯没问题，一给定速度并启动电机，电机响两声就报过流故障，这种情况也要下载 P&E Recovery Utility 工具halt CPU 然后下载新程序吗？ Re: S32DS K116编译问题 更新一下故障波形。 TimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpegTimLIANG_0-1787022591582.jpeg Re: S32DS K116编译问题 J9 J10 J11是在12位置，是PMSM 的位置。 TimLIANG_0-1787024596336.jpegTimLIANG_0-1787024596336.jpegTimLIANG_0-1787024596336.jpegTimLIANG_0-1787024596336.jpegTimLIANG_0-1787024596336.jpeg Re: S32DS K116编译问题 如果可以下载.srec只是运行电机控制程序有问题就不需要P&E Recovery Utility工具。这个工具是无法下载新程序的情况下使用的。 FreeMaster界面报过流故障能否截图我查一下。 官方例程里的.srec都能正常跑，只是你重新编译官方的三个工程后运行电机有问题？请问是否试过我给你的基于S32K11x_AMMCLIB_v1.1.29编译出来的.srec? Re: S32DS K116编译问题 Hi Robin 目前的情况是，不管是我编译的，还是官方例程的.srec，都是一启动电机响两声就报过流故障。 故障界面如下，外部设备抓的启动电流也如下： TimLIANG_0-1787020428889.pngTimLIANG_0-1787020428889.pngTimLIANG_0-1787020428889.png TimLIANG_1-1787020447511.pngTimLIANG_1-1787020447511.pngTimLIANG_1-1787020447511.png Re: S32DS K116编译问题 请先根据Get Started with the MCSPTE1AK116 的页面提示，检查硬件电路跳帽是否符合PMSM 配置。

dpaa2_net: FS table with 1 entries full hi creating 1 dpni and dpdmux. on Port 0 creating 2 RXQ . Adding rte_flow as below  memset(&udp_spec, 0, sizeof(udp_spec)); memset(&udp_mask, 0, sizeof(udp_mask)); udp_spec.hdr.dst_port = rte_cpu_to_be_16(udp_port); udp_mask.hdr.dst_port = 0xffff; pattern[0].type = RTE_FLOW_ITEM_TYPE_UDP; pattern[0].spec = &udp_spec; pattern[0].mask = &udp_mask; pattern[1].type = RTE_FLOW_ITEM_TYPE_END; action[0].type = RTE_FLOW_ACTION_TYPE_QUEUE; action[0].conf = &queue; action[1].type = RTE_FLOW_ACTION_TYPE_END; struct rte_flow *flow = rte_flow_create(port_id, &attr, pattern, action, &error); Creating 2 flow on port 0 for RXQ 0 and RXQ 1  create_udp_queue_flow(port_id, 5000, 0); create_udp_queue_flow(port_id, 5001, 1); Getting below error. dpaa2_net: FS table with 1 entries full Re: dpaa2_net: FS table with 1 entries full Hello, The logs and restool output tell a clear story. The DPNI object was provisioned with only 1 fs_entry , which gets consumed by the first flow rule ( UDP 5000 → RXQ 0 ). Any subsequent rte_flow_create() call fails immediately because the hardware FS table has no room left. Port 0 started with 2 RX queues and 7 TX queues UDP port 5000 -> RXQ 0 created dpaa2_net: FS table with 1 entries full dpaa2_net: Failure to create flow, return code (-1) Flow create failed: unknown fslmc: dpaa2_get_qbman_swp(): New Portal 0x17ffebbc0 (2) affined thread - 8602 fslmc: dpaa2_configure_stashing(): Portal= 2 CPU= 1 SDEST= 0 fslmc: DPAA Portal=0x17ffebbc0 (2) is affined for eth rx to thread 8602root@localhost:/home/user# restool dpni info dpni.1 dpni version: 8.2 dpni id: 1 plugged state: plugged endpoint state: 0 endpoint: dpdmux.0.2, link is down link status: 0 - down mac address: ce:8a:4d:82:e7:dc max frame length: 1536 dpni_attr.options value is: 0x80000310 Unrecognized options found... num_queues: 16 num_cgs: 24 num_rx_tcs: 8 num_tx_tcs: 16 mac_entries: 16 vlan_entries: 16 qos_entries: 64 fs_entries: 1 qos_key_size: 56 fs_key_size: 56 10:53 AM     DPAA2 Flow Steering Table Full — Root Cause & Fix The logs and restool output tell a clear story. The DPNI object was provisioned with only 1 fs_entry , which gets consumed by the first flow rule ( UDP 5000 → RXQ 0 ). Any subsequent rte_flow_create() call fails immediately because the hardware FS table has no room left. Root Cause dpaa2_net: FS table with 1 entries full dpaa2_net: Failure to create flow, return code (-1)   Confirmed by restool : fs_entries: 1 ← only 1 hardware flow-steering slot   The DPNI was created (either via DPL or restool dpni create ) without explicitly setting fs-entries , so it defaulted to 1. Fix — Recreate the DPNI with More FS Entries Option 1 — Dynamically via restool (no reflash needed): # Destroy the existing DPNI restool dpni destroy dpni.1 # Recreate it with sufficient FS entries (e.g., 16 or 64) restool dpni create \ --options=DPNI_OPT_HAS_KEY_MASKING \ --num-queues=16 \ --fs-entries=64 \ --num-rx-traffic-classes=8 \ --num-tx-traffic-classes=16 # Re-bind to the DPDMUX endpoint restool dpdmux connect dpdmux.0.2 --endpoint=dpni.X Replace dpni.X with the newly created ID shown after dpni create . Option 2 — Edit the DPL (Data Path Layout) file: Find the dpni@1 object block in your DPL ( .dts / .dpl ) and increase fs_entries : dpni@1 { compatible = "fsl,dpni"; ... fs_entries = <64>; /* was 1, increase as needed */ ... }; Then reload the DPL: restool dprc load dprc.1  Your DPNI already has qos_entries: 64 and qos_key_size: 56 , so the hardware supports it — only the provisioned FS table size was too small. Quick Validation After Fix # Confirm new fs_entries value restool dpni info dpni. | grep fs_entries # Expected: fs_entries: 64 (or whatever you set)   Then retry your DPDK application — the Flow create failed error should be gone.   regards       Re: dpaa2_net: FS table with 1 entries full root@localhost:/home/user# restool dpni info dpni.1 dpni version: 8.2 dpni id: 1 plugged state: plugged endpoint state: 0 endpoint: dpdmux.0.2, link is down link status: 0 - down mac address: ce:8a:4d:82:e7:dc max frame length: 1536 dpni_attr.options value is: 0x80000310 Unrecognized options found... num_queues: 16 num_cgs: 24 num_rx_tcs: 8 num_tx_tcs: 16 mac_entries: 16 vlan_entries: 16 qos_entries: 64 fs_entries: 1 qos_key_size: 56 fs_key_size: 56 Re: dpaa2_net: FS table with 1 entries full ./dpdk-multirxq-sample-prog  -l 1-3 -n 1 --log-level=fslmc,8 --huge-dir /dev/hugepages --proc-type=auto -b fslmc:dpio.16 -b fslmc:dpio.17 -b fslmc:dpio.18 -b fslmc:dpio.19 -b fslmc:dpio.20 -b fslmc:dpio.21 -b fslmc:dpio.22 -b fslmc:dpio.23 -b fslmc:dpmcp.38 -b fslmc:dpmcp.39 EAL: Detected 16 lcore(s) EAL: Detected 1 NUMA nodes EAL: Auto-detected process type: PRIMARY fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) EAL: Multi-process socket /var/run/dpdk/rte/mp_socket fslmc: fslmc_get_container_group(): Container: dprc.2 has VFIO iommu group id = 11 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: **Devargs matched dpmcp.39 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: **Devargs matched dpio.18 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: **Devargs matched dpio.16 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: Skipping invalid device (power) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: **Devargs matched dpio.22 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: **Devargs matched dpio.20 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: **Devargs matched dpio.19 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: **Devargs matched dpmcp.38 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: **Devargs matched dpio.17 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: **Devargs matched dpio.23 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: **Devargs matched dpio.21 fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.16) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.17) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.18) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.19) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.20) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.21) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.22) fslmc: rte_fslmc_parse(): Parsing dev=(dpio.23) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.38) fslmc: rte_fslmc_parse(): Parsing dev=(dpmcp.39) fslmc: FSLMC Bus scan completed fslmc: List of devices scanned on bus: fslmc: dpni.1 fslmc: dpseci.1 fslmc: dpseci.2 fslmc: dpseci.3 fslmc: dpseci.4 fslmc: dpseci.5 fslmc: dpseci.6 fslmc: dpseci.7 fslmc: dpseci.8 fslmc: dpseci.9 fslmc: dpseci.10 fslmc: dpseci.11 fslmc: dpseci.12 fslmc: dpseci.13 fslmc: dpseci.14 fslmc: dpseci.15 fslmc: dpseci.16 fslmc: dpcon.32 fslmc: dpcon.33 fslmc: dpcon.34 fslmc: dpcon.35 fslmc: dpcon.36 fslmc: dpcon.37 fslmc: dpcon.38 fslmc: dpcon.39 fslmc: dpbp.2 fslmc: dpbp.3 fslmc: dpbp.4 fslmc: dpbp.5 fslmc: dpbp.6 fslmc: dpbp.7 fslmc: dpbp.8 fslmc: dpbp.9 fslmc: dpbp.10 fslmc: dpbp.11 fslmc: dpbp.12 fslmc: dpbp.13 fslmc: dpbp.14 fslmc: dpbp.15 fslmc: dpbp.16 fslmc: dpbp.17 fslmc: dpio.16 fslmc: dpio.17 fslmc: dpio.18 fslmc: dpio.19 fslmc: dpio.20 fslmc: dpio.21 fslmc: dpio.22 fslmc: dpio.23 fslmc: dpio.24 fslmc: dpio.25 fslmc: dpio.26 fslmc: dpio.27 fslmc: dpio.28 fslmc: dpio.29 fslmc: dpio.30 fslmc: dpio.31 fslmc: dpci.0 fslmc: dpci.1 fslmc: dpmcp.37 fslmc: dpmcp.38 fslmc: dpmcp.39 fslmc: dpdmai.0 fslmc: dpdmai.1 fslmc: dpdmai.2 fslmc: dpdmai.3 fslmc: dpdmai.4 fslmc: dpdmai.5 fslmc: dpdmai.6 fslmc: dpdmai.7 fslmc: dpdmux.0 fslmc: dprc.2 EAL: Selected IOVA mode 'VA' EAL: No available hugepages reported in hugepages-2048kB EAL: No available hugepages reported in hugepages-32768kB EAL: No available hugepages reported in hugepages-64kB EAL: Probing VFIO support... EAL: VFIO support initialized fslmc: fslmc_get_container_group(): Container: dprc.2 has VFIO iommu group id = 11 fslmc: fslmc_vfio_setup_group(): VFIO Container FD is [0x1B] fslmc: fslmc_map_dma(): --> Map address: 0x140000000, size: 1073741824 fslmc: rte_fslmc_vfio_dmamap(): Installed memory callback handler fslmc: rte_fslmc_vfio_dmamap(): Total 1 segments found. fslmc: Unable to map region (errno = 22) fslmc: dpmcp.38 Blacklisted, skipping fslmc: dpmcp.39 Blacklisted, skipping fslmc: Device (dprc.2) abstracted from VFIO fslmc: Device (dpni.1) abstracted from VFIO fslmc: Device (dpseci.1) abstracted from VFIO fslmc: Device (dpseci.2) abstracted from VFIO fslmc: Device (dpseci.3) abstracted from VFIO fslmc: Device (dpseci.4) abstracted from VFIO fslmc: Device (dpseci.5) abstracted from VFIO fslmc: Device (dpseci.6) abstracted from VFIO fslmc: Device (dpseci.7) abstracted from VFIO fslmc: Device (dpseci.8) abstracted from VFIO fslmc: Device (dpseci.9) abstracted from VFIO fslmc: Device (dpseci.10) abstracted from VFIO fslmc: Device (dpseci.11) abstracted from VFIO fslmc: Device (dpseci.12) abstracted from VFIO fslmc: Device (dpseci.13) abstracted from VFIO fslmc: Device (dpseci.14) abstracted from VFIO fslmc: Device (dpseci.15) abstracted from VFIO fslmc: Device (dpseci.16) abstracted from VFIO fslmc: Device (dpcon.32) abstracted from VFIO fslmc: Device (dpcon.33) abstracted from VFIO fslmc: Device (dpcon.34) abstracted from VFIO fslmc: Device (dpcon.35) abstracted from VFIO fslmc: Device (dpcon.36) abstracted from VFIO fslmc: Device (dpcon.37) abstracted from VFIO fslmc: Device (dpcon.38) abstracted from VFIO fslmc: Device (dpcon.39) abstracted from VFIO fslmc: Device (dpbp.2) abstracted from VFIO fslmc: Device (dpbp.3) abstracted from VFIO fslmc: Device (dpbp.4) abstracted from VFIO fslmc: Device (dpbp.5) abstracted from VFIO fslmc: Device (dpbp.6) abstracted from VFIO fslmc: Device (dpbp.7) abstracted from VFIO fslmc: Device (dpbp.8) abstracted from VFIO fslmc: Device (dpbp.9) abstracted from VFIO fslmc: Device (dpbp.10) abstracted from VFIO fslmc: Device (dpbp.11) abstracted from VFIO fslmc: Device (dpbp.12) abstracted from VFIO fslmc: Device (dpbp.13) abstracted from VFIO fslmc: Device (dpbp.14) abstracted from VFIO fslmc: Device (dpbp.15) abstracted from VFIO fslmc: Device (dpbp.16) abstracted from VFIO fslmc: Device (dpbp.17) abstracted from VFIO fslmc: dpio.16 Blacklisted, skipping fslmc: dpio.17 Blacklisted, skipping fslmc: dpio.18 Blacklisted, skipping fslmc: dpio.19 Blacklisted, skipping fslmc: dpio.20 Blacklisted, skipping fslmc: dpio.21 Blacklisted, skipping fslmc: dpio.22 Blacklisted, skipping fslmc: dpio.23 Blacklisted, skipping fslmc: dpaa2_create_dpio_device(): LX2160 Platform Detected fslmc: Device (dpio.24) abstracted from VFIO fslmc: Device (dpio.25) abstracted from VFIO fslmc: Device (dpio.26) abstracted from VFIO fslmc: Device (dpio.27) abstracted from VFIO fslmc: Device (dpio.28) abstracted from VFIO fslmc: Device (dpio.29) abstracted from VFIO fslmc: Device (dpio.30) abstracted from VFIO fslmc: Device (dpio.31) abstracted from VFIO fslmc: Device (dpci.0) abstracted from VFIO fslmc: Device (dpci.1) abstracted from VFIO fslmc: Device (dpdmai.0) abstracted from VFIO fslmc: Device (dpdmai.1) abstracted from VFIO fslmc: Device (dpdmai.2) abstracted from VFIO fslmc: Device (dpdmai.3) abstracted from VFIO fslmc: Device (dpdmai.4) abstracted from VFIO fslmc: Device (dpdmai.5) abstracted from VFIO fslmc: Device (dpdmai.6) abstracted from VFIO fslmc: Device (dpdmai.7) abstracted from VFIO fslmc: Device (dpdmux.0) abstracted from VFIO PMD: dpni.1: netdev created, connected to dpdmux.0 fslmc: dpaa2_get_qbman_swp(): New Portal 0x17fff3280 (1) affined thread - 8602 fslmc: dpaa2_configure_stashing(): Portal= 1 CPU= 1 SDEST= 0 fslmc: DPAA Portal=0x17fff3280 (1) is affined to thread 8602 Port 0 started with 2 RX queues and 7 TX queues UDP port 5000 -> RXQ 0 created dpaa2_net: FS table with 1 entries full dpaa2_net: Failure to create flow, return code (-1) Flow create failed: unknown fslmc: dpaa2_get_qbman_swp(): New Portal 0x17ffebbc0 (2) affined thread - 8602 fslmc: dpaa2_configure_stashing(): Portal= 2 CPU= 1 SDEST= 0 fslmc: DPAA Portal=0x17ffebbc0 (2) is affined for eth rx to thread 8602 Re: dpaa2_net: FS table with 1 entries full Thanks resolved 

How Can I Watch All Live Events? Hi everyone, I’m a student and I’m trying to find a simple and reliable way to watch live events, sports, news, and other live programs online without getting confused by too many different websites and apps. I’ve heard people mention IPTVGREAT, but I’m not looking to promote any service. I just want to understand my options and find something that is safe, affordable, and easy for a student to use. If you have experience with watching live content online, could you please share some advice? I’d especially appreciate recommendations for legal and reliable options, free services, or affordable platforms that work well on a laptop or phone. Thanks to anyone who can help. I’m just trying to find a practical solution without spending too much as a student.

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.

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

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 Re: i.MX8M Plus EXT4-fs error The added trace confirms the panic is a configured response to an EXT4 metadata error on dm-6 ; Binder is probably just the userspace thread that happened to create/open a file when EXT4 detected the corrupt directory block. What happened: EXT4 detected an invalid directory entry while creating a file: the call path is openat() → ext4_create() → ext4_add_entry() → ext4_find_dest_de() . The directory block is corrupt: inode=0, rec_len=0 at offset=0 is not a valid EXT4 directory entry. EXT4 then aborted the journal: Aborting journal on device dm-6-8 . The kernel panicked because the filesystem is configured for errors=panic ; EXT4 has explicit panic-on-error modes ( EXT4_MOUNT_ERRORS_PANIC , EXT4_ERRORS_PANIC ). So the immediate issue is filesystem corruption on the block device behind dm-6 , not a Binder driver failure. Most likely location is Android /data / userdata if dm-6 is a mapped encrypted userdata device. NXP i.MX Linux documentation shows EXT4 filesystems can be created on device-mapper crypt devices, and the crypt target intercepts block I/O . NXP Android notes also state that after erasing userdata, Android recreates the EXT4 filesystem and encryption setup on first boot, and normal boot can call e2fsck to check the filesystem . Recommended debug sequence: adb root adb shell mount | grep dm-6 adb shell cat /proc/mounts | grep dm-6 adb shell ls -l /dev/block/mapper adb shell ls -l /dev/block/by-name adb shell dmctl list devices adb shell dmsetup table Then check for the real lower-layer cause before the EXT4 panic: adb shell dmesg | grep -Ei "mmc|cqhci|timeout|I/O error|Buffer I/O|dm-|verity|ext4|jbd2" If dm-6 maps to /data / userdata: Boot to recovery, initramfs, or another mode where userdata is not mounted read-write . Run: e2fsck -f -y /dev/block/by-name/userdata or run it on the correct mapped node only if that is the intended unmounted filesystem target: e2fsck -f -y /dev/block/dm-6 NXP community guidance for similar EXT4 corruption is to check/repair the filesystem with fsck / e2fsck ; one reported EXT4 corruption case was resolved with e2fsck . If the unit is a development board and data preservation is not required, the cleaner recovery is usually: fastboot erase userdata fastboot reboot or reflash the Android image set. Android will recreate userdata on first boot in the normal userdata-encryption flow . For root cause, focus on these areas: Unexpected power loss or reset during eMMC writes. NXP material notes that power loss during eMMC writing can reproduce filesystem/superblock damage, and sudden power loss or power-cycle stress can cause eMMC/SD data corruption. eMMC / storage errors. Look for lower-level mmc , cqhci , timeout, or I/O errors before the EXT4 message. Power integrity / reset sequencing. If this happens during repeated power cycling, increase the off/on interval and verify the PMIC/eMMC rails are stable before boot. DDR instability. Similar NXP forum guidance for EXT4 directory corruption also suggested checking whether all patches are applied and validating DDR calibration with the DDR stress test when power timing did not resolve the issue. Takeaway: map dm-6 ; if it is userdata, run offline e2fsck or erase/recreate userdata, then investigate eMMC power-loss/reset, lower-level MMC I/O errors, and DDR stability as the likely root causes.

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 Re: ls104x higher version of Linux 6.+ Please refer to the following link. https://github.com/nxp-qoriq/yocto-sdk Branch Version wrynose YP 6.0-lf-6.18.20 whinlatter YP 5.3-lf-6.18.2 walnascar YP 5.2-lf-6.12.49 styhead YP 5.1-lf-6.12.3 scarthgap YP 5.0-lf-6.6.52 nanbield YP 4.3-lf-6.6.3 mickledore YP 4.2–lf-6.1.55 langdale YP 4.1–lf-6.1.1

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 Re: OX05B1S GMSL2 camera with MAX96717/MAX96724 on i.MX95 yes, refer to the driver mx95mbcam.c which uses OX03C10, if you need change the camera, you should change this driver totally,  https://github.com/nxp-imx/linux-imx/blob/lf-6.18.y/drivers/media/i2c/mx95mbcam.c

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

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. Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time how about the failing rate？If the failing rate is higher than 50%，please share the error log for further analysis. Meanwhile does your application have requirement to program and erase internal flash very often？ Re: Device with MK22FN1M0VLQ12 resetting loop after working for some time Hello @Rigolon , Thanks for the additional details. The debugger halting at ASerialLDD2_Init or IntFlashLdd1_Erase without a breakpoint is a strong indicator that a fault (e.g., HardFault or BusFault) is occurring, not that execution is actually reaching those functions normally. A likely cause is corruption in the vector table region of Flash, if the fault handler vectors are corrupted, the MCU may jump to an incorrect address that happens to land near those PE-generated functions. You can check the HFSR、CFSR、BFAR、MMFAR registers.  And you can also refer to the way in How to debug a HardFault on an ARM Cortex-M MCU | Interrupt to verify whether it is indeed a Hard Fault. Hope it helps. BR Celeste

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 Re: T1040 mEMAC TX_FIFO_OVFL on port when another port loses link Thanks for the explanation. I checked the FMBM_PP configuration for the 1G TX ports. They are configured with the default values: MXT = 3: 4 maximum concurrent tasks MXD = 2: 3 maximum outstanding DMA requests I also experimented with the per-port resource limits. I increased and decreased DMA requests and concurrent tasks settings. This did not produce an observable improvement with TX FIFO Overflow. Given that a 1G TX port can only have 3 outstanding DMA requests with the default configuration, I am not sure how a single stalled 1G port could consume enough of the shared DMA resources to significantly affect another port. Is there a smaller shared DMA channel/resource pool separate from the 84-entry FMan v3 DMA command queue, or can a small number of stalled DMA transactions cause head-of-line blocking or otherwise prevent DMA transactions from other ports from progressing? Also, is there a DMA status/debug register or counter that can be used to confirm that outstanding DMA transactions from the link-down port are actually remaining open during this condition?

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:  Oswalag_0-1786397230469.pngOswalag_0-1786397230469.png 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 Re: Profinet porting on iMX95EVK Hi, Any update on this query. Re: Profinet porting on iMX95EVK Hello,  Please check the following fact-sheet, there is information about the core's roles  https://www.nxp.com/docs/en/fact-sheet/PROFINETFS.pdf All the available documentation is in https://www.nxp.com/design/design-center/software/development-software/software-for-industrial-networking/profinet-industrial-ethernet-protocol-software:PROFINET-INDUSTRIAL-COMMUNICATIONS-SOFTWARE For more information you can contact NXP Pro Support services 

关于RAM空间分配的问题 各位NXP官方的技术人员你们好 我在使用S32K144的过程中遇到了一些问题 Ni__0-1786357891196.png 在这个地址分配表中 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 _0-1786361688597.png 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: Julin_AragnM_0-1786473457854.png 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: Julin_AragnM_3-1786576291659.pngJulin_AragnM_3-1786576291659.png 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. Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit Hello. After I soldered pin 41 (PTD 14) of the MCU and pin 25 (RX_CTL/CONFIG6) of the TJA1103A, the ping really started working. Thanks!

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. Screenshot 2026-08-10 124516.png Screenshot 2026-08-10 124021.png Screenshot 2026-08-10 124207.png Screenshot 2026-08-10 124302.png 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