VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking suppo Hello NXP team, I'm currently debugging the VR5510 PMIC and have run into a real-time scheduling issue related to the watchdog refresh. The MCAL I2C watchdog refresh (feeding the VR5510 watchdog over I2C) is implemented as a synchronous operation. Because we call it from within an interrupt context, the synchronous wait blocks the CPU and degrades the real-time scheduling of other tasks. I noticed there is an asynchronous option in the driver configuration/code. However, in practice it still performs a synchronous busy-wait (it blocks and polls until the I2C transfer completes), so it does not actually decouple the transfer from the caller. My questions: Is there an officially supported way to make the VR5510 watchdog refresh truly non-blocking (e.g. interrupt-driven or DMA-driven I2C), so that it does not stall other tasks? If the asynchronous option is expected to be non-blocking, is the current synchronous busy-wait behavior a known limitation or a configuration issue on my side? Any guidance, reference configuration, or example code would be greatly appreciated. Thank you. Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello, @Jerry_cao  Thanks for the post. May I know if you are referring to the following API used " Std_ReturnType I2c_AsyncTransmit (uint8 Channel,  const I2c_RequestType ∗ RequestPtr ) "?  Which version RTD is used? BR Chenyin Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello： my version is：   *   Project              : RTD AUTOSAR 4.4 *   Platform             : CORTEXM *   Peripheral           : VR5510 *   Dependencies         : none * *   Autosar Version      : 4.4.0 *   Autosar Revision     : ASR_REL_4_4_REV_0000 *   Autosar Conf.Variant : *   SW Version           : 4.0.2 *   Build Version        : S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * *   (c) Copyright 2020-2023 NXP Semiconductors *   All Rights Reserved. * use this function  Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello, @Jerry_cao  Thanks for your confirmation. By checking with the corresponding code, the VR5510 Solution for I2C asynchronous communication is implemented in RTD5.0.0QLP04 You may check the related code in this version RTD for details. BR Chenyin Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s Hello： my version is：   *   Project              : RTD AUTOSAR 4.4 *   Platform             : CORTEXM *   Peripheral           : VR5510 *   Dependencies         : none * *   Autosar Version      : 4.4.0 *   Autosar Revision     : ASR_REL_4_4_REV_0000 *   Autosar Conf.Variant : *   SW Version           : 4.0.2 *   Build Version        : S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * *   (c) Copyright 2020-2023 NXP Semiconductors *   All Rights Reserved. * use this function  Pmic_VR55XX_TriggerWatchdog

SW32K14-MCAL421-RTMC-1.0.1 ダウンロードへのアクセスを有効にするリクエスト こんにちは、NXPサポートチーム様 SW32K14-MCAL421-RTMC-1.0.1のダウンロード アクセスをリクエストします。 現在、NXP ソフトウェア ライセンス ページの [前へ] タブがグレー表示されており、このバージョンにアクセスできません。 私のアカウントのユーザー名はChefanqfです。 このバージョンは、 S32K14x MCAL 4.2に基づく既存のプロジェクトとの互換性を保つために必要です。 私のアカウントでこのソフトウェアの権限を有効にするのを手伝っていただけますか? サポートしていただき誠にありがとうございます！ よろしくお願いいたします。 Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは@Chefanqf 、 NXP.com (検索 | NXP Semiconductors) で「S32K1 MCAL」を検索し、次のように flexera と入力してみてはいかがでしょうか。 この後、「オートモーティブ SW - AUTOSAR MCAL / QM」を選択すると、以前のソフトウェアが利用できるようになります。 「前へ」タブがまだグレー表示されている場合、直接リンク： SW32K14-MCAL421-RTMC-1.0.1 から入力してみてください。直接リンクを使用する場合は、nxp.com にログインしていることを確認してください。 よろしくお願いします、 ジュリアン Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは、NXPサポートチーム様 SW32K14-MCAL421-RTMC-1.0.1 のダウンロードアクセスをお願いしたいです。 現在、NXPソフトウェアライセンスページの「前回」タブが グレーアウト 表示され このバージョンにアクセスできません。 私のアカウントのユーザー名はmianlongxuです。 このバージョンは、既存のプロジェクトとの互換性のために必要です。 S32K14x MCAL 4.2 。 私のアカウントでこのソフトウェアの権限を有効にするのを手伝っていただけますか? サポートしていただき誠にありがとうございます！ よろしくお願いいたします。

JTAGデバッガのサポートに関するお問い合わせLX2082A 親愛なるNXPサポートチームへ、 NXP LX2082Aプロセッサをベースにしたカスタムボードを開発しており、現在ハードウェアのブリングアップとデバッグセットアップを計画中です。 SEGGER J-LinkがLX2082Aで以下のタスクに対して正式にサポートされているかどうかを確認したいと思います。 初期ボードの立ち上げ JTAGデバッグ ベアメタルデバッグ TF-AとU-Bootのデバッグ Linuxカーネルデバッグ Flashプログラミング（サポートされている場合） 私の開発環境はLinuxで、すべてのソフトウェアをLinuxホスト上で開発・構築する予定です。 何かアドバイスをいただけますか: SEGGER J-LinkはLX2082Aで正式にサポートされていますか？ もし対応しているなら、どのJ-Linkモデルに対応していますか? NXPが推奨するデバッグソリューションと比較して、何か制限事項はありますか？ もしJ-Linkが推奨されていないなら、公式に対応しているハードウェアデバッガをLX2082Aで教えていただけますか? JTAGのデバッグや基板の導入に関するドキュメントやアプリケーションノートがあれば、ぜひ教えていただけるとありがたいLX2082A。 ご協力ありがとうございました。ご指導を心よりお待ちしております。 敬具。 Re: Inquiry Regarding JTAG Debugger Support for LX2082A NXPが公式にサポートしているデバッガはCWTAPです。 あなたのアプリケーションにはCodewarrior Developer Suite Levelを使えます。 また、以下のリンクから評価版(無料トライアル)をダウンロードすることもできますが、30日間の制限があります すべての顧客アカウント(メールアドレス)は、以下のリンクから評価版をダウンロードできます。 「評価版をダウンロード」を選択してください。 https://www.nxp.com/design/design-center/software/development-software/codewarrior-development-tools/codewarrior-network-applications/codewarrior-development-suites-for-networked-applications:CW-DS-NETAPPS 下記に役立つ資料を掲載していますので、ご参照ください。   ARMv8_Targeting_Manual.pdf   CodeWarrior TAP プローブユーザーガイド   Layerscape Linux SDK ユーザーガイド Clarification on CodeWarrior License After 30-Day Evaluation (CW TAP / QCVS / QCS) こんにちは、NXPサポートの皆さん、 CodeWarriorの30日間評価版について質問があります。 評価期間終了後： JTAG接続（CW TAPを使用）は引き続き機能しますか、それともCodeWarriorは完全に動作しなくなりますか？ 有料ライセンスがなくても、RCWの生成・プログラミングおよびフラッシュプログラミングは引き続き利用できますか？ QCVS(QorIQ Configuration and Validation Suite)はトライアル終了後も引き続き使用できますか?それとも有効なCodeWarriorライセンスも必要ですか? Linuxのコマンドラインツール(U-Boot、Yocto、OpenOCDなど)のみを使用しているお客様にとって、CodeWarriorの購入はJTAGデバッグのためだけに推奨されるのか、それとも基板の設置に必須ですか? 評価期間終了後も利用可能な機能について、ご説明いただけると幸いです。 よろしくお願いします。 Re: Inquiry Regarding JTAG Debugger Support for LX2082A 1. CodeWarriorの機能が停止します。 2. いいえ。 3. いいえ。有効な免許証が必要です。 4. LinuxのデバッグはJTAGデバッグなしで動作しますが、各ボードでのDDR検証や初回フラッシュはCodeWarrior IDEとJTAGデバッガ(CW TAP)を使うべきです。

S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd Sort out the logic and rewrite: As the title suggests, when I enabled eMCEM_1 in the app code, downloading the app using the official bootloader failed. If I didn't erase the chip, I couldn't enter the boot again, and even after powering it back on, it wouldn't solve the problem. I suspect that after powering it back on, the boot jumped to the app, but the app didn't run. When I disable eMCEM_1, this issue does not occur. How can I use boot to flash the app when eMCEM_1 is enabled Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd Hi @XPW, The problem description is not entirely clear. If the application is being programmed through the bootloader, the eMCEM_1 configuration contained in the application should not affect the programming process itself, since the application is not executed during download, it is just a binary. Only after the bootloader transfers execution to the application would eMCEM/FCCU-related configuration become relevant, and at that point, it would be useful to check: FCCU status registers DCM flags, MC_RGM flags. Or whether the application actually reaches main() Based on the current description, it is unclear whether the programming operation fails, or whether programming succeeds and the issue occurs later when the application starts executing. Could you clarify the exact sequence of events? Regards, Daniel Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd After my investigation, I found that some global variables were not initialized as defined when was enabled 。 Select a portion for explanation： Firstly, when I haven't enabled the target Clock_ip. c under RTD file Power_ip. c under RTD file Can initialize correctly。 However, when I activated it： Clock_ip. c under RTD file Power_ip. c under RTD file Global variable initialization failed。 May I ask if there is a better solution? Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd Hi @XPW, Based on what I see in the screenshots, the variables are initialized correctly at first. However, after the eMCEM initialization, Clock_Ip_pfkNotificationsCallback contains an invalid pointer. eMCEM does not magically change the pointer value. This looks much more like one of the following issues: Startup initialization (.data copy / .bss initialization) is not completed correctly. RAM corruption occurs before main(). Linker sections overlap. Stack corruption. Can you test it with the linker file from the SPD demo project? BR, Daniel Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd The link file has been modified for the following. I have defined three global variables： I found that when is not enabled, after executing init_data-bss, It seems to be aligned with 4 bytes and assigned correctly. But when I enable , after executing init_data-bss It doesn't seem to be aligned. Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd What is the cause of this phenomenon and how should I investigate and solve it. Re: S32K344 chip, failed to download using bootloader after adding eMCEM_1 module in spd HI @XPW, Based on the screenshots, I am not convinced there is actually a problem with the variable initialization itself. variable_a is an 8-bit variable, and enabling eMCEM will introduce additional variables, which can change the layout of the .data section. Therefore, seeing the variables at different offsets is expected and does not by itself indicate corruption. I think the key question is whether the issue occurs when the application is run standalone, or only when it is programmed and started through the bootloader. Can you reproduce the issue when programming the application directly with the debugger and running it without the bootloader? If the problem only occurs after loading the application through the bootloader, then the investigation should focus on the bootloader programming process, image layout, or bootloader handover rather than the application itself. BR, Daniel

LS1046A 10GB SFP+ Configuration on kernel 6.12 Hello,  I have a custom board with the LS1046A, and I'm trying to use fm1-mac9 with a soldered SFP+ 10GB module.  My RCW in SERDES 1 is 0x1040:  So 10GB in fm1-mac9 is well covered from the RCW's perspective. Looking at the SFP power and laser everything seems healthy, but I can't seem to get it to talk/link with the sfp in front of it, so I suspect my DTB configuration is incorrect.  This is my current configuration for that MAC:  xfi10g: ethernet@f0000 {   status = "okay";   pcsphy-handle = <&pcsphy6>;   pcs-handle = <&pcsphy6>;   pcs-handle-names = "xfi";   phy-connection-type = "10gbase-r";   fixed-link {     speed = <10000>;     full-duplex;   }; }; mdio@f1000 {   status = "okay";   pcsphy6: ethernet-phy@0{     compatible = "fsl,lynx-pcs";     reg = <0x0>;   }; }; sfp_mac9: sfp {   compatible = "sff,sfp";   i2c-bus = <&i2c3>;   status = "okay"; }; For reference, I'm running linux-qoriq kernel 6.12, and the SFP probes correctly during boot reading its EEPROM. Do you have a proper example of running this type of connection in fm1-mac9? 

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?

IW612 蓝牙射频测试 大家好， 我正在尝试对基于 IW612 的模块执行射频测试。为此，我参考了几份文件，例如： AN14310 - NXP 蓝牙 UART 驱动程序集成 AN14114 - Linux 操作系统上的射频测试模式 AN14163 - 蓝牙直连测试模式 还有其他人。 我遇到了一些问题： - 在 5 GHz Wi-Fi 频段中，我无法看到低频信道（接近 5 GHz）生成的波形，只能看到高频信道生成的波形。 - 对于蓝牙，我无法生成经典蓝牙的波形，只能生成 BLE 的波形（使用 hcitool 进行扫描和获取配对信息的命令运行正常，因此我认为这不是硬件问题）。 我的配置中，我使用的是 SoM Variscite Dart IMX8M（版本 2.0），配备基于 IW612 的 2EL 无线电。为了获取波形，我使用了 HackRF。 我使用的是内核版本为 6.6.23 的系统。Yocto 定制版本，固件为 sduart_nw61x_v1.bin.se，默认版本 HCI 命令的反馈与文档相符，但我看不到波形。如果我在系统或生成流程中遗漏了什么，请您帮忙看看。这是认证流程的一部分，现在我卡在这里了。 非常感谢 Re: IW612 Bluetooth RF Test Hello 能否将测试命令和结果截图分享给我们？ 顺祝商祺！ 肖恩 Re: IW612 Bluetooth RF Test 你好，肖恩， 当然。我运行了这些 hcitool 和 wifi 命令，并将最终的配置文件附在后面。 适用于蓝牙经典 ------------------------------------ 这些指令直接摘自 UM11490（第 149 页）。 # RESET root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令：ogf 0x03，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 0C 00 # 启用扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 03 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令：ogf 0x03，ocf 0x0005，plen 3 02 00 02 > HCI 事件：0x0e plen 4 01 05 0C 00 # 进入测试模式 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令：ogf 0x06，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 18 00 # 启动TX变速器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0x0e plen 4 01 19 FC 00 # 停止TX传输 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 39 00 00 00 -------------------- 在发送数据之前停止对蓝牙低功耗 (BLE) 和经典蓝牙 (Classic) 的扫描 ---------------- # RESET root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0003 < HCI 命令：ogf 0x03，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 0C 00 # 启用扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 03 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 启用事件过滤器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI 命令：ogf 0x03，ocf 0x0005，plen 3 02 00 02 > HCI 事件：0x0e plen 4 01 05 0C 00 # 进入测试模式 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x06 0x0003 < HCI 命令：ogf 0x06，ocf 0x0003，plen 0 > HCI 事件：0x0e plen 4 01 03 18 00 # 禁用蓝牙扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCI 命令：ogf 0x03，ocf 0x001a，plen 1 00 > HCI 事件：0x0e plen 4 01 1A 0C 00 # 禁用经典扫描 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCI 命令：ogf 0x08，ocf 0x000c，plen 2 00 00 > HCI 事件：0x0e plen 4 01 0C 20 00 # 启动TX变速器 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0x0e plen 4 01 19 FC 00 # 停止TX传输 root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 63 07 00 00 ** 在进入测试模式前禁用扫描时，TX 传输停止会显示以下信息： root@oaslv:/home/hexagon# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI 命令：ogf 0x3f、ocf 0x0019、plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI 事件：0xff plen 6 19 01 ED 04 00 00 适用于 5 GHz Wi-Fi -------------------------------------------------------------------------------- 参数：连续发射，带宽 = 40 MHz，802.11ac无DFS，CH = 40，MCS0（13.5），功率 = 14 dBm root@oaslv:/home/hexagon# cat /proc/mwlan/adapter0/config 硬件状态=0 netlink_num=31 驱动模式=7 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 接收天线=1 band=1 bw=1 频道=44 radio_mode[0]=3 radio_mode[1]= 总处方药包数=0 接收多播/广播数据包计数=0 接收函数调用错误数据包计数=0 发射功率=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 触发帧=0 otp_mac_add_rd_wr= 00:00:00:00:00:00

NXP S32K144 - オートモーティブの入門ガイド こんにちは、 私はNXP S32K144シリーズを初めて使用するので、開発環境をセットアップするための詳細な手順が必要です。もう少し詳しく教えていただけますか:   S32 Design Studioのどのバージョンが必要ですか? 標準 のSDK をインストールするべきか、 RTM/RTD のドライバーをインストールするべきか、どちらが良いでしょうか? この特定のハードウェアシリーズにはどんな追加の ドライバやソフトウェアパッケージ が必要ですか? S32K1 Re: Getting started guide for NXP S32K144 - Automotive こんにちは、 @Buddynさん 特に技術を使い始めたばかりの方は、最新のソフトウェアリリースやツールのバージョンを常におすすめします。 S32K1デバイス向けの最新ソフトウェアリリースはRTD 3.0.0です。これはS32 Design Studio(S32DS)3.6.6で開発・検証されました。しかし、私の経験では、より新しいS32DS 3.6.xでも問題なく動作します。バージョン。したがって、最新のS32DS 3.6リリースをダウンロードして使用することをお勧めします。 これでプラットフォームの使い始めには十分でしょう。追加で必要になるソフトウェアパッケージは、アプリケーションの具体的な要件によって異なります。 S32K1デバイス向けの他のソフトウェアパッケージや例を探りたい場合は、 S32K1リファレンスソフトウェアへアクセスできます。 BR、VaneB Re: Getting started guide for NXP S32K144 - Automotive このRTDベースのソフトウェアについて。それに関するオープンソースのファームウェアのサンプルはありますか？ NXPにはs32DSの設定(クロック、ピン、ペリフェラル)に関するリファレンスやトレーニングセクションはありますか?もしそうなら、参考リンクを教えてください。 前もって感謝します

MCXW72 Matterロックの例として、Aliroミドルウェアの制御アクセスリクエスト NXPサポートの皆様、 私はルーヴェン・カトリック大学／COSICで応用暗号学の博士研究員をしています。私はCSA Aliro 1.0 Reader SDKの学術実装、セキュリティ、相互運用性に関する研究を行っています。 ダウンロードしました： MCUXpresso SDK 26.06.00 for MCX-W72-EVK; 対応するMCUXpresso設定ツールパッケージ、 mcuxsdk-examples-マター-release-v1.4.2; NXPのMatterのlock-app-aliroの例です。 マターの例では、以下の制御ミドルウェアが求められます: > /middleware/aliro/aliro_sdk.cmake しかし、AliroミドルウェアはMCXW72 SDK Builderパッケージやマターの例アーカイブには含まれていません。 MCUXpresso SDK 26.06.00およびMatter Aliroロックの例に対応したAliroミドルウェアパッケージの完全なアクセスを教えていただけますか? 当該資料は、許可された学術分析のみに使用され、適用されるライセンスまたは秘密保持契約に従って取り扱われます。 敬具、 サヨン・ダッタグプタ ポスドク研究員 COSIC、ルーヴェン・カトリック大学   セキュリティ（EdgeLock | セキュアブート | OTP）

DSP Implementation: Microcontrollers or FPGAs Hi, I know this is a topic which has come up again and again on this sub, but I just needed some domain-specific advice from the people in the field here. What I wanted to know is that, if am interested in the DSP applications in Communications field and want to work on implementations for the same, is it worthwhile spending my time learning about microcontroller programming? Am an ECE undergrad, so I was wondering if I should directly focus on FPGAs, which are more interesting to me, honestly. I am confused because I have seen people recommend that you really do need embedded software programming skills to work with the SOCs that are being used more and more now. Really apologise if it's a redundant question! I just haven't been able to find a proper answer regarding the same, and am at a point right now where I might have to prioritise things just a tad bit. Would really appreciate any advice!

IMXRT EDMAエラーIRQハンドラはSDKには実装されていません こんにちは、 SDK内のIMXRT EDMA APIは「ハッピーケース」割り込みを正しく処理しているようです。しかし、エラー割り込みを処理するための仕組みは見当たらないようだ。それだけでなく、すべてのDMAに対して1つのグローバルなDMA_ERROR_IRQHandlerが存在するようです。例えばDMA0とDMA1の両方を使っている場合、状況が「良好」な状態にあるときにDMA0/DMA1のIRQHandlerが呼び出され、SDKがどのDMAがハッピーインタラプトを受け取ったかを識別できます。しかし、DMAエラーが発生した場合、グローバルなエラー割り込みハンドラが1つしかないため、どのDMA（0、1、またはその他）でエラーが発生したかを簡単に知る方法はありません。 以前の質問で、LPUARTエラーIRQ処理について質問したのと同様です。なぜこれがSDKに組み込まれていて、DMAエラーを処理したり適切なコールバックを呼び出したりしないのでしょうか?今は、エラーがどのDMAにあるかを手作業で特定し、SDK外の特別な処理を呼ぶ方法を考えなければなりません。単にコールバックを呼んでもらうのではなく。 本番コードで使えるはずのSDKにしては、堅牢性の機能が欠けているように思えますし、多くの人はこれらのエラーがSDKによって処理されていると思い込んでいて、実際にはそうではないという事実を考えていないのだと思います。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 どのi.MX RTデバイスをお使いですか？DMA0とDMA1の話ですが、2つのDMAコントローラペリフェラルではなく、2つのDMAチャネルのことを指していますか? すべての i.MX RTデバイスに2つのeDMAコントローラーがあるわけではありません。例えば： i.MX RT1180には2つのeDMAコントローラが含まれています。スタートアップファイル(例:startup_mimxrt1189_cm33.c)には、DMA_ERROR_IRQHandlerとDMA4_ERROR_IRQHandlerの2つのDMAエラーハンドラがあります。 i.MX RT1050にはeDMAコントローラが1つしかありません。起動ファイル（例えば、startup_mimxrt1052.c）では、DMAエラーハンドラはDMA_ERROR_IRQHandlerという1つだけです。 一般的に、DMAエラーは比較的まれなイベントです。ハードウェアアーキテクチャの観点からは、チャネルエラーの状態はモジュールレベルのエラー要求に集約され、DMAエラー割り込みを引き起こします。したがって、ソフトウェアは各チャネルのエラーステータスレジスタ(例えばCHn_ES)を調べ、どの特定のチャネルがエラーを引き起こしたかを特定しなければなりません。 よろしくお願いいたします。 シェリー・チャン Re: IMXRT EDMA error IRQ handler is not implemented in the SDK すみません、チャネルのことを言いました。私はIMXRT1172を使用しています。 もし使っていた周辺機器に問題があった場合、DMAエラーは起こるのではないでしょうか?つまり、LPSPIとDMAを組み合わせた場合、SPIエラーが発生するとDMAエラーも発生するのではないでしょうか？そうでない場合、DMA使用時のSPIエラーはSPIエラー割り込みをトリガーしますか？ ありがとうございます -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 いいえ。DMA使用中に周辺エラーが発生しても、必ずしもDMAコントローラ自体がエラーを報告するわけではありません。ほとんどの場合、SPIエラーとDMAエラーは2つの別々のステータスおよび割り込み機構で処理されます。 DMAは、DMA、バス、または転送層のエラーのみを報告します。LPSPIにおけるプロトコルレベルまたはFIFO関連のエラーは、LPSPIペリフェラル自身のステータスフラグやエラー割り込みを通じて処理されるべきです。DMAモードで動作させた場合でも、すべてのSPIエラーが自動的にDMAエラーに変換されるわけではありません。 よろしくお願いいたします。 シェリー・チャン Re: IMXRT EDMA error IRQ handler is not implemented in the SDK やはりそうだったか。その場合、SDKの転送APIはさらに堅牢性が低くなります。SDK外でペリフェラルやDMAエラーを処理しなければならない場合、デフォルトのIRQハンドラをやや巧妙にオーバーライドしたり、エラープロセッシング後もSDKハンドラーに呼び出すようにするなど、かなりの追加作業が必要です。これらの機能がSDKの転送APIに含まれていないのは非常に落胆します。 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 ご懸念は理解できますし、SDKトランスファーAPIと別にペリフェラルエラーを扱うことで必要なアプリケーションレベルのコード量が増えることに同意します。ご意見ありがとうございます。皆さんのご意見はSDKチームにお伝えします。 よろしくお願いいたします。 シェリー・チャン Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 実際は、思っていたよりもひどい。EDMA LPSPI転送APIを使用すると、LPSPI_MasterTransferEDMAが呼び出す関数LPSPI_PrepareTransferEDMAがすべてのSPI割り込みを無効にするため、SPIエラーを捕捉できなくなります。そのため、エラー割り込みを呼び出し前に有効にすることは不可能で、再度無効化され、SPI EDMA転送がすでに進行中なので遅すぎます。これはこのAPIの重大なバグです。 -m

Request for controlled-access Aliro middleware for MCXW72 Matter lock example Dear NXP Support, I am a postdoctoral researcher in applied cryptography at KU Leuven/COSIC. I am conducting an academic implementation-security and interoperability study of CSA Aliro 1.0 Reader SDKs. I downloaded: MCUXpresso SDK 26.06.00 for MCX-W72-EVK; the corresponding MCUXpresso Config Tools package; mcuxsdk-examples-matter-release-v1.4.2; the NXP Matter lock-app-aliro example. The Matter example expects the following controlled middleware: >  /middleware/aliro/aliro_sdk.cmake However, the Aliro middleware is not present in the MCXW72 SDK Builder package or in the Matter example archive. Could you please provide access to the complete Aliro middleware package compatible with MCUXpresso SDK 26.06.00 and the Matter Aliro lock example? The material will be used solely for authorised academic analysis and will be handled according to any applicable licence or NDA. Kind regards, Sayon Duttagupta Postdoctoral Researcher COSIC, KU Leuven   Security(Edgelock | secure boot | OTP)

SDK 中未实现 IMXRT EDMA 错误 IRQ 处理程序。 您好， SDK 中的 IMXRT EDMA API 似乎能够正确处理“正常情况”中断。然而，似乎没有任何处理错误中断的机制。不仅如此，似乎所有 DMA 都只有一个全局的 DMA_ERROR_IRQHandler。因此，如果您同时使用 DMA0 和 DMA1，当一切正常时，DMA0/DMA1 IRQHandler 将被调用，SDK 可以区分哪个 DMA 收到了正常中断。但是，如果出现 DMA 错误，由于只有一个全局错误中断处理程序，因此没有简单的方法可以知道错误发生在哪个 DMA（0 或 1 或其他）上。 就像我之前关于 LPUART 错误 IRQ 处理的问题一样。为什么 SDK 没有内置处理 DMA 错误并调用相应回调的功能？现在我必须手动确定错误发生在哪个 DMA 上，并在 SDK 之外调用特殊处理，而不是让它为我调用回调。 对于一个本应在生产代码中使用的 SDK 来说，似乎缺少很多健壮性功能，我敢打赌大多数人只是假设这些错误是由 SDK 在底层处理的，而没有考虑到它们实际上并没有被处理。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 您使用的是哪款 i.MX RT 设备？当您提到 DMA0 和 DMA1 时，您指的是两个 DMA 通道，还是两个 DMA 控制器外设？ 并非所有 i.MX RT 设备都具有两个 eDMA 控制器。例如： i.MX RT1180 包含两个 eDMA 控制器。在启动文件（例如 startup_mimxrt1189_cm33.c）中，您可以找到两个 DMA 错误处理程序：DMA_ERROR_IRQHandler 和 DMA4_ERROR_IRQHandler。 i.MX RT1050 仅包含一个 eDMA 控制器。在启动文件（例如 startup_mimxrt1052.c）中，只有一个 DMA 错误处理程序：DMA_ERROR_IRQHandler。 一般来说，DMA 错误是相对不常发生的事件。从硬件架构的角度来看，通道错误状态被聚合为模块级错误请求，从而触发 DMA 错误中断。因此，该软件必须检查每个通道的错误状态寄存器（例如，CHn_ES），以确定哪个特定通道导致了错误。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 抱歉，我指的是频道。我使用的是 IMXRT1172。 如果与之连接的外设出现问题，难道不会发生DMA错误吗？也就是说，如果是 LPSPI 和 DMA，那么任何 SPI 错误都会导致 DMA 错误吗？如果不是，那么在使用DMA时，SPI错误是否会触发SPI错误中断？ 谢谢！ -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 不。在使用DMA时发生的外围设备错误并不一定意味着DMA控制器本身会报告错误。大多数情况下，SPI 错误和 DMA 错误由两个独立的状态和中断机制处理。 DMA 只报告 DMA 层、总线层或传输层错误。LPSPI 中的协议级或 FIFO 相关错误应通过 LPSPI 外设自身的状态标志和错误中断来处理。以 DMA 模式运行并不会自动将所有 SPI 错误转换为 DMA 错误。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 我猜也是这样。在这种情况下，SDK 的传输 API 就更不可靠了。必须在 SDK 之外处理外围设备和 DMA 错误，这需要相当多的额外工作，包括对默认 IRQ 处理程序进行一些变通的覆盖，并确保它们在处理任何错误后仍然调用 SDK 处理程序。令人沮丧的是，这些内容并未包含在 SDK 传输 API 中。 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 尊敬的@nxp16 ， 我理解您的担忧，我也同意将外围错误状态的处理与 SDK 传输 API 分开处理可能会增加所需的应用程序级代码量。感谢您的反馈。我会将您的意见转达给SDK团队。 顺祝商祺！ 张雪莉 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK 实际上，情况比我想象的还要糟糕。使用 EDMA LPSPI 传输 API 无法捕获 SPI 错误，因为 LPSPI_MasterTransferEDMA 调用的函数LPSPI_PrepareTransferEDMA会禁用所有 SPI 中断。因此，在调用它之前不可能启用错误中断，因为它会再次禁用它们，而之后就太晚了，因为 SPI EDMA 传输已经开始了。这是该API的一个重大漏洞。 -m

Assistance Required for VSC8254 PHY Bring-up in 1G SGMII Mode on LX2160A Hello everyone, We are working on a custom board based on the LX2160A Rev2 SoC, where the VSC8254 PHY is connected to the SoC through eMDIO1. We are currently facing issues while bringing up the PHY in 1G SGMII mode. So far, we have successfully brought up the PHY in 10G XFI mode by configuring a fixed link in both the DPC file and the Linux kernel Device Tree. After booting, we execute the NXP-provided mdio_cl45_write script to program the required Clause 45 registers, following which the link comes up and operates correctly. However, when we switch the configuration to 1G SGMII mode, we make the following changes: Update the DPC and Linux Device Tree to use SGMII instead of XFI. Execute the corresponding Clause 45 register initialization sequence for 1G. Update the SERDES reference clock from 125 MHz to 100 MHz, as required for the new configuration. Despite these changes, the PHY link does not come up. For reference: The VSC8254 PHY is connected to SERDES1 MAC3 and MAC4. We are using RCW 6 for the 10G XFI configuration. We are using RCW 4 for the 1G SGMII configuration. Could you please let us know if there are any additional configuration changes or initialization steps required to bring up the PHY in 1G SGMII mode? Thank you for your time and support. @yipingwang @chenyin_h  Re: Assistance Required for VSC8254 PHY Bring-up in 1G SGMII Mode on LX2160A 1. Please configure RCW[SRDS_PLL_REF_CLK_SEL_S1] as "00". 2. In Linux Kernel, please configure "CONFIG_VITESSE_PHY". 3. In Linux Kernel dts file arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts, please modify dpmac3 and dpmac4 configuration similar as the following. &dpmac3 { phy-handle = <&aquantia_phy1>; phy-connection-type = "usxgmii"; managed = "in-band-status"; }; aquantia_phy1: ethernet-phy@4 { /* AQR107 PHY */ compatible = "ethernet-phy-ieee802.3-c45"; interrupts-extended = <&extirq 2 IRQ_TYPE_LEVEL_LOW>; reg = <0x4>; }; Modify to: &dpmac3 {         phy-handle = <&sgmii_phy1>;         phy-connection-type = "sgmii";         managed = "in-band-status"; };         sgmii_phy1: ethernet-phy@xx{                 reg = <0xxx>;//specify dpmac3 related MDIO PHY address         }; 4. Please modify dtc file dpc-usxgmii.dts as the following.        board_info {                 ports {                         mac@3 {                                 link_type = "MAC_LINK_TYPE_PHY";                                 enet_if = "USXGMII";                         };                         mac@4 {                                 link_type = "MAC_LINK_TYPE_PHY";                                 enet_if = "USXGMII";                         }; Modify to:         board_info {                 ports {                         mac@3 {                                 link_type = "MAC_LINK_TYPE_PHY";                         };                         mac@4 {                                 link_type = "MAC_LINK_TYPE_PHY";                         };

VR5510：即使启用异步模式，I2C 看门狗刷新也会在 ISR 中阻塞——这是真正的非阻塞支持 您好，NXP团队， 我目前正在调试 VR5510 PMIC，遇到了与看门狗刷新相关的实时调度问题。 MCAL I2C 看门狗刷新（通过 I2C 向 VR5510 看门狗提供数据）的实现方式如下： 同步 手术。由于我们是在中断上下文中调用它，因此同步等待会阻塞 CPU，并降低其他任务的实时调度性能。 我注意到有一个 异步 驱动程序配置/代码中的选项。然而，实际上它仍然执行同步忙等待（它会阻塞并轮询，直到 I2C 传输完成），因此它实际上并没有将传输与调用者解耦。 我的问题： 是否有官方支持的方法可以刷新 VR5510 看门狗？ 真正无阻塞 （例如是否采用中断驱动或DMA驱动的I2C协议，以避免阻塞其他任务？ 如果异步选项预期是非阻塞的，那么当前的同步忙等待行为是已知的限制还是我的配置问题？ 任何指导、参考配置或示例代码都将不胜感激。 谢谢！ Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s 你好， @Jerry_cao 感谢分享。 请问您指的是以下使用的 API 吗？ Std_ReturnType I2c_AsyncTransmit ( uint8 Channel, const I2c_RequestType ∗ RequestPtr ) “？ 使用的是哪个版本的RTD？ BR 陈银 Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s 你好： 我的版本是：   * 项目：RTD AUTOSAR 4.4 * 平台：CORTEXM * 外设：VR5510 * 依赖项：无 * * Autosar 版本：4.4.0 * Autosar 版本：ASR_REL_4_4_REV_0000 * Autosar 配置变体： 软件版本：4.0.2 * 构建版本：S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) 版权所有 2020-2023 NXP 半导体 * 版权所有。 * 使用此函数 Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s 你好： 我的版本是：   * 项目：RTD AUTOSAR 4.4 * 平台：CORTEXM * 外设：VR5510 * 依赖项：无 * * Autosar 版本：4.4.0 * Autosar 版本：ASR_REL_4_4_REV_0000 * Autosar 配置变体： 软件版本：4.0.2 * 构建版本：S32_RTD_4_0_2_HF02_D2311_ASR_REL_4_4_REV_0000_20231103 * * (c) 版权所有 2020-2023 NXP 半导体 * 版权所有。 * 使用此函数 Pmic_VR55XX_TriggerWatchdog Re: VR5510: I2C watchdog refresh blocks in ISR even with async mode enabled – is true non-blocking s 你好， @Jerry_cao 谢谢您的确认。 通过与相应代码核对，RTD5.0.0QLP04 中实现了VR5510 的 I2C 异步通信解决方案。 您可以在此版本 RTD 中查看相关代码以了解详细信息。 BR 陈银

DSPの実装:マイクロコントローラまたはFPGA こんにちは、このサブで何度も話題になっている話題だと知っていますが、この分野の方々からドメイン特有のアドバイスが欲しかったのです。私が知りたかったのは、通信分野のDSPアプリケーションに興味があり、その実装に関わりたい場合、マイクロコントローラプログラミングを学ぶことに時間を費やす価値があるのかということです。私はECEの学部生なので、正直なところFPGAの方が興味があるので、直接集中すべきか悩んでいます。混乱しています。なぜなら、最近ますます使われているSOCを扱うには組み込みソフトウェアのスキルが必要だと勧める人を見たからです。 重複した質問でしたら、本当に申し訳ありません！それに関して適切な答えが見つからず、今は少し優先順位をつけなければならない状況にある。どんなアドバイスでもいただけると大変ありがたいです！

Getting started guide for NXP S32K144 - Automotive Hello, I am new to the NXP S32K144 series and need detailed instructions to set up my development environment. Could you please clarify:   Which version of S32 Design Studio is required? Whether I should install the standard SDK or the RTM/RTD drivers? What additional drivers or software packages are needed for this specific hardware series? S32K1 Re: Getting started guide for NXP S32K144 - Automotive Hi @Buddyn  We always recommend using the latest software releases and tool versions, especially if you are just getting started with the technology. For S32K1 devices, the latest software release is RTD 3.0.0, which was developed and validated with S32 Design Studio (S32DS) 3.6.6. However, based on my experience, it also works well with newer S32DS 3.6.x versions. Therefore, I would recommend downloading and using the latest available S32DS 3.6 release. This should be enough to get you started with the platform. Any additional software packages you may need will depend on your application's specific requirements. To explore other software packages and examples available for S32K1 devices, you can navigate to S32K1 Reference Software. BR, VaneB Re: Getting started guide for NXP S32K144 - Automotive For this RTD based software. Is there is any open-source firmware example for it. Does NXP has any reference or training sections for configurations (clock, pins, peripheral) in s32DS. If so, kindly share some reference link.  Thanks in advance

IMXRT EDMA error IRQ handler is not implemented in the SDK Hi, The IMXRT EDMA API in the SDK seems to handle "happy case" interrupts correctly.  However, there doesn't seem to be any provision for handling error interrupts.  Not only that, but it appears there is one global DMA_ERROR_IRQHandler for all DMA.  So if you're using both DMA0 and DMA1, when things are "happy" the DMA0/DMA1 IRQHandler would be called and the SDK can distinguish which DMA got the happy interrupt.  However, if there's a DMA error, since there's one global error interrupt handler, there's no easy way to know which DMA (0 or 1 or whatever) the error happened on. As in my previous question about LPUART error IRQ handling.  Why isn't this baked into the SDK to handle DMA errors and call appropriate callbacks?  Now I have to figure out how to determine which DMA the error is on by hand and call special handling outside the SDK instead of just having it call a callback for me. For an SDK that is supposed to be usable in production code, there seem to be a lot of missing robustness features, and I'm betting most people are just assuming these errors are handled under the hood by the SDK, and they don't think about the fact that they really aren't. -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Dear @nxp16 , Which i.MX RT device are you using? When you mention DMA0 and DMA1, are you referring to two DMA channels rather than two DMA controller peripherals? Not all i.MX RT devices have two eDMA controllers. For example: i.MX RT1180 contains two eDMA controllers. In the startup file (for example, startup_mimxrt1189_cm33.c), you can find two DMA error handlers: DMA_ERROR_IRQHandler and DMA4_ERROR_IRQHandler. i.MX RT1050 contains only one eDMA controller. In the startup file (for example, startup_mimxrt1052.c), there is only one DMA error handler: DMA_ERROR_IRQHandler. In general, DMA errors are relatively infrequent events. From the hardware architecture perspective, channel error status is aggregated into a module-level error request, which triggers the DMA error interrupt. Therefore, the software must examine each channel's error status register (for example, CHn_ES) to determine which specific channel caused the error. Best Regards, Shelly Zhang Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Sorry, I meant channel.  I'm using IMXRT1172. Wouldn't DMA errors occur if there was a problem with whatever peripheral it was being used with?  I.e. if it was LPSPI with DMA wouldn't any SPI errors cause a DMA error?  If not, then do SPI errors when using DMA trigger a SPI error interrupt? Thanks, -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK I figured as much.  In that case, the SDK's transfer API is even less robust.  Having to handle peripheral and DMA errors outside the SDK requires quite a bit of extra work, including somewhat hacky overriding of the default IRQ handlers and making sure they still call into the SDK handlers after processing any errors.  The fact that this stuff isn't part of the SDK transfer API is very discouraging. Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Dear @nxp16 , No. A peripheral error occurring while using DMA does not necessarily mean that the DMA controller itself will report an error. In most cases, SPI errors and DMA errors are handled by two separate status and interrupt mechanisms. DMA reports only DMA-, bus-, or transfer-layer errors. Protocol-level or FIFO-related errors in LPSPI should be handled through the LPSPI peripheral's own status flags and error interrupts. Operating in DMA mode does not automatically convert all SPI errors into DMA errors. Best Regards, Shelly Zhang Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Dear @nxp16 , I understand your concern, and I agree that handling peripheral error conditions separately from the SDK transfer API can increase the amount of application-level code required. Thank you for the feedback. I will pass your comments to the SDK team. Best Regards, Shelly Zhang Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Actually, it's worse than I thought.  Using the EDMA LPSPI transfer API makes it impossible to catch SPI errors because the function that LPSPI_MasterTransferEDMA calls, LPSPI_PrepareTransferEDMA. disables ALL SPI interrupts.  So it's impossible to enable the error interrupts before calling it, because it disables them again, and it's too late afterward because the SPI EDMA transfer is already taking place.  This is a major bug in this API. -m

请求为 MCXW72 Matter 锁示例提供受控访问的 Aliro 中间件 尊敬的NXP技术支持： 我是鲁汶大学/COSIC应用密码学专业的博士后研究员。我正在进行一项关于 CSA Aliro 1.0 Reader SDK 的学术实施安全性和互操作性研究。 我下载了： MCUXpresso SDK 26.06.00 for MCX-W72-EVK; 相应的 MCUXpresso 配置工具包； mcuxsdk-examples-matter-release-v1.4.2 ； NXP Matter lock-app-aliro 示例。 Matter 示例需要以下受控中间件： > /middleware/aliro/aliro_sdk.cmake 但是，Aliro 中间件并未包含在 MCXW72 SDK Builder 包或 Matter 示例存档中。 能否提供与 MCUXpresso SDK 26.06.00 和 Matter Aliro 锁示例兼容的完整 Aliro 中间件包？ 该材料将仅用于经授权的学术分析，并将根据任何适用的许可或保密协议进行处理。 亲切的问候， 萨永·杜塔古普塔 博士后研究员 鲁汶大学 COSIC   安全（Edgelock | 安全启动 | OTP）

NXP S32K144 汽车入门指南 你好， 我是NXP S32K144系列的新手，需要详细的说明来设置我的开发环境。请问您能否澄清一下：   需要哪个版本的S32 Design Studio ？ 我应该安装标准SDK还是RTM/RTD驱动程序？ 该系列硬件需要哪些额外的驱动程序或软件包？ S32K1 Re: Getting started guide for NXP S32K144 - Automotive 嗨@Buddyn 我们始终建议使用最新的软件版本和工具版本，尤其是在您刚开始接触这项技术时。 对于S32K1设备，最新软件版本为RTD 3.0.0。该软件采用 S32 Design Studio (S32DS) 3.6.6 开发和验证。不过，根据我的经验，它也适用于较新的 S32DS 3.6.x 版本。版本。因此，我建议下载并使用最新的 S32DS 3.6 版本。 这些应该足以让你开始使用该平台了。您可能需要的任何其他代码包，软件包将取决于您的应用程序的具体要求。 要探索其他可用于 S32K1 设备的软件包和示例，您可以访问S32K1 参考软件。 BR，VaneB Re: Getting started guide for NXP S32K144 - Automotive 适用于基于RTD的软件。是否有相关的开源固件示例？ NXP 是否有关于 s32DS 配置（时钟、引脚、外设）的参考资料或培训资料？如果可以的话，请提供一些参考链接。 提前致谢