Request for S32 Design Studio License Renewal Hello, I am currently using S32 Design Studio v3.4 and my license is about to expire. Could you please help me extend or renew the license? Here are the details: Activation Code: E1D3-XXXX-XXXX -XXXX Current Expiration Date: 2026-1-4 I would appreciate your support in renewing the license so I can continue using S32DS without interruption. Thank you in advance for your assistance. Best regards,

KV58F220M GHSフラッシュの問題 こんにちは、チームの皆さん。RAM にコードをダウンロードする際に問題が発生しています。ご参考までにPFA。   コマンドからの出力: Green Hills Probe エラー 1 (一般エラー)。 エラー 1 (一般エラー): Icepick はコアをアクティブ化できませんでした。   ロード: ダウンロードに失敗しました。 Re: KV58F220M GHS FLASH ISSUE ご返信ありがとうございます。開始スクリプトでRAMアドレスをリンクしてGHSからサポートを受けてみようと思います。 Re: KV58F220M GHS FLASH ISSUE こんにちは@Pavan_Moodyさん、 ご投稿ありがとうございます。残念ながら、Green Hills または Green Hills プローブが入手できないため、私の側で試すことができません。MCUXpresso と当社の SDKs を使用してテストしたところ、すべて正常に動作しました。SDKはここから入手できます：ボードを選択 | MCUXpresso SDK Builder。テスト手順は次のとおりです。 1. SDKの「Hello World」デモをmcuxpressoにインポートする 2. 「アプリケーションをRAMにリンク」オプションを設定します 3. RAMを位置1に移動する 4. コンパイルとデバッグ すべて問題なく実行されました。 Green Hills に関しては、当社が公式にサポートしている IDEs ではありません。引き続き使用したい場合は、サポート チームに直接問い合わせることをお勧めします。 ご理解いただきありがとうございます。良い一日をお過ごしください。 BR セレステ Re: KV58F220M GHS FLASH ISSUE コマンドからの出力: セットアップ スクリプトを実行しています: C:\ユーザー\Pavan.Jm\Downloads\KV58ramconfig\Project57\tgt\mpserv_standard.mbs エラー1（一般エラー）：SWD障害 エラー 1 (一般エラー): CTRL/STAT.STICKYERR が設定されています Green Hills Probe エラー 1 (一般エラー)。 エラー 1 (一般エラー): コア 1 のレジスタ trcpdsr を読み取ることができませんでした。 マニュアルのジャンパー設定に従いましたが、まだ他の問題があります。CAN、助けていただけませんか。

KV58F220M GHS FLASH ISSUE Hi Team, i am finding issue in downloading code in RAM. FYI PFA.   Output from command: Green Hills Probe error 1 (general error). ERROR 1 (general error): Icepick could not activate core.   load: Download failed. Re: KV58F220M GHS FLASH ISSUE Thank you for the response, where i can try linking RAM address in my starting script and try to get support from GHS Re: KV58F220M GHS FLASH ISSUE Hello @Pavan_Moody , Thank you for your post. Unfortunately, we don’t have Green Hills or the Green Hills probe available, so I’m unable to try it on my side. I tested using MCUXpresso and our SDK, and everything worked fine. SDK can be found here: Select Board | MCUXpresso SDK Builder. The test steps were as follows: 1. Import the SDK “Hello World” demo into mcuxpresso 2. Set the “Link application to RAM” option 3. Move RAM to position 1 4. Compile and debug Everything ran without issues. As for Green Hills, it is not one of our officially supported IDEs. If you prefer to continue using it, I recommend reaching out directly to their support team. Thanks for your understanding and have a nice day. BR Celeste Re: KV58F220M GHS FLASH ISSUE Output from command: Executing setup script: C:\Users\Pavan.Jm\Downloads\KV58ramconfig\Project57\tgt\mpserv_standard.mbs ERROR 1 (general error): SWD FAULT ERROR 1 (general error): CTRL/STAT.STICKYERR set Green Hills Probe error 1 (general error). ERROR 1 (general error): Couldn't read register trcpdsr on core 1. I HAVE followed Jumper setup in manual still i have some other issue can you help me out .

S32N55: How to build a blob image for fast wake-up boot. Hello Team, As we know, the S32N55 supports Fast Wake-up Boot. I tried building a blob image using the same format as Full Wake-up Boot, but the boot process failed. Could you please guide me on how to correctly build a blob image for Fast Wake-up Boot? Thank you! Best regards, Tangsheng. FSS_FW Priority: MEDIUM Re: S32N55: How to build a blob image for fast wake-up boot. Hello @Tangsheng_Zhou, The team has picked up the case and will provide an answer as soon as possible.  Best regards, Radu  Re: S32N55: How to build a blob image for fast wake-up boot. Hello @RaduBraga  I noticed that this ticket has been closed. Is there any update on the progress?   Best regards, Tangsheng.

引入 CW 发射器是为了向 RFID 标签注入额外的能量 你好，我有一个关于 UCODE 8 (U8) 无源超高频 RFID 标签的问题。 根据数据表，该标签对来自阅读器的 ASK 调制信号采用非相干解调（包络检测）。 当另外一个独立的 CW 发射器（与读取器的频率不同，例如 924Mhz v.s.910Mhz），为标签注入额外能量，但并不会增加反向散射通信范围。有时，它甚至会导致通信不稳定或通信距离缩短。 这似乎与直觉相反。 额外的 CW 信号提供了更大的能量，但结果并不是更远的距离。

CW transmitter is introduced to inject extra energy into the RFID tag Hello, I have a question regarding the UCODE 8 (U8) passive UHF RFID tag. According to the datasheet, the tag uses non-coherent demodulation (envelope detection) for ASK-modulated signals from the reader. When an additional, independent CW transmitter (different frequency as the reader, e.g., 924Mhz v.s. 910Mhz) is introduced to inject extra energy into the tag, it does not increase the backscatter communication range. Sometimes, it even causes unstable communication or reduces the range. This seems counterintuitive. The extra CW signal provides more energy, but the result is not a longer range.

How to push stream to display in iMX95 Verdin EVK with the NXP os08a20 camera I have recently bought the X-IMX-OS08A20 camera module from https://www.nxp.com/design/design-center/development-boards-and-designs/4K-MIPI-CMOS-CAMERA-MODULE. I have connected it to the iMX95 Verdin EVK kit and the camera gets detected properly and probes successfully. I am using the following dtb-  imx95-19x19-verdin-os08a20-isp-lt8912.dtb I am running the following v4l2 commands and I could get the v4l2 stream with stream-mmap command. The following is the commands which I use media-ctl -d /dev/media0 -l "'os08a20 2-0036':0 -> 'csidev-4ad30000.csi':0[1]" media-ctl -d /dev/media0 -l "'csidev-4ad30000.csi':1 -> '4ac10000.syscon:formatter@20':0[1]" media-ctl -d /dev/media0 -l "'4ac10000.syscon:formatter@20':1 -> 'crossbar':2[1]" media-ctl -d /dev/media0 -l "'crossbar':5 -> 'mxc_isi.0':0[1]" media-ctl -d /dev/media0 -l "'mxc_isi.0':1 -> 'mxc_isi.0.capture':0[1]" echo "media setting" media-ctl -d /dev/media0 -R "'os08a20 2-0036' [1/0->0/0[1]]" media-ctl -d /dev/media0 -R "'csidev-4ad30000.csi' [0/0->1/0[1]]" media-ctl -d /dev/media0 -R "'4ac10000.syscon:formatter@20' [0/0->1/0[1]]" media-ctl -d /dev/media0 -R "'crossbar' [2/0->5/0[1]]" echo "routing done" media-ctl -d /dev/media0 -V "'os08a20 2-0036':0/0 [fmt:SBGGR10/3840x2160 field:none]" media-ctl -d /dev/media0 -V "'csidev-4ad30000.csi':0/0 [fmt:SBGGR10/3840x2160 field:none]" media-ctl -d /dev/media0 -V "'4ac10000.syscon:formatter@20':0/0 [fmt:SBGGR10/3840x2160 field:none]" media-ctl -d /dev/media0 -V "'crossbar':2/0 [fmt:SBGGR10/3840x2160 field:none]" media-ctl -d /dev/media0 -V "'mxc_isi.0':0/0 [fmt:SBGGR10/3840x2160 field:none]" echo "linking Completed " I run the following command to get the frames with v4l2 and I am able to get the expected 30 fps. v4l2-ctl -d /dev/video0 --set-fmt-video=width=3840,height=2160,pixelformat=BG10 --stream-mmap <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.04 fps <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.04 fps <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.04 fps I am trying to push it  to the display and i face this issue.  root@imx95-19x19-verdin:~# gst-launch-1.0 libcamerasrc ! video/x-raw,format=BGRx,width=3840,height=2160 ! videoconvert ! fpsdisplaysink video-sink=autovideosink text-overlay=true Setting pipeline to PAUSED ... [0:01:33.994814097] [774] INFO Camera camera_manager.cpp:326 libcamera v0.5.0+330-7fce0333-dirty (2025-06-04T12:23:54UTC) Pipeline is live and does not need PREROLL ... [0:01:34.098980249] [780] WARN ISI imx8-isi.cpp:353 Cannot find a supported YUV/RGB format Pipeline is PREROLLED ... Setting pipeline to PLAYING ... ERROR: from element /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: Internal data stream error. Additional debug info: /usr/src/debug/libcamera/0.5.0.imx/src/gstreamer/gstlibcamerasrc.cpp(682): gst_libcamera_src_task_enter (): /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: streaming stopped, reason not-negotiated (-4) ERROR: pipeline doesn't want to preroll. Execution ended after 0:00:00.000314034 Setting pipeline to NULL ... [0:01:34.099615025] [780] WARN ISI imx8-isi.cpp:353 Cannot find a supported YUV/RGB format ERROR: from element /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: Internal data stream error. Additional debug info: /usr/src/debug/libcamera/0.5.0.imx/src/gstreamer/gstlibcamerasrc.cpp(682): gst_libcamera_src_task_enter (): /GstPipeline:pipeline0/GstLibcameraSrc:libcamerasrc0: streaming stopped, reason not-negotiated (-4) Freeing pipeline ... cam -c 1 --info [0:01:09.047021603] [772] INFO Camera camera_manager.cpp:326 libcamera v0.5.0+330-7fce0333-dirty (2025-06-04T12:23:54UTC) [0:01:09.152506530] [772] WARN ISI imx8-isi.cpp:353 Cannot find a supported YUV/RGB format Using camera /base/soc/bus@42000000/i2c@42530000/os08a20_mipi@36 as cam0 0: 3840x2160-SBGGR10 * Pixelformat: SBGGR10 (3840x2160)-(3840x2160)/(+1,+1) - 3840x2160 * Pixelformat: SBGGR12 (3840x2160)-(3840x2160)/(+1,+1) - 3840x2160 Till now I have not exported MATCH_LIST regarding the libcamera and the above are those logs. After this I export export LIBCAMERA_PIPELINES_MATCH_LIST='nxp/neo,imx8-isi' root@imx95-19x19-verdin:~# cam -c 1 --info [0:01:46.524765885] [782] INFO Camera camera_manager.cpp:326 libcamera v0.5.0+330-7fce0333-dirty (2025-06-04T12:23:54UTC) [0:01:46.642824790] [783] INFO NxpNeoIPA neo_ipa.cpp:128 nxpneo: IPANxpNeo NXPNEO_IPA_v0.5.0+330-7fce0333-dirty (2025-06-04T12:23:54UTC) Using camera /base/soc/bus@42000000/i2c@42530000/os08a20_mipi@36 as cam0 0: 3840x2160-BGR888 * Pixelformat: R8 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: R10 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: R12 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: R16 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: NV21 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: NV61 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: NV12 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: XBGR8888 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: BGR888 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: RGB888 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: XRGB8888 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: NV16 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: YUYV (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: XVUY8888 (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 * Pixelformat: UYVY (1920x1080)-(3840x2160)/(+0,+0) - 1920x1080 - 3840x2160 After this when I run the following gstreamer command the stream does not begin. There is no response for this process until it gets killed.  root@imx95-19x19-verdin:~# GST_DEBUG=3 gst-launch-1.0 libcamerasrc ! videoconvert ! autovideosink Setting pipeline to PAUSED ... [0:04:17.443233635] [794] INFO Camera camera_manager.cpp:326 libcamera v0.5.0+330-7fce0333-dirty (2025-06-04T12:23:54UTC) [0:04:17.562332552] [798] INFO NxpNeoIPA neo_ipa.cpp:128 nxpneo: IPANxpNeo NXPNEO_IPA_v0.5.0+330-7fce0333-dirty (2025-06-04T12:23:54UTC) Pipeline is live and does not need PREROLL ... 0:00:00.203418021 794 0xffffa4000b70 FIXME default gstutils.c:4169:gst_element_decorate_stream_id_internal: Creating random stream-id, consider implementing a deterministic way of creating a stream-id Pipeline is PREROLLED ... Setting pipeline to PLAYING ... 0:00:00.203987701 794 0xffffa4000b70 WARN default gstlibcamera-utils.cpp:345:gst_libcamera_stream_formats_to_caps: Unsupported DRM format R10 0:00:00.204038448 794 0xffffa4000b70 WARN default gstlibcamera-utils.cpp:345:gst_libcamera_stream_formats_to_caps: Unsupported DRM format R12 New clock: GstSystemClock 0:00:00.204228106 794 0xffffa4000b70 WARN default gstlibcamera-utils.cpp:345:gst_libcamera_stream_formats_to_caps: Unsupported DRM format XVUY [0:04:17.578186764] [799] INFO Camera camera.cpp:1205 configuring streams: (0) 3840x2160-NV21 0:00:00.0 / 99:99:99. How to overcome this issue. Can you please guide me on this. Re: How to push stream to display in iMX95 Verdin EVK with the NXP os08a20 camera I don't have this board to reproduce this issue, I tested hdmi with imx95-19x19-evk-os08a20-isp-it6263-lvds0.dtb without any issue, pls contact the vendor to support this, or try to use other dtb file to test again Re: How to push stream to display in iMX95 Verdin EVK with the NXP os08a20 camera https://community.nxp.com/t5/i-MX-Processors/How-to-display-video-capture-by-OS08A20-camera-via-HDMI-LT8912/m-p/2170756/page/2 The above link contains the same query regarding the streaming. Can you please check and confirm what solution was provided as I couldnt find one. Thanks. Re: How to push stream to display in iMX95 Verdin EVK with the NXP os08a20 camera Is there any solution for this , as I see many of them struggling with the same issue. We have bought the kit as well as the camera. It would be of great help if you could help Re: How to push stream to display in iMX95 Verdin EVK with the NXP os08a20 camera currently we don't support Verdin EVK since imx95 has still under preproduction stage, and I couldn't reproduce this on my board, refer to your log, the issue is related to the display side, you need contact the third party company to check if they verify this or not Re: How to push stream to display in iMX95 Verdin EVK with the NXP os08a20 camera you can contact this  https://www.toradex.com/support Re: How to push stream to display in iMX95 Verdin EVK with the NXP os08a20 camera the issue is related to the lt8912 which isn't supported by the nxp imx95 evk board, so I couldn't reproduce this and debug this, and current policy for Verdin board support is that customer needs to contact Verdin to check, because imx95 is still under preproduction stage, we didn't support the third party company board yet, if I can reproduce this on my board, I can try to give you suggestion or solution, but since this issue is only can be reproduced on their board with their SW, pls contact them directly in current stage Re: How to push stream to display in iMX95 Verdin EVK with the NXP os08a20 camera I have cloned the kernel source from NXP and I am using it ( regarding SW). Also the camera gets probed properly in my case and could get v4l2 stream. Is it possible for you to loop me with the Verdin contact for clarifying this issue. Thanks

imx8mp & pca9450c program cannot start When the board was initially powered on, all output voltages of the PCA9450 were normal. After downloading a program using SDPS mode on an M8P board without any program loaded, all power supplies to the PCA9450C except for LDO1 and LDO2 lost power. Using an oscilloscope to observe the PCA9450C startup, it was found that all power supply voltages, except for LDO1 and LDO2, exhibited pulses with 100ms intervals. These pulses lasted for several cycles before the power supply returned to normal. Below are the logs after downloading the program and the oscilloscope voltage readings. i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus PMIC Re: imx8mp & pca9450c program cannot start @guoweisun , Re: imx8mp & pca9450c program cannot start @guoweisun , Re: imx8mp & pca9450c program cannot start Call me at 147. Re: imx8mp & pca9450c program cannot start @guoweisun , 感谢回复 Re: imx8mp & pca9450c program cannot start Here we only look at the PCA9450 exception and test the VIN/BUCK1/POWER _ON_REQUEST waveforms

s32k144 - SPDの統合方法 SPD を統合する方法に関するヘルプが必要です - S32K144。このSPDはASIL-B準拠を達成するのに十分でしょうか？ Re: s32k144 - how to integrate SPD ハイ クリスマス休暇期間中は、サポートの応答時間は通常より長くなる場合がありますのでご了承ください。場合によっては、ご要望への対応が新年以降になることもあります。ご理解のほどよろしくお願いいたします。 前回の議論を読みました: Design stdio 付きの無料 RTOS が必要 - FS32K144HAT0MMHT S32K1 用拡張 MCEM ドライバ バージョン 1.0.1およびSW32K1_S32M24x_RTD_4.4_R21-11_2.0.0_D2308をダウンロードしましたか? EB Tresos 29 を構成ツールとして使用している場合は、 SW32K1_S32M24x_RTD_4.4_R21-11_2.0.0_D2308.exeとS32K1_EMCEM_1.0.1_D2408.exeをインストールしてください。 構成ツールおよびコンパイラとしてS32DS v3.5 を使用している場合は、S32DS v3.5 内でSW32K1_S32M24x_RTD_4.4_R21-11_2.0.0_D2308_DS_Updatesite.zipおよびS32K1_EMCEM_1.0.1_DS_updatesite_D2408.zip をオフラインでインストールしてください。 以下は S32K1_EMCEM_1.0.1_D2408 のドキュメントです。 C:\NXP\SW32K1_EMCEM_1.0.1_D2408\S32_SAF_Demo\doc\S32K1XX_EMCEM_IA_UM.pdf C:\NXP\SW32K1_EMCEM_1.0.1_D2408\eclipse\plugins\eMcem_TS_T40D2M10I1R0\doc\S32K1_EMCEM_UM.pdf よろしくお願いします、 ロビン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「解決策として承認」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 ---------------------------------------------------------------------------------

MCU Link pro as a SEGGER J-Link debug probe does not allow to increase SWO clk more than 6000kHz!! I am using MCU Link pro as a SEGGER J-Link debug probe as recommended here: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-install-Segger-Firmware-in-MCU-LINK-PRO/ta-p/2100846 This configuration allows MCU link pro to be used as SEGGER Jlink Debug probe but this does not allow to increase SWO clk more than 6000kHz?  In case of SEGGER J-Link base debug probe this is 30000kHz I would like to know if this is MCU Link pro limitation or SEGGER Jlink FW used in MCU Link pro?  Thank you in advance, Pratik Re: MCU Link pro as a SEGGER J-Link debug probe does not allow to increase SWO clk more than 6000kHz Hi @PratikKunjir  MCU-Link Pro is a low-cost debugger designed primarily for basic debugging functionality, without optimization for high-performance SWO Trace. The SWO rate is constrained by the processing power and interface bandwidth of the debugger's internal MCU. Best Regards, Zhiming Re: MCU Link pro as a SEGGER J-Link debug probe does not allow to increase SWO clk more than 6000kHz Thank you @Zhiming_Liu ,  Is there any possibility to increase baudrate more than 6000 kHz in future releases?

Clarification on Pin Multiplexing Differences Between CM7 and CM4 on i.MX RT1176 Hello everyone, I am working with the i.MX RT1176 using MCUXpresso SDK and developing applications for both the CM7 (primary) and CM4 (secondary) cores. I have an application that runs correctly on the CM7 core, and I replicated the same application logic on the CM4 core. The CM4 project builds successfully without errors. However, I noticed a significant difference in the generated pin_mux.c files for the two cores. In the CM7 project, the pin_mux.c file configures multiple peripherals such as ENET, LPUART1 and LPUART2, CAN, I2C, and several GPIOs. In contrast, the CM4 pin_mux.c file only configures LPUART1 and a limited number of GPIO pins. Peripherals like LPUART2, ENET, CAN, and I2C are completely absent in the CM4 pin configuration. Is this difference expected on the RT1176 due to core ownership, XRDC restrictions, or the way MCUXpresso generates projects for dual-core devices? What is the recommended approach when moving functionality from CM7 to CM4? Should pin multiplexing always be initialized on the CM7 core only, or is it valid for CM4 to configure its own pin multiplexing if clocks and XRDC permissions are set appropriately? Any guidance or best practices from NXP or experienced users would be greatly appreciated. Thank you. Evaluation Board Re: Clarification on Pin Multiplexing Differences Between CM7 and CM4 on i.MX RT1176 Hi @meetbhatt2113 , Thank you so much for your interest in our products and for using our community. Q1: Is this difference expected on the RT1176 due to core ownership, XRDC restrictions, or the way MCUXpresso generates projects for dual-core devices? A1: I suggest you can refer to IMXRT1170RM chapter3 Memory Maps, especially 3.2 System memory map (CM7) and 3.3 System memory map (CM4). You can find out that multiple peripherals can run in CM4. Q2: What is the recommended approach when moving functionality from CM7 to CM4? Should pin multiplexing always be initialized on the CM7 core only, or is it valid for CM4 to configure its own pin multiplexing if clocks and XRDC permissions are set appropriately? A2: There are many SDK demos for CM4 for you to refer.        Pin multiplexing can be initialized on the CM7 core, but synchronization with the CM4 core must be carefully managed. Alternatively, CM4 can configure its own pin multiplexing if required. The choice depends on your project  requirement. Q3:  Any guidance or best practices from NXP or experienced users would be greatly appreciated. A3:  I suggest you can refer to  the following application notes. https://www.nxp.com/docs/en/application-note/AN13264.pdf https://www.nxp.com/docs/en/application-note/AN13114.pdf Wish it helps you. If you still have question about it, please kindly let me know.  Best Regards MayLiu

88W9098 lf-6.12.34_2.1.0 firmware failure with uap_max_sta=64 We are evaluating the NXP 88W9098 chipset, as used in a uBlox JODY-W377-00B module on a TI TMDS64EVM evaluation board, mostly for use an an access point via Linux. Specifically, we have been setting uap_max_sta=64 and max_sta_conn=64 in wifi_mod_para.conf to support high connectivity. This no longer seems to work. It worked fine Using the lf-6.12.20_2.0.0 branch (May 27, 2025) of https://github.com/nxp-imx/mwifiex  and https://github.com/nxp-imx/imx-firmware (which identifies as "PCIE9098--17.92.1.p149.70-MM6X17537.p9-GPL-(FP92)") Recently I updated to the lf-6.12.34_2.1.0 branch (Aug 27, 2025) of both of the above repositories, and WiFi no longer works (firmware init failure) with the above settings of uap_max_sta=64 and max_sta_conn=64. This is using version 540.p7 of mlan.ko and moal.ko and version "PCIE9098--17.92.1.p149.76-MM6X17540.p7-(FP92)" of pcieuart9098_combo_v1.bin which are all from that branch of those two repositories. Bootup failure indications are (edited down part of Linux bootup): [ 17.023637] Request firmware: nxp/pcieuart9098_combo_v1.bin [ 17.058326] WLAN FW is active [ 17.075178] woal_request_fw failed [ 17.078616] Firmware Init Failed [ 17.112302] Free module params [ 17.127100] woal_pcie_probe: failed [ 127.513518] IOCTL failed: 00000000ccd62525 id=0x200000, sub_id=0x200011 action=1, status_code=0x3 [FW_CMDRESP] [ 207.385673] IOCTL failed: 00000000dcc6ae8c id=0x20000, sub_id=0x2000c action=1, status_code=0x1 [FW_NOT_READY] But it DOES work if set "uap_max_sta=48" and "max_sta_conn=48" instead of 64 in wifi_mod_para.conf .  I basically did a binary search to find a working value. Stranger still, if I replace the /lib/firmware/nxp/ contents which contained lf-6.12.34_2.1.0 with that of the original lf-6.12.20_2.0.0 files but KEEP the newer lf-6.12.34_2.1.0 drivers, everything seems to work fine with the old "uap_max_sta=64" and "max_sta_conn=64" settings. That is, the newer drivers seem to work fine, but only with the older firmware when using the higher settings. mlan/mlan_ioctl.h in branch lf-6.12.34_2.1.0 still has "#define MAX_STA_COUNT 64". So is this no longer correct? Either the newer firmware should reject settings it cannot support, or the firmware should be updated to support it again.

88W9098 lf-6.12.34_2.1.0uap_max_sta=64 でのファームウェア障害 私たちは、TI TMDS64EVM 評価ボード上の uBlox JODY-W377-00B モジュールで使用される NXP 88W9098 チップセットを、主に Linux 経由のアクセス ポイントとして使用するために評価しています。 具体的には、コネクティビティをサポートするために、wifi_mod_para.conf で uap_max_sta=64 と max_sta_conn=64 を設定しています。これはもう機能していないようです。 mwifiexおよびimx-firmwareファームウェアリポジトリのlf-6.12.20_2.0.0ブランチ（2025年5月27日）（「PCIE9098--17.92.1.p149.70-MM6X17537.p9-GPL-(FP92)」として識別）を使用しても正常に動作しました。 最近lf-6.12.34_2.1.0にアップデートしました上記両方のリポジトリの uap_max_sta=64 および max_sta_conn=64 の上記設定では、WiFi が機能しなくなりました (ファームウェアの初期化失敗)。これは、mlan.ko と moal.ko のバージョン 540.p7 と、pcieuart9098_combo_v1.bin のバージョン「PCIE9098--17.92.1.p149.76-MM6X17540.p7-(FP92)」を使用しています。これらはすべて、これら 2 つのリポジトリのブランチからのものです。 起動失敗の表示は次のとおりです (Linux 起動の一部を編集)。 [ 17.023637] ファームウェアのリクエスト: nxp/pcieuart9098_combo_v1.bin [ 17.058326] WLAN FWがアクティブです [ 17.075178] woal_request_fw が失敗しました [ 17.078616] ファームウェアの初期化に失敗しました [ 17.112302] フリーモジュールパラメータ [ 17.127100] woal_pcie_probe: 失敗 [ 127.513518] IOCTL失敗: 00000000ccd62525 id=0x200000、sub_id=0x200011 action=1、status_code=0x3 [FW_CMDRESP] [ 207.385673] IOCTL失敗: 00000000dcc6ae8c id=0x20000、sub_id=0x2000c action=1、status_code=0x1 [FW_NOT_READY] ただし、 wifi_mod_para.conf で 64 ではなく「uap_max_sta=48」および「max_sta_conn=48」を設定すると動作します。基本的に、有効な値を見つけるためにバイナリ検索を実行しました。 さらに奇妙なことに、lf-6.12.34_2.1.0 を含む /lib/firmware/nxp/ の内容を置き換えると、元のlf-6.12.20_2.0.0ファイルと同等ですが、新しいlf-6.12.34_2.1.0は保持します。ドライバは、古い「uap_max_sta=64」と「max_sta_conn=64」の設定でも、新しいlf-6.12.34_2.1.0でもすべて正常に動作するようです。ドライバ。 つまり、新しいドライバは正常に動作するように見えますが、より高い設定を使用する場合、古いファームウェアでのみ動作します。 ブランチ lf-6.12.34_2.1.0 の mlan/mlan_ioctl.hまだ「 #define MAX_STA_COUNT 64 」があります。SO、これはもう正しくないのでしょうか?新しいファームウェアではサポートできない設定を拒否するか、再度サポートできるようにファームウェアを更新する必要があります。

S32G399A CMSIS device pack location Hello, I'm trying to establish a SWD or JTAG debug interface for the S32G399A. Using an MCU-Link with PyOCD tooling requires a CMSIS device pack for the S32G, which is not included natively. Where can I locate the S32G CMSIS device pack online or locally? I have no issue finding such packs for other MCUs on the Arm Keil website, and the PyOCD pack installation process is also straightforward. I installed the S32G development package in S32 DS, but can't find a .pack zip file on my local installation path.  Thanks GoldVIP Re: S32G399A CMSIS device pack location hi，faraday78 Thank you for contacting us. Regarding the official debugging methods supported by S32G: through S32 Debug Probe or Lauterbach, combined with S32DS. BR Joey

NXP MPC5748 FreeRTOS demo we are testing FreeRTOS on the NXP MPC5748G by running the ready made demo provided by S32 design Studio it works fine when we Build and run the project but when we try to build and run the project as a standalone project the project main functionality does not run as intended after some trace we found that the problem is most likely to be in vtaskdelay() is not working so please can anyone suggest a solution Re: NXP MPC5748 FreeRTOS demo Hello, It sounds like your FreeRTOS tick isn’t running in the “standalone” build, so vTaskDelay() never wakes tasks. On the MPC5748G (PowerPC e200z4), that typically boils down to one of these in the move from “Run in IDE” → “Run from flash/standalone”: Clock source isn’t actually configured (PLL not locked, bus clock different). The tick timer isn’t initialized or its interrupt isn’t firing (STM/PIT/RTI). Global interrupts aren’t enabled (MSR.EE = 0). The interrupt vector table (IVPR) isn’t placed or the INTC isn’t set up in standalone. Interrupt priorities conflict with FreeRTOS’s configMAX_SYSCALL_INTERRUPT_PRIORITY. Linker/startup differences (missing startup code or wrong section placement). Watchdog resetting before you notice. Best regards, Peter

88W9098 lf-6.12.34_2.1.0 firmware failure with uap_max_sta=64 We are evaluating the NXP 88W9098 chipset, as used in a uBlox JODY-W377-00B module on a TI TMDS64EVM evaluation board, mostly for use an an access point via Linux. Specifically, we have been setting uap_max_sta=64 and max_sta_conn=64 in wifi_mod_para.conf to support high connectivity. This no longer seems to work. It worked fine using the lf-6.12.20_2.0.0 branch (May 27, 2025) of the mwifiex and imx-firmware firmware repositories (which identifies as "PCIE9098--17.92.1.p149.70-MM6X17537.p9-GPL-(FP92)") Recently I updated to the lf-6.12.34_2.1.0 branch (Aug 27, 2025) of both of the above repositories, and WiFi no longer works (firmware init failure) with the above settings of uap_max_sta=64 and max_sta_conn=64. This is using version 540.p7 of mlan.ko and moal.ko and version "PCIE9098--17.92.1.p149.76-MM6X17540.p7-(FP92)" of pcieuart9098_combo_v1.bin which are all from that branch of those two repositories. Bootup failure indications are (edited down part of Linux bootup): [ 17.023637] Request firmware: nxp/pcieuart9098_combo_v1.bin [ 17.058326] WLAN FW is active [ 17.075178] woal_request_fw failed [ 17.078616] Firmware Init Failed [ 17.112302] Free module params [ 17.127100] woal_pcie_probe: failed [ 127.513518] IOCTL failed: 00000000ccd62525 id=0x200000, sub_id=0x200011 action=1, status_code=0x3 [FW_CMDRESP] [ 207.385673] IOCTL failed: 00000000dcc6ae8c id=0x20000, sub_id=0x2000c action=1, status_code=0x1 [FW_NOT_READY] But it DOES work if set "uap_max_sta=48" and "max_sta_conn=48" instead of 64 in wifi_mod_para.conf . I basically did a binary search to find a working value. Stranger still, if I replace the /lib/firmware/nxp/ contents which contained lf-6.12.34_2.1.0 with that of the original lf-6.12.20_2.0.0 files but KEEP the newer lf-6.12.34_2.1.0 drivers, everything seems to work fine with the old "uap_max_sta=64" and "max_sta_conn=64" settings, even with the new lf-6.12.34_2.1.0 drivers. That is, the newer drivers seem to work fine, but only with the older firmware when using the higher settings. mlan/mlan_ioctl.h in branch lf-6.12.34_2.1.0 still has "#define MAX_STA_COUNT 64". So is this no longer correct? Either the newer firmware should reject settings it cannot support, or the firmware should be updated to support it again.

LPDDR4X 与 I.MX93 的 MID 你好 我可以在 I.MX93 芯片组上找到推荐的内存部件和供应商。 但我想咨询一下，如果使用不在推荐列表中的 LPDDR4X 内存，是否会有问题。例如其他供应商海力士、ISSI、APmemory、Fidliex 等。 我正在考虑为一个项目准备 I.MX93 FRDM 板，各种内存将在该环境中进行测试。 是在 MR5 上使用这些 MID 的板不在恩智浦的清单上吗？ Re: MID of LPDDR4X with I.MX93 感谢您的回答~ Re: MID of LPDDR4X with I.MX93 你好@Simon_JUNG 是的，没问题。只要这种动态随机存取存储器(DRAM)符合 JDEC 规范。可以与 imx93 一起使用。 b.r

HEF4052 日付コード確認 HEF4052、TKXの日付コードの確認にご協力ください。

How to push stream to display in iMX95 verdin evk kit I am trying to bring a Bayer RGGB sensor in iMX95 Verdin EVK and could get v4l2 stream using the stream-mmap command.  I have also captured and checked from video0.  How to push the stream to the display, what gstreamer command should be used to do it. Can you please provide your inputs on this. Thanks Re: How to push stream to display in iMX95 verdin evk kit pls refer to the chapter 7.3.9.6.1 GStreamer pipeline single camera preview of user guide as below https://www.nxp.com/docs/en/user-guide/UG10163.pdf

EB 许可证超过允许的最大数量 我目前正在开发 BMA7118，我想使用恩智浦的演示版。恩智浦的演示版是基于 EB 的，但恩智浦发给我的 EB 许可证超过了允许的最大数量，我该如何解决这个问题？ Re: EB lisence exceeds maximum quantity allowed 你好 管理员似乎只更新了带有新许可证代码的第 30 版。 嗯，我表示所有版本都需要更新。 不过，所有版本都是一个代码，所以请检查版本 30 并使用该代码： 顺祝商祺！ Peter Re: EB lisence exceeds maximum quantity allowed 我在我的 nxp 账户中没有找到新代码，你能把新代码发到我的邮箱吗？或者请给我一张截图，告诉我如何找到新的激活代码。谢谢。 Re: EB lisence exceeds maximum quantity allowed 你好 恩智浦 SW 账户上已经有了新代码。 顺祝商祺！ Peter