Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
已安装 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() 之前的更早阶段,如附图所示。 Shubham_MQ_0-1784123821324.png 通过此序列,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. Shubham_MQ_0-1784123821324.png 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については以下の通りです。 sofia_0571_0-1784080120640.png 「-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#
查看全文
PF53を0.8V出力するように設定するにはどうすればよいですか? こんにちは、 私の設計では、S32G399、MVR5510AMDALES、およびMPF5302AMDA0ESを使用しています。 データシートによると、MPF5302AMDA0ESはプログラム不要のデバイスです。MPF5302AMDA0ESからS32G399コアへ0.8Vを出力するように設定するにはどうすればよいですか?供給側はそれを利用する。 当初はJTAG経由でS32G399をプログラムし、S32G399がMPF5302AMDA0ESをIIC経由で0.8Vを出力するように設定できるようにしたかったのですが、S32G399コアには0.8Vが供給されていません。JTAG経由で電源を接続できません。これは悪循環のようです。 MichaelTao_0-1784009570077.png 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,最小负载)对于初步评估也非常有帮助。 感谢您的支持。 hankwang_0-1784018178178.png 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非常感谢您提供的信息。
查看全文
When GUIGuider-2.0.0 generates C code, the folder under the generated folder is completely empty. When using GUIGuider-2.0.0 on Windows 11 to generate C code, the folders under the "generated" folder are all empty, even though the logs show successful generation. This happens on the same computer as GUI-Guider-1.10.1-GA, which generates the code perfectly. I've tried various methods, including disabling antivirus software and running it as administrator, but the problem persists. Has anyone encountered the same issue? I would appreciate any help. 21:10:08 INFO [gg_event] gg_event_layer_sys.c Generated 21:10:08 INFO [gg_event] gg_event_layer_top.c Generated 21:10:08 INFO [gg_event] gg_event_layer_bottom.c Generated 21:10:08 INFO update-sdk Started 21:10:08 INFO Target Executor initialized 21:10:08 SUCCESS SDK template updated successfully 21:10:08 SUCCESS Operation completed in 0.00s 21:10:08 INFO [gg_event] gg_event_screen.c Generated 21:10:08 INFO [gg_event] gg_event.h Generated 21:10:08 INFO [gg_event] Generation completed 21:10:08 SUCCESS === Code generation completed successfully === Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 I reinstalled the system but it still didn't work; GUI Guider 1.10 works fine. I added a button to a blank project. Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 Hello @IFYINT , Sorry to keep you waiting. Could you please share the project where the problem occurred? We'll try to reproduce it. BR Celeste Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 I tried it on my Windows 11 PC, but I couldn't reproduce your problem: Celeste_Liu_0-1784687143167.png Would it be convenient for you to try a different computer? Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 It works on a different computer and can generate files normally, but it's not working on this computer. It worked fine on version 1.10 before. 屏幕截图 2026-07-24 202549.png Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 I tried again, but I still couldn't reproduce your situation. Could you check your project path? Did you generate a "generated" folder? If not, could you create it manually and then regenerate the code? Celeste_Liu_0-1785142973015.png We still suggest you export the project and send it to us for review.
查看全文
[i.MX95/AAOS16] 启动支持 硬件:i.MX95 15x15 软件版本:AAOS16_1.3.0 我们修补了几乎所有文件。 但是,仍然存在内核启动问题。 需要理查德·金的支持。 Re: [i.MX95/AAOS16] Bringup support 你好@Jaeheon-Sim_Mobis , 请查收附件中的修订版指南。 我还附上了所有已打补丁的文件,并附上了正确的目录结构,以便您可以直接在源代码树中覆盖它们。 谢谢! Re: [i.MX95/AAOS16] Bringup support 这个适用于 15x15 frdm-mx95 吗? Re: [i.MX95/AAOS16] Bringup support 不,这些补丁是为基于 i.MX95 15x15 EVK 的定制板准备的。
查看全文
RTC example can't build successfully in frdm_mcxw72 board Hi, the RTC example can't build OK in my workbench. you can find the basic setting information in below snapshot anliu114036_1-1784022974445.png below is the log message during the build process : Config task started... Workspace is d:\ABC\rtc Loading Zephyr default modules (Zephyr base (cached)). -- Application: D:/ABC/rtc -- CMake version: 3.30.0 -- Found Python3: C:/Users/Xpeng/.mcuxpressotools/.mcux-venv-3.12/Scripts/python.exe (found suitable version "3.12.12", minimum required is "3.12") found components: Interpreter -- Cache files will be written to: D:/ABC/zephyr/zephyr/.cache -- Zephyr version: 4.4.1 (D:/ABC/zephyr/zephyr) -- Found west (found suitable version "1.5.0", minimum required is "0.14.0") -- Board: frdm_mcxw72, qualifiers: mcxw727c -- Found host-tools: zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- Found toolchain: zephyr 1.0.1 (C:/Users/Xpeng/zephyr-sdk-1.0.1) -- Found Dtc: C:/Users/Xpeng/.mcuxpressotools/dtc-1.6.1/tools/usr/bin/dtc.exe (found suitable version "1.6.1", minimum required is "1.4.6") -- Found BOARD.dts: D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72.dts -- Found devicetree overlay: D:/ABC/rtc/boards/frdm_mcxw72.overlay -- Generated zephyr.dts: D:/ABC/rtc/build/zephyr/zephyr.dts -- Generated pickled edt: D:/ABC/rtc/build/zephyr/edt.pickle -- Generated devicetree_generated.h: D:/ABC/rtc/build/zephyr/include/generated/zephyr/devicetree_generated.h Parsing D:/ABC/zephyr/zephyr/Kconfig Loaded configuration 'D:/ABC/zephyr/zephyr/boards/nxp/frdm_mcxw72/frdm_mcxw72_defconfig' Merged configuration 'D:/ABC/rtc/prj.conf' Configuration saved to 'D:/ABC/rtc/build/zephyr/.config' Kconfig header saved to '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 version "2.43.1") -- The C compiler identification is GNU 14.3.0 -- The CXX compiler identification is GNU 14.3.0 -- The ASM compiler identification is GNU -- Found assembler: C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc.exe -- Looking for device MCXW727C in D:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/ -- Found device folder: D:/ABC/zephyr/modules/hal/nxp/mcux/mcux-sdk-ng/devices/MCX/MCXW/MCXW727C -- Found gen_kobject_list: D:/ABC/zephyr/zephyr/scripts/build/gen_kobject_list.py -- Configuring done (26.9s) -- Generating done (1.8s) -- Build files have been written to: D:/ABC/rtc/build Configure finished with return code 0 * Terminal will be reused by tasks, press any key to close it. * Executing task: CMake: build Workspace is d:\ABC\rtc build task started.... C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.EXE --build D:/ABC/rtc/build --target all -- [1/156] Generating include/generated/zephyr/version.h -- Zephyr version: 4.4.1 (D:/ABC/zephyr/zephyr), build: v4.4.1 [2/156] Generating misc/generated/syscalls.json, misc/generated/struct_tags.json [3/156] Generating include/generated/device-api-sections.ld, include/generated/device-api-sections.cmake [4/156] Generating include/generated/zephyr/driver-validation.h [5/156] Generating include/generated/zephyr/kobj-types-enum.h, include/generated/zephyr/otype-to-str.h, include/generated/zephyr/otype-to-size.h [6/156] Generating include/generated/zephyr/syscall_dispatch.c, include/generated/zephyr/syscall_exports_llext.c, syscall_weakdefs_llext.c, include/generated/zephyr/syscall_list.h [7/156] Building C object zephyr/lib/heap/CMakeFiles/heap_constants.dir/heap_constants.c.obj [8/156] Generating ../../include/generated/zephyr/heap_constants.h [9/156] Building C object zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj [10/156] Generating include/generated/zephyr/offsets.h [11/156] Building C object zephyr/arch/common/CMakeFiles/isr_tables.dir/isr_tables.c.obj [12/156] Building C object CMakeFiles/app.dir/src/main.c.obj [13/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_packaged.c.obj [14/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/libc/validate_libc.c.obj [15/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/printk.c.obj [16/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/sem.c.obj [17/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/thread_entry.c.obj [18/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/heap/heap.c.obj [19/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/clock.c.obj [20/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/dec.c.obj [21/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/hex.c.obj [22/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/cbprintf_complete.c.obj [23/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/set.c.obj [24/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/timeutil.c.obj [25/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/bitmask.c.obj [26/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/assert.c.obj [27/156] Building C object zephyr/CMakeFiles/zephyr.dir/misc/generated/configs.c.obj [28/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/last_section_id.c.obj [29/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/rb.c.obj [30/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/ring_buffer.c.obj [31/156] Building ASM object zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/mcxw72_platform_init.S.obj [32/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt.c.obj [33/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/bitarray.c.obj [34/156] Building C object zephyr/CMakeFiles/zephyr.dir/lib/utils/getopt/getopt_common.c.obj [35/156] Building C object zephyr/arch/common/CMakeFiles/arch__common.dir/init.c.obj [36/156] Building C object zephyr/CMakeFiles/zephyr.dir/soc/nxp/mcx/mcxw/mcxw7xx/soc.c.obj [37/156] Building C object zephyr/CMakeFiles/zephyr.dir/subsys/mem_mgmt/mem_attr.c.obj [38/156] Building C object zephyr/CMakeFiles/zephyr.dir/subsys/tracing/tracing_none.c.obj [39/156] Building C object zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj [40/156] Building ASM object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi_on_reset.S.obj [41/156] Building C object zephyr/arch/common/CMakeFiles/arch__common.dir/xip.c.obj [42/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault_s.S.obj [43/156] Building C object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/fatal.c.obj [44/156] Generating linker_zephyr_pre0.cmd [45/156] Building C object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/nmi.c.obj [46/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/reset.S.obj [47/156] Building C object zephyr/arch/arch/arm/core/CMakeFiles/arch__arm__core.dir/tls.c.obj [48/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/vector_table.S.obj [49/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fpu.c.obj [50/156] Linking C static library zephyr\arch\common\libisr_tables.a [51/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/svc.S.obj [52/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/scb.c.obj [53/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/fault.c.obj [54/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/prep_c.c.obj [55/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_manage.c.obj [56/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread.c.obj [57/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/swap_helper.S.obj [58/156] Building ASM object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/__aeabi_read_tp.S.obj [59/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/cpu_idle.c.obj [60/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/exc_exit.c.obj [61/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/irq_init.c.obj [62/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/thread_abort.c.obj [63/156] Building C object zephyr/arch/arch/arm/core/cortex_m/CMakeFiles/arch__arm__core__cortex_m.dir/isr_wrapper.c.obj [64/156] Building C object zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_core_mpu.c.obj [65/156] Building C object zephyr/arch/arch/arm/core/cortex_m/cmse/CMakeFiles/arch__arm__core__cortex_m__cmse.dir/arm_core_cmse.c.obj [66/156] Building C object zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu_regions.c.obj [67/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/assert.c.obj [68/156] Building C object zephyr/arch/arch/arm/core/mpu/CMakeFiles/arch__arm__core__mpu.dir/arm_mpu.c.obj [69/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/cbprintf.c.obj [70/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/chk_fail.c.obj [71/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/errno_wrap.c.obj [72/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/exit.c.obj [73/156] Building C object zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/time/time.c.obj [74/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/locks.c.obj [75/156] Building C object zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/fnmatch.c.obj [76/156] Building C object zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/abort.c.obj [77/156] Building C object zephyr/lib/libc/picolibc/CMakeFiles/lib__libc__picolibc.dir/stdio.c.obj [78/156] Building C object zephyr/lib/libc/common/CMakeFiles/lib__libc__common.dir/source/stdlib/malloc.c.obj [79/156] Building C object zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getentropy.c.obj [80/156] Building C object zephyr/lib/posix/c_lib_ext/CMakeFiles/lib__posix__c_lib_ext.dir/getopt_shim.c.obj [81/156] Building C object zephyr/drivers/clock_control/CMakeFiles/drivers__clock_control.dir/clock_control_mcux_scg_k4.c.obj [82/156] Building C object zephyr/drivers/console/CMakeFiles/drivers__console.dir/uart_console.c.obj [83/156] Building C object 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] Building C object zephyr/drivers/pinctrl/CMakeFiles/drivers__pinctrl.dir/pinctrl_nxp_port.c.obj [86/156] Building C object zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_utils.c.obj [87/156] Building C object zephyr/drivers/serial/CMakeFiles/drivers__serial.dir/uart_mcux_lpuart.c.obj [88/156] Building C object 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] Building C object zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/sys_clock_init.c.obj [90/156] Building C object 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] Building C object zephyr/drivers/timer/CMakeFiles/drivers__timer.dir/mcux_lptmr_timer.c.obj [92/156] Building C object 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] Building C object 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] Building C object 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] Building C object 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] Building C object 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] Building C object 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] Building C object 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] Building C object 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] Building C object 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] Building C object 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] Building C object zephyr/kernel/CMakeFiles/kernel.dir/main_weak.c.obj [103/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/banner.c.obj [104/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/busy_wait.c.obj [105/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/device.c.obj [106/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/version.c.obj [107/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/errno.c.obj [108/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/fatal.c.obj [109/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/init.c.obj [110/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/kheap.c.obj [111/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/mem_slab.c.obj [112/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/float.c.obj [113/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/idle.c.obj [114/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/mailbox.c.obj [115/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/mutex.c.obj [116/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/msg_q.c.obj [117/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/queue.c.obj [118/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/sem.c.obj [119/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/system_work_q.c.obj [120/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/stack.c.obj [121/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/condvar.c.obj [122/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/work.c.obj [123/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/thread.c.obj [124/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/pipe.c.obj [125/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/timeslicing.c.obj [126/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/timeout.c.obj [127/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/sched.c.obj [128/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/timer.c.obj [129/156] Building C object zephyr/CMakeFiles/zephyr_pre0.dir/misc/empty_file.c.obj [130/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/dynamic_disabled.c.obj [131/156] Building C object zephyr/kernel/CMakeFiles/kernel.dir/mempool.c.obj [132/156] Linking C static library app\libapp.a [133/156] Linking C static library zephyr\libzephyr.a [134/156] Linking C static library zephyr\arch\common\libarch__common.a [135/156] Linking C static library zephyr\arch\arch\arm\core\libarch__arm__core.a [136/156] Linking C static library zephyr\arch\arch\arm\core\cortex_m\cmse\libarch__arm__core__cortex_m__cmse.a [137/156] Linking C static library zephyr\arch\arch\arm\core\mpu\libarch__arm__core__mpu.a [138/156] Linking C static library zephyr\arch\arch\arm\core\cortex_m\libarch__arm__core__cortex_m.a [139/156] Linking C static library zephyr\lib\libc\common\liblib__libc__common.a [140/156] Linking C static library zephyr\lib\posix\c_lib_ext\liblib__posix__c_lib_ext.a [141/156] Linking C static library zephyr\drivers\clock_control\libdrivers__clock_control.a [142/156] Linking C static library zephyr\lib\libc\picolibc\liblib__libc__picolibc.a [143/156] Linking C static library zephyr\drivers\console\libdrivers__console.a [144/156] Linking C static library zephyr\drivers\gpio\libdrivers__gpio.a [145/156] Linking C static library zephyr\drivers\pinctrl\libdrivers__pinctrl.a [146/156] Linking C static library zephyr\drivers\serial\libdrivers__serial.a [147/156] Linking C static library zephyr\drivers\rtc\libdrivers__rtc.a [148/156] Linking C static library zephyr\drivers\timer\libdrivers__timer.a [149/156] Linking C static library modules\hal_nxp\libmodules__hal_nxp.a [150/156] Linking C static library zephyr\kernel\libkernel.a [151/156] Linking C executable zephyr\zephyr_pre0.elf FAILED: 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.a zephyr/libzephyr.a zephyr/arch/common/libarch__common.a zephyr/arch/arch/arm/core/libarch__arm__core.a zephyr/arch/arch/arm/core/cortex_m/libarch__arm__core__cortex_m.a zephyr/arch/arch/arm/core/cortex_m/cmse/libarch__arm__core__cortex_m__cmse.a zephyr/arch/arch/arm/core/mpu/libarch__arm__core__mpu.a zephyr/lib/libc/picolibc/liblib__libc__picolibc.a zephyr/lib/libc/common/liblib__libc__common.a zephyr/lib/posix/c_lib_ext/liblib__posix__c_lib_ext.a zephyr/drivers/clock_control/libdrivers__clock_control.a zephyr/drivers/console/libdrivers__console.a zephyr/drivers/gpio/libdrivers__gpio.a zephyr/drivers/pinctrl/libdrivers__pinctrl.a zephyr/drivers/rtc/libdrivers__rtc.a zephyr/drivers/serial/libdrivers__serial.a zephyr/drivers/timer/libdrivers__timer.a modules/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=descending -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:/Users/Xpeng/zephyr-sdk-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 D:\ABC\rtc\build\zephyr && C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.exe -E true"" C:/Users/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): in function `k_sleep': D:/ABC/rtc/build/zephyr/include/generated/zephyr/syscalls/kernel.h:185:(.text.main+0x94): undefined reference to `__device_dts_ord_92' collect2.exe: error: ld returned 1 exit status ninja: build stopped: subcommand failed. build finished with error(s). * The terminal process terminated with exit code: 1. * Terminal will be reused by tasks, press any key to close it. many thanks for your help to check the issue. Re: RTC example can't build successfully in frdm_mcxw72 board Hi RomanVR, The example: zephyr/samples/drivers/counter/alarm worked well,  but the RTC example still have problem during build even i created the overlay file the same as the snapshot. anliu114036_0-1784094520929.png below is  the key error message during the build process, it should be the hint  to solve the issue under your help. many thanks! [5/64] Building C object zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj FAILED: zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj C:\Users\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/MCXW/MCXW727C/drivers -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=always -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-security -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/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -MF zephyr\drivers\rtc\CMakeFiles\drivers__rtc.dir\rtc_counter.c.obj.d -o zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -c D:/ABC/zephyr/zephyr/drivers/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] Building C object 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] Building C object 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 Hello @anliu114036, hope you are doing well. The current implementation of the RTC driver of MCXW72 is meant to be used with the counter.h Zephyr library. Considering this, I'd suggest testing RTC functionality with the example: zephyr/samples/drivers/counter/alarm. As shown in the image below: RomanVR_0-1784070722139.png This project template will configure the RTC as a counter with an alarm functionality. To test it, please create in the /boards folder an overlay file [frdm_mcxw72.overlay] and add the following contents to the file: / { aliases { rtc=&rtc; }; }; &rtc{ status = "okay"; counter_rtc: counter_rtc { status = "okay"; }; }; Please let me know if these modifications help on your development. Re: RTC example can't build successfully in frdm_mcxw72 board Hello @anliu114036, For the RTC example to build properly you have to add the following setting to your prj.conf file: CONFIG_RTC_INIT_PRIORITY=70 Please let me know if this works for you. Re: RTC example can't build successfully in frdm_mcxw72 board Hi RomanVR, i did add the prj.conf file with the setting  CONFIG_RTC_INIT_PRIORITY=70 anliu114036_0-1784163152280.png but it still can't pass the building, and the error prompt message is the same, you can find the whole build log in the attachment. hope it can help to find the issue point. Best regards! Re: RTC example can't build successfully in frdm_mcxw72 board Hi @anliu114036, Would you please add the setting inside the file named prj.conf? As adding it in the created file named as frdm_mcxw72.conf will not be fetched automatically by the Zephyr build system like it does for an overlay file. RomanVR_0-1784217266337.png Please let me know if this helps. Re: RTC example can't build successfully in frdm_mcxw72 board Hi RomanVR, it worked after add the setting in the prj.conf,  thanks for your help! but there is still a problem that after i flashed the image into the evk, the RTC function looks still broken, because the time information is keep the same from the print message anliu114036_0-1784258576109.png can you help check it, many thanks! Re: RTC example can't build successfully in frdm_mcxw72 board Hi @anliu114036, glad to know you got the example built properly. Regarding the RTC functionality, currently, the RTC driver from Zephyr (rtc.h) is not compatible with our lower-level driver used for the MCXW72 RTC node (counter_mcux_rtc.c), the usage of the W72's RTC should be through the counter.h driver as the APIs are compatible with the defined in the lower-level driver. The alarm example I shared before (zephyr/samples/drivers/counter/alarm) demonstrates the full current functionality of our RTC driver. Please let me know if this information clears out your doubts.
查看全文
RT1176 - BT_FUSE_SEL のプログラミング後に JTAG 経由で SPI NOR フラッシュの読み出しに問題が発生する こんにちは、 RT1176 CPU上で署名および暗号化処理のテストを行っています。 基本的なシステム構成は、UART/JTAG <-> RT1176 <-> SPI Nor Flashです テストに使用するソフトウェアは以下の通りです: - RT1176テストファームウェア(起動後にLEDを点灯させるだけのシンプルなファームウェア) - NXP MCUXpresso セキュアプロビジョニング / blhost (UART を介した署名および暗号化用) - Segger JFlash(JTAG経由でFlashアクセス用) これまでに以下のテストを実施しました: 1) CPUがアンロックされ、署名がオフになっている間、ファームウェア(署名なし/暗号化されていない状態)は正常に起動し、JTAG経由で問題なくフラッシュにアクセスできます。 2) CPUがアンロックされて署名が有効な間、ファームウェア(署名済み/暗号化されていない状態)は正常に起動し、JTAG経由で問題なくフラッシュにアクセスできます。 3) CPUがロックされて署名がオンになっている間、ファームウェア(署名済み/暗号化済み)が起動せず、JTAG経由でフラッシュへのアクセスが不安定になります。 つまり、暗号化の問題があるということです。しかし、大きな暗号化問題を検証する前に、ステップ3の不安定なフラッシュ挙動を理解したいと思います。 いくつかのテストで、フラッシュ問題はBT_FUSE_SELが吹き抜けた直後に必ず発生することが明らかになりました(BT_FUSE_SEL無傷時はJTAG経由のフルフラッシュアクセスBT_FUSE_SEL、吹き飛ばすとJTAG経由の不安定なフラッシュアクセス)。現在テスト中のため、ヒューズ設定によるJTAGの無効化は行っていません。 では、質問はこうです: なぜBT_FUSE_SELがフラッシュへのアクセスを失わせるのでしょうか?(CPUがロックされているときに、何らかの読み出し保護機能が有効になっているのでしょうか?)segger jflashツールは、CPUがロックされている場合に問題が発生するのでしょうか? こちらもご覧ください: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/mxrt1176-quot-half-quot-bricked-after-programming-fuses-for/mp/2044051 -同じ問題>:BT_FUSE_SEL >フラッシュアクセスできません よろしくお願いします。 よろしくお願いします、 フロリアン Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL こんにちは、 @florian_arndt さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます! BT_FUSE_SELは、SPI NOR読み出し保護を直接有効にしたり、JTAGを無効にしたりするものではありません。その機能は、ブートROMにBOOT_CFGピンではなく、eFuseに保存されているブート構成を使用させることです。 OTFAD/encrypted-XIP構成がeFuseにもプログラムされている場合、BT_FUSE_SELを書き込むことで、その構成が起動のたびに有効になり、BOOT_CFGピンを介してそれをバイパスする可能性がなくなります。誤ったOTFADコンテキスト、キー、アドレス範囲、または暗号化されたイメージは、アプリケーション開始前にブートROMが失敗する原因となることがあります。 したがって、現時点で最も可能性の高い原因は、ブートに関連するGPIOがバイパスされているものの、対応するeFuseが正しく設定されていないことだと考えられます。BT_FUSE_SEL自体はJTAG接続に影響を与えません。問題点を迅速に特定するために、A/Bテストを実施することをお勧めします。 よろしくお願いします、 ギャビン Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL こんにちは、 @Gavin_Jia さん、 ご回答ありがとうございます! 本日、暗号化処理に関する不具合(ファームウェアのバグ)を修正しました。当社のファームウェアは、CPU内で署名/暗号化が有効になった状態で起動するようになりました。 つまり、大きな問題は解決しました。 残っているのは、BT_FUSE_SELを設定した後のJTAG経由のSPIフラッシュ読み出しの問題です。 添付ファイルにヒューズマップがあります。 問題の原因になりそうなものは見えますか? 前もって感謝します。 フロリアン
查看全文
RTC 示例程序在 frdm_mcxw72 开发板上无法成功编译。 您好, 我的工作台无法成功编译 RTC 示例。您可以在下面的截图中找到基本设置信息。 anliu114036_1-1784022974445.png 以下是构建过程中的日志信息: 配置任务已启动... 工作区位于 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) -- 已找到西部(找到合适的版本“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 -- 生成的 pickle 格式 edt 文件:D:/ABC/rtc/build/zephyr/edt.pickle -- 生成的 devicetree_generated.h:D:/ABC/rtc/build/zephyr/include/generated/zephyr/devicetree_generated.h 正在解析 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' -- 找到 GnuLd:C:/Users/Xpeng/zephyr-sdk-1.0.1/gnu/arm-zephyr-eabi/arm-zephyr-eabi/bin/ld.bfd.exe(找到版本“2.43.1”) -- C 编译器标识为 GNU 14.3.0 -- CXX 编译器标识为 GNU 14.3.0 -- 汇编编译器标识为 GNU -- 找到汇编程序:C:/Users/Xpeng/zephyr-sdk-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:版本 工作区位于 d:\ABC\rtc 构建任务已启动…… C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.EXE --build D:/ABC/rtc/build --target all -- [1/156] 正在生成 include/generated/zephyr/version.h -- Zephyr 版本:4.4.1 (D:/ABC/zephyr/zephyr),构建版本:v4.4.1 [2/156] 正在生成 misc/generated/syscalls.json 和 misc/generated/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.hinclude/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,包含/generated/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/generated/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/tracing/tracing_none.c.obj [39/156] 正在构建 C 对象 zephyr/arch/common/CMakeFiles/arch__common.dir/sw_isr_common.c.obj [40/156] 正在构建汇编对象 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\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__cortex_m __cmse.a [137/156] Linking C static library zephyr\arch\arch\arm\core\mpu\libarch__ arm __core__ mpu.a [138/156] 链接 C 静态库 zephyr\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\drivers\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\drivers\pinctrl\libdrivers __pinctrl.a [146/156] Linking C static library zephyr\drivers\serial\libdrivers__ serial.a [147/156] 链接 C 静态库 zephyr\drivers\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.azephyr/arch/common/libarch __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/drivers/clock_control/libdrivers__clock_control.azephyr/drivers/console/libdrivers __console.a zephyr/drivers/gpio/libdrivers__ gpio.azephyr/drivers/pinctrl/libdrivers __pinctrl.a zephyr/drivers/rtc/libdrivers__ rtc.azephyr/drivers/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=descending -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:/Users/Xpeng/zephyr-sdk-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 /DD:\ABC\rtc\build\zephyr && C:\Users\Xpeng\.mcuxpressotools\cmake-3.30.0-windows-x86_64\bin\cmake.exe -E true"" C:/Users/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/drivers/counter/alarm运行良好,但即使我创建的 overlay 文件与快照中的相同, RTC 示例在构建过程中仍然存在问题。 anliu114036_0-1784094520929.png 以下是构建过程中出现的关键错误信息,它应该能帮助您解决问题。非常感谢! [5/64] 正在构建 C 对象 zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj 失败:zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj C:\Users\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/MCXW/MCXW727C/drivers -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=always -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-security -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/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -MF zephyr\drivers\rtc\CMakeFiles\drivers__rtc.dir\rtc_counter.c.obj.d-o zephyr/drivers/rtc/CMakeFiles/drivers__rtc.dir/rtc_counter.c.obj -c D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c 从 D:/ABC/zephyr/zephyr/include/zephyr/toolchain.h:52 包含的文件, 来自 D:/ABC/zephyr/zephyr/include/zephyr/kernel_includes.h:23, 来自 D:/ABC/zephyr/zephyr/include/zephyr/kernel.h:17, 来自 D:/ABC/zephyr/zephyr/include/zephyr/drivers/rtc.h:26, 来自 D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c:9: D:/ABC/zephyr/zephyr/include/zephyr/toolchain/gcc.h:87:36:错误:静态断言失败:“RTC 初始化优先级必须大于计数器” 87 | #define BUILD_ASSERT(EXPR, MSG...) _Static_assert((EXPR), "" MSG) | ^~~~~~~~~~~~~~ D:/ABC/zephyr/zephyr/drivers/rtc/rtc_counter.c:684:1: 注意:在宏“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库。考虑到这一点,我建议使用以下示例测试 RTC 功能: zephyr/samples/drivers/counter/alarm 。如下图所示: RomanVR_0-1784070722139.png 该项目模板将把 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 你好@anliu114036 , 请将该设置添加到名为prj.conf的文件中。因为将其添加到名为frdm_mcxw72.conf的创建文件中,Zephyr 版本系统不会像处理 overlay 文件那样自动获取它。 RomanVR_0-1784217266337.png 请告诉我这是否有帮助。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好 RomanVR, 我已经添加了包含该设置的 prj.conf 文件。 CONFIG_RTC_INIT_PRIORITY=70 anliu114036_0-1784163152280.png 但它仍然无法通过构建,错误提示信息也相同,您可以在附件中找到完整的构建日志。希望这能有助于找到问题所在。 顺祝商祺! Re: RTC example can't build successfully in frdm_mcxw72 board 嗨@anliu114036 ,很高兴得知你已经成功构建了示例。 关于实时时钟 (RTC) 功能,目前 Zephyr 的 RTC 驱动程序 (rtc.h) 与我们用于 MCXW72 RTC 节点的底层驱动程序 (counter_mcux_rtc.c) 不兼容,因此 W72 的 RTC 应通过counter.h来使用。由于 API 与底层驱动程序中定义的 API 兼容,因此该驱动程序是可行的。 我之前分享的闹钟示例(zephyr/samples/drivers/counter/alarm)演示了我们 RTC 驱动程序的全部当前功能。 请告诉我这些信息是否解答了您的疑问。 Re: RTC example can't build successfully in frdm_mcxw72 board 你好 RomanVR, 在 prj.conf 文件中添加设置后,问题解决了,谢谢你的帮助! 但是仍然存在一个问题,就是当我把镜像刷入EVK后,RTC功能似乎仍然无法正常工作,因为打印出来的时间信息没有变化。 anliu114036_0-1784258576109.png 能否帮忙查一下?非常感谢!
查看全文
RT1176 - 通过 JTAG 编程 BT_FUSE_SEL 后出现 SPI 或非 Flash 读取问题 你好, 我们正在 RT1176 CPU 上测试签名和加密过程。 我们的基本系统配置为:UART/JTAG <-> RT1176 <-> SPI Nor Flash 我们用于测试的软件是: - RT1176 测试固件(一个简单的固件,启动后会激活一个 LED) - NXP MCUXpresso 安全配置/blhost(用于通过UART进行签名和加密) - Segger JFlash(用于通过 JTAG 访问闪存) 到目前为止,我们进行了以下测试: 1)当 CPU 解锁且签名关闭时,固件(未签名/未加密)按预期启动,我们可以通过 JTAG 毫无问题地访问闪存。 2) 当 CPU 解锁且签名处于活动状态时,固件(已签名/未加密)按预期启动,我们可以通过 JTAG 毫无问题地访问闪存。 3) 当 CPU 被锁定且签名开启时,固件(已签名/加密)将无法启动,并且通过 JTAG 对闪存的访问变得不稳定。 所以,我们遇到了某种加密问题。但在深入探讨加密问题之前,我们想了解步骤 3 中不稳定的闪存行为。 在几次测试中,很明显,一旦 BT_FUSE_SEL 熔断,闪存问题总是会发生(BT_FUSE_SEL 完好:通过 JTAG 完全访问闪存,BT_FUSE_SEL 熔断:通过 JTAG 不稳定访问闪存)。由于我们仍在测试阶段,因此尚未通过熔丝位设置禁用 JTAG。 所以问题是: 为什么 BT_FUSE_SEL 会导致我们失去对闪存的访问权限?(CPU锁定时是否有读取保护机制?)Segger JFlash 工具在 CPU 锁定的情况下是否存在问题?……) 另请参阅: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/mxrt1176-quot-half-quot-bricked-after-programming-fuses-for/mp/2044051 ->同样的问题:BT_FUSE_SEL > 无闪存访问 提前致谢。 此致, 弗洛里安 Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL 嗨@florian_arndt , 感谢您对 NXP MIMXRT 系列产品的关注! BT_FUSE_SEL 不会直接启用 SPI 或非 读取保护或禁用 JTAG。它的功能是强制 Boot ROM 使用存储在 eFuse 中的启动配置,而不是使用 BOOT_CFG 引脚。 如果 OTFAD/加密 XIP 配置也已编程到 eFuse 中,则烧录 BT_FUSE_SEL 可使该配置在每次启动时生效,并消除通过 BOOT_CFG 引脚绕过它的可能性。因此,错误的 OTFAD 上下文、密钥、地址范围或加密映像可能会导致 Boot ROM 在应用程序启动之前失败。 因此,我认为目前最可能的原因是与启动相关的 GPIO 已被旁路,但相应的 eFuse 没有正确配置。BT_FUSE_SEL 本身不会影响 JTAG 连接。我建议您进行A/B测试,以便快速找出问题所在。 此致, 加文 Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL 你好@Gavin_Jia , 谢谢你的回答! 今天我们修复了加密过程(固件中的一个漏洞)。我们的固件现在已启动,CPU 中已激活签名/加密功能。 所以大问题解决了。 剩下的问题是设置 BT_FUSE_SEL 后通过 JTAG 读取 spi-flash 的问题。 附件是我们的保险丝图。 你觉得有什么因素可能导致我们遇到的问题吗? 提前致谢。 弗洛里安
查看全文
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 BOARD_InitHardware() が呼び出される前にリセットとウェイクアップの状態を読み取るために、main() の冒頭付近に以下のコードを追加しました。 /******************************************************************************* * 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キーを押してDeepPowerDownモードに入ります 電源モード選択を待っています... ディープパワーダウン:VDD_CORE電圧ドメイン全体がパワーゲートされます。 起動ソースを選択してください: 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リセットステータスに関する私の解釈は以下のとおりです。 - 0x00004010:ソフトウェアリセット + ウォームリセット - 0x00004011:ソフトウェアリセット + ウォームリセット + ディープダウンウェイクアップリセット この解釈が正しければ、固定状態はディープダウンウェイクアップリセットが最初に行われ、その後ソフトウェアウォームリセットが行われたことを示しています。 アプリケーションの起動コード、system_MCXA266.cを確認しました。例のソースは見つかりませんでしたが、NVIC_SystemReset()、SYSRESETREQ、またはSCB->AIRCRの書き込みは見つかりませんでした。 また、保持されたNOLOAD変数を使用して、SystemInitHook()にカウンターを追加しました。SystemInitHook()はウェイクアップ後に一度だけ実行されたため、SystemInit()後にソフトウェアリセットされた証拠は見つかりませんでした。 私の質問は以下のとおりです。 ディープパワーダウンからのWUUウェイクアップ後、SRS = 0x4010およびSSRS = 0x4011は想定される値ですか? MCXA266 Boot ROMやExtended Bootloaderは、アプリケーション起動前にソフトウェアウォームリセットを発行しますか? どのWUUピンがディープ・パワーダウンのウェイクアップを引き起こしたかを特定するための推奨される方法は何ですか? 私の現在のCMCリセット状態の解釈は以下の通りですが、ビットの定義を誤解していたら訂正してください。 英語は母国語ではないので、説明のどこか分かりにくい部分があれば教えてください。 よろしくお願いします。 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ピンに特有のものではないようです。 捜査の進捗状況について何か新しい情報はありますか? 追加のログ、ソースコード、レジスタ値、またはテスト結果が必要な場合は、お知らせください。 よろしくお願いします。 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、@ka-2020 ご返信とご辛抱に感謝いたします。 ご要望に応じてこちら側でテストを行い、社内チームとも協議しました。ROMの動作に関する明確化にはROMチームからの確認が必要なため、調査に多少時間がかかりました。返信が遅くなり申し訳ありません。ご理解いただければ幸いです。 1. ディープパワーダウンからのWUUウェイクアップ後、SRS = 0x4010およびSSRS = 0x4011は想定される値ですか? はい。 SSRS :前回のメインコールドリセット以降にシステムリセットを生成し、かつクリアしていないすべてのシステムリセットの発生源を保存します。SSRSはコアソフトウェアのリセット後に更新されません。 SRS:メインのウォームリセットのたびに、最新のリセットの種類/発生源を示す更新情報を提供します。 2. MCXA266 Boot ROMやExtended Bootloaderは、アプリケーション起動前にソフトウェアウォームリセットを発行しますか?→いいえ。 3. どのWUUピンがディープ・パワーダウンのウェイクアップを引き起こしたかを特定する推奨方法は何ですか?->> ウェイクアップソースピンを特定するために、 WUU_GetExternalWakeUpPinsFlag() は電源ダウンモードに適しており、WUU割り込みサービスルーチンは通常通り実行できます。しかし、ディープ・パワーダウンのウェイクアップ後は、デバイスがリセットシーケンスで再起動し、WUUフラグが既にクリアされているため使用できません。 ところで、ウェイクアップピンは1つだけ使用していますか、それとも複数のウェイクアップピンを有効にしていますか? よろしくお願いします。 BR アリス Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、 @ka-2020さん ご返信ありがとうございます。 この問題とお客様のご要望を、社内のSEチームに最優先で報告いたしました。私たちはこの要請の重要性を十分に理解しており、積極的に対応を進めています。 もう少し調査する時間をください。最新情報をお伝えし、できるだけ早くご連絡いたします。 ご理解とご辛抱に感謝いたします。 BR アリス Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、 @Alice_Yang さん。 調査していただき、またご説明いただきありがとうございます。 あなたの説明によると、WUUフラグはアプリケーション開始前のディープ・ダウンリセットシーケンス中にクリアされているようです。 私のテストでは、2つのWUU外部ウェイクアップピンが有効になっていました。元のSW2ウェイクアップピンとWUU外部ウェイクアップピン0です。 念のため確認ですが、これはディープ・パワーダウン後にどのWUUピンがウェイクアップを引き起こしたかを特定するソフトウェアの方法がないということですか? よろしくお願いします。 Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、 @ka-2020さん ご辛抱いただきありがとうございます。 根本原因は特定されており、FUTUREサンプルチップの改良版で修正が実装される予定です。 ご迷惑をおかけして申し訳ございません。ご理解いただけますようお願い申し上げます。 よろしくお願いします。 BR アリス Re: MCXA266: WUU wake-up flags are 0 after Deep Power-Down wake-up (SRS=0x4010, SSRS=0x4011) こんにちは、 @Alice_Yang さん。 最新情報のご提供ありがとうございます。 修正はFUTUREサンプルチップのリビジョンで計画されていると理解しています。 再開まで今しばらくお待ちください。
查看全文
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: Julin_AragnM_0-1784069536942.png 此致, 朱利安 Re: FlexCAN(S32K348) bit timing calculation for TJA1445 您是否尝试过在 TJA14XX 系列产品中使用 FlexGUI?不确定它是否包含您请求的定时设置信息 当前版本为 NXP_TJA14XX_GUI_1.1.0可从恩智浦官方网站下载。
查看全文
imx8mmini sai1 max sample rates hi     sai1 connect a codecs support sample rates 768khz/32bit. SAI1-RX0 connect codec_DOUT. have no data with 768khz/32bit and L/R channels to read.but SAI1-TXFS/SAI1-TXC could output 768khz/49.152Mhz. read L/R channels with 768khz/16bit and 384khz/32bit is ok.kernel version 6.1.36. thanks. Re: imx8mmini sai1 max sample rates about codecs dts as below: sofia_0571_0-1784080120640.png run arecord cmd with "-f S32_LE -r 384000 -c 2 -d 1 test.wav" or "-f S16_LE -r 786000 -c 2 -d 1 test.wav" is ok. but run with "-f S32_LE -r 768000 -c 2 -d 1 test.wav",test.wav is NULL. Re: imx8mmini sai1 max sample rates Hello, Could you please share your device tree configuration? Which CODEC are you using? Best regards. Re: imx8mmini sai1 max sample rates Hello, If you are getting errors related to the sample rate, could be caused by clock source since it is not able to generate the necessary frequency for that sample rate. Sometimes, is needed to use a dedicated clock source such as an external clock to get an specific sample rate. Best regards. Re: imx8mmini sai1 max sample rates when read with 768kHz 32bit x 2 channel,SAI1_TXFS/SAI1_TXC output is ok(768khz/49.152Mhz),The codec data output pin (connect to SAI1_RX0)has data output when checked with an oscilloscope.Is it possible that imx8mmini sdma is not worKing? Re: imx8mmini sai1 max sample rates Hello, Do you get underflow or overflow errors during testing? Best regards. Re: imx8mmini sai1 max sample rates get kernel print errors during testing as below: [ 506.336480] [858] wait_for_avail:1936: asoc-simple-card sound-pcmdev: capture write error (DMA or IRQ trouble?) Re: imx8mmini sai1 max sample rates Hello, Please share your dmesg: dmesg | grep -i -E "xrun|overrun|dma|fifo|sdma|sai" With that error log the issue could be caused by an overrun, please try to increase period and buffer size, for example: arecord -D hw:0,0 -f S32_LE -r 768000 -c 2 --buffer-size=65536 --period-size=8192 -d 5 test.wav Best regards. Re: imx8mmini sai1 max sample rates hi JorgeCas:  thanks for your reply. the same error when  increase period and buffer size. ------------------------------------ root@mx8mm:/tmp# arecord -v -D hw:0,0 -f S16_LE -r 768000 -c 2 -d 1 test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 768000 Hz, Stereo Hardware PCM card 0 'pcmdev-audio' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 768000 exact rate : 768000 (768000/1) msbits : 16 buffer_size : 131064 period_size : 16383 period_time : 21332 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 16383 period_event : 0 start_threshold : 1 stop_threshold : 131064 silence_threshold: 0 silence_size : 0 boundary : 9222809086901354496 appl_ptr : 0 hw_ptr : 0 root@mx8mm:/tmp# ls test.wav -la -rw-r--r-- 1 root root 3072044 Jul 22 22:09 test.wav 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 Recording WAVE 'test.wav' : Signed 32 bit Little Endian, Rate 768000 Hz, Stereo arecord: pcm_read:2221: read error: Input/output error root@mx8mm:/tmp# dmesg | grep -i -E "xrun|overrun|dma|fifo|sdma|sai" [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000b8400000, size 1 MiB [ 0.000000] OF: reserved mem: initialized node vdevbuffer@b8400000, compatible id shared-dma-pool [ 0.000000] DMA [mem 0x0000000040000000-0x00000000bfffffff] [ 0.000000] DMA32 empty [ 0.000000] Policy zone: DMA [ 0.043871] DMA: preallocated 256 KiB GFP_KERNEL pool for atomic allocations [ 0.044176] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations [ 0.044364] DMA: preallocated 256 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations [ 0.105243] iommu: DMA domain TLB invalidation policy: strict mode [ 0.195002] imx-sdma 302c0000.dma-controller: Direct firmware load for imx/sdma/sdma-imx7d.bin failed with error -2 [ 0.195018] imx-sdma 302c0000.dma-controller: Falling back to sysfs fallback for: imx/sdma/sdma-imx7d.bin [ 0.199761] mxs-dma 33000000.dma-controller: initialized [ 1.996379] mmc2: SDHCI controller on 30b60000.mmc [30b60000.mmc] using ADMA [ 2.786360] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA [ 8.812860] imx-sdma 302c0000.dma-controller: firmware found. [ 8.818748] imx-sdma 30bd0000.dma-controller: firmware found. [ 8.825901] imx-sdma 30bd0000.dma-controller: loaded firmware 4.6 [ 91.326700] [857] soc_hw_sanity_check:775: 30010000.sai-pcmdevice-codec: ASoC: pcmdevice-codec <-> 30010000.sai info: [ 91.326722] [857] soc_hw_sanity_check:777: 30010000.sai-pcmdevice-codec: ASoC: rate mask 0x154c0 [ 91.326728] [857] soc_hw_sanity_check:778: 30010000.sai-pcmdevice-codec: ASoC: ch min 2 max 8 [ 91.326734] [857] soc_hw_sanity_check:780: 30010000.sai-pcmdevice-codec: ASoC: rate min 44100 max 768000 [ 91.342776] [857] fsl_sai_set_bclk:460: fsl-sai 30010000.sai: ratio 2 for freq 24576000Hz based on clock 49152000Hz [ 91.342784] [857] fsl_sai_set_bclk:481: fsl-sai 30010000.sai: best fit: clock id=1, div=2, deviation =0 [ 91.343315] [857] dapm_update_dai_unlocked:2698: fsl-sai 30010000.sai: Update DAI routes for 30010000.sai capture [ 113.965788] [861] soc_hw_sanity_check:775: 30010000.sai-pcmdevice-codec: ASoC: pcmdevice-codec <-> 30010000.sai info: [ 113.965809] [861] soc_hw_sanity_check:777: 30010000.sai-pcmdevice-codec: ASoC: rate mask 0x154c0 [ 113.965816] [861] soc_hw_sanity_check:778: 30010000.sai-pcmdevice-codec: ASoC: ch min 2 max 8 [ 113.965822] [861] soc_hw_sanity_check:780: 30010000.sai-pcmdevice-codec: ASoC: rate min 44100 max 768000 [ 113.977610] [861] fsl_sai_set_bclk:460: fsl-sai 30010000.sai: ratio 1 for freq 49152000Hz based on clock 49152000Hz [ 113.977618] [861] fsl_sai_set_bclk:481: fsl-sai 30010000.sai: best fit: clock id=1, div=1, deviation =0 [ 113.978149] [861] dapm_update_dai_unlocked:2698: fsl-sai 30010000.sai: Update DAI routes for 30010000.sai capture [ 124.127055] [861] wait_for_avail:1936: asoc-simple-card sound-pcmdev: capture write error (DMA or IRQ trouble?) root@mx8mm:/tmp# ls test.wav -la -rw-r--r-- 1 root root 44 Jul 22 22:09 test.wav root@mx8mm:/tmp#
查看全文
How to configure the PF53 to output 0.8V? Hello, I am using S32G399, MVR5510AMDALES, and MPF5302AMDA0ES for my design. According to the datasheet, the MPF5302AMDA0ES is a non-programmed device. How can I configure the MPF5302AMDA0ES to output 0.8V to the S32G399 Core? Supply uses it. I originally wanted to program the S32G399 via JTAG so that the S32G399 could configure the MPF5302AMDA0ES to output 0.8V via IIC. However, there is no 0.8V being supplied to the S32G399 core. Supply cannot connect via JTAG. This seems to be a vicious cycle. MichaelTao_0-1784009570077.png Re: PF53如何配置输出0.8V Okay, thank you. I'll post it again on the new page. Re: PF53如何配置输出0.8V Hello, @MichaelTao Hello, generally speaking 1. During the engineering development phase, customers are allowed to use the NXP GUI and socketed evaluation board to perform OTP emulation/programming (which can then be used with the S32G). 2. For custom OTPs used in the mass production stage, you need to contact NXP's sales channel/distributor; mass production OTP programming should be completed by NXP or a recommended third party. Since this forum primarily addresses issues related to the S32G itself, if you require further details for confirmation, please post in the following forums where dedicated product support engineers will provide further assistance. Thank you for your understanding. BR Chenyin BR Chenyin
查看全文
[i.MX95/AAOS16] Bringup support HW: i.MX95 15x15 SW: AAOS16_1.3.0 We patched about all files. But, still has a kernel boot problem. Need a Richard-kim's support. Re: [i.MX95/AAOS16] Bringup support Hello @Jaeheon-Sim_Mobis, Please find the revised guideline attached. I have also attached all the patched files with the correct directory structure so that you can directly overwrite them in your source tree. Thank you. Re: [i.MX95/AAOS16] Bringup support Will this work for the 15x15 frdm-mx95? Re: [i.MX95/AAOS16] Bringup support No, those patches are for custom board based on i.MX95 15x15 EVK.
查看全文
GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 GUIGuider-2.0.0,Windows11,生成C代码时generated文件下面的文件夹全是空的,日志显示已经生成成功,实际文件夹全是空的,同意电脑,GUI-Guider-1.10.1-GA可以完美生成。关了杀毒软件,用管理员启动,等等试了各种方法,都一样,有没有遇到相同问题的,请教一下。 21:10:08INFO[gg_event] gg_event_layer_sys.c Generated 21:10:08INFO[gg_event] gg_event_layer_top.c Generated 21:10:08INFO[gg_event] gg_event_layer_bottom.c Generated 21:10:08INFOupdate-sdk Started 21:10:08INFOTarget Executor initialized 21:10:08SUCCESSSDK template updated successfully 21:10:08SUCCESSOperation completed in 0.00s 21:10:08INFO[gg_event] gg_event_screen.c Generated 21:10:08INFO[gg_event] gg_event.h Generated 21:10:08INFO[gg_event] Generation completed 21:10:08SUCCESS=== Code generation completed successfully === Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 我重装系统都不行,GUI Guider1.10能够正常使用。一个空白工程加了一个按钮。 Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 Hello @IFYINT , 抱歉让您久等了。您方便共享一下出问题的工程吗,我们这边尝试复现一下。 BR Celeste Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 我这边试了一下(windows 11 PC),没能复现您的问题: Celeste_Liu_0-1784687143167.png 您那边方便换一台电脑再试一下吗? Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 换电脑是可以的,能够正常生成文件,就是这台电脑不行,之前运行1.10版本是可以的。 屏幕截图 2026-07-24 202549.png Re: GUIGuider-2.0.0生成C代码时generated文件下面的文件夹全是空的 我这边又试了一下,还是没能复现你的情况,你能检查一下你项目工程的路径吗?有没有生成generated文件夹,如果没有文件夹,你手动创建后重新generate code试试呢? Celeste_Liu_0-1785142973015.png 同时还是建议你导出工程发我们看看。
查看全文
RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL Hello, we are testing the signing and encryption process on RT1176 CPU. Our basic System setup is: UART/JTAG <-> RT1176 <-> SPI Nor Flash The Software we use for testing is: - RT1176 testfirmware (simple firmware which does active an LED after boot) - NXP MCUXpresso Secure Provisioning / blhost (for signing and encryption via UART) - Segger JFlash (for Flash access via JTAG) So far, we carried out the following tests: 1) While the CPU is unlocked and signing is off, the firmware (unsigned / not encrypted) boot as expected and we can access the flash without problems via JTAG. 2) While the CPU is unlocked and signing is active, the firmware (signed / not encrypted) boot as expected and we can access the flash without problems via JTAG. 3) While the CPU is locked and signing is on, the firmware (signed / encrypted) will not boot and access to the flash becomes unstable via JTAG. So, we have some kind of encryption issue. But before we examine the big encryption issue we want to understand the unstable flash behavior in step 3. During a few tests, it became apparent that the flash problem always occurs as soon as BT_FUSE_SEL is blown (BT_FUSE_SEL intact: full flash access via jtag, BT_FUSE_SEL blown: unstable flash access via JTAG). Since we're still testing, we haven't disabled JTAG via fuse setting. So the Question is: Why does BT_FUSE_SEL cause us to lose access to flash? (Is there some read-out-protection active when the CPU is locked? Does the segger jflash tool have problems with the locked CPU? ...) Also see: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/mxrt1176-quot-half-quot-bricked-after-programming-fuses-for/m-p/2044051 -> same issue: BT_FUSE_SEL > no flash access Thanks in advance. Best regards, Florian Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL Hi @florian_arndt , Thanks for your interest in NXP MIMXRT series! BT_FUSE_SEL does not directly enable SPI NOR read-out protection or disable JTAG. Its function is to force the Boot ROM to use the boot configuration stored in eFuse instead of the BOOT_CFG pins. If the OTFAD/encrypted-XIP configuration has also been programmed into eFuse, burning BT_FUSE_SEL makes that configuration effective on every boot and removes the possibility of bypassing it through the BOOT_CFG pins. An incorrect OTFAD context, key, address range, or encrypted image can therefore cause the Boot ROM to fail before the application starts. Therefore, I believe the most likely cause at this point is that the GPIOs related to boot have been bypassed, but the corresponding eFuse has not been properly configured. BT_FUSE_SEL itself does not affect the JTAG connection. I suggest you conduct an A/B test to quickly pinpoint the issue. Best regards, Gavin Re: RT1176 - SPI NOR-Flash readout issue via JTAG after programming BT_FUSE_SEL Hello @Gavin_Jia, thanks for your answer! Today we fixed the encryption process (bug in our firmware). Our Firmware is now booting with signing/encryption activated in the CPU. So the big issue is fixed. Whats left is the spi-flash read out issue via JTAG after setting BT_FUSE_SEL. Attached you will find our fusemap. Do you see anything which could lead to our problem? Thanks in advance. Florian
查看全文
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レイテンシやタスクレイテンシ(ns単位)も含まれます。例としての結果:no-load IRQ レイテンシ min/avg/max/stddev = 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 ユーザーガイド — RT レイテンシアプリケーション ベンチマークをハードウェアIRQイベントとソフトウェア動作間の時間差と定義し、ハードウェアタイマーとサブマイクロ秒単位の精度で測定します。 TSNの能力 i.MX 8M Plus製品/リファレンスマテリアル i.MX 8M PlusはデュアルGbイーサネットを搭載し、そのうち1つはTSNに対応し、産業用リアルタイム制御には統合 800 MHzのArm Cortex-M7 を使用します。 TSNハードウェア規格 i.MX 8M プラスリファレンスマニュアル TSNのサポートには 、IEEE 802.1Qbv Time-Aware Shaper 、 802.1Qav Credit-Based Shaper 、 IEEE 1588v2 PTP 、およびイーサネットブロック実装 802.1Qbv-2015が含まれます 、 802.3br 、 そして 802.1Qbu フレームプリエンプション関連のTSN関数。 TSNテスト/検証環境 リアルタイムエッジユーザーガイド トラフィック生成・解析およびレイテンシ、ジッター、同期精度の監視を含む8M Plus TSNの能力を評価するためのTSNテスト環境 i.MX 説明します。 TSNジッター/レイテンシの例 リアルタイムエッジユーザーガイド — TSNエンドポイントサンプルアプリ トラフィックの最小/平均/最大レイテンシやノート レイテンシは約503μs と レイテンシ ジッターは約300 ns を含むTSNエンドポイント統計を提供します。 TSNアプリケーションデモ AN13588 GenAVB/TSNのリアルタイム制御アプリケーションを実証します。これは 2ミリ秒サイクル  、400μsの予約/保証制御トラフィックウィンドウ 、スケジューリング、プロセッシングタイミング、トラフィックの正確性、レイテンシのための統計スレッドを記述しています。 TSN 802.1Qbv デモ AN13995 8M Plus i.MX を用いたTSN 802.1Qbvの実演と、時間認識シェーピングが固定リピーティングサイクルを用いてデターミニスティックなレイテンシを提供する方法を説明しています。また、Linux  tc  /  taprio  configurationの例も含まれています。   Re: Regarding 8M Plus Real time Accuracy @yipingwang 情報を提供していただきありがとうございます。iMX8M Plus EVKについても情報を教えていただけますか? ありがとうございます。 Re: Regarding 8M Plus Real time Accuracy i.MX95 EVKに関する公式な「リアルタイム性能レポート」は公開されていないことを承知しております。しかし、NXPはi.MX95プラットフォーム上でリアルタイムのベンチマークを内部で行っています。内部ベンチマーク文書によると、cyclictestおよびEtherCATのパフォーマンス評価は、Linux上でリアルタイムエッジソフトウェアを実行するi.MX95 LPDDR5 EVK上で実施PREEMPT_RTされています。報告された例としては、6時間のストレスNGテストにおける最大周期テスト**レイテンシ**約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のリアルタイムパフォーマンスやジッターに関する公式なパフォーマンスレポートは現在存在しないと伝えられました。 しかし、リアルタイムレイテンシを評価するためのテスト手法(例:cyclictest)についてのドキュメントも提供しました。 これは我々の側で多少の混乱を招いている。標準化されたテスト手法が存在することから、そのようなテストは少なくともリファレンスEVKプラットフォーム上で内部で実施されたと仮定します。 したがって、以下の点を明確にしたいと思います。 NXPはi.MX95 EVKのリアルタイム性能(例:レイテンシ、ジッター)の内部測定を行ったことはありますか? もしそうなら、共有できる参考や基準の結果はありますか? リアルタイムのパフォーマンスは、システム構成やワークロードによって変動する可能性があることを理解しています。しかし、管理された条件下(例えば、デフォルトのBSP、最小負荷)でのベースライン結果であっても、初期評価には非常に役立つだろう。 再開まで今しばらくお待ちください。 hankwang_0-1784018178178.png Re: Regarding 8M Plus Real time Accuracy REALTIMEEDGEUG (リアルタイムエッジソフトウェアユーザーガイド)(https://www.nxp.com/docs/en/user-guide/REALTIMEEDGEUG.pdf) .リアルタイムエッジソフトウェア(最も関連性が高い) NXPの Real-Time Edgeソフトウェア は公式にi.MX8M Plus EVKをサポートし、以下を含みます: PREEMPT_RT Linux TSNスタック IEEE 802.1AS (gPTP) 同期 TSNトラフィックシェーピングとスケジューリング EtherCAT、OPC-UA、CAN関連の産業用プロトコル Cortex-A53 + Cortex-M7を用いた異種リアルタイム動作 内部文書 REALTIMEEDGEUG によると、Real-Time Edge Softwareは以下の機能を提供します: リアルタイムネットワーキング(TSN) リアルタイムLinux(PREEMPT_RT) 純粋なRTOS/ベアメタルオプション 刑務所の仕切り インダストリアルプロトコルサポート i.MX 8M Plus LPDDR4 EVKのサポート NXPアプリケーションノート AN13995 – i.MX 8M Plusを用いたTSN 802.1Qbvデモンストレーション リアルタイムエッジのSix Pack資料(PREEMPT_RT+TSNサポートを説明する) Re: Regarding 8M Plus Real time Accuracy @yipingwang情報を提供していただき、本当にありがとうございました。
查看全文
FlexCAN(S32K348) bit timing calculation for TJA1445 Hello, I downloaded the attachment from the MPC5xxx/S32Kxx/LPCxxxx: CAN / CAN FD bit timing calculation knowledge base document to configure my settings. However, I cannot find the option for the TJA1445 transceiver in the calculator, so I am unable to proceed with the configuration for my S32K348 board. Could you please advise if there is an updated version of the calculator that includes the TJA1445 transceiver? If not, which alternative transceiver from the existing dropdown list would be the most compatible or closest option to select instead? Thank you in advance for your help! Best regards, Re: FlexCAN(S32K348) bit timing calculation for TJA1445 Hi @Penta7, By selecting Transceiver, propagation delay parameter is also loaded, but can be simply overwritten by user value. You can refer to TJA1445's datasheet and overwrite propTXRX to 220 ns: Julin_AragnM_0-1784069536942.png Best regards, Julián Re: FlexCAN(S32K348) bit timing calculation for TJA1445 Do you try FlexGUI for TJA14XX Family? Not sure it has timing setting information for your request Current version is NXP_TJA14XX_GUI_1.1.0 and can be downloaded from NXP official website
查看全文