[过滤器：垃圾邮件] nismkiki 的帖子正文匹配了 " phon**epe "，板 " 电源管理单元 "。 [过滤器：垃圾邮件] nismkiki 的帖子正文匹配了 " phon**epe "，板 " 电源管理单元 "。 帖子主题：如何退还错误的交易 职位机构： 如何从 PhonePe 上的错误交易中取回钱款（客户服务号码 📞076995 95414) 如果您不小心将钱汇入了错误的帐户或在 PhonePe 上进行了错误的交易（客户服务号码 👉+9176,,995,,,954,,,14👈)，请按照以下步骤操作：在 PhonePe 应用程序中进行投诉。如何取回在 PhonePe 上意外支付的款项？ 通过应用程序提出投诉： 打开 PhonePe 应用程序 → 我的（或设置）→ 帮助 & 支持 → 交易问题。TAP错误的交易 → 选择提出投诉 → 写下原因（例如，错误的账户、重复付款）→ 提交。   联系官方客服： 致电：080-6872-7374（免费电话）或 +91-22-6872-7374 提供：注册手机号码、交易编号、唯一参考号码（URN）。电子邮件：[[email protected]](mailto:[email protected])请在邮件主题行注明"Wrong Transaction Reversal" ，并发送您的手机号码、交易 ID 和问题描述。   向银行申请退款： 请就近前往银行网点或通过网上银行/手机银行提交书面申请。获取并保留银行的UTR号码（唯一交易参考）以进行撤销。   后续行动和预防措施： 尽快（最多 48 小时内）提交投诉。妥善保存截图、收据和交易 ID。切勿将您的 OTP、密码或个人信息透露给任何非官方号码或个人。仅使用官方渠道（上述提供的应用程序、网站、电话号码/电子邮件）。   注意：撤销程序通常需要 7-10 个工作日。如果没有及时收到退款，请再次联系客户服务中心或银行。 正文"PhonePe（客户服务号码 📞076995 95414) 如果您不小心将钱汇入了错误的帐户或在 PhonePe 上进行了错误的交易（客户服务号码 👉+9176,,995,,,954,,,14👈)，请按照以下步骤操作：在 PhonePe 应用程序中进行投诉。如何取回在 PhonePe 上意外支付的款项" 匹配的过滤模式"phon**epe" 。 用户[id=258406,login=nismkiki]的发帖因以下最终用户面临的错误而被拒绝： 邮件正文包含 PhonePe（客户服务号码 📞076995 95414) 如果您不小心将钱汇入了错误的帐户或在 PhonePe 上进行了错误的交易（客户服务号码 👉+9176,,995,,,954,,,14👈)，请按照以下步骤操作：在 PhonePe 应用程序中进行投诉。如何取回不小心在 PhonePe 上支付的款项，这在本社区是不允许的。请在发送您的帖子前删除这些内容。

如何替换自定义板的 Yocto 电路板支持包中的 DDR 二进制文件？ 你好 正在尝试替换自定义板的 Yocto 电路板支持包 中的 DDR 二进制。 新计算机已创建，配方 ddr-firmware 的目录也是在自定义元层中创建的，其中包含所需的文件。但是，为 SRC_URI 分配新值并删除配方附加中的原始值并不能阻止 Bitbake 在评估板的原始路径中搜索。不使用配方追加也不会改变本次搜索的任何内容。 似乎唯一有效的方法是掩盖原始配方并在自定义层中创建新配方。 但我不认为这是一种可取的方式。使用为自定义计算机创建的 DDR 二进制文件应该很容易做到这一点。这里可能遗漏了什么？ 谢谢您！ 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 好的，它能用。似乎与 NXP_FIRMWARE_LOCAL_DIR 中设置的文件夹不一致。但不管怎么说，它还是有用的。 还有一个问题，如何关闭自定义层 .bbappend 中的 NXP-EULA 许可证？ 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，仙鹤 感谢您的回复。 客户的 DDR 还应该有 DDR 固件，你能否尝试参考 S32G3_Linuxbsp_44.0_user_Manual.pdf 在 Yocto 中版本电路板支持包期间添加 DDR 固件。 BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 你好，乔伊、 感谢您的回复。 它是 S32G3，电路板支持包 是 "bsp44.0"。 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，起重机 感谢您与我们联系。 你使用的是哪个版本的电路板支持包？ 您使用的是 S32G3 还是 S32G2 芯片？ BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，乔伊、 添加 .bbappend 时尝试过，但不起作用用于定制板。 ERROR: /home/crane/work/yocto/sources/meta-alb/meta-alb-bsp/recipes-bsp/ddr-firmware/ddr-firmware.bb: Unable to get checksum for ddr-firmware SRC_URI entry NXP-EULA: file could not be found The following paths were searched: 尝试了 .bbappend只有 SUMMARY，LICENSE ="CLOSED" 和 LIC_FILES_CHKSUM ="" ，也试过不使用 .bbappend、都得到了相同的错误信息。 这是处理自定义 DDR 二进制文件的唯一方法是掩盖恩智浦的原始配方并创建自定义配方，而不是根据原始配方添加配方附加吗？ 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，仙鹤 请尝试修改文件夹 (fsl-auto-yocto-电路板支持包-build_s32g274ardb2/conf) 中 local.conf 文件。 accept_fsl_eula ="1" BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，起重机 您是否在文件夹中添加了 NXP-EULA 文件？ BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，乔伊、 我试图将这个文件复制到原始配方或自定义配方中，但都不起作用。两种方法都能找到文件，但都会产生以下错误信息： ERROR: No recipes in default available for: /home/crane/work/yocto/sources/meta-crane/recipes-bsp/ddr-firmware/ddr-firmware_%.bbappend 由于我没有使用恩智浦的DDR二进制文件，我认为使用恩智浦生成的NXP-EULA没有意义。禁用检查 NXP-EULA 是感知的，对吧？ 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，起重机 感谢您的回复。 我们应该找到问题的根源。请尝试在 Yocto 中版本 BSP44 以使用恩智浦的 DDR 固件和 NXP-EULA 文件。如果你能成功版本 BSP44，你可以尝试更换 DDR 固件，然后重新版本。 BR 乔伊

GUI Guider v1.7.2 オフライン テンプレートをダウンロードできません。 公式サイトからGUI Guider v1.7.2 オフライン テンプレートをダウンロードできません。ダウンロードしたバージョンは自動的に最新の 1.10.1 バージョンに更新されます。サーバーのリソース パスが正しいかどうかを確認してください。 Re: I can't download the GUI Guider v1.7.2 Offline Template. こんにちは@zzxx 、 この問題を報告していただきありがとうございます。試してみましたが、まさに説明どおりに動作しました。これを社内チームに報告し、修正が提供されるのを待ちます。 BR セレステ Re: I can't download the GUI Guider v1.7.2 Offline Template. こんにちは@zzxx 、 現時点ではこの問題に関してそれ以上の進展はありません。クリスマス休暇および EMEA と AMEC のタイム ゾーン全体の休日期間のため、プロセッシング時間は通常より長くなる場合がありますのでご了承ください。 皆様のご理解とご協力に心より感謝申し上げます。 楽しい一日をお過ごしください！ BR セレステ Re: I can't download the GUI Guider v1.7.2 Offline Template. こんにちは@zzxx 、 すべてが順調に進んでいることを祈っています。問題が解決したことをお知らせしたかったのです。   BR セレステ    

Kinetis K40DN512 の USB CDC デュアル VCOM および MSC こんにちは、 私は、K40DN512 ボード上で FatFS アプリケーションを使用してデュアル VCOM および MSC を作成しようと取り組んでいます。 デバイス スタック上のデュアル VCOM と SD ディスクを使用した FatFS の動作は確認できましたが、MSC の実装は困難でした。デバイス構成ツールを使用して一部の USB コンポーネントを構成する人がいるのを見たことがありますが、私のプロセッサはこれをサポートしていません。 適切なエンドポイントやその他の記述子情報を構成するために、何らかの形式のウィザードを使用して USB デバイス記述子を構成するより簡単な方法はありますか? そうでない場合、これまでに USB デバイス スタック経由でデュアル CDC VCOM および MSC w/ FatFS システムを動作させることに成功した人はいますか?もしSOなら、どのような構成を使用しましたか? ヒントやガイダンスがあれば歓迎します。 Kinetis KシリーズMCU USB Re: USB CDC Dual VCOM and MSC on Kinetis K40DN512 こんにちは@tbryant 要件に最も近い SDK デモ（例: usb_device_composite_cdc_msc_disk ）を選択することをお勧めします。まず、ボード上で正常に動作することを確認し、次を参照して 2 番目の CDC インターフェースを追加します。 Re: 複合USBデュアルCDCデバイス - NXPコミュニティ ありがとう。 BR アリス

ヘルプが必要です: RT1189 上の FlexSPI2 QSPI フラッシュからの起動 カスタム ハードウェア上でユーザー アプリケーションを起動しようとしています。このカスタム ハードウェアには、ポート A のプライマリ ピン グループを使用してコネクテッドされた FlexSPI2 QSPI フラッシュのみがあります。フラッシュ デバイスは、Micron MT25QU256ABA です。RT1189 (RT1189CVM8C) に搭載されたブート ROM がメモリを正しく構成せず、ブートに失敗します。ただし、NXP セキュア プロビジョニング ツールは、これに正常に読み取りと書き込みを行うことがCANできます。 フラッシュ構成ブロック (FCB) は、セキュア プロビジョニング ツールを使用して作成されました。 XIP ブート ヘッダーはイメージのコンパイル自体で無効化されました。代わりに、セキュア プロビジョニング ツールは、上記のスクリーンショットに示されている設定とまったく同じ設定を使用して、簡略化された UI から生成された FCB を使用するように構成されました。上記のスクリーンショットには表示されていませんが、「テスト接続」は成功しています。 さらに、セキュア プロビジョニング ツール (以下、「SPT」と呼びます) から外部メモリを構成するように要求された場合、FlexSPI2 メモリはプロセッサとツールによって正常に読み取ることができます。これを以下に図示します。 ユーザーがフラッシュ プログラマ ツールを開き、ポップアップで「はい」をクリックするか、「外部メモリの構成」ボタンをクリックすると、SPT は上記のフラッシュ構成ブロック設定を使用して、FlexSPI2 フラッシュ メモリをプログラミング用に初期化します。 以下のスクリーンショットは、完全なアプリケーション イメージ (FCB はオフセット 0x400、ユーザー アプリケーションはオフセット 0x1000) をフラッシュした後にキャプチャされたものです。 これにより、フラッシュ構成ブロックが正しいと考えられます。 RT1180 で次のヒューズ ビットが焼損しました。その他のヒューズビットはすべてデフォルトです。 BOOT_CFG0[6] (BT_FUSE_SEL) -> 1b、ヒューズからのブートを有効にする BOOT_CFG2[7] (FLEXSPI_INSTANCE) -> 1b、FlexSPI2を選択する（デフォルトはFlexSPI1） BOOT_MODE ピンを 000b (内部ヒューズからのブート) に設定すると、RT1189 は何もアクティビティを行いません。再度通信できるようにするには、「無限ループ」モードで起動し、その後シリアル ダウンローダー モードに戻す必要がありました。 BOOT_MODE ピンを 100b (「FlexSPI からのブート」) に設定すると、RT1189 は「スタック」したままになりますが、JLink デバッグ プローブによって停止できます。 BOOT_MODE 100b を使用して FlexSPI から起動しようとした後に停止すると、FlexSPI2 のメモリ領域を調べるとすべてゼロが表示されます。 ここで興味深いのは、「すべてゼロ」が RT1189 の FlexSPI2 メモリ領域のデフォルト状態と一致しないことです。次のスクリーンショットは、外部メモリを構成せずにシリアル ダウンローダー モードで起動した後にキャプチャされたものです。 最後にもう 1 つ: ユーザー アプリケーションの MCUXpresso サンプルのリンカー スクリプトが、FlexSPI2 から起動するように変更されました。 注意: スクリーンショットのキャプションには「0x14000000」と表示されていますが、コードで実際に使用されている値は「0x04000000」です。これはタイプミスです これは SPT に反映されています。 これらすべてを念頭に置いて、私の現在の理解は次のとおりです。 FCB は正しくなければなりません。そうでないと、SPT は FlexSPI2 バンク A に接続された外部フラッシュと対話できません。 ROM 自体は、起動時に、SPT とは異なる何らかの方法でこの外部メモリを初期化しようとしているはずです。RT1189 ブート ROM のソース コードがなければ、リバース エンジニアリングを行わずにデバッグを続けることはできませんが、NXP のお客様として、リバース エンジニアリングを行うつもりはありません。 私の質問: この動作を引き起こす設定の何が問題なのでしょうか? フラッシュの初期化に失敗する理由を理解するためにブート ROM をデバッグする方法はありますか? ありがとう！！ Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 数週間の努力の末、XIP ではなく ITCM (0xFFE00000) にリンクすることでプロセッサを起動することができました。ただし、このThreadはまだ関連性があります - FlexSPI2 上の XIP が正しく動作しないのはなぜですか? Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 @Sam_Gao 、 ご返信ありがとうございます。 元の投稿で述べたように: ブートインスタンスの選択は、コメントとAN14589で指定されているものとまったく同じです。BOOT_CFG2[7]はFlexSPI2を選択するために書き込まれます。 アプリケーション コードは、指定どおりに FlexSPI2 メモリ マップ領域 (0x04000000) にリンクされます (m_start_flash が 0x04000000 に変更されます)。返信ではこれを「0x40000000」としていますが、これは上記のアプリケーション ノートや RT1189 のリファレンス マニュアルに記載されているとおり正しくありません。 FCB は予想されるオフセットに存在します。フラッシュ チップを動作中の MIMXRT1180EVK のものと交換してみましたが、それでもまだ動作しません。 ロジック アナライザを使用して、フラッシュ構成ブロックがブート ROM によって読み取られている可能性が高いことを判断できました。クロック速度はすぐに 30 MHz から 125 MHz に変化し、読み取りデータは SPI データ ラインを介して送信されます。 ブート ROM またはブート シーケンスをさらにデバッグできるメカニズムはありますか? Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 こんにちは、 RT1189 のようなデバイス上の FlexSPI2 QSPI フラッシュからの起動に失敗する原因は、通常、いくつかの一般的な構成領域にあるようです。ここでは、潜在的な問題の詳細と、ブート ROM プロセスをデバッグして根本原因を特定する方法について説明します。 AN14589 を参照: https://www.nxp.com/docs/en/application-note/AN14589.pdf 1. ブートインスタンスの選択を確認する： ブートROMに、デフォルトのFlexSPI1ではなくFlexSPI2を使用するように明示的に指示する必要があります。これは BOOT_CFG2[7] によって制御されます。 ヒューズまたはピン。BOOT_CFG2 BOOT_CFG2[7] が 1 に設定されている FlexSPI2 を選択する ブートインスタンスとして 。プライマリブートモードピン（ BOOT_MODE[2:0] ）シリアルNORフラッシュからブートするには、正しく設定する必要があります（例： '100'） 2. アプリケーション リンカー アドレス: FlexSPI2 のブート可能なイメージをビルディングする場合、アプリケーション コードを FlexSPI2 メモリ マップから実行するようにリンクする必要があります。FlexSPI2 の開始アドレスは 0x40000000 です。プロジェクトのリンカー ファイルを変更して、フラッシュ開始アドレス ( m_flash_start ) を 0x40000000 に設定する必要があります (参照: AN14589 の 7 ページ)。 3. FCB: ブートROMには、外部QSPIデバイスを正しく初期化するために、フラッシュメモリの先頭（通常はオフセット 0x400 ）に有効な512バイトの構成ブロックが必要です。このブロックが欠落しているか、破損しているか、使用している特定のフラッシュ チップと一致していない場合、ブート ROM はフラッシュとの通信に失敗します。詳細については、 https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#preparing-source-image-for-rt118x-devicesをご覧ください。 Re: Help Needed: Booting from FlexSPI2 QSPI Flash on RT1189 問題はないようです。 ブート ROM とブート シーケンスの詳細については、 https://www.nxp.com/docs/en/application-note/AN14589.pdfを参照してください。 デバイスが「スタック」している場合は、リセットしないでください。JLink/デバッガーを使用して実行中のカーネルに直接アタッチし、次のレジスタの状態を確認します。例: プログラムカウンタ（PC）： PC が 0x2xxxxxxx (ROM 領域) にある場合、ROM はまだ実行中であるか、無限ループに陥っています (たとえば、ペリフェラルの応答を待機している)。 PC が 0x002xxxxx (OCRAM) または別の RAM 領域を指している場合、ROM はジャンプを試みたものの、アプリケーションがクラッシュした可能性があります。 PC が 0x4000xxxx (FlexSPI2 AMBA 領域) を指していて、すべてゼロまたはバス エラーとして読み取られた場合、ジャンプは発生しましたが、XIP アクセスは失敗しました。

无法将 iMX93EVK 中的 lpuart1 更改为 lpuart7 在过去的一个多月里，我一直在尝试将默认控制台从 lpuart1 更改为 lpuart7。我想更改 linux 控制台和 u-boot 控制台，或者至少我想查看日志。这是为了让 iMX93EVk 的 SOC 在新的载体上工作。然而，我却无法做到这一点。这是我尝试使用的补丁。还有我发现的所有我认为可以帮助我的帖子。我错过了什么？ i-MX-93-91-使用yocto项目调试控制台重定位 i-MX-Processors/Change-UART-for-imx93-in-uboot-and-kernel i-MX 处理器/imx8ULP 将 u-boot 串行控制台从 UART5 更改为 UART4 非常感谢你们的帮助，谢谢 Linux Re: Cant change lpuart1 to lpuart7 in iMX93EVK 你好 要成功地将调试控制台从 lpuart1 更改为 lpuart7，你需要修改三个关键元器件：U-启动、Arm 可信固件和 Linux 内核配置。 完整解决方案： 1.对于 U-Boot（lf_v2024.04 分支）： - 修改设备树文件以更新控制台路径和引脚配置 - 更新板配置以指向 lpuart7 - 使用 imx93_11x11_evk_defconfig 作为配置基础 2. 对于 Arm 可信固件（lf_v2.10 分支）： - 更改 ATF 源中的 UART 控制台位置 - 更新 IMX_LPUART_BASE 以指向 lpuart7 的基址 - 在取消设置 LDFLAGS 后使用 "make plat=imx93" 构建 3. 对于 Linux 内核： -将 bootargs 更新为引用 ttylP6（对应于 lpuart7） -更新设备树中的选定部分 该过程需要使用这些修改后的元器件重建 flash.bin 映像。另一位客户需要将 i.MX93 上的 UART1 重新映射到 UART8，也成功解决了类似问题。 此致 Re: Cant change lpuart1 to lpuart7 in iMX93EVK 谢谢，我无法确认该解决方案是否有效。我已经执行了您的所有更改，但发现错误出在硬件本身。一旦定制载体修好了，一切都测试好了，我就可以确认了。 感谢您的回复

Zephyr：Booting DSP from MCU in Zephyr Hello, I am currently working on a project using the RT595 with the Zephyr RTOS, and I want to know how to start the DSP from the MCU. According to section 4.7 of the official documentation (IMXRT595-EVK-UG), by setting DSP_IMAGE_COPY_TO_RAM=1in the IDE, it is possible to achieve "program once, and the ARM core automatically wakes up the DSP". Now that the project has fully transitioned to the Zephyr build system, I would like to know the specific steps to launch the DSP application and how it should be configured. Thank you for your help. Evaluation Board Re: Zephyr：Booting DSP from MCU in Zephyr @jingqi  General Steps: To launch the DSP from the MCU in a Zephyr project, you should first build the DSP binary with Xtensa Xplorer, then integrate that binary into your Zephyr build via CMake, and finally call the  BOARD_DSP_Init()  function from your application to handle the startup sequence. You need to complete the functionality using the official documentation (MCUXpresso + EVK) and you need to have the ability to develop Zephry before you can complete the migration. Refernce: 1. Build the DSP Firmware: Getting Started with Xplorer for EVK- MIMXRT595 Typically, you will get two output files, such as dsp_text_release.bin and dsp_data_release.bin. These are the firmware images that the Cortex-M33 core will load into the DSP's RAM 2. Integrate the DSP Binary into the Zephyr Build:  the Zephyr build system requires you to explicitly include these binary files in your Cortex-M33 application. You can do this by modifying the CMakeLists.txt file for your Zephyr application. You may need to use Zephyr's build system features (like zephyr_file_copy or by defining them as a binary blob) to place the files in a known location in the final firmware image. 3. The MCUXpresso SDK for the i.MX RT595 provides a driver (  fsl_dsp.c  /  .h  ) to manage the DSP lifecycle. Zephyr for NXP devices includes this SDK, so you can call these functions directly from your Zephyr application code. Details can be found from '3.3 DSP Core Initialization' of Getting Started with Xplorer for EVK- MIMXRT595

串行下载器 - 奇怪的问题 我在 RT1052 上遇到了一个奇怪的问题，如果我将启动引脚配置为串行启动。 它无法启动固件，也不会进入串行下载器模式（既不是 UART 或非 USB）。 但当我将 GPIO_B0_15 下拉至 GND 时，串行下载正常工作。 我找不到任何关于这个信号对启动过程的影响的文档。 - 处理器出厂时是全新的 - TXD1/RXD1 有上拉电阻 顺便说一下：烧录 BT_FUSE_SEL 串行下载后可以正常工作 我们已经开发了几个类似的电路，以前从未遇到过这个问题。

S32K144:SimulinkでPWM生成にFlexIOピンを使用する方法はありますか 現在、SimulinkでPWM生成にFlexIOピンを使用する方法を理解しようとしています。Simulinkには、PWM生成にFlexIOピンを使用するためのブロックは見当たらず、I2C、SPI、およびUARTのみに使用されています。どんな助けでも大歓迎です。 Re:S32K144:SimulinkでPWM生成にFlexIOピンを使用する方法はありますか 教えて頂きありがとうございました

在 FRDM-IMX93 上使用 GPIO 如何使用 FRDM-IMX93 板上的 GPIO？像简单的 GPIO、CAN、I2c 等？ 谢谢 拉尔夫

PF5030はすべての出力が失われた状態でI2Cを読み取ります こんにちは。致命的なエラーが発生すると、入力電源は維持されますが、PF5030 のすべての出力が失われます。I2C 経由で詳細な障害情報を取得する方法はありますか? VDDIO は出力の 1 つから供給されます。この状況では、VDDIO が失われ、I2C インターフェースが機能しない可能性があります。しかし、致命的なエラーが発生した後に外部 VDDIO を提供するとどうなるでしょうか? エラー メッセージは保持されたままになりますか、それともすでに失われていますか?エラーが発生した後に外部 VDDIO を供給し、I2C 通信を試行することで、エラーの原因をCANますか? Re: PF5030 read I2C while all output lost こんにちは、ポニーさん 致命的なエラー (ウォッチドッグ障害、監視対象レールの過電圧、障害カウンタのオーバーフローなど) が発生すると、PF5030 は DEEP-FS 状態に移行します。 DEEP-FS では、すべてのレギュレータがオフになります。 フェイルセーフロジックはVINから内部的に電源供給されている I²C インターフェースはフェイルセーフ ドメインにあり、VDDIO (1.71 V ～ 5.25 V の範囲) が存在すると再び機能するようになります。 VIN が POR しきい値を上回っており、デバイスの電源がオフ/オンされていない限り、フェイルセーフ レジスタ (例: FS_GRL_FLAGS 、 FS_OVUVREG_STATUS1 、 FS_DIAG_SAFETY 、 FS_STATES ) には次の内容が含まれます。 どの電圧モニターがトリガーされたか（OV/UVフラグ） ウォッチドッグエラーフラグ 障害カウンターとステートマシンのステータス これらのレジスタはPORまたは明示的な書き込みによってのみクリアされ、DEEP-FSに入ることによってはクリアされません。 FS_GRL_FLAGS （一般的な障害の概要） FS_OVUVREG_STATUS1 （VMONがトリガー） FS_DIAG_SAFETY (ウォッチドッグ、CRC、BIST ステータス) FS_STATES （現在のフェイルセーフ状態） VIN が失われていない限り、VDDIO に外部電源を供給して致命的なエラーが発生した後に詳細な障害情報を回復 CAN。VIN が POR を下回ると、すべての揮発性レジスタがクリアされます。 敬具、 ヨゼフ

clrc663 lpcd i 和 q 值 i 得到 0x00 我正在使用 clrc663 作为读卡器我在那里实现了 lpcd 模式我在运行 lpcd 校准功能时遇到了问题我得到了 i 而且 q 值是 0x00 我从天线得到的是什么问题怎么解决这个问题 我使用的这个函数   /* 执行 LPCD 校准 */ phStatus_t Calibrate_LPCD(uint32_t dwLPCDDemo, uint32_t *pdwLPCDRefValue) { phStatus_t wStatus； uint8_t bValueI = 0； uint8_t bValueQ = 0； uint8_t bVersion = 0； uint8_t bDigitalFilter = PH_ON； uint16_t wDetectionOption = PHHAL_HW_RC663_FILTER_OPTION1； uint16_t wPowerDownTimeMs = LPCD_POWERDOWN_TIME； uint16_t wDetectionTimeUs = LPCD_FIELD_ON_DURATION； DEBUG_PRINTF("\nLPCD 校准开始。"); phhalHw_FieldOn(pHal)； phhalHw_Wait(pHal, PHHAL_HW_TIME_MILLISECONDS, 5)；   /* 配置 LPCD 模式默认值，以执行 LPCD 校准循环。 * 提供输入参考 I 和 Q 值为零，并将检测时间提供给 * 在此持续时间内打开射频，使用 I 和 Q 通道值测量负载变化。 * 配置合适的掉电时间以节省 RC663 读卡器IC 的功耗。*/ wStatus = phhalHw_Rc663_Cmd_Lpcd_SetConfig(pHal，PHHAL_HW_RC663_CMD_LPCD_MODE_DEFAULT、 bValueI、bValueQ、wPowerDownTimeMs、wDetectionTimeUs）； CHECK_STATUS(wStatus)； DEBUG_PRINTF("\nphhalHw_Rc663_Cmd_Lpcd_SetConfig.")； /* 读取版本寄存器，以区分 RC663 Old（RC66301、RC66302）和 RC663 Plus（RC66303）。*/ wStatus = phhalHw_Rc663_ReadRegister(pHal,PHHAL_HW_RC663_REG_VERSION,&bVersion)； DEBUG_PRINTF("\nphhalHw_Rc663_ReadRegister.")； CHECK_STATUS(wStatus)； 如果 (bVersion == PHHAL_HW_CLRC663PLUS_VERSION)     { /* 配置充电泵，使其具有较高的检测范围。 * 启用电荷泵会在检测阶段增加功率级 * 探测范围。这导致平均电流消耗增加。*/ wStatus = phhalHw_SetConfig(pHal,PHHAL_HW_RC663_CONFIG_LPCD_CHARGEPUMP,PH_ON)； CHECK_STATUS(wStatus)； DEBUG_PRINTF("\nphhalHw_SetConfig.")； /* 配置数字滤波器会触发信号 RC663 Plus 算法以获得倍数的平均值 * 检测 I 值和 Q 值的变化。这反过来又延长了射频开启时间 * 增加平均电流消耗。*/ wStatus = phhalHw_SetConfig(pHal，PHHAL_HW_RC663_CONFIG_LPCD_FILTER、 ((uint16_t)(bDigitalFilter)|wDetectionOption))； CHECK_STATUS(wStatus)；    }   /* 执行 LPCD 校准周期并获取 LPCD 参考 I 和 Q 值。*/ wStatus = phhalHw_Rc663_Cmd_Lpcd_GetConfig(pHal,&bValueI,&bValueQ)； DEBUG_PRINTF("\nphhalHw_Rc663_Cmd_Lpcd_GetConfig.")； CHECK_STATUS(wStatus)；   *pdwLPCDRefValue = ((bValueI) | (bValueQ<< 0x8))； DEBUG_PRINTF("\npdwLPCDRefValue.")；   DEBUG_PRINTF("\nLPCD 校准成功。");   返回 PH_ERR_SUCCESS； } 然后我在主 while 循环中调用 /* ------------------------------------------------------------------ * 开机后运行一次 LPCD 校准 * ------------------------------------------------------------------ */ phStatus_t LPCD_Calibrate(void) { phStatus_t status; uint32_t refVal; char dbg_buf[64]； // 确保在校准前开启 RF phhalHw_FieldOn(pHal)； phhalHw_Wait(pHal,PHHAL_HW_TIME_MILLISECONDS,5)； status = Calibrate_LPCD(LPCD_DEMO_MODE_DEFAULT，&refVal)； // 校准后关闭射频 phhalHw_FieldOff(pHal)； if (status == PH_ERR_SUCCESS) { gLpcdValueI = (uint8_t)(refVal& 0xFF); gLpcdValueQ = (uint8_t)((refVal 0xFF)); gLpcdValueQ = (uint8_t)((refVal 0xFF)).>> 😎 & 0xFF); gLpcdCalibrated = 1； sprintf(dbg_buf,"LPCD Calibration OK (I=0x%02X, Q=0x%02X)\r\n", gLpcdValueI, gLpcdValueQ)； DEBUG_UART2((unsigned char*)dbg_buf, strlen(dbg_buf)); } else { DEBUG_UART2((unsigned char*)"LPCD Calibration FAILED\r\n", 28); } return status; } 如果 (!lpcdCalibrated)     { 如果 (LPCD_Calibrate() == PH_ERR_SUCCESS) { lpcdCalibrated = 1; // 标记为已完成 DEBUG_UART2((unsigned char*)"LPCD Calibration OK\r\n", 23)；          } 不然 { DEBUG_UART2((unsigned char*)"LPCD Calibration FAILED\r\n", 28)；      }    } Re: clrc663 lpcd i and q value i getting 0x00   您好，先生， 非常感谢您与我们分享您的示意图。不过，我还是要问一下你们天线的史密斯图。我们确实有一份应用笔记，其中显示了使用廉价的纳米VNA进行这些测量的步骤。 Re: clrc663 lpcd i and q value i getting 0x00 我在这里附上我的硬件测试和原理图，在正常模式下，我得到的是 uid，这不是问题；在 lpcd 模式下，我得到的是 0x00,0x00 的 q 值。在此查看我的测试文件。 Re: clrc663 lpcd i and q value i getting 0x00 抱歉，但是对自定义板的支持非常有限。   要提供任何具体信息，我需要您的硬件，因为评估套件的天线设置配置与您的配置存在很大差异。   不过，您是否介意分享一下天线的史密斯图和原理图，这将是我们提供良好建议的一个很好的起点。   正如我在上一篇文章中提到的那样，我们建议从一开始就遵循一些步骤。其中之一是将我们的 EVK 与您的新天线和新的匹配电路一起使用。所有这些都显示在我们的许多文档中。请看 NFC天线设计|恩智浦半导体视频2。   发送 RF 开启命令后，I 和 Q 值应显示与 0x0 不同的值。 Re: clrc663 lpcd i and q value i getting 0x00 我使用的是带有 stm32 硬件的定制 PCB Clrc663，只有在软件中天线调谐是正确的，我使用了 nfcrdlibEx6_rc663_LPCD_Demo.c 库中的校准演示代码，但 i 和 q 值均为 0x00，然后我使用错误寄存器来确定我在其中出现了什么错误。 printf debug i getting === EEPROM / LPCD 检查开始 === VERSION(0x7F)=0x1A ERROR(before)=0x00 ERROR(after LOADREG)=0x80 > > > EEPROM 错误 (0x80) 仍然存在。LPCD 可能无法正确校准！ === EEPROM / LPCD 检查完成 === // 这是代码 phStatus_t Rc663_EepromInitAndCalibrateLPCD( phhalHw_Rc663_DataParams_t *pHal, uint32_t *pdwLPCDRefValue) { phStatus_t status; uint8_t bVersion, bIrq1, bErr； uint8_t bValueI = 0, bValueQ = 0; char dbg[64]; uint8_t eepromVal; uint8_t addr; sprintf(dbg,"\r\n=== EEPROM + LPCD Init ===\r\n"); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); /* 1.读取芯片版本 */ status = phhalHw_Rc663_ReadRegister(pHal, PHHAL_HW_RC663_REG_VERSION,&bVersion)； CHECK_STATUS(status); sprintf(dbg,"VERSION(0x7F)=0x%02X\r\n", bVersion); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); /* 2.清除任何现有错误 */ phhalHw_Rc663_ReadRegister(pHal, PHHAL_HW_RC663_REG_ERROR,&bErr); sprintf(dbg,"ERROR(before)=0x%02X\r\n", bErr); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); /* 3. 强制将 LOADREG 从 EEPROM 写入寄存器 */ status = phhalHw_Rc663_WriteRegister(pHal, PHHAL_HW_RC663_REG_COMMAND, PHHAL_HW_RC663_CMD_LOADREG)； CHECK_STATUS(status); /* EEPROM 加载稍有延迟 */ phhalHw_Wait(pHal, PHHAL_HW_TIME_MILLISECONDS, 5); /* 4.再次检查错误寄存器 */ phhalHw_Rc663_ReadRegister(pHal, PHHAL_HW_RC663_REG_ERROR,&bErr); sprintf(dbg,"ERROR(after LOADREG)=0x%02X\r\n", bErr)； DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); if (bErr& PHHAL_HW_RC663_BIT_EE_ERR) { sprintf(dbg,"> > > EEPROM 错误 (0x%02X) detected！\r\n" 、berR); DEBUG_UART2 ((uint8_t*) dbg、strlen (dbg)); /*---EEPROM 转储（前 16 个字节用于调试）---*/ for (addr = 0；addr < 0x10；addr++) { phalHW_rc663_cmd_reade2 (phAL，addr，1，& eePromade2) val); spr intf (dbg，" EEPROM [0x%02X] = 0x%02X\ r\n "，addr，eepromVal)；DEBUG_UART2 ((uint8_t*) dbg，strlen (dbg))；} /*---绕过 EEPROM 继续手动初始化---*/ sprintf (dbg，" 绕过 EEPROM，使用手动 RF 设置...\ r\n ")； DEBUG_UART2 ((uint8_t*) dbg、strlen (dbg))；phhalHW_rc663_WriteRegister（phal，PHHAL_HW_RC663_RC663_REGISTER，PHAL_HW_RC663_RC663_RC663_）； phalHW_RC663_WriteRegister REG_TXAMP，0x1F）；phhalHW_RC663_WriteRegister（phal，PHHAL_HW_RC663_REG_DRVCON，0x18）；} else {sprintf（dbg，" EEPROM LOADREG OK。 \ r\n "); DEBUG_UART2 ((uint8_t*) dbg，strlen (dbg));} /* 5. 清除 IRQ 标志 */ phHALHW_RC663_WriteRegister（phal、PHHAL_HW_RC663_REG_IRQ0、0x7F）；phalHW_RC663_WriteRegister（phal、PHHAL_HW_RC663_REG_IRQ1、0x7F）；/* 6。 启用校准模式 */ phHALHW_RC663_WriteRegister (phAL、PHHAL_HW_RC663_REG_LPCD_OPTIONS、0x02)；/* 7. 启动 LPCD_CALIBRATE（0x37 是隐藏的校准命令）*/ phhalHW_RC663_WriteRegister（ phal，PHHAL_HW_RC663_REG_COMMAND，0x37）；/* 8。 等待 LPCDIRQ */ 做 {phHalHW_rc663_readRegister ( phAL、PHHAL_HW_RC663_REG_IRQ1、& birQ1);} while (! (birQ1 & PHHAL_HW_RC663_BIT_LPCDIRQ)); /* 9. 读取 I/Q 结果 */ phHALHW_RC663_readRegister（phal、PHHAL_HW_RC663_REG_LPCD_RESULT_I、& bValueI）；phalHW_rc663_readRegister（phal、PHHAL_HW_RC663_REG_LPCD_RESULT_Q、& bValueQ）；/* 10。 存储 */ *pdwLPCDRefValue = (uint32_t)bValueI | ((uint32_t)bValueQ<< 8); sprintf(dbg,"[LPCD] 校准完成：I=0x%02X Q=0x%02X Ref=0x%08X\r\n", bValueI, bValueQ, *pdwLPCDRefValue); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); return PH_ERR_SUCCESS; } Re: clrc663 lpcd i and q value i getting 0x00 您好，先生， 为了校准 CLRC663 的 LPCD，我们强烈建议您使用NFC Cockpit。 这是一个图形用户界面工具，允许用户以图形方式对天线进行微调，同时进行LPCD 校准（第 4.5 节）。我们鼓励您使用这种方法，因为校准必须根据您自己的设计进行。没有任何手册可以按部就班地完成这一程序。 NFC Cockpit 允许用户在读写器卸载和加载时进行实时校准。 请探讨查看以下天线设计视频系列的第 4 段视频的可能性：NFC 天线设计 | 恩智浦半导体

GD3162 新しい回路図デザインで GD3162 ゲート ドライバを使用する予定です。NXP のサイトで短いデータシートを見つけました。完全なデータシートはありますか? Re: GD3162 この製品に関して要求されたドキュメントは管理リリース下にあり、NDA (秘密保持契約) に基づいてセキュア ファイル経由でアクセスできます。 アクセスをリクエストするには、こちらをクリックしてください: https://www.nxp.com/webapp-signup/docstoreReg  フォームの送信時に、有効な NDA のコピーをアップロードするよう求められることにご注意ください。NXPについてにまだNDAがない場合は、まずNDAのフォームにご記入ください。 https://www.nxp.com/webapp-signup/ndaReqForm NDA の準備ができたら、安全なファイルへのアクセスをリクエストできます。 プロセスを理解するには、以下のリンク/FAQを確認してください。 https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS https://www.nxp.com/support/support/secure-access-rights/secure-access-rights-faqs:SEC-ACCESS-FAQS

PEでファームウェアをダウンロードしながらD-Flashをフォーマットする方法 こんにちは、 私たちのプロジェクトでは、D-flash の消去に関する問題が発生しました。.elfをフラッシュするときまたは PE を使用して .S19 ファイルを作成した場合、D フラッシュはフラッシュ プロセス後も消去されず、残留値が保持されていることがわかりました。PE 経由でフラッシュするたびに、D フラッシュを消去します。さらに、このプロジェクトでは S32K314 チップを使用します。この理由は何でしょうか?ありがとう！ Re: How to format D-flash while downloading firmware with PE こんにちは@gumu 、 PE Micro デバッガーは NXP 製品ではありません。 S32DS IDE は、Eclipse ベースの Arm IDEs 用の GDB サーバー プラグインを統合しており、これは PE Micro 製品です。 https://www.pemicro.com/products/product_viewDetails.cfm?product_id=15320151 プラグインにはこのオプションがあります: PE Microのサポートに お問い合わせて、独自のアルゴリズムの詳細を入手してください。 ありがとうございました。 よろしくお願いいたします。 ダニエル

S32G3：热关机 嗨，团队 硬件：基于 S32G3。 读取 1 区温度（A-core）时。当温度达到 "64 摄氏度 "时，硬件将重新启动。 下面是 Linux 系统的信息。连续读取三个区域的温度值，问题发生时的值如下。 64350（0 区） 64350（1 区） 62850（2 区） kernel[435]：[ 7919.187233] thermalthermal_zone1: a53_cores：达到临界温度，正在关闭 内核[435]：[ 7919.187252] 重新启动：硬件保护关闭（温度过高） 在 Linux DTS 中配置的警戒温度为 80 度，临界温度为 100 度，尽管我们配置了 100 度，但在 64 度时仍可观察到重启。 Re: S32G3: Thermal Shutdown 你好，@yellapu_anishkh 感谢您的回复。 自 BSP39 以来，有几个与 TMU 相关的问题，其中一些已在 BSP40 中修复，而另一些已在以后的版本中修复，如果可能的话，我建议在 BSP42 上对其进行测试 BR 切宁 Re: S32G3: Thermal Shutdown 您好， 我看到了该驱动程序的一个提交 (c5697686c8d19ff1edbce015fa5562ba2a2065e6)。评论中提到了它，但 Jira ID (ALB-10663) 并不匹配。请您确认一次。 Re: S32G3: Thermal Shutdown 你好，@yellapu_anishkh 感谢您的回复。 我检查了源代码，建议尽可能在 BSP42（或更新版本）下对您的情况进行测试，因为从这个版本开始应用了一些错误修复，从现有信息来看，您提到的错误也得到了修复。 BR 切宁 Re: S32G3: Thermal Shutdown 您好， 在 BSP39 上可以观察到这种情况，BSP39 版本说明中提到了以下问题。 我查看了从 BSP39 到 BSP44 的版本说明，发现当前的错误尚未修复。能否请您确认一下，是否已经修复？ Re: S32G3: Thermal Shutdown 你好，@yellapu_anishkh 谢谢您的帖子。 我知道你可以在基于 S32G3 的定制板上对其进行测试，对吗？我能知道你在使用哪个版本的电路板支持包吗？一旦确认，我会首先检查内核代码。 BR 切宁

ADV7535：显示屏上无图像输出 嗨，团队、 我们正在基于 Verdin Yavia IMX8M Plus 的定制载板上开发 DSI 转 HDMI 变流器 ( ADV7535)。 我们已经替换了 ADV7535 而不是 LT8912B MIPI DSI 转 HDMI 桥接器 ，后者自带 Toradex 载板。我们使用 I2C 通道 2 与 ADV7535 DSI 转 HDMI 桥接器进行 通信，这与使用不同的 I2C 通道的 Yavia 载板不同。因此，我们对设备树进行了以下更新以反映这一变化： 设备树变更 1. verdin-imx8mp_dsi-to-hdmi_overlay.dts 删除现有 hdmi_lontium_lt8912 节点。 在 I2C2 节点下新增 hdmi_adv7535 节点。 2. imx8mp-verdin.dtsi 删除了 hdmi_lontium_lt8912 节点。 从 hdmi_connector 节点中删除了 Lontium 引脚连接细节。 已添加 hdmi_adv7535 作为 I2C2 下的子节点。   更改后的观察结果 成功读写 ADV7535 的内部寄存器。 能够转储 I2C 数据： torizon@verdin-imx8mp-15404184:~$ i2cdump -y -f 1 0x39 No size specified (using byte-data access) 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 14 00 00 00 00 00 00 00 00 00 41 0e bc 18 01 13 ?.........A????? 10: 25 37 00 00 00 00 38 00 46 62 04 a8 00 00 1c 84 %7....8.Fb??..?? 20: 1c bf 04 a8 1e 70 02 1e 00 00 04 a8 08 12 1b ac ?????p??..?????? 30: 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 b0 ...........?...? 40: 00 50 f0 76 10 68 68 68 68 00 80 00 00 00 00 00 .P?v?hhhh.?..... 50: 00 00 02 0d 6d 02 00 00 00 00 00 00 00 00 00 00 ..??m?.......... 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 70: 01 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ??.............. 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 90: 00 00 00 00 c0 00 40 00 03 02 e0 18 30 61 00 00 ....?.@.????0a.. a0: 00 00 a4 a4 08 04 00 00 00 00 00 40 00 00 40 14 ..????.....@..@? b0: 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 ..........?..... c0: 00 00 00 00 00 00 06 00 00 03 00 00 02 00 01 04 ......?..?..?.?? d0: 0c ff 80 80 80 00 00 00 00 00 00 00 00 00 88 01 ?.???.........?? e0: d0 70 01 00 00 00 fd 00 00 00 52 46 00 00 00 00 ?p?...?...RF.... f0: 95 04 ff 00 00 00 00 00 00 00 7d aa 1c 00 b0 00 ??........}??.?. 检测 HDMI 显示器，并在 i.MX8MP 上检索 EDID 数据。HDMI-A -1 是 DSI 转 HDMI 端口，HDMI-A-2 是原生 HDMI 端口。 root@verdin-imx8mp-15288064:/home/torizon# cat /sys/class/drm/card0-HDMI-A-1/edid | edid-decode edid-decode (hex): 00 ff ff ff ff ff ff 00 30 ae 86 10 01 01 01 01 22 15 01 03 80 29 1a 78 ee e5 b5 a3 55 49 99 27 13 50 54 af ef 00 61 40 81 c0 81 80 81 8a 81 90 95 00 95 0f 01 01 64 19 00 40 41 00 26 30 18 88 36 00 a0 1d 00 00 00 18 00 00 00 fc 00 4c 45 4e 20 4c 31 39 35 30 77 44 0a 20 00 00 00 fd 00 32 4c 1e 51 0e 00 0a 20 20 20 20 20 20 00 00 00 ff 00 42 33 34 33 32 38 34 35 0a 20 20 20 20 01 0b 02 03 21 71 4e 06 07 02 03 15 96 11 12 13 04 14 05 1f 90 23 09 07 07 83 01 00 00 65 03 0c 00 10 00 8c 0a d0 90 20 40 31 20 0c 40 55 00 b9 88 21 00 00 18 01 1d 80 18 71 1c 16 20 58 2c 25 00 b9 88 21 00 00 9e 01 1d 80 d0 72 1c 16 20 10 2c 25 80 b9 88 21 00 00 9e 01 1d 00 bc 52 d0 1e 20 b8 28 55 40 b9 88 21 00 00 1e 02 3a 80 d0 72 38 2d 40 10 2c 45 80 b9 88 21 00 00 1e 00 00 00 00 d0   遇到的问题 连接的 HDMI 显示器上没有图像输出 。 dmesg 日志错误：   imx_sec_dsim_drv 32e60000.mipi_dsi: failed to get pmsk for: fin = 12000, fout = 0   故障排除尝试 我们尝试修改设备树中的 MIPI DSI 控制器时钟设置，如下所示： mipi_dsi: mipi_dsi@32e60000 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,imx8mp-mipi-dsim"; reg = <0x32e60000 0x10000>; clocks = <&media_blk_ctrl IMX8MP_CLK_MEDIA_BLK_CTRL_MIPI_DSI_PCLK>, <&media_blk_ctrl IMX8MP_CLK_MEDIA_BLK_CTRL_MIPI_DSI_CLKREF>; clock-names = "cfg", "pll-ref"; assigned-clocks = <&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>; assigned-clock-parents = <&clk IMX8MP_CLK_24M>; assigned-clock-rates = <11000000>; interrupts = 18 IRQ_TYPE_LEVEL_HIGH>; power-domains = <&mipi_phy1_pd>; status = "disabled"; port@0 { dsim_from_lcdif: endpoint { remote-endpoint = <&lcdif_to_dsim>; }; }; }; 不过，在 dmesg 日志中，默认频率仍显示为 12 MHz 。   要求澄清 我们希望您能就以下几点提供指导： 如何正确更新 fin 和 fout 的值，以解决 pmsk 错误？ 要通过 ADV7535 实现正确的图像输出，是否需要对设备树进行任何其他更改？ 期待您的见解和建议。 请参阅随附的 dmesg 日志，该话题中的设备树叠加层。 谢谢& ， Rupesh Kathar imx8mplus#adv7535 #dsi #hdmi #mipi #i2c #i2s i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: ADV7535: No image output on display 如果您使用的是 5.15，只需将分支更改为 5.15，因为您的源代码是第三方公司的，我不清楚您的驱动程序如何，但请参考 nxp adv7535 驱动程序 linux-imx/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c at lf-5.15.y - nxp-imx/linux-imx - GitHub 并不是所有的分辨率都能支持，有效时钟如下，如果需要新时钟，必须在时钟驱动程序中添加新时钟。 静态常量 int valid_clocks[] = { 148500, 135000, 132000, 108000, 78750, 74250, 65000, 49500, 40000, 31500, }; Re: ADV7535: No image output on display 您好@joanxie, 感谢您对恩智浦内核源代码的指导。 我们已经使我们的设备树与恩智浦内核5.15y（不是你共享的6.12）的imx8mp-evk.dts保持一致，我们的显示器适用于某些分辨率，但不适用于我们的目标分辨率，即1024x768。 除了 adv7535 的设备树外，我们没有做任何其他更改。使用 Toradex 内核 5.15.2.x。 下面的表格列出了哪些方法有效，哪些方法无效。 分辨率 宽高比 标准 常见刷新率 Realtek 显示器 戴尔显示器 640×480 4:3 双向 60 赫兹 工作 工作 800×600 4:3 VESA 60-75 赫兹 工作 工作 1024×768 4:3 VESA 60-75 赫兹 空白/闪烁时 禁用 内部定时发生器 无输出 1280×768 5:3 VESA 60 赫兹 无输出 无输出 1280×720 16:9 双向 24/25/30/50/60 赫兹 工作 工作 1366×768 16:9 VESA 60 赫兹 无输出 无输出 1920×1080p 16:9 双向 24/25/30/50/60 赫兹 工作 工作 只有 1024x768 不工作的可能原因是什么？其他分辨率只需插入 HDMI 即可正常工作。 Re: ADV7535: No image output on display 我之前已经分享过 imx8mp dts 文件，首先，您需要在 dts 中正确设置该桥接器，然后 adv7535 驱动程序就会 https://github.com/nxp-imx/linux-imx/blob/lf-6.12.y/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c Re: ADV7535: No image output on display 嗨 @joanxie， FYR，我们正在使用类似于 Toradex 的 Yavia 载板的定制板。唯一的变化是用 ADV7535 取代了 lontium DSI 转 HDMI 适配器。我们选用 ADV7535，因为恩智浦也在其部分产品中使用该器件。 因此，我们在 Toradex 为 Yavia-WiFi dts 提供的设备树及其父设备树源的基础上进行了设备树修改。 问题中的设备树节点是 1。MIPI-DSI-这里没有修改任何内容（与之前的文章不同，改回了默认值）。其他恩智浦设备也必须使用它。 2。ADV7535 特定的节点和叠加层，我们在上一篇文章中提供了。 驱动程序为sec_mipi_dsim-imx.c，sec-dsim.c,adv7511_drv.c,adv7533.c. 现在，在调整了设备树叠加层之后。我们不再收到 fin、fout 错误。 以下是上述驱动程序的 dev_dbg 日志。 torizon@verdin-imx8mp-15404184:~$ dmesg | grep drm [ 0.000000] Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_defau lt=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/7b778d635701b4e0bbc49652c 421a587ae63ff3c6cbfc07d964084a23df7631d/0 [ 2.771129] imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops lcdifv3_crtc_ops) [ 2.771181] imx-drm display-subsystem: bound imx-lcdifv3-crtc.1 (ops lcdifv3_crtc_ops) [ 2.772099] imx-drm display-subsystem: bound 32e60000.mipi_dsi (ops imx_sec_dsim_ops [sec_mipi_dsim_imx]) [ 2.772141] imx-drm display-subsystem: bound 32fd8000.hdmi (ops dw_hdmi_imx_ops) [ 2.772468] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 0 [ 2.869610] imx-drm display-subsystem: [drm] fb0: imx-drmdrmfb frame buffer device [ 5.099098] systemd[1]: Starting Load Kernel Module drm... [ 5.188031] systemd[1]: [email protected]: Deactivated successfully. [ 5.188992] systemd[1]: Finished Load Kernel Module drm. [ 5.262319] [drm] Initialized vivante 1.0.0 20170808 for 40000000.mix_gpu_ml on minor 1 torizon@verdin-imx8mp-15404184:~$ dmesg | grep dsim [ 0.000000] Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_defau lt=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/7b778d635701b4e0bbc49652c 421a587ae63ff3c6cbfc07d964084a23df7631d/0 dy [ 2.759952] Kernel module loaded from ramdisk: sec_dsim - result: 0 [ 2.771246] imx_sec_dsim_drv 32e60000.mipi_dsi: sec-dsim bridge bind begin [ 2.771290] imx_sec_dsim_drv 32e60000.mipi_dsi: version number is 0x1060200 [ 2.772085] imx_sec_dsim_drv 32e60000.mipi_dsi: sec-dsim bridge bind end [ 2.772099] imx-drm display-subsystem: bound 32e60000.mipi_dsi (ops imx_sec_dsim_ops [sec_mipi_dsim_imx]) [ 2.916294] Kernel module loaded from ramdisk: sec_mipi_dsim_imx - result: 0 [ 3.259164] imx_sec_dsim_drv 32e60000.mipi_dsi: p: min = 1, max = 6, m: min = 88, max = 1023, s: min = 0, ma x = 5 [ 3.259252] imx_sec_dsim_drv 32e60000.mipi_dsi: fout = 390000, fin = 12000, m = 130, p = 1, s = 2, best_delt a = 0 [ 3.259262] imx_sec_dsim_drv 32e60000.mipi_dsi: no pre-exist hpar can be used [ 18.521539] imx_sec_dsim_drv 32e60000.mipi_dsi: p: min = 1, max = 6, m: min = 88, max = 1023, s: min = 0, ma x = 5 [ 18.521629] imx_sec_dsim_drv 32e60000.mipi_dsi: fout = 390000, fin = 12000, m = 130, p = 1, s = 2, best_delt a = 0 [ 18.521640] imx_sec_dsim_drv 32e60000.mipi_dsi: no pre-exist hpar can be used torizon@verdin-imx8mp-15404184:~$ dmesg | grep adv [ 0.000000] Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/7b778d635701b4e0bbc49652c421a587ae63ff3c6cbfc07d964084a23df7631d/0 [ 1.052362] adv7511 1-0039: Rev. 20 [ 4.325789] systemd[1]: System time before build time, advancing clock. torizon@verdin-imx8mp-15404184:~$ 有了它，我们还能通过使用 i2cset 直接在 ADV7535 上设置寄存器来生成测试色条图案，这意味着 ADV7535 至 HDMI Sink 显示器的工作正常。问题出在 iMX8MP 与 ADV7535 的通信方式上。 显示屏上仍然没有任何输出。 我们希望了解，恩智浦在其产品中实现 ADV7535 的方式与我们在软件和硬件方法上实现 ADV7535 的方式是否存在差异。 Re: ADV7535: No image output on display 看来这个错误信息是你自己的驱动程序造成的，我在 nxp 驱动程序源代码中没有找到这个信息，而且这个设置也不正确，你无法获得你想要的任何时钟，时钟父频是 24Mhz，如果你设置了 11Mhz，你只能获得 24/2=12Mhz 的时钟、 assigned-clock-parents = <&clk IMX8MP_CLK_24M>; assigned-clock-rates = <11000000>; 你可以参考恩智浦源代码作为参考，检查你关于 lcdif、mipi dsi 和 adv7535 的设置是否正确 linux-imx/arch/arm64/启动/dts/freescale/imx8mp-evk.dts 位于 lf-6.12.y · nxp-imx/linux-imx · GitHub linux-imx/arch/arm64/启动/dts/freescale/imx8mp.dtsi 位于 lf-6.12.y · nxp-imx/linux-imx · GitHub 参考日志，似乎 pll 设置不正确，pll 驱动程序在 linux-imx/drivers/gpu/drm/imx/sec_mipi_pll_1432x.h at lf-6.12.y - nxp-imx/linux-imx - GitHub 您可以仔细检查

S32K396s ブートラウダー S32K396sブートローダープロジェクトでは、ldファイルをどのように変更すればよいでしょうか？K396用のブートローダーの例はありますか？ Re: S32K396s bootlouder こんにちは、 1. S32K3シリーズ用統合ブートローダデモ NXP は、S32K396 を含む S32K3 ファミリをサポートする統合ブートローダ デモを提供しています。このデモには以下が含まれます: ブートローダーとアプリケーションプロジェクト フラッシュ・メモリ・コンフィグレーション 起動とアプリケーションへのジャンプロジック 公式投稿とダウンロード リンクは、こちらにあります: NXPコミュニティの統合ブートローダー デモ。 https://community.nxp.com/t5/S32K-Knowledge-Base/Unified-bootloader-Demo/ta-p/1423099 2. S32 Design Studio（S32DS）とRTD ブートローダの例を使用するには、次のものが必要です。 S32 Design Studio (S32DS) S32K3 リアルタイム ドライバ (RTD) パッケージ S32K396開発パッケージ これらは、S32DS の拡張機能と更新メニューからCANインストールできます。インストールしたら、次のようなサンプル テンプレートから新しいプロジェクトを作成 CAN。 ポート_例_S32K396 Bootloader_Example (RTD バージョンで利用可能な場合) セットアップの詳細については、S32K396-BGA-DC1のスタートガイドをご覧ください。 https://www.nxp.com/document/guide/getting-started-with-s32k396-bga-dc1-evaluation-board:GS-S32K396-BGA-DC1?section=get-software よろしくお願いいたします。 ピーター

i.MX93 RGMII connection PHY and MAC to MAC connection tips This article describe i.M93 RGMII to PHY connection, delay adding tips. i.MX93 don't support delay in both FEC and QOS port in i.MX93 side. It also provide solution on i.MX93 how to connect MAC to MAC in HW & SW. Thanks! 

MCUXpresso SDK：CI/CD 流水线 概述 在不断发展的嵌入式系统开发领域，支持自动化和高效的工作流程变得越来越重要。本文将探讨如何使用 GitHub Actions、Docker、MCUXpresso SDK 和 Visual Studio Code 为嵌入式项目量身打造一个强大的 CI/CD 管道。通过集成这些工具，开发人员可以自动构建、运行测试，并确保在不同团队和环境中一致地交付固件。 我们首先概述了 CI/CD 在嵌入式工作流程中的优势，包括更快的迭代周期、减少人为错误以及增强协作。接下来，我们深入探讨实际设置：使用 Docker 封装构建环境，利用 GitHub Actions 协调构建和测试，以及在 VS Code 中借助 MCUXpresso SDK 来管理和开发固件项目。真实案例和可重复使用的模板将引导读者创建一个可扩展、可维护且针对基于恩智浦的开发板进行了优化的管道。 无论您是希望实现工作流程现代化的嵌入式工程师，还是希望缩短交付时间的产品经理，本指南都将帮助您在开发生命周期中利用自动化的力量。 前提条件 MCUXpresso for VS Code MCUXpresso SDK 24.12 或更高版本 Git GitHub 帐户 Docker 目录 嵌入式工作流程中的 CI/CD 优势 容器 - Docker 自动化 - GitHub Actions 使用流水线 结束语 1. CI/CD 在嵌入式工作流中的优势 在嵌入式系统开发中实施持续集成和持续部署 (CI/CD) 具有变革性优势，尤其是在使用 MCUXpresso SDK 等复杂工具链和特定硬件限制时。以下是主要优势： 自动构建和测试 CI/CD 管道通过自动编译、链接和闪存流程，消除了手动构建步骤。这可确保每次代码更改都能在一致的构建环境中得到验证，从而降低人为错误的风险，节省宝贵的工程时间。 及早发现问题 通过将自动单元测试、静态分析和在环硬件 (HIL) 测试集成到管道中，开发者可以在错误和回归进入生产硬件前及早发现。这将使固件更加稳定，减少集成过程中的意外情况。 使用 Docker 实现一致的环境 使用 Docker 对构建环境进行容器化，可确保开发机器和 CI 运行程序之间的一致性。开发人员不再需要担心工具链版本不匹配或依赖项缺失的问题，一切都已定义并可重现。 改善协作和代码质量 CI/CD 鼓励频繁提交和拉取请求，这些请求会自动验证。这促进了团队成员间更好的协作，执行编码标准，并确保只有经过测试的代码被合并到主分支中。 更快的迭代和部署 借助自动化管道，固件更新可以快速构建、测试并部署到目标设备或暂存环境中。这加快了开发周期，实现了快速原型开发，尤其适用于敏捷或迭代开发模式。 可追溯性和可审计性 CI/CD 系统会记录每一次构建、测试结果和部署，从而提供清晰的更改历史记录。这对于在汽车或医疗设备等受监管行业中进行调试、确保合规性和维持高质量标准至关重要。 跨项目的可扩展性 管道一旦建立，就可以在多个嵌入式项目中重复使用或调整。这种可扩展性减少了新板或应用程序的设置时间，并促进了团队之间的最佳实践。 2. 容器 - Docker 什么是容器？ 容器是轻量级、可移植的软件单元，它将代码与其所有依赖项、库和配置文件组成一个代码包，因此可以在不同的计算环境中可靠地运行。 将容器视为一个独立的盒子，其中包含应用程序运行所需的一切。有几个平台可以用来容器化工作区。本指南将重点介绍 Docker。 Docker是什么？ Docker 是一个开源平台，它使开发人员能够在容器中构建、打包和运行应用程序。它简化了创建隔离环境的过程，该环境包括应用程序在不同系统上持续运行所需的代码、库、工具和设置等所有内容。 Docker 的核心是确保开发、测试和部署环境相同，无论您是在本地还是在云中工作，都能帮助解决“它在我的机器上运行”的问题。 使用 Docker 对 MCUXpresso SDK 和构建系统进行容器化的步骤 使用 Docker 对 MCUXpresso SDK 和构建系统进行容器化需要以下组件。 Dockerfile - 这是一个文本文件，其中定义了构建 Docker 镜像的步骤，例如安装软件包、复制文件和设置环境变量。 Docker 镜像 - 这是容器环境的快照。它由 Dockerfile 构建，用于创建容器。 Docker 容器 - Docker 镜像的运行实例。它具有隔离性、轻便性和便携性。 编写 dockerfile 1. 打开文本编辑器（例如 VS Code） 2. 创建一个新的文本文件。将其命名为 dockerfile。将此文件保存为 Docker 文件类型。 3. 创建用于容器化 MCUXpresso SDK 和构建系统的 dockerfile 时，必须指定所需的所有元器件。我们在下面提供了一个模板，你可以复制并粘贴到 dockerfile 中。 该模板的用途： - 使用 Ubuntu 22.04 作为容器的基础。这为构建和运行嵌入式工具提供了稳定的 Linux 环境。 - 防止安装期间出现交互式提示 - 安装使用 MCUXpresso SDK 所需的所有软件包（部分为可选软件包） 安装 ARM GNU 13.2 工具链 - 设置一个工作区，以便使用 West 克隆 MCUXpresso SDK - 配置工具链路径环境变量 # Use Ubuntu 22.04 as the base image FROM ubuntu:22.04 # Set environment variables for non-interactive installations ENV DEBIAN_FRONTEND=noninteractive # Install necessary packages /some optional RUN apt update && apt install -y \ curl \ wget \ ca-certificates \ xz-utils \ libncurses5 \ cmake \ ninja-build \ git \ python3 \ python3-pip \ build-essential \ device-tree-compiler \ unzip \ && rm -rf /var/lib/apt/lists/* # =========================================================================================================== # Notes on flags used: # (-LO) follows http redirects and saves the downloaded file with same name as in URL # (-k) ignores SSL certificate verification. This is needed when system security prevents certain actions # Contact IT to whitelist arm servers if needed. # ============================================================================================================ RUN curl -LO -k https://developer.arm.com/-/media/Files/downloads/gnu/13.2.rel1/binrel/arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz && \ tar xf arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz && \ rm arm-gnu-toolchain-13.2.rel1-x86_64-arm-none-eabi.tar.xz # Install additional Python packages RUN pip3 install --upgrade west imgtool requests # Set the workspace directory WORKDIR /workspace # Clone the mcuxsdk-manifests repository RUN git clone https://github.com/nxp-mcuxpresso/mcuxsdk-manifests.git # Set the MCUXpresso SDK path environment variable ENV MCUX_SDK_PATH=/workspace/mcuxsdk-manifests # Initialize and update the west workspace RUN cd $MCUX_SDK_PATH && \ west init -l . && \ west update # ARMGCC ENV variable ENV ARMGCC_DIR=/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi # Default command: Start a shell CMD ["/bin/bash"] 构建容器映像 在继续之前，建议设置一个 GitHub 存储库并配置凭据，以便在后续步骤中使用。 1. 创建一个新的存储库。暂时留空。稍后，它将包含以下项目： .github/workflows/docker-build.yml my_app dockerfile README.md 2. 生成个人访问令牌（PAT）。这将允许您访问 GitHub API。 - 点击“我的”图标 - 选择设置 > 开发者设置 > 个人访问令牌 > 令牌（经典版） - 选择“生成新令牌（经典）” - 范围可以根据您的需求自定义。请在本指南中使用以下范围：delete:packages、repo、write:packages - 点击“生成令牌”。生成令牌后，请务必复制并保存该令牌。 - 然后，将个人访问令牌 (PAT) 存储为 GitHub 密钥。GitHub 密钥将用于工作流文件中的身份验证。这样做是为了在不修改工作流文件的情况下提高可重用性、安全性和轮换性。 - 导航到已创建的存储库，然后单击“设置”。 - 选择密钥和变量，然后单击操作。 - 我们将在此处添加 2 个密钥。一个是用户名，另一个是个人访问令牌。点击“新建存储库密钥”。 用户名的密钥 - 这可以个性化定制。然而，在本指南稍后将介绍的工作流文件中，该变量设置为 GH_USERNAME。将名称设置为 GH_USERNAME。在 “密钥” 字段中输入您的 GitHub 用户名。 令牌的密钥 - 工作流已将变量设置为 GH_PAT。将名称设置为 GH_PAT。在 “密钥” 字段中粘贴您的个人访问令牌。 3. 现在我们可以通过命令行构建容器镜像。 - 克隆存储库的本地副本。打开该位置的命令行界面。 - 将 dockerfile 保存到克隆存储库的根目录下。 登录到 GitHub 容器注册表。运行： echo | docker login ghcr.io -u --password-stdin 输出： -构建容器镜像。这是本指南中最长的步骤，但只需构建一次镜像，就能将其推送到 ghcr 以供使用。运行： docker build -t . 输出： - 要验证您的镜像详细信息，请运行： docker images - 标记 Docker 镜像。此命令不会创建新镜像；它只为现有镜像提供新名称和标签。当你准备将镜像推送到像 GHCR 这样的注册表时尤其有用。Docker 要求在推送镜像前必须标记注册表 URL 和存储库名称。运行： docker tag - 将镜像推送到容器注册表。运行： docker push **注意：由于服务器错误，输出可能显示为失败。如果出现这种情况，只需再次运行该命令即可。 再次运行该命令： 恭喜！MCUXpresso SDK 和构建系统现已集成在容器镜像中，可以用于构建项目。接下来，我们将配置 GitHub 以实现自动化。 3. 自动化 - GitHub Actions 为什么要使用 GitHub Actions？ GitHub Actions 是 GitHub 内置的自动化工具，允许你定义工作流，根据推送或拉取请求等事件来构建、测试和部署代码。它使用 YAML 文件来配置这些工作流，从而可以直接在存储库中轻松设置 CI/CD 管道。 1. 在本地克隆您的存储库。然后导航到其根目录。 - 在项目根目录内创建 .github/workflows 目录。 - 导航至 VS 代码并创建一个新文件。将其命名为：docker-build.yml - 我们在下面提供了一个模板，您可以将其复制并粘贴到 docker-build.ymll 中。 该模板的用途： 在推送或 PR 时运行 使用包含 MCUXpresso SDK 工具的容器 检查您的存储库 将您的应用复制到 West 工作区 使用 West 为 FRDM-MCXA153 构建它 name: Build MCUXpresso Project on: push: # branches: [ main ] pull_request: jobs: build: runs-on: ubuntu-latest container: image: ghcr.io/nxp-jose/mcuxpresso-sdk:latest steps: - name: Checkout repository uses: actions/checkout@v3 - name: Copy my_app into west workspace run: | cp -r $GITHUB_WORKSPACE/my_app /workspace/mcuxsdk-manifests/my_app - name: Build project using west working-directory: /workspace/mcuxsdk-manifests run: | echo "Building project..." west build -b frdmmcxa153 my_app 4. 使用管道 完成您的工作区设置 该过程的最后一步是创建一个项目以用于我们的管道。 1. 打开适用于 VS Code 的 MCUXpresso 2. 点击“从存储库导入示例” 3. 从 MCUXpresso SDK 24.12 或更高版本导入一个项目，作为独立示例。将导入位置设置为克隆存储库的根目录。 4. 将更改暂存、提交并推送到您的存储库。现在，您的存储库中应该包含： *注意：如果在本地构建项目，您将看到 .vscode 目录。将此目录推送到存储库是完全可选的。 5. 推送完成后，在 GitHub 上启用工作流。启用工作流后。连续的推送或拉取请求将触发自动项目构建。 6. 检查构建细节。 - 导航至 GitHub 上的“操作”选项卡 - “操作”选项卡将显示工作流已运行的所有实例。 - 点击“构建”查看详细信息。 - 显示的详细信息是构建过程中执行的各个步骤。点击步骤以查看具体详情。 5. 结论 本指南中概述的 CI/CD 管道为使用 Docker、MCUXpresso SDK 和 GitHub Actions 自动构建提供了一个简单而有效的起点。虽然该示例以基本工作流为重点，但可对其进行广泛自定义，以满足项目的特定需求，例如集成自动测试、添加质量检查或使用自定义 MCUXpresso SDK 清单。利用这些工具，团队可以简化开发流程，确保一致性，并以最少的人工干预来扩展流程。 MCUXpresso SDK

フリースケール・カップ2015 EMEAチーム一覧 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 2014年11月17日現在、159チームがThe Freescale Cup 2015 EMEA に登録しています( 添付資料を参照) INNOVで始まるチーム名は、イノベーションチャレンジチームです フリースケール・カップ予選イベントが開催されていない国のチームは、選択した場所に自由に参加できます。Flavio Stiffanに連絡して、選択が記録されることを確認してください。