Multi Source Translation Content

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

Multi Source Translation Content

Discussions

Sort by:
NX20P0477UKZを使用した水分検出 こんにちは、チームの皆さん、 当社は、部品番号NX20P0477UKZを使用したカスタム基板を開発しました。水分検知機能は搭載しておりません。 私たちの設計では、携帯電話を接続するために1.5メートルのケーブルを使用しています。つまり、ケーブルの片端はカスタムボードで接続され、もう片方はモバイル接続のために外部に露出しています。 外部に曝露されたケーブルからの湿気を検出しようとすると、水分を検知できません。この問題を解決するための方法をご教示ください。 よろしくお願いします。 Re: Moisture detection using NX20P0477UKZ こんにちは、カダム 良い一日! このNX20P0477は、デバイスが接続されていない状態で動作することを想定しており、主な目的は事前にFLAGBを主張することで湿気条件下での接続を防ぐことです。 ケーブルや機器が接続されると(モバイル電話はケーブルを介して接続されます)、CCラインの電気的条件はより複雑になり、水の存在とアクティブな接続が組み合わさると予測不能な挙動を引き起こします。したがって、これらの条件下では装置は水分イベント情報を確実に識別または検出できません。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。 Re: Moisture detection using NX20P0477UKZ こんにちは、ラファール。 迅速なご対応ありがとうございます。 私たちは、いかなる機器も接続せずにテストを実施しています。私たちのアプリケーションでは、ケーブルの片方を搭載タイプCコネクタに接続し、もう一方の端は開いたままにしています。ケーブルの開いた端を水に浸していますが、フラッグピン(C1)は常に高さにあり、湿気を検出できません。 水分を検出するために、CP_EN(B2)ピンをハイレベルに設定しています。 機能の検証方法を教えていただけますか? よろしくお願いします。
View full article
使用 NX20P0477UKZ 进行湿度检测 各位团队成员,大家好! 我们开发了使用 P/N: NX20P0477UKZ 的定制电路板。我们无法检测到水分。 我们的设计采用1.5米长的电缆连接手机。因此,电缆的一端连接到我们定制的板,另一端则暴露在外,用于连接移动设备。 所以当我们试图检测暴露在外的电缆中的水分时。我们无法检测到水分。请指导我们如何解决这个问题。 谢谢! Re: Moisture detection using NX20P0477UKZ 你好 kadamm 再会! NX20P0477 旨在未连接任何设备时运行,其主要目的是通过预先断言 FLAGB 来防止在潮湿条件下连接。 一旦电缆或设备连接(即使是通过电缆连接的手机),CC 线路上的电气条件就会变得更加复杂,水的存在以及活动的连接会导致不可预测的行为。因此,在这些条件下,该设备无法可靠地区分或检测潮湿事件。 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 祝你今天过得愉快,一切顺利。 Re: Moisture detection using NX20P0477UKZ 你好,拉法尔。 感谢您的快速回复。 我们是在不连接任何设备的情况下进行测试的。根据我们的应用,我们将一根电缆的一端连接到我们板载的C型连接器上,电缆的另一端保持开放状态。我们将电缆开口端浸入水中,但标志引脚(C1)始终为高电平,无法检测到水分。 我们将 CP_EN(B2) 引脚置为高电平以检测湿度。 请问我们如何验证功能性? 谢谢!
View full article
i.MX8M Quad – M4コア起動手順と必要なU-Bootコマンド 私は i.MX8M Quad EVK SDカードイメージ を扱っており 、 U-Bootから Cortex-M4コア でアプリケーションの起動と実行の正しい手順を理解したい と思っています。 i.MX8M Quad用の MCUXpresso SDK をダウンロード し、 M4コア用の Hello World 例を無事にコンパイルしました。生成された.bin ファームウェアファイル も手に入りました。 U-Bootから このM4.bin ファームウェアをロードして起動するための 正しい U-Bootコマンドとブートシーケンス を教えてください 。また、M4コンソールを確認する方法も教えてください。 #imx8mq #m4 #cortex-m4 #boot_m4 #UBoot Yocto #ubootコマンド i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands こんにちは、 U-Bootコマンドの手順 1. SDカードを準備する コンパイル済みの .bin ファイルをコピーしてください。ファイル(例: hello_world.bin )SDカードをEVKに挿入する前に、SDカードのFAT/ブートパーティション(パーティション1)にコピーしてください。 2. U-Bootの自動起動を停止する ボードの電源を入れ、U-Bootプロンプトが表示されたらすぐに任意のキーを押して自動起動を中断してください。 3. オプションA — TCM実行(MCUXpresso SDKアプリに推奨) これはMCUXpresso SDKのHello World例の標準的な方法であり、TCM at 0x1FFE0000 (エイリアス)から実行するためにリンクされています 0x7E0000 😞 # Step 1: Load .bin from SD card FAT partition into a DDR staging buffer u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin # Step 2: Copy the image from DDR staging buffer into the M4's TCM u-boot=> cp.b 0x48000000 0x7e0000 0x20000 # Step 3: (Optional but recommended) Flush data cache before starting M4 u-boot=> dcache flush # Step 4: Release M4 from reset and start execution from TCM u-boot=> bootaux 0x7e0000   以下のような出力が表示されるはずです。 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE0305...       3. オプションB — DDR実行 バイナリが DDR から実行するようにリンクされている場合 (例: 0x80000000 😞 u-boot=> fatload mmc 1:1 0x80000000 hello_world.bin u-boot=> dcache flush u-boot=> bootaux 0x80000000   ⚠️ 重要: MCUXpresso SDKアプリをコンパイルした際に使った リンカースクリプト によって、 0x7e0000(TCM)または 0x80000000(DDR)を使用してください。 デフォルトのHello Worldの例では、TCM( 0x7e0000 )が正しいターゲットです。 オプション:リソーステーブル領域をクリアする(Hello World / ベアメタル環境向け) イメージに RPMsg リソース テーブルがない場合 (例えば、単純な hello_world.bin など)、後でLinuxを混乱させる可能性のあるゴミ値を避けるために、リソーステーブル領域をクリアしてください: u-boot=> mw 0xb80ff000 0 4 オプション:Linuxも起動する prepare_mcore を実行する M4を起動した後もLinuxを起動し続ける予定がある場合は、 bootaux 前にこの追加コマンドを実行してください。LinuxがM4で使われるクロックを無効化しないようにクロックを設定しています: u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin u-boot=> cp.b 0x48000000 0x7e0000 0x20000 u-boot=> run prepare_mcore u-boot=> bootaux 0x7e0000     M4コンソールの確認 i.MX8MQ EVKは、PCに接続すると 2つの別々のCOMポートを列挙する FTDI USBシリアルチップを使用しています。 ポート コア 小さい方の番号(例:COM9 / /dev/ttyUSB0 ) Cortex-A53(U-Boot / Linuxコンソール) より大きな番号(例:COM10 / /dev/ttyUSB1 ) Cortex-M4コンソール       両ポートの設定: 115200ボー、8データビット、パリティなし、1ストップビット(115200 8N1)。 2つの別々のターミナルウィンドウを開きます(例:TeraTerm、minicom、PuTTY)。 ターミナル1 → 下位COMポート → U-Bootコマンド用 ターミナル2 → 上位COMポート → M4 Hello World 出力を確認する クイックリファレンス:環境変数によるオートメーション 利便性のためにU-Bootの環境変数として保存できます: u-boot=> setenv m4_image hello_world.bin u-boot=> setenv m4_loadaddr 0x7e0000 u-boot=> setenv load_m4_image "fatload mmc '${mmcdev}':'${mmcpart}' 0x48000000 '${m4_image}'; cp.b 0x48000000 0x7e0000 0x20000" u-boot=> setenv run_m4_image "run load_m4_image; bootaux '${m4_loadaddr}'" u-boot=> saveenv # Then simply run: u-boot=> run run_m4_image     主要参考資料 UG10163 — i.MX Linuxユーザーガイド (セクション4.7.4) — i.MX8M Quadの公式M4起動手順 AN5317 — i.MX 用U-Boot/LinuxからCortex-Mにコードを読み込む 方法 — TCMとDDRの読み込みについて詳しく検討 GS-MCIMX8M-EVK — MCIMX8M-EVK 入門ガイド— ボード固有のステップバイステップガイド よろしくお願いします。
View full article
i.MX8MP ENET_RXC/A25 引脚复用说明(适用于 MII 接口) 我们正在使用 PHYTEC phyCORE-i.MX8M Plus SOM 开发定制板,并正在审查以太网引脚复用,以便从现有的 RGMII 接口迁移到 MII。PHYTEC SOM 引脚 A25 与 i.MX8M Plus ENET_RXC 信号相关联。在 i.MX8MP 引脚复用器中,ENET_RXC 支持 ALT0 = CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 和 ALT1 = ENET_QOS_RX_ER。我们需要澄清预期 MII 配置的正确引脚分配和接口要求。具体来说,MII 接收接口是否需要 ENET_RXC,或者是否可以将所需的 RX_ER 功能分配给另一个合适的 i.MX8M Plus 焊盘/GPIO?如果可以使用其他焊盘,请提供推荐的引脚映射。我们还需要确认 i.MX8M Plus ENET_QOS 控制器是否支持预期的 MII 接口,以及是否需要对 IOMUX、MAC、设备树、GPR 或 PHY 配置进行任何更改。请提供 i.MX8M Plus 与 PHYTEC phyCORE SOM 的推荐以太网引脚映射和配置建议。 Re: i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface 您好, 感谢您对恩智浦半导体产品的关注, i.MX 8M Plus 不支持 MII,请参考 RM 中的以下摘录: 通过以下方式之一与商用以太网PHY设备无缝连接: 工作频率为 50 MHz 的 2 位精简 MII (RMII)。 运行于125 MHz的一个(双倍数据速率)4位简化GMII (RGMII)。 有关信号映射,您可以参考 i.MX 8M Plus DS。 此致
View full article
i.MX 8M Plus:RGMIIからMIIへの移行 – ENET_RXC / RX_ERピン割り当て こんにちは、NXPコミュニティの皆さん、 NXP i.MX 8M Plus SoCとPHYTEC phyCORE-i.MX8M Plus SOMを使ったカスタムイーサネット設計に取り組んでいます。 現在、RGMIIをベースにしたイーサネット設計を採用しており、カスタムボードのRGMIIからMIIへの移行を検討しています。 ピンマルチプレクサのレビュー中に、i.MX 8M PlusのENET_RXCパッドについて以下の機能を発見しました。 ALT0: CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1: ENET_QOS_RX_ER ALT5: GPIO1_IO25 当社のPHYTEC SOM割り当てでは、この信号はSOMピンA25に関連付けられています。 私の懸念は、RGMIIからMIIへの移行に関するものです。必要なイーサネット信号はRGMIIとMIIで異なります。 以下の点について明確にしておきたいと思います。 1. i.MX 8M Plus ENET_QOS MACはRGMIIやRMIIに加えて、真のMIIインターフェースをサポートしていますか? 2. 真のMIIがサポートされている場合、MII_RX_CLK、MII_RX_DV、MII_RX_ER、MII_RXD0~MII_RXD3、MII_TX_CLK、MII_TX_EN、およびMII_TXD0~MII_TXD3の正しいi.MX 8M Plusピンマッピングは何ですか? 3. ENET_RXCパッドの場合、ALT0、CCM_ENET_QOS_CLOCK_GENERATE_RX_CLKはRGMII専用ですか?それともこの機能はMIIの受信クロックとして使えますか? 4. RGMIIからMIIへの移行中、MIIインターフェースのENET_RXCパッドにENET_QOS_RX_ERが必要ですか? 5. MII_RX_ERが必要な場合、IOMUXを通じて他の利用可能な i.MX 8M Plusパッドに割り当てられますか?それともこの信号は内部的にそのENET_RXCパッドに紐づいているのでしょうか? 6. PHYTEC phyCORE-i.MX8M Plus SOMを使用している場合、MIIインターフェースの実装に伴い考慮すべきSOMルーティングの制限はありますか? 7. もしMIIがサポートされている場合、i.MX 8M Plus MIIのMAC-to-PHYピン構成およびデバイスツリー構成の正しい例や参考文献を誰か教えていただけますか? この説明の理由は、現在ボッシュ社製カスタムキャリアボードのピン配置図と回路図を作成しているためです。SOMとキャリアボードのピン配置を変更する前に、MII信号のマッピングが正しいことを確認したい。 当社のBSPからの関連するピンマルチプレクサ情報は以下のとおりです。 ENET_RXC ALT0: CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1: ENET_QOS_RX_ER ALT5: GPIO1_IO25 i.MX 8M Plus ENET_QOS MACで真のRGMIIからMIIへの移行がサポートされているのか、もしサポートされているなら、どのように扱うべきENET_RXCやRX_ERを扱うべきか、誰か確認していただけますか? よろしくお願いします。 Re: i.MX 8M Plus: RGMII to MII Migration – ENET_RXC / RX_ER Pin Assignment こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 この問題は このトピックに関連しています。 このThreadでENET_QOS詳細を追加します。以前は聞かれていなかったので。 ENETもENET_QOS/EQOSもMIIをサポートしていません。以下のEQOSのRM情報を参照してください。 RMII(10/100Mbps)、RGMII(10/100/1000Mbps) DSより: 1.8V/3.3V RMII動作、1.8V RGMII動作 この投稿では、ENET信号がEQOS信号とインターフェースしていることについて言及しています。NET信号はNETモジュールに対応し、ENET_QOSはEQOSモジュールに対応します。PHYTEC SOM内の利用可能な信号が希望する機能にマッピングできるか必ず確認してください。pinfunc.hをベースに設定できます。  または設定ツール。 i.MX用設定ツールはこちらからダウンロードしてください。 よろしくお願いします。
View full article
imx93 lvds,内核版本 6.12 我正在尝试让 LVDS 显示屏在 imx93 定制板上工作。我遇到了这个错误: imx-lcdif 4ae30000.lcd-controller: probe with driver imx-lcdif failed with error -2 添加一些跟踪信息后,发现这是驱动程序中的这一行代码(在函数 lcdif_load 中)。 lcdif->clk_axi = devm_clk_get(drm->dev, "axi"); if (IS_ERR(lcdif->clk_axi)) return PTR_ERR(lcdif->clk_axi); 所以,它似乎找不到“axi”时钟。 我使用的是内核中的设备树,即 imx93.dtsi。作为基础,其中包括以下几行: clock-names = "pix", "disp-axi", "disp-apb"; assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>, <&clk IMX93_CLK_MEDIA_DISP_PIX>, <&clk IMX93_CLK_MEDIA_AXI>, <&clk IMX93_CLK_MEDIA_APB>; 所以这里设备树和驱动程序之间存在一些不一致之处。问题是我不知道这些时钟是否正确,也不知道我应该使用哪个。 我尝试查看 6.18 分支的内容,但是这部分(lcdif 控制器)已从 imx93.dtsi 文件中完全消失了。 有什么提示吗? Re: imx93 lvds with kernel 6.12 好的,找到一个原因了,这是因为使用了错误的驱动程序。现在,使用 lcdif_v3 驱动程序,不存在时钟问题。 另一方面,我仍然会遇到这个问题。 imx93-ldb ldb-display-controller:无法与 4ae30000.lcd-controller 创建设备链接 (0x180)。 有什么提示吗? Re: imx93 lvds with kernel 6.12 你好@julienblanc 希望你一切都好。 你的问题仍然存在吗? 顺祝商祺! 萨拉斯。 Re: imx93 lvds with kernel 6.12 很遗憾,不行。 我一直遇到同样的错误。以下是我尝试的配置方法: backlight_lvds: backlight-lvds { compatible = "pwm-backlight"; status = "okay"; power-supply = <&display_power_12v>; brightness-levels = < 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100>; default-brightness-level = <30>; pwms = <&pwm_backlight 0 1000000 0>; }; pwm_backlight: pwm_gpio { compatible = "pwm-gpio"; #pwm-cells = <3>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_clko4_gpio>; gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>; // gpio controller &gpio4, pin 29 status = "okay"; }; panel { compatible = "panel-lvds"; width-mm = <224>; height-mm = <126>; backlight = <&backlight_lvds>; status = "okay"; port { panel_in: endpoint { remote-endpoint = <&lvds_ldb_out>; }; }; panel-timing { clock-frequency = <72400000>; hactive = <1280>; vactive = <800>; hfront-porch = <72>; hback-porch = <88>; hsync-len = <20>; vfront-porch = <15>; vback-porch = <23>; vsync-len = <10>; de-active = <1>; pixelclk-active = <1>; }; }; &ldb { status = "okay"; lvds-channel@0 { #address-cells = <1>; #size-cells = <0>; status = "okay"; port@1 { reg = <1>; lvds_ldb_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; &ldb_phy { status = "okay"; }; display_power 在 exander 上占用大量 GPIO: display_power_12v: gpio_regulator { gpio-hog; gpios = <12 GPIO_ACTIVE_HIGH>; output-high; label = "DISPLAY12V"; }; 这主要取材于设备树中的一些示例。我搞不清楚哪里出了问题,也不知道为什么显示屏无法启动,甚至连背光都打不开。我知道我应该使用 TPM 而不是软件 GPIO,但这需要硬件修复,目前我只能暂时这样处理,但我认为这并不是问题的根源。 感谢您的支持! 此致, 朱利安
View full article
カーネル6.12を使用したimx93 lvds imx93カスタムボード上でLVDSディスプレイを動作させようとしています。このエラーで困っています。 imx-lcdif 4ae30000.lcd-controller: probe with driver imx-lcdif failed with error -2 トレースを追加すると、これはドライバのこのライン(関数lcdif_load)から来ます lcdif->clk_axi = devm_clk_get(drm->dev, "axi"); if (IS_ERR(lcdif->clk_axi)) return PTR_ERR(lcdif->clk_axi); つまり、「axi」クロックが見つからないようです。 私はカーネルのデバイスツリー、imx93.dtsiを使用しています。ベースとして、以下の行が含まれます。 clock-names = "pix", "disp-axi", "disp-apb"; assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>, <&clk IMX93_CLK_MEDIA_DISP_PIX>, <&clk IMX93_CLK_MEDIA_AXI>, <&clk IMX93_CLK_MEDIA_APB>; つまり、デバイスツリーとドライバの間には多少の矛盾があります。問題は、時計が正確かどうか、どの時計を使うべきか分からないことです。 6.18のブランチに何があるか確認しようとしましたが、この部分(LCDIFコントローラー)はIMX93.dtsiファイルから完全に消えてしまいました。 何かヒントはありますか? Re: imx93 lvds with kernel 6.12 わかりました。原因が一つ分かりました。これは間違ったドライバを使っていたことです。今はlcdif_v3ドライバなのでクロックの問題はありません。 一方で、この問題はまだあります IMX93-LDB LDB-Display-Controller: 4ae30000.lcd-controllerとデバイスリンク(0x180)を作成できません 何かヒントはありますか? Re: imx93 lvds with kernel 6.12 こんにちは、 @julienblanc お元気でお過ごしのことと思います。 まだ問題は解決していませんか? よろしくお願いいたします。 サラス。 Re: imx93 lvds with kernel 6.12 残念ながら、いいえ。 同じエラーが繰り返し発生します。私が試した設定方法は以下のとおりです。 backlight_lvds: backlight-lvds { compatible = "pwm-backlight"; status = "okay"; power-supply = <&display_power_12v>; brightness-levels = < 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100>; default-brightness-level = <30>; pwms = <&pwm_backlight 0 1000000 0>; }; pwm_backlight: pwm_gpio { compatible = "pwm-gpio"; #pwm-cells = <3>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_clko4_gpio>; gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>; // gpio controller &gpio4, pin 29 status = "okay"; }; panel { compatible = "panel-lvds"; width-mm = <224>; height-mm = <126>; backlight = <&backlight_lvds>; status = "okay"; port { panel_in: endpoint { remote-endpoint = <&lvds_ldb_out>; }; }; panel-timing { clock-frequency = <72400000>; hactive = <1280>; vactive = <800>; hfront-porch = <72>; hback-porch = <88>; hsync-len = <20>; vfront-porch = <15>; vback-porch = <23>; vsync-len = <10>; de-active = <1>; pixelclk-active = <1>; }; }; &ldb { status = "okay"; lvds-channel@0 { #address-cells = <1>; #size-cells = <0>; status = "okay"; port@1 { reg = <1>; lvds_ldb_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; &ldb_phy { status = "okay"; }; display_powerはExander上でGPIOを大量に消費します。 display_power_12v: gpio_regulator { gpio-hog; gpios = <12 GPIO_ACTIVE_HIGH>; output-high; label = "DISPLAY12V"; }; これは主にデバイスツリー内のいくつかの例から引用したものです。何が問題なのか、なぜディスプレイが表示されず、バックライトも表示されないのか分かりません。ソフトウェアGPIOではなくTPMを使うべきだと分かっていますが、それはハードウェアの修正が必要で、今は対応していて、それが問題だとは思いません。 ご支援ありがとうございます。 よろしくお願いいたします。 ジュリアン
View full article
i.MX 8M Plus:RGMII 到 MII 的迁移 – ENET_RXC / RX_ER 引脚分配 NXP社区的各位朋友,大家好! 我正在使用 NXP i.MX 8M Plus SoC 和 PHYTEC phyCORE-i.MX8M Plus SOM 开发定制以太网设计。 我们目前有一个基于 RGMII 的以太网设计,我们正在评估将我们的定制板从 RGMII 迁移到 MII 的可能性。 在引脚复用审查过程中,我发现 i.MX 8M Plus ENET_RXC 引脚具有以下功能: ALT0:CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1:ENET_QOS_RX_ER ALT5:GPIO1_IO25 在我们的 PHYTEC SOM 分配中,该信号与 SOM 引脚 A25 相关联。 我担心的是 RGMII 到 MII 的迁移问题。RGMII 和 MII 所需的以太网信号不同。 我想澄清以下几点: 1. 除了 RGMII 和 RMII 之外,i.MX 8M Plus ENET_QOS MAC 是否支持真正的 MII 接口? 2. 如果支持真正的 MII,那么 i.MX 8M Plus 的 MII_RX_CLK、MII_RX_DV、MII_RX_ER、MII_RXD0 到 MII_RXD3、MII_TX_CLK、MII_TX_EN 和 MII_TXD0 到 MII_TXD3 的正确引脚映射是什么? 3. 对于 ENET_RXC 焊盘,ALT0、CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 是否仅用于 RGMII,或者该功能是否可以用作 MII 接收时钟? 4. 在 RGMII 到 MII 迁移期间,MII 接口是否需要 ENET_RXC 焊盘上的 ENET_QOS_RX_ER? 5. 如果需要 MII_RX_ER,能否通过 IOMUX 将其分配给另一个可用的 i.MX 8M Plus 焊盘,还是该信号内部与 ENET_RXC 焊盘关联? 6. 由于我们使用的是 PHYTEC phyCORE-i.MX8M Plus SOM,在实现 MII 接口时,是否需要考虑 SOM 路由方面的任何限制? 7. 如果支持 MII,能否提供 i.MX 8M Plus MII MAC 到 PHY 引脚配置和设备树配置的示例或参考资料? 之所以要进行此项澄清,是因为我们目前正在为博世定制载板准备引脚复用和原理图。在更改 SOM 和载板引脚分配之前,我们希望确认正确的 MII 信号映射。 我们的 BSP 中相关的 pinmux 信息如下: ENET_RXC ALT0:CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1:ENET_QOS_RX_ER ALT5:GPIO1_IO25 请问有人可以确认 i.MX 8M Plus ENET_QOS MAC 是否支持真正的 RGMII 到 MII 迁移吗?如果支持,应该如何处理 ENET_RXC 和 RX_ER? 谢谢! Re: i.MX 8M Plus: RGMII to MII Migration – ENET_RXC / RX_ER Pin Assignment 您好, 感谢您对恩智浦半导体产品的关注, 这个问题与这个主题相关。 由于之前没有问到 ENET_QOS 的详细信息,我将在本帖中补充这些信息。 ENET 和 ENET_QOS / EQOS 均不支持 MII,请参考 EQOS RM 提供的以下信息: RMII(10/100Mbps),RGMII(10/100/1000Mbps) 来自DS: 1.8V/3.3V RMII 操作,1.8V RGMII 操作 帖子中提到了 ENET 信号与 EQOS 信号的接口。ENET 信号对应于 ENET 模块,而 ENET_QOS 对应于 EQOS 模块。请务必检查 PHYTEC SOM 中可用的信号是否可以映射到您所需的功能,您可以参考pinfunc.h文件。或配置工具。 在此处下载 i.MX 配置工具。 此致
View full article
i.MX 8M Plus: RGMII to MII Migration – ENET_RXC / RX_ER Pin Assignment Hello NXP Community, I am working on a custom Ethernet design using the NXP i.MX 8M Plus SoC with a PHYTEC phyCORE-i.MX8M Plus SOM. We currently have an Ethernet design based on RGMII, and we are evaluating a migration from RGMII to MII for our custom board. During the pinmux review, I found the following functions for the i.MX 8M Plus ENET_RXC pad: ALT0: CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1: ENET_QOS_RX_ER ALT5: GPIO1_IO25 In our PHYTEC SOM allocation, this signal is associated with SOM pin A25. My concern is related to the RGMII to MII migration. The required Ethernet signals are different between RGMII and MII. I would like to clarify the following points: 1. Does the i.MX 8M Plus ENET_QOS MAC support a true MII interface in addition to RGMII and RMII? 2. If true MII is supported, what is the correct i.MX 8M Plus pin mapping for MII_RX_CLK, MII_RX_DV, MII_RX_ER, MII_RXD0 to MII_RXD3, MII_TX_CLK, MII_TX_EN, and MII_TXD0 to MII_TXD3? 3. For the ENET_RXC pad, is ALT0, CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK, intended only for RGMII, or can this function be used as the MII receive clock? 4. During an RGMII to MII migration, is ENET_QOS_RX_ER on the ENET_RXC pad required for the MII interface? 5. If MII_RX_ER is required, can it be assigned to another available i.MX 8M Plus pad through IOMUX, or is this signal internally associated with the ENET_RXC pad? 6. Since we are using a PHYTEC phyCORE-i.MX8M Plus SOM, are there any SOM routing limitations that need to be considered for implementing the MII interface? 7. If MII is supported, could someone provide an example or reference for the correct i.MX 8M Plus MII MAC-to-PHY pin configuration and device-tree configuration? The reason for this clarification is that we are currently preparing the pinmux and schematic for a Bosch custom carrier board. We want to confirm the correct MII signal mapping before changing the SOM and carrier-board pin allocation. The relevant pinmux information from our BSP is: ENET_RXC ALT0: CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK ALT1: ENET_QOS_RX_ER ALT5: GPIO1_IO25 Could someone please confirm whether a true RGMII-to-MII migration is supported on the i.MX 8M Plus ENET_QOS MAC and, if so, how ENET_RXC and RX_ER should be handled? Thank you. Re: i.MX 8M Plus: RGMII to MII Migration – ENET_RXC / RX_ER Pin Assignment Hi, Thank you for your interest in NXP Semiconductor products, This issue is related to this topic. I will add in this thread the ENET_QOS details since they were not asked previously. Neither ENET nor ENET_QOS / EQOS support MII, please refer to the following information from RM of EQOS: RMII (10/100Mbps), RGMII (10/100/1000Mbps) From DS: 1.8 V/3.3 V RMII operation, 1.8 V RGMII operation Post mentions ENET signals interfacing EQOS signals. ENET signals correspond to ENET module, while ENET_QOS correspond to EQOS module, make sure to review that an available signal in PHYTEC SOM can be mapped to your desired function, you can base in pinfunc.h  or config tools. Download Config Tools for i.MX here. Regards
View full article
imx93 lvds with kernel 6.12 I'm trying to make an LVDS display work on an imx93 custom board. I'm struggling with this error : imx-lcdif 4ae30000.lcd-controller: probe with driver imx-lcdif failed with error -2 After adding some traces, this comes from this line in the driver (in function lcdif_load) lcdif->clk_axi = devm_clk_get(drm->dev, "axi"); if (IS_ERR(lcdif->clk_axi)) return PTR_ERR(lcdif->clk_axi); So, it seems it cannot find the "axi" clock. I'm using the device tree from the kernel, imx93.dtsi, as the base, which includes the following lines: clock-names = "pix", "disp-axi", "disp-apb"; assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>, <&clk IMX93_CLK_MEDIA_DISP_PIX>, <&clk IMX93_CLK_MEDIA_AXI>, <&clk IMX93_CLK_MEDIA_APB>; So there's some inconsistency here between the device tree and the driver here. Problem is that i don't know if the clocks are correct, which ones i should use. I tried to have a look to what is in the 6.18 branch, but this part (lcdif controller) has completely disappeared from the imx93.dtsi file. Any hints? Re: imx93 lvds with kernel 6.12 Ok, found one cause, this was using the wrong driver. Now, with the lcdif_v3 driver, no clock issues. On the other hand, i still get this problem imx93-ldb ldb-display-controller: Failed to create device link (0x180) with 4ae30000.lcd-controller Any hints ? Re: imx93 lvds with kernel 6.12 Hello @julienblanc  Hope you are doing very well. Are you still having the issue? Best regards, Salas. Re: imx93 lvds with kernel 6.12 Unfortunately, no. I keep having the same error. Here's how i tried to configure things : backlight_lvds: backlight-lvds { compatible = "pwm-backlight"; status = "okay"; power-supply = <&display_power_12v>; brightness-levels = < 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100>; default-brightness-level = <30>; pwms = <&pwm_backlight 0 1000000 0>; }; pwm_backlight: pwm_gpio { compatible = "pwm-gpio"; #pwm-cells = <3>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_clko4_gpio>; gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>; // gpio controller &gpio4, pin 29 status = "okay"; }; panel { compatible = "panel-lvds"; width-mm = <224>; height-mm = <126>; backlight = <&backlight_lvds>; status = "okay"; port { panel_in: endpoint { remote-endpoint = <&lvds_ldb_out>; }; }; panel-timing { clock-frequency = <72400000>; hactive = <1280>; vactive = <800>; hfront-porch = <72>; hback-porch = <88>; hsync-len = <20>; vfront-porch = <15>; vback-porch = <23>; vsync-len = <10>; de-active = <1>; pixelclk-active = <1>; }; }; &ldb { status = "okay"; lvds-channel@0 { #address-cells = <1>; #size-cells = <0>; status = "okay"; port@1 { reg = <1>; lvds_ldb_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; &ldb_phy { status = "okay"; }; display_power is a gpio-hog on an exander : display_power_12v: gpio_regulator { gpio-hog; gpios = <12 GPIO_ACTIVE_HIGH>; output-high; label = "DISPLAY12V"; }; This is mostly taken from some examples in the device-trees. I can't get what's wrong, or why it won't bring the display up, even not the backlight. I know i should use a TPM instead of a software gpio, but that need a hardware fix, currently i have to deal with it and i don't think that's the problem. Thanks for your support, Regards, Julien
View full article
i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface We are developing a custom board using the PHYTEC phyCORE-i.MX8M Plus SOM and are reviewing the Ethernet pinmux for migration from the existing RGMII interface to MII. The PHYTEC SOM pin A25 is associated with the i.MX8M Plus ENET_RXC signal. In the i.MX8MP pinmux, ENET_RXC supports ALT0 = CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK and ALT1 = ENET_QOS_RX_ER. We need clarification regarding the correct pin assignment and interface requirements for the intended MII configuration. Specifically, is ENET_RXC required for the MII receive interface, or can the required RX_ER function be assigned to another suitable i.MX8M Plus pad/GPIO? If a different pad can be used, please provide the recommended pin mapping. We also need confirmation of whether the i.MX8M Plus ENET_QOS controller supports the intended MII interface and whether any IOMUX, MAC, device-tree, GPR, or PHY configuration changes are required. Please advise on the recommended Ethernet pin mapping and configuration for the i.MX8M Plus with the PHYTEC phyCORE SOM. Re: i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface Hi, Thank you for your interest in NXP Semiconductor products, i.MX 8M Plus does not support MII, please refer to the following extract from RM: Seamless interface to commercial ethernet PHY devices via one of the following: a 2-bit Reduced MII (RMII) operating at 50 MHz. a (double data rate) 4-bit Reduced GMII (RGMII) operating at 125 MHz. For signal mapping, you can refer to i.MX 8M Plus DS. Regards
View full article
i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands I am working with an i.MX8M Quad EVK SD card image and would like to understand the correct procedure for booting and running an application on the Cortex-M4 core from U-Boot. I have downloaded the MCUXpresso SDK for the i.MX8M Quad and successfully compiled the Hello World example for the M4 core. I now have the generated .bin firmware file. Please provide the correct U-Boot commands and boot sequence to load and start this M4 .bin firmware from U-Boot? And how to check M4 console ? #imx8mq #m4 #cortex-m4 #boot_m4 #UBoot #yocto #uboot-commands i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands Hello, Step-by-Step U-Boot Commands 1. Prepare the SD Card Copy your compiled .bin file (e.g., hello_world.bin ) to the FAT/boot partition (partition 1) of the SD card before inserting it into the EVK. 2. Stop U-Boot Autoboot Power on the board and immediately press any key to interrupt autoboot at the U-Boot prompt. 3. Option A — TCM Execution (Recommended for MCUXpresso SDK apps) This is the standard method for MCUXpresso SDK Hello World examples, which are linked to run from TCM at 0x1FFE0000 (alias 0x7E0000 😞 # Step 1: Load .bin from SD card FAT partition into a DDR staging buffer u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin # Step 2: Copy the image from DDR staging buffer into the M4's TCM u-boot=> cp.b 0x48000000 0x7e0000 0x20000 # Step 3: (Optional but recommended) Flush data cache before starting M4 u-boot=> dcache flush # Step 4: Release M4 from reset and start execution from TCM u-boot=> bootaux 0x7e0000   You should see output like: ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE0305...       3. Option B — DDR Execution If your binary is linked to run from DDR (e.g., 0x80000000 😞 u-boot=> fatload mmc 1:1 0x80000000 hello_world.bin u-boot=> dcache flush u-boot=> bootaux 0x80000000   ⚠️ Important: Use 0x7e0000 (TCM) or 0x80000000 (DDR) depending on the linker script used when you compiled the MCUXpresso SDK app. For the default Hello World example, TCM ( 0x7e0000 ) is the correct target. Optional: Clear Resource Table Area (for Hello World / bare-metal) If your image does not have an RPMsg resource table (like a simple hello_world.bin ), clear the resource table area to avoid garbage values that could confuse Linux later: u-boot=> mw 0xb80ff000 0 4 Optional: Run prepare_mcore (When Linux Will Also Boot) If you plan to continue booting Linux after starting the M4, run this additional command before bootaux . It configures clocks so Linux does not disable M4-used clocks: u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin u-boot=> cp.b 0x48000000 0x7e0000 0x20000 u-boot=> run prepare_mcore u-boot=> bootaux 0x7e0000     Checking the M4 Console The i.MX8MQ EVK uses an FTDI USB-serial chip that enumerates two separate COM ports when connected to the PC: Port Core Lower number (e.g., COM9 / /dev/ttyUSB0 ) Cortex-A53 (U-Boot / Linux console) Higher number (e.g., COM10 / /dev/ttyUSB1 ) Cortex-M4 console       Settings for both ports: 115200 baud, 8 data bits, No parity, 1 stop bit (115200 8N1). Open two separate terminal windows (e.g., TeraTerm, minicom, PuTTY): Terminal 1 → Lower COM port → for U-Boot commands Terminal 2 → Higher COM port → to see M4 Hello World output Quick Reference: Automation via Environment Variables You can save these as U-Boot environment variables for convenience: u-boot=> setenv m4_image hello_world.bin u-boot=> setenv m4_loadaddr 0x7e0000 u-boot=> setenv load_m4_image "fatload mmc '${mmcdev}':'${mmcpart}' 0x48000000 '${m4_image}'; cp.b 0x48000000 0x7e0000 0x20000" u-boot=> setenv run_m4_image "run load_m4_image; bootaux '${m4_loadaddr}'" u-boot=> saveenv # Then simply run: u-boot=> run run_m4_image     Key Reference Documents UG10163 — i.MX Linux User's Guide (Section 4.7.4) — Official M4 boot procedure for i.MX8M Quad AN5317 — Loading Code on Cortex-M from U-Boot/Linux for the i.MX — Deep dive on TCM vs DDR loading GS-MCIMX8M-EVK — Getting Started with the MCIMX8M-EVK — Board-specific step-by-step guide Regards
View full article
MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Environment MCU: MWCT2016S based Wireless Charging Controller Working Setup (Legacy): HSE FW Version: 2.6.0 (Application + Secure Boot) merge hex. New Setup (Failing): HSE FW Version: 2.40.0 (Application + Secure Boot) merge hex. We are migrating from HSE FW v2.6.0 to HSE FW v2.40.0 while maintaining the same Qi key provisioning and Secure Boot flow. Problem Statement With HSE FW v2.6.0, the complete provisioning sequence executes successfully: HSE installation Erase Keys S2TP key slot provisioning Qi key programming Secure Boot configuration Application boots successfully With HSE FW v2.40.0, all provisioning steps complete successfully until Secure Boot configuration is started. During Secure Boot configuration the following API fails: ImportPlainSymKeyReqMuChannel() in secure boot code.   return HSE response: 0x55A5A399 which corresponds to:  #define HSE_SRV_RSP_INVALID_PARAM ((hseSrvResponse_t)0x55A5A399UL)   After this failure, Secure Boot configuration cannot be completed, and the ECU remains stuck in the Secure Boot code.   Provisioning Sequence Working Configuration (HSE 2.6.0) 00_Blank_MWCT2016_CodeFlash_DataFlash.hex Power Reset 01_HSE_flash.srec  version 2.6.0 Power Reset 02_EraseKeysSW.hex Power Reset 03_S2TP_KeySlotsAligned.srec  S2TP SW Version: 1.1.1 Power Reset Write Qi Keys via UART Power Reset Application+SecureBoot.hex Power Reset     HSE response after merge hex flashing from UART log:  HseStatus : 2848         bit 0   : 0 RFU         bit 1   : 0 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 0 , smrStatus[0] : 0   Code debug log HSE response:  ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5aa33    LoadBootMacKey-hseResp: 0x55a5aa33    Generic_ImportKeys-hseResp: 0x55a5aa33    KeyProvisioningForJTAG-status: 1    SecureBootConfiguration-hseResp: 0x55a5aa33    KeyProvisioningToHseNVM-status: 1    NON_SECURE_IVT-BLOCK1-hseResp: 0x55a5aa33    SECURE_IVT-BLOCK0-hseResp: 0x55a5aa33    writeDefaultData    Running Secure Boot CFG program  Hse-FW Version : 0.13.0.2.6.0 , full mem  using interface version : 0.13.0.2.6.0  HseStatus : 2862         bit 0   : 0 RFU         bit 1   : 1 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 1 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 1 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 1 , smrStatus[0] : 1 Failing Configuration-HSE FW 2.40.0 reports: 00_Blank_MWCT2016_CodeFlash_DataFlash.hex Power Reset 01_S32K344_HSE_FW_UPDATE_v2_40_0.srec Power Reset 02_M210WLCUMBCD00A_WSB00.31_EraseKeySW_UART_ENABLE.hex Power Reset 03_S2TP_2_1_0_KeySlotsAligned.srec Power Reset Write Qi Keys via UART Power Reset Application+SecureBoot.hex Power Reset    HseStatus : 2912         bit 0   : 0 RFU         bit 1   : 0 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 1 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 0 , smrStatus[0] : 0 ImportPlainSymKeyReqMuChannel-hseResp: 0x55A5A399   after Power reset:  UML SW Version : WSB00.3B_UART_ENABLE    Running Secure Boot CFG program  Hse-FW Version : 0.13.0.2.40.0 , full mem  using interface version : 0.13.0.2.40.0    HseStatus : 2848         bit 0   : 0 RFU         bit 1   : 0 HSE_SHE_STATUS_SECURE_BOOT         bit 2   : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         bit 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED         bit 4   : 0 HSE_SHE_STATUS_SECURE_BOOT_OK         bit 5   : 1 HSE_STATUS_RNG_INIT_OK         bit 6   : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE         bit 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE         bit 8   : 1 HSE_STATUS_INIT_OK         bit 9   : 1 HSE_STATUS_INSTALL_OK         bit 10  : 0 HSE_STATUS_BOOT_OK         bit 11  : 1 HSE_STATUS_CUST_SUPER_USER         bit 12  : 0 HSE_STATUS_OEM_SUPER_USER         bit 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS         bit 14  : 0 RFU         bit 15  : 0 RFU  smrCoreStatus_Get :  smrCoreStatus[1] : 0 , smrCoreStatus[0] : 0  smrStatus[1] : 0 , smrStatus[0] : 0    ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5a399 ECU getting stuck in secure boot only Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @ShrikantM  Could you please share your key catalogs as well as the parameters used in the ImportPlainSymKeyReqMuChannel() function call? The reported error indicates that one or more HSE request parameters are invalid. BR, VaneB Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @SwapnilGawade  Thank you for sharing the information. Based on your configuration, I have the following observations: The SHE key group is configured with HSE_KEY_OWNER_CUST as the owner. However, the HSE Service API Reference Manual specifies that, for an SHE key catalog configuration, the owner of an SHE key group must be set to HSE_KEY_OWNER_ANY. This is also demonstrated in the NVM SHE Key Catalog Configuration example. The targetKeyHandle passed to ImportPlainSymKeyReqMuChannel() is defined as: #define NVM_AES128_BOOT_KEY GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 1, 1)​ However, according to your NVM key catalog configuration, the AES key group is the third group (NvmKeyGroup_2). Based on this configuration, the correct definition for NVM_AES128_BOOT_KEY should be:  GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 2, 0)​ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @VaneB , We are using below key catalogs: /* Table containing NVM key catalog entries */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = {     /* NvmKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* NvmKeyGroup_1 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}},     /* NvmKeyGroup_2 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}},     /* Marker to end the key catalog */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; /* Table containing RAM key catalog entries */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = {     /* RamKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* Marker to end the key catalog */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; For below function we receive HSE_SRV_RSP_INVALID_PARAM hseSrvResponse_t Generic_ImportKeys(void) {     hseSrvResponse_t srvResponse = HSE_SRV_RSP_GENERAL_ERROR;     /*Import key linked with SMR#0*/     srvResponse = ImportPlainSymKeyReqMuChannel(             MU0,             1U,             NVM_AES128_BOOT_KEY,             HSE_KEY_TYPE_AES,             ( HSE_KF_USAGE_VERIFY ),             0U,             aesEcbKeyLength,             aesEcbKey,             TRUE             );     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             goto exit;     /* load keys for SHE secure boot */     srvResponse = LoadBootMacKey();     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             goto exit; exit:     return srvResponse; } Please check attached global_defs.h for more details about the parameters. Thanks and Regards, Swapnil Gawade Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @SwapnilGawade  According to your description, I noticed that you appear to have combined the DemoApp framework with the Hse_Ip drivers. Is my understanding correct? If so, what modifications have been applied? Also, have you disabled the data cache in your project? This is a common cause of the HSE_SRV_RSP_INVALID_PARAM error. All data objects used for communication with HSE must be forced to non-cacheable memory. I also noticed that you are passing HSE_DTCM_ADDR(pHseSrvDesc) as the pHseSrvDesc parameter to the Hse_Ip_ServiceRequest() function. Please refer to the thread HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR, where my colleague explains some considerations regarding the use of HSE with DTCM memory. You may also want to take a look at Hse_Ip_ToAHBAddress(), which converts a local address into an HSE host address when TCM support is enabled. It could be useful in this scenario. Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel Hi @VaneB , As per your suggestion I have done the changes, but it also gives similar response as HSE_SRV_RSP_INVALID_PARAM (0x55a5a399). After debugging we found that it, in ImportPlainSymKeyReqMuChannel(...)->EraseKeyReq(targetKeyHandle, HSE_ERASE_NOT_USED))->HSE_Send(muIf, muChannelIdx, gSyncTxOption, pHseSrvDesc)->Hse_Ip_ServiceRequest(u8MuInstance, u8MuChannel, pHseIp_Request , HSE_DTCM_ADDR(pHseSrvDesc))->Mu_Ip_SetTxRegister(Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc) retruns response as HSE_SRV_RSP_INVALID_PARAM (0x55a5a399). The parameters of pHseSrvDesc are added in attached Mu_Ip_SetTxRegister-pHseSrvDesc.xlsx. Thanks and Regards, Swapnil Gawade
View full article
i.MX8M 四核 – M4 核心启动步骤和所需的 U-Boot 命令 我正在使用 i.MX8M Quad EVK SD 卡镜像 ,想了解 从 U-Boot 启动并在 Cortex-M4 内核 上运行应用程序的正确步骤。 我已经下载了 适用于 i.MX8M 四核处理器的 MCUXpresso SDK ,并成功编译了 M4 内核的 Hello World 示例程序。现在我已经得到了生成的.bin 固件文件。 请提供正确的U-Boot 命令和启动顺序,以便从 U-Boot 加载并启动此 M4 .bin固件?以及如何查看 M4 控制台? #imx8mq #m4 #cortex-m4 #boot_m4 #UBoot #yocto #uboot命令 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus Linux Yocto Project Re: i.MX8M Quad – M4 Core Boot Steps and Required U-Boot Commands 你好, U-Boot 命令分步指南 1. 准备 SD 卡 复制你编译好的 .bin 文件文件(例如, hello_world.bin )在将 SD 卡插入 EVK 之前,将其写入 SD 卡的FAT/启动分区(分区 1)。 2. 停止 U-Boot 自动启动 打开板电源,然后立即按任意键中断 U-Boot 提示符处的启动。 3. 选项 A — TCM 执行(推荐用于 MCUXpresso SDK 应用) 这是 MCUXpresso SDK Hello World 示例的标准方法,这些示例链接到位于 0x1FFE0000 (别名 0x7E0000 的 TCM 运行。😞 # Step 1: Load .bin from SD card FAT partition into a DDR staging buffer u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin # Step 2: Copy the image from DDR staging buffer into the M4's TCM u-boot=> cp.b 0x48000000 0x7e0000 0x20000 # Step 3: (Optional but recommended) Flush data cache before starting M4 u-boot=> dcache flush # Step 4: Release M4 from reset and start execution from TCM u-boot=> bootaux 0x7e0000   你应该看到类似这样的输出: ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE0305...       3. 选项 B — DDR 执行 如果您的二进制文件链接到 DDR 运行(例如, 0x80000000 😞 u-boot=> fatload mmc 1:1 0x80000000 hello_world.bin u-boot=> dcache flush u-boot=> bootaux 0x80000000   ⚠️ 重要提示: 根据编译 MCUXpresso SDK 应用程序时使用的 链接器脚本 ,使用 0x7e0000 (TCM) 或 0x80000000 (DDR)。 对于默认的 Hello World 示例,TCM( 0x7e0000 )是正确的目标。 可选:清除资源表区域(用于 Hello World / 裸机环境) 如果你的镜像没有RPMsg 资源表(例如简单的 hello_world.bin ),清除资源表区域,以避免产生可能在以后导致 Linux 系统混乱的垃圾值: u-boot=> mw 0xb80ff000 0 4 可选:运行 prepare_mcore (当 Linux 系统也启动时) 如果您计划在启动 M4 后继续启动 Linux,请在 bootaux 之前运行此附加命令。它配置时钟,使 Linux 不会禁用 M4 使用的时钟: u-boot=> fatload mmc 1:1 0x48000000 hello_world.bin u-boot=> cp.b 0x48000000 0x7e0000 0x20000 u-boot=> run prepare_mcore u-boot=> bootaux 0x7e0000     检查M4控制台 i.MX8MQ EVK 使用 FTDI USB 转串口芯片,连接到 PC 时会枚举两个独立的 COM 端口: 端口 内核 较低的编号(例如,COM9 / /dev/ttyUSB0 ) Cortex-A53(U-Boot/Linux 控制台) 更高的数字(例如,COM10 / /dev/ttyUSB1 ) Cortex-M4 控制台       两个端口的设置: 115200 波特率,8 位数据位,无奇偶校验,1 位停止位 (115200 8N1)。 打开两个独立的终端窗口(例如,TeraTerm、minicom、PuTTY): 终端 1 → 下方 COM 端口 → 用于 U-Boot 命令 终端 2 → 更高端口的 COM 端口 → 查看 M4 Hello World 输出 快速参考:通过环境变量实现自动化 为了方便起见,您可以将这些值保存为 U-Boot 环境变量: u-boot=> setenv m4_image hello_world.bin u-boot=> setenv m4_loadaddr 0x7e0000 u-boot=> setenv load_m4_image "fatload mmc '${mmcdev}':'${mmcpart}' 0x48000000 '${m4_image}'; cp.b 0x48000000 0x7e0000 0x20000" u-boot=> setenv run_m4_image "run load_m4_image; bootaux '${m4_loadaddr}'" u-boot=> saveenv # Then simply run: u-boot=> run run_m4_image     关键参考文件 UG10163 — i.MX Linux 用户指南(4.7.4 节) — i.MX8M 四核处理器的官方 M4 启动步骤 AN5317 — 通过 U-Boot/Linux 在 i.MX 上向 Cortex-M 加载代码— TCM 与 DDR 加载深度解析 GS-MCIMX8M-EVK — MCIMX8M-EVK 入门指南 — 针对特定开发板的逐步指南 此致
View full article
S32K118EVB2Q048:ADC读数与所选MCU供电电压不匹配 您好,NXP团队: 我正在使用 S32K118EVB2Q048 板(原理图 SCH-47530 Rev A1)测试 ADC。当输入电压超过约 3.3 V 时,我的读数就会出错。 设置: - MCU:S32K118(48-LQFP) - IDE:[S32 设计工作室版本] - 驱动程序:[RTD 版本 / SDK 版本 / 裸机版本] - ADC通道:[例如PTA7 – ADC0_SE3] 分辨率:12 位 - 输入:[外部直流电源/板载电位器] - 跳线:J10 = 2-3 (5V)、J107、J15 - 板供电方式:[USB / 12V] 问题: 我将 J10 设置为 2-3,这样 MCU 就可以在 5V 电压下运行。 - 输入 4.10 V:原始值 = 4095。以 5V 为参考电压,我预期读数约为 3358。 - 4V 至 5V 之间的任何输入:始终为 4095(满量程)。 - 当我使用 5V 电压进行计算时,随着输入电压的增加,误差也会增加。 问题: 在 SCH-47530 Rev A1 上,将 J10 设置为 2-3 是否足以使 VDDA 和 ADC 参考电压为 5V,还是我还需要更改其他任何东西(J15、J107、任何电阻器)? 能否分享一个适用于此EVB的S32K118 ADC工作示例,并用5V基准电压进行测试?能否也提供不同分辨率下的计算范围? Re: S32K118EVB2Q048: ADC readings do not match the selected MCU supply voltage 你好 请问您使用的是哪个RTD/SDK版本? 另外,我看到你正在使用 PTA7,但是你提到了 ADC_POT。由于 EVB 上未安装 R761,因此 ADC_POT 未连接: 我假设您是通过 J3.1 接头使用 PTA7。 请确认J10和J107都设置为 2-3,并尝试测量 VDD,以确保它确实设置为 5V。 我使用了RTD软件包中的Adc_Pdb_Ip_example_S32K118 ,并简单地修改了main函数,使其循环并启动软件转换: while(1) { /* Start a software trigger conversion */ Adc_Ip_StartConversion(ADCHWUNIT_0_VS_0_INSTANCE, ADC_IP_INPUTCHAN_EXT2, TRUE); /* Wait for the notification to be triggered and read the data */ while (notif_triggered != TRUE); notif_triggered = FALSE; delay(1000); } 之后,我使用电源测量了 0 到 5V 之间的电压,可以看到正确的数值。 ADC0_SE2 @3.3V: ADC0_SE2 @5V: 最后,检查 ADC_SC2[REFSEL] 中 REFSEL 是否设置正确: 此致, 朱利安
View full article
S32K118EVB2Q048: ADC readings do not match the selected MCU supply voltage Hi NXP team, I'm using the S32K118EVB2Q048 board (schematic SCH-47530 Rev A1) and testing the ADC. I'm getting wrong readings when the input voltage goes above about 3.3 V. Setup: - MCU: S32K118 (48-LQFP) - IDE: [S32 Design Studio version] - Driver: [RTD version / SDK version / bare-metal] - ADC channel: [e.g. PTA7 – ADC0_SE3] - Resolution: 12-bit - Input: [external DC power supply / on-board potentiometer] - Jumpers: J10 = 2-3 (5V), J107, J15  - Board powered from: [USB / 12V] Issue: I set J10 to 2-3 so the MCU runs at 5V. - Input 4.10 V: raw = 4095. With a 5V reference I expected about 3358. - Any input from 4 V to 5 V: always 4095 (full scale). - When I calculate with 5V, the error increases as the input voltage increases. Questions: On SCH-47530 Rev A1, is setting J10 to 2-3 enough to make VDDA and the ADC reference 5V, or do I need to change anything else (J15, J107, any resistor)? Can you share a working S32K118 ADC example for this EVB, tested with a 5V reference , can u also give ur calculated range for different for resolution  Re: S32K118EVB2Q048: ADC readings do not match the selected MCU supply voltage Hello  Can you share which RTD/SDK version you are using? Also, I can see you are using PTA7, however, you mentioned ADC_POT. ADC_POT is not connected as R761 is not populated on the EVB: I assume you are using PTA7 through the J3.1 header. Please confirm both J10, and J107 are set 2-3, and try to measure VDD to make sure it is indeed set at 5V. I used Adc_Pdb_Ip_example_S32K118 from RTD package, and simply modified main to loop and start a SW conversion: while(1) { /* Start a software trigger conversion */ Adc_Ip_StartConversion(ADCHWUNIT_0_VS_0_INSTANCE, ADC_IP_INPUTCHAN_EXT2, TRUE); /* Wait for the notification to be triggered and read the data */ while (notif_triggered != TRUE); notif_triggered = FALSE; delay(1000); } After this, I used a power supply to measure between 0 and 5V, and I could see the correct values. ADC0_SE2 @3.3V: ADC0_SE2 @5V: Lastly, check if REFSEL is correctly set in ADC_SC2[REFSEL]: Best regards, Julián
View full article
MWCT2016 HSE 2.40.0 セキュアブート構成エラー - ImportPlainSymKeyReqMuChannel 環境 MCU:MWCT2016Sベースのワイヤレス充電コントローラー 動作環境設定(従来型) : HSE FW バージョン: 2.6.0 (アプリケーション+セキュアブート)16進をマージします。 新規設定(失敗) : HSE FW バージョン: 2.40.0 (アプリケーション+セキュアブート)16進をマージします。 Qiキーのプロビジョニングとセキュアブートのフローはそのまま維持しつつ、HSE FW v2.6.0からHSE FW v2.40.0への移行を進めています。 問題提起 HSE FW v2.6.0では、プロビジョニングシーケンス全体が正常に実行されます。 HSE設備 キーを消去する S2TPキースロットのプロビジョニング Qiキープログラミング セキュアブート構成 アプリケーションが正常に起動します HSE FW v2.40.0では、セキュアブート構成が開始されるまで、すべてのプロビジョニング手順が正常に完了します。 セキュアブートの設定中に、以下のAPIが失敗します。 ImportPlainSymKeyReqMuChannel() はセキュアブートコードに含まれています。   HSE応答を返します: 0x55A5A399これは以下に対応します: #define HSE_SRV_RSP_INVALID_PARAM ((hseSrvResponse_t)0x55A5A399UL)   この失敗後、セキュアブートの設定が完了できず、ECUはセキュアブートコードに閉じ込められてしまいます。   プロビジョニングシーケンス 動作構成(HSE 2.6.0) 00_Blank_MWCT2016_CodeFlash_DataFlash.hex 電源リセット 01_HSE_flash.srecバージョン2.6.0 電源リセット 02_EraseKeysSW.hex 電源リセット 03_S2TP_KeySlotsAligned.srec  S2TPソフトウェアバージョン: 1.1.1 電源リセット UART経由でQiキーを書き込む 電源リセット Application+SecureBoot.hex 電源リセット     UARTログからのマージ後の16進数フラッシュ後のHSE応答: HseStatus: 2848 ビット0:0 RFU         ビット 1   : 0 HSE_SHE_STATUS_SECURE_BOOT ビット 2 : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         ビット 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED ビット4:0 HSE_SHE_STATUS_SECURE_BOOT_OK ビット 5 : 1 HSE_STATUS_RNG_INIT_OK ビット 6 : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE      ビット 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE ビット 8 : 1 HSE_STATUS_INIT_OK ビット9:1 HSE_STATUS_INSTALL_OK ビット 10 : 0 HSE_STATUS_BOOT_OK ビット 11 : 1 HSE_STATUS_CUST_SUPER_USER ビット 12 : 0 HSE_STATUS_OEM_SUPER_USER         ビット 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS ビット14:0 RFU ビット15:0 RFU smrCoreStatus_Get : smrCoreStatus[1] : 0 、smrCoreStatus[0] : 0 smrStatus[1] : 0 、smrStatus[0] : 0   コードデバッグログHSE応答:  ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5aa33   LoadBootMacKey-hseResp: 0x55a5aa33    Generic_ImportKeys-hseResp: 0x55a5aa33   KeyProvisioningForJTAG-status: 1   SecureBootConfiguration-hseResp: 0x55a5aa33   KeyProvisioningToHseNVM-status: 1    NON_SECURE_IVT-BLOCK1-hseResp: 0x55a5aa33    SECURE_IVT-BLOCK0-hseResp: 0x55a5aa33   writeDefaultData   セキュアブートCFGプログラムを実行中 Hse-FW バージョン: 0.13.0.2.6.0、フルメモリ インターフェースバージョン使用:0.13.0.2.6.0 HseStatus: 2862 ビット0:0 RFU ビット 1 : 1 HSE_SHE_STATUS_SECURE_BOOT ビット 2 : 1 HSE_SHE_STATUS_SECURE_BOOT_INIT ビット 3 : 1 HSE_SHE_STATUS_SECURE_BOOT_FINISHED ビット4:0 HSE_SHE_STATUS_SECURE_BOOT_OK ビット 5 : 1 HSE_STATUS_RNG_INIT_OK ビット 6 : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE      ビット 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE ビット 8 : 1 HSE_STATUS_INIT_OK ビット9:1 HSE_STATUS_INSTALL_OK ビット 10 : 0 HSE_STATUS_BOOT_OK ビット 11 : 1 HSE_STATUS_CUST_SUPER_USER ビット 12 : 0 HSE_STATUS_OEM_SUPER_USER         ビット 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS ビット14:0 RFU ビット15:0 RFU smrCoreStatus_Get : smrCoreStatus[1] : 0 、smrCoreStatus[0] : 0 smrStatus[1] : 1 、smrStatus[0] : 1 構成エラー - HSE FW 2.40.0 のレポート: 00_Blank_MWCT2016_CodeFlash_DataFlash.hex 電源リセット 01_S32K344_HSE_FW_UPDATE_v2_40_0.srec 電源リセット 02_M210WLCUMBCD00A_WSB00.31_EraseKeySW_UART_ENABLE.hex 電源リセット 03_S2TP_2_1_0_KeySlotsAligned.srec 電源リセット UART経由でQiキーを書き込む 電源リセット Application+SecureBoot.hex 電源リセット   HseStatus: 2912 ビット0:0 RFU         ビット 1   : 0 HSE_SHE_STATUS_SECURE_BOOT ビット 2 : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         ビット 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED ビット4:0 HSE_SHE_STATUS_SECURE_BOOT_OK ビット 5 : 1 HSE_STATUS_RNG_INIT_OK ビット 6 : 1 HSE_STATUS_HOST_DEBUGGER_ACTIVE      ビット 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE ビット 8 : 1 HSE_STATUS_INIT_OK ビット9:1 HSE_STATUS_INSTALL_OK ビット 10 : 0 HSE_STATUS_BOOT_OK ビット 11 : 1 HSE_STATUS_CUST_SUPER_USER ビット 12 : 0 HSE_STATUS_OEM_SUPER_USER         ビット 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS ビット14:0 RFU ビット15:0 RFU smrCoreStatus_Get : smrCoreStatus[1] : 0 、smrCoreStatus[0] : 0 smrStatus[1] : 0 、smrStatus[0] : 0 ImportPlainSymKeyReqMuChannel-hseResp: 0x55A5A399   電源リセット後: UMLソフトウェアバージョン:WSB00.3B_UART_ENABLE   セキュアブートCFGプログラムを実行中 Hse-FW バージョン: 0.13.0.2.40.0、フルメモリ インターフェースバージョン:0.13.0.2.40.0の使用   HseStatus: 2848 ビット0:0 RFU         ビット 1   : 0 HSE_SHE_STATUS_SECURE_BOOT ビット 2 : 0 HSE_SHE_STATUS_SECURE_BOOT_INIT         ビット 3   : 0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED ビット4:0 HSE_SHE_STATUS_SECURE_BOOT_OK ビット 5 : 1 HSE_STATUS_RNG_INIT_OK ビット 6 : 0 HSE_STATUS_HOST_DEBUGGER_ACTIVE      ビット 7   : 0 HSE_STATUS_HSE_DEBUGGER_ACTIVE ビット 8 : 1 HSE_STATUS_INIT_OK ビット9:1 HSE_STATUS_INSTALL_OK ビット 10 : 0 HSE_STATUS_BOOT_OK ビット 11 : 1 HSE_STATUS_CUST_SUPER_USER ビット 12 : 0 HSE_STATUS_OEM_SUPER_USER         ビット 13  : 0 HSE_STATUS_FW_UPDATE_IN_PROGRESS ビット14:0 RFU ビット15:0 RFU smrCoreStatus_Get : smrCoreStatus[1] : 0 、smrCoreStatus[0] : 0 smrStatus[1] : 0 、smrStatus[0] : 0    ImportPlainSymKeyReqMuChannel-hseResp: 0x55a5a399 ECUがセキュアブートのみで停止する Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @ShrikantM さん。 ImportPlainSymKeyReqMuChannel() 関数呼び出しで使われているパラメータと、キーカタログを教えていただけますか?報告されたエラーは、1つ以上のHSEリクエストパラメータが無効であることを示しています。 BR、VaneB Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @VaneB さん。 弊社では以下のキーカタログを使用しています。 /* NVMキーカタログエントリを含むテーブル */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = {     /* NvmKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* NvmKeyGroup_1 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}},     /* NvmKeyGroup_2 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}},     /* キーカタログの終了を示すマーカー */     {0U、0U、0U、0U、0U、{0U、0U}} }; /* RAMキーカタログエントリを含むテーブル */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = {     /* RamKeyGroup_0 */     {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}},     /* キーカタログの終了を示すマーカー */     {0U、0U、0U、0U、0U、{0U、0U}} }; 以下の関数では、HSE_SRV_RSP_INVALID_PARAM を受け取ります。 hseSrvResponse_t Generic_ImportKeys(void) {     hseSrvResponse_t srvResponse = HSE_SRV_RSP_GENERAL_ERROR;     /*SMR#0にリンクされたインポートキー*/     srvResponse = ImportPlainSymKeyReqMuChannel(             MU0、 1U、             NVM_AES128_BOOT_KEY、             HSE_KEY_TYPE_AES、             ( HSE_KF_USAGE_VERIFY )             0U、             aesEcbKeyLength、             aesEcbKey、 真実             );     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             出口へ移動;     /* SHEセキュアブート用のキーをロード */     srvResponse = LoadBootMacKey();     ASSERT(HSE_SRV_RSP_OK == srvResponse );     if(HSE_SRV_RSP_OK != srvResponse)             出口へ移動; 出口:     return srvResponse; } 添付のglobal_defs.hをご確認ください。パラメータの詳細については、こちらをご覧ください。 よろしくお願いいたします。 スワプニル・ガワデ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @SwapnilGawade さん。 情報共有ありがとうございます。お客様の設定に基づき、以下の点を確認いたしました。 SHEキーグループはHSE_KEY_OWNER_CUSTを所有者として設定しています。しかし、HSEサービスAPIリファレンスマニュアルでは、SHEキーカタログ構成の場合、SHEキーグループの所有者をHSE_KEY_OWNER_ANYに設定しなければならないと規定されています。これは、NVM SHEキーカタログ構成の例でも示されています。 ImportPlainSymKeyReqMuChannel() に渡される targetKeyHandle は次のように定義されます。 #define NVM_AES128_BOOT_KEY GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 1, 1)​ ただし、NVMキーカタログの設定によると、AESキーグループは3番目のグループ(NvmKeyGroup_2)となります。この構成に基づくと、NVM_AES128_BOOT_KEY の正しい定義は次のようになります。 GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 2, 0)​ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @SwapnilGawade さん。 あなたの説明によると、DemoAppフレームワークとHse_Ipドライバーを組み合わせているように見えました。私の理解は正しいでしょうか?もしそうなら、どのような修正が加えられましたか? また、プロジェクトでデータキャッシュを無効にしていますか?これは、HSE_SRV_RSP_INVALID_PARAM エラーの一般的な原因です。HSEとの通信に使用されるすべてのデータオブジェクトは、キャッシュ不可能なメモリに強制的に格納されなければならない。 また、Hse_Ip_ServiceRequest() 関数に pHseSrvDesc パラメータとして HSE_DTCM_ADDR(pHseSrvDesc) を渡していることに気づきました。HSE_ReadAdkp returning HSE_SRV_RSP_INVALID_ADDR Threadを参照してください。同僚がDTCMメモリでのHSE使用に関するいくつかの考慮点を説明しています。 また、TCMサポートを有効にするとローカルアドレスをHSEホストアドレスに変換する機能Hse_Ip_ToAHBAddress()も検討すると良いでしょう。この状況では役立つかもしれません。 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel こんにちは、 @VaneB さん。 ご提案いただいたとおり変更を行いましたが、 HSE_SRV_RSP_INVALID_PARAM (0x55a5a399) と同様の応答も返されます。 デバッグの結果、 ImportPlainSymKeyReqMuChannel (...)-> EraseKeyReq (targetKeyHandle, HSE_ERASE_NOT_USED))-> HSE_Send (muIf, muChannelIdx, gSyncTxOption, pHseSrvDesc)-> Hse_Ip_ServiceRequest (u8MuInstance, u8MuChannel, pHseIp_Request , HSE_DTCM_ADDR(pHseSrvDesc))-> Mu_Ip_SetTxRegister (Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc) でHSE_SRV_RSP_INVALID_PARAM (0x55a5a399)という応答が返されることがわかりました。 pHseSrvDesc のパラメータは、添付の Mu_Ip_SetTxRegister-pHseSrvDesc.xlsx に追加されています。 よろしくお願いいたします。 スワプニル・ガワデ
View full article
i.MX8MP ENET_RXC/A25 Pinmux MIIインターフェースの説明 PHYTEC phyCORE-i.MX8M Plus SOMを使用したカスタムボードを開発しており、既存のRGMIIインターフェースからMIIへのイーサネットピンマックス移行を検討しています。PHYTEC SOMのピンA25は、i.MX8M PlusのENET_RXC信号に関連付けられています。i.MX8MPピンマックスでは、ENET_RXC ALT0 = CCM_ENET_QOS_CLOCK_GENERATE_RX_CLKおよびALT1 = ENET_QOS_RX_ERをサポートしています。意図されたMII構成の正しいピン割り当てとインターフェース要件についての明確な説明が必要です。具体的には、MII受信インターフェースにENET_RXCが必要でしょうか?それとも必要なRX_ER機能は別の適切なi.MX8M Plusパッド/GPIOに割り当てられるのでしょうか?別のパッドが使える場合は、推奨されるピンマッピングをご提供ください。また、i.MX8M Plus ENET_QOSコントローラが意図されたMIIインターフェースをサポートしているか、IOMUX、MAC、デバイスツリー、GPR、PHYの設定変更が必要かどうかも確認する必要があります。i.MX8M PlusとPHYTEC phyCORE SOMの推奨イーサネットピンマッピングと設定についてアドバイスをお願いします。 Re: i.MX8MP ENET_RXC/A25 Pinmux Clarification for MII Interface こんにちは、 NXP Semiconductors製品にご関心いただきありがとうございます。 i.MX 8M PlusはMIIをサポートしていないため、RMからの以下の抜粋を参照してください。 以下のいずれかを通じて商用イーサネットPHYデバイスへのシームレスなインターフェースが可能です: 50MHzで動作する2ビット縮小MII(RMII)。 125 MHzで動作する、 1 つの (ダブル・データ・レート)4 ビットの縮小GMII (RGMII)。 信号マッピングについては、8M Plus DS i.MX を参照してください。 よろしくお願いします。
View full article
MWCT2016 HSE 2.40.0 安全启动配置失败 - ImportPlainSymKeyReqMuChannel 环境 MCU:基于MWCT2016S的无线充电控制器 工作设置(旧版) : HSE固件版本:2.6.0 (应用程序 + 安全启动)合并十六进制。 新设置(失败) : HSE固件版本:2.40.0 (应用程序 + 安全启动)合并十六进制。 我们正在从 HSE FW v2.6.0 迁移到 HSE FW v2.40.0,同时保持相同的 Qi 密钥配置和安全启动流程。 问题陈述 使用 HSE FW v2.6.0,完整的配置序列可以成功执行: HSE 安装 擦除按键 S2TP密钥槽配置 Qi 键编程 安全启动配置 应用程序启动成功 使用HSE FW v2.40.0时,所有配置步骤均成功完成,直到启动安全启动配置。 在安全启动配置期间,以下API 失败: 在安全启动代码中导入PlainSymKeyReqMuChannel()。   返回HSE 响应: 0x55A5A399 ,对应于: #define HSE_SRV_RSP_INVALID_PARAM ((hseSrvResponse_t)0x55A5A399UL)   出现此故障后,安全启动配置无法完成,ECU 将卡在安全启动代码中。   配置顺序 工作配置(HSE 2.6.0) 00_Blank_MWCT2016_CodeFlash_DataFlash.hex 电源 RESET 01_HSE_flash.srec版本 2.6.0 电源 RESET 02_EraseKeysSW.hex 电源 RESET 03_S2TP_KeySlotsAligned.srec S2TP 软件版本:1.1.1 电源 RESET 通过 UART 写入 Qi 密钥。 电源 RESET 应用程序+安全启动.hex 电源 RESET     从 UART 日志中获取合并十六进制烧录后的 HSE 响应: HseStatus:2848 位 0:0 RFU 位 1:0 HSE_SHE_STATUS_SECURE_BOOT 位 2:0 HSE_SHE_STATUS_SECURE_BOOT_INIT 位 3:0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED 位 4:0 HSE_SHE_STATUS_SECURE_BOOT_OK 位 5:1 HSE_STATUS_RNG_INIT_OK 位 6:0 HSE_STATUS_HOST_DEBUGGER_ACTIVE 位 7:0 HSE_STATUS_HSE_DEBUGGER_ACTIVE 位 8:1 HSE_STATUS_INIT_OK 位 9:1 HSE_STATUS_INSTALL_OK 位 10:0 HSE_STATUS_BOOT_OK 位 11:1 HSE_STATUS_CUST_SUPER_USER 位 12:0 HSE_STATUS_OEM_SUPER_USER 位 13:0 HSE_STATUS_FW_UPDATE_IN_PROGRESS 位 14:0 RFU 位 15:0 RFU smrCoreStatus_Get: smrCoreStatus[1]:0,smrCoreStatus[0]:0 smrStatus[1]:0,smrStatus[0]:0   代码调试日志 HSE 响应:  ImportPlainSymKeyReqMuChannel-hseResp:0x55a5aa33   LoadBootMacKey-hseResp: 0x55a5aa33    Generic_ImportKeys-hseResp:0x55a5aa33   KeyProvisioningForJTAG-status: 1   SecureBootConfiguration-hseResp: 0x55a5aa33   KeyProvisioningToHseNVM-status: 1    NON_SECURE_IVT-BLOCK1-hseResp:0x55a5aa33    SECURE_IVT-BLOCK0-hseResp:0x55a5aa33   writeDefaultData   运行安全启动配置程序 Hse-FW 版本:0.13.0.2.6.0,完整内存 使用的接口版本:0.13.0.2.6.0 HseStatus:2862 位 0:0 RFU 位 1:1 HSE_SHE_STATUS_SECURE_BOOT 位 2:1 HSE_SHE_STATUS_SECURE_BOOT_INIT 位 3:1 HSE_SHE_STATUS_SECURE_BOOT_FINISHED 位 4:0 HSE_SHE_STATUS_SECURE_BOOT_OK 位 5:1 HSE_STATUS_RNG_INIT_OK 位 6:0 HSE_STATUS_HOST_DEBUGGER_ACTIVE 位 7:0 HSE_STATUS_HSE_DEBUGGER_ACTIVE 位 8:1 HSE_STATUS_INIT_OK 位 9:1 HSE_STATUS_INSTALL_OK 位 10:0 HSE_STATUS_BOOT_OK 位 11:1 HSE_STATUS_CUST_SUPER_USER 位 12:0 HSE_STATUS_OEM_SUPER_USER 位 13:0 HSE_STATUS_FW_UPDATE_IN_PROGRESS 位 14:0 RFU 位 15:0 RFU smrCoreStatus_Get: smrCoreStatus[1]:0,smrCoreStatus[0]:0 smrStatus[1]:1,smrStatus[0]:1 配置失败 - HSE 固件 2.40.0 报告: 00_Blank_MWCT2016_CodeFlash_DataFlash.hex 电源 RESET 01_S32K344_HSE_FW_UPDATE_v2_40_0.srec 电源 RESET 02_M210WLCUMBCD00A_WSB00.31_EraseKeySW_UART_ENABLE.hex 电源 RESET 03_S2TP_2_1_0_KeySlotsAligned.srec 电源 RESET 通过 UART 写入 Qi 密钥。 电源 RESET 应用程序+安全启动.hex 电源 RESET   房屋状态:2912 位 0:0 RFU 位 1:0 HSE_SHE_STATUS_SECURE_BOOT 位 2:0 HSE_SHE_STATUS_SECURE_BOOT_INIT 位 3:0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED 位 4:0 HSE_SHE_STATUS_SECURE_BOOT_OK 位 5:1 HSE_STATUS_RNG_INIT_OK 位 6:1 HSE_STATUS_HOST_DEBUGGER_ACTIVE 位 7:0 HSE_STATUS_HSE_DEBUGGER_ACTIVE 位 8:1 HSE_STATUS_INIT_OK 位 9:1 HSE_STATUS_INSTALL_OK 位 10:0 HSE_STATUS_BOOT_OK 位 11:1 HSE_STATUS_CUST_SUPER_USER 位 12:0 HSE_STATUS_OEM_SUPER_USER 位 13:0 HSE_STATUS_FW_UPDATE_IN_PROGRESS 位 14:0 RFU 位 15:0 RFU smrCoreStatus_Get: smrCoreStatus[1]:0,smrCoreStatus[0]:0 smrStatus[1]:0,smrStatus[0]:0 ImportPlainSymKeyReqMuChannel-hseResp:0x55A5A399   断电重启后: UML 软件版本:WSB00.3B_UART_ENABLE   运行安全启动配置程序 Hse-FW 版本:0.13.0.2.40.0,完整内存 使用的接口版本:0.13.0.2.40.0   HseStatus:2848 位 0:0 RFU 位 1:0 HSE_SHE_STATUS_SECURE_BOOT 位 2:0 HSE_SHE_STATUS_SECURE_BOOT_INIT 位 3:0 HSE_SHE_STATUS_SECURE_BOOT_FINISHED 位 4:0 HSE_SHE_STATUS_SECURE_BOOT_OK 位 5:1 HSE_STATUS_RNG_INIT_OK 位 6:0 HSE_STATUS_HOST_DEBUGGER_ACTIVE 位 7:0 HSE_STATUS_HSE_DEBUGGER_ACTIVE 位 8:1 HSE_STATUS_INIT_OK 位 9:1 HSE_STATUS_INSTALL_OK 位 10:0 HSE_STATUS_BOOT_OK 位 11:1 HSE_STATUS_CUST_SUPER_USER 位 12:0 HSE_STATUS_OEM_SUPER_USER 位 13:0 HSE_STATUS_FW_UPDATE_IN_PROGRESS 位 14:0 RFU 位 15:0 RFU smrCoreStatus_Get: smrCoreStatus[1]:0,smrCoreStatus[0]:0 smrStatus[1]:0,smrStatus[0]:0    导入PlainSymKeyReqMuChannel-hseResp:0x55a5a399 ECU 仅卡在安全启动模式 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@ShrikantM 能否请您分享一下您的密钥目录以及在ImportPlainSymKeyReqMuChannel()函数调用中使用的参数?报告的错误表明一个或多个 HSE 请求参数无效。 BR,VaneB Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@VaneB , 我们使用以下主要目录: /* 包含 NVM 密钥目录条目的表 */ const hseKeyGroupCfgEntry_t aHseNvmKeyCatalog[] = { /* NvmKeyGroup_0 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}}, /* NvmKeyGroup_1 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_ECC_PAIR, 1U, 256U, {0U, 0U}}, /* NvmKeyGroup_2 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_AES, 1U, 256U, {0U, 0U}}, /* 关键目录结束标记 */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; /* 包含 RAM 键目录条目的表 */ const hseKeyGroupCfgEntry_t aHseRamKeyCatalog[] = { /* RamKeyGroup_0 */ {(HSE_MU0_MASK), HSE_KEY_OWNER_CUST, HSE_KEY_TYPE_SHE, 1U, 128U, {0U, 0U}}, /* 关键目录结束标记 */     {0U, 0U, 0U, 0U, 0U, {0U, 0U}} }; 对于以下函数,我们收到 HSE_SRV_RSP_INVALID_PARAM 错误 hseSrvResponse_t Generic_ImportKeys(void) { hseSrvResponse_t srvResponse = HSE_SRV_RSP_GENERAL_ERROR; /*导入与 SMR#0 关联的密钥*/     srvResponse = ImportPlainSymKeyReqMuChannel( MU0, 1U             NVM_AES128_BOOT_KEY,             HSE_KEY_TYPE_AES,             ( HSE_KF_USAGE_VERIFY ),             0U, aesEcbKeyLength, aesEcbKey, 真的             ); ASSERT(HSE_SRV_RSP_OK == srvResponse); 如果(HSE_SRV_RSP_OK != srvResponse)             跳转到出口; /* 加载 SHE 安全启动的密钥 */ srvResponse = LoadBootMacKey(); ASSERT(HSE_SRV_RSP_OK == srvResponse); 如果(HSE_SRV_RSP_OK != srvResponse)             跳转到出口; 出口: 返回 srvResponse; } 请查看附件 global_defs.h 文件。有关参数的更多详细信息。 感谢并致意 斯瓦普尼尔·加瓦德 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@SwapnilGawade 感谢您分享信息。根据您的配置,我有以下几点看法: SHE 密钥组配置的所有者为 HSE_KEY_OWNER_CUST。但是,HSE 服务 API 参考手册规定,对于 SHE 密钥目录配置,SHE 密钥组的所有者必须设置为 HSE_KEY_OWNER_ANY。NVM SHE 密钥目录配置示例也证明了这一点。 传递给 ImportPlainSymKeyReqMuChannel() 的 targetKeyHandle 定义如下: #define NVM_AES128_BOOT_KEY GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 1, 1)​ 但是,根据您的 NVM 密钥目录配置,AES 密钥组是第三组 (NvmKeyGroup_2)。基于此配置,NVM_AES128_BOOT_KEY 的正确定义应该是: GET_KEY_HANDLE(HSE_KEY_CATALOG_ID_NVM, 2, 0)​ Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@VaneB , 根据您的建议,我已经进行了更改,但它仍然给出与HSE_SRV_RSP_INVALID_PARAM (0x55a5a399) 类似的响应。 经过调试,我们发现ImportPlainSymKeyReqMuChannel (...)-> EraseKeyReq (targetKeyHandle, HSE_ERASE_NOT_USED))-> HSE_Send (muIf, muChannelIdx, gSyncTxOption, pHseSrvDesc)-> Hse_Ip_ServiceRequest (u8MuInstance, u8MuChannel, pHseIp_Request , HSE_DTCM_ADDR(pHseSrvDesc))-> Mu_Ip_SetTxRegister (Hse_Ip_apMuBase[u8MuInstance], u8MuChannel, (uint32)pHseSrvDesc) 返回的响应为HSE_SRV_RSP_INVALID_PARAM (0x55a5a399) 。 pHseSrvDesc 的参数已添加到附件 Mu_Ip_SetTxRegister-pHseSrvDesc.xlsx 中。 感谢并致意 斯瓦普尼尔·加瓦德 Re: MWCT2016 HSE 2.40.0 Secure Boot Configuration Failure- ImportPlainSymKeyReqMuChannel 嗨@SwapnilGawade 根据您的描述,我注意到您似乎将 DemoApp 框架与 Hse_Ip 驱动程序结合使用了。我的理解正确吗?如果进行了修改,具体做了哪些修改? 另外,您是否已在项目中禁用数据缓存?这是导致 HSE_SRV_RSP_INVALID_PARAM 错误的一个常见原因。所有用于与 HSE 通信的数据对象都必须强制存储在不可缓存的内存中。 我还注意到,您将 HSE_DTCM_ADDR(pHseSrvDesc) 作为 pHseSrvDesc 参数传递给了 Hse_Ip_ServiceRequest() 函数。请参阅HSE_ReadAdkp 返回 HSE_SRV_RSP_INVALID_ADDR 的线程,我的同事在其中解释了有关将 HSE 与 DTCM 内存一起使用的一些注意事项。 您可能还想了解一下 Hse_Ip_ToAHBAddress(),当启用 TCM 支持时,它会将本地地址转换为 HSE 主机地址。在这种情况下,它或许有用。
View full article
S32K118EVB2Q048:ADCの読み取り値が選択されたMCUの電源電圧と一致しない こんにちは、NXPチームの皆様、 私はS32K118EVB2Q048ボード(回路図SCH-47530 Rev A1)を使用してADCをテストしています。入力電圧が約3.3Vを超えると、誤った測定値が表示されます。 セットアップ: - MCU:S32K118(48-LQFP) - IDE:[S32 Design Studio版] - ドライバ:[RTDバージョン/SDKバージョン/ベアメタル] - ADCチャネル:[例:PTA7 – ADC0_SE3] - 解像度:12ビット - 入力:[外部直流電源/搭載ポテンショメータ] - ジャンパー:J10 = 2-3(5V)、J107、J15 - 基板電源:[USB / 12V] 問題: J10を2-3に設定してMCUを5Vで動作させています。 - 入力 4.10 V: 生データ = 4095。5Vの基準電圧であれば、約3358を期待していました。 - 4V~5Vの入力:常に4095(フルスケール)。 - 5Vで計算すると、入力電圧が高くなるにつれて誤差が大きくなります。 質問: SCH-47530 Rev A1では、J10を2~3に設定するだけでVDDAとADCの基準電圧が5Vになりますか?それとも他に何か変更する必要はありますか(J15、J107、抵抗など)? このEVBの動作するS32K118 ADCの例を5Vの基準でテストしたものを共有してもらえますか?また、解像度のために異なる異なる計算範囲も教えてもらえますか? Re: S32K118EVB2Q048: ADC readings do not match the selected MCU supply voltage こんにちは どのRTD/SDKバージョンを使っているか教えてもらえますか? また、PTA7を使っているのはわかりますが、ADC_POTも言及されていましたね。ADC_POTは接続されていません。なぜならR761はEVBに登録されていないからです: あなたはJ3.1ヘッダーを介してPTA7を使用しているものと想定します。 J10とJ107の両方が2-3に設定されていることを確認し、VDDを測定して、実際に5Vに設定されていることを確認してください。 RTDパッケージの Adc_Pdb_Ip_example_S32K118 を使い、メインをループに改造して SW 変換を始めるだけです: while(1) { /* Start a software trigger conversion */ Adc_Ip_StartConversion(ADCHWUNIT_0_VS_0_INSTANCE, ADC_IP_INPUTCHAN_EXT2, TRUE); /* Wait for the notification to be triggered and read the data */ while (notif_triggered != TRUE); notif_triggered = FALSE; delay(1000); } その後、電源ユニットで0Vから5Vの間で測定し、正しい値が確認できました。 ADC0_SE2 @3.3V: ADC0_SE2 @5V: 最後に、ADC_SC2[REFSEL]でREFSELが正しく設定されているか確認してください。 よろしくお願いします、 ジュリアン
View full article