Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
GPIO Based on the S32K324 MCU, how to configure a GPIO to high‑impedance state using S32DS. Re: GPIO Hi Please refer to previous similar discussions: S32K3 GPIO HIGH-Z If the pin may have previously enabled internal pull, in order to satisfy the tristate definition in S32K3XXRM, Siul2_Port_Ip_SetPullSel(..., PORT_INTERNAL_PULL_NOT_ENABLED) should be called to ensure PUE=0; Best Regards, Robin
View full article
Query Regarding PCA9450CHN Voltage Configuration Through I2C We are using the PCA9450CHN PMIC and understand that it powers up with default regulator voltages, which can be modified through I2C programming. Could you please explain the complete sequence for changing these voltages after power-on, including when the SoC starts communicating with the PMIC? Also, please let us know the recommended debugger or tools to monitor and verify the PMIC register programming and voltage changes. Board Design HW-Open-Source Re: Query Regarding PCA9450CHN Voltage Configuration Through I2C guoweisun_0-1786078934821.png You can refer to above after the POR_B signal pull high and the PCA9450C enter into RUN mode you can change its power rails output value.
View full article
S32K566 LPUART Communication Issue Hi, I am using the Uart_Example_S32K566_M7 module on the S32K566 microcontroller with an LPUART module clock of 50 MHz. I configured the baud rate to 115200 and am sending 0xAA data to the PC using a UART-to-USB converter. However, the received data is incorrect (0x00 0x80 0x80). When I configure the baud rate to 115200/8 = 14400, the data is received correctly. I also tried different baud rates such as 9600 and 19200. I am using S32DS 3.6.6 and SDK 0.8.0. Uart_Example_S32K566_M7 source code also attached here please find.  I have attached the configuration and received data screenshots for reference. Manikandan_Aruchamy_0-1786092514163.png Receiver terminal window baud rate is 115200: Manikandan_Aruchamy_1-1786092584169.png Receiver terminal window baud rate is 14400: Manikandan_Aruchamy_2-1786092633034.png Re: S32K566 LPUART Communication Issue Hello @Manikandan_Aruchamy , I hope this email finds you well. I am writing to you in regard to a product currently in your possession – an NPI (New Product Introduction) which has not been officially launched yet. Please be advised that customers who have been granted early access to such products have assigned their field engineers. Your designated field engineer should serve as your primary support channel for any issues, concerns or queries you may have about this product. Our online support team will be opening a wider range of support for this product once it has been officially released. Until then, we will not be equipped to provide the desired assistance. Thank you for your understanding. Best regards, Pavel
View full article
The SPI duty cycle of S32K322 is not 50% for 8MHz Dear NXP team,           We are working on an improvement activity where we need to have the 8MHz SPI SCLK to be periodic within SPI transactions. We measured the SPI SCLK for 8MHz (which is driven by the SPI peripheral driver in S32K322) and found that 50% duty is not maintained. When we lower the frequency to 1/2/4 MHz we see 50% duty being maintained for those SCLK frequencies.  Question - Is this any Hardware limitation of the Peripheral driver or by changing the driver settings, desired 50% duty can be obtained for 8MHz? PFA the screenshots where duty is maintained for 1MHz and not for 8MHz Note: We have connected Logic Analyzer from Saleae that has higher sampling resolution (250MS/s) to measure the SPI signals Re: The SPI duty cycle of S32K322 is not 50% for 8MHz Hi, the LPSPI clock duty cycle is determined by the SCKSET and SCKHLD timing parameters. A 50/50 duty cycle is only obtained when these fields are programmed to equal values. Depending on the selected LPSPI functional clock and the divider values required to generate 8 MHz, an exact 50/50 duty cycle may not be achievable due to the timing resolution of the clock generator. The observed 76 ns / 48 ns high-low times appear consistent with such divider quantization effects. PetrS_0-1786090730852.png So, try to calculate the expected duty cycle from your LPSPI functional clock frequency, TCR[PRESCALE], and the contents of the CCR/CCR1 registers (SCKSET, SCKHLD, SCKDIV), and determine whether a different clock source or divider configuration could achieve a duty cycle closer to 50/50.   BR, Petr
View full article
IW612 working on IMX95-19x19 EVK board based on Android 16 In default, IMX95-19x19 EVK board enables the PCIe M.2 interface for Wi-Fi modules. But for SDIO interface M.2 Wi-Fi module, we could not use it directly. This doc is a step by step guide about how to make IW612 SDIO M.2 module(Murata 2EL) working on IMX95-19x19 EVK board based on Android 16. 1.Download I.MX Android BSP package, copy with scp to VMSIS. 16.0.0_1.4.0_ANDROID_SOURCE 2.Decompressing android bsp tar -xzf imx-android-16.0.0_1.4.0.tar.gz 3. source ./imx_android_setup.sh to download Android source code. 4.Prepare cross compiler GCC cross compiler: Download the tool chain for the AArch32 and AArch64 on: Arm GNU Toolchain I download the latest version: Arm GNU Toolchain 15.3.rel1 Need to pay attention, for I.MX95, need both 64 bit and 32 bit GCC compile tool. 64bit: arm-gnu-toolchain-15.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz 32 bit: arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi.tar.xz For AArch64 toolchain nxf93258@lsv051430:~/GCC_cross_compile_toolchain$sudo tar -xvJf arm-gnu-toolchain-15.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt/ nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$export AARCH64_GCC_CROSS_COMPILE=/opt/arm-gnu-toolchain-15.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- For 32bit toolchain: nxf93258@lsv051430:~/GCC_cross_compile_toolchain$sudo tar -xvJf arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi.tar.xz -C /opt/ nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ export AARCH32_GCC_CROSS_COMPILE=/opt/arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi- 5.Set the external clang, kernel-build-tools, rust, and clang-tools tools for kernel building: nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ sudo ./device/nxp/common/tools/setup_android_kernel_prebuilts.sh 6.Set up the environment for building. This only configures the current terminal, if change to another terminal need to re-run the configurations. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ source build/envsetup.sh 7.Execute the Android lunch command for i.MX95-EVK. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$lunch evk_95-nxp_stable-userdebug 8.Optional Steps: Execute the imx-make.sh script to finish the whole images compiling. Or you can follow below steps to only build required images. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ ./imx-make.sh -j4 2>&1 | tee build-log.txt 9.Modify the device tree to disable pcie0 and enable usdhc3 like below: ~/Android/imx-android-16.0.0_1.4.0/android_build/vendor/nxp-opensource/kernel_imx/arch/arm64/boot/dts/freescale$ git diff diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts index 69508a66f1c8..dfa1d3d51a9c 100644 --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts @@ -26,10 +26,19 @@ / { aliases { mmc0 = &usdhc1; mmc1 = &usdhc2; + mmc2 = &usdhc3; serial0 = &lpuart1; ethernet0 = &enetc_port0; ethernet1 = &enetc_port2; }; + + usdhc3_pwrseq: usdhc3_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usdhc3_pwrseq>; + post-power-on-delay-ms = <100>; + }; + bt_sco_codec: audio-codec-bt-sco { #sound-dai-cells = <1>; @@ -651,7 +660,7 @@ &pcie0 { reset-gpio = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>; vpcie-supply = <&reg_pcie0>; supports-clkreq; - status = "okay"; + status = "disable"; }; &pcie1 { @@ -733,6 +742,22 @@ &usdhc2 { status = "okay"; }; +&usdhc3 { + pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; + pinctrl-0 = <&pinctrl_usdhc3>; + pinctrl-1 = <&pinctrl_usdhc3_100mhz>; + pinctrl-2 = <&pinctrl_usdhc3_200mhz>; + pinctrl-3 = <&pinctrl_usdhc3>; + mmc-pwrseq = <&usdhc3_pwrseq>; + vmmc-supply = <&reg_pcie0>; //Both PCIE0 and USDHC3 use same power supply. + bus-width = <4>; + keep-power-in-suspend; + non-removable; + wakeup-source; + status = "okay"; +}; + + &enetc_port0 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enetc0>; @@ -1225,6 +1250,45 @@ IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e >; }; + + pinctrl_usdhc3_pwrseq: usdhc3pwrseq { + fsl,pins = < + IMX95_PAD_XSPI1_SCLK__GPIO5_IO_BIT9 0x31e + >; + }; + + pinctrl_usdhc3: usdhc3grp { + fsl,pins = < + IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e + IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e + IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e + IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e + IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e + IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e + >; + }; + + pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp { + fsl,pins = < + IMX95_PAD_SD3_CLK__USDHC3_CLK 0x158e + IMX95_PAD_SD3_CMD__USDHC3_CMD 0x138e + IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x138e + IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x138e + IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x138e + IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x138e + >; + }; + + pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp { + fsl,pins = < + IMX95_PAD_SD3_CLK__USDHC3_CLK 0x15fe + IMX95_PAD_SD3_CMD__USDHC3_CMD 0x13fe + IMX95_PAD_SD3_DATA0__USDHC3_DATA0 0x13fe + IMX95_PAD_SD3_DATA1__USDHC3_DATA1 0x13fe + IMX95_PAD_SD3_DATA2__USDHC3_DATA2 0x13fe + IMX95_PAD_SD3_DATA3__USDHC3_DATA3 0x13fe + >; + }; }; &thermal_zones { 10.Build dtbo image. Need about 40 minutes. DTBO image holds the device tree binary of the board. nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ source build/envsetup.sh nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$ lunch evk_95-nxp_stable-userdebug nxf93258@lsv051430:~/Android/imx-android-16.0.0_1.4.0/android_build$./imx-make.sh dtboimage -j4 Then you will see that the dtbo images time stamp are updated as below: Christine_Li_0-1786168405295.png Below info is for your reference. ~/Android/imx-android-16.0.0_1.4.0/android_build/device/nxp/common/build/dtbo.mk This makefile includes the logic how to pack dtbo image. ~/Android/imx-android-16.0.0_1.4.0/android_build/device/nxp/imx9/evk_95/SharedBoardConfig.mk Christine_Li_1-1786168463709.png  This Macro: SUPPORT_GBL is not enabled in default, so still use dtbo image for the device tree. ~/Android/imx-android-16.0.0_1.4.0/android_build/device/nxp/imx9/evk_95/BoardConfig.mk Christine_Li_2-1786168477241.png  Wi-Fi/Bluetooth FW located here: Christine_Li_3-1786168507234.png  Wi-Fi/Bluetooth driver located here: Christine_Li_4-1786168518852.png Can modify the Makefile accordingly if needed. After compiled, the Wi-Fi driver and cfg80211.ko is located here: Christine_Li_5-1786168540709.png 11.Download prebuilt Image and decompress it. 16.0.0_1.4.0_DEMO_95//Pay attention to the version, need to match with our Android Source code download version. 12.Replace dtbo image. Rename the original dtbo-imx95.img to dtbo-imx95_original.img in the prebuilt image directory to be a backup. Then copy the dtbo-imx95.img from the remote android source code compiled directory: ~/Android/imx-android-16.0.0_1.4.0/android_build/out/target/product/evk_95/dtbo-imx95.img to the prebuilt image directory. Like below: Christine_Li_6-1786168893998.png 13.Flash images into board. Change the I.MX95-19*19-EVK board's SW7 to 1001 (from 1-4 bit) to enter serial download mode, then connect the board's USB1 port with type C cable to Windows PC. Download the UUU binary file from GitHub: Releases · nxp-imx/mfgtools Open the cmd interface in administrator mode, and enter to the prebuilt image directory. Flash the images into I.MX95-19*19-EVK board with below command: uuu_imx_android_flash.bat -f imx95 -a -e -u trusty-dual For the details of each parameter, can refer to: Android Quick Start Guide 14.Verify Wi-Fi and Bluetooth functions. After flash finished successfully, power off the board and change the board's SW7 to switch the board back to 1010 (form 1-4 bit) to enter eMMC boot mode. Check dmesg logs to confirm IW612 Wi-Fi driver is loaded successfully: Christine_Li_7-1786169134244.png   Check Wi-fi and Bluetooth work as expected in UI.  Can use this application: scrcpy on windows instead of connecting a LCD. Christine_Li_8-1786169192905.png Christine_Li_9-1786169200898.png This guide can also be a reference for other M.2 Wi-Fi modules with SDIO interface working on I.MX95 19*19-EVK board with Android or Linux OS. Reference: Android Quick Start Guide Android User's Guide Linux-Kernel Archive: [PATCH V3 2/3] arm64: dts: imx95-15x15-evk: Disable PCIe bus in the default dts Finished by Christine.Li. Aug 5 2026.
View full article
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.
View full article
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 ErikaC_0-1780606331928.png ErikaC_0-1785342135078.png 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. ErikaC_1-1780606357974.png 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. ErikaC_0-1785263036476.png   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. ErikaC_1-1785263096789.png 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. ErikaC_0-1785352884818.png 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 ErikaC_0-1785340210113.png 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. ErikaC_0-1785341778973.png   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. ErikaC_1-1785341802204.png   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. ErikaC_4-1780606435484.png 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. ErikaC_0-1780606934177.png   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. ErikaC_5-1780606454839.png     ErikaC_6-1780606463739.png   ErikaC_7-1780606471571.png   ErikaC_8-1780606485773.png 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. ErikaC_9-1780606500895.png   ErikaC_10-1780606511051.png   I2C
View full article
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
View full article
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? IVT_error.png 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) chenyin_h_0-1786010049364.png 2. To simplify the process, you may import an example project into the S32DS, and then open the IVT tool, for example: chenyin_h_1-1786010241259.png Then have a try if the IVT tool could be used for generating blob based on your own images. BR Chenyin
View full article
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().   natered21_0-1785877418073.png 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. 
View full article
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
View full article
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
View full article
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
View full article
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. sean_dvorscak_0-1785962043300.png 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
View full article
[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 Harry_Zhang_2-1786007232854.png 5. and west flash 6. Harry_Zhang_0-1786007007588.png 7. Harry_Zhang_1-1786007044209.png which confirms that the UART transport, SMP server, MCUmgr, and MCUboot integration are all working correctly. BR Harry
View full article
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. 
View full article
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:     Zhiming_Liu_2-1785995739657.png 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: Zhiming_Liu_3-1785995783165.png  
View full article
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? onurgoksu_0-1785737312799.png onurgoksu_1-1785737654143.png 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. Zhiming_Liu_0-1785725904605.png 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
View full article
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. Chenxu1_0-1785987344020.png 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: Senlent_0-1785999338085.png 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 Senlent_0-1785997622463.png 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). Senlent_3-1785997707326.png Senlent_1-1785997665931.png Senlent_2-1785997677611.png
View full article
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
View full article