Multi Source Translation Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Multi Source Translation Content

Discussions

Sort by:
GC7000 GPU 挂起 galcore 超时 问题概要 在 NavApp 运行时,屏幕完全冻结。对内核日志的调查表明,这是 不是应用程序崩溃,而是 Vivante GC7000 GPU (Galcore) 挂起。 观察结果: 内核报告 GPU 超时时间为 30 秒(gpuTimeout = 30000)。 Galcore生成 GPU状态转储和调用: gckKERNEL_Recovery() gckHARDWARE_DumpGPUState() 司机随后报告: [galcore]:停止驱动程序以保持场景。 GPU状态转储显示多个GPU模块卡住: FE 不怠速 SH 未空闲 TX非空闲状态 MC非怠速 DMA似乎卡住了。 驱动程序配置 当前 Galcore 配置显示: 恢复时间 = 0,GPU超时时间 = 30000   由于 GPU 恢复功能已禁用(恢复 = 0),驱动程序在检测到挂起后停止运行,屏幕上会留下最后渲染的帧,这就解释了观察到的屏幕冻结现象。 GPU内存状态: GPU内存统计信息 并不表示记忆力衰竭。 GPU总显存:256 MB 已用:约 155 MB 免费:约 113 MB 因此,该问题似乎并非由 GPU 内存不足引起。 GPU客户端: GPU数据库显示 程序卡死时, NavApp 是唯一活跃的 GPU 客户端。 GPU状态转储引用了以下人员提交的多个命令缓冲区: 导航应用 这表明 GPU 挂起发生在执行 NavApp 提交的渲染命令时。   申请时间表: 从应用程序日志中可以观察到,在 GPU 挂起之前,会立即出现以下序列: 连续地图缩放操作 离线地图/图块访问 路线计算 路线信息显示 GPU超时和状态转储 GPU 死机通常发生在高强度渲染活动之后。 结论: 根据收集到的证据: 有 没有内核崩溃, OOM ,或 应用程序崩溃。 失败是 Galcore 监控程序检测到GPU 命令处理挂起。 NavApp 是渲染客户端,当程序卡死时,故障却在 GPU 驱动程序内部被发现。 GPU内存使用率在允许范围内,并不表示资源耗尽。 请TVS团队调查此事: Vivante GC7000 / Galcore GPU 驱动程序在渲染过程中挂起。 这个问题究竟是已知的GPU驱动程序限制还是固件限制? 此平台是否支持和推荐使用 GPU 恢复(recovery=1)。 分析 GPU 状态转储,以确定是哪个 GPU 命令或硬件块导致了超时。 是否有更新的 电路板支持包、GPU 驱动程序或固件 版本 来解决类似的 GPU 超时问题。 Re: GC7000 GPU hang galcore timeout 嗨@Zhiming_Liu SOC - iMX8qxpComek BSP 版本 - Scarthgap L6.6.5 剧透 (高亮部分可供阅读) 剧透 (高亮部分可供阅读)     Re: GC7000 GPU hang galcore timeout 嗨@Ram2 请提供 SOC 部件号、BSP 版本以及重现步骤。 此致, 志明 Re: GC7000 GPU hang galcore timeout 嗨@Zhiming_Liu 重现步骤: 屏幕冻结问题没有固定的重现步骤,因为它随机且间歇性地发生。但是,我发现当可用系统内存非常低时(通常低于 60 MiB ),这种情况更容易发生。 为了增加重现问题的可能性,我持续执行了以下操作: 开辟了 2-3 条长途路线。 启动导航后,大约一分钟内退出。 反复使用“家” 、 “办公室”和“酒店”快捷操作按钮创建路线。 通过平移和频繁的缩放操作探索不同的地图区域。 在这些活动期间,当可用内存下降到较低水平时,观察到屏幕冻结现象。例如: 内存使用量(MiB):总计 1709.5,可用 55.8,已用 1298.1,缓冲/缓存 567.2 MiB 交换空间:总计 0.0,可用 0.0,已用 0.0,可用内存 411.4 这表明,当可用内存几乎耗尽时,持续使用过程中更容易出现此问题。 Re: GC7000 GPU hang galcore timeout 嗨@Ram2 请提供在 EVK 上重现此问题的步骤。 此致, 志明 Re: GC7000 GPU hang galcore timeout 嗨@Ram2 NXP发布的Linux 电路板支持包。不包含导航应用程序。请提供测试应用程序和测试说明。 此致, 志明
View full article
サポート要件: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を使用しているので、この方法を使うことをおすすめします。必要なカーネル設定や実際の手順についてはドキュメントをご覧ください。 よろしくお願いいたします。 アルド。
View full article
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コミットプロセスを介して送信されることが明確に示されています。 よろしくお願いします、 志明
View full article
无法更新 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提交过程提交该版本。 此致, 志明
View full article
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
View full article
需要支持: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, 阿尔多。
View full article
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.
View full article
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
View full article
[i.MX95/AAOS16]ブリングアップ支援 ハードウェア: i.MX95 15x15 SW: AAOS16_1.3.0 ほぼすべてのファイルにパッチを適用しました。 しかし、カーネル起動の問題は依然として残っている。 リチャード・キムのサポートが必要です。 Re: [i.MX95/AAOS16] Bringup support こんにちは、 @Jaeheon-Sim_Mobis さん、 改訂版ガイドラインを添付いたしましたのでご確認ください。 また、パッチされたすべてのファイルを正しいディレクトリ構造で添付しているので、ソースツリーで直接上書きできるようにしています。 よろしくお願いします。
View full article
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 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) Hello  @Alice_Yang  Thank you for looking into this issue. I performed an additional test using another WUU external wake-up pin and wanted to share the result. I added the following configuration in addition to the original wake-up button configuration: WUU_SetExternalWakeUpPinsConfig(APP_WUU, 0, &wakeupButtonConfig); I then woke the device from Deep Power-Down using the pin assigned to WUU pin 0. The device woke up successfully, but I observed the same result as before: CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 Therefore, this behavior does not seem to be specific to the original SW2 WUU pin. Do you have any updates on the investigation? Please let me know if you need any additional logs, source code, register values, or test results from my side. Thank you.
View full article
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の起動時には必要となるのはなぜですか? 明確な根本原因の説明と推奨される初期化手順を提示してください。現在のソリューションが堅牢であり、本番環境で問題を引き起こさないことを確認する必要があります。 追加の詳細情報や時計の設定に関する詳細情報が必要な場合はお知らせください。 よろしくお願いします、 シュバム・パルデシ
View full article
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.
View full article
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公式ウェブサイトからダウンロード可能です
View full article
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成功=== コード生成が正常に完了しました === Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 システムを再インストールしましたが、それでも動作しませんでした。GUI Guider 1.10は正常に動作します。空のプロジェクトにボタンを追加しました。 Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 こんにちは、 @IFYINT さん、 お待たせして申し訳ありません。問題が発生したプロジェクトを共有していただけますでしょうか?こちらで再現を試みます。 BR セレステ Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 Windows 11搭載PCで試してみましたが、あなたの問題は再現できませんでした。 別のコンピューターをお試しいただくのはご都合よろしいでしょうか? Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 別のコンピューターでは正常に動作し、ファイルも問題なく生成できるのですが、このコンピューターでは動作しません。以前のバージョン1.10では問題なく動作していました。
View full article
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機能がまだ壊れているように見えるという問題が残っています。これは、プリントメッセージからの時刻情報がそのままになっているためです。 チェックを手伝ってもらえますか?ありがとうございます!
View full article
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 爱丽丝 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) 你好@Alice_Yang 感谢您调查此事。 我使用另一个 WUU 外部唤醒引脚进行了额外的测试,并想与大家分享结果。 除了原有的唤醒按钮配置外,我还添加了以下配置: WUU_SetExternalWakeUpPinsConfig(APP_WUU, 0, &wakeupButtonConfig); 然后我使用分配给 WUU 引脚 0 的引脚将设备从深度掉电状态唤醒。设备成功唤醒,但我观察到了与之前相同的结果: CMC_GetSystemResetStatus(CMC) = 0x4010 CMC_GetStickySystemResetStatus(CMC) = 0x4011 CMC_GetWakeupSource(CMC) = 0x0 WUU_GetExternalWakeUpPinsFlag(WUU0) = 0x0 因此,这种行为似乎并非原始 SW2 WUU 引脚所特有的。 调查方面有任何最新进展吗? 如果您需要我提供任何其他日志、源代码、寄存器值或测试结果,请告诉我。 谢谢!
View full article
已安装 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 启动时似乎需要? 请提供清晰的根本原因解释和推荐的初始化顺序。我们需要确保当前解决方案的稳健性,并且不会在生产环境中造成任何问题。 如有任何其他详情或时钟配置详情需要告知,请与我们联系。 此致, 舒巴姆·帕德西
View full article
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?
View full article
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 の問題?) Re: imx8mmini sai1 max sample rates こんにちは、 dmesg の内容を共有してください。 dmesg | grep -i -E "xrun|overrun|dma|fifo|sdma|sai" そのエラーログではオーバーランが原因かもしれません。例えば、期間とバッファサイズを増やしてみてください。 arecord -D hw:0,0 -f S32_LE -r 768000 -c 2 --buffer-size=65536 --period-size=8192 -d 5 test.wav よろしくお願いいたします。 Re: imx8mmini sai1 max sample rates こんにちは、ホルヘカスさん: ご返信ありがとうございます。 期間とバッファサイズを増やした場合も同じエラーが発生します。 ------------------------------------ root@mx8mm:/tmp# arecord -v -D hw:0,0 -f S16_LE -r 768000 -c 2 -d 1 test.wav WAVEファイル「test.wav」を録音しています:署名付き16ビットリトルエンディアン、レート768000 Hz、ステレオ ハードウェアPCMカード0 'pcmdev-オーディオ' device 0 subdevice 0 その構成は以下の通りです: ストリーム:キャプチャ アクセス:RW_INTERLEAVED フォーマット:S16_LE サブフォーマット:STD チャネル数:2 レート:768000 正確なレート:768000(768000/1) MSBITS:16件 buffer_size:131064 period_size:16383 period_time:21332 tstamp_mode:なし tstamp_type:単調 period_step : 1 avail_min:16383 period_event : 0 start_threshold : 1 stop_threshold:131064 silence_threshold:0 silence_size : 0 境界:9222809086901354496 appl_ptr : 0 hw_ptr : 0 root@mx8mm:/tmp# test.wav -la -rw-r--r-- 1 ルート 7月22日 22:09 test.wav 3072044 root@mx8mm:/tmp# arecord -D hw:0,0 -f S32_LE -r 768000 -c 2 --buffer-size=65536 --period-size=8192 -d 5 test.wav WAVEファイル「test.wav」を録音しています:署名付き32ビットリトルエンディアン、レート768000 Hz、ステレオ arecord: pcm_read:2221: read error: input/output error root@mx8mm:/tmp# dmesg |grep -i -E "xrun|overrun|dma|fifo|sdma|sai" [ 0.00000] OF: 予約済みメモリ:初期化されたNode Linux、CMA、互換性ID Shared-DMA-プール [ 0.000000] 予約メモリ:0x00000000b8400000にDMAメモリプールを作成、サイズ1 MiBで [ 0.00000] OF: 予約済み メモリ: 初期化されたノードvdevbuffer@b8400000、互換性のあるid shared-dma-pool(共有済みDMA-プール) [0.000000] DMA [記憶0x0000000040000000-0x00000000bfffffff] [ 0.000000] DMA32 空 [ 0.000000] ポリシーゾーン:DMA [ 0.043871] DMA:原子力割り当て用に事前割り当てされた256 KiB GFP_KERNELプール [ 0.044176 DMA: 事前割り当て256 KiB GFP_KERNEL|GFP_DMA原子割り当てプール [ 0.044364] DMA: 事前割り当て256 KiB GFP_KERNEL|GFP_DMA32原子割り当てプール [ 0.105243] iommu: DMAドメインTLB無効化ポリシー:厳格モード [ 0.195002] IMX-SDMA 302C0000.DMA-コントローラー:imx/sdma/sdma-imx7d.binの直接ファームウェアロードがエラー-2で失敗しました [ 0.195018] IMX-SDMA 302C0000.DMA-コントローラー:sysfsへのフォールバック:imx/sdma/sdma-imx7d.bin [ 0.199761] MXS-DMA 3300000.DMA-コントローラー:初期化 [ 1.996379] mmc2: 30b60000.mmc 上のSDHCIコントローラ [30b60000.mmc]ADMAの使用 [ 2.786360] mmc1: 30b50000.mmc 上のSDHCIコントローラー [30b50000.mmc]ADMAの使用 [ 8.812860] IMX-SDMA 302C0000.DMA-コントローラー:ファームウェアが見つかりました。 [ 8.818748] IMX-SDMA 30BD0000.DMA-コントローラー:ファームウェアが見つかりました。 [ 8.825901] IMX-SDMA 30BD0000.DMA-コントローラ:ファームウェア4.6をロードしました [ 91.326700] [857] soc_hw_sanity_check:775: 30010000.sai-pcmdevice-codec:ASoC: pcmdevice-codec <-> 30010000.sai 情報: [ 91.326722] [857] soc_hw_sanity_check:777: 30010000.sai-pcmdevice-codec:ASoC: レートマスク 0x154c0 [ 91.326728] [857] soc_hw_sanity_check:778: 30010000.sai-pcmdevice-codec:ASoC: ch 最小2 最大8 [ 91.326734] [857] soc_hw_sanity_check:780: 30010000.sai-pcmdevice-codec:ASoC: レート最小 44100 最大 768000 [ 91.342776] [857] fsl_sai_set_bclk:460: fsl-sai 30010000.sai:クロック周波数49152000Hzに基づく周波数24576000Hzの比率2 [ 91.342784] [857] fsl_sai_set_bclk:481: fsl-sai 30010000.sai:最適な適合: 時計ID=1、div=2、偏差=0 [ 91.343315] [857] dapm_update_dai_unlocked:2698: fsl-sai 30010000.sai:30010000.saiキャプチャのDAIルートを更新します [ 113.965788] [861] soc_hw_sanity_check:775: 30010000.sai-pcmdevice-codec:ASoC: pcmdevice-codec <-> 30010000.sai 情報: [ 113.965809] [861] soc_hw_sanity_check:777: 30010000.sai-pcmdevice-codec:ASoC: レートマスク 0x154c0 [ 113.965816] [861] soc_hw_sanity_check:778: 30010000.sai-pcmdevice-codec:ASoC: ch 最小2 最大8 [ 113.965822] [861] soc_hw_sanity_check:780: 30010000.sai-pcmdevice-codec:ASoC: レート最小 44100 最大 768000 [ 113.977610] [861] fsl_sai_set_bclk:460: fsl-sai 30010000.sai:クロック周波数49152000Hzに基づく周波数49152000Hzの比率1 [ 113.977618] [861] fsl_sai_set_bclk:481: fsl-sai 30010000.sai:最適な適合: 時計ID=1、div=1、偏差=0 [ 113.978149] [861] dapm_update_dai_unlocked:2698: fsl-sai 30010000.sai:30010000.saiキャプチャのDAIルートを更新します [ 124.127055] [861] wait_for_avail:1936: asoc-simple-card sound-pcmdev: キャプチャ書き込みエラー (DMA または IRQ の問題?) root@mx8mm:/tmp# ls test.wav -la -rw-r--r-- 1 root root 44 7月 22 22:09 test.wav root@mx8mm:/tmp#
View full article
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 チェイン
View full article