i.MX AndroidクロスバージョンOTAに関する注意事項 本書について i.MX Androidでは、新しいAndroidバージョンで直接OTAパッケージをビルドし、それを旧バージョンのAndroidが動作しているデバイスに適用することは、実現できない場合があります。たとえば、i.MX Android-13.0.0_2.0.0リリースでビルドされたevk_8mm向けOTAパッケージは、i.MX Android-11.0.0_1.0.0でビルドされたイメージが動作しているevk_8mmボードには直接適用できません。 この記事では、まず、i.MX AndroidでクロスバージョンOTAが直接実行できない理由について説明します。次に、クロスバージョンOTAの前に考慮すべき点および実施すべき内容について説明します。 Googleがデバイスのシステムを更新する方法 Googleが初めてデバイスをリリースすると、そのデバイスは「ローンチデバイス」と呼ばれます。ローンチデバイスには以下があります： コードネーム。Pixel 3a XLを例に挙げると、コードネームはbonitoです Androidバージョン。Pixel 3a XLの場合、Android 9.0です カーネルバージョン。Pixel 3a XLの場合、4.9です PRODUCT_SHIPPING_API_LEVEL。Pixel 3a XLの場合、そのAndroidバージョンのSDKバージョンと同じ28に設定されています。 FCMターゲットレベル。Pixel 3a XL の場合は 3 です システムコードが新しいバージョンに更新された後、Pixel 3a XL向けにaosp_bonito-userまたはaosp_bonito-userdebugのランチターゲットを使用してOTAパッケージをビルドできます。このように更新されたデバイスを「レトロフィットデバイス」と呼ぶことにします。 コードネームは変更されていません。そのデバイス構成は、引き続き「device/google/bonito/」にあります。 Androidバージョン。OTAで更新されたバージョンです。Android 9、10、11、12の4つのバージョンがサポートされています。つまり、Pixel 3a XLは最大でAndroid 12までアップグレード可能です。「device/google/bonito/」はAndroid 9で導入され、Android 13で削除されました。 カーネルバージョン。OTA適用後も変更されません PRODUCT_SHIPPING_API_LEVEL。OTA では変更されないため、OTA 後、プロパティ「ro.product.first_api_level」の値は SDK バージョンと異なります。 FCMターゲットレベル。OTA適用後も変更されません。 FCMターゲットレベルはデバイスのmanifest.xmlに定義されており、特定のバージョンのsystem compatibility.matrix.xmlに対応しています。したがって、FCMターゲットレベルが変更されない場合、このデバイスによって提供されるHALに大きな変更を加える必要はありません。 これは、Google が自社のデバイスのシステムを維持する方法です。これは、i.MX Android デバイスが維持される方法ではありません。 保守対象デバイスに対するi.MX Androidのシステム更新方法 保守対象のi.MXデバイスに対してコードが新しいバージョンに更新されると、すべてのデバイスは「ローンチデバイス」として扱われます。そのため、以前のバージョンと比較して、新しいシステムでは以下のような変更があります： カーネルバージョンが変更されました PRODUCT_SHIPPING_API_LEVELが変更されました FCM のターゲットレベルが変更されました。 物理パーティションが変更される場合もあります。 FCMターゲットレベルが変更される場合、このデバイスが提供するHALに大きな変更が加わる可能性があります。 PRODUCT_SHIPPING_API_LEVELが変更されると、プロパティ「ro.product.first_api_level」に基づく多くのコードロジックが異なる処理フローで実行されることになります。 パーティションの変更がある場合、更新後のコードで直接ビルドされたOTAパッケージは、適用できないことがよくあります。たとえば、新しいパーティション用のイメージは、旧システムが動作しているボードには適用できません。旧システムにはそのイメージ用のパーティションが存在しないためです。 OTA中に変更できない項目 クロスバージョンOTAが直接実行できない理由を明確にするためには、OTA中に変更できない項目があることを理解しておく必要があります。 1.OTA中は物理パーティションを変更することはできません。 関連する機能は以下のとおりです。 *動的パーティション * gki * ブートヘッダーバージョン 2.userdata パーティションのユーザーデータは変更しないでください。変更すると、OTA中にデータが失われる可能性があります。 関連する機能は以下のとおりです。 * 暗号化オプション 新しいバージョンのAndroidが、古いバージョンのAndroidで暗号化されたデータを認識できるようにするため、暗号化オプションは変更するべきではありません。 一部のfs_mgr暗号化オプションでは、product_shipping_api_levelがカーネルに渡される最終的な暗号化パラメータに影響を与えます。次のコードをご覧ください。同じfs_mgr暗号化オプションでも、first_api_levelが異なると、Androidバージョンごとに最終的な暗号化パラメータが異なります。 android10 system/extras/libfscrypt/fscrypt.cpp if (filenames_encryption_mode == FS_ENCRYPTION_MODE_AES_256_CTS) { // Use legacy padding with our original filenames encryption mode. return FS_POLICY_FLAGS_PAD_4; } else if (filenames_encryption_mode == FS_ENCRYPTION_MODE_ADIANTUM) { // ...snip... return (FS_POLICY_FLAGS_PAD_16 | FS_POLICY_FLAG_DIRECT_KEY); } // ...snip... return FS_POLICY_FLAGS_PAD_16; android11 system/extras/libfscrypt/fscrypt.cpp if (!is_gki && options->version == 1 && options->filenames_mode == FSCRYPT_MODE_AES_256_CTS) { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_4; } else { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_16; } android12 system/extras/libfscrypt/fscrypt.cpp if (first_api_level <= __ANDROID_API_Q__ && options->version == 1 && options->filenames_mode == FSCRYPT_MODE_AES_256_CTS) { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_4; } else { options->flags |= FSCRYPT_POLICY_FLAGS_PAD_16; } fscryptのバージョンも結果に影響します。指定されていない場合、「product_shipping_api_level <= 29」であれば、デフォルトの「version」は「v1」になり、それ以外の場合は「v2」になります。 「casefold」や「project id」などの一部の fscrypt 機能は fscrypt「v2」に依存します。これらの機能は、「device/nxp」に「$(call inherit-product, $(SRC_TARGET_DIR)/product/emulated_storage.mk)」を含めることで有効になります。fscrypt「v1」を使用する場合は、「emulated_storage.mk」を含めないでください。 * userdataパーティションのファイルシステムタイプ ext4（i.MX Android 13.0.0 より前で使用） f2fs（i.mx android 13.0.0から使用） * userdata パーティション上のエミュレーテッドストレージのファイルシステム sdcardfs ヒューズ 3. miscパーティション内のブート制御情報は、OTAの前後で認識される必要があります。 関連する機能は次のとおりです。 *ブートコントロールHAL 4。U-Bootがカーネルに渡すブート引数は、ブートローダーが更新されない限り変更できません 関連する機能は次のとおりです。 * bootconfig は、Android 12.0.0_1.0.0以降でブート引数を渡すために使用されます。vendor boot header v4とともに使用されます。   デュアルブートローダーまたはpostinstallが使用されている場合、ブートローダーの更新が可能であることを理解しておく必要があります。 これらの関連機能について、Googleは「レトロフィットデバイス」向けには実装や変更を行っておらず、「ローンチデバイス」向けの機能変更のみに対応しています。これにより、ローンチデバイスではクロスバージョンOTAの直接適用が可能になります。これは、OTA中に変更できない項目が Androidバージョン間で共通であるためです。 i.MX Androidでは、すべての保守対象デバイスに新機能を実装するため、Androidの新しいバージョンへの更新時に、OTA中に変更可能な項目が変更されることがよくあります。これにより、クロスバージョンOTAの直接適用は実現できなくなります。   参照用として、以下に主な機能変更の履歴を記載します。 * 物理パーティションの変更履歴   P9.0.0_2.3.0 10.0.0_1.0.0 10.0.0_2.0.0 11.0.0_1.0.0 12.0.0_1.0.0 12.1.0_1.0.0 13.0.0_1.0.0 14.0.0_1.0.0 bootloader_a/b 4MB 4MB 4MB 4MB 4MB 16MB 16MB 16MB dtbo_a/b 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB boot_a/b 48MB 48MB 64MB 64MB 64MB 64MB 64MB 64MB init_boot_a/b - -   -   - 8MB 8MB vendor_boot_a/b - -   64MB 64MB 64MB 64MB 64MB misc 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB metadata 2MB 2MB 2MB 2MB 16MB 16MB 64MB 64MB presistdata 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB 素晴らしい - - 7168MB 3584MB 4096MB 4096MB 4096MB 4096MB fbmisc 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB vbmeta_a/b 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB system_a/b 2560MB 1536MB - -   - - - vendor_a/b 256MB 512MB - -   - - - product_a/b - 1792MB - -   - - -   boot_a/b：48MB → 64MB（デバッグオプションの有効化によりイメージサイズが増加） vendor_boot_a/b：boot header v3。GKI機能を有効にするには、vendor bootおよびboot header v3が必須です。 init_boot_a/b：ramdisk内のinitバイナリがboot.imgからinit_boot.imgに移動されました。GoogleからのGKIイメージを書き込んでも、initに対するベンダーの変更には影響しません。   metadataパーティションについて： 2MB → 16MB（VTSの要件：「-m vts_gsi_boot_test -t MetadataPartition#MinimumSize」） 16MB → 64MB（パーティションをF2FSとしてフォーマットするには32MBでは足りないため、64MBが使用されます。） metadataパーティションは、ユーザーデータチェックポイント機能を有効にした際にAndroid 11で初めてマウントされました。 * GKI機能の変更履歴 Android 11で初めて導入されました。一部のコードはモジュールとしてビルドされ、vendor_boot_a/bパーティションに配置されます。vendor_boot_a/bパーティションもAndroid 11で初めて導入されました。 GKIのプリビルドバイナリはAndroid 12から統合されました。   i.MX AndroidのクロスバージョンOTA処理方法 手順は以下のとおりです OTAベースコードとOTAターゲットコードのパーティションを一致させます 製品が開発段階にあり、OTAベースコードの修正が可能な場合： OTAベースコードでパーティションを予約します。たとえば、Android 10から11へのOTAを行う場合、vendor_boot.imgがなくても、Android 10のパーティションテーブルでvendor_bootパーティションを予約しておきます。このパーティションを更新できるように、update_engineに対する SELinux ルールを変更します。 OTAターゲットコードと同様に、OTAベースコード内の一部のパーティションを拡張します。たとえば、Android 13ではブートローダーパーティションが16MBです。Android 12 から Android 13 への OTA を行う際、Android 12 のコードを修正できる場合は、ブートローダーパーティションを 16MB に拡張してください。 OTA中にuserdataおよびmetadataパーティションのデータは変更されないため、OTAターゲットコードでのuserdataおよびmetadataパーティションのマウントオプションは、OTAベースコードと同一にしてください。 製品パーティションがすでに出荷されている場合、修正できるのは OTAターゲットコードのみです。 OTA中にuserdataおよびmetadataパーティションのデータは変更されないため、OTAターゲットコードでのuserdataおよびmetadataパーティションのマウントオプションは、OTAベースコードと同一にしてください。 OTAベースコードに合わせてパーティションサイズを変更してください。 vendor_bootやinit_bootなどのパーティションは、削除が必要になる場合があります。 削除または変更されたパーティションに関連する機能を削除または変更する デュアルブートローダーを使用しない場合： 最近のAndroidバージョン更新では、vendor_bootおよびinit_bootパーティションが追加されており、これはブートイメージヘッダーのバージョンに関連しています。これらのパーティション内のイメージはU-Bootによって読み込まれ、検証されます。そのため、デュアルブートローダーを使用しない場合、これらに関連するU-Bootコードを変更する必要があります。U-Boot内の「struct boot_img_hdr」に関連するコードを確認してください。 OTAベースコードとOTAターゲットコードの間で、A/Bスロットメタデータのフォーマットが変更されている可能性があります。この A/Bスロットメタデータには、Androidのbootctrl HALとU-Bootの両方がアクセスします。デュアルブートローダーが使用されていないためU-Bootは更新されず、更新されたAndroidのbootctrl HALも同じフォーマットでファイルにアクセスする必要があります。 ポストインストールメカニズムを使用して uboot イメージを更新することができますが、更新に失敗した場合のフォールバックがないため、リスクを評価する必要があります。 OTAパッケージが適用可能かどうか、および更新後のシステムが起動できるかどうかを確認してください。 失敗例：Android 10からAndroid 12へのOTAにおいて、PRODUCT_SHIPPING_API_LEVEL (ro.product.first_api_level) が原因でシステムが起動に失敗しました。値の違いにより、userdataパーティションに異なる暗号化オプションが使用されます。そのため、PRODUCT_SHIPPING_API_LEVELの値は、OTAベースコードと同じ値に変更する必要があります。 PRODUCT_SHIPPING_API_LEVELを変更すると、device manifest.xmlおよびcompatibility_matrix.xmlの変更を含め、FCMターゲットバージョンおよび関連するHALの変更も必要になる場合があります。FCMターゲットバージョンの変更に伴い、どのような変更が加えられたかを確認するため、コミット履歴をチェックする必要があります。   動的パーティションに関して、注意すべき点があります。 動的パーティションを使用していないイメージから、動的パーティションを使用するイメージへのOTA： Android 10.0.0_2.0.0のコードを参照すると、10.0.0_1.0.0から10.0.0_2.0.0 のアップデート手順が示されています。0.0.0_1.0.0では、動的パーティションは有効化されていません。変数「TARGET_USE_RETROFIT_DYNAMIC_PARTITION」および関連する設定を確認してください。 動的パーティションから仮想A/BへのOTA（例：Android 10からAndroid 11へのOTA） 「build/make/target/product/virtual_ab_ota_retrofit.mk 」を継承します。 Android 10からAndroid 11に初めてOTA アップデートを行う際には、「build/make/target/product/virtual_ab_ota_retrofit.mk」を継承し、動的パーティションが使用されるようにBOARD_NXP_DYNAMIC_PARTITIONS_SIZEが設定されます。 2回目のOTAでは、デバイスがVirtual A/Bレトロフィット機能付きのAndroid 11を実行しています。今回はクロスバージョンではないOTAとなり、「build/make/target/product/virtual_ab_ota.mk」を継承します。代わりに、仮想A/B機能が使用される場合、BOARD_NXP_DYNAMIC_PARTITIONS_SIZEを設定できます。 動的パーティションにアップグレードされたデバイスは、仮想 A/B を後付けすることができません。 OTAターゲットコードにvendor_dlkmなどの新しい動的パーティションがある場合、追加の変更は必要ありません。 次に、お客様側で、品質を保証するために xTS のフルテストを実施する必要があります。  

关于 i.MXRT 的 FlexSPI 和 SEMC 接口上 DQS 引脚的所有须知信息 我们经常收到有关 i.MXRT 上 DQS 引脚的疑问，包括其使用方法、具体功能以及为何使用它很重要。 本文档旨在解答这些常见问题，并指出连接该引脚时最常见的错误。 首先，我们来明确 DQS 信号的作用：DQS 是 “数据选通信号” (Data Strobe) 的缩写，它是数据线的时钟信号，用于解决存储器读取过程中的一个关键问题。控制器必须先将时钟传输到存储器（这需要 x 纳秒），然后存储器再将数据位发送回控制器（这又需要 x 纳秒）。这种时钟偏移 (clock skew) 会限制传输速度，而 DQS 正是为解决这一问题而设计的。 在iMXRT系列中，它存在于FlexSPI和SEMC接口上，您可以连接多个存储器。它还允许有多种配置，因为并非所有存储器都提供DQS信号。 下一节将详细介绍每个内存接口的具体配置，将使用RT1170的数据，但RT10xx系列的信息也适用。 SEMC SEMC 在 DQSMD 寄存器中针对 DQS 焊盘有两种配置。   当 DQSMD = 0 时：我们无法确定可达到频率的具体最大值/最小值，只知道在此模式下，SDRAM 无法达到 SEMC 的最高频率。此模式下的频率可能会有差异。无法以最高 200MHz 1 的频率运行并满足数据手册中的输入时序规范，因此需要降低时钟频率以确保仍能满足时序要求，这取决于所使用存储器的数据输出延迟规范。 当 DQSMD = 1 时：由于信号延迟在 DQS 焊盘中计算，此模式下可达到 200MHz 1 的频率。请注意，该引脚需要悬空，或在特殊情况下（如下文将讨论的）施加额外电容。 由于SDRAM设备不输出DQS信号，因此将DQS引脚用作环回，测量信号延迟，并利用该延迟进行补偿以获得正确的数据选通点。这种方法可以覆盖大多数应用场景并实现良好的性能。然而，如果外部信号延迟较大，且拓扑结构复杂、走线较长，则无法通过DQS引脚的延迟来补偿外部SDRAM信号的延迟。 调整延迟有两种方法：第一种是使用延迟链控制寄存器（DCCR），另一种是在DQS引脚上添加电容。遗憾的是，由于这与SDRAM信号布局相关，不同的布局会导致不同的信号延迟，因此无法通过公式计算寄存器值和电容值。 在某些特殊情况下，当为 RT1xx 系列添加 3 个以上的 SDRAM 时，由于存储器的总电容超过了焊盘电容，导致无法在最高速度下使用存储器；这个问题通过在 DQS 引脚上增加额外的电容得到了解决。   FlexSPI FlexSPI 的 DQS 引脚功能与 SEMC 上的类似，但在可用配置和最高速度方面存在一些差异。 对于FlexSPI设备，有三种不同的配置模式由MCR0寄存器中的RXCLKSRC字段控制。 RXCLKsrc=0x0 （内部虚拟读取选通和内部回环） 在这种模式下，DQS 引脚不被使用，因此可以为该引脚配置替代功能，但由于无法满足最高速度的时序要求，所达到的频率是最低的。   RXCLKsrc=0x1（内部虚拟读选通和来自 DQS 焊盘的环回） 在这种模式下，FlexSPI 会使用 DQS 引脚，且该引脚必须配置为 FlexSPI 功能，在这种模式下不能将其用于其他用途。内部生成的读选通被发送到 DQS 引脚，并在该引脚处被采样，以更紧密地匹配数据引脚的时序。使用内部虚拟读选通环回进行采样的时序与来自焊盘的环回时序非常相似，但它能实现比内部环回更高的频率，不过并非最高频率。 与SEMC侧描述的情况类似，存在一些特殊情况，例如信号延迟较大、设计拓扑结构复杂或走线较长，此时的解决方案是为DQS焊盘添加额外电容。由于这取决于具体设计，因此无法通过公式计算所需的电容值。   RXCLKsrc=0x3 (闪存提供的读选通) 在此模式下，DQS 信号由所连接的存储器提供，该模式允许存储器以最高频率运行，但只有特定的存储器会提供此信号。FlexSPI 控制器将读选通延迟串行根时钟的半个周期（借助 DLL），然后使用延迟后的选通信号对读取的数据进行采样。 结束语 i.MXRT 系列通常会使用外部存储器来执行代码或访问重要数据，而这些场景都需要设备具备良好的性能。为了优化存储器的访问速度，DQS 信号是必不可少的，因为它可能会限制速率。 1 有关详细速率，请参考具体器件的数据手册。 i.MXRT 106x

i.MX8DXL OpenDDS do_packageエラー Hello, Yocto Scarthgapバージョンのbitbakeを始めました。私は自分のディストリビューションにmeta-openddsレイヤーを追加しました。 OpenDDSからレイヤーをクローンし、レイヤーをbblayers.confファイルに追加しました。 私は "IMAGE_INSTALL:append = "opendds" として local.conf ファイルに OpenDDS を追加しました しかし、bitbakeを起動すると、 opendds-3.29.1-r0 do_package stepで次のエラーが発生します。 このエラーの後、yocto イメージは作成されますが、opendds の  subscriber または publisher example アプリケーションはどれも rootfs に追加されません。 エラーログ: エラー:opendds-3.29.1-r0 do_package:opendds-dev:libTAO_Valuetype.so.2.5.21の複数のshlibプロバイダー:opendds-dev、opendds(ファイルで使用:\/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/DCPS/FindTopic/findtopic) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libOpenDDS_Dcps.so.3.29.1の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:\/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/DCPS/FooType/libDcpsFooType.so.3.29.1) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libTAO_Valuetype.so.2.5.21の複数のshlibプロバイダー:opendds-dev、opendds(ファイルで使用:/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/security/IDL_Serialization/Security_IDL_Serialization) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libACE.so.6.5.21の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/ACE_wrappers/TAO/tao/PI/libTAO_PI.so.2.5.21) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libOpenDDS_Rtps.so.3.29.1の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:\/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/DCPS/RtpsDurableReplay/publisher) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libTAO_PortableServer.so.2.5.21の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/ACE_wrappers/TAO/orbsvcs/ImplRepo_Service/tao_imr) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libOpenDDS_Dcps.so.3.29.1の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/DCPS/Reliability/IDL/libReliability.so.3.29.1) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libOpenDDS_Dcps.so.3.29.1の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/DCPS/Prst_delayed_subscriber/publisher) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libOpenDDS_Dcps.so.3.29.1の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/security/ConcurrentAuthLimit/ConcurrentAuthLimit) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libACE.so.6.5.21の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/DCPS/KeyTest/IsBounded) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libTAO.so.2.5.21の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/FACE/CallbackAndReceive/Publisher/publisher) エラー:opendds-3.29.1-r0 do_package:opendds-dev:libACE.so.6.5.21の複数のshlibプロバイダー:opendds、opendds-dev(ファイルで使用:\/home/yocto/yocto-nxp/build-nxp/tmp/work/armv8a-poky-linux/opendds/3.29.1/packages-split/opendds-dev/usr/share/DDS_ROOT/tests/DCPS/LivelinessTimeout/publisher) これらのエラーを助けていただけませんか? よろしくお願いいたします。 i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Yocto Project Re:i.MX8DXL OpenDDSのdo_packageエラー Hi @pengyong_zhang, 応援いただき、誠にありがとうございました。 以下のリンクのGitHubの問題のおかげで、KirkstoneのOpenDDS 3.24 do_packageの問題を解決しました。 Link: https://github.com/OpenDDS/meta-opendds/issues/47 よろしくお願いいたします。 Re:i.MX8DXL OpenDDSのdo_packageエラー HI @cebel  これは、opendds-dev パッケージに複数の共有ライブラリ (shlib) プロバイダがあり、ファイルの競合を引き起こす可能性があるためです。具体的な問題は、複数のライブラリファイル(libACE.so、libOpenDDS_Dcps.so、など)複数のパッケージによって提供される場合があり、ビルド中に競合が発生します。 解決策の提案を次に示します。 1. OpenDDS パッケージの依存関係をチェックして、重複する依存関係ライブラリ ファイルがないことを確認します。 2. Yocto の設定をチェックして、すべてのライブラリ ファイルが正しくリンクされていることを確認します。 3. Yoctoの依存関係管理ツールを使用して、ライブラリファイルの競合を解決します。 B.R

imx7d android-pie 上的 android UI 格式不匹配问题 Hi, 我正在将新的 LCD 移植到我的 imx7d DIY 开发板上。 kernel: 4.14 android: 9 屏幕尺寸为320x240，物理格式为RGB565。我遇到了一个非常奇怪的问题。主屏幕和一些Android应用程序可以正确显示。但有些android应用程序没有刷新。 如果我进一步调试，我可以在 FbDisplay.cpp 中找到，updateScreen()函数报告缓冲区格式为RGBA8888，但配置格式为RGB565，因此停止刷新操作。 如果我强迫 getBE().mRenderEngine = RE::impl::RenderEngine::创建（HAL_PIXEL_FORMAT_RGBA_8888 是 getBE().mRenderEngine = RE::impl::RenderEngine::创建（HAL_PIXEL_FORMAT_RGB_565 这些Android应用程序可以在屏幕上显示，但是红色和蓝色像素是相反的。如果我使用这种方法，我就无法监控我的电脑上的屏幕。 我想知道什么原因导致了这种格式不匹配的问题以及如何完美地解决它？ 回复：imx7d android-pie 上的 android UI 格式不匹配问题 嗨志明， 谢谢你的建议。我已经找到解决该问题的方法。通过在 kotlin 项目中旋转屏幕方向。可能是布局高度太长，Android 框架无法调整大小。我应该改变布局中的宽度：高度。 此致敬礼！ PatrickZ 回复：imx7d android-pie 上的 android UI 格式不匹配问题 你好， 我对SurfaceFlinger的理解是， SurfaceFlinger 是一个渲染引擎，它接收来自应用层的操作，然后调用 fbdisplay 进行显示。所以问题可能出在应用层，应用程序告诉渲染引擎如何渲染一帧。我认为渲染引擎不是为一种像素格式设计的，像素格式应该在应用层设置。 此致， 志明 回复：imx7d android-pie 上的 android UI 格式不匹配问题 嗨志明， 你的意思是 android kotlin 应用程序可能有问题吗？Fbdisplay 中的 config.format 是正确的，我认为问题出在 surfaceflinger 上。buffer.format 保持为 RGBA8888。 此致敬礼！ 张先生 回复：imx7d android-pie 上的 android UI 格式不匹配问题 Hello, 这可能与出现问题的应用程序的代码有关，该应用程序使用的是32位数据，因此在HAL层代码中返回的是RGB888。您需要再次查看应用程序的代码以尝试解决问题。 https://github.com/nxp-imx-android/android-imx_platform_hardware_imx/blob/p9.0.0_2.3.4/display/display/FbDisplay.cpp#L457C1-L462C6 此致， 志明

LT9611UXC i.MX8 演示板   任何想要使用该解决方案的人都应从 Lontium 获取参考设计和固件。 硬件 以下是 LT9611UXC 演示板的框图。 由于我们的EVK的MIPI端口可以提供5V、3V3和1V8电压，因此我们可以从参考设计中移除无用的DC-DC芯片。 下面是 LT9611UXC 演示板。 软件 将固件下载到 LT9611UXC 中。在 Linux 端，我们需要驱动 MIPI 以输出 1080P 标准时序的信号。 面板类型 diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts index 1732b5c72380..c6a829be541f 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts @@ -696,13 +716,17 @@ &ldb_phy { &mipi_dsi { status = "okay"; + panel@0{ + compatible = "nxp,lt9611uxc"; + reg = <0>; + status = "okay"; }; }; &snvs_pwrkey { diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 4f78bbf63f33..90d99f12515b 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -4997,6 +4997,34 @@ struct panel_desc_dsi { unsigned int lanes; }; +static const struct drm_display_mode lt9611_panel_mode = { + .clock = 148500, + .hdisplay = 1920, + .hsync_start = 1920 + 88, + .hsync_end = 1920 + 88 + 44, + .htotal = 1920 + 88 + 44 + 148, + .vdisplay = 1080, + .vsync_start = 1080 + 4, + .vsync_end = 1080 + 4 + 5, + .vtotal = 1080 + 4 + 5 + 36, +}; + +static const struct panel_desc_dsi lt9611_panel = { + .desc = { + .modes = &lt9611_panel_mode, + .num_modes = 1, + .bpc = 8, + .size = { + .width = 62, + .height = 110, + }, + .connector_type = DRM_MODE_CONNECTOR_DSI, + }, + .flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_NO_EOT_PACKET | MIPI_DSI_MODE_VIDEO_SYNC_PULSE, + .format = MIPI_DSI_FMT_RGB888, + .lanes = 4, +}; + static const struct drm_display_mode auo_b080uan01_mode = { .clock = 154500, .hdisplay = 1200, @@ -5201,6 +5229,9 @@ static const struct panel_desc_dsi osd101t2045_53ts = { static const struct of_device_id dsi_of_match[] = { { + .compatible = "nxp,lt9611uxc", + .data = &lt9611_panel, + },{ .compatible = "auo,b080uan01", .data = &auo_b080uan01 }, { 图形与显示 i.MX 8 系列 | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Yocto Project

i.MX8 用 LT9611UXC デモボード   このソリューションを使用したい方は、Lontium からリファレンス・デザインとファームウェアを入手する必要があります。 ハードウェア こちらがLT9611UXCデモボードのブロック図です。 当社の EVK の MIPI ポートは 5V、3V3、1V8 を供給できるため、リファレンス・デザインから不要な DC-DC チップを削除できます。 以下はLT9611UXCデモ・ボードです。 ソフトウェア ファームウェアを LT9611UXC にダウンロードしてください。Linux 側では、MIPI を駆動して 1080P の標準タイミングで信号を出力する必要があります。 パネル・タイプ diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts index 1732b5c72380..c6a829be541f 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts @@ -696,13 +716,17 @@ &ldb_phy { &mipi_dsi { status = "okay"; + panel@0{ + compatible = "nxp,lt9611uxc"; + reg = <0>; + status = "okay"; }; }; &snvs_pwrkey { diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 4f78bbf63f33..90d99f12515b 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -4997,6 +4997,34 @@ struct panel_desc_dsi { unsigned int lanes; }; +static const struct drm_display_mode lt9611_panel_mode = { + .clock = 148500, + .hdisplay = 1920, + .hsync_start = 1920 + 88, + .hsync_end = 1920 + 88 + 44, + .htotal = 1920 + 88 + 44 + 148, + .vdisplay = 1080, + .vsync_start = 1080 + 4, + .vsync_end = 1080 + 4 + 5, + .vtotal = 1080 + 4 + 5 + 36, +}; + +static const struct panel_desc_dsi lt9611_panel = { + .desc = { + .modes = &lt9611_panel_mode, + .num_modes = 1, + .bpc = 8, + .size = { + .width = 62, + .height = 110, + }, + .connector_type = DRM_MODE_CONNECTOR_DSI, + }, + .flags = MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_NO_EOT_PACKET | MIPI_DSI_MODE_VIDEO_SYNC_PULSE, + .format = MIPI_DSI_FMT_RGB888, + .lanes = 4, +}; + static const struct drm_display_mode auo_b080uan01_mode = { .clock = 154500, .hdisplay = 1200, @@ -5201,6 +5229,9 @@ static const struct panel_desc_dsi osd101t2045_53ts = { static const struct of_device_id dsi_of_match[] = { { + .compatible = "nxp,lt9611uxc", + .data = &lt9611_panel, + },{ .compatible = "auo,b080uan01", .data = &auo_b080uan01 }, { グラフィックスとディスプレイ i.MX 8ファミリ | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Yocto Project

U-bootにi.MX93 LVDSドライバを追加   はじめに プラットフォーム: i.MX93 EVK Uboot: origin/lf_v2022.04(lf-6.1.1-1.0.0) i.MX93のLVDS設計とメディアブロック制御は、i.MX8MPlusと非常によく似ています。この記事では、U-bootにおいてドライバを実装します。 U-bootにadp5585のPWMドライバを実装する、0001-Add-fake-adp5585-pwm-driver.patchを適用する必要があります。これは、PWMドライバフレームワークのみを実装するフェイクのPWMドライバです。現時点では、PWM値を使用して明るさを調整することはできませんが、バックライトを有効にするにはこれで十分です。 その後、0002-Add-imx93-lvds-and-panel-driver.patch を適用してください。このパネルにはNXPのロゴが表示されます。 https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/dy1212w-4856:DY1212W-4856 ポーティングに関するヒント 1. drivers/video/simple_panel.c でパネルのタイミングを変更します。 /* define your panel timing here and * copy it in simple_panel_get_display_timing */ static const struct display_timing boe_ev121wxm_n10_1850_timing = { .pixelclock.typ = 71143000, .hactive.typ = 1280, .hfront_porch.typ = 32, .hback_porch.typ = 80, .hsync_len.typ = 48, .vactive.typ = 800, .vfront_porch.typ = 6, .vback_porch.typ = 14, .vsync_len.typ = 3, }; static int simple_panel_get_display_timing(struct udevice *dev, struct display_timing *timings) { memcpy(timings, &boe_ev121wxm_n10_1850_timing, sizeof(*timings)); return 0; } 2.VIDEO_PLLを変更する VIDEO_PLLは、ピクセルクロックの7倍になります。デフォルトパネルの場合、ピクセルクロックは71.143MHzで、VIDEO_PLLは498MHzです。 static struct imx_fracpll_rate_table imx9_fracpll_tbl[] = { FRAC_PLL_RATE(1000000000U, 1, 166, 4, 2, 3), /* 1000Mhz */ FRAC_PLL_RATE(933000000U, 1, 155, 4, 1, 2), /* 933Mhz */ FRAC_PLL_RATE(700000000U, 1, 145, 5, 5, 6), /* 700Mhz */ FRAC_PLL_RATE(498000000U, 1, 166, 8, 0, 1),/* rate, rdiv, mfi, odiv, mfn, mfd */ FRAC_PLL_RATE(484000000U, 1, 121, 6, 0, 1), FRAC_PLL_RATE(445333333U, 1, 167, 9, 0, 1), FRAC_PLL_RATE(466000000U, 1, 155, 8, 1, 3), /* 466Mhz */ FRAC_PLL_RATE(400000000U, 1, 200, 12, 0, 1), /* 400Mhz */ FRAC_PLL_RATE(300000000U, 1, 150, 12, 0, 1), }; 3. dts の lcdif ノードを変更します。 <498000000>, <71142857>, <400000000>, <133333333>; , , <MEDIA_AXI>,<MEDIA_APB> &lcdif { status = "okay"; - assigned-clock-rates = <484000000>, <121000000>, <400000000>, <133333333>; + assigned-clock-rates = <498000000>, <71142857>, <400000000>, <133333333>; };

NFCデモ - 情報、ソース・コード、回路図 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 近距離無線通信（NFC）はすでに15億台以上のスマートフォンに搭載されています。決済やアクセス制御などのよく知られたアプリケーションはNFCによって実現されていますが、今まさに登場しつつある新たな革新的ユースケースもあります。 この記事では、Nürnbergで開催された「embedded world 2018」で初めて展示された当社のNFCデモに関する詳細情報、背景、およびハウツーガイドをご紹介します。あらゆる場所にNFCを導入するヒントにお役立てください。 アクセサリーと消耗品 アクセサリーや消耗品の識別と認証により、製品に大きな価値が付加されますが、その仕組みを初めてライブでご紹介します。デモでは、ドリルビット、標準のマイナスドライバーとプラスドライバーの3種類の工具のNFCを使用したツールの識別をご説明します。各工具にはNTAG213 NFCタグが組み込まれており、電動ドリルにはNFCリーダー（CLRC663plus）が搭載されています。工具を挿入するとすぐに本体が工具の種類と使用状況（摩耗）を読み取ります。この情報に基づいて、非純正または摩耗したツールを拒否し、工具の種類に応じて最大/最小速度などの内部設定を調整することができます。 このデモは、当社のパートナーであるGMMCの最新のNFC Nutshellキットを基にしており、このキットを使用して既存の製品にNFCを簡単に追加する様子を示しています。 こちらでアクセサリーおよび消耗品の識別と認証に関する詳細な説明をご覧ください：https://community.nxp.com/docs/DOC-340283 パラメータ設定、診断、ファームウェア・アップデート このデモでは、NFC電話を使用してDINレールモジュール（またはその他の電子機器）をパラメータ化/構成する方法を示します。モジュールが完全に電源が入っていない場合でも可能です。スマートフォン・アプリを使用すると、ランプの動作やディスプレイの言語を設定することができます。簡単なタップによる設定の後、主電源をオンにすると、デバイスは設定通りに起動します。また、NFCを使用すると、デバイスの電源がオンかオフかに関係なく、診断データを読み取ることができます。したがって、サービスUARTをNFCに置き換えることも可能です。3つ目は、デモでNFCを使用してファームウェアをフラッシュすることがどれほど簡単かを示します。繰り返しますが、これはデバイスの電源がオフになっている場合でも機能します。 このアプリケーションは、NTAG I²C plus パッシブ接続タグ IC に基づいています。   詳細な説明とすべてのソースコードはこちら：https://community.nxp.com/docs/DOC-333834でご覧いただけます。商用製品での動作にご関心をお持ちの場合は、NFCを介してSchneider Zelio NFCタイマー・リレーを簡単に設定する方法を示すこちらのビデオをご覧ください。 アクセス管理 アクセス管理コーナーでは、NXP NFCとBLEソリューションを通じて住宅またはホスピタリティ・アプリケーション向けの究極の非接触型接続をご説明し、カード、モバイル・デバイス、ウェアラブル上のMIFARE ® DESFire ® 認証情報による優れた非接触型体験とセキュリティをご紹介します。 当社のデモンストレーターは、オールインワンのフルNFCコントローラーであるPN7462ファミリー、低消費電力のBLEシステムオンチップであるQN9021、および自動キャリブレーション機能を備えた静電容量式近接スイッチであるPCF8883Tを基にしており、非常に低い消費電力を実現しています。 また、当社のパートナーによる2つの商用製品を紹介しています。 1) 使いやすく非常に効率的なアクセス制御システムのSalto XS4レンジのスマート・ドアロック。 2) 小型NFCリーダー・ボードを使用した、Kroneggerのモジュール式アクセス制御ソリューション。 また、既存のHVQFN64パッケージを補完する、PN7462ファミリー用の新しいBGAパッケージ（VFBGA64、4.5x4.5mm²）をベースにした非常に小さなフットプリントの完全なリーダー・ボードも公開します。   NFC Tandem - 世界最良の二品 電源が入っている状態と入っていない状態の両方でNFC機能が必要な場合は、NFC Tandemのデモをご覧ください。NFCリーダー（PN7150）とパッシブ接続のNFCタグ（NTAG I²C plus）が1つのアンテナを共有しています。ユーザーは、デバイスの電源がオフの状態で（NTAG I²C plusを使用して）デバイスとやりとりすることができます。デバイスの電源が入ると、カード、タグ、またはその他の接続されたタグを読み取ることができます。 設計ファイル、ユーザー・マニュアル、その他の資料のダウンロードはこちら：https://community.nxp.com/docs/DOC-340244 シングルチップ統合ソリューション：パッシブNFCインターフェースを備えたLPC8N04 MCU このデモでは、最新の統合NFCソリューションであるLPC8N04、統合（パッシブ）NFC接続を備えたコスト効率の高いMCUをご紹介します。このMCUは、複数のパワーダウン・モードや最高8MHzまで選択可能なCPU周波数など、さまざまな機能を搭載しており、超低消費電力を実現できます。 このデモは、概念的な時計形式で機能をご紹介します。 - NFC対応の電話で時計の現在の時刻/日付を簡単に設定 - オプションのアラーム機能、Androidアプリを使用してプログラムおよび制御できるリアルタイムクロック - GPIO制御の棒グラフでプログラム可能な「安全動作範囲」を表示 - I2C制御のOLEDユーザー・ディスプレイ - Androidアプリを使用して構成されたデータ（温度）ログ このデバイスの詳細については、www.nxp.com/LPC8N04をご覧ください。 シングルチップ統合ソリューション：NTAG SmartSensor NTAG SmartSensor を使用すると、消費者やブランド所有者は、魚、ワイン、医薬品などの温度に敏感な製品が適切に取り扱われていることを確認できます。NTAG SmartSensorを使用すると、アイテム・レベルで温度を検知できるため、個々の製品が安全に使用できるかどうかを確認できます。NFCスマートフォンを1回タップするだけで、NTAG SmartSensorの温度履歴を読み取ることができます。 NTAG SmartSensorの詳細については、当社のウェブページをご覧いただくか、ビデオをご覧ください。 NTAG SmartSensorを使用した既製のロガーをお探しの場合は、NTAG SmartSensorベースのロガーを提供しているメーカーのリストをご覧ください。 電子棚札 NFC対応の電子棚札（ESL）を使用すると、価格の誤表示、不透明なプロセス、顧客とのやり取り不足がもはや発生しなくなります。このデモでは、2社のラベルをご紹介します。SES Imagotagの商用電子棚札とMpicoSysのePaperラベルです。 詳細については、NXPのシニア・マーケティング・マネージャーであるFabrice Punchの記事をご覧ください。 ePaperラベルにNFCが搭載されている理由 NFCを使用すると、電池を使わずに製品を作成できるため充電の必要がなく、ラベルを常時使用できる ケーブルやコネクタが不要なため、ラベルは完全に密封され、防水仕様にできる NFCは実績があり、広く支持されている標準規格 PCとスマートフォンの両方と簡単に統合可能 PicoLabelのアプリケーション - MpicoSys ePaperラベル ロジスティック・ラベル（倉庫保管、サプライ・チェーン・マネジメント） IDバッジ（従業員、訪問者、会議のバッジに画像を表示） 認証バッジ（ID、認証、暗号化セキュリティ） ドア・サイネージ（シェア・オフィス、会議センター） 製造（紙ラベルとの置き換え） NFCキューブ NFC Cubeは、NFCアプリケーションのユニバーサル・デモです。デバイスとカード/タグ間、デバイスと電話間、そして2つのデバイス間の通信を示します。Cortex M0コアを統合したPN7462AUシングルチップのNFCコントローラを使用します。 NFC Cubeキットは、NTAG I 2 C plus Explorerボードと相互運用可能で、2つのデバイスがNFCを介して通信する方法を実証することができます。 NFCポートフォリオおよびパッケージオプション 当社のNFCリーダーおよび接続タグICのパッケージ・オプションの概要は、こちらをご覧ください。 NFC Everywhereデモンストレーターのパートナー このデモンストレーターに貢献してくださったパートナーの皆様に、心より感謝申し上げます。 Lab ID：NFC/RFIDカード、チケット、ラベル、インレイ Kronegger：論理アクセス制御、NFCリーダー・モジュール、カスタマイズ・ソリューションのデモ Salto：スマート・ドアロックのデモ GMMC：小型NFCリーダー・ソリューションのデモ、改造、開発を容易にするNFC Nutshellキット SES Imagotag：NFCを介した顧客とのインタラクションを可能にする商業用電子棚札 MpicoSys：ePaperとNFCによるコンテンツ更新をベースにした商用PicoLabel 詳細はこちら NFC Everywhereを発見：https://www.nxp.com/nfc MIFAREのすべて：https://www.mifare.net 技術的なNFCの質問と回答：https://community.nxp.com/community/identification-security/nfc NFC認定エンジニアリング・コンサルタント（AEC）の一覧：https://nxp.surl.ms/NFC_AEC NFC Everywhereパンフレット：https://www.nxp.com/docs/en/brochure/NFC-EVERYWHERE-BR.pdf  インダストリアル

imx7d android-pieでAndroidのUI形式が一致しない問題 Hi, 新しいLCDをimx7d DIY開発ボードに移植しています。 kernel: 4.14 android: 9 画面サイズは320x240、物理形式はRGB565です。そして、私は非常に奇妙な問題を抱えています。メイン画面と一部のAndroidアプリケーションは正しく表示できます。ただし、一部のAndroidアプリケーションは更新されません。 さらにデバッグを行うと、FbDisplay.cppで見つけることができます。updateScreen() 関数のレポートバッファ形式はRGBA8888ですが、設定形式は RGB565 であるため、更新操作は停止します。 私が強制すると getBE().mRenderEngine = RE::impl::RenderEngine::create(HAL_PIXEL_FORMAT_RGBA_8888 される getBE().mRenderEngine = RE::impl::RenderEngine::create(HAL_PIXEL_FORMAT_RGB_565 これらのAndroidアプリケーションは画面に表示できますが、赤と青のピクセルは反対です。この方法を使用すると、PCの画面を監視できなくなります。 この形式が一致しない問題の原因と、それを完全に修正する方法を知りたいです。 Re:imx7d android-pieでAndroidのUI形式が一致しない問題 こんにちはZhiming、 ご提案ありがとうございます。私はすでにその問題を解決するための解決策を見つけています。kotlinプロジェクトで画面の向きを回転させます。おそらく、レイアウトの高さが長すぎてAndroidフレームワークのサイズを変更できないでしょう。レイアウトのwidth:heightを変更する必要があります。 敬具 PatrickZ Re:imx7d android-pieでAndroidのUI形式が一致しない問題 こんにちは surfaceflingerについての私の理解として、surfaceflingerはレンダリングエンジンであり、アプリケーションレイヤーから操作を受け取り、fbdisplayを呼び出して表示します。したがって、問題はアプリケーションレイヤーから発生する可能性があり、アプリはレンダリングエンジンにフレームのレンダリング方法を指示します。レンダリングエンジンは1つのピクセル形式用に設計されているとは思わず、ピクセル形式はアプリレイヤーから設定する必要があります。 よろしくお願いいたします 志明 Re:imx7d android-pieでAndroidのUI形式が一致しない問題 こんにちはZhiming、 あなたはそれがAndroid Kotlinアプリケーションで何か問題があるかもしれないということですか?Fbdisplayのconfig.formatは大丈夫です、そして私は問題がsurfaceflingerから来ていると思います。buffer.format は 1 RGBA8888 のままです。 敬具 パトリック・チャン Re:imx7d android-pieでAndroidのUI形式が一致しない問題 Hello, これは、問題が発生しているアプリケーションのコードと関係がある可能性があり、アプリケーションは 32 ビット データを使用しているため、HAL レイヤー コードでは RGB888 が返されます。問題を解決するには、アプリケーションのコードをもう一度見る必要があります。 https://github.com/nxp-imx-android/android-imx_platform_hardware_imx/blob/p9.0.0_2.3.4/display/display/FbDisplay.cpp#L457C1-L462C6 よろしくお願いいたします 志明

S32 Design Studio 3.6.0リリース発表     ​S32 Design Studio バージョン 3.6.0   1. IDEの新機能 「S32Design Studio 3.6」は、初回ユーザー体験を向上させるために、2.5GBの単一インストーラ形式ですべてのパブリックNPIと共に提供されます。アルファのお客様はFlexeraの資格に基づき追加パッケージをご利用いただけます。このパッケージはS32Design Studio 3.6.0に、下図のとおり拡張機能と更新メカニズムを使用して、インストール可能です。 新しいS32Design Studioのインストーラは（S32Design Studio 3.5と比較して）高速かつ軽量になりました。 Windows 11 OSおよびUbuntu 20.04の公式サポート付きで、Windows 10 OSとの互換性をテスト済みです。 新しいEclipse 2023.12、CDT11.4およびJava 17を採用しています。 旧バージョンのS32Design Studio 3.5.xで提供される開発、アドオン、拡張パッケージは、バージョン3.6.0と互換性があります。 S32Design Studio 3.5.xを基盤とするRTDとランタイム・ソフトウェアのリリースは、S32Design Studio 3.6.0と後方互換性があります（スマート互換性メカニズムを使用）。 ARMコア用に新しいGDB 15.1を採用しています。 ARM コア用に新しい Python 3.10を採用しています。 S32Design Studioのプロセスが使用中でインストールを完了できない場合にユーザーに警告するための拡張機能と更新のメカニズムを改善しました。 すべてのレジスタを拡大し、ビットフィールドをエクスポートするようにレジスタ監視ビューを改善しました。 ダッシュボードに表示されるクイック・アクセス用オプションが増えるように改善しました。 UIの改善、C/C++とデバッグのパースペクティブを更新しました。 コマンド・ラインから新規プロジェクトを容易に作成できるように、CLIサポートを改善しました。詳細については、HOWTO_S32_Design_Studio_Command_Line_Interface.pdfを参照してください。 すべてのNPIでCCSリモートを有効にしました。 2. S32Debugger 新機能 新しいS32DebugプローブOS バージョン1.1.0アップデートにより、USB経由でのプローブ接続時にWi-Fiが切断する問題を解決しました。プローブのファームウェアを新しいバージョンに更新するには、HOWTO_Update_the_S32Debug_Probe_OS.pdfに従ってください。 ArmV8コアのデバッグ・ビューで現在の例外レベルが表示されます。 新しい GDB バージョン GDB 15.1 が Python3 インタープリターと共に Arm コアに統合されました S32K3xx/S32M2xx/S32K14x: S32K14xフラッシュ・プログラマのサポート データ・フラッシュのプログラミングもサポートするようにFlashプログラマを強化 3. S32Configuration Tools 1.8.0の新機能 S32Design Studioへのアライメント：Java 17、Windows 11、Eclipse 2023.12 3.1 DDRの機能： メモリ・テスト実行状況の中間レポート インポートログオプション 32ビット・アドレス空間を超えたLPDDR5 DRAMへのアクセス LPDDR5の高速起動、データ保持サポート、マルチコア・テストの実行   3.2 シナリオ・ツールの機能： すべてのブート・ツール（IVT、DCD、QSPI）でUI/UXを更新し、内蔵ツールバーから主要なツール機能にすばやくアクセスできるようにしました。   3.2 GTMツールの機能： CMU用外部クロック TIMの拡張設定モードと新しい定義済みユースケース TOM、ATOM、TIM、TBUモジュールの動的なチャネル管理 HTMLレポートのエクスポート 4. S32Trace 3.6.0の主な機能 S32G3ファミリのすべての部品とアプリケーション・コアのサポートを追加しました。 S32G2ファミリのすべての部品にCortex-M7コアのサポートを追加しました。 5. MCUの主な機能 - S32K1、S32K3、S32K37/39およびS32M2ファミリー： S32DebuggerがFLASHとRAM構成でS32K14xをサポート S32DebuggerがFLASHとRAM構成でS32K3xxをサポート（マルチコア対応） S32K37/39ファミリはS32K3ファミリ・ディストリビューションに帰属 S32DebuggerがFLASHとRAM構成でS32M2xxをサポート サード・パーティのデバッガのサポートを次のとおり更新しました。 Segger J-Link 8.10c PEmicro v5.9.2 TASKING v9.21.273 6.今回のリリースの入手元 S32Design Studio 3.6.0はnxp.comおよびFlexeraから入手可能です。 7. インストール手順： 1. nxp.comのS32Design Studioページに移動し、「ダウンロード」をクリックします。 2. （まだの場合は）ログインし、ライセンス契約に同意します。 3. 「ライセンスキー」タブに移動し、アクティベーション・コードをコピーします。 4. S32Design Studio インストーラを起動し、アクティベーション・コードの入力を求められたら、上記の手順で取得したコードを入力します。 ​   ​ `

i.MX8M和plus系列CPU支持IEEE1588 V2吗？ i.MX8M和plus系列CPU支持IEEE1588 V2吗？ i.MX 8M | i.MX 8M Mini | i.MX 8M Nano 回复：i.MX8M 和 plus 系列 CPU 是否支持 IEEE1588 V2？ 感谢您的快速回复！ 回复：i.MX8M 和 plus 系列 CPU 是否支持 IEEE1588 V2？ 你好，cyesman： i.MX 8M 系列可以支持 IEEE 1588V2，参考手册称 IEEE 1588 消息格式可以使用较新的 1588v2 直接封装在以太网帧（第 2 层）中。 您可以参考 i.MX Linux 参考手册来了解如何实现。 第 4.2 节 ENET IEEE-1588   另请注意，iMX8M 系列支持 1588V2 2 步，但不支持 1 步。 请参阅以下链接了解更多详细信息 i.MX8M（或 8M Plus）可以支持 1588v2 1-Step 吗？- 恩智浦社区 此致 Daniel

i.MX8MおよびplusシリーズのCPUはIEEE1588 V2に対応していますか? i.MX8MおよびplusシリーズのCPUはIEEE1588 V2に対応していますか? i.MX 8M | i.MX 8M Mini | i.MX 8M Nano 日時:i.MX8MおよびplusシリーズのCPUはIEEE1588 V2をサポートしていますか? 迅速な返信をいただきありがとうございます! 日時:i.MX8MおよびplusシリーズのCPUはIEEE1588 V2をサポートしていますか? こんにちは、cyesman: i.MX 8MファミリはIEEE 1588V2をサポートでき、リファレンスマニュアルには、IEEE 1588メッセージ形式を新しい1588V2と直接イーサネットフレーム(レイヤー2)にカプセル化できると記載されています。 実装については、i.MX Linux リファレンス マニュアルを参照してください。 セクション4.2 ENET IEEE-1588   また、iMX8Mファミリーは1588V2 2ステップをサポートしていますが、1ステップはサポートしていないことにも注意してください。 詳細については、以下のリンクを参照してください i.MX8M(または8M Plus)は1588v2 1ステップをサポートできますか?- NXPコミュニティ よろしくお願いします。 Daniel

SLN-SVUI-IOTターンキー・ソリューションの導入 SLN-SVUI-IOTターンキー・ソリューションの導入 1. アブストラクト NXP SLN-SVUI-IOT EdgeReadyソリューションは、ローカルおよびオンラインの音声制御に対応し、統合型音声インテリジェント・テクノロジー（VIT）を搭載したi.MX RT106VクロスオーバーMCUを活用して、タッチレスアプリケーション向けの音声ユーザーインターフェースを提供します。 この超小型フォームファクターの生産準備が整ったハードウェア設計には、FreeRTOS上で動作する完全に統合されたソフトウェアが付属しており、すぐに評価や概念実証の開発を行うことができます。このターンキーソリューションは、市場投入までの時間、リスク、開発の手間を最小限に抑え、OEMが産業用およびIoT製品に音声機能を簡単に追加できるようにします。 図1 2 主な特長 低コスト Arm Cortex-M7 – 600 MHz + 1 MB SRAM 外部DSPやウェイクワードエンジンなし、統合コーデック ホストMCUを置き換え（アドオンソリューションではありません） MPU上でのLinuxベースの実装コストの半分以下 SDRAM、eMMCフラッシュ、PMICを排除し、4層基板を使用 最速かつ最も簡単な方法で、コンセプトから生産まで6か月以内 使い慣れたMCU+RTOSプラットフォーム（Linuxの学習曲線なし） ターンキーソリューション – ワンストップショップ – すべてのソフトウェアが含まれています システムインテグレーター不要、サードパーティとの契約も不要 音声やオーディオの専門知識不要 – 機械学習によるファーフィールドAFE 実績のあるフレーズスポッティング自動音声認識（ASR）エンジンを含む プラグアンドプレイ、すぐに使える体験 AmazonのEcho Dotと同様のファーフィールド音声パフォーマンス 2つまたは3つのマイクサポート、180°または360°のファー・フィールドの実装 全世界での可用性とサポート 3. ローカル音声制御の対象アプリケーション クラウド接続なしでハンズフリーのプライベート音声制御が必要な場所はどこでも スマートホーム スマート照明、シェード、ファンの制御 スマートスイッチ、調光器、プラグ、コンセント サーモスタット、ルームエアコン、除湿器・加湿器 アラームパネル、ガラス破壊センサ、煙および一酸化炭素検出器 セットトップボックス、ホームゲートウェイおよびルーター ガレージドアオープナーとアクセスパネル スマート玩具 スマート家電 大型家電（冷蔵庫、オーブン、洗濯機、乾燥機、コンロ、換気フード、ワインクーラーなど） カウンタートップ（電子レンジ、コーヒーメーカー、フードプロセッサー、マルチクッカーなど） スマートビルディングと産業 エレベーター 複数住戸用インターホンシステム 自動販売機 産業オートメーションとハンズフリーのプロセス制御 図2 4. 生産グレード、認定および資格を持つリファレンス・システム 図3 5. ハードウェアとソフトウェアの状況 SLN-SVUI-IOTハードウェアの主な特徴： 最大600MHz（デフォルト528MHz）Cortex-M7 MCUコア 1MBのオンチップRAM（512kB TCM） 複数のマイクロフォントポロジー：          – メインボードにPDMマイク2つ（デフォルトでは非アクティブ）          – 拡張ボードにPDMマイク2つ（デフォルトでは非アクティブ）          – 拡張ボードにI2Sマイク3つ（デフォルトでは非アクティブ） 3 Wモノラル・フィルターレス クラスDアンプ Wi-Fi/Bluetooth コンボチップ（顧客の必要に応じてOTAアップデートに使用することを想定） 一体型スピーカー GPIO拡張ヘッダ 図4 図5 SLN-SVUI-IOTソフトウェアの主な特徴： 顧客の実装に柔軟性を持たせる2段階のブートストラップとブートローダー 高保証ブート（HAB）を用いたセキュアブートフロー UART経由のオーバーザワイヤー（OTW）アップデート 製造/再プログラミングの自動化ツール ディープラーニングによる音声認識エンジン ファーフィールド自動音声認識（ASR）用のオーディオフロントエンド（AFE） 図6 SLN-SVUI-IOTキットは、NXPとそのパートナーが提供する包括的かつ無料の有効化スイートによってサポートされています。 MCUXpresso開発ツール ハードウェア設計ファイル ローカル音声アプリケーションソフトウェアのソースコード ソフトウェアオーディオチューニングツール ドキュメント トレーニング資料 6. スマート音声UIテクノロジー スマート音声UIの部品番号： RT1062: ボイスシーカー（AECなし）+ VIT RT106V: ボイスシーカー（AEC付き）+ VIT RT106C: ボイスシーカー（AEC搭載）+ Cyberon DSMT 6.1 ボイスシーカー 低電力で常時オンのデバイス向けのマルチマイクロフォン・オーディオ・フロントエンド信号処理ソリューション。マルチマイクのビームフォーミング、ノイズ抑制、マルチチャネルのアコースティック・エコー・キャンセレーションを備えており、高性能なファーフィールド音声ピックアップが可能です。 nxp.com/VoiceSeeker VoiceSeeker概要ビデオ 主な機能/利点 柔軟なマイクロフォンの形状をサポート ビームフォーミング、ノイズリダクション、デリバーブレーション、ペイロードキャプチャ 到着方向の指示は、最大1度の間違いのない精度 オプションのマルチチャネル音響エコーキャンセレーションが利用可能 VoiceSpotおよびVITエンジンと簡単に統合可能 MCUXpresso SDK に AEC を含まない標準イネーブルメント 図7 6.2 音声インテリジェント・テクノロジ 音声インテリジェント・テクノロジ（VIT）ウェイクワードおよび音声コマンド・エンジンを利用することで、開発者は音声UIを無料かつ手軽に使用することができます。お客様が定義したウェイクワードとコマンドを、無料のオンライン・ツールを使用して利用できるようになります。ライブラリおよび音声制御ソフトウェアパッケージはMCUXpresso SDKまたはLinux BSPを通じて提供されます。 このソフトウェア・パッケージは、ディープ・ラーニングの音声認識テクノロジをベースにしており、ウェイクワードと音声コマンドの包括的なソリューションを提供します。VITは、ファーフィールド操作をサポートするマルチマイク・オーディオ・フロントエンドであるVoiceSeekerで簡単に設定できます。VITウェイクワードおよび音声コマンドエンジンは、Arm ® Cortex ® -M7、M33、A-53、またはCadence Xtensa ® HiFi 4およびFusion F1コアを含むいくつかのプラットフォームでロイヤリティフリーで利用可能です。 https://www.nxp.com/vit 図8 特長： VITは最先端のディープラーニングと音声認識技術に基づいています。 VITは、関連するNXPプラットフォーム上で音声対応を可能にする完全なNXP IPで、顧客は無料で使用できます（バイナリライブラリが提供されます）。 Text to Modelによるウェイクワード・モデルの生成（オーディオ・データベースが不要） Text to Modelを使用するカスタム・コマンド Text to Modelに利用可能な豊富なボキャブラリ 英語、中国語（北京語）、フランス語、ドイツ語、イタリア語、日本語、韓国語、スペイン語、トルコ語の言語サポート：vit.nxp.comで提供中 最大3つのウェイクワードを同時サポート 各モデルに対するコマンドの現在の制限は30です 図9 6.3 Cyberon DSMT DSpotterモデリングツール（DSMT）は、顧客定義のウェイクワードとコマンドを使用してカスタマイズされたモデルを作成するためのユーザーフレンドリーなツールです。 注：このツールにはインターネット接続が必要です。 図10 図11 モデルを作成するには、以下の手順に従ってください。 あなたの資格情報でログインしてください。アクセスするには、local‑commands@nxp.com までお問い合わせください。メールには必ず次の詳細を明記してください。 名称 EメールID 会社名 MACアドレス 7.Smart Voice UIソリューションの利点の概要 図12

lpcopen keil iar v2.05 を探しています about LPC1347 全然です。LPC1347シリーズのLPCopen V2.05 Realeaseバージョンの開発リソースパッケージがあり、公式Webサイトのリソースリンクの有効期限が切れています。 Re: LPC1347についてのlpcopenのkeil iar v2.05を求めて こんにちは、@Harry_Zhang  OK、試してみたところ、今すぐダウンロードできます。ありがとうございました。頑張ってください。 by nuipi_plus Re: LPC1347についてのlpcopenのkeil iar v2.05を求めて Hi @niupi_plus  情報ありがとうございます。 この問題を解決し、ダウンロードできるようになりました。   BR ハリー

MCUXpresso Secure Provisioning Tool v9.0.1 现已发布 MCUXpresso 安全配置工具（SEC）是一款图形用户界面（GUI）工具，涵盖安全启动过程和信任配置功能，主要面向微控制器客户。它为现有的命令行工具（cst、pfr、tpconfig、tphost）提供了统一的图形用户界面（GUI）前端。 本次 v9.0.1 版本的新增功能： 新增支持 MCF56816xx/7xx/8xx 处理器 增加了对 MCX N23x 和 MCX A14x/A15x 处理器的支持 增加了对 MWCT2x12/D2 处理器的支持 新增对NHS52S04处理器的支持 新增支持 MCUboot 开源二级引导程序 多数处理器（除 KW45 和 K32W 外）可支持附加镜像文件 导出的 OTP/PFR/IFR 配置现包含页面名称，导入时会进行验证 为 LPC55Sxx 和 i.MX RTxxx 处理器提供固件版本支持（RT118x 仅支持已签名镜像） 现可在固件配置对话框中指定最低固件版本 新增构建、烧录及生产脚本钩子支持 取消 LPC55S6x 和 i.MX RTxxx 处理器的密钥链长度限制（其他 LPC 处理器改为警告提示） 为 i.MX RT116x/7x 的 FlexSPI NAND 新增 FlexSPI 实例选择支持 支持 LPC55S3x、MCX N1xx、RW61x、KW45 和 K32W 处理器的密钥吊销约束 在执行设备 HSM 之前，MBI 图像被部分擦除，因此在重置后无法启动。适用于 MCX N10、MCX N11、LPC55S3x、RW61x 和 MWCT2x12 安装目录新增 "sample_data" 子文件夹（软链接），包含：示例二进制应用程序、签名提供程序示例、信任区、XMCD 和 DCD 配置模板。 签名提供程序： - 新增仅发送数据哈希值进行签名的支持 - 公钥编码格式变更（采用标准 pem/der/nxp 编码替代原有十六进制格式） 集成 NXP Secure Provisioning SDK 2.2.x 主要变更：  - new tools: nxpmemcfg, dk6prog, el2go, nxpwpc i.MX RT1050/6x：支持 eMMC RW61x：设备 HSM 信任配置现在需要受限数据包中的设备 HSM 加载器 移除对 JLink 和 PEmicro 调试库的支持，所有调试探针现通过 pyOCD 实现 添加了 CLI 工具：imgtool 和 uuu CLI：新增保存/修改工作区设置及指定附加镜像的功能 修复了 SB 编辑器中 $check_fw_versions SB2.1 的高级命令 修正 i.MX RT117x 默认闪存型号（基于 RT117x-EVKB 使用的 W25Q512NWEQ） 修正 i.MX RT10xx 和 RT116x/7x 闪存加载程序签名密钥（从默认首密钥改为用户选定密钥） 修复了 i.MX RT1181/82 处理器的 flashloader。 注：v9.0.1 版本修复了 SEC v9 中多个客户反馈的问题 文件下载 要下载安装程序，请通过以下链接登录我们的下载网站： https://nxp.com/mcuxpresso/secure 有用链接： 发布说明详见：MCUXpresso Secure Provisioning Tool (SEC) v9.0.1 版本说明 产品说明：MCUXpresso 安全配置工具简介 公告

将摄像头和 LCD 连接到 i.MX RT EVK 本指南将逐步介绍如何将摄像头和 LCD 模块连接到 i.MX RT 开发板，并测试以确保摄像头和 LCD 模块连接正确。2022 年 5 月更新：这些 LCD 面板推出了新版本，对软件配置会产生影响。请参阅此博文以了解更多详情。原版面板与新版面板的物理连接相同，因此本指南内容无需更改。 本指南的第一部分适用于 i.MX RT1050、i.MX RT1060 和 i.MX RT1064 EVK。 本指南的第二部分适用于 i.MX RT595、i.MX RT1160 和 i.MX RT1170 EVK。 第 1 部分：i.MX RT1050、i.MX RT1060 和 i.MX RT1064 的摄像头和 LCD： RT1050、RT1060 和 RT1064 EVK 使用的摄像头相同。但是这款摄像头仅随 RT1060 和 RT1064 EVK 一起提供。正如这篇博客文章中所讨论的，RT1050 有其他可用的替代方案。 与这些开发板兼容的 LCD 显示屏为 RK043FN66HS-CTG  摄像头： 1）摄像头连接器位于开发板的正面。优化：将黑色连接器向上掀起，使其与原位置呈 90° 角。 2）然后将摄像头的扁平排线插入连接器中。 3) 将黑色连接器翻回去。它应该使带状电缆保持紧密。 LCD： 1) 在电路板背面，将黑色 LCD 排线连接器向前滑动。 2) 然后将扁平的 LCD 排线电缆滑入黑色连接器下方。 3）将黑色连接器滑回其原始位置。电缆应保持紧密。 4) 对触控控制器连接器执行相同的操作，然后将黑色连接器向前滑动。 4) 然后将电缆插入黑色连接器与白色顶部之间，确保电缆位于中间。这可能需要尝试几次，因为它有点困难。您也可以使用尖嘴钳来帮助引导电缆，但要小心损坏电缆。 5）然后将黑色连接器滑回原来的位置。电缆应插牢并且没有松动。 6) 完成后，它应如下所示。 测试： 1) 要测试摄像头和 LCD，请使用 MCUXpresso SDK 中的 CSI 驱动程序示例。 2) 第一次使用时，摄像头可能会失去焦点。通过顺时针旋转镜头进行调整，直到图像清晰对焦。您可以使用手指或尖嘴钳。它最多可能需要旋转两圈，并且应该很容易转动。还要移除塑料盖。 3) 要测试触摸控制器，请使用 MCUXpresso SDK 中的 emWin 温度控制示例 磁带： 1）一旦确认 LCD 可以正常工作，您可以使用两层厚双面泡沫胶带将其牢固地固定在电路板上。 第 2 部分：i.MX RT1160 和 i.MX RT1170 EVK 的摄像头和 LCD： i.MX RT1160 和 i.MX RT1170 EVK 均配有 OV5640 MIPI 摄像头模块，包装内附带。 与i.MX RT1160 和 i.MX RT1170-EVK 兼容的 LCD 屏幕是RK055HDMIPI4MA0，您可以在此处找到。 i.MX RT1170-EVK 摄像头： 1) 摄像头连接器位于电路板正面的 J2 位置。只需将摄像头按下至连接器即可完成连接。这需要一点力气，但不应该太难。 i.MX RT1170-EVK LCD: 1) 在电路板背面，将 LCD 带的黑色连接器 (J40) 向前滑动至电路板的边缘。 2) 然后小心将扁平的 LCD 排线插入连接器中。电缆应插牢并且没有松动。它应该位于您刚刚滑出的连接器的黑色部分上方，并位于连接器的白色部分下方。 3）将黑色塑料连接器滑回其原始位置。电缆在被拉动时应保持紧绷。它应该看起来如下所示： i.MX RT1170-EVK 电源： 1) 如果使用 LCD，则必须使用外部电源适配器与电路板配合使用。将圆柱形连接器连接到电路板上的 J43。 2) 还需将J38上的跳线更改为连接1-2脚，以便使用外部电源。 3) 将微型 USB 数据线连接到 J11 接口，这将使主板被识别为 COM 端口，并作为调试接口用于下载和调试代码。 i.MX RT1170-EVK 摄像头和 LCD 测试： 1) 要测试摄像头和LCD，请使用MCUXpresso SDK for i.MX RT1170中提供的csi_mipi_rgb_cm7驱动示例。如果一切连接正常，摄像头输入应显示在LCD屏幕上。

i.MX6のUARTを使用するときに0xFFを連続して受信する問題に関するヒント この記事では、i.MX6シリーズで発生することがある問題について、1つのヒントを示します。RXラインがずっとハイのときに、UARTが継続的にRX割り込みを生成し、0xFFを受信するという問題です。 以下に、imx6DLを用いて説明いたします。一部の設定は、再現を容易にするためのものです。 BSP バージョン：L5.4.70-2.3.0 ボードHW:MCIMX6DL-SDB 問題が発生する状況 i.MX6DL UART3をシリアル・ポートとして設定し、1200ボー、8-N-1形式を使用します。 RXラインを高く保ってください。 RXラインをローにして、その状態を短時間（360～370マイクロ秒）維持します。 この状態では、RX ラインをハイに戻しても、UART は継続的に RX 割り込みを生成し、0xFF を受信していることが表示されます。 問題が発生する原因 このローの時間は正常な範囲内になく、当社の仕様から外れています。 i.MX6DLのAECのドキュメントには、次のような「UARTレシーバ」というセクションがあります。 1200ボーを使用する場合、有効な1ビットの時間は833マイクロ秒です。そして仕様には、「各ビットで1/(16 x Fbaud_rate)の許容誤差を認める」との規定があります。つまり1200ボーの場合には、有効な1ビットの範囲は781～885マイクロ秒です。しかし、問題を再現するときのロー・レベルの時間は360マイクロ秒です。この範囲外の時間によって、UARTのステート・マシンが混乱します。 解決方法 実際には、当社の仕様に従っていただくのが最善の方法です。お客様の環境でこのような未知の状況が発生する場合には、お客様が直面する問題を解決するためのヒントとして、次のような方法が考えられます。 割り込みハンドラは USR1[AWAKE] を確認します。 2    AWAKEがアサートされている場合は、それをクリアして、通常どおり処理を進めます（有効なデータがあると想定します）。それ以外の場合は、USR1[AGTIM] がアサートされているかどうかを確認します。 3    AGTIMがアサートされている場合は、それをクリアして、通常どおり処理を進めます。それ以外の場合は、ソフトウェア・リセットを実行します（データが無効であるものと想定します）。 AGTIMをチェックするのは、RX FIFOにいくつかの文字（RXTL未満）があるものの、それ以上のデータが入ってこないときの競合状態に対処するためです。 この手順に従うと、ブロック割り込みが発生したときにUARTはソフトウェア・リセットを実行します。 注：お客様の報告によると、RXラインで有効なスタート・ビットが検出された場合には、エラーがクリアされる可能性があります。これはお客様自身で確認していただく必要があります。 テストコードは添付ファイルに含まれています。 Besst Regards i.MX6 全て

MPC5674FでのSPIタイムアウト遅延の計算 Hello, 264MHzで動作するMPC5674Fマイクロコントローラ用のSPIドライバに取り組んでおり、ポーリングベースのSPIトランザクションのタイムアウト遅延を計算する必要があります。SPI 転送の完了は、転送完了フラグ (TCF) を使用して監視され、反復回数に基づくタイムアウトが使用されます。 システムクロックの詳細: MCU周波数 = 264MHz クロック周期 = 1/264MHz = 3.78787879 ns (サイクルあたり約 3.79 ns) コード スニペット: #define SPI_MAX_WAIT_ITERATIONS 100 // Wait until the transfer is complete. // The TCF bit indicates that all bits in a frame have been shifted out. while (p_spi_config->port->SR.B.TCF == 0) { if (iteration_counter++ > SPI_MAX_WAIT_ITERATIONS) { // If this point is reached, the SPI transfer did not complete // within the expected iterations. spi_status = eSPI_TIMEOUT; iteration_exceeded = true; // Set flag to break `for` loop break; // exit from while loop } } 遅延計算: イテレーションが次のもので構成されると仮定します。 TCF ビットの読み取り (p_spi_config->port->SR.B.TCF == 0) → 2サイクル 1サイクルiteration_counter →インクリメント iteration_counter > SPI_MAX_WAIT_ITERATIONS → 1サイクルの比較 ループ開始→1サイクルに戻る イテレーションあたりの合計 ≈ 5 クロック サイクル SPI_MAX_WAIT_ITERATIONS = 100 の場合、タイムアウト前の合計サイクル数: 合計サイクル = 100×5 = 500 合計時間 = 500×3.79 ns = 1.89マイクロ 秒 問： この遅延計算はMPC5674Fに対して正しいですか? 100回の反復は妥当なタイムアウトですか、それとも調整する必要がありますか? MPC5674F SPIモジュールには、ステータスレジスタごとにオーバーラン、フレームエラーなどのエラーを検出するためのフラグがありません。エラーを検出する方法はありますか? コミュニティからの洞察は大歓迎です! よろしくお願いいたします！ ナレンドラC MPC5674F、#POWERPC アーキテクチャ   Re: MPC5674F での SPI タイムアウト遅延計算 Hi, 1)それはあなたが概説したほど単純ではなく、より多くなります。あなたはむしろ、コードがどのようにコンパイルされ、アセンブラコードに基づいて、コアマニュアルの命令セットの状態の助けを借りて、より多くを推測することができますかを確認する必要があります。ただし、I/Dキャッシュ、メモリ待機状態、クロスバー設定/レイテンシなど、MCUの別の設定が役割を果たします。 ただし、内部タイマーを使用したり、ピンを切り替えて特定のコード実行時間を測定したりできます。 2) 実際のSPI転送/ビットレート設定による 3)TXFIFOアンダーフローとRXFIFOオーバーフローの表示があります。転送属性は通信前に設定されるため、マスター/スレーブで同じである必要があり、SPIはシリアルクロックと同期通信であるため、このようなエラーは予想されません。 BR, Petr

S32G3 RDB3 GMAC0 SGMIIテスト Hi, 現在 、bsp41 を使用しており、 S32G-RDB3 ボードでGMAC0をSGMIIモードで動作するように構成しようとしています。RDB3 イーサネット イネーブルメント ガイドに基づいて、次の設定が必要であることを理解しています。 GMAC0:SGMIIの PFE_MAC0、PFE_MAC1、PFE_MAC2: ガイドの例 4 で概説されているように、それぞれ SGMII、SGMII、RGMII です。 U-Boot と Device Tree で必要な変更をすでに行っています。しかし、 DIPスイッチ や SJA1110ファームウェアの役割についてはよくわかりません。具体的には： DIPスイッチの設定とSJA1110ファームウェアの両方を変更する必要がありますか? DIP スイッチだけでスイッチを SGMII モードに設定できますか、それともファームウェアの変更は必須ですか? また、ドキュメントに記載されている P1-1G-P4-1G.bin ファイルを見つけることもできません。SGMII モードの SJA1110 スイッチ ポートの設定方法や、正しいファームウェア ファイルの取得に関するガイダンスを教えてください。 あなたが提供できる洞察やガイダンスは大歓迎です。 ありがとうございます XDの Re:S32G3 RDB3 GMAC0 SGMIIテスト こんにちは@XD、 フィードバックをありがとう!SDKリクエストには時間がかかる場合がありますが、前の回答があなたの質問を解決した場合、それを受け入れられたソリューションとしてマークできますか? RDB3ボードでSJA1110 SDKを使用する際に問題が発生した場合は、いつでも新しい投稿を作成できます。 よろしくお願いいたします Re:S32G3 RDB3 GMAC0 SGMIIテスト Hi @alejandro_e  詳細な説明をいただきありがとうございます。とても助かりますし、本当に感謝しています。SDKソースコードを取得するためのリクエストを送信しましたので、アクセス可能になったらご連絡いたします。 ありがとうございます XDの Re:S32G3 RDB3 GMAC0 SGMIIテスト こんにちは@XD  あなたの質問に答える: ディップスイッチ(SW17)は、SerDesの出力を多重化するために使用されます S32G-VNP-RDB3製品ページのデザインファイルセクションにある回路図のスイッチの信号をたどると、それを確認できます。 したがって、DIPスイッチを変更して、期待どおりの動作にする必要があります。 SAJ1110 バイナリは、RDB3 イーサネット有効化ガイドに示されているように、Linux からフラッシュできます イーサネット有効化ガイドに記載されているように、バイナリを自分でコンパイルすることもできますが、次の構成で GoldVIP パッケージで見つけることもできます[GoldVIP User manua, Rev. 1.12.0 — 18 June 2024]: このパッケージはAUTO-SW-PACKAGE-MANAGERからダウンロードできます。 ユーザーマニュアルは documentation フォルダにあり、SJA1110バイナリは binaries フォルダにあります。 fsl-image-goldvip-s32g399ardb3.sdcardをフラッシュして実行することにより、SJA1110ファームウェアをダウンロードすることもできますRDB3の画像 RDB3 の GoldVIP イメージ (バイナリ フォルダにもあります) をフラッシュして実行すると、ファームウェアがブートログのSJA1110にフラッシュされることがわかります ... 必要なのは、イーサネット有効化ガイドの説明に従ってジャンパを設定することだけです。 J189:ピン1-2:ショート、ピン3-4:ショート SDK を使用すると、SJA1110 のコンフィギュレーションを変更できます 必要に応じて構成を変更できますが、パッケージにアクセスするにはNDAが必要であることに注意してください。これは、「ソフトウェアの取得」セクションのステップ3にあるイーサネットイネーブルメントガイド(https://www.nxp.com/document/guide/get-started-with-the-sja1110-evm:GS-SJA1110-EVM)のステップ1のリンクをクリックすると確認できます。 この情報が役に立ったかどうか教えてください。

如何下载 FS8630 安全手册？ Hi， 作为系统集成商，需要下载安全手册来完成，但在NXP整个网站都找不到FS8630的安全手册。请帮我找到安全手册。 功能安全 回复：如何下载 FS8630 安全手册？ 你好，查理， FS86 安全手册被归类为需要保密协议 (NDA) 的安全文件。 如果您的公司尚未与 NXP 签署保密协议，您可以通过以下方式申请： https://www.nxp.com/support/support:SUPPORTHOME 如果有有效的保密协议 (NDA)，您可以从以下网站下载： https://www.nxp.com/products/FS86 请确保您已登录 nxp.com。如果您没有看到 FS86 安全手册，请单击“请求其他访问权限”或转到“我的 NXP”>“个人资料”编辑您的安全访问权限。有关安全访问权限的更多信息，请参阅此网站： https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS BRs, Tomas