Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
有使用MCUXpresso经验的人请问,PRINTF宏的输出会输出到哪里? 我正在尝试调试 FRDM-KL25Z 上的一些代码,但我无法确定使用此宏时会将输出打印到哪个控制台。我不得不使用串口连接进行调试。 Re: Anyone with experience using MCUXpresso, where does the PRINTF macro print to? 你好@kyoto5 感谢你的帖子。 MCUXpresso SDK 中的 PRINTF 不是标准的 C printf() 函数。这是一个 SDK 调试控制台宏,通常映射到 DbgConsole_Printf,其输出目标取决于项目的 SDK 调试控制台配置。 在 MCUXpresso IDE 中,SDK 项目可以配置为以下两种模式之一: - 半托管控制台 输出通过调试器连接发送到 IDE 半主机/控制台窗口,而不是通过 UART。 - UART 控制台 输出通过板载UART发送。在 FRDM-KL25Z 上,这通常作为 OpenSDA 虚拟 COM 端口暴露给主机 PC,因此您需要 Tera Term 或 PuTTY 等终端程序来查看它。 要在 MCUXpresso IDE 中将 UART 输出切换到 PRINTF,请参阅NXP 社区的“MCUXpresso 通常不会在‘hello world’示例中将 PRINTF 输出到控制台”一文。 希望对您有所帮助。 BR 塞莱斯特
記事全体を表示
sCheck 集成功能安全文档 设备:NXP S32K388 微控制器 元器件:SAF 软件包 - SW32K3_SAF_1.0.6_HF01_D2603,sCheck 插件(SRAM ECC 测试) 可用资料: S32K3xx 参考手册(S32K3XXRM_Rev12_2025_11_11.pdf / S32K3XXRM 1_fullReferenceManual.pdf,sCheck UserManual、sCheck SRAM ECC 测试源代码。 差距:缺乏端到端的技术规范、设备寄存器映射、依赖关系交互和预期结果。 版本说明:明确指出以下版本存在一些限制 所需信息: 假定明确的功能安全目标和ECC方案 S32K388 中哪些 SRAM 实例/存储体/分区在范围内,哪些不在范围内 逐步流程包括初始化、故障注入方法、验证和恢复。 所需运行条件(时钟、MPU/XRDC 设置、缓存/TCM 状态、从 RAM/Flash 运行) 跨插件的前置条件/后置条件;元器件间初始化序列示例 SAF/sCheck/eMcem/SafetyBase 基于 S32K388 的版本兼容性矩阵 及格/不及格标准、结果代码及其解读方法 使用的中断、NMI 或错误报告路径;用于应用程序级处理的钩子/回调 Re: Safety documentation for sCheck integration 你好, 对于 sCheck 集成,请主要参考 sCheck 用户手册,特别是“软件集成”章节。本章包含集成要求、假设、内存段定义、链接器文件更新、MPU 配置要求以及任何特定于测试的先决条件。 除了 sCheck 用户手册外,请查阅相应的 S32K3 功能安全手册,其中列出了 sCheck (SM2.*.SCHECK) 涵盖的功能安全机制,并解释了它们在整体功能安全概念中的作用。 SAF 文档代码包,软件包还包含针对其他 SAF 元器件(sBoot、mSel、eMCEM、BIST 等)的模块特定集成指南。因此,集成要求分散在 SAF 模块用户手册中,而不是集中在一个独立组网 \(SA\) 功能安全集成文档中。 我们至少建议您查看以下内容: sCheck 用户手册 → 软件集成 查看用户手册 → 条件、限制和副作用 S32K3 功能安全手册 → SAF/sCheck 涵盖的功能安全机制 SAF 集成文档,涵盖链接器、MPU、启动和 API 集成要求 [[ ## completed ##]] 这些文档提供了将 sCheck 集成到功能安全应用程序所需的信息。 顺祝商祺! Peter
記事全体を表示
Imx6ull KSZ8041NLイーサネットの問題 こんにちは 、 私たちの潜在的なプロジェクトの一つにデュアルイーサネットを利用するために、Imx6ullプロセッサを搭載した2つのイーサネット物理線を接続しました。 一方のPHYはKSZ8081、もう一方のPHYはKSZ8041です。以下は当社のDTS構成です。 &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; ステータス = "正常"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; ステータス = "正常"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0: イーサネット-phy@1 { reg = <1>; micrel、LEDモード = <1>; クロック = <&CLKS IMX6UL_CLK_ENET_REF>; クロックネーム = 「rmii-ref」; }; ETHphy1: イーサネットphy@3 { reg = <3>; micrel、LEDモード = <1>; クロック = <&clks IMX6UL_CLK_ENET2_REF>; クロックネーム = 「rmii-ref」; }; }; }; pinctrl_enet1: enet1grp { fsl、pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2: enet2grp { fsl、pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; イーサネットの物理はカーネルログで検出され、イーサネットケーブルを接続するとリンクも検出されています。 しかしIPはKSZ8081物理に接続されているイーサネットに届き、IPはKSZ8084NLに接続されているイーサネットに割り当てられていません。 そして、イーサネットKSZ8041NL eth0でrxエラーが観察されます。以下のログは以下の通りです: root@sls-IMX6ull14X14evk:~# ifconfig eth0 リンク encap:イーサネット HWaddr BA:9C:69:1F:76:3A UP放送マルチキャスト MTU:1500 メトリック:1 RXパケット:0 エラー:1065 ドロップ:0 オーバーラン:0 フレーム:1065 送信パケット数:65 エラー数:0 ドロップ:0 オーバーラン数:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:12024(11.7 KiB) eth1 リンク encap:イーサネット HWaddr 42:19:11:7F:5E:89 inet addr:10.20.0.184放送日時: 10.20.1.255マスク:255.255.254.0 inet6 アドレス: fe80::8248:9837:9647:2a00/64 スコープ:リンク UP ブロードキャスト実行中 マルチキャスト MTU:1500 メトリック:1 受信パケット数:18 エラー数:0 ドロップ数:0 オーバーラン数:0 フレーム数:0 送信パケット数:23 エラー数:0 ドロップ数:0 オーバーラン数:0 キャリア数:0 衝突回数:0 txqueuelen:1000 RX バイト:2494 (2.4 KiB) TX バイト:3162 (3.0 KiB) lo Link encap:ローカルループバック インターネットアドレス: 127.0.0.1マスク:255.0.0.0 inet6 アドレス: ::1/128 スコープ:ホスト UPループバック実行中 MTU:65536 メトリック:1 受信パケット数:17 エラー数:0 ドロップ数:0 オーバーラン数:0 フレーム数:0 送信パケット数:17 エラー数:0 ドロップ数:0 オーバーラン数:0 キャリア数:0 衝突回数:0 txqueuelen:1000 RX バイト:2011 (1.9 KiB) TX バイト:2011 (1.9 KiB)   root@sls-IMX6ull14x14EVK:~# ethtool eth0 eth0の設定: 対応ポート:[TP MII ] 対応リンクモード:10baseT/Half、10baseT/Full。 100ベースT/ハーフ 100ベースT/フル サポートされる一時停止フレーム使用:対称 自動交渉を支持:はい 対応FECモード:報告されていません 広告リンクモード:10baseT/ハーフ 10baseT/フル 100ベースT/ハーフ 100ベースT/フル 広告される一時停止フレームの使用:対称 広告された自動交渉:はい 広告されたFECモード:報告されていません リンクパートナーが宣伝しているリンクモード:10baseT/Half、10baseT/Fullです 100ベースT/ハーフ 100ベースT/フル リンクパートナーが一時停止を提示したフレーム使用:いいえ リンクパートナーが自動交渉を宣伝していました:はい リンクパートナーがFECモードを広告している:報告されていません 速度:100Mb/s デュプレックス:フル 自動交渉:オン 移植版:ツイステッドペア ファイアド:3 トランシーバ:外部 MDI-X:不明 ウェイクオン支援:g ウェイクオン:d リンク検出:はい   また、50MHzのクロックも確認しましたが、これは適切に生成され、PHY KSZ8041NLにも入力されています。 要するに、1本のイーサネットは正常に動作していますが、2本目のイーサネットは正常に動作KSZ8081 KSZ8041NL。 解決策をご提案ください。参考までに、両方のイーサネット物理ハードウェアのスクリーンショットも添付しています。 image (1).png image (2).jpg i.MX6 全て i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue NXPチームの皆様、こんにちは。 問い合わせ内容について、何か最新情報があれば教えていただけますか? Re: Imx6ull KSZ8041NL ethernet issue こんにちは、NXPサポートチームの皆さん、 私たちはすでに、私たちが直面しているイーサネットの問題について詳細を共有しています。 ですので、あなたの側で確認して、何か解決があれば教えていただけますか? 必要であれば、お電話にて貴社チームと問題について話し合うことも可能です。 貴社チームからの良いフィードバックをお待ちしております。 よろしくお願いいたします。 リテシュ・プラジャパティ Re: Imx6ull KSZ8041NL ethernet issue こんにちは@HarshilSoni434 @ritesh_prajapat お元気でお過ごしのことと思います。 KSZ8041の回路図のストラップオプションを見てみましょう。 Manuel_Salas_0-1785172670273.png 分離モード:プルアップ(デフォルト)=有効 プルダウン= 無効にする PHYは、RMIIデータピン(RXD0、RXD1、CRS/DV、RX_ER、TXD0、TXD1、TX_EN)をMACから切り離します。 MDIO/MDCは完全に機能しており、PHYも検出され、リンクパルスも生成されています。おそらくこれが、PHYが検出され、リンクがアップ状態に見える理由でしょう。 ISOLATEピンのR37をプルアップ抵抗 (~4.7kΩからGND)に変更してみてもらえますか? 次に確認すべき点はリセットピンです。リセットが正しくアサルされているか確認していただけますか? そして、reset_n信号が以下の接続点に合っているかを確認してください: phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; 次に、CONFIG[2:0] RMII のストラップが物理的に正しく接続されていることを確認してください。 また、KSZ8041の回路図の信号マッピング表には、次の情報が記載されています。 Manuel_Salas_1-1785173206995.png ネット名が入れ替わっているように見えます(MDCはenet_mdioとラベル付けされ、その逆も同様です)。 よろしくお願いいたします。 サラス。 Re: Imx6ull KSZ8041NL ethernet issue @Manuel_Salasさん、ご提案いただきありがとうございます。 お客様からいただいたご提案事項はすべて確認し、結果は大体本日中にご報告いたします。 よろしくお願いいたします。 リテシュ・プラジャパティ Re: Imx6ull KSZ8041NL ethernet issue こんにちは@Manuel_Salas ご返信ありがとうございます。 ご提案通り、プルダウン抵抗の変更を行い、イーサネットの通信も確認しましたが、残念ながら挙動は同じです。 IPネゴシエーション中にRXエラーが発生しています。 また、以下の点についても確認いたしました。 - リセットピンは、imx6ullのピン接続に基づいて適切です。リセットラインに手動でパルスを印加したところ、PHY(KSZ8041NL)はリセットされましたが、動作は同じでした。 - MDIOとMDCのピンの入れ替わりは回路図上の問題であり、実際のハードウェアでは接続は正しく行われています。 つまり、変更後も動作は同じで、両方のPhyは検出されますが、IPはKSZ8081と共に出ていて、KSZ8041NLでは検出されません。以下は更新されたログです: root@sls-IMX6ull14x14evk:~# DMESG |グレップFEC [ 2.124528] FEC 20B4000.イーサネット eth0: 登録済みPHCデバイス0 [ 2.207221 FEC 2188000.イーサネット eth1: 登録済みPHCデバイス1 [ 72.966866] fec 20b4000.イーサネット eth0: リンクは稼働中 - 100Mbps/フル - フロー制御はオフ root@sls-IMX6ull14x14evk:~# DMESG |グレップ eth0 [ 2.124528] FEC 20B4000.イーサネット eth0: 登録済みPHCデバイス0 [ 72.966866] fec 20b4000.イーサネット eth0: リンクは稼働中 - 100Mbps/フル - フロー制御はオフ root@sls-IMX6ull14X14evk:~# ifconfig eth0 リンク encap:イーサネット HWaddr 26:F5:A6:8C:73:42 inet6 addr: FE80::F2af:2D7A:228C:2038/64 Scope:Link UP放送 マルチキャスト実行 MTU:1500 メトリック:1 RXパケット:0 エラー:63 ドロップ:0 オーバーラン:0 フレーム:63 送信パケット:12 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:2093(2.0 KiB) eth1 リンク encap:イーサネット HWaddr 22:81:A6:66:8C:3A UP放送マルチキャスト MTU:1500 メトリック:1 RXパケット:0 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 TXパケット:0 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 衝突:0 TCキューレン:1000 RXバイト:0(0.0 B) TX バイト:0(0.0 B) lo Link encap:ローカルループバック inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host ループバックを走らせる MTU:65536 メトリクス:1 RXパケット:91 エラー:0 ドロップ:0 オーバーラン:0 フレーム:0 送信パケット数:91 エラー:0 ドロップ:0 オーバーラン:0 キャリア:0 collisions:0 txqueuelen:1000 RXバイト:7797(7.6 KiB) TX バイト:7797(7.6 KiB) root@sls-IMX6ull14x14EVK:~# ethtool eth0 eth0の設定: 対応ポート:[TP MII ] 対応リンクモード:10baseT/Half、10baseT/Full。 100ベースT/ハーフ 100ベースT/フル サポートされる一時停止フレーム使用:対称 車載交渉を支持:はい 対応FECモード:報告されていません 広告リンクモード:10baseT/ハーフ 10baseT/フル 100ベースT/ハーフ 100ベースT/フル 広告される一時停止フレームの使用:対称 広告された車載交渉:はい 広告されたFECモード:報告されていません リンクパートナーが宣伝しているリンクモード:10baseT/Half、10baseT/Fullです 100ベースT/ハーフ 100ベースT/フル リンクパートナーが一時停止を提示したフレーム使用:いいえ リンクパートナーが車載交渉を宣伝していました:はい リンクパートナーがFECモードを広告している:報告されていません 速度:100Mb/s デュプレックス:フル 車載交渉:オン 移植版:ツイステッドペア ファイアド:0 トランシーバ:外部 MDI-X:不明 ウェイクオン支援:g ウェイクオン:d リンク検出:はい ぜひご提案をお願いします。 Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん さらにイーサネットFECドライバ fec_main.Cへのデバッグも行いましたRXエラーの根CASEを特定するために。 その結果、ドライバがCRCの不一致エラー BD_ENET_RX_CRのためにすべてのrxパケットを無視していることがわかりました。 SO これを踏まえて、問題解決のためのご提案をお願いします。 Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん、 前回の観察結果に基づくと、何か最新情報はありますか? CRCエラーのため、すべての受信パケットが無視されることを改めてお知らせします。SO、何がその原因になり得るCANでしょうか? Re: Imx6ull KSZ8041NL ethernet issue こんにちは、 @Manuel_Salas さん、 おはよう、 すでに共有された問題に関する直近のアップデート@HarshilSoni434確認する機会はありましたか?CRCミスマッチの受信パケットの正確な問題を絞り込むために、何か手がかりや追加の発見があれば教えていただけませんか? 弊社側で何か情報が必要な場合はお知らせください。 よろしくお願いいたします。 リテシュ・プラジャパティ
記事全体を表示
LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers This has dragged on for far too long now... I've been through the examples for single SPI/DMA transfers and these work. I've been through the examples for DMA/Linked memory transfers and these work. But none cover my requirement and try s I might I can't get one to fit. I need a free running SPI TX/RX using DMA with either linked configurations or just ping-pong to start. Surely there must be someone on here that's achieved this already, who'd be willing to share some knowledge? The best I've managed so far is a set of linked configurations for SPI_DMA, which execute just once (despite the last linking back to the first) and then stop. The worse is a single 8-bit transfer for linked 16-bit transfers. I'm running out of ideas and pretty sure I'm now trying things that have already failed. Anybody..? General LPC55xx Peripherals Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers I know this is an old post, but anyway... the problem is related with the width of your tx transfer. To configure the fifo must be 32 bits (16 data + 16 cfg) or you have all the configuration bit in the spi that are zeroes, with the problems you are experiencing. --gra Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers Hi @IanMcCarthy  I would like to apologize for the delay. We are experimenting an anormal volume of questions these days. I really thank you for your patience. Regarding your question, once you do a single manual start (run on debug session), all the code has to run indefinitely, and SCK from SPI has to generate more than 2 pulses (continuosly until you press stop). I would like to ask for you which example from our SDK you are using for LPC55S69? What changes did you make to the code? So I can reproduce your code on my board and see what is going on. Thank you so much for your help. Please let me know if you have more questions. Best Regards. Pablo Avalos. Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers Third attempt to post an update... I need to continuously receive data from a slave SPI device at a fixed rate (manually triggering won't meet the requirements). The code below shows where I'm currently at, but this just generates 2 SPI clock pluses and that's it. I'm assuming once SPI is configured I can configure a linked set of DMA descriptors and after a single manual start, this will run indefinately, or am I mistaken? If someone would be willing to help out, it'd be much appreciated. srcClock_Hz = EXAMPLE_SPI_MASTER_CLK_FREQ; SPI_MasterGetDefaultConfig(&masterConfig); masterConfig.sselNum = (spi_ssel_t)EXAMPLE_SPI_SSEL; masterConfig.sselPol = (spi_spol_t)EXAMPLE_MASTER_SPI_SPOL; masterConfig.dataWidth = kSPI_Data8Bits; masterConfig.baudRate_Bps = 8000; SPI_MasterInit(EXAMPLE_SPI_MASTER, &masterConfig, srcClock_Hz); DMA_Init(EXAMPLE_DMA); // Enable channels DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel priorities DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL, kDMA_ChannelPriority3); DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL, kDMA_ChannelPriority2); // Create channel handles DMA_CreateHandle(&masterTxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_CreateHandle(&masterRxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel callbacks DMA_SetCallback(&masterTxHandle, TxCallback, NULL); DMA_SetCallback(&masterRxHandle, RxCallback, NULL); DMA_SetupDescriptor( &dmaTxDescriptors[0], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[1]); DMA_SetupDescriptor( &dmaTxDescriptors[1], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[2]); DMA_SetupDescriptor( &dmaTxDescriptors[2], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[0]); DMA_PrepareChannelTransfer(&dmaChannelConfig, &masterTxData, (void *)&SPI7->FIFOWR, DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), kDMA_MemoryToPeripheral, NULL, // &dmaChannelTrigger, &dmaTxDescriptors[0] ); DMA_SubmitChannelTransfer(&masterTxHandle, &dmaChannelConfig); DMA_StartTransfer(&masterTxHandle); Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers I haven't totally understood your answer, could you please further explain? Why not keeping the uint8_t width of the transfer? I have also noticed that the 3rd and 4th input parameters of the function DMA_SetupDescriptor() are in the incorrect place. Additionally, shouldn't each descriptor destination address re-direct the data to another memory position, instead of all of them pointing to &masterTxData ?
記事全体を表示
MCUXpressoの使用経験のある方、PRINTFマクロはどこに出力されますか? FRDM-KL25Zのコードをデバッグしようとしているのですが、このマクロを使うときにどのコンソールに印刷されているのか分かりません。デバッグのためにシリアル接続を使わざるを得ませんでした。 Re: Anyone with experience using MCUXpresso, where does the PRINTF macro print to? こんにちは@kyoto5 投稿ありがとうございます。 MCUXpresso SDKのPRINTFは標準のCのprintf()ではありません。これはSDKデバッグコンソールのマクロで、通常DbgConsole_Printfにマッピングされ、その出力先はプロジェクトのSDKデバッグコンソールの設定に依存します。 MCUXpresso IDEでは、SDKプロジェクトは以下のいずれかに設定できます: - セミホスティングコンソール 出力はUART経由ではなく、デバッガ接続を通じてIDEのセミホスティング/コンソールウィンドウに送信されます。 - UARTコンソール 出力は基板上のUARTを介して送信されます。FRDM-KL25Zでは、これは通常OpenSDAバーチャルCOMポートとしてホストPCに公開されるため、Tera TermやPuTTYなどのターミナルプログラムで表示する必要があります。 MCUXpresso IDEでUARTをPRINTF出力に切り替えるには、「MCUXpressoはしばしばPRINTFをコンソールに変換しない」例を「hello world」で参照してください - NXPコミュニティ お役に立てば幸いです。 BR セレステ
記事全体を表示
Imx6ull KSZ8041NL 以太网问题 你好呀 , 为了在我们的潜在项目中利用双以太网,我们将两个以太网PHY芯片连接到了Imx6ull处理器上。 其中一块 PHY 芯片是 KSZ8081,另一块 PHY 芯片是 KSZ8041,以下是我们的 DTS 配置: &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; 状态 = "正常"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; 状态 = "正常"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0:以太网物理层@1 { reg = <1>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET_REF>; clock-names = "rmii-ref"; }; ethphy1:以太网物理层@3 { reg = <3>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET2_REF>; clock-names = "rmii-ref"; }; }; }; pinctrl_enet1:enet1grp { fsl,pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2:enet2grp { fsl,pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; 内核日志中检测到了两个以太网物理层,而且当我们连接以太网电缆时,两个设备上也都能检测到链路。 但是,连接到 KSZ8081 phy 的以太网上可以接收到 IP 地址,而连接到 KSZ8084NL 的以太网上却无法分配 IP 地址。 在KSZ8041NL以太网接口(eth0)上观察到接收错误,以下是日志: root@sls-imx6ull14x14evk:~# ifconfig eth0 链路封装:以太网硬件地址 BA:9C:69:1F:76:3A 上行广播组播 MTU:1500 指标:1 接收数据包:0 个错误:1065 个丢弃:0 个溢出:0 个帧:1065 个 发送数据包:65,错误:0,丢弃:0,溢出:0,载波:0 碰撞次数:0 txqueuelen:1000 接收字节数:0 (0.0 B) 发送字节数:12024 (11.7 KiB) eth1 链路封装:以太网 硬件地址 42:19:11:7F:5E:89 inet addr:10.20.0.184广播地址:10.20.1.255掩码:255.255.254.0 inet6 地址:fe80::8248:9837:9647:2a00/64 范围:链路 广播运行中 多播 MTU:1500 指标:1 接收数据包:18 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:23 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 RX 字节:2494 (2.4 KiB) TX 字节:3162 (3.0 KiB) lo Link encap:本地环回 inet addr:127.0.0.1掩码:255.0.0.0 inet6 地址: ::1/128 范围:主机 环路已启动,运行中,MTU:65536,指标:1 接收数据包:17 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:17 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 RX 字节:2011 (1.9 KiB) TX 字节:2011 (1.9 KiB)   root@sls-imx6ull14x14evk:~# ethtool eth0 eth0 的设置: 支持的端口:[ TP MII ] 支持的链路模式:10baseT/半高、10baseT/全高 100baseT/半成品 100baseT/全成品 支持的暂停帧使用方式:对称 支持自动协商:是 支持的FEC模式:未报告 宣传的连接模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 广告中暂停帧的使用:对称 广告中提及的自动协商:是 已公布的FEC模式:未报告 链路伙伴宣传的链路模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 链接伙伴宣传的暂停帧使用情况:否 链接合作伙伴已宣传自动协商:是 链接伙伴宣传的FEC模式:未报告 速度:100Mb/s 复式:全套 自动协商:开启 端口:双绞线 PHYAD:3 收发器:外部 MDI-X:未知 支持唤醒:g 唤醒:d 检测到连接:是   我们还检查了时钟,它是 50MHz 的,生成正常,并且也输入到 KSZ8041NL 物理层。 简而言之,使用 KSZ8081 的 1 个以太网接口工作正常,但使用 KSZ8041NL 的 2 个以太网接口无法工作。 请给我们提供解决方案。我们还附上了以太网PHY硬件的截图供您参考。 image (1).png image (2).jpg i.MX6 全部 i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue 您好,NXP团队, 我们提出的问题有任何更新吗? Re: Imx6ull KSZ8041NL ethernet issue 您好,NXP支持团队, 我们已经分享了我们这边遇到的以太网问题的详细信息。 所以,请您从您那边检查一下,如果有任何进展,请与我们联系。 如有需要,我们也可以通过电话与您的团队讨论问题。 等待贵团队的积极反馈。 此致, 里特什·普拉贾帕蒂 Re: Imx6ull KSZ8041NL ethernet issue 你好@HarshilSoni434 @ritesh_prajapat 希望你一切都好。 查看您的KSZ8041原理图的跳线选项: Manuel_Salas_0-1785172670273.png 隔离模式:上拉(默认)= 启用 下拉= 禁用 PHY 将其 RMII 数据引脚(RXD0、RXD1、CRS/DV、RX_ER、TXD0、TXD1、TX_EN)与 MAC 断开连接。 MDIO/MDC 仍然完全正常,PHY 已被发现,链路脉冲仍在生成,也许这就是 PHY 被检测到且链路处于 UP 状态的原因。 请尝试将 ISOLATE 引脚上的 R37 从上拉电阻改为下拉电阻(~4.7kΩ 至 GND)? 第二件要检查的事情是RESET引脚。请确认复位信号是否已正确置位? 检查 reset_n 信号是否正确连接到: phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; 然后,请检查 RMII 的 CONFIG[2:0] 绑带是否已物理正确钳位。 此外,在KSZ8041原理图的信号映射表中: Manuel_Salas_1-1785173206995.png 网络名称似乎互换了(MDC 标记为 enet_mdio,反之亦然)。 顺祝商祺! 萨拉斯。 Re: Imx6ull KSZ8041NL ethernet issue 你好@Manuel_Salas , 谢谢你的回复。 根据您的建议,我们更换了下拉电阻并检查了以太网通信,但遗憾的是,情况依旧如此。 IP协商过程中出现RX错误。 我们还核实了以下几点: - 根据 imx6ull 引脚连接判断,RESET 引脚连接正确。我们也尝试在RESET线上施加手动脉冲,PHY(KSZ8041NL)被复位,但行为仍然相同。 - MDIO 和 MDC 引脚互换是原理图问题,实际硬件中的连接是正确的。 所以更改后行为仍然相同,两个 Phy 都能被检测到,但 IP 只能通过 KSZ8081 获取,而无法通过 KSZ8041NL 获取。以下是更新后的日志: root@sls-imx6ull14x14evk:~# dmesg | grep fec [ 2.124528] fec 20b4000.ethernet eth0:已注册 PHC 设备 0 [ 2.207221] fec 2188000.ethernet eth1:已注册 PHC 设备 1 [ 72.966866] fec 20b4000.ethernet eth0:链路已连接 - 100Mbps/全双工 - 流控已关闭 root@sls-imx6ull14x14evk:~# dmesg | grep eth0 [ 2.124528] fec 20b4000.ethernet eth0:已注册 PHC 设备 0 [ 72.966866] fec 20b4000.ethernet eth0:链路已连接 - 100Mbps/全双工 - 流控已关闭 root@sls-imx6ull14x14evk:~# ifconfig eth0 链路封装:以太网 硬件地址 26:F5:A6:8C:73:42 inet6 地址:fe80::f2af:2d7a:228c:2038/64 范围:链路 广播运行中 多播 MTU:1500 指标:1 接收数据包:0 个错误:63 个丢弃:0 个溢出:0 个帧:63 个 发送数据包:12 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 (0.0 B) 发送字节数:2093 (2.0 KiB) eth1 链路封装:以太网硬件地址 22:81:A6:66:8C:3A 上行广播组播 MTU:1500 指标:1 接收数据包:0 个错误:0 个丢弃:0 个溢出:0 个帧:0 个 发送数据包:0 个错误:0 个丢弃:0 个溢出:0 个载波:0 个 碰撞次数:0 txqueuelen:1000 接收字节数:0 (0.0 字节) 发送字节数:0 (0.0 字节) lo Link encap:本地环回 互联网地址:127.0.0.1 掩码:255.0.0.0 inet6 地址: ::1/128 范围:主机 环路已启动,运行中,MTU:65536,指标:1 接收数据包:91 个,错误:0 个,丢弃:0 个,溢出:0 个,帧:0 个 发送数据包:91 个,错误:0 个,丢弃:0 个,溢出:0 个,载波:0 个 碰撞次数:0 txqueuelen:1000 RX 字节:7797 (7.6 KiB) TX 字节:7797 (7.6 KiB) root@sls-imx6ull14x14evk:~# ethtool eth0 eth0 的设置: 支持的端口:[ TP MII ] 支持的链路模式:10baseT/半高、10baseT/全高 100baseT/半成品 100baseT/全成品 支持的暂停帧使用方式:对称 支持自动协商:是 支持的FEC模式:未报告 宣传的连接模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 广告中暂停帧的使用:对称 广告中提及的自动协商:是 已公布的FEC模式:未报告 链路伙伴宣传的链路模式:10baseT/半成品 10baseT/全成品 100baseT/半成品 100baseT/全成品 链接伙伴宣传的暂停帧使用情况:否 链接合作伙伴已宣传自动协商:是 链接伙伴宣传的FEC模式:未报告 速度:100Mb/s 复式:全套 自动协商:开启 端口:双绞线 PHYAD:0 收发器:外部 MDI-X:未知 支持唤醒:g 唤醒:d 检测到连接:是 请您就此提出建议。 Re: Imx6ull KSZ8041NL ethernet issue 感谢@Manuel_Salas提供的建议。 我们会核实您提出的所有建议,并于今天内公布结果。 此致, 里特什·普拉贾帕蒂 Re: Imx6ull KSZ8041NL ethernet issue 你好@Manuel_Salas 我们对以太网 FEC 驱动程序 fec_main.c 进行了进一步的调试。用于识别 rx 错误根案例。 因此,我们发现驱动程序由于 CRC 不匹配错误 BD_ENET_RX_CR 而忽略了所有接收数据包。 基于以上情况,请您提出解决问题的建议。 Re: Imx6ull KSZ8041NL ethernet issue 你好@Manuel_Salas , 根据我们上次的观察,请问有什么最新消息吗? 再次通知您,由于 CRC 错误,所有接收数据包均被忽略。那么,造成这种情况的原因可能是什么呢? Re: Imx6ull KSZ8041NL ethernet issue 你好@Manuel_Salas , 早上好, 您是否已查看@HarshilSoni434之前分享的关于此问题的最新更新?能否请您查看一下,并与我们联系您是否有任何线索或发现,以帮助我们缩小接收数据包CRC不匹配失败的具体问题范围? [[ ## completed ##]] 如果您需要我们提供任何信息,请与我们联系。 此致, 里特什·普拉贾帕蒂
記事全体を表示
Anyone with experience using MCUXpresso, where does the PRINTF macro print to? I'm trying to debug some code on an FRDM-KL25Z, but I can't figure out which console is printed to when this macro is used. I've had to resort to using a serial connection for debugging. Re: Anyone with experience using MCUXpresso, where does the PRINTF macro print to? Hello @kyoto5  Thanks for your post. PRINTF in the MCUXpresso SDK is not the standard C printf() . It is an SDK Debug Console macro, typically mapped to DbgConsole_Printf , and its output destination depends on the project’s SDK Debug Console configuration. In MCUXpresso IDE, the SDK project can be configured for either: - Semihosting console Output is sent through the debugger connection to the IDE semihosting/console window, not through UART. - UART console Output is sent through the board UART. On FRDM-KL25Z, this is typically exposed to the host PC as the OpenSDA Virtual COM port, so you need a terminal program such as Tera Term or PuTTY to view it. To switch UART to PRINTF output in MCUXpresso IDE, please refer to MCUXpresso often won't do PRINTF to Console in 'hello world' example - NXP Community Hope it helps. BR Celeste
記事全体を表示
Imx6ull KSZ8041NL ethernet issue Hello There , To utilize dule ethernet for one of our potential project , We have connected 2 Ethernet phy with Imx6ull processor , One phy is KSZ8081 and one phy is KSZ8041 , below is our DTS configuration : &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <&ethphy0>; phy-reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; status = "okay"; }; &fec2 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet2>; phy-mode = "rmii"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; phy-reset-duration = <26>; phy-reset-post-delay=<20>; phy-supply = <&reg_peri_3v3>; status = "okay"; mdio { #address-cells = <1>; #size-cells = <0>; ethphy0: ethernet-phy@1 { reg = <1>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET_REF>; clock-names = "rmii-ref"; }; ethphy1: ethernet-phy@3 { reg = <3>; micrel,led-mode = <1>; clocks = <&clks IMX6UL_CLK_ENET2_REF>; clock-names = "rmii-ref"; }; }; }; pinctrl_enet1: enet1grp { fsl,pins = < MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 >; }; pinctrl_enet2: enet2grp { fsl,pins = < MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0 MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0 MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0 MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0 MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0 MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0 MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b031 >; }; Both The Ethernet Phys are getting detected in kernel logs and also when we connect ethernet  cable , link is also getting detected on both. but Ip is arriving on ethernet which is connected to KSZ8081 phy , the IP is not getting assigned with the Ethernet which is connected to KSZ8084NL. and there is rx errors are observed in KSZ8041NL Ethernet which is eth0 , below are the logs : root@sls-imx6ull14x14evk:~# ifconfig eth0      Link encap:Ethernet  HWaddr BA:9C:69:1F:76:3A           UP BROADCAST MULTICAST  MTU:1500  Metric:1           RX packets:0 errors:1065 dropped:0 overruns:0 frame:1065           TX packets:65 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:0 (0.0 B)  TX bytes:12024 (11.7 KiB) eth1      Link encap:Ethernet  HWaddr 42:19:11:7F:5E:89           inet addr:10.20.0.184  Bcast:10.20.1.255  Mask:255.255.254.0           inet6 addr: fe80::8248:9837:9647:2a00/64 Scope:Link           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:18 errors:0 dropped:0 overruns:0 frame:0           TX packets:23 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:2494 (2.4 KiB)  TX bytes:3162 (3.0 KiB) lo        Link encap:Local Loopback           inet addr:127.0.0.1  Mask:255.0.0.0           inet6 addr: ::1/128 Scope:Host           UP LOOPBACK RUNNING  MTU:65536  Metric:1           RX packets:17 errors:0 dropped:0 overruns:0 frame:0           TX packets:17 errors:0 dropped:0 overruns:0 carrier:0           collisions:0 txqueuelen:1000           RX bytes:2011 (1.9 KiB)  TX bytes:2011 (1.9 KiB)   root@sls-imx6ull14x14evk:~# ethtool eth0 Settings for eth0:         Supported ports: [ TP    MII ]         Supported link modes:   10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full         Supported pause frame use: Symmetric         Supports auto-negotiation: Yes         Supported FEC modes: Not reported         Advertised link modes:  10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full         Advertised pause frame use: Symmetric         Advertised auto-negotiation: Yes         Advertised FEC modes: Not reported         Link partner advertised link modes:  10baseT/Half 10baseT/Full                                              100baseT/Half 100baseT/Full         Link partner advertised pause frame use: No         Link partner advertised auto-negotiation: Yes         Link partner advertised FEC modes: Not reported         Speed: 100Mb/s         Duplex: Full         Auto-negotiation: on         Port: Twisted Pair         PHYAD: 3         Transceiver: external         MDI-X: Unknown         Supports Wake-on: g         Wake-on: d         Link detected: yes   We have also checked the clock which is 50MHz , which is generated properly and also coming into phy KSZ8041NL. In short 1 Ethernet with KSZ8081 is working properly but 2nd Ethernet not working with KSZ8041NL. Please suggest us solution. we have also attached screenshot of both Ethernet phy Hardware  for your reference . image (1).png image (2).jpg i.MX6 All i.MX6UL Re: Imx6ull KSZ8041NL ethernet issue Hello NXP Team , Is there any update for us for our asked query ? Re: Imx6ull KSZ8041NL ethernet issue Hello NXP Support Team, We have already shared details about Ethernet issue which we are facing at our end.  So, would you please check it from your end and let us know resolution if anything from your end?  If needed then we will be available over call to discuss issue with your team as well. Waiting for positive feedback from your team end.  Regards, Ritesh Prajapati Re: Imx6ull KSZ8041NL ethernet issue Hello @HarshilSoni434 @ritesh_prajapat  Hope you are doing very well. Looking at your KSZ8041 schematic's Strapping Option: Manuel_Salas_0-1785172670273.png Isolate Mode: Pull-up (Default) = Enable Pull-Down = Disable The PHY disconnects its RMII data pins (RXD0, RXD1, CRS/DV, RX_ER, TXD0, TXD1, TX_EN) from the MAC. MDIO/MDC remains fully functional and PHY is discovered, link pulse is still generated and maybe this is why the PHY appears detected and link is UP. Can you please try Changing R37 from pull-up to a pull-down resistor (~4.7kΩ to GND) on the ISOLATE pin? The second thing to check is the Reset Pin. Can you please confirm that the reset is properly asserted? And check the reset_n signal is according connected to the: phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>; //phy-reset-gpios = <&gpio5 6 GPIO_ACTIVE_LOW>; Then, please check the CONFIG[2:0] Strapping for RMII are physically well asserted. Also, in the KSZ8041 schematic's signal mapping table: Manuel_Salas_1-1785173206995.png The net names appear swapped (MDC labeled as enet_mdio and vice versa). Best regards, Salas. Re: Imx6ull KSZ8041NL ethernet issue Hello @Manuel_Salas , Thank you for your response , As per your suggestion , We have done the pull-down resistor change and checked the Ethernet communication , Unfortunately the behavior is same. We are getting RX-errors during IP Negotiation. We have also verified the below points : - The reset pin is proper based on imx6ull pin connection. we have also applied manual pulse on reset line , the phy (KSZ8041NL) is getting reset but the behavior is same. - The MDIO and MDC pin swap is the schematic issue , the connection is proper in actual hardware . So the behavior is same after changes , Both Phy is getting detected but IP is coming with KSZ8081 only not with KSZ8041NL. below is the updated log : root@sls-imx6ull14x14evk:~# dmesg | grep fec [ 2.124528] fec 20b4000.ethernet eth0: registered PHC device 0 [ 2.207221] fec 2188000.ethernet eth1: registered PHC device 1 [ 72.966866] fec 20b4000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off root@sls-imx6ull14x14evk:~# dmesg | grep eth0 [ 2.124528] fec 20b4000.ethernet eth0: registered PHC device 0 [ 72.966866] fec 20b4000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off root@sls-imx6ull14x14evk:~# ifconfig eth0 Link encap:Ethernet HWaddr 26:F5:A6:8C:73:42 inet6 addr: fe80::f2af:2d7a:228c:2038/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:63 dropped:0 overruns:0 frame:63 TX packets:12 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:2093 (2.0 KiB) eth1 Link encap:Ethernet HWaddr 22:81:A6:66:8C:3A UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:91 errors:0 dropped:0 overruns:0 frame:0 TX packets:91 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7797 (7.6 KiB) TX bytes:7797 (7.6 KiB) root@sls-imx6ull14x14evk:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 100Mb/s Duplex: Full Auto-negotiation: on Port: Twisted Pair PHYAD: 0 Transceiver: external MDI-X: Unknown Supports Wake-on: g Wake-on: d Link detected: yes Please provide us the your suggestion for the same. Re: Imx6ull KSZ8041NL ethernet issue Thanks @Manuel_Salas for providing suggestions from your end. We will check all things suggested from your end and will post results mostly by today. Regards, Ritesh Prajapati Re: Imx6ull KSZ8041NL ethernet issue Hello @Manuel_Salas we have done further debugging into ethernet fec driver fec_main.c for identifying the rx error root-case. So we found that driver is ignoring all the rx-packets due to CRC mismatch error BD_ENET_RX_CR. so based on this , please provide your suggestion for issue resolution . Re: Imx6ull KSZ8041NL ethernet issue Hello @Manuel_Salas  , Based on our last observation , is there any update for us .? just updating you again that all the rx-packets are ignored due to CRC error. so what can be the cause of it ? Re: Imx6ull KSZ8041NL ethernet issue Hello @Manuel_Salas , Good Morning, Did you get a chance to review last couple of updates regarding issue which @HarshilSoni434 has already shared to you? Can you please look into it and let us know if you have any clue or any further findings from your end to narrow down exact issue of CRC mismatch failed for receive packet?  Let us know if need any information from our end.  Regards, Ritesh Prajapati
記事全体を表示
LPC55S69 与 SPI - DMA - 关联或乒乓传输无缘 这件事已经拖得太久了...... 我看过单次 SPI/DMA 传输的示例,这些都能正常工作。 我看过 DMA/链接内存传输的示例,这些都能正常工作。 但没有一个能满足我的要求,我想尽办法也找不到合适的。 我需要一个使用 DMA 的自由运行 SPI TX/RX,既可以是链接配置,也可以是乒乓启动。 这里肯定有人已经做到了这一点,愿意分享一些知识? 到目前为止,我所能做到的最好的方法是为 SPI_DMA 设置一组链接配置,这些配置只执行一次(尽管最后一个链接会返回到第一个链接),然后停止。 更糟糕的是,链接 16 位传输只需一次 8 位传输。 我已经没有办法了,而且很确定我现在正在尝试一些已经失败的事情。 有人吗? 概述 LPC55xx 外设 Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 我知道这是个老帖子了,但不管怎样......问题与您的 Tx 传输宽度有关。要配置 fifo,必须是 32 位(16 个数据 + 16 个 cfg),否则 spi 中的所有配置位都是 0,就会出现您遇到的问题。 --格拉 Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 你好@IanMcCarthy 我想对延误表示歉意。这些天,我们正在试验一个正常的问题量。真的非常感谢你们的耐心。 关于你的问题,一旦你进行一次手动启动(在调试会话中运行),所有代码都必须无限期运行,来自SPI的SCK必须生成2个以上的脉冲(持续直到你按停止)。请问您使用的是 LPC55S69 SDK 中的哪个示例?您对代码做了哪些修改?这样我就可以在我的板上重现你的代码,看看发生了什么。 非常感谢你们的帮助。如果您有更多问题,请告诉我。 致以最崇高的敬意 巴勃罗-阿瓦洛斯 Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 第三次尝试发布更新... 我需要以固定速率持续接收来自从属SPI设备的数据(手动触发不符合要求)。 下面的代码显示了我目前所做的工作,但这只是生成 2 个 SPI 时钟增量,仅此而已。 我想一旦配置了 SPI,就可以配置一组关联的 DMA 描述符,然后手动启动一次,就可以无限期运行,还是我弄错了? 如果有人愿意帮忙,将不胜感激。 srcClock_Hz = EXAMPLE_SPI_MASTER_CLK_FREQ; SPI_MasterGetDefaultConfig(&masterConfig); masterConfig.sselNum = (spi_ssel_t)EXAMPLE_SPI_SSEL; masterConfig.sselPol = (spi_spol_t)EXAMPLE_MASTER_SPI_SPOL; masterConfig.dataWidth = kSPI_Data8Bits; masterConfig.baudRate_Bps = 8000; SPI_MasterInit(EXAMPLE_SPI_MASTER, &masterConfig, srcClock_Hz); DMA_Init(EXAMPLE_DMA); // Enable channels DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_EnableChannel(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel priorities DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL, kDMA_ChannelPriority3); DMA_SetChannelPriority(EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL, kDMA_ChannelPriority2); // Create channel handles DMA_CreateHandle(&masterTxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_TX_CHANNEL); DMA_CreateHandle(&masterRxHandle, EXAMPLE_DMA, EXAMPLE_SPI_MASTER_RX_CHANNEL); // Set channel callbacks DMA_SetCallback(&masterTxHandle, TxCallback, NULL); DMA_SetCallback(&masterRxHandle, RxCallback, NULL); DMA_SetupDescriptor( &dmaTxDescriptors[0], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[1]); DMA_SetupDescriptor( &dmaTxDescriptors[1], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[2]); DMA_SetupDescriptor( &dmaTxDescriptors[2], DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), &masterTxData, (void *)&SPI7->FIFOWR, &dmaTxDescriptors[0]); DMA_PrepareChannelTransfer(&dmaChannelConfig, &masterTxData, (void *)&SPI7->FIFOWR, DMA_CHANNEL_XFER(true, false, true, false, 1, 0, 0, 1), kDMA_MemoryToPeripheral, NULL, // &dmaChannelTrigger, &dmaTxDescriptors[0] ); DMA_SubmitChannelTransfer(&masterTxHandle, &dmaChannelConfig); DMA_StartTransfer(&masterTxHandle); Re: LPC55S69 Getting nowhere with SPI - DMA - Linked or Ping-Pong transfers 我还没完全理解你的回答,你能再解释一下吗?为什么不保留传输的 uint8_t 宽度? 我还注意到函数 DMA_SetupDescriptor() 的第 3 个和第 4 个输入参数位置不正确。 此外,每个描述符目标地址是否应该将数据重定向到另一个内存位置,而不是全部指向 &masterTxData?
記事全体を表示
Safety documentation for sCheck integration Device: NXP S32K388 microcontroller Components: SAF Package -  SW32K3_SAF_1.0.6_HF01_D2603, sCheck plugin ( SRAM ECC test) Available artifacts: S32K3xx Reference Manual (S32K3XXRM_Rev12_2025_11_11.pdf / S32K3XXRM 1_fullReferenceManual.pdf, sCheck UserManual, sCheck SRAM ECC test source code. Gap: lack of end-to-end tehnical specification, device register mapping, dependecny interactions and expected outcomes. Release Note : specifies that following release has limitations Information requested: Precise safety goal(s) and ECC scheme assumed Which SRAM instances/banks/partitions are in scope and out of scope on S32K388 Step-by-step flow including initialization, fault injection method, verification, and restoration Required operating conditions (clock, MPU/XRDC settings, caches/TCM state, run-from-RAM/Flash) Cross-plugin preconditions/postconditions; example initialization sequence across components Version compatibility matrix for SAF/sCheck/eMcem/SafetyBase on S32K388 Pass/fail criteria, result codes, and how to interpret them Interrupts, NMI, or error reporting paths used; hooks/callbacks for application-level handling Re: Safety documentation for sCheck integration Hello, For sCheck integration, please refer primarily to the sCheck User Manual, especially the chapter"Software Integration". This chapter contains the integration requirements, assumptions, memory section definitions, linker file updates, MPU configuration requirements, and any test-specific prerequisites. In addition to the sCheck User Manual, please review the corresponding S32K3 Safety Manual, which identifies the safety mechanisms covered by sCheck (SM2.*.SCHECK) and explains their role within the overall safety concept. The SAF documentation package also contains module-specific integration guidance for the other SAF components (sBoot, mSel, eMCEM, BIST, etc.). The integration requirements are therefore distributed across the SAF module User Manuals rather than being collected in a single standalone safety integration document. As a minimum, we recommend reviewing: sCheck User Manual → Software Integration sCheck User Manual → Conditions, Limitations and Side Effects S32K3 Safety Manual → safety mechanisms covered by SAF/sCheck SAF integration documentation for linker, MPU, startup, and API integration requirements These documents provide the information required to integrate sCheck into a safety application. Best regards, Peter
記事全体を表示
sCheck統合のためのセーフティドキュメント デバイス:NXP S32K388 マイクロコントローラ コンポーネント:SAFパッケージ - SW32K3_SAF_1.0.6_HF01_D2603、sCheckプラグイン(SRAM ECCテスト) 利用可能なアーティファクト:S32K3xxリファレンスマニュアル (S32K3XXRM_Rev12_2025_11_11.pdf / S32K3XXRM 1_fullReferenceManual.pdf、ユーザーマニュアルを確認し、SRAM ECC テストのソースコードを確認してください。 ギャップ:エンドツーエンドの技術仕様、デバイスレジスタマッピング、依存関係の相互作用、および期待される結果が不足している。 リリースノート:以下のリリースには制限事項があることを明記します 要求された情報: 正確なセーフティ目標とECCスキームの仮定 S32K388において、どのSRAMインスタンス/バンク/パーティションが対象範囲内であり、どのSRAMインスタンス/バンク/パーティションが対象範囲外であるか 初期化、故障注入方法、検証、復元を含むステップバイステップのフロー 必要な動作条件(クロック、MPU/XRDC設定、キャッシュ/TCM状態、RAM/フラッシュからの起動) プラグイン間の前提条件/事後条件。コンポーネント間の初期化シーケンスの例。 S32K388上のSAF/sCheck/eMcem/SafetyBaseのバージョン互換性マトリックス 合否判定基準、結果コード、およびその解釈方法 割り込み、NMI、またはエラー報告経路の使用;アプリケーションレベルのハンドリングのためのフック/コールバック Re: Safety documentation for sCheck integration こんにちは、 sCheck統合については、主にsCheckユーザーマニュアル、特に「ソフトウェア統合」章を参照してください。この章では、統合要件、前提条件、メモリセクションの定義、リンカファイルの更新、MPU構成要件、およびテスト固有の前提条件について説明します。 sCheckユーザーマニュアルに加え、対応するS32K3セーフティマニュアルもご確認ください。そこではsCheck(SM2.*.SCHECK)でカバーされているセーフティ機構が記載され、全体的なセーフティ概念における役割を説明しています。 SAFのドキュメントパッケージには、他のSAFコンポーネント(sBoot、mSel、eMCEM、BISTなど)に関するモジュール固有の統合ガイダンスも含まれています。したがって、統合要件は単一の独立したセーフティ統合文書にまとめられるのではなく、SAFモジュールのユーザーマニュアル全体に分散されています。 最低限、以下の項目を確認することをお勧めします。 sCheck ユーザーマニュアル → ソフトウェア統合 sCheck ユーザーマニュアル → 状態、制限および副作用 S32K3 セーフティマニュアル → SAF/sCheckで扱われる安全機構 リンカー、MPU、スタートアップ、API統合要件に関するSAF統合ドキュメント これらの書類は、sCheckをセーフティアプリケーションに統合するために必要な情報を提供します。 よろしくお願いいたします。 ピーター
記事全体を表示
SENT Protocol Hi community I am trying to figure out how to implement SENT protocol on S32K311 PCB board for position detection of Actuator as it has position sensor. As NXP doesn't have Block set related to SENT protocol. It will be a great help if someone is willing to share. Re: SENT Protocol Hi@Ganesh808 If you are using S32 DS + RTD, our S32 DS example code provides a demo of implementing the SENT protocol using flexio. Senlent_0-1785740424865.png If you are using MBDT, here's a similar answer I've seen: https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/SENT-Protocol-Support-in-S32K3-MBDT/td-p/1775025 If you are developing a project using MBDT and encounter any problems, please ask in the MBDT forum next time. This is a dedicated forum for answering MBDT questions.
記事全体を表示
Can an eBike motor get wet? Yes! An eBike motor can get wet from rain, mud, and splashing puddles, but it is water-resistant, not waterproof. This means your eBike can handle normal wet weather, but it will suffer severe damage if it gets submerged in deep water or blasted with a pressure washer. Using the Himiway D5 2.0 as a reference, here is everything you need to know about how your motor handles water, its safety limits, and how to maintain it after a wet ride. Can an eBike motor get wet.png Real-World Boundaries: What's Safe vs. What's Dangerous The Himiway D5 2.0 is an all-terrain fat-tire eBike built to handle mud, rain, and off-road trails. However, its powerful 750W rear hub motor still operates under key physical limits. What is safe: Riding through steady rain, splashing through shallow puddles, navigating wet off-road trails, and wiping down your frame with a damp cloth or soft brush. What is dangerous: Riding through deep streams or flooded streets where water reaches the center of the wheel hubs, riding in torrential downpours for hours, or using a high-pressure hose. High-pressure water forces moisture past rubber gaskets and into internal electronics. The "Thermal Vacuum" Risk: When you push your Himiway D5 2.0 hard up a steep hill, the hub motor warms up. If you immediately plunge that hot motor into a cold puddle or creek, the air inside contracts rapidly. This sudden cooling creates a vacuum effect that can pull moisture past the seals and directly into the internal circuitry. Understanding Ingress Protection (IP) Ratings Most eBikes use standard IP (Ingress Protection) ratings to define how well their motors and battery systems resist dust and moisture: IP Rating Level of Protection Real-World Application IPX4 Splashes from any angle Light drizzle and small splashes IPX5 Low-pressure water jets Moderate rain and road spray (Standard for Himiway D5 2.0 components) IPX6 Powerful high-pressure jets Heavy downpours and thick mud spray IPX7 Temporary submersion Shallow submersion up to 30 mins (Rarely found on standard eBikes) Note on the Himiway D5 2.0: The D5 2.0's motor, battery, and display screen carry solid IPX5/IPX6-equivalent weather sealing. It is engineered to keep wet trail spray and heavy rain out, provided the seals are not blasted with high pressure. 4 Rules for Wet Weather Maintenance Taking care of your eBike after a wet ride keeps the electronics dry and prevents corrosion over time. Ditch the Pressure Washer: Stick to a bucket of warm water, a gentle soap, a soft brush, and a low-pressure garden hose spray if needed. Dry Key Components Immediately: After riding through rain or mud, use a micro-fiber towel to wipe down the rear motor casing, display, throttle controls, and battery contacts. Never Store It Wet: Park your bike in a warm, dry room or garage so lingering surface humidity can evaporate naturally. If water got near the battery housing, drop the battery out to let the compartment air dry. Don't Power On a Flooded Bike: If you suspect deep water reached the interior of the motor or controller, leave the power off. Allow the bike to dry completely for 24 to 48 hours before turning it back on to avoid short-circuiting the system.
記事全体を表示
SPC入力がWUUに伝わらず、デバイスが起動しない [MCXN947との連携] SPCでは、低電力モードとアクティブモードの両方で、電圧検出割り込みを有効にしています(リセットは無効)。アクティブモードはリセットを無効にし、バンドギャップを有効にしています。 SPC0->ACTIVE_CFG: 3f101615 SPC0->LP_CFG: 3f221515 SPC0->VD_IO_CFG: 0000000a SPC0->VD_SYS_CFG: 0000000a SPC0->VD_CORE_CFG: 0000000a WUUでSPCをウェイクアップソースとして有効にしました(WUU->MEビットが設定されています)。 SPC割り込みはアクティブモードで動作しますが、電源オフモードでは動作しません。つまり、プロセッサはSPC割り込みを処理するためにウェイクアウトしません。 MCX N Re: SPC input to WUU not waking device おそらく動作しているとは思うが、アクティブモードとパワーダウンモードでは反応に大きな違いがある。アクティブモードでは、SPC割り込みはより迅速に応答し、繰り返し発生しますが、パワーダウンモードからは、割り込みが発生するまでに非常に時間がかかり、一度しか発生しません。 Re: SPC input to WUU not waking device こんにちは、 @robert_hines さん。 電源オフモードからのウェイクアップレイテンシは、アクティブモードの割り込み応答時間よりも長くなると予想されます。電源オフモードでは、MCUの大部分が静的状態にあります。より深い低消費電力モードに入る際のトレードオフの一つは、そのモードの入り出時にレイテンシが増えることです。 割り込みが一度だけ発生する問題については、アプリケーションコードの処理に問題があるのではないかと疑っています。SDKに含まれるpower_mode_switch例を参照し、実装とあなたのコードを比較していただけますか? それでも問題が解決しない場合は、FRDM-MCXN947ボード上で問題を再現できる簡単なプロジェクトを提供してください。喜んでさらに詳しく調査いたします。 よろしくお願いします。 BR アリス Re: SPC input to WUU not waking device 状況は以下のとおりです。 - FreeRTOSへの移植 - 低電力タイマーを使用して、PM_EnterLowPower()で電源オフモードに移行します。 - IRQHandlers は setFromISR() と portYIELD_FROM_ISR() を使用します - 高優先度タスクがISRで設定されたイベントビットを待機している場合、xEventGroupWaitBits() - 一部の割り込みはWUUを経由して電源オフモードで利用可能にしており、外部ピンの一部(正常に動作しているようです)や、SPCが遅い/応答しない点を除き、問題なく動作する内部モジュール(VBAT、LPTMR、TDET、SPC)も含まれます。 - SPC割り込みはIRQHandlerで無効化され、イベントビットの設定を待つ高優先度タスクで処理された後に再有効化されます。この待機タスクはイベント情報ビットのプロセッシング後に再び PM_EnterLowPower() を呼び出します。 問題は、SPC割り込みが他の割り込みと同じように応答しないことだ。プロセッサが起動しても再びスリープに戻り、再びトリガーされません。アクティブモードで電源が切れても、発火は続けます(PM_EnterLowPower()でプロセッサを再び電源オフモードに戻せません)。
記事全体を表示
[i.MX95/AAOS16]ブリングアップ支援 ハードウェア: i.MX95 15x15 SW: AAOS16_1.3.0 ほぼすべてのファイルにパッチを適用しました。 しかし、カーネル起動の問題は依然として残っている。 リチャード・キムのサポートが必要です。 Re: [i.MX95/AAOS16] Bringup support こんにちは、 @Jaeheon-Sim_Mobis さん、 改訂版ガイドラインを添付いたしましたのでご確認ください。 また、パッチされたすべてのファイルを正しいディレクトリ構造で添付しているので、ソースツリーで直接上書きできるようにしています。 よろしくお願いします。 Re: [i.MX95/AAOS16] Bringup support これは15x15サイズのFRDM-MX95にも使えますか? Re: [i.MX95/AAOS16] Bringup support いいえ、それらのパッチはi.MX95 15x15 EVKをベースにしたカスタムボード用です。
記事全体を表示
采用LCU互补PWM和死区时间实现6步BLDC换向的推荐方法是什么? 大家好, 我正在使用S32K311 开发一个三相无刷直流电机六步换向项目: 用于 PWM 生成的 eMIOS TRGMUX 拉库 GD3000闸门驱动器 RTD 5.0.0 我的相位映射图是: U_HS = eMIOS ch0 U_LS = eMIOS ch1 V_HS = eMIOS ch2 V_LS = eMIOS ch3 W_HS = eMIOS ch4 W_LS = eMIOS ch5 我使用以下 LUT 值: #define LCU_LUT_OFF 0x0000U #define LCU_LUT_PWM 0xAAAAU #define LCU_LUT_INV_PWM 0x5555U #define LCU_LUT_ON 0xFFFFU 最初,我通过在每个扇区动态更改查找表 (LUT) 来实现换向: Lcu_Ip_SetSyncOutputLutControl(LCU_LutList, 6U); V+ / W- 示例: Emios_Pwm_Ip_SetDutyCycle(EMIOS_INSTANCE, PWM_CHANNEL_V_HS, activeDuty); LCU_LutList[PWM_CHANNEL_V_HS].Value = LCU_LUT_PWM; LCU_LutList[PWM_CHANNEL_V_LS].Value = LCU_LUT_INV_PWM; LCU_LutList[PWM_CHANNEL_W_LS].Value = LCU_LUT_ON; Lcu_Ip_SetSyncOutputLutControl(LCU_LutList, 6U); 出现了一个奇怪的问题: 如果在循环之前配置一次 V_HS,则会出现 PWM。 进入换向循环并反复调用 Lcu_Ip_SetSyncOutputLutControl() 后,V_HS 停止切换,而其他通道继续工作。 这让我不禁思考,动态同步 LUT 更新是否是电机换向的正确方法。   我的主要问题 对于S32K311 + GD3000 ,推荐的架构是什么? 3对互补的PWM对 死时间插入 六步换算 安全切换 我应该: 保持 LCU LUT静态(PWM / INV_PWM),仅通过改变LCU 输出使能/覆盖状态来执行换向? 是否使用 Lcu_Ip_SetOutputLutControl()(立即更新)代替 Lcu_Ip_SetSyncOutputLutControl()? 完全避免动态 LUT 重写?   死时间问题 我想利用 LCU 生成具有死区时间的互补 PWM 。 预期方法是否为: 使用 eMIOS 仅生成 3 个基本 PWM(U、V、W), 将它们通过 TRGMUX 路由到 LCU, 使用固定 LUT:HS = 0xAAAA LS = 0x5555 在LCU输出/滤波器设置中配置死区时间, 然后仅更改每个换向扇区的输出启用/覆盖设置? 如果 NXP 有示例(RTD 或 MBDT)演示了带有 LCU 互补 PWM 和死区时间插入的 6 步 BLDC ,我将非常感激您提供参考,引用。 谢谢! Re: Recommended way to implement 6-step BLDC commutation with LCU complementary PWM and dead time? 您好@Esakki 您可以参考以下链接中的电机解决方案,您可以在此页面找到演示代码和应用程序节点: https://www.nxp.com/design/design-center/development-boards-and-designs/MCSPTE1AK344 例如,在 BLDC 的六步法中,改变电机的旋转方向通常不是通过更新 LCU 的状态来实现的,您可以查看我们的演示代码和应用程序节点。
記事全体を表示
发送协议 大家好 我正在尝试弄清楚如何在 S32K311 PCB 板上实现 SENT 协议,以检测致动器的位置,因为它有一个位置传感器。由于 NXP 没有与 SENT 协议相关的块集。如果有人愿意分享,那将对我们非常有帮助。 Re: SENT Protocol 您好@ Ganesh808 如果您正在使用 S32 DS + RTD,我们的 S32 DS 示例代码提供了一个使用 flexio 实现 SENT 协议的演示。 Senlent_0-1785740424865.png 如果你使用的是 MBDT,以下是我见过的一个类似答案: https://community.nxp.com/t5/Model-Based-Design-Toolbox-MBDT/SENT-Protocol-Support-in-S32K3-MBDT/td-p/1775025 如果您在使用 MBDT 开发项目时遇到任何问题,请下次在 MBDT 论坛中提问。这是一个专门用于回答MBDT问题的论坛。
記事全体を表示
S32K3 DMA logic link channel Hello, How should I use the DMA logic link channel function (major loop or minor loop)? I use channel 0 to link to channel 1. Why does channel 0 complete the transport and cause an interruption, but channel 1 does not transport any data. Attached is my test project BR Jason 回复: S32K3 DMA logic link channel Jason22_0-1785726345456.png This configuration needs to be checked
記事全体を表示
eバイクのモーターはCAN濡れることはありますか? はい!eバイクのモーターは雨や泥、水たまりで濡れることがありますが、水道ではなく水道耐性があります。 つまり、eバイクは通常の雨天にも耐えられますが、深い水道に浸かったり高圧洗浄機で洗浄したりすると大きな損傷を受けます。 Himiway D5 2.0を参考にして、モーターの水道の扱い方、セーフティ限界、そして濡れた走行後のメンテナンス方法について知っておくべきことをすべてご紹介します。 Can an eBike motor get wet.png 現実世界の境界線:安全なものと危険なもの Himiway D5 2.0は、泥道、雨天、オフロードコースにも対応できるよう設計された、全地形対応のファットタイヤ電動自転車です。しかし、その強力な750Wリアハブモーターは、依然としていくつかの物理的な限界の中で動作する。 安全な走行方法:降り続く雨の中を走行すること、浅い水たまりをはためきながら走ること、濡れたオフロードを走行すること、そしてフレームを湿らせた布や柔らかいブラシで拭くこと。 危険なこと:深い小川や水没した通りを走り、水道がホイールハブの中心に達すること、豪雨の中を何時間も走ること、または高圧ホースの使用。高圧の水道はゴム製ガスケットを通って湿気を内部の電子機器に送り込みます。 「熱真空」のリスク: Himiway D5 2.0 を急な坂道で強く押すと、ハブモーターが熱くなります。熱くなったモーターをすぐに冷たい水たまりや小川に浸けると、内部の空気が急速に収縮します。この急激な冷却により真空効果が発生し、湿気がシールを越えて内部回路に直接引き込まれます。 侵入保護等級(IP等級)の理解 ほとんどの電動自転車は、モーターとバッテリーシステムが粉塵や湿気にどれだけ耐えられるかを定義するために、標準的なIP(侵入保護)規格を使用しています。 IP評価 保護レベル 実世界でのアプリケーション IPX4 あらゆる角度からの飛沫 小雨と小さな水しぶき IPX5 低圧水道噴射 中程度の雨と路面からの水しぶき(Himiway D5 2.0コンポーネントの標準仕様) IPX6 強力な高圧ジェット 激しい豪雨と濃い泥しぶき IPX7 一時的な水没 最大30分間の浅い水没に耐える(一般的な電動自転車ではめったに見られない機能) Himiway D5 2.0に関する注記:D5 2.0のモーター、バッテリー、およびディスプレイ画面は、IPX5/IPX6相当の優れた防水性能を備えています。シール部分に高圧が加えられない限り、濡れた路面からの水しぶきや激しい雨を防ぐように設計されています。 雨天時のメンテナンスに関する4つのルール 雨天走行後に電動自転車を適切に手入れすることで、電子機器を乾燥した状態に保ち、経年劣化による腐食を防ぐことができます。 高圧洗浄機をやめましょう:温かい水道の入ったバケツ、優しい石鹸、柔らかいブラシ、必要なら低圧のガーデンホーススプレーを使いましょう。 キー部品をすぐに乾燥させる:雨や泥の中を走った後は、マイクロファイバータオルでリアモーターケース、ディスプレイ、スロットルコントロール、バッテリーお問い合わせを拭き取ってください。 濡れた状態で保管しないでください:自転車は暖かく乾燥した部屋やガレージに停め、表面の湿気が自然に蒸発しやすくしましょう。もし水道がバッテリーハウジングの近くに入った場合は、バッテリーを抜いてコンパートメントを自然乾燥させてください。 浸水したバイクの電源を入れないでください:モーターやコントローラの内部に深い水道が達していると疑われる場合は、電源を切ったままにしてください。システムのショートを防ぐため、バイクの電源を入れる前に、24時間から48時間かけて完全に乾燥させてください。
記事全体を表示
S32K3 DMA 逻辑链路通道 你好, 我应该如何使用DMA逻辑链路通道功能(主循环或次循环)?我使用通道 0 连接到通道 1。为什么通道 0 完成了传输并导致中断,而通道 1 没有传输任何数据? 附件是我的测试项目 BR 杰森 回复: S32K3 DMA logic link channel Jason22_0-1785726345456.png 需要检查此配置。
記事全体を表示