Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
A2DP test on IW612+I.MX8MPlus-EVK L6.6.52 This doc is a brief step by step introduction for how to play music through A2DP on IW612 + I.MX8MPlus-EVK based on L6.6.52. Step 1: Load WiFi/Bluetooth Driver • NXP i.MX Release Distro 6.6-scarthgap imx8mpevk ttymxc1 imx8mpevk login: root root@imx8mpevk:~# modprobe moal mod_para=nxp/wifi_mod_para.conf root@imx8mpevk:~# root@imx8mpevk:~# dmesg | grep wlan [ 562.728200] wlan: Loading MWLAN driver [ 562.728788] wlan: Register to Bus Driver... [ 562.730460] wlan: Enable TX SG mode [ 562.730464] wlan: Enable RX SG mode [ 563.554778] wlan: uap%d set max_mtu 2000 [ 563.622367] wlan: version = SDIW612---18.99.3.p21.10-MM6X18505.p4-GPL-(FP92) [ 563.625611] wlan: Register to Bus Driver Done [ 563.625622] wlan: Driver loaded successfully root@imx8mpevk:~#modprobe btnxpuart root@imx8mpevk:~# hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:EE:71:4F ACL MTU: 1021:7 SCO MTU: 120:6 DOWN RX bytes:774 acl:0 sco:0 events:48 errors:0 TX bytes:496 acl:0 sco:0 commands:47 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT • Step 2: Up BT interface and enable the power save feature root@imx8mpevk:~# hciconfig hci0 up root@imx8mpevk:~# hciconfig hci0 piscan root@imx8mpevk:~#hciconfig hci0 noencrypt root@imx8mpevk:~# hciconfig -a hci0: Type: Primary Bus: UART BD Address: D0:17:69:EE:71:4F ACL MTU: 1021:7 SCO MTU: 120:6 UP RUNNINGPSCAN ISCAN RX bytes:1900 acl:0 sco:0 events:109 errors:0 TX bytes:1365 acl:0 sco:0 commands:108 errors:0 Features: 0xbf 0xfe 0x8f 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'imx8mpevk' Class: 0x200000 Service Classes: Audio Device Class: Miscellaneous, CI Version: 5.4 (0xd) Revision: 0x8300 LMP Version: 5.4 (0xd) Subversion: 0x1015 Manufacturer: NXP Semiconductors (formerly Philips Semiconductors) (37) • Step 3: Scan, Pair and Connect to Headset root@imx8mpevk:~# bluetoothctl hci0 new_settings: powered connectable discoverable bondable ssp br/edr le secure-conn cis-central cis-peripheral Agent registered [CHG] Controller D0:17:69:EE:71:4F Pairable: yes [bluetooth]# power on Changing power on succeeded [bluetooth]# default-agent Default agent request successful [bluetooth]# agent on Agent is already registered [bluetooth]# scan on [NEW] Device B1:96:11:68:9C:09 联想thinkplus-HE05X II代 [bluetooth]# scan off [bluetooth]# pair B1:96:11:68:9C:09 Attempting to pair with B1:96:11:68:9C:09 hci0 device_flags_changed: B1:96:11:68:9C:09 (BR/EDR) supp: 0x00000000 curr: 0x00000000 [DEL] Device 67:02:B9:7C:ED:B5 67-02-B9-7C-ED-B5 [DEL] Device 80:F4:16:4C:48:F2 HI-Apiyoo-12MIQ001981 hci0 B1:96:11:68:9C:09 type BR/EDR connected eir_len 34 [CHG] Device B1:96:11:68:9C:09 Connected: yes hci0 new_link_key B1:96:11:68:9C:09 type 0x04 pin_len 0 store_hint 1 [CHG] Device B1:96:11:68:9C:09 Bonded: yes [DEL] Device 6A:98:7A:08:0F:B8 6A-98-7A-08-0F-B8 [CHG] Device B1:96:11:68:9C:09 ServicesResolved: yes [CHG] Device B1:96:11:68:9C:09 Paired: yes Pairing successful5X II代]# [DEL] Device 6C:59:25:E5:66:77 6C-59-25-E5-66-77 [DEL] Device 61:CC:7D:CE:20:4E 61-CC-7D-CE-20-4E [DEL] Device 64:C1:4B:76:C1:80 64-C1-4B-76-C1-80 [DEL] Device 72:50:16:14:52:A6 72-50-16-14-52-A6 hci0 B1:96:11:68:9C:09 type BR/EDR disconnected with reason 2 [CHG] Device B1:96:11:68:9C:09 ServicesResolved: no [CHG] Device B1:96:11:68:9C:09 Connected: no [bluetooth]#trust B1:96:11:68:9C:09 [CHG] Device B1:96:11:68:9C:09 Trusted: yes Changing B1:96:11:68:9C:09 trust succeeded [bluetooth]#connect B1:96:11:68:9C:09 Attempting to connect to B1:96:11:68:9C:09 hci0 B1:96:11:68:9C:09 type BR/EDR connected eir_len 34 [CHG] Device B1:96:11:68:9C:09 Connected: yes [NEW] Endpoint /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep1 [NEW] Endpoint /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep2 [NEW] Transport /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep1/fd0 [CHG] Transport /org/bluez/hci0/dev_B1_96_11_68_9C_09/sep1/fd0 Delay: 0x05dc (1500) Connection successfulII代]# [CHG] Device B1:96:11:68:9C:09 ServicesResolved: yes [联想thinkplus-HE05X II代]#quit • Step 4: Start pipewire and wireplumber Service then list and choose default Audio Source/Sink Card root@imx8mpevk:~#systemctl --user start pipewire wireplumber root@imx8mpevk:~#wpctl status PipeWire 'pipewire-0' [1.0.5, root@imx8mpevk, cookie:831282980] Clients: 32. WirePlumber [1.0.5, root@imx8mpevk, pid:1528] 40. WirePlumber [export] [1.0.5, root@imx8mpevk, pid:1528] 87. wpctl [1.0.5, root@imx8mpevk, pid:1552] Audio -Devices: 41. Built-in Audio [alsa] 42. Built-in Audio [alsa] 43. Built-in Audio [alsa] 44. Built-in Audio [alsa] 45. Built-in Audio [alsa] 81. 联想thinkplus-HE05X II代 [bluez5] -Sinks: 47. Built-in Audio Mono [vol: 0.40] 48. Built-in Audio Stereo [vol: 0.40] 50. Built-in Audio Stereo [vol: 0.40] 58. Built-in Audio Digital Stereo (IEC958) [vol: 0.40] * 82. 联想thinkplus-HE05X II代 [vol: 0.40] -Sources: 46. Built-in Audio Mono [vol: 1.00] 49. Built-in Audio Stereo [vol: 1.00] 51. Built-in Audio Stereo [vol: 1.00] * 59. Built-in Audio Digital Stereo (IEC958) [vol: 1.00] -Filters: -Streams: Video -Devices: 52. mxc-isi-m2m_v1 [v4l2] 53. vsi_v4l2enc [v4l2] 54. vsi_v4l2dec [v4l2] Streams: Settings Default Configured Devices: root@imx8mpevk:~#wpctl set-default 82 root@imx8mpevk:~#wpctl set-default 59 root@imx8mpevk:~# wpctl status PipeWire 'pipewire-0' [1.0.5, root@imx8mpevk, cookie:831282980] Clients: 32. WirePlumber [1.0.5, root@imx8mpevk, pid:1528] 40. WirePlumber [export] [1.0.5, root@imx8mpevk, pid:1528] 87. wpctl [1.0.5, root@imx8mpevk, pid:1572] Audio 41. Built-in Audio [alsa] 42. Built-in Audio [alsa] 43. Built-in Audio [alsa] 44. Built-in Audio [alsa] 45. Built-in Audio [alsa] 81. 联想thinkplus-HE05X II代 [bluez5] 47. Built-in Audio Mono [vol: 0.40] 48. Built-in Audio Stereo [vol: 0.40] 50. Built-in Audio Stereo [vol: 0.40] 58. Built-in Audio Digital Stereo (IEC958) [vol: 0.40] * 82. 联想thinkplus-HE05X II代 [vol: 0.40] 46. Built-in Audio Mono [vol: 1.00] 49. Built-in Audio Stereo [vol: 1.00] 51. Built-in Audio Stereo [vol: 1.00] * 59. Built-in Audio Digital Stereo (IEC958) [vol: 1.00] 分区Bluetooth 的第4 页 * 59. Built-in Audio Digital Stereo (IEC958) [vol: 1.00] Streams: Video 52. mxc-isi-m2m_v1 [v4l2] 53. vsi_v4l2enc [v4l2] 54. vsi_v4l2dec [v4l2] Streams: Settings Default Configured Devices: 0. Audio/Sink bluez_output.B1_96_11_68_9C_09.1 1. Audio/Source alsa_input.platform-sound-xcvr.iec958-stereo Step 5: Copy、Play and Enjoy Music Drag the music file yesterday-once-more.wavto I.MX8MP-EVK board by connecting Windows PC and I.MX8MP-EVK board into one local area network. root@imx8mpevk:~# pw-play -v ./yesterday-once-more.wav sndfile: opened file "yesterday-once-more.wav" format 00010002 channels:2 rate:44100 sndfile: using default channel map: FL,FR PCM: fmt:s16 rate:44100 channels:2 width:2 rate:44100 latency:4410 (0.100s) connecting playback stream; target=(null) stream state changed unconnected -> connecting stream param change: Spa:Enum:ParamId:Latency stream param change: Spa:Enum:ParamId:Tag stream param change: Spa:Enum:ParamId:Props stream properties: application.name = "pw-play" node.name = "pw-play" media.software = "Lavf58.29.100" media.format = "WAV (Microsoft)" node.rate = "1/44100" node.latency = "4410/44100" media.type = "Audio" media.category = "Playback" media.role media.filename = "yesterday-once-more.wav" media.name = "yesterday-once-more.wav" stream.is-live = "true" node.want-driver = "true" node.autoconnect = "true" media.class = "Stream/Output/Audio" remote 0 is named "pipewire-0" stream state changed connecting -> paused stream param change: Spa:Enum:ParamId:Props stream param change: Spa:Enum:ParamId:Latency stream param change: Spa:Enum:ParamId:Latency stream param change: Spa:Enum:ParamId:Format stream state changed paused -> streaming stream set volume to 1.000 -success stream node 88 stream time: now:0 rate:1/48000 ticks:0 delay:9248 queued:0 buffered:0 buffers:0 avail:2 size:0 stream time: now:4821374572568 rate:1/48000 ticks:49152 delay:9248 queued:1882 buffered:32 buffers:1 avail:1 size:1882 stream time: now:4822355905886 rate:1/48000 ticks:96256 delay:9248 queued:1882 buffered:32 buffers:1 avail:1 size:1882 stream time: now:4823379905870 rate:1/48000 ticks:145408 delay:9248 queued:1881 buffered:32 buffers:1 avail:1 size:1881 Finished By Christine.Li Jul 22th,2026.
記事全体を表示
Understanding I²C Buffers and Static Voltage Offset (SVO): Why Your Bus May Fail I²C communication is widely used due to its simplicity, but when the system grows (more devices, longer traces, different voltage domains), communication issues may appear. One common root cause is the incorrect use of I²C buffers or level translators. This post explains: How I²C logic levels really work Why buffers are needed Types of I²C Buffer Technologies How Static Voltage Offset (SVO) works Common design mistakes to avoid How I²C logic levels really work I²C does not use fixed voltages like 0 V or 5 V to define logic states. Instead, it uses thresholds relative to VCC: Logic 0 (LOW): below ~30% of VCC Logic 1 (HIGH): above ~70% of VCC Undefined region: between 30%–70% → signal is unreliable In real systems, signal levels may not behave ideally. Due to: Different driver strengths Load variations Buffer offset behavior You may observe three voltage levels, even though the protocol only defines two logic states. This can lead to misinterpretation of signals. We will explore this behavior in more detail in the following sections, especially when analyzing how I²C buffers and offset mechanisms work. Why buffers are needed You should consider an I²C buffer when: Bus capacitance exceeds ~400 pF Long PCB traces or cables are used Multiple devices are connected Different voltage domains are required Isolation between sections is needed Buffers divide the system into smaller segments and improve signal integrity. For a deeper understanding, refer to the training: The Ins and Outs of I²C Bus Buffers Types of I²C Buffer Technologies Different buffer architectures solve these challenges in different ways: Static Offset: Introduces a fixed voltage offset on one side of the bus, enabling direction detection. Incremental Offset: Adds a small dynamic voltage shift (~100 mV), allowing symmetrical bidirectional operation. Amplifier: Boosts sink current instead of shifting voltage, helping weak drivers control heavier loads. In this post, we will focus specifically on Static Offset buffers, as they are widely used and often misunderstood in system design. Static Offset Buffer Characteristics Static Offset buffers are commonly used due to their robust behavior: Fully bidirectional and support multi-master operation, including clock stretching and do not generate any ‘glitches’. Isolate bus segments electrically, preventing capacitance and loading on one side from affecting the other side. Each side operates independently with its own rise time and pull-up network. Regenerate signals, producing clean LOW levels independent of the input LOW amplitude. Use a fixed Static Voltage Offset (SVO), creating a slightly higher LOW level on one side of the buffer. This offset allows the buffer to determine the origin of a LOW signal and prevents latching. Weaknesses of Static Offset Buffers Require specific design rules due to their special offset voltage levels. Static Offset ports cannot be connected together on the same bus segment. Only one offset port should exist per bus segment. Add propagation delay, which must be considered in timing analysis. Multiple buffers can reduce the maximum achievable I²C bus speed The main challenge in I²C buffers is that the bus is bidirectional. Both master and slave can pull the line LOW. By introducing a fixed voltage offset, the buffer can distinguish which side initiated the LOW condition and correctly propagate the signal across the bus. How Static Voltage Offset (SVO) works Static Voltage Offset introduces an intentional voltage offset, so a LOW level is not always represented by 0 V. Instead, the buffer creates two valid LOW levels, both within the I²C specification. To achieve this, the input and output logic levels on the special side of the buffer are intentionally designed to be different.   The key concept is that the special output LOW voltage (VOL) is set slightly higher than the corresponding input HIGH threshold (VIH): For example: Special output VOL ≈ 0.7 V Special input VIH ≈ 0.55 V When the buffer drives the special side LOW at approximately 0.7 V, that voltage is still considered a valid LOW by other I²C devices on the bus. However, for the buffer's own special input, 0.7 V is interpreted as a HIGH because it is above its VIH threshold. As a result, the buffer's output cannot feed back into its own input, preventing the latching condition commonly found in simple bidirectional buffers. This enables the buffer to distinguish between two conditions: State 1: The voltage is between the special input threshold (VIL) and the offset level (VOL/SVO). This indicates that the LOW originated from one side of the buffer. State 2: The voltage is pulled much closer to 0 V, below the special threshold. This indicates that the LOW originated from the opposite side of the buffer. By monitoring these voltage levels, the buffer can determine where the LOW signal originated (Side A or Side B). Once the direction is identified, the buffer can correctly propagate the signal to the other side while avoiding feedback, latching, and communication conflicts. But, How Does the Buffer Determine the Signal Direction? The Buffer uses an internal voltage offset to automatically determine the direction of I²C signal propagation. The offset appears on the opposite side of the device that is actively pulling the bus LOW, allowing the buffer to identify the signal source and maintain proper bidirectional operation. The buffer continuously monitors the voltage present on both sides and compares it against the internal offset thresholds. Case 1: LOW originated from the Non-Offset side (A → B) A device on Side A pulls the line LOW. The buffer propagates this LOW to Side B while adding the static offset: Side A = LOW Side B = LOW + Offset As a result: Input = LOW Output = OFFSET The presence of the offset voltage indicates that the signal originated from the Non-Offset side and is being propagated toward the Offset side.   Case 2: LOW originated from the Offset side (B → A) A device on Side B pulls the line LOW. The buffer recognizes that the voltage has been driven below the offset threshold and propagates a true LOW toward Side A: Side B ≈ LOW Side A ≈ LOW As a result: Input = LOW Output = LOW The absence of an offset on the output indicates that the signal originated from the Offset side and is being propagated toward the Non-Offset side.   INPUT OUTPUT DIRECTION LOW LOW B SIDE TO A SIDE LOW OFFSET A SIDE TO B SIDE   Common design mistakes to avoid When using I²C buffers that implement Static Voltage Offset (SVO), it is important to carefully consider both device selection and system-level design. This is because not all buffers use the same offset value. Typically, the SVO can vary between approximately 0.1 V and 0.6 V, depending on the internal design of each device. This variation directly affects how LOW levels are interpreted and how signals are propagated between segments of the bus, which can ultimately impact the reliability of bidirectional communication. Another important aspect is that the offset is not always located on the same side of the buffer. In some devices, the offset is applied on Side B, while in others it is on Side A. There are even cases where the offset may dynamically change sides depending on the operating conditions. For this reason, it is essential to fully understand the internal behavior of the selected buffer in order to avoid unexpected system behavior. The easiest way to verify this is by reviewing the device datasheet and identifying whether it specifies a parameter such as the VOL–VILC difference, which represents the difference between the LOW-level output voltage and the LOW-level input voltage during a contention condition. Voltage contention occurs when both sides of the buffer attempt to pull the line LOW at the same time but with different voltage levels or drive strengths. Due to this variability, there is a very important design rule: SVO-based buffers must never be directly connected to each other, whether in series or in parallel. This means that you should not connect two buffer sides that both introduce a voltage offset, as their LOW levels will not align correctly. The reason for this limitation is that it can lead to errors in LOW-level propagation. In such cases, a LOW signal may propagate correctly in one direction but fail in the opposite direction, breaking the bidirectional behavior of the I²C bus, which is essential for proper communication.   These diagrams show correct implementations of SVO-based I²C buffers. In these configurations, only one side of the system introduces a static voltage offset, allowing the buffer to properly distinguish the origin of the LOW signal. This ensures correct bidirectional communication, stable signal propagation, and prevents contention or oscillation issues.         These diagrams illustrate incorrect configurations where two SVO-based buffers are directly connected. In this case, both sides introduce different LOW offset levels, preventing proper alignment of logic thresholds. As a result, the buffer may fail to correctly detect the signal origin, leading to incomplete LOW propagation, loss of bidirectional behavior, and potential communication failures.     I2C
記事全体を表示
Example SJA1110 FreeRTOS lwIP SJA1110-EVM S32DS 3.5 RTD 1.0.2 ********************************************************************************* * Detailed Description: * Updated the example lwip_FreeRTOS_SJA1110 for board SJA1110-EVM * to enable ping from the command window, from all applicable ports * *ping 192.168.0.200 * *Pinging 192.168.0.200 with 32 bytes of data: *Reply from 192.168.0.200: bytes=32 time=2ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 * *Ping statistics for 192.168.0.200: * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), *Approximate round trip times in milli-seconds: * Minimum = 1ms, Maximum = 2ms, Average = 1ms * * Installed packages to S32DS 3.5 update 14: * SW32SJA11xx_S32DS_3.5.0_RFP_D2206.zip * SJA11XX_RTD_4.4_1.0.1_P02_HF01_D2510_DesignStudio_updatesite.zip * SW32SJA1110_XJA11XX_ETH_PHY_4.4_1.0.8_CD01_D2509_DesignStudio_updatesite.zip * SJA11XX_ETH_SWITCH_4.4_1.0.2_CD01_D2509_DesignStudio_updatesite.zip * SW32SJA11xx_FreeRTOS_11.1.0_0.8.0_CD2_D2411_DesignStudio_updatesite.zip * SJA11XX_TCPIP_2.0.0_CD01_D2510_DesignStudio_updatesite.zip * * EVB: * - Except SW15, All DIP switches accordingly to um575112-AH1901 SJA1110 - EVM User Manual(1.2).pdf * - TJA1101 needs to be in Managed Operation, RMII mode (50 MHz output on REF_CLK) * SW15.1-8: ON OFF ON OFF ON OFF OFF ON * * Configuration: * - Updated switch configuration * - Updated phy configuration * - Fixed Mcu/McuModuleConfiguration/McuPowerControlUnit - 1V8 and 2V5 * - Fixed Eth configuration * * * * - TCPIP stack: enabled UDP_ECHO, etc. * - Added Gpio_Dio * - Added nvm_metadata * - MAC learning is disabled * - Added LED control via I2C GPIO expander * (adopted & fixed from SJA1110_gptp_ds example - SW32SJA11xx_M7_gPTP_1_0_0_D2411_DesignStudio_updatesite.zip) * * main.c * - Updated only the header * device.c/h * - adopted from SJA1110_gptp_ds example * test.c * - Removed the code that shuts down the TCP/IP stack after its predefined timeout * - Added LED ALIVE * - Added debug stuff * /board + /pca950x + /swi2c * - adopted from SJA1110_gptp_ds example * * ----------------------------------------------------------------------------- * Test HW: SJA1110-EVM SCH REV B2 * MCU: SJA1110 * Debugger: Lauterbach TRACE32 * Target: RAM or external FLASH (flash_image.bin generated) * EVB connection: any port (excluding SFP cages) <-> RDDRONE T1ADAPT (on ports where applicable) <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11
記事全体を表示
Ethernet Switch SJA1110 Examples S32G-VNP-RDB2 Note: S32G-VNP-RDB2 examples can be used also on S32G-VNP-RDB3. Example SJA1110 FreeRTOS lwIP S32G-VNP-RDB2 S32DS 3.5 RTD 1.0.2 SJA1110-MGS-EVM Example SJA1110 FreeRTOS lwIP SJA1110-MGS-EVM S32DS 3.5 RTD 1.0.2 MR-T1ETH8 Example SJA1110 FreeRTOS lwIP MR-T1ETH8 S32DS 3.5 RTD 1.0.2 SJA1110-EVM Example SJA1110 FreeRTOS lwIP SJA1110-EVM S32DS 3.5 RTD 1.0.2
記事全体を表示
LLCE example and U-boot Hello. I'm trying to make the LLCE examples work on the Goldbox. I modified the CAN2CAN example a little bit, and it works if I debug it from S32DS. If I try to run it from U-boot, however, it executes, but hangs U-boot itself. These are the commands I'm running: dcache off; mw.q 0x34000000 0x0 0x100000; dcache on fatload mmc 0:2 ${loadaddr} /llce.elf bootm7 ${loadaddr} VTABLE I can see the CAN traffic on the bus, so the example is running, but U-boot hangs and is not able to accept commands anymore. After some debugging, I was able to trace the problem to the PlatformInit() call, and in particular the code to set the clock. If I remove that code, however, the example does not work anymore. Do you have any suggestions? Re: LLCE example and U-boot Hello, @GioMusto  Thanks for your reply. Yes, it is for S32G2, not G3, but the method introduced is similar. Since it is based on early version software packages, it could not be considered as a step by step guide when using recent version software combinations. BR Chenyin Re: LLCE example and U-boot Hi @chenyin_h, thanks for your reply. I see the guide you posted is for the S32G2. Is it the same for S32G3, or are there some differences? Do you have any suggestion on things to keep an eye on? Common problems, and so on. Re: LLCE example and U-boot Hello, @GioMusto  Thanks for your post. The issue you mentioned may be caused clock or other resource confliction between M and A side. 1. On S32G product, under default settings, the BSP running on A53 side is designed under the assumption that it has exclusive access to the system, and therefore does not consider potential conflicts introduced by other software components, while in your M core application, it may also touch critical resources like clock/memory, etc. You have to careful about every part of the code, to avoid any possible confliction/re-configuration for critical resources. 2. For running both M7 application and Linux BSP simultaneously, the recommended way is to firstly running a M7 bootloader to manage the resources, as introduced via AN13750  BR Chenyin Re: LLCE example and U-boot I'm trying to build the M7 bootloader by following AN13750 and the "System-Level Bootloader Integration Example for S32G3XX". I managed to compile the bootloader (with some difficulties, since I'm missing the SAF package), but now I'm stuck with the IVT tool in S32DS. When I create a new project, select S32G399A, Cortex-M7_0, and create a configuration, I get the error "IVT tool does not support the current processor. The same is true for DCD, QuadSPI, DDR and eFuse (see screenshot). What am I doing wrong? Re: LLCE example and U-boot Hello, @GioMusto  Thanks for your reply. 1. Commonly, I suggest using S32DS3.5.x(for example, 3.5.14) for working with S32G(mentioned in release notes of S32G RTD release), and make sure that the following packages are installed at least:(RTD and development package) 2. To simplify the process, you may import an example project into the S32DS, and then open the IVT tool, for example: Then have a try if the IVT tool could be used for generating blob based on your own images. BR Chenyin
記事全体を表示
RW612 WiFi Init stuck on HAL_ImuLinkIsUp() I am trying to run the MQTT example on a custom board. The module used is ublox IRIS-W106-30B. I followed the instructions to use j-link to install the wifi fw blob serperatly. However, I am getting stuck in an infinite loop in WPL_Init().   I was also unable to initialize the BLE due to similar issue. SDK 25.09.00 using MCUXpresso  Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Yes, I am able to run my normal application code, log to UART etc.  Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Hi, Are you able to test a simple Hello World example? Also, have you already applied the required modifications to enable your module? Please refer to the following article for guidance. Regards, Daniel. Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() Are you using the RD-RW61X-BGA SDK or the FRDM-RW612 SDK? Which files did you modify to port the original example to your module? Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() If I'm understanding correctly, you're able to run the Wi-Fi and Bluetooth examples on your custom board without any issues. The problem appears when you start integrating or porting the networking functionality into your own application. My recommendation is to use the MQTT example as the foundation for your application. If your use case requires Wi-Fi and BT/BLE to run simultaneously, then it would be better to start from one of the coexistence examples and add your application-specific functionality on top of it, rather than trying to add coexistence support to an existing custom application afterward. By the way, SDK 25.09 is already three releases behind. I would recommend upgrading to the latest SDK 26.06 before continuing. Re: RW612 WiFi Init stuck on HAL_ImuLinkIsUp() SDK_2.x_RW610 From the mqtt example I copied everything from "main_task" and after into my existing project. This leave the hardware init, as a major difference. I am unable to identify which aspects from the example are causing IMU to not initialize.  I can run the base example project on my custom board but am unable to port it into existing project. 
記事全体を表示
S32G-VNP-RDB3: Onchip debugging support Hello, I want to debug my AUTOSAR Operating System based application on following environment. 1) Board Name: S32G-VNP-RDB3 2) Microcontroller Variant: S32G399 3) Cortex-M7 Cores 4) Host: Windows Is there any on-chip debugging support enabled in the mentioned board where I can connect without any external debugger or probe. If on-chip debugging support is not available on this board then can I debug with S32 debug probe (H/W) and s32 design studio IDE (S/W) ? With Regards, Madhusudan Gupta Re: S32G-VNP-RDB3: Onchip debugging support Hello, @madhusudangupta007  Thanks for your post. 1. There is no onchip debugger on RDB3, so it is not supported to directly debug the RDB3 via the USB port. 2. Commonly, the Lauterbach TRACE32 Debug is used for debugging the S32G products, besides, the S32 Debug Probe which is provisioned by NXP(S32 Debug Probe | NXP Semiconductors) is also used. 3. Yes, as mentioned before, the S32 debug probe(HW) and S32 Design Studio(IDE) could be used together for debugging the RDB3 board.    BR Chenyin
記事全体を表示
i2c problems during wakeup frum suspend A question for the experts out there. I have a circuit in which several push-button switches are connected to a GPIO expander. My current system is based on an IMX8MP, to which this GPIO expander is connected via I²C. This expander has an interrupt line to the IMX8MP. Often, when I put the system into suspend mode and press one of the push buttons (the expander is also marked as a wake-up source in the device tree), I receive this message hundreds or even thousands of times as soon as the system comes out of suspend: [ 117.113106] pca953x 3-0076: failed reading register. I know there was already a patch for a similar issue in the i2c-imx.c driver, and I’ve applied it. However, it isn’t having the desired effect. What can I do about this? P.S. It doesn’t happen all the time, but it can be reproduced relatively quickly. Best regards R. Re: i2c problems during wakeup frum suspend I use Kernel Version 6.6.23 Re: i2c problems during wakeup frum suspend Hi @RRD101  Based on your description, it seems like you could try this commit. Also, which kernel version are you using? Best Regards, Zhiming
記事全体を表示
S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way Setup S32K396, no HSE FW ever installed, no secure boot, no ADKP. FS26 with 200ms watchdog What happened I was installing the AB_SWAP pink image over the MU interface 1. Programmed the HSE FW usage flag in UTEST at 0x1B000000. No other UTEST location touched. SBAF had not programmed it itself despite `FW_USAGE_FLAG_PROGRAM` being set in my boot config. 2. Wrote 0xA5 into DCMRWP1 (0x402AC400) bits 31 to 24 and issued a functional reset. 3. Ran the handshake on MU0 ch0: got 0xFF00F00F, replied 0xF0F00F0F, got 0xDADABABA, wrote the pink image address. so SBAF started programming the firmware. 4. Sometime after that, everything halted. Nothing more on the UART console. I power-cycled after ~5 minutes. Since then the board produces no console output at all, and I can no longer debug it the way I normally do: J-Link reports "Locked S32K3xx device detected" and asks for the ADKP. Or reports "Power-up of DAP failed" (See attached file). So I cannot read GPR3, DCMRWP1 or UTEST any more. I never provisioned an ADKP and never requested a life-cycle advance. Questions 1. Could the LC have advanced by itself? 2. Or is this recovery mode? In JTAG recovery mode on a CUST_DEL device, can a J-Link connection present as "locked / password required"? Figure 12 in the HSE_B Firmware Reference manual shows that path as waiting for a debugger without authentication. 3. What can I still test before scrapping the part? Above all: is there any way to read the current LC state over the debug interface when the host core is not released? Or is it possible another debug method using Trace32 would work better? Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way 1) No, it cannot. It can be programmed either by user directly to UTEST (when HSE FW is not used) or with using of HSE service (when HSE FW is used). 2) I don’t think so, although I don’t have experience with J-Link. It is possible "Locked S32K3xx device detected" message Yes, the "Locked S32K3xx device detected" message can be a false positive caused by hardware (typically power) rather than an actual security lock. I would recommend to discuss it with Segger: https://www.segger.com/support/technical-support/ Even the device would be in JTAG recovery mode, if still in CUST_DEL life cycle, you still should be able to connect by debugger, download SW and so. 3) I would try to attach or attach just after POR, possibly erase application SW. Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way What I've noticed now is that the 'RESET_RECOVERY_MODE' bit was not set in the BCW. Could not setting this bit in the BCW explain this behavior? Im a bit confused as to what setting this bit does. Will setting this bit enable recovery mode or disable it? In `Table 119. BCW bit mapping` in the HSE reference manual its written that 'RESET_RECOVERY_MODE' is "Used to disable entry into recovery mode because of consecutive resets. See Disable Entry into Reset Recovery Mode for more detail". Then In the chapter `2.6.1.3.3 Disable entry into reset recovery mode` in the HSE reference manual "Entry into recovery mode" is only true while 'RESET_RECOVERY_MODE == 1 AND DCMRWP1 (SBAF_REC_DIS_FRST or SBAF_REC_DIS_DRST) == 0'.  Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way Thank you for your reply, David. Okay. I have reached out to Segger regarding the possibility of a falsely locked device and am awaiting a response. I connected using the J-Link debugger after a POR while shorting the reset pin. This is the log from that sequence: In this case, the HSE firmware is not installed, nor is the device locked. The error that remains from both scenarios is the DAP error. SEGGER J-Link Commander V9.18 (Compiled Feb 11 2026 16:34:58) DLL version V9.18, compiled Feb 11 2026 16:33:51 Connecting to J-Link via USB...O.K. Firmware: J-Link V10 compiled Jan 30 2023 11:28:07 Hardware version: V10.10 J-Link uptime (since boot): N/A (Not supported by this model) S/N: 50116795 License(s): GDB VTref=4.509V Type "connect" to establish a target connection, '?' for help J-Link>connect Please specify device / core. : S32K396_M7_0 Type '?' for selection dialog Device> Please specify target interface: J) JTAG (Default) S) SWD T) cJTAG TIF>S Specify target interface speed [kHz]. : 4000 kHz Speed> Device "S32K396_M7_0" selected. Connecting to target via SWD ConfigTargetSettings() start ConfigTargetSettings() end - Took 46us InitTarget() start SDA_AP detected Unlocking device if necessary... Device is not locked. Proceeding without the unlock procedure. Checking if debug access is already enabled... Debug access is not enabled yet. Performing enable debug access sequence... Debug access enabled Checking if HSE firmware is installed... HSE firmware not installed Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode Lock step mode enabled InitTarget() end - Took 45.5ms Found SW-DP with ID 0x6BA02477 DPIDR: 0x6BA02477 CoreSight SoC-400 or earlier AP map detection skipped. Manually configured AP map found. AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000) AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user AP[4]: Core found ConfigTargetSettings() start ConfigTargetSettings() end - Took 15us InitTarget() start SDA_AP detected Unlocking device if necessary... Device is not locked. Proceeding without the unlock procedure. Checking if debug access is already enabled... Core already enabled Checking if HSE firmware is installed... HSE firmware not installed Checking if Cortex-M7_0 and Cortex-M7_1 are operating in lockstep mode Lock step mode enabled InitTarget() end - Took 18.2ms Found SW-DP with ID 0x6BA02477 DPIDR: 0x6BA02477 CoreSight SoC-400 or earlier AP map detection skipped. Manually configured AP map found. AP[0]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[1]: APB-AP (IDR: Not set, ADDR: 0x00000000) AP[2]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[3]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[5]: AHB-AP (IDR: Not set, ADDR: 0x00000000) AP[6]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[7]: MEM-AP (IDR: Not set, ADDR: 0x00000000) AP[4]: Skipped ROMBASE read. CoreBaseAddr manually set by user AP[4]: Core found ****** Error: DAP error while reading AIRCR. Error occurred: Could not connect to the target device. For troubleshooting steps visit: https://kb.segger.com/J-Link_Troubleshooting
記事全体を表示
KE1 ECC RAM Single Bit Corrrection Have a few questions regarding ECC. I am currently using the MCM_LMFAR to determine where the ECC triggered a fault and then using that address to read then write back to correct it. Questions: 1. Does the ECC have the ability to autocorrect bits? Or do I really need to perform this read/write to address to correct? 2. If there is not autocorrect, will I need to compensate for byte alignment when performing my read/write correction mechanism? Currently I am performing a 4-byte read/write at the address denoted by the MCM_LMFAR. I feel like this is dangerous as I am not sure the MCM_LMFAR will always show a 4-byte aligned address. Re: KE1 ECC RAM Single Bit Corrrection Hello @sean_dvorscak , Thank you for your post. Could you please let me know which specific device in the KE1 family you are using? This will help me locate the relevant documentation more accurately or perform validation using the same device. BR Celeste Re: KE1 ECC RAM Single Bit Corrrection It's a KE18F512VLH16. Thanks for your help. Re: KE1 ECC RAM Single Bit Corrrection One more question actually. The automatic HW ECC correction functionality is enabled by default? I don't really see any bits in the MCM registers that would suggest it's a feature that can be disabled/enabled. Re: KE1 ECC RAM Single Bit Corrrection Hello @sean_dvorscak , Thanks for your reply. So for your questions: 1. Does the ECC have the ability to autocorrect bits? Or do I really need to perform this read/write to address to correct? ->> Yes, ECC does support hardware correction for single-bit errors. So you should not need a software read/write sequence to obtain corrected data.  2. If there is not autocorrect, will I need to compensate for byte alignment when performing my read/write correction mechanism? Currently I am performing a 4-byte read/write at the address denoted by the MCM_LMFAR. I feel like this is dangerous as I am not sure the MCM_LMFAR will always show a 4-byte aligned address. ->> If implementing an optional scrub, please align the access according to the actual access size or scrub granularity, not blindly to the raw MCM_LMFAR value. Also don't use a fixed 4-byte access unless you first align the address appropriately and confirm the access size is valid. In fact, For multi-bit / non-correctable ECC events , do not assume a read/write can repair the data, you should treat it as data corruption and recover from a known-good source or reinitialize the affected memory as appropriate. Hope it helps. BR Celeste --------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the "ACCEPT AS SOLUTION" button. Thank you! --------------------------------------------------------------------------------------------------------------------- Re: KE1 ECC RAM Single Bit Corrrection Thanks for the confirmation and info. And yes, I am handling uncorrectable bit errors differently. Re: KE1 ECC RAM Single Bit Corrrection Yes, ECC checking/generation is enabled by default after reset. Re: KE1 ECC RAM Single Bit Corrrection Have more follow up questions. Does the hardware correct the data within the Memory Cell, or only on the Read Out Data? Example from AN5335, is the Read-out Data being corrected from 0->1? That would mean we need to write back the corrected value to RAM to actually clear it. We are concerned if the data in the RAM memory cell is not corrected, a single bit error could degrade to a double bit error. Re: KE1 ECC RAM Single Bit Corrrection Hello @sean_dvorscak , I noticed that this thread has already been closed. To help us better track and follow up on this issue, could you please create a new post? Thank you for your cooperation.   BR Celeste
記事全体を表示
[LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S69 Hi, I've been trying to get Zephyr's MCUboot to work on the LPC55XpressoS69 using core 0. I am running the simple Blinky sample application in Zephyr.  Running the application just fine without any errors. However, I've been trying to send a device firmware update (DFU) over UART using mcumgr and for some reason I can't even establish a connection between mcumgr and my device. I keep getting a "NMP timeout." For context, my directory structure looks like the following: | __boards                 |__ lpcxpresso55s69_lpc55s69_cpu0.overlay __ src                |__main.c __sysbuild               |__mcuboot.conf                __mcuboot.overlay __prj.conf __sysbuild.conf My prj.conf looks as follows:   # Enable MCUMGR subsystem and OS/Image management commands CONFIG_MCUMGR=y CONFIG_MCUMGR_GRP_OS=y CONFIG_MCUMGR_GRP_IMG=y # DIRECT SMP over UART CONFIG_MCUMGR_TRANSPORT_UART=y CONFIG_MCUMGR_TRANSPORT_SHELL=n # Dedicate flexcomm0 to SMP — nothing else on the UART CONFIG_CONSOLE=n CONFIG_UART_CONSOLE=n CONFIG_LOG=n CONFIG_SERIAL=y CONFIG_UART_INTERRUPT_DRIVEN=y # Required for SMP UART processing thread CONFIG_NET_BUF=y CONFIG_ZCBOR=y CONFIG_BASE64=y # Required subsystems for DFU CONFIG_FLASH=y CONFIG_IMG_MANAGER=y CONFIG_MCUBOOT_IMG_MANAGER=y # Dependencies for System/Reboot management via DFU CONFIG_REBOOT=y My sysbuild.conf is as follows:   SB_CONFIG_BOOTLOADER_MCUBOOT=y SB_CONFIG_MCUBOOT_MODE_OVERWRITE_ONLY=y My mcuboot.conf looks like    CONFIG_LOG=y CONFIG_MCUBOOT_LOG_LEVEL_INF=y CONFIG_MCUBOOT_SERIAL=y CONFIG_BOOT_SERIAL_UART=y CONFIG_UART_CONSOLE=n   My mcuboot.overlay looks like /* Step 3.4 - Configure button and LED for Serial Recovery */ // zephyr,console = &flexcomm0; // zephyr,uart-mcumgr = &flexcomm0; / { chosen { zephyr,code-partition = &boot_partition; zephyr,uart-mcumgr = &flexcomm0; zephyr,shell-uart = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; / { aliases { mcuboot-button0 = &user_button_3; mcuboot-led0 = &blue_led; }; }; &gpio0 { status = "okay"; }; &gpio1 { status = "okay"; }; &blue_led { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; And finally my lpcxpresso55s69_lpc55s69_cpu0.overlay looks like / { chosen { zephyr,code-partition = &slot0_partition; zephyr,mgmt-smp = &flexcomm0; zephyr,uart-mcumgr = &flexcomm0; }; }; &flexcomm0 { status = "okay"; }; /* Enlarge boot partition to 64KB to fit MCUboot with serial recovery */ &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; When I run the following MCUmgr command, I get back an NMP timeout, as seen below: > mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout So the mcumgr definitely realizes that the port is available (it would deny access otherwise), but it keeps getting timed out. I'm pretty sure this is a config option error. I've tried changing the config options numerous times but nothing quite seems to do the trick. I'm also pretty sure I'm missing some config option somewhere which is crucial for this to work.  I've looked through about as many application notes and user manuals out there as I can. None of them seem to help for my particular case: DFU using Zephyr MCUboot on an LPC55Sxx chip running a Zephyr application. Any help would is appreciated, though it may be best if someone tried it out on their board e.g. LPCXpresso55S69 and confirm they can carry out a UART DFU with any simple program. LPC55S6x LPC55S69-EVK  LPC55xx Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @ZQ2  Since mcumgr echo is already returning NMP timeout, I think you can  verify the MCUmgr UART communication before debugging the MCUboot DFU flow. You can  confirm the following: flexcomm0 is the UART connected to COM11 on the LPCXpresso55S69 board. The application is running normally (not staying in MCUboot serial recovery mode). No console, shell, or log output is sharing the same UART used by MCUmgr. As a quick validation, I would recommend starting from Zephyr's smp_svr sample and verifying that the following command works first: mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" BR Harry Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @Harry_Zhang , Coincidentally, I was using Zephyr's smp_svr sample yesterday immediately after posting this question. I get the same exact problem though. I followed the Zephyr documentation for the sample at the following link. I simply created a project for the sample and then built the code successfully, enabling the configs for the Raw UART (serial) smp_svr option from the docs using the following command, as instructed: west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild -- -DEXTRA_CONF_FILE="raw-serial.conf;fs.conf" And then I flashed the code successfully. Nonetheless: C:\Users\Dev>mcumgr --conntype serial --connstring "dev=COM11,baud=115200" echo "test" Error: NMP timeout   I even tried changing the debugger probe from Link2 to JLink, after which the debug probe became attached to COM16. I also disabled any mass storage device functionality, just in case, using JLink commander. Then I tried flashing and running: > west flash -r jlink but yet again: C:\Users\Dev> mcumgr --conntype serial --connstring "dev=COM16,baud=115200" echo "test" Error: NMP timeout What could I possibly be missing? I assume it has something to do with the configs? If so, I wonder why the Zephyr official sample for smp_svr isn't compatible with the LPC55S69 and requires modification. Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @Harry_Zhang , Your solution does indeed work. In fact, I was able to strip down the command to merely west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" This also worked. Thank you a ton for replicating my problem, it's deeply appreciated. Re: [LPC55S69] Zephyr MCUboot for Device Firmware Update Over UART Not Working with MCUmgr on LPC55S Hi @ZQ2  I was able to reproduce and verify the setup on an LPCXpresso55S69 board. 1. The key point is that MCUmgr must be used together with MCUboot in this configuration. The application is linked to slot0 (not the flash base address), so building and flashing the smp_svr application alone will not work correctly. MCUboot is required to boot and hand over control to the application. 2. i add the overlay file lpcxpresso55s69_lpc55s69_cpu0.overlay in file /c/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards. &boot_partition { reg = <0x00000000 DT_SIZE_K(64)>; }; &slot0_partition { reg = <0x00010000 DT_SIZE_K(160)>; }; &slot1_partition { reg = <0x00038000 DT_SIZE_K(160)>; }; &storage_partition { reg = <0x00060000 DT_SIZE_K(50)>; }; 3. built the project using the following command: west build -p always -b lpcxpresso55s69/lpc55s69/cpu0 --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- -DEXTRA_CONF_FILE="serial.conf" -DEXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" -Dmcuboot_EXTRA_DTC_OVERLAY_FILE="C:/SDK/zephyrproject/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/lpcxpresso55s69_lpc55s69_cpu0.overlay" 4. after built it. you can use command  grep -A20 -B5 "boot_partition" build/mcuboot/zephyr/zephyr.dts 5. and west flash 6. 7. which confirms that the UART transport, SMP server, MCUmgr, and MCUboot integration are all working correctly. BR Harry
記事全体を表示
lx2080(yocto image and debug) i need information regarding how to configure lx2080a nxp image build using yocto and if we want use custom bord  then how to make changes Re: lx2080(yocto image and debug) Layerscape Yocto BSP v26.06: The release includes both source code and prebuilt images as listed below: Source Release files are on https://github.com/nxp-qoriq/yocto-sdk/tree/walnascar-lsdk Branch: walnascar-lsdk Linux BSP Supported boards, Features, Known Issues, please refer to Release Notes Layerscape Software Development Kit User Guide for Yocto: UG10374.pdf Layerscape Linux SDK User Guide: UG10381.pdf Please modify RCW, u-boot, ATF and Linux dts for your custom board, and rebuild images. Porting steps: Modify rcw and rebuild rcw: $ bitbake rcw -c patch -f Go rcw source code folder build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/rcw/git/git/lx2160ardb_rev2/, please modify XGGFF_PP_HHHH_RR_19_5_2/rcw_2200_750_3200_19_5_2.rcw according to your custom board. $ bitbake rcw Modify and rebuild u-boot: $ bitbake u-boot -c patch -f Please go to u-boot source code folder build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/*/git/, modify u-boot source code according to your custom board. $ bitbake u-boot Modify and rebuild atf: $ bitbake qoriq-atf -c patch -f Please go to atf source code folder build_lx2160ardb-rev2/tmp/work/lx2160ardb_rev2-fsl-linux/qoriq-atf/*/git/, please modify atf source code according to your custom board. $ bitbake qoriq-atf Modify Linux dts file and rebuild Linux Kernel: $ bitbake virtual/kernel -c patch -f Please go to Linux Kernel folder build_lx2160ardb-rev2/tmp/work/ lx2160ardb_rev2-fsl-linux /linux-qoriq/*/git, please modify dts file arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts according to custom board. $ bitbake virtual/kernel Re: lx2080(yocto image and debug) for lx2080a  yocto (linux 24.04)image building(rcw->tfa->uboot-linux path) and flashing image via sd card or emmc or norflash   . code warrire tap jtag debugger can we use. 
記事全体を表示
IMX95 failed to reparent can1 I tried to enable can1 my device tree pin is follow imx95 evk, and disable  &micfil IMX95_PAD_PDM_CLK__AONMIX_TOP_CAN1_TX  0x39e IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_CAN1_RX  0x39e , but the following error occurred.  [ 9.968941] CAN device driver interface [ 9.976800] scmi-pinctrl-imx scmi_dev.8: Error set config -13 [ 9.976814] scmi-pinctrl-imx scmi_dev.8: pin_config_set op failed for pin 121 [ 9.976893] clk: failed to reparent can1 to syspll1_pfd1_di: -1 [ 9.978973] Internal error: synchronous external abort: 0000000096000010 [#1] SMP [ 9.978986] Modules linked in: flexcan(+) can_dev neoisp(+) at24 rpmsg_ctrl rpmsg_char pwm_fan enetc4_uio(O) fsl_ecat_enetc4 fsl_ecat_enetc_core moal(O) mlan(O) fuse [ 9.979017] CPU: 5 UID: 0 PID: 357 Comm: (udev-worker) Tainted: G M O 6.18.2-rt3-1.0.0-1.0.0 #1 PREEMPT_RT [ 9.979026] Tainted: [M]=MACHINE_CHECK, [O]=OOT_MODULE [ 9.979028] Hardware name: Axiomtek i.MX95 scm136 board (DT) [ 9.979031] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 9.979035] pc : flexcan_read_le+0x0/0x20 [flexcan] [ 9.979060] lr : flexcan_probe+0x454/0x834 [flexcan] [ 9.979067] sp : ffff800086133820 [ 9.979069] x29: ffff800086133850 x28: ffff8000862b0000 x27: ffff000085a182a0 Does anyone know how to fix this? Re: IMX95 failed to reparent can1 Hi,Zhiming_Liu Thank you for the reply. you are right ,I need to change system manager config. Re: IMX95 failed to reparent can1 Hi @HenryHsu  Here is my previous test on i.MX95 EVK, please check your dts with below modifications.   dts modification:     diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts index ab7bd4fdaadf..5eb3011f0894 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts @@ -380,7 +380,7 @@ &flexcan1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_flexcan1>; xceiver-supply = <&reg_can1_stby>; - status = "disabled"; + status = "okay"; }; &flexcan2 { @@ -623,23 +623,23 @@ spidev0: spi@0 { }; }; -&micfil { - #sound-dai-cells = <0>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&pinctrl_pdm>; - pinctrl-1 = <&pinctrl_pdm_sleep>; - assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>, - <&scmi_clk IMX95_CLK_AUDIOPLL2>, - <&scmi_clk IMX95_CLK_PDM>; - assigned-clock-parents = <0>, <0>, <0>, <0>, - <&scmi_clk IMX95_CLK_AUDIOPLL1>; - assigned-clock-rates = <3932160000>, - <3612672000>, <393216000>, - <361267200>, <49152000>; - status = "okay"; -}; +// &micfil { +// #sound-dai-cells = <0>; +// pinctrl-names = "default", "sleep"; +// pinctrl-0 = <&pinctrl_pdm>; +// pinctrl-1 = <&pinctrl_pdm_sleep>; +// assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>, +// <&scmi_clk IMX95_CLK_AUDIOPLL2>, +// <&scmi_clk IMX95_CLK_PDM>; +// assigned-clock-parents = <0>, <0>, <0>, <0>, +// <&scmi_clk IMX95_CLK_AUDIOPLL1>; +// assigned-clock-rates = <3932160000>, +// <3612672000>, <393216000>, +// <361267200>, <49152000>; +// status = "okay"; +// }; &mu7 { status = "okay"; @@ -960,19 +960,19 @@ IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x4000031e >; }; - pinctrl_pdm: pdmgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e - >; - }; + // pinctrl_pdm: pdmgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_PDM_CLK 0x31e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_PDM_BIT_STREAM_BIT0 0x31e + // >; + // }; - pinctrl_pdm_sleep: pdmsleepgrp { - fsl,pins = < - IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e - IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e - >; - }; + // pinctrl_pdm_sleep: pdmsleepgrp { + // fsl,pins = < + // IMX95_PAD_PDM_CLK__AONMIX_TOP_GPIO1_IO_BIT8 0x51e + // IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x51e + // >; + // }; pinctrl_ptn5110: ptn5110grp { fsl,pins = <     system manager modification: diff --git a/configs/mx95evk.cfg b/configs/mx95evk.cfg index 9250d02..6722097 100755 --- a/configs/mx95evk.cfg +++ b/configs/mx95evk.cfg @@ -389,7 +389,7 @@ SYS ALL # Resources M7P OWNER # CPUs must be first -CAN_FD1 OWNER +// CAN_FD1 OWNER FSB READONLY IRQSTEER_M7 OWNER LPIT1 OWNER @@ -612,6 +612,7 @@ CAMERA5 OWNER CAMERA6 OWNER CAMERA7 OWNER CAMERA8 OWNER +CAN_FD1 OWNER CAN_FD2 OWNER CAN_FD3 OWNER CAN_FD4 OWNER   Result:  
記事全体を表示
i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hello, Hardware: - i.MX8MQ (REV A0), custom board based on EVK design - QSPI NOR: Micron MT25QL256A (32MB, 3.3V, Quad connected) - BSP: Yocto Scarthgap, NXP BSP, U-Boot 2024.04 (u-boot-imx) Goal: Boot the bootloader (SPL + ATF + U-Boot) from FlexSPI NOR flash. Kernel and rootfs remain on eMMC. What works: - U-Boot (loaded to RAM via uuu SDP/SDPV) runs fine - "sf probe" detects the flash correctly: mt25ql256a, 32 MiB - U-Boot can read and write the flash reliably (verified with read-back tests after "sf protect unlock") - Image is built with IMXBOOT_TARGETS = "flash_evk_flexspi" Flash layout (verified by reading back from the chip): 0x000000: FCFB header - "qspihdr check" reports "Found boot config header in Q(F)SPI" tag = 42464346, version = 56010000 0x001000: IVT - d1 00 20 41, entry = 0x007E1000, boot_data = 0x007E0FE0, self = 0x007E0FC0 0x060000: U-Boot proper FIT (d00dfeed), matches CONFIG_SYS_SPI_U_BOOT_OFFS=0x60000 Problem: With boot switches set to QSPI/FlexSPI boot and the USB cable physically disconnected, the board does not boot. Nothing is printed on the serial console (SPL banner never appears), and the ROM falls back to serial download mode: uuu -lsusb 2:1 MX8MQ SDP: 0x1FC9 0x012B NXP FLASH BT_FUSE_SEL is not blown; boot configuration is done via GPIO boot pins. What I have already tried: - Both header formats: scripts/qspi_header (c0ffee01 tag) and scripts/fspi_header (FCFB tag). Fixed soc.mak so that flash_evk_flexspi uses fspi_header with offset 0. - Varying FCFB parameters: sflashA1Size, serialClkFreq (50MHz -> 20MHz), dataSetupTime/dataHoldTime, sflashPadType - "uuu -b qspi" (the official built-in script) - "qspihdr update safe" and "qspihdr init safe" - Erasing the flash completely vs. writing the full image: boot behaviour is essentially identical (SDP appears after ~1.6s vs ~1.8s), which suggests the ROM may not be reading the flash at all. Questions: 1. Does the i.MX8MQ Boot ROM support booting from serial NOR flash over FlexSPI at all? The Reference Manual section I have lists NAND flash and SD/MMC as boot devices, but I could not find FlexSPI/QSPI NOR listed. i.MX8MM/8MN documentation seems to describe it, but I am unsure about 8MQ. 2. If it is supported, what is the exact expected flash layout? Should the IVT be at offset 0x400 or 0x1000 when an FCFB is present at 0x0? 3. What is the correct BOOT_MODE / BOOT_CFG combination to select FlexSPI NOR boot on i.MX8MQ? 4. Are there any known errata for REV A0 silicon regarding FlexSPI boot? Thank you. Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hello, I'm working on a similar task.  Some sections on the same document mentions some boot options using SPI. Would you like to elaborate further please? Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Is there absolutely no way to boot the i.MX8MQ from QSPI NOR Flash while keeping the Linux kernel and root filesystem on eMMC? Our hardware design has already been built around this architecture, so it is very important for us. Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hi, Please refer primarily to the information in the RM; the i.MX8MQ does not support QSPI boot. Best Regards, Zhiming Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Dear NXP Technical Support Team, We would like to raise a serious concern regarding the documentation of QSPI boot support for the i.MX8MQ. Engineers rely on the Reference Manual as the primary and authoritative source when making hardware design decisions. When a boot source is listed or implied as supported in the Reference Manual, it is entirely reasonable for a development team to design the board around that information. This is not a minor typographical mistake. Boot-source selection directly affects schematic design, PCB layout, component selection, manufacturing, firmware architecture, recovery strategy, and product validation. An incorrect statement regarding QSPI boot capability can therefore result in significant engineering time loss, additional prototype revisions, delayed schedules, and substantial financial cost. It is especially concerning that similar questions and feedback appear to have been raised in the NXP community since approximately 2017–2018, while the documentation has apparently remained unclear or incorrect for many years. If NXP has known that the i.MX8MQ Boot ROM does not support direct boot from QSPI, this limitation should have been clearly stated in the Reference Manual, device errata, application notes, and product documentation. Leaving such a critical ambiguity unresolved for years is unacceptable for a component used in professional and commercial hardware designs. Customers must be able to trust the information provided in the official Reference Manual. We therefore request a clear and formal response to the following points: Does the i.MX8MQ Boot ROM support direct boot from QSPI NOR after power-on reset? If it does not, why was QSPI presented or implied as a supported boot option in the Reference Manual? Has NXP officially classified this as a documentation error? In which document revision will this information be corrected? Will NXP publish an erratum or product notice to warn customers who may have designed hardware based on the existing documentation? Is there any officially supported workaround that allows the Boot ROM to load the initial boot image directly from QSPI without requiring SD or eMMC? We strongly believe this issue requires more than an informal forum response. A formal documentation correction and an explicit technical notice are necessary to prevent other engineering teams from experiencing the same time and financial losses. Please escalate this matter to the i.MX8MQ product engineering and documentation teams and provide an authoritative written clarification. Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hello @Zhiming_Liu, @ayse-yilmaz  I've found the following topic related to this very problem: https://community.nxp.com/t5/i-MX-Processors/Does-i-MX8M-support-boot-from-QSPI/m-p/904429#M136467 But as a solution, tech support mentioned "for development purposes, the eFUSEs used to determine the boot device may be overridden using the GPIO pin inputs" but boot ROM does not support it anyway. I'm a bit confused here. Why even though the HW supports it, boot ROM doesn't? I guess it's impossible to boot from QuadSPI despite of the HW and the documents, due to ROM. Is my understanding right? Please kindly elaborate.  Thx, Onur Regards Re: i.MX8MQ: Does the Boot ROM support booting from FlexSPI/QSPI NOR flash? Hi @ayse-yilmaz @onur-goksu  Issues with the documentation in Chapter 6  SNVS, Reset, Fuse, and Boot were already reported in 2018, and NXP corrected the relevant documentation on its official website.  For the supported boot device, should refer the 6.1 System boot. About 1.6 Primary Boot Options, it looks like a document residue. Best Regards, Zhiming
記事全体を表示
S32K1 Complementary PWM Hi,NXP experts We used the S32K142 chip in the air conditioning compressor project of Nissan. However, Nissan requested to know how the FTM of the chip ensures the achievement of complementary PWM output. Therefore, they would like to ask for assistance in providing explanations and supporting materials, or test reports for the verification of this function. Thank you. Re: S32K1 Complementary PWM Hi@Chenxu1 the chip-level protection is mainly architectural: one channel defines the PWM timing, the companion channel is produced by internal complement logic, and optional dead-time/synchronized-update hardware preserves non-overlap and coherent updates. S32K-RM Rev14.1: Re: S32K1 Complementary PWM Hi, Senlent, Tkx for your reply. We are clear about how FTM outputs complementary PWM. At the chip level, how does it ensure that the complementary waveforms are not out of position? This is what our customers are interested in knowing. Re: S32K1 Complementary PWM Hi@Chenxu1 It can read and test AN5303 and its provided bare-metal code. https://www.nxp.com/docs/en/application-note/AN5303.pdf These are some steps I recorded during my previous testing, for your reference. I set up complementary PWM mode and inserted a 2µs dead time (I forgot to save the complete project, but the modification is very simple).
記事全体を表示
EasyEVSE signal board compatibility and availability I’m standing up an EasyEVSE development system and I have a few questions.   From the code revision history (and the 6 May 2026  vs. Dec 2025 versions of CCEVCPGSUG.pdf), it looks it looks like in software version 5.1.2  that support for EVSE-SIG-BRD2X has been removed and the expectation is that the EVSE side will use SIGBRD-HPGP instead.  Is this correct? It looks like software v5.1.2 added much of the support for SIGBRD-HPGP, does the previous version (v5.0.8) still support EVSE-SIG-BRD2X? Is the SIGBRD-HPGP available?  I don’t see it at mouser or digikey, or in NXP’s store. I have two of the EVSE-SIG-BRD2Xs and I’d like to move forward as the SIGBRD-HPGP appears to not be an option right now. Any insights would be appreciated Best Regards,               Chris Re: EasyEVSE signal board compatibility and availability Hi @chrisedwards, As you mention, the updated EVSE platform is designed to leverage the SIGBRD-HPGP on the EVSE side. Currently, the EV side still supports EVSE-SIG-BRD2X, although it can also be implemented using SIGBRD-HPGP. However, considering that you already have both EVSE-SIG-BRD2Xs, and that the SIGBRD-HPGP is still under qualification process (and will likely take some more time for it to be available for the public), I recommend you stick to this setup, and consider the use of a previous SW version before this latest modification. You should be able to use v5.0.8 for support with the two EVSE-SIG-BRD2X setup. BR, Edwin. Re: EasyEVSE signal board compatibility and availability Hi Edwin,  Thank you for your response.  I'm back working on this and am having issues getting EVSE code v5.0.8 that i got from Git to work.  It builds fine and displays the GUI, but when I try to use its debug interface and request the version information, I get a correct response for the 1060 code of 5.0.8, but the version of the sigbrd2x shows as hw: v 255, and sw: v255.255.0.  I seem to recall reading a post that said there was some issue with a communications conflict with the LCD display on the 1060 board.  I can program the sigbrd2x and step code, so I'm pretty confident that that side is executing.  I'm using the EVSE-RT106X-CBL rather than the arduino headers.  My primary symptoms are the version reporting above that seems suspect, and I can't get past the "firmware download" status on the EVSE LCD, and the EVSE code on the 1060 won't start if the sigbrd2x is powered up (I'm powering them separately).  It feels like a communications issue.  Is there a patch / workaround for this?  If so, can you point me to documentation on how to resolve it? Best Regards, Chris Edwards
記事全体を表示
Flashing Issue on IMX95EVK's M7 core Hello, I am trying to run an M7 application on IMX95LPD5EVK-19 following AN14748, but I cannot flash flash.bin with UUU. The board is detected briefly, then SDPS boot fails immediately. Hardware: IMX95LPD5BB-19 REV A1 (2024 NXP B.V.) Boot switch (SW7[1:4]): 1001 (Serial Download) Target: eMMC Host: Ubuntu Linux UUU: libuuu_1.5.243-0-g230f1b1 SDKs tried (MCUXpresso SDK Builder): SDK_26.06.00_IMX95LPD5EVK-19 SDK_2.15.000_IMX95LPD5EVK-19 Both produce the same result. Command: cd IMX95LPD5EVK/build_/tmp/deploy/images/imx95-a1-19x19-lpddr5-evk sudo uuu -b emmc flash.bin   Error: Success 0 Failure 1 1:2-E3C50910 1/ 1 [HID(W): LIBUSB_ERROR_NO_DEVICE (-4)] SDPS: boot -f flash.bin   Steps followed (per AN14748): Set SW7 = 1001 with board powered off Connect USB to host Run sudo uuu -b emmc flash.bin Power-cycle board Fails at SDPS boot every time Please share the steps to flash and the BSP version supported for M7 core for this version of the board. Re: Flashing Issue on IMX95EVK's M7 core Hello, The latest supported BSP for A1 revision is Linux 6.12.20. Also, you could try to build the the whole binary from scratch (Uboot+SPL+ATF+Firmware+M-SDK). #### Download and extract ARM GCC toolchain #### $ sudo tar -xvJf arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt $ sudo tar -xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz -C /opt #### Get NXP code necessary for the i.MX95 #### In your case be careful with the latest supported BSP version.  $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-sm -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/imx-oei -b lf-6.18.2-1.0.0 $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.18.2-1.0.0 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.5-29313e0.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.31-4fa5b46.bin #### Build Uboot #### $ cd uboot-imx $ make -j $(nproc --all) clean $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- imx95_19x19_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build ATF #### $ cd .. $ cd imx-atf $ make -j $(nproc --all) PLAT=imx95 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- #### Build SM #### $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk cfg (optional if the associated mx95evk.cfg file has been changed) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95evk all (Linux+M7) $ make -j $(nproc --all) TOOLS=/opt/ config=mx95alt all (config for MCUXpresso testing) #### Build OEI #### $ cd .. $ cd imx-sm $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=ddr DEBUG=1 $ make -j $(nproc --all) TOOLS=/opt/ board=mx95lp5 oei=tcm DEBUG=1 (for i.MX 95 A1 only) #### Extract Firmware #### $ cd .. $ chmod +x firmware-ele-imx-2.0.5-29313e0.bin $ ./firmware-ele-imx-2.0.5-29313e0.bin --auto-accept $ chmod +x firmware-imx-8.31-4fa5b46.bin $ ./firmware-imx-8.31-4fa5b46.bin --auto-accept #### M7 SDK compilation #### $ unzip SDK_25_12_00_IMX95LPD5EVK-19.zip $ python3 -m venv .venv $ source .venv/bin/activate $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi $ pip install west $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config release -b imx95lpd5evk19 -Dcore_id=cm7 #### For ITCM #### $ west build -p always examples/demo_apps/hello_world --toolchain armgcc --config ddr_release -b imx95lpd5evk19 -Dcore_id=cm7 #### For DDR #### $ exit (this will close the terminal so re-open the terminal) #### Copy the resulting binaries to imx-mkimage #### $ cd imx-mkimage $ cp ../uboot-imx/u-boot.bin ./iMX95 $ cp ../uboot-imx/spl/u-boot-spl.bin ./iMX95 $ cp ../imx-atf/bl31.bin ./iMX95 $ cp ../imx-oei/oei-m33-ddr.bin ./iMX95 $ cp ../imx-sm/m33_image.bin ./iMX95 $ cp ../mcuxsdk/build/hello_world_cm7.bin ./iMX95/m7_image.bin $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_dmem_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_qb_v202409.bin ./iMX95 $ cp ../firmware-imx-8.31-4fa5b46/firmware/ddr/synopsys/lpddr5_imem_v202409.bin ./iMX95 $ cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 $ make SOC=iMX95 OEI=YES flash_all You may use the resulting binary to flash your EVK, we tested this in standalone mode and it is working correctly. Best regards. Re: Flashing Issue on IMX95EVK's M7 core if boot from EMMC, SW7-3 should be 1 according to Quick Start Guide IMX95LPD5EVK-19 Re: Flashing Issue on IMX95EVK's M7 core Hello, Thank you for the update. Please try with sudo command. Best regards. Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas  I have followed the exact steps given by you. But there is a same flashing error. It goes till 60% and failed after sometime. Can you please check the below screenshots and let me know whether the commands are right. Thanks, Gaurav Re: Flashing Issue on IMX95EVK's M7 core why there is usb error no device?does it happen at 60% booting process? Re: Flashing Issue on IMX95EVK's M7 core Hello, I found a new resource that suggest use Linux 6.12.3_1.0.0/SDK25.03.00 for A1 silicon revision, please try again with this software versions. What do you see in Cortex-A console when you see the error log? Best regards. Re: Flashing Issue on IMX95EVK's M7 core And I am working on the lf-6.12 version for all the repos. Switch position for download mode is "1 0 0 1" Can you please also confirm the supported version of M7 SDK? Re: Flashing Issue on IMX95EVK's M7 core can this issue be reproduced as failed at 60% process all the time? Re: Flashing Issue on IMX95EVK's M7 core Hi @db16122 , Thanks for replying. Yes while flashing the firmware it is getting failed gets stuck at 60% for sometime and getting failed after that.  Thanks, Gaurav C. Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas , I have tried with sudo command as well but there is no change and it is still failing. Please check the below screenshot. Thanks, Gaurav C. Re: Flashing Issue on IMX95EVK's M7 core Yes, it is happening everytime. Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas  I have tried with SDK 25.03 and i am only getting some failure logs on /dev/ttyUSB3 while flashing the binary. I have also copied the file like below. cp ../firmware-ele-imx-2.0.5-29313e0/mx95b0-ahab-container.img ./iMX95 Do you think there exists a file for mx95a1-ahab-container.img as well? Please also go through the screenshot, it is showing the SOC IMX95(A0) while I am having A1 revision. Thanks Gaurav Re: Flashing Issue on IMX95EVK's M7 core Hi @JorgeCas  I am able to resolve this issue using document AN14748 and SDK25.03.00  Thanks for your suggestions and valuable time. Thanks, Gaurav
記事全体を表示
I am Using S32K312 and I want to Create New NVM key Catlog with my HSE Firmware I want to store 1 public key of 64 bytes in NVM key Catlog of HSE, but when I am trying to write into the Catlog I am facing issue as HSE_SRV_RSP_NOT_ALLOWED   (brief The operation is not allowed because of some restrictions (in attributes, life-cycle dependent operations, key-management, etc.).   Can you please guide me what should be done in this case ? Re: I am Using S32K312 and I want to Create New NVM key Catlog with my HSE Firmware Hi @Amolniwate  How you are configuring the key catalog? Also, if you have User rights, plain keys can only be imported authenticated. If you have SuperUser rights, the behavior depends on whether the slot is empty or already programmed: Empty slots: Plain key can be imported , with or without authentication. Non-empty slots: Plain/Encrypted key can only be imported (overwritten) authenticated. You can refer to Tables 47 and 48 in the HSE_B Firmware Reference Manual, Rev. 2.7 for more details. BR, VaneB
記事全体を表示
i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? Hello NXP Team, we created the SDRAM configuration for our custom i.MX RT1170 based hardware using the MCUXpresso SDK example as a reference: https://github.com/nxp-mcuxpresso/mcuxsdk-examples/blob/main/_boards/evkbmimxrt1170/demo_apps/shell/shell.mex Our design uses an ISSI IS42S16320F SDRAM connected to the SEMC interface. Unfortunately, we are experiencing occasional system instabilities with this configuration. While reviewing the SDRAM settings in detail, we noticed that Auto-Refresh appears to be disabled in the example configuration: This surprised us, because according to our understanding the IS42S16320F requires periodic refresh cycles to maintain data integrity, and therefore we would expect Auto-Refresh to be enabled. Could you please clarify the following points? Is it correct that Auto-Refresh is intentionally disabled in the provided SDK example? If so, what is the rationale behind this configuration? Are SDRAM refresh cycles handled elsewhere by the SEMC controller or software initialization code? For an ISSI IS42S16320F on a custom hardware design, would you recommend enabling Auto-Refresh explicitly? Thank you for your support. Best regards, i.MXRT 101x Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? Hello @Masmiseim, The DCD configuration provided in the example is implemented for the SDRAM used on the RT1170-EVKB. As you may know, each SDRAM device has its own timing requirements and initialization parameters, so the SEMC configuration included in the example may not be fully compatible with your specific SDRAM. In this example, the Auto Refresh feature is enabled as part of the final SDRAM initialization sequence. However, during the initialization process itself, the Auto Refresh bit remains disabled and the required refresh operations are performed through SEMC IP commands, as shown in the images below: If you would like to customize these settings for your SDRAM, the DCD can be generated using the MCUXpresso Config Tools. This allows you to configure the SDRAM parameters according to your device requirements, as illustrated in the following image:   On the other hand, there is available an SDK (version 26.06) example called "semc_cm7" which demonstrates how use the SEMC peripheral with an external SDRAM. Finally, in this community post Omar provides an example for configure the SEMC registers that could be useful. BR Habib Re: i.MX RT1170 SDRAM Configuration from SDK Example: Auto-Refresh Disabled? It's always wise to treat anything you attempt to use from the SDK as just an example and therefore you should check & verify everything.
記事全体を表示
i.MX8MM eMMC sd3 clk dse en slew rate setting The above mentioned pad control settings are not described in the reference manual. Why and how can we test / trim these settings? Re: i.MX8MM eMMC sd3 clk dse en slew rate setting Hello @NLFOHE  Hope you are doing very well. Actually, that pad is under the register's name: IOMUXC_SW_PAD_CTL_PAD_NAND_WE_B. Mux mode register should be configured as uSDHC3 (IOMUXC_SW_MUX_CTL_PAD_NAND_WE_B): Best regards, Salas. Re: i.MX8MM eMMC sd3 clk dse en slew rate setting Hello Salas, Issue not yet solved due holiday period. Is there any application note how to use SCC on this specific clock signal?
記事全体を表示