Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
MCUによるPMICセーフティ構成 こんにちは、NXPさん。 FS26セーフティマニュアルから、出力レギュレータの故障反応は初期化時にMCUによって設定できることが理解されています。 この構成要件が出力レギュレーターの故障反応にのみ適用されるのか、明確にしていただけますか(RSTB, FS0B & 01) PS_BUCK_PRE PS_CORE PS_LDO1 PS_LDO2 PS_LDO_REF PS_TRK1 PS_TRK2 また、 内部電圧監視機能 (例: VANA、VDIG、その他の内部監視供給レール)の故障反応も初期化時にMCUによって設定される必要があるのか? 内部電圧監視の故障反応がMCUで設定できない場合、これらの反応はFS26 PMICが内部で完全に管理していると考えてよいでしょうか? どの故障反応がMCUで設定不要で、どの回路が設定が必要かをリストアップできますか? FSBC+PMIC 機能安全 Re: PMIC Safety Configuration by MCU 以下の写真を参照してください: ABISTはVANAのVDIGを自動的にCANチェックできます。設定は不要です。
記事全体を表示
S32K396:设备锁定/在通过 MU 安装 HSE 固件后中途停止,并要求输入 ADKP 设置 S32K396,从未安装过 HSE 固件,没有安全启动,没有 ADKP。 FS26 带 200 毫秒看门狗 发生了什么 我正在通过 MU 接口安装 AB_SWAP 粉色镜像。 1. 在 UTEST 中,将 HSE FW 使用标志编程到 0x1B000000。UTEST其他地点未受影响。尽管我的启动配置中已设置了 `FW_USAGE_FLAG_PROGRAM`,但 SBAF 并未自行对其进行编程。 2. 将 0xA5 写入 DCMRWP1 (0x402AC400) 的第 31 位到第 24 位,并发出功能RESET。 3. 在 MU0 ch0 上运行握手:收到 0xFF00F00F,回复 0xF0F00F0F,收到 0xDADABABA,写入 粉色图片地址。于是SBAF开始编写固件。 4. 此后不久,一切都停止了。UART 控制台上没有其他信息了。大约5分钟后,我重启了电源。 从那以后,该板完全没有控制台输出,我再也无法像往常那样进行调试了:J-Link 报告“检测到锁定的 S32K3xx 设备”,并要求提供 ADKP。或者报告“DAP 启动失败”(见附件)。所以我现在无法读取 GPR3、DCMRWP1 或 UTEST 了。 我从未配置过 ADKP,也从未申请过生命周期预付款。 问题 1. LC有可能自行发展吗? 2. 或者这是恢复模式?在 CUST_DEL 设备的 JTAG 恢复模式下,J-Link 连接是否可以显示为 “已锁定/需要密码”?HSE_B 固件参考手册中的图 12 显示该路径正在等待调试器,但没有进行身份验证。 3. 在报废该零件之前,我还能测试些什么?最重要的是:当主机内核尚未发布版本时,是否有办法通过调试接口读取当前的 LC 状态?或者,使用 Trace32 的另一种调试方法是否会更有效? Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way 1)不,不可能。用户可以直接对 UTEST 进行编程(当未使用 HSE 固件时),也可以使用 HSE 服务进行编程(当使用 HSE 固件时)。 2)我不这么认为,虽然我没有使用 J-Link 的经验。可能会出现“检测到锁定的 S32K3xx 设备”消息 是的,"检测到锁定的 S32K3xx 设备"消息可能是由硬件(通常是电源)引起的误报,而不是真正的网络安全锁。我建议和塞格尔讨论一下: https://www.segger.com/support/technical-support/ 即使设备处于 JTAG 恢复模式,但仍处于 CUST_DEL 生命周期中,您仍然可以通过调试器连接、下载软件等等。 3)我会尝试在 POR 后立即连接或连接,可能会擦除应用程序软件。 Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way 我现在注意到的是,BCW 中没有设置“RESET_RECOVERY_MODE”位。BCW 中该位设置错误是否能解释这种现象? 我有点不明白这个设置是做什么用的。设置此位是启用还是禁用恢复模式? 在表 119 中。在 HSE 参考手册的 BCW 位映射中写道,“RESET_RECOVERY_MODE”用于“禁用因连续 RESET 而进入恢复模式”。有关更多详细信息,请参阅“禁用进入RESET恢复模式”。 然后,在“2.6.1.3.3”章节中禁用 HSE 参考手册中的“进入重置恢复模式”选项。“进入恢复模式”仅在“RESET_RECOVERY_MODE == 1 AND DCMRWP1 (SBAF_REC_DIS_FRST or SBAF_REC_DIS_DRST) == 0”时为真。 Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way 谢谢你的回复,大卫。 好的。 我已经就设备可能被错误锁定一事联系了 Segger 公司,目前正在等待回复。 我在进行 POR 操作后,通过短接 RESET 引脚,使用 J-Link 调试器进行了连接。这是该序列的日志: 在这种情况下,HSE固件尚未安装,设备也未被锁定。两种情况下遗留的错误都是 DAP 错误。 SEGGER J-Link Commander V9.18(编译于 2026 年 2 月 11 日 16:34:58) DLL 版本 V9.18,编译于 2026 年 2 月 11 日 16:33:51 通过 USB 连接到 J-Link...成功 固件:J-Link V10,编译于 2023 年 1 月 30 日 11:28:07 硬件版本:V10.10 J-Link 运行时间(自启动以来):不适用(此型号不支持) 序列号:50116795 许可证:GDB VTref=4.509V 输入“connect”建立目标连接,输入“?”获取帮助 J-Link>连接 请指定设备/核心。 : S32K396_M7_0 输入“?”以打开选择对话框 设备> 请指定目标接口: J) JTAG(默认) S) SWD T) cJTAG TIF>S 指定目标接口速度[kHz]。 :4000 kHz 速度> 已选择设备“S32K396_M7_0”。 通过SWD连接到目标 ConfigTargetSettings() 开始 ConfigTargetSettings() 结束 - 耗时 46 微秒 InitTarget() 开始 检测到 SDA_AP 必要时解锁设备…… 设备未锁定。不执行解锁程序,直接继续。 正在检查调试访问权限是否已启用…… 调试访问权限尚未启用。正在执行启用调试访问序列... 已启用调试访问权限 正在检查HSE固件是否已安装…… HSE固件未安装 检查 Cortex-M7_0 和 Cortex-M7_1 是否以同步模式运行 已启用锁定步进模式 InitTarget() 结束 - 耗时 45.5 毫秒 找到 ID 为 0x6BA02477 的 SW-DP DPIDR:0x6BA02477 CoreSight SoC-400 或更早版本 已跳过AP地图检测。已找到手动配置的AP地图。 AP[0]: MEM-AP(IDR:未设置,地址:0x00000000) AP[1]: APB-AP(IDR:未设置,地址:0x00000000) AP[2]: MEM-AP(IDR:未设置,地址:0x00000000) AP[3]: AHB-AP(IDR:未设置,地址:0x00000000) AP[4]: AHB-AP(IDR:未设置,地址:0x00000000) AP[5]: AHB-AP(IDR:未设置,地址:0x00000000) AP[6]: MEM-AP(IDR:未设置,地址:0x00000000) AP[7]: MEM-AP(IDR:未设置,地址:0x00000000) AP[4]: 跳过 ROMBASE 读取。用户手动设置 CoreBaseAddr AP[4]:核心已找到 ConfigTargetSettings() 开始 ConfigTargetSettings() 结束 - 耗时 15 微秒 InitTarget() 开始 检测到 SDA_AP 必要时解锁设备…… 设备未锁定。不执行解锁程序,直接继续。 正在检查调试访问权限是否已启用…… 核心已启用 正在检查HSE固件是否已安装…… HSE固件未安装 检查 Cortex-M7_0 和 Cortex-M7_1 是否以同步模式运行 已启用锁定步进模式 InitTarget() 结束 - 耗时 18.2 毫秒 找到 ID 为 0x6BA02477 的 SW-DP DPIDR:0x6BA02477 CoreSight SoC-400 或更早版本 已跳过AP地图检测。已找到手动配置的AP地图。 AP[0]: MEM-AP(IDR:未设置,地址:0x00000000) AP[1]: APB-AP(IDR:未设置,地址:0x00000000) AP[2]: MEM-AP(IDR:未设置,地址:0x00000000) AP[3]: AHB-AP(IDR:未设置,地址:0x00000000) AP[4]: AHB-AP(IDR:未设置,地址:0x00000000) AP[5]: AHB-AP(IDR:未设置,地址:0x00000000) AP[6]: MEM-AP(IDR:未设置,地址:0x00000000) AP[7]: MEM-AP(IDR:未设置,地址:0x00000000) AP[4]: 跳过 ROMBASE 读取。用户手动设置 CoreBaseAddr AP[4]:核心已找到 ****** 错误:读取 AIRCR 时出现 DAP 错误。 发生错误:无法连接到目标设备。 如需故障排除步骤,请访问: https://kb.segger.com/J-Link_Troubleshooting
記事全体を表示
S32K396: デバイスがロックされ、MU経由のHSEファームウェアのインストールが途中で停止した後、ADKPを要求します 設定 S32K396、HSE FWは一切インストールされておらず、セキュアブートもADKPもありません。 FS26(ウォッチドッグタイマー200ms) どうしたの AB_SWAPピンクのイメージをMUインターフェース経由でインストールしていました 1. UTESTでHSE FW使用フラグを0x1B000000にプログラムしました。他のUTEST拠点は一切影響を受けていません。ブート設定で`FW_USAGE_FLAG_PROGRAM`が設定されているにもかかわらず、SBAFはそれをプログラムしていませんでした。 2. DCMRWP1 (0x402AC400) のビット 31 から 24 に 0xA5 を書き込み、機能リセットを実行しました。 3. MU0 ch0 でハンドシェイクを実行: 0xFF00F00F を受信し、0xF0F00F0F に応答し、0xDADABABA を受信し、書き込みました。 ピンク色の画像のアドレス。SO、SBAFはファームウェアのプログラミングを始めました。 4. その後しばらくして、すべてが停止した。UARTコンソールにはそれ以上の情報はありません。約5分後に電源を入れ直しました。 それ以来、ボードはコンソール出力を一切出さず、通常のデバッグ方法もできません。J-Linkは「S32K3xxデバイスがロックされました」と表示し、ADKPを求めます。または、「DAPの電源投入に失敗しました」というレポートが表示されます(添付ファイルを参照)。SO、GPR3、DCMRWP1、UTESTはもう読めません。 私はADKPをプロビジョニングしたことも、ライフサイクルアドバンスを要求したこともありません。 質問 1. LCは単独で前進できたのか? 2. これはリカバリーモードでしょうか?CUST_DELデバイスのJTAGリカバリモードで、J-Link接続は次のように表示されます。 「ロック/パスワードが必要」?HSE_B Firmware リファレンス・マニュアルの図12は、認証なしでデバッガを待つ経路を示しています。 3. 部品を廃棄する前にまだ何を試せますか?まず最初に、ホストコアが解放されていない場合にデバッグインターフェース上で現在のLC状態を読み取る方法はありますか?それとも、Trace32を使った別のデバッグ方法の方がうまくいく可能性はありますか? Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way 1) いいえ、それはできません。HSE FWが使用されていない場合、ユーザーが直接UTESTにプログラムするか、HSE FWを使用する場合にHSEサービスを使用することでプログラムできます。 2) 私はそうは思いませんが、J-Linkの経験はありません。「ロックされたS32K3xxデバイスが検出されました」というメッセージが表示される可能性があります。 はい、「ロックされたS32K3xxデバイスが検出されました」というメッセージは、実際のセキュリティロックではなく、ハードウェア(通常は電源)による誤検知である可能性があります。セッガー氏と話し合うことをお勧めします。 https://www.segger.com/support/technical-support/ デバイス自体がJTAGリカバリーモードに入っているのであれば、もしまだCUST_DELライフサイクル中であれば、デバッガで接続したり、ソフトウェアをダウンロードしたりできるはずです。 3) POR直後に添付するか添付し、場合によってはアプリケーションを消去するのが良いでしょう。 Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way 今気づいたのは、BCWで「RESET_RECOVERY_MODE」ビットが設定されていなかったことです。BCWでこのビットを設定できなかったことがこの挙動の説明になるのでしょうか? この設定が何をするのか、少し混乱しています。このビットを設定すると、リカバリーモードが有効になりますか、それとも無効になりますか? 表119において。HSEの参考マニュアルには「RESET_RECOVERY_MODE」は「連続リセットのために回復モードへのエントリ ーを無効 化するために使用される」と書かれています。詳細については、「リセットリカバリーモードへのアクセスを無効にする」を参照してください。 次に、第2.6.1.3.3章ではHSEのリファレンスマニュアルにある「Entry into recovery mode」は「Entry into recovery mode」は「RESET_RECOVERY_MODE == 1 AND DCMRWP1 (SBAF_REC_DIS_FRST または SBAF_REC_DIS_DRST) == 0' の時にのみ有効です。 Re: S32K396: device locked / asks for ADKP after HSE FW install over MU stopped mid-way ご返信ありがとうございます、デイビッドさん。 わかった。 デバイスのロックが誤って行われた可能性についてSegger社に問い合わせており、現在回答待ちです。 PORの後にリセットピンをショートさせながらJ-Linkデバッガを使って接続しました。そのシーケンスのログは以下の通りです: この場合、HSEファームウェアはインストールされておらず、デバイスもロックされていません。どちらのシナリオでも残るエラーは、DAPエラーです。 SEGGER J-Link Commander V9.18 (コンパイル日時: 2026年2月11日 16:34:58) DLLバージョンV9.18、コンパイル日時:2026年2月11日 16:33:51 USB経由でJ-Linkに接続しています...わかった。 ファームウェア:J-Link V10 2023年1月30日 11:28:07 コンパイル ハードウェアバージョン:V10.10 J-Linkの稼働時間(起動後):該当なし(このモデルではサポートされていません) S/N:50116795 ライセンス:GDB VTref=4.509V ターゲット接続を確立するには「connect」と入力し、ヘルプを表示するには「?」と入力してください。 J-Link>接続 デバイス/コアを指定してください。 :S32K396_M7_0 選択ダイアログには「?」と入力してください 装置> ターゲットインターフェースを指定してください: J) JTAG(デフォルト) S) SWD T) cJTAG TIF> ターゲットインターフェース速度[kHz]を指定します。 <デフォルト>:4000kHz スピード> デバイス「S32K396_M7_0」が選択されました。 SWD経由でターゲットに接続 ConfigTargetSettings() 開始 ConfigTargetSettings() 終了 - 46マイクロ秒かかりました InitTarget() 開始 SDA_APが検出されました 必要に応じてデバイスのロックを解除します... デバイスはロックされていません。ロック解除の手順を経ずに続行します。 デバッグアクセスがすでに有効かどうか確認中... デバッグアクセスはまだ有効になっていません。デバッグアクセスの有効化シーケンスを実行しています... デバッグアクセス有効 HSEファームウェアがインストールされているかどうか確認しています... HSEファームウェアがインストールされていません Cortex-M7_0とCortex-M7_1がロックステップモードで動作しているか確認 ロックステップモード有効 InitTarget() エンド - 45.5msかかりました 身分証0x6BA02477で見つけたSW-DP DPIDR:0x6BA02477 CoreSight SoC-400以前 APマップ検出がスキップしました。手動で設定されたAPマップが見つかりました。 AP[0]: MEM-AP (IDR: 未設定、アドレス: 0x00000000) AP[1]: APB-AP (IDR: 未設定、アドレス: 0x00000000) AP[2]: MEM-AP (IDR: 未設定、アドレス: 0x00000000) AP[3]: AHB-AP (IDR: 未設定、アドレス: 0x00000000) AP[4]: AHB-AP (IDR: 未設定、アドレス: 0x00000000) AP[5]: AHB-AP (IDR: 未設定、アドレス: 0x00000000) AP[6]: MEM-AP (IDR: 未設定、アドレス: 0x00000000) AP[7]: MEM-AP (IDR: 未設定、アドレス: 0x00000000) AP[4]: ROMBASEの読み込みをスキップしました。ユーザーが手動で設定するCoreBaseAddr AP[4]: コア発見 ConfigTargetSettings() start ConfigTargetSettings() end - 15us をかかった InitTarget() start SDA_AP検出 必要なら解除装置を... デバイスはロックされていません。ロック解除の手順を経ずに続行します。 デバッグアクセスがすでに有効かどうか確認中... コアはすでに有効化されています HSEファームウェアがインストールされているかどうか確認しています... HSEファームウェアがインストールされていません Cortex-M7_0とCortex-M7_1がロックステップモードで動作しているか確認 ロックステップモード有効 InitTarget() エンド - 18.2ms かかりました 身分証0x6BA02477で見つけたSW-DP DPIDR:0x6BA02477 CoreSight SoC-400以前 APマップ検出がスキップしました。手動で設定されたAPマップが見つかりました。 AP[0]: MEM-AP (IDR: 未設定、アドレス: 0x00000000) AP[1]: APB-AP (IDR: 未設定、アドレス: 0x00000000) AP[2]: MEM-AP (IDR: 未設定、アドレス: 0x00000000) AP[3]: AHB-AP (IDR: 未設定、アドレス: 0x00000000) AP[4]: AHB-AP (IDR: 未設定、アドレス: 0x00000000) AP[5]: AHB-AP (IDR: 未設定、アドレス: 0x00000000) AP[6]: MEM-AP (IDR: 未設定、アドレス: 0x00000000) AP[7]: MEM-AP (IDR: 未設定、アドレス: 0x00000000) AP[4]: ROMBASEの読み込みをスキップしました。ユーザーが手動で設定するCoreBaseAddr AP[4]: コア発見 ****** エラー: AIRCR の読み取り中に DAP エラーが発生しました。 エラーが発生しました:ターゲットデバイスに接続できません。 トラブルシューティングの手順については、 https://kb.segger.com/J-Link_Troubleshootingを参照してください。
記事全体を表示
Understanding I²C Buffers and Static Voltage Offset (SVO): Why Your Bus May Fail I²C communication is widely used due to its simplicity, but when the system grows (more devices, longer traces, different voltage domains), communication issues may appear. One common root cause is the incorrect use of I²C buffers or level translators. This post explains: How I²C logic levels really work Why buffers are needed Types of I²C Buffer Technologies How Static Voltage Offset (SVO) works Common design mistakes to avoid How I²C logic levels really work I²C does not use fixed voltages like 0 V or 5 V to define logic states. Instead, it uses thresholds relative to VCC: Logic 0 (LOW): below ~30% of VCC Logic 1 (HIGH): above ~70% of VCC Undefined region: between 30%–70% → signal is unreliable In real systems, signal levels may not behave ideally. Due to: Different driver strengths Load variations Buffer offset behavior You may observe three voltage levels, even though the protocol only defines two logic states. This can lead to misinterpretation of signals. We will explore this behavior in more detail in the following sections, especially when analyzing how I²C buffers and offset mechanisms work. Why buffers are needed You should consider an I²C buffer when: Bus capacitance exceeds ~400 pF Long PCB traces or cables are used Multiple devices are connected Different voltage domains are required Isolation between sections is needed Buffers divide the system into smaller segments and improve signal integrity. For a deeper understanding, refer to the training: The Ins and Outs of I²C Bus Buffers Types of I²C Buffer Technologies Different buffer architectures solve these challenges in different ways: Static Offset: Introduces a fixed voltage offset on one side of the bus, enabling direction detection. Incremental Offset: Adds a small dynamic voltage shift (~100 mV), allowing symmetrical bidirectional operation. Amplifier: Boosts sink current instead of shifting voltage, helping weak drivers control heavier loads. In this post, we will focus specifically on Static Offset buffers, as they are widely used and often misunderstood in system design. Static Offset Buffer Characteristics Static Offset buffers are commonly used due to their robust behavior: Fully bidirectional and support multi-master operation, including clock stretching and do not generate any ‘glitches’. Isolate bus segments electrically, preventing capacitance and loading on one side from affecting the other side. Each side operates independently with its own rise time and pull-up network. Regenerate signals, producing clean LOW levels independent of the input LOW amplitude. Use a fixed Static Voltage Offset (SVO), creating a slightly higher LOW level on one side of the buffer. This offset allows the buffer to determine the origin of a LOW signal and prevents latching. Weaknesses of Static Offset Buffers Require specific design rules due to their special offset voltage levels. Static Offset ports cannot be connected together on the same bus segment. Only one offset port should exist per bus segment. Add propagation delay, which must be considered in timing analysis. Multiple buffers can reduce the maximum achievable I²C bus speed The main challenge in I²C buffers is that the bus is bidirectional. Both master and slave can pull the line LOW. By introducing a fixed voltage offset, the buffer can distinguish which side initiated the LOW condition and correctly propagate the signal across the bus. How Static Voltage Offset (SVO) works Static Voltage Offset introduces an intentional voltage offset, so a LOW level is not always represented by 0 V. Instead, the buffer creates two valid LOW levels, both within the I²C specification. To achieve this, the input and output logic levels on the special side of the buffer are intentionally designed to be different.   The key concept is that the special output LOW voltage (VOL) is set slightly higher than the corresponding input HIGH threshold (VIH): For example: Special output VOL ≈ 0.7 V Special input VIH ≈ 0.55 V When the buffer drives the special side LOW at approximately 0.7 V, that voltage is still considered a valid LOW by other I²C devices on the bus. However, for the buffer's own special input, 0.7 V is interpreted as a HIGH because it is above its VIH threshold. As a result, the buffer's output cannot feed back into its own input, preventing the latching condition commonly found in simple bidirectional buffers. This enables the buffer to distinguish between two conditions: State 1: The voltage is between the special input threshold (VIL) and the offset level (VOL/SVO). This indicates that the LOW originated from one side of the buffer. State 2: The voltage is pulled much closer to 0 V, below the special threshold. This indicates that the LOW originated from the opposite side of the buffer. By monitoring these voltage levels, the buffer can determine where the LOW signal originated (Side A or Side B). Once the direction is identified, the buffer can correctly propagate the signal to the other side while avoiding feedback, latching, and communication conflicts. But, How Does the Buffer Determine the Signal Direction? The Buffer uses an internal voltage offset to automatically determine the direction of I²C signal propagation. The offset appears on the opposite side of the device that is actively pulling the bus LOW, allowing the buffer to identify the signal source and maintain proper bidirectional operation. The buffer continuously monitors the voltage present on both sides and compares it against the internal offset thresholds. Case 1: LOW originated from the Non-Offset side (A → B) A device on Side A pulls the line LOW. The buffer propagates this LOW to Side B while adding the static offset: Side A = LOW Side B = LOW + Offset As a result: Input = LOW Output = OFFSET The presence of the offset voltage indicates that the signal originated from the Non-Offset side and is being propagated toward the Offset side.   Case 2: LOW originated from the Offset side (B → A) A device on Side B pulls the line LOW. The buffer recognizes that the voltage has been driven below the offset threshold and propagates a true LOW toward Side A: Side B ≈ LOW Side A ≈ LOW As a result: Input = LOW Output = LOW The absence of an offset on the output indicates that the signal originated from the Offset side and is being propagated toward the Non-Offset side.   INPUT OUTPUT DIRECTION LOW LOW B SIDE TO A SIDE LOW OFFSET A SIDE TO B SIDE   Common design mistakes to avoid When using I²C buffers that implement Static Voltage Offset (SVO), it is important to carefully consider both device selection and system-level design. This is because not all buffers use the same offset value. Typically, the SVO can vary between approximately 0.1 V and 0.6 V, depending on the internal design of each device. This variation directly affects how LOW levels are interpreted and how signals are propagated between segments of the bus, which can ultimately impact the reliability of bidirectional communication. Another important aspect is that the offset is not always located on the same side of the buffer. In some devices, the offset is applied on Side B, while in others it is on Side A. There are even cases where the offset may dynamically change sides depending on the operating conditions. For this reason, it is essential to fully understand the internal behavior of the selected buffer in order to avoid unexpected system behavior. The easiest way to verify this is by reviewing the device datasheet and identifying whether it specifies a parameter such as the VOL–VILC difference, which represents the difference between the LOW-level output voltage and the LOW-level input voltage during a contention condition. Voltage contention occurs when both sides of the buffer attempt to pull the line LOW at the same time but with different voltage levels or drive strengths. Due to this variability, there is a very important design rule: SVO-based buffers must never be directly connected to each other, whether in series or in parallel. This means that you should not connect two buffer sides that both introduce a voltage offset, as their LOW levels will not align correctly. The reason for this limitation is that it can lead to errors in LOW-level propagation. In such cases, a LOW signal may propagate correctly in one direction but fail in the opposite direction, breaking the bidirectional behavior of the I²C bus, which is essential for proper communication.   These diagrams show correct implementations of SVO-based I²C buffers. In these configurations, only one side of the system introduces a static voltage offset, allowing the buffer to properly distinguish the origin of the LOW signal. This ensures correct bidirectional communication, stable signal propagation, and prevents contention or oscillation issues.         These diagrams illustrate incorrect configurations where two SVO-based buffers are directly connected. In this case, both sides introduce different LOW offset levels, preventing proper alignment of logic thresholds. As a result, the buffer may fail to correctly detect the signal origin, leading to incomplete LOW propagation, loss of bidirectional behavior, and potential communication failures.     I2C
記事全体を表示
i.MX95 LPI2C 上的动态 I2C 从机地址配置 各位专家好, 我正在使用i.MX95平台,并在 Linux 下以 I2C 从模式使用 LPI2C 控制器。 目前,I2C 从机地址在设备树中是静态定义的。我的要求是根据外部 GPIO 输入(例如,板 ID 或地址选择 GPIO)动态确定从设备地址,而不是将其硬编码到设备树中。 我想知道: i.MX95 LPI2C 硬件是否支持在运行时动态更改 I2C 从机地址? Does the NXP 电路板支持包/Linux LPI2C 从设备驱动程序是否支持在启动后更新从设备地址,还是需要修改驱动程序? 从 SoC 或 电路板支持包 的角度来看,是否有推荐的机制在从设备注册之前或期间,根据外部 GPIO 选择从设备地址? 是否有任何参考实现或示例演示动态 I2C 从机地址配置? 任何指导或建议都将不胜感激。 BR, 阿伦·库马尔 Re: Dynamic I2C Slave Address Configuration on i.MX95 LPI2C 你好, 1. 是的,使用 i.MX95 的 LPI2C 模块可以实现。 2. 不,需要修改驱动程序。 当前 NXP 电路板支持包 Linux 驱动程序支持主模式和从模式,但从机地址只需从设备树中读取一次。 3. 修改驱动程序以读取 GPIO 地址并在探测期间更改线路的最佳方法。 https://github.com/nxp-imx/linux-imx/blob/b096ce610e956cc2596006343df8a2a26ed6e019/drivers/i2c/busses/i2c-imx-lpi2c.c 4. 我们有一个使用 i2c-imx-lpi2c.c 的从属 DTS 示例。驱动程序无法在运行时使用 GPIO 更改地址。您可以点击以下链接查看: https://github.com/nxp-imx/linux-imx/blob/74521e3f425001c27a54323ee8de4f7c59ee88dc/arch/arm64/boot/dts/freescale/imx95-15x15-evk-i2c-spi-slave.dts 顺祝商祺!
記事全体を表示
T Embedにはどのようなポートがありますか? 標準モデルのTエンベッドを持っていますが、どのポートか全く分かりません(もう一つのポートで、USB-Cではありません)。公式サイトではGroveポートと書いてあり、LilygoのWikiサイトではQwiicポートと書かれています。どなたか助けていただけませんか? Re: What kind of port does the T Embed have? こんにちは、 このデバイスはNXP製品ではないので、Lilygoのサポートに直接連絡して部品番号を共有することをお勧めします。ピン図やBOMのページを確認してみると良いでしょう。 よろしくお願いいたします。
記事全体を表示
i.MX95 LPI2Cにおける動的I2Cスレーブアドレス構成 こんにちは、専門家の皆様。 私はiについて取り組んでいます。MX95 プラットフォームで、 Linux上でLPI2CコントローラをI2Cスレーブモードで 使用しています。 現在、I2Cスレーブアドレスはデバイスツリー内で静的に定義されています。私の要件は、デバイスツリーにアドレスをハードコーディングするのではなく、外部GPIO入力(例えば、ボードIDやアドレス選択GPIO)に基づいてスレーブアドレスを動的に決定することです。 知りたいのは以下の点です。 i.MX95 LPI2Cハードウェアは、実行時にI2Cスレーブアドレスを動的に変更することをサポートしていますか? NXP BSP/Linux LPI2Cのスレーブドライバーは、起動後にスレーブアドレスを更新できるのでしょうか?それともドライバーの変更が必要でしょうか? SoCまたはBSPの観点から、スレーブ登録前または登録中に外部GPIOに基づいてスレーブアドレスを選択するための推奨されるメカニズムはありますか? 動的なI2Cスレーブアドレス設定を示すリファレンス実装やサンプルはありますか? 何かご助言や推奨される方法があれば、ぜひお聞かせください。 BR、 アルン・クマール Re: Dynamic I2C Slave Address Configuration on i.MX95 LPI2C こんにちは、 1. はい、i.MX95のLPI2Cモジュールで可能です。 2. いいえ、ドライバの改造は不要です。 現在のNXP BSP Linuxドライバはマスターモードとスレーブモードの両方をサポートしていますが、スレーブアドレスはデバイスツリーから一度だけ読み込みます。 3. このモモディットドライバーがプローブ中にGPIOアドレスを読み取り、ラインを変更する最良の方法。 https://github.com/nxp-imx/linux-imx/blob/b096ce610e956cc2596006343df8a2a26ed6e019/drivers/i2c/busses/i2c-imx-lpi2c.c 4. i2c-imx-lpi2c.c を使用するスレーブ DTS のサンプルがあります。ただし、GPIOを使って実行時にアドレスを変更することはできません。次のリンクからご覧いただけます: https://github.com/nxp-imx/linux-imx/blob/74521e3f425001c27a54323ee8de4f7c59ee88dc/arch/arm64/boot/dts/freescale/imx95-15x15-evk-i2c-spi-slave.dts よろしくお願いいたします。
記事全体を表示
S32K388 TCP/IP stack 5.0.0 not working Hi @PavelL, I was able to run the example TCP/IP stack example project previously with the following configuration: • S32KDS version 3.6.5 • RTD (Real-Time Drivers) version 7.0.0 • TCP/IP Stack version 4.0.0 However, after upgrading to the following versions and did the same setup procedure, it is not working: • S32KDS version 3.6.8 • RTD (Real-Time Drivers) version 7.0.1 • TCP/IP Stack version 5.0.0 I have attached my project. Thanks for the help again. Re: S32K388 TCP/IP stack 5.0.0 not working Hello @James_Zhang_SE , I need time for investigation. I'll do my best to reply within this week. Thank you for your understanding. Best regards, Pavel Re: S32K388 TCP/IP stack 5.0.0 not working Hello @James_Zhang_SE , I apologize for delayed response caused by my workload. The root cause is EthIf_Cfg.c , as we've already discussed in this thread S32K388 tcpip stack 4.0.0 missing lwip folder while compiling The example is working now on my S32K388EVB-Q289. Anyway, I did lots of changes in your project but the most critical is the EthIf_Cfg file. All modified files can be found in the attached zip. You may check the changes by yourself. Please notice that provided code is without any warranty. Once you replace files by the patch, please do not forget to do Update Code. Best regards, Pavel Re: S32K388 TCP/IP stack 5.0.0 not working Hi Pavel, Thank you so much for your help! After applying the same steps as before, I was able to ping and test the TCP loopback. I have a few quick questions: For the Ethif Config fix and RTD workarounds, will they be added in future releases of the driver and example project? Since I'm not too familiar with this stack. When something is not working, do you have a suggested systematic way to debug? Re: S32K388 TCP/IP stack 5.0.0 not working Hello @James_Zhang_SE , Thank you for sharing your current status.   If my previous post helped to solve the issue, please mark it as a solution, as this may help other users facing a similar problem.   Regarding point 1:   I have reported the EthIf_Cfg issue to the responsible software team. The release date of the fix is not known yet. There is still an internal discussion about where the RTD workaround should be implemented, whether in the MAC driver or in the clock configuration area. For now, we need to accept the current situation and apply the workaround manually.   Regarding point 2:   My usual debug flow is to check the pin configuration, clock configuration, interrupt configuration, FIFO sizes and the required RTD workaround code. The gPTP examples are also a very good reference, because they provide functional Ethernet-related configurations that can be used for comparison. Best regards, Pavel
記事全体を表示
Dynamic I2C Slave Address Configuration on i.MX95 LPI2C Hello Experts, I am working on the i.MX95 platform and using the LPI2C controller in I2C slave mode under Linux. Currently, the I2C slave address is defined statically in the Device Tree. My requirement is to determine the slave address dynamically based on an external GPIO input (for example, a board ID or address-select GPIO) instead of hardcoding it in the Device Tree. I would like to know: Does the i.MX95 LPI2C hardware support changing the I2C slave address dynamically at runtime? Does the NXP BSP/Linux LPI2C slave driver support updating the slave address after boot, or would it require driver modifications? Is there any recommended mechanism from the SoC or BSP perspective to select the slave address based on an external GPIO before or during slave registration? Are there any reference implementations or examples demonstrating dynamic I2C slave address configuration? Any guidance or recommended approach would be appreciated. BR, Arun Kumar Re: Dynamic I2C Slave Address Configuration on i.MX95 LPI2C Hello, 1. Yes, is possible with LPI2C module of i.MX95. 2. No, driver modifications are needed. The current NXP BSP Linux driver supports both master and slave modes but, the slave address is read once from the Device Tree. 3. The best approach for this modify driver to read the GPIO address and change line during probe. https://github.com/nxp-imx/linux-imx/blob/b096ce610e956cc2596006343df8a2a26ed6e019/drivers/i2c/busses/i2c-imx-lpi2c.c 4. We have an slave DTS example that uses i2c-imx-lpi2c.c driver but the address cannot be changed in runtime using GPIOs. You can take a look in the next link: https://github.com/nxp-imx/linux-imx/blob/74521e3f425001c27a54323ee8de4f7c59ee88dc/arch/arm64/boot/dts/freescale/imx95-15x15-evk-i2c-spi-slave.dts Best regards.
記事全体を表示
S32K388 TCP/IP 协议栈 5.0.0 无法正常工作 嗨@PavelL , 我之前使用以下配置成功运行了 TCP/IP 协议栈示例项目: • S32KDS 版本 3.6.5 • RTD(实时驱动程序)版本 7.0.0 • TCP/IP协议栈版本4.0.0 但是,升级到以下版本并执行相同的设置步骤后,却无法正常工作: • S32KDS 版本 3.6.8 • RTD(实时驱动程序)版本 7.0.1 • TCP/IP协议栈版本5.0.0 我已附上我的项目。再次感谢你的帮助。 Re: S32K388 TCP/IP stack 5.0.0 not working 你好@James_Zhang_SE , 我需要时间进行调查。我会尽力在本周内回复。 感谢您的理解。 顺祝商祺! 帕维尔 Re: S32K388 TCP/IP stack 5.0.0 not working 你好@James_Zhang_SE , 由于工作繁忙,回复有所延迟,敬请谅解。 根本原因是 EthIf_Cfg.c正如我们之前在这个帖子中讨论过的,S32K388 TCP/IP 堆栈 4.0.0 在编译时缺少 lwip 文件夹 该示例现在在我的 S32K388EVB-Q289 上运行正常。 总之,我对你的项目做了很多修改,但最关键的是 EthIf_Cfg 文件。所有修改后的文件都可以在附件的压缩包中找到。您可以自行查看更改。 请注意,所提供的代码不提供任何担保。 用补丁替换文件后,请不要忘记执行代码更新。 顺祝商祺! 帕维尔 Re: S32K388 TCP/IP stack 5.0.0 not working 你好,帕维尔, 非常感谢您的帮助!按照之前的步骤操作后,我能够 ping 通并测试 TCP 回环地址。我有几个问题想问一下: 对于 Ethif 配置修复和 RTD 变通方案,它们是否会在驱动程序和示例项目的未来版本中添加? 由于我对这个技术栈不太熟悉。当出现故障时,您是否有系统性的调试方法建议? Re: S32K388 TCP/IP stack 5.0.0 not working 你好@James_Zhang_SE , 感谢您分享您的最新情况。   如果我之前的帖子帮助您解决了问题,请将其标记为解决方案,因为这可能会帮助其他遇到类似问题的用户。   关于第一点:   我已经将 EthIf_Cfg 问题报告给了相关的软件团队。修复程序的发布日期尚未确定。目前内部仍在讨论 RTD 变通方案应该在何处实施,是在 MAC 驱动程序中还是在时钟配置区域中。目前,我们只能接受现状,并手动应用变通方案。   关于第二点:   我通常的调试流程是检查引脚配置、时钟配置、中断配置、FIFO 大小以及所需的 RTD 变通代码。gPTP 示例也是一个很好的参考,因为它们提供了可用于比较的功能性以太网相关配置。 顺祝商祺! 帕维尔
記事全体を表示
S32K388 TCP/IPスタック5.0.0が動作しません こんにちは、 @PavelL さん。 以前は、以下の設定でTCP/IPスタックのサンプルプロジェクトを実行することができました。 • S32KDS バージョン 3.6.5 • RTD(リアルタイム・ドライバ)バージョン7.0.0 • TCP/IPスタック バージョン 4.0.0 しかし、以下のバージョンにアップグレードして同じセットアップ手順を実行したところ、動作しなくなりました。 • S32KDS バージョン 3.6.8 • RTD (リアルタイム・ドライバ) version 7.0.1 • TCP/IPスタック バージョン 5.0.0 プロジェクトを添付しました。改めてご協力ありがとうございました。 Re: S32K388 TCP/IP stack 5.0.0 not working こんにちは、 @James_Zhang_SE さん、 調査に時間が必要です。今週中に返信できるよう最善を尽くします。 ご理解いただきありがとうございます。 よろしくお願いいたします。 パベル Re: S32K388 TCP/IP stack 5.0.0 not working こんにちは、 @James_Zhang_SE さん、 業務量が多く返信が遅れてしまい、申し訳ございません。 根本原因はEthIf_Cfg.cです。、このThreadですでに議論したように、tcpip stack 4.0.0 S32K388コンパイル中に lwip フォルダが欠けています このサンプルは、私のS32K388EVB-Q289で現在正常に動作しています。 とにかく、あなたのプロジェクトに多くの変更を加えましたが、最も重要なのは EthIf_Cfg ファイルです。すべての修正ファイルは添付のzipファイルで見つけることができます。変更内容はご自身で確認していただいても構いません。 提供されたコードには一切保証が付いておらず、保証もございませんのでご注意ください。 パッチでファイルを置き換えた後は、必ずコードの更新を行ってください。 よろしくお願いいたします。 パベル Re: S32K388 TCP/IP stack 5.0.0 not working こんにちは、パベルさん。 ご助力ありがとうございます!以前と同じ手順を適用した後、pingを実行してTCPループバックをテストすることができました。いくつか簡単な質問があります。 Ethif Configの修正やRTDの回避策については、FUTUREのドライバやサンプルプロジェクトのリリースで追加されるのでしょうか? [[ ## completed ##]] 私はこのスタックにあまり詳しくないので。何かがうまく動作しない場合、体系的なデバッグ方法を提案していただけますか? Re: S32K388 TCP/IP stack 5.0.0 not working こんにちは、 @James_Zhang_SE さん、 現在の状況をお知らせいただきありがとうございます。   もし前回の投稿が問題解決の助けになったなら、解決策としてマークしてください。同じような問題に直面している他のユーザーの助けになるかもしれません。   1点目について:   EthIf_Cfg問題を担当ソフトウェアチームに報告しました。修正プログラムのリリース日はまだ未定です。RTDの回避策をMACドライバーかクロック設定領域で実装すべきかについては、社内でまだ議論が続いています。今のところは現状を受け入れ、手動で回避策を適用する必要があります。   2点目について:   私の通常のデバッグ手順は、ピン構成、クロック構成、割り込み構成、FIFOサイズ、および必要なRTD回避コードを確認することです。gPTPの例も非常に参考になります。なぜなら、比較に利用できる機能的なイーサネット関連構成を提供しているからです。 よろしくお願いいたします。 パベル
記事全体を表示
I want to use flexio to work as a special spi, 20bit mosi output at the same time 20 chip dac need  to be controled  at the same time , I want to use flexio  to work as special spi,  to control the dac device. deltails as below: one  cs , one clk,  20 mosi,   use 20 pins,  to  output dac values to  20 dac devices at the  same time , can you give the  mcuexpross code  and project ? thanks! 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time Is  the  question two hard  lead to  there is nobody  can give  any suggestions  ? 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 1、 cs pull low level 2、flexio transmit 20 channel mosi evrytime, every channel transmit one bit,  one transmit use one shift register, 3、transmit 8 times use all the 8 shift registers , and every channel transmit  8 bits。 4、step 2 、3 is one  dma  transmit.  use  3 times of dma to transmit 24bit  data every channel, because  the dac chipi is  24bits. 5、pull cs high。 can  this work ok? 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time is   there anybody ? Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time the  chip i use is mcxn947. 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time Hi @justdomyself  For a similar implementation, I recommend checking the FlexIO QSPI application note AN14175 and the FlexIO SPI DMA examples in the MCUXpresso SDK. The AN14175 example demonstrates how to use FlexIO timers and shifters to create custom serial interfaces, which is closer to your requirement of driving 20 DAC channels simultaneously with one clock and multiple data outputs. The FlexIO SPI DMA example is also useful for understanding the basic FlexIO timer, shifter, and DMA configuration. BR Harry 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time Where is the project code for AN14175 located? Where can I download it? 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time Hi @justdomyself  Search | NXP Semiconductors Please search AN14175 in the NXP official website. And you can click the Associated File: AN14175SW to download the software. BR Harry 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time An error occurred during import: An error occurred during compilation: An error occurred during debugging: When executing BOARD_PowerMode_OD, the debug function crashes immediately with the error shown in the image above. Could you provide a newer, working project? My software version: MCUXpresso IDE v25.6 [Build 136] [2025-06-27] 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time Hi @justdomyself  You can download the SDK version corresponding to AN14175. BR Harry
記事全体を表示
我想使用 Flexio 作为特殊的 SPI,同时输出 20 位 MOSI 信号。 需要同时控制 20 个芯片 DAC,我想使用 Flexio 作为特殊的 SPI 来控制这些 DAC 设备。如下所示: 一个 cs, 一声钟响, 使用 20 个 MOSI 板,通过 20 个引脚同时向 20 个 DAC 设备输出 DAC 值,请问可以提供 MCUEXPROS 代码和项目吗? 谢谢您! 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 这个问题太难了,是不是没人能给出任何建议? 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 1、cs拉低级别 2、每次传输20通道MOSI,每个通道传输一位,一次传输使用一个移位寄存器。 3、传输8次,使用全部8个移位寄存器,每个通道传输8位。 4、步骤 2、3 是一次 DMA 传输。使用 3 倍的 DMA 来传输每个通道的 24 位数据,因为 DAC 芯片是 24 位的。 5、拉高 cs。 这样可以吗? 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 有人在吗? Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time 我使用的芯片是mcxn947。 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 嗨@justdomyself 对于类似的实现,我建议查看 FlexIO QSPI 应用笔记 AN14175 和 MCUXpresso SDK 中的 FlexIO SPI DMA 示例。 AN14175 示例演示了如何使用 FlexIO 定时器和移位器创建自定义串行接口,这更接近于您使用一个时钟和多个数据输出同时驱动 20 个 DAC 通道的要求。 FlexIO SPI DMA 示例对于理解 FlexIO 定时器、移位器和 DMA 的基本配置也很有用。 BR 哈里 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time AN14175    对应的工程代码在哪个位置?从哪下载? 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 导入的时候报错: 编译的时候报错: debug 的时候报错: 执行 BOARD_PowerMode_OD   。debug直接崩溃报上图错误。 能不能给个新一点的可以用的工程,  我的软件版本:MCUXpresso IDE v25.6 [Build 136] [2025-06-27] 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 嗨@justdomyself 搜索 | 恩智浦半导体 请在NXP官方网站上搜索AN14175。 您可以点击关联文件:AN14175SW 下载该软件。 BR 哈里 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 嗨@justdomyself 您可以下载与 AN14175 对应的 SDK 版本。 BR 哈里
記事全体を表示
T Embed 使用的是哪种接口? 我有一台标准的 T 型嵌入式开发板,但我不知道它用的是哪种接口(不是 USB-C 接口),因为官方网站说它是 Grove 接口,而 Lilygo Wiki 网站说它是 Qwiic 接口。请问有人可以帮帮我吗? Re: What kind of port does the T Embed have? 你好, 由于该设备并非 NXP 产品,我建议您直接联系 Lilygo 支持部门,提供元器件零件编号,您可以与他们一起查看引脚图或物料清单。 顺祝商祺!
記事全体を表示
What kind of port does the T Embed have? I have the standard model T Embed, but i have no Idea what kind of port it has (the other port, not usb c), because the official site says its a grove port, the lilygo Wiki site says its a qwiic port. Can anyone help me please? Re: What kind of port does the T Embed have? Hello, Since the device is not an NXP product, I would recommend you contact directly the Lilygo support to share the component part number, you could check the pin diagram or BOM with the page and them. Best Regards
記事全体を表示
Flexioを特殊なSPIとして、同時に20ビットMOSI出力として動作させたい。 20個のチップDACを同時に制御する必要があるため、Flexioを特別なSPIとして使用してDACデバイスを制御したいと考えています。詳細は以下の通りです。 1つのcs、 1クリック、 20 MOSI、20ピンを使って、同時に20台のDACデバイスにDAC値を出力します。MCUEctrossのコードとプロジェクトを教えてもらえますか? ありがとうございます! 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time この質問は難しいもので、誰も提案できないのでしょうか? 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 1、csプル低レベル 2、フレキシオは20チャネルを常に送信し、各チャネルは1ビットを送信し、1回送信は1シフトレジスタを使用します。 3、送信8回 8つのシフトレジスタすべてを使い、各チャンネルは8ビットを送信します。 4、ステップ2、3は1回のDMA送信です。DACのchipiは24ビットなので、各チャネルで24ビットデータを3回送信します。 5.CSを高く引く。 これでうまくいくのでしょうか? 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time 誰かいますか? Re: I want to use flexio to work as a special spi, 20bit mosi output at the same time 私が使用しているチップはmcxn947です。 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time こんにちは、 @justdomyself 同様の実装としては、FlexIO QSPIのアプリケーションノートAN14175とMCUXpresso SDK内のFlexIO SPI DMA例を確認することをお勧めします。 AN14175例はFlexIOタイマーとシフターを使ってカスタムシリアルインターフェースを作成する方法を示しており、1クロックと複数のデータ出力で20のDACチャネルを同時に駆動するというあなたのニーズにより近いものです。 FlexIO SPI DMAのサンプルは、FlexIOの基本的なタイマー、シフター、およびDMA構成を理解する上でも役立ちます。 BR ハリー 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time AN14175のプロジェクトコードはどこにありますか?どこからダウンロードできますか? 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time インポート中にエラーが発生しました。 コンパイル中にエラーが発生しました。 デバッグ中にエラーが発生しました。 BOARD_PowerMode_ODを実行すると、デバッグ関数が上記の画像に示すエラーで即座にクラッシュします。 より新しい、動作するプロジェクトを提供していただけますか? 私のソフトウェアバージョン:MCUXpresso IDE v25.6 [ビルド 136] [2025-06-27] 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time こんにちは、 @justdomyself 検索 |NXP Semiconductors NXP公式ウェブサイトでAN14175を検索してください。 そして、関連ファイル:AN14175SWをクリックするとソフトウェアをダウンロードできます。 BR ハリー 回复: I want to use flexio to work as a special spi, 20bit mosi output at the same time こんにちは、 @justdomyself AN14175対応のSDKバージョンをダウンロードできます。 BR ハリー
記事全体を表示
MPLS内部IP上のDPAA2 DPDK RSSハッシュ こんにちは、 SolidRun LX2160A Clearfog CXでDPDKを使ってDPAA2のRSS機能をテストしています。 例えばMPLSラベルやPPPoEの内部IPでハッシュ化できることがわかりました。 しかし、MPLS内部IPアドレスに対してハッシュ化できないようですが、私の理解は正しいでしょうか? これは少し驚きました。なぜなら: - MPLSヘッダーが何かを知っているのは、MPLSラベル上でハッシュ化できるからです - PPPoEの内側IPをハッシュ化できるため、内部IPを取得する方法を知っています MPLSの内部IPでハッシュ化がサポートされているかどうか確認してもらえますか? 私はNXP DPAA2やNXP全般についてかなり初心者なので、技術的な言葉を教えてもらえますか? ありがとうございます。 Re: DPAA2 DPDK RSS Hash on MPLS Inner IP はい — あなたの理解は、今日testpmdで使われているDPDK DPAA2 PMDに関して正しいです。MPLSラベル自体でのハッシュ処理はサポートされており、PPPoE後の内側IPでのハッシュも動作しますが、MPLSの内側IP RSSはすぐに使えるDPDK RSSモードとして明確に公開されていません。 重要なニュアンスは次のとおりです。 DPAA2ハードウェアは十分に対応可能です。LX2160AパーサーはMPLSを認識し、MPLSラベルスタックを通り抜け、特定の条件下でIPv4/IPv6へと解析を続けることができます。 DPAA2鍵抽出には「内側/最終IP」フィールドもあります。分配鍵機構ではHDR_INDEX = 0xFF 、つまり「最も内側/最後のヘッダー」を用い、ハードウェアは最後のIPヘッダーに対してIPSRC_N / IPDST_Nを定義します。 しかし、公開されたDPDK DPAA2 PMDドキュメントでは、RSSが一般的にサポートされているとのみ記載されており、固定RSSキーや設定不可のRETAなどの制限が記載されています。サポートされているRSSの組み合わせではありません。Linux/SDK向けのハッシュドキュメントには、イーサネット宛先、VLAN、L3プロトコル、IPv4の送信元/送信先、L4ポートなどの通常のフィールドが記載されていますが、「MPLS後のIP」は選択可能なハッシュモードとして記載されていません。 つまり、シリコンの制限ではなく、あなたが使っているDPDK DPAA2 PMDパスのソフトウェアやドライバー露出制限が原因だと思います。   試せることは まず、DPAA2がパケットを「MPLS + 内部IP」として認識していることを確認してください。 ハードウェアパーサーが内部のIPv4ヘッダーを存在としてマークしない場合、内部IP上のRSSは動作しません。 DPDKで、DPAA2 PMDログを有効にします。 コピー --log-level=pmd.net.dpaa2:debug また、受信パケットがアプリケーション内やtestpmdで意味のあるパケットタイプ情報を得られるかどうかも確認してください。例えば、パケットがMPLSのみに分類されているのか、MPLSと内なるIPv4として分類されているのかなどです。 パケットタイプがMPLSで終了すると、ドライバの観点からは内部IPv4が解析されていないため、RSSハッシュは内部IPv4を使用できません。 フローパターンを明確にしてみてください RSSタイプをmplsのみに設定した場合、MPLSフィールドは自動的にハッシュ化されます。内部IPv4ヘッダーを明示的に含むパターンを試してください。 コピー フロー作成 0 イングレス \ パターン eth / mpls / ipv4 / end \ アクション RSS キュー 0 1 終了 タイプ IPv4 終了 / 終了 送信元/宛先IPアドレスを具体的に知りたい場合は、以下も試してみてください。 コピー フロー作成 0 イングレス \ パターン eth / mpls / ipv4 / end \ アクション RSS キュー 0 1 終了 タイプ IP IPv4 終了 / 終了 それが拒否または承認されたにもかかわらず、内部 IPv4 アドレスに基づいて配布されない場合は、PMD が DPAA2 配布キーを「最後の/内部 IP」としてプログラムしていない可能性があります。 パーサーを助けるMPLSラベル値を試してみてください MPLSトラフィックが通常のサービスラベルを使用している場合、パーサはペイロードがIPv4であることを認識しない可能性があります。制御テストとしては、MPLSの明示的NULLラベルを試してください: MPLSラベル0はIPv4明示的NULLを意味します。 MPLSラベル2はIPv6の明示的NULLを意味します。 DPAA2のドキュメントによると、MPLSラベル解釈が有効の場合、ラベル0はIPv4に、label2はIPv6にマッピングされます。 もし内側IP上のRSSがラベル0でのみ動作する場合、問題はRSS自体ではありません。問題は、パーサーがMPLSペイロードがIPであることを知らなかったことです。 この機能が必要な場合、本当の解決策はPMDの作業である可能性が高いです。 DPAA2ハードウェアには、これに必要な概念が備わっています。 HDR_INDEX = 0xFF は「最も内側のヘッダーを使用する」ことを意味します。 IPSRC_NとIPDST_Nは、最後のIPヘッダーの送信元/宛先アドレスです。 MPLSパーサーは適切に設定すればMPLSを超えてIPへと進むことができます。 したがって、ドライバーレベルの実装では、DPNIの配信プロファイルを以下のようにプログラムする必要があるでしょう: 内部/最後の IPv4 送信元アドレス、 内部/最後の IPv4 宛先アドレス、 おそらく内部L4ポート、 MPLS解析パスの後。 実際には、これは単にtestpmdコマンドを変更するだけでなく、DPAA2 DPDK PMDを変更する必要があるかもしれません。 私の結論として、DPAA2ハードウェアは原則として「内側/最終IP」フィールドに到達できますが、MPLS-inner-IP RSSはスタック上で既にサポートされているDPDK DPAA2 PMD機能ではないようです。もし明示的なeth / mpls / ipv4のRSSルールが失敗した場合、別のtestpmdコマンドではなくPMD/パーサー/配布プロファイルの変更が考えられます。
記事全体を表示
MPLS 内部 IP 上的 DPAA2 DPDK RSS 哈希 你好, 我正在使用 DPDK 在 SolidRun LX2160A Clearfog CX 上测试 DPAA2 RSS 功能。 我发现它能够对 MPLS 标签和 PPPoE 内部 IP 进行哈希处理。 但是它似乎无法对 MPLS 内部 IP 进行哈希运算,我的理解对吗? 这让我有点惊讶,因为: 它知道什么是 MPLS 报头,因为它能够对 MPLS 标签进行哈希运算。 它知道如何获取内部 IP 地址,因为它能够对 PPPoE 内部 IP 地址进行哈希处理。 请问是否支持对 MPLS 内部 IP 进行哈希处理? 我对 NXP DPAA2 和 NXP 产品都比较陌生,所以您能解释一下您使用的技术术语吗? 谢谢。 Re: DPAA2 DPDK RSS Hash on MPLS Inner IP 是的——您对目前 testpmd 使用的 DPDK DPAA2 PMD 的理解是正确的:支持对MPLS 标签本身进行哈希处理,并且PPPoE 之后对内部 IP进行哈希处理也可以工作,但是MPLS 内部 IP RSS 并没有明确地作为可直接使用的 DPDK RSS 模式公开。 关键的区别在于: DPAA2 硬件功能足够强大:LX2160A 解析器可以识别 MPLS,遍历 MPLS 标签栈,然后在某些条件下继续解析为 IPv4/IPv6。 DPAA2 密钥提取还有“内部/最后一个 IP”字段:分发密钥机制可以使用 HDR_INDEX = 0xFF,表示“最内部/最后一个报头”,硬件为最后一个 IP 报头定义了 IPSRC_N / IPDST_N。 但公开的 DPDK DPAA2 PMD 文档只说 RSS 一般上受支持,并列出了诸如固定 RSS 密钥和不可配置 RETA 之类的限制;它没有列出受支持的 RSS 组合。面向 Linux/SDK 的哈希文档列出了以太网目标、VLAN、L3 协议、IPv4 源/目标和 L4 端口等常规字段,但没有将“MPLS 后的 IP”列为可选的哈希模式。 所以:这不是硅芯片的限制,而是您正在使用的 DPDK DPAA2 PMD 路径中的软件/驱动程序暴露限制。   你可以尝试以下方法 首先确认 DPAA2 将数据包识别为“MPLS + 内部 IP”。 如果硬件解析器未将内部 IPv4 报头标记为存在,则内部 IP 上的 RSS 无法工作。 在DPDK中,启用DPAA2 PMD日志: 复制 --log-level=pmd.net.dpaa2:debug 此外,还要检查应用程序或 testpmd 是否能获取接收到的数据包类型信息,例如数据包是否仅被分类为 MPLS 或 MPLS 加内部 IPv4。 如果数据包类型止于 MPLS,则 RSS 哈希不能使用内部 IPv4,因为从驱动程序的角度来看,内部 IPv4 没有被解析。 尽量在流程模式中做到明确。 如果您只配置了 RSS 类型 mpls,那么自然会对 MPLS 字段进行哈希处理。尝试使用明确包含内部 IPv4 报头的模式: 复制 流创建 0 个入口 \ 模式 eth / mpls / ipv4 / 结束 \ 操作 RSS 队列 0 1 结束 类型 IPv4 结束 / 结束 如果您想要获取源/目标 IP 地址,也可以尝试: 复制 流创建 0 个入口 \ 模式 eth / mpls / ipv4 / 结束 \ 操作 RSS 队列 0 1 结束 类型 IP IPv4 结束 / 结束 如果拒绝或接受,但仍然不根据内部 IPv4 地址进行分发,则 PMD 可能没有将 DPAA2 分发密钥编程为“最后一个/内部 IP”。 尝试使用有助于解析的 MPLS 标签值 如果您的 MPLS 流量使用普通服务标签,解析器可能无法识别有效负载是 IPv4。为了进行受控测试,请尝试使用 MPLS 显式 NULL 标签: MPLS 标签 0 表示 IPv4 显式 NULL。 MPLS 标签 2 表示 IPv6 显式 NULL。 DPAA2 文档指出,启用 MPLS 标签解释时,标签 0 映射到 IPv4,标签 2 映射到 IPv6。 如果内部 IP 上的 RSS 仅对标签 0 有效,那么问题不在于 RSS 本身;问题在于解析器没有被告知您的 MPLS 有效负载是 IP。 如果你需要这个功能,真正的解决方案很可能是PMD作品。 DPAA2硬件具备实现这一目标所需的概念: HDR_INDEX = 0xFF 表示“使用最内层的标头”。 IPSRC_N 和 IPDST_N 是最后一个 IP 报头的源地址/目标地址。 如果配置得当,MPLS 解析器可以超越 MPLS 解析器,扩展到 IP 解析器。 因此,驱动程序级别的实现可能需要对 DPNI 分发配置文件进行编程以提取: 内部/最后一个 IPv4 源地址 内部/最后一个 IPv4 目标地址 可能是内部L4端口, 在 MPLS 解析路径之后。 实际上:这可能需要更改 DPAA2 DPDK PMD ,而不仅仅是更改 testpmd 命令。 我的结论:DPAA2 硬件原则上可以访问“内部/最后一个 IP”字段,但 MPLS-inner-IP RSS 似乎不是您的堆栈上现成支持的 DPDK DPAA2 PMD 功能;如果显式的 eth / mpls / ipv4 RSS 规则失败,可能的解决方案是更改 PMD/解析器/分发配置文件,而不是不同的 testpmd 命令。
記事全体を表示
DPAA2 DPDK RSS Hash on MPLS Inner IP Hello, I'm testing DPAA2 RSS capabilities with DPDK on a SolidRun LX2160A Clearfog CX. I've found that it is able to hash on MPLS labels and PPPoE inner IP for example. However it seems to not be able to hash on MPLS inner IP, am I right on this ? This surprise me a bit because: - It know what is a MPLS header because it is able to hash on MPLS labels - It know how to get inner IP because it is able to hash on PPPoE inner IP Could you confirm if it is supported or not to hash on MPLS inner IP ? I'm quite newbie with NXP DPAA2 and NXP in general, so can you please explain your technical words. Thanks. Re: DPAA2 DPDK RSS Hash on MPLS Inner IP Yes — your understanding is correct for the DPDK DPAA2 PMD as used from testpmd today : hashing on the MPLS label itself is supported, and hashing on inner IP after PPPoE can work, but MPLS inner IP RSS is not clearly exposed as a ready-to-use DPDK RSS mode . The important nuance is this: DPAA2 hardware is capable enough : the LX2160A parser can recognize MPLS, walk through an MPLS label stack, and then continue parsing to IPv4/IPv6 under some conditions. DPAA2 key extraction also has “inner/last IP” fields : the distribution key mechanism can use HDR_INDEX = 0xFF , meaning “most inner / last header,” and the hardware defines IPSRC_N / IPDST_N for the last IP header. But the public DPDK DPAA2 PMD documentation only says RSS is supported in general , and lists limitations like fixed RSS key and non-configurable RETA; it does notas a supported RSS combination. The Linux/SDK-facing hashing documentation lists ordinary fields such as Ethernet destination, VLAN, L3 protocol, IPv4 source/destination, and L4 ports, but not “IP after MPLS” as a selectable hash mode. So: not a silicon limitation, but likely a software/driver exposure limitation in the DPDK DPAA2 PMD path you are using.   What you can try First confirm that DPAA2 sees the packet as “MPLS + inner IP” If the hardware parser does not mark the inner IPv4 header as present, RSS on inner IP cannot work. In DPDK, enable DPAA2 PMD logs: Copy --log-level=pmd.net.dpaa2:debug Also check whether received packets get meaningful packet type information in your application or with testpmd , for example whether packets are classified only as MPLS or as MPLS plus inner IPv4. If the packet type stops at MPLS, the RSS hash cannot use inner IPv4 because, from the driver’s point of view, inner IPv4 was not parsed. Try being explicit in the flow pattern If you only configured RSS type mpls , that will naturally hash MPLS fields. Try a pattern that explicitly includes the inner IPv4 header: Copy flow create 0 ingress \   pattern eth / mpls / ipv4 / end \   actions rss queues 0 1 end types ipv4 end / end If you want source/destination IP specifically, also try: Copy flow create 0 ingress \   pattern eth / mpls / ipv4 / end \   actions rss queues 0 1 end types ip ipv4 end / end If that is rejected or accepted but still does not distribute based on the inner IPv4 addresses, then the PMD is probably not programming the DPAA2 distribution key as “last/inner IP.” Try MPLS label values that help the parser If your MPLS traffic uses ordinary service labels, the parser may not know the payload is IPv4. For a controlled test, try MPLS Explicit NULL labels: MPLS label 0 means IPv4 Explicit NULL. MPLS label 2 means IPv6 Explicit NULL. The DPAA2 documentation says label 0 maps to IPv4 and label 2 maps to IPv6 when MPLS label interpretation is enabled . If RSS on inner IP works only with label 0 , then the problem is not RSS itself; the issue is that the parser was not being told that your MPLS payload is IP. If you need this feature, the real fix is likely PMD work The DPAA2 hardware has the concepts needed for this: HDR_INDEX = 0xFF means “use the most inner header”. IPSRC_N and IPDST_N are the source/destination address of the last IP header. The MPLS parser can advance beyond MPLS to IP when configured appropriately. So a driver-level implementation would likely need to program the DPNI distribution profile to extract: inner/last IPv4 source address, inner/last IPv4 destination address, possibly inner L4 ports, after an MPLS parse path. In practical terms: this may require changing the DPAA2 DPDK PMD , not just changing a testpmd command. My conclusion: DPAA2 hardware can in principle reach “inner/last IP” fields, but MPLS-inner-IP RSS does not appear to be a ready-supported DPDK DPAA2 PMD feature on your stack; if explicit eth / mpls / ipv4 RSS rules fail, the likely solution is a PMD/parser/distribution-profile change rather than a different testpmd command.
記事全体を表示
MRF13750H 输入匹配设计仿真 您好! 我正在尝试使用 Usimmics 模拟 MRF13750H-915MHz 参考电路板的输入匹配网络(我没有 ADS 或 AWR)。 我使用了与 NXP 数据手册中相同的宽度和长度的走线,但结果与 915MHz 不符。有人知道我哪里做错了吗? 最好的, 路易斯·维拉纽瓦 射频 Re: MRF13750H Input Matching Design Simulation 谢谢你提供的信息! Re: MRF13750H Input Matching Design Simulation 你好 Luis_V 再会! 很遗憾,我没有使用过你正在使用的模拟器,所以无法进行全面比较,但就我所见,我可以告诉你以下几点: 在 ADS/AWR 中,原始布局包括: T型不连续点, 斜接弯头, 开放式效果, 耦合效应。 您的原理图使用了直接连接的理想 MLIN 段。 此外,我了解到 AWR 仿真“考虑”了封装中可能存在的寄生效应。 希望这些信息对您有所帮助,如果您还需要其他帮助,请告诉我。 祝你今天过得愉快,一切顺利。
記事全体を表示