PCF2131 MBF可靠性报告 我使用的是 PCF2131 RTC I2C 集成电路，我们需要它在 50C 温度条件下的可靠性报告和 MTBF 数据。 RTC Re: PCF2131 RELIABILITY REPORT FOR MTBF 您好， 为了获取所需的 FIT/MTBF 数据，请创建 标准票据。 谢谢您！ BRs, Tomas

S32DS3.6.2 build gPTP Example Code error 原来一直在S32DS3.5+RTD5..0.0开发，介于新的需求要开发gPTP相关功能，所以重新搭建新的开发环境： S32DS_3.6.2_RFP_win32.x86_64.exe SW32K3_S32M27x_RTD_R21-11_6.0.0_D2506_DesignStudio_updatesite.zip SW32K3_FreeRTOS_11.1.0_6.0.0_CD1_D2506_DesignStudio_updatesite.zip SW32K3xx_M7_gPTP_1.0.0_D2507_DesignStudio_updatesite.zip SW32K3_TCPIP_STACK_3.0.0_D2507_DesignStudio_updatesite.zip 搭建完成后创建S32K388_gptp_free_rtos_ds工程，更新code直接编译发现下面错误： 我的理解是不是环境搭建过程中是不是缺少插件的安装？ 实际同样的情况lwip_FreeRTOS_s32k388也出现： 但是对应的插件我都安装了，附件是S32K388_gptp_free_rtos_ds导出例程，刚开始搭建麻烦指点一下，谢谢！ Re: S32DS3.6.2 build gPTP Example Code error 你好，实际我不太关注这个错误，这些错误肯定可以修订，主要再S32DS3.5+RTD5.0.0直接导入IDE提供的标准例程没有出现编译出错问题，但是在S32DS3.6.2+RTD6.0.0同样的操作出现该现象，是不是插件安装不匹配导致，最担心是： 涉及的source code file都是SDK提供的，基本上不会修改，就是修改也是通过IDE界面配置修改，后面随着功能增加，会不断update Code，已经修改的文件再次覆盖，每次都需要修改一边，这样是不是不太方便！ Re: S32DS3.6.2 build gPTP Example Code error 你好@Ryan_xjl 我能够复制这个问题。要构建没有错误的项目，需要进行以下更改： FreeRTOSConfig.h Add the following definition: #define configKERNEL_PROVIDED_STATIC_MEMORY 1 port.c Add the declaration: void xPortSysTickHandler( void ) __attribute__( ( naked ) ); Vector_Table.s Change .globl vPortSVCHandler to .globl SVC_Handler Change .long vPortSVCHandler to .long SVC_Handler+1 BR、VaneB Re: S32DS3.6.2 build gPTP Example Code error 你好@Ryan_xjl 关于软件兼容性，您目前使用的版本应该可以正常运行，因为它们都依赖于 RTD 6.0.0 版本。 关于从 RTD 5.0.0 迁移到 RTD 6.0.0，以及从 S32DS 3.5 迁移到 S32DS 3.6.2、软件和集成开发环境都有了一些变化。因此，尽管整体功能在很大程度上仍然相似，但无法保证完全的后向兼容性。 最后，关于生成文件中的修改丢失，这是使用 ConfigTools 时的预期行为。每次应用新配置时，该工具都会重新生成文件并将其恢复到默认状态。直接在这些文件中进行的任何手动更改都不会被保留。因此，在使用生成的代码时，必须谨慎管理自定义修改。 Re: S32DS3.6.2 build gPTP Example Code error 非常感谢你如此耐心的帮助我解决困惑，可能是我表达的不够明白，或者我刚开始学习，方便明确表达我的意思，我提供了整个操作流程的视频，可以更好表达我的诉求，再次感谢你如此耐心的帮助我 PS：过程中有个现象，不知道是不是该情况导致 附件是操作流程视频 Re: S32DS3.6.2 build gPTP Example Code error 你好@Ryan_xjl 不用担心，语言的差异有时会造成误解，我非常感谢你分享了一段视频来说明这个问题。 打开 ConfigTools 时显示的窗口只是一个警告，表明创建项目时使用的工具版本比当前使用的版本旧。只有当您尝试打开.mex文件的原始（旧）版本。就您的情况而言，应该不会有任何问题。此外，从头开始创建项目时，也不会出现该警告。 最后，你在编译示例时遇到的版本错误可以通过应用我在第一个回复中提到的更改来解决。 我希望这有助于澄清您的问题。 Re: S32DS3.6.2 build gPTP Example Code error 你好@Ryan_xjl 我这边导入了 lwip_FreeRTOS_s32k388 示例，但似乎缺少了堆栈文件夹，这导致了错误。 解决方法是，您可以修改 tcpip_itm_manifest.xml 文件并将 S32K388 添加到三个设备列表中。例如，可以在以下位置找到该文件： C:\NXP\S32DS.3.6.4\S32DS\software\PlatformSDK_S32K3\tcpip_itm_manifest.xml 此外，请参阅S32K388 tcpip stack 4.0.0 在编译时丢失 lwip 文件夹的主题，该主题已讨论过这一问题。该主题还指出了一个示例项目，可能对您的情况有所帮助。 Re: S32DS3.6.2 build gPTP Example Code error 非常感谢，这个问题目前就按照当前的思路进行 附件的这个工程操作流程与gPTP工程一样，是否可以协助看看(发现stack没有生成)

VS Code拡張機能のアップデートによりRTOSビューアが壊れました こんにちは、 これまでは、vscode ツール バージョン 1.9.20 (旧バージョン) を使用しており、freertos スレッド (RT1189) の状態を確認するためにhttps://marketplace.visualstudio.com/items?itemName=mcu-debug.rtos-viewsを使用していました。アップデート後、ツールが動作しなくなり、「 RTOS検出が完了しませんでした。次回の停止時に再開されます。」と表示されるだけです。何か解決策はありますか？ よろしくお願いします。 Re: VS code extension update broke RTOS viewer こんにちは、 VS Code 用の MCUXpresso には、以前から独自の RTOS ビューアが搭載されています。https://mcuxpresso.nxp.com/mcux-vscode/latest//html/RTOS-Details.htmlをご確認ください。 また、以前の変更点として、拡張機能がMicrosoft C/C++デバッグアダプタからCortex-Debugに基づく独自のデバッグアダプタに移行しました。そのため、新しいデバッグ構成を作成する必要があります。これにより、当社のデバッグアダプタに基づく構成が自動的に作成されます（タイプとして「mcuxpresso-debug」が表示されます）。 追記：Seggerデバッグプローブを使用している場合は、RTOSの**サポート**を有効にするために特別な**イネーブルメント**が必要になりますのでご注意ください（ https://mcuxpresso.nxp.com/mcux-vscode/latest//html/Debug-Views.html#enabling-rtos-awarenessを参照）。 よろしくお願いいたします。 クリスティアン Re: VS code extension update broke RTOS viewer はい、解決しました。デバッグモードで-Ogフラグを付けてコンパイルしていたのですが、それを-O0に変更したらビューアが動作するようになりました。しかし、Ogが標準的な編集・デバッグプロセスのデフォルトとなるべきなので、このツールには改善が必要だと思います。 これとは関係ないのですが、デバッグコンソールにもこの警告が表示されます。 「警告: ' \Main.cpp' をホストエンコーディング (CP1252) から UTF-32 に変換できませんでした。」 通常はこのようなことは起こらないはずです。バグ報告を提出してください。 よろしくお願いします。 Re: VS code extension update broke RTOS viewer ありがとうございます 実際には、このメッセージはMCUXpresso RTOSビュー自体から発信されています（私は別のプラグインを誤って参照していました）。 launch.json とカスタムデバイススクリプトを添付しました (Linkserver 26.3.123 の MIMXRT1180-EVK.json と同じです)。しかし、「接続スクリプト」は「RT1180_reset.scp」です。 当社のアプリはハイパーラム上で動作し、SDK 2.16を使用しています。Freertosの変数は正しく設定されています。 アプリのステップデバッグはできますが、RTOSの詳細ビューには依然として「 RTOS検出が完了しませんでした。次の停止時に再開されます。」と表示されます。 よろしくお願いします。 Re: VS code extension update broke RTOS viewer @cristiantepusこの件について何か進展はありますか？ Re: VS code extension update broke RTOS viewer 今日、MCUXpresso RTOSビューアがリリースモードでは動作せず、何も表示されないことに気づきました。 しかし、 https://marketplace.visualstudio.com/items?itemName =mcu-debug.rtos-views -Og およびリリースモードでは動作しますが、現在の mcuxpresso vscode プラグインでは動作しません (無効になります)。それを元に戻す方法はありますか？ Re: VS code extension update broke RTOS viewer こんにちは、 @arunkumar_g さん。 弊社が提供するRTOS詳細ビューは、ELFファイル内にいくつかのシンボルが存在することを前提としています（例：「 FreeRTOSDebugConfig」、「 pxCurrentTCB」、「 uxCurrentNumberOfTasks」など多数あります。「 RTOS検出が完了しませんでした。次の停止時に再開されます。」というメッセージでは何が問題だったのかが分からないという点には同意します。この点をより明確にするよう努めます。 「デバッグ」と「リリース」で得られた結果についてですが、これはコンパイラ/リンカの最適化の結果だと考えられます。必要なシンボルが削除されているため、利用者はそれらを見つけることができません。この場合、RTOSの詳細ビューが機能しないだけでなく、低レベルのGDB Thread認識（LinkServer、J-Link、PEmicro）でも、コールスタックビューでFreeRTOSタスクを表示およびデバッグできなくなります。この場合、デバッグモードとリリースモードの両方で必要なシンボルが存在するようにコードを更新することをお勧めするしかありません。ドキュメントとツールからの情報を更新し、必要な記号が不足しているためにビューにデータが表示されないことを明確にします。 また、このケースではMCUデバッグRTOSビューが動作しているとおっしゃっていましたが、そうかもしれません。しかし、私が最後に確認した時点では、バージョン管理（バージョンは「 FreeRTOSDebugConfig」を調べることで確認できます）は一切サポートされていませんでした。また、FreeRTOSのデータ構造はRTOSのバージョンに固有のものであることにもご注意ください。MCUデバッグビューを有効にするには、サポート対象リストに「mcuxpresso-debug」デバッグアダプタ（MCUXpresso固有）を追加する方法をメンテナーに問い合わせてください。 古いSDK 2.16をベースにしたプロジェクトを使用しているとのことですので、CMakeとKconfigをベースにした最新のMCUXpresso SDKに切り替えることをお勧めします。   いくつかの便利なリンク： - RTOSの詳細： RTOSの詳細 — MCUXpresso for VS Code 26.04ドキュメント - MCUXpresso SDK: MCUXpresso SDK ドキュメント — MCUXpresso SDK ドキュメント   ありがとうございます エイドリアン

USBハブの複数デバイス接続に関する問題 私はプロジェクト開発において、i.MX RT1060コントローラーを使用しています。複数のデバイス（MSD - ペン ドライブ、CDC - プリンター）を以下の順序で接続すると、USBハブの機能に問題が発生します。 Case 1 A) プリンター：添付イベント情報が発生し、正常に動作しています B) フラッシュドライブ： フラッシュドライブのアタッチイベントは発生しません。 フラッシュドライブを取り外すと、システムはUSB_HostReleaseDeviceResource内でハングアップします。 CASE 2 A) フラッシュドライブ：コネクテッドで正常に動作しています B) プリンター: アタッチイベントが発生しましたが、インターフェースが完全に完了していません。ポートオープンイベントのコールバックでエラーが発生しました。 フラッシュドライブを取り外すと、両方のデバイスの接続が切断されました。 CASE 3 フラッシュドライブとプリンターの両方が挿入されました：フラッシュドライブの接続イベントのみが発生し、正常に動作しています。 フラッシュドライブを取り外して再度接続すると、正常に動作します。 CDCデバイスの接続/切断ではイベントは発生しません。 CDCの機能を復旧させる唯一の方法は、システムを再起動することです。 調査結果： ハブをPCに接続して機能を確認すると、デバイスマネージャーに両方のデバイスが表示されます。このことから、問題はi.MX RT1060のUSBドライバの実装/USBの複合デバイス処理にあると結論付けます。 MSDデバイスとCDCデバイスの両方をハブ経由で確実に列挙および管理できるように、この問題を解決する方法はありますか？ よろしくお願いいたします。 パヴァン #IMXRT1060 #nxp #マイクロコントローラ #USBハブ #USB複合デバイスの処理。 USB Re: USB hub multiple devices connection issue 上記について何かご提案はありますか？ Re: USB hub multiple devices connection issue こんにちは、 @Gangapavan さん。 使用しているSDKのバージョンは何ですか？弊社のSDKに含まれているUSB関連のサンプルを基にプロジェクトを進めていますか？あなたのアプリケーションでは、MSDとCDCのためのUSB機能をどのように実装しましたか？ 標準のUSBハブ操作を管理するために、弊社が提供する「usb」>「host」>「class」フォルダ内のUSBホストハブドライバを実装していますか？ BR、 エドウィン。 Re: USB hub multiple devices connection issue こんにちは、@EdwinHzさん ご返信ありがとうございます。 私たちはSDKバージョン2.13.0を使用しています。私たちはSDKのサンプルをベースにしてアプリケーションを開発しました。 はい、上記で指定した場所にあるハブファイルも使用しています。 プロジェクトが本番稼働段階にあるため、この問題の迅速な解決が必要です。必要であれば、メールまたはご希望の方法でファイルを共有いたします。 ありがとうございます。 Re: USB hub multiple devices connection issue こんにちは、@EdwinHzさん 上記について何かご提案はありますか？

MIMXRT1180-EVK LittleFS サンプルは、DCache が無効になっていない限り、外部フラッシュで失敗します。 こんにちは、 Zephyr LittleFS サンプル ( https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/fs/littlefs ) を実行しようとしています。CM33コアを使用して外部フラッシュ（W25Q128JWSIQ）に書き込んでいますが、問題が発生しています。 サンプルをデフォルト設定で実行しようとすると、約90%の確率で失敗します。フラッシュメモリを消去してファイルシステムを再構築するオプションをオンにすると、ほぼ毎回失敗するようです。 失敗するタイミングは様々ですが、ログは通常次のような内容になります。 ネタバレ （ハイライトして読む） *** Zephyr OSビルドv4.3.0-6239-g28cd602a81eaを起動しています*** littlefs上のファイルを読み書きするためのサンプルプログラム w25q128jw@0 の 0xe20000 にある領域 3、1966080 バイト [00:00:00.022,000] main: フラッシュ領域を消去しています... 0 [00:00:00.028,000] littlefs: LittleFS バージョン 2.11、ディスクバージョン 2.1 [00:00:00.037,000] littlefs: w25q128jw@0:0xe20000 の FS は 480 個の 0x1000 バイトのブロックで、512 サイクルです [00:00:00.047,000] littlefs: パーティションサイズ: rd 16 ; pr 16 ; ca 64 ; la 32 [00:00:00.055,000] littlefs: WEST_TOPDIR/modules/fs/littlefs/lfs.c:1386:{0x0, 0x1} のディレクトリペアが破損しています [00:00:00.066,000] littlefs: マウントできません (LFS -84); フォーマット[00:00:00.118,000] littlefs: /lfs がマウントされました /lfs マウント: 0 /lfs: bsize = 16 ; frsize = 4096 ; blocks = 480 ; bfree = 478 ディレクトリ /lfs を一覧表示しています... [00:00:00.150,000] littlefs: WEST_TOPDIR/modules/fs/littlefs/lfs.c:2109:スーパーブロック0x0は書き込み不能になりました [00:00:00.161,000] fs: ファイルオープンエラー (-5) [00:00:00.167,000] main: 失敗: /lfs/boot_count を開けません: -5 [00:00:00.174,000] littlefs: /lfs がマウントされていません /lfs アンマウント: 0 *** Zephyr OSビルドv4.3.0-6239-g28cd602a81eaを起動しています***w25q128jw@0 の littlefsArea 3 の 0xe20000 にある 1966080 バイトのファイルを読み書きするサンプル プログラム[00:00:00.022,000] main: フラッシュ領域を消去しています... 0[00:00:00.028,000] littlefs: LittleFS バージョン 2.11、ディスク バージョン 2.1[00:00:00.037,000] littlefs: w25q128jw@0:0xe20000 の FS は 480 個の 0x1000 バイトのブロックで構成され、512 サイクル[00:00:00.047,000] があります。 littlefs: パーティションサイズ: rd 16 ; pr 16 ; ca 64 ; la 32[00:00:00.055,000] littlefs: WEST_TOPDIR/modules/fs/littlefs/lfs.c:1386:{0x0, 0x1}[00:00:00.066,000] でディレクトリペアが破損しています littlefs: マウントできません (LFS -84); フォーマット中[00:00:00.118,000] littlefs: /lfs マウント済み/lfs マウント: 0/lfs: bsize = 16 ; frsize = 4096 ; blocks = 480 ; bfree = 478ディレクトリ /lfs を一覧表示中...[00:00:00.150,000] littlefs: WEST_TOPDIR/modules/fs/littlefs/lfs.c:2109:スーパーブロック 0x0 が書き込み不能になりました[00:00:00.161,000] fs: ファイルオープンエラー (-5)[00:00:00.167,000] main: 失敗: /lfs/boot_count を開けません: -5[00:00:00.174,000] littlefs: /lfs アンマウント /lfs アンマウント: 0 ある時点で「スーパーブロック0x0が書き込み不能になりました」というエラーが発生し、サンプルが失敗します。 Kconfigオプション「CONFIG_DCACHE=n」でDCacheを無効にするとサンプルが確実に動作することがわかったので、これはキャッシュの問題だと考えています。 ネタバレ （ハイライトして読む） *** Zephyr OSビルドv4.3.0-6239-g28cd602a81eaを起動しています*** littlefs上のファイルを読み書きするためのサンプルプログラム w25q128jw@0 の 0xe20000 にある領域 3、1966080 バイト [00:00:00.060,000] main: フラッシュ領域を消去しています... 0 [00:00:00.069,000] littlefs: LittleFS バージョン 2.11、ディスクバージョン 2.1 [00:00:00.127,000] littlefs: w25q128jw@0:0xe20000 の FS は 480 個の 0x1000 バイトのブロックで、512 サイクルです [00:00:00.139,000] littlefs: パーティションサイズ: rd 16 ; pr 16 ; ca 64 ; la 32 [00:00:00.151,000] littlefs: WEST_TOPDIR/modules/fs/littlefs/lfs.c:1386:{0x0, 0x1} のディレクトリペアが破損しています [00:00:00.164,000] littlefs: マウントできません (LFS -84); フォーマット[00:00:00.235,000] littlefs: /lfs がマウントされました /lfs マウント: 0 /lfs: bsize = 16 ; frsize = 4096 ; blocks = 480 ; bfree = 478 ディレクトリ /lfs を一覧表示しています... /lfs/boot_count 読み取り回数:0 (バイト数: 0) /lfs/boot_count に新しいブートカウント 1 を書き込みます: [wr:1] [00:00:00.297,000] main: テストファイル: /lfs/pattern.bin が見つかりません。作成してください。 ------ ファイル: /lfs/pattern.bin ------ 01 55 55 55 55 55 55 55 02 55 55 55 55 55 55 55 03 55 55 55 55 55 55 55 04 55 55 55 55 55 55 55 05 55 55 55 55 55 55 55 06 55 55 55 55 55 55 55 07 55 55 55 55 55 55 55 08 55 55 55 55 55 55 55 09 55 55 55 55 55 55 55 0a 55 55 55 55 55 55 55 0b 55 55 55 55 55 55 55 0c 55 55 55 55 55 55 55 0d 55 55 55 55 55 55 55 0e 55 55 55 55 55 55 55 0/55 55 55 55 55 55 55 10 55 55 55 55 55 55 55 11 55 55 55 55 55 55 55 12 55 55 55 55 55 55 55 13 55 55 55 55 55 55 55 14 55 55 55 55 55 55 55 15 55 55 55 55 55 55 55 16 55 55 55 55 55 55 55 17 55 55 55 55 55 55 55 18 55 55 55 55 55 55 55 19 55 55 55 55 55 55 55 1a 55 55 55 55 55 55 55 1b 55 55 55 55 55 55 55 1c 55 55 55 55 55 55 55 1d 55 55 55 55 55 55 55 1e 55 55 55 55 55 55 55 1f 55 55 55 55 55 55 55 20 55 55 55 55 55 55 55 21 55 55 55 55 55 55 55 22 55 55 55 55 55 55 55 23 55 55 55 55 55 55 55 24 55 55 55 55 55 55 55 25 55 55 55 55 55 55 55 26 55 55 55 55 55 55 55 27 55 55 55 55 55 55 55 28 55 55 55 55 55 55 55 29 55 55 55 55 55 55 55 2a 55 55 55 55 55 55 55 2b 55 55 55 55 55 55 55 2c 55 55 55 55 55 55 55 2d 55 55 55 55 55 55 55 2e 55 55 55 55 55 55 55 2f 55 55 55 55 55 55 55 30 55 55 55 55 55 55 55 31 55 55 55 55 55 55 55 32 55 55 55 55 55 55 55 33 55 55 55 55 55 55 55 34 55 55 55 55 55 55 55 35 55 55 55 55 55 55 55 36 55 55 55 55 55 55 55 37 55 55 55 55 55 55 55 38 55 55 55 55 55 55 55 39 55 55 55 55 55 55 55 3a 55 55 55 55 55 55 55 3b 55 55 55 55 55 55 55 3c 55 55 55 55 55 55 55 3d 55 55 55 55 55 55 55 3e 55 55 55 55 55 55 55 3f 55 55 55 55 55 55 55 40 55 55 55 55 55 55 55 41 55 55 55 55 55 55 55 42 55 55 55 55 55 55 55 43 55 55 55 55 55 55 55 44 55 55 55 55 55 55 55 45 55 aa [00:00:00.659,000] littlefs: /lfs がマウントされていません /lfs アンマウント: 0 *** Zephyr OSビルドv4.3.0-6239-g28cd602a81eaを起動しています***w25q128jw@0 の littlefsArea 3 の 0xe20000 にある 1966080 バイトのファイルを読み書きするサンプル プログラム[00:00:00.060,000] main: フラッシュ領域を消去しています... 0[00:00:00.069,000] littlefs: LittleFS バージョン 2.11、ディスク バージョン 2.1[00:00:00.127,000] littlefs: w25q128jw@0:0xe20000 の FS は 480 個の 0x1000 バイトのブロックで構成され、512 サイクル[00:00:00.139,000] があります。 littlefs: パーティションサイズ: rd 16 ; pr 16 ; ca 64 ; la 32[00:00:00.151,000] littlefs: WEST_TOPDIR/modules/fs/littlefs/lfs.c:1386:{0x0, 0x1}[00:00:00.164,000] でディレクトリペアが破損しています littlefs: マウントできません (LFS -84); フォーマット中[00:00:00.235,000] littlefs: /lfs マウント済み/lfs マウント: 0/lfs: bsize = 16 ; frsize = 4096 ; blocks = 480 ; bfree = 478 ディレクトリ /lfs を一覧表示中 .../lfs/boot_count 読み取り回数:0 (バイト数: 0)/lfs/boot_count 新しいブートカウントを書き込む 1: [wr:1][00:00:00.297,000] main: テストファイル: /lfs/pattern.bin が見つかりません。作成してください！------ファイル: /lfs/pattern.bin ------01 55 55 55 55 55 55 55 02 55 55 55 55 55 55 5503 55 55 55 55 55 55 55 04 55 55 55 55 55 55 55 5505 55 55 55 55 55 55 55 06 55 55 55 55 55 55 5507 55 55 55 55 55 55 55 08 55 55 55 55 55 55 55 5509 55 55 55 55 55 55 55 0a 55 55 55 55 55 55 550b 55 55 55 55 55 55 55 55 0c 55 55 55 55 55 55 55 550d 55 55 55 55 55 55 55 55 0e 55 55 55 55 55 55 55 550f 55 55 55 55 55 55 55 10 55 55 55 55 55 55 5511 55 55 55 55 55 55 55 12 55 55 55 55 55 55 55 5513 55 55 55 55 55 55 55 14 55 55 55 55 55 55 5515 55 55 55 55 55 55 55 16 55 55 55 55 55 55 55 17 55 55 55 55 55 55 55 18 55 55 55 55 55 55 55 55 19 55 55 55 55 55 55 55 1a 55 55 55 55 55 55 55 1b 55 55 55 55 55 55 55 1c 55 55 55 55 55 55 55 1d 55 55 55 55 55 55 55 1e 55 55 55 55 55 55 55 55 1f 55 55 55 55 55 55 55 20 55 55 55 55 55 55 55 21 55 55 55 55 55 55 55 22 55 55 55 55 55 55 55 23 55 55 55 55 55 55 55 24 55 55 55 55 55 55 55 25 55 55 55 55 55 55 55 26 55 55 55 55 55 55 55 27 55 55 55 55 55 55 55 28 55 55 55 55 55 55 55 29 55 55 55 55 55 55 55 2a 55 55 55 55 55 55 552b 55 55 55 55 55 55 55 2c 55 55 55 55 55 55 552d 55 55 55 55 55 55 55 2e 55 55 55 55 55 55 552f 55 55 55 55 55 55 55 30 55 55 55 55 55 55 5531 55 55 55 55 55 55 55 32 55 55 55 55 55 55 5533 55 55 55 55 55 55 55 34 55 55 55 55 55 55 5535 55 55 55 55 55 55 55 36 55 55 55 55 55 55 5537 55 55 55 55 55 55 55 38 55 55 55 55 55 55 5539 55 55 55 55 55 55 55 3a 55 55 55 55 55 55 553b 55 55 55 55 55 55 55 3c 55 55 55 55 55 55 553d 55 55 55 55 55 55 55 3e 55 55 55 55 55 55 553f 55 55 55 55 55 55 55 40 55 55 55 55 55 55 5541 55 55 55 55 55 55 55 42 55 55 55 55 55 55 5543 55 55 55 55 55 55 55 44 55 55 55 55 55 55 5545 55 aa[00:00:00.659,000] littlefs: /lfs アンマウント /lfs アンマウント: 0 しかし、DCache を有効にしたまま、フラッシュの変更 (書き込みと消去、ドライバレベルではなくサンプルレベル) のたびに "sys_cache_data_flush_and_invd_all()" を使用して DCache をフラッシュおよび無効化し、割り込みを "irq_lock()" でロックしても、やはり動作しません。 DCacheを無効にすることは一時的な回避策としては有効ですが、本番システムには理想的ではありません。動作させるために何か見落としている点があるのでしょうか？ MCUXpresso SDKに付属しているフラッシュメモリにアクセスするサンプルは正常に動作するため、おそらくZephyrまたはその設定に問題があると考えられます。 フラッシュにアクセスする他のZephyrサンプルでも同様の挙動が見られ、DCacheを無効にした場合のみ安定したアクセスが可能になりますが、それらについては徹底的なテストは行っていません。 技術情報： ボード：NXP MIMXRT1180-EVK（CM33コア）をマイクロUSB経由でWindows PCからパススルーしてUbuntu VMに接続 OS: Zephyr v4.3.0-6239-g28cd602a81ea IDE: Ubuntu上のVS Code用MCUXpresso 26.3.72（Zephyr開発者ソフトウェアキット4.3付き） プロジェクトKconfig： ネタバレ （ハイライトして読む） # # 著作権 (c) 2019 Peter Bigot Consulting, LLC # # SPDX-License-Identifier: Apache-2.0 # # オプションでファイルシステムの再作成を強制する CONFIG_APP_WIPE_STORAGE=y CONFIG_DEBUG=y CONFIG_NO_OPTIMIZATIONS=y CONFIG_LOG=y CONFIG_PRINTK=y CONFIG_SHELL=y CONFIG_LOG_DEFAULT_LEVEL=3 CONFIG_LOG_BACKEND_UART=y CONFIG_LOG_MODE_IMMEDIATE=y CONFIG_UART_CONSOLE=y CONFIG_FILE_SYSTEM=y CONFIG_FILE_SYSTEM_LITTLEFS=y CONFIG_MAIN_STACK_SIZE=4096 CONFIG_FLASH=y CONFIG_FLASH_MAP=y # フラッシュメモリを確実に動作させるために必要な回避策 CONFIG_DCACHE=n ## Copyright (c) 2019 Peter Bigot Consulting, LLC## SPDX-License-Identifier: Apache-2.0##オプションでファイルシステムの再作成を強制します CONFIG_APP_WIPE_STORAGE=yCONFIG_DEBUG=yCONFIG_NO_OPTIMIZATIONS=yCONFIG_LOG=yCONFIG_PRINTK=yCONFIG_SHELL=yCONFIG_LOG_DEFAULT_LEVEL=3CONFIG_LOG_BACKEND_UART=yCONFIG_LOG_MODE_IMMEDIATE=yCONFIG_UART_CONSOLE=yCONFIG_FILE_SYSTEM=yCONFIG_FILE_SYSTEM_LITTLEFS=yCONFIG_MAIN_STACK_SIZE=4096CONFIG_FLASH=yCONFIG_FLASH_MAP=y# フラッシュを確実に動作させるために必要な回避策CONFIG_DCACHE=n どんなご協力でもありがたいです。 よろしくお願いします、 ジェイソン Re: MIMXRT1180-EVK LittleFS sample fails on external flash unless DCache is disabled こんにちは、エドウィンさん。 この問題解決にご協力いただきありがとうございます。しかし、ご提案いただいた解決策がよく理解できません。同じ例はFreeRTOSでも動作し、LWIPスタックやミドルウェアは一切関与していません。Zephyrでは動作せず、FreeRTOSでは動作する、単純なLittleFSフラッシュの読み書きの例です。 重要なバッファデータはキャッシュ不可能なメモリに格納する必要があることは理解していますが、Zephyrが提供するもの以外に、そのようなサブシステムやソフトウェアは存在しません。つまり、Zephyrドライバまたはサブシステム内で問題の原因となっている可能性のあるバッファを特定し、それらをキャッシュ不可能なメモリに移動させることを提案しているのですか？ どのバッファーがよくある原因なのか、ご説明いただき、ご経験を共有していただけると幸いです。 よろしくお願いいたします トーマス Re: MIMXRT1180-EVK LittleFS sample fails on external flash unless DCache is disabled こんにちは、 @JasonPD さん。 この問題の原因は間違いなくキャッシュ関連であり、具体的には、以下の記事で説明されている内容です。 「i.MXRT でキャッシュされていないメモリを使用する」 前述のとおり、この問題はLwIPのようなミドルウェアを使用している場合に最も顕著に現れ、Dキャッシュを完全に無効にするのではなく、重要なデータをキャッシュ不可能なメモリ領域に配置することで解決できます。 問題の本質をより深く理解するために、その投稿と参照されているアプリケーションノート（ i.MXRT L1キャッシュの使用）を確認し、記事の推奨事項に従ってLwIPミドルウェアが正しく機能するようにしてください。 BR、 エドウィン。 Re: MIMXRT1180-EVK LittleFS sample fails on external flash unless DCache is disabled さらに調べて、フラッシュドライバ「flash_mcux_flexspi_nor.c」を見てみました。その中に、書き込みと消去後に現金が無効化される仕組みが定義ガードによって保護されているのを見つけました。 #ifdef CONFIG_HAS_MCUX_CACHE 現在当社が独占的に使用しているCM33の場合、KConfファイルには次のように記載されています。 config SOC_MIMXRT1189_CM33 HAS_MCUX_XCACHE を選択してください CM7の場合は次のようになります。 config SOC_MIMXRT1189_CM7 HAS_MCUX_CACHE を選択します。 フラッシュドライバの定義ガードを次のように調整しました。 #if defined(CONFIG_HAS_MCUX_CACHE) || defined(CONFIG_HAS_MCUX_XCACHE) この変更により、フラッシュメモリへの書き込みと消去がエラーなく行えるようになりました。XIPとDCacheを再度有効にし、すべてのIRQ無効化を解除しました。今のところはうまくいっているようです。 NXPの視点から見て、この解決策は理にかなっているかどうか、ご意見をいただけますか？フラッシュメモリにアクセスする際、依然としてIRQを無効にする必要がありますか？ よろしくお願いいたします トーマス

tea2376 位相分離 Ringo GUIでは、TEA2376の位相シェディングを0、30%、40%の負荷ポイントを超えて編集できません。RingoでMTP設定を微調整する方法はありますか？ Re: tea2376 phase shedding こんにちは、リーさん。 ご質問はTEA2376を担当しているアプリケーションエンジニアに転送いたしました。下記に彼の回答を掲載いたしますので、ご確認ください。   現時点では、この設定をさらに微調整するための詳細設定タブや追加パラメータは用意されていません。   回避策として、現在のOPP設定に十分な余裕がある場合は、PFC OPPの閾値を調整して位相分離動作点をずらすことをお勧めします。   BRs、トーマス

DNPUクラスタ NPUクラスターの夢 - だから、私には夢がある。PCIeスイッチドライザー上に16168カードを4枚組み合わせて、LLMを実行するNPUクラスタを構築したいと考えています。できれば、GPUと並行してWindows上で異種混在のコンピューティング環境で動作するようにしたいです。あるいは、Ubuntuマシンにインストールすることもできます。私は一体どれほどおかしいんだろう？それを解明するために、GeminiとCursorに働きかけている。Cursorはこれが妥当だと考えているようですが、もう少し情報がないと、実行可能なドライバーを導き出すことはできません。Cursorは、Windowsホストのイネーブルメント（プログラマーズガイド、ファームウェアパッケージ、リファレンスドライバまたはポーティングキット、および再配布条件）を要求するか、あるいはそれが存在しないことと、適用されるNDAパスを確認することを求めている（これは彼の希望リストかもしれない）。 Re: DNPU cluster こんにちは、 どうやらあなたはARA240に似たものを作ろうとしているようですね。 https://www.nxp.com/products/ARA240 また、ARA240と組み合わせるためのi.MX8MP FRDMボードにもご興味があるかもしれません。 https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX8MPLUS よろしくお願いいたします。 アルド。 Re: DNPU cluster 追記 - このカードは私が欲しいライザーカードのようです:: https://www.google.com/search?q=4+Port+M.2+NVMe+PCIe+4.0+Switch+Expansion+Card+No+Bifurcation+Needed+for+Mac+PC+Workstation+ %7C&prds=convid% 3Ac_4cdfc9901a5bceba %2CheadlineOfferDocid% 3A8079091716787424541 %2Cproductid% 3A8079091716787424541 %2Cpvo% 3A38 %2Cpvt% 3Ahg %2Creqid% 3Ar_0fc0b132f7dc7c0a&ibp=oshop&pvo=38&opi=103135050&gl=US&hl=en&noiga=1 Re: DNPU cluster はい ！ありがとうございます。Ara240がマターの核心です。16168モジュールへの言及はGateworks GW16168に関するもので、私の知る限り、Ara240 16GB M.2モジュールとそれほど大きな違いはないはずです（もし分かりにくい表現でしたら申し訳ありません）。私が作ろうとしているのは、SBUというよりはPCIe拡張カードと呼ぶ方が適切でしょう。スイッチ付きPCIEライザーカードは元々M.2 mキードライブの拡張用に設計されたものですが、私はそのPCIEインフラストラクチャを再利用して4つのAra240 m.2モジュールをホストし、ローカルでLLMを実行するためのクラスタを構築したいと考えています。Tensor LLM構造が私のGPUでうまく機能するかどうかは分かりませんが、ぜひ試してみたいです。私の最大の希望は、自分のPC上で異種混在型のコンピューティング環境を実現することです。とにかく、本当の決め手はドライバーの構造にあるようだ。私のカーソルエージェントは多くのことができるように感じますが、Ara240チップに関するソフトウェアレベルの情報がもう少しないと、実際にできることには限界があります。

FS26を使用してHSEファームウェア（AB_SWAP）をアップデートする方法は？ ハードウェアのセットアップ S32K396 FS26 ソフトウェアのセットアップ HSEファームウェアバージョン0.2.50.0がAB_SWAPモードでインストールされました FS26ウォッチドッグがタイムアウト200msで有効になっています バックグランド HSEリファレンスマニュアルバージョン2.7第11.3章（「HSEファームウェアアップデート（AB_SWAP）」）によると： HSEは、ファームウェアが更新されているかどうかに関わらず、スワップサービス後のリセット後に、新しいパッシブパーティションに自身のバックアップを取得します。そのため、これらのシーケンスでは、HSE FWがバックアップを取得するため、起動時間が約1秒長くなります。 HSEファームウェア0.2.50.0で動作が変更されましたが、新しいHSEファームウェアをインストールした後の1秒間の長い遅延は依然として残っているようです。（リリースノート第6.1章「0.2.50.0での変更点」参照） ABSwapでは、HSEファームウェアが同じ場合、ファームウェアバックアップをスキップすることで、パーティションスワップとリセット後のHSE初期化時間を短縮します。 FS26は、1秒の遅延が完了する前にシステムをリセットすることに注意してください。 質問 1秒の遅延を解消する方法はありますか？そうでない場合、HSEファームウェアをアップデートするにはどうすればよいですか？ Re: How to update HSE firmware (AB_SWAP) with FS26? 迅速なご返信ありがとうございます！ セキュアブートを使用している場合でも、これは適用されますか？つまり、HSE CPUは、HSEファームウェアをパッシブパーティションにコピーする前に、検証済みのコアを解放するのでしょうか？ Re: How to update HSE firmware (AB_SWAP) with FS26? こんにちは、 @FredrikMoller さん 重要な違いがあります。これはHSEコアの起動時間（または初期化時間）を指します。アプリケーションコアの起動時間は以前と変わりません。ファームウェアがパッシブパーティションに書き込まれるまでは、HSEサービスを使用することはできません。 つまり、HSE_STATUS_INIT_OKフラグが設定されるまで約1秒かかるということです。しかし、アプリケーションは通常どおり動作しており、必要に応じてウォッチドッグを更新できます。 よろしくお願いいたします。 ルーカス Re: How to update HSE firmware (AB_SWAP) with FS26? 素晴らしい！ルーカスさん、素晴らしいサポートを本当にありがとうございました！ Re: How to update HSE firmware (AB_SWAP) with FS26? この使用例について確信が持てなかったので、テストしてみました。答えはイエスです。セキュアブート（プリブートモード／シーケンシャル）が実行され、アプリケーションコアが解放され、その後ファームウェアがコピーされます。ファームウェア0.2.40.0を使用しましたが、スワップ後の1秒の遅延（アプリケーションコアを解放するまでの遅延）は確認できませんでした。シンプルなLED点滅アプリケーションを作成したのですが、すぐに点滅し始めました。 よろしくお願いいたします。 ルーカス

由于 高效密码学标准\\(SEC\\)/CAAM 未初始化，BL2 中的安全启动失败 安全启动在 BL2 中失败看起来是因为 高效密码学标准(SEC)/CAAM 未初始化。在仔细研究代码时，似乎没有直接调用 sec_init，但看起来配置函数是在它之前被调用的，因此全局变量无法获得 高效密码学标准(SEC) 区块地址的定义常量。即 NXP_CAAM_ADDR 值。当我对这个值进行硬编码时，我可以让它稍微进一点，但随后我出现了无法刷新/重置任务铃声的错误。 QorIQ LS1设备 Re: Secure boot fails in BL2 because SEC/CAAM not initialized 你好 BL2中的这种安全启动失败是TF-A（可信固件-A）初始化流程中典型的 " chicken and egg " 问题，专门针对恩智浦Layerscape或i.MX平台。 当你对 NXP_CAAM_ADDR 进行硬编码并克服地址错误但遇到 Job Ring 刷新/RESET 错误时，这通常意味着 CAAM 硬件块要么没有时钟，要么处于过渡状态，要么被安全违规阻止。   1.初始化序列 sec_init 没有在配置函数之前被调用的原因，很可能是 bl2_main.c 中的顺序造成的。或特定平台的 plat_bl2_el3_setup.c 。 修复：确保在 bl2_el3_early_platform_setup 内调用 plat_ls_sec_init() （或与 SoC 类似的函数）。 全局变量问题：如果 NXP_CAAM_ADDR 没有弹出，请检查平台的 plat_get_caam_address() 函数是否返回 0，或者 BL2 转换表中的数据段是否没有正确映射。   2.为什么工作环冲洗失败 如果代码试图刷新作业环却失败了，请考虑以下三个罪魁祸首： 安全违规（最有可能）：如果 SoC 处于 " Closed " 模式（已熔丝），CAAM 可能在从 bootROM 过渡到 BL2 的过程中触发了安全违规。网络安全违规会使 CAAM 处于 " Halted " 状态，在该状态下，在违规行为被清除之前，无法重置或使用工作戒指。 缺少时钟/功率：如果在 BL2 期间未在 DCFG（设备配置）或 PCC（外设时钟控制）中明确启用 高效密码学标准(SEC) 模块时钟门，则寄存器将可访问（如果幸运的话），但内部逻辑（如 Job Ring 控制器）不会响应重置命令。 主 ID (MID) 不匹配：作业环需要特定的主 ID 配置，以便 BL2（在 EL3 中运行）能够"自己的" 。如果 BootROM 将振铃分配到不同的 MID 但没有释放它们，BL2 在尝试 RESET 它们时会超时。   3.调试步骤 检查 SEC_VID（版本 ID）和 SEC_STA（状态）寄存器：在 Job Ring 重置呼叫之前阅读这些寄存器。如果状态寄存器显示网络安全违规，则需要找出触发该违规的原因（通常是前一阶段的身份验证失败）。 验证重置位：确保在切换重置位后等待足够长的时间。在某些芯片版本中，CAAM 重置所需的时间比 SDK 中提供的标准延迟环路长。 检查 TrustZone 设置：确保您正在访问的任务环在中央安全单元 (CSU) 或资源域控制器 (RDC) 中标记为 " Secure "。 此致 Re: Secure boot fails in BL2 because SEC/CAAM not initialized 开机后，但在加载 SRKH 镜像寄存器并释放 CPU 之前，如果我检查 DCFG_CCSR_DEVDISR1 寄存器，我会发现位 22 (高效密码学标准(SEC)) 设置为 1。根据有关重置的文档，该寄存器应全部为 0。在启动过程的这么早期，这个值可能在哪里设置？我需要对 pbl 命令做些什么吗？RCW 是否有误？我确实看到在低功耗安全寄存器中检测到电源故障，但我也看到配置寄存器显示应忽略/不应对低功率篡改采取行动。 Re: Secure boot fails in BL2 because SEC/CAAM not initialized 好吧，谁能帮我确认一下？ 在 TF-A 驱动程序/nxp/dcfg/dcfg.c 中我找到了一个用于检查是否启用 高效密码学标准(SEC) 的计算方法。它在 SVR_SEC_MASK 和寄存器 0x1ee00a4 的值之间进行比特& ，寄存器 0x1ee00a4 是一个只读寄存器。如果我正确读取了字段，那么 16-23 位的状态是否为 ls1043 或 ls1023，是否 高效密码学标准\(SEC\) 硬件是否启用。我看到该位的值为 0x00000001。哪个会是这个芯片上禁用的高效密码学标准(SEC)封锁，对吗？我参考了完整零件号的示意图并得到了 LS1043ASN7MNLB，当我查看恩智浦的网站显示高效密码学标准(SEC)已禁用时。这是否导致了我的安全启动问题？高效密码学标准(SEC)能否启用这款芯片，还是在它离开恩智浦后就一成不变了？我们需要考虑其他芯片吗，还是可以在没有高效密码学标准(SEC)的情况下进行安全启动？ Re: Secure boot fails in BL2 because SEC/CAAM not initialized 支持人工智能复制粘贴？如果我们要走这条路，就需要进一步调整代理。如果 SoC 知道自己的代码库，那么它就应该知道 NXP_CAAM_ADDR 是在头文件中静态定义的，而不是先填充的。

清除 GPIO ISR 大家好， 我们尝试按照 IMXRT1176 参考手册从 CM7 内核获取 GPIO_DISP_B2_00 引脚的访问权限。 gpio_pin_config_t config = { kGPIO_DigitalInput, 0, kGPIO_IntRisingEdge, }； SETUP(IOMUXC_GPIO_DISP_B2_00_GPIO_MUX5_IO01, 1, AD_PULL_UP + AD_SLEW_SLOW); GPIO_PinInit(GPIO5, 1,&config )； 这发生在启动过程中的引脚复用器中。在应用程序的某处，我们会编写代码来初始化该 gpio 的中断： GPIO_PortClearInterruptFlags(GPIO5, 0xFFFFFFFF)； GPIO_PortEnableInterrupts(GPIO5, 1<< 1)； NVIC_SetPriority(GPIO5_Combined_0_15_IRQn, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY)； EnableIRQ(GPIO5_Combined_0_15_IRQn); volatile uint32_t a = GPIO_PortGetInterruptFlags(GPIO5)； PRINTF (" %lu\ r\n ", a)； 此代码打印： 4 294 901 757 这是 0x FFFE FFFD — >--> 0b1111 1111 1111 1110 1111 1111 1111 1101 如你所见，引脚 1 位看起来像 0。 因此，我们可以假设 RESET 对其产生了影响。 但是我不明白的是，为什么其他位设置为 1，为什么第 17 位设置为 0？ 参考手册指出 1402/6259： ```当在 GPIO 输入上检测到活动状态（由 相应的 ICR 位确定）并正在等待服务时，将钳位该寄存器的第 n 位 中断状态（高电平有效）。寄存器 的值与 IMR 寄存器的值无关。 检测到激活状态后，相应位将保持设置状态，直至软件清除。 通过将1写入相应的位位置 ```来清除状态标志， 因此我假设所有值都应为0作为默认RESET状态。其他 GPIO 也遵循类似的模式，在 ISR 寄存器中设置了许多位。 谁能告诉我，我在这里误解了什么？感谢您的帮助 🙂 致以最崇高的敬意， Jakub Re: Clearing GPIO ISR 你好@jslota13245、 误解在于，GPIO ISR RESET 值仅描述 RESET 后立即的寄存器状态。它不能保证稍后在启动期间会读取什么软件。ISR 是一个锁存状态寄存器：一旦检测到配置的条件，该位将保持设置状态，直到软件将其清除，这与 IMR 无关。要确定当前启用了哪些中断源，我们可以使用GPIOx->ISR& GPIOx->IMR； 对于 RT1170，恩智浦还记录了勘误表 ERR050643：DISP_B2 引脚在初始上电期间可以看到短暂的内部上拉脉冲，因此在应用程序读取 ISR 之前，GPIO_DISP_B2_00 可能合法地处于待定状态。因此，启动后的非零ISR并不意味着重置失败。 致以最诚挚的问候， Gavin Re: Clearing GPIO ISR 亲爱的@Gavin_Jia， ，非常感谢你的详细答复。 1) 确认一下，您可能已经注意到了，在我之前发送的示例代码中，我们明确向状态寄存器写入 0xffffff ffff 以清除它，我们做了一些无操作循环，操作后我们几乎立即尝试读取它，并在 GPIO->ISR 中得到非零值。这意味着在清零/读取调用之间，硬件已在大部分引脚上注册了中断条件，这很难让人相信，因为我们根本没有使用它们。这发生在 GPIO 初始化的早期启动之后。So what you're suggesting is there is some hardware noise that may cause this behaviour when we write 0xffffffff to GPIO->ISR? 2) By the way, reading forums i found this thread: https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/GPIO-ISR-and-Clearing-ISR/m-p/1059441 答案如下： ''在您的情况下，您需要注意未配置为中断操作的位的中断状态将读作待处理。因此，你不能像 那样只检查中断状态，我想知道这是否是真的，因为这与观察到的行为有些吻合。但是我在参考手册中找不到任何关于它的信息。 再次感谢您的支持！ 最美好的祝愿， Jakub

LX2160A 電源インテグリティ (PI) 解析 専門家の皆様へ 現在、LX2160Aを使用したPCB設計を進めており、電源インテグリティ（PI）解析を実施する予定です。 適切な分析条件を設定するために、以下の項目についてご指導いただけますでしょうか？ 1. 各電源レールにおける推奨目標インピーダンス 2. 解析における想定最大過渡電流（di/dt）条件 また、推奨されるPI分析ツールや手法があれば、ぜひご教示いただければ幸いです。 サポートありがとうございます。ご返信をお待ちしております。 よろしくお願いいたします。 Re: LX2160A Power Integrity (PI) analysis 1. 電源レール概要（LX2160A） LX2160Aは、コアロジック、SRAM/PLL、SerDes、DDR、およびI/O用に複数の独立した電源レールを使用します。正確なレールリストと公称電圧は、 LX2160Aのデータシートおよびリファレンスデザインに定義されており、それらが正式な情報として扱われるべきです。 典型的なキーレール（名称は回路図によって異なります）： レール機能 標準定格電圧 備考 コア（VDD） 約0.75～0.85V di/dtが最も高く、PIにとって最も重要 プラットフォーム／キャッシュ（VDD_PLAT） 約0.9V 大容量オンダイSRAM、垂下現象に敏感 SerDesアナログ 約1.0V ノイズに敏感で、di/dtが低い SerDes Digital 約0.9V 適度な切り替え活動 DDR VDD 1.2 V JEDEC主導の外部メモリが主流 DDR VPP 2.5V 低電流 入出力（VDD_IO） 1.8V / 3.3V PIの臨界値が最も低い 2. 推奨ターゲットインピーダンス（Z_TARGET） LX2160Aは明示的なZターゲット値を公表していないため、標準的な電圧リップルに基づく方法を使用する。 Ztarget=ΔVallowableΔImaxZ_{target} = \frac{\Delta V_{allowable}}{\Delta I_{max}} Z t a r g e t = Δ I m a x Δ V a l l o w a b l e NXPは一般的に、Layerscapeデバイスのコア型電源レールにおけるリップル率を3～5%以下にすることを推奨しています（設計チェックリストおよびリファレンスボードに基づく）。[static.chipdip.ru] 、[community.nxp.com] 実用的な目標インピーダンス値 レール 許容リップル 推定ΔI 推奨Z_TARGET コア（VDD） ±3%（約25mV） 8～12歳 2～3 mΩ プラットフォーム／SRAM ±3%（約30mV） 4～6 A 5～8 mΩ SerDes Digital ±5% 1～2 A 25～40 mΩ SerDesアナログ ±5% <1 A >50 mΩ DDR VDD JEDEC 3～5 A 20～30 mΩ 入出力レール ±5～10% <2 A >50 mΩ ✅ 重要なポイント： コアレールとSRAMレールのみが、低ミリオーム範囲まで非常に積極的なPDN設計を必要とする。 3. 過渡電流/di/dtに関する仮定 コアレール（重要） PIシミュレーションにおける最悪ケースの過渡現象に関する仮定は、一般的に以下のとおりです。 ΔIステップ：5～8A エッジレート：1～5ナノ秒 di/dt : 1～5 A/ns これらは以下を表しています。 複数のCortex-A72コアの同時切り替え キャッシュ＋データパスアクセラレータの動作（DPAA2、DCE、SEC） これは、NXPのリファレンスボードや設計チェックリストにおけるバルク＋高周波デカップリングのサイズ決定方法と一致しています。[static.chipdip.ru] 、[community.nxp.com] その他のレール レール ΔIの仮定 di/dt プラットフォーム／SRAM 2～4 A 0.5～1 A/ns SerDes Digital 0.5～1 A 0.1～0.3回答 DDR VDD JEDECによって管理されるバースト より遅い、レギュレーター主導 I/O <0.5 A 非常に低い 4. 分析対象周波数範囲 LX2160Aの場合、PI解析では以下の項目を対象とする必要があります。 DC → 100 MHz （最小） オンダイL/C効果のため、コアレールには最大300～500MHzが推奨されます。 約1MHz以下： ✅ VRMとバルクコンデンサが大部分を占める 1～100MHz: ✅ ボードレベルのMLCCとプレーン 100 MHz: ✅ オンパッケージ＋オンダイ静電容量（利用可能な場合はパッケージSパラメータを使用してモデル化） 5. デカップリング戦略（参照ベース） NXPのリファレンスデザインは、3層構造のアプローチを示しています。 バルク コアレールあたり47～330μFのポリマーまたはタンタル 中周波MLCC 1～10 µF、X7R、パッケージ外周全体に分布 高周波MLCC BGA直下に0.01～0.1μF この方法は、LayerscapeのRDBレイアウトと整合性があります。[static.chipdip.ru] 6. 推奨PIツール LX2160AクラスのSoCでうまく機能する、広く使われているツール： シミュレーション ケイデンス シグリティ パワーSI Ansys SIwave Keysight PIPro Altium PDNアナライザー（初期段階のチェック） 測定（ポストシリコン） VNAを用いたPDNインピーダンス測定（2ポートシャントスルー方式） BGAブレークアウトテストポイントにおける高帯域幅プロービング 7．方法論の概要（ベストプラクティス） Z_TARGETベースのPDN設計から始めましょう スイープインピーダンスプロット（対数-対数）を作成する Z_TARGET以下の反共鳴ピークを除去する 検証方法： 最悪の場合の現在のステップ 負荷過渡シミュレーション 可能であればRDBの挙動と相関関係を分析する 8. NXP固有の推奨事項 NXPは、社内でPDNサイジングに使用される電力使用事例やレール電流に関するガイダンスを含むAN5407 – LX2160A/LX2162A設計チェックリストを確認することを強く推奨します。[community.nxp.com] NXPプレミアムサポートをご利用の場合は、以下のリクエストも可能です。 鉄道ごとの最悪シナリオの電流表 パッケージPDNモデル（利用可能な場合）

デジタル信号の電圧変換ってどうやればいいの？ (日本語ブログ) 0. 目次 0. 目次 1. 電圧レベル・トランスレータって？ 2. デジタル信号 2.1 様々なデジタル信号 2.2 CMOSとTTL：単純な電圧のHIGHとLOWによる論理レベルの信号 2.3 入出力電圧の規定：VOH / VOL と VIH / VIL 2.3.1 出力電圧の規定：VOHとVOL 2.3.2 入力電圧の規定：VIHとVIL 2.3.3 VOH / VOL と VIH / VIL の関係 3. 基本的な電圧レベル変換の方法：片方向信号の変換 3.1 チップの電源電圧が違っても変換の必要がない例 コラム：TTLのVIH(min) = 2.0V，VIL(max) = 0.8Vはどうやって決まっている？ 3.2 変換が必要な例 3.2.1 オープンドレイン出力による変換 3.2.2 標準ロジック(汎用ロジック)チップを用いた変換 4. 自動方向切り替えが必要な双方向信号の変換 4.1 単体MOSトランジスタによる双方向変換 4.2 専用品による双方向変換 4.2.1 I²C信号電圧変換チップ 4.2.2 高速化を図った双方向オープンドレイン信号電圧変換チップ 4.2.3 双方向プッシュプル信号電圧変換チップ 4.2.4 I3C信号電圧変換チップ 4.2.5 バッファによる変換 5. まとめ 5.1 ブログ内で紹介した方式/品番の比較 6. 参考資料 1. 電圧レベル・トランスレータって？ デジタル回路同士をつなぐとき，単純に信号線を直結すればいい… ということはなくて，「論理レベルの電圧」が合わないと，動作しなかったり，不安定になったり，最悪の場合チップを壊してしまうことがあります． そんなときに便利に使えるのが電圧レベル・トランスレータ(Voltage Level Translator．電圧レベル・シフタとも呼ぶ)です． 電圧レベル・トランスレータは，異なる電源電圧のデジタル回路間で信号をやり取りできるようにする回路です． 例えば，次のようなケースで必要になります． 3.3V マイコン ↔︎ 5V センサ の接続 1.8V FPGA ↔︎ 3.3V 周辺デバイス の接続 図1：信号電圧の違い   このブログでは，デジタル回路で使われる論理回路の種類(*TTL，*LVTTL，*CMOS)の電圧レベルの違いから，それを判断する上で重要なV OH /V OL /V IH /V IL の意味について解説します．さらに様々な変換の方法の中から，どのような電圧レベル・トランスレータを選べばよいかを解説します． さらにこのブログでは信号の方向を自動で検出して変換を行う電圧レベル・トランスレータの具体例を見ていきます． NXPではSDカード/SIMカード向けや，*GTL↔︎TTLレベル変換のような特定用途向け電圧レベル・トランスレータもラインナップしていますが，このブログは汎用またはシリアル・バス用途をターゲットにした製品の解説となります． *TTL（Transistor-Transistor Logic） *LVTTL（Low Voltage Transistor-Transistor Logic） *CMOS（Complementary Metal-Oxide-Semiconductor） *GTL（Gunning Transceiver Logic） 2. デジタル信号   2.1 様々なデジタル信号 いわゆる「デジタル信号」は論理レベルの1と0を電気的に表現したものです．この論理レベルの1と0を扱う回路設計方法には歴史的に様々なものがあります．論理レベルを単純な電圧のHIGHとLOWで表現するものや，電圧の差を利用してHIGH/LOWを表現するものなど． 単純なHIGH/LOWを5V/0Vで表すTTL．さらにそのTTLを低電圧化し3.3V/0Vで表すLVTTLなどバイポーラ・トランジスタ回路を基準に電圧レベルが決められたもの． 同様にバイポーラ・トランジスタを使いながらも負電源を使い低振幅で差動で動作論理レベルを実装し，高速化が図られたECL．基準電圧を設けて低振幅のシングルエンド信号でHIGH/LOWを伝達するGTLなど... また単純なHIGH/LOWでの表現でも低消費電力化を目的に開発された4000シリーズと呼ばれるCMOS汎用ロジックでは，HIGHレベルとして3V〜18Vを使うことができました． https://en.wikipedia.org/wiki/Logic_family このブログでは，上記のような様々な論理レベルの中でも，単純なHIGHとLOWの電圧で論理を表現するTTL(LVTTL)とCMOSの電圧レベルの扱いについて解説します． その他の信号変換には専用チップが用いられるため，ここでは扱いません． このほか近年では半導体技術の微細化・高速化・低消費電力化が進むとともに，電源に使われる電圧は低くなってきています．このため信号電圧差を橋渡しする電圧レベル・トランスレータは特に重要になってきています． 図2：信号波形 - 電圧の高低(HIGH/LOW)で論理レベルを表す   2.2 CMOSとTTL：単純な電圧のHIGHとLOWによる論理レベルの信号 デジタル回路に使われる単純な電圧のHIGHとLOWによる論理レベルの信号には，HIGHを電源電圧で，LOWを0Vとするものが一般的です．電源電圧が異なってもHIGH/LOWの電圧レベルが同じであれば，そのまま信号をやり取りすることができます． たとえばTTL(LVTTL)は入力される信号が2.0V以上であればHIGH，0.8V以下であればLOWと解釈します．このような取り決めがあるため，TTL信号であれば互いに電源電圧が異なってもHIGH/LOWの電圧レベルは変わりません． いっぽう，CMOSは電源電圧の半分の電圧を基準にしてHIGH/LOWを定義します．このためCMOSは電源電圧が異なるとHIGH/LOWの電圧レベルも変わります． 図3：入力信号電圧の規定   2.3 入出力電圧の規定：V OH  / V OL  と V IH  / V IL デジタル回路ではHIGHとLOWとして出力される電圧と，入力される信号をHIGHとLOWに判断する電圧が規定されています．これらは使用する各チップの仕様で規定されているため，データシートで確認する必要があります． V OH  : HIGHレベル出力電圧 (HIGH-level output voltage) V OL  : LOWレベル出力電圧 (LOW-level output voltage) V IH  : HIGHレベル入力電圧 (HIGH-level input voltage) V IL  : LOWレベル入力電圧 (LOW-level input voltage) 2.3.1 出力電圧の規定：V OH とV OL 出力ではHIGH/LOWを出力する際の電流を考えておかねばなりません．電流は負荷により増減します． HIGH出力での最大流出電流時に保証できる電圧をV OH (min)，LOW出力での最大流入電流時に保証できる電圧をV OL (max)と呼びます． V OH (min)は回路出力段の上側のトランジスタがONになったときに出力される電圧です．このトランジスタには「ON抵抗」と呼ばれる抵抗分があります． トランジスタから流れ出る電流が大きい場合，"トランジスタの抵抗分 x そこに流れる電流"で電圧が発生．すると出力はその電圧分だけ電源電圧から下がってしまいV OH が低くなってしまいます．このため，あらかじめ想定される最大流出電流のときに保証できる最小の電圧がV OH (min)となります． 図4：デジタル信号出力回路(プッシュプル)   図5：HIGH出力電圧は負荷によって変化する   V OL はこの逆となります．回路出力段の下側のトランジスタがONになったとき，流れ込む電流が大きいと，上記と同様にトランジスタのON抵抗によって発生する電圧によって，出力は0Vより上がってしまいます．これを考慮し，あらかじめ想定される最大流入電流のときに保証できる最大の電圧がV OL (max)となります． 図6：LOW出力電圧も負荷によって変化する   2.3.2 入力電圧の規定：V IH とV IL 入力にはHIGHとLOWを判断するための電圧レベルがあります．V IH (min)とV IL (max)です．電圧がV IH (min)以上であればHIGHと判断され，V IL (max)以下であればLOWと判断されます． CMOS入力では電源電圧の1/2がHIGHとLOWの基準となりますが，これをそのままV IH (min)とV IL (max)とはしていません．これはチップごとのバラツキなどによって閾値が上下するためです．また，遅く立ち上がる信号に乗ったノイズなどによるグリッチが出力に現れることを軽減するため，入力にはヒステリシスを持たせることが一般的です．このような理由によりV IH (min)とV IL (max)はある程度の電圧差を設けて規定されます． 2.3.3 V OH  / V OL  と V IH  / V IL  の関係 正常な信号のやり取りを行うには，出力と入力の関係は下式を満たす必要があります． HIGHレベル： V OH (min) > V IH (min) LOWレベル： V OL (max) < V IL (max) この関係が守られていれば，出力側の回路は，次の入力側の回路に対してHIGH/LOWを正しく伝えることができます．さらにこの互いの電圧差である「V OH (min) - V IH (min)」や「V IL (max) - V OL (max)」は「ノイズ・マージン」となり，ノイズ耐性を高く保つための目安になります． 図7：V OH (min) / V OL (max) と V IH (min) / V IL (max) 3. 基本的な電圧レベル変換の方法：片方向信号の変換   3.1 チップの電源電圧が違っても変換の必要がない例 『「V OH (min) > V IH (min)」かつ「V OL (max) < V IL (max)」』の関係が成り立つ場合には基本的には電圧レベル変換は必要ありません．たとえばTTLとLVTTLはそれぞれのチップに使われる電源電圧は違うものの，入出力電圧の規定は同一です． TTL(5V)とLVTTL(3.3V)ではどちらも，V OH (min)は2.4V，V OL (max)は0.4Vです．V IH (min)/V IL (max)も，どちらも2.0V/0.8Vなので問題なく互いに接続できます． ただし出力電圧が入力側チップの電源電圧よりも高い場合には注意が必要です．出力側が5V，入力側が3.3V電源を使うチップである場合には，入力側は「5Vトレラント入力」に対応していなければなりません． 5Vトレラント入力とは，5VのHIGH信号を3.3Vの電源電圧で動作するチップの入力に接続しても問題なく動作する入力のことです．一般的なチップの入力には静電気対策のためのESD保護回路が入っていますが，このESD保護回路が次の図のような回路で構成されていると5Vを入力した際に入力から3.3Vの電源に電流が逆流してしまい，チップを破壊してしまうことがあります．このような問題を起こさないための対策が取られた入力が5Vトレラント入力です．トレラント入力にはESD保護がないわけではなく，電源電圧より高い信号が入力されても問題がないような構造を持つESD保護回路が組み込まれています． 図7のようなESD保護ダイオードは，入力側チップの電源が切られている時にも問題を引き起こします．チップごとに個別に電源のON/OFF管理を行うようなシステムの場合，入力側チップがOFFになっているにも関わらず出力側の信号が電源に回り込み，入力側チップを動作させてしまうことがあります． 図7：ESD保護ダイオード - 非トレラント入力 コラム：TTLのV IH (min) = 2.0V，V IL (max) = 0.8Vはどうやって決まっている？ CMOSの入力閾値が電源電圧の中点(VCC/2)を基準にしているのに対し，TTLのV IH (min)/V IL (max)は2.0V/0.8Vという，電源電圧(5V)に対して特に綺麗な比率ではない値になっています．これには，TTLの入力段がバイポーラ・トランジスタで構成されていることが関係しています． 標準TTLロジックIC:SN7400(2入力NAND)の内部回路例 『最新汎用ロジック・デバイス規格表 1988』(CQ出版)に掲載されていたもの 標準的なTTLゲートの入力段は，多重エミッタの入力トランジスタと，その後段のフェーズスプリッタ・トランジスタが直列に重なった構造をしています．ゲートが実際に反応し始める「スイッチング・スレッショルド」は，この2段に重なったPN接合の順方向電圧で決まります．シリコンのPN接合1個あたりの順方向電圧はおよそ0.6〜0.7Vなので，2段重なると合計でおよそ1.3〜1.5V付近がTTLゲートの実質的なスイッチング・スレッショルドとなります． ただしこの約1.4Vという値はあくまで「典型値(typical)」であり，個体差や温度などのバラツキによってロットごと・条件ごとに変動します．そこでデータシート上の規定値であるV IH (min)とV IL (max)は，この約1.4Vの典型値に対して上下に十分なマージンを取り，「ここまで下がれば確実にLOWと判定できる(V IL (max)=0.8V)」「ここまで上がれば確実にHIGHと判定できる(V IH (min)=2.0V)」という，保証値として規定されています． さらにこの値は単独で決められているわけではなく，2.3.3節で説明したV OH /V OL との関係も踏まえて設計されています．標準TTLでは出力段の構成により，HIGH出力は電源電圧にはならず，少し低い(上記回路例では130Ωの抵抗，トランジスタとダイオードで発生する電圧分だけ低い)電圧になります（VOH(min)=2.4V）．これとVOL(max)=0.4Vを組み合わせると， HIGH側ノイズ・マージン：V OH (min) − V IH (min) = 2.4 − 2.0 = 0.4V LOW側ノイズ・マージン：V IL (max) − V OL (max) = 0.8 − 0.4 = 0.4V のように，上下対称に0.4Vのノイズ・マージンが確保されるよう設計されています．つまりTTLの2.0V/0.8Vという「電源電圧に対して半端」に見える数字は，バイポーラ・トランジスタの接合電圧という物理的な実体と，ノイズ・マージン設計という2つの要請から導かれた，合理的な値だったということになります． SN7420(4入力NAND)の入力ピン3つをHIGH，1つに100kHzの三角波を入力(ch1)した様子 無負荷状態の出力(ch2)だがHIGHのとき4V未満の出力となっている(Vcc=5V) なお，本コラムで紹介した回路は無印(74LS00や74HC00のようにLS/HCなどの付かないもの．英語では“バニラTTL”と呼ばれることもある)標準TTLの例ですが，V IH /V IL の規定が同じ理由（入力段のバイポーラ接合特性）は74LSなど他のTTLファミリにも共通しています．   3.2 変換が必要な例   TTLやLVTTLでは電圧レベルが揃っているため上記のような接続が可能ですが，電源電圧の違うCMOSチップ同士や，CMOSとTTLチップの接続では論理レベルが合わない場合が多く発生します．前述の『「V OH (min) > V IH (min)」かつ「V OL (max) < V IL (max)」』の関係が成り立たない，またはその差が小さくなってしまい，ノイズ・マージンが取れないような状況がそれにあたります． この問題を解決するのが電圧レベル・トランスレータです． 図9：論理レベルが合わない例(1)：充分なHIGH電圧が入力されない   図10：論理レベルが合わない例(2)：充分なLOW電圧が入力されない     3.2.1 オープンドレイン出力による変換 電圧レベル変換チップを用いなくても，簡単に電圧レベル合わせを行う方法はあります． 信号の方向が出力側チップ→入力側チップで固定され切り替わることがないのなら．HIGH側の出力をオープンドレイン出力にすることで，入力側の電圧に合わせる方法です．オープンドレインはデジタル回路の出力段の上側のトランジスタがない構成のもので，入力側チップの電源電圧に接続されたプルアップ抵抗によってHIGHの電圧を得ます． 図11：デジタル信号出力回路(オープンドレイン)   オープンドレインは単純で安価な方法ですが，いくつかの注意点があります． まず出力側がオープンドレイン出力が可能なものである必要があります．多くのマイコンのGPIOピンなどでは設定によってこの出力が可能です． まず出力側がオープンドレイン出力が可能なものである必要があります．多くのマイコンのGPIOピンなどでは設定によってこの出力が可能です．もしオープンドレイン出力に設定できないプッシュプル出力固定など場合には，外付けのトランジスタなどを使ってオープンドレイン出力に変換する必要があります． さらにプルアップ抵抗の選択も重要です． プルアップはHIGHの電圧を得るために必要な抵抗ですが，抵抗値が小さすぎるとLOW出力時に流れる電流が大きく(負荷が大きい状態に)なり，消費電力が増える上にV OL の上昇を招いてしまいます． 逆に大きすぎると配線とピンによる容量の影響を受け，LOWからHIGHへの立ち上がりが遅くなってしまい，通信速度の低下が起こります． 3.2.2 標準ロジック(汎用ロジック)チップを用いた変換 単純な電圧レベル変換であれば標準ロジックを用いる方法もあります．たとえばNexperia社の74AVCH4T245は4ビットの双方向レベル変換を行うことができるCMOS汎用ロジックチップです． このチップでは0.8V〜3.6Vの信号を変換することができ，信号の方向をDIRピンによって切り替えることもできます．信号速度は変換を行う電圧にも依存しますが，100M〜380Mbps程度に対応可能です． 図12：標準ロジックの例 - 74AVCH4T245 このチップを用いると高速な信号の双方向電圧変換が可能ですが，方向の制御は外部からの信号によって行わなければなりません．このような制御はパラレル・バスのREAD/WRITEのような信号によって可能ですが，プロトコルによって通信方向が切り替わるシリアル・バスのような通信には適用が困難です． 図13：標準ロジックの例．信号の方向を外部から指定しなくてはならない 4. 自動方向切り替えが必要な双方向信号の変換 これまでに紹介した"オープンドレイン出力"や"標準ロジックチップを用いた電圧変換方法"では，主に一方向のみの変換を行うもの，あるいは外部信号による方向の切り替えが必要なものでした． I²C，I3Cのような信号の方向がダイナミックに変化するような通信には，方向が自動で検出して切り替わる「双方向の電圧レベル変換」が必要です．このような信号の方向を外部から制御するのは難しく，前述のようなバッファ・チップで実現するのは困難です． さらにI²Cはオープンドレイン信号であるため，オープンドレインの標準ロジック・バッファを互いに違う向きに接続するようなことができません．図14はその例です．オープンドレイン・バッファを互いに反対方向に接続しています．バッファの両側がHIGHの時は問題ありませんが，どちらかが一旦LOWになると，バッファは互いの入力をLOWに引っ張ったままとなり，HIGHに戻すことができなくなります． 図14：通常のオープンドレイン・バッファでは双方向通信を自動切替できない   4.1 単体MOSトランジスタによる双方向変換   これまでI²Cの信号電圧変換には，単純な回路が用いられることがありました．その最も簡単なMOSトランジスタを使った方法をその例として挙げます． 図15：MOSトランジスタを使った変換の例   図15はI²Cの仕様書version2.1(2000年)から引用したもので，3.3Vと5Vの信号を2本の信号にそれぞれ1個のMOSトランジスタ(TR1, TR2)を用いる例です．このような単純なトランジスタ単体での変換例は，後述する問題点があるため現在のI²Cの仕様書からは削除されていますが，原理を理解するために紹介します． SDAとSCLと呼ばれるI²Cの信号線は，どちらもオープンドレイン出力の双方向信号となっています．3.3V側と5V側にそれぞれプルアップ抵抗が接続されています． この回路では3.3V側，5V側の信号がHIGHである場合，このトランジスタのゲート(g)とソース(s)間は同電位となるため，ソース(s)とドレイン(d)OFF状態となって互いの接続が切れた状態に置かれます．この状態で3.3VがLOWに変化すると，3.3V側のトランジスタ(のsとdの間)がONになり，5V側の信号もLOWになります． 3.3V側がHIGHで5V側がLOWに変化した場合には，まず3.3V側から5V側への寄生ダイオード(ボディ・ダイオード)がONになります．ダイオードがONになるとソース(s)の電圧が降下．その結果トランジスタがONになり，3.3V側の信号もLOWになります． このようにトランジスタをスイッチとして使う非常に単純な仕組みで電圧レベル変換ができるのですが，ここには問題もあります．トランジスタのバラツキが信号変換の閾値に影響すること．さらに今日ではより低い信号電圧を扱うことが増えてきており，たとえば信号電圧が1V程度では，このような回路では十分なゲート(g)とソース(s)間電圧(Vgs)が得られないため動作させることができません． 追記：図15と同じ回路は，NXPから半導体ディスクリート/ロジック製品事業が分社化されて誕生したNexperia社のアプリケーションノートAN10441「Level shifting techniques in I²C-bus design」として今も公開されています．I²C仕様書とは別に2007年に初版(Rev.01)のアプリケーションノートが発行され，2020年にNexperiaブランドへ改訂(Rev.2)されています． 4.2 専用品による双方向変換   「電圧レベル・トランスレータ専用IC」を用いることで，I²C, I3Cのような双方向通信を行うバスの電圧レベル変換を容易に行うことができます． 4.2.1 I²C信号電圧変換チップ PCA9306，NVT20xxシリーズ(NVT2001/02, NVT2003/06, NVT2008/10)は双方向信号の変換に特化した電圧レベル・トランスレータです．これらのチップでは複数の信号線(複数ビットの信号線)をまとめて扱うことができます．これらはI²C信号の電圧変換チップとされていますが，信号の仕様が合えば他の目的(SPIやその他のプッシュプル信号など)にも使うことができます． PCA9306，NVT20xxシリーズは同じ内部構造を持ち，プルアップ抵抗は，変換する電圧差が1V以上であれば電圧の高い側だけに接続すれば良いようになっています． 図16はその内部構造と外部チップの接続を示したものです(アプリケーションノートAN11127：「Bidirectional voltage level translators NVT20xx and PCA9306」のFig.2から抜粋)．このチップ内部には信号線数(ビット数)+1個のMOSトランジスタが内蔵されています．各トランジスタはソースとドレインが可換の構造となっています． 信号を伝達するための経路のトランジスタはパス・トランジスタと呼ばれ，残りの1個はリファレンス・トランジスタと呼ばれます． 図16：NVT20xx(PCA9306) - チップ動作の解説図   回路を見てみると，リファレンス・トランジスタのゲートとドレイン間はショートされており，200kΩの抵抗を介して高い電圧側の電源に接続されています．リファレンス・トランジスタの残りの端子：ソースは低電圧側の電源に接続されています．このような接続により，リファレンス・トランジスタは1個のダイオードとなっており，このゲート電圧は低電圧側の電源よりもダイオード1個分高い電圧となります． 残りのパス・トランジスタはドレイン側が高い電圧側の信号線と1kΩのプルアップ抵抗に，ソース側は低い電圧側の信号線，さらにゲートはリファレンス・トランジスタのゲートに接続されています．パス・トランジスタの高い側，低い側の信号がどちらもHIGHになっている時，高い側は1kΩによってプルアップされた電圧となります． パス・トランジスタはいわゆる「ソースフォロワ」と呼ばれる回路を構成しています．低い電圧側の端子(ソース端子)は，ゲートに印加されている電圧よりトランジスタをONにするために必要なVgs分だけ低い電圧が現れます．つまり低電圧側の電源と同じ電圧となります．トランジスタはONでもOFFでもない半分ONの状態(線形領域での動作)になっています． この状態で，高または低のどちら側かの信号がLOWになると，ゲートと信号端子の電圧差によりトランジスタがON(完全にONとなった飽和領域での動作)になり，反対側の端子もLOWになります． このシリーズで扱える信号速度は，プルアップと信号線の容量の影響を受けます．データシートでは，PCA9306は2MHzまで．NVT20xxシリーズでは192Ωのプルアップ抵抗を使用し，容量50pFの条件で最大33MHzまでの信号速度に対応可能とされています．1MHz程度の信号であれば，プルアップ抵抗や容量をあまり気にしなくても(通常I²Cで使うような範囲内を想定)で問題なく動作します．しかしこのチップをプッシュプルのより高速な信号を扱う場合には特製の把握と慎重な部品選択が必要になります． このタイプの電圧レベル・トランスレータ動作の詳細は，「PCA9306の中身と動作」の記事で紹介されています． 4.2.2 高速化を図った双方向オープンドレイン信号電圧変換チップ 高速化を図った双方向オープンドレイン信号変換チップとして，NTS030xシリーズ(NTS0302JK, NTS0304E)を紹介します． このチップは2ビットまたは4ビットの双方向信号変換を行うことができ，オープンドレイン信号であれば2Mbps(1MHz)，プッシュプル信号であれば20Mbps(10MHz)の信号に対応可能です．   図17：NTS030x - チップ内部ブロック図   図17はNTS030xの信号1ビット分の内部構造です． 図ではT3のトランジスタがパス・トランジスタとなっており，ゲート端子バイアス電圧がかけられているので，AとBと書かれた信号のどちらかがLOWとなった時にONとなります． AとBの両方がHIGHの時はT3がOFFになり，AとBはそれぞれの電源に比較的大きいプルアップ抵抗(10kΩ)で接続されているのでそれぞれの電圧となります． このチップにはT3のほかにT1とT2が存在しています．このT1とT2は「エッジレート・アクセラレータ」と呼ぶ機能のために使われます．このうちの片方，T1に注目しこの動作を解説します． T1はA側に置かれ，ソース端子はA信号に，ドレイン端子はA側電源に接続されています．ゲート端子はこれを制御する「ONE-SHOT AND SLEW RATE CONTROL」と書かれたブロックに接続されています． 「ONE-SHOT AND SLEW RATE CONTROL」ブロックは反対側のB信号に接続されていて，B側の信号のLOWからHIGHへの変化を検出．これを検出した時に一時的にT1をONにして，プルアップの10kΩ抵抗をバイパスして電流を流す事により，A側の信号のHIGHへの変化を加速します．このように信号の立ち上がりを速くすることで，より高速な信号を扱うことができるようにしています． ちなみに，このT1をONにする際のスルーレートは制御されていて，急な電流増加によるリンギング発生を抑えることも考慮されています． もういっぽうのT2はこの同じ仕組みが逆方向に作られており，B側信号にも適用されるようになっています． このNTSシリーズにはもう一つの使いやすい点があります． ここまで説明したMOSトランジスタ単体やPCA9306/NVT20xxの場合，どちらかの電源がOFFになった場合，他方の信号をLOWにしてしまうという問題がありました．NTS030xではこの問題を解決するために，両方の電源がONになっていない場合は，互いに影響が出ないように信号ピンをハイ・インピーダンス状態とするよう動作します．このような機能を使うことにより，システムの電源を部分的にON/OFF制御するような使い方が可能になります． NTS030xシリーズと同等品で，より高速の信号に対応するためスルーレート制御機能の無いNTS010xシリーズ(NTS0102, NTS0104)も用意されています． なお，NTS0304Eには，すぐに簡単な動作検証ができるように評価基板：NTS0304EUK-ARDが用意されています．NTS0304EUK-ARD基板の概要と動かし方はこちらの動画「NTS0304EUK-ARDの動かし方」をご参考ください． 4.2.3 双方向プッシュプル信号電圧変換チップ さらにこのNTS030xシリーズをプッシュプル信号だけで使う場合のより高速なオプションとしてNTB010xシリーズ(NTB0102, NTB0104)があります． HIGHまたはLOWで安定した状態では4kΩを通して信号を駆動．NTS030xシリーズ同様のワンショット機能をHIGHとLOW側の両側に持たせ，いずれかの端子で信号の変化があった場合にこれを用いて，反対側信号を変化させる機構を持っています． このような機構により，信号方向の自動検出機能を持ちながら70〜80Mbpsの速度の信号電圧変換が可能です．   図17：NTB010x - チップ内部ブロック図 4.2.4 I3C信号電圧変換チップ I3Cはオープンドレインとプッシュプルを切り替えながら通信を行う仕様を持ち，オープンドレインではI²Cと互換〜4MHzの周波数．プッシュプル時は12.5MHzのクロックが使われます．信号の電圧は通常1V〜3.3Vの範囲で使われるため，電圧差がある場合には，信号仕様に合わせた動作をする電圧レベル・トランスレータが必要になります． 図18はP3A1604の1ビット分の内部ブロック図です．このチップでは図の通り，LOW→HIGHだけでなくHIGH→LOWの変化を加速する仕組みとON/OFFの切り替えができるプルアップ抵抗が内蔵されています．   図18：P3A1604 - チップ内部ブロック図 P3A1604は4ビット用のI3C電圧レベル・トランスレータ．この他にも2ビット用のP3A9606も用意されています．   4.2.5 バッファによる変換 もう一つの双方向信号の変換方法として，専用品のバッファを使う方法があります． バッファの本来の目的は，駆動能力の増強や接続している信号線の容量の分離などですが，電圧の変換に対応した製品も存在します． 双方向のオープンドレイン信号を相互にバッファするには，このブログの中で説明したように単純なバッファでは実現できません．そのため双方向オープンドレイン信号用として様々な工夫がされたバッファ製品が用意されています． バッファについての詳細はまた次の機会に解説する予定です． 5. まとめ 電圧レベル・トランスレータは，異なる電源電圧を持つデジタル回路間で安全かつ確実に信号をやり取りするために不可欠な部品です．TTLやLVTTL，CMOSなど論理レベルの規定や，VOH/VOL/VIH/VILの関係を理解することで，適切な接続や変換方法を選択できます． 片方向の変換にはオープンドレイン出力や標準ロジックIC，双方向の変換にはMOSトランジスタや専用IC（PCA9306/NVT/NTS/NTB/P3Aシリーズなど）が利用できます． 特にI²CやI3Cなど双方向通信が必要なバスでは，信号方向の自動検出機能を持つ電圧レベル・トランスレータが有効です． また，近年の半導体技術の進化により，低電圧化・高速化が進み，より厳密な電圧レベル管理が求められるようになっています．電圧レベル変換の方法や選択肢は多岐にわたりますが，信号仕様や速度，システムの電源管理など用途に応じて最適な方法・部品を選ぶことが重要です． 5.1 ブログ内で紹介した方式/品番の比較 方式/品番 用途 ビット数 方向切替 オープンドレイン対応 低電圧側[V] 高電圧側[V] ビットレート[bps] オープンドレイン出力での変換 汎用 1 片方向 - - - - 標準ロジック(例:74AVCH4T245) 汎用(パラレルバスなど) 4 + 4 外部制御 非対応 0.8 ~ 3.6 0.8 ~ 3.6 100M ~ 380M 単体MOSトランジスタによる双方向変換 I²C, 汎用 1 自動 対応 トランジスタの仕様による ~ 1M PCA9306 I²C, 汎用 2 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M (2MHz．条件による) NVT2001 I²C, 汎用 1 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2002 I²C, 汎用 2 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2003 I²C, 汎用 3 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2006 I²C, 汎用 6 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2008 I²C, 汎用 8 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NVT2010 I²C, 汎用 10 自動 対応 1.0 ~ 3.6 1.8 ~ 5.5 4M(2MHz@オープンドレイン), 66M(33MHz@最適化条件による) NTS0302JK I²C, SPI, 汎用 2 自動 対応 0.95 ~ 3.6 1.65 ~ 5.5 2M @オープンドレイン, 20M @プッシュプル NTS0304E I²C, SPI, 汎用 4 自動 対応 0.95 ~ 3.6 1.65 ~ 5.5 2M @オープンドレイン, 20M @プッシュプル NTS0102 I²C, SPI, 汎用 2 自動 対応 1.65 ~ 3.6 2.3 ~ 5.5 50M @プッシュプル NTS0104 I²C, SPI, 汎用 4 自動 対応 1.65 ~ 3.6 2.3 ~ 5.5 50M @プッシュプル NTB0102 SPI, 汎用 2 自動 非対応 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M NTB0104 SPI, 汎用 4 自動 非対応 1.2 ~ 3.6 1.65 ~ 5.5 70M ~ 80M P3A9606 I3C, I²C, SPI, 汎用 2 自動 対応 0.72 ~ 1.98 0.72 ~ 1.98 (12.5MHz) P3A1604 I3C, I²C, SPI, 汎用 4 自動 対応 0.72 ~ 1.98 1.62 ~ 3.63 6.8M @オープンドレイン, 40M @プッシュプル 表1：ブログ内で紹介した方式/品番の比較   6. 参考資料 製品紹介ページ：電圧レベル変換器 NXP システム・マネジメントI2C, I3C, SPIセレクタ・ガイド I2C バス仕様およびユーザーマニュアル (Rev5.0 日本語版) I2C バス仕様およびユーザーマニュアル (Rev7.0 英語版) NXPコミュニティ・ブログ：I3Cバスの概要 ～次のシリアルバス～ 日本語ウェビナー動画：『【今知っておくべき】次世代インターフェース「I3C」の基礎』  Qiita @teddokano：PCA9306の中身と動作 変更履歴： 2025-08-28：初版 2025-08-28：NTS0304EUK-ARDの紹介と動画公開ブログへのリンクを追記 2026-04-10：表1の低電圧側[V]，高電圧側[V]の訂正 2026-06-20：第3.1節「コラム：TTLのVIH(min) = 2.0V，VIL(max) = 0.8Vはどうやって決まっている？」を追加．標準TTLロジックIC:SN7400(2入力NAND)の内部回路例，SN7420の出力波形を追加 2026-07-10：第4.1節に，図15の回路がNexperia社アプリケーションノートAN10441としても公開されている旨を追記 ========================= 本投稿の「Comment」欄にコメントをいただいても、現在返信に対応しておりません。 お手数をおかけしますが、お問い合わせの際には「NXPへの技術質問 - 問い合わせ方法 (日本語ブログ)」をご参照ください。 （既に弊社NXP代理店、もしくはNXPとお付き合いのある方は、直接担当者へご質問いただいてもかまいません。） このブログでは，デジタル回路で使われる論理回路の種類(*TTL，*LVTTL，*CMOS)の電圧レベルの違いから，それを判断する上で重要なV OH /V OL /V IH /V IL の意味について解説します． さらに様々な変換の方法の中から，どのような電圧レベル・トランスレータを選べばよいかを解説します． 特に特別な扱いが必要となる，双方向オープンドレイン信号の変換について詳しく見てみます Interface introduction 日本語ブログ

【恩智浦单片机简介】【电机控制】【基础知识（四）】让我们来实践一下！通过框图来了解矢量控制的机制！（日语博客）   【入门指南】【基础版】永磁同步电机的工作原理及控制方法 我们来试一试！让我们用框图来了解矢量控制的机制！ 矢量控制的全貌：反馈是关键！ 让我们按步骤来！交流电转直流电（图表左半部分） 控制系统的核心：“控制过程”（图表中心） 回到电机部分！直流转交流的逆向转换（图表右半部分） 逆变换的终极武器：一种名为 SVM（空间矢量调制）的艺术形式。 摘要：高速循环产生的平滑旋转 【入门指南】【基础版】永磁同步电机的工作原理及控制方法 我们来试一试！让我们用框图来了解矢量控制的机制！ 你好！ 在上一篇文章中，我谈到了神奇的计算方法——克拉克变换和帕克变换，它可以将三相交流电转换为直流电。 “但它究竟是如何使用的呢？” 我也这么认为！这次，让我们来看一下下面的框图，并了解这些转换如何在实际的电机控制系统中发挥至关重要的作用！ 矢量控制的总体思路：反馈至关重要！(*) （*这只是个人观点，其他重要因素也需要考虑。） 上图展示了矢量控制的整体流程。乍看之下可能有些复杂，但其原理其实很简单：它不断地弥合目标与现实之间的差距。这被称为“反馈控制”，是所有精密控制的基础。 例如，想想开车这件事。 目标： “我想以每小时 60 公里的速度跑步。” 事实：请查看速度表上的当前速度。 操作：如果落后于目标，则踩下油门；如果领先于目标，则松开油门。 矢量控制的工作原理完全相同。最右侧的 ① 電圧出力 代表实际输送给电机的电流（加速器运行）。最终目标是精确控制这个电流。 为此，我们需要准确了解“电机当前所处的状态”（实际情况）。用于此目的的传感器位于左侧。 ② 電流測定 ：测量实际流过电机的三相电流（A相、B相、C相）。这是扭矩的来源，代表“实际力”值。 ③ 速度・位置検出 ：此参数检测电机轴（转子）当前的旋转角度和速度。这是“实际位置”，是停车转换的关键。 微控制器接收到这种“现实”信息， 利用坐标变换和电机模型，我们可以计算并确定电机内部的磁通分量（d轴）和扭矩分量（q轴） 。 每个单元以极高的速度不断更新电压指令，以控制电流，使其与目标值相匹配。 这就是矢量控制的基本概念。 让我们按步骤来！交流电转直流电（图表左半部分） 现在，让我们从图中的左侧向中间看看测量信息是如何处理的。 测量三相电流：首先，我们从在 ② 電流測定 （波动交流电）处获得的 A、B 和 C 相的电流值开始。 克拉克变换（三相到两相） ：利用上次学习的克拉克变换，我们将这三个交流电值变换为两个正交的交流电值“α”和“β”。这就是图中标记为“静止坐标系”的坐标系。现在，三个变量简化为两个，处理起来就容易多了。 Park变换（静止帧→旋转帧） ：接下来，我们对这些α和β值进行Park变换。我们使用在 ③ 速度・位置検出 处获得的“转子角度(θ)”。我们将切换到“dq坐标”，即跟踪旋转矢量的旋转坐标。 因此，α 和 β 的交流值转换为“d”和“q”的直流值！ 这意味着电机的“实际”状态现在以微控制器可以理解的形式表示，由两个简单的直流值表示：“磁通量分量（d）”和“扭矩分量（q）”。 *在 IPMSM 中，d 轴电流也有助于产生转矩。 控制系统的核心：“控制过程”（图表中心） 图中中心的蓝色方框 制御プロセス 是矢量控制系统的核心。在这里，微控制器执行其最强大的功能：“比较和计算直流值”。 与指令值的比较：我们将根据外部给出的指令值（例如“我们想要这个扭矩”和“我们想要以这个速度旋转”）确定的目标 d 轴和 q 轴电流值与先前计算的“实际 d 和 q 值”进行比较。 误差计算：此计算“目标”值与“实际”值之间的差异（误差）。例如，“实际扭矩小于目标扭矩”或“磁通量大于目标值”。 PI 控制调整：为了消除这种误差，需要计算调整量，例如“将 d 轴电压增加这么多”或“将 q 轴电压降低这么多”。这种计算采用了一种称为PI 控制的巧妙技术，它会随着误差的增大而增加调整量，如果误差已经累积，则会进一步增加调整量。 这样，就可以确定“下一时刻接近目标时的理想 d 轴电压和 q 轴电压”。 回到电机部分！直流转交流的逆向转换（图表右半部分） 控制过程中确定的“d 和 q 端指令电压”不能直接发送到电机。这是因为电机只能识别三相交流电。 所以，这次我们将进行反向转换，将微控制器语言（直流）转换回电机语言（三相交流）。 逆帕克变换（旋转系统→静止系统） ：首先，利用逆帕克变换将指令电压d和q转换回交流指令值α和β。这相当于从旋转的旋转木马上下来，从地面重新观察这些矢量。 逆克拉克变换 (SVM) ：最后，将 α 和 β 的指令值转换回电机可以直接理解的 A、B、C 相的具体电压指令值。此时，通常使用一种称为**空间矢量调制 (SVM)**的技术，它比简单的逆克拉克变换效率更高、性能更强。 逆变换的终极武器：一种名为 SVM（空间矢量调制）的艺术形式。 SVM 是一种专注于如何利用逆变器电路的六个开关（只能开/关的笨拙开关）忠实地再现微控制器创建的“理想电压矢量 (α,β)”的技术。 GIF动画中的红色箭头：这代表微控制器想要达到的理想电压矢量。它旋转得很平滑，对吧？ 六边形顶点处的蓝色箭头：这些是逆变器开关组合所能物理产生的仅有的六个基本电压矢量（加上一个中心零点）。它们是成角度的。 SVM 是一种数字艺术，它通过以超高速（每秒数万次）切换和组合这些有限的基本矢量，使人眼无法察觉地施加与理想红色箭头相同的电压，从而平均而言，使人眼看起来好像施加了相同的电压。 得益于这项技术，我们可以在有限的电源电压下发挥最大的性能，并实现极其平稳安静的电机旋转。 摘要：高速循环产生的平滑旋转 病媒控制程序可概括如下： 测量（交流）→ 转换（直流）→ 控制（直流）→ 逆转换（交流）→ 输出 这就像把一门外语翻译成日语来理解它，整理你的思路，然后再把它翻译回原来的外语来与对方交流。 整个“测量→计算→输出”循环在微控制器内部以惊人的速度（每秒超过10000次）重复进行。这种高速反馈循环是确保电机平稳有力旋转，始终听从我们指令的关键，即使负载或速度指令突然变化也能正常工作。 有关详细的设置说明以及如何运行示例代码，请参见下方↓ 【恩智浦单片机简介】【电机控制】【实际应用（一）】永磁同步电机的机理及控制方法（日语博客） 这是一个汇总了有关恩智浦电机控制产品文章的网站↓ NXP电机控制 - 概要页面（日语博客） =========================​ 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便，我们深表歉意，但 在进行咨询时， 请 参考“ NXP 技术问题 - 如何联系我们 （ 日语博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ，您可以直接咨询您的代表。 ） 本指南清晰地解释了如何使用恩智浦半导体（NXP）的FRDM控制板“FRDM-MCXA156”进行电机控制。指南分为基础知识部分和实践部分，您可以根据自己的兴趣选择阅读部分内容。 • 基础章节 1-7，实践章节 1-3 这次，作为基础系列（第 4 部分）的一部分，我们将介绍“矢量控制机制”。 （阅读时间：10分钟） MCUXpresso MCUXpresso IDE MCUXpresso SDK MCX 电机控制 技术聚焦 日本博客

入門ガイド

S32K148 FlexCAN2 不工作 你好 我正在尝试启用 S32K148 上的 FlexCAN2，同时使用 Eclipse OpenBSW 项目。 FlexCAN0 正常工作，但 FlexCAN2 无法传输有效帧。 配置： MCU: S32K148 CAN 实例：FlexCAN2 别针 PB12 → CAN2_RX (ALT4) PB13 → CAN2_TX（ALT4） 外部收发器：以 5V 电压供电的 MCP2551 总线终端：总计 ~60 Ω 比特率500 kbps（经典 CAN） 观察到的行为 总线上只能观察到错误帧 发生位填充错误 未收到 ACK 问题 MCP2551 （5V 收发器）与 S32K148 FlexCAN I/O 电平兼容吗？ PB12/PB13 ALT4 是 FlexCAN2 的正确引脚吗？ FlexCAN0 和 FlexCAN2 之间是否存在需要考虑的特定时钟或配置差异？ 如能得到任何指导，将不胜感激。 谢谢！ Re: S32K148 FlexCAN2 not working 嗨，@sousou54、 1.我认为 MCP2551 的兼容性没有问题。 2.是的。 3.无需额外配置。CAN0/1/2 的时钟频率相同。 您可以尝试按步骤测试您的节点... 尝试在不使用收发器的情况下将 TX/RX 引脚连接在一起并发送信息。您应该会看到由于缺少 ACK 而反复出现的信息。TX 错误计数器为 0x80，模块处于错误被动状态。如果出现其他情况，则说明针脚设置有误。 将 TX/RX 引脚正常连接到收发器，并使其与总线断开连接。发送信息您应该会看到与上面相同的内容。如果没有，收发器可能被禁用或未终止。 我从 MCP2551 数据表中看到，您必须通过将 Rs 引脚连接到 Vss 来选择高速模式。 使用其他节点将收发器连接到总线（例如CAN 工具），发送/接收信息。如果检测到任何错误，很可能是 CAN 位定时不正确。确保所有节点使用相同的比特率和采样点。 您可以使用以下工具：MPC5xxx/S32Kxx/LPCxxxx：CAN / CAN FD 位定时计算。 最后，这是定制板，还是你在使用 S32K148EVB？如果这是定制板，请按照 AN5426：S32K1xx 硬件设计指南中的说明检查连接。 致以最诚挚的问候， Julián

加密实现 密码块链接(CBC)-aes-tee 修改了提供给它的密钥。 你好 我看到内核加密实现密码块链接(CBC)-aes-tee（来自恩智浦OP-TEE）与其他密码块链接(CBC)-aes实现（密码块链接(CBC)-aes-ce、密码块链接(CBC)-aes-neonbs、密码块链接(CBC)-aes-generic）的行为有所不同。我使用的是 iMX93 和 linux-imx 6.12.20-2.0.0，yocto walnascar 和 optee 4.6。 我在尝试使用 RAUC 安装加密更新捆绑包时遇到了这个问题。RAUC 能够使用 openSSL 解密更新捆绑包，但无法使用 dm_crypt 加载捆绑包。我在 RAUC Github 页面上发现了一个问题，描述了这个问题。(第 1833 期，链接：https://github.com/rauc/rauc/issues/1833） 我确认这就是我面临的问题。问题在于 密码块链接(CBC)-aes-tee 不直接使用来自内核驱动程序的密钥传递，而是将其视为派生新密钥的盐。这与内核的预期（特别是 crypto_skcipher_setkey）背道而驰，也与其他 密码块链接(CBC)-aes 实现（密码块链接(CBC)-aes-ce、密码块链接(CBC)-aes-neonbs、密码块链接(CBC)-aes-neonbs、密码块链接(CBC)-aes-generic）不同。RAUC 的其他用户已经解决了这个问题，他们降低了 OP-TEE 对称密钥加密技术在内核加密 API 中的优先级，这样内核就会优先使用其他实现。这可以通过在 tee_skcipher.h 中将 TEE_CRYPTO_CRA_PRIORITY 设置为较低值来实现。这会导致内核在我的板上使用 cbc-aes-ce 而不是 cbc-aes-tee，这确实解决了 RAUC 和 dm_crypt 的直接问题。但是，我的同事认为这有点严厉，这并不能解决密码块链接(CBC)-aes-tee的问题。 我编写了一个小程序来演示这个问题。该程序使用 OpenSSL 加密消息，然后使用 密码块链接(CBC)-aes-ce、密码块链接(CBC)-aes-neonbs、密码块链接(CBC)-aes-generic，最后使用 密码块链接(CBC)-aes-tee 对其进行解密。密码块链接(CBC)-aes-tee 实现是唯一不起作用的实现，因为它不直接使用密钥。我附上了程序源代码、编译后的程序二进制文件（gzipped 这样我就可以上传了），以及程序在我的板上运行后的输出。 我很想修复这个问题，这样 密码块链接(CBC)-aes-tee 的行为与其他实现相同。如果我能帮上什么忙，请告诉我。 Re: Crypto implementation cbc-aes-tee modifies the key given to it. 与 AE 团队讨论。 Re: Crypto implementation cbc-aes-tee modifies the key given to it. 根据 R&D 团队的答复，这是一种预料之中的行为。 这种 TEE 卸载不是为了实现互操作性，即加密由 TEE 卸载完成，而相应的解密则由非 TEE 完成。 我已经筹集了一张 jira 票证 LF-17796 来建议 R & D 可以降低 "密码块链接(CBC)-aes-tee" 驱动程序的默认优先级。 让我们等待反馈吧。 Re: Crypto implementation cbc-aes-tee modifies the key given to it. 感谢您的反馈。 如果密码块链接(CBC)-aes-tee不打算与其他 密码块链接(CBC)（aes）实现兼容，那么我认为内核加密API不应该选择它作为密码块链接(CBC)（aes）的实现。 Re: Crypto implementation cbc-aes-tee modifies the key given to it. 谢谢，如果团队有任何反馈，请告诉我。 Re: Crypto implementation cbc-aes-tee modifies the key given to it. 该补丁https://github.com/rauc/rauc/issues/1833#issuecomment-3632067956 正在审查中。 客户可以使用此补丁来解决问题。该问题将在以后的 电路板支持包 版本中修复。

[滥用] 发布者：@RishavKaaraTech /板：TapLinx-SDK /举报人：rkzelkdx rkzelkdx 报告了 @RishavKaaraTech 发布的帖子 RFIDDiscover 工具已被收购，但如何使用它 ，原因如下： 原因： 详情： < a href="https://hetnieuweteamwerken.be/forums/forum/speman-buy-low-price-hbqrl"> online最便宜的 speman < a href="https://slp.millingtonpubliclibrary.org/content/speman-buy-cod-fertility-pill"> 购买多伦多 speman < a href="http://www.familygalactictravel.com/node/3214"> 折扣speman saturday delivery fast < a href="https://hetnieuweteamwerken.be/forums/forum/speman-buy-low-price-hbqrl"> where to buy next speman < a href="https://oregonweddingday.com/your-couple-name-3695"> bestspeman 5kmtl 的价格 < a href="http://hubram.cz/content/speman-can-i-purchase"> 在哪里可以买到 speman < a href="http://en.sp-journal.ru/article/19262"> 药房speman canadian pharmacy < a href="https://cadel.ru/forum/speman-purchase-rx-bradford"> can i buy speman drug < a href="https://mnbride.com/your-couple-name-4220"> where to order next speman < a href="https://investor18.ru/investors/speman-generic-online-usa"> best价格 speman 检查 internet < a href="https://arendville.ru/speman-buy-low-price-hbqrl"> orderspeman store no script < a href="http://dev.nikol-buket.com/content/speman-pharmacy-online-germany"> pharmacy德国 speman 在线 < a href="https://jeunescathos-bxl.org/fr/content/speman-where-order-next"> 如何购买 speman < a href="http://xn--80aah2bgapnqg.xn--p1ai/job/speman-cost-price-online-why"> 如何订购 speman < a href="https://www.vgame.ca/node/47884"> 购买处方 speman 无需购买 < a href="https://dev.beautynbrushes.com/services-provided/short-cut-maroonimmortalep-1"> speman购买 hn8hb < a href="http://ph-ed-plus.nspu.ru/article/17987"> speman税务摊销收益 no rx https://www.rapidservice.com.ec/es/content/speman-buy-brand-shop-buy">speman 通过密码支付 < a href="https://darkmetalmush.net/history/speman-best-price-5kmtl"> cheapspeman no prescrip < a href="https://www.tripmayntra.com/speman-get-no-prescription-fedex"> buy处方 speman without buy < a href="https://www.rapidservice.com.ec/es/content/speman-buy-brand-shop-buy"> cheapspeman no prescrip < a href="https://museusvalenciapre.grupotecopy.es/en/node/4090"> getspeman no prescription fedex < a href="https://www.ziveknihy.sk/autor/speman-generic-pills"> buyingspeman florida < a href="https://www.rapidservice.com.ec/es/content/speman-buy-brand-shop-buy"> FDAapproved generic speman mogwt < a href="https://direct.needshub.com/node/28534"> how购买斯皮曼片 < a href="https://stage.cc.radiant.digital/node/3152"> want购买 speman < a href="http://wsb2.pl/content/speman-delivery-cheap"> 在网上购买 speman 药片 < a href="https://www.tripmayntra.com/speman-get-no-prescription-fedex"> 购买speman next day delivery < a href="https://www.intellectualpedia.org/countyelectron-speman-buy-low-price-hbqrl"> buy品牌 speman 商店购买 < a href="http://xn--80ab2anoq0a.xn--p1ai/art/speman-buy-mastercard-without-prescription"> 购买speman low price hbqrl < a href="https://www.thebiketube.com/topeak-francesca"> discountspeman from canada < a href="https://www.intellectualpedia.org/countyelectron-speman-buy-low-price-hbqrl"> purchasespeman 样品 < a href="http://pi5ny.com/node/5148"> generic speman fedex wyoming < a href="http://pi5ny.com/node/5148"> pharmacy speman store < a href="https://www.itconnecta.es/speman-cost-evohaler-trimethoprim"> cheapspeman no prescrip < a href="http://polden.info/story/speman-get-rx-no-prescription"> for sale speman ware < a href="http://dev.nikol-buket.com/content/speman-pharmacy-online-germany"> genericspeman fedex wyoming < a href="https://slp.millingtonpubliclibrary.org/content/speman-buy-cod-fertility-pill"> discounted speman purchase buy check < a href="http://xn--80aah2bgapnqg.xn--p1ai/job/speman-cost-price-online-why"> buyspeman missouri < a href="http://old-bxl.jeunescathos.org/fr/content/speman-cost-cheap-buy"> genericspeman middlesbrough 发表链接 ：https://community.nxp.com/t5/TapLinx-SDK-TagWriter-and/RFIDDiscover-tool-acquired-but-how-to-use-it/m-p/2164324#M205 帖子作者 @RishavKaaraTech|Email Author 报告人：rkzelkdx |Email Reporter 报告的帖子有 3 个回复。

S32G399のRGMIIとSGMIIおよびPHY間の相互接続通信において、MDCとMDIOはどのように割り当てられますか？ こんにちは、 S32GのPCIeインターフェースを使用して、SGMII経由でイーサネットスイッチに接続する予定です。一方、イーサネットスイッチの残りのポートは、RGMII経由でPHYに接続します。 S32G399の3つのRGMIIチャネルを、PHY4と同じように設定しました。S32Gのこれら3つのRGMIIチャネルはそれぞれ、PHYに接続された独自のMDCとMDIOを備えています。 では、PHY0～3のMDCおよびMDIO通信ポートは、S32Gにどのように割り当てるべきでしょうか？   Re: S32G399 RGMII和SGMII与PHY互联通讯MDC和MDIO如何分配 こんにちは、チェンイさん はい、PHYは全部で7つあります。PHY5とPHY6はPHY4と同じ構造ですが、まだ図を描いていません。 Re: S32G399 RGMII和SGMII与PHY互联通讯MDC和MDIO如何分配 こんにちは、 @MichaelTao こんにちは 念のため確認ですが、S32GのMACアドレスのうち1つを使用してSJA1105（4つのPHYに接続）にSGMII経由で接続し、残りの3つのMACアドレスはRGMII経由でPHYに接続した、つまり合計7つのPHYが接続された、ということでしょうか？ BR チェイン Re: S32G399 RGMII和SGMII与PHY互联通讯MDC和MDIO如何分配 こんにちは、 @MichaelTao ご確認いただきありがとうございます。 スイッチに接続されたPHYを管理するために1つのMDIOチャネルを使用し、SOC MACに接続されたPHYを管理するために別の、または複数のMDIOチャネルを使用することを検討できます。これは、具体的な設計によっては可能となるはずです。 BR チェイン Re: S32G399 RGMII和SGMII与PHY互联通讯MDC和MDIO如何分配 こんにちは、 @MichaelTao はい、MDIOインターフェースは複数のPHYに接続できます。 BR チェイン Re: S32G399 RGMII和SGMII与PHY互联通讯MDC和MDIO如何分配 つまり、SOC上の3つのMDIOチャネルは、対応する3つのRGMII MACチャネルにバインドされておらず、このMDIOバスに他のPHYを追加できるということでしょうか？ 画像に示したトポロジーでうまくいくはずですよね？

U4N-如何设置 Aion 2 私人服务器进行测试 为什么要设置私人服务器？ 私人服务器可让您完全控制游戏环境。你可以 在没有时间压力的情况下，测试班级技能、轮换和连击。 尝试装备升级或强化。 反复运行 PvP 或 PvE 场景。 通过观察受控环境中的行为，更快地学习游戏机制。 对于许多玩家来说，这尤其有助于他们尝试在官方服务器上有风险或昂贵的策略。 开始前的准备工作 在建立私人服务器之前，您需要做好以下准备： 体面的电脑 私人服务器可以在本地运行，但性能取决于 CPU 和内存。配备至少 8GB 内存和现代 CPU 的中档机器足以进行小规模测试。 Aion 2 客户端副本 您需要游戏客户端来连接服务器。确保它与您计划运行的服务器版本一致。 服务器文件 Aion 2 的私人服务器文件经常在社区论坛中共享。查找明确标注用于测试或开发的版本。避免未知来源，降低恶意软件风险。 数据库软件 大多数私人服务器使用 MySQL 或 MariaDB 来存储游戏数据。您需要安装和配置其中一个数据库。 基本网络知识 你不需要成为一名网络工程师，但了解端口、IP 地址和防火墙的工作原理非常重要。客户端必须可以连接到服务器。 步骤 1：安装服务器软件 拿到服务器文件后，第一步就是安装： 提取文件将它们 放在计算机上的专用文件夹中。避免使用系统目录，以减少潜在冲突。 配置服务器设置 打开配置文件。最重要的设置包括 IP 地址：将其设置为本地计算机的 IP 或 127.0.0.1（仅用于本地测试）。 端口号：确保这些端口空闲。典型的 Aion 2 端口通常都包含在文档中。 数据库连接：输入数据库用户名、密码和数据库名称。 运行安装脚本 许多私有服务器包都附带用于初始化数据库的脚本。运行这些操作可创建必要的表格和默认数据。 启动服务器 执行服务器程序。监测控制台是否有任何错误消息。常见问题包括数据库凭证错误或端口已在使用中。 步骤 2：连接客户端 服务器运行后，您需要告诉您的 Aion 2 客户端与其连接。 修改客户端配置 查找配置文件，通常命名为 Aion2.ini 或类似文件。将服务器 IP 更改为您的私人服务器使用的 IP。 测试连接 启动游戏客户端并登录。如果遇到连接错误，请检查防火墙设置并确保服务器正在运行。 创建测试账户 在私人服务器上，您可以创建无限账户进行测试。使用这些账户来尝试不同的版本和装备设置。 步骤 3：使用服务器进行测试 连接后，您就可以开始使用服务器进行任何测试，而不会产生任何后果。一些实用的方法包括 技能轮换测试：运行假人或小怪来测量技能时机和伤害输出。 齿轮实验：测试不同的齿轮组合和升级。许多玩家还会模拟市场，查看物品对游戏进程的影响。 经济模拟：有些玩家喜欢模拟贸易、手工艺和基纳积累。如果您想测试 kinah 获取策略，私人服务器是最佳选择，因为您可以模拟大规模交易、物品种植，甚至使用 Aion 2 kinah 快速交付功能等快捷方式进行受控实验。 步骤 4：常见问题和解决方案 即使是经验丰富的玩家也会遇到常见问题。下面是几个问题及解决方法： 服务器崩溃：通常是由于服务器文件过时或不匹配造成的。确保服务器文件与客户端版本完全一致。 数据库错误：检查凭证和数据库名称。有时会丢失表结构；请重新运行初始化脚本。 延迟或性能缓慢：减少同时在线玩家或 NPC 的数量，并确保电脑符合推荐的规格。 连接问题：验证 IP 地址，在防火墙中打开端口，并确认客户端配置与服务器设置相匹配。 步骤 5：维护服务器 即使是测试，正确维护服务器也是非常有用的： 经常备份：定期备份数据库，避免丢失进度。 谨慎更新服务器文件：如果您下载了更新的版本，请在将其应用到主测试环境之前对其进行单独测试。 记录更改：记录对设置、技能或数据库所做的任何修改。这有助于排除意外行为的故障。 法律和道德方面的考虑 重要的是要记住，私人服务器存在于灰色地带。它们只能用于个人测试和学习，不得用于公开传播或商业目的。避免将私人服务器连接到官方账户，以保护您的数据并遵守游戏的服务条款。 建立一个私人 Aion 2 服务器是一种有效的学习和测试方法，而不会给您的主账户带来风险。按照这些步骤--准备正确的工具、安装服务器文件、配置客户端和维护服务器--您就可以安全地尝试使用技能、装备和游戏中的策略。对于对实际测试感兴趣的玩家来说，即使是像经济模拟这样复杂的过程，也可以在受控环境中进行处理，包括尝试有效管理游戏内货币的概念，如 Aion 2 kinah 快速交付。 私人服务器不仅有助于测试，还有助于更深入地了解游戏。只要有耐心、精心设置并注重细节，您就能在 Aion 2 中创造出改进游戏的宝贵工具。

UART 経由でさまざまな長さのデータを受信するにはどうすればよいでしょうか? おい ！ 私は s32k144 評価ボードを使用しており、MODBUS プロトコルを使用して UART 経由でデータを受信するために UART_PAL ライブラリを使用していました。while ループで非ブロッキング uart_receivedata() API を使用し、コールバックを使用して受信イベントをチェックし、データを受信していました。 受信するデータの長さが確実になるまでは問題なく動作していましたが、受信するデータの長さが固定されておらず、時間とともに変化する場合はどうすればよいでしょうか。 同様のスレッドをいくつか見ましたが、どのスレッドも絶対的な解決策を示していませんでした。適切な解決策をご指導ください。可能であれば、コードやスクリーンショットを提供してください。 スクリーンショットを添付しましたが、ここでは、switch ステートメント内で、受信されるデータの長さがさまざまなケースで不確実です。 解決策を教えてください@Robin_Shen よろしくお願いいたします。 アダルシュ。 Re: How to receive data of varying length over UART? こんにちは。485 で可変長データを受信する問題は解決したかお伺いしたいです。私も現在同じ問題に遭遇しており、解決できていません。 Re: How to receive data of varying length over UART? このガイドには記載されていないが、 @Robin_Shenが送信したリンクには記載されているものがもう 1 つあります。こちらにも記載させていただきます。 6.LPUART_DRV_StartReceiveDataUsingInt()関数でCTRL[IDLE]を有効にする このガイドを作成していただいた@Adarshnandaに心より感謝します。 Re: How to receive data of varying length over UART? HI 私はLPC804でUART経由でデータを受信しようとしています。mcuxpresso IDEsを使用していますが、どなたかコードを提供していただき、データを受信する手順を教えていただけませんか。 Re: How to receive data of varying length over UART? こんにちは@Robin_Shen 、 Threadをチェックしてみましたが、うまくいきました。唯一混乱する部分は、スレッドには DMA 経由でデータを受信することに関する回答がいくつかあり、割り込み経由でデータを受信することに関する回答もいくつかあることです。 INTERRUPTS を使用して UART_IDLE_LINE_RECEIVE を実装する場合に従うべき手順を簡単にまとめておきます。 LPUART ドライバを内部に追加する必要があることに注意してください。 1.LPUART_DRV_INIT 関数では、ペリフェラルレジスタを設定して IDLE LINE INTERRUPT を有効にし、IDLE フラグが設定される前に受信するアイドル文字の数を設定する必要があります。それについてはリファレンスマニュアルを参照してください。アイドル キャラクターを 8 人用に設定し、スクリーンショットをここに添付します。 2. LPUART_DRV_IRQHandler 内で、IDLE_LINE_DETECT フラグが設定されているかどうかを確認し、設定されている場合は関数 LPUART_DRV_RxIdleCallback を呼び出す必要があります (デフォルトでは存在しないため、ユーザーが定義する必要があります)。注意 - この関数は、IRQ_Handler の開始時に呼び出す必要があります。 3. ファイル (callbacks.h) の enum uart_event_t 内で、イベント UART_EVENT_IDLE_DETECT を定義します。 4. LPUART_DRV_RxIdleCallback を定義し、その関数プロトタイプを提供します。 5. その後、アプリケーションで使用できるようになります。 @Robin_Shen さん、ありがとうございます。これが他の人にも役立つことを願っています。 よろしくお願いいたします。 アダルシュ。 Re: How to receive data of varying length over UART? こんにちは、アダルシュさん 申し訳ありませんが、最近の S32K1 SDK/RTD ドライバーではアイドル検出は実装されていません。S32K144 LPUART IDLE ライン割り込み構成の説明を参照しましたか?LPUART アイドル ライン割り込みを取得するには、SDK ドライバを変更する必要があります。 よろしくお願いします、 ロビン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「正解としてマーク」ボタンをクリックしてください。ありがとう！ - スレッドは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいスレッドを開いて、閉じたスレッドを参照してください。 --------------------------------------------------------------------------------- Re: How to receive data of varying length over UART? 7. LPUART_DRV_GetReceiveStatus 関数が呼び出されて受信長が計算され、LPUART_DRV_AbortReceivingData 関数が呼び出されて最初のフレームが処理された後にデータの受信が再開され、受信バッファが 0 から開始されます。 これが私が追加したコンテンツです。デバッグは正常に完了しました。前回のコンテンツを共有してくださった専門家の皆様に感謝いたします。皆様、ありがとうございました。