Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
什么因素决定了流媒体服务是否适合日常观看? 在比较在线流媒体服务时,我认为最重要的因素是播放稳定性、图像质量、设备兼容性以及内容更新的频率。 在探索不同选择的过程中,我发现了NexusIPTV ,这项服务声称可以为使用不同设备的观众提供直播电视和在线点播内容。 值得评估的一些功能包括: 图像质量:支持全高清和 4K,具体取决于内容和连接方式。 设备兼容性:可兼容智能电视、安卓设备、Fire TV 设备、电脑和智能手机。 内容丰富多样:除了电影和电视剧外,还有直播电视节目。 播放性能:服务在高峰时段和不同网络连接下的性能表现。 内容更新:现有资料库是否得到定期维护和更新。 当然,单凭规格参数并不能保证良好的体验。实际性能取决于网络连接、设备和服务条件。此外,还需确认该内容在您所在地区是否已获得合法授权。 点击此处了解更多信息 讨论问题:在评估流媒体服务时,您最看重的是:播放稳定性、4K 画质、内容多样性,还是与您的设备的兼容性?
View full article
SEO効果を高めるための最適な即時URLインデックスツール Rocket Indexerは、迅速なURLとバックリンクの発見において、総合的に最高のインスタントインデックスプラットフォームと広く評価されています。 トップインスタントインデクサー • Rocket Indexer :リアルタイムのpingシステムを使用し、高い成功率で数分以内に定期的にクローラーの訪問をトリガーします。プランは、手頃な信用格付けレベルから始まります。 • インデックス作成:高速なバックリンクおよびコンテンツインデックス作成に優れた性能を発揮し、複数の発見およびAI/LMサーフェス全体に新しいリンクを迅速にルーティングできます。
View full article
S32 DS for ARM v2018 R1 ライセンス延長のリクエスト NXPサポートチーム様 S32 Design Studio for ARM v2018 R1 ライセンスの有効期限の延長をリクエストするためにこのメールを書いています。 現在のライセンスは、2026 年 3 月 10 日に期限切れになる予定です。ソフトウェアを中断なく継続的に使用できるように、ライセンスを更新したいと考えています。 ライセンスの詳細は次のとおりです。 - 製品: S32 Design Studio for ARM v2018 R1 - アクティベーションコード: 7B20-AC2E-8F18-970E このアクティベーション コードの有効期限を延長するお手伝いをお願いできますか? 再開まで今しばらくお待ちください。 Re: Request for S32 DS for ARM v2018 R1 License Extension こんにちは、 S32DS ライセンスが延長されました。 Re: Request for S32 DS for ARM v2018 R1 License Extension こんにちは、NXP チームの皆様、 また、S32 Design Studio for ARM v2018 R1ライセンスの延長をお願いしたいと思っています。私のアクティベーションコードは9D31-3A20-FFB1-F104です。 ありがとうございます!
View full article
CW_PA_v10.5.1でQCVSパッケージをインストールしている際のエラー こんにちは、 PBL用のQorIQ設定プロジェクトを作成する必要があり、そのためQCVSパッケージをインストールする必要があります。 「QCVS Power Architecture Rev 4.5.zip for CodeWarrior オフラインインストールパッケージ」をダウンロードしました。しばらく前にサポートポータルから。最近、新しいノートPCに CodeWarrior 10.5.1 をインストールしました。 しかし、CodeWarriorにQCVSパッケージをインストールしたり追加したりすることができません。インストール中に、以下のエラーが発生しました。 この問題を解決するのを手伝ってください。 よろしくお願いいたします。 ヴィマルプラサード。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 PCでCodeWarriorソフトウェアをアンインストールしてください。 以下のリンクから「QCVS offline installation packages for CodeWarrior for Power Architectures Rev 4.5.zip」および「CodeWarrior Development Studio for Power Architecture v10.5.1 – Windows.exe」をダウンロードしてください https://support.nxp.com/s/case/500Te00000gyh6mIAA/community-error-while-installing-the-qcvs-package-in-cwpav1051?language=en_US まず、CodeWarrior for PA 10.5.1をインストールしてください。その後、新しいワークスペースでCodeWarrior IDEを開き、「CodeWarrior for Power Architectures Rev 4.5.zipのQCVSオフラインインストールパッケージ」をインストールします。CodeWarrior IDEのHelp->Install New Software->Add->Archiveから。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 こんにちは@yipingwangさん ご回答ありがとうございます。 新しいワークスペースで試してみましたが、それでもインストール中にこのエラーが発生します。 CW_PA_v10.5.1に対応した最新バージョンのQCVSツールはありますか? よろしくお願いいたします。 ヴィマルプラサード。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 まず新しいワークスペースでCodeWarrior IDEを開き、CodeWarrior IDEのHelp->Install New Software->Add->ArchiveからQCVS 4.5をインストールしてください。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 こんにちは@yipingwangさん まだ以下のエラーが表示されます。 さらに、 CodeWarrior for Power Architecture Rev 4.5.zip向けのQCVSオフラインインストールパッケージを追加しました。 これは、「processcheck」アクションで「path」パラメータが設定されていないことを示しています。 よろしくお願いいたします。 ヴィマルプラサド M Re: Error while installing the QCVS package in CW_PA_v10.5.1 こんにちは@yipingwangさん ご返信ありがとうございます。 Windows 11にCW 10.5.1とQCVS 4.5をインストールする方法はありますか? あるいは、Windows 11に対応した最新のQCVSバージョンはありますか? Re: Error while installing the QCVS package in CW_PA_v10.5.1 お使いのOSは何ですか?Windows 11? Re: Error while installing the QCVS package in CW_PA_v10.5.1 こんにちは@yipingwangさん はい、Windows 11を使用しています。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 私もWindows 11環境で同様の問題を再現できました。 Windows 10の仮想マシンにCW 10.5.1とQCVS 4.5をインストールすることをお勧めします。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 Windows 11向けの新しいバージョンのQCVSソフトウェアはまだありません。 ご不便をおかけして申し訳ありません。
View full article
Build errors, Missing .axf file, and RedlinkServerException during debug launch Hello NXP Support Team, I am encountering multiple issues while trying to build and debug my project in MCUXpresso IDE. Environment Details: MCUXpresso IDE Version:  v11.8.0 Host OS: Windows Target Board / MCU: MKM34z256vll7 Debug Probe:CMSIS-DAP  Symptoms Observed: Build Errors / Missing .axf/.elf File: When attempting to build the Release configuration, build errors occur. Because of these errors, the .axf/.elf output file is not generated, resulting in the "Program file does not exist" debug launch error. RedlinkServerException: When attempting to debug or connect, I receive a RedlinkServerException: Cannot write to server not open, indicating a communication failure with LinkServer. Probe Discovery Issue: The IDE occasionally fails to properly discover or communicate with the debug probe. Troubleshooting Steps Already Tried: Verified that build errors must be resolved, but need guidance on resolving the specific compilation/linker errors preventing the .axf file generation. Restarted MCUXpresso IDE and power-cycled the debug probe / development board. Re: Build errors, Missing .axf file, and RedlinkServerException during debug launch Hello @Maheswari123 , Thanks for your post.  1. Release build failure / missing .axf or .elf file The .axf/.elf executable can only be generated after the project has been compiled and linked successfully. Therefore, please first identify the actual compiler/linker error that is preventing the Release build from completing. Please Clean the project and rebuild the Release configuration, then provide the complete build output from the Console, especially the first error together with the messages around it. With the actual compiler/linker error, we can determine whether the issue is related to source/include paths, linker configuration, undefined references, or something else. You can also try opening an SDK demo to see if you can successfully build it. This can help determine whether the issue lies with the tool or with your custom code. 2. CMSIS-DAP / LinkServer communication issue For RedlinkServerException and intermittent probe discovery, please check whether Windows recognizes the CMSIS-DAP probe and whether firewall or security software is blocking communication with Redlink Server. After ending any debug sessions, you can try Clean Up Debug and then search for the probe again. In addition, please let us know the exact CMSIS-DAP probe being used (for example, MCU-Link, OpenSDA CMSIS-DAP, or another probe). If the issue persists, please also provide the complete LinkServer console/log output related to the error. Looking forward to your reply. BR Celeste
View full article
版本错误,缺少 .axf 文件文件,以及调试启动期间的 RedlinkServerException 您好,NXP支持团队, 我在 MCUXpresso IDE 中构建和调试项目时遇到了多个问题。 环境详情: MCUXpresso IDE 版本:v11.8.0 主机操作系统:Windows 目标板/MCU:MKM34z256vll7 调试探针:CMSIS-DAP 观察到的症状: 构建错误/缺少 .axf/.elf 文件:尝试构建 版本 配置时,出现构建错误。由于这些错误,无法生成 .axf/.elf 输出文件,导致出现“程序文件不存在”调试用上市,不用发布错误。 RedlinkServerException:尝试调试或连接时,我收到 RedlinkServerException:无法写入未打开的服务器,表明与 LinkServer 的通信失败。 探针发现问题: IDE 有时无法正确发现调试探针或与其通信。 已尝试过的故障排除步骤: 已确认构建错误必须解决,但需要指导以解决阻止生成 .axf 文件的具体编译/链接器错误。文件生成。 重启了 MCUXpresso IDE 并对调试探针/开发板进行了断电重启。 Re: Build errors, Missing .axf file, and RedlinkServerException during debug launch 你好@Maheswari123 , 感谢你的帖子。 1. 版本版本失败/缺少 .axf 文件或 .elf文件 只有在项目编译和链接成功之后,才能生成 .axf/.elf 可执行文件。 因此,请首先确定导致发布版本构建无法完成的实际编译器/链接器错误。请清理项目并重新构建版本配置,然后提供控制台的完整构建输出,特别是第一个错误及其周围的消息。通过实际的编译器/链接器错误,我们可以确定问题是与源/包含路径、链接器配置、未定义的引用还是其他原因有关。 您也可以尝试打开一个 SDK 演示程序,看看是否可以成功构建。这有助于确定问题是出在工具本身还是出在您自己的自定义代码上。 2. CMSIS-DAP/LinkServer 通信问题 对于 RedlinkServerException 和间歇性探测发现,请检查 Windows 是否识别 CMSIS-DAP 探测,以及防火墙或网络安全软件是否阻止了与 Redlink 服务器的通信。结束所有调试会话后,您可以尝试清理调试,然后再次搜索探针。 此外,请与我们联系所使用的确切 CMSIS-DAP 探针(例如,MCU-Link、OpenSDA CMSIS-DAP 或其他探针)。如果问题仍然存在,请同时提供与该错误相关的完整 LinkServer 控制台/日志输出。 期待你的答复。 BR 塞莱斯特
View full article
ビルドエラー、.axfファイルが見つかりませんファイル、およびデバッグ起動中の RedlinkServerException こんにちは、NXPサポートチームの皆さん、 MCUXpresso IDEでプロジェクトの構築とデバッグを試みているときに、複数の問題に直面しています。 環境の詳細: MCUXpresso IDE バージョン:v11.8.0 ホストOS: Windows ターゲットボード/MCU:MKM34z256vll7 デバッグプローブ: CMSIS-DAP 観察された症状: ビルドエラー / .axf/.elf ファイルが見つかりません:リリース構成をビルドしようとすると、ビルドエラーが発生します。これらのエラーのため、.axf/.elf 出力ファイルが生成されず、 「プログラム ファイルが存在しません」というデバッグ起動エラーが発生します。 RedlinkServerException: デバッグや接続を試みると、RedlinkServerException: Write not opened(開いていないサーバーに書き込みできません)というメッセージを受け取り、LinkServerとの通信失敗を示しています。 プローブ発見の問題: IDEがデバッグプローブと正しく検出または通信できないことがあります。 既に試したトラブルシューティング手順: ビルドエラーを解決する必要があることは確認済みですが、.axf ファイルの生成を妨げる特定のコンパイル/リンカーエラーの解決方法についてガイダンスが必要です。ファイル生成。 MCUXpresso IDEを再起動し、デバッグプローブ/開発ボードの電源を入れ直しました。 Re: Build errors, Missing .axf file, and RedlinkServerException during debug launch こんにちは、 @Maheswari123 さん。 投稿ありがとうございます。 1. リリースビルドの失敗 / .axf ファイルが見つからないまたは.elfファイル .axf/.elf実行ファイルは、プロジェクトが成功裏にコンパイル・リンクされた後にしか生成できません。 したがって、まずリリースビルドの完了を妨げている実際のコンパイラ/リンカーエラーを特定してください。プロジェクトをクリーンアップしてリリース構成を再構築し、コンソールからの完全なビルド出力、特に最初のエラーとその周辺のメッセージを提供してください。実際のコンパイラ/リンカーエラーを使えば、問題がソース/インクトゥルパス、リンカーの設定、未定義の参照、あるいは他の何かに関連しているのかを判断できます。 SDKデモを開いて、うまくビルドできるか試してみてください。これにより、問題がツール自体にあるのか、カスタムコードにあるのかを判断するのに役立ちます。 2. CMSIS-DAP / LinkServer 通信の問題 RedlinkServerExceptionおよび断続的なプローブ検出については、WindowsがCMSIS-DAPプローブを認識しているか、またファイアウォールやセキュリティソフトウェアがRedlinkサーバーとの通信をブロックしていないかを確認してください。デバッグセッションを終了した後、クリーンアップデバッグを試してから再度プローブを検索することができます。 さらに、使用されている正確なCMSIS-DAPプローブ(例:MCU-Link、OpenSDA CMSIS-DAP、または他のプローブ)も教えてください。問題が解決しない場合は、エラーに関連するLinkServerのコンソール/ログ出力全体も提供してください。 ご返信をお待ちしております。 BR セレステ
View full article
申请 S32 DS for ARM v2018 R1 许可证延期 亲爱的恩智浦支持团队 我写这封信是为了请求延长我们的 S32 Design Studio for ARM v2018 R1 许可证的到期日期。 我们目前的许可证即将于 2026 年 3 月 10 日到期。我们希望续签许可证,以确保软件的持续使用不受任何干扰。 以下是许可证的详细信息: -产品:适用于 ARM v2018 R1 的 S32 设计工作室 - 激活代码7B20-AC2E-8F18-970E 能否请您协助延长该激活码的有效期? 感谢您的支持。 Re: Request for S32 DS for ARM v2018 R1 License Extension 你好、 您的 S32DS 许可证已延期。 Re: Request for S32 DS for ARM v2018 R1 License Extension 您好,NXP团队: 我还想申请延长我的S32 Design Studio for ARM v2018 R1 许可证。我的激活码:9D31-3A20-FFB1-F104。 感谢您!
View full article
在 CW_PA_v10.5.1 中安装 QCVS 软件包时出错 您好, 我需要为 PBL 创建一个 QorIQ 配置项目,因此需要安装 QCVS 软件包。 我下载了“QCVS Offline Installation Packages for CodeWarrior for Power Architectures Rev 4.5.zip”之前从支持门户网站下载的。最近,我在一台新笔记本电脑上安装了CodeWarrior 10.5.1 。 但是我无法在 CodeWarrior 中安装或添加 QCVS 包。安装过程中,我遇到以下错误: 请帮我解决这个问题。 此致, 维玛尔普拉萨德。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 请卸载您电脑上的CodeWarrior软件。 请从以下链接下载“适用于 Power Architecture 的 CodeWarrior Rev 4.5 的 QCVS 离线安装包.zip”和“适用于 Power Architecture 的 CodeWarrior 开发工作室 v10.5.1 – Windows.exe”。 https://support.nxp.com/s/case/500Te00000gyh6mIAA/community-error-while-installing-the-qcvs-package-in-cwpav1051?language=en_US 请先安装适用于 PA 10.5.1 的 CodeWarrior。然后,在新工作区中打开 CodeWarrior IDE,并安装“适用于 Power Architectures Rev 4.5 的 CodeWarrior 的 QCVS 离线安装包.zip”。来自 CodeWarrior IDE 的帮助->安装新软件->添加->归档。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 嗨@yipingwang , 谢谢你的回复。 我已在新工作区中尝试过,但安装时仍然出现此错误。 是否有适用于 CW_PA_v10.5.1 的最新版 QCVS 工具? 此致, 维玛尔普拉萨德。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 请先在新工作区中打开 CodeWarrior IDE,然后从 CodeWarrior IDE 的“帮助”->“安装新软件”->“添加”->“归档”安装 QCVS 4.5。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 嗨@yipingwang , 我仍然遇到以下错误。 同时添加了适用于 Power Architectures 的 CodeWarrior Rev 4.5 的 QCVS 离线安装包.zip。 它显示“processcheck”操作中未设置“path”参数。 此致, 维玛普拉萨德·M Re: Error while installing the QCVS package in CW_PA_v10.5.1 你使用的是什么操作系统?Windows 11? Re: Error while installing the QCVS package in CW_PA_v10.5.1 嗨@yipingwang , 是的,我使用的是 Windows 11。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 嗨@yipingwang , 谢谢你的回复。 有没有办法在 Windows 11 上安装 CW 10.5.1 和 QCVS 4.5? 或者,是否有适用于 Windows 11 的更新版 QCVS? Re: Error while installing the QCVS package in CW_PA_v10.5.1 我在我的 Windows 11 操作系统环境下也重现了您的问题。 我建议您在 Windows 10 虚拟机上安装 CW 10.5.1 和 QCVS 4.5。 Re: Error while installing the QCVS package in CW_PA_v10.5.1 目前我们还没有适用于 Windows 11 的新版 QCVS 软件。 带来不便敬请谅解。
View full article
Request for S32 DS for ARM v2018 R1 License Extension Dear NXP Support Team, I am writing to request an expiration date extension for our S32 Design Studio for ARM v2018 R1 license. Our current license is scheduled to expire shortly on March 10, 2026. We would like to renew the license to ensure continuous use of the software without any disruptions. Here are the details of the license:  - Product: S32 Design Studio for ARM v2018 R1  - Activation Code: 7B20-AC2E-8F18-970E Could you please assist in extending the expiration date for this activation code? Thank you for your support. Re: Request for S32 DS for ARM v2018 R1 License Extension Hi,  your S32DS license has been extended.  Re: Request for S32 DS for ARM v2018 R1 License Extension Hi NXP Team, I also like to request extend my S32 Design Studio for ARM v2018 R1 license. My activation code: 9D31-3A20-FFB1-F104. Thanks you!
View full article
Error while installing the QCVS package in CW_PA_v10.5.1 Hi, I need to create a QorIQ Configuration Project for PBL and therefore need to install the QCVS package. I downloaded "QCVS Offline Installation Packages for CodeWarrior for Power Architectures Rev 4.5.zip" from the support portal some time ago. Recently, I installed CodeWarrior 10.5.1 on a new laptop. However, I am unable to install or add the QCVS package to CodeWarrior. During the installation, I encounter the following error: Please help me to resolve this issue. Regards, Vimalprasad. Re: Error while installing the QCVS package in CW_PA_v10.5.1 Please uninstall CodeWarrior software on your PC. Please download "QCVS offline installation packages for CodeWarrior for Power Architectures Rev 4.5.zip" and  “CodeWarrior Development Studio for Power Architecture v10.5.1 – Windows.exe” from the following link https://support.nxp.com/s/case/500Te00000gyh6mIAA/community-error-while-installing-the-qcvs-package-in-cwpav1051?language=en_US Please install CodeWarrior for PA 10.5.1 first. Then open CodeWarrior IDE in a new workspace and install "QCVS offline installation packages for CodeWarrior for Power Architectures Rev 4.5.zip" from Help->Install New Software->Add->Archive in CodeWarrior IDE. Re: Error while installing the QCVS package in CW_PA_v10.5.1 Hi @yipingwang , Thanks for your response, I have tried in the new workspace, but still I'm getting this error while installing. Is there any latest version of QCVS tool is there for CW_PA_v10.5.1? Regards, Vimalprasad. Re: Error while installing the QCVS package in CW_PA_v10.5.1 Please open CodeWarrior IDE in a new workspace first and install QCVS 4.5 from Help->Install New Software->Add->Archive in CodeWarrior IDE. Re: Error while installing the QCVS package in CW_PA_v10.5.1 Hi @yipingwang , I'm still getting this following error. while adding this QCVS offline installation packages for CodeWarrior for Power Architectures Rev 4.5.zip. It shows the "path" parameter was not set in the "processcheck" action. Regards, Vimalprasad M Re: Error while installing the QCVS package in CW_PA_v10.5.1 What OS are you using? Windows 11? Re: Error while installing the QCVS package in CW_PA_v10.5.1 Hi @yipingwang , Thanks for your reply,  Is there any way to install CW 10.5.1 and QCVS 4.5 on a Windows 11? Or, is there any updated QCVS version is there for Window 11? Re: Error while installing the QCVS package in CW_PA_v10.5.1 I also reproduced your problem on my Windows 11 OS environment. I suggest you install CW 10.5.1 and QCVS 4.5 on a Windows 10 VM. Re: Error while installing the QCVS package in CW_PA_v10.5.1 Hi @yipingwang ,       Yes, I'm using Windows 11. Re: Error while installing the QCVS package in CW_PA_v10.5.1 We don't have new version QCVS software for Windows 11 so far. Sorry for the inconvenience. 
View full article
VRC_CTRLに関する説明 こんにちは、NXPサポートの皆さん、 S32K3のVRC_CTRL(PTE13)についていくつか質問させてください。 (1) RMがVRC_CTRL直接信号だと言及していますが、以下の表(赤字)の理解や質問を確認してください。 ALTx OBE IBE VRC_CTRL 質問 汎用I/O (GPIO) ディセーブルされる ディセーブルされる イネーブル VRC_CTRLは有効になりますよね? 汎用I/O (GPIO) ディセーブルされる イネーブル イネーブル VRC_CTRLは引き続き有効ですよね? 汎用I/O (GPIO) イネーブル 気にしない イネーブル 誰に効力が及ぶのか? (2)PTE13をGPIO + OBE有効 + 出力レベル低 に設定すると 、VRC_CTRLがエラー信号として扱われるため、VRC_CTRLの負帰還メカニズムが壊れ、GPIOとVRC_CTRLが同時にピンを駆動するようになるのでしょうか? (3)NXP MCALでは、PTE13をPG_VRC_CTRL_OUTとして設定すれば、関数Port_Ipw_SetOnlyOutputMode()によってOBEが自動的に設定されますが、これはMCALの問題でしょうか? (4)VRC_CTRLフィードバック機構のテスト方法、どの条件下でどのような波形が期待されるか? (5)MSCR141がRMで「サポートされていません」と記載されているのはなぜですか? ありがとうございます。 BR Re: VRC_CTRL Clarification こんにちは、パベルさん。 詳細なご回答をありがとうございました。 ラストマイルレギュレータで使用されている間は、VRC_CTRLをGPIO出力として設定したり、強制的に使用したりしないでください。特に、GPIO出力レベルをLowに設定することは、レギュレータを無効化または制御する正しい方法ではありません。 VRC_CTRLが有効になっている場合とOBEが同時に有効になっている場合、どうなりますか?PTE13には中級レベルが設けられるかもしれない。 ダイレクト信号とSIUL2出力多重の両方の合計駆動経路を示す図はどこで見つかりますか? 以下は私の測定値です。VRC_CTRLが有効になると、GPIO出力がPTE13に影響を与えることがあります。 検証のためには、起動時および負荷変動時に、V15とVRC_CTRLを同時に測定する必要があります。 負荷変更をトリガーするにはどうすればいいですか?コアの周波数を切り替えることでできますか?   MSCR141は「サポート対象外」と記載されています。これは、PTE13/VRC_CTRLが通常のSIUL2出力多重化パスではなく、PMCからの直接接続を使用するためです。したがって、MSCR141はVRC_CTRL機能の制御に使用してはなりません。 ここでよく理解できなかったのですが、少なくとも無効GPIO141無効VRC_CTRL使えるのに、なぜRMはMSCR141サポートしていないとだけ書いているのでしょうか? 実はデバッガーからMSCR141にアクセスできて、そこで設定を切り替えられます。 Port_Ipw_SetOnlyOutputMode() に関して言えば、この関数が呼び出されたという事実だけでは、PMC レギュレータが影響を受けていることを証明するものではありません。 すみません、あなたの言いたいことがよく分かりませんでした。 実際、これが私がこの質問をした主な理由です。MCALポートモジュールでPTE13 PinModeをPG_VRC_CTRL_OUTに設定すると、次のコードが生成されます。 #define SIUL2_0_PORT141_PG_VRC_CTRL_OUT (PORT_ONLY_OUTPUT_MODE) Port_Ipw_SetOnlyOutputMode() will be called and “OBE” bit will set in this function.​ MCALのバグかもしれません。PG_VRC_CTRL_OUTモードが誤ってOBEを有効にしている可能性があります。 確認を手伝ってもらえますか? GPIO + PORT_PIN_HIGH_Z + PORT_PIN_LEVEL_NOTCHANGE に設定することは回避策だと思いますか?この場合、PTE13のMSCR141は確実に0(OBE = 0)になることが保証されます。 よろしくお願いいたします。 くまモン Re: VRC_CTRL Clarification こんにちは、 @kumamon さん。 主な誤解は、VRC_CTRLが通常のSIUL2/GPIO出力として扱われていることにあると思います。 VRC_CTRLは、PMCラストマイルレギュレータの直接出力です。外部バラストトランジスタ電源オプションを使用すると、PMCはV15ドメインを監視し、外部NPNトランジスタのベースにコネクテッドされたVRC_CTRLを調整します。これにより閉鎖されたアナログフィードバックループが形成されます。したがって、VRC_CTRLは通常のGPIO出力データレジスタを介して制御されるものではありません。 このため、表中のGPIO ALTx、IBE、OBEの組み合わせはVRC_CTRL関数には適用されません。 IBEはデジタル入力バッファのみを制御し、V15レギュレータのフィードバックループには関与しません。 ラストマイルレギュレータで使用されている間は、VRC_CTRLをGPIO出力として設定したり、強制的に使用したりしないでください。特に、GPIO出力レベルをLowに設定することは、レギュレータを無効化または制御する正しい方法ではありません。 ラストマイルレギュレータは、PMC_CONFIG[LMBCTLEN]フィールドや、デバイス固有のPMCの章に記載されている初期化シーケンスなど、PMCによって制御されます。 VRC_CTRLはデジタルステータス出力ではなくアナログ制御信号です。したがって、すべてのデザインに適用される単一の固定波形は存在しません。その電圧は外部トランジスタ、V15負荷、電源電圧、外部静電容量、動作モードに依存します。検証のためには、起動時および負荷変動時に、V15とVRC_CTRLを同時に測定する必要があります。期待される結果は、VRC_CTRLが必要に応じて外部トランジスタを調整している間、V15が規定の動作範囲内に留まることです。 MSCR141は「サポート対象外」と記載されています。これは、PTE13/VRC_CTRLが通常のSIUL2出力多重化パスではなく、PMCからの直接接続を使用するためです。したがって、MSCR141はVRC_CTRL機能の制御に使用してはなりません。 Port_Ipw_SetOnlyOutputMode() に関して言えば、この関数が呼び出されたという事実だけでは、PMC レギュレータが影響を受けていることを証明するものではありません。 また、リセット動作は導関数に固有のものであることにご注意ください。例えば、S32K3x8(およびS32K356)PMCはデバイス固有のCONFIGリセット値が0x00000083なので、リセット後にラストマイルレギュレーター構成が有効になります。これは、LMBCTLENを明示的に有効にする必要がある場合がある古いS32K3派生版から一般化して適用すべきではありません。 よろしくお願いいたします。 パベル Re: VRC_CTRL Clarification こんにちは、 @kumamon さん。 寸法を教えていただきありがとうございます。彼らは設定MSCR141[OBE] = 1)がデジタル出力ドライバーを有効にし、GPIOレベルがVRC_CTRLノードに影響を与えることを確認しています。PMCラストマイルレギュレータがアクティブな状態でGPIO出力ドライバーを有効にするのはサポートされていない構成であり、V15の規制を乱す可能性があります。 これは必ずしもMCALドライバの欠陥を示すものではありません。PTE13/VRC_CTRLは、用途ごとに取り扱う必要がある特殊なピンです。汎用ポートドライバは出力モードが要求されるとOBEを有効にしますが、PMCレギュレーターと外部バラストトランジスタ回路が使用されているかどうかを判別できません。 提案された回避策は、結果としてMSCR141[OBE] = 0となる構成であれば適切です。 PORT_PIN_HIGH_Zを使用してください。 PORT_PIN_LEVEL_NOTCHANGED を使用してください。 Port_Init() の後に MSCR141[OBE] を確認してください。 VRC_CTRLがアクティブな間は、PTE13をデジタル出力として設定しないでください。 必須条件は、デジタル出力バッファを無効にしておくことです。 よろしくお願いいたします。 パベル Re: VRC_CTRL Clarification こんにちは、パベルさん。 ご回答ありがとうございます。 汎用ポートドライバは出力モードが要求されるとOBEを有効にします。 次の図において、 PG_VRC_CTRL_OUT以外の設定で「出力モード」を導入するものはどれかご存知ですか?申し訳ありませんが、MCAL PortがPG_VRC_CTRL_OUTを誤って出力モードにマッピングしているように感じます。 検証のためには、起動時および負荷変動時に、V15とVRC_CTRLを同時に測定する必要があります。 負荷変更をトリガーするにはどうすればいいですか?コアの周波数を切り替えることでできますか?   ありがとうございます。 BR/くまモン Re: VRC_CTRL Clarification こんにちは、 @kumamon さん。 あなたの懸念は理解できました。設定で選択する内容: ピン方向 = ポートピンHIGH_Z ピンレベル値 = PORT_PIN_LEVEL_NOTCHANGED ピンモード = PG_VRC_CTRL_OUT したがって、デジタル出力バッファは有効にされないことが想定されます。生成されたコードがそれでもOBE = 1に設定してしまう場合は、MCALポートの設定でこの動作を調査する必要があります。 MSCR141は、この特殊用途の直接信号には対応していないことが文書で明記されていることにご注意ください。PTE13/VRC_CTRLはPMCによって制御されるため、通常のSIUL2出力バッファ構成は必要ありません。したがって、手動でMSCR141にアクセスしたり変更したりすることは、サポートされた適用方法ではありません。 正確なMCAL/RTDバージョンと、OBEを設定する生成された設定および初期化コードも教えていただけますか?また、中古のS32K3 MCUの正確なバージョンも教えてください。 CPUの負荷に関しては、これはレギュレータの応答を観察するためのオプションの提案に過ぎず、VRC_CTRL構成を検証するために必須ではありません。 よろしくお願いいたします。 パベル Re: VRC_CTRL Clarification こんにちは、パベルさん。 ありがとうございます。 スクリーンショットに示されている設定は正しいようです。 しかし問題は、生成されたコードがOBEビットを有効にしてしまうことであり、これは想定外のことだ。 クロック構成を変更せずにCPUのワークロードを変更する方が、コア周波数を変更するよりも一般的に解釈しやすい。 CPUワークロードを変更する方法について少し説明してもらえますか? ありがとうございます。 BR/くまモン。 Re: VRC_CTRL Clarification こんにちは、パベルさん。 ありがとうございます。 MSCR141は、この特殊用途の直接信号には対応していないことが文書で明記されていることにご注意ください。 以下の図によると、PTE13は必ずしもVRC_CTRLではなく、他のどの関数でもなり得ます。「MSCR141はサポートされていません」という記述と矛盾しているように感じます。 正確なMCAL/RTDバージョンと、OBEを設定する生成された設定および初期化コードも教えていただけますか?また、中古のS32K3 MCUの正確なバージョンも教えてください。 RTDバージョン: 構成: 生成: 注:申し訳ありません、前回の議論で間違いがありました。OBEはPort_Ipw_SetOnlyOutputMode()では設定されず、Siul2_Port_Ip_PinInit()で設定する必要があります。 MCU:S32K322 ありがとうございます。 BR/くまモン Re: VRC_CTRL Clarification こんにちは、 @kumamon さん。 スクリーンショットに示されている設定は正しいようです。 負荷変動測定に関しては、これはレギュレータの応答を評価するためのオプションの提案にすぎませんでした。VRC_CTRLの設定を検証する必要はありません。そのようなテストが必要な場合、クロック構成を変更せずにCPUのワークロードを変更する方が、コア周波数を変更するよりも一般的に解釈しやすい。 よろしくお願いいたします。 パベル Re: VRC_CTRL Clarification こんにちは、パベルさん。 詳しい説明をありがとうございました。 最も良い方法は、MCALポートの設定からPTE13を完全に除外することのようです。 私たちのユースケースは少し特別です: ブートローダーでは、ほとんどのピンが入力(IBE = 1)として設定されています。// そして、現時点ではブートローダーを変更したくありません。 - アプリケーション上、PTE13を完全に手つかずにするためにGPIO + HIGH_Zに設定し、その時にIBEをクリアできるようにしています。 質問(長々と書いてしまってすみません) : - 前回の議論によると、「IBE = 1」はVRC_CTRL関数に影響を与えない、ということですよね?IBE=1のままにしてもいいですか? - PTE13をGPIO + HIGH_Zに設定してアプリケーションで完璧な未修正状態を達成しても問題ないですよね? よろしくお願いします。 BR/くまモン Re: VRC_CTRL Clarification こんにちは、 @kumamon さん。 私は詳細な調査を行った。結果は以下のとおりです。 S32K3 RTD 4.0.0とRTD 7.0.1の間で、ポート構成データとそれに伴う動作は一貫しています。 S32K3 リファレンスマニュアル: MSCR141サポートされていないという声明には、より明確なデバイスごとの説明が必要です。MSCR141は、PTE13およびVRC_CTRLピン機能が定義されていないS32K388およびS32K389ではサポートされていません。 PTE13をVRC_CTRLとして使用する場合の構成: PTE13をPMCラストマイルレギュレータのVRC_CTRL出力として使用する場合、MCALポートモジュールでピンを構成する必要はありません。 PTE13をGPIOや他のペリフェラル機能として使用する場合の構成: この場合、PMCのVRC_CTRL機能はアクティブであってはなりません。これは、リセット後に最終段階の規制当局が有効になるデリバティブ商品にとって特に重要です。アプリケーションは通常のSIUL2関数にPTE13を割り当てる前に、まずPMC電源を適切に設定する必要があります。 したがって、この2つのユースケースは相互に排他的として扱うべきです。 VRC_CTRL の使用法: PMCラストマイルレギュレータを設定します。 MCALポートモジュールはPTE13には手を加えないでください。 GPIOまたはペリフェラルの使用: PMCラストマイルレギュレーターを無効にするか、使用しないでください。 MCALポートモジュールを介してPTE13を設定します。 あなたの測定結果はこの区別と一致しています。PMC VRC_CTRL機能とSIUL2デジタル出力バッファが同時に作動している場合、デジタル出力経路がVRC_CTRLノードに影響を与え、V15の制御を乱す可能性があります。したがって、このような同時構成は避けるべきである。 よろしくお願いいたします。 パベル Re: VRC_CTRL Clarification こんにちは、@Pavel さん。 効果的で詳細なサポートに感謝します。 これで明確になりましたので、このチケットはクローズします。 BR/クマノン Re: VRC_CTRL Clarification こんにちは、 @kumamon さん。 利用ケースを明確にしてくれてありがとうございます。 はい、IBE = 1は有効のままにできます。 はい、PTE13をGPIO + HIGH_Zに設定できます。 MCALポートの設定でPG_VRC_CTRL_OUTを選択しないようにしてください。RTDは、選択されたPortPinDirectionに関係なく、このモードをPORT_ONLY_OUTPUT_MODEとして分類し、結果として出力バッファを有効にします。PORT_PIN_HIGH_Zを選択しても、PG_VRC_CTRL_OUTのこの動作は上書きされません。 よろしくお願いいたします。 パベル
View full article
eFlexPWMを使用した初期PWM出力値 こんにちは、 MCXA132のeFlexPWMを使用して、PWM23の初期値を変更したいと考えています。 そのため、私は以下の手順を実行します。 1. SM1CTRL2[PWM23_INIT] = 1 2. SM1CTRL2[FRCEN] = 1 SM1CTRL2[力] = 1(SM1CTRL2[FORCE_SEL]は000であることに注意) 3. MCTRL[RUN] = 010 しかし最初のPWMサイクルは常に出力レベル0から始まります。 問題はどこにあるのでしょうか? よろしくお願いします MCXA Re: Initial PWM output value with eFlexPWM こんにちは、 @zorrotz さん。 問題の分析に協力するために、あなたのプロジェクト全体をぜひ共有していただけますか? よろしくお願いします。 BR アリス Re: Initial PWM output value with eFlexPWM こんにちは、 自分の間違いに気づきました。 リファレンス・マニュアルには次のような注記があります: 「MCTRL[LDOK]が設定されていない場合、MCTRL[RUN]を設定するとSTS[RF]フラグも設定されます。CPU割り込み要求を防ぐには、MCTRL[RUN]を設定する前にINTEN[RIE]をクリアしてください。 私はSTS[RF]を使ってPWMサイクルを終わらせていますが、MCTRL[RUN] = 1を行う前にSTS[RF]をクリアしています。 よろしくお願いします。
View full article
VRC_CTRL Clarification Hello NXP Support, I would like to ask some questions on S32K3's VRC_CTRL (PTE13). (1) RM mentions VRC_CTRL is direct signal, could you please check the understanding/question in the following table (red font)? ALTx OBE IBE VRC_CTRL Question GPIO Disabled Disabled Enabled VRC_CTRL will take effect, right? GPIO Disabled Enabled Enabled VRC_CTRL will still take effect, right? GPIO Enabled Not Care Enabled Who will take effect? (2) If we configure PTE13 as GPIO + OBE Enabled + Output Level Low, will the VRC_CTRL negative feedback mechanism be broken because VRC_CTRL is treated as error signal and now maybe GPIO and VRC_CTRL are driving the pin at the same time? (3) In NXP MCAL, as long as I configure PTE13 as PG_VRC_CTRL_OUT, OBE will be automatically set by function Port_Ipw_SetOnlyOutputMode(), is it an issue of MCAL? (4) How to test VRC_CTRL feedback mechanism , what waveform is expected during which condition? (5) Why is MSCR141 documented as "Not Supported" in RM? Thanks. BR Re: VRC_CTRL Clarification Hello Pavel, Thanks a lot for your detailed answer. VRC_CTRL should not be configured or forced as a GPIO output while it is used by the last-mile regulator. In particular, setting a GPIO output level to Low is not the correct way to disable or control the regulator. What will happen if VRC_CTRL is enabled and OBE is also enabled at the same time? Maybe a intermediate level will be present on PTE13? Where can I find some diagram to describe the combined driving path from both direct signal and SIUL2 output-multiplexing? The following is my measurement. You can see when VRC_CTRL is enable, GPIO output can have some impact to the PTE13. For validation, V15 and VRC_CTRL should be measured together during startup and under load changes. How to trigger the load change, is it by switching the frequency of the core?   MSCR141 is documented as “Not Supported” because PTE13/VRC_CTRL uses a direct connection from the PMC rather than the normal SIUL2 output-multiplexing path. Therefore, MSCR141 must not be used to control the VRC_CTRL function. I didn't quite understand here, at least GPIO141 can be used when VRC_CTRL is disabled, why does RM just mention MSCR141 is not supported? Actually I can access MSCR141 from debugger, and I can switch the settings there.  Regarding Port_Ipw_SetOnlyOutputMode(), the fact that this function is called does not by itself prove that the PMC regulator is affected. Sorry, I didn't get your point here. Actually this is the main reason I asked this question, following code will be generated when I configure PTE13 PinMode as PG_VRC_CTRL_OUT in MCAL Port module. #define SIUL2_0_PORT141_PG_VRC_CTRL_OUT (PORT_ONLY_OUTPUT_MODE) Port_Ipw_SetOnlyOutputMode() will be called and “OBE” bit will set in this function.​ I think it maybe a MCAL bug, PG_VRC_CTRL_OUT mode enables OBE by mistake. Could you please help to check? Do you think that configuring it to GPIO + PORT_PIN_HIGH_Z + PORT_PIN_LEVEL_NOTCHANGE can be a workaround, in this case, MSCR141 of PTE13 can be guaranteed to be 0 (OBE = 0)? Best regards Kumamon Re: VRC_CTRL Clarification Hello @kumamon , I think the main misunderstanding is that VRC_CTRL is being treated as a regular SIUL2/GPIO output. VRC_CTRL is a direct output of the PMC last-mile regulator. When the external ballast-transistor supply option is used, the PMC monitors the V15 domain and adjusts VRC_CTRL, which is connected to the base of the external NPN transistor. This forms a closed analog feedback loop. Therefore, VRC_CTRL is not controlled through the normal GPIO output data registers. For this reason, the GPIO ALTx, IBE and OBE combinations in the table are not applicable to the VRC_CTRL function: IBE only controls the digital input buffer and has no role in the V15 regulator feedback loop. VRC_CTRL should not be configured or forced as a GPIO output while it is used by the last-mile regulator. In particular, setting a GPIO output level to Low is not the correct way to disable or control the regulator. The last-mile regulator is controlled by the PMC, including the PMC_CONFIG[LMBCTLEN] field and the initialization sequence documented in the device-specific PMC chapter. VRC_CTRL is an analog control signal rather than a digital status output. Consequently, there is no single fixed waveform that applies to all designs. Its voltage depends on the external transistor, V15 load, supply voltage, external capacitance and operating mode. For validation, V15 and VRC_CTRL should be measured together during startup and under load changes. The expected result is that V15 remains within its specified operating range while VRC_CTRL adjusts the external transistor as required. MSCR141 is documented as “Not Supported” because PTE13/VRC_CTRL uses a direct connection from the PMC rather than the normal SIUL2 output-multiplexing path. Therefore, MSCR141 must not be used to control the VRC_CTRL function. Regarding Port_Ipw_SetOnlyOutputMode(), the fact that this function is called does not by itself prove that the PMC regulator is affected. Please also note that the reset behavior is derivative-specific. For example, the S32K3x8 (and S32K356) PMC has a device-specific CONFIG reset value of 0x00000083, so the last-mile regulator configuration is enabled after reset. This must not be generalized from older S32K3 derivatives where LMBCTLEN may need to be enabled explicitly. Best regards, Pavel Re: VRC_CTRL Clarification Hello Pavel, Thanks for the answer. The generic Port driver enables OBE when an output mode is requested. Do you know which setting other than PG_VRC_CTRL_OUT in the following figure introduces the "output mode"? Sorry, but I still feel MCAL Port maps the PG_VRC_CTRL_OUT to output mode by mistake. For validation, V15 and VRC_CTRL should be measured together during startup and under load changes. How to trigger the load change, is it by switching the frequency of the core?   Thanks. BR/Kumamon Re: VRC_CTRL Clarification Hello @kumamon , Thank you for the measurements. They confirm that setting MSCR141[OBE] = 1 enables the digital output driver and allows the GPIO level to influence the VRC_CTRL node. Enabling the GPIO output driver while the PMC last-mile regulator is active is not a supported configuration and can disturb V15 regulation. This does not necessarily indicate an MCAL driver defect. PTE13/VRC_CTRL is a special-purpose pin that requires application-specific handling. The generic Port driver enables OBE when an output mode is requested, but it cannot determine whether the PMC regulator and the external ballast-transistor circuit are being used. Your proposed workaround is appropriate, provided that the resulting configuration leaves MSCR141[OBE] = 0: Use PORT_PIN_HIGH_Z. Use PORT_PIN_LEVEL_NOTCHANGED. Verify MSCR141[OBE] after Port_Init(). Do not subsequently configure PTE13 as a digital output while VRC_CTRL is active. The essential requirement is to keep the digital output buffer disabled. Best regards, Pavel Re: VRC_CTRL Clarification Hello Pavel, Thanks. The configuration shown in your screenshot appears to be correct. But the question is that the generated code will enable OBE bit, which is not expected. changing the CPU workload while keeping the clock configuration unchanged is generally easier to interpret than changing the core frequency. Could you please explain a bit on how to change CPU workload? Thanks. BR/Kumamon. Re: VRC_CTRL Clarification Hello Pavel, Thanks. Please note that MSCR141 is documented as not supported for this special-purpose direct signal. According to the following diagram, PTE13 is not necessarily VRC_CTRL, it can be any of other functions. I feel It is conflicting to the statement "MSCR141 is not supported". Could you please provide the exact MCAL/RTD version and the relevant generated configuration and initialization code that sets OBE? Also provide exact version of used S32K3 MCU. RTD Version: Configuration: Generated: Note: Sorry, I made a mistake in previous discussion. OBE is not set by Port_Ipw_SetOnlyOutputMode(), it shall be set in Siul2_Port_Ip_PinInit(). MCU: S32K322 Thanks. BR/Kumamon Re: VRC_CTRL Clarification Hello @kumamon , The configuration shown in your screenshot appears to be correct. Regarding the load-change measurement, this was only an optional suggestion for evaluating the regulator response. It is not required to verify the VRC_CTRL configuration. If such a test is desired, changing the CPU workload while keeping the clock configuration unchanged is generally easier to interpret than changing the core frequency. Best regards, Pavel Re: VRC_CTRL Clarification Hello @kumamon , I now understand your concern. Your configuration selects: Pin Direction = PORT_PIN_HIGH_Z Pin Level Value = PORT_PIN_LEVEL_NOTCHANGED Pin Mode = PG_VRC_CTRL_OUT Therefore, the digital output buffer is not expected to be enabled. If the generated code nevertheless sets OBE = 1, this behavior should be investigated in the MCAL Port configuration. Please note that MSCR141 is documented as not supported for this special-purpose direct signal. PTE13/VRC_CTRL is controlled by the PMC and should not require a normal SIUL2 output-buffer configuration. Accessing or modifying MSCR141 manually is therefore not a supported application method. Could you please provide the exact MCAL/RTD version and the relevant generated configuration and initialization code that sets OBE? Also provide exact version of used S32K3 MCU. Regarding the CPU workload, this was only an optional suggestion for observing the regulator response and is not required to verify the VRC_CTRL configuration. Best regards, Pavel Re: VRC_CTRL Clarification Hello Pavel, Thanks a lot for detailed explanation. The best way seems to be excluding PTE13 from MCAL port configuration completely. Our use-case is a little special: - In bootloader, most of the pins are configured as input (IBE = 1).   // and we do not want to change bootloader now. - in application, in order to make PTE13 perfectly untouched, I configure it to GPIO + HIGH_Z, so IBE can be cleared then. Question (Please forgive my verbosity): - According to previous discussion, "IBE = 1" will not impact VRC_CTRL function, right? I can keep IBE = 1? - If I configure PTE13 to GPIO + HIGH_Z to achieve perfect untouched state in application, it is also OK, right? Thanks BR/Kumamon Re: VRC_CTRL Clarification Hello @kumamon , I performed a detailed investigation. Here are the results: The Port configuration data and the resulting behavior are consistent between S32K3 RTD 4.0.0 and RTD 7.0.1. S32K3 Reference Manual: The statement that MSCR141 is not supported requires a clearer device-specific explanation. MSCR141 is not supported on S32K388 and S32K389, where PTE13 and the VRC_CTRL pin function are not defined. Configuration when PTE13 is used as VRC_CTRL: If PTE13 is used as the VRC_CTRL output of the PMC last-mile regulator, the pin does not need to be configured in the MCAL Port module. Configuration when PTE13 is used as GPIO or another peripheral function: In this case, the PMC VRC_CTRL function must not be active. This is particularly important for derivatives where the last-mile regulator is enabled after reset. The application must first configure the PMC supply appropriately before assigning PTE13 to a regular SIUL2 function. The two use cases should therefore be treated as mutually exclusive: VRC_CTRL use: Configure the PMC last-mile regulator. Leave PTE13 untouched by the MCAL Port module. GPIO or peripheral use: Disable or do not use the PMC last-mile regulator. Configure PTE13 through the MCAL Port module. Your measurements are consistent with this distinction. If the PMC VRC_CTRL function and the SIUL2 digital output buffer are active at the same time, the digital output path can influence the VRC_CTRL node and disturb the V15 regulation. This simultaneous configuration should therefore be avoided. Best regards, Pavel Re: VRC_CTRL Clarification Hello @kumamon , Thank you for clarifying your use case. Yes, IBE = 1 can remain enabled. Yes, you can configure PTE13 to GPIO + HIGH_Z. Just do not select PG_VRC_CTRL_OUT in the MCAL Port configuration. RTD classifies this mode as PORT_ONLY_OUTPUT_MODE, independently of the selected PortPinDirection and consequently enables the output buffer. Selecting PORT_PIN_HIGH_Z does not override this behavior for PG_VRC_CTRL_OUT. Best regards, Pavel Re: VRC_CTRL Clarification Hello @Pavel, Thank you for your effective, and detailed support. It is clear to me now, I will close this ticket. BR/Kumanon
View full article
Initial PWM output value with eFlexPWM Hi, Working with eFlexPWM of MCXA132, I want to modify the initial value for PWM23. For that I do next steps: 1. SM1CTRL2[PWM23_INIT] = 1 2. SM1CTRL2[FRCEN] = 1     SM1CTRL2[FORCE] = 1    (note that SM1CTRL2[FORCE_SEL] is 000) 3. MCTRL[RUN] = 010 But first PWM cycle always starts with output at level 0. Where can be the problem? Thanks in advance MCXA Re: Initial PWM output value with eFlexPWM Hello @zorrotz  To help us analyze the issue, could you please share your complete project with us? Thank you. BR Alice Re: Initial PWM output value with eFlexPWM Hello, I have found my mistake. The reference manual has this note: "If MCTRL[LDOK] is not set, setting MCTRL[RUN] also sets the STS[RF] flag. To prevent a CPU interrupt request, clear INTEN[RIE] before setting MCTRL[RUN]." I am using STS[RF] to end PWM cycle, but I clear STS[RF] before doing MCTRL[RUN] = 1. Thanks
View full article
VRC_CTRL 说明 您好,NXP技术支持, 我想问一些关于 S32K3 的 VRC_CTRL (PTE13) 的问题。 (1)RM提到VRC_CTRL是直接信号,请您核对下表(红色字体)中的理解/问题? ALTx OBE IBE VRC_CTRL 问题 通用IO 禁用 禁用 已启用 VRC_CTRL 会生效,对吗? 通用IO 禁用 已启用 已启用 VRC_CTRL 仍然会生效,对吗? 通用IO 已启用 不在乎 已启用 谁将负责执行? (2)如果我们配置 PTE13 为 GPIO + OBE 使能 +输出电平低,VRC_CTRL 负反馈机制是否会被破坏,因为 VRC_CTRL 被视为错误信号,而现在 GPIO 和 VRC_CTRL 可能同时驱动该引脚? (3)在 NXP MCAL 中,只要我将 PTE13 配置为 PG_VRC_CTRL_OUT,OBE 就会通过函数Port_Ipw_SetOnlyOutputMode()自动设置,这是 MCAL 的问题吗? (4)如何测试 VRC_CTRL 反馈机制,在什么情况下预期会产生什么样的波形? (5)为什么 RM 中将 MSCR141 记录为“不支持”? 谢谢。 BR Re: VRC_CTRL Clarification 你好,帕维尔, 非常感谢您的详细解答。 当 VRC_CTRL 被最后一公里稳压器使用时,不应将其配置或强制为 GPIO 输出。具体来说,将 GPIO 输出电平设置为低电平并不是禁用或控制稳压器的正确方法。 如果同时启用 VRC_CTRL 和 OBE 会发生什么情况?PTE13或许会设立中级水平? 哪里可以找到描述直接信号和 SIUL2 输出复用组合驱动路径的图表? 以下是我的测量结果。可以看到,当 VRC_CTRL 启用时,GPIO 输出会对 PTE13 产生一些影响。 为了进行验证,应在启动和负载变化期间同时测量 V15 和 VRC_CTRL。 如何触发负载变化?是通过切换磁芯频率吗?   MSCR141 被记录为“不支持”,因为 PTE13/VRC_CTRL 使用来自 PMC 的直接连接,而不是正常的 SIUL2 输出复用路径。因此,MSCR141 不能用于控制 VRC_CTRL 功能。 这里我不太明白,至少在 VRC_CTRL 被禁用时可以使用 GPIO141,为什么 RM 只提到不支持 MSCR141? 实际上,我可以从调试器访问 MSCR141,并且可以在那里更改设置。 关于 Port_Ipw_SetOnlyOutputMode(),调用此函数本身并不能证明 PMC 调节器受到影响。 抱歉,我没明白你的意思。 实际上,这就是我提出这个问题的主要原因,当我在 MCAL 端口模块中将 PTE13 PinMode 配置为 PG_VRC_CTRL_OUT 时,将生成以下代码。 #define SIUL2_0_PORT141_PG_VRC_CTRL_OUT (PORT_ONLY_OUTPUT_MODE) Port_Ipw_SetOnlyOutputMode() will be called and “OBE” bit will set in this function.​ 我认为这可能是 MCAL 的一个 bug,PG_VRC_CTRL_OUT 模式错误地启用了 OBE。 请问您能帮忙查一下吗? 您认为将其配置为 GPIO + PORT_PIN_HIGH_Z + PORT_PIN_LEVEL_NOTCHANGE是否可以作为一种变通方法,在这种情况下,可以保证 PTE13 的 MSCR141 为 0 (OBE = 0)? 顺祝商祺! 熊本 Re: VRC_CTRL Clarification 你好@kumamon , 我认为主要的误解在于将 VRC_CTRL 视为常规的 SIUL2/GPIO 输出。 VRC_CTRL 是 PMC 末端调节器的直接输出。当使用外部镇流晶体管供电选项时,PMC 会监测 V15 功能域并调整 VRC_CTRL,VRC_CTRL 连接到外部 NPN 晶体管的基极。这就形成了一个闭合的模拟反馈回路。因此,VRC_CTRL 不是通过正常的 GPIO 输出数据寄存器来控制的。 因此,表中所示的 GPIO ALTx、IBE 和 OBE 组合不适用于 VRC_CTRL 功能: IBE 仅控制数字输入缓冲器,在 V15 稳压器反馈回路中不起作用。 当 VRC_CTRL 被最后一公里稳压器使用时,不应将其配置或强制为 GPIO 输出。具体来说,将 GPIO 输出电平设置为低电平并不是禁用或控制稳压器的正确方法。 最后一公里调节器由 PMC 控制,包括 PMC_CONFIG[LMBCTLEN] 字段和设备特定 PMC 章节中记录的初始化序列。 VRC_CTRL 是一个模拟控制信号,而不是数字状态输出。因此,没有一种固定的波形适用于所有设计。其电压取决于外部晶体管、V15 负载、电源电压、外部电容和工作模式。为了进行验证,应在启动和负载变化期间同时测量 V15 和 VRC_CTRL。预期结果是 V15 保持在规定的工作范围内,而 VRC_CTRL 根据需要调整外部晶体管。 MSCR141 被记录为“不支持”,因为 PTE13/VRC_CTRL 使用来自 PMC 的直接连接,而不是正常的 SIUL2 输出复用路径。因此,MSCR141 不能用于控制 VRC_CTRL 功能。 关于 Port_Ipw_SetOnlyOutputMode(),调用此函数本身并不能证明 PMC 调节器受到影响。 另请注意,RESET行为是特定于衍生产品的。例如,S32K3x8(和 S32K356)PMC 具有设备特定的 CONFIG 复位值为 0x00000083,因此复位后即可启用最后一公里稳压器配置。这不能从较旧的 S32K3 衍生版本中推广,因为在这些版本中可能需要显式启用 LMBCTLEN。 顺祝商祺! 帕维尔 Re: VRC_CTRL Clarification 你好@kumamon , 谢谢你提供的尺寸信息。他们确认,将 MSCR141[OBE] 设置为 1 可启用数字输出驱动程序,并允许 GPIO 电平影响 VRC_CTRL 节点。在 PMC 最后一公里稳压器处于活动状态时启用 GPIO 输出驱动程序是不受支持的配置,并且可能会干扰 V15 稳压。 这并不一定表明MCAL驱动程序存在缺陷。PTE13/VRC_CTRL 是一个特殊用途的引脚,需要根据特定应用进行处理。通用端口驱动程序在请求输出模式时启用 OBE,但它无法确定是否正在使用 PMC 稳压器和外部镇流晶体管电路。 只要最终配置后的 MSCR141[OBE] = 0,您提出的变通方案就是合适的: 使用 PORT_PIN_HIGH_Z。 使用 PORT_PIN_LEVEL_NOTCHANGED。 在 Port_Init() 之后验证 MSCR141[OBE]。 当 VRC_CTRL 处于活动状态时,请勿将 PTE13 配置为数字输出。 最基本的要求是禁用数字输出缓冲器。 顺祝商祺! 帕维尔 Re: VRC_CTRL Clarification 你好,帕维尔, 谢谢你的回答。 通用端口驱动程序在请求输出模式时启用 OBE。 你知道下图除了PG_VRC_CTRL_OUT之外,还有哪个设置可以引入“输出模式”吗?抱歉,但我仍然觉得 MCAL 端口错误地将PG_VRC_CTRL_OUT 映射到了输出模式。 为了进行验证,应在启动和负载变化期间同时测量 V15 和 VRC_CTRL。 如何触发负载变化?是通过切换磁芯频率吗?   谢谢。 BR/熊本熊 Re: VRC_CTRL Clarification 你好,帕维尔, 谢谢。 从截图中看到的配置似乎是正确的。 但问题是,生成的代码会启用 OBE 位,这是意料之外的。 在保持时钟配置不变的情况下改变 CPU 工作负载,通常比改变核心频率更容易解释。 请问如何更改 CPU 工作负载? 谢谢。 BR/熊本熊。 Re: VRC_CTRL Clarification 你好@kumamon , 我现在明白你的担忧了。您的配置选择了: 引脚方向 = PORT_PIN_HIGH_Z 引脚电平值 = PORT_PIN_LEVEL_NOTCHANGED 引脚模式 = PG_VRC_CTRL_OUT 因此,预计不会启用数字输出缓冲器。如果生成的代码仍然将 OBE 设置为 1,则应在 MCAL 端口配置中调查此行为。 请注意,文档显示 MSCR141 不支持此特殊用途的直接信号。PTE13/VRC_CTRL 由 PMC 控制,不应需要正常的 SIUL2 输出缓冲区配置。因此,手动访问或修改 MSCR141 不是一种受支持的应用方法。 请提供MCAL/RTD的确切版本以及设置OBE的相关配置和初始化代码。另外,请提供所用S32K3 MCU的确切版本。 关于 CPU 工作负载,这只是观察调节器响应的一个可选的建议,并非验证 VRC_CTRL 配置的必要条件。 顺祝商祺! 帕维尔 Re: VRC_CTRL Clarification 你好,帕维尔, 谢谢。 请注意,文档显示 MSCR141 不支持此特殊用途的直接信号。 根据下图,PTE13 不一定是 VRC_CTRL,它可以是任何其他功能。我觉得这与“不支持 MSCR141”的说法相矛盾。 请提供MCAL/RTD的确切版本以及设置OBE的相关配置和初始化代码。另外,请提供所用S32K3 MCU的确切版本。 RTD 版本: 配置: 已生成: 注:抱歉,我之前的讨论中犯了个错误。OBE 不是由 Port_Ipw_SetOnlyOutputMode() 设置的,而应该在 Siul2_Port_Ip_PinInit() 中设置。 MCU:S32K322 谢谢。 BR/熊本熊 Re: VRC_CTRL Clarification 你好@kumamon , 从截图中看到的配置似乎是正确的。 关于负载变化测量,这只是评估调节器响应的一个可选的建议。无需验证 VRC_CTRL 配置。如果需要进行此类测试,在保持时钟配置不变的情况下改变 CPU 工作负载通常比改变核心频率更容易解释。 顺祝商祺! 帕维尔 Re: VRC_CTRL Clarification 你好@kumamon , 我进行了详细调查。以下是结果: S32K3 RTD 4.0.0 和 RTD 7.0.1 之间的端口配置数据和结果行为是一致的。 S32K3 参考手册:关于不支持 MSCR141 的声明需要更清晰的针对特定设备的解释。MSCR141 在 S32K388 和 S32K389 上不受支持,因为 PTE13 和 VRC_CTRL 引脚功能未定义。 当 PTE13 用作 VRC_CTRL 时进行配置:如果 PTE13 用作 PMC 末端稳压器的 VRC_CTRL 输出,则无需在 MCAL 端口模块中配置该引脚。 当 PTE13 用作 GPIO 或其他外设功能时,配置:在这种情况下,PMC VRC_CTRL 功能必须处于非活动状态。对于RESET后启用最后一公里调节器的衍生品来说,这一点尤其重要。应用程序必须先正确配置 PMC 电源,然后才能将 PTE13 分配给常规 SIUL2 功能。 因此,这两种使用场景应视为互斥的: VRC_CTRL 的用法: 配置 PMC 最后一公里调节器。 MCAL 端口模块不要触碰 PTE13。 GPIO 或外设用途: 禁用或不使用 PMC 最后一公里调节器。 通过 MCAL 端口模块配置 PTE13。 你的测量结果与这种区别相符。如果 PMC VRC_CTRL 功能和 SIUL2 数字输出缓冲器同时处于活动状态,则数字输出路径会影响 VRC_CTRL 节点并干扰 V15 调节。因此,应避免这种同时配置的情况。 顺祝商祺! 帕维尔 Re: VRC_CTRL Clarification 你好,帕维尔, 非常感谢您的详细解释。 最好的办法似乎是将 PTE13 从 MCAL 端口配置中完全排除。 我们的使用场景有点特殊: - 在引导加载程序中,大多数引脚都配置为输入(IBE = 1)。//我们现在不想更改引导加载程序。 - 在应用中,为了使 PTE13 完全不受影响,我将其配置为 GPIO + HIGH_Z,这样就可以清除 IBE。 问题(请原谅我的啰嗦) : - 根据之前的讨论,“IBE = 1”不会影响 VRC_CTRL 功能,对吗?我可以保持 IBE = 1 吗? - 如果我将 PTE13 配置为 GPIO + HIGH_Z 以实现应用程序中完美的未触及状态,这样也可以,对吗? 谢谢! BR/熊本熊 Re: VRC_CTRL Clarification 你好@kumamon , 感谢您详细说明您的使用场景。 是的,IBE = 1 可以保持启用状态。 是的,您可以将PTE13 配置为 GPIO + HIGH_Z。 请勿在 MCAL 端口配置中选择 PG_VRC_CTRL_OUT。RTD 将此模式归类为 PORT_ONLY_OUTPUT_MODE,与所选的 PortPinDirection 无关,因此启用输出缓冲区。选择 PORT_PIN_HIGH_Z 并不会覆盖 PG_VRC_CTRL_OUT 的此行为。 顺祝商祺! 帕维尔 Re: VRC_CTRL Clarification 你好@Pavel , 感谢您高效而细致的支持。 现在我明白了,我会关闭这个工单。 BR/库马农
View full article
eFlexPWM 的初始 PWM 输出值 你好, 在使用 MCXA132 的 eFlexPWM 时,我想修改 PWM23 的初始值。 为此,我将采取以下步骤: 1. SM1CTRL2[PWM23_INIT] = 1 2. SM1CTRL2[FRCEN] = 1 SM1CTRL2[FORCE] = 1(注意 SM1CTRL2[FORCE_SEL] 为 000) 3. MCTRL[RUN] = 010 但第一个 PWM 周期总是从输出电平 0 开始。 问题出在哪里? 提前致谢 MCXA Re: Initial PWM output value with eFlexPWM 你好@zorrotz 为了帮助我们分析问题,能否请您与我们分享您的完整项目? 谢谢! BR 爱丽丝 Re: Initial PWM output value with eFlexPWM 你好, 我找到我的错误了。 参考手册中有这样一条注释: “如果未设置 MCTRL[LDOK],则设置 MCTRL[RUN] 也会设置 STS[RF] 标志。为防止 CPU 中断请求,请在设置 MCTRL[RUN] 之前清除 INTEN[RIE]。 我使用 STS[RF] 来结束 PWM 周期,但在执行 MCTRL[RUN] = 1 之前,我会清除 STS[RF]。 谢谢!
View full article
特定のフィットイメージにcsfヘッダーファイルが関連付けられていることを確認します。 セキュアブートは正常に動作しており、esbc_validateを使用してU-Bootが何をしているのかおおよそ理解しています。しかし、私は、cst 2.x で生成された特定のヘッダーファイルが、特定のフィット (カーネル、dtbs、ルートファイルシステム) イメージに関連付けられていることを検証するアップグレードユーティリティを作成しようとしています。 CSFセキュリティヘッダーを正しいオフセットに配置し、フィットイメージをオフセットに配置すれば、起動時には問題なく動作します。しかし、それらをそれぞれの場所に配置する前に、確認しておきたいのです。 公開鍵はCSFに埋め込まれているので、それを抽出しなければならないと理解しています。その後、少し混乱しています。RSA署名を抽出して、抽出した公開鍵を使ってハッシュを取得する必要があると思うのですが、そのハッシュは何らかの形でフィットイメージに関連付けられているものの、単にフィットイメージのハッシュではないのでしょうか? すでにSRKHを切れたヒューズから引き抜くことができたので比較できます。 今のところ、Google/Geminiはあまり役に立っていません。 ヒントをいただけますか? QorIQ LS1デバイス Re: Verify a csf header file is associated with a specific fit image. 署名は単にFITのハッシュではありません。このセキュアブートフローでは、CSFヘッダーのSHA-256ダイジェスト、そのヘッダーで指定されたイメージバイト、公開鍵マテリアル、および使用されている場合はSGテーブルを認証します。検証では、鍵と融合されたSRKHとの照合も行われます。 SO、どちらのファイルをインストールする前に、ユーティリティは候補ヘッダーを解析し、そのサイズとオフセットフィールドを使って候補FITから正しいバイトを選択し、署名済みデータのダイジェストを計算し、抽出したRSA署名を検証済み公開鍵で検証しなければなりません。検証が成功すると、そのヘッダーは認証済みのFITバイトに関連付けられます。FITのみのSHA-256比較では機能しません。
View full article
URLとバックリンクのための最高のインスタントインデックスツール、インスタントインデクサー2026 https://www.indexingurl.comを試してみてください あるいはお問い合わせ T g srma25 Whats app +8801602923484         評価ボード
View full article
TJA1410_10Base_T1s Hi,NXP I am testing 10BASE-T1S using the S32K5 and TJA1410. Currently, I can see waveforms on the TX pin, and there are also waveforms on the RX and ED pins, which indicates that signals can be received on the MDI. However, the TX pin is unable to send data to the MDI. TX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmpTX_RX_ED-2026-09-10-19-26-50.bmp Best Reagrds. xianlong Ethernet PHY Re: TJA1410_10Base_T1s Hello @wuxianlong , How have you measured the MDI? MDI is differential interface so you need to use differential oscilloscope probe. MDI requires proper differential termination - please refer to AN14787 - Application note 10BASE-T1S Ethernet PMD transceiver TJA1410, Rev. 1.0 , chapter 3.3. Best regards, Pavel Re: TJA1410_10Base_T1s Hello @wuxianlong , I hope this email finds you well. I am writing to you in regard to a product currently in your possession – an NPI (New Product Introduction) - S32K5 - which has not been officially launched yet. Please be advised that customers who have been granted early access to such products have assigned their field engineers. Your designated field engineer should serve as your primary support channel for any issues, concerns or queries you may have about this product. Our online support team will be opening a wider range of support for this product once it has been officially released. Until then, we will not be equipped to provide the desired assistance. We appreciate your understanding in this matter. Thank you for your understanding. Best regards, Pavel Re: TJA1410_10Base_T1s Hi,@PavelL  I did not use a differential probe. When I transmit (TX), the MDI shows no fluctuation on the oscilloscope — it remains flat/horizontal. However, when the PC sends data, the MDI clearly shows a differential waveform. It feels like the TJA1410 is not being correctly switched into transmit mode and the chip remains in normal mode. Are there any methods to verify the PHY's current mode? Currently, our TJA1410 is not connected to an SMI interface — what precautions should we take regarding this? Best Regards, xianlong Re: TJA1410_10Base_T1s Hello @wuxianlong , Since S32K5 is an NPI device, please note that we are currently unable to validate the complete S32K5 and TJA1410 setup on our side.   The TJA1410 operating mode is not selected through the SMI interface. The transitions between Normal and Transmitting modes are controlled by commands received on the TX pin. Therefore, observing data activity on TX does not necessarily confirm that the TJA1410 has entered Transmitting mode. The preceding TRANSMIT command and its timing must also comply with the timing specified in the TJA1410 data sheet.   Please verify the transition from Normal to Transmitting mode according to Figure 10 in the TJA1410 data sheet. In particular, please capture the TX command together with the differential VLINE signal and ED output. This should confirm whether the TJA1410 recognizes the TRANSMIT command and activates its MDI transmitter.   Best regards, Pavel 回复: TJA1410_10Base_T1s As can be seen from the waveform in the manual, RX ignores the first transition starting with high impedance (or 0), resulting in RX missing a transition and RZI decoding error. I'd like to ask about NXP TJA1410. In this case, are there any recommended decoding methods? 回复: TJA1410_10Base_T1s Hello @li_wang , Please note: Once an answer is marked as a solution, the original query is no longer actively tracked in our system. I only receive subscription emails for updates and those can occasionally be missed. If you need further assistance, the best approach is to create a new query. Best regards, Pavel
View full article