Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
外部ウォッチドッグを使用したPMICの動作(Wdg_43_VR5510) PMIC用に外部ウォッチドッグ(Wdg_43_VR5510)を実装しました。しかし、Pmic_VR5XX_TimeoutLoops_StateTransistion で無限ループに陥っています(下記参照)。 SagarZala_1-1728467272425.png 現在、状態はINIT_FS状態です。状態図によると、状態をINIT_FSからWait_ABIST2に変更するには、適切なウォッチドッグ更新が必要です。 image (7).png 最初のウォッチドッグ更新が256ms以内に正常に行われるようにするため、EcuM初期化中にWdg_43_VR5510_Init関数の後にウォッチドッグトリガーAPIを呼び出しました。 image (8).png 最初の監視機関の刷新をどのように、どこで行うべきかを知る必要がある。つまり、状態遷移はINIT_FSからwait_ABIST2へと起こるということです。 Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) こんにちは、 @Jerry_cao さん。 お問い合わせいただきありがとうございます。しかし、元の投稿はほぼ2年間閉鎖されているため、そのThreadでの支援を継続することはできません。 S32G - NXPコミュニティであなたの問題について新しい投稿を作成してください。私たちのチームは喜んでさらにサポートいたします。 BR セレステ Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) NXPチームの皆様、こんにちは。 現在VR5510 PMICのデバッグを行っているのですが、ウォッチドッグの更新に関連するリアルタイムスケジューリングの問題に遭遇しました。 MCAL I2C ウォッチドッグのリフレッシュ (I2C を介して VR5510 ウォッチドッグにフィードする) は、 同期 手術。同期待機は割り込みコンテキスト内から呼び出されるため、CPUをブロックし、他のタスクのリアルタイムスケジューリングを低下させます。 ドライバーの設定やコードに 非同期 オプションがあるのに気づきました。しかし実際には同期のビジー待機(I2C転送が完了するまでブロックとポーリングを行う)を実行しているため、実際には転送を呼び出し元から切り離すことはありません。 私の質問: VR5510のウォッチドッグリフレッシュを公式にサポートされた方法で実行することは可能ですか? 真のノンブロッキング (例えば割り込み駆動かDMA駆動のI2C)で、他のタスクを停止させないために? 非同期オプションがノンブロッキングであることが想定されている場合、現在の同期ビジーウェイト動作は既知の制限事項でしょうか、それとも私の側の設定の問題でしょうか? 何かご助言、設定例、またはサンプルコードをご提供いただければ大変ありがたいです。 よろしくお願いします。 Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) こんにちは、SagarZalaさん、 S32 Design Studio(S32DS)の標準化された2つの例を試したことはありますか?彼らも同じ問題を抱えるのだろうか?彼らはあなたにとって非常に良い参考資料となるかもしれません。 Celeste_Liu_0-1729049570948.png Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) こんにちは、 ご返信ありがとうございます。 私はRTDバージョン4.0.2を使用しています。I2Cは既に高速に設定済みで、 WD_WINDOWも1024msに設定されています。しかし、それでもうまくいきません。 Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) 親愛なる@SagarZala様、 ご質問ありがとうございます。VR5510は一般的にS32Gマイクロプロセッサ と組み合わせられます。そのため、VR5510の利用可能なドライバはS32G RTDパッケージ内で提供されるべきです。使用しているRTDのバージョンと、具体的な例を教えてください。 RTD 4.0.0バージョンを例にすると、パスC:\NXP\SW32G_RTD_4.4_4.0.0\eclipse\plugins\Wdg_43_VR5510_TS_T40D11M40I0R0\docの下に「RTD_WDG_43_VR5510_IM」と「RTD_WDG_43_VR5510_UM」のドキュメントがあります。文書「RTD_WDG_43_VR5510_UM」に詳細が記載されています。 ウォッチドッグタイマーはI2Cコマンドによって起動され、I2Cの速度に依存することに留意すべきである。I2Cの速度が低い場合、ウォッチドッグタイマーが作動ウィンドウのオープン時間内に正常にトリガーされない可能性があります。この問題を避けるために、ユーザーはI2cを高速で設定し、有効な期間は長いウィンドウを使うことを推奨します。 ウォッチドッグのリフレッシュを設定するには、WD_WINDOW[3:0]を設定してリフレッシュ時間を取得します。次の図に示すように: Celeste_Liu_0-1728636341767.png 「Document VR5510 製品 data sheet」(表45ページ、60ページ)を参照してください。ウォッチドッグウィンドウの期間設定は、以下のスクリーンショットに示すとおりです。WD(廃液排出)期間を正しく設定した後、WDに正しく給紙する必要があります。 Celeste_Liu_4-1728636786838.png Celeste_Liu_5-1728636805408.png 上記の情報がお役に立てば幸いです。 よろしくお願いいたします。 セレステ
記事全体を表示
S32DS 3.6.7 RTD 7.0.1 P02 HSEコード生成エラー S32DS 3.6.7を使用してS32K358のHSE 関連の RTD コードを生成しようとしています。しかし、問題が発生しました。 まず、以下の更新サイトを下記の順序でインストールしました。 SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip インストール状況は下の画像に示されています。 wodudwo_1-1784020530765.png wodudwo_0-1784020518071.png 次に、下記のSDKを選択して新しいプロジェクトを作成しました。 wodudwo_2-1784020561794.png 次に、以下に示すように、Config ToolsにBaseNXPとHseのコンポーネントを追加しました。 wodudwo_3-1784020582815.png しかし、以下の検証エラーが発生します。 Issue: Hse is not found in the toolchain/IDE project. The project will not compile! Level: Error Type: Validation Tool: Toolchain/IDE project Origin: Peripherals Target: Toolchain/IDE project: M7_0_0 Resource: platform.driver.Hse この問題をどう解決し、HSE関連のRTDコードを正常に生成すればよいでしょうか? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error こんにちは、 以下のパッケージをインストールしてコードを生成しようとしましたが、同じ検証エラーが出ます。 wodudwo_1-1784074948979.png wodudwo_2-1784074960671.png wodudwo_3-1784074969264.png wodudwo_0-1784074933867.png ご提案の通り、まずRTD関連の拡張機能をすべてアンインストールし、その後、以下のパッケージのみをインストールしました。 - SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip インストール状況は以下のとおりです。 wodudwo_4-1784075002029.png wodudwo_5-1784075010124.png しかし、これを実行した後は、下の画像のように新しいプロジェクトを作成する際にSDKを選択できなくなりました。 wodudwo_6-1784075045680.png この問題を解決するにはどうすれば良いですか? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error こんにちは、 @wodudwo さん。 ソフトウェアパッケージの欠落がないことを確認するために、IDEにインストールされているパッケージと以下の画像に示されているものを比較していただけますか? VaneB_0-1784059529950.png さらに、S32K3 RTDに関連するすべてのパッケージをアンインストールし、名前に「P02」が含まれているパッケージだけを再インストールしてみましょう。 BR、VaneB Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error こんにちは、 @wodudwo さん。 インストール手順の1つが抜けている可能性があります。以下は、私がパッケージをうまくインストールするために使っている手順です: すでにいくつかのパッケージをインストールしているので、まずはS32K3デバイス向けのRTDに関連するすべてのパッケージをアンインストールすることをお勧めします。S32K3およびS32Mデバイス向けのS32 Configuration Tools R1.8 NPIデータパッケージも含めて、これらはRTDパッケージに依存しているためです。 - 以下の更新サイトを追加してください。 SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite_updated_D20260630.zip - 名前にP02を含むパッケージのみを選択しインストールする。インストールに必要な追加の依存パッケージを自動的に選択・インストールできるようにします。 インストールが正常に完了するまで待ち、S32DSを再起動してください。 - 再起動後、S32K3およびS32Mデバイスコンポーネント用のすべてのS32構成ツールR1.8 NPIデータパッケージを選択してインストールします。ここでも、S32DSが必要な依存関係を自動的に選択するように設定してください。 インストールが正常に完了するまで待ち、S32DSを再度再起動してください。 これらの手順を踏んだ結果、IDEsに6つのRTD 7.0.1パッケージ(P02を含む)がインストールされました。このセットアップで、HSEドライバをプロジェクトに問題なく追加できます。 VaneB_0-1784154210318.png
記事全体を表示
PWM捕获功能在frdm_mcxw72板上无法工作 你好, 我尝试在frdm_mcxw72板上练习pwm捕获示例,但不幸的是,串口工具中的打印消息只显示“捕获周期错误-134 ”。我确信有 1Khz、50% 占空比的 PWM 信号注入到 frdm_mcxw72 板的 PTA21 引脚中。 我从演示案例中导入了整个项目文件,没有任何改动,只是添加了覆盖文件,以下是覆盖文件设置。 anliu114036_0-1783501416708.png 请帮忙查一下为什么打印信息不正确。提前致谢! Re: PWM Capture can't work in frdm_mcxw72 board 你好, 希望你一切都好。请问您使用的是哪个 Zephyr 仓库? 另外,你是从哪些例子入手的?你修改过什么吗? 顺祝商祺! 里卡多 Re: PWM Capture can't work in frdm_mcxw72 board 你好, 请问您使用的是哪个代码仓库? 您使用的是上游还是下游? 另外,这个示例在您那边无需修改就能正常运行吗? 顺祝商祺! 里卡多 Re: PWM Capture can't work in frdm_mcxw72 board 嗨,里卡多, 仓库版本为V4.4.1.0,以下是我的步骤 1. 从仓库导入捕获示例应用程序 anliu114036_0-1783644698775.png 2. 将 DTS overlay 文件添加到板文件夹中,overlay 文件的内容已在第一条消息中发布。 3. 将固件编译并烧录到我手中的frdm_mcxw72开发板上,打印信息为: “捕获周期错误”,看起来板状态正常,因为我没有注入 PWM 信号,但是将 PWM 信号注入 PTA21 引脚后,打印消息仍然相同。     Re: PWM Capture can't work in frdm_mcxw72 board 嗨,里卡多 这是仓库版本 anliu114036_0-1783902527295.png 我只更新了覆盖文件,如果没有这个文件,就无法成功版本。 顺祝商祺! Re: PWM Capture can't work in frdm_mcxw72 board 你好, 请问您使用的是上游系统还是下游系统? 顺祝商祺! 里卡多 Re: PWM Capture can't work in frdm_mcxw72 board 嗨,里卡多, 抱歉,我不太明白这里的“上游”和“下游”是什么意思。我猜应该是下游。或者您能否修改其他描述?
記事全体を表示
S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach Hello NXP Team, Background: MCU: S32K311 AUTOSAR RTD MCAL: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 HSE FW (Full Memory): s32k3x1_hse_fw_0.12.0_2.55.0_pb250225.bin Full Investigation Report attached in PDF Main Issue The software crashes and the MCU resets in Clock_Ip_DistributePll(). In addition, the debugger is sometimes unable to attach. When I tried to hot-attach the debugger, the reset reason was sometimes reported as HSE_CLK_FAIL. Can you check mainly the above procedure, IVT and DCF records and additionally information why this issue is occurring and its solution, Please let us know if any additionally information is needed. Could you please check the HSE installation procedure, IVT configuration, and DCF records, and advise why this issue is occurring and how it can be resolved? Please let us know if any additional information is required. Best regards, Shubham Pardeshi Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach Hello @davidtosenovjan  Our software consists of FBL and APPL, and both use the same Functional reset mechanism. When APPL initiates the reset, the issue is not observed. When FBL initiates the reset, the software crashes during APPL startup inside Clock_Ip_DistributePll(). Initially, we added a check for HSE_STATUS_INIT_OK after Mcu_InitClock() and before Mcu_DistributePllClock(). This prevented the crash. However, it took approximately 20 seconds for HSE_STATUS_INIT_OK to be set, after which the actual APPL startup continued. Today, we moved the HSE_STATUS_INIT_OK check to an earlier stage, before Mcu_Init() in APPL, as shown in the attached screenshot. Shubham_MQ_0-1784123821324.png With this sequence, HSE_STATUS_INIT_OK is set almost immediately, and the crash is no longer observed. Could you please clarify the following? Why does this issue occur only when the reset is initiated by FBL, even though FBL and APPL use the same reset mechanism? Why does HSE_STATUS_INIT_OK take approximately 20 seconds when checked after Mcu_InitClock(), but become available almost immediately when checked before Mcu_Init()? Why is the HSE_STATUS_INIT_OK check not required in FBL, but appears to be required during APPL startup? Please provide a clear root-cause explanation and the recommended initialization sequence. We need to ensure that the current solution is robust and will not cause any issues in production. Please let us know if any additional details or clock configuration details are required. Best regards, Shubham Pardeshi Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach Mentioned 70 and 20 seconds are times from reset to HSE_STATUS_INIT_OK. So basically only boot time is included, correct? Does it behave the same way on every device?
記事全体を表示
使用外部看门狗的 PMIC 行为 (Wdg_43_VR5510) 我已经为 PMIC 实现了外部看门狗(Wdg_43_VR5510)。但它在 Pmic_VR5XX_TimeoutLoops_StateTransistion 中陷入了无限循环(见下文)。 SagarZala_1-1728467272425.png 目前它处于 INIT_FS 状态,根据状态图,我们需要进行一次良好的看门狗刷新,才能将状态从 INIT_FS 更改为 Wait_ABIST2。 image (7).png 为了满足 256ms 内首次有效看门狗刷新的要求,我们在 EcuM 初始化期间的 Wdg_43_VR5510_Init 函数之后调用了看门狗触发 API。 image (8).png 我们需要知道如何以及在哪里调用第一个监控程序刷新。因此,状态转换从 INIT_FS 到 wait_ABIST2。 Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) 你好@Jerry_cao , 感谢您与我们联系。然而,原帖已关闭近两年,因此我们无法继续在该帖下为您提供支持。 请在S32G - NXP 社区中为您的问题创建一个新帖子,我们的团队将很乐意为您提供进一步的帮助。 BR 塞莱斯特 Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) 您好,NXP团队, 我目前正在调试 VR5510 PMIC,遇到了与看门狗刷新相关的实时调度问题。 MCAL I2C 看门狗刷新(通过 I2C 向 VR5510 看门狗提供数据)的实现方式如下: 同步 手术。由于我们是在中断上下文中调用它,因此同步等待会阻塞 CPU,并降低其他任务的实时调度性能。 我注意到有一个 异步 驱动程序配置/代码中的选项。然而,实际上它仍然执行同步忙等待(它会阻塞并轮询,直到 I2C 传输完成),因此它实际上并没有将传输与调用者解耦。 我的问题: 是否有官方支持的方法可以刷新 VR5510 看门狗? 真正无阻塞 (例如是否采用中断驱动或DMA驱动的I2C协议,以避免阻塞其他任务? 如果异步选项预期是非阻塞的,那么当前的同步忙等待行为是已知的限制还是我的配置问题? 任何指导、参考配置或示例代码都将不胜感激。 谢谢! Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) 你好 SagarZala, 我想知道您是否尝试过 S32 设计工作室 (S32DS) 中的两个现成示例?他们会遇到同样的问题吗?或许他们能成为你很好的推荐人。 Celeste_Liu_0-1729049570948.png Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) 您好, 谢谢回复。 我使用的是 RTD 版本 4.0.2。我已经将 I 2C 配置为高速,并且WD_WINDOW 也配置为 1024ms。但它仍然不起作用。 Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) 亲爱的@SagarZala , 谢谢你的提问。VR5510 通常与 S32G 微处理器搭配使用。为此,应在 S32G RTD 软件包下提供 VR5510 的可用驱动程序。您使用的是哪个版本的RTD?具体是哪个示例? 以 RTD 4.0.0 版本为例,您可以在路径 C:\NXP\SW32G_RTD_4.4_4.0.0\eclipse\plugins\Wdg_43_VR5510_TS_T40D11M40I0R0\doc 下找到文档“RTD_WDG_43_VR5510_IM”和“RTD_WDG_43_VR5510_UM”。文件“RTD_WDG_43_VR5510_UM”中有更详细的描述。 值得一提的是,看门狗是通过 I2c 命令触发的,并且取决于 I2c 速度。当 I2c 速度较低时,看门狗可能无法在看门狗的窗口打开时间内成功触发。为避免此问题,我们建议用户将 I2c 配置为高速,并在启用 I2c 时使用较大的窗口周期。 要设置看门狗刷新,您可以配置 WD_WINDOW [3:0] 来获取刷新时间。如下图所示: Celeste_Liu_0-1728636341767.png 请参阅“ Document VR5510 产品数据手册”第 60 页表 45。监视窗口周期配置,如下截图所示。设置好正确的 WD 周期时间后,需要正确地给 WD 供料。 Celeste_Liu_4-1728636786838.png Celeste_Liu_5-1728636805408.png 希望以上信息对您有所帮助。 顺祝商祺! 塞莱斯特
記事全体を表示
关于8M+实时精度 您好,我们想更多地了解 8M Plus 在实时应用方面的功能。是否有关于TSN、实时性能或抖动方面的测试报告或相关资料? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy 面积 可用材料 它包含什么 实时 CPU/RTOS 延迟 鱼叉用户指南 测量实时延迟 i.MX 8M Plus / Zephyr 包括 IRQ 延迟和任务延迟(单位:纳秒)。示例结果:空载 IRQ 延迟最小值/平均值/最大值/标准差 = 625 / 796 / 11,125 / 1,798 ns 任务延迟 = 2,583 / 2,671 / 13,041 / 6,045 ns 。在 Linux 系统下,CPU + 内存负载,IRQ 延迟 = 625 / 798 / 4,250 / 4,674 ns ,任务延迟 = 2,583 / 2,670 / 14,333 / 10,407 ns 。 实时基准测试方法 Harpoon 用户指南 — 实时延迟应用程序 将基准定义为硬件 IRQ 事件与软件操作之间的时间差,使用硬件计时器以亚微秒精度进行测量。 TSN 能力 i.MX 8M Plus 产品/参考资料 i.MX 8M Plus 包含双千兆以太网接口,其中一个以太网接口支持 TSN,并使用集成式 800 MHz Arm Cortex-M7 用于工业实时控制。 TSN硬件标准 i.MX 8M Plus 参考手册 TSN支持包括 IEEE 802.1Qbv 时间感知整形器 , 802.1Qav 基于信用的整形者 , IEEE 1588v2 PTP 以太网模块实现了 802.1Qbv-2015 , 802.3br , 和 802.1Qbu 与帧抢占相关的TSN功能。 TSN 测试/验证环境 实时边缘计算用户指南 描述了用于评估 i.MX 8M Plus TSN 功能的 TSN 测试环境,包括流量生成/分析以及对延迟、抖动和同步精度的监控。 TSN抖动/延迟示例 实时边缘用户指南 — TSN 端点示例应用程序 提供 TSN 端点统计信息,包括流量延迟最小值/平均值/最大值和备注 延迟约为 503 微秒 和 延迟抖动约为 300 纳秒 在所示示例中。 TSN 应用演示 AN13588 演示 GenAVB/TSN 实时控制应用。它描述了一个 2毫秒周期 ,一个 400 微秒预留/保证的控制流量窗口 以及一个用于调度、处理时间、流量正确性和延迟的统计线程。 TSN 802.1Qbv 演示 AN13995 演示了使用 i.MX 8M Plus 的 TSN 802.1Qbv,并解释了时间感知整形技术如何利用固定的重复周期来提供确定性的延迟;它还包含 Linux 版本。  tc  /  taprio  配置示例。   Re: Regarding 8M Plus Real time Accuracy @yipingwang 感谢您提供信息。请问您能否也向我们提供有关 iMX8M Plus EVK 的信息? 谢谢。 Re: Regarding 8M Plus Real time Accuracy 我们了解到,i.MX95 EVK 尚未正式发布任何公开的“实时性能报告”。但是,NXP 内部确实对 i.MX95 平台进行了实时基准测试。内部基准测试文档表明,已在运行实时边缘软件和 PREEMPT_RT Linux 的 i.MX95 LPDDR5 EVK 上执行了 cyclictest 和 EtherCAT 性能评估。报告的例子包括:在 6 小时的压力测试期间,循环测试的最大延迟约为 38 µs;在记录的测试条件下,EtherCAT 滤波后的最大抖动约为 12 µs。由于实时性能很大程度上取决于 BSP 版本、内核配置、CPU 隔离、工作负载和网络流量,因此这些值应被视为参考测量值,而不是保证的应用级限制。   请参阅https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf 作为支持的基准测试平台,并提供详细的循环测试、压力测试和 rt_latency 测试程序。 Re: Regarding 8M Plus Real time Accuracy 我们的代理商告知我们,目前还没有关于 NXP i.MX95 EVK 实时性能或抖动的官方性能报告。 但是,他们还提供了描述评估实时延迟的测试方法(例如,循环测试)的文档。 这导致我们这边有些困惑。由于存在标准化的测试方法,我们假设此类测试一定已在内部执行过——至少在参考 EVK 平台上执行过。 因此,我们想澄清如下: NXP 是否对 i.MX95 EVK 进行过任何实时性能(例如延迟、抖动)的内部测量? 如果可以,是否有任何参考结果或基准结果可以分享? 我们了解到,实时性能可能会因系统配置和工作负载而异。然而,即使是受控条件下的基准结果(例如,默认 BSP,最小负载)对于初步评估也非常有帮助。 感谢您的支持。 hankwang_0-1784018178178.png Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (实时边缘软件用户指南)( https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf ) 实时边缘软件(最相关) 恩智浦半导体的实时边缘软件正式支持 i.MX8M Plus EVK,并包含以下内容: PREEMPT_RT Linux TSN 协议栈 IEEE 802.1AS (gPTP) 同步 TSN流量整形和调度 EtherCAT、OPC-UA、CAN 相关工业协议 使用 Cortex-A53 + Cortex-M7 的异构实时操作 内部文件REALTIMEEDGEUG指出,实时边缘软件提供: 实时网络(TSN) 实时 Linux (PREEMPT_RT) 纯RTOS/裸机选项 监狱隔断 工业协议支持 支持 i.MX 8M Plus LPDDR4 EVK NXP 应用笔记AN13995 – 使用 i.MX 8M Plus 进行 TSN 802.1Qbv 演示 实时优势产品概览材料中描述了 PREEMPT_RT + TSN 支持 Re: Regarding 8M Plus Real time Accuracy @yipingwang非常感谢您提供的信息。
記事全体を表示
S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error I am trying to generate the HSE-related RTD code for S32K358 using S32DS 3.6.7, but I have encountered an issue. First, I installed the following Update Sites in the order shown below: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip The installation status is shown in the image below. wodudwo_1-1784020530765.png wodudwo_0-1784020518071.png Next, I created a new project by selecting the SDK shown below. wodudwo_2-1784020561794.png Then, I added the BaseNXP and Hse components in Config Tools as shown below. wodudwo_3-1784020582815.png However, the following validation error occurs: Issue: Hse is not found in the toolchain/IDE project. The project will not compile! Level: Error Type: Validation Tool: Toolchain/IDE project Origin: Peripherals Target: Toolchain/IDE project: M7_0_0 Resource: platform.driver.Hse How can I resolve this issue and successfully generate the HSE-related RTD code? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error Hello, I tried generating the code with the following package installed, but I still encounter the same validation error. wodudwo_1-1784074948979.png wodudwo_2-1784074960671.png wodudwo_3-1784074969264.png wodudwo_0-1784074933867.png As you suggested, I first uninstalled all RTD-related extensions and then installed only the following package: - SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip The installation status is shown below. wodudwo_4-1784075002029.png wodudwo_5-1784075010124.png However, after doing this, I can no longer select any SDK when creating a new project, as shown in the image below. wodudwo_6-1784075045680.png What should I do to resolve this issue? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error Hi @wodudwo  To verify that there are no missing software packages, could you please compare the packages installed in your IDE with those shown in the following image? VaneB_0-1784059529950.png Additionally, let's try uninstalling all packages related to S32K3 RTD and then reinstall only the packages that contain "P02" in their name. BR, VaneB Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error Hi @wodudwo  I believe one of the installation steps may be missing. Below is the procedure I use to install the packages successfully: Since you have already installed some packages, I recommend first uninstalling all packages related to RTD for S32K3 devices, including the S32 Configuration Tools R1.8 NPI Data Package for S32K3 and S32M devices, as these have dependencies on the RTD packages. - Add the following update sites: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite_updated_D20260630.zip - Select and install only the packages that contain P02 in their name. Allow S32DS to automatically select and install any additional dependent packages required for the installation. - Wait for the installation to complete successfully and allow S32DS to restart. - After the restart, select and install all S32 Configuration Tools R1.8 NPI Data Package for S32K3 and S32M devices components. Again, allow S32DS to automatically select any required dependencies. - Wait for the installation to complete successfully and allow S32DS to restart once more. After following these steps, I end up with six RTD 7.0.1 packages (including P02) installed in my IDE. With this setup, I am able to add the HSE drivers to my projects without any issues. VaneB_0-1784154210318.png
記事全体を表示
RT1064 400kHzでのI2C通信異常 RT1064デバイスのI2C2インターフェースはモジュールAに接続されます。通信異常は400kHzで発生しますが、100kHzでは正常に動作します 1. 同じシリーズ内の異なるモデルのモジュールBを400kHzで接続することは問題ありません 2. 波形の観点からは、ホストクロックが伸縮され、モジュールAに接続された後に復元される異常に相当します 追伸:デバイスのI2Cドライバーポートを別の1064デバイスに実装し、モジュールAをテストしましたが、400kで問題ありません その理由は何でしょうか? 1. 図1 モジュールA ロジックアナライザの400kHzにおける異常波形 foreverwlh2025_0-1782181859478.png 2. 図2:モジュールAの100kHzにおけるロジックアナライザの波形 foreverwlh2025_1-1782181977222.png 3. 図3:モジュールBの400kHzにおける波形 foreverwlh2025_2-1782182029028.png i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 追加のご説明ありがとうございます。これは非常に重要な指摘です。   あなたの観察からすると、問題はモジュールA自体の異常というよりも、2段ADUM1251アイソレーションリンクによる400 kHz I2Cのタイミングマージン不足に関連している可能性が高いようです。 ライズ時間が規格内であっても、RT1064ではLPI2Cマスター側の400kHz構成、特にMCFGR2[FILTSCL/FILTSDA]およびMCCR0/MCCR1の確認を推奨します。なぜなら、RT1064のマスター同期レイテンシはライズ時間だけでなく、デジタルフィルターやタイミングパラメータ設定にも影響を受けるからです。 プロジェクトで実際に使用されている構成を読み、RT1064リファレンスマニュアル第47章の表47-5「LPI2C例タイミング構成」と比較することをお勧めします。 特に、選択したクロック条件における以下の設定が、サンプル値と一致しているかどうかを確認してください。 I2Cモジュールクロックソース 目標ボーレート:400Kbps PRESCALE FILTSCL / FILTSDA セソルド クロックロ CLKHI データビデオ お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 追加情報として、昨日ポジショニングにいくつかの進展がありました: ハードウェア拡張は以下の通りです: マザーボード:RT1064--- ADUM1251 3.3V~5V サブボード:ADUM1251 - モジュールA 5V~3.3V 検証の結果、ハードウェアリンクの2層にADUM1251を追加した後、モジュールAで通信異常が発生したことが判明した。しかし、ADUM1251を取り外すと、400kで通信が正常に戻った。その理由は何でしょうか? 追伸:ハードウェアエンジニアは、ADUM1251は通信レイテンシを増加させるだけで、それ以外には影響がないと考えています Re: RT1064 I2C communication abnormality at 400kHz こんにちは、@mayliu1 当社の製品はまもなくリリースされ、数日間この問題を調査してきました。できるだけ早くご返信いただければ、大変ありがたいです! Re: RT1064 I2C communication abnormality at 400kHz ハイ 補足情報 1.2人のハードウェアエンジニアはオシロスコープで問題の波形を確認し、上昇時間は100+ns以内の要件を満たしました 2. I2Cの初期化および読み書き機能ドライバを別のタイプのRT1064デバイスに移植し、モジュールAを問題なくテストしました 以下の図は、別のデバイスモジュールAの波形を示しています。テスト用ロジックアナライザー foreverwlh2025_0-1782194338022.png 疑い: 1.ストレッチ後に時計が異常に回復するなら、他にどんな理由が考えられますか 2. 前回の返信で言及されたMCFGR2のような設定設定専用機能はありますか?I2C初期化プロセスで設定するインターフェースは見当たりませんでした ----上昇時間が満たされた場合、これらのレジスタ設定を考慮する必要はないのでしょうか? Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 これはモジュールAの問題ではなく、その特定のRT1064 LPI2C2バスの400 kHzのタイミングマージンの問題だと思います。 RT1064では、LPI2Cのタイミングはバスの上昇時間、バス負荷、プルアップ抵抗、グリッチフィルタ レイテンシの影響を受けます。 リファレンス・マニュアルRT1064RMでは、上昇時間が長いと同期レイテンシが増加すると説明されています。(第47.3.1.4章を参照)タイミングパラメータ) マスターグリッチフィルターMCFGR2[FILTSCL/FILTSDA]は、**レイテンシ**がSCLの最低ロー/ハイ期間を下回るように設定されなければならず、RT1064はMCCR0/MCCR1の400 kbpsタイミング設定の例を提供しています。表47-5をご確認ください。LPI2Cのタイミング構成例 mayliu1_0-1782186916949.png したがって、モジュールAがバスエッジをわずかに遅くしたり、実効負荷を変えたりすると、バスは400kHzで故障しても100kHzでは動作し続けることがあります。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 10 MHzのLPI2C機能クロックは、RT1064リファレンスマニュアルの400 kbpsのタイミング設定例には記載されていません。 このクロックを使用すれば400kbpsのボーレートを生成することは可能ですが、自動生成されるタイミングパラメータは、特にtLOW、tHIGH、セットアップ/ホールドタイミング、およびデータ有効タイミングに関して、I2C仕様と照らし合わせて慎重に検証する必要があります。 デザインリスクを減らすために、リファレンス・マニュアルに示されている48 MHzなどの検証済みクロックソースを使用することが推奨されています。 Re: RT1064 I2C communication abnormality at 400kHz 以下は印刷設定です。どのパラメータを調整する必要があるでしょうか? 追伸:どうやら自動インターフェース割り当てによるようです foreverwlh2025_0-1782704741259.png Re: RT1064 I2C communication abnormality at 400kHz 60MHzと8MHzの両方を変更してみましたが、それでもうまくいきませんでした。下図の赤い枠で囲まれた部分は、修正後に印刷された値を示しており、マニュアルに記載されている値とは異なっています。 foreverwlh2025_0-1782813239395.png Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 I2Cクロックを設定する方法はいくつかあります。 提案として、8 MHzと60 MHzを試してみるのも良いでしょう。この2つのクロック設定は比較的簡単に達成できます。 SDKのデモを使っています: 「evkmimxrt1064_lpi2c_edma_b2b_transfer_master」 方法1:LPI2Cクロックソースを60MHzに設定する 時計の分周器を0に設定するだけです。 mayliu1_3-1782806044116.png 方法2:LPI2Cクロックソースを8MHzに設定する MCUXpresso IDEsクロックツールを使い、以下の通りに設定してください。クロックソースとしてOSC_CLKを選択し、分周器を3に設定すると、LPI2C(I2C)モジュール用の8MHzクロックが生成されます。 mayliu1_0-1782804733641.png mayliu1_4-1782806209573.png お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 現在のI2Cクロックは、SDK2_13_0-EVK-MIMXRT1064 \ ボード \ evkmimxrt1064 \ river_deamples \ lpi2cディレクトリ内のサンプル構成に基づいて構成されています。 #define LPI2C_CLOCK_SELECT(0U) #define LPI2C_CLOCK_DIVIDER(5U) CLOCK_SetMux(kCLOCK_Lpi2cMux、LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv、LPI2C_CLOCK_DIVIDER); ---正確な8MHzか48MHzをどうやって修正すればいいですか?(時計の木が見えないようですね) Re: RT1064 I2C communication abnormality at 400kHz こんにちは、 @foreverwlh2025 さん。 レジスタを直接設定してみるのも良いでしょう。 例えば、60 MHzのI2Cクロックを使用する場合、以下の構成を適用できます。 mayliu1_1-1782813580334.png お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: RT1064 I2C communication abnormality at 400kHz 図に示すように、パラメータに対応するようにレジスタ設定を変更しようとしましたが、60MHzでは改善がありませんでした。良いモジュールでも8MHzでは正常に動作しません foreverwlh2025_0-1782882582056.png Re: RT1064 I2C communication abnormality at 400kHz 原因が特定され、問題のあるモジュールではクロックの伸縮が400kHzで発生することになります。 しかし、私たちが使っているアイソレータチップはSCLの双方向に対応していません。アイソレーターチップを交換した後、 検査結果は正常だった。この注文は閉じていけます
記事全体を表示
board.h missing extern C guard This is a bug report. I am using SDK_2.16.000 for the MCXA153. When I use the "Create a new C/C++ project" wizard in MCUXpresso and create a new C++ project, the generated code fails to build because of  undefined reference to `BOARD_InitDebugConsole()' This is because board.h is missing the extern C guard, which can be fixed as follows: #ifdef __cplusplus extern "C" { #endif void BOARD_InitDebugConsole(void); #ifdef __cplusplus } #endif Development Board MCXA Re: board.h missing extern C guard More that a year after you've made a promise, the bug is still there when creating a C++ project in a fresh installation (december, 2025): undefined reference to `BOARD_InitDebugConsole()' Does anyone at NXP is taking care of its customers? Re: board.h missing extern C guard Dear @aberger , Based on your feedback, we have reproduced the issue and have indeed identified the corresponding problem. Thank you for your contribution to the NXP Community with your answer! We have submitted the bug to the relevant team and hope to update the corresponding patch as soon as possible. Best Regard Liu Re: board.h missing extern C guard Hello @fjrg76  Thank you for reporting this issue. I sincerely apologize for my delayed response. In our internal system, once a case has been closed for more than one month, we no longer receive reminders or notifications when new updates are added to the case. I sincerely apologize for any inconvenience this may have caused. Regarding this issue, I will confirm it with our SDK team and get back to you as soon as possible. As a kind reminder, if you have any further questions or concerns in the future, please create a new support ticket. This will allow us to see your request promptly and provide a timely response. Alternatively, you may contact me directly, and I will get back to you as soon as I see your message. Thank you for your understanding and patience. BR Alice
記事全体を表示
PNEV5180B 2.0 PN5180 Altium 原理图 PNEV5180B 2.0 PN5180 原理图是否有 ALtium 格式? 此外,PCB板也很有用,主要用于NFC天线。 我们想使用PN5180,并希望尽快投入使用。 Re: PNEV5180B 2.0 PN5180 Altium Schematics 你好@David-Lightbug 希望你一切都好。 非常抱歉,PN5180 设计文件暂不可用。或许您可以参考PN5180 评估板快速入门指南,其中包含一些显示相关原理图的图片。另外,请参考PN5180天线设计。 如果可能的话,我建议考虑使用PN5190 | NFC 前端进行支付。以下是与PNEV5190BP相关的设计文件: -模块板 底板 问候, 爱德华多。 Re: PNEV5180B 2.0 PN5180 Altium Schematics 您好, 浏览 Altium 原理图,它们似乎都是 BGA 封装/ 你有 PNEV5190M(BGA 封装电路图)和 PNEV5190BP,也是 BGA。 我找到了评估板手册 PNEV5180B,其中显示了 QFN 封装,但没有显示 Altium 文件。 你能帮忙吗? Re: PNEV5180B 2.0 PN5180 Altium Schematics 您好, 感谢您的快速回复。 我将改用PN5190。 该代码是否与 PN5180 兼容/类似?我这样问是因为我注意到有 PN5180 的 Arduino 库,但没有 PN5180 的。 你们有图书馆吗?我们只想尽快启动并开始使用该产品。板设计很可能在两周内完成并制作完成。 谢谢! Re: PNEV5180B 2.0 PN5180 Altium Schematics 您好, 我们提供适用于 PN5190 的NFC读取器库。该库是为 NXP 产品组合中的一些主机 MCU 设计的,例如 LPC1769 和 Kinetis K82;将功能移植到第三方平台不在我们的支持范围内,必须完全由客户完成。您可以参考以下文章,并将其作为移植工作的参考: -将 NFC 阅读器库与 LPC55S69 结合使用 - NFC读取器库移植 FRDM_K64F -将 NFC 阅读器库移植到 i.MX RT1050 - NXP 社区 PN5190 的可用设计文件基于我们的开发板 ( PNEV5190BP ),该开发板嵌入了 BGA 封装。VFLGA40 封装也有一个参考设计:模块板 PN5190 HVQFN 设计文件;但是,该文件的目的是说明此特定封装所需的连接。 问候, 爱德华多。
記事全体を表示
8M以上のリアルタイム精度について こんにちは。8M Plusのリアルタイムアプリケーションに関する機能について、さらに詳しく知りたいと思います。TSNやリアルタイムパフォーマンス、ジッターに関するテストレポートや関連資料はありますか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy エリア 入手可能な資料 内容物 リアルタイムCPU/RTOSレイテンシ ハープーンユーザーガイド  i.MX 8M Plus / Zephyr でリアルタイムレイテンシを測定し、IRQレイテンシやタスクレイテンシ(ns単位)も含まれます。例としての結果:no-load IRQ レイテンシ min/avg/max/stddev = 625 / 796 / 11,125 / 1,798 ns タスクレイテンシ = 2,583 / 2,671 / 13,041 / 6,045 ns 。Linux CPU + メモリ負荷の場合、IRQレイテンシ= 625 / 798 / 4,250 / 4,674 ns 、タスクレイテンシ= 2,583 / 2,670 / 14,333 / 10,407 ns です。 リアルタイムベンチマーク方法 Harpoon ユーザーガイド — RT レイテンシアプリケーション ベンチマークをハードウェアIRQイベントとソフトウェア動作間の時間差と定義し、ハードウェアタイマーとサブマイクロ秒単位の精度で測定します。 TSNの能力 i.MX 8M Plus製品/リファレンスマテリアル i.MX 8M PlusはデュアルGbイーサネットを搭載し、そのうち1つはTSNに対応し、産業用リアルタイム制御には統合 800 MHzのArm Cortex-M7 を使用します。 TSNハードウェア規格 i.MX 8M プラスリファレンスマニュアル TSNのサポートには 、IEEE 802.1Qbv Time-Aware Shaper 、 802.1Qav Credit-Based Shaper 、 IEEE 1588v2 PTP 、およびイーサネットブロック実装 802.1Qbv-2015が含まれます 、 802.3br 、 そして 802.1Qbu フレームプリエンプション関連のTSN関数。 TSNテスト/検証環境 リアルタイムエッジユーザーガイド トラフィック生成・解析およびレイテンシ、ジッター、同期精度の監視を含む8M Plus TSNの能力を評価するためのTSNテスト環境 i.MX 説明します。 TSNジッター/レイテンシの例 リアルタイムエッジユーザーガイド — TSNエンドポイントサンプルアプリ トラフィックの最小/平均/最大レイテンシやノート レイテンシは約503μs と レイテンシ ジッターは約300 ns を含むTSNエンドポイント統計を提供します。 TSNアプリケーションデモ AN13588 GenAVB/TSNのリアルタイム制御アプリケーションを実証します。これは 2ミリ秒サイクル  、400μsの予約/保証制御トラフィックウィンドウ 、スケジューリング、プロセッシングタイミング、トラフィックの正確性、レイテンシのための統計スレッドを記述しています。 TSN 802.1Qbv デモ AN13995 8M Plus i.MX を用いたTSN 802.1Qbvの実演と、時間認識シェーピングが固定リピーティングサイクルを用いてデターミニスティックなレイテンシを提供する方法を説明しています。また、Linux  tc  /  taprio  configurationの例も含まれています。   Re: Regarding 8M Plus Real time Accuracy @yipingwang 情報を提供していただきありがとうございます。iMX8M Plus EVKについても情報を教えていただけますか? ありがとうございます。 Re: Regarding 8M Plus Real time Accuracy i.MX95 EVKに関する公式な「リアルタイム性能レポート」は公開されていないことを承知しております。しかし、NXPはi.MX95プラットフォーム上でリアルタイムのベンチマークを内部で行っています。内部ベンチマーク文書によると、cyclictestおよびEtherCATのパフォーマンス評価は、Linux上でリアルタイムエッジソフトウェアを実行するi.MX95 LPDDR5 EVK上で実施PREEMPT_RTされています。報告された例としては、6時間のストレスNGテストにおける最大周期テスト**レイテンシ**約38μsや、EtherCATのフィルタによる最大ジッター約12μsが報告されています。リアルタイム性能はBSPバージョン、カーネル構成、CPU分離、ワークロード、ネットワークトラフィックに大きく依存するため、これらの値はアプリケーションレベルの保証された制限ではなく、参照の測定とみなすべきです。   詳細については、 https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdfを参照してください。 サポートされるベンチマークプラットフォームとして、詳細なサイクリックテスト、ストレス、rt_latency手順を提供します。 Re: Regarding 8M Plus Real time Accuracy 代理店からは、NXP i.MX95 EVKのリアルタイムパフォーマンスやジッターに関する公式なパフォーマンスレポートは現在存在しないと伝えられました。 しかし、リアルタイムレイテンシを評価するためのテスト手法(例:cyclictest)についてのドキュメントも提供しました。 これは我々の側で多少の混乱を招いている。標準化されたテスト手法が存在することから、そのようなテストは少なくともリファレンスEVKプラットフォーム上で内部で実施されたと仮定します。 したがって、以下の点を明確にしたいと思います。 NXPはi.MX95 EVKのリアルタイム性能(例:レイテンシ、ジッター)の内部測定を行ったことはありますか? もしそうなら、共有できる参考や基準の結果はありますか? リアルタイムのパフォーマンスは、システム構成やワークロードによって変動する可能性があることを理解しています。しかし、管理された条件下(例えば、デフォルトのBSP、最小負荷)でのベースライン結果であっても、初期評価には非常に役立つだろう。 再開まで今しばらくお待ちください。 hankwang_0-1784018178178.png Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (リアルタイムエッジソフトウェアユーザーガイド)(https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf) .リアルタイムエッジソフトウェア(最も関連性が高い) NXPの Real-Time Edgeソフトウェア は公式にi.MX8M Plus EVKをサポートし、以下を含みます: PREEMPT_RT Linux TSNスタック IEEE 802.1AS (gPTP) 同期 TSNトラフィックシェーピングとスケジューリング EtherCAT、OPC-UA、CAN関連の産業用プロトコル Cortex-A53 + Cortex-M7を用いた異種リアルタイム動作 内部文書 REALTIMEEDGEUG によると、Real-Time Edge Softwareは以下の機能を提供します: リアルタイムネットワーキング(TSN) リアルタイムLinux(PREEMPT_RT) 純粋なRTOS/ベアメタルオプション 刑務所の仕切り インダストリアルプロトコルサポート i.MX 8M Plus LPDDR4 EVKのサポート NXPアプリケーションノート AN13995 – i.MX 8M Plusを用いたTSN 802.1Qbvデモンストレーション リアルタイムエッジのSix Pack資料(PREEMPT_RT+TSNサポートを説明する) Re: Regarding 8M Plus Real time Accuracy @yipingwang情報を提供していただき、本当にありがとうございました。
記事全体を表示
PWM Capture can't work in frdm_mcxw72 board Hi, I tried to practice the pwm capture sample in  frdm_mcxw72 board, but unfortunately, the print message in serial tool only show " capture cycle err -134" . I'm sure there is the 1Khz, 50% duty cycle pwm signal inject into the PTA21 pins in frdm_mcxw72 board. i imported the whole project files from the demo case,  there is no change that i only added the overlay file,   below is the overlay files setting. anliu114036_0-1783501416708.png can you help check the reason why there is no correct print information. thanks in advance! Re: PWM Capture can't work in frdm_mcxw72 board Hello, Hope you are doing well. Could you please clarify what Zephyr repo are you using? Also, are you starting from any of the examples? Did you modify something? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo, The repo version is V4.4.1.0,  below is the my steps  1. Import the capture example application from the repo anliu114036_0-1783644698775.png  2. Add the  DTS overlay file in the board folder, the content of the overlay file  posted in first message. 3. build and flash into the frdm_mcxw72 board in my hand,  the print message is  "capture cycle err" ,  it looks the board state is ok because i didn't inject the pwm signal , but the print message is the same after the pwm signal injected into PTA21 pins.     Re: PWM Capture can't work in frdm_mcxw72 board Hello, Could you please clarify what repository are you using? Are you using Upstream or Downstream? Also, is the example working on your side without modifications? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo here is the repo version  anliu114036_0-1783902527295.png i only update the overlay file,  it will be  can't build successfully if there is no this file. Best regards! Re: PWM Capture can't work in frdm_mcxw72 board Hello, Could you please clarify if you are using Upstream or Downstream? Best Regards, Ricardo Re: PWM Capture can't work in frdm_mcxw72 board Hi Ricardo, Sorry, i didn't very understand  what's the "Upstream" or "Downstream" here . i guess it should be the downstream. or can you change another description?
記事全体を表示
IMXRT LPUARTの非ブロッキング転送APIはエラー処理を困難にする こんにちは、 私は、割り込みベースのノンブロッキング転送を行うためのLPUARTの「転送」APIについて調べています。LPUART割り込みなどの「ハッピーケース」処理をうまくラップし、準備ができたときにだけデータを受信できる良い高水準APIを提供しているようです。アイドル状態、受信準備完了、送信完了などの処理。しかし、これによってUARTエラーの処理が非常に困難になる。 LPUART_TransferHandleIRQ関数内にはエラー処理がなく、fsl_lpuart.cのその関数の直後には「ユーザーによって実装される」というコメントを含む偽の空LPUART_TransferHandleErrorIRQがあります。これは完全に未完成に見える。 UARTエラーを実際に処理する唯一の方法は、デフォルトのLPUARTx_IRQHandler関数を上書きし、LPUARTx_RX_DriverIRQHandler(またはTX)を呼び出す代わりに、自分でエラーを処理し、「ハッピーCASE」割り込みを元のLPUARTx_RX/TX_DriverIRQHandlerに渡してLPUART_TransferHandleErrorIRQに呼び出すようにすることのようです。 さらに、転送APIの外部でLPUART_EnableInterruptsを呼び出してエラー割り込みを自分で有効にし、エラー処理の中でLPUART_DisableInterruptsを呼び出してそれらをクリアするなどの処理を行う必要があります。 エラー処理にこれだけの手間をかけるのは、かなり面倒な作業のように思える。なぜこの機能が転送API自体に組み込まれていないのでしょうか? -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 詳細なフィードバックをありがとうございます。SDKは各ペリフェラル機能の共通ユースケースを提供するためのものなので、少し曖昧な部分もあることは理解しています。このようなご意見も参考にしながら、私たちは常にAPIの改善に取り組んでいます。ご提案ありがとうございます。今後のリリースでもLPUARTのエラー処理が実装されることを願っています。 一方で、どのエラー条件を扱いたいのか、どのデバイスを使っているのか教えていただけますか?その情報をもとに、実装に役立つエラー条件に関するドキュメントを提案できます。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult 考えられるすべてのエラー。これは、転送APIはあるがエラー処理がないほぼすべてのペリフェラル(SPI、I2Cなど)に当てはまります。IMXRT1172のLPUARTには、特にフレーミングエラー、パリティエラー、ノイズエラーがあり、これらは適切に処理されていません。残念ながら現状、これらのペリフェラルは転送API使用時のエラー処理にハッキングが必要です。SDKハンドラーを呼び出す前に、エラーを確認するために実際のデフォルトのIRQハンドラをオーバーライドしなければなりませんでした。 ありがとうございます -m Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 追加の開発期間が必要になる可能性があることは理解していますが、SDKsの改善に引き続き取り組んでいます。参考として、SDK(バージョン26.6)の関数「LPUART_TransferHandleIRQ」の構造を確認し、アプリケーションが必要とする類似の回復フローを実装できます。 Habib_MS_1-1784062752001.png BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult こんにちは、 @nxp16 さん。 他に質問がありましたら、お気軽にお知らせください。 BR ハビブ Re: IMXRT LPUART non-blocking transfer API makes error handling difficult はい、既に似たようなものを実装しています。送っていただきありがとうございます。
記事全体を表示
RT1064 I2C 通信异常,频率为 400kHz RT1064 设备的 I2C2 接口连接到模块 A。在 400kHz 频率下出现通信异常,但在 100kHz 频率下工作正常。 1. 将同一系列中不同型号的模块 B 以 400kHz 的频率连接没有问题。 2. 从波形上看,这相当于主机时钟在连接到模块 A 后被拉伸然后恢复时发生的异常情况。 PS:将该设备的 I2C 驱动程序移植到另一台 1064 设备上,测试模块 A,在 400k 功耗下未发现问题。 原因可能是什么? 图 1 模块 A 逻辑分析仪在 400kHz 下的异常波形 foreverwlh2025_0-1782181859478.png 图 2:模块 A 在 100kHz 下的逻辑分析仪波形 foreverwlh2025_1-1782181977222.png 图3:模块B在400kHz时的波形 foreverwlh2025_2-1782182029028.png i.MX RT106x Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 感谢您的进一步说明——这是一个非常重要的发现。   根据您的观察,该问题似乎更有可能是由于两级 ADUM1251 隔离链路导致的 400 kHz I2C 时序裕量不足,而不是模块 A 本身的异常。 即使上升时间在规格范围内,在 RT1064 上,我们仍然建议检查 LPI2C 主侧 400 kHz 配置,特别是 MCFGR2[FILTSCL/FILTSDA] 和 MCCR0/MCCR1,因为 RT1064 上的主同步延迟不仅受上升时间的影响,还受数字滤波器和定时参数设置的影响。 我们建议您阅读项目中实际使用的配置,并将其与 RT1064 参考手册第 47 章中的表 47-5“LPI2C 示例时序配置”进行比较。 请特别检查以下设置是否与您所选时钟条件的示例值相符: I2C模块时钟源 目标波特率:400Kbps 预分频 FILTSCL/FILTSDA SETHOLD CLKLO CLKHI DATAVD 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 补充信息:昨天在定位方面取得了一些进展: 我们的硬件扩容计划如下: 主板:RT1064--- ADUM1251 3.3V 至 5 V 子板:ADUM1251-模块A 5V转3.3V 经验证,在硬件链路的两层中添加 ADUM1251 后,模块 A 的通信出现异常。但移除 ADUM1251 后,通信在 400k 处恢复正常。造成这种情况的原因可能是什么? PS:我们的硬件工程师认为 ADUM1251 只会增加通信延迟,不会产生其他影响。 Re: RT1064 I2C communication abnormality at 400kHz 你好,@mayliu1 我们的产品即将发布,我们已经调查这个问题好几天了。如果您能尽快回复,我们将不胜感激! Re: RT1064 I2C communication abnormality at 400kHz HI 补充信息 1.我们的两位硬件工程师使用示波器检查了故障波形,上升时间符合要求,在 100ns 以上。 2. 我将 I2C 初始化和读写功能驱动程序移植到另一种 RT1064 设备,并测试了模块 A,没有发现任何问题。 下图显示了另一个设备模块 A 的测试逻辑分析仪的波形。 foreverwlh2025_0-1782194338022.png 怀疑: 1.如果时钟在拉伸后恢复异常,还有哪些其他原因可能导致这种情况? 2. 是否有专门的功能来设置上次回复中提到的 MCFGR2 等设置?我没有看到在 I2C 初始化过程中需要设置任何接口。 ----如果上升时间满足要求,我们是否就不需要考虑这些寄存器设置了? Re: RT1064 I2C communication abnormality at 400kHz 嗨@foreverwlh2025 , 非常感谢您对我们产品的关注以及对我们社区的使用。 我认为这很可能不是 A 模块的问题,而是该特定 RT1064 LPI2C2 总线上的 400 kHz 时序裕量问题。 在 RT1064 上,LPI2C 时序受总线上升时间、总线负载、上拉电阻和毛刺滤波器延迟的影响。 RT1064RM 参考手册指出,上升时间越大,同步延迟就越高。(参见第 47.3.1.4 章)时序参数) 主故障滤波器 MCFGR2[FILTSCL/FILTSDA] 必须设置,使其延迟保持在最小 SCL 低/高周期以下,RT1064 在 MCCR0/MCCR1 中提供了 400 kbps 定时设置的示例。请查看表 47-5。LPI2C 示例时序配置 mayliu1_0-1782186916949.png 因此,如果模块 A 使总线边沿稍微变慢或改变有效负载,则总线可能在 400 kHz 时发生故障,但在 100 kHz 时仍然可以工作。 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz RT1064 参考手册中没有列出 400 kbps 的 10 MHz LPI2C 功能时钟。 虽然可以使用此时钟生成 400 kbps 波特率,但应根据 I2C 规范仔细验证自动生成的定时参数,特别是 tLOW、tHIGH、建立/保持定时和数据有效定时。 为降低设计风险,建议使用经过验证的时钟源,例如 48 MHz,如参考手册所示。 Re: RT1064 I2C communication abnormality at 400kHz 以下是打印配置。可能需要调整哪个参数? PS:显然是由于自动接口分配造成的 foreverwlh2025_0-1782704741259.png Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 您可以尝试直接设置寄存器。 例如,当使用 60 MHz I2C 时钟时,可以采用以下配置。 mayliu1_1-1782813580334.png 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 当前的 I2C 时钟是基于 SDK2_13_0-EVK-MIMXRT1064 板 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c 目录中的示例配置进行配置的。 #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); 我该如何修改才能获得精确的 8MHz 或 48MHz 频率?(时钟树似乎看不见) Re: RT1064 I2C communication abnormality at 400kHz 我尝试将频率修改为 60MHz 和 8MHz,但仍然无效。下图中的红色方框显示的是修改后打印的值,这些值与手册中的值不同。 foreverwlh2025_0-1782813239395.png Re: RT1064 I2C communication abnormality at 400kHz 你好@foreverwlh2025 , 配置 I2C 时钟有多种方法。 建议您尝试 8 MHz 和 60 MHz,因为这两个时钟设置相对容易实现。 我正在使用 SDK 演示版: "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" 方法一:将 LPI2C 时钟源配置为 60 MHz 只需将时钟分频器设置为 0 即可。 mayliu1_3-1782806044116.png 方法二:将 LPI2C 时钟源配置为 8 MHz 使用 MCUXpresso IDE 时钟工具并按如下所示进行配置。选择 OSC_CLK 作为时钟源,并将分频器设置为 3,这将为 LPI2C (I2C) 模块生成 8 MHz 时钟。 mayliu1_0-1782804733641.png mayliu1_4-1782806209573.png 希望对你有帮助 顺祝商祺! 5月 Re: RT1064 I2C communication abnormality at 400kHz 如图所示,我尝试修改寄存器设置以匹配参数,但在 60MHz 下性能没有提升;即使是性能良好的模块在 8MHz 下也无法正常工作。 foreverwlh2025_0-1782882582056.png Re: RT1064 I2C communication abnormality at 400kHz 原因已查明,出现问题的模块将在 400k 时出现时钟拉伸现象。 但是我们使用的隔离器芯片不支持 SCL 双向。更换隔离芯片后, 测试结果正常;此订单可以结案。
記事全体を表示
board.h に extern C ガードがありません これはバグレポートです。MCXA153にはSDK_2.16.000を使用しています。MCUXpressoの「新しいC/C++プロジェクトの作成」ウィザードを使用して新しいC++プロジェクトを作成すると、生成されたコードがビルドに失敗します。 `BOARD_InitDebugConsole()' への未定義の参照 これは board.h に extern C ガードが欠落しているためです。これは次のように修正できます。 #ifdef __cplusplus extern "C" { #endif void BOARD_InitDebugConsole(void); #ifdef __cplusplus } #endif 開発ボード MCXA Re: board.h missing extern C guard 約束してから 1 年以上経ちましたが、新規インストールで C++ プロジェクトを作成すると、バグはまだ存在します (2025 年 12 月)。 `BOARD_InitDebugConsole()' への未定義の参照 NXP ではお客様のケアをしている人っているのでしょうか? Re: board.h missing extern C guard 親愛なる@aberger様、 お客様のフィードバックに基づいて問題を再現し、対応する問題を特定しました。 回答を NXP コミュニティにご提供いただき、ありがとうございます。このバグは関連チームに提出済みであり、対応するパッチをできるだけ早く更新したいと考えています。 よろしくお願いいたします LIU Re: board.h missing extern C guard こんにちは、 @fjrg76さん この問題を報告していただきありがとうございます。返信が遅くなり、大変申し訳ございませんでした。 当社の社内システムでは、CASEが1か月以上クローズされると、新たな更新が加わった際にリマインダーや通知を受け取ることはありません。ご迷惑をおかけしましたことを心よりお詫び申し上げます。 この問題については、SDKチームに確認し、できるだけ早くご連絡いたします。 念のためお伝えしますが、今後さらに質問や懸念があれば、新しいサポートチケットを作成してください。これにより、お客様のご要望を迅速に確認し、タイムリーな対応が可能になります。または、直接私にご連絡いただければ、メッセージを受け取り次第すぐにご連絡いたします。 ご理解とご辛抱に感謝いたします。 BR アリス
記事全体を表示
RT1064 I2C communication abnormality at 400kHz The I2C2 interface of the RT1064 device connects to Module A. Communication anomalies occur at 400kHz, but it functions properly at 100kHz 1. Connecting module B of a different model within the same series at 400kHz is no problem 2. In terms of waveform, it is equivalent to an anomaly occurring when the host clock is stretched and then restored after connecting to Module A PS: Implement the I2C driver port of the device to another 1064 device, test module A, no issues at 400k What might be the reason? 1. Figure 1 Module A Abnormal Waveform of Logic Analyzer at 400kHz foreverwlh2025_0-1782181859478.png 2. Figure 2: Waveform of Logic Analyzer for Module A at 100kHz foreverwlh2025_1-1782181977222.png 3. Figure 3: Waveform of Module B at 400kHz foreverwlh2025_2-1782182029028.png i.MXRT 106x Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , Thanks for the additional clarification — this is a very important observation.   From your observations, the issue appears more likely to be related to insufficient 400 kHz I2C timing margin caused by the two-stage ADUM1251 isolation link, rather than an abnormality of Module A itself. Even if the rise time is within spec, on RT1064, we still recommend checking the LPI2C master-side 400 kHz configuration, especially MCFGR2[FILTSCL/FILTSDA] and MCCR0/MCCR1 , because the master synchronization latency on RT1064 is affected not only by rise time, but also by the digital filter and timing parameter settings. We suggest reading out the actual configuration used in your project and comparing it with Table 47-5, “LPI2C Example Timing Configurations,” in Chapter 47 of the RT1064 Reference Manual . In particular, please check whether the following settings match to the example values for your selected clock condition: I2C module clock source Target baud rate: 400Kbps PRESCALE FILTSCL / FILTSDA SETHOLD CLKLO CLKHI DATAVD Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Additional information, there was some progress in positioning yesterday: Our hardware expansion is: Motherboard: RT1064--- ADUM1251    3.3 V to 5 V Subboard: ADUM1251- Module A          5v to 3.3v After verification, it was found that after adding ADUM1251 to the two layers of the hardware link, module A had abnormal communication. However, after removing it, communication returned to normal at 400k. What could be the reason for this? PS: Our hardware engineers believe that ADUM1251 only increases communication latency and has no other impact Re: RT1064 I2C communication abnormality at 400kHz Hi,@mayliu1 Our product is about to be released, and we have been investigating this issue for several days. If we could receive your response as soon as possible, we would greatly appreciate it! Re: RT1064 I2C communication abnormality at 400kHz Hi  Supplementary information 1. Our two hardware engineers checked the waveform of the problem through an oscilloscope, and the rise time met the requirements, within 100+ns 2. I ported I2C initialization and read-write function drivers to another type of RT1064 device,  and tested module A without any issues The following figure shows the waveform of another device module A testing logic analyzer foreverwlh2025_0-1782194338022.png doubt: 1. If the clock recovers abnormally after stretching, what other reasons could be causing it 2. Is there a dedicated function to set settings such as MCFGR2 mentioned in the last reply? I didn't see any interface to be set in the I2C initialization process ----If the rise time is met, do we not need to consider these register settings? Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , Thank you so much for your interest in our products and for using our community. I think that this is most likely not a Module A issue, but a 400 kHz timing-margin issue on that specific RT1064 LPI2C2 bus. On RT1064, LPI2C timing is affected by bus rise time, bus loading, pull-up resistors, and glitch-filter latency.  RT1064RM  reference manual describe  that larger rise time increases synchronization latency.  (refer to chapter 47.3.1.4 Timing Parameters) The master glitch filters MCFGR2[FILTSCL/FILTSDA] must be set so their latency stays below the minimum SCL low/high period, and RT1064 provides example 400 kbps timing settings in MCCR0/MCCR1 .  Please check the Table 47-5. LPI2C Example Timing Configurations mayliu1_0-1782186916949.png So if Module A makes the bus edges slightly slower or changes the effective loading, the bus may fail at 400 kHz but still work at 100 kHz .  Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Below is the configuration for printing. Which parameter may need to be adjusted? PS:apparently due to automatic interface allocation foreverwlh2025_0-1782704741259.png Re: RT1064 I2C communication abnormality at 400kHz A 10 MHz LPI2C functional clock is not listed in the RT1064 Reference Manual example timing configurations for 400 kbps. Although it is possible to generate a 400 kbps baud rate with this clock, the automatically generated timing parameters should be carefully verified against the I2C specification, particularly with respect to tLOW, tHIGH, setup/hold timing, and data valid timing. To reduce design risk, it is recommended to use a validated clock source, such as 48 MHz, as shown in the Reference Manual. Re: RT1064 I2C communication abnormality at 400kHz I tried modifying 60MHz and 8MHz, but it still didn't work. The red box in the figure below shows the values printed after modification, which are different from the manual foreverwlh2025_0-1782813239395.png Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , There are several ways to configure the I2C clock. As a suggestion, you can try 8 MHz and 60 MHz, as these two clock settings are relatively easy to achieve. I am using the SDK demo: "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" Way 1: Configure LPI2C clock source to 60 MHz Simply set the clock divider to 0. mayliu1_3-1782806044116.png Way 2: Configure LPI2C clock source to 8 MHz Use the MCUXpresso IDE Clock Tool and configure it as shown below. Select OSC_CLK as the clock source and set the divider to 3, which will generate an 8 MHz clock for the LPI2C (I2C) module. mayliu1_0-1782804733641.png mayliu1_4-1782806209573.png Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz Hi @foreverwlh2025 , You may try setting the registers directly. For example, when using a 60 MHz I2C clock, the following configuration can be applied. mayliu1_1-1782813580334.png Wish it helps you Best Regards May Re: RT1064 I2C communication abnormality at 400kHz The current I2C clock is configured based on the sample configuration in the SDK2_13_0-EVK-MIMXRT1064 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c directory, #define LPI2C_CLOCK_SELECT (0U) #define LPI2C_CLOCK_DIVIDER (5U) CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT); CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER); ---How can I modify it to obtain the precise 8MHz or 48MHz? (The clock tree doesn't seem to be visible) Re: RT1064 I2C communication abnormality at 400kHz As shown in the diagram, I tried to modify the register settings to correspond to the parameters, but there was no improvement at 60MHz; Even good modules cannot function properly at 8MHz foreverwlh2025_0-1782882582056.png Re: RT1064 I2C communication abnormality at 400kHz The cause has been identified, and the module with the problem will experience clock stretching at 400k. However, the isolator chip we are using does not support SCL bidirectional. After replacing the isolator chip, the test was normal; This order can be closed
記事全体を表示
Behavior of PMIC using external Watchdog (Wdg_43_VR5510) I have implemented the external watchdog (Wdg_43_VR5510) for PMIC. But it is going into endless loop in Pmic_VR5XX_TimeoutLoops_StateTransistion (refer below). SagarZala_1-1728467272425.png Currently it is in INIT_FS state, as per the state diagram it says we need to have a good watchdog refresh to change the state from INIT_FS to Wait_ABIST2. image (7).png To Satisfy the first good watchdog refresh within 256ms, we have called watchdog trigger API after Wdg_43_VR5510_Init function during EcuM Initialization. image (8).png We need to know, how and where to call the first watchdog refresh. So that the state transition happens from INIT_FS to wait_ABIST2. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hello @Jerry_cao , Thank you for contacting us. However, the original post has been closed for nearly two years, so we are unable to continue supporting you under that thread. Please create a new post for your issue on S32G - NXP Community, and our team will be happy to assist you further. BR Celeste Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hello NXP team, I'm currently debugging the VR5510 PMIC and have run into a real-time scheduling issue related to the watchdog refresh. The MCAL I2C watchdog refresh (feeding the VR5510 watchdog over I2C) is implemented as a synchronous operation. Because we call it from within an interrupt context, the synchronous wait blocks the CPU and degrades the real-time scheduling of other tasks. I noticed there is an asynchronous option in the driver configuration/code. However, in practice it still performs a synchronous busy-wait (it blocks and polls until the I2C transfer completes), so it does not actually decouple the transfer from the caller. My questions: Is there an officially supported way to make the VR5510 watchdog refresh truly non-blocking (e.g. interrupt-driven or DMA-driven I2C), so that it does not stall other tasks? If the asynchronous option is expected to be non-blocking, is the current synchronous busy-wait behavior a known limitation or a configuration issue on my side? Any guidance, reference configuration, or example code would be greatly appreciated. Thank you. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hello SagarZala, I wonder if you have tried the two out-of-the-box examples in S32 Design Studio (S32DS)? Will they have the same problem? May be they are very good references for you. Celeste_Liu_0-1729049570948.png Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Hi, Thanks for the reply. I am using RTD version 4.0.2. I have already configured the I2C at high speed and WD_WINDOW is also configured at 1024ms. But still its not working. Re: Behavior of PMIC using external Watchdog (Wdg_43_VR5510) Dear @SagarZala , Thank you for your question. VR5510 is commonly paired with the S32G microprocessor. For this, the available drivers for VR5510 should be provided under the S32G RTD packages. Which RTD version are you using and which specific example is it? Taking the RTD 4.0.0 version as an example, you can find the documents "RTD_WDG_43_VR5510_IM" and "RTD_WDG_43_VR5510_UM" under the path C:\NXP\SW32G_RTD_4.4_4.0.0\eclipse\plugins\Wdg_43_VR5510_TS_T40D11M40I0R0\doc. The document "RTD_WDG_43_VR5510_UM" describes more detail. It is worth mentioning that the watchdog is triggered via the I2c command and it depends on the I2c speed. When the I2c speed is low, the watchdog may not be triggered successfully within the watchdog's window open time. To avoid this problem, we recommend that the user configure I2c with high speed and use a large window period when it is enabled. To set the watchdog refresh, you can configure the WD_WINDOW [3:0] to obtain the refresh time. As shown in the following figure: Celeste_Liu_0-1728636341767.png Refer to "Document VR5510 Product data sheet", page 60, Table 45. Watchdog window period configuration, as shown in the screenshot below. And after setting the correct WD period time, you need to correctly feed the WD. Celeste_Liu_4-1728636786838.png Celeste_Liu_5-1728636805408.png Hope the above information is helpful to you. Best Regards, Celeste
記事全体を表示
S32DS 3.6.7 RTD 7.0.1 P02 HSE 代码生成错误 我正在尝试使用S32DS 3.6.7为S32K358生成与 HSE 相关的 RTD 代码,但我遇到了一个问题。 首先,我按以下顺序安装了以下更新站点: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip 安装状态如下图所示。 wodudwo_1-1784020530765.png wodudwo_0-1784020518071.png 接下来,我通过选择下面显示的 SDK 创建了一个新项目。 wodudwo_2-1784020561794.png 然后,我在配置工具中添加了BaseNXP和Hse组件,如下所示。 wodudwo_3-1784020582815.png 但是,出现以下验证错误: Issue: Hse is not found in the toolchain/IDE project. The project will not compile! Level: Error Type: Validation Tool: Toolchain/IDE project Origin: Peripherals Target: Toolchain/IDE project: M7_0_0 Resource: platform.driver.Hse 我该如何解决这个问题并成功生成与 HSE 相关的 RTD 代码? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error 你好, 我尝试安装了以下软件包后生成代码,但仍然遇到同样的验证错误。 wodudwo_1-1784074948979.png wodudwo_2-1784074960671.png wodudwo_3-1784074969264.png wodudwo_0-1784074933867.png 按照您的建议,我首先卸载了所有与RTD相关的扩展程序,然后只安装了以下软件包: - SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip 安装状态如下所示。 wodudwo_4-1784075002029.png wodudwo_5-1784075010124.png 但是,这样做之后,我在创建新项目时就无法再选择任何 SDK 了,如下图所示。 wodudwo_6-1784075045680.png 我应该如何解决这个问题? Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error 嗨@wodudwo 为了验证是否缺少软件包,请将您 IDE 中安装的软件包与下图所示的软件包进行比较? VaneB_0-1784059529950.png 此外,我们来尝试卸载所有与 S32K3 RTD 相关的软件包,然后只重新安装名称中包含“P02”的软件包。 BR,VaneB Re: S32DS 3.6.7 RTD 7.0.1 P02 HSE code generation error 嗨@wodudwo 我认为安装步骤中可能缺少某个步骤。以下是我成功安装软件包的步骤: 由于您已经安装了一些软件包,我建议您首先卸载所有与 S32K3 设备 RTD 相关的软件包,包括 S32K3 和 S32M 设备的 S32 配置工具 R1.8 NPI 数据包,因为这些软件包依赖于 RTD 软件包。 - 添加以下更新站点: SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite.zip SW32K3_RTD_R23-11_7.0.1_P02_D2603_DesignStudio_updatesite_updated_D20260630.zip - 选择并安装名称中包含 P02 的软件包。允许 S32DS 自动选择并安装安装所需的任何其他依赖软件包。 - 等待安装成功完成,并允许 S32DS 重新启动。 - 重启后,选择并安装所有适用于 S32K3 和 S32M 设备的 S32 配置工具 R1.8 NPI 数据包组件。再次允许 S32DS 自动选择任何所需的依赖项。 - 等待安装成功完成,然后让 S32DS 再次重新启动。 按照这些步骤操作后,我的 IDE 中最终安装了六个 RTD 7.0.1 软件包(包括 P02)。通过这种设置,我可以将 HSE 驱动程序添加到我的项目中,而不会出现任何问题。 VaneB_0-1784154210318.png
記事全体を表示
PNEV5180B 2.0 PN5180 Altium Schematics Are the PNEV5180B 2.0 PN5180 schematics available in ALtium format ? ALso PCB would be useful , mainly for the NFC antenna. We want to use the PN5180 and want to get  up and working asap Re: PNEV5180B 2.0 PN5180 Altium Schematics Hello @David-Lightbug Hope you are doing well. Please accept my apologies, PN5180 design files are not available. Perhaps you could refer to the PN5180 Evaluation board quick start guide, which includes some pictures showing the relevant schematics. Also, please refer to the PN5180 Antenna design. If possible, I will recommend considering PN5190 | NFC Frontend for payment. Following design files related to PNEV5190BP are available: - Module board - Base board Regards, Eduardo. Re: PNEV5180B 2.0 PN5180 Altium Schematics Hi, Going through the altium schematics , they all appear to be the BGA package/  You have the PNEV5190M  (BGA packagein cct diagram) and   PNEV5190BP also BGA. I have found the evaluation board manual, PNEV5180B that shows the QFN package but not the altium files. Can you help. Re: PNEV5180B 2.0 PN5180 Altium Schematics Hi, We offer a NFC Reader Library for PN5190. This library is designed for some Host MCUs from NXP's portfolio, such as LPC1769 and Kinetis K82; porting the functionality to a third-party platform is out of our support and must be done entirely by the customers. You can refer to the following articles and use them as a reference for the porting: - Using NFC Reader Library with LPC55S69 - NFC Reader Library Porting FRDM_K64F - NFC Reader Library Porting to i.MX RT1050 - NXP Community The available design files for PN5190 are based on our Development Board (PNEV5190BP), which embeds the BGA package. There is also a reference design for the VFLGA40 package: Module board PN5190 HVQFN design files; however, the purpose of this file is to illustrate the required connections for this specific package. Regards, Eduardo. Re: PNEV5180B 2.0 PN5180 Altium Schematics Hi, Thanks for your quick reply. I will change to use the PN5190. Are the code compatible/ similar to the PN5180 , the reason I am asking is that I have noticed there are Arduino libraries  for the PN5180 but not the PN5180. DO you have libraires - we just want to get up and going quickly with the product.  The board design is likely to be ready and made in less than two weeks. Thanks
記事全体を表示
已安装 HSE 的 S32K311:软件崩溃和 MCU RESET,调试器无法连接 您好,NXP团队, 背景: MCU: S32K311 AUTOSAR RTD MCAL: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 HSE 固件(全内存): s32k3x1_hse_fw_0.12.0_2.55.0_pb250225.bin 完整调查报告以PDF格式附件形式提供。 主要问题 软件在 Clock_Ip_DistributePll() 中崩溃,MCU RESET。此外,调试器有时无法附加。 当我尝试热连接调试器时,复位原因有时会报告为 HSE_CLK_FAIL。 请您主要检查上述流程、IVT 和 DCF 记录,以及有关此问题发生原因及其解决方案的信息。如有任何其他需要的信息,请告知我们。 请您检查 HSE 安装程序、IVT 配置和 DCF 记录,并告知出现此问题的原因以及如何解决? 如有任何其他信息需要提供,请告知我们。 此致, 舒巴姆·帕德西 Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 提到的 70 秒和 20 秒是从 RESET 到 HSE_STATUS_INIT_OK 的时间。所以基本上只包含启动时间,对吗? 在所有设备上的表现都一样吗? Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 你好@davidtosenovjan 我们的软件由 FBL 和 APPL 组成,两者都使用相同的功能复位机制。 当 APPL 发起复位时,不会出现此问题。 当 FBL 发起 RESET 时,软件在 APPL 启动期间于 Clock_Ip_DistributePll() 内部崩溃。 最初,我们在 Mcu_InitClock() 之后、Mcu_DistributePllClock() 之前添加了对 HSE_STATUS_INIT_OK 的检查。这样就避免了车祸。然而,大约 20 秒后 HSE_STATUS_INIT_OK 才被设置,之后 APPL 的实际启动才继续进行。 今天,我们将 HSE_STATUS_INIT_OK 检查移到了 APPL 中的 Mcu_Init() 之前的更早阶段,如附图所示。 Shubham_MQ_0-1784123821324.png 通过此序列,HSE_STATUS_INIT_OK 几乎立即被设置,并且不再观察到崩溃。 请问您能否澄清以下问题? 为什么只有当 FBL 发起 RESET 时才会出现这个问题,即使 FBL 和 APPL 使用的是相同的 RESET 机制? 为什么在 Mcu_InitClock() 之后检查 HSE_STATUS_INIT_OK 时大约需要 20 秒,但在 Mcu_Init() 之前检查时几乎立即可用? 为什么 FBL 中不需要 HSE_STATUS_INIT_OK 检查,而 APPL 启动时似乎需要? 请提供清晰的根本原因解释和推荐的初始化顺序。我们需要确保当前解决方案的稳健性,并且不会在生产环境中造成任何问题。 如有任何其他详情或时钟配置详情需要告知,请与我们联系。 此致, 舒巴姆·帕德西
記事全体を表示