Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
标题:Murata Type 2FR EVK 上的 RW612 闪存编程验证失败,错误地址为 0x08400000 NXP社区的各位朋友,大家好! 我正在使用基于 NXP RW612 MCU 的 Murata Type 2FR (LBES0ZZ2FR-EVK) ,需要帮助解决闪存编程问题。 最初,我参考了 Murata Type 2FR Wi-Fi CLI 项目及其文档。我已成功构建并刷写了 Wi-Fi CLI 应用程序,并将设备连接到了 Wi-Fi 网络。之后,我尝试了 Wi-Fi MQTT 示例,该示例在同一块板上也成功运行。 然而,过了一段时间后,我突然无法将新的固件编程到设备中。 问题描述 我已尝试将不同的固件二进制文件刷入到各自的地址: 应用程序固件: 0x08000000 Wi-Fi固件版本: 0x08400000 蓝牙固件版本: 0x08540000 我还尝试重新刷写之前运行正常的 Wi-Fi CLI 和 Wi-Fi MQTT 项目,但问题仍然存在。 我可以通过 SEGGER J-Link 经由 SWD 连接到 RW612,并且可以读取现有的闪存内容。然而,在闪存验证过程中编程失败。该问题在不同的固件镜像中都会出现,并且不局限于某个项目或地址。 我偶然看到NXP社区一篇题为“如何解决FRDM-RW612的烧录问题(闪存锁定)”的文章,并尝试使用MCUXpresso安全配置工具按照建议的方法进行恢复。然而,我仍然无法解决问题。 我还尝试了使用 USB 和 UART 进行 ROM ISP 恢复的方法,但两种方法都失败了。使用 USB 方法时, blhost -- list-memory命令报告: 未找到指定的 USB HID 设备:0x1FC9、0x0020 该设备在 Windows 设备管理器中显示为 USB 串行端口 (COM16),但配置工具无法检测到预期的 USB HID 设备。 当前 J-Link 错误 我正在使用 J-Link Commander V8.44,并选择了 RW612 目标。调试器通过 SWD 成功连接到 Cortex-M33,目标电压约为 3.3 V。 当对地址为0x08400000 的Wi-Fi 固件二进制文件rw61x_sb_wifi_a2.bin进行编程时,出现以下错误: J-Link>loadfile "...\\rw61x_sb_wifi_a2.bin" 0x8400000 Downloading file [...] J-Link: Flash download: Bank 0 @ 0x08000000: 1 range affected (589824 bytes) J-Link: Flash download: Total: 4.538s J-Link: Flash download: Program speed: 249 KB/s ****** Error: Verification failed @ address 0x08400000 Error while programming flash: Verify failed. Unable to perform operation! Command failed with exit code 1 当我尝试对应用程序固件和其他以前可以正常运行的二进制文件进行编程时,都会出现同样的问题。 我需要哪些方面的帮助? 这可能是由于闪存写入锁定、网络安全配置、闪存保护或错误的闪存编程算法造成的吗? 使用 MCUXpresso Secure Provisioning Tool 是否有可靠的方法来恢复或解锁 Murata Type 2FR EVK 上的 RW612 闪存? FRDM-RW612 的闪存恢复程序可以安全地应用于 Murata Type 2FR EVK 吗?进入 ROM ISP 模式时,不同板之间是否存在板级差异? 既然调试器可以连接并读取闪存内容,但编程验证失败,接下来我应该检查什么? 有没有办法在不损坏现有板配置或永久禁用调试访问的情况下恢复闪存编程访问权限? 我希望能够获得详细的恢复步骤说明,特别是针对 MCUXpresso 安全配置工具和 ROM ISP 方法的说明。 该板之前使用 Wi-Fi CLI 和 Wi-Fi MQTT 示例都能正常工作。问题出现于之后,并非人为对硬件进行任何改动。 感谢您的帮助。 Re: Title: RW612 Flash Programming Verification Failed at 0x08400000 on Murata Type 2FR EVK 你好@sakshee ,希望你一切都好。 下面我将回答您的问题: 这可能是由于闪存写入锁定、网络安全配置、闪存保护或错误的闪存编程算法引起的吗? 当应用程序使用无效的闪存配置块 (FCB) 写入闪存时,就会发生闪存锁定,例如,当应用程序在构建时考虑了不同的外部闪存设备。以 Murata Type 2FR 为例,它包含与 FRDM-RW612 不同的闪存,因此每块板都需要不同的 FCB。请问是否已构建 FRDM-RW612 的应用程序版本并将其刷写到 2FR EVK 中? > 是否有可靠的方法可以使用 MCUXpresso Secure Provisioning Tool 恢复或解锁 Murata Type 2FR EVK 上的 RW612 闪存? 如果发生了上述情况并且闪存被锁定,则可靠的解锁方法如上述帖子中所述:如何解决 FRDM-RW612 的刷机问题(闪存锁定) ,但是,本指南重点介绍如何解锁 FRDM-RW612。为了将本指南应用于 Murata 的闪存,我建议按照以下一般步骤操作(参考安全配置工具和本文本身): 将板设置为ISP模式。 打开工作区,选择 RD-RW612-BGA 选项,以及“rdrw612bga_gpio_led_output_extfls.s19”;源可执行映像。 配置UART接口。 进入主工作区菜单后,请确保闪存配置与 EVK 的启动内存配置窗口中的闪存配置相匹配(请参见下图)。 请按指南其余部分的步骤操作。 > FRDM-RW612 的闪存恢复程序可以安全地应用于 Murata Type 2FR EVK 吗?进入 ROM ISP 模式时,不同板之间是否存在差异? 不,两块板的闪存各不相同,因此您必须考虑上一个答案中提到的步骤。另外,我建议您查看RW612 开发板的迁移指南,因为它提供了有关此主题和应用程序定制的具体注意事项。 既然调试器可以连接并读取闪存内容,但编程验证失败,接下来我应该检查什么? 请先核对上述步骤和信息,并将您的核对结果告知我。 > 是否有办法在不损坏现有板配置或永久禁用调试访问的情况下恢复闪存编程访问权限? 共享程序不应对您的电路板配置或调试访问端口造成任何损坏。 请告诉我这是否有帮助。
記事全体を表示
android_KK4.4.3_2.0.0-ga_core_source.tar.gz「どこでダウンロードできますか?コピーを送ってもらえますか? android_KK4.4.3_2.0.0-ga_core_source.tar.gz 「どこでダウンロードできる?もし誰かが私のメールにコピーを送っていただければ、とても感謝します。」 i.MX6 全て i.MX6DL i.MX6Dual i.MX6DualPlus | 6QuadPlus i.MX6Quad i.MX6S i.MX6SL i.MX6SoloX i.MX6UL SCM-i.MX6DQ Re: android_KK4.4.3_2.0.0-ga_core_source.tar.gz "Where can I download it? Could you please send こんにちは、 お元気でいらっしゃいますか?サポートチケットの作成を手伝っていただけますか?ファイルを共有できるように。 それ以外の場合には共有できません。 よろしくお願いいたします。 アルド。
記事全体を表示
タイトル: RW612 フラッシュプログラミング検証が、Murata Type 2FR EVK の 0x08400000 で失敗しました こんにちは、NXPコミュニティの皆さん、 私はNXP RW612 MCUをベースにしたMurata Type 2FR(LBES0ZZ2FR-EVK)を使っており、フラッシュプログラミングの問題を解決する助けが必要です。 最初は村田Type 2FR Wi-Fi CLIプロジェクトとそのドキュメントをフォローしていました。Wi-Fi CLIアプリケーションを無事に構築・フラッシュし、デバイスをWi-Fiネットワークに接続しました。その後、Wi-Fi MQTTのサンプルを試してみたところ、同じボード上で正常に動作しました。 しかし、しばらくすると、突然、デバイスに新しいファームウェアを書き込むことができなくなってしまった。 問題の説明 それぞれのファームウェアバイナリを、対応するアドレスに書き込んでみました。 アプリケーションファームウェア:0x08000000 Wi-Fiファームウェア: 0x08400000 Bluetoothファームウェア: 0x08540000 以前正常に動作していたWi-Fi CLIとWi-Fi MQTTプロジェクトを再フラッシュしてみましたが、問題は解決しませんでした。 SEGGER J-Linkを使ってSWD経由でRW612に接続でき、既存のフラッシュの内容も読み取れます。しかし、フラッシュ検証中にプログラミングが失敗する。この問題は様々なファームウェアイメージで発生し、特定のプロジェクトやアドレスに限定されるものではありません。 NXPコミュニティの「FRDM-RW612(フラッシュロック)のフラッシュ問題の解決方法」という記事を見つけ、MCUXpresso Secure Provisioning Toolを使って提案された回復方法を試しました。しかし、問題を解決できていません。 USBとUARTを使ったROM ISP復旧方法も試しましたが、どちらもうまくいきませんでした。USB方法を使うと、 blhost -- list-memory の報告: 指定されたUSB HIDデバイスが見つかりません: 0x1FC9、0x0020 デバイスはWindowsデバイスマネージャーでUSBシリアルポート(COM16)として表示されますが、プロビジョニングツールは期待されるUSB HIDデバイスを検出しません。 現在のJ-Linkエラー 私はRW612ターゲットを選択したJ-Link Commander V8.44を使用しています。デバッガはSWD経由でCortex-M33に接続し、目標電圧は約3.3Vです。 Wi-Fiファームウェアバイナリrw61x_sb_wifi_a2.binをアドレス0x08400000に書き込む際に、以下のエラーが発生します。 J-Link>loadfile "...\\rw61x_sb_wifi_a2.bin" 0x8400000 Downloading file [...] J-Link: Flash download: Bank 0 @ 0x08000000: 1 range affected (589824 bytes) J-Link: Flash download: Total: 4.538s J-Link: Flash download: Program speed: 249 KB/s ****** Error: Verification failed @ address 0x08400000 Error while programming flash: Verify failed. Unable to perform operation! Command failed with exit code 1 同じような一般的な問題は、アプリケーションのファームウェアや以前は動作していたバイナリをプログラムしようとすると発生します。 私が助けを必要としているのは これはフラッシュ書き込みロック、セキュリティ設定、フラッシュ保護、あるいは誤ったフラッシュプログラミングアルゴリズムが原因かもしれません。 MCUXpresso Secure Provisioning Toolを使用して、Murata Type 2FR EVKのRW612フラッシュを復元またはロック解除するための信頼できる手順はありますか? FRDM-RW612フラッシュリカバリー手順は村田タイプ2FR EVKに安全に適用できますか?ROM ISPモードに入る際、基板固有の違いはありますか? デバッガは接続してフラッシュの内容を読み取れるのに、プログラムが検証に失敗するので、次に何を確認すればいいのでしょうか? 既存のボード構成を壊さず、デバッグアクセスを永久に無効化せずにフラッシュプログラミングアクセスを復元する方法はありますか? 特にMCUXpressoセキュアプロビジョニングツールとROM ISP方法について、段階的な復旧手順を教えていただけるとありがたいです。 以前は、このボードはWi-Fi CLIとWi-Fi MQTTの両方のサンプルで正常に動作していました。問題は後になって発生したが、ハードウェアに意図的な変更は一切加えていない。 ご協力ありがとうございます。 Re: Title: RW612 Flash Programming Verification Failed at 0x08400000 on Murata Type 2FR EVK こんにちは、 @sakshee さん。お元気でお過ごしでしょうか。 ご質問にお答えします。 > これはフラッシュ書き込みロック、セキュリティ設定、フラッシュ保護、または誤ったフラッシュプログラミングアルゴリズムによって引き起こされる可能性はありますか? フラッシュロックは、アプリケーションが無効なフラッシュ構成ブロック(FCB)でフラッシュに書き込みられた場合、例えば異なる外部フラッシュデバイスを想定してアプリケーションが構築された場合に発生します。村田タイプ2FRの場合はFRDM-RW612とは異なるフラッシュを搭載しているため、各基板ごとに異なるFCBが必要です。FRDM-RW612のアプリケーションビルドが2FR EVKにビルドされ、フラッシュされたかどうか確認していただけますか? MCUXpresso Secure Provisioning Toolを使用して、Murata Type 2FR EVKのRW612フラッシュを復元またはロック解除するための信頼できる手順はありますか? 前述のケースでフラッシュがロックされている場合、信頼できる解除方法は前述の投稿「 FRDM-RW612(フラッシュロック)でのフラッシュ問題の解決方法」ですが、このガイドではFRDM-RW612の解除に焦点を当てています。このガイドを村田製作所製フラッシュメモリに適用するには、以下の一般的な手順に従うことをお勧めします(セキュアプロビジョニングツールとこの記事の両方を参照してください)。 ボードをISPモードに設定してください。 ワークスペースを開き、RD-RW612-BGAオプションと「rdrw612bga_gpio_led_output_extfls.s19」を選択します。ソース実行可能イメージ。 UARTインターフェースの設定をしてください。 メインワークスペースメニューに入ったら、ブートメモリ構成ウィンドウで、フラッシュ構成がEVKのフラッシュ構成と一致していることを確認してください(下の画像を参照)。 残りの手順はガイドの指示通りに行ってください。 >FRDM-RW612フラッシュリカバリー手順は村田タイプ2FR EVKに安全に適用できますか?ROM ISPモードに入る際に基板固有の違いはありますか? いいえ、両方のボードはそれぞれ異なるフラッシュメモリーを持っているので、前の回答で説明した手順を考慮する必要があります。また、 RW612開発ボードの移行ガイド も確認することをお勧めします。同じトピックやアプリケーションのカスタマイズに関する具体的な注意点が記載されています。 > デバッガは接続してフラッシュの内容を読み取れるのに、プログラミングが検証に失敗するので、次に何を確認すればいいでしょうか? まず、記載されている手順と情報をご確認いただき、その結果をお知らせください。 > 既存の基板構成を損傷したり、デバッグアクセスを永久に無効にしたりせずに、フラッシュプログラミングへのアクセスを復元する方法はありますか? 共有手順はボード構成やデバッグアクセスポートにダメージを与えることはありません。 これが役に立つかどうか教えてください。
記事全体を表示
S32G3 LLCE CAN Controller MIXED interrupt Hello  current configuration was interrupt Rx & Tx for all controllers  we need to use Mixed mode for one CAN Controller  we Selected mode to be mixed  Then one mail box to be using polling , check box activated  but after generation NXP_MCAL_GenData\swcd\Can_43_LLCE_Bswmd.arxml This file which will be imported to vector stack not been updated by read and write mian functions  its only been updated if the mode is polling . we need support to know why its not updated on mixed mode . Re: S32G3 LLCE CAN Controller MIXED interrupt Hi,MomenHALAWA Thank you for contacting us. Could you tell me which LLCE version are you using? I will help you to check it. Also, are you using the EB tresos for your application? What is the version of your EB tresos?  BR Joey Re: S32G3 LLCE CAN Controller MIXED interrupt LLCE Version :  EB Tresos 29.0.0 and for mcal only bsw from vector  Re: S32G3 LLCE CAN Controller MIXED interrupt Hi,MomenHALAWA Thank you for your reply and information. I checked arxml template file in the LLCE 1.0.10 project, the read and write main functions only will be used in the "POLLING" mode, but the mixed mode driver can be found in the code, it might be an issue with LLCE. I will help you in further confirming it internally. eclipse\plugins\Can_43_LLCE_TS_T40D11M10I10R0\generate_swcd\swcd\Can_43_LLCE_Bswmd.arxml Also, it will take some time for confirming it internally, for my personal suggestion, I think you can try to use the “POLLING” mode to generate the read and write main functions in the file of arxml, and use these functions in the arxml file by generating in the "MIXED" mode. Hope this information can help you. BR Joey
記事全体を表示
S32G3 LLCE CAN 控制器混合中断 你好 当前配置为中断所有控制器的接收和发送 (Rx & Tx)。 我们需要对一个CAN控制器使用混合模式。 我们选择了混合模式 然后,选中一个要使用轮询的邮箱复选框,该邮箱将启用轮询功能。 但是生成 NXP_MCAL_GenData\swcd\Can_43_LLCE_Bswmd.arxml 之后 该文件将被导入到向量堆栈中,但尚未通过读写主函数进行更新。 只有在轮询模式下才会更新。 我们需要技术支持,以了解为什么混合模式下它没有更新。 Re: S32G3 LLCE CAN Controller MIXED interrupt 你好, MomenHALAWA 感谢您与我们联系。 请问您使用的是哪个版本的LLCE?我会帮你检查一下。 另外,您的应用中使用的是 EB tresos 吗?你的EB Tresos是什么版本? BR 乔伊 Re: S32G3 LLCE CAN Controller MIXED interrupt LLCE 版本: EB Tresos 29.0.0 和仅适用于 mcal 的 bsw 来自 vector Re: S32G3 LLCE CAN Controller MIXED interrupt 你好, MomenHALAWA 感谢您的回复和提供的信息。 我检查了 LLCE 1.0.10 项目中的 arxml 模板文件,发现读写主函数仅在“轮询”模式下使用,但代码中却存在混合模式驱动程序,这可能是 LLCE 的问题。我会协助您在内部进一步确认。 eclipse\plugins\Can_43_LLCE_TS_T40D11M10I10R0\generate_swcd\swcd\Can_43_LLCE_Bswmd.arxml 另外,内部确认还需要一些时间。就我个人建议而言,我认为您可以尝试使用“轮询”模式在 arxml 文件中生成读取和写入主函数,然后通过在“混合”模式下生成来在 arxml 文件中使用这些函数。 希望这些信息对您有所帮助。 BR 乔伊
記事全体を表示
CLRD730 compatibility with 701 Hello, We have a customer with many CLRD 701 deployed. They would like to buy more. What is the chance to have their application working with the 730 without modifying the code ?  Thanks a lot and best regards. Re: CLRD730 compatibility with 701 Hello @fox13 , Hope you are doing great. Thank you for continuing to choose NXP products. Regarding your question, it should be possible to use the CLRD730 with your application. Please consider that the Pegoda CLRD730 desktop reader is designed to work with the default Windows CCID driver.  We also encourage you to review Section 6.8 "PC/SC mode" of the CLRD730 datasheet, which covers relevant information for your integration. Best Regards, Jaime.
記事全体を表示
CLRD730 与 701 的兼容性 你好, 我们有一位客户部署了许多 CLRD 701。他们还想买更多。不修改代码,他们的应用程序与730兼容的可能性有多大? 非常感谢,并致以最诚挚的问候。 Re: CLRD730 compatibility with 701 你好@fox13 , 希望你一切都好。 感谢您一直以来选择恩智浦产品。 关于您的问题,CLRD730 应该可以与您的应用程序一起使用。 请注意,Pegoda CLRD730 桌面读卡器设计用于默认的 Windows CCID 驱动程序。我们还建议您查阅 CLRD730 数据手册 的 6.8 节“ PC/SC 模式” ,其中包含与您的集成相关的必要信息。 此致, 杰米。
記事全体を表示
Example S32K311 SPI LinTrcv_fs23 MCAL S32DS3.6.11 RTD7.0.1 ***************************************************************************** *Detailed Description: *This is a basic communication example for LIN transceiver module of FS23 SBC with SPI interface. *The FS23 SBC on the S32K31XEVB-Q100 board integrated a LIN transceiver. To test LIN communication, another board or a LIN analyzer must be used. *In this example, the S32K311 configures and controls the FS23 via LPSPI0. *The FS23 LinTrcv driver is initialized by calling LinTrcv_43_fs23_Init(), while LinTrcv_43_fs23_SetOpMode() is used to change the operating mode of the integrated LIN transceiver. *After initialization is complete, the S32K3 transmits a LIN frame with ID 0x1A. *At this stage, the LIN frame should be received by the LIN analyzer connected to the J9 LIN bus interface on the S32K31XEVB-Q100 board. *LED Indications: Blue LED ON: LIN frame transmission in progress Blue LED OFF: LIN frame transmission completed Red LED flashes: LIN frame transmission timed out *---------------------------------------------------------------------------- *Test HW: * S32K31XEVB-Q100 Board SCH-55131 REV A1 P32K311HVS 0P98C * PCAN-USB Pro * PCAN-USB Pro | S32K31XEVB-Q100 ------------------------|-------------------- LIN LIN2.4 | J9.1 VBAT LIN2.9 | J9.2 GND LIN2.5 | J9.4 - S32K31XEVB-Q100 Jumper Configuration: J25 1-2 https://www.nxp.com/document/guide/getting-started-with-the-s32k31xevb-q100-evaluation-board-for-general-purpose:GS-S32K31XEVB-Q100?section=plug-it-in_plug-it-in-1 Test SW: *PLIN-View Pro *SDK: * S32K3_S32M27x Real-Time Drivers ASR R23-11 Version 7.0.1 (SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip) * 2.0.0 SBC FS23 R23-11 2.0.0 (SBC_FS23_R23-11_2.0.0_D2604_DesignStudio_updatesite.zip) *Debugger: S32DS 3.6.11, OpenSDA/ PEmicro Multilink Universal FX *Target: internal_FLASH *Reference Documentation: * AN14041 FS23 quick start guide (Rev. 2.0 23 January 2025) * AN14129 FS23 implementation and behaviors (Rev. 2.0 13 December 2024) * FS23, Safety System Basis Chip (SBC) with Power Management, CAN FD and LIN Transceivers Data Sheet (Rev. 8.0 30 June 2025) * RTD_SBC_FS23_UM.pdf C:\NXP\S32DS.3.6.11_S32K3_RTD701\S32DS\software\common\SBC_FS23\Sbc_fs23_TS_T40DXXM20I0R0\doc * RTD_LINTRCV_43_FS23_UM.pdf C:\NXP\S32DS.3.6.11_S32K3_RTD701\S32DS\software\common\SBC_FS23\LinTrcv_43_fs23_TS_T40DXXM20I0R0\doc * AUTOSAR_CP_SWS_LINDriver.pdf https://www.autosar.org/fileadmin/standards/R23-11/CP/AUTOSAR_CP_SWS_LINDriver.pdf * This example is migrated from LinTrcv_fs23_Example_S32K312. The method of migrating refers to the video "2.S32DS CT MCAL demo porting K344 to K312 based on RTD500": https://community.nxp.com/t5/S32K-Knowledge-Base/S32K3-Tools-Part-How-to-port-RTD-s-existing-MCAL-demo-to-other/ta-p/1966315 ***************************************************************************** * Revision History: * Ver Date Author Description of Changes * 0.0 10-14-2026 Robin Shen Initial version *****************************************************************************
記事全体を表示
[RTD701 MCAL] FRDM-A-S32K344 CAN <-> ETH Gateway Interrupt **************************************************************************** * Detailed Description: * * CAN <-> Ethernet gateway demo for FRDM-A-S32K344. * * CAN FD frames are encapsulated into raw Ethernet frames and * transmitted over the 100BASE-TX link. Received Ethernet frames * are decapsulated and forwarded to the CAN FD bus. * * Key Functionality: * - Interrupt-driven CAN FD reception via CanIf_RxIndication callback. * - Interrupt-driven Ethernet reception via EthIf_RxIndication callback * (EthCtrlEnableIngressQueueInterrupt, GMAC0_CH_RX_IRQHandler). * - GMAC TX confirmation interrupt processing (GMAC0_CH_TX_IRQHandler). * - Custom gateway format for CAN ID, DLC, flags and * payload (up to 64 bytes CAN FD) in a fixed 72-byte Ethernet payload. * - PHY CAN transceiver initialization. * - Ethernet PHY auto-detection and MDIO configuration via EthPhy driver. * - PHY initialization selectable at compile time: * PHY_INIT_BY_PIN_STRAPPING (default) * PHY_INIT_BY_SOFTWARE (MDIO register write) * * Main Loop Flow: * - CAN -> ETH : CanIf_bRxFlag set by ISR -> App_EthTransmit() * - ETH -> CAN : ethReceiveFlag set by ISR -> App_CanTransmit() * * Notes: * - Red LED set if Gateway_Init returns E_NOT_OK. * - Green LED toggles upon CAN reception. * - Blue LED toggles upon ETH reception. * - EthIf.c contains the custom EthIf_RxIndication gateway implementation. * - During S32 Configuration Tool code generation select "Keep Existing" * for EthIf.c to avoid overwriting the custom callback. * - Eth_43_GMAC_ReleaseRxBuffer() must be called unconditionally inside * EthIf_RxIndication. * * ------------------------------------------------------------------------- * Test HW : FRDM-A-S32K344 Rev A * MCU : S32K344_257BGA * IDE : S32DS 3.6.10 * RTD : S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206 * AUTOSAR : 4.9.0 * Debugger : P&E Micro * Target : Internal_FLASH * CAN : CAN FD, 500 Kbps nominal / 2 Mbps data, TJA1043 transceiver * Ethernet : RMII 100BASE-TX, DP83848 PHY **************************************************************************** ETH Reception with Wireshark:ETH Reception with Wireshark: CAN Reception with PCAN-USB.CAN Reception with PCAN-USB. Note 1: Inside project you can comment NODE_1 and define NODE_2 as 1 to enable simple routine which sends out a CAN frame if SW3 is pressed, and an ETH frame if SW2 is pressed. Note 2: For a real gateway application, use a queue or ring buffer instead of one global frame; otherwise, a second CAN frame can overwrite the first before Ethernet transmission completes. This example is for demostration purposes only.
記事全体を表示
MCXN947 DLL auto-adjusted function not working Hello, I'm using the MCXN947 via FlexSPI with an OctalRAM (IS66WVO32M8DALL-200BLI). The FlexSPI root clock is supplied at 150 MHz via PLL1, and since the RAM operates in DDR mode, I have an output clock rate of 75 MHz. The `flexspi_device_config_t` has the following parameters: flexspi_device_config_t psram_config = { .flexspiRootClk = 150000000U, .isSck2Enabled = false, .flashSize = OCTALRAM_ISSI_SIZE, .CSIntervalUnit = kFLEXSPI_CsIntervalUnit1SckCycle, .CSInterval = 2, .CSHoldTime = 2, .CSSetupTime = 2, .dataValidTime = 2, .columnspace = 4, .enableWordAddress = false, .AWRSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_WRITEDATA, .AWRSeqNumber = 1, .ARDSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_READDATA, .ARDSeqNumber = 1, .AHBWriteWaitUnit = kFLEXSPI_AhbWriteWaitUnit2AhbCycle, .AHBWriteWaitInterval = 0, .enableWriteMask = true, }; To initialize FlexSpi, I use the SDK FLEXSPI_DRIVER, version 2.6.0. When I configure the delay cells using the auto-adjusted function (as described in the manual under section 10.3.15.6, “DLL configuration for sampling”) with the following values: • SLVDLYTARGET=0x0F (divider 16/32 * root_clock = 3.33 ns) • REFPHASEGAP=0x02 • DLLEN=0x01 • OVRDEN=0x01 After waiting for the ASLVLOCK and AREFLOCK lock bits, I get 0x01 for ASLVSEL and 0x00 for AREFSEL. Consequently, the RAM's read and write functions do not work, since the set delay time is approximately 120 ps! /* Configure DLL. */ configValue = FLEXSPI_CalculateDll(base, config); base->DLLCR[index] = configValue; /* DLL neu kalibrieren */ base->DLLCR[0] |= FLEXSPI_DLLCR_DLLRESET_MASK; base->DLLCR[0] &= ~FLEXSPI_DLLCR_DLLRESET_MASK; /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Lock abwarten */ while ((base->STS2 & (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) != (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) { } SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); Even if I use different values for SLVDLYTARGET, the output of ASLVLOCK and AREFLOCK does not change. However, if I set the delay time to a fixed value using the registers OVRDEN=0x01 and OVRDVAL=0x1b (corresponding to a delay time of approximately 3.36 ns), reading from and writing to RAM works without any problems. However, since the root clock is greater than 100 MHz, NXP recommends using the DLL's auto-adjustment feature. Unfortunately, it doesn't seem to be able to determine the correct delay time! Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Core and Memory MCXN Re: MCXN947 DLL auto-adjusted function not working Hi @IbhDaniel  Thank you for the post! The MCXNx4 Reference Manual indicates that the serial root clock is the FlexSPI core clock (see Table 79. Clock Usage). In your case, this clock is configured to 150 MHz. I also see that you have implemented the DLL sampling configuration, and the auto-calibration path appears to be the correct approach. The settings SLVDLYTARGET = 0x0F and DLLEN = 0x01 were configured correctly. The only issue identified was OVRDEN = 0x01 instead of 0x00, which disables the auto-calibration output path and causes ASLVSEL = 0x01 and AREFSEL = 0x00 regardless of the SLVDLYTARGET value. I would just like to confirm that the above analysis applies to your implementation. Could you please verify that: MCR0[RXCLKSRC] = 3h (Flash-memory-provided read strobe and input from DQS pad) is being used in your configuration? Re: MCXN947 DLL auto-adjusted function not working Hi Carlos, Thanks for your reply. Sorry, that was a typo on my part, I set the OVRDEN bit to 0. In the screenshot of the MCU register, you can also see that OVRDEN was set to value 0. I’m using the OctalRam IS66WVO32M8DALL-200BLI, if I understand correctly, this module sends the DQS signal to the MCU. Re: MCXN947 DLL auto-adjusted function not working I checked it again, and the MCR0[RXCLKSRC] bit is set to 3h in the MCU. Re: MCXN947 DLL auto-adjusted function not working Hi @IbhDaniel, Could you please verify that MCR0[RXCLKSRC] = 3h (Flash-memory-provided read strobe input from the DQS pad) is being used in your configuration? This point is important because auto-adjustment/calibration is only supported when the DQS signal is sourced from the external DQS pad. If a different RXCLKSRC setting is selected, the automatic delay adjustment mechanism will not operate as expected. Re: MCXN947 DLL auto-adjusted function not working Hi @IbhDaniel  Thank you for the confirmation, I'll review this with the internal team. This may take some time. We appreciate your patience.  In the meanwhile, please use the workaround you find doing the manual calibration.  Apologize the inconvenience this may cause.  Re: MCXN947 DLL auto-adjusted function not working Hi @IbhDaniel, Could you please share your flexspi_config_t?  This to replicate the behavior you are facing.  Also, try adding SDK_DelayAtLeastUs of 10us after UpdateDllValue and after FLEXSPI_SetFlashConfig() BR Re: MCXN947 DLL auto-adjusted function not working Hi Carlos, Here is the information on the parameters I use with the `flexspi_config_t` structure: flexspi_config_t config; /* Get FLEXSPI default settings and configure the flexspi. */ FLEXSPI_GetDefaultConfig(&config); config.rxSampleClock = kFLEXSPI_ReadSampleClkExternalInputFromDqsPad; /*Set AHB buffer size for reading data through AHB bus. */ config.ahbConfig.enableAHBPrefetch = true; config.ahbConfig.enableAHBBufferable = true; config.ahbConfig.enableAHBCachable = true; config.ahbConfig.enableReadAddressOpt = true; for (uint8_t i = 1; i < FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1; i++) { config.ahbConfig.buffer[i].bufferSize = 0; } config.ahbConfig.buffer[0].masterIndex = 4; /* DMA0 */ config.ahbConfig.buffer[0].bufferSize = 512; /* Allocate 512B bytes for DMA0 */ config.ahbConfig.buffer[0].enablePrefetch = true; config.ahbConfig.buffer[0].priority = 0; /* All other masters use last buffer with 512B bytes. */ config.ahbConfig.buffer[FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1].bufferSize = 512; #if !(defined(FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) && FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) config.enableCombination = true; #endif FLEXSPI_Init(BUNNY_FLEXSPI, &config); And here is the code for the “SDK_DelayAtLeastUs” and “FLEXSPI_SetFlashConfig” functions: SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); /*! * @brief Delay at least for some time. * Please note that, if not uses DWT, this API will use while loop for delay, different run-time environments have * effect on the delay time. If precise delay is needed, please enable DWT delay. The two parmeters delayTime_us and * coreClock_Hz have limitation. For example, in the platform with 1GHz coreClock_Hz, the delayTime_us only supports * up to 4294967 in current code. If long time delay is needed, please implement a new delay function. * * @Param delayTime_us Delay time in unit of microsecond. * @Param coreClock_Hz Core clock frequency with Hz. */ void SDK_DelayAtLeastUs(uint32_t delayTime_us, uint32_t coreClock_Hz) { uint64_t count; if (delayTime_us > 0U) { count = USEC_TO_COUNT(delayTime_us, coreClock_Hz); assert(count <= UINT32_MAX); #if defined(SDK_DELAY_USE_DWT) && defined(DWT) /* Use DWT for better accuracy */ MSDK_EnableCpuCycleCounter(); /* Calculate the count ticks. */ count += MSDK_GetCpuCycleCount(); if (count > UINT32_MAX) { count -= UINT32_MAX; /* Wait for cyccnt overflow. */ while (count < MSDK_GetCpuCycleCount()) { } } /* Wait for cyccnt reach count value. */ while (count > MSDK_GetCpuCycleCount()) { } #else /* Divide value may be different in various environment to ensure delay is precise. * Every loop count includes three instructions, due to Cortex-M7 sometimes executes * two instructions in one period, through test here set divide 1.5. Other M cores use * divide 4. By the way, divide 1.5 or 4 could let the count lose precision, but it does * not matter because other instructions outside while loop is enough to fill the time. */ #if (__CORTEX_M == 7) count = count / 3U * 2U; #else count = count / 4U; #endif DelayLoop((uint32_t)count); #endif /* defined(SDK_DELAY_USE_DWT) && defined(DWT) */ } } /*! * brief Configures the connected device parameter. * * This function configures the connected device relevant parameters, such as the size, command, and so on. * The flash configuration value cannot have a default value. The user needs to configure it according to the * connected device. * * param base FLEXSPI peripheral base address. * param config Flash configuration parameters. * param port FLEXSPI Operation port. */ void FLEXSPI_SetFlashConfig(FLEXSPI_Type *base, flexspi_device_config_t *config, flexspi_port_t port) { uint32_t configValue = 0; uint8_t index = (uint8_t)port >> 1U; /* PortA with index 0, PortB with index 1. */ /* Wait for bus to be idle before changing flash configuration. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } /* Configure flash size and address shift. */ #if defined(FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) && (FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) base->FLSHCR0[port] = config->flashSize | FLEXSPI_FLSHCR0_ADDRSHIFT(config->addressShift); #else base->FLSHCR0[port] = config->flashSize; #endif /* FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT */ /* Configure flash parameters. */ base->FLSHCR1[port] = FLEXSPI_FLSHCR1_CSINTERVAL(config->CSInterval) | FLEXSPI_FLSHCR1_CSINTERVALUNIT(config->CSIntervalUnit) | FLEXSPI_FLSHCR1_TCSH(config->CSHoldTime) | FLEXSPI_FLSHCR1_TCSS(config->CSSetupTime) | FLEXSPI_FLSHCR1_CAS(config->columnspace) | FLEXSPI_FLSHCR1_WA(config->enableWordAddress); /* Configure AHB operation items. */ configValue = base->FLSHCR2[port]; configValue &= ~(FLEXSPI_FLSHCR2_AWRWAITUNIT_MASK | FLEXSPI_FLSHCR2_AWRWAIT_MASK | FLEXSPI_FLSHCR2_AWRSEQNUM_MASK | FLEXSPI_FLSHCR2_AWRSEQID_MASK | FLEXSPI_FLSHCR2_ARDSEQNUM_MASK | FLEXSPI_FLSHCR2_ARDSEQID_MASK); configValue |= FLEXSPI_FLSHCR2_AWRWAITUNIT(config->AHBWriteWaitUnit) | FLEXSPI_FLSHCR2_AWRWAIT(config->AHBWriteWaitInterval); if (config->AWRSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_AWRSEQID((uint32_t)config->AWRSeqIndex) | FLEXSPI_FLSHCR2_AWRSEQNUM((uint32_t)config->AWRSeqNumber - 1U); } if (config->ARDSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_ARDSEQID((uint32_t)config->ARDSeqIndex) | FLEXSPI_FLSHCR2_ARDSEQNUM((uint32_t)config->ARDSeqNumber - 1U); } base->FLSHCR2[port] = configValue; /* Configure DLL. */ FLEXSPI_UpdateDllValue(base, config, port); /* Step into stop mode. */ base->MCR0 |= FLEXSPI_MCR0_MDIS_MASK; /* Configure write mask. */ if (config->enableWriteMask) { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMOPT1_MASK; } else { base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMOPT1_MASK; } if (index == 0U) /*PortA*/ { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENA_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENA(config->enableWriteMask); } #if !((defined(FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) && (FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) else { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENB_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENB(config->enableWriteMask); } #endif /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Wait for bus to be idle before use it access to external flash. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } } Thank you very much for your great support! Best regards, Daniel
記事全体を表示
RT1064 オンラインアップグレードプラン 下記は、当製品のハードウェア拡張図です。 1. PCとメインボードはTCPで接続されています 2. メインボードは4つのサブボードに4つのSPIバスを介して接続されており、サブボードの機能は同じです 3. メインボードのUART4は、シリアルポートのスイッチを介して4つのサブボードのうちUART1に切り替えることができます foreverwlh2025_0-1789970732170.png プロジェクトの要件により、 PCは4つのサブボード(RT1064)からTCPまでのファームウェアプログラムをアップグレードする必要があります。ハードウェア拡張に基づいて、上位コンピュータ開発、メインボード開発、サブボード開発の作業負荷を考慮して、サブボードファームウェアのアップグレードに最も簡単な解決策を提供できますか? i.MXRT 106x Re: RT1064 Online Upgrade Plan @foreverwlh2025様、 ご質問ありがとうございます。 推奨されるアプローチ PCはTCPを介してマザーボードと通信します。マザーボードはTCPサーバーとして機能し、UART透過ブリッジを実装しています。メインボード上のUART4はシリアルスイッチチップを経由して選択したサブボードのUART1インターフェースにルーティングされます。サブボードはRT1064 ROMブートローダーを動作させるため、サブボード側で追加のブートローダーやファームウェア開発は不要です。 単一サブボードのアップグレード手順(ステップバイステップ): サブボードNでRESET信号をアサートし、BOOT_MODE[1:0]を01(シリアルダウンローダーモード)に設定する。 シリアルスイッチチップを切り替えてUART4をサブボードNのUART1に接続します リリースRESET — サブボードNがRT1064 ROMブートローダーに入り、UARTコマンドを待つ TCP↔UART4バイト転送を有効にする RESETを切り替えてBOOT_MODEを通常に戻すと、サブボードNが新しいファームウェアで起動します。 シリアルセレクタを次のサブボードに切り替えて繰り返します ハードウェアの前提条件 実装前に、以下のハードウェア条件が満たされていることをご確認ください。 メインボードは、各サブボードのBOOT_MODE[1:0]ピンを独立してGPIO制御できます。 メインボードは、各サブボードのRESETピンを個別にGPIO制御できます。 シリアルスイッチチップはメインボードのGPIOで制御可能で、4つのサブボードすべて間のスイッチングをサポートします ご質問や、導入の詳細についてさらに話し合いたい場合は、お気軽にご連絡ください。 Re: RT1064 Online Upgrade Plan @foreverwlh2025様、 ファームウェアのアップグレードに関するお客様のシナリオに対し、弊社が推奨するソリューションの概要を以下にご説明いたします。 1. PCツール PC側では blhost というオープンソースのコマンドラインクライアントを提供しており、NXPのMCUブートローダープライベートフレーミングプロトコル(BSD/MITライセンス)を実装しています。デバイス側プロトコルはMCUオンチップROMブートローダーによって実装されます。これら2つの機能により、ファームウェアのダウンロードとデバイスの設定が可能になります。 このツールはUSBとUART1に対応していますが、TCPには対応していません。 オープンソースリポジトリ: https://github.com/nxp-mcuxpresso/spsdk blhostとROMブートローダーは独自のフレーミングパケットプロトコルで通信します。ご参照ください: MCU Bootloader v2.5.0 リファレンス・マニュアル(MCUBOOTRM) ファームウェアイメージの生成およびパッケージングについては、NXPのSPSDK(Secure Provisioning SDK)に含まれるnxpimageツールをご利用ください。 2. 推奨ソリューション:マザーボード経由のTCP透過転送 あなたのシナリオ(PC→マザーボード→サブボード)の場合、最小限の手間で済む方法は、マザーボードを透過的なTCP-UARTブリッジとして機能させ、blhostを少し変更してシリアルデータをTCPでラップすることです。 建築: PC (modified blhost) ↓ TCP packet (include original UART byte stream) Main Board (TCP Server) ↓ Unpack and forward to sub-board via UART Sub-board (ROM Bootloader) 主な変更点: blhostトランスポート層の変更:blhostソースコードに新しいTCPトランスポートモジュールを追加します。既存のUARTバイトストリーム(フレーミングパケット)は、送信経路ではそのままTCPパケットにラップされ、受信経路ではアンラップされる。 メインボードはTCPサーバーを実装しています。PCからTCPデータを受信し、ペイロードをバイト単位でUART1経由でサブボードに転送します。サブボードからの応答は、同じ透過的な方法でTCP経由でPCに転送されます。 サブボードに変更は不要です。サブボードMCUは単にISPモードでROMブートローダーが動作し、標準UARTコマンドを待つだけで済みます。 Re: RT1064 Online Upgrade Plan 4. TCP↔UART4バイト転送を有効にする すみません、このデータ伝送のステップのために、追加の上位コンピュータを開発する必要があるのでしょうか?例えば、PCは画像データをどのような形式で送信すべきか、サブボードから返された応答データをどのように解析すべきか、そしてどのように相互作用すべきか、といった点です。 Re: RT1064 Online Upgrade Plan いくつか質問があります。 1. mcuXpressIDEから直接コンパイルしたbinのファームウェアは使えませんか?nxpimageを使わなければならないのですか? 2. サブボードのアップグレードを完了するには、MCUの起動モードを切り替え、自社の上位コンピュータソフトウェアでチャネルを切り替える必要があるようです。つまり、私たちは自分たちの上層コンピュータとblhostソフトウェアを同時に使わなければなりません。4つのサブ基板をアップグレードすると、頻繁に切り替えが少し面倒になることがあります 3. BLhostがサブボードと通信するには、まずマザーボードのTCPが透過モードに入る必要があります。操作が完了した後、マザーボードを透過モードからTCP受信モードに切り替え、サブボードが通常の起動モードに入るようにするにはどうすればよいのでしょうか 4. blhostのソースコードに新しいTCP送信モジュールを追加します - 例はありますか? 5. マザーボード上でシリアルポートの透過伝送を実現するための提案はありますか?例えば、DMAの使用や割り込みとブロッキングの実装など。 Re: RT1064 Online Upgrade Plan @foreverwlh2025様、 1. MCUXpresso IDEが直接生成したBINファイルは起動できません。nxpimage はMCUXpresso IDEで生成されたBINファイルを起動可能なイメージに変換します。 2. はい、ホストPCのソフトウェアを自分で修正する必要があります。この方法では、4つのサブボードは一度に1つずつしかアップグレードできません。 3. メインボードアプリケーションがこれを処理する必要があります。ファームウェアのアップグレードが完了した後、 メインボードは自らTCP受信モードに戻り、サブボードの起動モードを制御してQSIブートモードに切り替え、その後サブボードをリセットします。その後、サブボードは正常に起動します。 4. いいえ、これに関する例はありません。 5.特に推奨事項はありません。すべてのTCPデータを受信したら、UART経由でサブボードに送信します。UART送信にはポーリング方式の使用を推奨します。 よろしくお願いいたします。 シェリー Re: RT1064 Online Upgrade Plan @ShellyZhang様 前回取り上げられた問題について、CANお答えいただけますか?ありがとう!! 追伸:このプロジェクトのアップグレード計画は新しいもので、多くのサポートが必要になるかもしれません Re: RT1064 Online Upgrade Plan @foreverwlh2025様、 1.blhostがUART1経由でファームウェアをボードに書き込むと、ブートローダーは書き込まれたイメージの検証を完了した後、応答を返します。 あなたの用途では、PCがこの応答を監視し、メインボードにTCP受信モードに切り替えるよう指示できます。 2. 透過的な転送デバイスとして機能するのではなく、メインボードはサーバーとして機能し、MCUブートローダープロトコル(ホスト)をファームウェア内で直接実装できます。これにより、メインボードがファームウェアのアップグレードプロセスとサブボードとの通信を自ら管理できるようになります。 よろしくお願いいたします。 シェリー Re: RT1064 Online Upgrade Plan @ShellyZhangさんへ ファームウェアのアップグレードが完了すると、メインボードは自動的にTCP受信モードに戻るはずです 1. 透過送信モードでは、メインボードはサブボードのアップグレードが終了したことを検知できないのですよね? 2.このソリューションはデバイス側のコーディングは少ないようですが、ホスト側でやるべきことがたくさんあり、それらすべてをアップグレードすると操作がより複雑になります。他に解決策はありますか?
記事全体を表示
RT1064 在线升级计划 下图是我们产品的硬件扩展示意图: 1. PC 和主板通过 TCP 连接。 2.主板通过四条SPI总线与四个子板连接,各子板的功能相同。 3.主板上的UART4可以通过串口切换芯片切换到4个子板的UART1。 foreverwlh2025_0-1789970732170.png 由于项目需要, PC需要通过TCP升级四块RT1064子板的固件程序。基于硬件扩展情况,能否提供最简单的子板固件升级方案(考虑到上位机开发、主板开发和子板开发的工作量)? i.MX RT106x Re: RT1064 Online Upgrade Plan 亲爱的@foreverwlh2025 , 谢谢你的提问。 推荐方法 PC通过TCP协议与主板通信。主板充当 TCP 服务器,并实现 UART 透明桥接。主板上的 UART4 通过串行切换芯片路由到所选子板的 UART1 接口。子板运行 RT1064 ROM 引导加载程序,因此子板端不需要额外的引导加载程序或固件开发。 单个子板的逐步升级流程: 对子板 N 施加 RESET 信号;设置 BOOT_MODE[1:0] = 01(串行下载器模式) 将串口切换芯片切换为连接 UART4 和子板 N 的 UART1。 释放 RESET 按钮——子板 N 进入 RT1064 ROM 引导加载程序并等待 UART 命令。 启用 TCP↔UART4 字节转发 切换 RESET 开关并将 BOOT_MODE 恢复为正常模式——子板 N 将使用新固件启动。 将串行选择器切换到下一个子板并重复上述步骤。 硬件先决条件 请在实施前确认以下硬件条件已具备: 主板对每个子板的BOOT_MODE[1:0]引脚具有独立的 GPIO 控制。 主板对每个子板的RESET引脚具有独立的 GPIO 控制。 该串行切换芯片可通过主板GPIO控制,并支持在所有4个子板之间进行切换。 如有任何疑问或想进一步讨论实施细节,请随时联系我们。 Re: RT1064 Online Upgrade Plan 亲爱的@foreverwlh2025 , 以下是针对您的固件升级场景推荐的解决方案概要。 1. 电脑工具 在 PC 端,我们提供了blhost——一个开源的命令行客户端,它实现了 NXP 的 MCU 引导加载程序私有帧协议(BSD/MIT 许可证)。设备端协议由MCU片上ROM引导加载程序实现。它们共同实现了固件下载和设备配置。 该工具支持 USB 和 UART1,不支持 TCP。 开源仓库: https://github.com/nxp-mcuxpresso/spsdk blhost 和 ROM 引导加载程序使用专有的帧数据包协议进行通信,请参阅: MCU 引导加载程序 v2.5.0 参考手册 (MCUBOOTRM) 对于固件映像的生成和打包,请使用 NXP 的SPSDK(安全配置 SDK)中包含的nxpimage工具。 2. 推荐方案:通过主板实现 TCP 透明转发 对于你的场景(PC→主板→子板),最省力的方法是让主板充当透明的 TCP 到 UART 桥接器,只需对 blhost 进行少量修改,将串行数据封装在 TCP 中即可: 建筑学: PC (modified blhost) ↓ TCP packet (include original UART byte stream) Main Board (TCP Server) ↓ Unpack and forward to sub-board via UART Sub-board (ROM Bootloader) 关键修改点: 修改 blhost 传输层:在 blhost 源代码中添加一个新的 TCP 传输模块。现有的UART字节流(帧数据包)在发送路径上直接封装成TCP数据包,在接收路径上解封装。 主板实现了一个 TCP 服务器:从 PC 接收 TCP 数据,通过 UART1 将有效载荷逐字节地转发到子板;子板的响应以同样透明的方式通过 TCP 转发回 PC。 子板无需任何更改:子板 MCU 只需处于 ISP 模式,ROM 引导加载程序正在运行,等待标准 UART 命令即可。 Re: RT1064 Online Upgrade Plan 4.启用TCP↔UART4字节转发 -----请问,数据传输的这一步骤是否需要额外开发一台上位计算机?例如,PC应该以什么格式传输图像数据?它应该如何解析子板返回的响应数据?以及它应该如何与子板交互? Re: RT1064 Online Upgrade Plan 以下是一些问题: 1. 能否使用直接从 mcuXpressIDE 编译的 bin 固件?我必须使用 nxpimage 吗? 2. 看来要完成子板的升级,我们需要使用我们自己的上位机软件切换MCU的启动模式和切换通道。换句话说,我们必须将我们自己的上位机和 blhost 软件一起使用。如果我们升级四个子板,频繁切换可能会有点麻烦。 3. 主板 TCP 需要先进入透明模式,BLhost 才能与子板交互。交互完成后,如何触发主板从透明模式切换到TCP接收模式,从而使子板能够进入正常启动模式? 4. 在 blhost 源代码中添加一个新的 TCP 传输模块——您有示例吗? 5. 对于在主板上实现串口透明传输,是否有任何建议,例如使用DMA或实现中断和阻塞机制 Re: RT1064 Online Upgrade Plan 亲爱的@foreverwlh2025 , 1. MCUXpresso IDE 直接生成的 BIN 文件无法启动。nxpimage 可以将 MCUXpresso IDE 生成的 BIN 文件转换为可启动的镜像文件。 2. 是的,您需要自行修改主机软件。采用这种方法,四个子板一次只能升级一个。 3. 主板应用程序需要处理这个问题。固件升级完成后,主板应自动切换回 TCP 接收模式,控制子板的启动模式切换为 QSPI 启动模式,然后重置子板。子板随后将正常启动。 4. 不,我们没有这方面的例子。 5. 无具体建议。接收到所有 TCP 数据后,通过 UART 将其发送到子板。我们建议使用轮询方式进行 UART 传输。 顺祝商祺! 雪莉 Re: RT1064 Online Upgrade Plan 亲爱的@ShellyZhang 您能否对今天上次提出的问题作出回应?谢谢你!! PS:本项目升级计划是全新的,可能需要您的大力支持。 Re: RT1064 Online Upgrade Plan 亲爱的@ShellyZhang 固件升级完成后,主板应自动切换回 TCP 接收模式。 1.在透明传输模式下,主板无法检测到子板升级已经结束,对吗? 2.虽然这个方案在设备端的代码量似乎较少,但在主机端有很多事情要做,升级所有这些事情会使操作更加复杂。还有其他解决办法吗? Re: RT1064 Online Upgrade Plan 亲爱的@foreverwlh2025 , 1.blhost 通过 UART1 将固件编程到板子后,引导加载程序将在完成对已编程映像的验证后返回响应。 就您的使用场景而言,PC 可以监测此响应,然后命令主板切换到 TCP 接收模式。 2. 主板可以不作为透明转发设备,而是作为服务器,直接在其固件中实现 MCU Bootloader 协议(主机)。这样一来,主板就可以自行管理固件升级过程以及与子板的通信。 顺祝商祺! 雪莉
記事全体を表示
i.MX6ULL以太网接口在接头温度高于95℃时断开连接 您好,NXP, 我们使用 i.mx6ull 08AB 版本设计了我们的产品,并发现了一个如下所示的问题。 1>零件编号: MCIMX6Y2CVM08AB 2>问题: 当接头温度高于 95℃ 时,部分板会出现以太网断开连接的问题。 您有什么建议可以帮助我们解决这个问题吗? 非常感谢。 i.MX6UL Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ 您的客户中有多少家主板存在这个问题?他们测试的是哪个版本的BSP? Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ 测试1 相同条件:环境温度 65 摄氏度,6 个板处于空闲状态。 第一板:93.82摄氏度 第二块板:91.88摄氏度 板3:96.35摄氏度 第四块板:91.92摄氏度 第五块板:91.81摄氏度 第六块板:93.46摄氏度 测试 2 室温25摄氏度时: 3号板显示温度为65摄氏度,其他板都显示温度在60摄氏度左右。 测试 3 运行一些任务后,板 3 和板 6 失去了以太网连接(ENET1 使用外部 YT8512H PHY,ping 失败)。 当时,板 3 的温度为 99 摄氏度,板 6 的温度为 97.2 摄氏度。 ABA交叉验证 我们将 MCIMX6Y2CVM08AB 从热板 3 换到了另一块载板上。高温随芯片转移到了新的板上。 问题 为什么这款 MCIMX6Y2CVM08AB 在相同条件下读数比其他型号高出约 5°C? 当温度超过 97 摄氏度时,3 号和 6 号板出现以太网 ping 失败的情况,请问对此有什么建议吗?
記事全体を表示
LPCScrypt 无法在 Windows 11 25H2 上运行 [LPCScrypt版本2.1.3_83] 为了启动和刷新旧的 LPC1857,我们使用 lpcsCrypt 来更新设备固件。 自 Windows 11 25H2 起,LPCScrypt 就坏了:在命令行(即 PowerShell)上调用它会导致"错误:来自 CreateProcess 的错误:系统无法找到指定的文件" Sysinternal 的 Process 监测 假设 LpcsCrypt 正在使用 " wmic 路径 win32_pnPentity 执行 wmi 查询,其中(像 '%usbser%' 这样的服务,像 '%lpc%' 这样的名称)get.exe "。 但是,wmic 已于 2016 年宣布弃用,并已于 25H2 起从 Windows 11 中 移除 (请参阅 Windows Management Instrumentation Command-line (WMIC) removal from Windows - Microsoft Support) 。 请求恩智浦开发团队解决:这个问题是否已被发现?如何让它在未来发挥作用? Re: LPCScrypt not running on Windows 11 25H2 你好,ErichStyger,你说得没错。从 Windows 10 升级后,wmic 将保留在 Windows 11 中。 但我不得不重新安装 Windows 11 系统,结果遇到了这个问题。 Re: LPCScrypt not running on Windows 11 25H2 感谢您提供的信息。 我的解决办法是在 Windows 11 中添加 wmic 支持,具体如下 以管理员身份打开系统设置,进入可选功能(... 更多功能...)并添加 wmic 或使用" DISM/Online /Add-Capability /CapabilityName:WMIC" [请参阅将 WMIC 安装到 Windows 11 计算机 - Microsoft Q& A] 。 此致, 马蒂亚斯 Re: LPCScrypt not running on Windows 11 25H2 可能是因为我已经从 Win10 升级到了 Win11,我的机器上仍然有 WMIC: Re: LPCScrypt not running on Windows 11 25H2 我最近从 Win10 升级到了 Win11 25H2。 但到目前为止,我还没有看到 LPCScrypt 出现问题(尚未)。使用 LinkServer v25.9.134 中代码包的那个(见下文) 用 LPCScrypt 更新我的 LPC-Link2 运行正常。 我不是 WMIC 方面的专家,但根据信息,它在 25H2 中消失了,chatGTP 建议将旧版本 Windows 中的 wmic.exe 和 wmic.exe.mui 复制到 25H2。 恩智浦已经意识到了这个问题,下一个LinkServer版本中可能会有更新的LPCsCrypt。 Re: LPCScrypt not running on Windows 11 25H2 你好@mathiasmonse 感谢您的提问。 如果 WMIC 支持被移除,可以尝试安装。或者使用早期的 Windows 版本,或者在 Linux 或 macOS 上运行 LPCScrypt。 BR 爱丽丝 Re: LPCScrypt not running on Windows 11 25H2 这个问题已通过 LPCScrypt 2.1 解决,该版本似乎包含在 LinkServer 的最新版本中。
記事全体を表示
RT1064 Online Upgrade Plan The following figure is the hardware expansion diagram of our product: 1.The PC and mainboard are connected via TCP 2.The mainboard is connected to four subboards through four SPI buses, and the functions of the subboards are the same 3.The uart4 of the mainboard can be switched to UART1 of 4 sub boards through a serial port swtich chip foreverwlh2025_0-1789970732170.png Due to project requirements, the PC needs to upgrade the firmware program of four sub boards RT1064 through TCP. Based on hardware expansion, can you help provide the simplest solution for upgrading the sub board firmware (considering the workload of upper computer development, mainboard development, and sub board development) i.MXRT 106x Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , Thank you for your questions. Recommended Approach The PC communicates with the mainboard over TCP. The mainboard acts as a TCP server and implements a UART transparent bridge. UART4 on the mainboard is routed through a serial switch chip to the UART1 interface of the selected sub-board. The sub-board runs the RT1064 ROM Bootloader, so no additional bootloader or firmware development is required on the sub-board side. Step-by-step upgrade flow for a single sub-board : Assert RESET on sub-board N; set BOOT_MODE[1:0] = 01 (Serial Downloader mode) Switch the serial switch chip to connect UART4 to sub-board N's UART1 Release RESET — sub-board N enters the RT1064 ROM Bootloader and waits for UART commands Enable TCP↔UART4 byte forwarding Toggle RESET and restore BOOT_MODE to normal — sub-board N boots with the new firmware Switch the serial selector to the next sub-board and repeat Hardware Prerequisites Please confirm the following hardware conditions are in place before implementation: Mainboard has independent GPIO control over each sub-board's BOOT_MODE[1:0] pins Mainboard has independent GPIO control over each sub-board's RESET pin The serial switch chip is controllable by mainboard GPIO and supports switching among all 4 sub-boards Please feel free to reach out if you have any questions or would like to discuss implementation details further. Re: RT1064 Online Upgrade Plan 4.Enable TCP↔UART4 byte forwarding -----Excuse me, do we need to develop an additional upper computer for this step of data transmission? For example, what format should the PC transmit image data in, how should it parse the response data returned by the sub board, and how should it interact Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , Please find below a summary of our recommended solution for your firmware upgrade scenario. 1. PC Tool  On the PC side, we provides blhost — an open-source command-line client that implements NXP's MCU Bootloader private framing protocol (BSD/MIT license). The device-side protocol is implemented by the MCU on-chip ROM Bootloader. Together, they enable firmware download and device configuration.  The tool supports USB and UART1, doesn't support TCP. Open-source repository: https://github.com/nxp-mcuxpresso/spsdk blhost and the ROM Bootloader communicate using a proprietary framing packet protocol, please refer to: MCU Bootloader v2.5.0 Reference Manual (MCUBOOTRM) For firmware image generation and packaging, please use the nxpimage tool included in NXP's SPSDK (Secure Provisioning SDK). 2. Recommended Solution: TCP Transparent Forwarding via Mainboard For your scenario (PC→ Mainboard → Sub-board), the minimum-effort approach is to have the mainboard act as a transparent TCP-to-UART bridge, with a small modification to blhost to wrap serial data in TCP: Architecture: PC (modified blhost) ↓ TCP packet (include original UART byte stream) Main Board (TCP Server) ↓ Unpack and forward to sub-board via UART Sub-board (ROM Bootloader) Key modification points: Modify blhost transport layer: Add a new TCP transport module in the blhost source code. The existing UART byte stream (Framing Packets) is wrapped into TCP packets as-is on the send path, and unwrapped on the receive path.  Main board implements a TCP Server: Receives TCP data from the PC, forwards the payload byte-for-byte to the sub-board via UART1; sub-board responses are forwarded back to the PC via TCP in the same transparent manner. Sub-board requires no changes: The sub-board MCU simply needs to be in ISP mode with the ROM Bootloader running, waiting for standard UART commands. Re: RT1064 Online Upgrade Plan Here are a few questions: 1. Can't the bin firmware compiled directly from mcuXpressIDE be used? Do I have to use nxpimage? 2. It seems that to complete the upgrade of the sub board, we need to switch the MCU's startup mode and switch channel using our own upper computer software. In other words, we must use our own upper computer and blhost software together. If we upgrade four sub boards, frequent switching can be a bit troublesome 3. The motherboard TCP needs to enter transparent mode first in order for the BLhost to interact with the subboard. After the interaction is complete, how can the motherboard be triggered to switch from transparent mode to TCP receiving mode, so that the subboard can enter normal startup mode 4. Add a new TCP transmission module to the blhost source code - do you have an example 5. Is there any suggestion for implementing serial port transparent transmission on the motherboard, such as using DMA or implementing interrupt and blocking Re: RT1064 Online Upgrade Plan Dear  @ShellyZhang  Can you provide a response to the issue raised last time today? Thank you!! PS:The upgrade plan for this project is brand new and may require a lot of your support Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , 1. The BIN file generated directly by MCUXpresso IDE cannot boot.  nxpimage converts the BIN file generated by MCUXpresso IDE into a bootable image. 2. Yes, you need to modify your host PC software yourself. With this approach, the four sub -boards can only be upgraded one at a time. 3. The main-board application needs to handle this. After the firmware upgrade is completed, the main-board should switch back to TCP receive mode by itself, control the sub-board's boot mode to switch to QSPI boot mode, and then reset the sub-board. The sub-board will then boot normally. 4. No, we do not have an example for this. 5. No specific recommendation. After all the TCP data has been received, send it to the sub-board through UART. We recommend using a polling method for the UART transmission. Best Regards, Shelly Re: RT1064 Online Upgrade Plan Dear @foreverwlh2025 , 1. After blhost completes programming the firmware to the board via UART1, the bootloader will return a response after it finishes verification of the programmed image. For your use case, the PC can monitor this response and then command the main board to switch to the TCP received mode. 2. Instead of acting as a transparent forwarding device, the main board can function as a server and implement the MCU Bootloader protocol (host) directly in its firmware. This allows the main board to manage the firmware upgrade process and communication with the sub-boards itself. Best Regards, Shelly Re: RT1064 Online Upgrade Plan Dear @ShellyZhang  After the firmware upgrade is completed, the main-board should switch back to TCP receive mode by itself 1.In transparent transmission mode, the mainboard cannot detect that the sub board upgrade has ended, right? 2.It seems that this solution has some less coding on the device side, but there are many things to do on the host side, and upgrading all of them makes the operation more complicated. Is there any other solution?
記事全体を表示
LPCScrypt not running on Windows 11 25H2 [LPCScrypt version 2.1.3_83] For booting and flashing an old LPC1857 we use LPCScrypt for updating device firmware. Since Windows 11 25H2 LPCScrypt is broken: calling it on the command line (ie PowerShell) leads to "Error: Error from CreateProcess: The system cannot find the file specified" Sysinternal's Process Monitor leads to the assumption that LPCScrypt is performing a wmi query by using "wmic path Win32_PnPEntity where (service like '%usbser%' and name like '%lpc%') get.exe". But wmic is declared deprecated since 2016 and had been removed from Windows 11 since 25H2 (see Windows Management Instrumentation Command-line (WMIC) removal from Windows - Microsoft Support) Request to NXP dev team: Is this issue known yet? How to get it to work in the future? Re: LPCScrypt not running on Windows 11 25H2 Hi ErichStyger, you are right. By upgrading from Windows 10 wmic is kept in Windows 11. But I had to setup a fresh Windows 11 system and came accross that issue. Re: LPCScrypt not running on Windows 11 25H2 Thank you for the information. My workaround was to add wmic support to Windows 11 as follows open system settings as an administrator, go to optional features (...further features...) and add wmic  or by using "DISM /Online /Add-Capability /CapabilityName:WMIC" [see Install WMIC to a Windows 11 computer - Microsoft Q&A] Regards, Mathias Re: LPCScrypt not running on Windows 11 25H2 Probably because I have upgraded from Win10 to Win11, I still have WMIC on my machine: Re: LPCScrypt not running on Windows 11 25H2 I recently upgraded from Win10 to Win11 25H2. But so far, I have not seen an issue with LPCScrypt (yet). Using the one packaged with LinkServer v25.9.134 (see below) Updating my LPC-Link2 with LPCScrypt worked fine. Not an expert on WMIC, but according to the information it is gone in 25H2, chatGTP suggested to copy wmic.exe and wmic.exe.mui from an older Windows version to 25H2. NXP is aware of the issue, and there might be an updated LPCScrypt in a next LinkServer release. Re: LPCScrypt not running on Windows 11 25H2 Hello @mathiasmonse  Thanks for your question. If WMIC support is removed, yes, you can try to install it. Or  use an earlier Windows version or to run LPCScrypt on Linux or macOS. BR Alice Re: LPCScrypt not running on Windows 11 25H2 This has been resolved with LPCScrypt 2.1 which appears to be in the latest release of LinkServer.
記事全体を表示
i. MX6ULLのイーサネット切断は、接合温度が95°Cを超えると切断されます こんにちは、NXPさん、        弊社はi.mx6ull 08ABバージョンで製品を設計しましたが、以下の問題が見つかりました。 1>部品番号: MCIMX6Y2CVM08AB        2>質問: 接合温度が95°Cを超えると、一部の基板でイーサネット切断の問題が発生します。 この問題を解決するためのヒントはありますか? どうもありがとうございました。 i.MX6UL Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ お客様は何台のボードでこの問題を感じていますか?彼らはどのBSPバージョンをテストしたのですか? Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ テスト1 同じ条件:周囲温度65℃、ボード6枚がアイドル状態。 ボード1:93.82℃ ボード2:91.88℃ ボード3:96.35℃ ボード4:91.92 C ボード5:91.81 C ボード6:93.46℃ テスト2 室温25℃の場合: ボード3は65℃を示しており、その他はすべて60℃前後である。 テスト3 いくつかのタスクを実行した後、ボード3とボード6がイーサネット接続を失いました(ENET1は外部YT8512H PHYでping失敗)。 その時、3番ボードの温度は99℃、6番ボードの温度は97.2℃だった。 ABAクロスバリデーション ホットボード3からMCIMX6Y2CVM08ABを別のキャリアボードに交換しました。高温はチップから新しい基板に伝わりました。 質問 なぜこの特定のMCIMX6Y2CVM08ABは、同じ条件下で他のものよりも約5℃高い温度を示すのでしょうか? 温度が97°Cを超えるときに基板3と6で観察されるイーサネットpingの故障について何かアドバイスはありますか?
記事全体を表示
MCXN947 DLL 自动调整功能无法正常工作 你好, 我正在使用 FlexSPI 连接 MCXN947,并搭配 OctalRAM (IS66WVO32M8DALL-200BLI)。 FlexSPI 根时钟通过 PLL1 以 150 MHz 的频率提供,由于 RAM 以 DDR 模式运行,因此我的输出时钟频率为 75 MHz。 `flexspi_device_config_t` 具有以下参数: flexspi_device_config_t psram_config = { .flexspiRootClk = 150000000U, .isSck2Enabled = false, .flashSize = OCTALRAM_ISSI_SIZE, .CSIntervalUnit = kFLEXSPI_CsIntervalUnit1SckCycle, .CSInterval = 2, .CSHoldTime = 2, .CSSetupTime = 2, .dataValidTime = 2, .columnspace = 4, .enableWordAddress = false, .AWRSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_WRITEDATA, .AWRSeqNumber = 1, .ARDSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_READDATA, .ARDSeqNumber = 1, .AHBWriteWaitUnit = kFLEXSPI_AhbWriteWaitUnit2AhbCycle, .AHBWriteWaitInterval = 0, .enableWriteMask = true, }; 为了初始化 FlexSpi,我使用了 SDK FLEXSPI_DRIVER,版本 2.6.0。 当我使用自动调整功能(如手册第 10.3.15.6 节“采样 DLL 配置”中所述)配置延迟单元时,使用以下值: • SLVDLYTARGET=0x0F(分频器 16/32 * 根时钟 = 3.33 ns) • REFPHASEGAP=0x02 • DLLEN=0x01 • OVRDEN=0x01 在等待 ASLVLOCK 和 AREFLOCK 锁定位之后,我得到 ASLVSEL 为 0x01,AREFSEL 为 0x00。因此,RAM 的读取和写入功能无法工作,因为设置的延迟时间约为 120 ps! /* Configure DLL. */ configValue = FLEXSPI_CalculateDll(base, config); base->DLLCR[index] = configValue; /* DLL neu kalibrieren */ base->DLLCR[0] |= FLEXSPI_DLLCR_DLLRESET_MASK; base->DLLCR[0] &= ~FLEXSPI_DLLCR_DLLRESET_MASK; /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Lock abwarten */ while ((base->STS2 & (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) != (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) { } SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); 即使我使用不同的 SLVDLYTARGET 值,ASLVLOCK 和 AREFLOCK 的输出也不会改变。 但是,如果我使用寄存器 OVRDEN=0x01 和 OVRDVAL=0x1b 将延迟时间设置为固定值(对应于大约 3.36 ns 的延迟时间),则从 RAM 读取和写入数据都不会出现任何问题。 但是,由于根时钟大于 100 MHz,NXP 建议使用 DLL 的自动调整功能。 很遗憾,它似乎无法确定正确的延迟时间! 通信与控制(I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO) 核心与内存 MCX N Re: MCXN947 DLL auto-adjusted function not working 嗨@IbhDaniel 谢谢你的帖子! MCXNx4 参考手册指出,串行根时钟是 FlexSPI 内核时钟(见表 79)。时钟使用情况)。就你的情况而言,这个时钟配置为 150 MHz。 我还看到您已经实现了 DLL 采样配置,自动校准路径似乎是正确的方法。设置 SLVDLYTARGET = 0x0F 和 DLLEN = 0x01 配置正确。唯一发现的问题是 OVRDEN = 0x01 而不是 0x00,这会禁用自动校准输出路径,并导致 ASLVSEL = 0x01 和 AREFSEL = 0x00,而不管 SLVDLYTARGET 值如何。 我只想确认以上分析是否适用于您的实现。请您确认一下,您的配置中是否使用了以下设置:MCR0[RXCLKSRC] = 3h(闪存提供的读取选通信号和来自 DQS 焊盘的输入)? Re: MCXN947 DLL auto-adjusted function not working 嗨,卡洛斯, 谢谢你的回复。 抱歉,这是我的笔误,我把 OVRDEN 位设置为 0 了。在 MCU 寄存器的截图中,您也可以看到 OVRDEN 的值被设置为 0。 我正在使用 OctalRam IS66WVO32M8DALL-200BLI,如果我理解正确的话,这个模块会将 DQS 信号发送到 MCU。 Re: MCXN947 DLL auto-adjusted function not working 嗨@IbhDaniel , 请您确认一下,您的配置中是否使用了 MCR0[RXCLKSRC] = 3h(从 DQS 焊盘读取闪存提供的选通输入)? 这一点很重要,因为只有当 DQS 信号来自外部 DQS 垫时,才支持自动调整/校准。如果选择了不同的 RXCLKSRC 设置,则自动延迟调整机制将无法按预期运行。 Re: MCXN947 DLL auto-adjusted function not working 我再次检查了一下,MCU 中的 MCR0[RXCLKSRC] 位设置为 3h。 Re: MCXN947 DLL auto-adjusted function not working 嗨@IbhDaniel 感谢您的确认,我会和内部团队一起审核。这可能需要一些时间。感谢您的耐心等待。 在此期间,请使用您找到的手动校准变通方法。 由此造成的不便,我们深表歉意。 Re: MCXN947 DLL auto-adjusted function not working 嗨@IbhDaniel , 请问您能否分享一下您的 flexspi_config_t 文件? 这样做是为了重现你遇到的情况。 另外,尝试在 UpdateDllValue 之后和 FLEXSPI_SetFlashConfig() 之后添加 SDK_DelayAtLeastUs 为 10us。 BR Re: MCXN947 DLL auto-adjusted function not working 嗨,卡洛斯, 以下是我在 `flexspi_config_t` 结构中使用的参数信息: flexspi_config_t config; /* Get FLEXSPI default settings and configure the flexspi. */ FLEXSPI_GetDefaultConfig(&config); config.rxSampleClock = kFLEXSPI_ReadSampleClkExternalInputFromDqsPad; /*Set AHB buffer size for reading data through AHB bus. */ config.ahbConfig.enableAHBPrefetch = true; config.ahbConfig.enableAHBBufferable = true; config.ahbConfig.enableAHBCachable = true; config.ahbConfig.enableReadAddressOpt = true; for (uint8_t i = 1; i < FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1; i++) { config.ahbConfig.buffer[i].bufferSize = 0; } config.ahbConfig.buffer[0].masterIndex = 4; /* DMA0 */ config.ahbConfig.buffer[0].bufferSize = 512; /* Allocate 512B bytes for DMA0 */ config.ahbConfig.buffer[0].enablePrefetch = true; config.ahbConfig.buffer[0].priority = 0; /* All other masters use last buffer with 512B bytes. */ config.ahbConfig.buffer[FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1].bufferSize = 512; #if !(defined(FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) && FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) config.enableCombination = true; #endif FLEXSPI_Init(BUNNY_FLEXSPI, &config); 以下是“SDK_DelayAtLeastUs”和“FLEXSPI_SetFlashConfig”函数的代码: SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); /*! * @brief Delay at least for some time. * Please note that, if not uses DWT, this API will use while loop for delay, different run-time environments have * effect on the delay time. If precise delay is needed, please enable DWT delay. The two parmeters delayTime_us and * coreClock_Hz have limitation. For example, in the platform with 1GHz coreClock_Hz, the delayTime_us only supports * up to 4294967 in current code. If long time delay is needed, please implement a new delay function. * * @Param delayTime_us Delay time in unit of microsecond. * @Param coreClock_Hz Core clock frequency with Hz. */ void SDK_DelayAtLeastUs(uint32_t delayTime_us, uint32_t coreClock_Hz) { uint64_t count; if (delayTime_us > 0U) { count = USEC_TO_COUNT(delayTime_us, coreClock_Hz); assert(count <= UINT32_MAX); #if defined(SDK_DELAY_USE_DWT) && defined(DWT) /* Use DWT for better accuracy */ MSDK_EnableCpuCycleCounter(); /* Calculate the count ticks. */ count += MSDK_GetCpuCycleCount(); if (count > UINT32_MAX) { count -= UINT32_MAX; /* Wait for cyccnt overflow. */ while (count < MSDK_GetCpuCycleCount()) { } } /* Wait for cyccnt reach count value. */ while (count > MSDK_GetCpuCycleCount()) { } #else /* Divide value may be different in various environment to ensure delay is precise. * Every loop count includes three instructions, due to Cortex-M7 sometimes executes * two instructions in one period, through test here set divide 1.5. Other M cores use * divide 4. By the way, divide 1.5 or 4 could let the count lose precision, but it does * not matter because other instructions outside while loop is enough to fill the time. */ #if (__CORTEX_M == 7) count = count / 3U * 2U; #else count = count / 4U; #endif DelayLoop((uint32_t)count); #endif /* defined(SDK_DELAY_USE_DWT) && defined(DWT) */ } } /*! * brief Configures the connected device parameter. * * This function configures the connected device relevant parameters, such as the size, command, and so on. * The flash configuration value cannot have a default value. The user needs to configure it according to the * connected device. * * param base FLEXSPI peripheral base address. * param config Flash configuration parameters. * param port FLEXSPI Operation port. */ void FLEXSPI_SetFlashConfig(FLEXSPI_Type *base, flexspi_device_config_t *config, flexspi_port_t port) { uint32_t configValue = 0; uint8_t index = (uint8_t)port >> 1U; /* PortA with index 0, PortB with index 1. */ /* Wait for bus to be idle before changing flash configuration. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } /* Configure flash size and address shift. */ #if defined(FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) && (FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) base->FLSHCR0[port] = config->flashSize | FLEXSPI_FLSHCR0_ADDRSHIFT(config->addressShift); #else base->FLSHCR0[port] = config->flashSize; #endif /* FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT */ /* Configure flash parameters. */ base->FLSHCR1[port] = FLEXSPI_FLSHCR1_CSINTERVAL(config->CSInterval) | FLEXSPI_FLSHCR1_CSINTERVALUNIT(config->CSIntervalUnit) | FLEXSPI_FLSHCR1_TCSH(config->CSHoldTime) | FLEXSPI_FLSHCR1_TCSS(config->CSSetupTime) | FLEXSPI_FLSHCR1_CAS(config->columnspace) | FLEXSPI_FLSHCR1_WA(config->enableWordAddress); /* Configure AHB operation items. */ configValue = base->FLSHCR2[port]; configValue &= ~(FLEXSPI_FLSHCR2_AWRWAITUNIT_MASK | FLEXSPI_FLSHCR2_AWRWAIT_MASK | FLEXSPI_FLSHCR2_AWRSEQNUM_MASK | FLEXSPI_FLSHCR2_AWRSEQID_MASK | FLEXSPI_FLSHCR2_ARDSEQNUM_MASK | FLEXSPI_FLSHCR2_ARDSEQID_MASK); configValue |= FLEXSPI_FLSHCR2_AWRWAITUNIT(config->AHBWriteWaitUnit) | FLEXSPI_FLSHCR2_AWRWAIT(config->AHBWriteWaitInterval); if (config->AWRSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_AWRSEQID((uint32_t)config->AWRSeqIndex) | FLEXSPI_FLSHCR2_AWRSEQNUM((uint32_t)config->AWRSeqNumber - 1U); } if (config->ARDSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_ARDSEQID((uint32_t)config->ARDSeqIndex) | FLEXSPI_FLSHCR2_ARDSEQNUM((uint32_t)config->ARDSeqNumber - 1U); } base->FLSHCR2[port] = configValue; /* Configure DLL. */ FLEXSPI_UpdateDllValue(base, config, port); /* Step into stop mode. */ base->MCR0 |= FLEXSPI_MCR0_MDIS_MASK; /* Configure write mask. */ if (config->enableWriteMask) { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMOPT1_MASK; } else { base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMOPT1_MASK; } if (index == 0U) /*PortA*/ { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENA_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENA(config->enableWriteMask); } #if !((defined(FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) && (FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) else { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENB_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENB(config->enableWriteMask); } #endif /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Wait for bus to be idle before use it access to external flash. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } } 非常感谢您的大力支持! 顺祝商祺! 丹尼尔
記事全体を表示
MCXN947 DLLの自動調整機能が動作しません こんにちは、 私はFlexSPI経由でMCXN947とOctalRAM(IS66WVO32M8DALL-200BLI)を使用しています。 FlexSPIのルートクロックはPLL1を介して150MHzで供給され、RAMはDDRモードで動作するため、出力クロックレートは75MHzになります。 `flexspi_device_config_t`には以下のパラメータがあります。 flexspi_device_config_t psram_config = { .flexspiRootClk = 150000000U, .isSck2Enabled = false, .flashSize = OCTALRAM_ISSI_SIZE, .CSIntervalUnit = kFLEXSPI_CsIntervalUnit1SckCycle, .CSInterval = 2, .CSHoldTime = 2, .CSSetupTime = 2, .dataValidTime = 2, .columnspace = 4, .enableWordAddress = false, .AWRSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_WRITEDATA, .AWRSeqNumber = 1, .ARDSeqIndex = HYPERRAM_CMD_LUT_SEQ_IDX_READDATA, .ARDSeqNumber = 1, .AHBWriteWaitUnit = kFLEXSPI_AhbWriteWaitUnit2AhbCycle, .AHBWriteWaitInterval = 0, .enableWriteMask = true, }; FlexSpiの初期化には、SDK FLEXSPI_DRIVERバージョン2.6.0を使用しています。 自動調整機能(マニュアル10.3.15.6節「サンプリングのためのDLL構成」)でディレイセルを以下の値で設定すると、 • SLVDLYTARGET=0x0F(分算器16/32 * root_clock = 3.33 ns) • REFPHASEGAP=0x02 • DLLEN=0x01 • OVRDEN=0x01 ASLVLOCKとAREFLOCKのロックビットを待った後、ASLVSELには0x01、AREFSELには0x00が返されました。その結果、設定された遅延時間が約120psであるため、RAMの読み書き機能は動作しません。 /* Configure DLL. */ configValue = FLEXSPI_CalculateDll(base, config); base->DLLCR[index] = configValue; /* DLL neu kalibrieren */ base->DLLCR[0] |= FLEXSPI_DLLCR_DLLRESET_MASK; base->DLLCR[0] &= ~FLEXSPI_DLLCR_DLLRESET_MASK; /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Lock abwarten */ while ((base->STS2 & (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) != (FLEXSPI_STS2_AREFLOCK_MASK | FLEXSPI_STS2_ASLVLOCK_MASK)) { } SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); SLVDLYTARGETに異なる値を使用しても、ASLVLOCKとAREFLOCKの出力は変わりません。 しかし、レジスタOVRDEN=0x01とOVRDVAL=0x1bを使用して遅延時間を固定値(約3.36ナノ秒の遅延時間に相当)に設定すると、RAMからの読み書きは問題なく動作します。 しかし、ルートクロックが100 MHzを超えるため、NXPはDLLの自動調整機能の使用を推奨しています。 残念ながら、正しい遅延時間を判断できないようです! 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) コアとメモリ MCX N Re: MCXN947 DLL auto-adjusted function not working こんにちは、 @IbhDanielさん 投稿ありがとうございます! MCXNx4リファレンスマニュアルによると、シリアルルートクロックはFlexSPIコアクロックであることが示されています(表79参照)。時計の使用状況)。あなたの場合、このクロックは150 MHzに設定されています。 また、DLLサンプリング構成を実装しており、自動キャリブレーションパスが正しいアプローチのようです。設定値SLVDLYTARGET = 0x0FおよびDLLEN = 0x01は正しく構成されています。唯一特定された問題は、OVRDENが0x00ではなく0x01であり、これにより自動キャリブレーション出力経路が無効化され、SLVDLYTARGET値に関係なくASLVSEL=0x01、AREFSEL=0x00となります。 上記の分析結果が貴社の実装にも当てはまるかどうか確認させてください。以下を確認してください:MCR0[RXCLKSRC] = 3h(フラッシュメモリ提供の読み取りストロボとDQSパッドからの入力)があなたの構成で使用されているか? Re: MCXN947 DLL auto-adjusted function not working こんにちは、カルロスさん。 ご返信ありがとうございます。 すみません、誤字で、OVRDENビットを0に設定しました。MCUレジスタのスクリーンショットを見ると、OVRDENが値0に設定されているのもわかります。 私はOctalRam IS66WVO32M8DALL-200BLIを使っています。もし理解が正しければ、このモジュールはDQS信号をMCUに送っているようです。 Re: MCXN947 DLL auto-adjusted function not working 再度確認したところ、MCUのMCR0[RXCLKSRC]ビットは3時間に設定されています。 Re: MCXN947 DLL auto-adjusted function not working こんにちは、 @IbhDaniel さん。 あなたの構成でMCR0[RXCLKSRC] = 3h(DQSパッドからのフラッシュメモリ提供の読み取りストロボ入力)が使われているか確認していただけますか? この点は重要です。なぜなら、自動調整・キャリブレーションはDQS信号が外部DQSパッドから送信される場合にのみサポートされるからです。RXCLKSRCの設定が異なると、自動遅延調整機構は期待どおりに動作しません。 Re: MCXN947 DLL auto-adjusted function not working こんにちは、 @IbhDanielさん 確認ありがとうございます。社内チームと検討いたします。これには時間がかかる場合があります。ご理解とご協力に感謝いたします。 それまでの間は、手動キャリブレーションで見つけた回避策をご利用ください。 ご迷惑をおかけして申し訳ございません。 Re: MCXN947 DLL auto-adjusted function not working こんにちは@IbhDaniel。 flexspi_config_tを教えていただけますか? これは、あなたが直面している現象を再現するためのものです。 また、UpdateDllValue と FLEXSPI_SetFlashConfig() の後に SDK_DelayAtLeastUs を 10us 追加してみてください。 BR Re: MCXN947 DLL auto-adjusted function not working こんにちは、カルロスさん。 `flexspi_config_t`構造体で使用するパラメータに関する情報は以下のとおりです。 flexspi_config_t config; /* Get FLEXSPI default settings and configure the flexspi. */ FLEXSPI_GetDefaultConfig(&config); config.rxSampleClock = kFLEXSPI_ReadSampleClkExternalInputFromDqsPad; /*Set AHB buffer size for reading data through AHB bus. */ config.ahbConfig.enableAHBPrefetch = true; config.ahbConfig.enableAHBBufferable = true; config.ahbConfig.enableAHBCachable = true; config.ahbConfig.enableReadAddressOpt = true; for (uint8_t i = 1; i < FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1; i++) { config.ahbConfig.buffer[i].bufferSize = 0; } config.ahbConfig.buffer[0].masterIndex = 4; /* DMA0 */ config.ahbConfig.buffer[0].bufferSize = 512; /* Allocate 512B bytes for DMA0 */ config.ahbConfig.buffer[0].enablePrefetch = true; config.ahbConfig.buffer[0].priority = 0; /* All other masters use last buffer with 512B bytes. */ config.ahbConfig.buffer[FSL_FEATURE_FLEXSPI_AHB_BUFFER_COUNT - 1].bufferSize = 512; #if !(defined(FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) && FSL_FEATURE_FLEXSPI_HAS_NO_MCR0_COMBINATIONEN) config.enableCombination = true; #endif FLEXSPI_Init(BUNNY_FLEXSPI, &config); 以下は、「SDK_DelayAtLeastUs」関数と「FLEXSPI_SetFlashConfig」関数のコードです。 SDK_DelayAtLeastUs(10U, CLOCK_GetCoreSysClkFreq()); /*! * @brief Delay at least for some time. * Please note that, if not uses DWT, this API will use while loop for delay, different run-time environments have * effect on the delay time. If precise delay is needed, please enable DWT delay. The two parmeters delayTime_us and * coreClock_Hz have limitation. For example, in the platform with 1GHz coreClock_Hz, the delayTime_us only supports * up to 4294967 in current code. If long time delay is needed, please implement a new delay function. * * @Param delayTime_us Delay time in unit of microsecond. * @Param coreClock_Hz Core clock frequency with Hz. */ void SDK_DelayAtLeastUs(uint32_t delayTime_us, uint32_t coreClock_Hz) { uint64_t count; if (delayTime_us > 0U) { count = USEC_TO_COUNT(delayTime_us, coreClock_Hz); assert(count <= UINT32_MAX); #if defined(SDK_DELAY_USE_DWT) && defined(DWT) /* Use DWT for better accuracy */ MSDK_EnableCpuCycleCounter(); /* Calculate the count ticks. */ count += MSDK_GetCpuCycleCount(); if (count > UINT32_MAX) { count -= UINT32_MAX; /* Wait for cyccnt overflow. */ while (count < MSDK_GetCpuCycleCount()) { } } /* Wait for cyccnt reach count value. */ while (count > MSDK_GetCpuCycleCount()) { } #else /* Divide value may be different in various environment to ensure delay is precise. * Every loop count includes three instructions, due to Cortex-M7 sometimes executes * two instructions in one period, through test here set divide 1.5. Other M cores use * divide 4. By the way, divide 1.5 or 4 could let the count lose precision, but it does * not matter because other instructions outside while loop is enough to fill the time. */ #if (__CORTEX_M == 7) count = count / 3U * 2U; #else count = count / 4U; #endif DelayLoop((uint32_t)count); #endif /* defined(SDK_DELAY_USE_DWT) && defined(DWT) */ } } /*! * brief Configures the connected device parameter. * * This function configures the connected device relevant parameters, such as the size, command, and so on. * The flash configuration value cannot have a default value. The user needs to configure it according to the * connected device. * * param base FLEXSPI peripheral base address. * param config Flash configuration parameters. * param port FLEXSPI Operation port. */ void FLEXSPI_SetFlashConfig(FLEXSPI_Type *base, flexspi_device_config_t *config, flexspi_port_t port) { uint32_t configValue = 0; uint8_t index = (uint8_t)port >> 1U; /* PortA with index 0, PortB with index 1. */ /* Wait for bus to be idle before changing flash configuration. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } /* Configure flash size and address shift. */ #if defined(FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) && (FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT) base->FLSHCR0[port] = config->flashSize | FLEXSPI_FLSHCR0_ADDRSHIFT(config->addressShift); #else base->FLSHCR0[port] = config->flashSize; #endif /* FSL_FEATURE_FLEXSPI_SUPPORT_ADDRESS_SHIFT */ /* Configure flash parameters. */ base->FLSHCR1[port] = FLEXSPI_FLSHCR1_CSINTERVAL(config->CSInterval) | FLEXSPI_FLSHCR1_CSINTERVALUNIT(config->CSIntervalUnit) | FLEXSPI_FLSHCR1_TCSH(config->CSHoldTime) | FLEXSPI_FLSHCR1_TCSS(config->CSSetupTime) | FLEXSPI_FLSHCR1_CAS(config->columnspace) | FLEXSPI_FLSHCR1_WA(config->enableWordAddress); /* Configure AHB operation items. */ configValue = base->FLSHCR2[port]; configValue &= ~(FLEXSPI_FLSHCR2_AWRWAITUNIT_MASK | FLEXSPI_FLSHCR2_AWRWAIT_MASK | FLEXSPI_FLSHCR2_AWRSEQNUM_MASK | FLEXSPI_FLSHCR2_AWRSEQID_MASK | FLEXSPI_FLSHCR2_ARDSEQNUM_MASK | FLEXSPI_FLSHCR2_ARDSEQID_MASK); configValue |= FLEXSPI_FLSHCR2_AWRWAITUNIT(config->AHBWriteWaitUnit) | FLEXSPI_FLSHCR2_AWRWAIT(config->AHBWriteWaitInterval); if (config->AWRSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_AWRSEQID((uint32_t)config->AWRSeqIndex) | FLEXSPI_FLSHCR2_AWRSEQNUM((uint32_t)config->AWRSeqNumber - 1U); } if (config->ARDSeqNumber > 0U) { configValue |= FLEXSPI_FLSHCR2_ARDSEQID((uint32_t)config->ARDSeqIndex) | FLEXSPI_FLSHCR2_ARDSEQNUM((uint32_t)config->ARDSeqNumber - 1U); } base->FLSHCR2[port] = configValue; /* Configure DLL. */ FLEXSPI_UpdateDllValue(base, config, port); /* Step into stop mode. */ base->MCR0 |= FLEXSPI_MCR0_MDIS_MASK; /* Configure write mask. */ if (config->enableWriteMask) { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMOPT1_MASK; } else { base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMOPT1_MASK; } if (index == 0U) /*PortA*/ { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENA_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENA(config->enableWriteMask); } #if !((defined(FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) && (FSL_FEATURE_FLEXSPI_HAS_NO_FLSHCR4_WMENB)) else { base->FLSHCR4 &= ~FLEXSPI_FLSHCR4_WMENB_MASK; base->FLSHCR4 |= FLEXSPI_FLSHCR4_WMENB(config->enableWriteMask); } #endif /* Exit stop mode. */ base->MCR0 &= ~FLEXSPI_MCR0_MDIS_MASK; /* Wait for bus to be idle before use it access to external flash. */ while (!FLEXSPI_GetBusIdleStatus(base)) { } } サポートいただき、本当にありがとうございます! よろしくお願いいたします。 ダニエル
記事全体を表示
i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ Hi NXP,        We has designed our production with i.mx6ull 08AB version, and found a question shown below.        1>Part No.: MCIMX6Y2CVM08AB        2>Question:             When the joint temperature is higher than 95℃, some boards will occur the ethernet disconnection issue.         Do you have some tips for us to fix this problem ?         Thanks very much. i.MX6UL Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ how many boards do your customer find this issue? any what bsp version did they test?  Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ Test 1 Same condition: 65C ambient, 6 boards idle. Board 1: 93.82 C Board 2: 91.88 C Board 3: 96.35 C Board 4: 91.92 C Board 5: 91.81 C Board 6: 93.46 C Test 2 At 25C room temperature: Board 3 shows 65C, all others around 60C. Test 3 After running some tasks, Board 3 and Board 6 lost Ethernet connectivity (ENET1 with external YT8512H PHY, ping failed). At that moment, Board 3 temperature was 99C, Board 6 was 97.2C. ABA cross-validation We swapped the MCIMX6Y2CVM08AB from the hot Board 3 onto another carrier board. The high temperature followed the chip to the new board. Questions Why does this specific MCIMX6Y2CVM08AB read about 5C higher than others under identical conditions? Any suggestion for the Ethernet ping failure observed on Boards 3 and 6 when temperature rises above 97C?
記事全体を表示