Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
30日間無料トライアルライセンスはどこで入手できますか? チームの皆さん、こんにちは。 NXP MCALの30日間無料トライアルライセンスを探しています。 以前は、私は道を見つけることができた。しかし、ウェブサイトが更新されたため、ライセンスリンクがなくなってしまいました。 ライセンスを教えてもらえますか?私はEB 29.0とRTD 6.0.0を使用しています。 緊急のことなので、すぐにサポートをいただけますか? BRとありがとう、 志陽 Re: Where to find the free-trial license for 30days? こんにちは、ロビンさん。 どうもありがとう! BR、 志陽 Re: Where to find the free-trial license for 30days? こんにちは、紫陽さん SW32K3_S32M27x_RTD_R21-11_6.0.0_D2506_ReleaseNotes.pdfの「 2.4.1 EB Tresos 」セクションには、以下の記述があります。 モジュール構成は、Tresos構成ツールバージョン「EB Tresos Studio 29.0.0 b220329-0119」を使用して開発およびテストされました。 ですので、どうぞ Eb Tresos Studio 29.0.0 b220329-0119 をクリックでダウンロードしてください S32K3 標準ソフトウェア - > オートモーティブ SW - EB tresos Studio / AUTOSAR 設定ツール - > EB tresos Studio 29.0.0 よろしくお願いいたします ロビン
View full article
imx-optee-osをソースコードからビルドして、それをuboot FITイメージに統合するにはどうすればよいですか? 私はi.MX8MP SoCを使用しています。私はhttps://github.com/nxp-imx/imx-optee-os.gitから imx-optee-os のソースコードをクローンし、lf-6.6.36_2.1.0 ブランチをチェックアウトしました。imx-optee-oをどのように構築して、それをflash.binにパッケージ化すればいいのでしょうか画像? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: How do I build imx-optee-os from source and integrate it into the uboot FIT image? こんにちは、 どのBSPバージョンを使っているのか正確にはわかりませんが、i.MX Linuxユーザーガイドのセクション4.5.13をぜひご覧くださいimx-mkimageを使ってimx-bootイメージを構築する方法と、i.MX 8M EVKセクション(i.MX8Mがファミリ)を探す Linuxのドキュメント: https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX i.MX Linuxユーザーガイド: https://www.nxp.com/docs/en/user-guide/UG10163.pdf よろしくお願いいたします。 アルド。
View full article
Where to find the free-trial license for 30days? Hi team, i am looking for a 30days free-trial license for NXP MCAL. In the past i was able to find the path. but now the website is updated and i lost the license link. Could you please share me the license? i am using EB 29.0 with RTD 6.0.0. It's urgent for me, could you please have quick support? BR and thx, Zhiyang Re: Where to find the free-trial license for 30days? Hi Robin, thx a lot! BR, Zhiyang Re: Where to find the free-trial license for 30days? Hi Zhiyang, The section "2.4.1 EB Tresos" of SW32K3_S32M27x_RTD_R21-11_6.0.0_D2506_ReleaseNotes.pdf mentions: Modules configurations were developed and tested using the Tresos Configuration Tool version "EB Tresos Studio 29.0.0 b220329-0119" So please download the EB Tresos Studio 29.0.0 b220329-0119 by click  S32K3 Standard Software -> Automotive SW - EB tresos Studio / AUTOSAR Configuration Tool -> EB tresos Studio 29.0.0 Best Regards, Robin
View full article
S32DS3.4 Could you provide a download link and activation key for S32DS3.4? Re: S32DS3.4 OK, thanks Re: S32DS3.4 Hi@ DontUnderstandRobots Click this to find older versions of the S32 DS. I haven't tested installing the SDK on the new version. If it's RTM 3.0.X, you can only use it on S32 DS V2.2. I haven't tried installing RTM 4.0.X on S32 DS V3.6. Re: S32DS3.4   Uh... why does clicking on version 3.4 redirect me to download version 3.5? So, S32DS V3.6 doesn't support the S32K1 series SDK version, right? Re: S32DS3.4 Hi@ DontUnderstandRobots Clicking the download button will take you to the download page, where you can see different S32 DS versions. For S32 DS V3.6, it depends on the software version you used to develop S32K1, whether it's the SDK or the RTD. If you are developing a new application and using RTD, this is fully supported. Re: S32DS3.4 The link you provided leads to this... Does S32DS v3.6 support the S32K146 chip? Re: S32DS3.4 Also, S32 DS V3.6 is compatible with older versions. Re: S32DS3.4 Hi@ DontUnderstandRobots Please provide me with a screenshot of your download page so I can take a look. Re: S32DS3.4 Your official website only has S32DS versions 3.5 and 3.6; I couldn't find version 3.4. Re: S32DS3.4 Hi@不懂机器人 Release is available for download on NXP web and from S32DS 3.4. Please make sure that you get new activation ID for this version.
View full article
MCXW71 - 2.4 GHzの共存/RFロバストネによる2 Mbpsのハーフデュプレックスでのパケットロスと不安定性 こんにちは、NXPコミュニティの皆さん、 現在、#MCXW71C ワイヤレスMCUを使ったプロジェクトに取り組んでいます。私は、2Mbpsのデータレートで動作する2つのMCXW71Cチップ間で、半二重通信プロトコルを開発しました。 クリーンなRF環境では通信は完全に安定していますが、スマートウォッチ、ワイヤレスイヤホン、Bluetooth対応スマートフォンなど他の2.4GHzのRFデバイスがハードウェアに近づくと(約30cm以内)深刻な不安定さと大幅なパケットロスが発生しています。 当社のシステムに関する重要な詳細情報は以下のとおりです。 ハードウェア:これはカスタムPCB設計(評価ボードではありません)。RFフロントエンド用のインピーダンス整合ネットワークは自ら設計・実装しました。 PHY / プロトコル: GENFSK NXP SDK Version: SDK_2.25.09.00_MCXW716C 周波数ホッピング:FHSSではありません 当社のカスタムボードは単独では動作しますが、混雑したRF環境では性能が低下するため、レシーバは隣接する2.4 GHzの干渉器によって感度が低下または飽和されている可能性があります。 何かアドバイスをいただけますか? MCXW71には、レシーバの選択性、AGC(自動ゲイン制御)挙動、またはノイズ環境でのLNAゲインを最適化するための特定のハードウェアチューニングガイドラインやレジスタはありますか? パケット衝突をより適切に処理するために推奨されるソフトウェア共存設定やCCA(クリアチャネル評価)閾値調整はありますか? カスタムインピーダンスネットワークのわずかな不一致が、強い帯域外・隣接干渉体が存在する場合に、トランシーバの選択性やブロッキング性能を低下させる可能性はありますか? ボード設計 Re: MCXW71 - Packet loss and instability at 2 Mbps half-duplex due to 2.4 GHz co-existence / RF robu こんにちは、 あなたの調子が良いといいのですが。   カスタムボードを使用しているとのことですので、同じ伝導試験設定でFRDM-MCXW71との性能比較を行うことをお勧めします。無線レジスタを改造する前に、RF配置、接地、アンテナ整合ネットワーク、電源ノイズ、そしてエンクロージャーに関連する結合効果などの要素を確認することが重要です。 また、CCAの閾値をスイープしながらPERテストを行い、実用的な運用点を見つけることもできます。CCAはチャネルがすでに混雑している場合の送信を防ぐことでパケット衝突の低減に役立ちますが、閾値は対象のRF環境で実証的に検証されるべきです。 以下の文書は、RF性能テストの手法とそれをCCAの挙動評価に使う方法を説明しています: AN14399 MCXW71 802.15.4 アプリケーション向け接続テスト RF設計のさらなる検証のために、以下の文書も役立つかもしれません: UG10146 MCXW71 ハードウェア設計ガイド AN14374 FRDM-MCXW71 Bluetooth LEおよびIEEE 802.15.4アプリケーション向けRFシステム評価報告書 AN2731 2.4GHz通信用小型平面アンテナ よろしくお願いします、 ソフィア。
View full article
BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS Hi, I am using NXP chip sd8987 (M2-JODY-W263-10C) with TI soc am62p. I am using android OS. a2dp is working, but hands free is not working. I have only 1 codec speaker. is there anything to be taken care from the pin perspective of M2-JODY-W263-10C (sd8987) module. Regards Roshan Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS Hi, @Roshan888  Can you please let me know what is your Android version? Did you use PCM/I2S interface for SCO on SD8987 M2-JODY-W263-10C module? Could you please provide me a full log from booting up your device and including the full A2DP connected but HFP could not work process? Best regards, Christine. Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS Hi Christine, I'm not using the pcm/i2s pin. Software HFP path over UART. I'm using TI am62p soc android version 16.  Attached the bluetooth_manager log. Regards Roshan Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS Hi, @Roshan888  Thanks for your dumpsys and your information. From your dumpsys, I see that the RFCOMM is already opened, and SCO is created successfully, also the handler has already been initiated. To debug further, can you please help to provide me: 1.Bluetooth HCI snoop log including the whole process including the full connection, A2DP connected but HFP could not work process? On Android, you can capture HCI logs by enabling Bluetooth HCI snoop log in Developer Options , toggling Bluetooth once to start capture, and then exporting the log with  adb  . Steps: Open Developer Options Enable Bluetooth HCI snoop log Toggle Bluetooth off and on once Trying to reproduce the issue. Pull the log file with ADB commands. 2. adb shell dumpsys media.audio_policy > audio_policy.txt adb shell dumpsys media.audio_flinger > audio_flinger.txt adb logcat -b all -d > logcat_log.txt (from booting up your device)   Best regards, Christine. Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS Hi, @Roshan888  Can you please help to provide the requested logs to move forward on this issue? Best regards, Christine. Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS Hi, @Roshan888  Does your issue resolved? Do you still need our support?  If yes, can you please help to provide the requested logs to move forward on this issue? Best regards, Christine.
View full article
imx93 为自定义目标构建 u-启动 我们正在使用 Yocto Scarthgap 开发新的 imx93 板。我们有一款与 EVK 上的 NXP SOM 非常相似的 SOM,以至于如果我将 EVK 的 SDIO 卡放到我们的板上,它就会启动。 为了避免与 Yocto 打交道带来的麻烦,我推出了 u-boot-imx,并使用 Yocto 的 SDK 将其制作成了独立版本。我可以成功地为 EVK 版本 u-boot 然后它就会启动。 所以对于我们的板来说,我: 添加了 板/freescale/imx93_nimbus/ 并在其中填充了 板/freescale/imx93_evk/ 的内容 修改了 imx93_evk.c到 imx93_nimbus.c 中、内容不变 修改了 Kconfig,用 Nimbus/Nimbus 替换 EVK/EVK 并将其添加到 arch/arm/mach-imx/imx/imx/imx9/KConfig 修改了 Makefile,将 EVK/evk 改为 NIMBUS/nimbus 添加了 arch/arm/dts/imx93-nimbus.dts,内容与 imx93-11x11-evk.dts 相同 添加了 include/configs/imx93_nimbus.h,将 EVK/evk 改为 NIMBUS/nimbus 从 imx93_11x11_evk_defconfig 添加 configs/imx93_nimbus_defconfig,唯一的区别是 devicetree 命名和 TARGET 命名 make imx93_nimbus_defconfig make 复制了 imx-启动-tools 并在其下创建了一个 imx93 目录 将 u-启动.bin 和 spl/u-启动-spl.bin 复制到 imx-启动-tools/imx93 cd 到 imx-启动-tools/imx93 make -f ./soc.mak flash_singleboot sudo dd if=flash.bin of=/dev/sdb bs=1k seek=32 conv=fsync 现在我有了 SDIO 卡我应该可以用来启动... 但是什么也没发生,主机上什么也没发生。如果我遵循同样的流程但使用 imx93-evk 它可以在我们的板上运行并启动。 对于 flash.bin 来说,EVK 比 NIMBUS 大 24,576 字节,所以我觉得自己好像遗漏了一些东西。Bl31.bin、tee.bin 和 mx93a1-ahab-container.img 都存在。 我尝试了一张使用 EVK u-boot-spl.bin 和 NIMBUS u-boot.bin 的图像;SPL 出现了但是后来在尝试运行 U-BOOT 时卡住了。 请大家帮忙! Re: iMX93 building u-boot for a custom target 感谢您的快速回复... 我的问题原来是缺少设备树文件。EVK 有一个名为 " imx93-11x11-evk-u-启动.dtsi ";我从未听说过这个文件,也从未在创建新目标的任何文档中见过它。该文件用于描述多文件容器。我复制了 EVK 文件并将名称更改为我的新目标,版本并启动了。 希望这篇文章能对今后遇到同样问题的人有所帮助。 Re: iMX93 building u-boot for a custom target 你好@大卫-帕顿 希望你一切都好。 生成正确 flash.bin 的一般步骤见第 3.1.1 章如何在 i.MX 移植指南的独立组网 (SA) 环境中构建 U-Boot 启动。 具体步骤参见第 4.5.13 章如何使用 i. MX Linux 用户指南中的 imx-mkimage 版本 imx-boot 启动映像。 i.MX93 的具体步骤 您将在表 3 中找到所有必要的代码包。i.MX Linux 发行说明的 BSP 和多媒体标准包。 顺祝商祺! 萨拉斯 Re: iMX93 building u-boot for a custom target 我也遇到了同样的问题,花了整整两天时间反复尝试才找到你的帖子。这件事真的需要记录下来。
View full article
Android OSでNXP sd8987 wifi+BTコンボモジュールを使うと、BT HFが動作しません こんにちは、 私はNXPチップsd8987(M2-JODY-W263-10C)とTI SoC am62pを使用しています。私はAndroid OSを使っています。a2dpは動作していますが、ハンズフリーは動作しません。コーデックスピーカーは1つしか持っていません。 M2-JODY-W263-10C (sd8987) モジュールのピン配置に関して、注意すべき点はありますか? よろしくお願いします。 ロシャン Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS こんにちは、 @Roshan888 Androidのバージョンを教えてもらえますか? SD8987 M2-JODY-W263-10CモジュールでSCO用のPCM/I2Sインターフェースを使いましたか? デバイスの起動時に、A2DPがコネクテッドした全てのログを教えてもらえますか?HFPが動作しませんでした。 よろしくお願いいたします。 Christine。 Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS こんにちは、クリスティンさん。 私はPCM/I2Sピンを使用していません。ソフトウェアHFP経由UARTを使います。 私はTI am62p Soc Android バージョン16を使っています。 bluetooth_managerログを添付しました。 よろしくお願いします。 ロシャン Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS こんにちは、 @Roshan888 ダンプファイルと情報を提供していただきありがとうございます。 ダンプファイルから判断すると、RFCOMMは既に開かれており、SCOも正常に作成され、ハンドラも既に初期化されているようです。 さらにデバッグのために、以下の情報提供をいただけませんか? 1.Bluetooth HCIのスヌープログで、全プロセスを含む完全な接続、A2DPは接続されているのにHFPが動作しないプロセス? Androidでは、 HCIのスヌープログ Bluetooth in Developer Options を有効にし、Bluetoothを一度切り替えてキャプチャを開始し、その後ログをエクスポートすることで adb をキャプチャできます。 手順: 開ける 開発者向けオプション 有効にする Bluetooth HCIスヌープログ Bluetoothの切り替え 一度オンオフを繰り返して 問題の再現を試みています。 ADBコマンドを使用してログファイルを取得します。 2. ADBシェルダンプsys media.audio_policy> audio_policy.txt ADB Shell Dumpsys media.audio_flinger> audio_flinger.txt adb logcat -b all -d > logcat_log.txt (デバイスの起動時に実行)   よろしくお願いいたします。 Christine。 Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS こんにちは、 @Roshan888 この問題を進めるために、リクエストされたログの提供を手伝ってもらえますか? よろしくお願いいたします。 Christine。 Re: BT HF is not working by using NXP sd8987 wifi+BT combo module in android OS こんにちは、 @Roshan888 問題は解決しましたか? まだ私たちのサポートが必要ですか? もしそうなら、この問題を進めるために求められたログの提供をご協力いただけますか? よろしくお願いいたします。 Christine。
View full article
TJA1120A RGMII 自动以太网 我们正在基于 TI AM62A7 的定制主板上开发 TJA1120A RGMII 自动以太网 请帮助我们了解如何在 Yocto Linux 上启用该接口。 我们按照 https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/nxp% 2Ctja11xx.yaml 中的 DTS 节点格式进行了尝试 但驱动程序在内核 dmesg 中没有探测到 据了解,该 PHY 的供应商 ID 为 D001B:B031 我们还在内核配置CONFIG_NXP_C45_TJA11XX_PHY中启用了 CONFIG_ NXP_TJA11XX_PHY。 Re: TJA1120A RGMII Auto-Ethernet 你好@vikyhre、 为了缩小范围,请与我们分享一下: 1) U-Boot 是否在预期的地址检测到 MDIO 总线上的 PHY?例如“mdio 列表”/“mii info” 的输出) 2) 请分享 CPSW 端口节点和 MDIO/PHY 节点(phy-handle、phy-mode、PHY 注册/地址)的相关 DTS 片段,以及与 MDIO/PHY 初始化相关的启动日志行:dmesg | egrep-i " mdio|cpsw|phy|tja|nxp " 有了这两个项目,我们可以快速确定PHY在MDIO上是不可见的(硬件/PINMUX/RESET/地址),还是DT绑定/引用问题。 顺祝商祺! 帕维尔 Re: TJA1120A RGMII Auto-Ethernet 我们目前使用的是基于 AM62A7 的 iWave 系统模块,尚未修改 eMMC 中存储的 u-boot/引导加载程序固件。 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done SPL initial stack usage: 17040 bytes am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed Starting ATF on ARM64 core... NOTICE: BL31: v2.9(release):d7a7135d3-dirty NOTICE: BL31: Built : 09:34:15, Aug 24 2023 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed U-Boot 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SoC: AM62AX SR1.0 HS-FS Model: iW-RainboW-G55M-TI-AM62AX OSM DRAM: 2 GiB Core: 60 devices, 29 uclasses, devicetree: separate MMC: mmc@fa10000: 0, mmc@fa00000: 1 Loading Environment from nowhere... OK In: serial@2800000 Out: serial@2800000 Err: serial@2800000 Board Info: BSP Version : iW-PRHAZ-SC-01-R2.0-REL1.0-Linux6.1.46 SOM Version : iW-PRHAZ-AP-01-R2.0 Net: eth0: ethernet@8000000port@1 Hit any key to stop autoboot: 0 iWave-G55M > mdio list mdio@f00: ethernet@8000000port@1: 4 - Generic PHY <--> ethernet@8000000port@1 iWave-G55M > mii info U-Boot固件我们没有改动,只是从SD卡启动Linux系统。 我已附上k3-am62a7-iwg55m.dtsi文件,其中以太网接口 eth0 和 eth1 均已禁用 &cpsw3g { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_rgmii1_pins_default>, <&main_rgmii2_pins_default>; cpts@3d000 { /* MAP HW3_TS_PUSH to GENF1 */ ti,pps = <2 1>; }; }; &cpsw_port1 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy0>; }; &cpsw_port2 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy1>; }; &cpsw3g_mdio { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_mdio1_pins_default>; cpsw3g_phy0: ethernet-phy@0 { reg = <4>; adi,rx-internal-delay-ps = <2000>; }; cpsw3g_phy1: ethernet-phy@1 { reg = <5>; qca,disable-smarteee; vddio-supply = <&vddio0>; vddio0: vddio-regulator { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; }; }; 在 k3-am62a7-iwg55s-prgjj-41.dts 文件中,我使用相应的 DT 条目启用了 eth0 和 eth1。 &cpsw_port1 和 &cpsw3g_phy0 对应于我们的自动以太网 &cpsw_port1 { status = "okay"; phy-mode = "rgmii"; }; &cpsw_port2 { status = "okay"; phy-mode = "rgmii"; }; &cpsw3g_phy0 { //compatible = "ethernet-phy-id001b.b031", "ethernet-phy-ieee802.3-c45"; compatible = "ethernet-phy-id001b.b030"; nxp,rmii-refclk-in; reg = <4>; }; &cpsw3g_phy1 { compatible = "ethernet-phy-id0022.1620"; reg = <0>; txc-skew-ps = <900>; rxc-skew-ps = <900>; rxd0-skew-ps = <420>; rxd1-skew-ps = <420>; rxd2-skew-ps = <420>; rxd3-skew-ps = <420>; txd0-skew-ps = <420>; txd1-skew-ps = <420>; txd2-skew-ps = <420>; txd3-skew-ps = <420>; rxdv-skew-ps = <420>; txen-skew-ps = <420>; }; 我的 PHY TJA1120A 的 PHY 标识寄存器 1:1B 和 PHY 标识寄存器 2:B030。 因此,合适的驱动程序应该兼容 = "ethernet-phy-id001b.b030" dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"的响应 root@am62ax-iwg55m-osm:/sys/class/hwmon/hwmon0# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.349271] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown [ 1.375925] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.388839] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.395108] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.402236] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512 [ 1.412875] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.422952] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.876699] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.893353] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.937861] am65-cpsw-nuss 8000000.ethernet eth0: validation of rgmii with support 00000000,00000000,00006280 and advertisement 00000000,00000000,00002280 failed: -EINVAL 我还附上了 dmesg 文件。 Re: TJA1120A RGMII Auto-Ethernet 你好@vikyhre、 请注意,社区帖子会在最后一条回复发布后的7天内受到持续监测。此后,我们将仅收到订阅邮件通知以获取后续更新,此类通知有时可能会被错过。   如果您将来需要更多帮助,我们建议您创建一个新的社区查询或支持工单https://support.nxp.com/s/?language=en_US 。 总之,以下是我的分析。 请注意,以下提供的 Linux 命令仅作为建议的诊断检查。由于我无法访问您的确切版本和运行时环境,因此我无法直接在您的设置上验证它们,根据您的系统配置,可能需要进行一些小的调整。 以下讨论串可能对参考有所帮助: 使用 TJA1120 和 i.MX8 评估硬件时,无法进行数据包传输。 从日志来看,MDIO 访问本身似乎工作正常,因为 Linux 检测到 MDIO 总线上有两个 PHY 设备: [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown 因此,TJA1120A 似乎在 MDIO 地址 4 处可见,但它尚未绑定到 NXP C45 TJA11xx PHY 驱动程序。这很可能是 CPSW 端口在 RGMII 验证期间发生故障的原因。 首先,请尝试更新 TJA1120A PHY 节点,明确指定第 45 条: &cpsw_port1 { 状态 = "正常"; phy-mode = "rgmii"; /* 或 rgmii-id / rgmii-rxid / rgmii-txid,具体取决于您的电路板延迟设计 */ phy-handle = <&cpsw3g_phy0>; };   &cpsw3g_phy0 { 兼容 = "ethernet-phy-id001b.b030", "ethernet-phy-ieee802.3-c45"; reg = <4>; 状态 = "正常"; }; 另外,请从 TJA1120A 节点中移除此属性:  nxp,rmii-refclk-in; 此属性与 RMII 参考时钟配置有关,不应将其用于您的 RGMII TJA1120A 设置。   使用更新后的 DTB 重新构建并启动后,请检查驱动程序是否已附加,例如: dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"   预期结果是地址 4 处的 PHY 不再显示为 driver unknown ,而是连接到 NXP C45 TJA11xx/TJA1120 驱动程序。 如果仍然显示为 driver unknown ,请确认正在运行的内核确实包含驱动程序支持: zcat /proc/config.gz | zcat /proc/config.gz | egrep "NXP.*TJA|C45|PHYLIB" 查找 /lib/modules/$(uname -r) -name "*tja*"   顺祝商祺! 帕维尔
View full article
iMX93 カスタムターゲット用の u-boot をビルディング 新しい imx93 ボードには Yocto Scarthgap を使用しています。EVK 上の NXP SOM と非常によく似た SOM があり、EVK 用の SDIO カードをボードに挿入すると起動します。 Yocto を扱う際の煩わしさを避けるために、u-boot-imx を取り出し、Yocto の SDK を使用してスタンドアロン ビルドにしました。EVK 用の u-boot を正常にビルドし、CAN 起動します。 SO 私は取締役会に次のことを提案します。 board/freescale/imx93_nimbus/ を追加し、board/freescale/imx93_evk/ の内容を入力しました。 変更されたimx93_evk.cimx93_nimbus.c に、内容は変更なし Kconfig を修正し、EVK/evk を NIMBUS/nimbus に置き換え、arch/arm/mach-imx/imx9/Kconfig に追加しました。 Makefileを修正し、EVK/evkをNIMBUS/nimbusに変更しました。 arch/arm/dts/imx93-nimbus.dts を追加しました。内容は imx93-11x11-evk.dts と同じです。 include/configs/imx93_nimbus.h を追加し、EVK/evk を NIMBUS/nimbus に変更しました。 imx93_11x11_evk_defconfig から configs/imx93_nimbus_defconfig を追加しました。デバイスツリー命名と TARGET 命名のみ異なります。 imx93_nimbus_defconfig を作成する 作成する imx-boot-toolsをコピーし、その下にimx93ディレクトリを作成しました u-boot.bin と spl/u-boot-spl.bin を imx-boot-tools/imx93 にコピーします。 imx-boot-tools/imx93 に cd します make -f ../soc.mak flash_singleboot sudo dd if=flash.bin of=/dev/sdb bs=1k seek=32 conv=fsync そして、今では SDIO カードを持っていて、起動できるはずです...しかし何も起こりません。コンソールには何も表示されません。これと同じプロセスに従い、imx93-evk を使用すると、ボード上で動作し、起動します。 flash.bin の場合、EVK は NIMBUS よりも 24,576 バイト大きいため、何かが欠けているように感じます。Bl31.bin、tee.bin、mx93a1-ahab-container.img がすべて存在します。 EVK u-boot-spl.bin と NIMBUS u-boot.bin を使用したイメージを試してみましたが、SPL は起動しましたが、U-BOOT を実行しようとすると停止してしまいました。 ご協力ください! Re: iMX93 building u-boot for a custom target 早速のお返事ありがとうございます。 私の問題はデバイス ツリー ファイルが見つからないことであることが判明しました。EVK には「imx93-11x11-evk-u-boot.dtsi」という名前のファイルがあります。このファイルについては聞いたことがありませんし、新しいターゲットを作成する際のドキュメントでも見たことがありません。このファイルは、マルチファイル コンテナーを記述するようです。EVK ファイルをコピーし、名前を新しいターゲットに変更してビルドし、起動しました。 FUTURE、同じ問題に遭遇した誰かにとって、この投稿が役に立つことを願っています。 Re: iMX93 building u-boot for a custom target こんにちは@davidpatton お元気でお過ごしのことと思います。 正しいflash.binを生成するための一般的な手順は3.1.1章に記載されています。i.MX 移植ガイドのスタンドアロン環境で U-Boot を構築する方法。 具体的な手順については4.5.13章をご覧ください。i.MX Linux ユーザーガイドの imx-mkimage を使用して imx-boot イメージを構築する方法。 i.MX93の具体的な手順: 必要なパッケージはすべて表 3 にあります。i.MX Linux リリース ノートの BSP およびマルチメディア標準パッケージ。 よろしくお願いいたします。 サラス。 Re: iMX93 building u-boot for a custom target 私も全く同じ問題に遭遇し、あなたの投稿を見つけるまで2日間試行錯誤していました。これはどこかに記録しておく必要がある。
View full article
S32K3 Unlock Secure Debug with Trace32 Hello S32K3 Team, I am currently experiencing an issue with secure debug unlock. The debugger I am using is Trace32 and autosar os using.... The Life Cycle (LC) has been switched to OEM, and secure debug is configured in password mode (not challenge–response). The configured TEST password is: 0xFFEEDDCCBBAA99887766554433221100 Before switching the LC, I confirmed that the HASH value matched correctly. I have tried the following two methods to unlock secure debug: Using the Trace32 command: SYStem.Option KEYCODE %Byte 0xFF 0xEE 0xDD 0xCC 0xBB 0xAA 0x99 0x88 0x77 0x66 0x55 0x44 0x33 0x22 0x11 0x00 Using the S32_JTAG_WRITE.cmm script However, both methods failed to unlock secure debug. I would appreciate your guidance on what I should check next or any potential causes I might be overlooking. I have attached my script for reference. Best regards, #HSE #secureDebug Re: S32K3 Unlock Secure Debug with Trace32 I have recently test it. See attached scripts debug_authorization.cmm shows how to enter the password and then it calls other scripts. I am sending you attachment directly. Re: S32K3 Unlock Secure Debug with Trace32 Hello, I am experiencing the same issue in the same environment. Could you please share the file with me as well? I would really appreciate your help. Thank you!
View full article
S32K3 使用 Trace32 解除锁定安全调试 你好,S32K3 团队、 我目前遇到了安全调试解锁的问题。 我使用的调试器是 Trace32 和 autosar os,使用.... ,生命周期(LC)已切换到 OEM,安全调试配置为密码模式(不是挑战-响应)。 配置的 TEST 密码为 0xFFEEDDCCBBAA99887766554433221100 在切换 LC 之前,我确认了 HASH 值是否正确匹配。 我尝试了以下两种方法来解锁安全调试: 使用 Trace32 命令 SYStem.Option KEYCODE%字节 0xFF 0xEE 0xDD 0xCC 0xBB 0xAA 0x99 0x88 0x77 0x66 0x55 0x44 0x33 0x22 0x11 0x00 使用 S32_JTAG_WRITE.cmm 脚本 然而,这两种方法都无法解锁安全调试。 如果您能指导我下一步应该检查什么,或者我可能忽略的任何潜在原因,我将不胜感激。 我附上了我的脚本以供参考。 顺祝商祺! #HSE #安全调试 Re: S32K3 Unlock Secure Debug with Trace32 我最近进行了测试。见所附脚本 debug_authorization.cmm 演示如何输入密码,然后调用其他脚本。 我直接向您发送附件。 Re: S32K3 Unlock Secure Debug with Trace32 你好, 我在相同的环境下也遇到了同样的问题。 您能否也把文件分享给我?非常感谢您的帮助。 谢谢!
View full article
TJA1120A RGMII 車載イーサネット 私たちはTI AM62A7をベースにしたカスタムボード上でTJA1120A RGMII車載イーサネットの開発に取り組んでいます。 Yocto Linuxでこのインターフェースを有効にする方法について教えてください。 私たちは、 https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/nxp%2Ctja11xx.yamlに記載されている DTS ノード形式に従って試してみました。 しかし、ドライバはカーネルdmesgを調べなかった このPHYのベンダーIDはD001B:B031であると理解しています。 また、カーネル設定でCONFIG_NXP_C45_TJA11XX_PHYを有効にしました。 Re: TJA1120A RGMII Auto-Ethernet こんにちは、 @vikyhre さん。 絞り込むために、以下の情報を共有していただけますか? 1) U-Bootは、MDIOバス上のPHYを想定されたアドレスで検出しますか?(例えば「mdio list」/「mii info」の出力) 2) CPSWポートノードとMDIO/PHYノード(phy-handle、phy-mode、PHY reg/address)に関する関連するDTSスニペットと、MDIO/PHY初期化に関連するブートログ行を共有してください。 dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" これら2つの項目があれば、PHYがMDIO(ハードウェア/ピンマルチプレクサ/リセット/アドレス)上で認識されていないのか、それともDTバインディング/参照の問題なのかを迅速に判断できます。 よろしくお願いいたします。 パベル Re: TJA1120A RGMII Auto-Ethernet 私たちはAM62A7ベースのiWave SoMを使用しており、現時点ではeMMCに格納されているu-boot/ブートローダーファームウェアには手を加えていません。 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done SPL initial stack usage: 17040 bytes am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed Starting ATF on ARM64 core... NOTICE: BL31: v2.9(release):d7a7135d3-dirty NOTICE: BL31: Built : 09:34:15, Aug 24 2023 U-Boot SPL 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.8--v09.01.08 (Kool Koala)') am62a_init: board_init_f done am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Trying to boot from MMC1 am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed am62a_init: spl_boot_device: devstat = 0x374b bootmedia = 0x9 bootindex = 0 Authentication passed U-Boot 2023.04-g2b8a667ace (May 24 2024 - 11:27:05 +0000) SoC: AM62AX SR1.0 HS-FS Model: iW-RainboW-G55M-TI-AM62AX OSM DRAM: 2 GiB Core: 60 devices, 29 uclasses, devicetree: separate MMC: mmc@fa10000: 0, mmc@fa00000: 1 Loading Environment from nowhere... OK In: serial@2800000 Out: serial@2800000 Err: serial@2800000 Board Info: BSP Version : iW-PRHAZ-SC-01-R2.0-REL1.0-Linux6.1.46 SOM Version : iW-PRHAZ-AP-01-R2.0 Net: eth0: ethernet@8000000port@1 Hit any key to stop autoboot: 0 iWave-G55M > mdio list mdio@f00: ethernet@8000000port@1: 4 - Generic PHY <--> ethernet@8000000port@1 iWave-G55M > mii info U-Bootのファームウェアは変更せず、LinuxをSDカードから起動しています k3-am62a7-iwg55m.dtsi を添付しました。ここで、両方のイーサネットeth0、eth1が無効化されています &cpsw3g { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_rgmii1_pins_default>, <&main_rgmii2_pins_default>; cpts@3d000 { /* MAP HW3_TS_PUSH to GENF1 */ ti,pps = <2 1>; }; }; &cpsw_port1 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy0>; }; &cpsw_port2 { status = "disabled"; phy-mode = "rgmii-rxid"; phy-handle = <&cpsw3g_phy1>; }; &cpsw3g_mdio { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&main_mdio1_pins_default>; cpsw3g_phy0: ethernet-phy@0 { reg = <4>; adi,rx-internal-delay-ps = <2000>; }; cpsw3g_phy1: ethernet-phy@1 { reg = <5>; qca,disable-smarteee; vddio-supply = <&vddio0>; vddio0: vddio-regulator { regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; }; }; k3-am62a7-iwg55s-prgjj-41.dts では、適切な DT エントリを使用して eth0 と eth1 の両方を有効にしました。 &cpsw_port1と&cpsw3g_phy0はオートイーサネットに対応しています &cpsw_port1 { status = "okay"; phy-mode = "rgmii"; }; &cpsw_port2 { status = "okay"; phy-mode = "rgmii"; }; &cpsw3g_phy0 { //compatible = "ethernet-phy-id001b.b031", "ethernet-phy-ieee802.3-c45"; compatible = "ethernet-phy-id001b.b030"; nxp,rmii-refclk-in; reg = <4>; }; &cpsw3g_phy1 { compatible = "ethernet-phy-id0022.1620"; reg = <0>; txc-skew-ps = <900>; rxc-skew-ps = <900>; rxd0-skew-ps = <420>; rxd1-skew-ps = <420>; rxd2-skew-ps = <420>; rxd3-skew-ps = <420>; txd0-skew-ps = <420>; txd1-skew-ps = <420>; txd2-skew-ps = <420>; txd3-skew-ps = <420>; rxdv-skew-ps = <420>; txen-skew-ps = <420>; }; ここで、私のPHY TJA1120AにはPHY識別レジスタ1:1BとPHY識別レジスタ2:B030があります。 したがって、適切なドライバーは イーサネット と互換性があるはずです = "ethernet-phy-id001b.b030" dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"に対する応答 root@am62ax-iwg55m-osm:/sys/class/hwmon/hwmon0# dmesg | egrep -i "mdio|cpsw|phy|tja|nxp" [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys). [ 1.349271] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000 [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown [ 1.375925] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006 [ 1.388839] am65-cpsw-nuss 8000000.ethernet: Use random MAC address [ 1.395108] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5 [ 1.402236] am65-cpsw-nuss 8000000.ethernet: ALE Table size 512 [ 1.412875] am65-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:1 [ 1.422952] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19 [ 6.876699] am65-cpsw-nuss 8000000.ethernet eth1: PHY [8000f00.mdio:00] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 6.893353] am65-cpsw-nuss 8000000.ethernet eth1: configuring for phy/rgmii link mode [ 6.937861] am65-cpsw-nuss 8000000.ethernet eth0: validation of rgmii with support 00000000,00000000,00006280 and advertisement 00000000,00000000,00002280 failed: -EINVAL dmesgも添付しました。 Re: TJA1120A RGMII Auto-Ethernet こんにちは、 @vikyhre さん。 コミュニティスレッドは前回の投稿から7日間、積極的に監視されていることにご注意ください。この期間以降、私たちは最新情報の購読メール通知のみを受け取り、そのような通知を見逃すこともあります。   今後追加の支援が必要な場合は、新しいコミュニティクエリを作成するか、サポートチケット を作成 https://support.nxp.com/s/?language=en_US することをお勧めします。 さて、私の分析結果は以下の通りです。 以下のLinuxコマンドは推奨される診断チェックとして提供されていることに注意してください。正確なビルドやランタイム環境にアクセスできないため、セットアップ上で直接検証できず、システム構成によっては軽微な調整が必要になるかもしれません。 以下のスレッドが参考になるかもしれません: TJA1120とi.MX8評価用ハードウェアではパケット送信は行われません。 ログを見る限り、MDIOアクセス自体は動作しているようです。なぜならLinuxはMDIOバス上の2つのPHYデバイスを検出しているからです。 [ 1.358577] davinci_mdio 8000f00.mdio: phy[0]: device 8000f00.mdio:00, driver Micrel KSZ9031 Gigabit PHY [ 1.368066] davinci_mdio 8000f00.mdio: phy[4]: device 8000f00.mdio:04, driver unknown つまり、TJA1120AはMDIOアドレス4で見えるようですが、まだNXP C45のTJA11xx PHYドライバには割り当てられていません。これが、CPSWポートが後にRGMII検証中に失敗する理由である可能性が高い。 まず最初のステップとして、TJA1120A PHYノードを更新して、条項45を明示的に指定してみてください。 &cpsw_port1 { status = "OK"; phy-mode = "RGMII";     /* または rgmii-id / rgmii-rxid / rgmii-txid(ボードの遅延設計によります)*/ phy-handle = <&cpsw3g_phy0>; };   &cpsw3g_phy0 { コンパソコント = 「イーサネット-PHY-ID001B.B030」、「イーサネット-PHY-IEEE802.3-C45」; reg = <4>; status = "OK"; }; また、TJA1120Aノードからこのプロパティを削除してください。  nxp,rmii-refclk-in; このプロパティはRMIIリファレンスクロックの設定に関連するものであり、RGMII TJA1120Aの設定には使用しないでください。   再構築して更新されたDTBで起動した後は、ドライバが接続されているか確認してください。例えば: dmesg | egrep -i "mdio|cpsw|phy|tja|nxp"   予想される結果として、アドレス4のPHYはもはや driver unknown として表示されず、NXP C45 TJA11xx/TJA1120ドライバに接続されます。 もしまだ driver unknown のままであれば、実行中のカーネルに本当にドライバーのサポートが含まれているかも確認してください。 zcat /proc/config.gz | egrep "NXP.*TJA|C45|PHYLIB" find /lib/modules/$(uname -r) -name "*tja*"   よろしくお願いいたします。 パベル
View full article
GUI Guider 2.0.0 just released! GUI Guider v2.0.0 Is Here: Build Embedded UIs Faster GUI Guider v2.0.0 improves the embedded UI development workflow with a redesigned editor, real-time rendering, updated project structure, and broader platform support. It helps developers move from layout design to integration faster, with fewer context switches along the way. 🚀 Key Enhancements in This Release ✅ A redesigned IDE UI with a more professional look and flexible layout options ✅ A new real-time rendering mechanism for a true what-you-see-is-what-you-get editing experience ✅ A flowchart-style event system designed for complex interaction logic ✅ Figma-to-GUI Guider project import to bridge design and development 1. Redesigned IDE UI The redesigned interface introduces a cleaner, more consistent visual style, making the editor easier to navigate and more comfortable to use during day-to-day development. Customizable layouts let developers organize the workspace around their preferred workflow, helping them access frequently used tools more quickly and edit interfaces more efficiently. Resource management, property configuration, and editing interactions have been streamlined to make common UI development tasks easier to complete. 2. Real-Time Rendering and Instant Simulation GUI Guider v2.0.0 integrates a new rendering mechanism that enables real-time rendering directly in the GUI editor. After modifying the interface, developers can preview the results immediately, reducing the time spent repeatedly generating code and switching contexts. This capability significantly accelerates UI prototyping and interaction validation, especially during fast iteration cycles. 3. Upgraded Property and Style System This release expands property and style configuration, giving developers more control over widget behavior, visual states, and appearance. Developers can enable, adjust, and manage properties, styles, and state settings based on the needs of each project. At the same time, the generated code structure has been further optimized, making it easier to integrate, read, and maintain. 4. New Project Structure GUI Guider v2.0.0 introduces a new folder organization model and project JSON configuration. The project directory is easier to understand, and project metadata is managed in a more consistent way. This structure makes projects easier to maintain as teams collaborate, add features, and expand the UI over time. 5. UI Design in the JSON Editor In addition to visual editing, the new version also supports UI design directly in the JSON editor. This is useful for automated builds, template-based configuration, and advanced engineering workflows where project files need to be reviewed, generated, or updated directly. 6. Visual Event System The event system now uses a flowchart-style visual representation. Conditions and animations can be reused, making the system better suited for building complex UI interaction logic. This approach is more intuitive and also makes debugging and maintenance easier. 7. Figma Design Import GUI Guider v2.0.0 supports converting Figma designs directly into GUI Guider projects. This further connects the workflow from design mockups to editable GUI projects, helping shorten the path between design and development. 8. Graphics Library Upgrade The new version upgrades to LVGL v9.4.0 and supports System Layer, Top Layer, and Bottom Layer capabilities, making it easier to organize UI elements across different layers. 9. Platform and Development Ecosystem Support While maintaining compatibility with existing platforms and development ecosystems, GUI Guider v2.0.0 further improves the project integration experience. It keeps pace with the latest Zephyr 4.4 release, strengthening project integration and version adaptation capabilities. The tool continues to support mainstream NXP embedded product families, including MCX, RW, i.MX RT, and i.MX. It can be seamlessly integrated into existing MCU and MPU projects to meet GUI development needs across a wide range of scenarios. With more stable ecosystem support, developers can spend more time on UI design and feature implementation and less time on integration work.   🚀 Try GUI Guider v2.0.0 and explore a faster workflow for developing embedded UIs. 📥 Resources Download GUI Guider 2.0.0 Visit the NXP website 💬 Community Forum: Join the discussion Follow us for more embedded GUI development tips and product updates!
View full article
CLRC663 plus - LPCD Tip & Tricks Prerequisites:  CLRC663 plus Low Power Card Detection 1// Antenna Size  The stronger the coupling between reader and card, the better the detection range.  Ideally, the NFC reader antenna should have a size and form factor similar to that of the target NFC tag antenna. In practice, the reader antenna is typically designed to be slightly larger—by approximately 10% to 20%—to ensure reliable coupling and performance. 2// Antenna Q-factor  Higher Q-factor typically serves higher detection range. The Q-factor should be selected in accordance with the target communication bit rate.(e.g. Q≈30 for 106 kbit/s).  The antenna Q factor is mainly defined by the mechanical design of the antenna itself, as well as by external damping resistors. However, for LPCD-insensitive systems, a zero-ohm damping resistor can be used, and the system should then be evaluated through testing.  3// Target tuning  The CLRC663 should typically be used with the asymmetrical tuning as there is no internal power regulation implemented.  However, in some cases, symmetrical tuning may be beneficial, as it can improve detection range and sensitivity. Care must be taken to ensure that, under varying conditions—such as antenna loading by different NFC tags or the presence of nearby metal, the TVDD current does not exceed the specified maximum limits.   In CLRC663 LPCD operation, detection performance improves with higher TX power. However, this also increases current consumption, so an appropriate trade-off must be determined.   As a starting point, an antenna impedance of approximately Z≈ 50 Ω can be used.   4// Receiver setting (external Rx resistors) Based on the AN11019 (chapter 4.4.1), the peak voltage between RxN and GND (or RxP and GND) shall be in the range of 1.2Vp - 1.7Vp. Generally, higher Rx voltage levels improve detection range. To increase LPCD sensitivity and range, it can be advantageous to operate close to the upper limit of the allowed Rx voltage.   Please note that excessively high RX voltage may lead to immediate false wake-ups. 5//LPCD Settings As a starting point, we recommend using the following settings:   These settings provide robust immunity against false wake-ups and are highly efficient in terms of current consumption. The typical detection range for standard NFC tags is approximately 10 mm to 20 mm or even less in an application where the antenna is placed near a metal environment. Detection performance can be further improved by lowering the threshold settings +0 and -0. If this settings is used, we strongly advice using LPCD_FILTER feature as well. Alternatively, the user can use "high detection range option" + LPCD_FILTER. After using these settings, we recommend running "Endless LPCD" for a while and checking for any false wake-up rates. Note: The LPCD filter feature helps prevent false wake-ups. This is especially important when the threshold is set to +0 and -0. When using thresholds of +0 and −0 it is also recommended to set the "CWMAX" parameter (address 0x2A) to 1b. 5.1// LPCD RF ON time  If the RF on-time is shorter than approximately 20 µs - 30 µs , the primary detuning effect is dominated by the physical design of the NFC tag. For longer RF on-times, the NFC tag becomes energized, and its electrical parameters begin to contribute significantly to the overall detuning. Based on this understanding, a longer RF on-time can help increase LPCD detection range. However, this comes at the cost of higher current consumption. Therefore, it is recommended to compensate by adjusting the RF off-time. See an example below.   5.2// LPCD Charge pump  This function allows the TX power to be increased exclusively during the LPCD RF On time.   This can be beneficial if you want to avoid increasing the power in active mode (e.g., by reducing the tuning impedance) but only increase it during LPCD operation.   By activating the LPCD charge pump, detection performance can be improved, but at the cost of increased current consumption.   If this feature is enabled, it is recommended to verify the LPCD RF ping using an oscilloscope. It may be necessary to increase the RF On time to allow the amplitude to properly settle. Especially for TVDD= 3.3V or lower. 6// Summary Mode  Tuning function Target impedance Q-factor Receiver voltage LPCD Threshold LPCD Filter LPCD Charge -pump RF On time  Standard Asymmetrical  20 Ω - 80 Ω  10 - 30 1.5 Vp +1 and -1 disable disable 10 us High detection range  Asymmetrical /Symmetrical (1) 20 Ω - 50 Ω >25 (2) 1.7 Vp +0 and -0 enable enable/ disable (3)  20 us-100 us Note (1): Symmetrical tuning can only be applied if the TVDD current does not exceed the maximum allowable value after antenna loading caused by a card or metal object. Please ensure that this condition is met. Note (2): If high detection performance is required, the external antenna damping resistors are typically replaced with 0 Ω resistors, resulting in a higher antenna Q-factor. In this case, the user must verify that NFC communication continues to operate reliably. Due to the increased Q-factor, this configuration is typically limited to communication speeds of 106 kbit/s Note (3): Once the charge pump is enabled, the RF On time should be verified and adjusted if necessary. Please also note that the relationship between TX power and detection distance is not linear or unlimited. Beyond a certain point, enabling the charge pump provides only marginal improvements in detection distance.     Please note that the High Detection mode is generally more susceptible to false wake-ups and results in higher current consumption than the standard mode. NFC Frontend Solutions
View full article
How to send multiple CAN messages after stop and restart the CAN analyzer in the model attached RHinnen‌ Hi , RHinnen    Could  you spare some precious time to help me solve the following problems: How to  modify the model attached to send multiple CAN messages and keep sending CAN messages without reset the the mcu after the CAN analyzer is stopped and started again? The example -CAN1(Flexcan Traffic )offered  in the MPC574xP Example Projects-Communictions does not exsit the problem.    Up to now ,even though i added another CAN message (different ID) in the model ,the CAN analyzer only sent one ID CAN message.  The CAN analyzer  will stop sending CAN messages after stopped and started .      Look forward to your solution ,thank you very much! Example Models Re: How to send multiple CAN messages after stop and restart the CAN analyzer in the model attached Hi, I am also searching to resolve the same issue. If you resolved that CAN signal sending without MCU restart. Kindly share your approach it will be helpful for my project Thank You, Rahul Re: How to send multiple CAN messages after stop and restart the CAN analyzer in the model attached Hello sparkee, Yes, unfortunately if you want to use the same MB for multiple transfers you'll have to do one of the following: - either use blocking mode (which will likely slow down a bit your application) - either use non-blocking mode, but making sure the 2nd transfer on the same MB will be done only after the 1st was completed. Otherwise, the 1st transfer will be halted by the 2nd, so it will not run to completion. The 2nd option here depends on how you write your application, as you'll have to manage the timing yourself - nevertheless, it can have the advantage of a slightly faster application (depending on what overhead you add with the timing management). The 1st option is simple enough (the block handles everything), but you must decide if that bit of extra time spent in the blocking transfer is something you can have or not in your application. The best scenario is the one where you have MBs available so that you can use the non-blocking mode, each transfer having it's own MB set. Hope this clears things up a bit. Kind regards, Razvan. Re: How to send multiple CAN messages after stop and restart the CAN analyzer in the model attached This question was asked in November... any traction on this?  The issue that I found was that I was not setting the message buffers different for each message.  I didn't realize you had to set each message to load into a specific buffer. Re: How to send multiple CAN messages after stop and restart the CAN analyzer in the model attached    I still don't know what the right approach should look like. Can you give me a correct example?    thanks. Re: How to send multiple CAN messages after stop and restart the CAN analyzer in the model attached paulvlase‌, Please have a look and investigate a possible solution. Thank you! Daniel
View full article
MCXA153: LPSPI data burst transfer. Hello, The Reference Manual MCXA153 contains a description of the TDBRn and RDBRn LPSPI registers: "TDBRn and RDBRn registers supports burst transfers of data to the transmit FIFO for use with the DMA controller". Can anyone share sample code for a burst transfer using these registers? best regards Bogdan Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) MCXA Re: MCXA153: LPSPI data burst transfer. Hi @bogdan_u  Sorry, there are currently no relevant examples available. The closest MCXA153 example I found uses LPSPI_MasterTransferEDMALite() with eDMA, but the driver targets TDR/RDR via LPSPI_GetTxRegisterAddress() / LPSPI_GetRxRegisterAddress() , not the burst alias window. But i think you can try to use. typedef struct { uint32_t cmd; uint32_t data[128]; } lpspi_burst_tx_t; static inline uint32_t LPSPI_TCBR_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TCBR_OFFSET); } static inline uint32_t LPSPI_TDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_TDBR0_OFFSET); } static inline uint32_t LPSPI_RDBR0_Address(LPSPI_Type *base) { return ((uint32_t)base + LPSPI_RDBR0_OFFSET); } void LPSPI_StartTxBurstDMA(LPSPI_Type *base, edma_handle_t *txDmaHandle, uint32_t *cmd_plus_data, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = (uint32_t)&cmd_plus_data[0]; cfg.destAddr = LPSPI_TCBR_Address(base); cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords + 1u; EDMA_ResetChannel(txDmaHandle->base, txDmaHandle->channel); EDMA_SetTransferConfig(txDmaHandle->base, txDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(txDmaHandle); LPSPI_EnableDMA(base, kLPSPI_TxDmaEnable); } void LPSPI_StartRxBurstDMA(LPSPI_Type *base, edma_handle_t *rxDmaHandle, uint32_t *rx_words, uint32_t nwords) { edma_transfer_config_t cfg = {0}; cfg.srcAddr = LPSPI_RDBR0_Address(base); cfg.destAddr = (uint32_t)&rx_words[0]; cfg.srcOffset = 4; cfg.destOffset = 4; cfg.srcTransferSize = kEDMA_TransferSize4Bytes; cfg.destTransferSize = kEDMA_TransferSize4Bytes; cfg.minorLoopBytes = 4; cfg.majorLoopCounts = nwords; EDMA_ResetChannel(rxDmaHandle->base, rxDmaHandle->channel); EDMA_SetTransferConfig(rxDmaHandle->base, rxDmaHandle->channel, &cfg, NULL); EDMA_StartTransfer(rxDmaHandle); LPSPI_EnableDMA(base, kLPSPI_RxDmaEnable); } BR Harry
View full article
i.MX8M Plus - WDOG_B# PU when using PCA9450C Hi Team, Do we need to mount 100k PU in WDOG_B# pin for using BSDL Mode? As per Hardware Design Guide it says "If using a PMIC other than PCA9450, an external pullup resistor (100 kΩ) may be required to support Boundary-scan mode" In EVK design it seems 100k PU was mounted in WDOG_B# pin they are using same PCA9450 PMIC. Kindly confirm. PMIC Re: i.MX8M Plus - WDOG_B# PU when using PCA9450C Although PCA9450C disables WDOG_B reset by default and the pull-up is not strictly required for normal operation, NXP recommends adding the 100 kΩ pull-up when Boundary-Scan support is required. The EVK also populates this resistor to ensure a defined WDOG_B level during BSDL testing and avoid potential reset issues when WDOG_B is floating in Boundary-Scan mode.
View full article
Android 16向けPN7221の適応 「AN14880 PN7160/PN7220 - Android 16移植ガイド」はPN7221チップにも適用可能でしょうか? 該当しない場合は、PN7221をAndroid 16に移植するためのドキュメントを提供してください。 Re: PN7221 adaptation for Android 16 こんにちは、 @zhangkai さん。 「AN14880 PN7160/PN7220 - Android 16移植ガイド」は、PN7220とPN7221の両方に適用されます。 Re: PN7221 adaptation for Android 16 @KaiLi 以下のログに示すように、HALレイヤーによって読み取られたチップタイプはPN7220です。   07-01 02:08:17.400 518 5053 D NxpHal : processChipType デフォルトのチップタイプ pn7220 を設定   07-01 02:08:17.400 518 5053 D NxpHal : processChipType 製品:pn7220   07-01 02:08:17.400 518 5053 D NxpHal : phNxpNciHal_configFeatureList ()chipType = 4   07-01 02:08:17.400 518 5053 D NxpTml : phTmlNfc_e_setFragmentSize 0x22A     しかし、チップに実際にシルクスクリーン印刷されているのはPN7221です。 device-nfc.mk のNXP_NFC_HWはpn7220_i2csに設定すべきか、それともpn7221_i2csに設定すべきかアドバイスいただけますか?
View full article
AutosarプログラムでOsIf_GetCounterを呼び出すとE_OS_CALLEVEL チームの皆さん、こんにちは。 私たちは NXP S32K588 をAUTOSARベースのプログラムで使用しており、 ETAS OS と EB MCALを組み合わせています。 いくつかのMCALコンポーネントは、タイムアウト方法を以下のいずれかに設定できるタイムアウト機構を提供しています: OSIF_COUNTER_SYSTEM OSIF_COUNTER_DUMMY タイムアウト方法が OSIF_COUNTER_SYSTEMに設定されている場合、影響を受けるドライバーは初期化シーケンス中にOsIf_GetCounter()を通じてOSIFカウンターにアクセスしようとします。 これらのドライバー初期化関数は EcuM_Init()から呼び出されるため、AUTOSAR OSは以下の方法でエラーを報告します: エラーフック => E_OS_CALLEVEL 私たちの理解では、これはAUTOSAR OSカウンターAPIは タスク や ISRなどの有効なOSコンテキストからのみアクセスが許可されているのに対し、EcuM_Init()はOSスケジューラが起動する前に実行されるためです。 この状況に対処するための推奨されるアプローチについてアドバイスをいただけますか?具体的には: OS起動前のMCALタイムアウト処理に関して、推奨される設定はありますか? EcuM_Init()から初期化されたドライバーにはOSIF_COUNTER_DUMMYを使うべきでしょうか? プリOSフェーズ中にタイムアウト機能を安全に有効にするための、ETAS OS、EB MCAL、またはNXP固有のガイドラインや回避策はありますか? Re: Invokation of OsIf_GetCounter in Autosar program causes E_OS_CALLEVEL こんにちは、 ありがとうございます。SW/RTDチームに追加のフィードバックがあれば聞いてみます。 BR、ペトル Re: Invokation of OsIf_GetCounter in Autosar program causes E_OS_CALLEVEL こんにちは、 あなたの分析は正しいようです。OSIF_COUNTER_SYSTEMで設定されたドライバがOS起動前にEcuM_Init()から初期化されている場合、AUTOSAR OSの実装によってOsIf_GetCounter E_OS_CALLEVELが発生することがあります。 OS起動前の段階で初期化されるモジュールの場合、一般的な回避策は、OSベースのタイミングサービスの使用を避け、代わりにOSIF_COUNTER_DUMMY(または別のOS以外のタイミングソース)を使用することです。 具体的な推奨事項は、ETAS OSの実装方法や使用しているMCAL/RTDのバージョンによっても異なる場合があります。さらなる検証のためにS32DSとRTD(またはMCAL)バージョンを共有していただけませんか? BR、ペトル
View full article