Example SJA1110 FreeRTOS lwIP S32K3-T-BOX S32DS 3.5 RTD 1.0.2 ********************************************************************************* * Detailed Description: * Updated the example lwip_FreeRTOS_SJA1110 for board S32K3-T-BOX * to enable ping from the command window, from all applicable ports * *ping 192.168.0.200 * *Pinging 192.168.0.200 with 32 bytes of data: *Reply from 192.168.0.200: bytes=32 time=2ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.200: bytes=32 time=1ms TTL=255 * *Ping statistics for 192.168.0.200: * Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), *Approximate round trip times in milli-seconds: * Minimum = 1ms, Maximum = 2ms, Average = 1ms * * Installed packages to S32DS 3.5 update 14: * SW32SJA11xx_S32DS_3.5.0_RFP_D2206.zip * SJA11XX_RTD_4.4_1.0.1_P02_HF01_D2510_DesignStudio_updatesite.zip * SW32SJA1110_XJA11XX_ETH_PHY_4.4_1.0.8_CD01_D2509_DesignStudio_updatesite.zip * SJA11XX_ETH_SWITCH_4.4_1.0.2_CD01_D2509_DesignStudio_updatesite.zip * SW32SJA11xx_FreeRTOS_11.1.0_0.8.0_CD2_D2411_DesignStudio_updatesite.zip * SJA11XX_TCPIP_2.0.0_CD01_D2510_DesignStudio_updatesite.zip * * EVB: * - All jumpers in default positions * - to enable Lauterbach TRACE32: S1.1 OFF and S1.2 ON -> 0b01 - NVM Boot - SPI Flash * * Configuration: * - Updated switch configuration * - Updated phy configuration * - Fixed Mcu/McuModuleConfiguration/McuPowerControlUnit - 1V8 and 2V5 * - Fixed Eth configuration * * * * - TCPIP stack: enabled UDP_ECHO, etc. * - Added DIO * - Added nvm_metadata * - MAC learning is disabled * - All ports initialized & tested * - 100BASE-TX * - 100BASE-T1 5x * - SGMII4 - SABRE port tested with TJA1120-SDBS * - added to the PHY list * - pin strapping: PHYADDR 6, SGMII PHY, Master - Enabled - XTAL * * - Disable BC_DOMAIN and FL_DOMAIN between port 0 (SJA1110 internal M7) * and port 2 (S32K3). This avoids flooding S32K3 traffic to the * internal M7 port, which was observed to make the SJA1110 local TCP/IP * stack stop responding. * * main.c * - Updated only the header * device.c * - Added LED routines * test.c * - Removed code that shuts down the TCP/IP stack after its predefined timeout * - Added RX/TX blinking LED * - Added debug stuff * - Commented out the code that initializes 2nd switch * * ----------------------------------------------------------------------------- * Test HW: S32K3-T-BOX * MCU: SJA1110 * Debugger: Lauterbach TRACE32 * Target: RAM or external FLASH (flash_image.bin generated) * EVB connection: any port <-> Media converter TE-1402 (100M Leader or 1000M Follower) (where applicable) <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11

Ethernet Switch SJA1110 Examples S32G-VNP-RDB2 Note: S32G-VNP-RDB2 examples can be used also on S32G-VNP-RDB3. Example SJA1110 FreeRTOS lwIP S32G-VNP-RDB2 S32DS 3.5 RTD 1.0.2 SJA1110-MGS-EVM Example SJA1110 FreeRTOS lwIP SJA1110-MGS-EVM S32DS 3.5 RTD 1.0.2 MR-T1ETH8 Example SJA1110 FreeRTOS lwIP MR-T1ETH8 S32DS 3.5 RTD 1.0.2 SJA1110-EVM Example SJA1110 FreeRTOS lwIP SJA1110-EVM S32DS 3.5 RTD 1.0.2 S32K3-T-BOX Example SJA1110 FreeRTOS lwIP S32K3-T-BOX S32DS 3.5 RTD 1.0.2

Problems encountered during IDE and RTD installation Hello, I have installed S32DSIDE 3.6.6 software. Then I installed the RTD package. However, the SDK cannot be found when creating a new application project, as shown in the image below. This problem has been bothering me for a long time. I look forward to your reply. Thank you. My computer configuration is as follows: My computer has JDK 8 and JDK 17, and Python versions 13, 14, and 15 installed.   Re: 关于安装IDE和RTD遇到的问题 Thanks, I discovered this problem, and then I wanted to install gcc-10.2. I found a webpage about compilers. I didn't know which one to use, so I downloaded both of these EXE files to install. However, after installation, creating a new project in the S32DS software still did not show gcc-10.2. Then I tried to download it through the extension manager, but I kept getting errors and failing to download it successfully. Could you please guide me on what to do next? Thank you! Re: 关于安装IDE和RTD遇到的问题 Hello @YangLuYao, I've translated your query, so please let me know if there are any misunderstandings. Please try selecting NXP GCC 10.2 instead. S32K1 RTD does not support GCC 11.4 yet: Best regards, Julián Re: 关于安装IDE和RTD遇到的问题 I've solved the problem, thank you! Re: 关于安装IDE和RTD遇到的问题 Sorry, the past two days were the weekend, and this is the error message I reported this morning after trying to recreate the game. Re: 关于安装IDE和RTD遇到的问题 Hello @YangLuYao, Sorry for the late reply. From the image, it seems you are trying to install NXP GCC 6.3.1 (build 1620), you should actually install v10.2 (build 1728): If this still does not work, I guess you can try to install it externally: Installing software in S32 Design studio. Things I would check: Unstable network when installing. Proxy / Firewall at your workplace. Antivirus / Security checks. Disk space. Other than that, I'm not sure what could be the root cause. You could try re-installing S32DS and trying to install NXP GCC 10.2 again. Best regards, Julián

IDEおよびRTDのインストール中に発生した問題 こんにちは、S32DSIDE 3.6.6ソフトウェアをインストールしました。 次に、RTDパッケージをインストールしました。 しかし、下の画像に示すように、新しいアプリケーションプロジェクトを作成する際にSDKが見つかりません。 この問題は長い間私を悩ませてきました。ご回答をお待ちしております。ありがとうございます。私のコンピューターの構成は以下のとおりです。 私のコンピューターには、JDK 8とJDK 17、そしてPythonのバージョン13、14、15がインストールされています。   Re: 关于安装IDE和RTD遇到的问题 ありがとうございます。この問題に気付いた後、gcc-10.2をインストールしようと思いました。コンパイラに関するウェブページを見つけました。 どちらを使えばいいのか分からなかったので、両方のEXEファイルをダウンロードしてインストールしました。 しかし、インストール後、S32DSソフトウェアで新しいプロジェクトを作成しても、gcc-10.2は表示されませんでした。 その後、拡張機能マネージャーからダウンロードしようとしましたが、エラーが発生してダウンロードに失敗し続けました。次に何をすればよいか教えていただけますでしょうか？よろしくお願いいたします。 Re: 关于安装IDE和RTD遇到的问题 こんにちは、 @YangLuYao さん。 ご質問の内容を翻訳しましたので、誤解があればお知らせください。 代わりにNXP GCC 10.2を選択してみてください。S32K1 RTDはまだGCC 11.4をサポートし ていません : よろしくお願いします、 ジュリアン Re: 关于安装IDE和RTD遇到的问题 こんにちは@YangLuYaoさん スタンドアロンツールチェーンをダウンロードする必要はありません。S32DSは既にNXP GCC 10.2を提供しています。 ツールチェーンを選択し、「 1項目をインストール/更新」をクリックした後、「次へ」をクリックすると、S32DSが再起動を促します。再起動後、インストールされていることが確認できるはずです。 もし誤りがあれば教えてもらえますか? よろしくお願いします、 ジュリアン Re: 关于安装IDE和RTD遇到的问题 問題を解決できました。ありがとうございました！ Re: 关于安装IDE和RTD遇到的问题 申し訳ありませんが、ここ2日間は週末だったため、今朝ゲームを再現しようとした際に報告したエラーメッセージはこれです。 Re: 关于安装IDE和RTD遇到的问题 こんにちは、 @YangLuYao さん。 返信が遅くなり申し訳ありません。画像から判断すると、NXP GCC 6.3.1 (ビルド 1620) をインストールしようとしているようですが、実際には v10.2 (ビルド 1728) をインストールする必要があります。 それでも動かなければ、外部インストールを試してみるのも良いかもしれません:S32 Design Studioにソフトウェアをインストールする。 私が確認する項目： インストール時にネットワークが不安定になる。 職場におけるプロキシ／ファイアウォール。 ウイルス対策やセキュリティチェック。 ディスク容量。 それ以外に根本的な原因はわかりません。S32DSを再インストールして、NXP GCC 10.2を再度インストールしてみるのも手です。 よろしくお願いします、 ジュリアン

适用于 MCSPTR2AK396 开发套件的 lwip_FreeRTOS_s32k396 示例项目 你好！我正在使用 S32K396 MCSPTR2AK396 三相永磁同步电机控制开发套件。为了测试基础固件，我安装了以下软件包： S32DS_3.6.5_RFP_win32 S32K3_ETPU_SW_4.9_2.0.1_D2512 SW32K3_S32M27x_RTD_R23-11_7.0.0_QLP03_D2512 SW32K3_FreeMASTER_Driver_1.5.0_D2512 S32K3xx_AMMCLIB_RTM_1_1_45_BIN MCSPTR2AK396_SW GCC 版本 10.2 经过多次尝试同步所有软件版本均告失败后，终于成功了，基础固件开始运行。不过，接下来我想测试以太网通信功能，而这正是我目前遇到的尚未解决的问题。 我还安装了： SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603 SW32K3_TCPIP_STACK_4.0.0_D2512 我尝试了测试项目 lwip_FreeRTOS_s32k396，但它始终无法编译，总是出现错误；描述中总是存在冲突和其他问题。我尝试使用最新版本的 SW32K3_TCPIP_STACK_5.0.0_CD01_D2605，并且在更新代码过程中必须进行文件替换。最终，固件编译成功，虽然出现了一些警告，但没有出现错误。 之后，我便开始进行测试。我的系统设置如下：个人电脑 -> GeekStore 100BT1-PRO2 汽车变流器 ( http://pinzhi-tech.com.cn/en/home_eng/product_list_100base-t1_eng/100bt1-pro2_eng/ )-> MCSPTR2AK396。我调整了计算机上以太网连接的 IP 地址和固件中指定的 IP 地址，使它们位于同一子网中。然而，从计算机尝试 ping 电机的分配 IP 地址却失败了，尽管变流器显示网络轮询正在进行中。 问题可能出在哪里？是不是我不应该使用最新版本的 TCPIP_STACK？电路板本身是否存在问题？控制器板上的标签标明了版本 B1 和 B。是否可以获取专门针对这些修订的更多文档（在网站上，我只看到了修订版 A 的文档）？任何建议或疑问，我都非常感激。 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 你好@Anna_Anna ， 是的，是 fsdata.c之前版本中报告的 EthIf.c 文件问题已修复；EthIf.c来自 RTD 的文件只是一个短截线。我们提供了自己的 EthIf 最小实现，因此可以安全地将 RTD 中的文件从项目中排除。 其次，是的，根据您的描述，该示例似乎运行正常。需要进行连接，并且应该按照所述方式进行（将CRS_DV布线/焊接至PTD14 ）。 此致， 朱利安 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 谢谢，我稍后会尝试这种方法，并向你汇报结果。 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 你好@Anna_Anna ， 首先，我不确定 TCPIP v4.0.0 存在哪些错误，因为它也与 RTD 7.0.0 兼容。FreeRTOS 7.0.0 CD01 软件包，但是最新的 TCPIP 协议栈 (v5.0.0) 可以正常工作。能否告知一下您修改了哪些文件？ 我顺利地导入、生成和编译了该项目。我的环境：S32DS v3.6.0，RTD v7.0.1、FreeRTOS v7.0.0 CD 01 和 TCPIP 协议栈版本 5.0.0CD 01。 MCSPTR2AK396似乎存在设计缺陷。EMAC_MII_RMII_RX_DV ( PTD14 ) 未连接到RX_CTL - CONFIG6 ： MCSPTR2AK396 EVB 以太网连接，CRS_DV 信号澄清。 也就是说，该任务和操作系统是否正在运行？ xTickCount — 如果 RTOS 滴答中断处于活动状态，则此值应持续递增。 xSchedulerRunning — 如果调度程序正在运行，则应将其设置为 1。 此致， 朱利安   Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 你好@Julián_AragónM ！ 使用 TCPIP v4.0.0 构建测试项目时遇到的问题已通过从构建过程中排除 fsdata.c 和 EthIf.c 这两个文件得到解决。此冲突似乎已在 5.0.0 版本中自动解决。 我还通过 S32DS 调试器的“表达式”窗口检查了变量 xSchedulerRunning 和 xTickCount 的值。xSchedulerRunning 的值确实为 1，而 xTickCount 的值依次递增（1、5001、10001……），这让我得出结论：FreeRTOS 在板载上运行正常，问题不在于软件。如果我理解正确，剩下的唯一原因就是硬件问题——TJA1103A 上的 CRS_DV (CONFIG6) 引脚与 PTD14 引脚之间没有连接？要解决这个问题，我需要将这两个触点焊接在一起吗？请确认。 此致， 安娜 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit 你好 关于设计文件，我可以看到 MCSPTR2AK396 的硬件设计包包含 B2 版本： 此致， 朱利安

MCSPTR2AK396開発キット用のlwip_FreeRTOS_s32k396サンプルプロジェクト こんにちは！私はS32K396 MCSPTR2AK396と共に3相永久磁石同期モーター制御開発キットを使っています。ベースファームウェアをテストするために、以下のスタックをインストールしました。 S32DS_3.6.5_RFP_win32 S32K3_ETPU_SW_4.9_2.0.1_D2512 SW32K3_S32M27x_RTD_R23-11_7.0.0_QLP03_D2512 SW32K3_FreeMASTER_Driver_1.5.0_D2512 S32K3xx_AMMCLIB_RTM_1_1_45_BIN MCSPTR2AK396_SW GCC バージョン 10.2 すべてのソフトウェアバージョンを同期しようと何度か試みましたが失敗しましたが、最終的には動作し、ベースのファームウェアが動作し始めました。しかし、次にイーサネット通信機能をテストしたいと思ったところ、そこで未解決の問題に直面しました。 さらに以下のものをインストールしました： SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603 SW32K3_TCPIP_STACK_4.0.0_D2512 そして、テストプロジェクトlwip_FreeRTOS_s32k396を試してみましたが、エラーなしでコンパイルできたことは一度もありませんでした。常に説明の矛盾やその他の問題が発生していました。SW32K3_TCPIP_STACK_5.0.0_CD01_D2605の最新バージョンを使ってみたところ、コード更新処理中にファイルの置換を行う必要がありました。最終的に、ファームウェアは警告は表示されたものの、エラーは発生せずにコンパイルされた。 その後、テストに移りました。私は次のようにシステムをセットアップしました:パーソナルコンピュータ - > GeekStore 100BT1-PRO2 オートモーティブ コンバーター(http://pinzhi-tech.com.cn/en/home_eng/product_list_100base-t1_eng/100bt1-pro2_eng/)-> MCSPTR2AK396。パソコンのイーサネット接続とファームウェアで指定されたIPアドレスを同じサブネットに割り当てました。しかし、コンピュータからモーターの割り当てられたIPにpingを試みましたが失敗しましたが、コンバーターからはネットワークのポーリングが進行中であることが示されています。 何が原因なのでしょうか?もしかすると、最新バージョンのTCPIP_STACKを使うべきではなかったのでしょうか?基板自体に問題がある可能性はありますか？コントローラーボードのステッカーには、リビジョンB1とBが示されています。これらの改訂版専用の追加ドキュメントを入手することは可能でしょうか(ウェブサイトで、改訂Aのドキュメントしか見かけませんでした)?何かアドバイスや不明点があれば、ぜひお聞かせください。 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit こんにちは、 @Anna_Anna さん、 はい、fsdata.cまた、以前のリリースにおける EthIf.c の問題が報告され、修正されました。RTDからのファイルは単なるスタブです。EthIfの最小限実装も提供しているので、RTDのファイルはプロジェクトから安全に除外できます。 第二に、はい、あなたの説明から判断すると、その例は正しく動作しているようです。接続は必要であり、前述のとおりに行う必要があります（ CRS_DVをPTD14に配線/はんだ付けする）。 よろしくお願いします、 ジュリアン Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit ありがとうございます。後ほどこの方法を試してみて、結果をご報告します。 Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit こんにちは、 @Anna_Anna さん、 まず、TCPIP v4.0.0にはどのようなエラーがあったのか分かりません。なぜなら、RTD 7.0.0とも互換性があるからです。およびFreeRTOS 7.0.0 CD01パッケージですが、最新のTCPIPスタック(v5.0.0)は問題ありません。ファイルの改変内容について教えてもらえますか? プロジェクトのインポート、生成、コンパイルは問題なく完了しました。私の環境: S32DS v3.6.0、RTD v7.0.1、FreeRTOS v7.0.0 CD 01、およびTCPIPスタックバージョン5.0.0CD 01。 どうやらMCSPTR2AK396設計上の見落としがあるようです。 EMAC_MII_RMII_RX_DV (PTD14)はRX_CTLに接続されていません - CONFIG6:MCSPTR2AK396 EVB イーサネット コネクティビティ、信号の明確化CRS_DV。 とはいえ、タスクとOSは実行されていますか？ xTickCount — RTOSのティック割り込みがアクティブな場合、これは継続的に増加するはずです。 xSchedulerRunning — スケジューラが実行されている場合は、これを 1 に設定する必要があります。 よろしくお願いします、 ジュリアン   Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit こんにちは、 @Julián_AragónM! TCPIP v4.0.0を使ってテストプロジェクトを構築する際の問題は、fsdata.cとEthIf.cの2つのファイルをビルドから除外することで解決されました。この競合はバージョン5.0.0で自動的に解決されたようです。 また、S32DSデバッガのExpressionsウィンドウからxSchedulerRunningとxTickCountの変数の値も確認しました。xSchedulerRunningは確かに1の値を受け取り、2つ目の値は順次増加します(1、5001、10001...)。これにより、FreeRTOSは基板上で正しく動作しており、問題はソフトウェアにあるのではないと結論づけています。私の理解が正しければ、残っている唯一の原因はハードウェアの問題で、TJA1103AのCRS_DV(CONFIG6)とPTD14ピンの間に接続がないということですか?これを解決するには、この2つの接点をはんだ付けする必要がありますか?確認してください。 よろしくお願いします、 アンナ Re: lwip_FreeRTOS_s32k396 example project for MCSPTR2AK396 Development Kit こんにちは デザインファイルについてですが、MCSPTR2AK396のハードウェアデザインパッケージにはリビジョンB2が含まれているのが確認できます。 よろしくお願いします、 ジュリアン

S32DS LPSPI SLAVE Configuration The S32K344 + 33664 requires LPSPI to be configured in slave mode. After configuring the S32DS SPI as a slave, how does the MCU retrieve data after the 33664 sends data back? Which APIs need to be called? Re: S32DS LPSPI SLAVE 配置 It has been tested that using Lpspi_Ip_AsyncTransmit() can receive data. I wanted to call this function again in the callback function of Lpspi_Ip_AsyncTransmit() to trigger the reception of the second frame of data replied by MC33664. However, since MC33664 replied with two frames of data, the interval between the two CS is only 2.6us . The callback function of Lpspi_Ip_AsyncTransmit() cannot process it in time, resulting in the data of the second CS not being received. How can I handle this? Re: S32DS LPSPI SLAVE 配置 Hi @RRR123  As you are configuring the slave to use DMA, call Lpspi_Ip_AsyncTransmit(). Also, as a starting point, you may find the following demo applications useful references: S32K344 + MC33664 + MC33775 : RTD 3.0.0 : BMS SDK 1.0.2 S32K344 + MC33664 + MC33774 : RTD 3.0.0 : BMS SDK 1.0.2 BR, VaneB Re: S32DS LPSPI SLAVE 配置 Hi @RRR123  As a recommendation, please consider using the PHY_664 driver available in the BMS SDK for MC33664 communication. The PHY_664 driver was specifically designed to manage communication with the MC33664 transceiver. NXP Battery Management Software Development Kit and Toolchain

FRDM-MCXA156：MCUXpresso IDE 中的 SWO 跟踪（数据、配置文件和中断）功能无法正常工作 大家好， 我目前正在使用FRDM-MCXA156开发板，在调试过程中遇到了SWO（串行线输出）问题。 虽然应用程序调试成功，但我无法在SWO 跟踪窗口中接收任何数据，包括： SWO 数据 SWO概况 SWO中断跟踪 SWO ITM 控制台 为了排查问题，我已经核实了以下内容： 使用配置工具已正确配置SWO 引脚。 TRACE 时钟已启用并配置为96 MHz ，与 MCU 内核时钟匹配（MCXA156 运行频率为 96 MHz）。 该项目正在使用LinkServer和板载MCU-Link探针进行调试。 尽管进行了这些配置，但在调试过程中所有 SWO 跟踪窗口仍然为空。 为了方便参考，我附上了SWO 跟踪配置、 SWO 数据、 SWO 配置文件和其他窗口的截图，以及相关的项目配置。 对于可能导致此问题的原因，或者在FRDM-MCXA156上启用 SWO 跟踪是否需要任何额外的配置步骤，我非常感谢您能提供任何指导或建议。 感谢您抽出时间提供帮助。 #swo #frdm-mcxa156 开发板 MCXA Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 关于之前的帖子， 下面附上 SWO 启用配置和时钟的屏幕截图。 谢谢！ Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 你好@sidsal 对于 FRDM-MCXA156 板，将 SWO 信号连接到板载调试器的电阻 R36 默认情况下为 DNP（未安装）。请您填充 R36 并再次测试一下好吗？ 谢谢！ BR 爱丽丝 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 感谢@Alice_Yang指出这一点。我检查了 FRDM-MCXA156 原理图，并确认将 P0_2/SWO 信号连接到板载 MCU-Link 调试器的 R36 标记为 DNP。 我还注意到，在 FRDM-MCXN947 上，等效的 SWO 连接 (R130) 装配了一个 0 Ω 电阻。请问FRDM-MCXA156上的R36是否也应该安装一个0Ω电阻，以便通过板载MCU-Link调试器进行SWO跟踪？ 另外，能否请您解释一下为什么 FRDM-MCXA156 默认情况下 R36 未填充 (DNP)？是否有特殊的电路板设计原因或限制，要求该元件保持空置状态？所以我不能使用SWO功能吗？ 感谢您的帮助。 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 你好@sidsal “请问FRDM-MCXA156上的R36是否也需要连接一个0Ω电阻，才能通过板载MCU-Link调试器进行SWO跟踪？ ” 是的。如果要使用 SWO 功能，则需要安装一个 0 Ω 电阻或相应地焊接连接。 另外，能否请您解释一下，为什么FRDM-MCXA156芯片上的R36插槽默认是空的（DNP）？“ 我认为这是因为并非所有用户都需要 SWO 功能，所以默认情况下没有安装 0 Ω 电阻。 谢谢！ BR 爱丽丝 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 感谢@Alice_Yang的支持。

FRDM-MCXA156:MCUXpresso IDEでSWOトレース(データ、プロファイル、割り込み)が動作しない こんにちは、みんな、 現在、 FRDM-MCXA156 の開発ボードを使っていて、デバッグ中に SWO(シリアルワイヤー出力) で問題が発生しています。 アプリケーションは正常にデバッグされましたが、 SWOトレースウィンドウには以下のようなデータが一切届きません。 SWOデータ SWOプロファイル SWO割り込みトレース SWO ITMコンソール 問題のトラブルシューティングのため、以下の点を既に確認しました。 SWOピンはConfig Toolsを使用して正しく設定されました。 TRACEクロックは有効化され、96 MHzに設定されており、MCUコアクロック(MCXA156 96 MHzで動作)と一致します。 プロジェクトは、オンボードのMCU-Linkプローブを搭載したLinkServerを用いてデバッグされています。 これらの設定にもかかわらず、デバッグ中はすべてのSWOトレースウィンドウが空のままです。 参考までに、 SWOトレース構成、 SWOデータ、 SWOプロファイル、その他のウィンドウのスクリーンショットと、関連するプロジェクト構成を添付しました。 この問題の原因について、またはFRDM-MCXA156でSWOトレースを有効にするために必要な追加の設定手順があるかどうかについて、ご助言やご提案をいただければ大変ありがたいです。 お時間とご協力に感謝いたします。 #swo #frdm-mcxa156 開発ボード MCXA Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE 前のスレッドについてですが、 SWO有効化設定とクロックのスクリーンショットを以下に添付します。 よろしくお願いします。 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE こんにちは、 @sidsal FRDM-MCXA156ボードの場合、SWO信号をオンボードデバッガに接続する抵抗R36は、デフォルトではDNP（未実装）となっています。R36を入力して再度テストしてもらえますか? よろしくお願いします。 BR アリス Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE ご指摘ありがとうございます、 @Alice_Yang さん。FRDM-MCXA156の回路図を確認し、P0_2/SWO信号をオンボードのMCU-Linkデバッガに接続するR36がDNPとしてマークされていることを確認しました。 また、FRDM-MCXN947では、SWO接続（R130）に相当する部分に0Ωの抵抗器が取り付けられていることにも気づきました。FRDM-MCXA156のR36にも、オンボードのMCU-Linkデバッガを通じたSWOトレーシングを有効にするために0 Ω抵抗を埋め込むべきか確認していただけますか? さらに、なぜR36がFRDM-MCXA156でデフォルトで未入力(DNP)されているのか、説明していただけますか?特定のボード設計上の理由や制限で、そのボードを無人のままにしておく必要があるのでしょうか?つまりSWO機能は使えないのですか? ご協力ありがとうございます。 Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE こんにちは、 @sidsal 「CFRDM-MCXA156のR36にも0 Ω抵抗を入れて、オンボードのMCU-Linkデバッガを通じたSWOトレーシングを有効にするべきか確認していただけますか?」" はい。SWO機能を使用する場合は、0Ω抵抗を取り付けるか、それに応じて接続部をはんだ付けする必要があります。 「さらに、なぜR36がFRDM-MCXA156でデフォルトで未登録(DNP)されているのか、説明していただけますか?」 ->>これはすべてのユーザーがSWO機能を必要としているわけではないため、0 Ω抵抗がデフォルトで埋められていないからだと思います。 よろしくお願いします。 BR アリス Re: FRDM-MCXA156: SWO Trace (Data, Profile & Interrupts) Not Working in MCUXpresso IDE ご支援ありがとうございます@Alice_Yang。

过压和欠压情况下的电压注入测试及相关行为 大家好， SBC FS4503在我们的一个项目中被使用，并按如下方式配置以适应 OV / UV 条件。 VCCA、VCORE 和 VAUX 配置为仅在 OV 条件下对 FS0B产生影响，在 UV 条件下对 RSTB 和 FS0B 均产生影响。 电压注入测试是通过使用第二个电源向 VCORE、VAUX 和 VCCA 引脚注入电压来进行的，同时第一个电源向 SBC 提供 12V 输入。 测试结果如下： 1. VAUX OV - 断言 FS0B， 2. VAUX UV 触发信号RESET 3. VCORE OV- 断言 FS0B，但 VCORE 被切断，如数据表中所述。 4. VCORE UV 触发器 RESET 5. VCCA OV - 断言 FS0B，但 VCORE 短暂下拉，因此 RESET 6. VCCA UV 触发器 RESET。 VPRE-OV-数据手册提到稳压器已关闭，但我们观察到 RESET。 以下是查询内容： 1. 台式测试程序有效吗？其中，在OV条件下，在相应的引脚上注入约5.5V电压，在紫外线条件下，在相应的引脚上注入约3.5V的电压。 2. VCCA OV病症的观察是否可接受？ 3. 当VPRE发生OV状态时，数据手册提到稳压器被关闭，这是否也会切断VCORE电源？ 谢谢！ 阿迪亚 Re: Voltage injection tests for OV and UV scenarios and associated behavior 1. 台架测试程序是否有效？其中，对于 OV 条件，在相应的引脚上注入约 5.5V 电压；对于 UV 条件，在引脚上注入约 3.5V 电压。 [gw]OV 应使用高于 5.5V 的电压，UV 测试应低于 3V。 同时还需要满足过滤时间和反应时间的要求。 2. VCCA OV 条件下的观察结果是否可以接受？ [gw]第二个电源（OV电压）是否会通过VCCA引脚反向供电，从而导致VPRE/VCORE回路出现干扰？ 在本次VCCA OV测试中，您是否监测了VPRE？ 3. 当 VPRE 出现过压情况时，数据手册提到稳压器会关闭，这是否也会切断 VCORE 电源？ [gw]是的，VCORE 由 VPRE 提供。 Re: Voltage injection tests for OV and UV scenarios and associated behavior 你好@guoweisun ， 谢谢你的回复。这很有帮助。 以下是我的问题： [gw]第二个电源（OV电压）是否会通过VCCA引脚反向供电，从而导致VPRE/VCORE回路出现干扰？ 在本次VCCA OV测试中，您是否监测了VPRE？ [ab]：未对 VPRE 进行监测。我将通过新的测试来监测它。请问您能否帮我理解一下通过VCCA引脚反向供电是什么意思？ [gw]OV 应使用高于 5.5V 的电压，UV 测试应低于 3V。 “还需要满足过滤时间和反应时间的要求。” [ab]：由于我是手动执行此操作，因此对于OV情况，过滤时间100-200微秒和反应时间314微秒均满足要求。 以下是一些其他问题： 1. 如何检测OV/UV？SBC使用的采样率是多少？ 2. 过滤时间和反应时间有何意义？ 2. 在检测到任何引脚上的过压/过压故障之前，允许有多少个不合格样品？ 谢谢！ 阿迪亚

OVおよびUVシナリオにおける電圧注入テストと関連する挙動 コミュニティの皆様、こんにちは。 SBC FS4503は、当社のプロジェクトの一つで使用されており、OV/UV条件下向けに以下のように構成されています。 VCCA、VCORE、VAUXは、FS0BにはOV条件下でのみ影響を与え、UV条件下ではRSTBとFS0Bの両方に影響を与えるように構成されています。 電圧注入テストは、第１の電源からSBCに12Vの入力電圧を供給しながら、第２の電源を使用してVCORE、VAUX、VCCAピンに電圧を注入することによって実施しました。 試験結果は以下のとおりです。 1. VAUX OV - FS0B をアサートします。 2. VAUX UVトリガーリセット 3. VCORE OV - データシートに記載されているように、FS0B をアサートしますが、VCORE はカットオフされます。 4. VCORE UVトリガーリセット 5. VCCA OV- FS0B をアサートするが、VCORE が短時間プルダウンされ、リセットされる。 6. VCCA UV-トリガーリセット。 VPRE-OV - データシートにはレギュレーターがオフになっていると記載されており、リセットが観察されています。 以下はクエリです。 1. ベンチテスト手順は有効か?OV条件下ではそれぞれのピンに約5.5V、UV条件下では約3.5Vがピンに注入されました。 2. VCCAのOV状態での観察は許容されるか? 3. VPREでOV状態が発生した場合、データシートにはレギュレーターがオフになっていると記載されていますが、これによりVCOREの電源も遮断されますか? ありがとうございました。 アディティヤ Re: Voltage injection tests for OV and UV scenarios and associated behavior 1. ベンチテストの手順は有効ですか？ここで、OV条件では約5.5Vがそれぞれのピンに注入され、UV条件では約3.5Vがピンに注入された。 [gw]OVは5.5V以上の電圧を使用し、UVテストは3V未満にする必要があります。 また、濾過時間と反応時間の要件も満たす必要があります。 2. VCCA OV条件での観察結果は許容範囲内ですか？ [gw]2番目の電源（0V電圧）はVCCAピンを通して逆方向に供給され、VPRE/VCOREループに障害を引き起こしますか？ このVCCA OV検査中にVPREをモニタリングしましたか？ 3. VPREでOV状態が発生した場合、データシートにはレギュレーターがオフになっていると記載されていますが、これによりVCOREの電源も遮断されますか? [gw]はい、VCOREはVPREによって提供されます。 Re: Voltage injection tests for OV and UV scenarios and associated behavior こんにちは@guoweisunさん ご回答ありがとうございます。これは役に立つ。 以下に私の質問事項を記載します。 [gw]2番目の電源（0V電圧）はVCCAピンを通して逆方向に供給され、VPRE/VCOREループに障害を引き起こしますか？ このVCCA OV検査中にVPREをモニタリングしましたか？ [ab]: VPREは監視されていませんでした。新たな検査で監視していきます。VCCAピンを通じたリバース電源とはどういう意味か教えていただけますか? [gw]OVは5.5V以上の電圧を使用し、UVテストは3V未満にする必要があります。 「また、ろ過時間と反応時間の要件も満たす必要があります。」 [ab]: この作業を手動で行っているため、OV CASEではフィルター時間100〜200us、反応時間314usが満たされています。 以下は追加の質問です。 1. OV/UVはどのように検出されますか？SBCで使用されるサンプリングレートはどれくらいですか？ 2. 濾過時間と反応時間の重要性は何ですか？ 2. いずれかのピンで過電圧/低電圧障害を検出するまでに、いくつの不良サンプルが許容されますか？ ありがとうございました。 アディティヤ

SL3S1013FTB0,115 设计检查请求 1）上述应答器原理图是否适用于3.6V供电和RFID供电的配置？ 2）对于采用3.6V电源和RFID供电的RFID应答器配置，所标明的电压是否正确？ a) 2.6V - 3.1V（3.6V供电） b) 1-1.5V（RFID供电） Re: SL3S1013FTB0,115 design check request 我们已收到您的电源电压校正请求。我会进行更正。 您的问题：这是您使用该应用程序的预期目的吗？ 答：我们目前还没有这款产品的应用案例，但我们想了解一下这个防拆报警器的工作原理。 我计算了电压为 1.8V 和 2.2V 时的输出电压 Vout。这个计算结果正确吗？如果答案是肯定的，则输出电压太低，无法进行任何有意义的操作。 Vout = Ivdd X 1k Ivdd = Iinternal + Iout 典型的持续电流消耗在 1.8V 时约为 120 µA，在 2.2V 时约为 340 µA。 对于VDD = 1.8 V，Idd = 0.00012A 当 VDD = 2.2 V 时，Idd = 0.00034A 当 VDD = 1.8 V 时，Vout = 0.00012X 1千欧姆 输出电压 = 0.12V 当 VDD = 2.2 V 时，Vout = 0.00034X 1千欧姆 输出电压 = 0.34V Re: SL3S1013FTB0,115 design check request 你好@pragashsangaran 当采用外部供电时，VDD 焊盘需要 1.8V 至 2.2V 之间的电压；对于更高的电压值，则需要串联电阻。要进行正确计算，请参阅UCODE G2i 的 AN10940 常见问题解答，第 3 章/第 4 章。 OUT 引脚是一个数字输出，可用于防拆回路、小型外部电路或作为指示器；这些配置需要外部提供 VDD 引脚电源。如果 R35 被连接，则会引入一个可能激活“防拆指示器”位的连接，如标签防拆报警功能所述（请参阅UCODE G2i 常见问题解答 AN10940第 16 章）。这是否符合您的应用预期用途？ OUT 引脚的预期电压等级在AN10940 FAQ on UCODE G2i第 13 章中有描述。为连接到 OUT 引脚的设备供电的解决方案需要在 VDD 引脚上提供外部电源。 我建议您查看AN11237 UCODE G2iM+ 演示板文档，图 3 和图 5 中有一些参考连接。 问候， 爱德华多。 Re: SL3S1013FTB0,115 design check request 您好， 要使用 OUT 引脚的功能，例如数字输出/开关或为外部电路供电，需要外部电源。此外，正如UCODE G2i 常见问题解答 AN10940第 16 章“标签防拆报警功能如何使用？”中所述，此功能基于 VDD 和 OUT 之间的电气连接；需要注意的是，防拆功能和外部供电模式不能同时使用。 关于计算，请注意 OUT 引脚上的可用电压等级由 VDD 上的电压等级减去内部串联电阻上的电压下降决定。您可以在 UCODE G2i 的 AN10940 常见问题解答第 5.3 章中找到一些示例。 问候， 爱德华多。 Re: SL3S1013FTB0,115 design check request 你好， EduardoZamora ， 我们不会使用防拆报警功能，所以可以忽略这一点。R35是备选方案。 对我们来说，Vout 非常重要，因为它需要用来开启产品。你的意思是说，必须有VDD才能获得Vout。但是，我对使用这个部件有两个主要的顾虑。 计算出的输出电压过低。 当 VDD = 1.8 V 时，Vout = 0.12V 当 VDD = 2.2 V 时，Vout = 0.34V。 这个 Vout 对开启设备没有任何帮助。即使我们考虑提高电压，也没有太多方法可以进一步提高电压。 我的计算正确吗？完整的计算过程请参见我之前的回复。 在有VDD的情况下，Vout是否可以独立于RFID信号存在？我们希望 Vout 仅在天线接收到 RFID 信号时才存在。这是真的吗？ Re: SL3S1013FTB0,115 design check request 您好， Vout 取决于 VDD 引脚上的电压（根据AN10940 FAQ on UCODE G2i第 5 章对 VDD 和 RFN 之间的串联电阻进行适当尺寸调整后），减去 VDD 和 OUT 之间的内部串联电阻上的电压下降（~1kΩ）。一些计算示例可以在第 5.3 章中找到。 关于 OUT 引脚的状态，请参阅第 8 章至第 10 章，了解有关如何控制此引脚的更多信息。 问候， 爱德华多。 Re: SL3S1013FTB0,115 design check request EduardoZamora ，非常感谢。经过多次反复提问，我终于感觉得到了正确的答案。我真心希望我们能通过这个工单解决我的问题。 我还想知道这是否是 RFID 供电配置（无 VDD）的 Vout。您也能告诉我一声吗？ 我没有使用防拆指示器。我希望我们能够证明使用SL3S1013FTB0,115 而不是肖特基二极管的合理性。如果肖特基二极管无需电源电压就能提供更高的输出电压，我更倾向于选择肖特基二极管。

S32K356 RTDの選択 S32K356を使用する予定ですが、バージョン7.0.0と7.0.1しか利用できないことがわかりました。しかし、対応するautosar...AUTOSAR R21を使用する場合、どのバージョンをお勧めしますか？ Re: S32K356 RTD选择 SW32K3_S32M27x_RTD_R21-11_6.0.0_P05_D2510も試してみましたが、何度も失敗しました。S32D32のバージョンに関係しているのではないかと考えています。3.6.7も試してみました。では、どのバージョンのS32D32を使用すればよいのでしょうか？ Re: S32K356 RTD选择 こんにちは@wenming さん おっしゃる通りです。たとえS32K356がSW32K3_S32M27x_RTD_R21-11_6.0.0_D2506_ReleaseNotes.pdfの「サポート済みデリバティブ」セクションに記載されていても、S32K356プロジェクトは作成できません。 RTD 6.0.0 P05リリースノートには、このP05リリースがS32K356派生モデルのS32DS/CTサポートを追加すると記載されています。 よろしくお願いいたします。 パベル Re: S32K356 RTD选择 バージョン6.0.0の説明によると、S32K356はサポートされていません。 Re: S32K356 RTD选择 こんにちは@wenming さん S32K3 RTDバージョン6.0.0(AUTOSAR R21-11)は、AUTOSAR R21とのS32K356に推奨される選択肢です。 よろしくお願いいたします。 パベル Re: S32K356 RTD选择 こんにちは@wenming さん スクリーンショットをありがとうございます。 エラーメッセージから判断すると、これはS32DSのバージョン制限によるものではないようです。S32DSがインストールするアイテムを収集/ダウンロードしている最中にエラーが発生し、重要なメッセージは次のとおりです。 ZLIB入力ストリームの予期しない終了 失敗した項目は、S32DSのプラットフォーム/デバッグ関連アーティファクトです。例えば: com.nxp.s32ds.doc.platform.resources com.nxp.s32ds.lrc.gdb.arm64.linux.win32 これは通常、アーティファクトのいずれかが完全にダウンロードされなかったか、ダウンロード/解凍中に破損したことを示しています。つまり、この問題はRTD 7.0.1とS32DS 3.6.7の互換性制限というよりは、更新サイトやダウンロード、キャッシュの問題のように見えます。 リリースノートに関して：記載されているS32DSバージョンは、そのRTDリリースにおけるベースライン/テスト済みのS32DSバージョンとして理解してください。しかし、S32DSはモジュール式であり、RTDのインストールでは、関連するプラットフォーム、ツール、デバッガ、コンパイラ、ドキュメントコンポーネントが現在のインストールで欠けているか古い場合は、更新またはインストールが必要になる場合があります。 以下の手順をお試しください。 S32DSを再起動して、もう一度インストールを試してください。 NXPのアップデートサイトへのネットワーク接続が安定していることを確認してください。 可能であれば、インストール時にオンラインダウンロードのみに頼るのではなく、公式のオフラインアップデートサイトZIP/パッケージを使用してください。 S32DSに必要なGCC 10.2ツールチェーンがインストールされていることを確認してください。 問題が解決しない場合は、S32DS 3.6.x をクリーンインストールしてみてください。インストール後、追加のパッチやアップデートパッケージを適用する前に、まずRTD 7.0.1の基本パッケージをインストールしてください。 したがって、現在のスクリーンショットから判断すると、RTD 7.0.1がS32DS 3.6.7で使えないとは結論づけません。今回のエラーは、必要なS32DSアップデートファイルのダウンロードが不完全または破損していることを示唆しています。 参考までに、私はS32DS 3.6.6にSW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zipを正常にインストールできました。私のセットアップでは、S32K3 RTDパッケージに必要なGCC 10.2ツールチェーンを追加でインストールするだけで済みました。   よろしくお願いいたします。 パベル Re: S32K356 RTD选择 S32DSのバージョンを3.6.10にアップグレードしました。これにより、追加コンポーネントなしでRTD 7.0.1をインストールできます。今後は開発にS32DS 3.6.10 + RTD 7.0.1を使用します。後でautosarが必要になった場合は…バージョンR21へのアップデート情報があれば、お知らせください。よろしくお願いいたします。 Re: S32K356 RTD选择 こんにちは@wenming さん この問題はS32DSのバージョンに関連している可能性があります。 ただし、まずQLP01がインストールされていることを確認してください。SW32K3_S32M27x_RTD_R21-11_6.0.0_P05_D2510_ReleaseNotes.txtには「このリリースはこのS32K3_S32M27xリアルタイム・ドライバAUTOSAR R21-11バージョン6.0.0 QLP01の上に載っている」と記載されています。 よろしくお願いいたします。 パベル Re: S32K356 RTD选择 上記の画像に示すように、バージョン 6.0.0 QLP01 もインストールに失敗します。もう 1 つの問題は、RTD リリース ノートにはインストールに必要なのは S32DS 3.6.2 のみと記載されていることです。バージョン 3.6.7 を使用しているのに、なぜコンポーネントの更新を求められるのでしょうか？これはリリースに関連しています...メモの内容が一致しません。原因は何でしょうか？ Re: S32K356 RTD选择 こんにちは@wenming さん いくつか追加の発見がありました。 朗報です。S32DS 3.6.2にRTD 6.0.0 QLP01とP05をインストールすることができました。しかし、リリースノートの記述にもかかわらず、RTD 6.0.0 QLP01は、まずクリーンなRTD 6.0.0のインストール環境の上にインストールする必要がありました。その後、P05も無事に取り付けられるようになりました。 残念ながら、このインストール手順を経ても、SDKはS32DSのS32K356プロジェクトにまだ接続できません。 古いAUTOSAR版をお探しだと理解しています。しかし、観察された挙動から判断すると、S32DSでRTD 6.0.0で動作するS32K356セットアップは確認できません。S32K356として、実用的なS32DSサポートは新しいRTD 7.0.0で利用可能になっているようです/ 7.0.1 リリース。 よろしくお願いいたします。 パベル Re: S32K356 RTD选择 S32DSのバージョン互換性の問題を解決するにはどうすればよいですか？S32DS3.6.7にRTD7.0.1をインストールできないのはなぜですか？また、アップデートを促され続けるのはなぜですか？ Re: S32K356 RTD选择 こんにちは@wenming さん Q1: S32DSのバージョン互換性の問題はどう解決すればいいですか? 具体的にどの不適合メッセージが見られているのか、もう少し具体的に教えていただけますか?   Q2: なぜS32DS3.6.7にRTD7.0.1をインストールしず、アップデートを促され続けるのですか? アップデートを促すメッセージ自体はエラーではありません。選択したRTDパッケージが新しいコンポーネントや追加コンポーネントに依存している場合、S32DSは関連するプラットフォームやツールパッケージの更新を求めることがあります。   また、S32K3 RTDパッケージで必要なGCC 10.2ツールチェーンがS32 Design Studioにインストールされているか必ず確認してください。   よろしくお願いいたします。 パベル Re: S32K356 RTD选择 これはRTD 7.0.1のインストール時に表示されるエラーメッセージです。バージョン制限によるものと思われますか？また、RTDリリースで説明されているS32DSバージョンは、原則としてS32DSコンポーネントを更新することなくインストールできるはずです。それでもコンポーネントの更新が必要な場合は、より使いやすい新しいインストールバージョンをお勧めする方が良いでしょう。

S32K356 RTD Selection We plan to use the S32K356, but found that only versions 7.0.0 and 7.0.1 are available, but the corresponding autosar...If using autosar R21, which version would you recommend? Re: S32K356 RTD选择 I also tried SW32K3_S32M27x_RTD_R21-11_6.0.0_P05_D2510, but it failed many times. I suspect it's related to the S32Ds version. I've also tried 3.6.7. So, which version of S32D32 should I use? Re: S32K356 RTD选择 Hello @wenming , You are right - even if the S32K356 is mentioned in the Supported Derivatives section of the  SW32K3_S32M27x_RTD_R21-11_6.0.0_D2506_ReleaseNotes.pdf , S32K356 project can't be created. The RTD 6.0.0 P05 release notes state that this P05 release adds the S32DS/CT support for the S32K356 derivative.  Best regards, Pavel Re: S32K356 RTD选择 Based on the description of version 6.0.0, it does not support S32K356. Re: S32K356 RTD选择 Hello @wenming , S32K3 RTD versions 6.0.0 (AUTOSAR R21-11) is the recommended option for S32K356 with AUTOSAR R21. Best regards, Pavel Re: S32K356 RTD选择 Hello @wenming , Thank you for the screenshot. From the error message, this does not look like an S32DS version limitation. The error happens while S32DS is collecting/downloading the items to be installed, and the key message is: Unexpected end of ZLIB input stream The failed items are S32DS platform/debug related artifacts, for example: com.nxp.s32ds.doc.platform.resources com.nxp.s32ds.lrc.gdb.arm64.linux.win32 This usually indicates that one of the artifacts was not downloaded completely or was corrupted during download/extraction. So the issue looks more like an update-site/download/cache problem than a direct RTD 7.0.1 versus S32DS 3.6.7 compatibility limitation. Regarding the Release Note: the listed S32DS version should be understood as the baseline/tested S32DS version for that RTD release. However, S32DS is modular, and the RTD installation may still require related platform, tools, debugger, compiler, or documentation components to be updated or installed if they are missing or outdated in the current installation. Please try the following: Restart S32DS and try the installation again. Make sure the network connection to the NXP update site is stable. If possible, use the official offline update-site ZIP/package instead of relying only on online download during installation. Check that the required GCC 10.2 toolchain is installed in S32DS. If the issue remains, please try a clean S32DS 3.6.x installation and then install the base RTD 7.0.1 package first before applying any additional patch/update package. So based on the current screenshot, I would not conclude that RTD 7.0.1 cannot be used with S32DS 3.6.7. The current error points rather to an incomplete/corrupted download of required S32DS update artifacts. For reference, I was able to install SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite.zip successfully in S32DS 3.6.6. In my setup, I only had to additionally install the GCC 10.2 toolchain required by the S32K3 RTD package.   Best regards, Pavel Re: S32K356 RTD选择 I've upgraded my S32DS version to 3.6.10, which can install RTD 7.0.1 without requiring additional components. We'll use S32DS 3.6.10 + RTD 7.0.1 for development now. If autosar is needed later...If there's news of an update to version R21, please let me know. Thank you. Re: S32K356 RTD选择 As shown in the image above, version 6.0.0 QLP01 also fails to install. Another issue is that the RTD release note states that only S32DS 3.6.2 is required for installation. Why is it prompting me to update components when I use version 3.6.7? This is related to the release...The note does not match; what could be the reason? Re: S32K356 RTD选择 How do I resolve the S32DS version incompatibility issue? Why can't I install RTD7.0.1 in S32DS3.6.7, and it keeps prompting me to update? Re: S32K356 RTD选择 Hello @wenming , Q1: How do I resolve the S32DS version incompatibility issue? Could you please be more specific about the exact incompatibility message you see?   Q2: Why can't I install RTD7.0.1 in S32DS3.6.7, and it keeps prompting me to update? The update prompt itself is not an error. S32DS may ask to update related platform/tool packages when the selected RTD package depends on newer or additional components.   Also, please make sure that the GCC 10.2 toolchain required by the S32K3 RTD package is installed in S32 Design Studio.   Best regards, Pavel Re: S32K356 RTD选择 This is an error message when installing RTD 7.0.1. Does it seem to be a version limitation? Also, the S32DS version described in the RTD release should, in principle, be ready to install without needing to update the S32DS components. If component updates are still required, it would be better to recommend the newer installation version, which would be easier to use.

MIMXRT1160 XIP 随机失效 我有多个板运行 XIP，从八进制闪存以 166 MHz 的频率运行。其中一个程序偶尔会出错，并显示“未定义指令”错误。 我怀疑是信号完整性问题，但我没有在PCB板上设置测试点，所以唯一的检查方法就是将频率从166MHz降低到133MHz，这似乎“解决”了该电路板的问题。 值得注意的是，当从 mcuboot 链式加载应用程序时，该错误最常出现。在应用程序运行时这种情况较为罕见。我也找不到可靠的方法来触发它——需要反复重启电路板几次，直到故障出现。 有没有办法更精确地诊断这个 XIP 故障？ Re: MIMXRT1160 XIP fails randomly 嗨@tbonkers ， 您描述的行为很可能是由于 166 MHz 时读取采样裕量（建立/保持）不足造成的，这是由于 PCB 布线紧凑/闪存数据线上的信号完整性裕量不足所致。这也解释了这两个症状：降到 133 MHz 会扩大采样窗口，因此问题“消失”；而 mcuboot 链加载是冷 RESET 后第一个密集的、缓存冷指令的获取，此时裕量最紧——因此它最常在那里失败，而运行时获取大多命中缓存，很少触发它。 我们建议进行以下检查，所有检查均在软件层面进行，无需PCB测试点： 先从虚拟循环开始。验证读取 LUT 中的虚拟周期计数是否与 166 MHz 下的 Octal Flash 数据手册规格严格匹配。如果自动生成的 FCB（例如，来自配置工具）使用较低的值，请将其设置为数据表指定的值，并且您可以添加 1-2 个额外的虚拟周期来扩大数据有效窗口并增加采样裕度。虚拟周期不足会导致第一个数据节拍处于转折/尚未稳定区域——这是间歇性错误的典型来源。 验证读取采样时钟源。166 MHz 仅在 readSampleClksrc=3 时符合规范（ kFlexSPIReadSampleClk_ExternalInputFromDqsPad：读取 Flash 设备提供的选通/DQS）。如果当前值为 0 或 1，则 166 MHz 超出规格，这与“133 MHz 可以解决这个问题”的说法完全一致。请确认PCB上存在真实的DQS走线，并使用此模式。 如果在进行这些调整后仍然出现间歇性故障，您可以按照上述步骤 1-3 隔离 166 MHz 裕量瓶颈，同时以 133 MHz 作为安全基线运行。这篇文章或许也有帮助： https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Octal-flash-IS25WX256-dummy-cycles/mp/2178828   最好的祝愿， 加文 Re: MIMXRT1160 XIP fails randomly 分享错误日志或原理图可能会有所帮助，目前的故障率是多少？ Re: MIMXRT1160 XIP fails randomly 嗨@Gavin_Jia ， 我用不同的虚拟循环次数测试了READ命令，但仍然出现故障。 我已将闪存易失性寄存器中的虚拟周期数设置为 20，以便它可以支持 166 MHz。根据闪存数据手册，它应该支持高达 200 MHz 的频率和 20 个虚拟周期。 readSampleClksrc=3 由 bootROM 设置，已通过连接调试器确认。 DQS跟踪记录确实存在。 有时故障发生在应用程序运行时，在第一次主要闪存读取之后。 Re: MIMXRT1160 XIP fails randomly 嗨@tbonkers ， 感谢您提供的详细测试数据。根据您的发现，这最符合 166 MHz 八路 DDR XIP 读取路径在其采样/信号完整性裕度边缘运行的情况。 readSampleClksrc=3 DQS跟踪是必要条件，但并非充分条件：在DDR DQS模式下，RT1160端仍然要求DQS到SIO的相对偏差保持在~±1ns以内，而166MHz是接口的上限，因此裕量很小。 我查阅了更多资料，以下解决方案或许可以帮助您在不修改PCB的情况下解决当前问题： 应用 DLL 勘误表 ERR011377。RT1160 勘误表指出，在设置 DLL 锁定状态位后，由于时序问题，立即对外部闪存进行读/写操作仍可能返回错误数据；解决方法是在设置锁定位后至少等待 512 个 FlexSPI 根时钟周期再访问闪存。请确保在引导加载程序和应用程序中重新配置 FlexSPI/DLL/时钟的每个路径中都应用此延迟——这与“链式加载时最频繁，运行时间歇性”的原则非常吻合。 运行可量化的 RAM 驻留压力测试（比反复断电重启更有效） 。将测试代码和故障处理程序放在 ITCM/OCRAM 中，通过 CRC 比较，反复从 AHB 内存映射中读取大闪存块，扫描频率为 166/133/120 MHz。如果随着频率的降低，错误率急剧下降，则证实存在时序/信号完整性裕量问题。 对于 MCU 启动的情况：如果引导加载程序曾经擦除/编程了外部或非，则必须在跳转到应用程序之前使 I/数据缓存失效；还要确认应用程序不会使用不同的时钟/DLL/LUT/焊盘设置重新初始化 FlexSPI。 如果最终只有 166 MHz 出现故障而 133 MHz 稳定，我们建议将 133 MHz 作为当前板的安全工作频率；如果生产必须使用 166 MHz，则应检查 PCB 的 DQS/SCLK/SIO 长度匹配、阻抗、串扰和焊盘驱动强度，并在下一个版本中添加这些信号的测试点。 此致， 加文

MIMXRT1160 XIPがランダムに失敗する 私は、166MHzで動作する8ビットフラッシュメモリからXIPを実行する複数のボードを所有しています。そのうちの1つが、時折「未定義の命令」エラーで失敗する。 信号の整合性の問題を疑っていますが、PCBにテストポイントがないので、それを確認できる唯一の方法は速度を166MHzから133MHzに下げることで、そのボードの問題が「解決」しているようです。 このエラーは、mcubootからアプリケーションをチェーンロードするときに最も頻繁に出るのが示唆的です。アプリケーション実行時にはより稀です。信頼できるトリガー方法も見つかりません。故障が現れるまで何度も電源を入れ直す必要があります。 このXIPの故障をより正確に診断する方法はありますか? Re: MIMXRT1160 XIP fails randomly こんにちは、 @tbonkers さん。 ご説明いただいた現象は、フラッシュデータラインのPCB配線や信号品質の余裕が限られているため、166MHzにおける読み出しサンプリングマージン（セットアップ/ホールド）が不足していることが原因である可能性が最も高いです。これにより両方の症状も説明できます。133 MHzに落とすとサンプリングウィンドウが広がり、問題が「消える」ことになります。そしてMCUbootのチェーンロードは、コールドリセット直後に最初に密度の高いキャッシュコールド命令フェッチであり、マージンが最も厳しい場所です。そのため、そこで最も失敗しやすく、ランタイムフェッチは主にキャッシュに当たってほとんどトリガーされません。 以下のチェックを推奨します。すべてソフトウェア側で、PCBテストポイントは不要です。 まずはダミーサイクルから始めましょう。読み出しLUT内のダミーサイクル数が、166MHzにおけるオクタルフラッシュのデータシート仕様と厳密に一致していることを確認してください。自動生成されたFCB(例:プロビジョニングツールからのもの)がより低い値を使用している場合は、データシートで指定された値に設定し、データ有効ウィンドウを広げてサンプリングマージンを拡大するために1〜2回のダミーサイクルを追加できます。ダミーサイクルが不十分なため、最初のデータビートがターンアラウンド/未確定領域に配置されてしまい、断続的なエラーの典型的な原因となる。 読み取りサンプルクロックソースを確認します。166 MHz は readSampleClksrc=3 ( kFlexSPIReadSampleClk_ExternalInputFromDqsPad:フラッシュ デバイスから提供されるストローブ/DQS を読み取る) の場合にのみ仕様を満たします。現在0または1の場合、166MHzは仕様外であり、これは「133MHzで修正される」という記述と完全に一致します。基板上に実際のDQSトレースが存在することを確認し、このモードを使用してください。 これらの調整後も断続的な故障が続く場合は、166 MHzのマージンボトルネックを上記のステップ1〜3で隔離しながら、安全な基準として133 MHzで動作できます。また、こちらの投稿も参考になるかもしれません： https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/Octal-flash-IS25WX256-dummy-cycles/mp/2178828   幸運をお祈りしています、 ギャビン Re: MIMXRT1160 XIP fails randomly エラーログや回路図の共有が役立つかもしれませんが、今のところの故障率はどうでしょうか? Re: MIMXRT1160 XIP fails randomly こんにちは、 @Gavin_Jia さん。 読み取りコマンドを様々なダミーサイクル数でテストしてみましたが、やはりエラーが発生します。 フラッシュボラタイルレジスタのダミーサイクル数を20に設定し、166 MHzをサポートできるようにしました。フラッシュのデータシートによると、20回のダミーサイクルで最大200 MHzをサポートするはずです。 readSampleClksrc=3はbootROMによって設定され、デバッガ接続で確認されます。 DQSトレースは確かに存在する。 時には、アプリケーションが実行中、最初の大きなフラッシュ読み取りの後に故障が発生することがあります。 Re: MIMXRT1160 XIP fails randomly こんにちは、 @tbonkers さん。 詳細なテストをありがとうございました。あなたの調査結果に基づくと、これは166MHzオクタルDDR XIPの読み出しパスがサンプリング／信号完全性マージンの限界付近で動作しているという状況と最も整合性が取れています。 readSampleClksrc=3 およびDQSトレースは必要条件ですが十分条件ではありません。DDR DQSモードでは、RT1160側はDQSからSIOへの相対スキューが~±1ナ秒以内に保たれ、166 MHzがインターフェースの上限であるため、マージンは最小限です。 さらに調査したところ、基板を改造することなく現在の問題を解決するのに役立つ可能性のある解決策が以下のとおりです。 DLLのエラータERR011377を適用してください。RT1160の訂正表には、DLLロックステータスビットが設定された後も、外部フラッシュへの即時読み書きがタイミングの問題により誤ったデータを返す可能性があると記載されています。回避策としては、ロックビットが設定されてから少なくとも512回のFlexSPIルートクロックサイクルを待ってからフラッシュにアクセスすることです。この遅延は、ブートローダーおよびFlexSPI/DLL/クロックを再設定するアプリケーションのすべてのパスに適用されるようにしてください。これは「チェーンロード時に最も頻繁で、実行時に断続的」とよく合致します。 定量化可能なRAM常駐ストレステストを実行します（繰り返し電源のオンオフよりも効果的です） 。テストコードと障害ハンドラをITCM/OCRAMに配置し、CRC比較を使用してAHBメモリマップから大きなフラッシュブロックを繰り返し読み出し、166/133/120MHzをスイープします。周波数が低下するにつれてエラー率が急激に低下する場合、それはタイミング/SIマージンの問題を裏付けるものです。 mcubootのCASE、ブートローダーが外部NORを消去・プログラムした場合、アプリケーションにジャンプする前にI/Dキャッシュを無効化しなければなりません。また、アプリケーションが異なるクロック/DLL/LUT/パッド設定でFlexSPIを再初期化していないかも確認してください。 最終的に166MHzのみが故障し、133MHzが安定している場合は、現在の基板の安全な動作周波数として133MHzを推奨します。166MHzが生産上必須の場合は、PCBのDQS/SCLK/SIOの長さのマッチング、インピーダンス、クロストーク、パッド駆動強度を見直し、次回の改訂でこれらの信号のテストポイントを追加する必要があります。 よろしくお願いします、 ギャビン

MC9S08QG8 代码战士 如果在 CW V6.3 或 CW 11.1 中看不到衍生产品 MC9S08QG8，那我恐怕要说再见了。我已经花了 40 天时间让这段代码运行起来了。你说没问题，但我找不到任何能在 CW 11.1 或 CD 6.3 中运行和调试的 CW V6.3 WINDOWS 11 版本。如果我错了，请告诉我。 Re: MC9S08QG8 CODE WARRIOR 你好， MC9S08QG8 设备可在 CodeWarrior v11.1 的 S08>HCS08Q 系列>MC9S08QG8 部分中找到。 我使用以下配置进行了测试： 操作系统：Windows 11 CodeWarrior：11.1 器件：板载 MC9S08QG8（DEMO9S08QG8） 调试连接：通过板载连接DEMO9S08QG8 （USB 转 BDM 接口） 顺祝商祺！

MC9S08QG8 コードウォリアー さて、派生MC9S08QG8がCW V6.3やCW 11.1で見られなければ、さようならと言わなければなりません。私はこのコードを動作させるために40日間取り組んできました。あなたは問題ないと言いましたが、CW V6.3のWINDOWS 11でCW 11.1やCD 6.3で動作・デバッグできるものは見つかりません。もし私の認識が間違っていたら、教えてください。 Re: MC9S08QG8 CODE WARRIOR こんにちは、 MC9S08QG8デバイスはCodeWarrior v11.1のS08>HCS08Qファミリのセクションで利用可能です>MC9S08QG8 以下の設定でテストを行いました。 OS: Windows 11 CodeWarrior: 11.1 デバイス: MC9S08QG8 (基板 DEMO9S08QG8) デバッグ接続:ボード内の接続 DEMO9S08QG8 (USB-to-BDMインターフェース)を介して よろしくお願いいたします。

LX2162A USXGMII 链路始终无法建立连接。 大家好， 我有一个由Solidrun公司生产的LX2162A系统模块。我目前使用的是Clearfog开发套件，但很快会换成定制的载体。 Solidrun 提供基本的 RCW/DCP/DPL，我已经验证了其功能。就我而言，dpmac3 的 DPC 适用于 SFP 笼，我可以通过 SFP DAC 电缆和各种 SFP 模块获得 XFI 连接。 RCW“rcw_2000_650_2900_3_11_0_auto”设置为SerDes1=3，SerDes2=11，我使用的是QorIQ内核（lf-6.6.52-2.2.0）和mc-utils（10.39.0），但两者都应用了一些Solidrun补丁。Uboot和其他一些东西也被打上了补丁。所有补丁均来自此处： https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 我有一套 MaxLinear GPY245-EKV-1（和 -2）开发套件，需要通过 DAC 电缆使用 USXGMII 将 phy 连接到设备。这似乎很正常。最终，这款物理芯片将被集成到 SerDes2=7 的第 6 道和第 7 道中，但我必须使用 Clearfog 上的 SFP 插槽进行测试。 Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP 我只是想配置 dpmac3 通过 DPC 使用这个 USXGMII 链路： mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; （我也尝试过 MAC_LINK_TYPE_BACKPLANE） 已通过“restool dpmac info dpmac.3”确认显示“DPMAC 以太网接口：DPMAC_ETH_IF_USXGMII”。 在Linux系统中，我添加了MaxLinear驱动程序并修复了一些问题： gpy_update_interface() 修复（LKML，Daniel Golle）。这导致 USXGMII 接口返回 -EINVAL，使 phy_state_machine 崩溃。 已修复 pcs-lynx.c 中的 lynx_pcs_config_usxgmii() 函数。同时通过 mdiobus_c45_modify() 写入 MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART)，因为该函数只写入了 MII_ADVERTISE，而从未在复制器块本身上启用 AN。这一问题与本论坛上的另一篇帖子（“LS1028A 10g-qxgmii phy 启动”）相吻合，该帖子也发现了相同的症状（MMD31.0/复制器）。控制寄存器卡在 0)，手动设置第 12 位后，AN 开始工作。 这是 DPMAC3 Linux 设备树条目： &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; 其中 `gpy245_0` 是 MDIO 节点。MDIO 到物理层的流量正常。 我在 lynx_pcs 驱动程序中添加了一个打印输出，用于显示读取结果： mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 问题： 鉴于对该 PCS 实例上的 MDIO_MMD_VEND2 寄存器的写入似乎不会持久，在 LX2162A 系列 SoC 上的 USXGMII 接受配置之前，是否需要已知的额外步骤（SerDes/PCS 块使能、协议特定的初始化或类似步骤）？协议 3 是否已针对 dpmac3 上的 USXGMII 进行了全面验证，还是主要针对 XFI 进行设计/测试？ 其他问题： 也许我不了解 GPY245 和 USXGMII。我看到有些人称之为 QXGMII，但我不知道 LX2162A 是否能够实现这个功能。 或许我需要联系 Solidrun，但他们所有的补丁似乎都没有限制 LX2162A 的功能。 谢谢！ Re: LX2162A USXGMII link never completes LX2162A 端的文档显示，它支持您所使用的路径上的 USXGMII ，但您所描述的症状看起来不像缺少 Linux pcs-lynx 写入，而更像是所选的 PCS 实例实际上仍未处于 USXGMII 应用程序模式，或者 MC 固件正在对错误的 10G PCS 选择器进行编程。 对于SerDes1 协议 3 ，LX2162A 参考手册将所有四个 SerDes1 通道列为 USXGMII / XFI，其中第一个通道为 USXGMII / XFI.3，这对应于您在 Clearfog SFP 路径上测试的 DPMAC3 用例。对于您未来的自定义载波目标， SerDes2 协议 7还将通道 6 和通道 7 记录为 USXGMII / XFI.13 和 USXGMII / XFI.14。 需要注意的是，USXGMII / XFI 条目不会自动显示为“USXGMII”。参考手册指出，在同一通道上，USXGMII 和 XFI 之间的默认值为 XFI。模式是通过协议配置寄存器 C (PCCC)选择，其 SXGMII*_XFI 位选择 0b = USXGMII 和 1b = XFI/SFI。因此，我首先要检查的不是 Linux BMCR 写入本身，而是DPMAC3 的特定 SXGMII 实例在 MC/DPC 初始化后是否清除了其 PCCC XFI 选择位。 MC 固件中出现此类故障并非 Linux PCS 驱动程序中的故障，此前也有过先例：一个 LX2162A 工单显示，MC 在 USXGMII 配置的 PCCC 中清除了错误的 10G 接口选择器，而 MC 固件工程版本 10.35.101 解决了该问题。另一张工单指出，MC 设置由 MC 固件完成，NXP 以二进制形式提供 MC。由于您使用的是 MC 10.39.0，因此您应该已经过了那个特定的旧修复程序，但您看到的故障模式仍然与“MC 没有将预期的 PCS 置于 USXGMII 模式”或“正在处理错误的 PCS 实例”一致。 接下来我会这样做： 在 Linux 进行任何更改之前，请阅读 PCCC。 在 RCW + MC + DPL/DPC 加载之后，但在 Linux PCS 驱动程序运行之前，读取 PCCC 并确认相关的 SXGMII*_XFI 位为 0。适用于 DPMAC3 / USXGMII/XFI.3预计会是第一个 SXGMII 选择器，而不是 MAC13/14 选择器。如果该位保持为 1，则该通道仍然是 XFI/SFI，并且您的 VEND2/USXGMII PCS 写入不会应用于活动的 USXGMII PCS 路径。 检查 MDIO 访问是否连接到预期的 PCS 管理端口。 SXGMII 协议控制寄存器有一个 MDEV_PORT 字段，用于匹配 MDIO 访问。手册中指出，软件在更改该字段后必须至少等待 3 个平台时钟周期，然后才能对 SGMII/PCS 目标进行 MDIO 访问。如果 MDIO 地址解码错误，写入操作可能会“无法持久”，因为您正在读取不同的或重置/默认的 PCS 窗口。 确认 USXGMII AN 寄存器只有在模式选择正确后才有意义。 USXGMII PCS CONTROL 寄存器的第 12 位具有 AUTO_NEGOTIATION_ENABLE，而 DEV_ABILITY / PARTNER_ABILITY 是 RW 寄存器。DEV_ABILITY 下供应商任意速度字段必须非零，因为零会导致自动协商失败。但如果 PCCC 仍然选择 XFI，那么这些 BMCR/能力写入并不是真正的根本问题。 除非 GPY245 板文档明确说明，否则不要将 QXGMII 视为单独的必需外部协议。 LX2162A 文档确实包含 QXGMII 协议变流器寄存器，包括 RESET/掉电控制位，例如 PD_QXGM 和 RST_QXGM。NXP 社区关于 LS1028A 的资料也提到了 10G_QXGMII Lynx SerDes 驱动程序路径。但是您选择的已记录的 LX2162A DPMAC 接口仍然是 USXGMII / XFI，NXP 文档单独指出 LX2160 类设备支持 USXGMII，“SXGMII”不是同一回事。换句话说：“QXGMII”在驱动程序/社区讨论中的引用可能描述的是内部转换器/驱动程序命名路径，不一定与您配置的USXGMII模式不同的MAC到PHY协议。 对于本次 Clearfog SFP 测试，请保持 DPC 简单。 MAC_LINK_TYPE_PHY with enet_if = "USXGMII"  是 MDIO 上管理外部 PHY 的更自然模型。除非您有意使用背板/KR 风格的流程，否则我不认为 MAC_LINK_TYPE_BACKPLANE 可以修复面向 PHY 的 USXGMII 设置。 我不会得出协议 3“主要仅限 XFI”的结论。参考手册将协议 3 记录为 DPMAC3 的 SerDes1 通道的 USXGMII / XFI。我无法从检索到的材料中证实的是，有单独的验证声明称“协议 3 + DPMAC3 + USXGMII 已通过 GPY245 验证”。更有力、有证据支持的说法是：硬件模式存在，默认为 XFI，除非 PCCC 选择 USXGMII，并且已知 MC 固件有先例对错误的 10G PCS 选择器进行编程。 针对您具体的回读： 写入 ADV=0xd601 BMCR=0x1a00 回读 ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 如果 PCS 实例未完全启用/选择用于 USXGMII，或者 MDIO 管理窗口未指向预期的 PCS 实例，则这正是我所期望的结果。在添加更多 Linux 端写入之前，我会先验证 PCCC 和 MC 日志。 LX2162A 协议 3 已记录在案，适用于 DPMAC3 上的 USXGMII / XFI，但 USXGMII 依赖于 MC/PCCC 选择 USXGMII PCS；如果 VEND2/BMCR 写入没有持久性，首先要证明 DPMAC3 的正确 PCCC 位已清除，并且 MDIO 正在寻址正确的 SXGMII PCS 实例。 Re: LX2162A USXGMII link never completes @yipingwang非常感谢您的详细解答！ 你说的都很有道理，我已经开始更多地了解这个平台了。我已经开始使用 AN13329.pdf 中的建议。部分地址和功能似乎无法正常工作（可能是版本不匹配），但至少我可以获取如下所示的 MC 日志： => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ 我尝试通过 uboot 来操作 PCCC。以下是相关内容： crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... 我真心希望 0x1ea10b0 是正确的地址。根据 LX2162ARM.pdf 文件，那*可能*是正确的地址，解码后显示： A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI 是否应该观察正确的寄存器地址（PCCC）？我还能提供其他信息吗？ 谢谢！

LX2162A USXGMIIリンクが完了しない みなさん、こんにちは。 私はSolidrun社製のLX2162A SoMを所有しています。Clearfogの開発キットを使用していますが、近いうちにカスタムキャリアに移行する予定です。 Solidrunは基本的なRCW/DCP/DPLを提供しており、その機能は確認済みです。私の場合、DPC3のDPCはSFPケージで動作し、SFP DACケーブルと様々なSFPモジュールでXFIリンクが接続されています。 RCW "rcw_2000_650_2900_3_11_0_auto" は SerDes1=3、SerDes2=11 に設定され、私は QorIQ カーネル (lf-6.6.52-2.2.0) と mc-utils (10.39.0) を使用していますが、両方に Solidrun のパッチが適用されています。U-Bootやその他のものもパッチが適用されています。すべてのパッチはここから取得されます： https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0 私はMaxLinear GPY245-EKV-1（および-2）開発キットを持っており、PHYをデバイスに接続するためにDACケーブル経由のUSXGMIIを必要としています。どうやらこれはごく普通のことらしい。最終的にはこのPHYチップはSerDes2=7のレーン6とレーン7に統合される予定ですが、テストのためにはClearfogのSFPケージを使用する必要があります。 Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP 私は、dpmac3がDPC経由でこのUSXGMIIリンクを使用するように設定しようとしているだけです。 mac@3 { link_type = "MAC_LINK_TYPE_PHY"; enet_if = "USXGMII"; }; （MAC_LINK_TYPE_BACKPLANEも試してみました） 「restool dpmac info dpmac.3」で確認済み「DPMAC イーサネットインターフェース:DPMAC_ETH_IF_USXGMII」と表示されます。 LinuxではMaxLinearドライバーを追加し、いくつかの点を修正しました: gpy_update_interface() の修正 (LKML、Daniel Golle)。これはUSXGMIIインターフェースで-EINVALを戻す際にクラッシュphy_state_machine。 pcs-lynx.c の lynx_pcs_config_usxgmii() 関数にパッチを適用しました。mdiobus_c45_modify() を介して MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) も書き込む必要があります。この関数はこれまで MII_ADVERTISE しか書き込んでおらず、レプリケータブロック自体で AN を有効にしたことがなかったためです。このギャップは、このフォーラムの別の投稿（「LS1028A 10g-qxgmii phy 起動」）と一致しており、同じ症状（MMD31.0/Replicator）が報告されています。コントロールレジスタが0に固定され、ビット12を手動で設定した後、ANが作動しました。 こちらがDPMAC3 Linuxデバイスツリーのエントリーです: &dpmac3 { managed = "in-band-status"; phy-mode = "usxgmii"; phy-handle = <&gpy245_p0>; phys = <&serdes_1 7>; status = "okay"; }; ここで、`gpy245_0`はMDIOノードです。PHYへのMDIOトラフィックは正常に動作しています。 lynx_pcsドライバーにリードバックを表示するプリントアウトを追加しました: mdio_bus 0x0000000008c0f000:00: USXGMII: wrote ADV=0xd601 BMCR=0x1a00 readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 質問： このPCSインスタンスのMDIO_MMD_VEND2レジスタへの書き込みが持続しないような場合、LX2162AファミリSoCのUSXGMIIが設定を受け入れる前に、SerDes/PCSブロックの有効化、プロトコル固有の初期化など、追加のステップが必要になるのでしょうか?プロトコル3はdpmac3上のUSXGMII向けに完全に検証済みですか、それとも主にXFI向けに設計・テストされていますか？ その他の質問： GPY245とUSXGMIIについて、私はよく理解していないのかもしれません。これをQXGMIIと呼ぶ人もいますが、LX2162Aが本当に動作するのかはわかりません。 Solidrunに問い合わせる必要があるかもしれないが、彼らのパッチはどれもLX2162Aの性能を制限するものではないようだ。 ありがとう！ Re: LX2162A USXGMII link never completes LX2162A側は、あなたが使っているパス上でUSXGMIIをサポートするドキュメントがありますが、あなたが示している症状はLinux pcs-lynxの書き込みが欠けているというより、選択したPCSインスタンスがまだUSXGMIIアプリケーションモードに入っていないか、MCファームウェアが間違った10G PCSセレクタをプログラムしているように見えます。 SerDes1プロトコル3の場合、LX2162Aリファレンスマニュアルでは4つのSerDes1レーンすべてがUSXGMII / XFIとして記載されており、最初のレーンにはUSXGMII / XFI.3と記載されています。これはClearfog SFPパス上でテストしているDPMAC3のユースケースに対応しています。将来のカスタムキャリアのターゲットとして、SerDes2プロトコル7はレーン6とレーン7をUSXGMII / XFI.13およびUSXGMII / XFI.14として記録しています。 重要な注意点は、USXGMII / XFI のエントリが自動的に「USXGMII」になるわけではないということです。リファレンス・マニュアルには、USXGMIIとXFIのレーン内のデフォルトはXFIと書かれています。モードは、プロトコル構成レジスタCであるPCCCによって選択され、そのSXGMII*_XFIビットによって0b = USXGMII、1b = XFI/SFIが選択されます。まず最初に確認すべきは、LinuxのBMCR書き込み自体ではなく、DPMAC3の特定のSXGMIIインスタンスがMC/DPC初期化後にPCCC XFIセレクトビットがクリアされているかどうかです。 この正確な故障クラスは、LinuxのPCS**ドライバ**ではなくMCファームウェアに起きている前例もあります。あるLX2162Aチケットでは、USXGMII構成でMCがPCCCの10G**インターフェースセレクタ**を間違ったクリアしている様子があり、MCのファームウェアエンジニアリングビルドバージョン10.35.101で問題が解決されました。別のチケットでは、MCの設定はMCファームウェアによって行われ、NXPはMCをバイナリとして提供していると記載されています。MC 10.39.0 を使用しているため、その特定の古い修正は適用されていないはずですが、発生している障害モードは依然として「MC が意図した PCS を USXGMII モードにしなかった」または「間違った PCS インスタンスが処理されている」というエラーと一致しています。 次に私がすること： Linuxが何かを変える前にPCCCを読んでください。 RCW + MC + DPL/DPCのロード後、LinuxのPCSドライバーが動作する前に、PCCCを読み取り、該当するSXGMII*_XFIビットが0であることを確認します。DPMAC3 / USXGMII/XFI.3 用、最初のSXGMIIセレクタを期待してください。MAC13/14のセレクタではありません。そのビットが1のままの場合、レーンは依然としてXFI/SFIであり、VEND2/USXGMII PCS書き込みはアクティブなUSXGMII PCSパスに適用されません。 MDIOアクセスが意図したPCS管理ポートに届いているか確認してください。 SXGMIIプロトコル制御レジスタにはMDIOアクセスをマッチングするためのMDEV_PORTフィールドがあり、マニュアルにはMDIOがSGMII/PCSターゲットにアクセスするまで、ソフトウェアは変更後少なくとも3プラットフォームクロックを待つ必要があると記載されています。もしMDIOアドレスデコードが間違っていると、書き込みが「永続しない」ように見えることがあります。これは異なる、またはリセット/デフォルトのPCSウィンドウを読み取っているからです。 USXGMII ANレジスタが意味を持つのは、モード選択が正しく行われた後のみであることを確認してください。 USXGMII PCS CONTROLレジスタのビット12にはAUTO_NEGOTIATION_ENABLEがあり、DEV_ABILITY / PARTNER_ABILITYはRWレジスタです。DEV_ABILITY下位ベンダーの任意の速度フィールドはゼロでなければならず、ゼロは自動交渉失敗を引き起こす可能性があります。しかし、PCCCが依然としてXFIを選択する場合、これらのBMCR/能力書き込みは本当の根本的な問題ではない。 GPY245ボードのドキュメントに明確に記載されていない限り、QXGMIIを別の必須外部プロトコルとして扱わないでください。 LX2162Aドキュメントには、PD_QXGMやRST_QXGMなどのリセット/電源停止制御ビットを含むQXGMIIプロトコルコンバータレジスタが含まれています。NXPコミュニティの資料LS1028Aでは10G_QXGMII Lynx SerDesドライバーパスも言及されています。しかし、選んでいるDPMACインターフェースLX2162Aドキュメントは依然としてUSXGMII / XFIであり、NXPのドキュメントにはLX2160クラスのデバイスがUSXGMIIをサポートし、「SXGMII」は同じ意味ではないと別途記載されています。言い換えれば、「QXGMII」という言及は、ドライバ/コミュニティの議論において、あなたが設定したUSXGMIIモードとは必ずしも異なるMAC-to-PHY契約ではなく、内部のコンバータ/ドライバの命名パスを指している可能性があります。 このClearfog SFPテストでは、DPCはシンプルなものにしてください。 MAC_LINK_TYPE_PHY enet_if = 「USXGMII」のモデルは、MDIO上で管理される外部PHYのより自然なモデルです。バックプレーン/KRスタイルのフローを意図的に使用していない限り、MAC_LINK_TYPE_BACKPLANE が PHY 側の USXGMII 設定を修正するとは期待できません。 プロトコル3が「主にXFI専用」であるとは結論付けません。リファレンス・マニュアルでは、プロトコル3をDPMAC3のSerDes1レーン用にUSXGMII / XFIとして記載しています。取得した資料から確認できないのは、「プロトコル3 + DPMAC3 + USXGMIIはGPY245で検証された」という別の検証文です。より強力な証拠に基づく主張は、ハードウェアモードは存在し、PCCCがUSXGMIIを選択しない限りデフォルトでXFIに移行すること、そしてMCファームウェアで誤った10G PCSセレクタをプログラムする前例が存在することが知られています。 具体的な読み上げ内容については、以下をご覧ください。 ADV=0xd601 BMCR=0x1a00 を書き込んだ リードバック ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000 これは、PCSインスタンスがUSXGMIIで完全に有効化・選択されていないか、MDIOマネジメントウィンドウが意図したPCSインスタンスに対応していない場合に予想される結果です。Linux側の書き込みを追加する前に、まずPCCCとMCログを確認したほうがいいでしょう。 LX2162Aプロトコル3はDPMAC3上のUSXGMII / XFIについて文書化されていますが、USXGMIIはMC/PCCCがUSXGMII PCSを選択することに依存しています。VEND2/BMCR書き込みが永続化されない場合は、まずDPMAC3の正しいPCCCビットがクリアされていること、およびMDIOが正しいSXGMII PCSインスタンスをアドレス指定していることを確認してください。 Re: LX2162A USXGMII link never completes @yipingwang詳細なご回答、本当にありがとうございます！ あなたの言うことはすべて納得でき、プラットフォームについてもっと学び始めています。AN13329.pdfに記載されているアドバイスを実践し始めました。いくつかのアドレスや機能がうまくいかず(おそらくバージョンの不一致です)、少なくとも以下に示すようにMCログは入手できます: => md 0x8340020 10 08340020: e0000006 00000021 00060000 00000000 ....!........... 08340030: 00000000 00000000 00000000 00000000 ................ 08340040: 00000000 00000000 00000000 00000000 ................ 08340050: 00000000 00000000 00000000 00000000 ................ => md 0x21e1000000 21e1000000: 4d430100 00000000 01400000 00300000 [email protected]. 21e1000010: 00000073 00000000 00000000 00000000 s............... 21e1000020: 00000000 00000000 00000000 00000000 ................ 21e1000030: 00000000 00000000 00000000 00000000 ................ => md 0x21e1400000 50 21e1400000: 202c575b 54414c50 4d524f46 5520205d [W, PLATFORM] U 21e1400010: 20545241 6e697270 61662074 64656c69 ART print failed 21e1400020: 6c61202c 6564206c 20677562 61746164 , all debug data 21e1400030: 6c697720 6562206c 69727020 6465746e will be printed 21e1400040: 206f7420 66667562 0a2e7265 6e6e7552 to buffer..Runn 21e1400050: 20676e69 6120434d 202c7070 74696177 ing MC app, wait 21e1400060: 20676e69 20726f66 6e657665 2e207374 ing for events . 21e1400070: 000a2e2e 00000000 00000000 00000000 ................ 21e1400080: 00000000 00000000 00000000 00000000 ................ 21e1400090: 00000000 00000000 00000000 00000000 ................ 21e14000a0: 00000000 00000000 00000000 00000000 ................ 21e14000b0: 00000000 00000000 00000000 00000000 ................ 21e14000c0: 00000000 00000000 00000000 00000000 ................ 21e14000d0: 00000000 00000000 00000000 00000000 ................ 21e14000e0: 00000000 00000000 00000000 00000000 ................ 21e14000f0: 00000000 00000000 00000000 00000000 ................ 21e1400100: 00000000 00000000 00000000 00000000 ................ 21e1400110: 00000000 00000000 00000000 00000000 ................ 21e1400120: 00000000 00000000 00000000 00000000 ................ 21e1400130: 00000000 00000000 00000000 00000000 ................ 私はubootを介してPCCCを操作しようと試みました。関連する事項は以下のとおりです。 crc32+ MC firmware version 10.39.0 fsl-mc: Booting Management Complex ... SUCCESS fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1) Autoboot in 3 seconds => mmc read 0x80d00000 0x6800 0x800 => fsl_mc apply dpl 0x80d00000 fsl-mc: Deploying data path layout ... SUCCESS => md.l 0x1ea10b0 1 01ea10b0: 88889991 .... 0x1ea10b0が正しいアドレスであることを心から願っています。LX2162ARM.pdfによると、それが正しい住所である可能性はあり、ビットを解読すると次のようになります: A (lane 0) bit 31 1 = XFI/SFI B (lane 1) bit 27 1 = XFI/SFI C (lane 2) bit 23 1 = XFI/SFI D (lane 3) bit 19 1 = XFI/SFI 正しいレジスタアドレス（PCCC）を観察すべきでしょうか？他に提供できる情報はありますか? ありがとう！