Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
i.MX8M Plus - ディスプレイとカメラ専用のI2Cポート チームの皆さん、こんにちは。 ディスプレイとカメラ専用のI2Cポートがあるかどうか確認したかっただけです。 (例えばディスプレイ用のI2C2やカメラ用のI2C4のような)設定に制限はありませんか?ディスプレイとカメラのインターフェースに任意のI2Cを使えますか? Re: i.MX8M Plus - Dedicated I2C for Display and Camera i.MX8M Plusでは、ディスプレイ関連やカメラ関連デバイス用に利用可能な任意のI2Cコントローラーを使用できます。SoC内部には、専用の「カメラI2C」や「ディスプレイI2C」は搭載されていません。選択はハードウェア設計とデバイスツリー構成によって決まります。
查看全文
通过禁用 i.MX95 上的 CPU/GPU/VPU 来降低功耗 您好,NXP, 我们正在寻找降低基于 i.MX95 的系统整体功耗的方法。 请问您能否帮忙解答以下问题? 是否可以在不需要时完全关闭单个 CPU 核心的电源? 如果我们的应用程序不使用 GPU 和 VPU,是否可以完全关闭它们? 如果不需要使用 CPU/GPU/VPU,是否可以在启动后默认禁用它们以进一步降低功耗?(通过设备树?) 是否有推荐的软件配置或参考文档可以实现最低的功耗? 我们的电路板支持包 基于 Yocto 5.2 / Linux 6.12.x。 谢谢。 顺祝商祺! 肖恩 Linux
查看全文
Debug authentication Response for MCXW72 I am trying to unlock the debug port on the MCXW72. Unlocking it with the MCUXpresso Secure Provisioning Tool works correctly, but I am attempting to unlock the port using my own application based on the Debug Credential (DC), the DCK private key, and the DAC received from the device. The documentation is very unclear in this area (and in some places even incorrect). As I understand it, the DAR consists of: DAR = DC + AB + UUID (from DAC) + Signature (Figure 50 in the Reference Manual shows the UUID and AB fields in the wrong order.) I would like to calculate the Signature using OpenSSL, however I cannot determine exactly what data should be signed: a) DC + CV (from DAC) b) DC + AB + CV (from DAC) c) DC + AB + UUID (from DAC) + CV (from DAC) or something else entirely? The documentation states that the signature binds the DAR to the challenge vector (CV), but it does not clearly specify the exact byte sequence that must be hashed and signed. Could you please clarify the precise data that is used to generate the DAR signature? MCXA Security(Edgelock | secure boot | OTP) Re: Debug authentication Response for MCXW72 Hi @Surdej  Secure Provisioning Tool is built on top of Secure Provisioning SDK, see https://spsdk.readthedocs.io/en/latest/ This is open source so you can find the answers there.
查看全文
iMX95 动态随机存取存储器(DRAM) 速度 您好, 目前的 iMX95 最高只能支持 6.4Gbps 的传输速率。 NXP 是否会发布支持 LPDDR5X 且速度高达 8.5Gbps 的处理器? 谢谢。 Re: iMX95 DRAM speed 嗨@pengyong_zhang , 请问可以提供一下型号名称吗?初步规格说明是什么? 谢谢。 Re: iMX95 DRAM speed 嗨@simonng imx95 之后的芯片将支持 LPDDR5X 8533MT/s 内存。 BR
查看全文
调试 MCXW72 的身份验证响应 我正在尝试解锁 MCXW72 上的调试端口。使用 MCUXpresso 安全配置工具解锁端口可以正常工作,但我正在尝试使用我自己的应用程序,该应用程序基于从设备接收的调试凭证 (DC)、DCK 私钥和 DAC 来解锁端口。 这方面的文档非常不清楚(有些地方甚至有错误)。 据我了解,DAR 由以下部分组成: DAR = DC + AB + UUID(来自 DAC)+ 签名 (参考手册中的图 50 显示 UUID 和 AB 字段顺序错误。) 我想使用 OpenSSL 计算签名,但我无法确定应该对哪些数据进行签名: a)直流 + 恒压(来自数模转换器) b) DC + AB + CV(来自 DAC) c) DC + AB + UUID(来自 DAC)+ CV(来自 DAC) 或者完全是其他原因? 文档指出,签名将 DAR 与挑战向量 (CV) 绑定,但并未明确指定必须进行哈希和签名的确切字节序列。请问能否详细说明用于生成DAR特征的具体数据? MCXA 安全(Edgelock | 安全启动 | OTP) Re: Debug authentication Response for MCXW72 嗨@Surdej 安全配置工具基于安全配置 SDK 构建,请参阅https://spsdk.readthedocs.io/en/latest/ 这是开源软件,所以你可以在那里找到答案。
查看全文
system manager driver code for PCAL6524 could you please provide the system manager driver code for PCAL6524HEAZ fsl_pcal6524.c fsl_pcal6524.h Re: system manager driver code for PCAL6524 Dear Binson, I am not aware of an official MCUXpresso SDK/System Manager driver named fsl_pcal6524.cfsl_pcal6524.h for the PCAL6524HEAZ. NXP Linux BSPs support the device through the standard Linux GPIO-expander driver using the PCA6524 device-tree compatible string. The i.MX95 19x19 EVK is a public example that uses the PCAL6524 as an I²C GPIO expander: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts   With Best Regards, Jozef
查看全文
i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Hi, These are my yocto build parameters: Release: imx-linux-walnascar BSP Version: imx-6.12.49-2.2.0 MACHINE: imx8mpevk DISTRO: fsl-imx-xwayland I have been using this build environment successfully for the past couple of months. However, I suddenly started encountering the attached error. To troubleshoot, I completely cleaned the build environment, reinitialized the repository (repo init), synced everything again, and performed a fresh build. Unfortunately, I am still facing the same issue. Please find the attached log file for your reference. I would appreciate your help in identifying the root cause and suggesting a solution. i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) bitbake imx-image-core Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) What "bitbake command" are you using? I will do verification. Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Thank you for your response. I verified my build environment, and it already matches the configuration you recommended. Host OS: Ubuntu 22.04.5 LTS (Jammy) GNU tar version: GNU tar 1.34 $ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.5 LTS" ... $ tar --version tar (GNU tar) 1.34 However, I still encounter the same failure Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Please check the tar version, if the host is Ubuntu 24.04 and tar is 1.35 Build inside a container or VM with: Ubuntu 22.04 LTS GNU tar 1.34 Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Please find file below,  Here i am pasting the some lines of error  DEBUG: Executing python function extend_recipe_sysroot NOTE: Direct dependencies are ['/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/binutils/binutils-cross_2.44.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/gcc/gcc-cross_14.3.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/quilt/quilt-native_0.68.bb:do_populate_sysroot', '/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-core/coreutils/coreutils_9.6.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/bison/bison_3.8.2.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/dwarfsrcfiles/dwarfsrcfiles.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/flex/flex_2.6.4.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-devtools/rpm/rpm_4.20.0.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-extended/bc/bc_1.08.1.bb:do_populate_sysroot', 'virtual:native:/home/vvdn/LWT_Build/sources/poky/meta/recipes-kernel/kmod/kmod_34.1.bb:do_populate_sysroot'] NOTE: Installed into sysroot: [] NOTE: Skipping as already exists in sysroot: ['gettext-minimal-native', 'binutils-cross-aarch64', 'cmake-native', 'gcc-cross-aarch64', 'libtool-native', 'm4-native', 'quilt-native', 'texinfo-dummy-native', 'kern-tools-native', 'linux-libc-headers', 'file-native', 'openssl-native', 'coreutils-native', 'expat-native', 'ncurses-native', 'readline-native', 'util-linux-libuuid-native', 'zlib-native', 'bison-native', 'dwarfsrcfiles-native', 'elfutils-native', 'flex-native', 'git-native', 'gnu-config-native', 'json-c-native', 'libedit-native', 'lua-native', 'make-native', 'patch-native', 'perl-native', 'pkgconfig-native', 'pseudo-native', 'python3-native', 'rpm-native', 'bc-native', 'bzip2-native', 'libarchive-native', 'libidn2-native', 'lzlib-native', 'xz-native', 'zstd-native', 'kmod-native', 'acl-native', 'attr-native', 'curl-native', 'gdbm-native', 'gmp-native', 'gnutls-native', 'libtasn1-native', 'libcap-native', 'libffi-native', 'libgcrypt-native', 'libgpg-error-native', 'libmicrohttpd-native', 'libmpc-native', 'libunistring-native', 'mpfr-native', 'nettle-native', 'p11-kit-native', 'popt-native', 'sqlite3-native'] DEBUG: Python function extend_recipe_sysroot finished DEBUG: Executing python function sstate_task_prefunc DEBUG: Python function sstate_task_prefunc finished DEBUG: Executing python function do_package DEBUG: Executing python function package_setup_pkgv DEBUG: Python function package_setup_pkgv finished DEBUG: Executing python function package_convert_pr_autoinc DEBUG: Python function package_convert_pr_autoinc finished DEBUG: Executing python function package_prepare_pkgdata NOTE: Installed into pkgdata-sysroot: [] DEBUG: Python function package_prepare_pkgdata finished DEBUG: Executing python function perform_packagecopy ERROR: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:perform_packagecopy(d) 0003: File: '/home/vvdn/LWT_Build/sources/poky/meta/classes-global/package.bbclass', lineno: 363, function: perform_packagecopy 0359: rpath_replace (dvar, d) 0360:} 0361:perform_packagecopy[cleandirs] = "${PKGD}" 0362:perform_packagecopy[dirs] = "${PKGD}" *** 0363: 0364:python populate_packages () { 0365: oe.package.populate_packages(d) 0366:} 0367:populate_packages[dirs] = "${D}" File: '/usr/lib/python3.10/subprocess.py', lineno: 421, function: check_output 0417: else: 0418: empty = b'' 0419: kwargs['input'] = empty 0420: *** 0421: return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, 0422: **kwargs).stdout 0423: 0424: 0425:class CompletedProcess(object): File: '/usr/lib/python3.10/subprocess.py', lineno: 526, function: run 0522: # We don't call process.wait() as .__exit__ does that for us. 0523: raise 0524: retcode = process.poll() 0525: if check and retcode: *** 0526: raise CalledProcessError(retcode, process.args, 0527: output=stdout, stderr=stderr) 0528: return CompletedProcess(process.args, retcode, stdout, stderr) 0529: 0530: Exception: subprocess.CalledProcessError: Command 'tar --exclude=./sysroot-only -cf - -C /home/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/linux-imx/6.12.34+git/image -p -S . | tar -xf - -C /home/vvdn/LWT_Build/build/tmp/work/imx8mpevk-poky-linux/linux-imx/6.12.34+git/package' returned non-zero exit status 2. Subprocess output: got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. got *at() syscall for unknown directory, fd 4 unknown base path for fd 4, path lib couldn't allocate absolute path for 'lib'. tar: ./usr/lib: Cannot mkdir: Bad address tar: ./usr/lib/modules: Cannot mkdir: No such file or directory Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) It seems that I don't have the permission to download the attachment. Would you please resend it again? Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) Hi @yipingwang  Awaiting for your prompt support in further debugging. Re: i.MX8MP_EVK: YOCTO Compilation Error do_package() (Issue: tar & *at()) On your ubuntu PC, use the command "sudo apt install tar=1.34+dfsg-1build3"
查看全文
MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Dear NXP engineers and community experts, I am currently developing with the MFS2323BMBA5EP Safety SBC and have encountered a significant conflict between my configuration files and datasheet reports regarding the OTP factory configuration. I would greatly appreciate your expertise in clarifying this. The Configuration Conflict: 1. Evidence from the .cfg file: In my FS2320_BA5_CONFIG_Rev_A.cfg file, there is a direct register value: 0x30 : 0x00 According to the FS23 datasheet (Table 229, OTP_MAIN_SYS_I2C_CFG😞 Bit 4 (SPI_EN_OTP): 0 means I2C is enabled, SPI is disabled; 1 means SPI is enabled. Bit 3~0 (I2CDEVADDR_OTP): 0000 means the I2C slave address is 0x20. This clearly suggests the chip is factory-configured for I2C mode. 2. Evidence from the Configuration Report PDF: However, in my R_MFS2323BMBA5_Rev_A_test.pdf document, under Table 2. Device OTP configuration, the report explicitly states: SPI Enable: SPI pins are enabled. This suggests the hardware pins are locked to SPI mode. My Actual Hardware Test Results: When I configured my MCU (S32K344) as an SPI Master to communicate with this PMIC: The MISO pin stays at a constant 0.3V (indicating high-impedance with internal weak pull-down, meaning the slave is not driving the line). The SCK pin on the PMIC side was actually outputting clock signals on its own. I suspect the chip might be locked in OTP Emulation mode or configured as an I2C slave, which is causing the SPI communication to completely fail. My Specific Questions: Could you please confirm the actual factory OTP configuration for the MFS2323BMBA5EP? Is it SPI or I2C? When there is a conflict between the .cfg register file (0x30 : 0x00) and the PDF configuration report, which one should be considered the absolute hardware truth? Is there a possibility that the PDF report contains a documentation error? (I have attached the FS2320_BA5_CONFIG_Rev_A.cfg and the R_MFS2323BMBA5_Rev_A_test.pdf to this post for reference). Thank you in advance for your help! Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Okay, thank you. Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Which company are you from? Currently, you're using your own email address, which is considered a low-priority (C-level) customer. This requires checking your schematic and a series of things related to the CRC driver. I suggest you submit a ticket using your company email address. Home Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Currently, it's not possible. I'm communicating in DEBUG mode. I've tested the SCK and MOSI waveforms on the 344 pin separately, and they can transmit the data I write. However, because the FS23's SCK pin is also sending a signal, when these two are connected together, the SCK signal sent by the MCU is pulled low by the FS23. The responses I send to the FS23 are all 0s. I've also configured CRC. The purple line represents the SCK signal after the top. Yellow indicates data signals. The scale is 5V. The data sent is {0x02, 0x00, 0x00, CRC} If you forcefully interpret the SCK waveform as a normal waveform, you can see that the data is correct; the first bit is 2, followed by 00 and CRC. Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Can you successfully communicate using SPI? Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification Is it possible that the SCK signal of the FS23 is also being sent when communicating with the S32K344 via SPI? Because if I don't configure SPI communication with the FS23, there's no waveform when I try to capture the SCK pin of the FS23. Only when communicating with the S32K344 are both the SCK pins of the FS23 and the S32K344 sending signals, and the waveforms of the SCK and CS pins are exactly the same. Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification I uploaded the .cfg file to Mirror via the GUI. The register indicates SPI mode.
查看全文
PCAL6524 的系统管理器驱动程序代码 请问能否提供PCAL6524HEAZ的系统管理器驱动程序代码? fsl_pcal6524.c fsl_pcal6524.h Re: system manager driver code for PCAL6524 亲爱的宾森: 我不知道有名为fsl_pcal6524.cfsl_pcal6524.hf或 PCAL6524HEAZ 的官方 MCUXpresso SDK/系统管理器驱动程序。NXP Linux BSP 通过标准的 Linux GPIO 扩展器驱动程序,使用 PCA6524 设备树兼容字符串来支持该设备。i.MX95 19x19 EVK 是一个公开示例,它使用 PCAL6524 作为 I²C GPIO 扩展器: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts   最诚挚的问候, 约瑟夫
查看全文
FS26 LDO 発行終了 Hello 私はFS26とS32K358を使用しています。 私はFS26のVLDO2をMCUの電源として、FS26のVLDO1をCANトランシーバの電源として使っています。 MCUがCAN通信状態のままになると、FS26のVLDOはオフになり、MCUの電源が遮断されます。 (これはランダムに発生し、およそ1~8時間ごとに起こります。) VLDOは、FS26の電源が遮断され、その後復旧された後にのみ復旧します。 この問題はすべてのボードで発生し、単一のボードだけでなく、CAN通信が進行中でない場合は発生しません。 問題発生時の状況は以下のとおりです。 Vpre 6V O VDIG 1.6VO VBOS 5V O VLDO2 X VLDO1 X VCORE X OTPによるDFSは無効化されています。 FS26の現状と、この問題が発生する原因について知りたいです。 Re: FS26 LDO Off Issue こんにちは、 kjy106906さん 良い一日! ウォッチドッグは有効になっていますか? 以下の値は何ですか? FS_STATES FS_GRL_FLAGS FS_OVUV_REG_STATUS M_REG_FLG 障害発生直後にM_STATUSが表示されますか? FS26にUVフラグやOVフラグが表示されていないか確認しましたか? また、あなたのM_STATUSも教えてもらえますか? この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。 Re: FS26 LDO Off Issue @RafaR ご返信ありがとうございます。 残念ながら、MCUはSBCから電力を受け取っていますが、VLDOがオフであるため通信は不可能です。 MCUが動作するためには、基板の電源を切って再供給しなければなりません。 監視ウィンドウは無限です。
查看全文
Reducing Power Consumption by Disabling CPU/GPU/VPU on i.MX95 Hi NXP, We are looking for ways to reduce the overall power consumption of our i.MX95-based system. Could you please help clarify the following questions? Is it possible to completely power down individual CPU cores when they are not required? Is it possible to completely power down the GPU and VPU if our application does not use them? If the CPU/ GPU / VPU is not required, is it possible to keep them disabled by default after boot to further reduce power consumption ? (by device-tree ?) Are there any recommended software configurations or reference documents for achieving the lowest possible power consumption? Our BSP is based on Yocto 5.2 / Linux 6.12.x. Thanks. Best Regards, Sean Linux
查看全文
MFS2323BMBA5EP OTP 配置冲突:SPI 与 I2C 模式识别 尊敬的恩智浦工程师和社区专家们: 我目前正在使用以下技术进行开发 MFS2323BMBA5EP 功能安全单板计算机 (SBC) 的配置文件与数据手册中关于一次性密码 (OTP) 出厂配置的报告存在重大冲突。非常感谢您能凭借专业知识对此进行澄清。 配置冲突: 1. 来自以下方面的证据 .cfg 文件: 在我的 FS2320_BA5_CONFIG_Rev_A.cfg 文件中,有一个直接的寄存器值: 0x30 : 0x00 根据 FS23 数据表(表 229), OTP_MAIN_SYS_I2C_CFG😞 位 4 ( SPI_EN_OTP ) : 0 方法 I2C 已启用,SPI 已禁用; 1 表示SPI已启用。 位 3~0 ( I2CDEVADDR_OTP ) : 0000 意思是 I2C 从机地址是 0x20 。 这清楚地表明该芯片是出厂时就已配置好的。 I2C模式。 2. 来自配置报告 PDF 的证据: 然而,在我的 R_MFS2323BMBA5_Rev_A_test.pdf 文件,在 表 2. 设备 OTP 配置,报告中明确指出: SPI 使能:SPI 引脚已启用。 这表明硬件引脚被锁定。 SPI模式。 我的实际硬件测试结果: 当我将我的MCU(S32K344)配置为SPI主设备以与该PMIC通信时: MISO引脚保持恒定 0.3伏 (表示高阻抗,内部下拉电阻较弱,意味着从设备无法驱动线路)。 PMIC 侧的 SCK 引脚实际上会自行输出时钟信号。 我怀疑该芯片可能被锁定在 OTP 仿真模式或配置为 I2C 从设备,这导致 SPI 通信完全失败。 我的具体问题: 请您确认一下。 MFS2323BMBA5EP的实际出厂OTP配置是什么?是SPI还是I2C? 当两者之间发生冲突时 .cfg 寄存器文件( 0x30:0x00 )和PDF配置报告,哪个才是硬件配置的绝对权威?PDF报告是否存在文档错误的可能性? (我已附上) FS2320_BA5_CONFIG_Rev_A.cfg 以及 R_MFS2323BMBA5_Rev_A_test.pdf (参见此帖)。 提前感谢您的帮助! Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 好的谢谢您 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 请问你们是哪个公司?目前您是用的自己的邮箱属于C客户优先级很低的 这个是需要检查您的原理图,驱动CRC一系列的东西。 我建议您用公司的邮箱提交一个ticket Home  Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 目前不能,我现在是在DEBUG模式下去通讯,我单独测试344端的SCK和MOSI的波形是能发出我写的数据的,但是由于,FS23的SCK引脚也在发信号,这两个接在一块后,MCU发出来的SCK信号被FS23对顶后拉低了,我发送给FS23回复的都是0,我也配置了CRC了 紫色的线是对顶后的SCK信号 黄色是数据信号 刻度都是5V 发送的数据是 {0x02, 0x00, 0x00,CRC} 如果强行把SCK看成正常波形是能看出来数据是对的,第一位是2然后00和CRC Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 你配置成SPI 能通信成功吗? Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 会出现与S32K344SPI通讯时FS23的SCK信号也在发送吗,因为如果我不配置SPI与FS23通讯,我去抓FS23的SCK脚是没有波形的,只有344和他通讯的时候这两个的SCK引脚都在发信号,而且SCK和CS引脚的波形是一模一样的 Re: MFS2323BMBA5EP OTP Configuration Conflict: SPI vs I2C Mode Identification 我在GUI upload .cfg文件到mirror register显示就是SPI 模式
查看全文
i.MX8M Plus — Secondary image boot (IMG_CNTN_SET1_OFFSET) on ECSPI/SPI NOR: does ROM fall back in OP i.MX8M Plus -- Secondary image boot (IMG_CNTN_SET1_OFFSET) on ECSPI/SPI NOR: does ROM fall back in OPEN config? ==== Setup ==== - SoC: i.MX8M Plus (custom SMARC module) - Boot device: serial NOR on ECSPI2 / CS1 (Winbond W25Q128, 16 MiB). This is the legacy eCSPI controller, NOT FlexSPI. - Security: OPEN configuration (device is not HAB-closed). - Fuse IMG_CNTN_SET1_OFFSET (fuse read 2 1) = 0x00000000. - Flash map: primary bootloader at 0x000000, secondary copy at 0x400000 (4 MiB). Per the documented SPI mapping: "For SPI: secondary boot disabled if fuse > 10; n == 0 -> Offset = 4 MB; n == 2 -> 1 MB; others & n <= 10 -> 1 MB * 2^n." With fuse n = 0 (factory default, no burn needed) the secondary offset should be exactly 0x400000. ==== The problem ==== We placed a byte-identical, cmp.b-verified copy of the primary image at 0x400000, then invalidated the primary boot header (sf erase 0 0x1000) and reset. The ROM does NOT fall back to the secondary image -- the board is bricked (recoverable only via USB SDP). We also tried erasing a hole inside the primary body (sf erase 0x100000 0x40000) with the same result. ==== Questions ==== 1. On SPI/ECSPI NOR, what exactly triggers the ROM to switch to the secondary image at the IMG_CNTN_SET1_OFFSET? Is it any invalid primary boot header / failed image parse, or specifically a HAB authentication failure? 2. Does secondary-image boot work in OPEN (non-secured) configuration, or only when the device is HAB-closed? 3. Does it fall back on the same reset, or does it require a power cycle / second reset (persistent-boot style)? 4. Must the secondary image at 0x400000 be a separately-built bootable image (its own IVT/boot data for that offset), or is a byte-identical copy of the primary sufficient? ==== Logic-analyzer evidence (SPI bus captured during reset) ==== We probed the ECSPI2 bus (CLK, MOSI, MISO, CS) with a Saleae Logic Pro 16 at 500 MS/s and decoded every SPI transaction during reset. For comparison we did the same on an i.MX8QM module which boots from FlexSPI NOR and does fall back to secondary successfully. ---- i.MX8M Plus (ECSPI NOR), primary corrupted ---- The ROM issues only 0x03 READ commands, reading strictly sequentially from offset 0: 0x03 00 00 FC -> READ 0x0000FC 0x03 00 04 EC -> READ 0x0004EC 0x03 00 08 DC -> READ 0x0008DC ... (~50 reads per 64 KiB block, strictly increasing) ... 0x03 00 13 xx -> read count drops here (erased hole 0x100000-0x140000, MISO=0xFF) 0x03 00 18 xx -> continues LINEARLY past the hole ... up to ~0x1A69E8 ... The ROM reads linearly through the entire primary region, straight through the erased/invalid area (getting 0xFF back), and NEVER issues a read to 0x400000 or 0x800000 (the secondary region). There is no "0x03 40 xx xx" anywhere in the full capture (25 million samples, 654 decoded transactions). On a fully-erased-header case the ROM loads 0xFF, executes it, and crashes with a Synchronous Abort -- no fallback of any kind. ---- i.MX8QM (FlexSPI NOR), for contrast -- secondary fallback DOES work ---- When only the primary container header is invalidated (FCB left intact at 0x000400), the QM ROM does: 0x0B 00 04 00 -> Fast-Read FCB @0x000400, MISO: 46 43 46 42 ("FCFB" magic, FlexSPI config valid) ... reads FCB configuration data ... 0x0B 00 10 00 -> Fast-Read primary container @0x001000, MISO: FF FF FF FF (invalid!) 0x0B 40 10 00 -> Fast-Read SECONDARY container @0x401000, MISO: valid <-- ROM switched, SAME reset 0x0B 40 30 00, 0x0B 40 40 00, ... -> loads whole secondary image (~90 reads at 0x40xxxx) The QM ROM reads FCB, configures FlexSPI, checks the primary container at 0x001000, sees 0xFF, and immediately (same reset) switches to the secondary container at 0x401000. This works. If we instead erase the whole first 4 MB (including the FCB), the QM ROM makes only 2 reads at 0x000400, gets 0xFF, and does NOT fall back -- so a valid FCB is required for the fallback to engage. ---- Comparison ---- i.MX8M Plus (this board): Controller : eCSPI (legacy SPI) Read opcode: 0x03 READ FCB present: No (eCSPI has no FCB concept) Reads secondary on corrupt primary: NO -- bus never shows "0x03 40 xx xx" Result: bricks (loads 0xFF -> crash) i.MX8QM (reference): Controller : FlexSPI Read opcode: 0x0B Fast Read FCB present: Yes (0x400, magic "FCFB") Reads secondary on corrupt primary: YES -- "0x0B 40 10 00", same reset Result: boots secondary successfully ==== Summary ==== From the bus captures, the IMG_CNTN_SET1_OFFSET secondary-image boot on i.MX8M Plus appears to be either FlexSPI-only, or gated by HAB-closed config, and does not engage for eCSPI NOR in OPEN config. Could NXP please confirm: - Whether eCSPI (as opposed to FlexSPI) NOR is supported for secondary-image boot at all on i.MX8M Plus; - Whether the trigger is HAB-auth-failure (closed config only) vs. any invalid header (open config too); - Whether fallback is same-reset or requires a power cycle; - Whether the secondary must be separately built for that offset, or a byte-identical copy is OK. Thank you.
查看全文
IMX95EVK-19-REV-A1 flash problem Dear NXP, I'm trying to flash a linux image(6.18.20_2.0.0/ 6.18.2_1.0.0/6.12.49_2.2.0) to eMMC/SD Card on IMX95LP5-19 EVK REV A1 and none of them is successful. The command prompt shows [HID(W): LIBUSB_ERROR_PIPE (-9) ] SDPS: boot -f imx-boot-imx95-19x19-lpddr5-evk-sd.bin-flash_all. IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) The reference above mentioned that A1 silicon does not support current images on official site(6.12.34 does not have IMX95EVK patch). so I wonder if there is an unpublished official link that includes suitable images?  Looking forward to your reply, Thanks. BR/david Here is a reference IMX95LPD5EVK-19CM: UUU eMMC flash of L6.18.2 fails (LIBUSB errors on Linux and Windows) Re: IMX95EVK-19-REV-A1 flash problem A1 silicon: The recommended BSP is LF 6.6.52_2.2.x Please download demo image L6.6.52_2.2.2_MX95 And use image imx-boot-imx95-a1-19x19-lpddr5-evk-sd.bin-flash_all I just verified the following command, it worked. uuu.exe -b emmc imx-boot-imx95-a1-19x19-lpddr5-evk-sd.bin-flash_all
查看全文
ls1021a eTSEC tx timeout I have a LS1021A IOT and a prototype board based on this cpu. On both we use our boot loader. It works perfectly in the IOT board but on my board I get TX timeout on the Ethernet port. I get a few pings going and then tx timeout and more pings.  This makes tftp rarely possible. There are hardware difference of course. Our MAC is connected to a BCM54616S then to a LAN9514. The autonegotiation is limited to 100FD. TX timeout also happens in loopback mode. In order to transmit data, I had to set bit SGMII_AN bit in the TBI PHY on my boards while I did not have to on the IOT (IOT can negotiate at 1000FD). Not sure why the TX is so intermittent. Could it be related to this speed limitation? Re: ls1021a eTSEC tx timeout Hello, For 100FD SGMII , verify these items in your boot loader on the prototype board: Set LS1021A eTSEC for SGMII 100 Mbps ECNTRL[TBIM] = 1 ECNTRL[SGMIIM] = 1 ECNTRL[R100M] = 1 MACCFG2[I/F Mode] = 01 for 10/100 mode The LS1021A RM specifically notes setting R100M = 1 for SGMII 100 Mbps. Reset and program the internal TBI PHY The RM states that SGMII uses the TBI register set and that it is important to reset the TBI for all interface modes, including SGMII. Keep SGMII_AN set The TBI SGMII_AN bit is documented as “must be set to 1.” So the fact that your board only transmits after setting this bit is not surprising; it suggests your boot-loader initialization was incomplete for this PHY/MAC mode. Do not rely on 1G-style SGMII AN behavior at 100 Mbps There are known LS1021A reports where 100 Mbps SGMII operation shows “SGMII link is not ok” or intermittent no-packet behavior after link cycling, while 1G operation is clean. That does not prove your exact TX timeout root cause, but it makes 100FD SGMII configuration a strong suspect. The loopback result matters. If your “loopback mode” is external PHY loopback or SGMII-side loopback, the 100FD SGMII/TBI setup can still be involved. If it is internal MAC/eTSEC loopback , then the external BCM54616S/LAN9514 path is mostly out of the picture, and I would focus on eTSEC initialization, descriptor-ring handling, cache coherency, and TX halt/error status. For debugging, check the eTSEC TX halt status when the timeout occurs. The RM says the transmit halt bits are set when eTSEC is no longer processing transmit frames from a TxBD ring; repeatable causes include bus errors, invalid BD/data addresses, uncorrectable BD/data read errors, and TxBD programming errors such as Ready = 1 with length 0 . Also check whether you are seeing IEVENT_BSY ; NXP material describes BSY as dropped RX frames due to lack of buffers/software not servicing the BD ring fast enough, which is a software/BD-ring symptom rather than a pure SGMII electrical symptom. Recommended isolation sequence: 1. Force external PHY to 100FD, no autoneg toward copper if needed. 2. Force LS1021A MAC/eTSEC to SGMII 100 Mbps: TBIM=1, SGMIIM=1, R100M=1, MACCFG2 I/F mode=10/100. 3. Reset/reinitialize TBI after setting SGMII mode. 4. Set TBI SGMII_AN=1. 5. Confirm TBI link/AN status, eTSEC ECNTRL/MACCFG2, and PHY SGMII-side status. 6. On timeout, dump IEVENT, TX halt registers, DMA status, and TXBD ring contents. regards  Re: ls1021a eTSEC tx timeout Forgot to say my port is set for SGMII mode.
查看全文
MTC40F2046S1RC64BD2 Are you able to confirm if this mpn: MTC40F2046S1RC64BD2 is X-ray sensitive?  Re: MTC40F2046S1RC64BD2 That's not true. X-ray exposure is a common testing procedure and will not cause damage. We suggest you find a seller with a Certificate of Conformity (COC) for safety assurance.
查看全文
边缘人工智能 建议使用 imx93 的 EDGE AI 应用 Re: edge ai 对于 i.MX 93,我建议最适合应用于边缘人工智能工业视觉/非接触式人机界面应用。 它为何适用于 i.MX 93: i.MX 93 旨在为工业、汽车和物联网市场提供节能型边缘计算、机器学习加速和快速边缘推理功能。 它集成了Arm Ethos-U65 微型 NPU ,旨在加速嵌入式和物联网设备中的机器学习推理。 NXP 文档明确列出了工业人机界面、工业视觉、工业自动化、非接触式门禁控制和机器视觉作为 i.MX 93 的应用领域。 该平台支持人工智能应用场景,例如计算机视觉、语音识别、物体检测、面部识别和姿态检测。 一个实用的应用程序概念: 智能工业视觉 + 非接触式操作界面 示例功能: 基于摄像头的物体检测,用于零件存在性检查、标签检查或缺陷筛查。 用于非接触式机器控制的手势或姿态检测。 可选语音命令界面,实现免提操作。 在 i.MX 93 上进行本地推理,减少对云的依赖和延迟。 使用 i.MX 93 安全架构提供安全设备身份和生命周期支持,包括 i.MX 93 材料中提到的 EdgeLock 相关功能。 其他适合 i.MX 93 的边缘人工智能应用候选方案: 应用创意 为什么它合适 智能门铃/门禁系统 使用人脸/物体检测和本地推理;智能门铃和智能锁是 i.MX 93 智慧家居目标之一。 驾驶员监测系统 DMS 已明确列入 i.MX 93 适用于汽车应用零部件清单。 带异常检测功能的电能表 该电能表适用于工业/楼宇控制用途;机器学习可以检测本地使用异常情况。 智能健身/姿态检测演示 姿态检测和智能健身示例是已记录的边缘人工智能用例。 最佳建议:在 i.MX 93 上构建工业视觉或非接触式 HMI 边缘 AI 应用,因为它与已记录的 i.MX 93 NPU、工业视觉、HMI 和本地 ML 推理用例直接相关。
查看全文
Support Request: HD-SDI Interface Using i.MX8M Plus LVDS Output Dear Sir, We are designing a system based on the NXP i.MX8M Plus processor and would like your guidance regarding the implementation of an HD-SDI interface. Our requirement is to support three HD-SDI outputs. We are planning to use the LVDS interface of the i.MX8M Plus and convert it to HD-SDI using the following devices: LMH0340SQE/NOPB – LVDS to HD-SDI Serializer 2 × LMH0324RTWT – 1-to-3 HD-SDI Distribution Amplifiers Could you please confirm whether the LVDS interface of the i.MX8M Plus is compatible with this architecture for generating three HD-SDI outputs? If this approach is not recommended or supported, could you please suggest an alternative solution for implementing three HD-SDI interfaces while continuing to use the i.MX8M Plus processor? We would prefer to retain the i.MX8M Plus in our design, as it satisfies all of our other system requirements. We would appreciate your recommendations and any reference designs or application notes that may help us implement this interface successfully. Thank you for your support. We look forward to your guidance. Best regards, Samudralankaiah Jampani Analog(ADC|CMP|DAC|OpAmps) Board Design MCXA MCXC
查看全文
ICODE SLI 无法切换到 ICODE SLIX 我的客户一直在使用我提供的 ICODE SLI 芯片,但该芯片已经停产了。我们正在尝试切换到 ICODE SLIX,但客户的 RFID 阅读器无法识别它。 Re: ICODE SLI can't be switch to ICODE SLIX 你好, ICODE SLIX 旨在向后兼容 ISO15693 级别的 ICODE SLI,因此读卡器至少应该在盘点期间检测到 SLIX UID。如果读卡器无法识别,请先检查故障是出在射频存货层面还是出在应用程序的标签识别逻辑层面。常见原因包括 AFI/UID 过滤、硬编码的 SLI 产品识别、旧的读卡器固件,或者在迁移过程中使用 SLIX 特有的网络安全/功能。对于第一个测试,禁用 AFI 过滤和标签白名单,执行标准的 ISO15693 清单,读取 UID/DSFID/AFI,然后将应用程序的接受逻辑与旧的 SLI 标签进行比较。 此致
查看全文
i.MX8M Plus - SPDIFプロトコル実装例 こんにちは、チームのみなさん。 どなたか、i.MX8M plusでSPDIFプロトコルを実装し検証する方法を教えていただけませんか? Re: i.MX8M Plus - SPDIF Protocol Implementation Example 最もシンプルな i.MX 8M Plus S/PDIF実装については、i.MX Audio Board / MCIMX8M-AUDを最も近いNXPの参照ハードウェアとして使用し、ベース i.MX 8M Plus EVK単独ではありません。オーディオボードは8M Plus i.MX をサポートし、RCAおよびTOSLINKコネクタを備えたS/PDIF I/Oを提供し、最大192 kHzまでのTOSLINK対応であることが文書化されています。 推奨されるシンプルなアプローチ: 可能であれば、まず光S/PDIFを使用してください。 最も簡単なハードウェアパス:i.MX8MP SPDIF_OUT →光式TOSLINKトランスミッタ。 受信用:光TOSLINK受信モジュール→ i.MX8MP SPDIF_IN。 これにより、同軸75Ωライン駆動、トランス/カップリング、および接地に関する問題を回避できます。 i.MX 8M PlusのS/PDIFピンをIOMUX経由で使用する i.MX 8M PlusオーディオサブシステムはSPDIFの入出力を備えています。 リファレンスマニュアルには、選択可能なパッドのAUDIOMIX_SPDIF1_OUTとAUDIOMIX_SPDIF1_INのIOMUXオプションが示されています。 Linuxでは対応するIOMUX定義にはMX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF_OUTとMX8MP_IOMUXC_SPDIF_RX__AUDIOMIX_SPDIF_INが含まれます。 同軸RCAが必要な場合は SoCピンを直接RCAのラインドライバーのように扱わないでください。 選択したトランスミッタ/インターフェース回路ごとに適切な75 Ω S/PDIF同軸ケーブル出力ネットワーク/結合を追加してください。 光ファイバー方式は、通常、よりシンプルで安全な最初の実装方法です。 参考資料 MCIMX8M-AUD / i.MX オーディオボード:i.MX 8MファミリのS/PDIF I/OおよびRCAおよびTOSLINKに最適なNXPリファレンス。 i.MX 8M Plusリファレンスマニュアル:AUDIOMIX_SPDIF1_INおよびAUDIOMIX_SPDIF1_OUT用のpinmux / IOMUXセットアップ。 i.MX 8M Plusのデータシート:クロックのハイ/ロータイミングを含む、S/PDIFのタイミングパラメータが記載されています。 最も単純な設計では、AUDIOMIX_SPDIF1_OUT/INを光TOSLINKモジュールにルーティングし、MCIMX8M-AUDをNXPのS/PDIF I/O挙動の基準点として使用します。 Re: i.MX8M Plus - SPDIF Protocol Implementation Example こんにちは、Yipingwangさん、 SPDIFを最もシンプルに実装するための参考回路図を教えていただけませんか? Re: i.MX8M Plus - SPDIF Protocol Implementation Example i.MX8M Plusで既存のLinux ALSA Audio XCVR / S/PDIFドライバーを使用;通常、S/PDIFプロトコルを最初から実装することはありません。i.MX8M Plus Audio XCVRはeARC、ARC、S/PDIFモードをサポートし、LinuxのS/PDIF対応では、ALSAを通じてTx用の再生デバイスとRx用のキャプチャデバイスを1台公開します。 推奨される実装方法: カーネルドライバーを有効にしてください有効化: CONFIG_SND_IMX_SPDIF メニューパス: コピー デバイスドライバー -> サウンドカードサポート -> 高度なLinuxサウンドアーキテクチャ -SoCオーディオサポート> ALSA - フリースケール i.MX CPU向けの> SoC オーディオ - > S/PDIF対応 i.MX ボード向けのSoCオーディオサポート ドキュメント化されたDTバインディングは、ドキュメント/devicetree/bindings/sound/fsl spdif.txtおよびドキュメント/devicetree/bindings/sound/imx-audio-spdfif.txtにあります。 デバイスツリーの設定i.MX8M Plusでは、xcvrオーディオブロックを使い、サウンドカード/DAIリンクを有効にしてください。代表的な構成例は以下のとおりです。 サウンドトランスフォーマー { 互換 = 「FSL,IMX-オーディオカード」; model = "imx-audio-xcvr"; pri-dai-link { リンク名 = "XCVR PCM"; CPU { sound-dai = <&xcvr>;         }; }; }; &xcvr { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_xcvr>; ステータス = "正常"; }; Tx ピンの多重化については、文書化された例の 1 つで MX8MP_IOMUXC_SPDIF_TX__AUDIOMIX_SPDIF1_OUT が使用されています。 ボードのルーティングやジャンパーを確認してくださいNXPオーディオボードを使用する場合、意図するS/PDIFパスの物理ルーティングを設定します。i.MX8M Plusの場合、J1500=1-2は同軸コネクタをi.MX8M Plusにルーティングし、J1500=4-5は光コネクタをi.MX8M Plusにルーティングします。CPLD/HDMIカードを経由してルーティングする場合、J2511=1-3は「i.MX 8M PlusからCPLD、そしてHDMIカードへ」として文書化されています。 ALSA / IEC958を正しく使いましょうS/PDIF Txドライバーは32、44.1、48 kHzのサンプリングレートをサポートし、S16_LEおよびS24_LEフォーマットに対応しています。24ビット出力の場合、ファイルは1チャネルフレームあたり32ビットを使用し、有効な24個のLSBのみを使用します。パスが生のPCMではなくIEC958サブフレームを想定する場合は、ユーザー空間でPCMからIEC958への変換を行い、例えばALSA PCMプラグインを使って行います。 検証手順: aplay -l arecord -l これらを使用して、S/PDIF再生/キャプチャカードおよびデバイスIDを特定します。ドキュメントには、S/PDIFデバイスがIMXSPDIF[imx-spdif]のようなALSAカードとして表示され、デバイス0: S/PDIF PCMとして表示されています。 トランザクション検証: aplay -D hw: , audio48k24S.wav リファレンス検証方法 は、M-Audio Transit USBサウンドカードとWaveLabを組み合わせた外部の光S/PDIF レシーバ を使用し、ストリームを外部に録音して再生して正確性を確認します。 処方箋の検証: arecord -D hw: , -c 2 -d 20 -r 48000 -f S24_LE record.wav レコードに渡されるサンプルレートは、入力されるS/PDIFストリームのサンプルレートと一致している必要があります。Rxの場合、アプリケーションフローはS/PDIF Rx PCMデバイスを開き、内部DPLLが入力ビットストリームにロックされるのを待ち、入力サンプリングレートを取得し、チャネル/フォーマット/レートパラメータを設定し、準備してキャプチャをトリガーすることです。 プロトコルレベルのチェックには、以下を使用してください。 iecset -c iecsetはIEC958ステータスビットの設定またはダンプに記載された標準ユーティリティであり、ドライバはALSA制御インターフェースを通じてチャネル状態処理も公開します。 i.MX8M Plus EVKスタイルの検証については、NXPはimxaudioxcvrカードを用いたループバックスタイルのLinuxテストも記録しており、例えばimxaudioxcvrからの録音とwm8960audioへの再生などがあります。 arecord -Dsysdefault:CARD=imxaudioxcvr -c2 -r48000 -fS32_LE -twav | \ aplay -Dsysdefault:CARD=wm8960audio 簡単に言うと、i.MX S/PDIF / XCVR ALSAドライバーを有効にし、xcvrデバイスツリーとボードルーティングを設定し、aplay 、arecord、iecset 、および外部の光/同軸S/PDIFソースまたはシンクでTx/Rxを検証します。
查看全文