MRF300AN 27MHz VSWR保護および回復戦略 私たちはこのMRF300ANを用いて、医療美容アプリケーション向けの300W、27MHzのCW RFジェネレーターを開発しています。荷重(ハンドピース)が一時的に開回路になることがあり、堅牢な保護と回復戦略が必要です。我々は、開放負荷時の安全な電力レベルを求めているわけではありません（65:1 VSWRの堅牢性はパルス状であることがわかっています）。CWへの過負荷を防ぐため、システムレベルの保護アーキテクチャと復旧タイミングの最適化に取り組んでいます。 これまでに実施したこと: 3つのトロイド方向カプラーは、前方および電力の反射をサンプリングします。検出された直流レベルはヒステリシスを伴うコンパレータに供給されます。反射電力が閾値を超えるとラッチが設定され、シャントFETがMRF300ANゲートバイアスを急速にゼロに引き寄せます。MCUはラッチをリセットでき、また小信号のRF入力レベルも制御できます。つまり、基本的な検出、比較、ラッチ、ゲートバイアスのプルダウンチェーンが整っており、MCUはラッチをリセットしドライブレベルを調整できます。 私たちの懸念と具体的な支援が必要なギャップ: 電流回復シーケンスは、基本的にMCUがラッチをリセットし、ゲートバイアスが戻り、ドライブが復元されるというものです。これはあまりにも対称的すぎると認識しています。保護は迅速に行われるべきですが、復旧は慎重に行われるべきです。このアプリケーションに全体のアーキテクチャが適しているか確信が持てず、回復タイミングのデザイン方法も不明です。(1) 開積力状態がまだ存在している間にPAが再作動しないこと、(2) 最初の再突入試み自体が二次的な過負荷イベント情報を生じさせないよう。 Q1:建築 コンパレータ-ラッチ-ゲート-プルダウン方式は27 MHz CWに対する適切な一次保護でしょうか?それともこの電力クラスとアプリケーションに適したトポロジーがあるのでしょうか?いくつかの代替案の言及を見ており、CW医療ジェネレーターの27 MHzでのMRF300ANにどの方向が最も適切かについて、NXPのアプリケーションレベルの判断をいただけるとありがたいです。 - PA出力にPINダイオードを用いたシャントまたはスイッチ保護を施し、障害時に制御インピーダンスを提示したりPAを絶縁したりします。 - MRIやその他の医療用RFチェーンで一般的に用いられる終端負荷を持つ循環器/アイソレーター。コストと体積のペナルティを受け入れます。 - レイヤー保護:非常に高速なハードウェアパスが突然のオープンサーキットイベント情報を処理し、より遅いパス(MCUまたはALC)がフォールドバックとリカバリーを管理します。 - コンパレータ+ラッチ+ゲートバイアスプルダウンを主な保護として保持し、最終線電圧クランプとしてTVSクランプを追加すること。 MRF300ANを特に27MHz CWで使用する場合、これらのうちどれかを好む、あるいは避けるべき理由はありますか？特に、PINダイオード出力スイッチがゲートバイアスプルダウン単独と比べてデバイスの負荷を実質的に軽減できるのか、それともこの周波数と電力レベルで自身の損失と信頼性のトレードオフが生じるのかに関心があります。 Q2:回復のタイミング 故障後に無差別にラッチをリセットすると、PAが保護閾値でチャタリングし、繰り返し応力を注入する可能性があることを理解しています。NXP社による保有期間延長および再参入制度に関するガイダンスを希望します。 ・システムは、障害発生後、再突入試行を許可する前に一定の待機時間を強制すべきでしょうか？ 再突入時、負荷が安全なVSWRに戻ったかどうかを確認するために、短時間の低電力プローブ（例えば、短時間の低駆動バースト）を使用し、その後、駆動を徐々に増加させてから、全電力に戻すことは許容されますか？NXPコミュニティのガイダンスでは、初期起動時に急激にフルドライブするのではなく、徐々に電源を入れることを推奨しています。私たちはこの原則を故障復旧にも拡張しようとしています。 - CW動作時のMRF300ANにはNXP推奨のランププロファイルや再突入電力上限があるのか、それともこれはデバイスに依存しないシステムレベルの状態機械設計として扱うべきか? Q3:TVSの役割 NXP 27 MHzのリファレンス・デザインの議論では、ドレインからグラウンドまでの110V TVSについて議論され、スタンドオフ電圧は最大通常のドレイン電圧を上回るべきだというガイダンスが示されていました。当社のシステムには、既に能動的な反射電力保護機能が備わっています。TVSは、アクティブ保護が作動するまでの短い期間における最終ラインの遮断装置として扱うべきなのか、それとも保護機能のより大きな役割を担うことが期待されるのか？27 MHz CWでは、TVSの接合静電容量や応答速度が通常のRF波形忠実度に何か懸念をもたらすのでしょうか? 最も役立つものは以下の通りです: アプリケーションレベルのガイダンス、推奨アーキテクチャ、LDMOS PAのVSWR保護と回復に関する既存のNXPアプリケーションノートへの指針、あるいはNXP自身のリファレンス・デザインが故障・ホールドオフ再突入シーケンスをどのように扱っているかの簡単な説明があれば、デザインに直接反映されるでしょう。 よろしくお願いします。 Re: MRF300AN 27MHz VSWR Protection and Recovery Strategy こんにちは@fengyuqiさん 詳細な説明をありがとうございました。コンパレータ、ハードウェアラッチ、アクティブゲートバイアスプルダウンが合理的な一次保護経路を形成します。300WのCWアプリケーションでは、単一のメカニズムに頼るのではなく、レイヤーアーキテクチャの一部として利用することを推奨します。 可能な限り、高速なハードウェア経路はRFドライブを抑制しつつゲートバイアスを引き下げるべきです。MCUは即時のシャットダウンループの一部であってはなりません。その後のホールドオフ、診断、制御された再突入、繰り返しの故障ロックアウトを管理するべきです。 PINダイオードスイッチは、PA出力を既知で適切に定格されたインピーダンスに転送する場合のみ、ストレスを軽減できます。ハンドピースを単に接続解除するだけでも、別の断線状態が発生する可能性があります。この電力レベルでは、挿入損失、ダイオードの発熱、定格電圧、スイッチング過渡現象、およびスイッチング時に生じるインピーダンスをすべて考慮する必要があります。定格終端を持つ循環器は負荷のアイソレータを強化しますが、サイズ、コスト、損失のトレードオフが大きいです。 回復のためには、一定の最小ホールドオフに続いて低電力プローブと制御されたドライブランプを行うというシステムレベルのアプローチが妥当である。プローブ中は、前方電力と反射電力の両方を監視する必要がある。なぜなら、検出器のノイズフロア付近では、反射電力対前方電力比が不正確になる可能性があるからである。新たな障害が発生した場合は、システムは直ちにラッチ状態に戻り、繰り返し失敗した場合は、より長いバックオフ時間、または永久的なロックアウトとなるべきである。 NXPはMRF300ANについて、専用のホールドオフ時間、ランププロファイル、または再突入電力の上限値を規定していません。これらの値は、保護回路の応答、整合回路に蓄積されたエネルギー、検出器のダイナミックレンジ、バイアスの安定化、熱条件、および想定される負荷挙動に依存します。したがって、それらはシステムレベルで決定および検証される必要があり、複数の位相不整合角でのテストも含まれる。 ドレインTVSは、アクティブシャットダウンが有効になるまでの期間における最終ラインの過渡クランプとして考えるべきである。連続反射RF パワーを吸収することは期待できません。スタンドオフ電圧、クランプ挙動、パルスエネルギー能力、接合静電容量、パッケージ/レイアウトの寄生要素はすべてRFおよび過渡分析に含めなければなりません。なぜなら、デバイスは27 MHzの出力マッチングに影響を与える可能性があるためです。 公開されたMRF300AN 27 MHzリファレンスデザインには、適格な故障ホールドオフ再突入シーケンスは定義されていないため、完全な保護アーキテクチャはアプリケーション固有の設計責任に委ねられています。 よろしくお願いいたします。 パベル

Mifare Plus EV2のフルデータシートはどこで手に入りますか? MIFARE Plus EV2の完全なデータシートはどこで見つけられますか? AuthenticateSectorSwitchコマンドの使い方について詳細な手順が必要です。 Re: Where Can I Find Mifare Plus EV2 full datasheet? こんにちは、 @YangGyu DS 522334-MF1 P(H)x2 - MIFARE Plus EV2 リクエストは [email protected] 宛にメールでお送りください。 BR ケリー Re: Where Can I Find Mifare Plus EV2 full datasheet? ご指摘のファイルが見つかりません。 追加のリクエストを提出すべきでしょうか？ Re: Where Can I Find Mifare Plus EV2 full datasheet? ご指摘のファイルが見つかりません。 追加のアクセス申請を提出すべきでしょうか?  Re: Where Can I Find Mifare Plus EV2 full datasheet? こんにちは、 @YangGyu https://www.nxp.com/products/MFPEV2?ticket=ST-2765-SsyUzuME1f4C5JrCBJ3-gU5P4Gk-nxp#myDocumentにアクセスして、以下を選択してください。 BR ケリー

i.MX 93 – プリビルドのUbuntu/Debian Linuxイメージおよびカスタムキャリアボードサポート こんにちは、NXPサポートチームの皆さん、 私はEVSEアプリケーション用に i.MX 93プラットフォームを評価しているところ、EVSE-IMX93開発キットに出会いました。 利用可能なLinuxイメージと、それらが潜在的なカスタムキャリアボードデザインとの互換性について明確にしたいと思います。 私たちの意図は、MCIMX93-SOMを用いて、元のNXPキャリアボードデザインを基にした簡素化されたカスタムキャリアボードを開発することです。使用していないペリフェラルや回路を除去しつつ、SOMコネクタとピンの割り当ては同じままにします。 私は i.MX プロセッサプラットフォームとYoctoベースの開発にはまだ比較的新しいため、カスタマイズに進む前にすぐに使えるLinuxソリューションを探しています。 以下の点を明確にしていただけますか? i.MX 93用の 使いやすいUbuntuやDebian 13(Trixie)イメージ はありますか ?できれば汎用サーバーや最小限のLinuxイメージが望ましいです。 このイメージは、Yoctoビルドなしで直接microSDカードにダウンロードしてフラッシュしてボードを起動できますか? 利用可能な画像はapt、Python 3、SSH、systemd、networkingなどの標準的なLinux機能をサポートしていますか? CAN/CAN-FD(SocketCAN)、Wi-Fi、イーサネット、MQTT のサポートは含まれています か?Mosquittoのようなパッケージはaptでインストールできますか? 元のSOMコネクタと関連するハードウェア接続を保持すれば、同じプリビルドイメージを提案しているカスタムキャリアボードに使うことは可能でしょうか?デバイスツリーまたは設定の変更のみが必要となるのでしょうか？ もしそのような画像があれば、直接ダウンロードリンク、対応ボードの詳細、インストール手順を共有していただけると助かります。 私たちの目標は、i.MX 93をEVerestフレームワークやその他のEVSEアプリケーションソフトウェアを動かす汎用Linuxプラットフォームとして活用しつつ、最初にYoctoビルドの保守を回避することです。 ご協力ありがとうございました。 敬具 ガネーシュ・バグワット Re: i.MX 93 – Prebuilt Ubuntu/Debian Linux Image and Custom Carrier Board Support こんにちは、 はい、i.mx93プラットフォームに対応したDebian Linux SDKがあります。Yoctoではなく「Flexbuild」の実装を通じてイメージを構築し、flexinstallerツールでイメージをフラッシュできます。ディストリビューションのサポートパッケージについてはこちらで詳しくご覧いただけます: DEBIAN-SDK Debianソフトウェアリリースノート LDLSDK_26.06

i.MX95：在定制硬件上 OP-TEE xtest 测试失败 你好， 我最近将基于 i.MX95 (B0 rev) 的自定义硬件的 BSP 从 Linux 6.12.49_2.2.0 移植到了 Linux 6.18.37_2.1.0。突然，OP-TEE 的 xtest 开始出现测试失败的情况（xtest 输出已附上）。 经过一番调查，我发现故障源于 OP-TEE 核心无法验证从文件系统加载的 TA 上的 RSA 签名；这是由于 ELE 总是对 RSA 验证请求响应 ELE_INVALID_MESSAGE 造成的。 以下是 CFG_TEE_CORE_LOG_LEVEL=2 和 CFG_TEE_TA_LOG_LEVEL=2 时 OP-TEE 输出的摘录： E/TC:? 0 imx_ele_signature_verification:391 签名验证失败 res = ffff0006 ETC：？0 do_verify:514 RSA 签名验证失败 E/LD: init_elf:494 sys_open_ta_bin(cb3e5ba0-adf1-11e0-998b-0002a5d5c51b) ETC：？0 ldelf_init_with_ldelf:152 ldelf 失败，返回值为：0xffff000f 有什么建议可以帮助我调查吗？ 先感谢您 Linux 安全 Re: i.MX95: OP-TEE xtest failing on custom hardware 我找到了罪魁祸首：新的 电路板支持包。 启用了 ELE 支持的 ECC 和 RSA，但它们依赖于已加载的 ELE 运行时固件。可以通过以下方式触发负载： echo 1 > /sys/kernel/se/se_load_fw 预期的 dmesg 输出为：   fsl-se secure-enclave-0：正在加载固件 imx/ele/mx95b0runtime-ahab-container.img fsl-se secure-enclave-0：固件已成功加载   Re: i.MX95: OP-TEE xtest failing on custom hardware 你好@fvalla-MTA 是的你是对的。 版本 6.18.37 需要加载 ELE 运行时固件。 B.R

生成式人工智能的应用：通过智能创新变革企业 生成式人工智能（GenAI）正在迅速改变企业的运营方式、创新方式以及与客户互动的方式。从自动化内容创作和智能聊天机器人到高级数据分析和人工智能驱动的应用，生成式人工智能正在成为现代数字化转型的重要组成部分。 然而，成功应用人工智能不仅仅是实施新技术。它关乎识别正确的商业机会、了解组织面临的挑战以及创造可衡量的价值。 生成式人工智能的日益普及 各行各业的组织都在探索生成式人工智能，以提高生产力、降低运营成本、加快决策速度并提供个性化的客户体验。 根据安永会计师事务所发布的《2025 年印度高管调查报告》，47% 的组织表示在生产环境中拥有多个生成式人工智能用例。这标志着从最初的实验阶段转向了实际的商业实施阶段。 一些关键的采用领域包括： 业务自动化：自动化重复性任务、工作流程和运营流程。 客户体验：开发智能虚拟助手和个性化客户互动。 内容创作：创建营销内容、报告、产品描述和商业沟通材料。 数据智能：从大型数据集中提取洞见，为明智的决策提供支持。 软件开发：加速编码、测试、文档编写和应用程序开发。 人工智能应用面临的挑战 尽管生成式人工智能具有巨大潜力，但企业在采用该技术时仍面临诸多挑战。数据隐私、模型准确性、集成复杂性、基础设施成本和负责任的人工智能治理仍然是重要的考虑因素。 组织还必须确保人工智能生成的输出结果可靠、透明，并符合业务需求。人工监督和持续评估对于建立人们对人工智能系统的信任至关重要。 研究驱动的生成式人工智能应用 Enaviya 认为，成功采用生成式人工智能始于研究、业务理解和正确的技术战略。 从研究和技术的角度来看，研究新兴人工智能模型如何解决现实世界的商业问题非常重要。这包括评估大型语言模型（LLM）、探索功能域特定的 AI 应用、了解自动化机会以及评估 AI 集成的实际影响。 Enaviya 致力于通过生成式人工智能开发、LLM 集成、人工智能代理、定制人工智能应用程序和智能自动化，将这些机遇已翻译为可扩展的业务解决方案。 研究驱动的方法可以帮助组织摆脱对人工智能工具的试验，专注于能够带来可衡量的业务成果的解决方案。 请在本帖中分享您的反馈意见。 Re: Generative AI Adoption: Transforming Businesses Through Intelligent Innovation 感谢分享这份概述——关于在推出新工具之前进行调研的观点真的让我很有共鸣。根据我的经验，那些从人工智能中获益最多的团队，是在漫长的测试和文档编写过程中安排适当的休息时间，并保持基本工作的正确性，而不是试图一次性完成所有事情。短暂的休息，喝杯好咖啡，确实能帮助我更清醒地重新思考问题。如果您喜欢在家中储备充足的物资，不妨看看这个网站。

关于 SIMULATED_IN_FIELD Lifecy 中间歇性 SYS_AUTH_REQ 和 NVM 密钥导入失败的调查 你好， 我们正在运行 HSE_B FW 2.40.0 的 S32K328 设备上，使用 SIMULATED_IN_FIELD 生命周期测试 SYS_AUTH_REQ 和 NVM 密钥导入服务。 在测试过程中，我们观察到这些服务的成功或失败取决于RESET周期和服务调用的顺序。我们希望您能协助我们澄清这一行为。 1. 测试环境和配置 - MCU：S32K328 - HSE 固件：S32K358_HSE_FW_2.40.0 - 目标生命周期：IN_FIELD - 测试生命周期：现场模拟 - NVM 密钥组所有者：HSE_KEY_OWNER_OEM SYS_AUTH_REQ 配置 - 授权密钥类型：AES - 授权密钥长度：256 位 - 授权密钥所有者：HSE_KEY_OWNER_OEM - 认证算法：AES-256-CMAC - sysAuthOption = HSE_SYS_AUTH_ALL - sysRights = HSE_RIGHTS_SUPER_USER SYS_AUTH 过程按如下方式执行： 1.调用 HSE_SRV_ID_SYS_AUTH_REQ 服务以接收来自 HSE 的质询。 2. 使用授权密钥在主机上计算 AES-256-CMAC。 3.使用计算出的 CMAC 调用 HSE_SRV_ID_SYS_AUTH_RESP 服务。 4. 身份验证成功后，授予 SU（超级用户）权限。 2. 测试程序 1. ECU启动 2. 将生命周期设置为 SIMULATED_IN_FIELD 3.调用 SYS_AUTH_REQ 或 NVM 密钥导入服务 4. 如果调用了 SYS_AUTH_REQ，则执行质询-响应过程 5. 检查服务执行结果 我们在多个RESET周期内重复了上述测试。 3. 观察到的行为 在多次RESET周期中重复测试后，我们观察到以下现象。 案例 1. SYS_AUTH_REQ 之后的 NVM 密钥导入 - SYS_AUTH_REQ 服务有时会成功，有时会失败。 - 如果初始 SYS_AUTH_REQ 服务成功，则通过质询-响应过程授予 SU 权限，并且在同一 RESET 周期内紧随其后的 NVM 密钥导入服务也会成功完成。 - 如果初始 SYS_AUTH_REQ 服务失败，则返回 HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL)。 - 在这种情况下，在同一 RESET 周期内立即调用的 NVM 密钥导入服务总是会成功。 案例 2. 首先请求导入 NVM 密钥 - NVM密钥导入服务有时会成功，有时会失败。 - 如果 NVM 密钥导入失败，则返回 HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL)。在同一RESET周期内紧随其后的 SU 授权过程 (SYS_AUTH_REQ → SYS_AUTH_RESP) 总是成功的。 - 相反，如果 NVM 密钥导入成功，则在同一RESET周期内紧随其后调用的 SYS_AUTH_REQ 服务始终返回 HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL)。 案例 3. 获取 SU 权限并完成 NVM 密钥导入后再次调用 SYS_AUTH_REQ - 即使初始 SYS_AUTH_REQ 和 SYS_AUTH_RESP 调用成功并授予了 SU 权限，随后 NVM 密钥导入服务也成功完成，但在同一 RESET 周期内再次调用 SYS_AUTH_REQ 总是返回 HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL)。 补充观察 我们还进行了 MCU RESET 后的测试，以调查这种行为是否可能是由于先前 RESET 周期中保留的 SU 权限引起的。 例如，我们观察到以下序列也存在同样的现象： 1.请致电NVM密钥导入服务。 2. NVM 密钥导入失败（HSE_SRV_RSP_NOT_ALLOWED）。 3. 执行MCU RESET。 4. 调用 SYS_AUTH_REQ 服务。 5. SYS_AUTH_REQ 失败（HSE_SRV_RSP_NOT_ALLOWED）。 6.请致电NVM密钥导入服务。 7. NVM密钥导入成功。 因此，根据我们目前的测试结果，很难断定这种行为是由先前RESET周期中保留的SU权限引起的。 总体而言，两项服务的成功与否取决于RESET周期，我们观察到一种趋势，即一项服务在另一项服务失败时反而会成功。 4. 问题 1. 现场模拟生命周期 - 在 SIMULATED_IN_FIELD 生命周期和实际 IN_FIELD 生命周期中，SYS_AUTH_REQ / SYS_AUTH_RESP 和 NVM 密钥导入服务的行为是否存在任何差异？ - 在 SIMULATED_IN_FIELD 生命周期中使用这些服务是否存在任何已知的限制？ 2. 重复的SU授权请求 - 在已授予 SU 权限的情况下，在同一 RESET 周期内再次调用 SYS_AUTH_REQ 是否会返回 HSE_SRV_RSP_NOT_ALLOWED？ - 是否允许在同一个 RESET 周期内多次执行 SU 授权程序，或者是否有推荐的使用模式？ 3. 实际 IN_FIELD 生命周期中的行为 - 同样的情况是否也会发生在实际的 IN_FIELD 生命周期中，也就是我们最终的目标生命周期中？ - 在实际的 IN_FIELD 环境中，是否有推荐的可靠使用 SU 授权和 NVM 密钥导入的步骤？ - 如果这些服务在实际的 IN_FIELD 生命周期中可靠运行，是否也允许在同一个 RESET 周期内多次执行 SU 授权程序？ 4. 授权密钥配置 - 使用 256 位 AES 密钥的 AES-256-CMAC 进行 SYS_AUTH 认证是否有效？ - 当授权密钥用于 SYS_AUTH 时，对授权密钥的密钥类型、密钥长度、密钥所有者或密钥用途是否有任何限制？ 鉴于此事的紧迫性，我们非常感谢您的及时回复。 感谢您的支持。 Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li 你好， 这纯粹是我的失误。 一切运行正常。 给您带来的不便，敬请谅解。 如果您能删除这个问题，我将不胜感激。 感谢您的帮助。 Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li 嗨@wodudwo 你描述的行为在我看来有些不寻常，尤其是考虑到RESET周期之间的差异。 首先，我建议消除数据缓存可能造成的任何影响。请您在项目中完全禁用数据缓存，然后重新进行测试，看看情况是否会发生变化？ 我还想确认一下时钟配置，以排除这方面的问题。请将您配置工具中相关时钟设置的截图发送给我。您是否在 UTEST DCF 中修改了 HSE_CLK_MODE_AND_GSKT_CTRL？ 同时，我将检查是否存在与此场景相关的已知问题，并验证您提出的问题的答案。 此致， Lukas

Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Lifecy Hello, We are testing the SYS_AUTH_REQ and NVM Key Import services with the SIMULATED_IN_FIELD Lifecycle on an S32K328 device running HSE_B FW 2.40.0. During testing, we observed that the success or failure of these services varies depending on the Reset Cycle and the order in which the services are called. We would appreciate your assistance in clarifying this behavior. 1. Test Environment and Configuration - MCU: S32K328 - HSE Firmware: S32K358_HSE_FW_2.40.0 - Target Lifecycle: IN_FIELD - Test Lifecycle: SIMULATED_IN_FIELD - NVM Key Group Owner: HSE_KEY_OWNER_OEM SYS_AUTH_REQ Configuration - Authorization Key Type: AES - Authorization Key Length: 256-bit - Authorization Key Owner: HSE_KEY_OWNER_OEM - Authentication Algorithm: AES-256-CMAC - sysAuthOption = HSE_SYS_AUTH_ALL - sysRights = HSE_RIGHTS_SUPER_USER The SYS_AUTH procedure is performed as follows: 1. Call the HSE_SRV_ID_SYS_AUTH_REQ service to receive a challenge from the HSE. 2. Calculate AES-256-CMAC on the Host using the Authorization Key. 3. Call the HSE_SRV_ID_SYS_AUTH_RESP service with the calculated CMAC. 4. Upon successful authentication, SU (Super User) rights are granted. 2. Test Procedure 1. ECU Boot 2. Set the Lifecycle to SIMULATED_IN_FIELD 3. Call either the SYS_AUTH_REQ or NVM Key Import service 4. If SYS_AUTH_REQ is called, perform the Challenge-Response procedure 5. Check the service execution result We repeated the above tests over multiple Reset Cycles. 3. Observed Behavior After repeating the tests over multiple Reset Cycles, we observed the following behavior. Case 1. NVM Key Import after SYS_AUTH_REQ - The SYS_AUTH_REQ service sometimes succeeds and sometimes fails. - If the initial SYS_AUTH_REQ service succeeds, SU rights are granted through the Challenge-Response procedure, and the NVM Key Import service called immediately afterward within the same Reset Cycle also completes successfully. - If the initial SYS_AUTH_REQ service fails, it returns HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL). - In this case, the NVM Key Import service called immediately afterward within the same Reset Cycle is always successful. Case 2. NVM Key Import requested first - The NVM Key Import service sometimes succeeds and sometimes fails. - If NVM Key Import fails, it returns HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL). The SU authorization procedure (SYS_AUTH_REQ → SYS_AUTH_RESP) called immediately afterward within the same Reset Cycle is always successful. - Conversely, if NVM Key Import succeeds, the SYS_AUTH_REQ service called immediately afterward within the same Reset Cycle always returns HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL). Case 3. Calling SYS_AUTH_REQ again after obtaining SU rights and completing NVM Key Import - Even if the initial SYS_AUTH_REQ and SYS_AUTH_RESP calls succeed and SU rights are granted, followed by successful completion of the NVM Key Import service, calling SYS_AUTH_REQ again within the same Reset Cycle always returns HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL). Additional Observation We also performed tests after an MCU Reset to investigate whether this behavior could be caused by SU rights retained from a previous Reset Cycle. For example, we observed the same behavior with the following sequence: 1. Call the NVM Key Import service. 2. NVM Key Import fails (HSE_SRV_RSP_NOT_ALLOWED). 3. Perform an MCU Reset. 4. Call the SYS_AUTH_REQ service. 5. SYS_AUTH_REQ fails (HSE_SRV_RSP_NOT_ALLOWED). 6. Call the NVM Key Import service. 7. NVM Key Import succeeds. Therefore, based on our test results so far, it is difficult to conclude that this behavior is caused by SU rights being retained from a previous Reset Cycle. Overall, the success and failure of the two services vary depending on the Reset Cycle, and we have observed a tendency for one service to succeed when the other service fails. 4. Questions 1. SIMULATED_IN_FIELD Lifecycle - Is there any difference in the behavior of SYS_AUTH_REQ / SYS_AUTH_RESP and the NVM Key Import service between the SIMULATED_IN_FIELD and actual IN_FIELD Lifecycles? - Are there any known restrictions on using these services in the SIMULATED_IN_FIELD Lifecycle? 2. Repeated SU Authorization Requests - Is it expected that calling SYS_AUTH_REQ again within the same Reset Cycle, after SU rights have already been granted, returns HSE_SRV_RSP_NOT_ALLOWED? - Is it permitted to perform the SU authorization procedure multiple times within the same Reset Cycle, or is there a recommended usage pattern? 3. Behavior in the Actual IN_FIELD Lifecycle - Could the same behavior occur in the actual IN_FIELD Lifecycle, which is our final target Lifecycle? - Is there a recommended procedure for reliably using SU authorization and NVM Key Import in the actual IN_FIELD environment? - If these services operate reliably in the actual IN_FIELD Lifecycle, is it also permissible to perform the SU authorization procedure multiple times within the same Reset Cycle? 4. Authorization Key Configuration - Is it valid to use AES-256-CMAC with a 256-bit AES key for SYS_AUTH? - Are there any restrictions on the Authorization Key's Key Type, Key Length, Key Owner, or Key Usage when it is used for SYS_AUTH? Given the urgency of this issue, we would greatly appreciate your prompt response. Thank you for your support. Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li Hello, This was simply a mistake on my part. Everything is working as expected. I apologize for the inconvenience. I would appreciate it if you could delete this question. Thank you for your help. Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li Hi @wodudwo  The behavior you described seems somewhat unusual to me, especially considering the variation between reset cycles. As a first step, I would recommend eliminating any possible influence of the data cache. Could you please disable the data cache completely in the project and repeat the tests to see if the behavior changes? I would also like to verify the clock configuration, just to rule out any issue there. Please send me screenshots of the relevant clock settings from your configuration tool. Did you modified HSE_CLK_MODE_AND_GSKT_CTRL in UTEST DCF? In parallel, I will check whether there are any known issues related to this scenario and verify the answers to the questions you raised. Regards, Lukas

TCL - EB Tresos v29.0.0 のツール信頼度レベルに関するドキュメント NXP管理者の皆様へ EB Tresosに関するTCL文書を送っていただけますでしょうか。MCAL/RTDパッケージの中に見当たりませんでした。 可能であれば、セーフティマニュアルも送っていただけますか？もしくは、MCAL/RTDのどこに記載されているか教えていただけますか？ よろしくお願いします、 シャロン Re: TCL - Tool confidence level document for EB Tresos v29.0.0 こんにちは、 @sharonfmc93 さん、 TCL社向けにEB Tresosに関する情報がいくつか存在するが、機密保持契約（NDA）の対象となっている。代わりにサポートチケットを発行していただけますか？ 可能であれば、セーフティマニュアルも送っていただけますか？もしくは、MCAL/RTDのどこに記載されているか教えていただけますか？ セーフティマニュアル（およびセーフティ関連情報すべて）は、 S32K3製品ページのドキュメントにある「セキュアファイル」にあります。 セキュアアクセス権限を申請していない場合は、よくある質問（FAQ）をご覧ください：セキュアアクセス権限に関するよくある質問 | NXP Semiconductors 。 よろしくお願いします、 ジュリアン Re: TCL - Tool confidence level document for EB Tresos v29.0.0 こんにちは、 @allenlw さん。 EB Tresosの場合、ツールインパクトはTI2、ツール検出はTD1です。 EB Tresos Studioのソフトウェアツールに対するISO 26262の信頼度を説明した文書があります。ただし、前述のとおり、この文書は秘密保持契約（NDA）の対象となります。 サポートCASEを開設し、依頼された書類を共有できるよう有効なNDA番号を提供してください。 よろしくお願いします、 ジュリアン Re: TCL - Tool confidence level document for EB Tresos v29.0.0 こんにちは、ジュリアン EBのTresos TCLレベルに関する情報は見当たりませんでしたが、どのファイルを教えてもらえますか?

生成型AIの導入：インテリジェントなイノベーションを通じてビジネスを変革する 生成型AI、マシン・ラーニング（機械学習）(GenAI)は、企業の運営方法、イノベーション、お客様との関わり方を急速に変えています。自動コンテンツ作成やインテリジェントチャットボットから高度なデータ分析、AI搭載アプリケーションに至るまで、生成AIは現代のデジタルトランスフォーメーションにおいて重要な一部となりつつあります。 しかし、AIの導入を成功させるには、単に新テクノロジを導入することだけではありません。それは、適切なビジネスチャンスを見極め、組織的な課題を理解し、測定可能な価値を創造することに関わる。 生成型AIの普及拡大 業界の組織が生産性向上、運用コスト削減、意思決定の迅速化、パーソナライズされたお客様体験の提供のために生成AIを模索しています。 EYの2025年インドCスイート調査によると、47%の組織が複数の生成AIのユースCASEを本環境で抱えていると報告しています。これは、初期の実験段階から、実際のビジネスへの導入へと移行していることを示している。 導入の主な分野には以下のようなものがあります。 ビジネスオートメーション:繰り返しの作業、ワークフロー、運用プロセスの自動化。 お客様体験:インテリジェントなバーチャルアシスタントとパーソナライズされた顧客対応の開発。 コンテンツ生成:マーケティングコンテンツ、レポート、製品説明、ビジネスコミュニケーションの作成。 データインテリジェンス：大規模データセットから洞察を抽出し、情報に基づいた意思決定を支援する。 ソフトウェア開発: コーディング、テスト、ドキュメント作成、アプリケーション開発の加速。 AI導入における課題 潜在能力は高いものの、企業が生成型AIを導入する際には、いくつかの課題に直面する。データプライバシー、モデルの精度、統合の複雑さ、インフラストラクチャコスト、責任あるAIガバナンスは依然として重要な考慮事項です。 組織はまた、AIが生成する出力が信頼性が高く、透明性があり、ビジネス要件に合致していることを確保しなければならない。AI搭載システムにおける信頼構築には、人間の監督と継続的な評価が不可欠です。 研究主導型生成AIの導入 Enaviyaでは、生成AIの成功はリサーチ、ビジネス理解、そして適切なテクノロジ戦略から始まると信じています。 研究およびテクノロジの観点からは、新興のAIモデルが現実世界のビジネス課題にどのように対応できるかを研究することが重要です。これには、大規模言語モデル(LLM)の評価、ドメイン特化したAIアプリケーションの探求、オートメーションの機会の理解、AI統合の実用的影響の評価が含まれます。 Enaviyaは、生成AI開発、LLM統合、AIエージェント、カスタムAIアプリケーション、インテリジェントオートメーションを通じて、これらの機会をスケーラブルなビジネスソリューションへと転換することに注力しています。 研究主導型のアプローチは、組織がAIツールの実験段階を超え、測定可能なビジネス成果をもたらすソリューションに焦点を当てるのに役立ちます。 ぜひこのThreadでご意見をお寄せください。 Re: Generative AI Adoption: Transforming Businesses Through Intelligent Innovation この概要を共有していただきありがとうございます。新しいツールを導入する前に調査を行うべきだという点は、非常に共感できました。私の経験では、AIの恩恵を最も得ているチームは、適切な休憩を設け、長時間のテストやドキュメント作成の際に基本をしっかり守るチームであり、すべてを一度に押し切ろうとするわけではありません。美味しいコーヒーを飲みながら少し休憩すると、頭がすっきりした状態で問題に取り組むことができる。ホームで良い備蓄を常に用意しておくのが好きな方は、このウェブサイトをご覧ください

i.MX95: カスタムハードウェアでOP-TEEのテストが失敗する こんにちは、 最近、カスタムハードウェア用にi.MX95(B0バージョン)用にBSPをLinux 6.12.49_2.2.0からLinux 6.18.37_2.1.0に移植しましたそして突然、OP-TEEのxtestがテストに失敗し始めました（xtestの出力を添付します）。 調査の結果、OP-TEEコアがファイルシステムからロードされたTA上のRSA署名を検証できないことが障害の原因であることが判明しました。これは、ELEがRSA検証要求に対して常にELE_INVALID_MESSAGEという応答を返すことが原因です。 以下は、CFG_TEE_CORE_LOG_LEVEL=2 および CFG_TEE_TA_LOG_LEVEL=2 の場合の OP-TEE 出力の抜粋です。 E/TC:? 0 imx_ele_signature_verification:391 署名検証に失敗しました res = ffff0006 等：？0 do_verify:514 RSA署名検証に失敗しました E/LD: init_elf:494 sys_open_ta_bin(cb3e5ba0-adf1-11e0-998b-0002a5d5c51b) 等：？0 ldelf_init_with_ldelf:152 ldelf が res: 0xffff000f で失敗しました 何を調べればいいか、何かアイデアはありますか? よろしくお願いします Linux Security Re: i.MX95: OP-TEE xtest failing on custom hardware 原因が判明しました。新しいBSPはELEを基盤としたECCとRSAを有効にしますが、それらはELEランタイムファームウェアがロードされていることを前提としています。負荷は以下の方法でトリガーできます: echo 1 > /sys/kernel/se/se_load_fw 期待されるdmesgの出力は以下のとおりです。   FSL-se セキュア・エンクレーブ-0: loading firmware IMX/ele/MX95B0runtime-ahab-container.img FSL-SE セキュア・エンクレーブ-0:ファームウェアの正常なロード   Re: i.MX95: OP-TEE xtest failing on custom hardware こんにちは、 @fvalla-MTAさん はい、おっしゃる通りです。バージョン6.18.37では、ELEランタイムファームウェアのロードが必要です。 B.R

使用 LPC4337 控制器和 LPCUSBLIB 接口条码扫描器时出现问题 你好 ， 我目前正在研究使用lpcusblib（HID键盘主机示例）将条形码扫描器与LPC4337连接。 问题：USB1 主机在成功读取几次条形码后，仅接收到扫描器的第一个字符，然后就停止工作。重新扫描后，不会再进行数据传输。 我已经启用了 USB1 中断并使用了 HID_Host_ReceiveReport()，但我怀疑我缺少正确的 IN 数据包处理或报告清除。 有人在LPC微控制器上使用lpcusblib实现过HID条形码扫描吗？任何关于处理连续数据传输的指导或代码片段都将对我非常有帮助，不胜感激。 提前谢谢！ #嵌入式系统 #LPC4337 #USB主机 #HID #固件 此致， LPC43xx 外设 USB Re: Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB 您好@RDGC_member 请参阅以下主题：使用 LPC4337 控制器和 LPCUSBLIB 连接条形码扫描器时遇到的问题 - NXP 社区 BR 爱丽丝 Re: Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB 我正在使用 LPCUSBLIB 库将 USB 条码扫描器与 LPC4337 控制器连接起来。我想知道清除管道缓冲器的条件是什么。有时候我能正确收到完整的条形码。有时扫描第一个字符后就收不到任何数据，而且USB线还会卡住，导致之后多次扫描条形码都收不到任何数据。

Generative AI Adoption: Transforming Businesses Through Intelligent Innovation Generative Artificial Intelligence (GenAI) is rapidly changing how businesses operate, innovate, and interact with customers. From automated content creation and intelligent chatbots to advanced data analysis and AI-powered applications, Generative AI is becoming an important part of modern digital transformation. However, successful AI adoption is not simply about implementing new technology. It is about identifying the right business opportunities, understanding organizational challenges, and creating measurable value. The Growing Adoption of Generative AI Organizations across industries are exploring Generative AI to improve productivity, reduce operational costs, accelerate decision-making, and deliver personalized customer experiences. According to EY's 2025 India C-suite survey, 47% of organizations reported having multiple Generative AI use cases in production. This indicates a shift from initial experimentation towards practical business implementation. Some of the key areas of adoption include: Business Automation: Automating repetitive tasks, workflows, and operational processes. Customer Experience: Developing intelligent virtual assistants and personalized customer interactions. Content Generation: Creating marketing content, reports, product descriptions, and business communications. Data Intelligence: Extracting insights from large datasets and supporting informed decisions. Software Development: Accelerating coding, testing, documentation, and application development. The Challenges Behind AI Adoption Despite its potential, businesses face several challenges when adopting Generative AI. Data privacy, model accuracy, integration complexity, infrastructure costs, and responsible AI governance remain important considerations. Organizations must also ensure that AI-generated outputs are reliable, transparent, and aligned with business requirements. Human oversight and continuous evaluation are essential for building trust in AI-powered systems. Research-Driven Generative AI Adoption At Enaviya, we believe successful Generative AI adoption begins with research, business understanding, and the right technology strategy. From a research and technology perspective, it is important to study how emerging AI models can address real-world business problems. This includes evaluating large language models (LLMs), exploring domain-specific AI applications, understanding automation opportunities, and assessing the practical impact of AI integration. Enaviya focuses on translating these opportunities into scalable business solutions through Generative AI development, LLM integration, AI agents, custom AI applications, and intelligent automation. A research-driven approach helps organizations move beyond experimenting with AI tools and focus on solutions that deliver measurable business outcomes. Please share your feedback in this thread. Re: Generative AI Adoption: Transforming Businesses Through Intelligent Innovation Thanks for sharing this overview — the point about doing the research before rolling out new tools really resonated with me. In my experience, the teams that get the most from AI are the ones that build in proper breaks and keep the basics right during long testing and documentation sessions, rather than trying to push through everything at once. A short pause with a decent coffee genuinely helps me come back to a problem with a clearer head. For anyone who likes to keep a good supply on hand at home, have a look at this website

S32DS v3.5 License Activation Failed After Laptop Replacement (FNP Error 0) Hello NXP Support Team, I previously activated S32 Design Studio v3.5 on my old laptop. I recently replaced my laptop, but I can no longer access the old machine to return the license. When I try to activate S32DS v3.5 on my new laptop, I receive the following error: "The quantity specified exceeds maximum quantity allowed (0). (FNP error 0)." The NXP licensing portal also displays: "Returning this license is not allowed." Could you please reset my previous license activation or increase the available activation quantity so that I can activate S32DS v3.5 on my new laptop? I also tried contacting [email protected], but my email was rejected with SMTP error 550 5.4.1. I can provide my license details privately if required. Thank you for your assistance. Re: S32DS v3.5 License Activation Failed After Laptop Replacement (FNP Error 0) Hi,  the number of available licenses has been increased. 

Where Can I Find Mifare Plus EV2 full datasheet? Where can I find the full data sheet for the MIFARE Plus EV2? I need detailed instructions on how to use the AuthenticateSectorSwitch command. Re: Where Can I Find Mifare Plus EV2 full datasheet? Hello @YangGyu  Please send eamail to [email protected] to request DS522334-MF1 P(H)x2 - MIFARE Plus EV2 . BR kelly Re: Where Can I Find Mifare Plus EV2 full datasheet? I am unable to find the file you mentioned. Should I submit an additional request? Re: Where Can I Find Mifare Plus EV2 full datasheet? I am unable to find the file you mentioned. Should I submit an additional access request?  Re: Where Can I Find Mifare Plus EV2 full datasheet? Hello @YangGyu  Please going https://www.nxp.com/products/MFPEV2?ticket=ST-2765-SsyUzuME1f4C5JrCBJ3-gU5P4Gk-nxp#myDocument and selecting: BR kelly

Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB Hello , I’m currently working on barcode scanner interfacing with LPC4337 using lpcusblib (HID keyboard host example).  Issue: The USB1 host receives only the first character from the scanner after receiving few successful barcode readings, and then stalls. After rescanning, no further data transfers occur. I’ve enabled USB1 interrupts and used HID_Host_ReceiveReport(), but suspect I’m missing proper IN packet handling or report clearing. Has anyone implemented HID barcode scanning with lpcusblib on LPC microcontrollers? Any guidance or code snippets on handling continuous data transfer would be greatly helpful for me and appreciated. Thank you in advance! #EmbeddedSystems #LPC4337 #USBHost #HID #Firmware  Regards, LPC43xx Peripherals USB Re: Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB Hello @RDGC_member  Please refee to the thread: Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB - NXP Community BR Alice Re: Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB I am using LPCUSBLIB library for interfacing USB barcode scanner with LPC4337 controller. i wanted to know that which are the conditions cause to clear the  pipe buffer. some times i receive full barcode properly. some times after first character nothing is received also the usb line gets stuck so that after that nothing is received for several times barcode scanning. 

笔记本电脑更换后，S32DS v3.5 许可证激活失败（FNP 错误 0） 您好，NXP支持团队， 我之前在我的旧笔记本电脑上激活了 S32 Design Studio v3.5。 我最近更换了笔记本电脑，但我现在无法访问旧电脑来退还许可证。 当我在新笔记本电脑上尝试激活 S32DS v3.5 时，收到以下错误信息： “指定的数量超过了允许的最大数量（0）。（FNP 错误 0）。 NXP 授权门户网站还显示： “不允许退还此许可证。” 请问您能否 RESET 我之前的许可证激活状态，或者增加可用的激活数量，以便我可以在新笔记本电脑上激活 S32DS v3.5？ 我还尝试联系[email protected] ，但我的电子邮件被拒绝，SMTP 错误为 550 5.4.1。 如有需要，我可以私下提供我的驾照详情。 谢谢你的帮助。 Re: S32DS v3.5 License Activation Failed After Laptop Replacement (FNP Error 0) 你好， 可用许可证数量已增加。

MRF300AN 27MHz VSWR保护和恢复策略 我们正在使用 MRF300AN 开发一款用于医疗美容应用的 300W、27MHz CW 射频发生器。负载（手柄）可能会瞬间开路，我们需要一个可靠的保护和恢复策略。我们并不追求开路负载下的安全功率级（我们知道 65:1 VSWR 的耐用性是脉冲特性）。我们正在努力优化系统级保护架构和恢复时间，以防止连续波过载。 我们目前已实施的内容： 三环定向耦合器可对正向功率和反射功率进行采样。检测到的直流电平输入到具有迟滞特性的比较器中；当反射功率超过阈值时，锁存器被置位，并联 FET 快速将 MRF300AN 的栅极偏置拉向零。MCU 可以 RESET 锁存器，并且 MCU 还可以控制小信号射频输入电平。换句话说，我们已经建立了基本的检测、比较、锁存和栅极偏置下拉链，MCU 可以 RESET 锁存器并调整驱动电平。 我们关注的问题以及我们需要帮助的具体方面： 当前的恢复序列本质上是 MCU RESET 锁存器，栅极偏置恢复，驱动恢复。我们意识到这种观点过于对称：保护应该迅速，但恢复应该深思熟虑。我们不确定我们的整体架构是否适合此应用，也不确定如何设计恢复时间，以便 (1) 在开路负载条件仍然存在时 PA 不会重新激活，以及 (2) 第一次重新进入尝试本身不会产生二次过应力事件。 问题一：建筑 我们的比较器-锁存器-栅极-下拉方法是否是 27 MHz 连续波的正确主要保护方式，还是有更好的拓扑结构适用于这种功率等级和应用？我们看到了一些关于替代方案的参考，引用资料，我们希望恩智浦能就MRF300AN在27 MHz的连续波医疗发生器中哪种方向最合适给出应用层面的判断： - 在 PA 输出端采用基于 PIN 二极管的并联或开关保护，以在故障情况下呈现受控阻抗或隔离 PA。 - 带有终止负载的循环器/隔离器，常用于 MRI 和其他医疗射频链中，可接受成本和体积方面的损失。 - 分层保护，其中速度非常快的硬件路径处理突然的开路事件，而速度较慢的路径（MCU 或 ALC）管理折返和恢复。 - 保留比较器 + 锁存器 + 栅极偏置下拉作为主要保护，并添加 TVS 钳位作为最后一行电压钳位。 对于 MRF300AN 在 27 MHz CW 频段，是否有理由优先选择或避免使用其中某些型号？我们特别感兴趣的是，与单独的栅极偏置下拉相比，PIN 二极管输出开关是否能显著降低设备的压力，或者在这种频率和功率级下，它是否会引入自身的损耗和可靠性权衡。 Q2：恢复时间 我们了解到，在发生故障后盲目地 RESET 锁存器会导致 PA 在保护阈值处抖动，并反复注入应力。我们希望恩智浦就暂缓和重新进入市场方案获得指导： - 系统是否应在发生故障后强制执行固定的延迟时间，之后才允许重新进入系统？ - 在重返大气层期间，是否可以采用短时低功率探测（例如，短暂的低驱动脉冲）来检查负载是否已恢复到安全的驻波比，然后缓慢增加驱动功率，而不是直接恢复到全功率？NXP 社区指南已经建议在初始启动期间逐步上电，而不是突然全速驱动；我们正在尝试将这一原则扩展到故障恢复。 - NXP 是否推荐 MRF300AN 在连续波 (CW) 工作模式下的斜坡曲线或重入功率上限？或者这是否应该被视为与设备无关的系统级状态机设计？ Q3：TVS 的作用 在 NXP 27 MHz 参考设计讨论中，讨论了漏极到地的 110 V TVS，并指导说截止电压应该高于最大正常漏极电压。我们的系统中已经具备主动反射功率保护功能。TVS 应该被视为主动保护装置响应前的短暂间歇期的最后一道防线，还是应该承担更多的保护责任？在 27 MHz CW 频率下，TVS 的结电容和响应速度是否会对正常的射频波形保真度造成任何影响？ 最有帮助的是什么？ 任何应用层面的指导、推荐的架构、指向 NXP 现有关于 LDMOS PA 的 VSWR 保护和恢复的应用笔记的链接，甚至是 NXP 自己的参考设计如何处理故障保持重入序列的简要说明，都将直接为我们的设计提供信息。 谢谢！ Re: MRF300AN 27MHz VSWR Protection and Recovery Strategy 你好@fengyuqi ， 感谢您提供的详细描述。您的比较器、硬件锁存器和有源栅极偏置下拉电路构成了一条合理的初级保护路径。对于 300W CW 应用，我们建议将其作为分层架构的一部分使用，而不是依赖单一机制。 在条件允许的情况下，快速硬件路径应同时抑制射频驱动并拉低栅极偏置。MCU 不应成为立即关机回路的一部分；它应该管理后续的延迟、诊断、受控重入和重复故障锁定。 只有当 PIN 二极管开关将 PA 输出转换为已知且额定阻抗合适的阻抗时，才能降低应力。仅仅断开手柄连接可能会导致另一种开路情况。在此功率级下，必须考虑插入损耗、二极管发热、额定电压、开关瞬态以及开关过程中出现的阻抗。具有额定终端的循环器可提供更强的负载隔离，但尺寸、成本和损耗方面存在显著的权衡。 对于恢复而言，采用固定最小保持时间，然后进行低功耗探测和受控驱动斜坡是一种合理的系统级方法。在探测过程中，应同时监测前向功率和反射功率，因为反射功率与前向功率之比在探测器噪声基底附近可能会变得不准确。任何新的故障都应立即使系统恢复到锁定状态，并且反复尝试失败应导致更长的退避时间或永久锁定。 NXP 没有为 MRF300AN 指定专用的保持时间、斜坡曲线或再入功率上限。这些值取决于保护链响应、匹配网络中存储的能量、探测器动态范围、偏置稳定、热条件和预期负载行为。因此必须在系统层面确定和验证这些参数，包括在多个失配相位角下进行测试。 在主动关断生效之前的这段时间内，漏极瞬态电压应被视为最后一道线路瞬态钳位。它不应被期望吸收持续反射的射频功率。其截止电压、钳位特性、脉冲能量能力、结电容和封装/布局寄生参数都必须纳入射频和瞬态分析中，因为该设备可能会影响 27 MHz 输出匹配。 已发布的 MRF300AN 27 MHz 参考设计没有定义合格的故障保持重入序列，因此完整的保护架构仍然是特定应用的设计责任。 顺祝商祺！ 帕维尔

LPCUSBLIBとLPC4337コントローラを組み合わせたバーコードスキャナーのインターフェースでの問題 こんにちは 、 現在、lpcusblib（HIDキーボードホストのサンプル）を使用して、バーコードスキャナとLPC4337のインターフェースを開発中です。 問題：USB1ホストは、バーコードの読み取りに数回成功した後、スキャナーから最初の文字のみを受信し、その後停止します。再スキャン後は、それ以上のデータ転送は発生しません。 USB1割り込みを有効にしてHID_Host_ReceiveReport()を使用しましたが、INパケットの適切な処理またはレポートのクリアが不足しているのではないかと考えています。 誰かLPCマイコンでLPCマイクロコントローラでIPCのバーコードスキャンを実装したことがありますか?継続的なデータ転送の扱い方に関するアドバイスやコードスニペットがあれば、ぜひ教えていただけると助かります。 お手数ですが、よろしくお願いいたします。 #組み込みシステム #LPC4337 #USBホスト #HID #ファームウェア よろしくお願いいたします。 LPC43xx ペリフェラル USB Re: Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB こんにちは@RDGC_member Threadをご覧ください:LPCUSBLIBでLPC4337コントローラを使ったバーコードスキャナーのインターフェース問題 - NXPコミュニティ BR アリス Re: Issue in interfacing Barcode scanner using LPC4337 controller with LPCUSBLIB 私はLPCUSBLIBライブラリを使って、USBバーコードスキャナーとコントローラをインターフェースしていますLPC4337。パイプバッファをクリアする条件を知りたいです。時々、バーコード全体が正しく表示されることがあります。最初の文字の後に何も受信しないこともあり、USB回線も詰まってしまい、その後何度もバーコードスキャンを繰り返しても何も受信されません。

SIMULATED_IN_FIELDライフサイクルにおけるSYS_AUTH_REQおよびNVMキーインポートの断続的な失敗に関する問い合わせ こんにちは、 HSE_B FW 2.40.0 を実行している S32K328 デバイス上で、SIMULATED_IN_FIELD ライフサイクルを使用して SYS_AUTH_REQ および NVM キーインポート サービスをテストしています。 テスト中に、これらのサービスの成否はリセットサイクルとサービス呼び出しの順序によって異なることが観察されました。この行動についてご説明いただければ幸いです。 1. テスト環境と構成 - MCU:S32K328 - HSEファームウェア:S32K358_HSE_FW_2.40.0 - ターゲットライフサイクル:IN_FIELD - テストライフサイクル:SIMULATED_IN_FIELD - NVMキーグループオーナー:HSE_KEY_OWNER_OEM SYS_AUTH_REQ 設定 - 認可キータイプ:AES - 認可キー長:256ビット - 認可鍵所有者:HSE_KEY_OWNER_OEM - 認証アルゴリズム:AES-256-CMAC - sysAuthOption = HSE_SYS_AUTH_ALL - sysRights = HSE_RIGHTS_SUPER_USER SYS_AUTH プロシージャは次のように実行されます。 1.HSEからの異議申し立てを受け取るにはHSE_SRV_ID_SYS_AUTH_REQサービスに電話してください。 2. Authorization Keyを使ってホスト上のAES-256-CMACを計算します。 3.計算されたCMACをHSE_SRV_ID_SYS_AUTH_RESPサービスに連絡してください。 4. 認証が成功すると、SU(スーパーユーザー)権利が付与されます。 2. 試験手順 1. ECUブート 2. ライフサイクルを「SIMULATED_IN_FIELD」に設定します。 3.SYS_AUTH_REQ または NVM キーインポートサービスを呼び出します。 4. SYS_AUTH_REQが呼び出された場合は、チャレンジ・レスポンス手順を実行します。 5. サービス実行結果を確認する 上記のテストを複数のリセットサイクルにわたって繰り返した。 3. 観察された行動 複数のリセットサイクルにわたってテストを繰り返した結果、以下の挙動が観察されました。 CASE 1。SYS_AUTH_REQ後のNVMキーインポート - SYS_AUTH_REQサービスは、成功する場合と失敗する場合があります。 - 初期の SYS_AUTH_REQ サービスが成功した場合、チャレンジ・レスポンス手順を通じて SU 権限が付与され、同じリセット サイクル内で直後に呼び出される NVM キー インポート サービスも正常に完了します。 - 初期SYS_AUTH_REQサービスが失敗した場合、HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL) が返されます。 - このCASEでは、同じリセットサイクル内で直後に呼び出されたNVMキーインポートサービスは常に成功します。 CASE2。NVMキーインポートを最初に要求 - NVMキーインポートサービスは、成功する場合と失敗する場合があります。 - NVMキーのインポートが失敗した場合、HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL) が返されます。同じリセットサイクル内で直後に呼び出されるSU認証手順（SYS_AUTH_REQ → SYS_AUTH_RESP）は常に成功します。 - 逆に、NVM キーのインポートが成功した場合、同じリセット サイクル内で直後に呼び出される SYS_AUTH_REQ サービスは、常に HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL) を返します。 CASE 3。スープス権限を取得しNVMキーインポートを完了した後、再度SYS_AUTH_REQに電話をかける - たとえ最初の SYS_AUTH_REQ および SYS_AUTH_RESP 呼び出しが成功し、SU 権限が付与され、その後 NVM キーインポート サービスが正常に完了したとしても、同じリセット サイクル内で SYS_AUTH_REQ を再度呼び出すと、常に HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21CUL) が返されます。 追加の観察 また、MCUリセット後にこの挙動が前回のリセットサイクルで保持されたSU権限によって引き起こされるかどうかも検証しました。 例えば、以下のシーケンスでも同様の挙動が観察されました。 1.NVMキーインポートサービスに電話してください。 2. NVMキーインポート失敗(HSE_SRV_RSP_NOT_ALLOWED)。 3. MCUリセットを実行する。 4. SYS_AUTH_REQサービスに連絡する。 5. SYS AUTH_REQは失敗します(HSE_SRV_RSP_NOT_ALLOWED)。 6.NVMキーインポートサービスを呼び出してください。 7. NVMキーのインポートが成功しました。 したがって、これまでのテスト結果から判断すると、この挙動が前のリセットサイクルから保持された自動権限によるものであると結論づけるのは難しいです。 全体として、2つのサービスの成否はリセットサイクルによって異なり、一方のサービスが失敗すると他方のサービスが成功する傾向があることが観察されています。 4. 質問 1. シミュレーション環境下でのライフサイクル SYS_AUTH_REQ / SYS_AUTH_RESP および NVM キーインポートサービスの動作は、SIMULATED_IN_FIELD ライフサイクルと実際の IN_FIELD ライフサイクルで違いがありますか？ - SIMULATED_IN_FIELDライフサイクルにおいて、これらのサービスの使用に関する既知の制限事項はありますか？ 2. SU承認要求の繰り返し - SU権限が既に付与された後、同じリセットサイクル内でSYS_AUTH_REQを再度呼び出すと、HSE_SRV_RSP_NOT_ALLOWEDが返されるのは想定される動作でしょうか？ - 同じリセットサイクル内でSU認証手順を複数回実行することは許可されていますか、それとも推奨される使用パターンがありますか？ 3. 実際のIN_FIELDライフサイクルにおける動作 - 最終的な目標ライフサイクルである実際のIN_FIELDライフサイクルでも同じ挙動が起こる可能性はありますか? - 実際のIN_FIELD環境でSU認証とNVMキーインポートを確実に使用するための推奨手順はありますか？ - これらのサービスが実際の IN_FIELD ライフサイクルで確実に動作する場合、同じリセット サイクル内で SU 認証手順を複数回実行することも許可されますか？ 4. 認証キーの設定 - AES-256-CMACを256ビットAESキーでSYS_AUTH使用することは有効ですか? - SYS_AUTHに使用される際に、認可キーのキータイプ、キー長、キー所有者、キー使用に制限はありますか? この問題の緊急性を鑑み、迅速なご対応をいただければ幸いです。 再開まで今しばらくお待ちください。 Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li こんにちは、 @wodudwo さん。 あなたが説明した動作は、特にリセットサイクル間のばらつきを考慮すると、私にはやや異常に思えます。 まず第一歩として、データキャッシュの影響を排除することをお勧めします。プロジェクト内のデータキャッシュを完全に無効にして、テストを繰り返して挙動が変わるか確認してもらえますか? 念のため、クロックの設定も確認しておきたいと思います。そこに問題がないことを確認するためです。設定ツールから、関連する時計設定のスクリーンショットを送ってください。UTEST DCFでHSE_CLK_MODE_AND_GSKT_CTRLを変更しましたか？ 並行して、このシナリオに関連する既知の問題がないか確認し、ご指摘いただいた質問への回答を検証いたします。 よろしくお願いいたします。 ルーカス Re: Inquiry Regarding Intermittent SYS_AUTH_REQ and NVM Key Import Failures in SIMULATED_IN_FIELD Li こんにちは、 これは単に私のミスでした。 すべて想定通りに動作しています。 ご迷惑をおかけして申し訳ございません。 この質問を削除していただけるとありがたいです。 ご協力ありがとうございます。

i.MX 93 – 预构建的 Ubuntu/Debian Linux 镜像和定制载板支持 您好，NXP支持团队， 我正在评估 i.MX 93 平台在 EVSE 应用方面的性能，并发现了EVSE-IMX93 开发套件。 我想澄清一下可用的 Linux 镜像及其与潜在的定制载板设计的兼容性。 我们的目标是使用 MCIMX93-SOM，并基于 NXP 原有的载板设计开发一款简化的定制载板。我们将保留相同的SOM连接器和引脚分配，同时移除未使用的外围设备和电路。 由于我对 i.MX 处理器平台和基于 Yocto 的开发还比较陌生，我正在寻找一个简单易用的 Linux 解决方案来入门，然后再进行自定义。 请问您能否澄清以下问题？ 是否有适用于 i.MX 93 的现成 Ubuntu 或 Debian 13 (Trixie) 镜像？最好是通用服务器/最小 Linux 镜像。 这个镜像可以直接下载并刷入microSD卡来启动板，而无需Yocto构建吗？ 提供的镜像是否支持标准的 Linux 功能，例如apt 、Python 3、SSH、systemd 和网络功能？ 它是否支持CAN/CAN-FD (SocketCAN)、Wi-Fi、以太网和 MQTT ？是否可以使用apt安装 Mosquitto 等软件包？ 在我们保留原有SOM连接器和相关硬件连接的前提下，能否将相同的预构建镜像用于我们提出的定制载板？是否只需要更改设备树或配置？ 如果有这样的镜像文件，能否分享一下直接下载链接、支持的板信息和安装说明？ 我们的目标是将 i.MX 93 用作运行 EVerest 框架和其他 EVSE 应用软件的通用 Linux 平台，同时避免最初维护 Yocto 构建的需要。 谢谢你的帮助。 此致敬礼 加内什·巴格瓦特 Re: i.MX 93 – Prebuilt Ubuntu/Debian Linux Image and Custom Carrier Board Support 你好， 是的，有一个与 i.mx93 平台兼容的 Debian Linux SDK，您可以通过“Flexbuild”的实现来构建镜像，而不是使用 Yocto，然后使用 flexinstaller 工具刷写镜像。有关该发行版支持的软件包的更多信息，请参阅此处： DEBIAN-SDK Debian 软件版本说明 LDLSDK_26.06