Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
S32K322カスタムボード:デバッガが接続できず、RESET_bが低いままです こんにちは 、 私はS32K 322 MCUを使っていて、そのボードは開発前のブランクチップで、量産ボードではありません。HSM関連の設定は一切変更しておらず、S32DSバージョン3.6.10を使用しています。Flash Debugでデバッグしていると上記のメッセージが表示され、デバッグがうまくいかないので、質問したいです。 ご協力ありがとうございました。 こちらはリーです Re: S32K322 custom board: debugger cannot connect, RESET_b stays low こんにちは、 セキュアデバッグメッセージは、根本原因ではなく、結果である可能性があります。これはカスタムボードであり、RESET_bがローのままであるため、まずは電源、リセット回路、またはRESET_bをアサート状態に保持している外部デバイスなど、ハードウェア関連の問題を調査します。リセット中のデバイスはデバッガでアクセスできず、Secure Debugが有効でなくてもこのメッセージが発生することがあります。   BR、ペトル Re: S32K322 custom board: debugger cannot connect, RESET_b stays low さらに、Multilink Universal FX Port G Mini 10ピンJTAGを使用しています。
View full article
Migrating v8.3.10 LVGL based project to v9.2.1 The following document describes the migration process of a GUI Guider project based on the older LVGL library 8.3.10, to the newer LVGL library 9.2.1 that is supported on GUI Guider v1.9.0+. We will take the CoffeePourAnimation example project as a basis to illustrate this process. For demonstrative purposes, we will create the project on GUI Guider 1.8.0, which was the last GUI Guider version that only supported LVGL 8.3.10, and migrate it to GUI Guider 1.10.0, currently the latest version of GUI Guider, that supports LVGL 9.2.1. In this case, we will use a MIMXRT1060-EVKC with a RK043FN66HS-CTG display. With the project created, the very first thing we have to make sure to do is generate the GUI C code using the ‘Generate Code’ button: Note that the project created will be based on the SDK version 2.16.000: This SDK version is what contains the LVGL libraries, which are v8.3.10. If we want to upgrade the LVGL libraries to the latest v9.2.1, we need to update the SDK as well. But simply importing the project to a newer GUI Guider version will not update the SDK. This will just update the project file, without changing any of the underlying software package. In order to make sure both the SDK and the LVGL libraries get updated, we will use MCUXpresso IDE. Here, we can create a new base project that uses the SDK version 25.06.00 and replace only the GUI with the one of the older projects. This will ensure we have a v9.2.1 LVGL based project, with the GUI from the previous project. Why use specifically v25.06.00 of the SDK? Because this is the version of SDK that the latest GUI Guider (v1.10.0) uses to create projects based on LVGL v9.2.1. In order to do this, first import the LVGL example for the board we are using (in this case, the MIMXRT1060-EVKC). This new project will be used to ensure the newest LVGL library is in place: Make sure to import the example project named: "lvgl_guider". The resulting project will be created, along with the following folders and files. The actual GUI, is stored on the “custom” and “generated” folders, so these are the folders that have to be replaced to bring the old GUI on the new project: In order to replace them, navigate to both the original GUI Guider project folder, as well as the MCUXpresso lvgl_guider example project folder. Delete the ‘custom’ and ‘generated’ folders from the lvgl_guider example, and drag-and-drop these same folders from the GUI Guider project into the MCUXpresso example project: After doing this, the new ‘generated’ and ‘custom’ folders will not be detected as source folders for the project, since they were copied from an external project. In order to add them as source folders, navigate to Project Properties > C/C++ General > Paths and Symbols, click on ‘Add Folder…’ and select both ‘custom’ and ‘generated’ folders before clicking OK: After following either of these two processes, the old GUI Guider project will have been updated to the new SDK, which also has the new LVGL 9.2.1 libraries. That said, due to major changes on the APIs of LVGL v8 and v9, building the project will most likely result in compilation errors. Most changes of the LVGL libraries are addressed on the official LVGL documentation, specifically the following migration guide from v8 to v9: Changelog — LVGL documentation The following section will describe the process to address the specific changes from the CoffeePourAnimation example project from LVGL v8.3.10 to v9.2.1. Adjusting for 9.2.1 LVGL library changes: First of all, if after compiling the project, the following error shows up: fatal error: gui_guider.h: No such file or directory It means that the code generated by GUI Guider was not done correctly. If that is the case, one must repeat the whole process described earlier, making sure to click on the “Generate Code” in C, as mentioned previously. Specifically for this example  CoffeePourAnimation GUI, we get an error stating: fatal error: extra/widgets/animimg/lv_animimg.h: No such file or directory This is because the path to the “lv_animimg.h” header file was changed on LVGL v9. In fact, that LVGL file was also renamed to “lv_animimage.h”. Therefore, we have to change the following line in “gui_guider.h”. From: #include "extra/widgets/animimg/lv_animimg.h" To: #include "src/widgets/animimage/lv_animimage.h" The next error that shows up is one that is present for all of the image files: fatal error: lvgl/lvgl.h: No such file or directory This is because previously, on LVGL v8, the include path was set to the parent directory of the “lvgl.h” file (meaning that the inclusion of this header file had to be “lvgl/lvgl.h”). This is no longer the case, so we can define the following macro in order to fix the inclusion issue and simplify it to: #include “lvgl.h”. The macro to be defined is LV_LVGL_H_INCLUDE_SIMPLE. In project properties, under C/C++ Build > Settings > Tool Settings > MCU C Compiler> Preprocessor, click on the “Add…” button, and add that macro: After completing this, the next errors that are shown after a compilation are all related to the images of the GUI. There were several format changes on the image headers from LVGL v8 to v9. This means that the “.c” array files that were generated on GUI Guider will no longer be compatible with the new LVGL libraries. Because of this, the images have to be re-converted for LVGL v9.2.1. This can be achieved by using the official LVGL image converter tool, either online here: Image Converter — LVGL, or via a python script found here: lvgl/scripts/LVGLImage.py at master · lvgl/lvgl · GitHub. All of the images used on the GUI should be located under the “import” folder of the main project’s folder location. Once all of the images from the project have been converted to the LVGL v9 format, simply replace the .c array files located under the project folder > generated > images, with the newly generated ones: Although several changes were made to the API of the LVGL library between v8.x and v9.x, LVGL comes with an API map file, that maps new API functions to older ones for retroactive compatibility. As stated on the aforementioned Changelog — LVGL documentation, for example, “lv_disp_... is renamed to lv_display_...”, and the “lv_api_map_v8.h” file addresses this change, so that the old v8 function calls that our GUI uses, will still work on the new v9 LVGL: That said, there might be some exceptions that fly under the radar. In the specific case that we are looking at, it happens on the following line under the “events_init.c” file: lv_animimg_del(guider_ui.coffeePour_animimg_coffee); In this case, the API map file does not currently contain an alias for the new function call of LVGL v9, therefore we have to adjust it manually. This might happen on other functions for specific GUIs being imported. Thankfully MCUXpresso does provide suggestions that might point to the right function to replace them with: Also, the next change is necessary on the “events_init.c” file, which instead of doing a direct call to “animimg1->dsc”, we do it through the following call. From: const void **coffee_imgs = animimg1->dsc; To: const void **coffee_imgs = lv_animimg_get_src(guider_ui.coffeePour_animimg_coffee); Finally, the lv_line_set_points() was changed from using the following arguments on v8: void lv_line_set_points(lv_obj_t *obj, const lv_point_t points[], uint16_t point_num) To these arguments on v9: void lv_line_set_points(lv_obj_t *obj, const lv_point_precise_t points[], uint32_t point_num)​ Therefore, the following change has to be made on “setup_scr_coffeePour.c”. From: static lv_point_t coffeePour_line_right[] = {{0, 0},{0, 180},{0, 90},{120, 90},}; static lv_point_t coffeePour_line_left[] = {{120, 0},{120, 180},{120, 90},{0, 90},}; To: static lv_point_precise_t coffeePour_line_right[] = {{0, 0},{0, 180},{0, 90},{120, 90},}; static lv_point_precise_t coffeePour_line_left[] = {{120, 0},{120, 180},{120, 90},{0, 90},}; With these changes, the CoffePourAnimation GUI Guider project has been migrated from using LVGL v8.3.10 to v9.2.1. Happy migrating!
View full article
FRDM i.MX 95 Pro Hands-On: Unboxing and first steps   Introduction This hands-on walks you through everything that happens before you ever write a line of application code: unboxing your FRDM i.MX 95 Pro board, getting acquainted with its layout and ports, powering it on, and confirming a healthy first boot from the on-board eMMC. By the time you are done, you will be comfortable using both the i.MX System Manager console and the Linux command line to confirm exactly what hardware you have in front of you. By the end you will be able to: Verify that the contents of your FRDM i.MX 95 Pro box are complete Get acquainted with the board, its peripherals, and ports Set up and boot the board for the first time Get familiar with the i.MX System Manager (SM) console and the Linux CLI Verify the board's hardware and resources using Linux commands Hardware & Prerequisites You need very little to get started: FRDM-IMX95-PRO board (the box) — in addition to the board itself, the box includes USB-C cables for power and debugging, mounting standoffs, the IW612 wireless module, and a documentation card linking to the product page and a getting-started tutorial. Power supply — a USB-C to USB-C cable is included in the box. For basic bring-up, any standard USB-C phone charger is sufficient. If your setup adds higher-power accessories (e.g., a display), use a 100 W-capable USB-C power adapter instead. PC host — a computer with a terminal / serial console program to connect to the board's debug port. That's it — no display or camera is required for this hands-on. Watch the Module Video Watch the full hands-on walkthrough below, then follow along on your own board. (function() { var wrapper = document.getElementById('lia-vid-6406134452112w960h540r408'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos)   Steps to Run the Hands-On Step 1: Explore the Board with Linux Commands Once the board has booted, open a terminal on the debug console and run the following commands to confirm the Linux environment and the hardware resources available to you. # 1) Linux version uname -a # 2) Storage devices lsblk # 3) Verify CPU numbers and architecture. lscpu # 4) SoC Id and Family cat /sys/devices/soc0/soc_id cat /sys/devices/soc0/family # 5) RAM memory available cat /proc/meminfo | head -20 # 6) network peripherals and addresses ip addr # 7) List Video Encoders and Decoders v4l2-ctl --list-devices # 😎 GPU specs and capabilities vulkaninfo --summary # 9) Print available GPIOs gpioinfo Step 2: Explore the i.MX System Manager Console Next, switch to the i.MX System Manager (SM) console to inspect the board at the system level — Logical Machines, boot times, power rails, and clocks. # 1) System manager version, Board, Revision, Silicon etc info # 2) Logical Machines information lm info # 3) Boot time of each Logical machine btime # 4) Power status of each peripheral power.r # 5) Clocks status clock.r Troubleshooting Symptom What to check Power LED is on but there is no output on the console Check the Boot Mode switches (set them to eMMC) Power-cycle the board (turn it off and back on) after changing the Boot Mode switches Verify the serial console baud rate is set to 115200 Confirm the Debug port is connected to the host PC Open all the COM ports exposed by the board when the Debug port is connected to the host PC Conclusion In this hands-on, you: Verified the contents of your FRDM i.MX 95 Pro box Got acquainted with the board, its peripherals, and ports Set up and booted the board for the first time from eMMC Used the i.MX System Manager console and the Linux CLI to inspect the board Confirmed the board's hardware and resources via Linux commands If you have not already, watch the module video above for the full walkthrough, and check out the rest of the FRDM Training Hub for the next hands-on in the series. FRDM-IMX9 FRDM-Training Hands-On Training i.MX Application Processors
View full article
FRDM i.MX 95 Pro Hands-On: Flashing SD Card, BSP & Waveshare 7 DSI Display Introduction This hands-on walks you through bringing a display to life on the FRDM-IMX95-PRO board. You will flash a BSP image to an SD card, attach a Waveshare 7" DSI LCD, select the correct device tree in U-Boot, and then exercise the panel with brightness control, screen rotation, capacitive touch, and a live camera video pipeline. By the end you will have a fully working touch display and the core skills to configure DSI panels on i.MX 95. By the end of this hands-on you will be able to: Flash a BSP image to a microSD card using UUU in Serial Download mode. Connect the Waveshare 7" DSI display (FPC, power, and I2C) correctly. Select the matching device tree for the panel from the U-Boot prompt. Adjust and script the display backlight brightness. Rotate the screen through Weston's configuration. Verify capacitive touch with evtest . Stream live camera video to the panel with GStreamer. Hardware & Prerequisites FRDM-IMX95-PRO board. MicroSD card — 16 GB or larger. Waveshare 7" DSI LCD — 1024×600 IPS, 5-point capacitive touch. 22-pin FPC cable. Host PC with UUU installed. Watch the Module Video Watch the full hands-on walkthrough first to see each step performed on real hardware, then follow along on your own board using the steps below. This video is currently being processed. Please try again in a few minutes. (view in My Videos) Steps to Run the Hands-On 1. Enter Serial Download Mode Put the board into Serial Download Protocol (SDP) mode so the host can push the image, then connect it to your PC: Set boot switch SW1 = 1000 (Serial Download Protocol mode). Connect J7 USB-C to the host PC. Connect J22 USB-C to view debug output on the serial console. 2. Flash the BSP Image with UUU Run the following command on your host computer to flash the BSP boot image and full image to the SD card: # --- UUU --- # Run the following command on your host computer uuu.exe –b sd_all imx-boot-imx95-19x19-lpddr5-frdm-pro-sd.bin-flash_a55 imx-image-full-imx95evk.wic.zst 3. Switch to SD Boot Once flashing completes, reconfigure the board to boot from the SD card: Power off the board. Set boot switches SW3 and SW4 = 0011 (SD card boot). Turn on the board. 4. Connect the Display — FPC Cable Attach the 22-pin FPC cable between the board and the Waveshare panel, paying close attention to cable orientation on each end: Connect the 22-pin FPC to the board's MIPI-DSI connector — the stiffener side faces the board connector. Connect the other end to the Waveshare panel (15-pin side) — the conductive side faces the panel. 5. Connect the Display — Power & I2C The panel needs both power and an I2C connection for the display output to come up: Connect I2C via the J6 4-pin header. Connect 5V power to J17 (or any 5V connector). I2C must be connected for display output to work. 6. Change the Device Tree in U-Boot Watch the serial console during boot and press any key at the U-Boot countdown to reach the prompt: Hit any key to stop autoboot: 3 => (U-Boot prompt) At the U-Boot prompt, select the device tree for the Waveshare panel and boot: # --- U-Boot: select the device tree for the display --- fatls mmc 1 setenv fdtfile imx95-19x19-frdm-pro-waveshare-7inch-c-panel.dtb saveenv boot 7. Set & Check Backlight Brightness Once Linux is running on the board, the panel backlight is exposed through sysfs. The commands below set a brightness value and read the current and maximum allowed values. Valid range is 0 (off) up to max_brightness . Run these as root: # --- Linux on board --- # Run the following command on the board # Path to the backlight /sys/class/backlight/3-0045/ # Set brightness echo 128 > /sys/class/backlight/3-0045/brightness # Read the current value cat /sys/class/backlight/3-0045/brightness # Read the maximum allowed value cat /sys/class/backlight/3-0045/max_brightness 8. Fun Example — Breathing Backlight For a quick visual test, this small script ramps the backlight up and down continuously, giving a "breathing" effect. Save it as breathe.sh , make it executable, and run it as root. Press Ctrl+C to stop. # --- Linux --- # Breathing back light # Create and open the file vi breathe.sh # Write the following lines into the bash script BL=/sys/class/backlight/3-0045 MAX=$(cat "$BL/max_brightness") while true; do for ((i=0; i<=MAX; i++)); do echo "$i" > "$BL/brightness"; sleep 0.01; done for ((i=MAX; i>=0; i--)); do echo "$i" > "$BL/brightness"; sleep 0.01; done done # Change the permissions of the bash script chmod +x breathe.sh # Run the bash script ./breathe.sh 9. Rotate the Screen (Weston) Display orientation is controlled in Weston's configuration file. Edit weston.ini , add an [output] section with the desired transform, then restart the service: # --- Linux --- # On board # File path /etc/xdg/weston/weston.ini # Open the file vi /etc/xdg/weston/weston.ini # Add the following [output] name=DPI-1 transform=rotate-90 # Valid formats # normal - 0 degrees (default) # rotate-90 - 90 degrees clockwise # rotate-180 - upside down # rotate-270 - 270 degrees clockwise # Reboot or restart the service systemctl restart Weston # Check the status of the service systemctl status weston You can confirm the panel resolution and active modes with modetest : # --- Linux --- # Check the panel resolution modetest -c # list connectors & modes # full DRM/KMS overview modetest # Look for the DSI/DPI connector and confirm # 1024x600 is listed as an active mode 10. Test Capacitive Touch (evtest) Run evtest with no arguments to list the available input devices, then select the touch screen's event number to start capturing touch events: # --- Linux --- # Touch screen evtest # Run the evtest command evtest # It will list the available devices Available devices: /dev/input/event0: scmi_dev.11 /dev/input/event1: Goodix Capacitive TouchScreen Select the device event number [0-1]: 1 # Then it will run the evtest of the touch screen 11. Display Camera Video (GStreamer) Stream live camera video to the panel to verify both the camera and the display path in one go: # --- Linux --- # Gstreamer pipe line for webcam # Run the following command gst-launch-1.0 v4l2src device=/dev/video52 ! video/x-raw,width=640,height=480 ! Glimagesink # Pipeline breakdown # v4l2src device=/dev/video52 - capture from V4L2 node # video/x-raw,width=640,height=480 - raw 640x480 video # glimagesink - render on display via OpenGL Troubleshooting Symptom What to check No display output Check FPC orientation — the stiffener side must face the board connector. Ensure the I2C bus (J6) is connected; it is required for display output. fatls mmc 1 fails Verify the SD card is inserted. Confirm SW3 and SW4 = 0011 (SD boot mode). "No such file or directory" at the backlight path Confirm the node name with ls /sys/class/backlight/ . Touch not working after screen rotation Add a calibration_matrix for the touch device in weston.ini , or configure the touch coordinate transform via libinput. Conclusion In this hands-on you brought up a Waveshare 7" DSI display on the FRDM-IMX95-PRO board from a fresh SD card flash all the way to a working touch panel with live camera video. Key takeaways: Flashed a BSP image to the SD card with UUU and switched the board to SD boot. Connected the DSI panel correctly (FPC orientation, 5V power, and the required I2C link). Selected the matching device tree in U-Boot so the panel enumerates at 1024×600. Controlled backlight brightness, rotated the display in Weston, validated touch with evtest , and verified the camera path with GStreamer. Be sure to watch the module video above to see each step in action, and explore the rest of the FRDM-IMX95-PRO Training Hub for more hands-on modules. FRDM-Training
View full article
FRDM i.MX 95 Pro Hands-On: GoPoint — Running Pre-Built Demos FRDM i.MX 95 Pro · Hands-On Series GoPoint — Running Pre-Built Demos September 2026  |  FRDM i.MX 95 Pro Hands-On Series   Introduction Discover what your FRDM i.MX 95 Pro can do — right out of the box. This hands-on walks you through the full range of pre-built demo categories available through GoPoint on the FRDM i.MX 95 Pro board. From neural processing and machine learning to GPU-accelerated graphics, each demo showcases the real-world capabilities of NXP's i.MX 95 application processor — no custom code required. The hands-on covers the following topics: Launching GoPoint on the Weston desktop Exploring the available demo categories (NPU, ML, GPU) Running NPU demos with the Ara240 module Running ML and GPU demos By the end of this hands-on, you will be able to: Navigate the GoPoint interface on Weston Identify the available demo categories (NPU, ML, and GPU) Launch and run pre-built demos on your FRDM i.MX 95 Pro board Understand the hardware requirements for each demo type   Hardware & Prerequisites Before starting, make sure you have the following items ready: Required Hardware FRDM-IMX95-PRO board (booted from eMMC) HDMI display Mouse Keyboard USB camera Ara240 module (required for NPU demos) Optional Hardware EXPI-OS08A20 camera module — covered in the separate EXPI-OS08A20 Camera + ISP Pipeline hands-on Note: The board must be booted from eMMC with the pre-loaded BSP image before launching GoPoint. Ensure your display is connected via HDMI before powering on.   Watch the Hands-On Video A complete video walkthrough accompanies this hands-on. It demonstrates every step shown below — from opening GoPoint on Weston to running NPU, ML, and GPU demos live on the board. Watch it alongside the written steps for the best learning experience. This video is currently being processed. Please try again in a few minutes. (view in My Videos)   Steps to Run the Hands-On Follow the steps below to explore GoPoint and run the pre-built demos on your board. Step 1 — Launch GoPoint on Weston After the board boots into the Weston desktop environment, locate the GoPoint application icon on the desktop or in the application launcher. Click it to open the GoPoint demo browser. GoPoint provides a graphical interface that organises all available demos by category, making it easy to browse and launch them without any command-line interaction. Step 2 — Explore the Demo Categories Once GoPoint is open, you will see the main demo category tiles. The three primary categories available on the FRDM i.MX 95 Pro are: NPU Demos — Neural Processing Unit demos that leverage the Ara240 module for hardware-accelerated AI inference ML Demos — Machine learning demos running on the i.MX 95 application processor GPU Demos — Graphics Processing Unit demos showcasing GPU-accelerated rendering and compute Browse each category to see the individual demos available. Each demo tile shows its name, a brief description, and any special hardware it requires. Step 3 — Run NPU Demos (Ara240 Required) NPU demos require the Ara240 module to be attached to the board. Select any NPU demo from the GoPoint interface and click Run. GoPoint will automatically load the required AI model and launch the demo. The Ara240 module handles the neural network inference, delivering real-time results on-screen. Note: If AI/ML models are not yet present on the board, run the fetch_models command first (see the Troubleshooting section below). Step 4 — Run ML Demos ML demos run directly on the i.MX 95 application processor and do not require the Ara240 module. Select an ML demo from the GoPoint interface and click Run. These demos cover a range of machine learning use cases including image classification, object detection, and more. Step 5 — Run GPU Demos GPU demos showcase the graphics and compute capabilities of the i.MX 95's integrated GPU. Select a GPU demo from the GoPoint interface and click Run. These demos include GPU-accelerated graphics rendering and visual effects that highlight the board's multimedia performance.   Troubleshooting If you encounter issues while running GoPoint demos, use the table below to identify the symptom and the recommended action. Symptom What to Check Missing AI/ML models — demo fails to start or reports missing model files Fetch the required models using the commands below. Use --list to see available models and --repo-id to fetch a specific one: # List available models fetch_models --list # Fetch a specific model by repository ID fetch_models --repo-id Cannot download software requirements — network or SSL errors during model download The board's system clock may be incorrect, causing certificate validation to fail. Set the correct date and time, then retry: # Set the system date (replace with current date/time) date -s "MM/DD/YYYY HH:MM:SS" Board freeze — the board becomes unresponsive during a demo Reboot the board: reboot Corrupt download — a demo crashes immediately or shows unexpected errors after model download Remove the Python virtual environment ( venv ) for the affected demo and re-run it so GoPoint recreates a clean environment. The venv directory is located inside the demo's working folder. # Remove the venv of the corresponding demo, then relaunch it from GoPoint   Conclusion In this hands-on you explored the GoPoint application on the FRDM i.MX 95 Pro board and ran pre-built demos across three hardware-accelerated categories: Launched and navigated the GoPoint interface on the Weston desktop Ran NPU demos using the Ara240 neural processing module Ran ML demos on the i.MX 95 application processor Ran GPU demos showcasing the board's graphics capabilities Learned how to fetch AI/ML models and resolve common setup issues For a full visual walkthrough, watch the video in the Watch the Hands-On Video section above. To continue your learning journey, visit the FRDM i.MX 95 Pro Training Hub for the complete series of hands-on modules covering camera pipelines, connectivity, security, and more. FRDM-Training Hands-On Training
View full article
Introduction DNPU Training Introduction DNPU Training   Explore the evolution of AI at the edge, from perception AI and generative AI to the emerging era of Agentic AI. This session introduces NXP’s discrete NPU strategy and examines how neural networks, transformer models, and AI agents enable intelligent decision-making for industrial, healthcare, and automation applications. Participants will gain an understanding of the technologies driving the next generation of intelligent edge systems.   (function() { var wrapper = document.getElementById('lia-vid-6405511518112w960h540r721'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos) ARA240 DNPU Hands-On Training
View full article
KW47ナレッジハブ KW47 ファミリでは、96 MHz Arm® Cortex®-M33コアをBluetooth LEサブシステムとカップリングしています。この無線サブシステムは独立しており、コアやメモリも専用で、メインCPUの負荷を軽減するので、プライマリ・アプリケーションの分が保持され。また、ファームウェア・アップデートによる将来のワイヤレス標準のサポートも可能です。EdgeLock® Secure Enclave Core Profileを統合した高度なセキュリティのKW47は、NXPのEdgeLock 2GOクラウド・サービスによるサポートで認証情報の共有にも対応します。 KW47ファミリにはBluetoothのチャネル・サウンディング機能が搭載されており、オンチップの専用Localization Compute Engineで測距遅延を短縮します。アプリケーション固有のコード、コネクティビティ・スタック、OTA(Over-The-Air)ファームウェア・アップデートをサポートするための追加メモリも搭載されています。これにより、無線のリアルタイム動作がアプリケーションとは別のコアで実行されるため、信頼性の高いワイヤレス性能が得られます。 オートモーティブ・ソリューションを提供してきたNXPの豊富な経験に基づくKW47ファミリは、-40°C~125°Cの幅広い動作温度範囲と、車載アプリケーション向けペリフェラルを備えるほか、KW47は、長期使用をサポートするNXPの15年間の長期製品供給プログラムの対象ともなっています。 KW47シリーズは、MCUXpresso開発者エクスペリエンスによってサポートされ、組込みシステム開発の最適化、簡素化、迅速化に役立ちます。 KW47は製造開始前ですが、開発者はピンやソフトウェアの互換性があるKW45なら今すぐ使用を開始できます。       早期アクセスプログラム KW47早期アクセスプログラムはこちらKW47 Early Accessから参加できます。 アクセスのリクエストはNXPセールスチームまでご連絡ください。   チャネル・サウンディング チャネル・サウンディングご紹介プレゼンテーション CCC CS消費電力計算ツールあり(Excelファイル添付)   Bluetooth仕様 Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview Bluetooth_5.2_機能_概要 Bluetooth_5.3_機能_概要 Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview   トレーニング Bluetooth Low Energy 6.0 NXPご紹介 RFスイッチの比較 吸収型と反射型 規格の比較 ETSI/FCC/ARIB要件 BLEチャネルサウンディング - 概要 BLEチャネル・サウンディング - RFハードウェア BLEチャネル・サウンディング - ANSYSモデリング・ツール BLEチャネル・サウンディング - アンテナのプロトタイプの検証測定 機器 ワイヤレス機器:この記事には、プロジェクト策定に役立つ機器へのリンクが掲載されています。 便利なリンク リファレンスデザイン - NXP Community KW45/KW47/MCXW71/MCXW72でのSignal Frequency Analyzer(SFA)モジュールを使用したクロック測定 - NXPコミュニティ:このコミュニティでは、Signal Frequency Analyzerの使用方法に関する手順を提示しています。 [MCUXSDK]KW4x、MCXW7x、MCXW2xにGitHub SDKを使用する方法 - NXPコミュニティ GitHub SDKの使用方法をステップ別に紹介しています。 [MCUXSDK]GitHub SDK - Bluetooth LEプラットフォームのドキュメント - NXPコミュニティ BLEプラットフォーム用ドキュメントを提供しています。  KW47(オートモーティブ)またはMCXW712(IIoT)を使用してPCBを初めて正しく構築するための最適な方法 - コミュニティ:このコミュニティには、KW45またはK32W148/MCXW71を使用してPCBを構築するための重要なリンクと、無線性能、低電力、無線認証(CE/FCC/ICC)に関するあらゆる情報があります。 HCI_bbをKinetisファミリ製品で使用してDTMモードにアクセスする方法:この記事は次の2つの部分に分かれています。 HCI_bbバイナリを Kinetis製品へフラッシュする方法。 R&S CMW270を使用してRF測定を行う BLE HCIアプリケーションによるトランスミッタ/レシーバテストコマンドの設定:この記事では、ユーザーはどのようにすればシリアルコマンドをデバイスに送信できるかを示す手順を説明します。 Bluetooth LE HCI Black Boxクイックスタートガイド:この記事では、ユーザーが無線をシリアルコマンドで制御できるようにするためのシンプルなプロセスを説明します。 Kinetis(K32/38/KW45およびK32W1/MCXW71)パワー・プロファイル・ツール:Kinetis(KW35/KW38/KW45)およびMCX W7x(MCX W71)パワー・プロファイル・ツールに的を絞ったページです。お使いのアプリケーション(自動車またはIoT)での電力消費量を試算したり、ソリューションのバッテリ寿命を評価したりするのに役立ちます。  
View full article
KW47 知识中心 KW47 系列具备 96 MHz Arm® Cortex®-M33 内核,并搭载蓝牙低功耗(LE)子系统。独立的无线子系统具有专用核心和存储器,可减轻主CPU的负载,将其留给主要应用,并允许固件更新以支持未来的无线标准。KW47 还通过集成的 EdgeLock® 安全飞地核心配置文件提供高级安全性,并将由 NXP 的 EdgeLock 2GO 云服务支持凭证共享。 KW47 系列具备蓝牙信道探测功能,以及专用的片上定位计算引擎,可降低测距延迟。它集成了额外的内存,可支持特定应用代码、连接协议栈和无线固件更新。这意味着无线电子系统的实时活动在能够与应用程序不同的核心上运行,实现可靠的无线性能。 基于 NXP 在汽车解决方案领域的深厚历史,KW47 系列提供从 -40 °C 到 125 °C 的宽操作温度范围以及用于汽车应用的外围设备。KW47 将成为 NXP 15 年产品寿命计划的一部分,以支持长期使用。 KW47 系列配备 MCUXpresso Developer Experience 支持,可优化、简化和加速嵌入式系统的开发工作。 KW47 处于试生产阶段,开发人员可以立即开始使用与其引脚和软件兼容的 KW45。       早期访问计划 立即加入KW47早期访问计划:KW47 Early Access 您可以通过联系 NXP 销售团队来申请访问权限。   信道探测 信道探测简介 演示文稿 CCC CS 功率估算工具可用(附有 Excel 文件)   蓝牙规范 蓝牙 5.0 功能概述 蓝牙 5.1 功能概述 蓝牙 5.2 功能概述 Bluetooth_5.3_功能概述 Bluetooth_5.4_功能概述 Bluetooth_6_Feature_Overview   培训 蓝牙低能耗 6.0 NXP 简介 射频开关比较 吸收型/反射型 ETSI / FCC / ARIB 标准比较与要求 BLE 信道探测  - 概述 BLE 信道探测 - RF 硬件 BLE 信道探测 - ANSYS 建模工具 BLE 信道探测 - 天线原型验证测量 设备 无线设备: 本文提供了有助于项目开发的设备链接  有用链接 参考设计 - NXP 社区 使用 KW45/KW47/MCXW71/MCXW72 的信号频率分析仪 (SFA) 模块进行时钟测量 - NXP 社区:该社区提供了如何使用信号频率分析仪的步骤 [MCUXSDK] 如何使用 GitHub SDK 适用于 KW4x、MCXW7x、MCXW2x - NXP 社区此社区帖子逐步介绍了如何使用 GitHub SDK [MCUXSDK] GitHub SDK - 蓝牙 LE 平台文档 - NXP 社区此社区帖子提供了 BLE 平台的文档。  首次正确构建 PCB 的最佳方法,使用 KW47(汽车)或 MCXW712(IIoT)…… 社区:在此社区中,提供了使用 KW45 或 K32W148 和 MCXW71 构建 PCB 的重要链接,以及所有关于无线性能、低功耗和无线认证(CE/FCC/ICC)的内容。 如何在 Kinetis 系列产品上使用 HCI_bb 并进入 DTM 模式:本文分为两部分: 如何将HCI_bb二进制文件烧录到Kinetis产品中。 使用 R&S CMW270 进行射频测量 BLE HCI 应用程序用于设置发射机/接收机测试命令:本文提供了步骤,展示用户如何向设备发送串行命令 。Bluetooth LE HCI Black Box Quick Start Guide:本文介绍了一个简单的过程,用户可以通过串行命令控制无线电。 Kinetis (K32/38/KW45 & K32W1/MCXW71)功率配置工具: 此页面专门介绍 Kinetis (KW35/KW38/KW45) 和 MCX W7x (MCX W71) 功率配置工具。它将帮助您估算您的应用程序(汽车或物联网)的功耗,并评估您解决方案的电池寿命。  
View full article
KW47 Knowledge Hub KW47 family features a 96 MHz Arm® Cortex®-M33 core coupled with a Bluetooth LE subsystem. The independent radio subsystem, with a dedicated core and memory, offloads the main CPU, preserving it for the primary application and allowing firmware updates to support future wireless standards. The KW47 also offers advanced security with an integrated EdgeLock® Secure Enclave Core Profile and will be supported by NXP's EdgeLock 2GO cloud services for credential sharing. The KW47 family includes Bluetooth Channel Sounding capabilities, with a dedicated on-chip Localization Compute Engine to reduce ranging latency. It incorporates additional memory to support application-specific code, connectivity stacks and over-the-air firmware updates. This delivers reliable wireless performance, as the real-time activities of the radio run on a separate core from the application. Building on NXP's strong history of providing automotive solutions, the KW47 family offers a wide operating temperature range from -40 °C to 125 °C and peripherals for automotive applications, KW47 will be part of NXP's 15-year Product Longevity program to support long-term use. The KW47 series is supported by the MCUXpresso Developer Experience to optimize, ease and help accelerate embedded system development.   KW47 boards KW47-EVK Getting Started with the KW47 EVK KW47-EVK Board User Manual KW47-M2 Board User Manual  KW47-EVK Quick Start Guide KW47-M2 Quick Start Guide   KW47-LOC Getting Started with the KW47-LOC KW47-LOC Board User Manual KW47-LOC Quick Start Guide KW47: Bluetooth Channel Sounding MCU with On-Chip Localization Compute Engine the KW47 Security Certifications  PSA Certified Level 2 SESIP Level 2 Security Target  SESIP Level 2 KW47/MCXW72 SESIP certificate and ST are on TrustCB website  Regulatory Certifications European Union Declaration of Conformity - KW47-EVK MIC Radio Certificate - KW47-EVK European Union Declaration of Conformity - KW47-LOC MIC Radio Certificate - KW47-LOC  Bluetooth Qualifications Qualified Products | Bluetooth® Technology Website Q360996: KW47 / MCX W72 Bluetooth LE 6.0 (Channel Sounding) Controller Q332147: KW47 / MCX W72 Bluetooth LE 6.0 (Channel Sounding) Host Documents  KW47 Product Family Data Sheet KW47 Reference Manual Errata for KW47 KW47 Hardware Design Guide Bluetooth Interested in Bluetooth technology? Bluetooth® Low Energy Primer – Essential reading for understanding BLE fundamentals. Bluetooth® Specifications – Full list of standards, protocols, and technical documents. Awards and Recognition - Every year, the Bluetooth Special Interest Group (SIG) celebrates the hard work and commitment of working groups, committee members, and contributors who have been recognized by their peers as making a difference in advancing Bluetooth technology, like NXP! 2024: Channel Sounding 2025: Channel sounding amplitude-based attack resilience, LE test mode enhancements and Ranging profile and service.  Bluetooth AI Assistant - Amber   Bluetooth Feature Overview Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview Bluetooth_6.1_Feature_Overview Bluetooth_6.2_Feature_Overview Bluetooth_6.3_Feature_Overview Bluetooth Core Specification Core Specification 4.0 Core Specification 4.1 Bluetooth 4.1 FAQ Core Specification 4.2 Bluetooth 4.2 FAQ Core Specification 5.0 Core Specification 5.1 Core Specification 5.2 Core Specification 5.3 Core Specification 5.4 Core Specification 6.0 Core Specification 6.1 Core Specification 6.2 Core Specification 6.3 Application Notes Software, Hardware and Peripherals: AN14884 32kHz Cristal-less mode on KW47: This application note provides information on the 32 kHz Crystal-less mode on the KW47 device. This mode allows you to reduce the cost of the system, without compromising the 32 kHz clock accuracy.  AN14846 Boosting Application Performance with the KW47 Dual-Core Architecture: This application note describes how to use the dual-core architecture in the KW47 microcontroller to improve performance in generic embedded applications AN14796 Migration Guide from the KW45 to the KW47:  This document describes the procedure to migrate from KW45B41Z to KW47 with emphasis on the connectivity software. The document is intended for software engineers, software testers, software integrators, and customers designing their own hardware. Power Management: AN14709 Power Management Hardware for the KW47: This application note describes the usage of the different modules dedicated to power management in the KW47microcontroller. TheKW47integrates a DC-DC buck converter, a couple of low-dropout regulators, and a programmable solid-state switch to turn on/off theKW47power domains AN14684 Features, Usage, and Capabilities of Smart Power Switch on the KW47 Microcontroller: This application note describes the use of the smart power switch in the KW47 microcontroller. The KW47 integrates a programmable solid-state switch that turns connected components on or off, including KW47 power domains AN14664 Coincell Hardware Recommendations for Kinetis BLE Applications: his document describes some hardware and software solutions to minimize the peaks of current at the coin cell level AN14554 KW47 Bluetooth Low Energy Power Consumption Analysis:  This document provides the power consumption analysis of the Kinetis KW47 (automotive) wireless MCU using the KW47-EVK board RF: AN14719 Integrating the OTAP Client Service into a KW47 BLE Peripheral Device: This application note outlines the use of the NXP Over the Air Programming (OTAP) custom Bluetooth Low Energy (Bluetooth LE) service to upgrade software on a Microcontroller Unit (MCU) without using physical cables. AN14940 KW47 Coexistence with RF System Evaluation Report for the Bluetooth LE Applications: This document provides the coexistence RF evaluation test results of the KW47-EVK for Bluetooth LE applications (2FSK modulation). It includes the test setup description and the tools used to perform the tests on your own. For the KW47 radio parameters AN14461 KW47-EVK RF System Evaluation Report for Bluetooth LE Applications: This document provides the RF evaluation test results of the KW47-EVK board for Bluetooth LE (2FSK modulation) applications. It includes the test setup description and the tools used to perform the tests. AN14826 KW47-LOC System Evaluation Report for BLE Applications: This document provides the RF evaluation test results of the KW47 Localization board (KW47-LOC) for Bluetooth LE (2FSK modulation) applications. It includes the test setup description, and the tools used to perform the tests on your own. AN14696 Loadpull Test Report for KW47: This document explains the purpose of measuring the supply current, the transmit power, and the harmonics level. These measurements are monitored while the complex output load seen by the device under test (DUT) is tuned in amplitude and phase. AN14628 KW47 CCC Channel Sounding Power Profile Analysis:  this document explains power consumption measurement at each step of the full distance measurement procedure, changing of the code to set the different option in the SDK software, and usage of the associated power profile estimator tool. AN14865 Channel Sounding Fundamentals for the KW47 and MCX W72: This document provides an overview of the fundamentals for CS technology and how it can be used for custom solutions and applications. AN14832 Fundamental Steps to Design a Channel Sounding Board - Creating a Simple PCB without Diversity: In this document, an example of a minimalistic CS subsystem is presented. Attention is paid to the Radio-Frequency (RF) path, since RF circuitry strongly influences the properties of the whole CS application. AN14779 Printed Channel Sounding Antennas for the KW47 and MCX W72: his application note is focused on printed antennas implemented on printed-circuit boards (PCB), designed by NXP for the KW47 and MCX W72 controllers AN14720 Creation of Firmware Update Image for KW47 using Over the Air Programming Tool: This document outlines the steps to create and upgrade the image on the KW47–EVK board AN14868 RF Modeling of Channel Sounding in ANSYS: focuses on techniques for simulating and analyzing channel sounding in wireless communication systems using ANSYS tools AN14855 Channel Sounding Tests in Different Environments: This application note is about Bluetooth Channel Sounding (CS), a technique for measuring the distance between two devices in the Bluetooth frequency band. It explains key factors affecting accuracy AN14869 Fundamental Steps to Design a Complex Channel Sounding Board:  It focuses on creating hardware that supports advanced CS features, including antenna diversity and optimized RF paths, to improve accuracy and mitigate issues like multipath propagation. AN2731 Compact Planar Antennas for 2.4 GHz Communication: This document is not an exhaustive inquiry into antenna design. It is instead focused on helping the customers understand enough board layout and antenna basics to select a correct antenna type for their application, as well as avoiding typical layout mistakes that cause performance issues that lead to delays Security: AN14727 KW47 Flash Encryption using NPX: There is an increasing requirement to protect the application code and data stored in flash memories in an encrypted form due to security reasons. The NVM PRINCE XEX (NPX) is a module inside the Flash Memory Controller (FMC) that allows customers to protect the contents of flash regions (up to four regions). It performs on-the-fly, low-latency encryption and decryption of flash contents, and it is transparent to the developer and to the Cortex-M33 platform. No special handle is needed from the perspective of the developer. AN14607 KW47 Secure Boot using SEC tool: The KW47 is a low-power, highly secure, single-chip wireless MCU, the contents of flash memory can be saved as encrypted data, which can be decrypted instantly. It helps in protecting the sensitive data and algorithms. AN14647 KW47-LOC In-System Programming Utility: The document provides steps to boot the KW47 MCU in ISP mode and establish various serial connections to communicate with the MCU AN14653 Debug Authentication on KW47: This application note describes the steps for debug authentication using the MCUXpresso Secure Provisioning Tool (SEC). AN14649 KW47-EVK In-System Programming Utility: This document provides steps to boot the KW47 MCU into ISP mode and establish various serial connections to communicate with the MCU. AN14643 KW47 Managing Lifecycles: This document describes the following: Lifecycle stages that are available to the user, how to access the lifecycles, limitations of the lifecycles, how to transition to the next lifecycle AN15038 EdgeLock 2GO Provisioning MCUs via Product Type using Secure Provisioning (SEC) Tool:  This document offers an outline of the EdgeLock 2GO platform and discusses the "Device provisioning via product type" flow. The document focuses on the initial device provisioning using secure objects from the EdgeLock 2GO cloud server. Training Bluetooth Low energy 6.0 NXP Introduction KW4x: Automotive Bluetooth Low Energy MCUs for Secure Car Access RF Switch Comparison Absorptive/Reflective Standards Comparison ETSI / FCC / ARIB requirements BLE Channel Sounding  - Overview BLE Channel Sounding - RF Hardware BLE Channel Sounding - ANSYS Modeling Tools  BLE Channel Sounding - Antenna Prototypes Validation Measurements   Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development  Useful Links How to run KW47-M2 standalone - NXP Community How to generate a Standalone IAR toolchain project from MCUXSDK application example - KWX/MCWX  Debug probe firmware installation for the KW47-EVK and FRDM-MCXW72 This post will cover how to install the CMSIS-DAP/SEGGER J-link firmware for the KW47-EVK and FRDM-MCXW72 using NXP’s MCU-LINK installer. Updating NBU for Wireless Examples on KW47/MCXW72This post will cover how to update the NBU firmware How to import and run demo examples with MCUXpresso for Visual Studio Code: This article gives information on how to import and run demo examples from the new SDK with ARM GCC toolchain, in MCUXpresso for Visual Studio Code. [MCUXSDK] How to use GitHub SDK for KW4x, MCXW7x, MCXW2x - NXP Community this community post provides step by step how to use GitHub SDK [MCUXSDK] GitHub SDK - Documentation for Bluetooth LE platforms - NXP Community this community post provides the documentation for BLE platforms.  The best way to build a PCB first time right with KW47 (Automotive) or MCX W72 (IoT/Industrial) - NXP Community : In this community provides the important link to build a PCB using a KW47 and MCX W72 and all concerning the radio performances, low power and radio certification (CE/FCC/ICC). Workaround implementation for DCDC failure during drive strength change a DCDC failure can occur infrequently during a drive strength change to low, and the DCDC output voltage becomes greater than or equal to the current output voltage. How to use the HCI_bb on Kinetis family products and get access to the DTM mode:  This article is presenting two parts: How to flash the HCI_bb binary into the Kinetis product. Perform RF measurement using the R&S CMW270 BLE HCI Application to set transmitter/receiver test commands: This article provides the steps to show how user could send serial commands to the device. Bluetooth LE HCI Black Box Quick Start Guide : This article describes a simple process for enabling the user controls the radio through serial commands. Using HCI_VENDOR_CONFIG_TX_POWER on KW47 and MCXW72 Bluetooth LE Devices Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization):  This page is dedicated to the Kinetis (KW35/KW38/KW45/KW47/KW43) and MCX W7x (MCX W71/W72/W70) Power Profile Tools. It will help you to estimate the power consumption in your application (Automotive or IIoT) and evaluate the battery lifetime of your solution. One Wireless Connectivity Power Profile Tool KW47/MCXW72 32MHz & 32kHz Oscillation margins: this article provides the properly configuration for the Oscillation margins for the circuit. Changing CAN interface configuration on KW47-EVK while using serial terminal:Most available example applications use UART as the serial interface for terminal communication. This approach is commonly chosen because a terminal provides a simple and efficient method for interacting with the application during development and debugging. Errata ERR053377: Use Cases for Different Message Buffer ConfigurationsThis article discusses the different use cases and configuration of the errata "ERR053377: FlexCAN: Message Buffer (MB) and Enhanced RX FIFO Filter Element (ERFFEL) Memory Corruption" CAN-FD maximum baud rate on KW47 and MCXW72 This article describes the clock accuracy requirements and FlexCAN configuration needed to achieve the maximum supported CAN FD data rate of 6 Mbps on KW47 and MCXW72 devices. It explains how to use the FRO192 clock in closed-loop trim mode with a 32 MHz crystal reference and provides example code for clock and CAN FD configuration. Reference Designs Bluetooth Ranging Access Vehicle Enablement System - NXP Community Blue Ravens (Bluetooth Ranging Access Vehicle Enablement System) is a system solution developed by NXP to assist customers in designing their own BLE-based car access solutions using NXP products. Videos NXP Channel Sounding technology interfacing with Google Pixel 10 This is a demo showing the MCX W72 LOC board interacting with Google Pixel 10 phone using channel sounding KW47
View full article
Example S32K358 PWM ADC_HWtrig BCTU_TriggerMode RTD600 EBTresos29 ********************************************************************************* * Detailed Description: * * ADC hardware trigger demonstration using BCTU Trigger Mode on S32K358. * * An eMIOS1 Channel 23 reload event is used as a trigger source for the BCTU). * The BCTU initiates a hardware-triggered conversion of an ADC1 group containing * three channels. * * The result of the third ADC channel, connected to the on-board potentiometer * (ADCPOT0), is used to dynamically update the duty cycle of an * eMIOS Channel 5 PWM output. * * The PWM output drives the on-board LED, allowing the potentiometer position * to control LED brightness. * * Key Functionality: * - eMIOS-triggered BCTU operation. * - BCTU Trigger Mode configuration. * - ADC1 hardware-triggered group conversion. * - ADC notification callback processing. * - PWM duty-cycle update based on ADC result. * - LED brightness control using the potentiometer. * * ------------------------------------------------------------------------------ * Test HW: S32K3x8EVB-Q289 * MCU: S32K358 * IDE: EB Tresos 29.0.0 * RTD Release: S32K3_RTD_6_0_0_D2506_ASR_REL_4_7_REV_0000_20250610 * Debugger: Lauterbach * Target: Internal_FLASH ******************************************************************************** * Revision History: * Ver Date Author Description of Changes * 1.0 02-10-2026 Petr Stancik Initial version ********************************************************************************
View full article
HSE-B 安全散列算法\(SHA\)-512 / Ed25519 在 S32K344 上验证时间 - 这些数值是否符合预期? 嗨,卢卡斯( @lukaszadrapa ) 参考已解决:关于 HSE 对 ED25519 和 安全散列算法\(SHA\)-512 的支持的澄清 (S32K394) - NXP 社区, 感谢您澄清关于 HSE-B 上软件模拟 安全散列算法(SHA)-384/512 的问题。我们在 S32K344 引导加载程序中遇到了完全相同的问题,想知道我们的测量结果是否具有代表性。 设置 S32K344,CORE_CLK 160 MHz,HSE_CLK 80 MHz(CORE_CLK/2,如 Clock_Ip 中配置) 来自软件包 0.2.55.0 的 HSE 主机接口/标头已安装 HSE FW 0.2.40.0 (我们目前使用的是 SBAF 0.10.0,所以我们现在还不能升级到 0.2.55.0 版本) 消息:应用程序映像位于 PFLASH 中,大小为 2,965,376 字节(0x00500000–0x007D3F7F),通过地址传递(不复制到 RAM) 单次请求,MU0 通道 1,同步轮询;描述符和输出缓冲区位于不可缓存的 SRAM 中 在 M7 上使用 PIT (40 MHz) 对 HSE_Send() 进行计时 测量代码   c static uint8_t digest[64] __attribute__((aligned(32), section(".mcal_bss_no_cacheable"))); static uint32_t digest_len __attribute__((aligned(32), section(".mcal_bss_no_cacheable"))); static uint32_t hash_time_ms(hseHashAlgo_t algo, const uint8_t *msg, uint32_t len, uint32_t *rsp) { hseSrvDescriptor_t *desc = &gHseSrvDesc[0][1]; hseHashSrv_t *hsh = &desc->hseSrv.hashReq; digest_len = sizeof(digest); memset(desc, 0, sizeof(*desc)); desc->srvId = HSE_SRV_ID_HASH; hsh->accessMode = HSE_ACCESS_MODE_ONE_PASS; hsh->hashAlgo = algo; hsh->sgtOption = HSE_SGT_OPTION_NONE; hsh->inputLength = len; hsh->pInput = HSE_PTR_TO_HOST_ADDR(msg); /* PFLASH */ hsh->pHashLength = HSE_PTR_TO_HOST_ADDR(&digest_len); hsh->pHash = HSE_PTR_TO_HOST_ADDR(digest); uint32_t t0 = ~IP_PIT_0->TIMER[1].CVAL; /* 40 MHz up-counter */ *rsp = HSE_Send(0, 1, gSyncTxOption, desc); return ((~IP_PIT_0->TIMER[1].CVAL) - t0) / 40000u; /* ms */ } t256 = hash_time_ms(HSE_HASH_ALGO_SHA2_256, (const uint8_t *)0x00500000, 0x2D3F80, &rsp256); t512 = hash_time_ms(HSE_HASH_ALGO_SHA2_512, (const uint8_t *)0x00500000, 0x2D3F80, &rsp512); EdDSA 验证是一次 HSE_SRV_ID_SIGN 请求,其中 HSE_SIGN_EDDSA、bHashEddsa = FALSE(纯 Ed25519)、bInputIsHashed = FALSE,以及相同的消息指针和长度。密钥是导入到 RAM 插槽中的 ED25519 公钥。 结果(所有请求均返回 HSE_SRV_RSP_OK) 操作,2,965,376 字节 引擎时间 安全散列算法(SHA)-256 HSE-B(HW) 38毫秒 安全散列算法(SHA)-512 HSE-B(软件仿真) 26,010 毫秒 Ed25519 验证(纯) HSE-B 26,019 毫秒 Ed25519 验证(纯) Cortex-M7 软件,160 MHz,-O2,数据缓存 开启 952毫秒 因此,HSE 验证的速度比 M7 软件实现慢约 27 倍。几乎所有时间都是对消息进行 安全散列算法\(SHA\)-512 校验:验证减去 安全散列算法\(SHA\)-512 校验时间约为 9 毫秒。 问题 HSE-B 的 安全散列算法(SHA)-512 吞吐量约为 114 KB/s(80 MHz 时约为 700 个 HSE 周期/字节),这是预期值吗?还是说这指向了我们这边的配置问题(例如 HSE 的闪存读取路径)? FW 0.2.40.0 与 0.2.55.0 在 安全散列算法\(SHA\)-512/EdDSA 性能方面是否存在差异?针对固件版本 0.2.40.0,运行 0.2.55.0 接口头是否支持 HASH 和 SIGN 服务? 对于 HSE-B 上的快速图像认证,推荐的方法是使用 安全散列算法\(SHA\)-256 的 ECDSA P-256,还是有支持的方法使用带有硬件加速摘要的 Ed25519? 关于我们的硅 我们的零件是早期硅芯片,带有 SBAF 0.10.0,因此我们无法安装 HSE FW 0.2.55.0,只能使用 0.2.40.0。我们想知道这种较旧的 SBAF/FW 组合是否会导致 安全散列算法(SHA)-512 软件仿真速度比当前部件慢。也就是说,据我们了解,即使使用较新的固件,在 80 MHz 的 HSE 内核上模拟的安全散列算法(SHA)-512 也无法在 160 MHz 的 Cortex-M7 上达到相同的计算速度(完整的 Ed25519 验证需要 952 毫秒,而 HSE 大约需要 26 秒)。除非您发现我们的设置有误,否则我们计划在 M7 上保留 Ed25519 验证,并且仅在硬件加速的情况下(AES、安全散列算法\(SHA\)-256)使用 HSE。如果这个结论有误,请指正。 提前感谢! 法比奥 Re: HSE-B SHA-512 / Ed25519 verify timings on S32K344 – are these figures expected? 嗨@FabioG 测量结果看起来合理。Ed25519 验证时间过长几乎完全是由 安全散列算法(SHA)-512 处理 ~2.97 造成的。MB消息。 我有一些基准数据,与你的结果相符。当 HSE_CLK = 120MHz 时,对 24KB 数据进行哈希运算大约需要 140ms。将此扩展到 80MHz 和 ~2.97 MB 消息大小,大约需要 26.5 秒,这与您的测量值非常接近。 上述HSE固件版本之间没有性能差异。本次更新仅包含一些小改动和几个错误修复。这完全是由软件模拟引起的。 如果图像认证性能很重要,那么在 HSE-B 上,采用 安全散列算法\(SHA\)-256 的 ECDSA P-256 将是一个速度更快的选择。安全散列算法\(SHA\)-256 是硬件加速的。根据我掌握的基准测试数据,ECDSA P-256/安全散列算法(SHA)-256 验证结果约为 2.9780 MHz 的 MB 图像估计大约需要 0.3 秒,而 Ed25519 的 MB 图像则需要大约 26 秒。请注意,这只是简单的缩放,我还没有在硬件上验证过。 此致, Lukas
View full article
顶级供应商为制造企业构建定制化人工智能代理 我当时正在寻找能够为制造企业构建定制人工智能代理的顶级供应商,然后发现了 Intellectyx。该公司开发企业级人工智能代理,用于预测性维护、质量检验、生产计划、存货优化、设备监控、功能安全管理和供应链协调等工作流程。Intellectyx 还将这些代理与现有的 ERP、MES、CMMS、CRM 和工业数据系统集成。其在 Clutch 认证的我的获得了 4.9 分(满分 5 分),基于 10 条客户评价。有人与 Intellectyx 合作过或者评估过其制造业人工智能解决方案吗?
View full article
LS1046A IBIS file How do I get an IBIS model for the LS1046A? QorIQ LS1 Devices Re: LS1046A IBIS file How do I get an IBIS model for the LS1046A
View full article
需要澄清MPC5200CVR400B与SPC5200CVR400B的生命周期状态 尊敬的恩智浦技术支持团队: 我们正在评估 MPC5200/MPC5200B 系列产品的生命周期状态,希望您能就以下部件号提供一些说明: MPC5200CVR400B SPC5200CVR400B 根据 NXP 网站上提供的信息,我们了解到MPC5200CVR400B与停产通知 202601026DN 和 202601026DNU01 相关,并提供了最后购买日期和最后交货日期。 然而,对于SPC5200CVR400B ,我们注意到产品页面显示其已停产,但我们无法确定: SPC5200CVR400B 已正式发布与 MPC5200CVR400B 相同的停产通知。 SPC5200CVR400B 的最后购买日期 (LTB) 和最后交货日期 (LTD) 相同。 SPC5200CVR400B 被认为是过时/停产的,或者如果它在不同的生命周期状态下仍然可用。 MPC5200CVR400B 和 SPC5200CVR400B 在生命周期管理方面没有任何功能或商业上的区别。 请问能否提供SPC5200CVR400B的官方生命周期状态,以及(如有)相关的 PCN/EOL 文档? 您的确认将有助于我们在元器件生命周期数据库中正确分类此设备。 感谢您的支持。 此致, 阿比吉特·索兰基 CG动力与工业解决方案有限公司 [email protected] Re: Clarification Required on Lifecycle Status of MPC5200CVR400B vs SPC5200CVR400B 你好, 所有 S/MPC5200 型号现已停产。 https://www.nxp.com/products/MPC5200 内部电子邮件记录证实 SPC5200CVR400B 已停止使用。 SPC5200CVR400B:已停产/过时,但尚未正式确认是否适用同一停产通知,但我预计情况会相同。 如果您需要更多信息,请联系恩智浦销售部门或在NXP.com提交工单。 顺祝商祺! Peter
View full article
HSE-B SHA-512 / Ed25519 の S32K344 における検証タイミング - これらの数値は想定どおりですか? こんにちは、ルーカス( @lukaszadrapa ) 解決済み:ED25519およびSHA-512(S32K394)に対するHSEサポートに関する明確化 - NXPコミュニティ SHA-384/512がHSE-Bのソフトウェアでエミュレートされるという説明ありがとうございます。S32K344ブートローダーでまさにこの問題に遭遇したのですが、私たちの測定結果が代表的なものかどうかを知りたいと思っています。 設定 S32K344、CORE_CLK 160 MHz、HSE_CLK 80 MHz(CORE_CLK/2、Clock_Ipで設定) パッケージ0.2.55.0のHSEホストインターフェース/ヘッダー、HSE FW 0.2.40.0 がインストールされています(弊社は SBAF 0.10.0 を使用しています)。したがって、まだ0.2.55.0に移行することはできません) メッセージ:PFLASHのアプリケーションイメージ、2,965,376バイト(0x00500000–0x007D3F7F)、アドレスで渡されます(RAMコピーなし) ワンパスリクエスト、MU0チャネル1、同期ポーリング;非キャッシュ可能なSRAM内のディスクリプタおよび出力バッファ M7でPIT(40MHz)を使用してHSE_Send()付近で計測したタイミング 測定コード   c static uint8_t digest[64] __attribute__((aligned(32), section(".mcal_bss_no_cacheable"))); static uint32_t digest_len __attribute__((aligned(32), section(".mcal_bss_no_cacheable"))); static uint32_t hash_time_ms(hseHashAlgo_t algo, const uint8_t *msg, uint32_t len, uint32_t *rsp) { hseSrvDescriptor_t *desc = &gHseSrvDesc[0][1]; hseHashSrv_t *hsh = &desc->hseSrv.hashReq; digest_len = sizeof(digest); memset(desc, 0, sizeof(*desc)); desc->srvId = HSE_SRV_ID_HASH; hsh->accessMode = HSE_ACCESS_MODE_ONE_PASS; hsh->hashAlgo = algo; hsh->sgtOption = HSE_SGT_OPTION_NONE; hsh->inputLength = len; hsh->pInput = HSE_PTR_TO_HOST_ADDR(msg); /* PFLASH */ hsh->pHashLength = HSE_PTR_TO_HOST_ADDR(&digest_len); hsh->pHash = HSE_PTR_TO_HOST_ADDR(digest); uint32_t t0 = ~IP_PIT_0->TIMER[1].CVAL; /* 40 MHz up-counter */ *rsp = HSE_Send(0, 1, gSyncTxOption, desc); return ((~IP_PIT_0->TIMER[1].CVAL) - t0) / 40000u; /* ms */ } t256 = hash_time_ms(HSE_HASH_ALGO_SHA2_256, (const uint8_t *)0x00500000, 0x2D3F80, &rsp256); t512 = hash_time_ms(HSE_HASH_ALGO_SHA2_512, (const uint8_t *)0x00500000, 0x2D3F80, &rsp512); EdDSA検証は、HSE_SIGN_EDDSA、bHashEddsa = FALSE(純粋なEd25519)、bInputIsHashed = FALSE、および同じメッセージポインタと長さを指定した、1パスのHSE_SRV_ID_SIGNリクエストです。鍵となるのは、RAMスロットにインポートされたED25519公開鍵です。 結果(すべてのリクエストがHSE_SRV_RSP_OKを返しました) 処理時間:2,965,376バイト SHA-256 HSE-B(HW) 38ミリ秒 SHA-512 HSE-B(ソフトウェアエミュレーション) 26,010ミリ秒 Ed25519 検証 (純粋) HSE-B 26,019ミリ秒 Ed25519 検証 (純粋) Cortex-M7ソフトウェア、160MHz、-O2、Dキャッシュオン 952ミリ秒 つまり、HSEの検証はM7ソフトウェアの実装より約27倍遅いです。ほとんどの場合、メッセージに対するSHA-512: 検証マイナスSHA-512は約9ミリ秒です。 質問 約114 KB/秒(80 MHzで約700 HSEサイクル/バイト)は、HSE-BにおけるSHA-512の想定スループットでしょうか、それとも弊社側の設定上の問題(例えば、HSEからのフラッシュ読み取りパスなど)を示しているのでしょうか? FW 0.2.40.0はSHA-512/EdDSAのパフォーマンスにおいて0.2.55.0と異なる挙動を示す可能性はありますか?HASHおよびSIGNサービスで、FW 0.2.40.0に対して0.2.55.0インターフェースヘッダーを実行させることはサポートされていますか? HSE-Bで高速画像認証を行う場合、推奨される方法はECDSA P-256とSHA-256ですか?それともハードウェアアクセラレーションダイジェストでEd25519を使用するサポート方法はありますか? シリコンに関する注意事項 当社の部品はSBAF 0.10.0の初期シリコン製なので、HSE FW 0.2.55.0をインストールできず、0.2.40.0に制限されています。この古いSBAF/FWの組み合わせが、現在の部品よりもSHA-512ソフトウェアエミュレーションを遅くする可能性があるかどうか知りたいです。とはいえ、私たちの理解では、新しいFWを使っても、HSEコアで80MHzでエミュレートしたSHA-512は、Cortex-M7の160MHz(完全なEd25519検証で952ms、HSEで約26秒)に近づくことはできません。私たちの設定に問題がなければ、M7ではEd25519の認証を維持し、ハードウェアアクセラレーション(AES、SHA-256)でのみHSEを使用する予定です。この結論が間違っている場合は、ご指摘ください。 よろしくお願いいたします。 ファビオ Re: HSE-B SHA-512 / Ed25519 verify timings on S32K344 – are these figures expected? こんにちは、 @FabioGさん 測定結果は妥当なようだ。Ed25519の長い検証時間は、ほぼ完全にSHA-512による~2.97のプロセッシングによって引き起こされます。MBメッセージ。 あなたの結果と一致するベンチマークデータを持っています。HSE_CLK = 120MHzの場合、24KBのデータに対するハッシュ演算は約140msかかります。これを80MHz、メッセージサイズ約2.97MBにスケーリングすると、約26.5秒となり、これは測定値と非常に近い値です。 上記HSEファームウェアのバージョン間には、パフォーマンス上の違いはありません。軽微なアップデートといくつかのバグ修正が含まれています。これは完全にソフトウェアエミュレーションが原因です。 画像認証性能が重要な場合、ECDSA P-256とSHA-256の組み合わせはHSE-B上でより高速な選択肢となります。SHA-256はハードウェアアクセラレーションに対応しています。私が持っているベンチマークデータに基づくと、同じもののECDSA P-256/SHA-256検証は約2.97です。80 MHzでのMB画像は約0.3秒と推定でき、Ed25519は約26秒かかります。これは単純なスケーリングであり、ハードウェアでの確認はしていませんのでご注意ください。 よろしくお願いいたします。 ルーカス
View full article
HSE-B SHA-512 / Ed25519 verify timings on S32K344 – are these figures expected? Hi Lukas (@lukaszadrapa) Referring to Solved: Clarification on HSE support for ED25519 and SHA-512 (S32K394) - NXP Community,  Thanks for the clarification on SHA-384/512 being emulated in software on HSE-B. We ran into exactly this on an S32K344 bootloader and would like to know whether our measurements are representative. Setup S32K344, CORE_CLK 160 MHz, HSE_CLK 80 MHz (CORE_CLK/2, as configured in Clock_Ip) HSE host interface/headers from package 0.2.55.0, HSE FW 0.2.40.0 installed (we are on SBAF 0.10.0, so we cannot move to 0.2.55.0 yet) Message: application image in PFLASH, 2,965,376 bytes (0x00500000–0x007D3F7F), passed by address (no RAM copy) One-pass requests, MU0 channel 1, synchronous polling; descriptors and output buffers in non-cacheable SRAM Timing taken on the M7 with the PIT (40 MHz) around HSE_Send() Measurement code   c static uint8_t digest[64] __attribute__((aligned(32), section(".mcal_bss_no_cacheable"))); static uint32_t digest_len __attribute__((aligned(32), section(".mcal_bss_no_cacheable"))); static uint32_t hash_time_ms(hseHashAlgo_t algo, const uint8_t *msg, uint32_t len, uint32_t *rsp) { hseSrvDescriptor_t *desc = &gHseSrvDesc[0][1]; hseHashSrv_t *hsh = &desc->hseSrv.hashReq; digest_len = sizeof(digest); memset(desc, 0, sizeof(*desc)); desc->srvId = HSE_SRV_ID_HASH; hsh->accessMode = HSE_ACCESS_MODE_ONE_PASS; hsh->hashAlgo = algo; hsh->sgtOption = HSE_SGT_OPTION_NONE; hsh->inputLength = len; hsh->pInput = HSE_PTR_TO_HOST_ADDR(msg); /* PFLASH */ hsh->pHashLength = HSE_PTR_TO_HOST_ADDR(&digest_len); hsh->pHash = HSE_PTR_TO_HOST_ADDR(digest); uint32_t t0 = ~IP_PIT_0->TIMER[1].CVAL; /* 40 MHz up-counter */ *rsp = HSE_Send(0, 1, gSyncTxOption, desc); return ((~IP_PIT_0->TIMER[1].CVAL) - t0) / 40000u; /* ms */ } t256 = hash_time_ms(HSE_HASH_ALGO_SHA2_256, (const uint8_t *)0x00500000, 0x2D3F80, &rsp256); t512 = hash_time_ms(HSE_HASH_ALGO_SHA2_512, (const uint8_t *)0x00500000, 0x2D3F80, &rsp512); The EdDSA verify is a one-pass HSE_SRV_ID_SIGN request with HSE_SIGN_EDDSA, bHashEddsa = FALSE (pure Ed25519), bInputIsHashed = FALSE, and the same message pointer and length. The key is an ED25519 public key imported into a RAM slot. Results (all requests returned HSE_SRV_RSP_OK) Operation, 2,965,376 bytes Engine Time SHA-256 HSE-B (HW) 38 ms SHA-512 HSE-B (SW emulation) 26,010 ms Ed25519 verify (pure) HSE-B 26,019 ms Ed25519 verify (pure) Cortex-M7 software, 160 MHz, -O2, D-cache on 952 ms So the HSE verify is about 27x slower than the M7 software implementation. Almost all of the time is the SHA-512 over the message: verify minus SHA-512 is about 9 ms. Questions Is ~114 KB/s (≈700 HSE cycles/byte at 80 MHz) the expected SHA-512 throughput on HSE-B, or does it point to a configuration issue on our side (for example the flash read path from HSE)? Could FW 0.2.40.0 behave differently from 0.2.55.0 for SHA-512/EdDSA performance? Is running 0.2.55.0 interface headers against FW 0.2.40.0 supported for the HASH and SIGN services? For fast image authentication on HSE-B, is the recommended approach ECDSA P-256 with SHA-256, or is there a supported way to use Ed25519 with a hardware-accelerated digest? Note on our silicon Our parts are early silicon with SBAF 0.10.0, which is why we could not install HSE FW 0.2.55.0 and are limited to 0.2.40.0. We would like to know whether this older SBAF/FW combination could make the SHA-512 software emulation slower than on current parts. That said, our understanding is that even with a newer FW, a SHA-512 emulated on the HSE core at 80 MHz cannot get close to the same computation on the Cortex-M7 at 160 MHz (952 ms for the complete Ed25519 verify, against about 26 s on HSE). Unless you see something wrong in our setup, we plan to keep Ed25519 verification on the M7 and use HSE only where it is hardware accelerated (AES, SHA-256). Please correct us if this conclusion is wrong. Thanks in advance, Fabio Re: HSE-B SHA-512 / Ed25519 verify timings on S32K344 – are these figures expected? Hi @FabioG  The measured results look reasonable. The long Ed25519 verification time is caused almost entirely by SHA-512 processing of the ~2.97 MB message. I have some benchmark data which corresponds to your results. Hash operation on 24KB of data should take about 140ms when HSE_CLK = 120MHz. Scaling this to 80MHz and ~2.97 MB message size, it gives approximately 26.5 s, which is very close to your measured value. There’s no performance difference between mentioned HSE FW versions. There are just some minor updates and several bug fixes. It’s completely caused by SW emulation. If image authentication performance is important, ECDSA P-256 with SHA-256 would be a much faster option on HSE-B. SHA-256 is hardware accelerated. Based on benchmark data I have, ECDSA P-256/SHA-256 verification of the same ~2.97 MB image at 80 MHz can be estimated at approximately 0.3 s, compared with ~26 s for Ed25519. Please notice that this is just simple scaling, I haven’t confirmed this on HW. Regards, Lukas
View full article
LS1046A IBISファイル <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> LS1046A用のIBISモデルはどうやって取得できますか? QorIQ LS1デバイス Re: LS1046A IBIS file LS1046A用のIBISモデルはどうやって入手すればいいですか?
View full article
Top Vendors Building Custom AI Agents for Manufacturing Enterprises I was looking for top vendors that build custom AI agents for manufacturing enterprises and came across Intellectyx. The company develops enterprise AI agents for workflows such as predictive maintenance, quality inspection, production planning, inventory optimization, equipment monitoring, safety management, and supply-chain coordination. Intellectyx also integrates these agents with existing ERP, MES, CMMS, CRM, and industrial data systems. Its Clutch-verified profile has a 4.9 out of 5 rating based on 10 client reviews. Has anyone worked with Intellectyx or evaluated its manufacturing AI solutions?
View full article
MPC5200CVR400BとSPC5200CVR400Bのライフサイクル状況に関する明確化が必要 親愛なるNXPサポートチームへ、 MPC5200/MPC5200Bファミリのライフサイクル状況を審査しており、以下の部品番号についてご説明いただけると幸いです。 MPC5200CVR400B SPC5200CVR400B NXPのウェブサイトで入手可能な情報に基づくと、 MPC5200CVR400Bは販売終了通知202601026DNおよび202601026DNU01に関連付けられており、最終購入日と最終納品日が記載されています。 しかし、製品ページ SPC5200CVR400B「 End of Service 」と表示されているものの、以下のものかどうかは判断できません。 SPC5200CVR400Bは、MPC5200CVR400Bと同じ販売終了通知の対象となります。 SPC5200CVR400Bは、最終購入日(LTB)と最終納品日(LTD)が同じです。 SPC5200CVR400Bは、廃止/販売終了とみなされるか、または別のライフサイクルステータスで引き続き入手可能です。 ライフサイクルマネジメントに関して、MPC5200CVR400BとSPC5200CVR400Bの間に機能的または商業的な違いはありません。 公式なライフサイクル状況と、可能であれば関連するPCN/EOLドキュメントを SPC5200CVR400B教えていただけますか? お客様からのご確認は、当社の部品ライフサイクルデータベースにおいて、このデバイスを正しく分類するために役立ちます。 再開まで今しばらくお待ちください。 敬具 アビジート・ソランキ CGパワー・アンド・インダストリアル・ソリューションズ・リミテッド [email protected] Re: Clarification Required on Lifecycle Status of MPC5200CVR400B vs SPC5200CVR400B こんにちは、 S/MPC5200はすべて販売終了となりました。 https://www.nxp.com/products/MPC5200 社内メールの記録によると、SPC5200CVR400Bは販売終了(EOL)状態であることが確認されています。 SPC5200CVR400B:EOL/廃止品ですが、同じ販売終了通知の対象となるかどうかは正式には確認されていませんが、同じになると予想されます。 さらに詳しい情報が必要な場合はNXPセールスに連絡するか、NXP.com でチケットを提出してください よろしくお願いいたします。 ピーター
View full article
Clarification Required on Lifecycle Status of MPC5200CVR400B vs SPC5200CVR400B Dear NXP Support Team, We are reviewing the lifecycle status of the MPC5200/MPC5200B family and would appreciate your clarification regarding the following part numbers: MPC5200CVR400B SPC5200CVR400B Based on the information available on the NXP website, we understand that MPC5200CVR400B is associated with discontinuance notices 202601026DN and 202601026DNU01, with Last Time Buy and Last Time Delivery dates provided. However, for SPC5200CVR400B, we observe that the product page indicates an End of Life status, but we are unable to determine whether: SPC5200CVR400B is officially covered by the same discontinuance notice as MPC5200CVR400B. SPC5200CVR400B has the same Last Time Buy (LTB) and Last Time Delivery (LTD) dates. SPC5200CVR400B is considered obsolete/discontinued, or if it remains available under a different lifecycle status. There is any functional or commercial distinction between MPC5200CVR400B and SPC5200CVR400B regarding lifecycle management. Could you please provide the official lifecycle status and, if available, the relevant PCN/EOL documentation for SPC5200CVR400B? Your confirmation will help us correctly classify this device in our component lifecycle database. Thank you for your support. Best Regards, Abhijeet Solanki CG Power and Industrial Solutions Limited [email protected] Re: Clarification Required on Lifecycle Status of MPC5200CVR400B vs SPC5200CVR400B Hello, All S/MPC5200 are now end of life. https://www.nxp.com/products/MPC5200 Internal email records confirm that SPC5200CVR400B is in End of Life status. SPC5200CVR400B: EOL/obsolete, but coverage by the same discontinuance notice is not officially confirmed, but I expect that it will be the same. If you require more info get in touch with NXP Sales or rise a ticket at NXP.com Best regards, Peter
View full article