Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
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
IW610 M.2 and FRDM Adapter Product Training: Bringing Wireless Connectivity to Low-Cost Devices   Welcome to IW610 M.2 and FRDM Adapter Product Training! This page provides access to training materials, presentations, demos, recordings, and supporting resources related to the IW610 M.2 development card and the FRDM adapter. While live Q&A support will be available during the training period, all content will remain accessible for future reference and self-paced learning.  Instructions  To get started with the IW610 M.2 and FRDM Adapter training, you will need to have your FRDM-MCXN947, IW610G-M2 and FRDM Adapter board in hand and perform the set-up operations according to the IW610G-M2 and FRDM-ADPT-MCX-M2 Getting Started Page which is a pre-requisite.   Step 1. Mandatory pre-work before starting with the labs:  Getting Started with IW610G-M2 Getting Started with FRDM-ADPT-MCX-M2 Step 2. After completing the pre-work, download the lab guides. Each lab has its own guide document and a video guide you can use as support material in case you have any question at any step:  Lab1: Wi-Fi Server Temperature Monitor Description This demo connects the IW610G-M2 to an FRDM-MCXN947 using an FRDM-M2-ADAPTER board and sends temperature measurements to an HTTPS server over Wi-Fi. Also creates an access point to enable connections. The online dashboard can also be used to wirelessly control the onboard LEDs. (End applications: home automation, industrial monitoring) Lab2: RTP USB Camera Stream over Wi-Fi Description This demo connects the IW610G-M2 to an FRDM-MCXN947 using an FRDM-M2-ADAPTER board and uses a camera module to stream real-time video over Wi-Fi to a laptop or another FRDM-MCXN947 with an IW610G-M2. The captured video is displayed on an LCD-PAR screen (In case to use a FRDM-MCXN947). (End application: Interphone, security camera) Step 3. Review the support material and useful links to get you up to speed with some product information, M.2 development card and FRDM adapter information and getting started. Below also includes additional reading material.   IW610 M2 Module | NXP Semiconductors Getting Started with IW610G-M2 | NXP Semiconductors https://nww.preview-cloud.nxp.com/pages/:FRDM-ADPT-MCX-M2 Getting Started with FRDM-ADPT-MCX-M2 | NXP Semiconductors Community Support If you have questions regarding this training, please leave your comments in our Wireless Community! here 
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
使用 ISP 通过 USB 进行刷写 (MCXA175VLH) 尊敬的各位, 我们将现有的设计从 LPC1315 迁移到了新的 MCXA175VLH。我们通常使用 ISP 模式下的 USB 来上传软件。这对于 LPC1315(以及无数其他处理器)来说没有任何问题。但是,MCXA175VLH 连接到 PC 后不会显示任何消息。ISP 引脚 P0.6 设置为低电平,RESET 引脚也得到了正确的处理。DP+ 和 DM- 这两条线分别通过一个 33 欧姆的电阻连接到 PC。 处理器本身工作正常——通过 SWDIO 访问完全没问题——因此调试器也能正常工作。 有什么想法吗? 启动 ROM | 启动配置 | 闪存 USB Re: Using USB via ISP for flashing (MCXA175VLH) Hello 根据UG10365:MCX A175 硬件设计指南第 6.3 章 ISP 编程和表 13;MCX A17 仅支持通用异步接收器/发射器 (UART) 作为串行外设接口 (SPI) 接口。不支持集成电路间总线(I2C)、串行总线接口(SPI)和通用串行总线(USB)ISP接口。 在这种情况下,USB 连接将无法读取,因此请改为添加 UART ISP 连接。 如果您正在设计 MCXA175 定制板,请参考此硬件设计指南以获取更多建议和说明。 此致敬礼,路易斯
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
LS1046Aカスタムボード:PBL SD_CLKが195kHzから24kHzに低下し、その後アイドル状態になる。HRESET_BがLOWのままになる。 こんにちは、 これは先ほどのThread(6月は不在)に続くものです。 https://community.nxp.com/t5/QorIQ/LS1046A-custom-board-cold-boot-fails-from-eMMC-SD-and-QSPI/m-p/2416533 概要 SDカードからのネイティブコールドブートは、HRESET_BがLOWになると停止します。デバッガ支援ブート(CodeWarrior rcw.apply())は、同じRCW、PBI、およびカードを使用してU-Bootに到達します。ネイティブストール中、PBLは約195kHzでSD_CLKを開始し、コマンドフレームを送信します。DAT0はトグルしません。その後、クロックは停止し、約24kHzで短時間再始動し、バスはアイドル状態になる。これをRM表4-8「RCW州のタイミング」に照らし合わせて解釈するにあたり、ご協力をお願いいたします。 セットアップ(ボード2、リセット作業なし) LS1046AXE8T1A Rev 1.0 (SVR 0x87070010)CPLDは使用せず、STM32 BMCが電源シーケンスとリセットを行います。 cfg_rcw_src=0x40 (SW8 = 0010 0000、SW5 極 1 OFF)。 主要基準:100MHz差動。時計選択ストラップ IFC_WE_B (cfg_eng_use0)。DDR参照:差分。 SDカード:同じカードでLS1046ARDBをU-Bootで起動できます。 EVDD = 3.3 V。SD/eMMCマルチプレクサはSDスロットに設定されています。RCW EVDD_VSEL = 0b10。 RCW:ハードコードされた0x9F例からコピーされたPLL比率(プラットフォーム400MHz、CPU1300MHz、PLL2 1000MHz / FMan 500MHz、DDR 1600MT/s)、両方のSerDesは無効化されています: 0810000d 0a000000 00000000 00000000 00000000 00f00012 60040000 c1000000 00000000 00000000 00000000 0001c83e 00004504 24001102 00000096 00000001 PBI:前のThreadのストリームと同じで、08610040 6d8bdebf(END/CRC)で終わります。 リセット回路: PORESET_Bは、1.8Vへの10kΩプルアップ抵抗を備えたオープンドレインMOSFETによって駆動される。 TRST_Bは個別に制御され、PORESET_Bの1ms後に解放されます。 HRESET_Bには4.7kΩのプルアップ抵抗があります。 ネイティブのコールドブート観測(デバッガ接続なし) 時間は目安です。t = 0 は ASLEEP の立ち下がりエッジであり、これは別のキャプチャで PORESET_B の立ち上がりと一致しました。 ≈ +0.5 ms: SD_CLK は 192〜200 kHz (我々の計算では約 100 MHz/512) で開始します。CMDはアイドル状態です。 ≈ +3.2 ms: CMD フレームが開始されます。フレームの形状はCMD0(40 00 00 00 00 95)のように見えますが、まだデコードしていません。 ≈ +9.6 ms: SD_CLK は約 1 ms 停止します。 ≈ +10.6 ms:クロックなしで CMD と DAT0 にいくつかの遷移が現れます。 ≈ +10.7 ~ +11.2 ms: SD_CLK は約 16 サイクルにわたって 24.39 kHz (約 100 MHz/4096) で動作し、CMD フレームはありません。 ≈ +11.0 ms: ASLEEP が HIGH になります。 その後:残りの250ミリ秒の間、CLK、CMD、DAT0の活動は発生しない。HRESET_BはLOWのままです。 HRESET_BはPORESET_Bが解放される前はLOWであり、解放後もLOWのままです。 カードが挿入されている間、RESET_REQ_BはHIGHのままです。カードがない場合、RESET_REQ_BはLOWになります。 失速中のCCSアクセス CCS::config_chain {ls1043a DAP SAP2} が受け入れられます。ccs::display_mem 2 0x01ee0000 4 0 1 は「スキャンタイムアウト」を返します。 デバッガー支援ブート(動作確認済み) set_source(0x40)とset_data({13: 0x00004504})(カード上の値と同じ)を実行してからapply()を実行します。RCWSRはカードと照合します。U-BootはCPU 1300、プラットフォーム400、DDR 1600、FMan 500 MHzを報告しています。SDの初期化とFIPのロードに成功しました。 質問 表4-8「RCWステートタイミング」によると、100MHzのSYSCLKではどのようなSD_CLK周波数と遷移が見られるでしょうか?「~195 kHz → 停止→ ~24 kHz バースト→アイドル」は、カード識別中にPBLがタイムアウトされた、eSDHCがリセットされた、あるいは後期の状態に到達したことを意味しているのでしょうか? PBLはどのSDコマンドシーケンス(CMD0/CMD8/ACMD41…)を発行し、その際の再試行回数とタイムアウト回数はどのくらいですか?カードが応答しない場合、RESET_REQ_Bはアサートすべきでしょうか?また、どのくらいの時間後にアサートすべきでしょうか? HRESET_BがLOWの場合、SAP2で「スキャンタイムアウト」が発生するのは想定内ですか?もしそうなら、この状態でPBLの進捗を示せるJTAGアクセシブルな状態は何でしょうか? ゆっくりとしたPORESET_B上昇(仕様≤1 SYSCLK)がこの挙動を引き起こす可能性はありますか? カードなしでハードコードされた0x9F: PORESET_B解放後、HRESET_BがHIGHになりませんでした。これはどのように解釈すべきでしょうか? Re: LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW こんにちは、 波形は、デバイスがRCW/PLL遷移を完了しなかったことを示している。まだ通常のPBI/eSDHC動作段階には至っていません。 1. 100 MHz SYSCLK での SD_CLK の想定値 RCWの積載について: SD_CLK = SYSCLK / 512 100 MHz / 512 = 195.3125 kHz RCWロードとPLLロック後: HRESET_B 解除されるべきである。 プラットフォームの時計がスイッチします。 SD_CLK = プラットフォーム clock / 80 . 400 MHzのプラットフォームクロックの場合、これは約 5 MHzに相当します。NXPはこの遷移を、PLLロックとRCWロードが完了したことを示す兆候であると説明しています。 そのため、 ~195 kHz → stop → ~24 kHz burst → idle     これは、文書化された後期の状態遷移を表していません。24 kHz の値は、約 100 MHz / 4096 です。これはリセット/デフォルト分周器または再起動のアーティファクトとして扱い、PBL が PBI のロードに達したことの証明とはみなさないでください。クロックだけではSD識別タイムアウトとeSDHCのリセットを区別できません。 2. SDコマンド、再試行、およびRESET_REQ_B 予想されるSD識別の流れは大まかに以下の通りです: CMD0 CMD8 CMD55 + ACMD41 repeated until the card is ready CMD2 CMD3 CMD7 then block reads for RCW/PBI data     CMD1 は通常、eMMCの初期化コマンドであり、SDカードの初期化コマンドではありません。 正確なLS1043A ROMリトライ数やコマンドごとのタイムアウトは、NXPのサポート資料には記載されていません。これらは波形から推測すべきではありません。NXPのドキュメントでは端末の挙動が説明されています。選択したSDソースが利用できない場合、SoCは他のソースにフォールバックしません。 RESET_REQ_B を主張して停止します。 したがって、カードが完全に存在しない場合、 RESET_REQ_B 最終的にアサートされるはずです。合否判定の基準値として使用できる、「正確にNミリ秒後にアサートする」という固定値は文書化されていません。 HRESET_B ローのままで、かつこれがハイのままである場合、デバイスはまだターミナルPBLエラーパスの手前にあるか、ボードが RESET_REQ_B をマスク/干渉している可能性があります。 3. SAP2「スキャンタイムアウト」 はい、 HRESET_B がまだ有効になっている間は、これは想定される動作です。同じリセット署名— PORESET_B が解放され、 HRESET_B 低、 RESET_REQ_B 高、デバッグパス経由でプロセッサにアクセスできない—は早期リセット/起動条件に関連付けられています。 SAP2が利用可能になるまでは、PBLの進捗状況を報告する信頼できるCCSRレジスターは存在しない。使用: ポアセットB hreset_b RESET_REQ_B 眠っている CLK_OUT (設定されている場合) RCWオーバーライド/safe-RCWまたは RESET_REQ_B の隔離によってデバッグアクセスが確立されたら、以下を検査します。 RSTCR RSTRQSR RSTRQPBLSR RSTRQMR NXPはアクセス可能な場合にこれらのリセットレジスタ RESET_REQ_B 特に推奨しています。 4. PORESET_Bの上昇が遅い はい。遅いまたは形状の悪い PORESET_B リリースはリセット初期化タイミングに違反し、誤ったストラップ、クロック、PLL サンプリングの原因となることがあります。100 MHz の SYSCLK の場合、1 つの SYSCLK の公称制限は約10 nsです。リセットジェネレータ出力だけでなく、LS1043Aのピンで実際の電圧変動と立ち上がり時間を直接確認してください。 また、 RESET_REQ_B が PORESET_B にフィードバックしていないかも確認してください。NXPはブートアップ時に分離オプションを推奨しています。なぜなら、起動失敗がリセットループを起こしてJTAGアクセスを妨げる可能性があるからです。 5. 0x9Fテストの意味 0x9F はハードコードされたRCW/デバッグ識別子です。有効なクロックとリセットシーケンスがあれば、SDカードからRCWを読み取る必要性がなくなるはずです。したがって、カード HRESET_B 装着されていなくてもまだ起こらない場合は、 故障はSDカード識別よりも前から起こっている可能性が高いです。 SYSCLK/差動クロックの選択または品質 PLLロック RCWストラップの解読 電気的なタイミングをリセットします フィードバックまたはJTAG/TRST状態のリセット つまり、0x9Fという結果は、「カードの欠落」が主な原因であるという説に反論するものである。まず、 HRESET_B 0x9Fで立ち上がり、リセット/クロック設定が正常であることを確認してください。その後、SD RCWのロードに戻ります。 よろしくお願いします。
View full article
S32K142EVB-Q100 evaluation board with S32 Design Studio 3.6.11 I am having trouble using the S32K142EVB-Q100 evaluation board with S32 Design Studio 3.6.11 I used the S32DS Extensions and Updates to install S32K1xx Development Package and S32K1_S32M24X Real-Time Drivers AUTOSAR R21-11 Version 3.0.0 QLP07 My problem is that when I create a new project with S32K142 I cannot use the S32 Configuration Tools it says there is no data. I can't configure the pins or anything. How can I get started with this setup?   Re: S32K142EVB-Q100 evaluation board with S32 Design Studio 3.6.11 Hi, SW32K1_S32M24x_RTD_R21-11_3.0.0_QLP07_D2606 contains only a few Driver Plugins, refer to package Release note. First install S32K1_S32M24X Real-Time Drivers AUTOSAR R21-11 Version 3.0.0 QLP06 (SW32K1_S32M24x_RTD_R21-11_3.0.0_QLP06_D2603_DesignStudio_updatesite.zip), and then install S32K1_S32M24x Real-Time Drivers AUTOSAR R21-11 Version 3.0.0 QLP07 if needed it. Also don't forget to select GCC v10.2 toolchain when creating new Project. If this is not installed in your S32DS add it as well through Extension&Updates.   BR, Petr
View full article
PCA9450启动 各位团队成员,大家好! 我的设计中使用了PCA9459CHNY,但是没有得到输出电压。 我尝试了所有配置,但仍然无法获得输出电压。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Bring-Up of PCA9450 你好, 请问您是否在使用评价板?如果可以的话,您能否也分享一下您的配置详情?
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
PCA9450の立ち上げ こんにちは、チームの皆さん、 設計にPCA9459CHNYを使っていますが、出力電圧が出ません。 全ての構成を試しましたが、出力電圧を取得できませんでした。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Bring-Up of PCA9450 こんにちは、 評価ボードを使っているかどうか確認していただけますか?もしそうなら、あなたのセットアップについても教えていただけますか?
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
Bring-Up of PCA9450 Hello Team, I am using PCA9459CHNY in my design but I am not getting the output voltages.  I have tried all the configurations but still didn't able to get the output voltages i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Bring-Up of PCA9450 Hello, Could you please confirm whether you are using the evaluation board? If so, could you also share some details about your setup?
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
LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW Hello, This follows up the earlier thread (June is out of office): https://community.nxp.com/t5/QorIQ/LS1046A-custom-board-cold-boot-fails-from-eMMC-SD-and-QSPI/m-p/2416533 Summary Native cold boot from SD stalls with HRESET_B LOW. Debugger-assisted boot (CodeWarrior rcw.apply()) reaches U-Boot with the same RCW, PBI and card. During the native stall, the PBL starts SD_CLK at about 195 kHz and sends command frames. DAT0 never toggles. The clock then stops, restarts briefly at about 24 kHz, and the bus goes idle. We would like help interpreting this against RM Table 4-8 "RCW State Timing". Setup (board 2, no reset rework) LS1046AXE8T1A Rev 1.0 (SVR 0x87070010). No CPLD; an STM32 BMC does power sequencing and reset. cfg_rcw_src=0x40 (SW8 = 0010 0000, SW5 pole 1 OFF). Primary reference: 100 MHz differential. Clock-select strap IFC_WE_B (cfg_eng_use0). DDR reference: differential. SD card: The same card boots an LS1046ARDB to U-Boot. EVDD = 3.3 V. The SD/eMMC mux is set to the SD slot. RCW EVDD_VSEL = 0b10. RCW: PLL ratios copied from the hard-coded 0x9F example (platform 400 MHz, CPU 1300 MHz, PLL2 1000 MHz / FMan 500 MHz, DDR 1600 MT/s), both SerDes disabled: 0810000d 0a000000 00000000 00000000 00000000 00f00012 60040000 c1000000 00000000 00000000 00000000 0001c83e 00004504 24001102 00000096 00000001 PBI: identical to the stream in the earlier thread, ending with 08610040 6d8bdebf (END/CRC). Reset circuit: PORESET_B is driven by an open-drain MOSFET with a 10 kΩ pull-up to 1.8 V.  TRST_B is controlled separately and released 1 ms after PORESET_B. HRESET_B has a 4.7 kΩ pull-up. Native cold-boot observations (no debugger connected) Times are approximate. t = 0 is the ASLEEP falling edge, which coincided with PORESET_B rising in a separate capture. ≈ +0.5 ms: SD_CLK starts at 192–200 kHz (about 100 MHz/512 by our arithmetic). CMD is idle. ≈ +3.2 ms: CMD frames begin. The frame shape looks like CMD0 (40 00 00 00 00 95), but we have not decoded it. ≈ +9.6 ms: SD_CLK stops for about 1 ms. ≈ +10.6 ms: a few transitions appear on CMD and DAT0 with no clock. ≈ +10.7 to +11.2 ms: SD_CLK runs at 24.39 kHz (about 100 MHz/4096) for about 16 cycles, with no CMD frame. ≈ +11.0 ms: ASLEEP goes HIGH. Afterwards: no CLK, CMD or DAT0 activity for the rest of the 250 ms window. HRESET_B stays LOW. HRESET_B is LOW before PORESET_B is released and stays LOW afterwards. RESET_REQ_B stays HIGH with the card inserted. Without a card, RESET_REQ_B goes LOW. CCS access during the stall ccs::config_chain {ls1043a dap sap2} is accepted. ccs::display_mem 2 0x01ee0000 4 0 1 returns "Scan timeout".  Debugger-assisted boot (works) set_source(0x40) and set_data({13: 0x00004504}) (the same value as on the card), then apply(). RCWSR then matches the card. U-Boot reports CPU 1300, platform 400, DDR 1600, FMan 500 MHz. SD initialisation and FIP loading succeed. Questions Per Table 4-8 "RCW State Timing", what SD_CLK frequencies and transitions should we see with a 100 MHz SYSCLK? Does "~195 kHz → stop → ~24 kHz burst → idle" mean the PBL timed out during card identification, reset the eSDHC, or reached a later state? Which SD command sequence does the PBL issue (CMD0/CMD8/ACMD41 …), with what retries and timeouts? If the card doesn't answer, should RESET_REQ_B assert, and after how long? Is "Scan timeout" on SAP2 expected while HRESET_B is LOW? If so, what JTAG-accessible status can show PBL progress in this state? Could a slow PORESET_B rise ( specification ≤ 1 SYSCLK) cause this behaviour? Hard-coded 0x9F with no card: HRESET_B did not go HIGH after PORESET_B release. How should we interpret this? Re: LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW Hello, The waveform indicates the device never completed the RCW/PLL transition. It is not yet in the normal PBI/eSDHC operating phase. 1. Expected SD_CLK with 100 MHz SYSCLK For RCW loading: SD_CLK = SYSCLK / 512 100 MHz / 512 = 195.3125 kHz After RCW loading and PLL lock: HRESET_B should deassert. The platform clock switches. SD_CLK = platform clock / 80 . With a 400 MHz platform clock, this is approximately 5 MHz. NXP describes this transition as the indication that PLL lock and RCW loading completed. Therefore: ~195 kHz → stop → ~24 kHz burst → idle     does not represent the documented later-state transition. The 24 kHz value is approximately 100 MHz / 4096 ; treat it as a reset/default-divider or restart artifact, not proof that PBL reached PBI loading. The clock alone cannot distinguish an SD identification timeout from an eSDHC reset. 2. SD commands, retries, and RESET_REQ_B The expected SD-identification flow is broadly: CMD0 CMD8 CMD55 + ACMD41 repeated until the card is ready CMD2 CMD3 CMD7 then block reads for RCW/PBI data     CMD1 is normally the eMMC initialization command, not the SD-card equivalent. The exact LS1043A ROM retry count and per-command timeout are not specified in the accessible NXP support material; they should not be inferred from the waveform. NXP documentation instead describes the terminal behavior: if the selected SD source is unavailable, the SoC does not fall back to another source; it asserts RESET_REQ_B and halts. Thus, if the card is completely absent, RESET_REQ_B should eventually assert. There is no documented fixed “assert after exactly N ms” value to use as a pass/fail limit. If it remains high while HRESET_B remains low, the device may still be before the terminal PBL error path—or the board may be masking/interfering with RESET_REQ_B . 3. SAP2 “Scan timeout” Yes, this is expected while HRESET_B is still asserted. The same reset signature— PORESET_B released, HRESET_B low, RESET_REQ_B high, and the processor inaccessible through the debug path—is associated with an early reset/boot condition. Before SAP2 becomes accessible, there is no dependable CCSR register that reports PBL progress. Use: PORESET_B HRESET_B RESET_REQ_B ASLEEP CLK_OUT , if configured Once debug access is established by using RCW override/safe-RCW or by isolating RESET_REQ_B , inspect: RSTCR RSTRQSR RSTRQPBLSR RSTRQMR NXP specifically recommends these reset registers when RESET_REQ_B access is possible. 4. Slow PORESET_B rise Yes. A slow or poorly shaped PORESET_B release can violate the reset-initialization timing and cause incorrect strap, clock, or PLL sampling. With a 100 MHz SYSCLK, the stated limit of one SYSCLK is approximately 10 ns. Verify the actual voltage crossing and rise time directly at the LS1043A pin, not only at the reset-generator output. Also verify that RESET_REQ_B is not feeding back into PORESET_B ; NXP recommends an isolation option during bring-up because boot failures can otherwise create a reset loop that prevents JTAG access. 5. Meaning of the 0x9F test 0x9F is the hard-coded-RCW/debug discriminator. With a valid clock and reset sequence, it should remove dependence on reading the RCW from the SD card. Therefore, if HRESET_B still never rises with no card installed, the fault is probably earlier than SD-card identification: SYSCLK/differential clock selection or quality PLL lock RCW strap decode reset electrical timing reset feedback or JTAG/TRST state In other words, the 0x9F result argues against “missing card” as the primary cause. First prove that HRESET_B rises with 0x9F and a clean reset/clock setup; then return to SD RCW loading. Regards
View full article