Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
What could be the reason for the ABIST2_EXT self-test failure of the S32K3X4EVB-T172? I am using the S32K3X4EVB-T172 for development. I tried using Sbc_fs26_PerformAbist2Check to check: SBC_FS26_MOR_VPRE = 0 SBC_FS26_MOR_VCORE = 1 SBC_FS26_MOR_LDO1 = 2 SBC_FS26_MOR_LDO2 = 3 SBC_FS26_MOR_TRK1 = 4 SBC_FS26_MOR_TRK2 = 5 SBC_FS26_MOR_VREF = 6 SBC_FS26_MOR_VEXT = 7 However, I found that only Sbc_fs26_PerformAbist2Check(SBC_FS26_MOR_VEXT) makes ABIST2_PASS of FS_DIAG_SAFETY1 show as 0 / ABIST2 Fail or not executed, but I don't know why? OTP.png OTP2.png OTP3.png Could the issue be due to an incompatible OTP configuration of the FS26 part number PFS2613AMDA2AD used in the S32K3X4EVB-T172, or is it a faulty FS26 IC? OTP4.png Re: What could be the reason for the ABIST2_EXT self-test failure of the S32K3X4EVB-T172? I confirmed on EVB that it's the OTP that's causing it, same as I said before. If the OTP turns off the VMON behind it, you don't need to configure the bit of the corresponding channel. Re: What could be the reason for the ABIST2_EXT self-test failure of the S32K3X4EVB-T172? Yes, when executing ABIST2 self-tests, only ABIST2_EXT fails and shows ABIST2_PASS = 0, which may be a failure or not executed, but I can't think of a reason, but all other ABIST2 self-tests work and show 1 for PASS = ABIST2_PASS.
記事全体を表示
S32K3 RTD FlexCAN 驱动程序默认禁用内存 ECC。 队员们好 最近,我们的客户发现 S32K3 RTD 驱动程序会禁用 FlexCAN 的内存 ECC 功能。虽然默认情况下启用了 ECC 功能。 客户 Xingyu 遇到的问题是,一些 CAN MB 永远卡住,无法再接收特定 ID。我们发现根本原因是某些 CAN MB 存在 ECC 错误,从而改变了该 MB 的 ID 文件。启用内存修正功能后,客户的问题就不复存在了。 请问为什么在 CAN RTD 的初始化过程中禁用了该功能?请优先考虑这个问题,而且客户是批量生产领域的客户,并向我们提供解释。 谢谢& ,致以最崇高的敬意、 理查德 优先级:高 RTD Re: S32K3 RTD FlexCAN driver disable the memory ECC by default. 你好@DanNguyenDuy、 感谢您的答复。让我再澄清一下: 1.客户使用的是旧 RTD 2.0.0 版本。我注意到最新的 RTD 版本似乎也禁用了这种内存修正功能。 2.请参阅下面的 CAN 寄存器映射(从 0x40304000 开始)。   请问为什么启用该功能会影响正常的发送和接收过程? 客户 20,000 多种产品中的一种产品出现了这种随机问题,我们的质量团队参与其中。客户启用该内存校正功能后,CAN MB ECC 问题得以解决,并能正常收发数据。 BR 理查德 Re: S32K3 RTD FlexCAN driver disable the memory ECC by default. 你好@RichardLi、 过去,当默认启用 FlexCAN 的 ECC 时,FlexCan 驱动程序会出现 ECC 问题,上电复位后无法正常传输和接收数据。此外,RTD 驱动程序不支持 FlexCan 的 ECC。因此,他们默认禁用了这一功能。 关于客户的背景,您能告诉我相关信息吗? 1。他们使用了哪个 RTD 软件包版本? 2.遇到问题时,FlexCan 寄存器的值是多少? 顺祝商祺! 丹 Re: S32K3 RTD FlexCAN driver disable the memory ECC by default. 你好@DanNguyenDuy 感谢您的支持。我们将等待 RTD 团队的反馈。 在这里,我列出了我们与客户在线调试时剪下的一些寄存器,其中大部分寄存器都显示了出来。至于 xdm 配置文件,我们将联系客户,看他们能否根据公司政策提供给我们。 BR 理查德 Re: S32K3 RTD FlexCAN driver disable the memory ECC by default. 你好@RichardLi、 1.我向 RTD 团队提交了查询票(ARTDCC3-368),要求他们做出解释。 2.根据您的附图,我发现 ESR1[BIT0ERR] 的值 = 1。该值错误位可能是由于 CAN 收发器之间的物理连接或节点之间的 CAN 位定时不一致造成的。能否将更多配置文件(.xdm 或 .arxml文件)以及偏移 0 至 C14h 寄存器的值? 顺祝商祺! 丹 Re: S32K3 RTD FlexCAN driver disable the memory ECC by default. 你好@LiekLi、 您认为我们是否可以要求客户提供他们的 xdm 文件,以帮助 SW 团队进一步分析?或者我们只需要 RTD 团队给出一个解释,就足以关闭此票? BR 理查德 Re: S32K3 RTD FlexCAN driver disable the memory ECC by default. 嗨,理查德、 解释 RTD 为何禁用此功能就足够了。 Re: S32K3 RTD FlexCAN driver disable the memory ECC by default. 你好@RichardLi、 这就是他们的答复: " 关于为什么默认禁用 ECC 的问题:我想说的是,当我们创建 RTD 代码库时,它们是从传统的 MCAL 代码库继承的,因此它们可能一直存在到现在。这对于我们来说很难审查所有代码,以确定有关专用勘误表的具体代码。 此外,在 S32K3 上,我们在低级 FlexCAN 驱动程序中实现了对 ECC 的支持: ARTD-53030 [CAN]在 S32K3 平台上实现对 RAM ECC 操作的支持 - NXP Jira" 顺祝商祺! 丹 Re: S32K3 RTD FlexCAN driver disable the memory ECC by default. 你好@DanNguyenDuy、 感谢您的及时反馈。我将把这一解释传达给客户,看看他们是否有进一步的问题。 此致, 理查德 Re: S32K3 RTD FlexCAN driver disable the memory ECC by default. 你好@DanNguyenDuy RTD 团队是否有任何最新消息?谢谢! BR 理查德
記事全体を表示
HashDataDefSrv 返回参数无效 你好,@lukaszadrapa ,我正在使用 HseResponse = HashDataDefSrv(HSE_HASH_ALGO_SHA2_256,(uint32_t) sizeof(test)、test,&image_hash_length,image_hash,HSE_SGT_OPTION_NONE); 函数来计算存储为 const uint_8 [] 的图像的 HASH,但我得到的返回结果是 Parameter Invalid(参数无效)。于是我决定在一个更小的数组上测试哈希值,但也遇到了类似的问题。 请帮助解决这个问题! 此外,在使用 HSE 和 RTD 3.0.0 时,我还发现了一个小问题、即:- 当我在没有任何断点的情况下运行代码时,我的 HSE 应用程序接口总是响应 NOT_OK(not ok 意味着除了 HSE_OK 或 HSE_SUCCESS 之外的任何其他意思),但当我手动跳过这些应用程序接口时,我得到的是 HSE_SUCCESS Re: HashDataDefSrv returns Paramter Invalid 你好@lukaszadrapa 我试过你的解决方案(禁用 D_CACHE_ENABLE),但没有用。 而你却只字未提我的附加问题。 Re: HashDataDefSrv returns Paramter Invalid 你好@R_S002 第一步,您是否可以尝试禁用项目中的数据缓存?这是 HSE_SRV_RSP_INVALID_PARAM 错误的常见原因 。用于与 HSE 通信的所有数据对象必须强制使用非高速缓存内存。禁用数据缓存可以快速确认是否存在这种情况。 此致, Lukas Re: HashDataDefSrv returns Paramter Invalid 如果不是数据缓存造成的,我需要这两个问题的更多细节。 关于哈希服务,您能否在将其发送给 HSE 之前截取一张服务描述符的截图? 关于第二个问题,您能否检查一下 HSE 返回的错误代码是什么?如果步进代码时能正常工作,则可能是某种时间问题或一致性问题。在执行这些 HSE 服务时,您是否尝试过禁用中断? Re: HashDataDefSrv returns Paramter Invalid hi@lukaszadrapa 我一回到办公室就会提供服务描述符 第二个问题返回 HSE_SRV_RSP_NOT_SUPPORTED。您能更准确地说明"禁用中断" 吗? Re: HashDataDefSrv returns Paramter Invalid R_S002_0-1764847866495.png 你好@lukaszadrapa HASH 函数执行前的图像 Re: HashDataDefSrv returns Paramter Invalid 我在板上做了非常快的测试,我能看到同样的问题。我从未遇到过散列问题,让我检查一下是怎么回事。我今天没时间,下周再检查。 此致, Lukas Re: HashDataDefSrv returns Paramter Invalid 好吧,很可能是 pHashLength 导致的。该指针指向的变量必须初始化为哈希缓冲区的大小。不能为零。HSE 服务 API 参考手册说: " 输入/输出:指向存储以字节为单位的哈希长度的 uint32_t 位置的指针。 在调用此服务时,此参数应包含主机提供的缓冲区大小。 主机提供的缓冲区大小。请求完成后,应存储 返回值的实际长度。如果缓冲区 小于散列大小,散列将被截断" 因此,请检查该参数的内容。 Re: HashDataDefSrv returns Paramter Invalid 能否举例说明您是如何尝试并验证 HASH 函数的? Re: HashDataDefSrv returns Paramter Invalid 下面是我过去用过的一个简单例子: int main(void) { hseSrvResponse_t HseResponse; uint8_t hash_result[64] = {0U}; uint32_thash_length = 64U; /* 检查 Fw 安装状态*/ WaitForHSEFWInitToFinish(); /* 使用的测试向量:https://www.di-mgt.com.au/sha_testvectors.html*/ /* 输入信息:一百万 (1,000,000) 次重复字符"a" (0x61)。*/ /* SHA-512 */ /* 预期结果:*/ /* e718483d0ce76964 4e2e42c7bc7bc15b463 8e1f98b13b204428 5632a803afa973eb de0ff 244877e60a 4cb0432c577c31b eb009c5c2c249a2e 4edb2c49a2e 4ead0f2477e60a 4c0432c5c2c49a2e 4edb2c49a2e 4ead0f2477ea 60a 4c0432c5c2c49a2e 4ead9a2e 17ad8cc09b */ HseResponse = HSE_HashDataBlocking ( MU0, HSE_ACCESS_MODE_ONE_PASS, 0, HSE_HASH_ALGO_SHA2_512, 0x408000U、/* 使用附带的 cmm 脚本将 100 万个 "a "字符编程到此地址 */ 1000000, /* 数据长度 100 万 */ hash_result, & hash_length ); for (;;) { } } 要散列的数据是通过外部脚本编程到闪存中的。
記事全体を表示
PN7642 RF Design-in Tips and Tricks Prerequities:  PN7642 design-in recommendations   1// Impedance tuning  PN76 family antenna design guide The target impedance is chosen based on the target application. If full power is required (e.g., POS terminals). The target impedance of 15-17 Ω is recommended. For lower power applications using ULPCD, the higher impedance is typically preferred, 30-50 Ω (symmetrical tuning).   2// Dynamic power control  PN7642 - Basic RF power limitation using DPC   3// H-Field check  There are given limits, especially for the maximum H-field radiated by the reader. Exceeding these limits might lead to destroying the NFC Card/NFC Tag.   The H-Field can be measured with the help of test equipment, as  ISO 10373-6 Test PICC EMVCo 3.0 Test PICC  For indication only, the customers can use "smart" Field Strength Probes as shown below :    Tomas_Parizek_0-1764148815270.jpeg Note: The most critical position occurs when the card is placed directly on the NFC antenna . In this case, if the H-field exceeds the maximum allowed level, the output power must be reduced using DPC settings. 4// HF Attenuator value  Turn on the RF Field with the DPC set and enabled from the previous step  Read the CLIF_RXCTRL_STATUS register and check the HF_ATT_VAL as shown below.  Tomas_Parizek_1-1764147827990.png The value for the "unloaded" condition with full power shall be approximately 35-45dec.  If the value is out of this range, the customer is required to adjust the Rx resistors to reach this value.  5// Receiver settings  Check the "Power" range and Communication Range with the default settings provided by NXP.  Power Range -> The distance at which the NFC Tag can still generate its answer, but the NFC Reader does not see it  Communication Range -> The distance at which the NFC Tag can still communitate with the NFC Reader  Ideally, Power Range ≈ Communication Range Also, the NFC Reader should not generate any false communications as e.g., "HAL COLLISION ERROR".  The optimisation of the receiver can be done in the following way:  Enter DPC Calibration  Go to the "ARC" menu and "disable" the ARC algorithm Tomas_Parizek_0-1764153827503.png This will force the IC to use the RX settings from the following Register/EEPROM SIGPRO_RM_TECH_REG DGRM_RSSI_REG   5.1// SIGPRO_RM_TECH_REG (RM_MF_GAIN parameter) This parameter basically defines the gain of the input amplifier.  Select SIGPRO_RM_TECH_REG  Switch "operation" to EEPROM and choose the required technology  Increase the RM_MF_GAIN to 0x02 (it depends on the setup).   Tomas_Parizek_0-1764154133976.png   5.2// DGRM_RSSI_REG (DGRM_SIGNAL_DETECT_TH_OVR_VAL parameter) This parameter defines a threshold from which the internal logic starts to decode the incoming signal.  If the threshold is too low or very close to the noise floor, the system can detect the noise as an NFC Communication.  It is therefore,  Threshold + margin > noise floor The best routine is to perform "Signal Detection Threshold" analysis. This can be done with the help of the NFC Cockpit (described in PN7642 design-in recommendations) As a result, the user can obtain the mean value of the "Noise," and suggested "DGRM_SIGNAL_DETECT_TH_OVR_VAL" threshold based on the inserted "Margin."  Maring (m) + Noise mean value (μ) = Threshold  6+16=23 Then this value shall be written in "DGRM_RSSI_REG" EEPROM as shown below.    Tomas_Parizek_0-1764155707250.png 6// ULPCD Settings  We recommend the following ULPCD Settings as a starting point.  ULPCD VDDPA should be chosen in such a way that the HF Attenuator value is not 0x00! The typical value for HF Attenuator in ULPCD is around 0x05-0x0B.   6.1// RSSI Threshold evaluation  For a proper RSSI Threshold selection, it is recommended to perform the ULPCD Calibration, e.g., 20 times, and check the "jitter" of the RSSI signal for your device.  Tomas_Parizek_1-1782466350613.png If you see that the RSSI value is jittering, e.g., 1 unit as shown above. The absolute minimum threshold for this case is 2. However, it is always recommended to include adequate margin (To prevent false wake-ups).   Generally, the margin of 2 units is sufficient. So in this case, the optimum threshold will be 4. 
記事全体を表示
MCX W72 ナレッジハブ MCX W72xファミリーは、96MHzのArm ® Cortex ® -M33コアと、Matter、Thread、Zigbee、Bluetooth LEをサポートするマルチプロトコル無線サブシステムを搭載しています。専用のコアとメモリを備えた独立した無線サブシステムは、メインCPUの負荷を軽減し、主要アプリケーションのためにCPUを温存するとともに、FUTURE無線規格をサポートするためのファームウェアアップデートを可能にする。MCX W72xは、統合されたEdgeLock ® Secure Enclave Core Profileによる高度なセキュリティ機能も提供し、認証情報共有のためのNXPのEdgeLock 2GOクラウドサービスにも対応します。 MCX W72xファミリは、Bluetoothチャネルサウンディング機能を搭載し、測距レイテンシを低減するための専用オンチップ測位演算エンジンを備えています。アプリケーション固有のコード、接続スタック、および無線によるファームウェアアップデートをサポートするための追加メモリを搭載しています。さらに、無線サブシステムは、Bluetooth Low Energyスタックと並行して、ThreadまたはZigbeeのフルスタックを実行できます。これにより、無線機のリアルタイム処理がアプリケーションとは別のコアで実行されるため、信頼性の高い無線性能が実現します。 NXPが長年にわたり培ってきた産業用エッジソリューション提供の実績に基づき、MCX Wシリーズは-40℃~125℃の広い動作温度範囲と、オプションのCANインターフェースを含む産業アプリケーション向け**ペリフェラル**を提供し、長期的な産業利用をサポートするNXPの15年間の製品寿命延長プログラムの一部となります。 MCX Wシリーズは、 MCUXpresso開発者エクスペリエンス 組み込みシステム開発を最適化、簡素化、加速化する。 joseAntonio_ruiz_0-1739550415233.png   joseAntonio_ruiz_1-1739550414945.png セキュリティ認証 PSA認定レベル2 SESIPセキュリティターゲット SESIP KW47/MCXW72 SESIP証明書とSTはTrustCBにあります Webサイト 規制認証 欧州連合適合宣言書 - FRDM MCXW72 Bluetoothの要件 認定製品 | Bluetooth ®テクノロジーウェブサイト Q360996: KW47 / MCX W72 Bluetooth LE 6.0 (チャンネルサウンディング) コントローラー Q332147: KW47 / MCX W72 Bluetooth LE 6.0 (チャンネルサウンディング) ホスト 文書 MCX W72製品ファミリーデータシート MCX W72 リファレンスマニュアル MCX W72の正誤表 MCXW72 ハードウェア設計ガイド   MCX W72プラットフォームでのMatterの利用開始 NXP MCX W72 で OpenThread を使い始める   FRDM-MCXW72 ユーザーマニュアル FRDM-MCXW72の入門ガイド   MCX W72-LOC ユーザーマニュアル ブルートゥース Bluetooth技術にご興味がありますか? Bluetooth Low Energy Primer – BLEの基礎を理解するために必読の書。 Bluetooth ®仕様 -規格、プロトコル、技術文書の完全なリスト。 受賞歴と表彰 毎年、Bluetooth Special Interest Group (SIG) は、Bluetooth 技術の発展に貢献したとして同業者から認められたワーキンググループ、委員会メンバー、貢献者の努力と献身を称えています。 2024: チャネル Sounding 2025年:チャネルサウンディング振幅ベースの攻撃耐性、LEテストモードの機能強化、および測距プロファイルとサービス。 Bluetooth機能の概要 Bluetooth_5.0_機能の概要 Bluetooth_5.1_Feature_Overview Bluetooth_5.2_機能概要 Bluetooth_5.3_機能概要 Bluetooth_5.4_機能概要 Bluetooth 6の機能概要 Bluetooth 6.1の機能概要 Bluetooth 6.2 機能概要 Bluetooth 6.3 機能概要 アプリケーションノート ソフトウェア、ハードウェア、ペリフェラル: AN14850 MCX W72によるアプリケーションパフォーマンスの向上:このアプリケーションノートでは、汎用組み込みアプリケーションのパフォーマンスを向上させるために、MCX W72マイクロコントローラのデュアルコアアーキテクチャを使用する方法について説明します。 AN14937 MCX W72の32kHzクリスタルレスモード:このアプリケーションノートでは、MCX W72デバイスの32kHzクリスタルレスモードに関する情報を提供します。このモードを使用すると、32kHzのクロック精度を損なうことなく、システムのコストを削減できます。フリーランニング発振器(FRO32K)は32kHzクロックソースとして使用され、MCX W72の信号周波数アナライザ(SFA)モジュールを介して32MHz RF発振器に対して校正されます。 AN14745 MCX W72 のスマート電源スイッチの機能、使用方法、および性能:このアプリケーション ノートでは、MCX W72マイクロコントローラのスマート電源スイッチの使用方法について説明します。MCX W72には、接続されたコンポーネント(MCX W72の電源ドメインを含む)のオン/オフを切り替えるプログラム可能なソリッドステートスイッチが内蔵されています。 AN14747 MCX W72 のロードプルテストレポート:この文書では、供給電流、送信電力、および高調波レベルを測定する目的について説明します。これらの測定値は、被試験デバイス(DUT)が受ける複素出力負荷の振幅と位相を調整しながら監視されます。 パワーマネージメント:  AN14739 MCX W72 Bluetooth Low Energy 消費電力分析:このドキュメントでは、MCXW72-EVK ボードを使用した MCX W72 (IIoT) ワイヤレス MCU の消費電力分析について説明します。 AN14745 MCX W72マイクロコントローラのスマートパワースイッチの機能と使用方法:このアプリケーションノートでは、MCX W72マイクロコントローラのスマートパワースイッチの使用方法について説明します。MCX W72には、コネクテッドコンポーネント(MCX W72の電源ドメインを含む)のオン/オフを切り替えるプログラム可能なソリッドステートスイッチが内蔵されています。 AN14841 802.15.4 MCX W72 の マター および ZigBee 消費電力分析:このドキュメントでは、Kinetis MCX W72 (IIoT) ワイヤレス MCU の消費電力分析について説明します。 AN14742 MCX W72用電源管理ハードウェア:このアプリケーションノートでは、 MCX W72マイクロコントローラにおける電源管理専用の各種モジュールの使用方法について説明します。 AN14664 Kinetis BLEアプリケーション向けコインセルハードウェア推奨事項:この文書では、コインセルレベルでの電流ピークを最小限に抑えるためのハードウェアおよびソフトウェアソリューションについて説明します。 AN14889 :Bluetooth Low EnergyおよびIEEE 802.15.4向けFRDM-MCXW72無線周波数システム評価レポートこの文書では、Bluetooth Low Energy(2FSK変調)およびIEEE 802.15.4(OQPSK変調)アプリケーション向けFRDM-MCXW72ボードの無線周波数(RF)評価試験結果を示します。 RF: AN14865 KW47およびMCX W72用チャネルサウンディングの基礎:このドキュメントでは、CSテクノロジーの基礎と、カスタムソリューションやアプリケーションでどのように使用できるかについての概要を説明します。 AN14779 KW47およびMCX W72用プリントチャネルサウンディングアンテナ:このアプリケーションノートは、NXPがKW47およびMCX W72コントローラ向けに設計した、プリント回路基板(PCB)上に実装されたプリントアンテナに焦点を当てています。 AN14832 チャンネルサウンディングボードを設計するための基本的な手順 - 多様性のないシンプルなPCBの作成: この文書では、最小限のCSサブシステムの例を示します。無線周波数(RF)経路は、CSアプリケーション全体の特性に大きな影響を与えるため、特に注意が払われます。 AN14747 MCX W72用ロードプルテストレポート:この文書では、供給電流、送信電力、および高調波レベルを測定する目的について説明します。これらの測定値は、被試験デバイス(DUT)が受ける複素出力負荷の振幅と位相を調整しながら監視されます。 AN14868 ANSYSにおけるチャネルサウンディングのRFモデリング:チャネルサウンディングのシミュレーションと解析の手法に焦点を当てる ANSYSツールを使用した無線通信システム AN14855 さまざまな環境におけるチャネルサウンディングテスト:このアプリケーションノートは、 Bluetoothチャネルサウンディング(CS)は、Bluetooth周波数帯域における2つのデバイス間の距離を測定する技術です。精度に影響を与える主要な要因について説明します。 AN14869 複雑なチャネルサウンディングボードを設計するための基本的な手順:高度なCS機能をサポートするハードウェアの作成に焦点を当て、精度を向上させ、マルチパス伝搬などの問題を軽減するために、アンテナダイバーシティや最適化されたRFパスなどが含まれます。 AN2731 2.4GHz通信用小型平面アンテナ:このドキュメントは、アンテナ設計に関する網羅的な解説ではありません。むしろ、お客様がアプリケーションに適したアンテナタイプを選択できるよう、基板レイアウトとアンテナの基本について十分な理解を深めていただくこと、また、パフォーマンスの問題や遅延につながる典型的なレイアウトミスを回避していただくことを目的としています。 セキュリティ: AN14648 MCX W72 インシステムプログラミングユーティリティ:このドキュメントでは、MCX W72 MCUをISPモードで起動し、MCUと通信するための各種シリアル接続を確立する手順を説明します。 AN14613 MCX W72 セキュアブート(SECツール使用): MCX W72は、低消費電力でセキュリティの高いシングルチップ無線MCUです。フラッシュメモリの内容を暗号化データとして保存でき、瞬時に復号化できます。これにより、機密データやアルゴリズムの保護に役立ちます。 AN14646 MCX W72 でのデバッグ認証:このアプリケーション ノートでは、MCUXpresso Secure Provisioning Tool (SEC) を使用したデバッグ認証の手順について説明します。 AN14728 MCX W72 NPXを使用したフラッシュ暗号化:セキュリティ上の理由から、フラッシュメモリに保存されているアプリケーションコードとデータを暗号化して保護する必要性が高まっています。NVM PRINCE XEX(NPX)は、フラッシュメモリコントローラ(FMC)内のモジュールで、最大4つのフラッシュ領域の内容を保護することができます。NPXは、フラッシュコンテンツのオンザフライでの低遅延暗号化と復号化を実行し、開発者とCortex-M33プラットフォームに対して透過的です。開発者の視点から特別な操作は必要ありません。 AN14644 MCX W72 ライフサイクルの管理:このドキュメントでは、ユーザーが利用できるライフサイクルステージ、ライフサイクルへのアクセス方法、ライフサイクルの制限、次のライフサイクルへの移行方法について説明します。 AN14670 EdgeLock 2GO の SPSDK による MCU のプロビジョニング: EdgeLock 2GO は、NXP が運営するフルマネージドのクラウドプラットフォームであり、NXP MCU、MPU、および EdgeLock SE05x セキュアエレメントを統合した IoT デバイスの容易な展開と保守のためのセキュアなプロビジョニングサービスを提供します。 AN14624 EdgeLock 2GO のセキュアプロビジョニングツール (SEC) による MCU のプロビジョニング: EdgeLock 2GO は、NXP が運営するフルマネージドクラウドプラットフォームであり、NXP MCU、MPU、および EdgeLock SE05x セキュアエレメントを統合した IoT デバイスの容易な展開と保守のためのセキュアプロビジョニングサービスを提供します。 AN14544 EdgeLock 2Go MPUおよびMCU向けサービス: EdgeLock 2GOは、IoTデバイスのプロビジョニングと管理のためのNXPのサービスプラットフォームです。これにより、製造時または現場で、デバイスに鍵と証明書を安全にインストールし、デバイスのライフサイクル全体を通して認証情報を最新の状態に保つことができます。EdgeLock 2GOは、各デバイスのセキュリティ機能を活用することで、IoT機器群全体にわたって最適なレベルのセキュリティを実現します。 Bluetoothトレーニング Bluetooth Low Energy 6.0 NXP トレーニング MCX Wシリーズ トレーニング - NXPコミュニティ   RFスイッチ比較:吸収型/反射型 規格比較:ETSI / FCC / ARIBの要件 BLEチャネルサウンディング - 概要 BLEチャネルサウンディング - RFハードウェア BLEチャネルサウンディング - ANSYSモデリングツール BLEチャネルサウンディング - アンテナプロトタイプの検証測定 装置 無線機器:この記事では、プロジェクト開発に役立つ機器へのリンクを提供します。 役立つリンク集 KW47-EVKおよびFRDM-MCXW72用デバッグプローブファームウェアのインストールこの記事では、NXPのMCU-LINKインストーラを使用して、KW47-EVKおよびFRDM-MCXW72用のCMSIS-DAP/SEGGER J-linkファームウェアをインストールする方法について説明します。 KW47/MCXW72のワイヤレス環境におけるNBUのアップデートこの記事では、NBUファームウェアのアップデート方法について説明します。 MCUXpresso for Visual Studio Code でデモ例をインポートして実行する方法:この記事では、MCUXpresso for Visual Studio Code で、ARM GCC ツールチェーンを使用した新しい SDK からデモ例をインポートして実行する方法について説明します。 [MCUXSDK] KW4x、MCXW7x、MCXW2x 用 GitHub SDK の使い方 - NXP コミュニティこのコミュニティ投稿では、GitHub SDK の使い方をステップバイステップで解説します。 [MCUXSDK] GitHub SDK - Bluetooth LEプラットフォームのドキュメント - NXPコミュニティこのコミュニティ投稿では、BLEプラットフォームのドキュメントを提供します。 KW47(オートモーティブ)またはMCXW72(IoT/インダストリアル)を使用してPCBを初回から正しく構築する最良の方法:このコミュニティでは、KW45またはK32W148とMCXW71を使用してPCBを構築するための重要なリンクと、無線性能、低消費電力、無線認証(CE/FCC/ICC)に関するすべての情報を提供しています。 駆動強度変更時の DCDC 障害に対する回避策の実装駆動強度を低く変更し、DCDC 出力電圧が現在の出力電圧以上になったときに、まれに DCDC 障害が発生することがあります。 Kinetisファミリー製品でHCI_bbを使用し、DTMモードにアクセスする方法:この記事は2つのパートで構成されています。 HCI_bbバイナリをKinetis製品に書き込む方法。 R&S CMW270を使用してRF測定を実施する BLE HCIアプリケーションでトランスミッタ/レシーバのテストコマンドを設定する:この記事では、ユーザーがデバイスにシリアルコマンドを送信する方法を示す手順を説明します。 Bluetooth LE HCIブラックボックス クイックスタートガイド:この記事では、シリアルコマンドを使用してユーザーが無線を制御できるようにする簡単な手順について説明します。 Kinetis (../45/47/43;MCX W71/72/70) および MCX W23 パワープロファイルツール (ローカライゼーションを含む) : このページは、Kinetis (KW35/KW38/KW45/KW47/KW43) および MCX W7x (MCX W71/W72/W70) パワープロファイルツール専用です。このツールを使用すると、アプリケーション (自動車または IIoT) の消費電力を推定し、ソリューションのバッテリー寿命を評価できます。 KW47/MCXW72 32MHz & 32kHz 発振マージン: この記事では、回路の発振マージンを適切に設定する方法を説明します。 動画 NXPチャネルサウンディング技術とGoogle Pixel 10のインターフェースこれは、MCX W72 LOCボードがチャネルサウンディングを使用してGoogle Pixel 10スマートフォンと通信する様子を示すデモです。   サポート MCX W72に関するご質問がある場合は、弊社のワイヤレスMCUコミュニティにご質問をお寄せください。 ここ
記事全体を表示
S32K344 - LPUART 发送硬故障 您好, 我正在使用 FreeRTOS 开发 S32K 平台。我有两个任务(UartTask1 和 UartTask2)经常调用 debug_log(),通过 UART 发送信息。 记录结构: debug_log() 会格式化信息并将其排入 FreeRTOS 队列。 专用的 uart_log_task() 使用 Lpuart_Uart_Ip_AsyncSend() 出队并发送每条消息。 UART TX 的完成是通过设置 uart_tx_done 标志的回调来确认的。 在日志任务的 UART 传输后添加了一个小的 vTaskDelay() - 没有观察到队列溢出。 问题: 每次 UART 开始发送时,只能打印几个字符,有时是垃圾字符,然后系统就会出现 硬故障。 在 UART 传输过程中,而不是在传输之前, 。 主要发现: 当我隔离 UART 并在日志系统 (无队列、无多任务)之外测试 时, ,工作正常。因此,UART 驱动程序本身似乎没有问题。 问题 是什么原因导致多任务日志设置崩溃? 是否可能是共享/静态缓冲区(如 tx_data)在 TX 完成之前被覆盖或访问? 在 FreeRTOS 和多个任务中使用 Lpuart_Uart_Ip_AsyncSend(),是否有特定的注意事项? 如有任何帮助或建议,我们将不胜感激。 提前感谢! 我附上了代码片段和 lpuart 配置。 Re: S32K344 - LPUART Tx Send Hard Fault 您好, 尝试找出硬故障的原因。你可以参考:如何在 ARM Cortex-M (V7M) 微控制器上调试故障异常 (S32K3XX) 也许只是增加堆栈,堆大小会有所帮助。 BR, Petr
記事全体を表示
在应用定时测量过程中发生低于阈值的意外 VC_OV 事件 您好,      我使用的是采样率为 24 的应用定时测量模式,并将过压 (OV) 阈值设置为 4250 mV。 但是,在充电过程中,当电池电量达到80%左右(约4077 mV)时,某些电池偶尔会触发信号 VC_OV 事件。手动测量后,实际电池电压不会超过 OV 临界值。 是什么原因导致了这种行为,即即使测量电压明显低于阈值,也会发生 VC_OV 事件? 感谢您的帮助。 Mark 回复: Unexpected VC_OV Events Below Threshold during Application Timed Measurement 您好,马克, 请下载 MC33774A 功能安全手册并参阅其中的第 10、11 节。有一种 FTME(容错测量误差)的描述就是针对你这种情况的。 JozefKozon_0-1752726524781.png 请从 MC33774A 产品页面的 “功能安全” 部分下下载功能安全手册。 JozefKozon_1-1752726656099.png 致以最崇高的敬意 约瑟夫 回复: Unexpected VC_OV Events Below Threshold during Application Timed Measurement 你好,约瑟夫、 非常感谢你们一如既往的支持。 硬件设计已经过当地 FAE 的审查和确认。由于 MC33774A 已完全集成到电池模块中,我们无法使用示波器直接探测单个电池的电压,这一点令人遗憾。 我们还怀疑,对充电电流的控制不足可能会导致瞬态尖峰,进而引发零星的过电压(OV)事件。您的专业解释进一步证实了我们的假设,即这些事件很可能是由瞬态行为引起的。 作为后续问题,我们想问: 您是否推荐任何基于软件的方法来帮助识别由瞬态峰值引起的 OV 事件? 再次感谢您的宝贵帮助。 致以最崇高的敬意, Mark 回复: Unexpected VC_OV Events Below Threshold during Application Timed Measurement 您好,马克, 感谢您提供零件编号和示意图。但是,在原理图中,我看不出你是否在Cells和CTx CBx引脚之间使用了推荐的元器件。有关这些推荐元器件,请参阅 MC33774A 完整数据表中的第 11.1.1.2 节。 JozefKozon_0-1752661083762.png 请从 MC33774A 产品页面 的 "安全 "部分下载 MC33774A 的 完整数据表。 JozefKozon_1-1752661287104.png 在快速充电过程中,可能会出现短暂超过 OV 门限的瞬态电压。这些峰值可能无法通过手动测量捕获,但可以由 MC33774A 检测到。请使用示波器测量触发信号 OV 的单个电池的电压,以检查是否存在瞬态电压。 请确保在充电/测量过程中没有打开平衡装置。在平衡过程中,不保证测量电压。 致以最崇高的敬意 约瑟夫 回复: Unexpected VC_OV Events Below Threshold during Application Timed Measurement 你好,约瑟夫、 谢谢您的答复。 很抱歉之前没有提供足够的信息。 我们使用 MC33774ATP1AE。 这里是零件示意图。 感谢您的帮助。 致以最崇高的敬意 Mark Re: Unexpected VC_OV Events Below Threshold during Application Timed Measurement 您好,马克, 请分享您正在使用的元器件的完整部件号。 请分享您的示意图,包括电压等级和部件值。 致以最崇高的敬意 约瑟夫
記事全体を表示
IMXRT1170-EVKB 上的双以太网配置 大家好, 问候! 我正在研究 IMXRT1170-EVKB 板并实现双以太网(ETH0 和 ETH1)以同时以 100M 和 1G 的速度工作。 我首先导入 SDK 示例“evkbmimxrt1170_lwip_ping_bm_cm7”,该示例在同一工作区内以独立模式成功运行。以太网端口选择通过以下方式控制: - “板载网络使用100M以太网端口(1U)” -“板载网络使用100M以太网端口(0U)” 但是,我需要同时启用两个以太网端口(100M 和 1G)。为了实现这一目标,我采取了以下措施: - 使用 lwIP 配置并初始化两个以太网接口(100M 和 1G)。 - 分配唯一的 MAC 地址、PHY 资源和时钟配置。 - 为每个接口创建“netif_100M”和“netif_1G”结构。 驱动程序和配置文件的修改: 1. 在“opt.h”中启用“IP_FORWARD”。 2. 为两个以太网接口启用 ping 初始化。 3. 更新“lwipopts.h”: - 设置“LWIP_SINGLE_NETIF = 0”以允许多个接口。 - 设置“LWIP_NUM_NETIF = 2”来定义网络接口的最大数量。 整合这些更改后,我可以成功地向两个以太网输入发送 ping 消息。但只有“1G以太网(ETH1)有响应”,而“100M以太网(ETH0)没有收到任何响应”。 我已附上终端截图和完整修改后的项目“evkbmimxrt1170_lwip_ping_bm_cm7”以供参考。您能否检查一下我的配置并指出可能导致此问题的任何缺失步骤? 期待您的指导。 提前谢谢! 此致, 库马尔王子 回复:IMXRT1170-EVKB 上的双以太网配置 你好,山姆, 感谢您的快速回复。 我按照建议做了修改。删除/注释了“ netif_set_default(&netif_100M);”,但问题依旧。比如ping响应只来自1G网络,而不是100M网络。 BR, 库马尔王子
記事全体を表示
当前的 FSS 版本"S32N_FSS_FW_R21-11_1.8.1" 是否支持 S32N53? 你好,团队、 客户 HKMC 将从 S32N55 移至 S32N53。 所以我的问题是 当前的 FSS 版本"S32N_FSS_FW_R21-11_1.8.1" 是否支持 S32N53? 如果不是,什么时候会版本支持 S32N53 的 FSS? 顺祝商祺! 谢谢您! HSE_FW 优先级:高 Re: Does current FSS version "S32N_FSS_FW_R21-11_1.8.1" support S32N53? 你好,谭生、 我们计划在本月(7月底)发布的版本中提供支持; 谢谢! 辛杜
記事全体を表示
Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM Hello, At the AN4581 Application Note section 5.7 it is recommended to program the SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses to completely secure the device, but looking at both the IMX8MMRM and IMX8MMSRM, I wasn't able to find the exact location of those fuses (bank, word, bit). Where can I find this information? Thank you! Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM Hi @igorpadykov , I would appreciate if you could send me this information as well. Thanks in advance Dj Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM Hi, Would it be possible for you to send me this information as well? Also is this diifferent between an imx8m nano  and a mini? Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM We also would like to have this information. Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM hi @igorpadykov, I need information about the fuses for the imx8m mini. Could you be so kind to provide it to me? I need to disable the JTAG for security reasons. Best regrads, Julián Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM @igorpadykov could you also send me the info for the JTAG_HEO fuse? Thanks! Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM Can you also share this with me, please? Why isn't this just posted in a public app note, or the reference manual or security reference manual? Security through obscurity is not security. Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM Could you make this email public information? Why is this information not listed in the security reference manual? For the i.MX8M Nano this is listed in the security reference manual. But I cannot know whether the Mini uses the same fuses. Also, AN4581 also lists fuse DIR_BT_DIS to be of interest. But I cannot find any reference of it. Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM We also want to disable JTAG on the imx8m-mini and I couldn't find any info of about it in Reference Manual, Rev. 2, 08/2019 Chapter 6.2 Fusemap. Could you also point me into the right direction. Thank you! Re: Programming SJC_DISABLE, JTAG_SMODE and JTAG_HEO fuses on iMX8MM Hi rodrigo_travess additional info were sent via mail. Best regards igor
記事全体を表示
CST 4.0.1 の Openssl バージョン こんにちは、 NXPからCST 4.0.1(コード署名ツール)をダウンロードし、 docsフォルダ内のドキュメント(具体的にはUG10106 )を確認したところ、セクション3.1.1に遭遇しました。CST はUbuntu 22.04をサポートし、 OpenSSL 3.2.0が必要であると記載されています。 しかし、私の現在のUbuntu 22.04システムにはOpenSSL 3.0.2が搭載されています。インストールされました。OpenSSL 3.2.0へのアップグレードが心配です既存のシステム依存関係が壊れる可能性があります。CST を使用するには、本当に OpenSSL をアップグレードする必要がありますか?もしSOなら、システムに影響を与えずにそれを実行する最も安全な方法は何ですか? 参考までに、UG10106 のスクリーンショットも添付しました。 ありがとうございます カルティーク Re: Openssl Version for CST 4.0.1 こんにちは@kartheek ! NXP サポートにお問い合わせいただきありがとうございます。 CST ツールの推奨バージョンは OpenSSL 3.2.0 です。 残念ながらOpenSSL 3.0.2のバージョンはテストしていません。このツールを使用する場合は、システムにインストールされているバージョンの CST ツールを試すことをお勧めします。ツールが期待どおりに動作しない場合は、ユーザー ガイドで推奨されているバージョンをインストールしてみてください。 よろしくお願いいたします。 チャビラ
記事全体を表示
CST 4.0.1 的 Openssl 版本 您好, 我从恩智浦下载了CST 4.0.1(代码签名工具),在查看文档文件夹中的文档(特别是UG10106)时,我看到了第3.1.1 节、其中提到 CST 支持Ubuntu 22.04,需要OpenSSL 3.2.0。 不过,我当前的 Ubuntu 22.04 系统使用的是OpenSSL 3.0.2已安装。我担心升级到 OpenSSL 3.2.0可能会破坏现有的系统依赖关系。使用 CST 真的需要升级 OpenSSL 吗?如果是这样,有什么最安全的方法可以在不影响我的系统的情况下做到这一点? 我还附上了 UG10106 的屏幕截图以供参考。 谢谢! Kartheek Re: Openssl Version for CST 4.0.1 您好@kartheek! 感谢您联系恩智浦支持中心! CST 工具的推荐版本是 OpenSSL 3.2.0。 遗憾的是,我们尚未测试 OpenSSL 3.0.2 版本。如果该工具不能按预期运行,则应尝试安装用户指南中推荐的版本。 此致 查维拉
記事全体を表示
S32G3-Linux 上 A53 Core 的 FlexCan 示例版本 您好, 当我版本 FlexCan 示例项目时,我想获得一个 .elf可执行文件,可在Linux 下的 A53 内核上运行。 不过,该示例似乎是为M7 内核设计的。 有没有办法版本或调整 FlexCan 示例,使其生成可执行文件 .elf是否适合 A53 内核? 我还尝试从头开始创建一个针对A53的新应用程序项目,但我不确定如何重复使用或转移所有FlexCan配置(外围设备、驱动程序、初始化代码等)到这个新项目中。 请指导我如何实现这一目标? Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 我更新了主题,说我用 Goldvip 的图片解决了问题。 Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 感谢您分享您正在使用的板。 对于 Goldbox3,你需要在设备树中启用 can0 和 can1 节点。在这些节点中,您可以配置 CAN 输出使用哪些引脚。必须确保所选引脚在其 SSS 中支持 can0 或 can1 输出。 你可以查看哪些引脚可以在主板原理图和参考手册中附带的 S32G3_IOMUX.xlsx 文件中使用(你需要用 acrobat 阅读器打开 RM 才能看到附带的文件) Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 你好,我正在使用这个https://www.nxp.com/design/design-center/development-boards-and-designs/GOLDBOX-3 (S32G3 ) Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 你好@MrAlexIV 你能分享一下你在用哪个板吗?我分享的图片中提到的连接器适用于扩展名为 S32GRV-PLATEVB 的 S32G-VNP-EVB3。 Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 另外,按照手册(我在 S32G3 中关注过)它会提到 J166、J169... 但是在我的板上那些 Jumpers 不可用。 MrAlexIV_0-1753256274840.png Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 谢谢你,卡洛斯。 好吧,我明白你的意思了。我按照您的指示进行了操作,但这样我只能在 can0 和 can1 之间收发信息。我想要的是通过 CAN 总线接收或发送到其他设备(我有一个 CAN 总线,用于连接所有设备)。以 FlexCan 为例,我可以从其他设备接收,但是如果我只有低压差线性稳压器(LDO) candump can0,我就无法从其他设备接收 CAN 消息。 接口未处于环回状态。 这就是我想得到 .elf 的原因。因为我已经测试过 M7 的 FlexCan 示例,它可以正常工作。 我可以将简单的 candump can0 与你建议的 system () 一起使用,但看来我没有收到来自其他设备的 CAN 消息。 MrAlexIV_0-1753255421094.png Re: S32G3 - FlexCAN Example Build for A53 Core on Linux 你好@MrAlexIV 感谢您的提问 在运行 linux 的 A53 内核中,对 gpios、can 等模块的使用有些不同,而不是像裸机或 RTD(如 M7 内核)那样直接通过寄存器传递值。对于Linux的实现,需要一个驱动程序来在操作系统和硬件之间传递这些值,其中一些驱动程序已经在恩智浦提供的电路板支持包发行版中实现了。 要在 Linux 中使用 CAN,您可以查看电路板支持包用户手册中给出的示例 carlos_o_0-1753226320892.png [适用于 S32G2 平台的 Linux 电路板支持包 44.0 用户手册] 这个例子是在 linux 控制台中编写这些命令,你可以编写一个 C 程序,使用system() 函数发送命令,然后只执行你的 C 代码。
記事全体を表示
使用EB配置FS23驱动时报错 _0-1753439081159.png _1-1753439111221.png _2-1753439144529.png 您好,我在配置FS2303驱动时,EB出现如图一的错误提示。但是我在图二的地方已经添加了相关通知函数。同时图三提示的错误也不知道怎样产生的。我使用的是 Autosar4.4   版本2.0的S32K3 mcal驱动和Autosar4.7 版本1.0的FS23 MCAL驱动。我想请问一下上述问题是两个版本不兼容导致的问题吗? Re: 使用EB配置FS23驱动时报错 好的,谢谢您的回复 Re: 使用EB配置FS23驱动时报错 嗨@夏超 从release note里面来看,你所使用的版本确实是不兼容的。 FS23 SBC AUTOSAR R21-11 版本 1.0.0 Senlent_0-1753669563921.png FS23 SBC Autosar 4.4 版本 0.8.0 Senlent_1-1753669688281.png
記事全体を表示
RW612 FlexSPI PORTB1 访问 我在外部 XIP 模式下使用 RW612 芯片组,代码从 FlexSPI 端口 A1 运行,我将 PSRAM(APS6404L)连接到 FlexSPI 端口 B1,我使用 SDK(25.06 版)提供的配置访问端口 B1。 在尝试读取 PSRAM ID 时,我在端口 B1(CLCK/CS)上看不到任何信号活动。 我拆下了 SPARM,以确保这些信号不是由有缺陷的部件保持的。 这是否与 APS6404 不使用 DQS 信号有关? 如何配置 PortB1不使用 DQS? 感谢您的帮助和时间。 Re: RW612 FlexSPI PORTB1 access 你好,罗曼、 感谢您的帮助,问题与总线运行时尝试配置 FlexSPI 时钟有关,我注释了以下几行: CLOCK_EnableClock(kCLOCK_Flexspi); BOARD_SetFlexspiClock(FLEXSPI, 5U, 3U); 现在 FlexSPI 端口 B1 正在运行,我可以使用 AHB 高速缓存从 PSRAM 中写入/读取数据。 感谢您的帮助,非常感谢。 Re: RW612 FlexSPI PORTB1 access 你好@khalidL. 您是否按下图所示在 MCU 设置中定义了 PSRAM 内存部分? RomanVR_1-1753912826626.jpeg 请务必按照项目的Application Code Hub 帖子中提供的步骤操作,如果问题仍然存在,请告诉我。 Re: RW612 FlexSPI PORTB1 access 你好,罗曼、 感谢你的帮助和时间,在将上面的例子内置到我的项目中的过程中,我遇到了以下问题,当我从主服务器调用函数 " __RAMFUNC (SRAM) status_t board_initpsram (void) " 时,代码会静默崩溃。 除了更改链接器文件(main_data.ldt,)之外,我还需要对我的项目进行其他更改才能内置示例main_txt.ldt 和 noinit_noload_section.ldt)然后复制 board.c文件?我认为代码崩溃的原因是 BOARD_InitPsRam 没有正确复制到 RAM 中。 再次感谢您的时间和帮助。 Re: RW612 FlexSPI PORTB1 access 这个例子适用于我的板,非常感谢你的帮助。 Re: RW612 FlexSPI PORTB1 access 你好@khalidL,希望你一切都好。 Application Code Hub 中有一个关于来自外部或非闪存的 XIP 的示例,请帮助我测试共享链接中的示例,并告诉我它是否符合您的项目要求。 要将项目导入 MCUXpresso IDE,请单击"Import from Application Code Hub" 选项。(请注意,本示例需要使用 2.16.00 版 SDK) RomanVR_0-1753821216871.png 进入应用程序代码中心窗口后,搜索示例的名称(来自外部 或非 闪存的 XIP,使用多端口 FlexSPI 模块配置外部 pSRAM),将其选中,然后单击 " Github 链接 " 然后等待 " N ext > " 按钮可以使用。 RomanVR_1-1753821257434.png 点击"Next>" 按钮后,按照步骤从 git 仓库导入项目。最后,当项目在工作区中可用时,您就可以在您的设置上对其进行闪存和测试了。 如果有帮助,请告诉我。
記事全体を表示
TEA2017 27-30V 550W Design, PFC Mosfet rapidly getting hot with DCM/QR/CCM Mode. Howdy. I'm working with a client project, 27-30V, 550W designed using TEA2017 PFC and LLC. Now originally we were using Fixed Freq 55khz for PFC and the mosfets temps were hotter than usual but still controllable via heatsinks, but now we are trying to make our PFC more efficient. Hence utilizing DCM/QR/CCM mode. Unfortunately in our design in DCM/QR/CCM mode the mosfets rapidly goes up to the failure Temps.  things we have tried but didn't work: 1: Using transistors for gate drivers to drive the pfc gate hard 2: Confirming Our switching is happening after rigning period and when the DrainPFC was falling. 3. Disabling LLC and connect load directly to Vboost to test/tune PFC (result: tea didn't switch pfc the Vboost stayed at 327V (SNSBoost at 2V)) We haven't changed much with our design or TEA settings, as we are trying to test DCM/QR/CCM. Any help/clue int he right direction will be very helpful. I have posted the PFC part of the schematic, and CONFIG_D is what we use. Re: TEA2017 27-30V 550W Design, PFC Mosfet rapidly getting hot with DCM/QR/CCM Mode. HI  1: You should confirm which component getting hot the inductor or others,then provide the heat dissipation solution. 2: You can also configure the circuit as attached excel calculate sheet then update your schematic.
記事全体を表示
MC9S12ZVM128 SRAM 双位 ECC 处理 我们正在使用 MC9S12ZVM128,想知道如何处理 SRAM 中的双位 ECC 错误。具体来说,系统是否可以通过使用以下方法执行软件重启来恢复正常运行 CPMUCOP = 0x01; CPMUARMCOP = 0x00;? Re: MC9S12ZVM128 SRAM double bit ECC handling 你好,喇嘛 感谢您的答复。这个问题我们现在已经很清楚了,我相信我们可以结束这个话题。 BR, Mark Re: MC9S12ZVM128 SRAM double bit ECC handling 您好, 让我来概括一下。 在 POR 期间,SRAM 将被初始化。如果检测到双位 ECC 错误: 内存访问受阻。 已通知启动器模块。 7.3.4内存初始化 ... 为避免出现虚假的 ECC 错误报告,允许在首次写入前进行读取的内存操作(如非对齐访问的读取-修改-写入操作)要求在执行首次读取-修改-写入访问之前,内存必须包含有效的 ECC 值。ECC 模块提供在开机阶段将整个内存内容初始化为零的逻辑。在初始化过程中,SRAM 的访问被禁用,RDY 状态位被清零。如果初始化过程完成,则可以访问 SRAM,并设置 RDY 状态位。 POR(上电复位) 它的作用:POR 是通过重新启动电源或由专用 POR 信号触发的全面硬件 RESET。 对 ECC 错误的影响 -SRAM 已清除:所有易失性存储器都丢失,包括损坏的数据。 -ECC 逻辑已 RESET:所有 ECC 错误标志或状态位都被清除。 -寄存器RESET为默认值:所有配置寄存器返回其默认状态。 - 影响:除非从闪存或外部资源重新加载相同的损坏数据,否则系统将重新启动,双位 ECC 错误将不会继续存在。 ________________________________________ COP(计算机正常运行)RESET 它的作用:当软件无法及时维修时,看门狗定时器会触发 COP RESET。 对 ECC 错误的影响 - SRAM 未清除 - ECC 错误持续存在:如果损坏的数据仍在 SRAM 中,ECC 逻辑可能会在重启后再次检测到相同的双位错误。 -寄存器可能保留值:某些寄存器可能会保留其值,具体取决于RESET配置。 ________________________________________ 建议 如果您想保证消除 ECC 错误状态,请使用 POR RESET。如果您正在调试软件故障或从软件故障中恢复,并希望保留内存以供分析,则 RESET COP 可能更合适。 因此,最好确保在 POR 之后检查并处理 RDY,而不使用 RAM。 如果 COP 重新启动了系统,则尝试写入该字,并检查 ECC 错误是否确定。 此致 拉吉斯拉夫
記事全体を表示
NXPの日本語技術記事をまとめた「コンテンツ・マップ」を公開 (日本語ブログ) 2025年よりNXP Japanから日本語の技術記事をたくさんユーザーに届けよう!との想いの下、これまでに多数の技術記事(Tech Blog)を公開してまいりました。 これらの情報をより体系的にご活用いただけるよう「コンテンツ・マップ」(PDF)を公開しています。 *2026/5/11更新 計94個のコンテンツ Keita_Nagashima_0-1778477033130.png 図1.「コンテンツ・マップ」イメージ図(中身は逐次更新します) コンテンツ・マップとは? 本コンテンツ・マップは、NXP製品に関する技術情報をカテゴリ別に整理したもので、Yocto Linux、EdgeAI、Security、PMIC、Interface、NXPへの技術質問方法など、幅広い分野にわたる記事を網羅しています。各記事へのリンクも掲載しており、目的の情報にスムーズにアクセスできる構成となっています。 ・読みたいコンテンツの右端をクリックいただきますと、該当記事に飛ぶことができます。 Keita_Nagashima_1-1757990032973.png 図2.記事へのリンク   「Yocto Linux」、「エッジAI」、「I3C, I 2 C」、「セキュリティ」、「Zephyr」などのトピックについては、実装例やトラブルシューティングのヒントを含む実践的な内容が充実しています。これらは、開発現場での課題解決や新規プロジェクトの立ち上げ時に役立つ情報として、多くの技術者の皆様に活用いただいております。 コンテンツもメイントピック毎に色分けしており、ユーザーの状況に合わせたコンテンツを選択いただけます。 Keita_Nagashima_2-1757990241495.png ・基礎コンテンツ:  一般知識、基礎知識、プロトコルの解説など ・手順コンテンツ:  実際に動かしてみる、環境構築など ・応用コンテンツ:  深い技術知識、デバッグ手法、応用手順など *難易度も目安として★の数で表示しています。      図3.カテゴリ分け 今後について 今後もコンテンツ・マップを本ページに公開・更新することを検討しております。より多くの方々にNXPの技術情報を活用いただけるよう努めてまいります。技術者の皆様はもちろん、教育機関や学生の方々にも参考になる内容となっておりますので、ぜひご覧ください。ブックマークも是非♪ 更新時には、SNSでもご案内いたします。   Facebook_Logo_Primary.png   logo-black.png   Instagram_Glyph_Gradient.png   現在コンテンツ・マップに掲載の「今後のプラン」は、ほんの一部であり、他にも作成予定のコンテンツが多数ございますため、今後の更新にもご期待ください。 2025年よりNXP Japanから日本語の技術記事をたくさんユーザーに届けようとの想いの下、これまでに多数の技術記事(Tech Blog)を公開してまいりました。これらの情報をより体系的にご活用いただけるよう「コンテンツ・マップ」(PDF)を公開しています。 実装例やトラブルシューティングのヒントを含む実践的な内容が充実しており、開発現場での課題解決や新規プロジェクトの立ち上げ時に役立つ情報として、多くの技術者の皆様に活用いただいております。 (読了:5分) introduction 日本語ブログ
記事全体を表示
[i.MX/GST]a collection of several GST debugging tips and known-how On behalf of Gopise Yuan. A collection of several GST debugging tips and known-how. When you need to play onto a DRM layer/plane directly without going through compositor, kmssink should be a good choice: // kmssink, with scale and adjust alpha property (opaque) and zpos (this requires kmssink>=1.16): gst-launch-1.0 filesrc location=/media/AVC-AAC-720P-3M_Alan.mov ! decodebin ! imxvideoconvert_g2d ! kmssink plane-id=37 render-rectangle="<100,100,720,480>" can-scale=false plane-properties=s,alpha=65535,zpos=2 When using playbin, you can still customize the pipeline besides the sink plugin, e.g. add a converter plugin: // Playbin with additional customization on converter before sink: gst-launch-1.0 playbin uri=file:///mnt/MP4_H264_AAC_1920x1080.mp4 video-sink="imxvideoconvert_g2d ! video/x-raw,format=BGRA,width=1920,height=1080 ! kmssink plane-id=44" GST can generate a pipeline graph for analyzing the pipeline in a intuitive manner: // Generate pipeline graph: 1. Export GST_DEBUG_DUMP_DOT_DIR= , GST_DEBUG=4 2. Run pipeline with gst-launch or others. 3. Copy all dump files (.dot) from . Note: one dump file will be created for each state transaction. Normally, what we need will be PAUSE_READY or READY_PAUSE, after which pipeline has been setup. 4. Convert the .dot file to PDF with Graphviz: dot -Tpdf 0.00.03.685443250-gst-launch.PAUSED_READY.dot > pipeline_PAUSED_READY.pdf i.MX 8 Family | i.MX 8QuadMax (8QM) | 8QuadPlus i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Multimedia Yocto Project
記事全体を表示
ニュー・キッド・オン・ザ・ブロック - 60 GHz Wi-Fi <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ユビキタスなコネクティビティの時代を駆け抜け、データに対する飽くなき需要が求められる中、高速コネクティビティソリューションの必要性はかつてないほど高まっています。60 GHzまたは802.11ad Wi-Fiは、家庭やオフィス、高密度の屋内または屋外スペース、フロントホールまたはバックホールアプリケーションなど、あらゆる場所でブロックを引き継ぐ新しい子供です。さらに、この分野は、このマルチギガビットレートスペクトルを最大限に活用するための革新的なアプローチを持つ多くの新しいティア2プレーヤーによって主に影響を受けています。NXPに参加して、当社のSoCがこのエコシステムを促進するためにどのように不可欠であるかを学びましょう。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ユビキタスなコネクティビティの時代を駆け抜け、データに対する飽くなき需要が求められる中、高速コネクティビティソリューションの必要性はかつてないほど高まっています。60 GHzまたは802.11ad Wi-Fiは、家庭やオフィス、高密度の屋内または屋外スペース、フロントホールまたはバックホールアプリケーションなど、あらゆる場所でブロックを引き継ぐ新しい子供です。さらに、この分野は、このマルチギガビットレートスペクトルを最大限に活用するための革新的なアプローチを持つ多くの新しいティア2プレーヤーによって主に影響を受けています。NXPに参加して、当社のSoCがこのエコシステムを促進するためにどのように不可欠であるかを学びましょう。
記事全体を表示