Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
サポート要件:i.MX8QXP C0 MEK – Yocto Scarthgapにおけるセキュアパーティションアクセスファイル破損問題 こんにちは、NXP チームの皆様、 i.MX8QXP C0 MEKで検出されたセキュアパーティション/ファイルシステムの問題について、皆様のサポートをお願いします。 以下のソフトウェアベースラインを使用しています。 商品詳細 プラットフォーム i.MX8QXP C0 MEK BSP Yocto Linux ヨクトリリース スカースギャップ カーネルバージョン 6.6.5 問題の説明: セキュアパーティションキーを正常に生成できました。しかし、Linuxファイルシステムからセキュアパーティションを使ったりアクセスしようとすると、アクセスが失敗します。場合によっては、アクセス/書き込み操作後にファイルが破損することもあります。 観察: エリアステータス 安全なパーティションキー生成 成功 生成されたキーを用いたファイルシステムアクセス 失敗する ファイル読み書き操作 不安定 ファイル整合性 ファイル破損が確認されました i.MX8QXPのYocto Linuxにおける安全なパーティションアクセスの推奨かつ正しい方法について教えていただけますか? 以下の点について、皆様のご意見をお聞かせください。 i.MX8QXP上でYocto Linuxでセキュアパーティションを作成、フォーマット、マウント、アクセスする推奨方法は何ですか? セキュアパーティションの使用に推奨される特定のファイルシステムの種類はありますか? カーネル設定、デバイスツリー、OP-TEE、またはYoctoレイヤーの変更は必要ですか? NXP社製のセキュアパーティション処理に関するリファレンス実装やドキュメントはありますか? 生成されたセキュアキーを使うために、ファイルシステムアクセスの失敗やファイル破損を避けて正しいフローは何でしょうか? 適切な実施方法について、ご検討の上、ご提案いただけますでしょうか。 Re: Support Required: Secure Partition Access-File Corruption Issue on i.MX8QXP C0 MEK – Yocto Scart こんにちは、 BSPのドキュメントを参照してください。この特定のLinuxリリースは当社のリリースに見つからないので、最も近いものを参照することをお勧めします。 つまり、カーネル 6.6.23i.MX Linuxユーザーガイド 第10.5章 ディスク暗号化加速 ファイルシステムではテストにext4を使用しているので、この方法を使うことをおすすめします。必要なカーネル設定や実際の手順についてはドキュメントをご覧ください。 よろしくお願いいたします。 アルド。
記事全体を表示
i.MX95 FlexSPIブートイメージ用のAPPコンテナソフトウェアバージョンを更新できません こんにちは、専門家の皆様。 i.MX95プラットフォームの開発を進めており、ROLLBACK_INDEX_IN_CONTAINERを使ってロールバック保護を有効にしています。 local.confに以下の変数を追加しました。 export ROLLBACK_INDEX_IN_CONTAINER = "1" この値はビルドプロセス全体に伝播され、ビルドログにはmkimage_imx8が「1」で呼び出されたことが記録されています。 eMMCブートイメージを構築する際、生成されたイメージを解析するとコンテナソフトウェアのバージョンが正しく更新されていることが確認されます。  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   しかし、FlexSPIのブートイメージ(imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi)を構築する際には、画像を解析してもデフォルトのソフトウェアバージョンが報告されます ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 iMX95/soc.mak で興味深い点に気づきました。flash_a55_flexspi のビルド時に sw_version が含まれていないのです。 flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) 私の質問は以下のとおりです。 FlexSPIのブートイメージのソフトウェアバージョンを更新するROLLBACK_INDEX_IN_CONTAINER期待されていますか? FlexSPIイメージは、ロールバックインデックスやソフトウェアバージョンを別々に設定する必要がある別のコンテナ生成フローに従っているのでしょうか? これは、i.MX95のimx-mkimageビルドフローにおける既知の制限事項または問題でしょうか? もしi.MX95でFlexSPIブートイメージのROLLBACK_INDEX_IN_CONTAINERを成功裏に有効にした方がいれば、予想されるフローや追加設定について教えていただけますか? よろしくお願いいたします! よろしくお願いいたします。 アルン・クマール Re: Unable to update APP container software version for i.MX95 FlexSPI boot image こんにちは、@arun16598さん FlexSPIイメージはAHABフォーマットの別のバリエーションではなく、まずブートコンテナを生成し、次にU-Boot/ATFコンテナを追加するという複合的なプロセスを採用しています。あなたの-sw_version 1はu-boot-atf-container.imgに設定されています。ただし、flash_a55_flexspiが最初に作成するSM/M33、OEI、SPL、FCBを含むAPPコンテナは-sw_versionオプションを通さないため、そのコンテナは依然としてSWバージョン0を表示します。ROLLBACK_INDEX_IN_CONTAINERはセカンダリのU-Boot/ATF APPコンテナを生成するために使われますが、flash_a55_flexspiが作成したプライマリAPPコンテナには渡されません。最初のFlexSPI APPコンテナに同じソフトウェアバージョンが必要な場合は、flash_a55_flexspiのmkimage_imx8呼び出しに-sw_version $(ROLLBACK_INDEX_IN_CONTAINER)を追加する必要があります。 真の AHAB アンチロールバックの強制が目的であれば、確認および設定すべき重要な設定はsw_versionだけでなくfuse_versionと-fuse_versionです。S PSDKのi.MX95アンチロールバックの例では、OEMアンチロールバックはAHABコンテナYAMLで指定されたfuse_versionを使用し、そのバージョンはその後ELEのOEM_FW_FUSEコミットプロセスを介して送信されることが明確に示されています。 よろしくお願いします、 志明
記事全体を表示
无法更新 i.MX95 FlexSPI 启动映像的 APP 容器软件版本 各位专家好, 我正在使用 i.MX95 平台,并启用ROLLBACK_INDEX_IN_CONTAINER 的回滚保护功能。 我在local.conf文件中引入了以下变量: export ROLLBACK_INDEX_IN_CONTAINER = "1" 该值会在整个构建过程中传递,构建日志证实mkimage_imx8被调用时使用了“1”。 构建eMMC 启动映像时,解析生成的镜像显示容器软件版本已正确更新。  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   然而,在构建FlexSPI 启动镜像( imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi )时,解析该镜像仍然报告默认的软件版本。 ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 我在 iMX95/soc.mak 中注意到一个有趣的地方,因为在构建 flash_a55_flexspi 时没有包含 sw_version。 flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) 我的问题是: ROLLBACK_INDEX_IN_CONTAINER是否预期会更新 FlexSPI 启动映像的软件版本? FlexSPI 镜像是否遵循不同的容器生成流程,需要单独配置回滚索引/软件版本? 这是 i.MX95 imx-mkimage版本流程中已知的限制或问题吗? 如果有人已成功在 i.MX95 上为 FlexSPI 启动映像启用ROLLBACK_INDEX_IN_CONTAINER ,能否分享一下预期流程或所需的任何其他配置? 提前感谢! 顺祝商祺! 阿伦·库马尔 Re: Unable to update APP container software version for i.MX95 FlexSPI boot image 你好@arun16598 FlexSPI 镜像不是 AHAB 格式的另一种变体,而是采用了一种组合过程,即先生成引导容器,然后附加 U-Boot/ATF 容器。您的-sw_version 1已在u-boot-atf-container.img上设置;但是,包含 SM/M33、OEI、SPL 和 FCB 的 APP 容器( flash_a55_flexspi首先创建)没有传递-sw_version选项,因此该容器仍然显示SW 版本:0。ROLLBACK_INDEX_IN_CONTAINER用于生成辅助 U-Boot/ATF APP 容器,但它没有传递给flash_a55_flexspi创建的主 APP 容器。如果第一个 FlexSPI APP 容器需要相同的软件版本,则还必须将-sw_version $(ROLLBACK_INDEX_IN_CONTAINER)添加到flash_a55_flexspi中的 mkimage_imx8 调用中。 如果目标是真正实现 AHAB 防回滚强制执行,则需要验证和配置的关键设置是fuse_version和-fuse_version ,而不仅仅是sw_version 。S PSDK 的 i.MX95 防回滚示例明确指出,OEM 防回滚使用 AHAB 容器 YAML 中指定的fuse_version ,然后通过 ELE 的OEM_FW_FUSE提交过程提交该版本。 此致, 志明
記事全体を表示
Unable to update APP container software version for i.MX95 FlexSPI boot image Hello Experts, I'm working on the i.MX95 platform and enabling rollback protection using ROLLBACK_INDEX_IN_CONTAINER. I introduced the following variable in my local.conf: export ROLLBACK_INDEX_IN_CONTAINER = "1" This value is propagated through the build, and the build log confirms that mkimage_imx8 is invoked with "1" When building an eMMC boot image, parsing the generated image shows the container software version updated correctly.  if [ 1 ]; then \ ./../mkimage_imx8 -soc IMX9 -cntr_version 2 -sw_version 1 -c \ -ap bl31.bin a55 0x8A200000 \ -ap u-boot-hash.bin a55 0x90200000 \ -ap tee.bin a55 0x8C000000 \ -out u-boot-atf-container.img; \   However, when building the FlexSPI boot image (imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi), parsing the image still reports the default SW version ./mkimage_imx8 -soc IMX9 -parse imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi SOC: IMX9 Input container binary to be parsed: imx-boot-imx95-19x19-verdin-fspi.bin-flash_a55_flexspi ********************************* * * * APP CONTAINER 1 * * * ********************************* Length: 0X320 (800) Tag: 0X87 Version: 0X2 Flags: 0X10 Num images: 6 Fuse version: 0 SW version: 0X0 Sig blk offset: 0X310 I noticed an interesting thing in iMX95/soc.mak as there is no sw_version included during the build for flash_a55_flexspi flash_a55_flexspi: $(MKIMG) $(AHAB_IMG) $(MCU_IMG) $(SPL_A55_IMG) $(OEI_IMG_M33) fcb.bin u-boot-atf-container.img ./$(MKIMG) -soc IMX9 -cntr_version $(CTNR_VERSION) $(XSPI_FAST_HASH) -dev flexspi -append $(AHAB_IMG) -c $(OEI_OPT_M33) -msel $(MSEL) \ -m33 $(MCU_IMG) 0 $(MCU_TCM_ADDR) \ -ap $(SPL_A55_IMG) a55 $(SPL_LOAD_ADDR_M33_VIEW) $(V2X_DUMMY) -fcb fcb.bin $(FCB_LOAD_ADDR) -out flash.bin $(call append_container,u-boot-atf-container.img,1) $(call append_fcb) My questions are: Is ROLLBACK_INDEX_IN_CONTAINER expected to update the software version for FlexSPI boot images? Does the FlexSPI image follow a different container generation flow where the rollback index/software version must be configured separately? Is this a known limitation or issue in the i.MX95 imx-mkimage build flow? If anyone has successfully enabled ROLLBACK_INDEX_IN_CONTAINER for FlexSPI boot images on i.MX95, could you please share the expected flow or any additional configuration required? Thanks in advance! Best Regards, Arun Kumar Re: Unable to update APP container software version for i.MX95 FlexSPI boot image Hi @arun16598  The FlexSPI image is not another variant of the AHAB format, but it employs a combined process of first generating the boot container, then appending the U-Boot/ATF container. Your -sw_version 1 is set on u-boot-atf-container.img; however, the APP container containing SM/M33, OEI, SPL, and FCB—which flash_a55_flexspi creates first—does not pass the -sw_version option, so that container still displays SW version: 0. ROLLBACK_INDEX_IN_CONTAINER is used to generate the secondary U-Boot/ATF APP container, but it is not passed to the primary APP container created by flash_a55_flexspi. If the same software version is required for the first FlexSPI APP container, -sw_version $(ROLLBACK_INDEX_IN_CONTAINER) must also be added to the mkimage_imx8 invocation in flash_a55_flexspi. If the goal is true AHAB anti-rollback enforcement, the key settings to verify and configure are fuse_version and -fuse_version, not just sw_version. The SPSDK’s i.MX95 anti-rollback example clearly states that OEM anti-rollback uses the fuse_version specified in the AHAB container YAML, and the version is subsequently submitted via the ELE’s OEM_FW_FUSE commit process. Best Regards, Zhiming
記事全体を表示
需要支持:i.MX8QXP C0 MEK 上的安全分区访问文件损坏问题 – Yocto Scarthgap 您好,NXP团队: 我们需要您协助解决在i.MX8QXP C0 MEK上发现的安全分区/文件系统问题。 我们采用以下软件基线: 商品详情 平台 i.MX8QXP C0 MEK BSP Yocto Linux Yocto 版本 斯卡斯盖普 内核版本 6.6.5 问题描述: 我们已成功生成安全分区密钥。但是,当我们尝试从 Linux 文件系统使用/访问安全分区时,访问失败。在某些情况下,文件在访问/写入操作后也会损坏。 观察: 区域状态 安全分区密钥生成 成功的 使用生成的密钥访问文件系统 失败 文件读/写操作 不稳定 文件完整性 发现文件损坏 请问您能否帮助我们了解在 Yocto Linux for i.MX8QXP 中处理安全分区访问的推荐和正确方法? 我们需要您就以下几点提供指导: 在 i.MX8QXP 上的 Yocto Linux 中,创建、格式化、挂载和访问安全分区的推荐方法是什么? 对于安全分区,是否有推荐的特定文件系统类型? 是否需要对内核配置、设备树、OP-TEE 或 Yocto 层进行任何更改? NXP是否有任何关于安全分区处理的参考实现或文档? 如何正确使用生成的安全密钥,才能避免导致文件系统访问失败或文件损坏? 请您审阅并提出正确的实施方案。 Re: Support Required: Secure Partition Access-File Corruption Issue on i.MX8QXP C0 MEK – Yocto Scart 你好, 您可以参考我们的 BSP 文档,但我无法在我们的版本列表中找到这个特定的 Linux 版本,因此我建议您参考最接近的可用版本。 例如,内核 6.6.23 i.MX Linux 用户指南第 10.5 章磁盘加密加速 对于文件系统,我们在测试中使用 ext4,所以我建议也使用 ext4,请查看文档了解所需的内核配置和实际操作步骤。 此致敬礼/Saludos, 阿尔多。
記事全体を表示
Support Required: Secure Partition Access-File Corruption Issue on i.MX8QXP C0 MEK – Yocto Scarthgap Hi NXP Team, We need your support regarding a secure partition/file system issue observed on i.MX8QXP C0 MEK. We are using the below software baseline: Item Details Platform i.MX8QXP C0 MEK BSP Yocto Linux Yocto Release Scarthgap Kernel Version 6.6.5 Issue Description: We are able to generate the secure partition key successfully. However, when we try to use/access the secure partition from the Linux file system, the access fails. In some cases, the file also gets corrupted after access/write operations. Observation: Area Status Secure partition key generation Successful File system access using the generated key Failing File read/write operation Not stable File integrity File corruption observed Could you please help us understand the recommended and correct way to handle secure partition access in Yocto Linux for i.MX8QXP? We need your guidance on the below points: What is the recommended method to create, format, mount, and access a secure partition in Yocto Linux on i.MX8QXP? Is there any specific file system type recommended for secure partition usage? Are any kernel configuration, device tree, OP-TEE, or Yocto layer changes required? Is there any NXP reference implementation or document available for secure partition handling? What is the correct flow to use the generated secure key without causing file system access failures or file corruption? Request you to please review and suggest the correct implementation approach. Re: Support Required: Secure Partition Access-File Corruption Issue on i.MX8QXP C0 MEK – Yocto Scart Hello, You may refer to our BSP documentation, I cannot find this specific Linux release in our releases, so I may recommend to refer to the closest one available. i.e kernel 6.6.23 i.MX Linux User's Guide chapter 10.5 Disk encryption acceleration For the file system we use ext4 for our testing so I would recommend using this one, please have a look to the documentation for the kernel configuration needed and the actual steps to follow. Best regards/Saludos, Aldo.
記事全体を表示
Example SJA1110 FreeRTOS lwIP S32G-VNP-RDB2 S32DS 3.5 RTD 1.0.2 ********************************************************************************* * Detailed Description: * Updated the example lwip_FreeRTOS_SJA1110 for board S32G-VNP-RDB2 * to enable ping from the command window, from all applicable ports * *ping 192.168.0.210 * *Pinging 192.168.0.210 with 32 bytes of data: *Reply from 192.168.0.210: bytes=32 time=2ms TTL=255 *Reply from 192.168.0.210: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.210: bytes=32 time=1ms TTL=255 *Reply from 192.168.0.210: bytes=32 time=1ms TTL=255 * *Ping statistics for 192.168.0.210: * 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: * - SW10[1]: On, SW10[2]: Off * - SW12[1]: On, SW12[2]: Off * * Configuration: * - Updated switch configuration * - Updated phy configuration * - Fixed Mcu/McuModuleConfiguration/McuPowerControlUnit - 1V8 and 2V5 * - Fixed Eth configuration * * * * - TCPIP stack: enabled UDP_ECHO, etc. * - Changed IP address to 192.168.0.210 * - Added DIO * - Added nvm_metadata * - MAC learning is disabled * - The example includes two flash images for Port 4 SGMII speed * configuration towards the S32G: * - flash_image_2G5.bin (tested) * - flash_image_1G.bin (not tested) * * 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 debug stuff * - Commented out the code that initializes 2nd switch * * ----------------------------------------------------------------------------- * Test HW: S32G-VNP-RDB2 REV E * MCU: SJA1110A * Debugger: Lauterbach TRACE32 * Target: RAM or external FLASH (flash_image.bin generated) * EVB connection: any port <-> RDDRONE T1ADAPT (on ports where applicable) <-> USB-to-Ethernet adapter <-> Laptop DELL, Windows 11
記事全体を表示
[i.MX95/AAOS16]ブリングアップ支援 ハードウェア: i.MX95 15x15 SW: AAOS16_1.3.0 ほぼすべてのファイルにパッチを適用しました。 しかし、カーネル起動の問題は依然として残っている。 リチャード・キムのサポートが必要です。 Re: [i.MX95/AAOS16] Bringup support こんにちは、 @Jaeheon-Sim_Mobis さん、 改訂版ガイドラインを添付いたしましたのでご確認ください。 また、パッチされたすべてのファイルを正しいディレクトリ構造で添付しているので、ソースツリーで直接上書きできるようにしています。 よろしくお願いします。
記事全体を表示
MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello, I am investigating WUU wake-up behavior from Deep Power-Down mode on the FRDM-MCXA266 board. Environment: - MCU: MCXA266 - Board: FRDM-MCXA266 - SDK Example project: frdmmcxa266_power_mode_switch_ll_mcxa - SDK version: 26.6.000 - Development environment: MCUXpressoIDE_25.6.136 I added the following code near the beginning of main() to read the reset and wake-up status before BOARD_InitHardware() is called. /******************************************************************************* * Variables ******************************************************************************/ char *const g_modeNameArray[] = APP_POWER_MODE_NAME; char *const g_modeDescArray[] = APP_POWER_MODE_DESC; uint32_t resetCount; uint32_t resetStatus; uint32_t resetStickyStatus; uint32_t wakeupResource; uint32_t wuuWakeupPinsFlag; /******************************************************************************* * Code ******************************************************************************/ int main(void) { uint32_t freq; app_power_mode_t targetPowerMode; bool needSetWakeup = false; // --- START ADDED CODE --- resetStatus = CMC_GetSystemResetStatus(CMC); resetStickyStatus = CMC_GetStickySystemResetStatus(CMC); CMC_ClearStickySystemResetStatus(CMC, resetStickyStatus); wakeupResource = CMC_GetWakeupSource(CMC); wuuWakeupPinsFlag = WUU_GetExternalWakeUpPinsFlag(WUU0); WUU_ClearExternalWakeUpPinsFlag(WUU0, wuuWakeupPinsFlag); // --- END ADDED CODE --- BOARD_InitHardware(); // --- START ADDED CODE --- DbgConsole_Printf("CMC_GetSystemResetStatus(CMC) = 0x%x\r\n", resetStatus); DbgConsole_Printf("CMC_GetStickySystemResetStatus(CMC) = 0x%x\r\n", resetStickyStatus); DbgConsole_Printf("CMC_GetWakeupSource(CMC) = 0x%x\r\n", wakeupResource); DbgConsole_Printf("WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x%x\r\n", wuuWakeupPinsFlag); // --- END ADDED CODE --- APP_SetVBATConfiguration(); APP_SetSPCConfiguration(); APP_InitWaketimer(); The complete relevant output is: ``` Normal Boot. ########################### Power Mode Switch Demo ########################### Core Clock = 240000000Hz Power mode: Active Select the desired operation Press A to enter: Active mode Press B to enter: Sleep mode Press C to enter: DeepSleep mode Press D to enter: PowerDown mode Press E to enter: DeepPowerDown mode Waiting for power mode select... Deep Power Down: The whole VDD_CORE voltage domain is power gated. Please select wakeup source: Press A to select TIMER as wakeup source; Press B to select WAKE-UP-BUTTON as wakeup source; Waiting for wakeup source select... Wakeup Button Selected As Wakeup Source. Please press SW2 to wakeup. Isolate power domains: VDD_USB. CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 Normal Boot. ``` At the initial startup, the following values were printed: CMC_GetSystemResetStatus(CMC) = 0x110 CMC_GetStickySystemResetStatus(CMC) = 0x110 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 I then selected Deep Power-Down mode, selected WAKE-UP-BUTTON as the wake-up source, and pressed SW2. The MCU successfully woke up, and the application restarted, but the following values were printed: CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 My interpretation of the CMC reset status is: - 0x00004010: Software Reset + Warm Reset - 0x00004011: Software Reset + Warm Reset + Deep Power-Down Wake-up Reset If this interpretation is correct, the sticky status appears to indicate that a Deep Power-Down wake-up reset occurred first, followed by a software warm reset. I checked the application startup code, system_MCXA266.c, and the example sources, but I could not find NVIC_SystemReset(), SYSRESETREQ, or an SCB->AIRCR write. I also added a counter to SystemInitHook() using a retained NOLOAD variable. SystemInitHook() was executed only once after wake-up, so I could not find evidence of a software reset after SystemInit(). My questions are: Is SRS = 0x4010 and SSRS = 0x4011 expected after a WUU wake-up from Deep Power-Down? Does the MCXA266 Boot ROM or Extended Bootloader issue a software warm reset before the application starts? What is the recommended method for identifying which WUU pin caused the Deep Power-Down wake-up? My current interpretation of the CMC reset status is as follows, but please correct me if I have misunderstood the bit definitions: English is not my first language, so please let me know if any part of my explanation is unclear. Thank you. MCXA Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello @ka-2020  Thanks for your question. I will reproduce the test on my side using the same setup and investigate the behavior. Once I have the results, I will get back to you with my findings and answers to all of your questions. Thank you for your patience and support. BR Alice
記事全体を表示
HSEをインストールしたS32K311:ソフトウェアクラッシュとMCUリセット、デバッガの接続ができません NXPチームの皆様、こんにちは。 バックグラウンド: MCU: S32K311 AUTOSAR RTD MCAL: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 HSE FW (フルメモリ): s32k3x1_hse_fw_0.12.0_2.55.0_pb250225.bin 詳細な調査報告書はPDFファイルで添付されています。 主な争点 ソフトウェアがクラッシュし、MCUはClock_Ip_DistributePll()でリセットされます。さらに、デバッガーが接続できない場合もあります。 デバッガをホットアタッチしようとした際、リセット理由としてHSE_CLK_FAILが報告されることがありました。 上記の手順、IVTおよびDCFの記録を確認し、この問題がなぜ起こっているのか、その解決策についてもご確認いただけますか。追加情報が必要な場合はお知らせください。 HSEの設置手順、IVTの設定、DCF記録を確認し、なぜこの問題が発生しているのか、またどのように解決できるのか教えていただけますか? 追加情報が必要な場合はお知らせください。 よろしくお願いします、 シュバム・パルデシ Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 70秒と20秒は、リセットからHSE_STATUS_INIT_OKまでの時間です。つまり、基本的に起動時間だけが含まれているということですね? どのデバイスでも同じように動作しますか? Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach こんにちは、 @davidtosenovjan 当社のソフトウェアはFBLとAPPLで構成されており、どちらも同じ機能リセット機構を使用しています。 APPLがリセットを開始すると、この問題は発生しません。 FBLがリセットを開始すると、Clock_Ip_DistributePll()内でAPPL起動時にソフトウェアがクラッシュします。 当初は、Mcu_InitClock() の後、Mcu_DistributePllClock() の前に HSE_STATUS_INIT_OK のチェックを追加しました。これにより墜落は回避された。しかし、HSE_STATUS_INIT_OKが設定されるまでには約20秒かかり、その後、実際のAPPLの起動が続行されました。 本日、添付のスクリーンショットに示すように、HSE_STATUS_INIT_OK チェックを APPL の Mcu_Init() より前の段階に移動しました。 この手順を実行すると、HSE_STATUS_INIT_OKがほぼ即座に設定され、クラッシュは発生しなくなります。 以下の点を明確にしていただけますか? FBLとAPPLは同じリセットメカニズムを使用しているにもかかわらず、なぜこの問題はFBLによってリセットが開始された場合にのみ発生するのでしょうか? Mcu_InitClock() の後に HSE_STATUS_INIT_OK をチェックすると約 20 秒かかるのに、Mcu_Init() の前にチェックするとほぼすぐに利用可能になるのはなぜですか? FBLではHSE_STATUS_INIT_OKチェックが不要なのに、APPLの起動時には必要となるのはなぜですか? 明確な根本原因の説明と推奨される初期化手順を提示してください。現在のソリューションが堅牢であり、本番環境で問題を引き起こさないことを確認する必要があります。 追加の詳細情報や時計の設定に関する詳細情報が必要な場合はお知らせください。 よろしくお願いします、 シュバム・パルデシ
記事全体を表示
Regarding 8M Plus Real time Accuracy Hi,  We would like to lean more about 8M Plus capabilities regarding its real-time applications. Are there any test reports or related materials available concerning TSN or real-time performance, or jitter? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy Area Available material What it contains Real-time CPU/RTOS latency Harpoon User’s Guide Measured real-time latencies on i.MX 8M Plus / Zephyr , including IRQ latency and task latency in ns. Example results: no-load IRQ latency min/avg/max/stddev = 625 / 796 / 11,125 / 1,798 ns ; task latency = 2,583 / 2,671 / 13,041 / 6,045 ns . Under Linux CPU + memory load, IRQ latency = 625 / 798 / 4,250 / 4,674 ns , and task latency = 2,583 / 2,670 / 14,333 / 10,407 ns . Real-time benchmark method Harpoon User’s Guide — rt latency application Defines the benchmark as the time delta between hardware IRQ events and software actions, measured with a hardware timer and sub-microsecond precision. TSN capability i.MX 8M Plus product / reference material i.MX 8M Plus includes dual Gb Ethernet, with one Ethernet supporting TSN, and uses the integrated 800 MHz Arm Cortex-M7 for industrial real-time control. TSN hardware standards i.MX 8M Plus Reference Manual TSN support includes IEEE 802.1Qbv Time-Aware Shaper , 802.1Qav Credit-Based Shaper , IEEE 1588v2 PTP , and the Ethernet block implements 802.1Qbv-2015 , 802.3br , and 802.1Qbu frame preemption-related TSN functions. TSN test / validation environment Real-Time Edge User Guide Describes a TSN test environment for evaluating i.MX 8M Plus TSN capabilities, including traffic generation/analysis and monitoring of latency, jitter, and synchronization accuracy. TSN jitter / latency example Real-Time Edge User Guide — TSN endpoint sample app Provides TSN endpoint statistics including traffic latency min/mean/max and notes latency around 503 µs with latency jitter around 300 ns in the shown example. TSN application demo AN13588 Demonstrates a GenAVB/TSN real-time control application. It describes a 2 ms cycle , a 400 µs reserved/guaranteed control-traffic window , and a statistics thread for scheduling, processing timing, traffic correctness, and latency. TSN 802.1Qbv demo AN13995 Demonstrates TSN 802.1Qbv using i.MX 8M Plus and explains how time-aware shaping uses fixed repeating cycles to provide deterministic latency; it also includes Linux  tc  /  taprio  configuration examples.   Re: Regarding 8M Plus Real time Accuracy @yipingwang  Thank you for providing the information. Could you also please provide us with information about the iMX8M Plus EVK? Thanks. Re: Regarding 8M Plus Real time Accuracy We understand that no public "real-time performance report" has been officially released for i.MX95 EVK. However, NXP does internally perform real-time benchmarking on i.MX95 platforms. Internal benchmark documents indicate that cyclictest and EtherCAT performance evaluations have been executed on i.MX95 LPDDR5 EVKs running Real-Time Edge software with PREEMPT_RT Linux. Reported examples include a maximum cyclictest latency of approximately 38 µs during a 6-hour stress-ng test and EtherCAT filtered maximum jitter of approximately 12 µs under the documented test conditions. Because real-time performance depends strongly on BSP version, kernel configuration, CPU isolation, workload, and network traffic, these values should be considered reference measurements rather than guaranteed application-level limits.   Please refer to https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf as supported benchmarking platforms and provide detailed cyclictest, stress, and rt_latency procedures. Re: Regarding 8M Plus Real time Accuracy Our distributor informed us that there is currently no official performance report available for the NXP i.MX95 EVK regarding real-time performance or jitter. However, they also provided documentation describing the testing methodology (e.g., cyclictest) for evaluating real-time latency. This leads to some confusion on our side. Since a standardized testing methodology exists, we assume that such tests must have been performed internally—at least on the reference EVK platform. Therefore, we would like to clarify: Has NXP conducted any internal measurements of real-time performance (e.g., latency, jitter) on the i.MX95 EVK? If so, are there any reference or baseline results that could be shared? We understand that real-time performance may vary depending on system configuration and workload. However, even a baseline result under controlled conditions (e.g., default BSP, minimal load) would be very helpful for initial evaluation. Thank you for your support. Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (Real-Time Edge Software User Guide) (https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf) . Real-Time Edge Software (most relevant) NXP's Real-Time Edge Software officially supports the i.MX8M Plus EVK and includes: PREEMPT_RT Linux TSN stack IEEE 802.1AS (gPTP) synchronization TSN traffic shaping and scheduling EtherCAT, OPC-UA, CAN-related industrial protocols Heterogeneous real-time operation using Cortex-A53 + Cortex-M7 The internal document REALTIMEEDGEUG states that Real-Time Edge Software provides: Real-time networking (TSN) Real-time Linux (PREEMPT_RT) Pure RTOS/Bare-metal options Jailhouse partitioning Industrial protocol support Support for i.MX 8M Plus LPDDR4 EVK NXP Application Note AN13995 – TSN 802.1Qbv Demonstration using i.MX 8M Plus The Real-Time Edge Six Pack materials describing PREEMPT_RT + TSN support Re: Regarding 8M Plus Real time Accuracy @yipingwangThank you very much for the information you provided.
記事全体を表示
TJA1445のFlexCAN(S32K348)ビットタイミング計算 こんにちは、 設定設定のために MPC5xxx/S32Kxx/LPCxxxx: CAN / CAN FDビットタイミング計算 ナレッジベースドキュメントから添付ファイルをダウンロードしました。 しかし、カリキュレータで TJA1445 トランシーバーのオプションが見つからず、S32K348ボードの設定を進めることができません。 TJA1445トランシーバーを含むカリキュレータの最新バージョンがあるか教えていただけますか?もしそうでなければ、既存のドロップダウンリストからどの代替トランシーバが最も互換性があるか、または最も近い選択肢を選ぶべきでしょうか? ご協力ありがとうございます! よろしくお願いいたします。 Re: FlexCAN(S32K348) bit timing calculation for TJA1445 こんにちは、 @Penta7 さん。 トランシーバを選択することで伝播遅延パラメータも読み込みますが、ユーザー値で簡単に上書きできます。TJA1445のデータシートを参照して、propTXRXを220 nsに上書きできます: よろしくお願いします、 ジュリアン Re: FlexCAN(S32K348) bit timing calculation for TJA1445 TJA14XXファミリー向けにFlexGUIを試しましたか?ご要望のタイミング設定情報があるかどうかはわかりません 現在のバージョンはNXP_TJA14XX_GUI_1.1.0です。NXP公式ウェブサイトからダウンロード可能です
記事全体を表示
GUIGuider-2.0.0がCコードを生成すると、生成されたフォルダの下のフォルダは完全に空になります。 Windows 11でGUIGuider-2.0.0を使用してCコードを生成すると、ログには生成が成功したと表示されているにもかかわらず、「generated」フォルダ以下のフォルダがすべて空になります。これは、コードを完全に生成できるGUI-Guider-1.10.1-GAと同じコンピュータで発生します。ウイルス対策ソフトを無効にしたり、管理者として実行したりするなど、さまざまな方法を試しましたが、問題は解決しません。同じ問題に遭遇した方はいらっしゃいますか?何かご助言いただければ幸いです。 21:10:08 INFO [gg_event] gg_event_layer_sys.c が生成されました 21:10:08 INFO [gg_event] gg_event_layer_top.c が生成されました 21:10:08 INFO [gg_event] gg_event_layer_bottom.c が生成されました 21:10:08 INFO update-sdk 開始 21:10:08 INFOターゲットエグゼキュータが初期化されました 21:10:08成功SDKテンプレートが正常に更新されました 21:10:08成功操作は0.00秒で完了しました 21:10:08 INFO [gg_event] gg_event_screen.c が生成されました 21:10:08 INFO [gg_event] gg_event.h が生成されました 21:10:08 INFO [gg_event] 生成が完了しました 21:10:08成功=== コード生成が正常に完了しました ===
記事全体を表示
RTCの例がfrdm_mcxw72ボード上でうまく構築できません こんにちは、 RTCの例は私のワークベンチではうまく構築できません。基本的な設定情報は以下のスナップショットで確認できます 以下はビルドプロセス中のログメッセージです: 設定タスク開始... ワークスペースはd:\ABC\rtcです Zephyrのデフォルトモジュール(Zephyrベース(キャッシュ))を読み込み中。 -- アプリケーション:D:/ABC/rtc -- CMakeバージョン:3.30.0 -- Python3 を見つけました:C:/users/Xpeng/.mcuxpressotools/.mcux-venv-3.12/Scripts/python.exe(適切なバージョン「3.12.12」が見つかり、最低必要条件は「3.12」です)発見されたコンポーネント:インタプリタ -- キャッシュファイルは以下のアドレスに書き込まれます:D:/ABC/zephyr/zephyr/.cache -- Zephyrバージョン:4.4.1(D:/ABC/zephyr/zephyr) -- Found west(適切なバージョン「1.5.0」が見つかり、最低必要条件は「0.14.0」) -- ボード:frdm_mcxw72、予選:mcxw727c -- ホストツールを見つけました:zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 発見ツールチェーン:zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- 発見されたdtc: C:/Users/Xpeng/.mcuxpressotools/dtc-1.6.1/tools/usr/bin/dtc.exe(適切なバージョン「1.6.1」が見つかりました)最低必要値は「1.4.6」です。 -- BOARD.dts が見つかりました:D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72.dts -- デバイスツリーオーバーレイ発見:D:/ABC/rtc/boards/frdm_mcxw72.overlay -- 生成されたzephyr.dts:D:/ABC/rtc/build/zephyr/zephyr.dts -- 生成されたピクルドedt: D:/ABC/rtc/build/zephyr/edt.pickle -- 生成devicetree_generated.h: D:/ABC/rtc/build/zephyr/include/generated/zephyr/devicetree_generated.h Parsing D:/ABC/zephyr/zephyr/Kconfig ロード済み設定 'D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72_defconfig' マージされた構成 'D:/ABC/rtc/prj.conf' 設定は「D:/ABC/rtc/build/zephyr/.config」に保存されます Kconfigヘッダーは'D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h'に保存されています。 -- Found GnuLd: C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd.exe(foundバージョン「2.43.1」) -- Cコンパイラ識別はGNU 14.3.0です -- CXXコンパイラの識別はGNU 14.3.0です -- ASMコンパイラ識別はGNUです -- 見つけたアセンブラ:C:/ユーザー/Xpeng/Zephyr-SDKs-1.0.1/gnu/Arm-Zephyr-eabi/bin/Arm-Zephyr-eabi-gcc.exe -- D:/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/ でデバイスMCXW727Cを探しています -- デバイスフォルダーを見つけました:D:/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -- 見つけたgen_kobject_list:D:/ABC/Zephyr/Zephyr/scripts/build/gen_kobject_list.py -- 設定完了(26.9秒) -- 生成完了(1.8秒) -- ビルドファイルは以下の通りに書き込まれています: D:/ABC/rtc/build 終了コード0で終了する設定 * ターミナルはタスクで再利用されます。どのキーを押しても閉じてください。 * タスクを実行中: CMake: build ワークスペースはd:\ABC\rtcです ビルドタスク開始...... C:\ユーザー\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.EXE --build D:/ABC/rtc/build --target all -- [1/156] include/genated/zephyr/version.h 生成中 -- Zephyrバージョン:4.4.1(D:/ABC/zephyr/zephyr)、ビルド:v4.4.1 [2/156] 雑多/生成/syscalls.json、雑多/生成/struct_tags.json [3/156] include/generated/device-api-sections.ld、include/generated/device-api-sections.cmake を生成中 [4/156] include/generated/zephyr/driver-validation.h 生成中 [5/156] include/generated/zephyr/kobj-types-enum.h, include/generated/zephyr/otype-to-str.hを生成中,include/generated/zephyr/otype-to-size.h [6/156] include/generated/zephyr/syscall_dispatch.c、include/generated/zephyr/syscall_exports_llext.cの生成、syscall_weakdefs_llext.c、include/genated/zephyr/syscall_list.h [7/156] ビルドCオブジェクト zephyr/lib/heap/CMakeFiles/heap_constants.dir/heap_constants.c.obj [8/156] 生成中.../../include/generated/zephyr/heap_constants.h [9/156] ビルディングCオブジェクト zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj [10/156] include/genent/zephyr/offsets.h 生成中 [11/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/isr_tables.dir/isr_tables.c.obj [12/156] Cオブジェクトのビルディング CMakeFiles/app.dir/src/main.c.obj [13/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_packaged.c.obj [14/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/libc/validate_libc.c.obj [15/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/printk.c.obj [16/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/sem.c.obj [17/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/thread_entry.c.obj [18/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/heap/heap.c.obj [19/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/clock.c.obj [20/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/dec.c.obj [21/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/hex.c.obj [22/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_complete.c.obj [23/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/set.c.obj [24/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/timeutil.c.obj [25/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/bitmask.c.obj [26/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/os/assert.c.obj [27/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj [28/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/last_section_id.c.obj [29/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/rb.c.obj [30/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/ring_buffer.c.obj [31/156] ASMオブジェクトのビルディング zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/mcxw72_platform_init。S.obj [32/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt.c.obj [33/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/bitarray.c.obj [34/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt_common.c.obj [35/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/arch__common.dir/init.c.obj [36/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/soc.c.obj [37/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/subsys/mem_mgmt/mem_attr.c.obj [38/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr.dir/subsys/traceing/tracing_none.c.obj [39/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj [40/156] ASMオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi_on_reset をビルディングすること。S.obj [41/156] ビルディングCオブジェクト zephyr/arch/common/CMakeFiles/arch__common.dir/xip.c.obj [42/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault_s.S.obj [43/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/fatal.c.obj [44/156] linker_zephyr_pre0.cmd [45/156] ビルディング Cオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi.c.obj [46/156] ビルディング ASMオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/reset.S.obj [47/156] ビルディング Cオブジェクト zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/tls.c.obj [48/156] ビルディング ASMオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/vector_table.S.obj [49/156] ビルディング Cオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fpu.c.obj [50/156] リンクC静的ライブラリ zephyr\arch\common\libisr_tables.a [51/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/svc.S.obj [52/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/scb.c.obj [53/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault.c.obj [54/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/prep_c.c.obj [55/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_manage.c.obj [56/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread.c.obj [57/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/swap_helper。S.obj [58/156] ASMオブジェクトのビルディング zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/__aeabi_read_tp。S.obj [59/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/cpu_idle.c.obj [60/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/exc_exit.c.obj [61/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_init.c.obj [62/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread_abort.c.obj [63/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/isr_wrapper.c.obj [64/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_core_mpu.c.obj [65/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/cortex_m/cmse/CMakeFiles/arch__arm__core__cortex_m__cmse.dir/arm_core_cmse.c.obj [66/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu_regions.c.obj [67/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/assert.c.obj [68/156] ビルディングCオブジェクト zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu.c.obj [69/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/cbprintf.c.obj [70/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/chk_fail.c.obj [71/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/errno_wrap.c.obj [72/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/exit.c.obj [73/156] ビルディングCオブジェクト zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/time/time.c.obj [74/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/locks.c.obj [75/156] ビルディングCオブジェクト zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/fnmatch.c.obj [76/156] ビルディングCオブジェクト zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/abort.c.obj [77/156] ビルディングCオブジェクト zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/stdio.c.obj [78/156] ビルディングCオブジェクト zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/malloc.c.obj [79/156] ビルディングCオブジェクト zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getentropy.c.obj [80/156] ビルディングCオブジェクト zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getopt_shim.c.obj [81/156] ビルディングCオブジェクト zephyr/drivers/clock_control/CMakeFiles/drivers__clock_control.dir/clock_control_mcux_scg_k4.c.obj [82/156] ビルディングCオブジェクト zephyr/drivers/console/CMakeFiles/drivers__console.dir/uart_console.c.obj [83/156] ビルディングCオブジェクト zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/common.c.obj [84/156] Building C object zephyr/drivers/gpio/CMakeFiles/drivers__gpio.dir/gpio_mcux.c.obj [85/156] ビルディングCオブジェクト zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/pinctrl_nxp_port.c.obj [86/156] ビルディングCオブジェクト zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_utils.c.obj [87/156] ビルディングCオブジェクト zephyr/drivers/serial/CMakeFiles/drivers__serial.dir/uart_mcux_lpuart.c.obj [88/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common.c.obj [89/156] ビルディングCオブジェクト zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/sys_clock_init.c.obj [90/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common/fsl_common_arm.c.obj [91/156] ビルディングCオブジェクト zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/mcux_lptmr_timer.c.obj [92/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k/fsl_ccm32k.c.obj [93/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc/fsl_cmc.c.obj [94/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu/fsl_elemu.c.obj [95/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr/fsl_lptmr.c.obj [96/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat/fsl_vbat.c.obj [97/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/system_MCXW727C_cm33_core0.c.obj [98/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart/fsl_lpuart.c.obj [99/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu/fsl_wuu.c.obj [100/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj [101/156] ビルディングCオブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [102/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj [103/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/banner.c.obj [104/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/busy_wait.c.obj [105/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/device.c.obj [106/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/version.c.obj [107/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/errno.c.obj [108/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/fatal.c.obj [109/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj [110/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/kheap.c.obj [111/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mem_slab.c.obj [112/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/float.c.obj [113/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/idle.c.obj [114/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mailbox.c.obj [115/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mutex.c.obj [116/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/msg_q.c.obj [117/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/queue.c.obj [118/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/sem.c.obj [119/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/system_work_q.c.obj [120/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/stack.c.obj [121/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/condvar.c.obj [122/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/work.c.obj [123/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/thread.c.obj [124/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/pipe.c.obj [125/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/timeslicing.c.obj [126/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/timeout.c.obj [127/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/sched.c.obj [128/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/timer.c.obj [129/156] ビルディングCオブジェクト zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj [130/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/dynamic_disabled.c.obj [131/156] ビルディングCオブジェクト zephyr/kernel/CMakeFiles/kernel.dir/mempool.c.obj [132/156] Cの静的ライブラリ app\libapp.a のリンク [133/156] Cの静的ライブラリ zephyr\libzephyr.a のリンク [134/156] リンクC静的ライブラリ zephyr\arch\arch\common\libarch__common.a [135/156] Linking C static library zephyr\arch\arch\arm\core\libarch__arm__core.a [136/156] リンクC静的ライブラリ zephyr\arch\arch\arm\core\cortex_m\cmse\libarch ARM__core__mpu.a__arm__core__cortex_m__cmse.a [137/156] Linking C static library zephyr\arch\arch\arm\core\mpu\libarch__ [138/156] リンクC静的ライブラリ zephyr\arch\arch\arch\arm\core\cortex_m\libarch__arm__core__cortex_m.a [139/156] Cの静的ライブラリ zephyr\lib\libc\common\liblib__libc__common.a のリンク [140/156] リンクC静的ライブラリ zephyr\lib\posix\c_lib_ext\liblib__posix__c_lib_ext.a [141/156] リンクC静的ライブラリ Zephyr\ドライバ\clock_control\libdrivers__clock_control.a [142/156] リンクC静的ライブラリ zephyr\lib\libc\picolibc\liblib__libc__picolibc.a [143/156] c静的ライブラリ zephyr\drivers\console\libdrivers__console.a [144/156] Linking C static library zephyr\drivers\gpio\libdrivers__gpio.a のリンク [145/156] リンクC静的ライブラリ Zephyr\ドライバ\pinctrl\libdrivers__pinctrl.a [146/156] Linking C static library zephyr\drivers\serial\libdrivers__serial.a [147/156] リンクC静的ライブラリ Zephyr\ドライバ\rtc\libdrivers__rtc.a [148/156] Linking C static library zephyr\drivers\timer\libdrivers__timer.a [149/156] C静的ライブラリ modules\hal_nxp\libmodules__hal_nxp.a をリンクしています。 [150/156] リンクC静的ライブラリ zephyr\kernel\libkernel.a [151/156] C実行ファイルzephyr\zephyr_pre0.elfのリンク 失敗:zephyr/zephyr_pre0.elf zephyr/zephyr_pre0.map D:/ABC/rtc/build/zephyr/zephyr_pre0.map C:\Windows\system32\cmd.exe /C "cd .&& C:\Users\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -gdwarf-4 -Os zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj -o zephyr\zephyr_pre0.elf zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj -T zephyr/linker_zephyr_pre0.cmd -Wl,-Map,D:/ABC/rtc/build/zephyr/zephyr_pre0.map -Wl,--whole-archive app/libapp.aZephyr/libzephyr.aゼファー/アーチ/コモン/リバルク__common.a zephyr/arch/arch/arm/core/libarch__arm__core.AZephyr/arch/arch/Arm/core/cortex_m/libarch__arm__core__cortex_m.AZEPHYR/ARCH/ARCH/ARM/CORE/cortex_m/CMSE/Libarch__arm__core__cortex_m__cmse.a zephyr/arch/arch/arm/core/mpu/libarch__ARM__core__MPU.AZephyr/lib/libc/picolibc/liblib__libc__picolibc.azephyr/lib/libc/common/liblib__libc__common.aZephyr/lib/posix/c_lib_ext/liblib__posix__c_lib_ext.aZephyr/ドライバ/clock_control/libdrivers__clock_control.AZephyr/ドライバ/Console/LibDrivers__console.a zephyr/drivers/gpio/libdrivers__GPIO.azephyr/ドライバ/pinctrl/libドライバ__pinctrl.a zephyr/drivers/rtc/libdrivers__rtc.aZephyr/ドライバ/serial/libdrivers__serial.a zephyr/drivers/timer/libdrivers__timer.amodules/hal_nxp/libmodules__hal_nxp.a-Wl,--no-whole-archive zephyr/kernel/libkernel.a -LD:/ABC/rtc/build/zephyr zephyr/arch/common/libisr_tables.a-fuse-ld=bfd -mcpu=Cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=降順 -Wl,--sort-section=alignment -Wl,-u,_OffsetAbsSyms -wl,-u,_ConfigAbsSyms -nostdlib -static -znoexecstack -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -Wl,-no-pie -Wl,--undefined=_sw_isr_table -Wl,--undefined=_irq_vector_table -specs=picolibc.specs -DPICOLIBC_LONG_LONG_PRINTF_SCANF -L"C:/ユーザー/Xpeng/Zephyr-SDKs-1.0.1/gnu/Arm-zephyr-eabi/bin/../lib/gcc/Arm-zephyr-eabi/14.3.0/thumb/v8-m.main/nofp/space」-lc -lgcc && C:\Windows\system32\cmd.exe /C "cd /D:\ABC\RTC\BUILD\ZEPHYR && C:\ユーザー\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.exe -E true"" C:/ユーザー/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/14.3.0/../../../../arm-zephyr-eabi/bin/ld.bfd.exe:app/libapp.a(main.c.obj): 関数「k_sleep」で: D:/ABC/rtc/build/zephyr/include/generated/zephyr/syscalls/kernel.h:185:(.text.main+0x94):`__device_dts_ord_92`への未定義の参照 collect2.exe:エラー: ld が終了ステータス 1 を返しました ninja: ビルドが停止しました: サブコマンドが失敗しました。 ビルドはエラーで終了しました。 * 端末プロセスは終了コード1で終了しました。 * ターミナルはタスクによって再利用されます。閉じるには任意のキーを押してください。 問題の確認にご協力いただき、誠にありがとうございました。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、RomanVRさん。 例:Zephyr/samples/ドライバ/counter/alarm は問題なく動作しましたが、 RTCの例 はスナップショットと同じオーバーレイファイルを作成してもビルド中に問題が発生します。 以下はビルドプロセス中に発生した主要なエラーメッセージです。このメッセージは、皆様のご協力のもと問題を解決するためのヒントとなるはずです。本当にありがとうございます! [5/64] ビルドCオブジェクト zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj 失敗:zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj C:\ユーザー\Xpeng\zephyr-sdk-1.0.1\gnu\arm-zephyr-eabi\bin\arm-zephyr-eabi-gcc.exe -DCPU_MCXW727CMFTA_cm33_core0 -DKERNEL -DK_HEAP_MEM_POOL_SIZE=0 -DNDEBUG -DPICOLIBC_LONG_LONG_PRINTF_SCANF -D_POSIX_THREAD_SAFE_FUNCTIONS=200809L -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR_SUPERVISOR__ -D__ZEPHYR__=1 -ID:/ABC/rtc/build/zephyr/include/generated/zephyr -ID:/ABC/zephyr/zephyr/include -ID:/ABC/rtc/build/zephyr/include/generated -ID:/ABC/zephyr/zephyr/soc/nxp/mcx -ID:/ABC/zephyr/zephyr/lib/libc/picolibc/include -ID:/ABC/zephyr/zephyr/lib/posix/c_lib_ext/getopt -ID:/ABC/zephyr/zephyr/soc/nxp/mcx/mcxw/mcxw7xx/。-ID:/ABC/zephyr/zephyr/soc/nxp/mcx/../common -ID:/ABC/zephyr/modules/hal/cmsis_6/CMSIS/Core/Include -ID:/ABC/zephyr/zephyr/modules/cmsis_6/。-ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/common -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/ccm32k -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/cmc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/elemu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lptmr -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/lpuart -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/port -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/rtc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/vbat -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/wuu -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/periph3 -ID:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCX/MCXW/MCXW727C/ドライバ -isystem D:/ABC/Zephyr/zephyr/lib/libc/common/include -Wshadow -fno-strict-aliasing -Os -imacros D:/ABC/rtc/build/zephyr/include/generated/zephyr/autoconf.h -fno-printf-return-value -fno-common -g -gdwarf-4 -fdiagnostics-color=常に -mcpu=Cortex-m33 -mthumb -mabi=aapcs -mfp16-format=ieee -mtp=soft --sysroot=C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/Arm-zephyr-eabi/Arm-zephyr-eabi -imacros D:/ABC/zephyr/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-セキュリティ -Wno-format-zero-length -Wdouble-promotion -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -fno-asynchronous-unwind-tables -ftls-model=local-exec -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=D:/ABC/rtc=CMAKE_SOURCE_DIR -fmacro-prefix-map=D:/ABC/zephyr/zephyr=ZEPHYR_BASE -fmacro-prefix-map=D:/ABC/zephyr=WEST_TOPDIR -ffunction-sections -fdata-sections -mcmse -specs=picolibc.specs -std=c17 -MD -MT zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj -MF zephyr\ドライバ\rtc\CMakeFiles\ドライバ__rtc.dir\rtc_counter.c.obj.d-o zephyr/ドライバ/rtc/CMakeFiles/ドライバ__rtc.dir/rtc_counter.c.obj -c D:/ABC/Zephyr/Zephyr/ドライバ/rtc/rtc_counter.c In file included from D:/ABC/Zephyr/zephyr/include/zephyr/toolchain.h:52, from D:/ABC/Zephyr/zephyr/include/zephyr/kernel_includes.h:23, from D:/ABC/Zephyr/zephyr/include/zephyr/kernel.h:17, from D:/ABC/Zephyr/zephyr/include/zephyr/drivers/rtc.h:26, from D:/ABC/Zephyr/zephyr/drivers/rtc/rtc_counter.c:9: D:/ABC/Zephyr/zephyr/include/zephyr/toolchain/gcc.h:87:36: error: static assertion failed: "RTC init priority must be bigger than counter" 87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG) | ^~~~~~~~~~~~~~ D:/ABC/Zephyr/zephyr/drivers/rtc/rtc_counter.c:684:1: note: in expansion of macro 'BUILD_ASSERT' 684 | BUILD_ASSERT(CONFIG_RTC_INIT_PRIORITY > CONFIG_COUNTER_INIT_PRIORITY, | ^~~~~~~~~~~~ [6/64] ビルディング C オブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C/drivers/fsl_clock.c.obj [7/64] ビルディング C オブジェクト modules/hal_nxp/CMakeFiles/modules__hal_nxp.dir/D_/ABC/Zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/drivers/spc/fsl_spc.c.obj Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。お元気でお過ごしでしょうか。 現在のMCXW72のRTCドライバの実装はcounter.hと共に使用することを想定していますゼファー図書館。この点を踏まえて、例えば zephyr/samples/drivers/counter/alarmを使ってRTC機能をテストすることをお勧めします。下の画像に示すように: このプロジェクトテンプレートは、RTCをアラーム機能を備えたカウンターとして構成します。テストするには、 /boardsフォルダにオーバーレイファイル[frdm_mcxw72.overlay]を作成してください。そして、以下の内容をファイルに追加してください。 / { aliases { rtc=&rtc; }; }; &rtc{ status = "okay"; counter_rtc: counter_rtc { status = "okay"; }; }; これらの変更が開発に役立つかどうか、お知らせください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。 RTCのサンプルを正しくビルドするには、 prj.confファイルに以下の設定を追加する必要があります。 CONFIG_RTC_INIT_PRIORITY=70 これがあなたにとって有効かどうか教えてください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、RomanVRさん。 prj.conf ファイルの設定を追加しました CONFIG_RTC_INIT_PRIORITY=70 それでも建築は通過できず、エラープロンプトのメッセージも同じです。建築ログは添付ファイルで確認できます。問題のポイントを見つける助けになれば幸いです。 よろしくお願いいたします! Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。 prj.confというファイル内に設定を追加していただけますか?frdm_mcxw72.confという名前で作成されたファイルに追加しても、オーバーレイファイルのようにZephyrビルドシステムによって自動的に取得されません。 これが役に立つかどうか教えてください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、 @anliu114036 さん。サンプルが正しくビルドできたようで良かったです。 RTC機能に関しては、現在Zephyr(rtc.h)のRTCドライバーはMCXW72のRTCノード(counter_mcux_rtc.c)で使用している低レベルのドライバーと互換性がなく、W72のRTCはcounter.h経由で使用すべきですAPIが下位レベルのドライバで定義されているものと互換性があるため、ドライバを選びます。 先ほど紹介したアラームの例(Zephyr/samples/drivers/counter/alarm)は、RTCドライバの現在の全機能を示しています。 この情報で疑問が解消されたかどうか、お知らせください。 Re: RTC example can't build successfully in frdm_mcxw72 board こんにちは、RomanVRさん。 prj.confに設定を追加したらうまくいきました。ご協力ありがとうございました! しかし、EVKにイメージをフラッシュした後も、RTC機能がまだ壊れているように見えるという問題が残っています。これは、プリントメッセージからの時刻情報がそのままになっているためです。 チェックを手伝ってもらえますか?ありがとうございます!
記事全体を表示
MCXA266:深度掉电唤醒后,WUU 唤醒标志为 0(SRS=0x4010,SSRS=0x4011) 你好, 我正在研究 FRDM-MCXA266 板上从深度掉电模式唤醒 WUU 的行为。 环境: - MCU:MCXA266 - 电路板:FRDM-MCXA266 - SDK 示例项目:frdmmcxa266_power_mode_switch_ll_mcxa - SDK 版本:26.6.000 - 开发环境:MCUXpressoIDE_25.6.136 我在 main() 函数的开头附近添加了以下代码,以便在调用 BOARD_InitHardware() 之前读取 RESET 和唤醒状态。 /******************************************************************************* * Variables ******************************************************************************/ char *const g_modeNameArray[] = APP_POWER_MODE_NAME; char *const g_modeDescArray[] = APP_POWER_MODE_DESC; uint32_t resetCount; uint32_t resetStatus; uint32_t resetStickyStatus; uint32_t wakeupResource; uint32_t wuuWakeupPinsFlag; /******************************************************************************* * Code ******************************************************************************/ int main(void) { uint32_t freq; app_power_mode_t targetPowerMode; bool needSetWakeup = false; // --- START ADDED CODE --- resetStatus = CMC_GetSystemResetStatus(CMC); resetStickyStatus = CMC_GetStickySystemResetStatus(CMC); CMC_ClearStickySystemResetStatus(CMC, resetStickyStatus); wakeupResource = CMC_GetWakeupSource(CMC); wuuWakeupPinsFlag = WUU_GetExternalWakeUpPinsFlag(WUU0); WUU_ClearExternalWakeUpPinsFlag(WUU0, wuuWakeupPinsFlag); // --- END ADDED CODE --- BOARD_InitHardware(); // --- START ADDED CODE --- DbgConsole_Printf("CMC_GetSystemResetStatus(CMC) = 0x%x\r\n", resetStatus); DbgConsole_Printf("CMC_GetStickySystemResetStatus(CMC) = 0x%x\r\n", resetStickyStatus); DbgConsole_Printf("CMC_GetWakeupSource(CMC) = 0x%x\r\n", wakeupResource); DbgConsole_Printf("WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x%x\r\n", wuuWakeupPinsFlag); // --- END ADDED CODE --- APP_SetVBATConfiguration(); APP_SetSPCConfiguration(); APP_InitWaketimer(); 相关的完整输出结果如下: ``` 正常启动。 ######################### ## Power Mode Switch Demo ## ######################### 核心时钟频率 = 240000000Hz 电源模式:激活 选择所需的操作 按 A 键进入:运行模式 按 B 键进入:睡眠模式 按 C 键进入:深度睡眠模式 按 D 键进入:关机模式 按 E 键进入:深度关机模式 等待电源模式选择…… Deep 掉电: The whole VDD_CORE voltage domain is 掉电. 请选择唤醒源: 按 A 选择定时器作为唤醒源; 按 B 选择唤醒按钮作为唤醒源; 等待唤醒源选择... 已选择唤醒按钮作为唤醒源。 请按SW2键唤醒。 隔离功率域:VDD_USB。 CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 正常启动。 ``` 首次启动时,打印了以下值: CMC_GetSystemResetStatus(CMC) = 0x110 CMC_GetStickySystemResetStatus(CMC) = 0x110 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 然后我选择了深度关机模式,选择了唤醒按钮作为唤醒源,并按下了 SW2。 MCU 已成功唤醒,应用程序也已重新启动,但打印出了以下值: CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 我对 CMC RESET 状态的理解是: - 0x00004010:软件 RESET + 热 RESET - 0x00004011:软件 RESET + 热 RESET + 深度掉电唤醒 RESET 如果这种解释是正确的,则粘滞状态似乎表明首先发生了深度掉电唤醒重置,然后发生了软件热重置。 我检查了应用程序启动代码 system_MCXA266.c,以及示例源代码,但我找不到 NVIC_SystemReset()、SYSRESETREQ 或 SCB->AIRCR 写入。 我还使用保留的 NOLOAD 变量向 SystemInitHook() 添加了一个计数器。SystemInitHook() 在唤醒后只执行了一次,因此我找不到 SystemInit() 之后进行软件重置的证据。 我的问题是: 从深度掉电状态唤醒后,SRS = 0x4010 和 SSRS = 0x4011 是否正常? MCXA266 启动 ROM 或扩展启动加载程序在应用程序启动前是否会执行软件热复位? 如何确定是哪个 WUU 引脚导致了深度掉电唤醒? 我目前对 CMC RESET 状态的理解如下,但如果我对位定义的理解有误,请指正: 英语不是我的母语,所以如果我的解释有任何不清楚的地方,请告诉我。 谢谢! MCXA Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) 你好@ka-2020 谢谢你的提问。我将使用相同的设置在我的环境中重现该测试,并调查其行为。一旦我拿到结果,我会将我的发现和所有问题的答案告诉您。 感谢您的耐心和支持。 BR 爱丽丝
記事全体を表示
已安装 HSE 的 S32K311:软件崩溃和 MCU RESET,调试器无法连接 您好,NXP团队, 背景: MCU: S32K311 AUTOSAR RTD MCAL: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 HSE 固件(全内存): s32k3x1_hse_fw_0.12.0_2.55.0_pb250225.bin 完整调查报告以PDF格式附件形式提供。 主要问题 软件在 Clock_Ip_DistributePll() 中崩溃,MCU RESET。此外,调试器有时无法附加。 当我尝试热连接调试器时,复位原因有时会报告为 HSE_CLK_FAIL。 请您主要检查上述流程、IVT 和 DCF 记录,以及有关此问题发生原因及其解决方案的信息。如有任何其他需要的信息,请告知我们。 请您检查 HSE 安装程序、IVT 配置和 DCF 记录,并告知出现此问题的原因以及如何解决? 如有任何其他信息需要提供,请告知我们。 此致, 舒巴姆·帕德西 Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 提到的 70 秒和 20 秒是从 RESET 到 HSE_STATUS_INIT_OK 的时间。所以基本上只包含启动时间,对吗? 在所有设备上的表现都一样吗? Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach 你好@davidtosenovjan 我们的软件由 FBL 和 APPL 组成,两者都使用相同的功能复位机制。 当 APPL 发起复位时,不会出现此问题。 当 FBL 发起 RESET 时,软件在 APPL 启动期间于 Clock_Ip_DistributePll() 内部崩溃。 最初,我们在 Mcu_InitClock() 之后、Mcu_DistributePllClock() 之前添加了对 HSE_STATUS_INIT_OK 的检查。这样就避免了车祸。然而,大约 20 秒后 HSE_STATUS_INIT_OK 才被设置,之后 APPL 的实际启动才继续进行。 今天,我们将 HSE_STATUS_INIT_OK 检查移到了 APPL 中的 Mcu_Init() 之前的更早阶段,如附图所示。 通过此序列,HSE_STATUS_INIT_OK 几乎立即被设置,并且不再观察到崩溃。 请问您能否澄清以下问题? 为什么只有当 FBL 发起 RESET 时才会出现这个问题,即使 FBL 和 APPL 使用的是相同的 RESET 机制? 为什么在 Mcu_InitClock() 之后检查 HSE_STATUS_INIT_OK 时大约需要 20 秒,但在 Mcu_Init() 之前检查时几乎立即可用? 为什么 FBL 中不需要 HSE_STATUS_INIT_OK 检查,而 APPL 启动时似乎需要? 请提供清晰的根本原因解释和推荐的初始化顺序。我们需要确保当前解决方案的稳健性,并且不会在生产环境中造成任何问题。 如有任何其他详情或时钟配置详情需要告知,请与我们联系。 此致, 舒巴姆·帕德西
記事全体を表示
S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach Hello NXP Team, Background: MCU: S32K311 AUTOSAR RTD MCAL: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 HSE FW (Full Memory): s32k3x1_hse_fw_0.12.0_2.55.0_pb250225.bin Full Investigation Report attached in PDF Main Issue The software crashes and the MCU resets in Clock_Ip_DistributePll(). In addition, the debugger is sometimes unable to attach. When I tried to hot-attach the debugger, the reset reason was sometimes reported as HSE_CLK_FAIL. Can you check mainly the above procedure, IVT and DCF records and additionally information why this issue is occurring and its solution, Please let us know if any additionally information is needed. Could you please check the HSE installation procedure, IVT configuration, and DCF records, and advise why this issue is occurring and how it can be resolved? Please let us know if any additional information is required. Best regards, Shubham Pardeshi Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach Hello @davidtosenovjan  Our software consists of FBL and APPL, and both use the same Functional reset mechanism. When APPL initiates the reset, the issue is not observed. When FBL initiates the reset, the software crashes during APPL startup inside Clock_Ip_DistributePll(). Initially, we added a check for HSE_STATUS_INIT_OK after Mcu_InitClock() and before Mcu_DistributePllClock(). This prevented the crash. However, it took approximately 20 seconds for HSE_STATUS_INIT_OK to be set, after which the actual APPL startup continued. Today, we moved the HSE_STATUS_INIT_OK check to an earlier stage, before Mcu_Init() in APPL, as shown in the attached screenshot. With this sequence, HSE_STATUS_INIT_OK is set almost immediately, and the crash is no longer observed. Could you please clarify the following? Why does this issue occur only when the reset is initiated by FBL, even though FBL and APPL use the same reset mechanism? Why does HSE_STATUS_INIT_OK take approximately 20 seconds when checked after Mcu_InitClock(), but become available almost immediately when checked before Mcu_Init()? Why is the HSE_STATUS_INIT_OK check not required in FBL, but appears to be required during APPL startup? Please provide a clear root-cause explanation and the recommended initialization sequence. We need to ensure that the current solution is robust and will not cause any issues in production. Please let us know if any additional details or clock configuration details are required. Best regards, Shubham Pardeshi Re: S32K311 with HSE Installed: Software Crash and MCU Reset, Debugger Unable to Attach Mentioned 70 and 20 seconds are times from reset to HSE_STATUS_INIT_OK. So basically only boot time is included, correct? Does it behave the same way on every device?
記事全体を表示
imx8mmini sai1 最大サンプルレート hi SAI1 Connectのコーデックはサンプルレート768kHz/32bitに対応しています。 SAI1-RX0 codec_DOUT接続。 768kHz/32bitおよびL/Rチャネルで読み取れるデータはありませんが、SAI1-TXFS/SAI1-TXCは768kHz/49.152Mhzを出力可能です。768khz/16bitおよび384khz/32bitのL/Rチャネル読み取りは問題ありません。カーネルバージョン6.1.36です。 ありがとうございます。 Re: imx8mmini sai1 max sample rates コーデックdtsについては以下の通りです。 「-f S32_LE -r 384000 -c 2 -d 1 test.wav」を指定して arecord コマンドを実行します。または「-f S16_LE -r 786000 -c 2 -d 1 test.wav」でも問題ありません。しかし、「-f S32_LE -r 768000 -c 2 -d 1 test.wav」で実行すると、test.wav は NULL になります。 Re: imx8mmini sai1 max sample rates こんにちは、 デバイスツリーの設定を教えていただけますか? どのコーデックを使用していますか? よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates こんにちは、 サンプルレートに関連するエラーが出る場合、クロックソースがそのサンプルレートに必要な周波数を生成できないため、原因かもしれません。 特定のサンプリングレートを得るためには、外部クロックなどの専用のクロックソースを使用する必要がある場合があります。 よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates こんにちは、 テスト中にアンダーフローエラーやオーバーフローエラーが発生しますか? よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates 768kHzの32ビット×2チャンネルで読み取ると、SAI1_TXFS/SAI1_TXC出力は正常(768kHz/49.152MHz)です。コーデックのデータ出力ピン(SAI1_RX0に接続)は、オシロスコープで確認するとデータ出力があります。imx8mminiのSDMAが動作していない可能性はありますか? Re: imx8mmini sai1 max sample rates テスト中に以下のようなカーネル出力エラーが発生しました。 [ 506.336480] [858] wait_for_avail:1936: asoc-simple-card sound-pcmdev: キャプチャ書き込みエラー (DMA または IRQ の問題?)
記事全体を表示
PF53を0.8V出力するように設定するにはどうすればよいですか? こんにちは、 私の設計では、S32G399、MVR5510AMDALES、およびMPF5302AMDA0ESを使用しています。 データシートによると、MPF5302AMDA0ESはプログラム不要のデバイスです。MPF5302AMDA0ESからS32G399コアへ0.8Vを出力するように設定するにはどうすればよいですか?供給側はそれを利用する。 当初はJTAG経由でS32G399をプログラムし、S32G399がMPF5302AMDA0ESをIIC経由で0.8Vを出力するように設定できるようにしたかったのですが、S32G399コアには0.8Vが供給されていません。JTAG経由で電源を接続できません。これは悪循環のようです。 Re: PF53如何配置输出0.8V はい、ありがとうございます。新しいページにもう一度投稿します。 Re: PF53如何配置输出0.8V こんにちは、 @MichaelTao こんにちは、一般的に言って 1. エンジニアリング開発段階では、お客様はNXP GUIとソケット式評価ボードを使用してOTPエミュレーション/プログラミングを実行できます(これはS32Gで使用できます)。 2.量産段階で使用されるカスタムOTPについては、NXPの販売チャネル/代理店にお問い合わせください。量産OTPのプログラミングは、NXPまたは推奨する第三者が行う必要があります。 このフォーラムは主にS32G本体に関する問題を取り扱っているため、確認のためにさらに詳しい情報が必要な場合は、以下のフォーラムにご投稿ください。そちらでは、専任の製品サポートエンジニアがサポートを提供いたします。ご理解のほどよろしくお願いいたします。 BR チェイン BR チェイン
記事全体を表示
关于8M+实时精度 您好,我们想更多地了解 8M Plus 在实时应用方面的功能。是否有关于TSN、实时性能或抖动方面的测试报告或相关资料? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Regarding 8M Plus Real time Accuracy 面积 可用材料 它包含什么 实时 CPU/RTOS 延迟 鱼叉用户指南 测量实时延迟 i.MX 8M Plus / Zephyr 包括 IRQ 延迟和任务延迟(单位:纳秒)。示例结果:空载 IRQ 延迟最小值/平均值/最大值/标准差 = 625 / 796 / 11,125 / 1,798 ns 任务延迟 = 2,583 / 2,671 / 13,041 / 6,045 ns 。在 Linux 系统下,CPU + 内存负载,IRQ 延迟 = 625 / 798 / 4,250 / 4,674 ns ,任务延迟 = 2,583 / 2,670 / 14,333 / 10,407 ns 。 实时基准测试方法 Harpoon 用户指南 — 实时延迟应用程序 将基准定义为硬件 IRQ 事件与软件操作之间的时间差,使用硬件计时器以亚微秒精度进行测量。 TSN 能力 i.MX 8M Plus 产品/参考资料 i.MX 8M Plus 包含双千兆以太网接口,其中一个以太网接口支持 TSN,并使用集成式 800 MHz Arm Cortex-M7 用于工业实时控制。 TSN硬件标准 i.MX 8M Plus 参考手册 TSN支持包括 IEEE 802.1Qbv 时间感知整形器 , 802.1Qav 基于信用的整形者 , IEEE 1588v2 PTP 以太网模块实现了 802.1Qbv-2015 , 802.3br , 和 802.1Qbu 与帧抢占相关的TSN功能。 TSN 测试/验证环境 实时边缘计算用户指南 描述了用于评估 i.MX 8M Plus TSN 功能的 TSN 测试环境,包括流量生成/分析以及对延迟、抖动和同步精度的监控。 TSN抖动/延迟示例 实时边缘用户指南 — TSN 端点示例应用程序 提供 TSN 端点统计信息,包括流量延迟最小值/平均值/最大值和备注 延迟约为 503 微秒 和 延迟抖动约为 300 纳秒 在所示示例中。 TSN 应用演示 AN13588 演示 GenAVB/TSN 实时控制应用。它描述了一个 2毫秒周期 ,一个 400 微秒预留/保证的控制流量窗口 以及一个用于调度、处理时间、流量正确性和延迟的统计线程。 TSN 802.1Qbv 演示 AN13995 演示了使用 i.MX 8M Plus 的 TSN 802.1Qbv,并解释了时间感知整形技术如何利用固定的重复周期来提供确定性的延迟;它还包含 Linux 版本。  tc  /  taprio  配置示例。   Re: Regarding 8M Plus Real time Accuracy @yipingwang 感谢您提供信息。请问您能否也向我们提供有关 iMX8M Plus EVK 的信息? 谢谢。 Re: Regarding 8M Plus Real time Accuracy 我们了解到,i.MX95 EVK 尚未正式发布任何公开的“实时性能报告”。但是,NXP 内部确实对 i.MX95 平台进行了实时基准测试。内部基准测试文档表明,已在运行实时边缘软件和 PREEMPT_RT Linux 的 i.MX95 LPDDR5 EVK 上执行了 cyclictest 和 EtherCAT 性能评估。报告的例子包括:在 6 小时的压力测试期间,循环测试的最大延迟约为 38 µs;在记录的测试条件下,EtherCAT 滤波后的最大抖动约为 12 µs。由于实时性能很大程度上取决于 BSP 版本、内核配置、CPU 隔离、工作负载和网络流量,因此这些值应被视为参考测量值,而不是保证的应用级限制。   请参阅https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf 作为支持的基准测试平台,并提供详细的循环测试、压力测试和 rt_latency 测试程序。 Re: Regarding 8M Plus Real time Accuracy 我们的代理商告知我们,目前还没有关于 NXP i.MX95 EVK 实时性能或抖动的官方性能报告。 但是,他们还提供了描述评估实时延迟的测试方法(例如,循环测试)的文档。 这导致我们这边有些困惑。由于存在标准化的测试方法,我们假设此类测试一定已在内部执行过——至少在参考 EVK 平台上执行过。 因此,我们想澄清如下: NXP 是否对 i.MX95 EVK 进行过任何实时性能(例如延迟、抖动)的内部测量? 如果可以,是否有任何参考结果或基准结果可以分享? 我们了解到,实时性能可能会因系统配置和工作负载而异。然而,即使是受控条件下的基准结果(例如,默认 BSP,最小负载)对于初步评估也非常有帮助。 感谢您的支持。 Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (实时边缘软件用户指南)( https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf ) 实时边缘软件(最相关) 恩智浦半导体的实时边缘软件正式支持 i.MX8M Plus EVK,并包含以下内容: PREEMPT_RT Linux TSN 协议栈 IEEE 802.1AS (gPTP) 同步 TSN流量整形和调度 EtherCAT、OPC-UA、CAN 相关工业协议 使用 Cortex-A53 + Cortex-M7 的异构实时操作 内部文件REALTIMEEDGEUG指出,实时边缘软件提供: 实时网络(TSN) 实时 Linux (PREEMPT_RT) 纯RTOS/裸机选项 监狱隔断 工业协议支持 支持 i.MX 8M Plus LPDDR4 EVK NXP 应用笔记AN13995 – 使用 i.MX 8M Plus 进行 TSN 802.1Qbv 演示 实时优势产品概览材料中描述了 PREEMPT_RT + TSN 支持 Re: Regarding 8M Plus Real time Accuracy @yipingwang非常感谢您提供的信息。
記事全体を表示