Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
SL3S1013FTB0 RFID应答器原理图检查 这是我们正在使用的RFID应答器电路,请您检查一下原理图连接是否正确。 该电路既适用于自供电配置,也适用于外部(3.6V)供电配置。 自供电配置 - R37 = DNP 并将 0 欧姆连接到 R35。 外部(3.6V)电源配置 – R35 = DNP 并将 0 欧姆连接到 R37。 请告诉我我的配置是否正确。 Re: SL3S1013FTB0 RFID transponder schematic check 你好@pragashsangaran , 希望你一切都好。 对于 UCODE G2iM,OUT 引脚是一个数字输出,可用于防拆回路、小型外部电路或作为指示器;这些配置需要外部提供 VDD 引脚。 如果 R35 被填充,它将引入一个电连接,从而激活“防篡改指示器”位,如标签防篡改报警功能所述(请参阅UCODE G2i 的 AN10940 常见问题解答,第 16 章)。这是您申请该申请的预期用途吗? 外部供电时,需要进行以下配置: 问候, 爱德华多。
View full article
NXP Config Tools 26.06 for i.MX 无法加载已保存的配置 你好, 在评估 i.MX95 的新版 DDR 配置时,我发现配置工具中似乎存在一个错误。 以下是我具体的操作步骤,以便可以重现该问题: 1. 安装了该工具的Linux版本。 2. 创建了一个新配置。 3. 选定处理器 MIMX9596xxxxN。 4. 将预设更改为“LPDDR4X EVK / FRDM 15x15 4000MTs 配置”。 5. 保存配置,然后关闭工具。 6. 重新打开工具并加载已保存的配置。 此时根本不显示DDR配置信息。 至少 26.03 版本启动时 MCU 未被选中(手动选择即可解决问题),现在这个问题无法解决。 非常感谢您的帮助。 此致, 埃马努埃莱 Re: NXP Config Tools 26.06 for i.MX not loading saved configuration 该工具的 Windows 版本也存在同样的问题。 附图。 Re: NXP Config Tools 26.06 for i.MX not loading saved configuration 你好, 感谢您报告该工具的这个漏洞。 我能看出我这边的问题所在。 我会将此事上报给内部团队,以便尽快解决。 顺祝商祺!
View full article
How to Disable Mass Erase on the FRDM-A-S32K344 have created two applications for the FRDM-A-S32K344. One application is located at address 0x00400000, and the other is located at address 0x00500000. When I flash one of the applications using the onboard debugger, it performs a mass erase and removes the other application as well. How can I disable mass erase and configure the debugger to erase only a specific flash region or section during programming? Re: How to Disable Mass Erase on the FRDM-A-S32K344 Hello, OK, So you are able to load both binaries at once successfully. But, you didn't mention that you will use bootloader. What you actually want Reset → Bootloader runs → wait for SW2 → jump to App   When using Launch Group in S32DS, each debug configuration loads its ELF and the last one determines the current PC. Therefore, the application entry point overrides the bootloader, causing it to be skipped. To ensure correct bootloader execution, use a single debug configuration that loads both images but starts execution from the bootloader reset vector. Also disable “Run to main” to avoid skipping startup code. After a real reset the S32K3 always starts execution from the predefined boot address (internal flash at 0x00400000), and the first valid image (typically your bootloader) is executed. However, during debugging with S32DS, this behavior can be overridden by the debugger, which may set the program counter to the application entry point after loading ELF files, effectively bypassing the bootloader. Best regards, Peter Re: How to Disable Mass Erase on the FRDM-A-S32K344 Hello, Thank you for the suggestion. I created a Launch Group and added both the Bootloader and Application ELF debug configurations. However, when I start the debug session, it appears that only the application code is running, and the bootloader execution is being bypassed. My requirement is for the bootloader to execute first after reset and then jump to the application only when SW2 is pressed. Could you please advise if there are any additional Launch Group settings or debugger configurations required to ensure the bootloader runs before the application? I am using on board debugger in FRDM-A-S32K344 Re: How to Disable Mass Erase on the FRDM-A-S32K344 Hello, In Debug Configurations, you can create a Launch Group and simply add all the ELF files you want to load. This lets you load multiple images (e.g. bootloader + application) in one go. Best regards, Peter Re: How to Disable Mass Erase on the FRDM-A-S32K344 Hello Can you explain how to configure S32DS so that both ELF files are loaded, but the PC is set to the bootloader Reset_Handler at 0x00400000 instead of the application entry point?  Re: How to Disable Mass Erase on the FRDM-A-S32K344 Hi,  can you please check in Memory Browser (during Debug session) if the memory space from 0x00400000 is empty (has been erased by PE Micro) or there is only rewritten entry point?  The multiple .elf files are typically used with multicore MCUs. With single core it may be little bit tricky. One usable way is to have two debug session - in first one use the bootloader .elf file and second one with app, but you need to define which memory space should be preserved. PE Micro always performs mass erase, the preserve memory simply reads data from the preserved memory space, performs mass erase, write back the preserved data and write data from second .elf file.  Other possibility is use s-record tool ( https://srecord.sourceforge.net/ ) , from both .elf files create s-record and merge both s-records with this tool and use merged .srec instead of .elf. You can still use .elf files for debug and symbols. 
View full article
SL3S1013FTB0 RFID transponder schematic check This is the RFID transponder circuit we are using, and I would like you to check the schematic connections to see if they are correct. The circuit is catered for both self-powered and external (3.6V) powered configurations Self-power configuration -  R37 = DNP and connect 0 ohms to R35. External (3.6V) power configuration – R35 = DNP and connect 0 ohms to R37. Please let me know if my configurations are correct. Re: SL3S1013FTB0 RFID transponder schematic check Hello @pragashsangaran, Hope you are doing well. For UCODE G2iM, OUT pin is a digital output that can be used for tamper loop, a small external circuit or as indicator; these configurations require VDD pin to be externally suppled. If you populate R35, it will introduce a galvanic connection that will activate the "tamper indicator" bit, as per Tag Tamper Alarm feature (please see AN10940 FAQs on UCODE G2i, Chapter 16). Is this the intended purpose for your application? For external supply, the following configuration is required: Regards, Eduardo.
View full article
機能リセット後もRAM保持機能が動作しない(S32K3xx) チームの皆さん、こんにちは。 S32K3xx で機能リセット後も変数を保持しようとしていますが、うまくいきません。 実装: カスタムRAMセクションに配置された変数: __attribute__ ((section(".int_sram_results"))) uint32_t retain_var; リセット前に値が更新されます(retain_var=0x11223344 のテスト用)。 リセットタイプ: 機能リセット(ソフトウェアトリガー) 観察された行動: しかし、値は常に0(クリア済み)です。 RAM保持が行われていません 参照情報を確認しました: 既にこの議論を参照し、提案された方法を試しました。 https://community.nxp.com/t5/S32K/S32K311-noinit-ram/td-p/2123035 そこで示した例は私たちのCASEでは通用しませんでした リクエスト: S32K3xxで機能リセット後もRAMを保持するための動作例または最小限のコードスニペットを共有してください。 ありがとうございます ユスアップ S32K3 S32DS-ARM S32K31XEVB-Q100  Re: RAM retention not working across functional reset (S32K3xx) こんにちは、@yusupkhan241 さん。 おそらく、起動コードはリセットのたびにSRAM全体をゼロに初期化する(ECC初期化のため)と思われます。あなたの具体的な起動コードは見ていないので、断言はできません。 リセットが機能するときにECCの初期化をスキップすることも検討できます。 この回答を参照してください。 https://community.nxp.com/t5/S32K/SRAM-ECC-Initialization-for-S32K344/mp/1764143 BR、ダニエル Re: RAM retention not working across functional reset (S32K3xx) こんにちは、@yusupkhan241 さん。 「うまくいかない」とはどういう意味ですか? あなたが投稿したファイルは、最新の変更を反映していないようです。 機能リセット後にスタートアップコードを見てSRAMの変数を観察できますか?これにより、変数がどこで上書きされるかが明確に示されるはずです。 機能リセット後にデバッガーを取り付けるには、スタートコードの冒頭に簡単なループを追加できます。例えば: Loop: mov r0, #1 cmp r0, 0 /* Change r0 to 0 in register view */ bne Loop /* Capture after power-on reset */ よろしくお願いいたします。 ダニエル Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction. Re: RAM retention not working across functional reset (S32K3xx) こんにちは、 @danielmartynek さん。 下記の起動手順を、あなたが共有してくれた変更内容に置き換えてみましたが、うまくいきませんでした。 ご参考までに、関連ファイルをアップロードしました。.s と .ld.c 拡張子のファイルがアップロードされました拡大。内容をご確認いただき、追加情報が必要な場合はお知らせください。 RamInit: /* SRAM ECCを初期化 */ ldr r0, =__RAM_INIT cmp r0、0 /* __RAM_INIT が設定されていない場合はスキップします */ beq SRAM_LOOP_END ldr r0、=MCRGM_DES ldr r1, [r0] ldr r2、=MCRGM_DES_F_POR r1、r1、r2 cmp r1、0 beq NO_INIT_STANDBY_REGION ldr r2, =__INT_SRAM_START ldr r3, =__INT_SRAM_END b ZERO_64B_RAM 上記の手順が更新されました RamInit: /* Check MC_RGM DES register, if it's non-zero, jump to RAMInit_Start. (RAM init is needed if Destructive reset occurred) */ /* To make it work, customer should clear the MC_RGM DES register in application code. */ ldr r4, =MC_RGM_BASE_ADDR /* 0x4028C000 */ ldr r4, [r4, #0x0] cmp r4, #0x0 bne RamInit_Start /* Check MC_RGM FES register, if the F_EXR bit or ST_DONE bit is set, jump to RAMInit_Start. */ /* RAM init is needed if external reset occurred, or BIST Done functional reset occurred. */ /* To make it work, customer should clear the MC_RGM FES F_EXR register bit in application code. */ ldr r4, =MC_RGM_BASE_ADDR ldr r4, [r4, #0x8] ldr r5, =MC_RGM_FES_MASK_RAM_INIT and r4, r4, r5 cmp r4, #0x0 bne RamInit_Start b SRAM_LOOP_END RamInit_Start: /* Initialize SRAM ECC */ ldr r0, =__RAM_INIT cmp r0, 0 /* Skip if __SRAM_INIT is not set */ beq SRAM_LOOP_END ldr r1, =__INT_SRAM_START ldr r2, =__INT_SRAM_END ありがとうございます ユスプ Re: RAM retention not working across functional reset (S32K3xx) こんにちは、 @danielmartynek さん。 RAM保持動作を分離するために、設定を簡略化しました。 私はその変数を専用のSRAM領域に配置し、LED表示とウォッチドッグによるリセット機能を備えた最小限のメイン関数を使用しました。その考え方は次の通りです: 緑色LED → リセット後も値が保持されます 赤色LED → 価値が失われる 以下に、使用されているテストコードを示します。 C __attribute__ ((section(".int_sram_results"), used)) volatile uint32_t retain_var; int main(void) { Clock_Ip_Init(&Clock_Ip_aClockConfig[0]); DIO_Init(); WDT_Init(); if (retain_var == 0xAABBCCDD) { Siul2_Dio_Ip_SetPins(LED_GREEN_PORT, (1UL << LED_GREEN_PIN)); Siul2_Dio_Ip_ClearPins(LED_RED_PORT, (1UL << LED_RED_PIN)); } そうでない場合、 { Siul2_Dio_Ip_SetPins(LED_RED_PORT, (1UL << LED_RED_PIN)); Siul2_Dio_Ip_ClearPins(LED_GREEN_PORT, (1UL << LED_GREEN_PIN)); } retain_var = 0xAABBCCDD; while(1) { /* ウォッチドッグリセット */ } } 表示を減らす 観察: デバッガーを使用して実行した場合、動作は想定どおりです。 しかし、電源投入後のリセット後、LEDが点灯しないため、コードが期待どおりに実行されていない可能性がある。 参考までに、最新のリンカーファイルとスタートアップファイルを添付しました。 起動処理やリセット処理に関して何か不足している点があればお知らせください。 S32DS-ARM S32K31XEVB-Q100  ありがとう、 ユスプ Re: RAM retention not working across functional reset (S32K3xx) テストプロジェクト全体を共有してもらえますか?そうすれば自分の側でも簡単にテストできます。 ありがとうございました。 ダニエル Re: RAM retention not working across functional reset (S32K3xx) こんにちは、 @danielmartynek さん。 以下は、当社のテスト結果から得られた所見です。  デバッグモードの動作: 電源投入リセット(赤色LED): retain_var = 0x5AA55AA5 @ 0x20407B00 ウォッチドッグリセット後(緑色LED): 保持_var = 0xAABBCCDD @ 0x20407B00 これは、デバッガで実行している場合でも、機能リセット後のRAM保持機能が正常に動作していることを確認するものです。 ただし、スタンドアロン(デバッガーなし)で実行する場合: 電源投入後リセットしても、LED表示は点灯しません。 プログラムが実行されていないか、アプリケーションコードに到達していないようです。 この行動の原因を特定する手助けをしてもらえますか?また、完全な.int_sram_resultsを使用する予定です。機能リセット後も複数のパラメータを保持するためのセクション。確実なデータ保持のために、他に何か変更が必要かどうかご提案ください。 さらに、 ウォッチドッグの代替として機能リセットをトリガーするAPIや推奨方法があれば教えていただけますか? 参考までに、スタートアップファイルとリンカーファイルに加えた変更は共有プロジェクトで検証可能です。 起動ファイル(旧コード) RamInit: /* SRAM ECCを初期化 */ ldr r0, =__RAM_INIT cmp r0、0 /* __RAM_INIT が設定されていない場合はスキップします */ beq SRAM_LOOP_END ldr r0、=MCRGM_DES ldr r1, [r0] ldr r2、=MCRGM_DES_F_POR r1、r1、r2 cmp r1、0 beq NO_INIT_STANDBY_REGION ldr r2, =__INT_SRAM_START ldr r3, =__INT_SRAM_END b ZERO_64B_RAM 起動ファイル(新規コード) .equ MC_RGM_BASE_ADDR、0x4028C000 .equ MC_RGM_FES_MASK_RAM_INIT、0xFFFFFFFF RamInit: /* MC_RGM DESレジスタをチェックし、ゼロでない場合はRAMInit_Startにジャンプします。(破壊的リセットが発生した場合は、RAM初期化が必要です) /* 動作させるには、お客様がアプリケーションコードの MC_RGM DES レジスタをクリアする必要があります。*/ ldr r4, =MC_RGM_BASE_ADDR /* 0x4028C000 */ ldr r4、[r4、#0x0] cmp r4、#0x0 bne RamInit_Start /* MC_RGM FESレジスタをチェックし、F_EXRビットまたはST_DONEビットが設定されている場合は、RAMInit_Startにジャンプします。*/ /* 外部リセットが発生した場合、または BIST 完了機能リセットが発生した場合は、RAM 初期化が必要です。*/ /* 動作させるには、お客様はアプリケーションコード内のMC_RGM FES F_EXRレジスタビットをクリアする必要があります。*/ ldr r4、=MC_RGM_BASE_ADDR ldr r4、[r4、#0x8] ldr r5、=MC_RGM_FES_MASK_RAM_INIT r4、r4、r5 cmp r4、#0x0 bne RamInit_Start b SRAM_LOOP_END RamInit_Start: /* SRAM ECCを初期化 */ ldr r0, =__RAM_INIT cmp r0、0 /* __SRAM_INITが設定されていない場合はスキップします */ beq SRAM_LOOP_END ldr r1, =__INT_SRAM_START ldr r2, =__INT_SRAM_END b ZERO_64B_RAM リンカーファイルの変更 古いコード: .int_results (NOLOAD):     { 。= ALIGN(4); KEEP(*(.int_results)) 。+= 0x100; } > int_sram_results 新しいコード: .int_results(NOLOAD):     { 。= ALIGN(4); KEEP(*(.int_results)) } > int_sram_results S32K31XEVB-Q100 ありがとう、 ユスプ Re: RAM retention not working across functional reset (S32K3xx) こんにちは、@yusupkhan241 さん。 デバッグを行った結果、以下のコードに誤りがあることがわかりました。 R2とR3の代わりにR1とR2を使用しました。 R2とR3が必要な理由は以下のとおりです。 この起動コードはどこで入手したのですか? デバッガが接続された状態で、デバッガはSRAM ECCを初期化します。 デバッガーを使用しない場合、0x20400090でハードフォルトが発生しました。 よろしくお願いいたします。 ダニエル
View full article
LA1224 对 CodeWarrior 下载链接的支持似乎失效了。 我正在安装适用于联网设备的 CodeWarrior 版本,并且我想添加对 LA1224 的支持。 在本次讨论中https://community.nxp.com/t5/Layerscape/CodeWarrior-for-LA1224/mp/2107181您提到了这个链接https://support.nxp.com/s/case/500Tg00000KW12ZIAT/community-codewarrior-for-la1224?language=en_US ,但是该链接无法打开。 我拥有适用于 QorIQ LS 系列(ARM V8 ISA)的 CodeWarrior 开发工作室。 版本:11.5.0 版本 ID:200629GA 请提供有效的链接 谢谢! Re: LA1224 support for codewarrior download link isnt working 你好, 您安装的 CodeWarrior 11.5.0 / b200629GA 是支持 LA1224 的正确基础版本。 在 QCVS/项目创建中列出 LA1224 设备取决于额外的配置/更新内容,特别是 NXP 支持引用的 i.MX v16 软件包的配置工具。目前,支持案例下载 URL 会跳转到登录/cookie 页面,因此实际上无法正常工作。 您的 CW 11.5.0 安装是正确的 LA1224 基础,但添加 LA1224 处理器支持取决于额外的更新/配置包——特别是 i.MX v16 的配置工具——并且由于 NXP 登录/cookie 门禁,引用的支持链接目前无法访问。   此致 Re: LA1224 support for codewarrior download link isnt working 谢谢你的回复。 这个问题与我们的防火墙无关——错误页面是由 NXP 自己的服务器生成的,正如本帖中的其他用户所显示的那样。这证实该软件包受限制,不可公开下载。 请您提供对正确的 CodeWarrior 支持文件的直接访问权限(例如,通过 SharePoint,就像您为其他人所做的那样)? 在收到合适的软件包之前,我们无法继续进行 LA1224 的开发。 Re: LA1224 support for codewarrior download link isnt working 不,这将是你的防火墙: https://www.nxp.com/design/design-center/software/development-software/codewarrior-development-tools/downloads:CW_DOWNLOADS 此致
View full article
MCUBOOTによって開始されたデバッグアプリケーション 皆様へ 私たちが使用しているボードはIMXRT1176です。 私は、mcubootで起動した自分のアプリケーションをデバッグしたいと思っています。デバッガに署名されたアプリケーションをフラッシュしてからデバッグさせたいです。私がやったことをお見せしましょう: 1. オリジナルビルドでapp.elfが生成されました 2. app.elfをapp.binに変換し、imgtoolで焼き付けてapp_signed.bin 3. arm-none-eabi-objcopyを使ってapp_signed.binをapp_signed.bin.elfにラップしました 4. このlanuch.json構成を使いました ``` ヤージュ "type": "mcuxpresso-debug", "名前": "デバッグブートローダーアプリ", 「リクエスト」: 「起動」 "cwd": " ${workspaceFolder} ", "実行可能ファイル": " /app.elf", 「isAttach」: false、 「プローブタイプ」: 「リンクサーバー」 "stopAtSymbol": "main", "skipBuildBeforeDebug": true、 「extraSymbolFiles」: [ " /app.elf", " /bootloader.elf", ], 「postLaunchCommands」: [ "load /app_signed.bin.elf 0x30100000" ], "gdbInitCommands": [ 「set remotetimeout 600」 「デバッグファイルディレクトリを設定」 「ノンストップでオフに設定」 ], "gdbServerConfigs": { "Linkserver": { 「device」:「MIMXRT1176xxxxx:MIMXRT1170-EVKB」、 「コア」:「CM7」 }, 「セッガー」: {}, 「ペミクロ」: {} }, }, ``` 動作しているようで、ブートローダーとアプリの両方をデバッグできるのですが、まるでハックのように感じます。 私が一番気に入らないのは、Flashが2回書かれていることです。実行用には署名なしバイナリを書き込み、ロード用には署名付きバイナリを書き込みます(コアコードは当然同じです)。 何か明らかな見落としがあったら教えていただけますか?それを実現するための、もっとクリーンな方法があると思いますか? 参考までに申し上げますが、既に書き込まれたイメージにアタッチする方法は知っています。上記の手順は、デバッグを1ステップで開始できるようにするための利便性に関するものであり、私の目的を説明するために述べました。 ご協力やご提案をいただければ幸いです。どうぞよろしくお願いいたします! よろしくお願いします、 ヤクブ Re: Debug application started by the MCUBOOT こんにちは、 @jslota13245 さん、 現在、署名済みイメージの書き込みとデバッグを単一のワークフローに統合する明確な手順は定義されていません。これらは通常、別々のプロセスとして処理されるためです。一般的には、まず署名済みのイメージをデバイスに書き込み、その後デバッガーを接続します。参考として、 ota_mcuboot_basic 例の「デモの実行」セクションを確認すると役立つかもしれません。ここでは署名画像をフラッシュする2つの異なる方法を示しており、あなたのセットアップに適応できます。さらに、「フラッシュメモリへのデータ転送」セクションでは、フラッシュ処理に使用できる利用可能なツールの概要が提供されています。 一方で、署名済み画像を.bin.elfファイルに変換する理由を教えていただけますか?また、このプロセスのガイドに従っていたかどうかも確認してもらえますか? BR ハビブ Re: Debug application started by the MCUBOOT こんにちは、ハビブ! ご返信ありがとうございます。 ご質問にお答えします。起動時に複数のバイナリを書き込むためのガイドに従いました。私たちはMCUXpresso for VS Codeの代わりにIDEsを使っていますが、前提は同じであるべきです: https://mcuoneclipse.com/2022/11/01/loading-multiple-binary-files-with-gdb/ ここでのアイデアは、elfファイルに署名済みバイナリをデバッグするための情報が含まれているというものです。署名済みバイナリはヘッダーとトレーラーが付随するバイナリに過ぎないからです。.elf ファイルがこのファイルはこのレイアウトを念頭に置いて生成されたものであり、意図どおりに動作するはずです。 今後の参考までに、私が元の投稿で提案した方法はあまりうまく機能しません。なぜなら、デバッガがCPUが稼働している間に存在しない0x00000ブレークポイントで止まってしまうからです。だから、実際のクラッシュは起きていないのではないかと疑っています。ここには明らかに設定や統合デバッガの問題がありますが、正確な原因を特定できません。あなたはもしかして、そのような行動に遭遇したことがありますか? ご提案いただいた方法についてですが、以下の箇所を見つけました。 「`」 外部ツール(ダイレクト方法)を用いて署名付きアプリケーションイメージをプライマリアプリケーションパーティションにプログラムする デバッガーでアプリケーションをジャンプスタートし、署名済みイメージでイメージ更新を行い、ボードをリセットしてブートローダーに更新を任せる(間接方法) 後者の方法は以下の段階的な説明で用いられています。 デモプロジェクトを開いてビルドしてください。既知の問題:MDKリンカーが未使用のboot_hdrセクションに関する警告を発します。これはサンプル機能には影響しません。 SDK例のリードミーに記載されているように、生のバイナリからアプリケーションの署名付きイメージ mcuboot_opensource 準備します。 MCUXpressoの場合、生バイナリは自動的に生成されないことがあります。Binaries/.axf を右クリックしてバイナリツールを使用してください。プロジェクトツリー内のファイルを選択して手動で生成します。 IDEでデバッガを起動してアプリケーションをジャンプスタートしてください。 MCUXpresso IDEの場合、ブートローダー内で実行が終わりのないループで停止します。デバッグを一時停止し、デバッガーコンソールを使用してコマンドjump ResetISRを実行します。 「`」 ただ、VS-codeの拡張機能で何をすればいいのか少し迷っています。残念ながらIDEバックエンドは持っていません。以下の質問に答えていただけると助かりますか? 署名済みのバイナリファイルと、シンボルを含むオリジナルのELFファイルを持っていると仮定しましょう。 1.デバッガーはどのようにして署名付きイメージをキックスタートできるのでしょうか? 2. デバッガはフラッシュせずにキックスタートさせるにはどうすればいいですか?1つ目の項目では、何らかのツールを使ってフラッシュするようにと明記されていますが、2つ目の項目は別のことをしているのでしょうか? 3. デバッガはbase elfファイルだけをフラッシュできません。mcubootヘッダーとトレーラーがないため、それはMCUbootによって破棄されます。 4. 2.3のポイントで「IDEでデバッガを起動してアプリケーションをジャンプスタートする」と書かれている場合、それはデバッガが何かをフラッシュしているという意味ですか?それとも、既に書き込まれたイメージに添付されるのでしょうか? ご協力と貴重なお時間をいただき、ありがとうございます。 🙂 よろしくお願いします、 ヤクブ Re: Debug application started by the MCUBOOT こんにちは、 @jslota13245 さん、 「残念ながらIDEバックエンドを持っていません」とおっしゃったのは、VS CodeのMCUXpresso拡張機能にあまり慣れていないことを指しているのかもしれませんが、私の理解で合っていますか?もしそうなら、公式ドキュメントの「拡張探索」章をよく確認することをお勧めします。そこには拡張機能の特徴がわかりやすく説明されています。 ご質問についてですが、デバッグセッションを開始すると、デフォルトではツールが生成されたイメージをフラッシュメモリに書き込み、その後デバッガを接続します。デバッガは自動的にメイン関数にジャンプします。この点については、「デバッグセッションの開始」セクションで説明されています。このページには、拡張機能のデバッグ機能に関する詳細情報が記載されています。また、「プロジェクトをデバッグする」という章を復習することをお勧めします。そこにはコードのデバッグ手順が示されています。 まずはMCUbootやイメージ署名なしでアプリケーションを検証・デバッグし、完全にテストが終わった後にMCUbootを導入することを強くおすすめします。このプロセスには、鍵生成やイメージ署名などのセキュリティ機能を管理する機能を備えたMCUxpresso Secure Provisioning Toolの使用を強くお勧めします。そのため、このようなアプリケーションを扱う標準ツールとなっています。MCUブートのサインイメージやフラッシュの方法については、7.6.2章で詳しく知ることができます「このようなプロセッサでMCUbootを手動で起動する手順」セキュアプロビジョニングツールユーザーガイド26.03の内容。 一方、MCUbootを統合する場合は、他のイメージによって上書きされない専用のフラッシュ領域に配置するようにしてください。mcuboot_opensource_cm7の例では、各イメージの配置方法の代替案が示されています。 | 地域 | 開始 | 終了 | サイズ | |----------------|------------|------------|--------| | MCUブートコード | 0x30000000 | 0x3003FFFF | 256kB | | プライマリスロット | 0x30040000 | 0x3023FFFF | 2048kB | | セカンダリ スロット | 0x30240000 | 0x3043FFFF | 2048kB | まずMCUブートイメージを専用のフラッシュ領域にプログラムし、署名付きアプリケーションイメージをプライマリまたはセカンダリスロットに入れてください。MCUXpressoセキュアプロビジョニングツールは、このプロセスを一つのワークフロー内で処理し、ブートローダーとイメージをプログラムすることで、先に共有したユーザーガイドの7.6.2節で説明されています。 BR ハビブ
View full article
TRGMUXサポート - MCXE316 私はTRGMUXメソッドを使用して、コンパレータLPCMP0の出力をeMIOS0_CH7(入力キャプチャとして構成されている)の入力にルーティングしようとしています。私はMCXE316というデバイスを使用しています。私の問題点の一つは、入出力の理解と用語の把握であり、もう一つはPERI_TRGMUX.hのバグだと考えています。ファイル。 eMIOS0のチャネル7をシンプルな入力キャプチャとして設定していますが、これは物理ピンに割り当てると正しく動作します。しかし、入力キャプチャはLPCMP0コンパレータの出力によってトリガーされるようにしたいのです。したがって、TRGMUXを使用してコンパレータの出力をeMIOS0_7の入力キャプチャの入力にルーティングできるはずです。 リファレンスマニュアルに添付されているMCXE31_TRGMUX_connectivity.xlsxファイルを見ると、左側に「入力番号」とありますが、これはTRGMUXへの入力だと推測されます。そこにLPCMP_0_COUTという項目があり、入力番号は5となっています。これが私が探しているものだと思います。上部には「EMIOS_0_ipp_ind_emios_ch[7]」が表示され、その上に出力レジスタ番号9が表示されています。チャネル5、6、9も同じ番号になっていることが分かりました。 そこで最初の質問ですが、LPCMP0トリガー出力がチャネル5、6、9ではなくチャネル7に接続されるようにTRGMUXに指示するにはどうすればよいでしょうか?TRGMUXレジスタの内部にはSEL0、SEL1、SEL2、SEL3があることは知っていますが、これらのいずれかを使用してチャネルを選択すればよいのでしょうか?そうであれば、これはどのようにマッピングされているのでしょうか(SEL0はチャネル5など)、それとも別のマッピングがあるのでしょうか、あるいはマッピングは存在しないのでしょうか?マニュアルを確認しましたが、これについては触れられていませんでした。 SEL3がチャネル7用であるという私の推測(あくまでテストのため)に基づいて、SDKのTRGMUX方法を使用してみました。以下が私の呼び出しシーケンスです。 TRGMUX_SetTriggerSource(TRGMUX, kTRGMUX_Emios0_1, kTRGMUX_TriggerInput2, kTRGMUX_SourceLpcmp0 ); TRGMUXをレジスタベースとすると、kTRGMUX_Emios0_1はeMIOS0用のTRGMUXレジスタ(定義値は9)、kTRGMUX_TriggerInput2はレジスタのSEL2入力、kTRGMUX_SourceLpcmp0はトリガーのソース(定義値は5)です。 問題は、このルーチン自体がこの方法内でハードフォルトを発生させることです。このメソッドの実際のSDKコードは以下のとおりです。 status_t TRGMUX_SetTriggerSource(TRGMUX_Type *base, uint32_t index, trgmux_trigger_input_t input, uint32_t trigger_src) ヤージュ uint32_t 型の値; status_t ステータス; value = base->TRGCFG[index]; if (0U != (value & TRGMUX_TRGCFG_LK_MASK)) ヤージュ ステータス = kStatus_TRGMUX_Locked; } それ以外 ヤージュ /* TRGCFGレジスタ内のすべてのSELビットフィールドは同じ長さであるため、SEL0のマスクを使用して他のSELにアクセスします。 * ビットファイル。*/ value = (value & ~((uint32_t)TRGMUX_TRGCFG_SEL0_MASK << (uint32_t)input)) | ((trigger_src & (uint32_t)TRGMUX_TRGCFG_SEL0_MASK) << (uint32_t)input); base->TRGCFG[index] = value; ステータス = kStatus_Success; } ステータスを返します。 } ルーチンは最初の行でクラッシュします value = base->TRGCFG[index]; デバッグ出力を見ると、TRGCFG配列が一度も初期化されていないようです。この変数はPERI_TRGMUX.hで定義されています。そしてその構造は次のとおりです。 /** TRGMUX - レジスタ配列のサイズ */ #define TRGMUX_TRGCFG_COUNT 40u /** TRGMUX - レジスタレイアウト型定義 */ typedef struct { __IO uint32_t TRGCFG[TRGMUX_TRGCFG_COUNT]; /**< TRGMUX ADC12_0 レジスタ..TRGMUX CM7_RXEV レジスタ、配列オフセット: 0x0、配列ステップ: 0x4、有効なインデックス: [0-1、3、6-18、21-39] */ } TRGMUX_Type; TRGCFGが実際にどこで定義されているのか、どうしても見つけることができません。デバッガーでは、配列全体(40個の要素すべて)が199661に設定されていますが、これはゴミデータに違いありません。私は要素9(インデックスは9)にアクセスしています。 そこで2つ目の質問ですが、私はこの方法を正しく使っているのでしょうか?私の想定は正しいのでしょうか?それともSDKのルーチンに問題があるのでしょうか? ボード設計 ブートROM|ブート|フラッシュ クロック|タイマー Re: TRGMUX Assistance - MCXE316 こんにちは、 @brucebowling さん 投稿ありがとうございます! TRGMUX SELx の動作に関するあなたの理解は正しいです。EMIOS0_0 はチャネル 1 ~ 4 用、EMIOS0_1 はチャネル 5 ~ 7 および 9 用です。TRGMUX_connectivity.xlsx に示されているように、チャネル 0 および 8 は使用できません。 また、 私の環境でも同様の現象を再現できました。社内で検討し、解決に役立つ可能性のある関連情報があれば共有します。 Re: TRGMUX Assistance - MCXE316 SDKやTRGMUXの機能に関して新しいフィードバックがないか確認したいのですが。 TRGMUXはペリフェラルごとにレジスタが1つだけなので、次の1行で直接書き込もうとしました: *(volatile uint32_t *)0x40080024UL = 0x00050000UL; TRGMUXのベースアドレス(RMによると)は0x4008_000で、TRGMUX_eMIOS0_1レジスタのオフセットは0x24なので、絶対アドレスは0x40080024になります。LPCMP0_COUT の SELx フィールドは 0x05 です。これを SEL2 ビット位置 (ビット 16:23) にシフトします。ロックビットはリセット時(ロック解除時)は0であるべきで、私はそれをロック解除したままにしておきます。 この1本の線が、毎回深刻な障害によるクラッシュと焼損を引き起こします(不正確な障害)。他のSELxの場所を変更してみましたが、それでもクラッシュします。eMIOSやLPCMPの設定前にこの設定を試しましたし、ペリフェラルを完全にセットアップした後も試しましたが、毎回クラッシュしました。 ここで、マニュアルには見つからない疑問がいくつかあります: 1) TRGMUXリンクは**ペリフェラル**が初期化・有効化される前に設定しますか、それとも後ですか? 2) TRGMUX用のモジュールクロックやそれに類するものはありますか?クロックを有効にする前にモジュールにアクセスすると、私が経験しているようなハードフォルトが発生することは知っています。特に何かは見当たりませんし、TRGMUXレジスタは各ペリフェラルの一部だと思います。つまり、ペリフェラルのクロックを有効にすると必要なTRGMUXのクロックも有効になるはずですよね? ご協力ありがとうございました。 Re: TRGMUX Assistance - MCXE316 こんにちは、 @brucebowling さん 返信が遅くなり申し訳ありません。 TRGMUXクロックはデフォルトでは有効になっていないことに気づきました。クロックが無効化された状態でTRGMUXレジスタにアクセスしようとするとハードフォールトが発生します。時計が一つなくなっていたというあなたの推測は正しかったです。 電話する前に次の一文を追加してもらえますかTRGMUX_SetTriggerSource? CLOCK_EnableClock(kCLOCK_Trgmux); この変更で私の側の問題は解決しました。 参考までに、TRGMUXの使用例はSDKのこちらにあります: ボード/FRDMMCXE31b/demo_apps/mc_pmsm/pmsm_enc これで問題が解決したかどうか、またはTRGMUXに関して他に質問があればお知らせください。 Re: TRGMUX Assistance - MCXE316 OK、クラッシュの問題はまだ解決していませんが、さらに調査したところ、TRGMUXを設定する前にSIUL2 IMCRレジスタを設定する必要があるようです。参考マニュアルに添付されたIOMUX xlsファイルを見ると、eMIOS0_CH[7]でSSSビットを4に設定してTRGMUX_INT_OUT38を選択する必要があり、これはSIUL_IMCR567で行うと書かれています(512の命名オフセットのために512を567から差し引く必要があります)。以下に、この処理に使用したコードと、TRGMUXを設定するコードを示します。 SIUL2->IMCR[55] = SIUL2_IMCR_SSS(4); *(volatile uint32_t *)0x40080024UL = TRGMUX_TRGCFG_SEL3(kTRGMUX_SourceLpcmp0); TRGMUXのハードフォルトが依然として発生しています。 Re: TRGMUX Assistance - MCXE316 はい、クロックにこの行を追加することでハードフォルトとSDK方法が修正されました。そして、私が考え出した直接コーディングによる方法も同様にうまく機能しました。 一般的には、TRGMUXクロックを有効にしIMCRレジスタを設定し、さらにTRGMUXのリンクをSDKメソッドで呼び出す必要があります。これにより、LPCMPはeMIOSの入力キャプチャを適切にトリガーします。 サポートありがとうございます。
View full article
PCA9959の異常な動作 私は、1つのコントローラ(MCU1)でPCA9959に書き込み、SN74CBTLV3257マルチプレクサでSPIバスを切り替え、2つ目のコントローラ(MCU2)で値を読み取る回路を実装しました。MCU同士は直接通信しないが、書き込みと読み込みを順番に行うための仲裁機構が実装されている。 スイッチを切り替えずにMCU1のみで書き込む場合は問題なく動作します。問題はMCU1とMCU2を切り替え始めると発生します。 この星座の中で、LEDドライバがランダムにLEDをスイッチすることがあります。不思議なことに、MCU1で値を書き込み、その後読み戻すと、レジスタの内容は問題ないように見える。 何かヒントはありますか?正誤表は見つかりませんでした。 スイッチの信号: - SDI - CLK - SDO - nCS MCU1からのその他の信号: - nEN - nRESET どんなご支援でも大変ありがたく思います!PCA9959 Re: PCA9959 strange behavior こんにちは、goepeさん 良い一日! 私はSN74CBTLV3257の専門家ではありませんが、調べた情報によると、SN74CBTLV3257はバッファではなくパッシブFETスイッチです。 チャネルを切り替えると、切断された側がHi-Z(浮遊)になりますが、彼はPCA9959これらのピンを「見ている」ことができます SCLK、MOSI、nCSにプルアップ/プルダウンを追加してみてください。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。
View full article
由 MCUBOOT 启动的调试应用程序 各位亲爱的朋友们, 我们使用的电路板是 IMXRT1176。 我想调试一下由 MCU-Boot 启动的应用程序。我希望调试器能够烧录一个已签名的应用程序,然后再进行调试。让我来给你展示一下我做了什么: 1. 原始版本生成了一个 app.elf 文件。 2. 我将 app.elf 文件转换为 app.bin 文件,并使用 imgtool 对其进行签名,生成 app_signed.bin 文件。 3. 我使用 arm-none-eabi-objcopy 将 app_signed.bin 封装成 app_signed.bin.elf。 4. 我使用了这份 launch.json 配置 ``` { "type": "mcuxpresso-debug", "name": "调试引导加载程序应用程序", "请求": "启动", "cwd": " ${workspaceFolder} ", "可执行文件": " /app.elf", "isAttach": false, "probeType": "LinkServer", "stopAtSymbol": "main", "skipBuildBeforeDebug": true, "extraSymbolFiles": [ " /app.elf", " /bootloader.elf", ], "postLaunchCommands": [ "加载 /app_signed.bin.elf 0x30100000" ], "gdbInitCommands": [ “设置远程超时时间为 600”, “设置调试文件目录”, “不停地启动”, ], "gdbServerConfigs": { "链接服务器": { “设备”: “MIMXRT1176xxxxx:MIMXRT1170-EVKB” "核心": "cm7", }, "segger": {}, “pemicro”:{} }, }, ``` 它似乎有效,也就是说我可以调试引导加载程序和应用程序,但这感觉像是一种权宜之计。 我最不喜欢的是“flash”这个词写了两遍。一个用于可执行文件,我们写入无符号二进制文件;一个用于加载文件,我们写入有符号二进制文件(显然,它们具有相同的核心代码)。 请问我是否遗漏了什么显而易见的东西?你认为有没有更简洁的方法来实现这个目标? 仅供参考,我知道如何附加到已刷入的镜像,上述过程更多是为了方便一步开始调试,我提到这一点是为了说明我的目标。 非常感谢您的帮助和建议! 此致, 雅库布 Re: Debug application started by the MCUBOOT 你好@jslota13245 , 目前还没有明确的步骤将刷写和调试签名镜像合并到一个工作流程中,因为这些通常是作为单独的流程处理的。通常情况下,你会先将签名后的镜像文件刷写到设备上,然后再连接调试器。作为参考,您可以查看ota_mcuboot_basic示例的“运行演示”部分,其中演示了两种不同的刷写签名镜像的方法,您可以根据自己的设置进行调整。此外,“将数据传输到闪存”部分概述了可用于刷写过程的可用工具。 另一方面,能否请您解释一下将签名镜像转换为 .bin.elf 文件的原因?另外,您能否确认一下您在进行此操作时是否遵循了指南? BR 哈比卜 Re: Debug application started by the MCUBOOT 你好,哈比卜! 谢谢你的回复。 回答你的问题。我按照这个指南在启动时刷写了多个二进制文件。我们使用 mcuxpresso 来替代 vs-code IDE,但基本原理应该是一样的: https://mcuoneclipse.com/2022/11/01/loading-multiple-binary-files-with-gdb/ 这里的想法是,elf 文件包含调试已签名二进制文件的信息,因为已签名二进制文件只是一个附加了头部和尾部的二进制文件。如果 .elf该文件是根据这种布局生成的,应该可以按预期工作。 供以后参考,我在原帖中建议的方法效果不太好,因为调试器会卡在不存在的 0x00000 断点上,而 CPU 仍在运行,所以我怀疑并没有发生真正的崩溃。这里显然存在一些配置/集成调试器问题,但我无法准确指出问题所在。你是否曾遇到过类似的情况? 关于您建议的方法,我找到了以下部分: ``` 使用外部工具(直接方法)将已签名的应用程序映像编程到主应用程序分区 通过调试器启动应用程序,使用签名映像执行映像更新,RESET板并让引导加载程序执行更新(间接方法) 以下分步骤描述中使用的是后一种方法: 打开演示项目并进行构建。已知问题:MDK 链接器发出有关未使用的boot_hdr段的警告。这不会影响示例的功能。 按照mcuboot_opensource SDK 示例的 readme 文件中的说明,从原始二进制文件准备应用程序的签名映像。 如果是 MCUXpresso,则可能不会自动生成原始二进制文件。右键单击“二进制文件/.axf”后,使用二进制工具在项目树中查找要手动生成的文件。 在 IDE 中启动调试器,快速启动应用程序。 在使用 MCUXpresso IDE 时,程序会在引导加载程序中陷入无限循环。暂停调试,使用调试器控制台并发出命令jump ResetISR 。 ``` 但我不太清楚如何使用 VS Code 的扩展程序——很遗憾,我没有 IDE 后端。请您帮我回答以下问题好吗? 假设我确实有一个已签名的二进制文件和一个包含符号的原始 elf 文件。 1.如何让调试器启动已签名镜像? 2. 如何让调试器在不先烧录固件的情况下启动它?第 1 点明确指出要用某种工具刷写固件——我猜第 2 点是另有用途? 3. 调试器不能只烧录基础 elf 文件,因为它没有 mcuboot 头和尾部,会被 mcuboot 丢弃。 4. 第 2.3 点中提到“在 IDE 中启动调试器以快速启动应用程序”,这是否意味着调试器会烧录一些东西?或者它会附加到已经刷入的镜像上? 感谢您提前提供的帮助和时间。 🙂 此致, 雅库布 Re: Debug application started by the MCUBOOT 你好@jslota13245 , 当您提到“很遗憾,我没有 IDE 后端”时,我理解这可能指的是您对 VS Code 的 MCUXpresso 扩展不太熟悉,我的理解正确吗?如果是这样,我建议您查看该扩展程序官方文档中的“探索扩展程序”章节,因为它提供了对其功能的有用概述。 关于您的问题,当您启动调试会话时,该工具默认会将生成的映像编程到闪存中,然后连接调试器,调试器会自动跳转到主函数。这在“启动调试会话”部分有详细描述,您可以在此页面找到有关扩展程序调试功能的更多信息。我还可以建议您查看“调试项目”这一章节,其中介绍了调试代码的步骤。 我强烈建议您先在不使用 MCUboot 或镜像签名的情况下验证和调试您的应用程序,只有在您的应用程序经过全面测试后才引入 MCUboot。为了完成此过程,我们强烈建议使用 MCUxpresso 安全配置工具,该工具能够管理 MCUboot 的密钥生成和映像签名等安全功能,因此它是处理此类应用程序的标准工具。您可以在 7.6.2 节中找到有关如何对镜像进行签名以及如何刷写 MCUboot 的更多信息。安全配置工具用户指南 26.03中的“使用此类处理器手动启动 MCUboot 的步骤”。 另一方面,在集成 MCUboot 时,请确保将其放置在不会被其他镜像覆盖的专用闪存区域中。mcuboot_opensource_cm7 示例提供了一种放置每个镜像的替代方案: | 区域 | 从 | 到 | 大小 | |----------------|------------|------------|--------| | MCU启动代码 | 0x30000000 | 0x3003FFFF | 256kB | | 主插槽 | 0x30040000 | 0x3023FFFF | 2048kB | | 辅助插槽 | 0x30240000 | 0x3043FFFF | 2048kB | 您应该先将 MCUboot 映像编程到其专用闪存区域中,然后将签名的应用程序映像放入主插槽或辅助插槽中。MCUXpresso 安全配置工具可以简化此过程,它能够在一个工作流程中同时处理引导加载程序编程和映像编程,如我之前分享的用户指南第 7.6.2 节所述。 BR 哈比卜
View full article
Debug application started by the MCUBOOT Dear Everyone, the board we use is IMXRT1176. I would like to debug my application which is started by mcuboot. I would like the debugger to flash a signed application and debug it afterwards. Let me show you what i did: 1. Original build produced me an app.elf 2. I converted an app.elf to app.bin and singed it with imgtool to create app_signed.bin 3. I used arm-none-eabi-objcopy to wrap app_signed.bin into app_signed.bin.elf 4. I used this lanuch.json configuration ``` { "type": "mcuxpresso-debug", "name": "Debug bootloader app", "request": "launch", "cwd": "${workspaceFolder}", "executable": " /app.elf", "isAttach": false, "probeType": "LinkServer", "stopAtSymbol": "main", "skipBuildBeforeDebug": true, "extraSymbolFiles": [     " /app.elf",     " /bootloader.elf", ], "postLaunchCommands": [     "load /app_signed.bin.elf 0x30100000" ], "gdbInitCommands": [    "set remotetimeout 600",     "set debug-file-directory",     "set non-stop off", ], "gdbServerConfigs": {     "linkserver": {          "device": "MIMXRT1176xxxxx:MIMXRT1170-EVKB",          "core": "cm7", }, "segger": {}, "pemicro": {} }, }, ``` It seems to work, meaning i can debug both bootloader and app, but it feels like a hack. What I don't like the most is that flash is written twice. Once for executable where we write unsigned binary and one for load where we write signed binary (which has the same core code obviously). Could you please tell me if i missed something obvious? Do you think there is a cleaner way to achieve that. Just as an info, I know how to attach to already flashed image, the process above is more about convenience to start debugging in one step, I mention this to express what my goal is. Thanks a lot in advance for any help and suggestions! Best Regards, Jakub Re: Debug application started by the MCUBOOT Hello @jslota13245, There are currently no defined steps that combine flashing and debugging a signed image into a single workflow, as these are typically handled as separate processes. In general, you would first flash the signed image onto the device and then attach the debugger afterwards. As a reference, you may find it helpful to review the "Running the demo" section of the ota_mcuboot_basic example, which demonstrates two different approaches for flashing a signed image that could be adapted to your setup. Additionally, the "Transferring data" to the flash memory section provides an overview of the available tools that can be used for the flashing process. On the other hand, could you please clarify the reason for converting the signed image into a .bin.elf file? Also, could you confirm if you followed a guide for this process? BR Habib Re: Debug application started by the MCUBOOT Hello Habib! thank you for the reply. To answer your question. I followed this guide for flashing multiple binaries at the start-up. We use mcuxpresso for vs-code instead of IDE but the premise should be the same: https://mcuoneclipse.com/2022/11/01/loading-multiple-binary-files-with-gdb/ The idea here is that the elf file has information to debug a signed binary, as signed binary is just a binary with header and trailer attached. If the .elf file was generated with this layout in mind it should work as intended.  For future reference, approach i suggested in my original post doesn't work too well as debugger gets stuck on non-existing 0x00000 breakpoints while the CPU is still running so i suspect no real crash has occurred. There is clearly some configuration/integration debugger problem here but I can't point exactly where. Did you encounter such behaviour by any chance? As for your suggested approach, I found this section: ``` programing signed application image to the primary application partition using an external tool (direct method) jump-starting the application by debugger, performing an image update with the signed image, resetting the board and letting the bootloader to perform the update (indirect method) The latter method is used in the following step-by-step description: Open the demo project and build it. Known issue: MDK linker issues warning about unused boot_hdr sections. This does not affect the functionality of the example. Prepare signed image of the application from raw binary as described in the readme of mcuboot_opensource SDK example. In case of MCUXpresso raw binary may not be generated automatically. Use binary tools after right clicking Binaries/.axf file in the project tree to generate it manually. Launch the debugger in your IDE to jump-start the application. In case of MCUXpresso IDE the execution stalls in an endless loop in the bootloader. Pause the debugging and use debugger console and issue command jump ResetISR.  ``` But I'm a bit lost on what do i need to do with the extension for VS-code - I don't have ide backend unfortunately. Could you please help me by answering the questions below? Let's assume i do have a signed binary and original elf file with symbols.  1. How can debugger kick start signed image? 2. How can debugger kick start it without flashing it first? The point 1 explicitly states to flash it with some tool - i assume point 2 does something else?.  3. The debugger can't flash just base elf file as it'll be discarded by the mcuboot as it doesn't have mcuboot header and a trailer. 4. When point 2.3 states 'Launch the debugger in your IDE to jump-start the application' - does it mean the debugger flashes something? Or does it attach to already flashed image? Thanks in advance for your help and time 🙂 Best Regards, Jakub Re: Debug application started by the MCUBOOT Hello @jslota13245, When you mention "I don't have ide backend unfortunately" I understand this may refer to limited familiarity with the MCUXpresso extension for VS Code, is my understanding correct? If so, I recommend reviewing the chapter "Explore Extension" in the official documentation for the extension, as it provides a helpful overview of its features. Regarding your questions, when you start a debug session, the tool by default programs the generated image into flash and then attaches the debugger, which automatically jump to the main function. this is described in the "starting a debug sesion" section, inside this page you will find more information about the functionality of the debug in the extension.  I can also, suggest you review the chapter "debug a project" which shows the steps to debug your code. I highly recommend first validating and debugging your application without MCUboot or image signing and only introducing MCUboot once your application is fully tested. For make this process we strongly recommend using MCUxpresso Secure Provisioning Tool, which has the capabilities to manage security features such as key generation and image signing for MCUboot, which is why this is standard tool to handle applications just like this one. You can find more information about how sign image and flash your MCUboot in the chapter 7.6.2 " Steps to start MCUboot with such a processor manually"of the Secure Provisioning Tool User Guide 26.03. On the other hand, when integrating MCUboot, ensure that it is placed in a dedicated flash region that is not overwritten by other images, the mcuboot_opensource_cm7 example offers an alternative of how place each image:   | Region         | From       | To         | Size   | |----------------|------------|------------|--------| | MCUboot code   | 0x30000000 | 0x3003FFFF | 256kB  | | Primary slot   | 0x30040000 | 0x3023FFFF | 2048kB | | Secondary slot | 0x30240000 | 0x3043FFFF | 2048kB | You should first program the MCUboot image into its dedicated flash region, and then place the signed application image into the primary or secondary slot. The MCUXpresso Secure Provisioning Tool can facilitate this process by handling both, program the bootloader and program the image within a single workflow, as described in section 7.6.2 of the user guide I previously shared. BR Habib
View full article
RAM retention not working across functional reset (S32K3xx) Hi Team, We are trying to retain a variable across functional reset on S32K3xx, but it is not working. Implementation: Variable placed in custom RAM section: __attribute__((section(".int_sram_results"))) uint32_t retain_var;               The value is being updated before reset (for testing retain_var= 0x11223344) . Reset type: Functional reset (software-triggered) Observed behaviour: But value is always 0 (cleared) RAM retention is not happening Reference checked: Already referred this discussion and tried the suggested approach: https://community.nxp.com/t5/S32K/S32K311-noinit-ram/td-p/2123035 The example provided there did not work in our case Request: Please share a working example or minimal snippet for retaining RAM across functional reset on S32K3xx Thanks, Yusup S32K3 S32DS-ARM S32K31XEVB-Q100  Re: RAM retention not working across functional reset (S32K3xx) Hi @yusupkhan241, The startup code most likely initializes the entire SRAM to zero (for ECC initialization) after every reset—I haven’t seen your specific startup code. You could consider skipping the ECC initialization when the reset is functional. Refer to this answer: https://community.nxp.com/t5/S32K/SRAM-ECC-Initialization-for-S32K344/m-p/1764143 BR, Daniel Re: RAM retention not working across functional reset (S32K3xx) Hi @yusupkhan241, What do you mean by “it does not work”? The files you posted do not seem to reflect the latest changes. Can you step through the startup code and observe the variable in SRAM after a functional reset? This should clearly show where the variable gets overwritten. To attach the debugger after the functional reset, you can add a simple loop at the beginning of the startup code, for example: Loop: mov r0, #1 cmp r0, 0 /* Change r0 to 0 in register view */ bne Loop /* Capture after power-on reset */ Regards, Daniel Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction. Re: RAM retention not working across functional reset (S32K3xx) Hi @danielmartynek I have simplified the setup to isolate the RAM retention behavior. I placed the variable in a dedicated SRAM section and used a minimal main function with LED indication and watchdog-triggered reset. The idea is: Green LED → value retained after reset Red LED → value lost Below is the test code being used: C __attribute__((section(".int_sram_results"), used)) volatile uint32_t retain_var; int main(void) { Clock_Ip_Init(&Clock_Ip_aClockConfig[0]); DIO_Init(); WDT_Init(); if (retain_var == 0xAABBCCDD) { Siul2_Dio_Ip_SetPins(LED_GREEN_PORT, (1UL << LED_GREEN_PIN)); Siul2_Dio_Ip_ClearPins(LED_RED_PORT, (1UL << LED_RED_PIN)); } else { Siul2_Dio_Ip_SetPins(LED_RED_PORT, (1UL << LED_RED_PIN)); Siul2_Dio_Ip_ClearPins(LED_GREEN_PORT, (1UL << LED_GREEN_PIN)); } retain_var = 0xAABBCCDD; while (1) { /* watchdog reset */ } } Show less Observation: When running with debugger, the behavior is as expected. However, after power-on reset, there is no LED indication, which suggests the code may not be executing as expected. I have attached the latest linker and startup files for reference. Please let me know if you see anything missing on the startup or reset handling side. S32DS-ARM S32K31XEVB-Q100  Thanks, Yusup Re: RAM retention not working across functional reset (S32K3xx) Hi @danielmartynek I replaced the startup instructions below with the changes you shared, but it did not work. For your reference, I have uploaded the relevant files. The .s and .ld files were uploaded with a .c extension. Please review them and let me know if you need any additional information. RamInit: /* Initialize SRAM ECC */ ldr r0, =__RAM_INIT cmp r0, 0 /* Skip if __RAM_INIT is not set */ beq SRAM_LOOP_END ldr r0, =MCRGM_DES ldr r1, [r0] ldr r2, =MCRGM_DES_F_POR and r1, r1, r2 cmp r1, 0 beq NO_INIT_STANDBY_REGION ldr r2, =__INT_SRAM_START ldr r3, =__INT_SRAM_END b ZERO_64B_RAM The above instructions updated with  RamInit: /* Check MC_RGM DES register, if it's non-zero, jump to RAMInit_Start. (RAM init is needed if Destructive reset occurred) */ /* To make it work, customer should clear the MC_RGM DES register in application code. */ ldr r4, =MC_RGM_BASE_ADDR /* 0x4028C000 */ ldr r4, [r4, #0x0] cmp r4, #0x0 bne RamInit_Start /* Check MC_RGM FES register, if the F_EXR bit or ST_DONE bit is set, jump to RAMInit_Start. */ /* RAM init is needed if external reset occurred, or BIST Done functional reset occurred. */ /* To make it work, customer should clear the MC_RGM FES F_EXR register bit in application code. */ ldr r4, =MC_RGM_BASE_ADDR ldr r4, [r4, #0x8] ldr r5, =MC_RGM_FES_MASK_RAM_INIT and r4, r4, r5 cmp r4, #0x0 bne RamInit_Start b SRAM_LOOP_END RamInit_Start: /* Initialize SRAM ECC */ ldr r0, =__RAM_INIT cmp r0, 0 /* Skip if __SRAM_INIT is not set */ beq SRAM_LOOP_END ldr r1, =__INT_SRAM_START ldr r2, =__INT_SRAM_END Thanks, Yusup Re: RAM retention not working across functional reset (S32K3xx) Can you share the whole test project so that I can easily test it on my side? Thank you, Daniel Re: RAM retention not working across functional reset (S32K3xx) Hi @danielmartynek Below are the observations from our testing:  Debug mode behaviour: Power-on reset (RED LED): retain_var = 0x5AA55AA5 @ 0x20407B00 After watchdog reset (GREEN LED): retain_var = 0xAABBCCDD @ 0x20407B00 This confirms that RAM retention across functional reset is working when running under debugger. However, when running standalone (without debugger): After power-on reset, there is no LED indication. It appears that the program is not executing or not reaching the application code. Could you please help identify what might be causing this behaviour? Also, we are planning to use the complete .int_sram_results section to retain multiple parameters across functional reset. Please suggest if any additional changes are required for reliable retention. Additionally, could you please suggest if there is any API or recommended method to trigger a functional reset (alternative to watchdog)? For reference, I have included the changes made in the startup and linker files, and the same can be verified in the shared project. startup file (old code) RamInit:     /* Initialize SRAM ECC */     ldr  r0, =__RAM_INIT     cmp  r0, 0     /* Skip if __RAM_INIT is not set */     beq SRAM_LOOP_END     ldr r0, =MCRGM_DES     ldr r1, [r0]     ldr r2, =MCRGM_DES_F_POR     and r1, r1, r2     cmp r1, 0     beq NO_INIT_STANDBY_REGION     ldr r2, =__INT_SRAM_START     ldr r3, =__INT_SRAM_END     b   ZERO_64B_RAM startup file (new code) .equ MC_RGM_BASE_ADDR, 0x4028C000 .equ MC_RGM_FES_MASK_RAM_INIT, 0xFFFFFFFF RamInit:                /* Check MC_RGM DES register, if it's non-zero, jump to RAMInit_Start. (RAM init is needed if Destructive reset occurred) */                /* To make it work, customer should clear the MC_RGM DES register in application code. */                ldr r4, =MC_RGM_BASE_ADDR   /* 0x4028C000 */                ldr r4, [r4, #0x0]                cmp r4, #0x0                bne RamInit_Start                /* Check MC_RGM FES register, if the F_EXR bit or ST_DONE bit is set, jump to RAMInit_Start. */                /* RAM init is needed if external reset occurred, or BIST Done functional reset occurred. */                /* To make it work, customer should clear the MC_RGM FES F_EXR register bit in application code. */                ldr r4, =MC_RGM_BASE_ADDR                ldr r4, [r4, #0x8]                ldr r5, =MC_RGM_FES_MASK_RAM_INIT                and r4, r4, r5                cmp r4, #0x0                bne RamInit_Start                b SRAM_LOOP_END                RamInit_Start:                /* Initialize SRAM ECC */                ldr r0, =__RAM_INIT                cmp r0, 0                /* Skip if __SRAM_INIT is not set */                beq SRAM_LOOP_END                ldr r1, =__INT_SRAM_START                ldr r2, =__INT_SRAM_END     b   ZERO_64B_RAM linker file changes old code:     .int_results (NOLOAD):     {         . = ALIGN(4);         KEEP(*(.int_results))         . += 0x100;     } > int_sram_results new code:                    .int_results (NOLOAD):     {         . = ALIGN(4);         KEEP(*(.int_results))     } > int_sram_results    S32K31XEVB-Q100  Thanks, Yusup Re: RAM retention not working across functional reset (S32K3xx) Hi @yusupkhan241, I have debugged it found that the code below was incorrect. It used R1 and R2 instead of R2 and R3: We need R2 and R3 because of this: Where did you get this startup code? With the debugger connected, the debugger initializes the SRAM ECC. Without the debugger, there was a Hardfault at 0x20400090. Regards, Daniel
View full article
在frdm_mcxw72板上,覆盖文件无法正常工作。 我尝试在 frdm_mcxw72 开发板上运行 adc_dt 代码示例,但即使我已经将 overlay 文件添加到设备树文件夹中并修改了 CMakelist 文件中的开发板名称,也无法成功编译。编译过程中总是提示错误:#error "No suitable devicetree overlay specified" 。您能帮我找出原因吗?先谢谢了! Re: Overlay file can't worked in frdm_mcxw72 board 你好 RomanVR, 我把叠加文件放到了正确的位置。但它仍然行不通。您可以在下面的截图中找到更多关于我的工作台的信息。我使用的Zephyr版本是V4.4.0。如有任何发现,请告知。 顺祝商祺! Re: Overlay file can't worked in frdm_mcxw72 board 你好@anliu114036 ,希望你一切都好。 请问您正在使用哪个版本的Zephyr?另外,请说明您是否使用 MCUXpresso for VS Code 扩展来构建示例。 同时,为了简化流程,请确保将叠加层创建在项目文件内的“boards”文件夹中;并确保将叠加层文件命名为“frdm_mcxw72.overlay”。按照这两个步骤操作,Zephyr 将在构建过程中获取您的 overlay,而无需在 CMake 中显式设置其路径。 如果您使用的是我们的 MCUXpresso for VS Code 扩展,您的项目视图应如下图所示: 请告诉我这是否有帮助。
View full article
Overlay file can't worked in frdm_mcxw72 board I tried to run the adc_dt code sample in frdm_mcxw72 board, but it can't be build successfully even i already added the overlay file in the device tree folder and modified the board name in Cmakelist file. it always prompt  error: #error "No suitable devicetree overlay specified" during building . can you help me find the cause, thanks in advance! Re: Overlay file can't worked in frdm_mcxw72 board Hello RomanVR, i put the the overlay file in the position. but it still can't work. you can find more information about my workbench in below snapshot. i used the zephyr version is V4.4.0.  any finding please me know.  Best regards! Re: Overlay file can't worked in frdm_mcxw72 board Hello @anliu114036, hope you are doing well. Would you please share which Zephyr version are you working on? Also, please clarify if you are using MCUXpresso for VS Code extension to build the example. In the meantime, to ease the process, make sure that your overlay is created inside the "boards" folder that should be inside of your project files; make sure that your overlay file is named as "frdm_mcxw72.overlay", following these two steps will make Zephyr fetch your overlay in build process without the need of setting its path explicitly in CMake. If you are using our MCUXpresso for VS Code extension, your project view should look as the image below: Please let me know if this helps.
View full article
FRDM-A-S32K344で一括消去を無効にする方法 FRDM-A-S32K344向けに2つのアプリケーションを作成しました。1つのアプリケーションはアドレス0x00400000に、もう1つはアドレス0x00500000にあります。 オンボードデバッガで1つのアプリケーションをフラッシュすると、一括消去が行われ、もう1つのアプリケーションも削除されます。 大量消去を無効にして、デバッガーをプログラミング中に特定のフラッシュ領域やセクションだけ消去するように設定するにはどうすればいいですか? Re: How to Disable Mass Erase on the FRDM-A-S32K344 こんにちは、 なるほど、両方のバイナリを同時に正常に読み込めるということですね。 しかし、ブートローダーを使用する予定だとはおっしゃっていませんでしたね。 あなたが本当に欲しいもの リセット → ブートローダー実行 → SW2を待機 → アプリへジャンプ   S32DSでLaunch Groupを使うと、各デバッグ構成はELFを読み込み、最後の設定が現在のPCを決定します。したがって、アプリケーションのエントリポイントがブートローダーを上書きし、スキップします。 ブートローダーが正しく実行されるようにするには、両方のイメージをロードするものの、ブートローダーのリセットベクタから実行を開始する単一のデバッグ構成を使用してください。また、起動コードのスキップを避けるため、「メイン関数へ実行」を無効にしてください。 実際のリセット後、S32K3は必ず事前に定義されたブートアドレス(内部フラッシュ0x00400000)から実行を開始し、最初の有効なイメージ(通常はブートローダー)が実行されます。 しかし、S32DSでのデバッグ時には、この動作がデバッガによって上書きされ、ELFファイルを読み込んだ後にプログラムカウンターをアプリケーションのエントリポイントに設定することで、ブートローダーを実質的にバイパスできます。 よろしくお願いいたします。 ピーター Re: How to Disable Mass Erase on the FRDM-A-S32K344 こんにちは、 ご提案ありがとうございます。 Launch グループを作成し、Bootloaderとアプリケーション ELFのデバッグ設定の両方を追加しました。しかし、デバッグセッションを始めると、アプリケーションコードだけが実行され、ブートローダーの実行がバイパスされているように見えます。私の要件は、ブートローダーがリセット後に最初に実行され、その後SW2が押されたときにのみアプリケーションにジャンプすることです。 ブートローダーがアプリケーションより先に動作するようにするために、追加のLaunch Group設定やデバッガ設定が必要かどうか教えていただけますか? 私はFRDM-A-S32K344の搭載デバッガを使っています Re: How to Disable Mass Erase on the FRDM-A-S32K344 こんにちは、 Debug Configurationsでは、Launch Groupを作成し、読み込みたいすべてのELFファイルを追加するだけです。これにより、複数の画像を読み込むことができます(例:ブートローダー+アプリケーション)を一気に使うことができます。 よろしくお願いいたします。 ピーター Re: How to Disable Mass Erase on the FRDM-A-S32K344 Hello S32DSを両方のELFファイルが読み込まれているけれど、PCがアプリケーションのエントリポイントではなくブートローダー Reset_Handler 0x00400000に設定されるように設定する方法を説明してもらえますか? Re: How to Disable Mass Erase on the FRDM-A-S32K344 こんにちは、 デバッグセッション中にメモリブラウザで、0x00400000のメモリ空間が空(PE Microによって消去されている)か、それとも書き込み済みのエントリポイントだけがあるか確認してもらえますか? 複数の.elfこれらのファイルは通常、マルチコアMCUで使用されます。シングルコアだと少し難しいかもしれません。有効な方法の1つは、2つのデバッグセッションを用意することです。最初のセッションでは、ブートローダーの.elfファイルを使用します。ファイルとアプリ用の2つ目のファイルがありますが、どちらのメモリ領域を保持するかを定義する必要があります。PE Microは常に一括消去を実行します。保存メモリは、保存メモリ領域からデータを読み取り、一括消去を実行し、保存データを書き戻し、2番目の.elfからデータを書き込みます。ファイル。 別の方法としては、s-record ツール ( https://srecord.sourceforge.net/ ) を使用する方法もあります。) 、両方の .elf からこのツールでファイルを作成し、両方のsレコードをマージして、マージされた.srecを使用します。.elf の代わりに。.elfは使えますデバッグ用ファイルとシンボル。
View full article
EB公式デモ集 EBプロジェクトは以下の手順に従ってコンパイルされました。 (1)project_parameters.mk ファイルを修正する (2)S32DSが使用されたため、T32に関連する内容がcheck_build_params.mkファイルに注釈付けされました。 (3)「生成する」は許容されます。 (4)「make build」は誤りです。 これが何が原因だったのか教えていただけますか?メイクファイルを変更する必要はありますか? Re: EB official demo compilation こんにちは@ NXP2 選択したGCCのバージョンが間違っています。 Re: EB official demo compilation ご回答をお待ちしています。
View full article
NFC CSV 导入错误,为什么?HTTPS URL 我们特意购买了 NTAG215 标签,因为它们支持高达 540 字节的 NDEF 数据。我们花费了超过 200 欧元购买这些标签,以确保我们较长的验证 URL 能够顺利显示。 但是,NXP TagWriter 应用程序拒绝导入我们的 CSV 文件,并始终报告“格式无效”。CSV 结构正确(记录类型,URI),文件以带 BOM 的 UTF-8 格式保存,URL 有效,标签有足够的内存。同样的数据可以手动写入单个标签,不会有任何问题。该问题仅在导入 CSV 文件时出现。 这意味着限制因素不是标签、URL 或 CSV 格式。该限制似乎出在 TagWriter 应用程序本身。 令人极其沮丧的是,我们花了这么多钱购买了官方的 NXP 标签,却无法使用官方的 NXP 应用程序批量写入它们。我们不应该被迫购买第三方应用程序才能执行 TagWriter 声称支持的基本操作。 我们需要澄清以下几点: 为什么当 URL 长度在 NTAG215 内存限制范围内时,TagWriter 会拒绝有效的 CSV 文件? 这是已知的限制还是 CSV 导入功能中的一个漏洞? 是否有无需付费购买其他应用程序的官方解决方法? 我们急需一个解决方案,因为我们购买这些标签就是为了应对这种情况。 Re: NFC CSV Import Error, why? HTTPS URLS 我的网址看起来像这样: https://200.410.222.111:4443/verify-status.html?work_id=9d611323a-a9ac-4fb9-9039-74f443cf2720&sig=MKIRQDMQl3/NKQXSKLwZ123IvEgxkda123Gq0LOPqBz84mQIhANGc2GQFSNONSWR27nps0NMieAF5rZSkXt2j2rgquKh6 Re: NFC CSV Import Error, why? HTTPS URLS 谢谢,但他现在什么也不显示了。没有错误提示,但也没有数据。测试时看起来是这样的——正常情况下我们的URL要长得多。 Re: NFC CSV Import Error, why? HTTPS URLS 您好,先生, 我查看了您的 CSV 文件,发现您需要在结构中添加一些字段。 请参考以下社区案例:尝试在 TagWriter for Android 中选择 CSV 文件时出现“未找到有效的 NDEF 记录”错误 - NXP 社区 请在用户手册中查看 3) LINK_RECORD 的描述。 祝您今天过得愉快,先生! Re: NFC CSV Import Error, why? HTTPS URLS 你好, 请问您是否能够成功读取 NDEF 发送的短链接? 我这样问是因为,如果这样可以正常工作,那么问题很可能出在 NDEF 结构本身。请注意,根据 NFC 论坛规范,既有记录也有短记录。如果您的有效载荷大小超过 255 字节,则 NDEF 可能未正确构造。 我建议您查阅 NFC 论坛网站上提供的 NFC 数据交换格式规范。
View full article
S32K396 RTD 5.0.0FlexIO PWM – 「Period [ticks]」パラメータからPWM周期はどのように計算されますか? NXPチームの皆様、こんにちは。 S32K396とRTD 5.0.0、およびFlexIO PWMドライバを使用しています。 私の設定は以下のとおりです。 FLEXIO0_CLK = 160 MHz クロックプリスケーラ = FLEXIO_PWM_IP_CLK_DIV_16 チャネルID = CH_0 PIN ID = PIN_1 生成された構成: const Flexio_Pwm_Ip _ChannelConfigType Flexio_Pwm_Ip _I0_Ch0 = { /* TimerId */ 0 U 、 /* PinId */ 1 U 、 #if (defined(FLEXIO_PWM_IP_HAS_PRESCALER) && (FLEXIO_PWM_IP_HAS_PRESCALER == STD_ON)) /*プリスケーラ*/ FLEXIO_PWM_IP_CLK_DIV_16 、 #endif /* 期間 */ 400 U 、 /* デューティサイクル */ 0 U 、 #if (defined(FLEXIO_PWM_IP_HAS_LOW_MODE) && (FLEXIO_PWM_IP_HAS_LOW_MODE == STD_ON)) /* 極性 */ FLEXIO_PWM_IP_ACTIVE_HIGH 、 #endif /* IrqMode */ FLEXIO_PWM_IP_IRQ_DISABLED 、 /* IPLコールバック */ { /* CbFunction */ NULL_PTR 、 /* CbParameter */ NULL_PTR } 、 /* HLD コールバック */ { /* CbFunction */ NULL_PTR 、 /* CbParameter */ 0 } } ;   私は以下の間の正確な関係を理解しようとしています。 FLEXIOクロック周波数 プリスケーラ 期間 [ティック] デューティサイクル[ティック] 出力PWM周波数 私のサイズは以下の通りです。 期間 デューティ 測定頻度 デューティ 200 100 20kHz 50% 300 100 13.3kHz 33.3% 400 100 27.7kHz 69.4% 500 100 16.3kHz 40% 最初の2つの測定値は、以下のことを示しているようです。 Duty (%) = DutyTicks / PeriodTicks × 100 しかし、FlexIO PWM RTD ドライバの内部で使われている正確なPWM周波数公式を導き出すことはできません。 もう少し詳しく教えていただけますか: FlexIOのPWMドライバが Period(ティック) を出力PWM周波数に変換する際に使う正確な式は何ですか? TIMCMPレジスタは、設定された周期値からどのようにプログラムされるのですか? 有効な期間値の最大値はありますか(例えば、FlexIOタイマーの制限により255カウントなど)? 以下の場合、望ましいPWM周波数(例えば10 kHz)を得るために必要な周期値をどう計算すればよいのでしょうか: FLEXIO0_CLK = 160 MHz プリスケーラー = 16 FlexIOのPWMタイミング計算を説明するアプリケーションノートや参考文書はありますか? 内部タイミング方程式に関する説明があれば大変ありがたいです。 よろしくお願いします。 Re: S32K396 RTD 5.0.0 FlexIO PWM – How is PWM Period Calculated from the "Period [ticks]" こんにちは、 @Esakki さん。 1. あなたの計算式は正しいです。 2. 周期 = 200、デューティ = 100ティックの場合、デュアル8ビットカウンタPWMハイモード(TIMCTL[TIMOD]): TIMCMP = 0x00006363 最上位バイト = 0x63 = 99 → 出力がローの間はデクリメントされる 下位バイト = 0x63 = 99 → 出力がハイの間はデクリメントされる 3. はい、ドライバはFLEXIO_PWM_IP_DEV_ERROR_DETECT = STD_ONのバイトに対して256を超える値を書き込むのを防ぐべきです。 このチェックが無効になっている場合、フィールドがオーバーフローし、それがおそらく発生している問題の根本原因です。 4. 周期(ティック)-勤務時間(ティック)≦256。 このモードでは、指定された入力クロックでは10kHzを実現することはできません。プリスケーラーの値を上げる必要があります。 5. この点はリファレンスマニュアルのみが扱っています。 よろしくお願いいたします。 ダニエル Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.     Re: S32K396 RTD 5.0.0 FlexIO PWM – How is PWM Period Calculated from the "Period [ticks]" こんにちは、ダニエルさん。 ご説明ありがとうございます。 期間計算に関して、もう一つ質問があります。 あなたの説明から、デュアル8ビットカウンタのPWMハイモードでは次のようになっていると理解しました。 TIMCMP[15:8] = 期間 - 義務 - 1 TIMCMP[7:0] = 義務 - 1 また、両フィールドともカウント数は256に制限されています。 出力PWM周波数を計算する正確な公式を教えていただけますか: FlexIO入力クロック周波数 プリスケーラ 期間値 例えば、次のような場合: FlexIOクロック = 160MHz プリスケーラー = 256 期間 = 63ティック 想定されるPWM周波数はどれくらいでしょうか? 以下の式を使用します。 PWM周波数 = FlexIOクロック / (プリスケーラ × 周期) およそ9.92kHzになると思われます。 しかし、PWM出力を測定したところ、約3.9kHzであることが確認されました。 同様に、以下についても: プリスケーラー = 16 期間 = 200 計測値は約20kHzで、これは実効PWMクロックが160MHzではなく約64MHzに相当する。 説明していただけますか? FlexIO PWMデュアル8ビットモードにおける正確なPWM周波数計算式。 FlexIO PWMドライバーによって内部で追加のディバイダーやタイマーのスケーリングが適用されるかどうかも重要です。 PWMタイマーが実際に使用しているクロックを特定するには、どのランタイムレジスタまたはクロックソースを確認すればよいでしょうか。 ご協力ありがとうございます。 Re: S32K396 RTD 5.0.0 FlexIO PWM – How is PWM Period Calculated from the "Period [ticks]" こんにちは、 @Esakki さん。 この式はドライバー実装から直接導出できます — Flexio_Pwm_Ip_UpdatePeriodDuty(参照): Flexio_Pwm_Ip_SetLowerValue(Base, Channel, (uint8)(DutyCycle - 1U)); Flexio_Pwm_Ip_SetUpperValue(Base, Channel, (uint8)(Period - DutyCycle - 1U)); したがって、TIMMPへのマッピングは次の通りです: 下位8ビット = デューティサイクル - 1 上位8ビット = 周期 - デューティサイクル - 1 Flexio_Pwm_Ip_GetPeriod () から: 周期 = 上限 + 下限 + 2 周期 = (デューティサイクル - 1) + (周期 - デューティサイクル - 1) + 2 f_pwm = Input_FlexIO_CLK (プリコール済み) / 周期 デューティ比(%)=デューティサイクル/期間×100 例(FLEXIOクロック=160MHz、プリスケーラ=16→10MHzタイマークロック): 周期 = 200ティック -- f_pwm = 10 MHz / 200 = 50 kHz よろしくお願いいたします。 ダニエル   Re: S32K396 RTD 5.0.0 FlexIO PWM – How is PWM Period Calculated from the "Period [ticks]" こんにちは、ダニエルさん。 詳細な説明と頻度の計算式をありがとうございました。 式によれば: f_pwm = FlexIO_Input_Clock (プリスケーラ後) / 周期 私の設定では: FlexIOクロック = 160MHz プリスケーラー = 256 期間 = 63 私はこう予想します: f_pwm = 160 MHz / (256 × 63) = 9.92 kHz しかし、オシロスコープで測定すると、PWM周波数は約3.9kHzである。 同様に、以下についても: プリスケーラー = 16 期間 = 200 私が計測したところ約20kHzでしたが、FlexIOクロックが160MHzの場合、計算式では50kHzと予測されます。 何かアドバイスをいただけますか: FlexIOのPWMドライバは、クロックソースを使っている場合、設定されたFLEXIO0_CLKとは違いますか? 内部的に追加の分周器やクロックスケーリングが適用されていますか? FlexIO PWMタイマーで実際に使用されているランタイムクロック周波数を検証する推奨方法は何ですか? 測定されたPWM周波数が、設定された160MHzのFlexIOクロックを使用して計算された周波数と一致しない理由を理解したいです。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 エサッキ Re: S32K396 RTD 5.0.0 FlexIO PWM – How is PWM Period Calculated from the "Period [ticks]" こんにちは、 @Esakki さん。 再現できません。 f_timer = 160 MHz / 256 = 625 kHz T_pwm = 周期 / f_timer = 200 / 625000 = 320 µs 関税 = 100 / 200 = 50% T_pwm = 周期 / f_timer = 63 / 625000 約100.8マイクロ秒   税率 = 10 / 63 ≈ 15.87% Flexio_Pwm_Ip_Example_DS RTD のサンプルを使ってテストしました。 Flexio_Pwm_Ip_UpdatePeriodDuty(INSTANCE_0、FLEXIO_PWM_IP_CHANNEL_1、63U、10U); 問題を再現できる簡単なテストプロジェクトを作成し、ここで共有してください。そうすればテストできます。 あなたが共有してくれた結果から判断すると、あなたの設定におけるFlexIOの入力クロックは64MHzのようです。 CLKOUTを使ってシステムクロックを出力できます。 BR、ダニエル
View full article
Conflicting data for imx95 max power consumption I wanted to know the maximum power that is consumed by imx 95. when i checked the Power tree in the EVK Schematic, it says VDD_SOC will use 14156mA, image attached i felt this was too high, and as per their table imx95 soc itself uses 25 watts. so i crosschecked it with the imx95 datasheet and there the same VDD_SOC is using 4400mA max, image attached and not only this VDD_SOC line many other lines are also showing discrepancy, i would like to know which data is correct Thankyou Re: Conflicting data for imx95 max power consumption Hello, These values come from PI simulation is to verify the PCB performance to see if it meets the imx95 requirement, the spec in HDG is bases on the maximum current which list in EVK schematic. The real current will NOT be that high, but we still recommend you use the maximum current to do the simulation and ensure it meets the requirement in NXP HDG. The recommendation is use maximum supply currents from table 33 of datasheet in real use case scenario. Best regards.
View full article
启用猎鹰模式 - iMX8MP_EVK 你好, ,我需要在 Yocto 分支 6.12-walnascar 中为iMX8MP_EVK启用 Falcon 模式。但是,根据 AN14641 文档,m eta-imx-fastboot 层仅在 lf-6.6.36 -2.1.0-s 安全版本中可用分支。如何将此层移植到我的 walnascar 分支并启用 Falcon 模式? 请在这里帮忙... Re: Falcon Mode Enablement - iMX8MP_EVK 请使用以下命令。 uuu -b emmc_all - .rootfs.wic 例如: $ uuu-b emmc_all imx-boot-imx95evk-sd.bin-flash_all core-image-minimal-imx95evk.rootfs.wic Re: Falcon Mode Enablement - iMX8MP_EVK 你好,Tipingwang, 感谢您的回复。 我正在尝试启用 Falcon 模式,并已按照AN14641 中提供的步骤操作,但在烧录过程中遇到了问题。 根据README 文件,刷机步骤如下(适用于 eMMC): unzstd -[安全启动]- .rootfs.wic.zst uuu -b emmc_all - .rootfs.wic uuu -b emmc 我的启动内存是 eMMC。我尝试使用以下命令刷写镜像: sudo ./uuu-d-v-b emmc_all imx-boot-imx8mpevk-sd.bin-flash_evkimx-image-core-imx8mpevk.rootfs-20260616051114.wic 然而,在执行过程中,烧录过程因以下错误而失败: sudo ./uuu-d-v-b emmc_all imx-boot-imx8mpevk-sd.bin-flash_evkimx-image-core-imx8mpevk.rootfs-20260616051114.wic 适用于 NXP IMX 芯片的 uuu(通用更新工具)—— libuuu_1.5.243-5-g124d086   内置配置: Pctl 芯片 Vid Pid BcdVersion 序列号 ================================================== SDPS:MX8QXP 0x1fc9 0x012f [0x0002..0xffff] SDPS:MX8QM 0x1fc9 0x0129 [0x0002..0xffff] SDPS:MX8DXL 0x1fc9 0x0147 SDPS:MX28 0x15a2 0x004f SDPS:MX815 0x1fc9 0x013e SDPS:MX865 0x1fc9 0x0146 SDPS:MX8ULP 0x1fc9 0x014a SDPS:MX8ULP 0x1fc9 0x014b SDPS:MX93 0x1fc9 0x014e SDPS:MX91 0x1fc9 0x0159 SDPS:MX95 0x1fc9 0x015d SDPS:MX95 0x1fc9 0x015c SDPS:MX943 0x1fc9 0x0027 SDPS:MX952 0x1fc9 0x0028 SDP:MX7D 0x15a2 0x0076 SDP:MX6Q 0x15a2 0x0054 SDP:MX6D 0x15a2 0x0061 SDP:MX6SL 0x15a2 0x0063 SDP:MX6SX 0x15a2 0x0071 SDP:MX6UL 0x15a2 0x007d SDP:MX6ULL 0x15a2 0x0080 SDP:MX6SLL 0x1fc9 0x0128 SDP:MX7ULP 0x1fc9 0x0126 SDP:MXRT106X 0x1fc9 0x0135 SDP:MX8MM 0x1fc9 0x0134 SDP:MX8MQ 0x1fc9 0x012b SDPU:SPL 0x0525 0xb4a4 [0x0000..0x04ff] SDPV:SPL1 0x0525 0xb4a4 [0x0500..0x9998] SDPV:SPL1 0x1fc9 0x0151 [0x0500..0x9998] SDPU:SPL 0x0525 0xb4a4 [0x9999..0x9999] SDPU:SPL 0x3016 0x1001 [0x0000..0x04ff] SDPV:SPL1 0x3016 0x1001 [0x0500..0x9998] FBK:0x066f 0x9afe FBK:0x066f 0x9bff FBK:0x1fc9 0x0153 FB:0x0525 0xa4a5 FB:0x18d1 0x0d02 FB:0x3016 0x0001 FB: 0x1fc9 0x0152 FB:0x0483 0x0afb FB:0x1d6b 0x0104   运行内置脚本:   uuu_version 1.4.149   # @_flash.bin           | 引导加载程序,可从 WIC 镜像中提取 # @_image [_flash.bin]| 将 WIC 镜像写入 eMMC。     # 当 i.MX6/7、i.MX8MM、i.MX8MQ 时,将运行此命令 SDP:启动-f imx-boot-imx8mpevk-sd.bin-flash_evk-scanlimited 0x800000   # 当 ROM 支持流模式时,执行此命令 # i.MX8QXP、i.MX8QM SDPS:启动-scanterm-f imx-boot-imx8mpevk-sd.bin-flash_evk-scanlimited 0x800000   # 以下命令在启用 SPL 时执行,若未使用 SPL 则跳过 # SDPU 将被弃用。请使用 SDPV 而不是 SDPU # { SDPU:延迟 1000 SDPU:写入-f imx-启动-imx8mpevk-sd.bin-flash_evk-偏移量 0x57c00 SDPU:跳转 - 扫描限制 0x800000 # }   # 以下命令在启用 SPL 时执行,若未使用 SPL 则跳过 # 如果 (SPL 支持 SDPV) # { SDPV:延迟 1000 SDPV:写入-f imx-boot-imx8mpevk-sd.bin-flash_evk-skipspl -scanterm -scanlimited 0x800000 SDPV:跳转 - 扫描限制 0x800000 # }     FB:ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev${emmc_dev} FB:ucmd mmc dev ${emmc_dev} FB:flash -raw2sparse all imx-image-core-imx8mpevk.rootfs-20260616051114.wic FB:flash-scanterm-scanlimited 0x800000 引导加载程序 imx-boot-imx8mpevk-sd.bin-flash_evk FB:ucmd 如果 env 存在 emmc_ack;那么;否则 setenv emmc_ack 0;fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB:已完成     等待已知的 USB 设备出现... 新的 USB 设备已连接到 1:2-152 E1000D9DE520A 1:2-152 E1000D9DE520A > 启动 cmd: sdps:启动-scanterm-f imx-boot-imx8mpevk-sd.bin-flash_evk-scanlimited 0x800000 14%1:2-152E1000D9DE520A>HID(W) 识别失败:LIBUSB_ERROR_TIMEOUT (-7)(20.07s) 上面附有详细的 uuu 日志以供参考。 能否请您指导一下将支持 Falcon 的操作系统刷入 eMMC 的正确步骤,或者告诉我是否遗漏了任何必要的步骤或配置? 预先感谢您的支持。 Re: Falcon Mode Enablement - iMX8MP_EVK 猎鹰模式与安全启动不兼容, 但 在 lf-6.12.20-2.0.0-secure 上,您无法使用提供的 Yocto 流程将安全启动与 Falcon 模式一起启用 关于 0001-imx8m-reset-ethernet-phy-in-spl.patch 适用于 i.MX8MP EVK → 强烈推荐 如果您在早期启动期间不使用以太网,则不是严格要求的 Re: Falcon Mode Enablement - iMX8MP_EVK 王一平,您好, 感谢您的回复。 我还有几个问题需要进一步澄清。根据提供的信息,分支 lf-6.12.20-2.0.0-secure 支持 Falcon 模式 v2,但安全 启动被标记为尚不支持。 由于安全启动是我的 i.MX8MP 平台的要求,如果我使用这个分支,猎鹰模式能否正常运行,或者在启用安全启动时猎鹰模式不兼容? 对于 i.mx8MP EVK,我是否需要应用补丁 0001-imx8m-reset-ethernet-phy-in-spl.patch,还是根据用例是可选的? Re: Falcon Mode Enablement - iMX8MP_EVK 你可能不需要自己从 lf-6.6.36-2.1.0-secure 移植该层。公开的 nxp-imx-support/meta-imx-fastboot GitHub 仓库中已经显示了一个名为 lf-6.12.20-2.0.0-secure 的分支。 请参阅https://github.com/nxp-imx-support/meta-imx-fastboot中的 README 文件 Re: Falcon Mode Enablement - iMX8MP_EVK 请帮忙看看这个链接: 。我正在使用 UUU 刷写 eMMC。 Re: Falcon Mode Enablement - iMX8MP_EVK 根据我在 NXP 论坛上找到的这张图片,看来在此情况下,UUU 工具可能不支持对 eMMC 进行刷写。你能否建议使用支持 F alc on 的操作系统刷新 eMMC 设备的适当方法? 在您之前的回复中,您建议使用以下命令: < uuu -b emmc_all - .rootfs.wic> 我 尝试了这种方法,但又遇到了相同的错误: HID(W) 失败:LIBUSB_ERROR_TIMEOUT (-7) (20.07s) 能否请您指导一下正确的刷写流程,或者在启用 Falcon 模式的情况下,刷写 eMMC 所需的替代工具或步骤? Re: Falcon Mode Enablement - iMX8MP_EVK 之前的回复中您给出了IMX95FRDM的参考命令,请问该IMX95FRDM是否启用了Falcon功能? 这里可以看到我在 Yocto - IMX8MP 中完成的工作。 1) meta-imx-fastboot - lf-6.12.20-2.0.0-secure - Github_Link 2)已将此元数据添加到我的源代码 - Github_Link 3)并遵循了所有指示。 AN14641文件。 4)我遵循的Bitbake命令: bitbake -c clean linux-imx && bitbake -c clean imx-启动 && bitbake -c clean u-boot-imx && bitbake -c clean imx-atf && bitbake -c clean imx-image-core bitbake -c compile linux-imx && bitbake -c compile imx-启动 && bitbake -c compile u-boot-imx && bitbake -c compile imx-atf && bitbake -c compile imx-image-core bitbake linux-imx && bitbake imx-启动 && bitbake u-boot-imx && bitbake imx-atf && bitbake imx-image-core 5) 案例 1: sudo ./uuu-b emmc_all imx-image-core-imx8mpevk.rootfs-20260617095251.wic 适用于 NXP imx 芯片的 uuu(通用更新实用程序)-- libuuu_1.5.243-5-g124d086 成功 0 失败 0 1:2-152E1000 1/ 1 [=================100%=================] SDPS: 启动 -scanterm -f /home/smurugan8/YOCTO/LWT/image/imx-image-core-imx8mpevk.rootfs-20260617095251.wic -scanlimited 0x800000 案例二: sudo ./uuu-b emmc_all imx-boot-imx8mpevk-sd.bin-flash_evkimx-image-core-imx8mpevk.rootfs-20260617095251.wic 适用于 NXP imx 芯片的 uuu(通用更新实用程序)-- libuuu_1.5.243-5-g124d086 成功 0 失败 1 1:2-152E1000 1/ 1 [HID(W): LIBUSB_ERROR_TIMEOUT (-7) ] SDPS: 启动 -scanterm -f imx-boot-imx8mpevk-sd.bin-flash_evk-scanlimited 0x800000 重要提示:我需要将支持 Falcon 的操作系统刷入 eMMC 存储。 Re: Falcon Mode Enablement - iMX8MP_EVK 请帮帮我,我卡在这里了。 Re: Falcon Mode Enablement - iMX8MP_EVK 我在 IMX95FRDM 上验证了以下命令,没有问题,请参考我的日志。 C:\Users\nxa22585>C:\Users\nxa22585\Downloads\i.mx95\uuu.exe -lsusb 适用于 NXP imx 芯片的 uuu(通用更新实用程序)-- libuuu_1.5.243-0-g230f1b1 已连接的已知 USB 设备 路径芯片专业版视频 PID BCD版本 序列号 ==================================================================== 2:4 MX95 SDPS:0x1FC9 0x015D 0x0002 61F49AAB2DCB4DDF C:\Users\nxa22585>C:\Users\nxa22585\Downloads\i.mx95\uuu.exe -b emmc_all C:\Users\nxa22585\Downloads\i.mx95\imx-boot-imx95-15x15-lpddr4x-frdm-sd.bin-flash_all C:\Users\nxa22585\Downloads\i.mx95\core-image-minimal-imx8mnevk.rootfs.wic 适用于 NXP imx 芯片的 uuu(通用更新实用程序)-- libuuu_1.5.243-0-g230f1b1 成功 1 失败 0 1:2-61F49AAB 8/ 8 [完成] FB:完成 2:4-61F49AAB 3/ 3 [=================100%=================] SDPV: jump -scanlimited 0x800000 C:\Users\nxa22585> Re: Falcon Mode Enablement - iMX8MP_EVK 请注意,uuu 仅用于将图像编程到 eMMC 中,它不会检查图像的内容。 我怀疑你的 uuu 命令本身有问题。 你从哪里下载的uuu? 请从https://github.com/nxp-imx/mfgtools/releases下载最新版本的 UUU 请下载Windows版本UUU进行验证。 Re: Falcon Mode Enablement - iMX8MP_EVK 你好一平湾 我也尝试在 Windows 系统上使用 UUU 工具,但结果还是一样——它仍然无法用于刷新 eMMC。我已附上 UUU 日志。 但是,当我将同一个支持 Falcon 的操作系统刷入 SD 卡时,它就能正常启动和运行。这证实了图像本身和猎鹰配置都是有效的。 我的问题是: 为什么我无法将这个支持 Falcon 的镜像刷入 eMMC ,即使同样的镜像在 SD 卡上可以正常刷入? 除了使用 UUU 之外,还有其他推荐的方法或方法可以将支持 Falcon 的操作系统刷入 eMMC吗? 请问在这种情况下,有哪些官方支持或可靠的eMMC刷写方法? Re: Falcon Mode Enablement - iMX8MP_EVK 请帮忙。 Re: Falcon Mode Enablement - iMX8MP_EVK 上面你可以找到UUU的日志, 命令=> .\uuu.exe -b emmc C:\Users\vvdn\Sanjiv\Falcon\imx-boot-imx8mpevk-sd.bin-flash_evk C:\Users\vvdn\Sanjiv\Falcon\imx-image-multimedia-imx8mpevk.rootfs-20260624074743.wic 但它在 eMMC 上无法正常工作,同样的镜像在 SD 卡上却可以正常工作。 Re: Falcon Mode Enablement - iMX8MP_EVK 请尝试以下命令 uuu.exe -b emmc_all C :\Users\vvdn\Sanjiv\Falcon\imx-boot-imx8mpevk-sd.bin-flash_evkC:\Users\vvdn\Sanjiv\Falcon\imx-image-multimedia-imx8mpevk.rootfs-20260624074743.wic 然后把结果再发给我一次。 Re: Falcon Mode Enablement - iMX8MP_EVK 这里可以看到输出结果, PS C:\Users\vvdn\Sanjiv\uuu_source-uuu_1.5.243\uuu-uuu_1.5.243\uuu> .\uuu.exe -b emmc_all C:\Users\vvdn\Sanjiv\Falcon\imx-boot-imx8mpevk-sd.bin-flash_evkC:\Users\vvdn\Sanjiv\Falcon\imx-image-multimedia-imx8mpevk.rootfs-20260624074743.wic 适用于 NXP imx 芯片的 uuu(通用更新实用程序)-- libuuu_1.5.243-0-g230f1b1 成功 0 失败 1 1:3-152E1000 1/ 1 [HID(W): LIBUSB_ERROR_TIMEOUT (-7) ] SDPS: 启动 -scanterm -f C:\Users\vvdn\Sanjiv\Falcon\imx-b... Re: Falcon Mode Enablement - iMX8MP_EVK 请使用您的 Windows 版本 UUU 执行以下命令,并将结果发送给我,以便我进行进一步调查。 uuu.exe -b emmc_all imx-boot-imx8mpevk-sd.bin-flash_evkimx-image-core-imx8mpevk.rootfs-20260617095251.wic Re: Falcon Mode Enablement - iMX8MP_EVK 我在 IMX8MP_EVK 目标板上验证过,对 eMMC 进行编程没有问题,请参考以下日志。 C:\Users\nxa22585>C:\Users\nxa22585\Downloads\i.mx95\uuu.exe -b emmc_all C:\Users\nxa22585\Downloads\i.mx95\imx-boot-imx8mpevk-sd.bin-flash_evk C:\Users\nxa22585\Downloads\i.mx95\core-image-minimal-imx8mnevk.rootfs.wic 适用于 NXP imx 芯片的 uuu(通用更新实用程序)-- libuuu_1.5.243-0-g230f1b1 成功 1 失败 0 2:4-0F0B9800 8/8 [完成] FB:完成 C:\Users\nxa22585> 请从附件中提取我的图片,并仅执行以下命令。 uuu.exe -b emmc imx-boot-imx8mpevk-sd.bin-flash_evk 如果仍然失败,则可能是目标板上的 EMMC 本身存在问题。 您可以使用以下 emmc 命令来检查是否可以在 u-boot 中向 emmc 写入内容。 用法: mmc 读取地址块# cnt mmc 写入地址 blk# cnt mmc 擦除 blk# cnt Re: Falcon Mode Enablement - iMX8MP_EVK 请仅尝试使用 UUU 将默认启动映像写入 emmc 是否可行。 Re: Falcon Mode Enablement - iMX8MP_EVK 请帮忙…… @yipingwang Re: Falcon Mode Enablement - iMX8MP_EVK 是的, @yipingwang , 当我在版本过程中加入 meta-imx-fastboot 层时,刷写过程就会卡住。但是,如果我移除 meta-imx-fastboot 层,就可以成功地将镜像刷写到 eMMC 中。 Re: Falcon Mode Enablement - iMX8MP_EVK 我有一个问题@yipingwang,这是启用 Falcon 的图像吗?
View full article