SL3S1013FTB0,115 设计检查请求 pragashsangaran_0-1786452009588.pngpragashsangaran_0-1786452009588.pngpragashsangaran_0-1786452009588.pngpragashsangaran_0-1786452009588.png 1）上述应答器原理图是否适用于3.6V供电和RFID供电的配置？ 2）对于采用3.6V电源和RFID供电的RFID应答器配置，所标明的电压是否正确？ a) 2.6V - 3.1V（3.6V供电） b) 1-1.5V（RFID供电） Re: SL3S1013FTB0,115 design check request 我们已收到您的电源电压校正请求。我会进行更正。 您的问题：这是您使用该应用程序的预期目的吗？ 答：我们目前还没有这款产品的应用案例，但我们想了解一下这个防拆报警器的工作原理。 我计算了电压为 1.8V 和 2.2V 时的输出电压 Vout。这个计算结果正确吗？如果答案是肯定的，则输出电压太低，无法进行任何有意义的操作。 Vout = Ivdd X 1k Ivdd = Iinternal + Iout 典型的持续电流消耗在 1.8V 时约为 120 µA，在 2.2V 时约为 340 µA。 对于VDD = 1.8 V，Idd = 0.00012A 当 VDD = 2.2 V 时，Idd = 0.00034A 当 VDD = 1.8 V 时，Vout = 0.00012X 1千欧姆 输出电压 = 0.12V 当 VDD = 2.2 V 时，Vout = 0.00034X 1千欧姆 输出电压 = 0.34V Re: SL3S1013FTB0,115 design check request 你好@pragashsangaran 当采用外部供电时，VDD 焊盘需要 1.8V 至 2.2V 之间的电压；对于更高的电压值，则需要串联电阻。要进行正确计算，请参阅UCODE G2i 的 AN10940 常见问题解答，第 3 章/第 4 章。 OUT 引脚是一个数字输出，可用于防拆回路、小型外部电路或作为指示器；这些配置需要外部提供 VDD 引脚电源。如果 R35 被连接，则会引入一个可能激活“防拆指示器”位的连接，如标签防拆报警功能所述（请参阅UCODE G2i 常见问题解答 AN10940第 16 章）。这是否符合您的应用预期用途？ OUT 引脚的预期电压等级在AN10940 FAQ on UCODE G2i第 13 章中有描述。为连接到 OUT 引脚的设备供电的解决方案需要在 VDD 引脚上提供外部电源。 我建议您查看AN11237 UCODE G2iM+ 演示板文档，图 3 和图 5 中有一些参考连接。 问候， 爱德华多。 Re: SL3S1013FTB0,115 design check request 您好， 要使用 OUT 引脚的功能，例如数字输出/开关或为外部电路供电，需要外部电源。此外，正如UCODE G2i 常见问题解答 AN10940第 16 章“标签防拆报警功能如何使用？”中所述，此功能基于 VDD 和 OUT 之间的电气连接；需要注意的是，防拆功能和外部供电模式不能同时使用。 关于计算，请注意 OUT 引脚上的可用电压等级由 VDD 上的电压等级减去内部串联电阻上的电压下降决定。您可以在 UCODE G2i 的 AN10940 常见问题解答第 5.3 章中找到一些示例。 问候， 爱德华多。 Re: SL3S1013FTB0,115 design check request 你好， EduardoZamora ， 我们不会使用防拆报警功能，所以可以忽略这一点。R35是备选方案。 对我们来说，Vout 非常重要，因为它需要用来开启产品。你的意思是说，必须有VDD才能获得Vout。但是，我对使用这个部件有两个主要的顾虑。 计算出的输出电压过低。 当 VDD = 1.8 V 时，Vout = 0.12V 当 VDD = 2.2 V 时，Vout = 0.34V。 这个 Vout 对开启设备没有任何帮助。即使我们考虑提高电压，也没有太多方法可以进一步提高电压。 我的计算正确吗？完整的计算过程请参见我之前的回复。 在有VDD的情况下，Vout是否可以独立于RFID信号存在？我们希望 Vout 仅在天线接收到 RFID 信号时才存在。这是真的吗？ Re: SL3S1013FTB0,115 design check request 您好， Vout 取决于 VDD 引脚上的电压（根据AN10940 FAQ on UCODE G2i第 5 章对 VDD 和 RFN 之间的串联电阻进行适当尺寸调整后），减去 VDD 和 OUT 之间的内部串联电阻上的电压下降（~1kΩ）。一些计算示例可以在第 5.3 章中找到。 关于 OUT 引脚的状态，请参阅第 8 章至第 10 章，了解有关如何控制此引脚的更多信息。 问候， 爱德华多。 Re: SL3S1013FTB0,115 design check request EduardoZamora ，非常感谢。经过多次反复提问，我终于感觉得到了正确的答案。我真心希望我们能通过这个工单解决我的问题。 我还想知道这是否是 RFID 供电配置（无 VDD）的 Vout。您也能告诉我一声吗？ 我没有使用防拆指示器。我希望我们能够证明使用SL3S1013FTB0,115 而不是肖特基二极管的合理性。如果肖特基二极管无需电源电压就能提供更高的输出电压，我更倾向于选择肖特基二极管。 Re: SL3S1013FTB0,115 design check request 你好， EduardoZamora ， 我越来越困惑，完全无法理解你指出的计算过程。我觉得欧姆定律的计算结果是错误的。 文件内容如下： VSupply 通过 2kΩ 电阻连接至 VDD，提供约 2.5V 的典型持续供电电流，VDD 电压约为 1.99V，OUT 端负载为 100μA 时，输出电压 Vout 约为 1.68V。 − 如果没有电流从输出端流出：输出电流约为 240μA，输出电压约为 1.73V • 当 3.3V 电源通过 5.1kΩ 电阻连接至 VDD 时，VSupply 将提供约 255μA 的典型持续供电电流、约 2V 的 VDD 电压以及约 1.68V 的输出电压 Vout（OUT 端负载为 100μA）。 − 如果没有电流从输出端流出：供电电流约为 245μA，输出端电压约为 1.73V 在 2.5V 电源电压下，Idd = 250μA 在 3.3V 电源电压下，Idd = 255μA pragashsangaran_0-1786681961973.pngpragashsangaran_0-1786681961973.pngpragashsangaran_0-1786681961973.pngpragashsangaran_0-1786681961973.png 但我的计算结果显示，3.3V时，Idd = 647uA；2.5V时，Idd = 1250uA。 我完全搞不懂Vout是如何计算的。另一个尚未解答的问题是：我希望只有当天线/芯片检测到 RFID 信号时，Vout 才存在。如果在VDD和OUT之间直接连接一个1千欧姆的电阻，OUT端将始终有电压，对吗？这不是我想要的，它不适用于我的应用场景。请确认一下。 Re: SL3S1013FTB0,115 design check request 您好， 对于当前的功耗，这些示例考虑了第 5.2 节中规定的最大串联电阻计算以及数值舍入： EduardoZamora_1-1787005339602.pngEduardoZamora_1-1787005339602.pngEduardoZamora_1-1787005339602.pngEduardoZamora_1-1787005339602.png 以 2.5V 为例，~2kΩ 串联电阻上的电压降约为 0.5V。电流约为250微安。 关于 OUT 引脚的功能，其行为由 EPC 存储器控制。对于我的坚持，我深表歉意，请参阅UCODE G2i 的 AN10940 常见问题解答，第 8 章至第 10 章。 问候， 爱德华多。 Re: SL3S1013FTB0,115 design check request Vout取决于VDD引脚上的电压。根据UCODE G2iM 和 G2iM+ DS表 36，VDD 上的绝对最大电压为 2.2V，因此，如果使用提供更高电压的外部电源，则需要外部串联电阻。您可以预期 VOUT ~1.7V（在非常高的射频功率级下甚至高达 2V），驱动电流 (Iout) 最大为 100µA。 OUT 引脚的状态由 EPC 存储器中的一位（数字输出）控制，可以通过对该位执行 WRITE 写入命令来切换。数字输出位的值可以永久保留，也可以临时定义（如果应用程序需要临时输出，只要标签在读取器字段中）。这在UCODE G2i 的 AN10940 常见问题解答第 8 章至第 10 章中有解释。 问候， 爱德华多。 Re: SL3S1013FTB0,115 design check request 爱德华多·萨莫拉 数据表中的计算方法令人困惑。我只需要这三个问题的答案。你能回答这些问题吗？ 当 SL3S1013FTB0,115 由 3.6V 供电时，典型的输出电压 Vout 是多少？是 2.6V 到 3.1V 吗？您也可以提供相应的RFID功率。 在有VDD的情况下，Vout是否可以独立于RFID信号存在？我希望只有当天线接收到RFID信号时，Vout才存在。这是真的吗？ RFID供电的SL3S1013FTB0,115在没有VDD的情况下不会产生任何Vout吗？

IMX95 uGuzzi ISP:AEアルゴリズムは最大露出を達成できません AE制限を設定し、最大露出を適切に設定しました。しかし、実行時において、AEアルゴリズムは最大でも66666の露出しか達成できず、この時点でゲインは上限に達します。V4L2による測定結果から、AE曝露量が設定された上限値の半分以下であることが確認されました。 LiMengYi_0-1786522788247.pngLiMengYi_0-1786522788247.png Live Controlで手動で露出を設定すると、有効な露出は150000に達することがあり、V4L2露出も上限に達することがあります。 この問題はRowTimeに関連していると思われます。AEディスター内の行時間パラメータを変更しましたが、この変更には目に見える影響はありません。自動露出性能は以前とまったく変わりません。 低照度条件下でAEアルゴリズムが設定された最大露出値に達するようにするには、どのような調整が必要かを知りたいです。 Re: IMX95 uGuzzi ISP : The AE algorithm can't achieve the maximum exposure 現在の挙動から判断すると、AEアルゴリズムは絶対的な手動露出能力ではなく、アクティブセンサーモードのフレーム持続時間によって制限されているようです。値 66666 us は15fpsの1フレームに対応します。したがって、AE LIMITSの最大値を 150000 us に設定しても、アクティブセンサーのタイミングが150msを超えるフレーム期間を許すか、ドライバー/ヘルパーパスが露出をプログラムする前にVBLANK/フレーム長を延長しない限り、AEはこれを適用できません。 センサードライバーが V4L2_CID_EXPOSURE 、 V4L2_CID_VBLANK 、 V4L2_CID_HBLANK 、 V4L2_CID_PIXEL_RATE を露出し正しく更新しているかを確認してください。低照度AEが 150000 us に達するためには、アクティブフレームレートを約6.67fps以下に下げるか、AE制御パスでVBLANK/フレーム長を動的に増加させる必要があります。AE Dister で行時間を変更しても、V4L2/CameraHelper パスで報告されるアクティブ露出範囲が約 66666 us に制限されている場合は、AE に影響しない可能性があります。 また、変更されたAEパラメータが config_ipa_uguzzi.yaml で参照されるアクティブなDTPファイルに保存され、 /usr/share/libcamera/ipa/nxp/neo/uguzzi/ にコピーされ、カメラパイプラインが再起動されるか、または対応するアルゴリズムの再構成が適用されていることを確認してください。ライブコントロールの変更は、プロジェクト/DTPに保存するか、適切な再構成パスを通じて適用しない限り、通常は一時的なものです。 私の推奨事項は、まずフレーム持続時間/VBLANKの露出範囲の問題として対処し、次にDTP/プロファイルの有効化を確認することです。手動露出が 150000 us に達するという事実は有用ですが、AEが認識できる露出範囲とフレームタイミングも更新されない限り、AEループがその値を要求できることを証明するものではありません。

だからNXP MCXファミリについてはあまり語られません。マカス なぜですか？ 年初に、旧式のマイクロコントローラからNXP MCXAファミリのマイクロコントローラにいくつかの製品を移植しました。この選択の主な動機は、長期にわたって入手可能であったことである。 私はそのチップとそのインフラストラクチャを数ヶ月間扱いました。 そして何と言えばいいか:かなり良い作品だ。価格は妥当です。Dev-Boardの入手状況は良好です。 ソフトウェアスタックは機能しています。EclipseベースのIDEへの統合は問題ありません(強制されるわけではありません)。確かにソフトウェアに多少の問題点はありますが、特に変わったことはありません。 ハードウェアの機能：かなりクール。基本的な機能はもちろん、それ以上の機能も備えています。特に気に入っているのは、ほぼすべての周辺機器に、特筆すべきFIFOが搭載されている点です。 チップのよりマイナーな機能を使っても、シリコンバグは今のところ見つかりませんでした。 性能も良好です。 それなのに、これらのチップに関する投稿はほとんど見かけない。なぜですか？ MCX C Re: So little talk about NXP MCX family Mcus こんにちは、 @naofomi さん。 MCXA製品ファミリにご関心いただきありがとうございます。 MCXAは比較的新しいMCUシリーズであるため、LPCやKinetisのような成熟した製品ファミリーと比べて、コミュニティコンテンツやフォーラムでの議論が少なく、自然と少ないです。 お客様はDFAE(DFAE)やプライベートサポートケースなど、他のNXPチャネルを通じてサポートも受けられます。 ご質問があれば、こちらにお気軽にご投稿ください。私たちはあなたの成長を支援し、喜んでサポートいたします。 よろしくお願いします。 BR アリス

SJA1110スイッチのMAC転送設定 こんにちは、 SJA1110スイッチでL2転送ルールを設定したいです。以下のルールを: - トラフィックはポート7で受信されます。 送信元MACアドレス: 00:00:01:00:00:10、 宛先MACアドレス: 00:00:01:00:00:50、 VLAN ID 10、 PCP 7; - トラフィックはスイッチのポート5に転送され、出力SJA1110行われます。 SJA1110がポート7から宛先MACアドレス00:00:01:00:00:50のパケットが注入されたことを検出した場合、そのパケットをポート5経由で転送するだけでよい。ポート5のゲーティングは、パケット内のPCPを特定するだけで簡単に制御できます。   しかし、S32DSのSJA1110 SDKでどのように設定すればよいのか分かりません。 私は以下のように新しいL2ルックアップテーブルのエントリを設定しようとしました。 GuilhermeS32G_0-1786505280150.png VLANルックアップテーブルでVING_MIRRとVEGR_MIRRを設定してみました。 GuilhermeS32G_1-1786505432456.png また、一般パラメータでMIRR_PORTを5に設定しました。 GuilhermeS32G_2-1786505483489.png MAC構成テーブルでは、ポート7のING_MIRRを1に、ポート5のEGR_MIRRを1に設定しました。 しかし、それはうまくいかなかった。 この構成における正しいアプローチは何ですか？ ご支援に心より感謝いたします。 ギレルメ Re: MAC Forwarding Configuration on the SJA1110 switch こんにちは、 @GuilhermeS32G さん、 はい、その通りです。SJA1110 SDKフィールドはコロン区切りのMACアドレス形式を受け入れないため、MACアドレス00:00:01:00:00:50は小数点または十六進数、すなわち16777296または0x1000050のいずれかで入力できます。 先頭のゼロは値を変えないため、0x1000050は0x000001000050と同値です。 MASKフィールドに関して、マスクはL2ルックアップキーのどの部分がマッチングに使用され、どの部分がワイルドカードとして扱われるかを定義します。ビットが1に設定されている場合は、対応するビットが比較され、ビットが0に設定されている場合は、対応するビットが無視されることを意味します。 したがって、MACアドレスのみをマッチさせてIOTAG、VLANID、SRCPORTを無視したい場合、提案されたマスクは正しいです: マスク = 0x0000FFFFFFFFFFFF0 この場合、L2ルックアップエントリは入力ポートやVLAN IDに関係なく設定されたMACADDRと一致します。 あなたの元々のユースケースで、どこに合わせたいか: VLANID = 10 MACアドレス = 00:00:01:00:00:50 SRCPORT = 7 ただし、IOTAGに明示的に一致しない場合、推奨されるマスクは次のようになります。 マスク = 0x0FFFFFFFFFFFFFFFF 次に、L2ルックアップエントリを以下のように設定する必要があります。 VLANID = 10 MACアドレス = 0x000001000050 SRCPORT = 7 宛先ポート = ポート5 マスク = 0x0FFFFFFFFFFFFFFFF また、L2ルックアップテーブルからの最終宛先ベクトルは、L2転送テーブルによってフィルタリングされることを覚えておいてください。したがって、ポート7で受信されるトラフィックについては、対応するREACH_PORT設定でポート5も許可する必要があります。 よろしくお願いいたします。 パベル Re: MAC Forwarding Configuration on the SJA1110 switch こんにちは、 @PavelL さん。 改めてサポートありがとうございます。 念のため確認ですが、S32DSのSJA1110 SDKでは、MACADDRフィールドが整数または16進数の入力をサポートしていますが、コロンの関係で00:00:01:00:00:50を入力できません。なので、整数形式に変換するか、入力0x1000050として使うか、16777296に変換するかもしれません。それは正しいですか？ さらに、MASKフィールドについては、0から36893488147419103231までの整数形式(16進数0x1FFFFFFFFFFFFFFFF)をサポートしているようです。 しかし、私はこれらのMASKワイルドカードについてあまりよく理解していませんでした。 MACアドレスのみを一致させ、送信元ポートとVLAN IDは一致させない場合は、以下の方法を使用すればよいでしょうか？ マスク = 0x0000FFFFFFFFFFFF0 ? VLAN ID 10と送信元ポート7に一致させたい場合はどうすればよいでしょうか？ よろしくお願いいたします。 ギレルメ Re: MAC Forwarding Configuration on the SJA1110 switch こんにちは、 @GuilhermeS32G さん、 SJA1110転送テーブルの詳細については、UM11107およびAN12925の該当章を参照してください。使用されるフィールド名は、S32DS SJA1110 SDK構成で使われている用語に従っています。   このユースケースでは、ミラーリング機能ではなく L2ルックアップテーブルを使うのが正しいアプローチです。 宛先MACアドレスが00:00:01:00:00:50、VLAN IDが10のフレームをポート7で受信し、ポート5に転送する必要がある場合は、この宛先MACアドレス、VLAN ID、および送信元ポートに一致するL2ルックアップテーブルエントリを作成し、DESTPORTSをポート5に設定する必要があります。 以下の点もご確認ください。 1.MACADDRフィールドには、照合したいMACアドレスを入力してください。あなたの例では、宛先MACアドレスは00:00:01:00:00:50であるべきで、別の値であってはなりません。 2. MASKフィールドを確認してください。マスクは、L2ルックアップキーのどの部分を比較するかを定義します。完全一致の場合、マスクにはMACアドレス、VLAN ID、送信元ポートなどの関連フィールドをワイルドカードとして使用してはなりません。UM11107に基づくと、MASKは以下のビットで構成されます。 PavelL_0-1786518971668.png 3. L2転送テーブルも確認してください。L2ルックアップテーブルからの宛先ベクトルは、入力ポートのREACH_PORTフィールドによって引き続きフィルタリングされます。したがって、ポート7で受信したトラフィックについては、対応するL2転送テーブルのエントリでポート5が許可されている必要があります。 4. 通常の転送には、VING_MIRR、VEGR_MIRR、MIRR_PORT、ING_MIRR、EGR_MIRR などのミラーリング関連の設定は必要ありません。これらの設定はトラフィックミラーリングを目的としたものであり、標準の転送パスを定義するためのものではありません。 PCP 7に関しては、フレームがすでにPCP 7でVLANタグが付けられている場合、転送の決定はL2ルックアップテーブルによって行えます。PCPはポート5の 出口 優先度/スケジューリング/ゲート構成で使用可能です。PCPに基づいてトラフィックを分類したい場合を除き、L2ルックアップルールに含める必要はありません。 よろしくお願いいたします。 パベル

SL3S1013FTB0,115 デザインチェックリクエスト pragashsangaran_0-1786452009588.pngpragashsangaran_0-1786452009588.pngpragashsangaran_0-1786452009588.pngpragashsangaran_0-1786452009588.png 1) 上記のトランスポンダー回路図は、3.6V電源とRFID電源の組み合わせで正しいですか? 2) RFIDトランスポンダーの3.6VおよびRFID電源構成の電圧は正しいか? a) 2.6V～3.1V（3.6V電源時） b) 1 - 1.5V(RFID駆動) Re: SL3S1013FTB0,115 design check request 供給電圧補正データを受信しました。修正します。 質問:これがあなたのアプリケーションの意図された目的ですか? 回答:現行製品のアプリケーションはありませんが、この改ざんアラームの仕組みを理解したいと考えています。 1.8Vと2.2Vの場合のVoutを計算しました。この計算は正しいでしょうか？もしそうであれば、Voutが低すぎて意味のあることは何もできません。 Vout = Ivdd × 1k Ivdd = Iinternal + Iout 標準的な常時消費電流は、1.8Vの場合約120μA、2.2Vの場合約340μAとなります。 VDD = 1.8 Vの場合、Idd = 0.00012A VDD = 2.2 Vの場合、Idd = 0.00034A VDD = 1.8 V の場合、Vout = 0.00012X 1kΩ Vout = 0.12V VDD = 2.2 Vの場合、Vout = 0.00034X 1kΩ Vout = 0.34V Re: SL3S1013FTB0,115 design check request こんにちは、 @pragashsangaran さん。 外部電源を使用する場合、VDDパッドには1.8V～2.2Vの電圧が必要です。それ以上の電圧が必要な場合は、直列抵抗が必要になります。正確な計算方法については、 UCODE G2iに関するAN10940 FAQの第3章／第4章を参照してください。 アウトパッドはタンパーループ、小型の外部回路、またはインジケーターとして使用できるデジタル出力です。これらの構成ではVDDピンを外部から供給する必要があります。R35を入力すると、タグタンパーアラーム機能に従い「改ざんインジケーター」ビットを作動させる接続が導入されます(UCODE G2iのFAQ第16章AN10940参照してください)。これがあなたのアプリケーションの意図された目的ですか? OUTピンの期待電圧レベルは、UCODE G2iのFAQ第13章AN10940記載されています。OUTピンに接続されたデバイスに電力を供給するソリューションは、VDDピンに外部電源が必要です。 参考のつながりとして、 AN11237 UCODE G2iM+デモボードのドキュメント 、図3と図5 をご覧になることをお勧めします 。 よろしくお願いいたします。 エドゥアルド。 Re: SL3S1013FTB0,115 design check request こんにちは、 デジタル出力/スイッチや外部回路への電源供給などのアウトピン機能を使用するには、外部電源が必要です。また、 UCODE G2iのFAQ第16章「タグタンパーアラームはどのように使われるか?」AN10940述べたように、この機能はVDDとOUT間のガルバニック接続に基づいています。重要な点として、タンパー機能と外部電源モードは同時に使用できないという点です。 計算に関して、OUTピンで利用可能な電圧レベルは、VDDの電圧レベルから内部直列抵抗の電圧降下を差し引いた値で定義されることを考慮してください。UCODE G2iのFAQ第5.3章でいくつかの例AN10940見つけることができます。 よろしくお願いいたします。 エドゥアルド。 Re: SL3S1013FTB0,115 design check request エドゥアルド・ザモラさん、本当にありがとうございます。何度も同じ質問を繰り返した結果、ようやく自分の質問に対する正しい答えが得られるようになったと感じています。このチケットで私の質問が解決できることを本当に願っています。 また、RFID電源付き構成(VDDなし)のVoutかどうかも知りたいです。私にも教えていただけますか? 私は改ざん防止インジケーターを使用していません。ショットキーダイオードと比べてSL3S1013FTB0,115を使う正当性を正当化できることを願っています。もしショッキーダイオードが電源電圧なしでより高いVoutを提供できるなら、私はむしろショットキーダイオードを選びます。 Re: SL3S1013FTB0,115 design check request こんにちは、 Voutは、VDDピンに存在する電圧（ UCODE G2iに関するAN10940 FAQの第5章に従ってVDDとRFN間の直列抵抗を適切に設計した後）に依存し、VDDとOUT間の内部直列抵抗（約1kΩ）での電圧降下によって減少します。計算例は第5.3章に記載されています。 OUTピンの状態については、このピンの制御方法に関する詳細を記載した第8章から第10章を参照してください。 よろしくお願いいたします。 エドゥアルド。 Re: SL3S1013FTB0,115 design check request こんにちは、 EduardoZamoraさん。 タンパーアラームは使わないので無視してもいいです。念のためR35も用意しています。 私たちにとってVoutはとても重要です。なぜなら、それが製品を活性化させる必要があるからです。Voutを取得するにはVDDが必要だとおっしゃっているのですね。しかし、この部品を使うにあたって、私には2つの大きな懸念があります。 計算されたVoutは低すぎます。 VDD = 1.8 Vの場合、Vout = 0.12V VDD = 2.2 Vの場合、Vout = 0.34Vとなります。 このVoutは、物事をオンにするのに全く役立ちません。この電圧を上げることを考えたとしても、さらに電圧を上げるための選択肢はあまり多くない。 私の計算は正しいですか？詳しい計算方法については、以前の私の返信をご覧ください。 VDDが存在する場合、VoutはRFID信号に関係なく存在できますか?アンテナがRFID信号を受信したときだけ、ヴートは存在してほしい。これは本当ですか？ Re: SL3S1013FTB0,115 design check request こんにちは、 EduardoZamoraさん。 ますます混乱してきて、あなたが指摘した計算式を理解できなくなりました。オームの法則の計算が間違っていると思う。 文書にはこう書かれている。 2kΩでVDDに接続された2.5VのVsupplyは、100μA負荷時に通常恒時供給電流~250μA、VDD電圧~1.99V、出力電圧Vout~1.68Vを提供します − OUTから電流が引かれない場合:~ 240μAの電源電流と~ 1.73V OUTの電源電流 • 3.3VのVSupplyは5.1kΩを介してVDDに接続され、通常は恒時供給電流が~255μA、VDD電圧は~2V、出力電圧はVout~1.68Vで、出力電圧は100μA負荷で出力されます − OUTから電流が引かれない場合:~ 245μAの電源電流、OUTの供給電流 ~ 1.73V 2.5V電源の場合、Idd = 250μA 電源電圧3.3Vにおいて、Idd = 255μA pragashsangaran_0-1786681961973.pngpragashsangaran_0-1786681961973.pngpragashsangaran_0-1786681961973.pngpragashsangaran_0-1786681961973.png しかし、私の計算では、3.3VではIdd = 647μA、2.5VではIdd = 1250μAとなります。 ヴートの計算方法が本当に混乱しています。もう一つ答えのない疑問は、アンテナやチップがRFID信号を検出したときだけVoutが存在してほしいということです。VDDとOUTの間に1kΩの抵抗が直接接続されている場合、OUTには常に電圧がかかっている、ということでよろしいでしょうか？それは私の望むものではなく、私のアプリケーションには合いません。ご確認ください。 Re: SL3S1013FTB0,115 design check request こんにちは、 消費電流については、これらの例では、セクション5.2に従って最大直列抵抗の計算と値の丸めを考慮しています。 EduardoZamora_1-1787005339602.pngEduardoZamora_1-1787005339602.pngEduardoZamora_1-1787005339602.pngEduardoZamora_1-1787005339602.png 2.5Vの例では、約2kΩの直列抵抗器での電圧降下は約0.5Vになります。約250μAの電流を供給する。 OUTピンの機能に関しては、その動作はEPCメモリバンクによって制御されます。しつこく申し訳ありませんが、 UCODE G2iに関するAN10940 FAQの第8章から第10章をご参照ください。 よろしくお願いいたします。 エドゥアルド。 Re: SL3S1013FTB0,115 design check request エドゥアルド・ザモラ、 データシートの計算式が分かりにくい。私が知りたいのは、この3つの質問への回答だけです。答えられますか? SL3S1013FTB0,115に3.6Vを供給した場合、標準的な出力電圧（Vout）はどのくらいですか？2.6V～3.1Vでしょうか？対応するRFID出力も見積もりできます。 VDDが存在する場合、VoutはRFID信号に関係なく存在できますか?アンテナがRFID信号を受け取った時だけ、ヴートはそこにいてほしい。これは本当ですか？ RFID駆動のSL3S1013FTB0,115はVDDなしでVoutを生成できないのでしょうか? Re: SL3S1013FTB0,115 design check request VoutはVDDピンに印加される電圧に依存します。UCODE G2iMおよびG2iM+ DSの表36によると、VDDの絶対最大電圧は2.2Vであるため、より高い電圧を提供する外部電源を使用する場合は、外部直列抵抗が必要になります。駆動電流(Iout)は最大100μAで、VOUT ~1.7V(非常に高いRF出力では最大2V)が期待できます。 アウトピンの状態はEPCメモリバンク内のビット(デジタル出力)で制御され、このビットに対してWRITEコマンドを実行することで切り替えることができます。デジタル出力ビットの値は、ラベルがリーダーフィールドにある限り、アプリケーションに一時出力が必要な場合に一時的に保持または一時的に定義できます。この点については、UCODE G2iに関するAN10940 FAQの第8章から第10章で説明されています。 よろしくお願いいたします。 エドゥアルド。

过压和欠压情况下的电压注入测试及相关行为 大家好， SBC FS4503在我们的一个项目中被使用，并按如下方式配置以适应 OV / UV 条件。 VCCA、VCORE 和 VAUX 配置为仅在 OV 条件下对 FS0B产生影响，在 UV 条件下对 RSTB 和 FS0B 均产生影响。 电压注入测试是通过使用第二个电源向 VCORE、VAUX 和 VCCA 引脚注入电压来进行的，同时第一个电源向 SBC 提供 12V 输入。 测试结果如下： 1. VAUX OV - 断言 FS0B， 2. VAUX UV 触发信号RESET 3. VCORE OV- 断言 FS0B，但 VCORE 被切断，如数据表中所述。 4. VCORE UV 触发器 RESET 5. VCCA OV - 断言 FS0B，但 VCORE 短暂下拉，因此 RESET 6. VCCA UV 触发器 RESET。 VPRE-OV-数据手册提到稳压器已关闭，但我们观察到 RESET。 以下是查询内容： 1. 台式测试程序有效吗？其中，在OV条件下，在相应的引脚上注入约5.5V电压，在紫外线条件下，在相应的引脚上注入约3.5V的电压。 2. VCCA OV病症的观察是否可接受？ 3. 当VPRE发生OV状态时，数据手册提到稳压器被关闭，这是否也会切断VCORE电源？ 谢谢！ 阿迪亚 Re: Voltage injection tests for OV and UV scenarios and associated behavior 1. 台架测试程序是否有效？其中，对于 OV 条件，在相应的引脚上注入约 5.5V 电压；对于 UV 条件，在引脚上注入约 3.5V 电压。 [gw]OV 应使用高于 5.5V 的电压，UV 测试应低于 3V。 同时还需要满足过滤时间和反应时间的要求。 2. VCCA OV 条件下的观察结果是否可以接受？ [gw]第二个电源（OV电压）是否会通过VCCA引脚反向供电，从而导致VPRE/VCORE回路出现干扰？ 在本次VCCA OV测试中，您是否监测了VPRE？ 3. 当 VPRE 出现过压情况时，数据手册提到稳压器会关闭，这是否也会切断 VCORE 电源？ [gw]是的，VCORE 由 VPRE 提供。 Re: Voltage injection tests for OV and UV scenarios and associated behavior 你好@guoweisun ， 谢谢你的回复。这很有帮助。 以下是我的问题： [gw]第二个电源（OV电压）是否会通过VCCA引脚反向供电，从而导致VPRE/VCORE回路出现干扰？ 在本次VCCA OV测试中，您是否监测了VPRE？ [ab]：未对 VPRE 进行监测。我将通过新的测试来监测它。请问您能否帮我理解一下通过VCCA引脚反向供电是什么意思？ [gw]OV 应使用高于 5.5V 的电压，UV 测试应低于 3V。 “还需要满足过滤时间和反应时间的要求。” [ab]：由于我是手动执行此操作，因此对于OV情况，过滤时间100-200微秒和反应时间314微秒均满足要求。 以下是一些其他问题： 1. 如何检测OV/UV？SBC使用的采样率是多少？ 2. 过滤时间和反应时间有何意义？ 2. 在检测到任何引脚上的过压/过压故障之前，允许有多少个不合格样品？ 谢谢！ 阿迪亚 Re: Voltage injection tests for OV and UV scenarios and associated behavior 你好， Aditya 问：VPRE 没有被监测。我将通过新的测试来监测它。请问您能否帮我理解一下通过VCCA引脚反向供电是什么意思？ [gw]如果 VCCA 正常工作且内部 FET 导通，则下游侧的高电压会反向馈入 VPRE 引脚。  以下是一些其他问题： 如何检测OV/UV？SBC使用的采样率是多少？ [gw]没有这种规格，而是使用滤波时间。 过滤时间和反应时间的意义是什么？[gw]您可以在数据表表6中看到这些规格。 在检测到任何引脚上的过压/过压故障之前，允许出现多少个不合格样品？[gw]一旦检测到紫外线/紫外线病害，就应将其视为警告信号。

PN560 硬件 ID 您好，NXP， 我正在尝试确定哪个 NXP 芯片对应于硬件 ID ACPI\VEN_1FC9&DEV_3002 。 请问有人能确认一下PN560的硬件ID应该是什么吗？ 感谢您提前提供任何信息或文件参考资料。 Re: PN560 Hardware ID 你好，爱德华多， 感谢您的回复和抽出时间。 我想指出的是，这些信息似乎在笔记本电脑、平板电脑以及任何其他配备这些 NFC 阅读器的设备的设备管理器中都是公开可见的。但是，我理解你的立场，这件事就到此为止吧。 再次感谢您的支持。 顺祝商祺！ Re: PN560 Hardware ID 你好@johjoh 希望你一切都好。 非常抱歉，这些设备的信息尚未公开，而且这里也不是讨论相关信息的合适途径。 如需进一步支持，请联系您的恩智浦销售代表或最初向您提供这些设备信息的人员。 问候， 爱德华多。

プラットフォームSCP03のキー回転SE050C1 — PUT KEYが拒否(6A80 / 6982) NXPファクトリー(OEF)のキーから、当社独自のデバイス派生キーにSE050C1のプラットフォームSCP03キーをローテーションすることはできません。Plug&Trust 3.0.6と4.7.1の両方で、新品の部品に対して試したすべてのバリエーションでPUT KEYが拒否されました。 工場キーを使ったプラットフォーム SCP03セッションは正常に動作します — 開いてアプレットコマンド(GetVersion、GetRandom、ReadObject、WriteBinary)を正常に実行できます。PUT KEYのみが失敗します。 この部品でプラットフォームSCP03キーを回転させるための正しいAPDUシーケンスと、理想的には参照実装を知りたい。 設定： セキュア要素SE050C1(SSS_PFSCP_ENABLE_SE050C1 = 1) ATR 00 A0 00 00 03 96 04 03 E8 00 FE 02 0B 03 E8 08 01 00 00 00 00 00 00 64 00 00 0A 4A 43 4F 50 34 20 41 54 50 4F(「JCOP4 ATPO」) ホストMCU ESP32-S3、ESP-IDF v5.3.4 I2C経由でのT=1の転送（T1oI2C） ミドルウェアPlug&Trust — 3.0.6と4.7.1をテストしましたが、どちらもミニ版で同じ動作でした。 認証 SE05X_Auth=PlatfSCP03、SSS_HAVE_SE05X_AUTH_PLATFSCP03 ホスト暗号化mbedTLS この部品は工場出荷時の新品です。一度も正常に回転したことはなく、ex_sss_tp_scp03_keys.h の SE050C1 OEF キーで認証されます。 私たちが目指していること： プラットフォームSCP03キーセット(ENC / MAC / DEK)を工場出荷時のOEFキーから、ESP32上で派生したデバイス固有のキー(PBKDF2-HMAC-SHA256、ESP32のeFuse常駐HMACキー上)にローテーションし、特定のホストMCUのみがSE050でプラットフォームSCP03セッションを開けるようにします。 うまくいっている点： 工場出荷時キーでプラットフォームSCP03セッションを開くと成功し、その中のコマンドはwork:scp :DEBUG:認証 Successful!!! APDU :DEBUG:GetVersion [] -> 90 00 APDU 😄 EBUG:GetRandom [] -> 90 00 APDU 😄 EBUG:WriteBinary [] -> 90 00 つまり、チャネル、キー、セキュアメッセージングはすべて正常に機能しています。 何が失敗するか： ケースA: PUT KEYは6A80(誤ったデータ)で却下されます。 コマンドヘッダーと平文データフィールド（SCP03によるラッピング前）： hdr : 80 D8 0B 81 Lc=70 データ: 0B <- キーバージョン番号 88 11 10 <16 バイト ENC エンコード。DEK> 03<3-byte KCV> 88 11 10 <16 バイト MAC 暗号化。DEK> 03<3-byte KCV> 88 11 10 <16 バイト DEK エンコード。DEK下＞ 03<3-byte KCV> キー値は現在の(工場出荷時の)DEKでAES-CBCを用いてゼロIVで暗号化されます。KCVは、新しい鍵の下で16バイトの0x01ブロックのAES暗号化の最初の3バイトです。 ケースB:ISD選択 まずISDを選択すると: GP_Select(A0 00 00 01 51 00 00 00) -> 90 00 応答:6F 10 84 08 A0000001 510000000 A5 04 9F 65 01 FF 同じPUT KEYは6A80ではなく6982(セキュリティ未履行)で却下されます。 これは、ISDがコマンドを認識しているものの、安全なチャネルを必要としていることを示唆しており、CASE Aの場合、コマンドはD8命令がないSE050アプレットに送られていたことになります。 しかし、ミドルウェアのGP_Select()は平文のAPDUを送信し、既存のSCP03チャネルを切断します。ISDを選択した後（セッションでfp_Transform / authType / pdynScp03Ctxをリセットした後、nxScp03_AuthenticateChannel()を再度呼び出した）にSCP03を再確立しようとする試みは失敗します。 scp :WARN :nxEnsure:'status == kStatus_SSS_Success' が失敗しました。 行:148 関数:nxScp03_AuthenticateChannel ケースC: DoAPDUTxRx_s_Case4_ext経由(Leと共に送信)すると6700(長さが誤り)を返し、ISDのFCI広告で9F 65 01 FF(最大データフィールド255)と一致します。 既に除外されているもの： これらのそれぞれについてテストを行ったが、結果に違いはなかった。 試した変数の価値 P1 0x00(新規作成)、0x0B(現在のバージョンを置き換える)、0x11(ターゲットバージョン) データフィールドの先頭KVNバイトが存在/不在 APDUケース4(短編)/Case4_ext(拡張) キーブロック構造 88 11 10 03 現在のDEK(1ブロックのECBに相当)でのAES-CBC 0 IVキーラッピング KCV方法AESは新しいキーで16×0x01の最初の3バイトを使いました ミドルウェアバージョン Plug&Trust 3.0.6 および 4.7.1 DEKソースは、KEKがセッションを開く鍵セットと同じであることを確認した。 アプレットを選択した場合、すべてのバリアントで6A80が返されます。ISDを選択した場合、すべての短縮形バリアントで6982が返されます。 質問： プラットフォームSCP03キーをSE050C1上で回転させる正しいAPDUシーケンスは何ですか?具体的には、PUT KEYは発行者セキュリティドメインに送信される予定ですか、それともSE050アプレットに送られる予定ですか? もしISDに送る必要がある場合、Plug&Trustミドルウェアを使ってプラットフォームSCP03チャネルをISDに対してどのように構築すべきでしょうか?EX_SSS_BOOT_SKIP_SELECT_APPLET意図されたメカニズムでしょうか?もしそうなら、正しい呼び出し順序(SELECT ISD → INITIALIZE UPDATE → EXTERNAL AUTHENTICATE → PUT KEY)は何でしょうか? 上記のキーデータフィールドのフォーマットは、この部分において正しいでしょうか？特に、キータイプのコーディング、長さのエンコーディング、DEKラッピングモード、およびKCVアルゴリズムについて教えてください。 当社のPlug&TrustパッケージはnxScp03_Const.hでINS_GP_PUT_KEY(0xD8)を定義していますglobal_platf.h は存在するが、実装も使用例も含まれていない。プラットフォーム SCP03のキーローテーションの例やデモ(se05x_Delete_and_test_provisionプロビジョニング用のものに相当)を教えてもらえますか?またはフルSDKで教えていただけますか? AN12436(ex_sss_auth.hで参照)を教えていただけますか?OEFプラットフォームSCP03キーのソースとして、あるいはこの部分のキー回転を文書化したアプリケーションノート? 背景 ― なぜこれが見過ごされたのか 透明性を保つために申し上げると、これは私たちが自ら招いた問題であり、ごく最近になってようやく気づいたことです。 当社のプロビジョニングコードはPUT KEYを呼び出し、その後、戻りステータスを破棄しました。 sw = gp_put_key_using_nxp_middleware(se, DERIVED_SCP03_KEYVER, ...); /* ステータスは一度もチェックされていません */ mark_rotated(se, DERIVED_SCP03_KEYVER); /* "rotated"マーカーを書き込む */ ESP_LOGI(TAG, "SCP03キーが正常に回転しました"); /* 無条件に出力されます */ マーカー書き込み(WriteBinary)は成功するため、すべてのデバイスは「回転」フラグが設定され、プラットフォームSCP03キーが工場出荷時のままであり、プロビジョニングで成功が報告されます。その後、ステータスチェックを追加したところ、PUT KEYがどのユニットでも実際に成功したことがないことが判明しました。 その部分については、助けを求めていません。既に修正済みです。私たちがこの件を最初に提起するのではなく、今提起する理由を説明するため、そして当該部品が部分的に回転した状態ではなく、完全に回転していない状態であることを明確にするために、このことを言及しています。 SE050 Re: Platform SCP03 key rotation on SE050C1 — PUT KEY rejected (6A80 / 6982) こんにちは、 @Rutwik0409 さん。 提供された情報に基づき、SE050C1はアプレットレベルで正しく動作しているようです:  SELECT  、  GetVersion  、  GetRandom  、  ReadObject  、そして  WriteBinary  全員がSCP03プラットフォーム上で成功。したがって、これは基本的な輸送、T=1、SCP03キー、またはセキュアメッセージングの失敗ではないようです。 ESP32-S3をカスタムT=1のI²Cトランスポートで使用しているため、これはGlobalPlatformセキュリティドメインSCP03セッションに関するポートや統合の問題であり、SE050C1がSCP03キーローテーションをサポートしていない証拠ではない可能性が高いです。  Platform SCP03キーローテーション において、the  PUT KEY  コマンドは GlobalPlatform Security Domain操作 であり、SE050のIoTアプレットコマンドではありません。文書化された手順は以下のとおりです。 セキュリティドメイン/SSDを選択してください。 プラットフォームSCP03のセキュアチャネルを  INITIALIZE UPDATE  /  EXTERNAL AUTHENTICATE  で開け。 プラットフォームSCP03キーセットを更新するためにSend   PUT KEY  。 これは観察された挙動とも一致する。 SE050アプレットを選択すると、  PUT KEY  returns  6A80  これはGlobalPlatformコマンドを誤ったターゲットに送ることと一致します。 ISDを選択しても、そのドメインへのチャネルが  PUT KEY  returns  6982  に確立されていない場合、これは「セキュリティステータスが満たされていない」と一致します。 ですので、確認すべき主なポイントは SCP03プラットフォームがSE050アプレットに動作するかどうかだけでなく ミドルウェアが発行前に正しいセキュリティドメインに対してSCP03プラットフォームを開いているかどうかです  PUT KEY  。 NXPは、この操作に関するリファレンスデモを提供しています。 se05x_RotatePlatformSCP03Keys デモは、デフォルトのプラットフォームSCPキーでの認証と、そのキーをユーザー定義キーにローテーションする様子を具体的に説明しています。  弊社の推奨事項は、手動で構築することを避けることです。  PUT KEY  最初はAPDUを使用し、代わりにNXPのリファレンス実装と比較する。 まずは、NXPの公式リファレンスパス、例えばZephyr + nanoパッケージに収録されている「se05x_RotatePlatformSCP03Keys」デモを使って実装を検証することをお勧めします。これにより、移植作業なしでESP32 MCUがしっかりサポートされます。このデモは、NXPによるSCP03キー回転プラットフォームのリファレンス実装として機能しています。現在の問題は、「PUT KEY」コマンドが誤ったターゲットに送られているか、または対応するプラットフォームSCP03のセキュアチャネルがISD/SSDを選択した後に正しく確立されていないことを示唆しています。SCP03がSE050アプレットと通信しているからといって、GlobalPlatformセキュリティドメインレベルでの「PUT KEY」プロセスが正しく設定されているとは限りません。 詳細については、 https://github.com/NXPPlugNTrust/nano-package/blob/master/zephyr/readme.rstを参照してください。   お役に立てば幸いです。   すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

i.MX95 (ELE) 密钥导入 API 的替代方案——需要注入预共享的 AES 密钥 我们在 imx-secure-enclave 仓库的 Readme.md 文件中看到了以下声明：“不支持密钥导入 API。”(链接)到仓库： https://github.com/nxp-imx/imx-secure-enclave ） 在我们的应用场景中，我们希望能够将预共享的 AES 密钥注入到 ELE 中，以便用于加密操作。 有什么计划来支持这项功能？ 您能否提出其他建议？ Re: Alternative to Key Import API on i.MX95 (ELE) — need to inject a pre-shared AES key 你好， 请参阅以下应用笔记： https://www.nxp.com/webapp/Download?colCode=AN14898&isHTMLorPDF=HTML 此致敬礼/Saludos， 阿尔多。

IMX95 uGuzzi ISP：AE算法无法达到最大曝光 我已经配置了 AE LIMITS，并相应地设置了最大曝光量。然而，在运行时，AE 算法最多只能达到 66666 次曝光，此时增益也达到了上限。通过 V4L2 读取的数据证实，AE 暴露量不到配置上限的一半。 LiMengYi_0-1786522788247.pngLiMengYi_0-1786522788247.png 通过实时控制手动配置曝光时，有效曝光量可达 150000，V4L2 曝光量也可达到上限。 我们怀疑这个问题与 RowTime 有关。我们修改了 AE Dister 中的 Row Time 参数，但此更改没有显示出任何明显效果；自动曝光性能与以前完全相同。 我们想知道需要进行哪些调整才能使 AE 算法在弱光条件下达到配置的最大曝光量。 Re: IMX95 uGuzzi ISP : The AE algorithm can't achieve the maximum exposure 根据目前的表现来看，AE 算法似乎受限于活动传感器模式帧持续时间，而不是绝对手动曝光能力。值 66666 us 对应于每秒 15 帧的一帧。因此，即使 AE LIMITS 最大值设置为 150000 us ，除非活动传感器定时允许帧周期超过 150 毫秒，或者驱动程序/辅助路径在编程曝光之前延长 VBLANK/帧长度，否则 AE 也无法应用它。 请检查传感器驱动程序是否公开并正确更新 V4L2_CID_EXPOSURE 、 V4L2_CID_VBLANK 、 V4L2_CID_HBLANK 和 V4L2_CID_PIXEL_RATE 。要使低光照 AE 达到 150000 us ，活动帧速率必须降低到大约 6.67 fps 或更低，或者 AE 控制路径必须动态增加 VBLANK/帧长度。如果通过 V4L2/CameraHelper 路径报告的活动曝光范围保持在约 66666 us 以内，则单独更改 AE Dister 中的行时间可能不会影响 AE。 请确认修改后的 AE 参数已保存到 config_ipa_uguzzi.yaml 引用的活动 DTP 文件中，并复制到 /usr/share/libcamera/ipa/nxp/neo/uguzzi/ ，且相机流程已重新启动或已应用相应的算法重新配置。实时控制更改通常是暂时的，除非保存到项目/DTP 或通过正确的重新配置路径应用。 我的建议：首先将其视为帧持续时间/垂直消隐曝光范围问题，然后验证 DTP/配置文件激活情况。手动曝光达到 150000 us 的事实很有用，但这并不能证明 AE 循环可以请求该值，除非 AE 可见的曝光范围和帧时间也进行了更新。

TJA1028TK/3V3/20 适配 您好， 哪里可以找到TJA1028TK/3V3/20/J FIT的故障率？您能提供相关信息吗？ 谢谢。 Re: TJA1028TK/3V3/20 FIT 此信息不公开，已通过电子邮件发送给您。

MPXM053GSの空気漏れ 私たちはPCB MPXM2053GSに圧力センサを組み立てました。初期テスト中に、一部のユニットで出力電圧が0Vであることが判明しました。これは空気漏れが原因であると推測されます。基板から不良部品を取り外した後、底面の通気孔を検査したところ、正常な部品の通気孔とは明らかに異なっていることがわかりました。具体的には、故障した部品の通気孔内部には、溶融または熱損傷を受けた物質が含まれているように見える。この不具合の根本原因として考えられるのは何ですか？ Re: MPXM2053GS air leakage こんにちは、デイビッドさん。 最も効果的な予防策は、PCBステンシル上の通気孔の真下に、はんだペーストの侵入禁止領域を明確に定めることです。これにより、その部分にペーストが付着せず、リフロー時に穴に吸い込まれるのを防ぎます。さらに、ノークリーンフラックスを使用することで、残留物が開口部に移動する可能性を最小限に抑えられます。 さらなるサポートについては、STMicroelectronicsに直接連絡することをお勧めします。彼らは現在のこのMPXM2053の所有者であり、サポートを提供するのに最適な立場にあります。 BRs、トーマス Re: MPXM2053GS air leakage 底部の通気口から半田ペーストやフラックスが侵入するのを防ぐための対策について、何かご提案はありますか？ Re: MPXM2053GS air leakage こんにちは、デイビッドさん。 通気孔内の溶融または熱による損傷した材料は、リフローはんだ付け時のはんだペーストやフラックスの侵入、またはパッケージの最大ピーク温度である250°C(最大)30秒）。MPXM2053GSは下部ベントを大気基準として使うベント付きゲージセンサーなので、その穴が詰まると基準が失われ、出力は0Vになります。 さらにお知らせしますが、2026年2月2日現在、NXP MEMSセンサー製品(MPXM2053シリーズを含む)はSTMに移行しました。正式な故障解析や継続的な製品サポートには、STMが適切なお問い合わせです。 BRs、トーマス Re: MPXM2053GS air leakage こんにちは、 出力ゼロのユニットを分解したところ、内部のダイに亀裂が入っていることが判明した。このひび割れは異物によって引き起こされたものですか、それとも他の要因が関係していますか？ピックアップノズルが原因の可能性があると推測しています。なぜなら、ピックアップノズルは直接入口ポートに接触しているからです。しかし、ノズル圧力がダイを破壊するほど高くなっているかは不明です。

所以很少有人谈论NXP MCX系列Mcus 怎么会这样？ 今年年初，我们将一些产品从过时的微控制器移植到了 NXP MCXA 系列微控制器。选择这款产品的主要原因是其长期供应。 所以我花了几个月的时间研究那款芯片及其基础设施。 我还能说什么呢？他们确实很不错。价格还可以。开发板供应充足。 软件栈运行正常。集成到他们基于 Eclipse 的 IDE 中是可以的（而且你并非必须使用它）。是的，软件中确实存在一些瑕疵，但没什么特别的。 硬件特性：相当不错。它具备所有基本功能，而且功能更多。我特别喜欢他们几乎所有外围设备都配备了值得一提的FIFO（先进先出）功能。 到目前为止，我还没有发现任何硅芯片缺陷，即使我使用了芯片中一些不太常用的功能。 性能也很好。 然而，你几乎找不到任何关于这些芯片的帖子。怎么会这样？ MCXC Re: So little talk about NXP MCX family Mcus 嗨@naofomi 感谢您对MCXA产品系列的关注。 由于 MCXA 是一个相对较新的 MCU 系列，与 LPC 和 Kinetis 等成熟的产品系列相比，社区内容和论坛讨论自然较少。 客户还可以通过 NXP 的其他渠道获得支持，包括 DFAE 和私人支持案例。 如有任何疑问，请随时在此处留言。我们将乐于帮助和支持您的发展。 谢谢！ BR 爱丽丝

SC18IS606 - バックナンバーを読む こんにちは、 NXP製のI2CからSPIへのコンバーター SC18IS606を使います。私たちはRaspberry Piを使用して、I2C経由でSC18IS606にデータを書き込み、読み取っています。デバイスSC18IS606はRaspberry Pi OSのターミナルに表示され、ターミナルで「i2cdetect -y 1」コマンドを実行すると正しいアドレスで検出されます。 簡単なテストとして、GPIO 0～2への書き込み操作（設定/クリア）を行い、ループ内で一定の遅延を挟みながらそれらを切り替えてみました。この部分は正常に動作しています。 しかし、SC18IS606から読み戻すと、0x00ではなく0x80が読み取られます。 その後、ジャンパー線を使ってMISOピンとMOSIピンを接続し、SPIループバックを作成しました。SPIにパターン0x00から0x07を送信しています。読み戻されたデータは0x80から0x87までです。 ループバックテストでSPIを読み戻すと、MSBは常に1になります。 Mouserから購入したSC18IS606チップを2個テストしたところ、同じ結果が得られました。 何が原因か心当たりはありますか?どうすれば直せますか？ Re: SC18IS606 - reading back issue こんにちは、ジョンピーター 良い一日！ 1. 注文内容をご確認ください SC18IS606のSPI構成レジスタには、ORDERビットが含まれています。 順序 = 0 → 最上位ビット優先（デフォルト） 順序 = 1 → 最下位ビットが先 SC18IS606がLSB優先に設定されているのに、ソフトウェアが受信バイトをMSB優先と解釈すると、パターンがずれて見え、MSBが常に設定されているように見えることがあります。 F0h SPI インターフェース構成コマンドでどの値を書いているか確認してもらえますか? 2．バッファを正しく読み取っていますか？ SC18IS606は、コマンド実行後すぐにGPIOまたはSPIデータを返しません。順序は次のとおりです。 GPIO読み取り（F5h）またはSPIトランザクションを送信します。 完了するまで待機します（デバイスをポーリングするか、INTを使用します）。 バッファのI²C読み取りを実行します。 SPI操作の場合、受信したMISOデータは内部バッファに格納され、その後I²C読み出しトランザクションによって読み戻される必要があります。 バッファを読み取る際のプロトコルエラー(例えばアドレスバイトをデータとして扱う、または1ビットのオフセットを読み取るなど)が、正確な「+0x80」を生むことがあります。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。 Re: SC18IS606 - reading back issue Raspberry Pi上で実行したPythonコードと、ターミナルに表示された出力結果を添付しました。SC18IS606はMAX31865とつながっています。レジスタ読み出し時に、最上位ビット（7ビット目）がハイになっている生バイナリデータを確認しました。 例えば、RTDの最上位ビットの生データは0xC6です。Pythonコードの7ビット目をマスクすると、0x41が得られます。レジスタ読み出しのたびに7ビット目がハイになる理由は何でしょうか？ 38.png38.png 39.png39.png 20260818_00h49m35s_grim_01.png20260818_00h49m35s_grim_01.png

SJA1110交换机上的MAC转发配置 你好， 我希望在 SJA1110 交换机上设置一条 L2 转发规则，其中： - 流量通过7号端口接收， 源 MAC 地址：00:00:01:00:00:10 目标 MAC 地址：00:00:01:00:00:50 VLAN ID 10， PCP 7； 然后，流量被转发到 SJA1110 交换机的端口 5 进行输出。 当 SJA1110 检测到从端口 7 注入目标 MAC 地址为 00:00:01:00:00:50 的数据包时，它只需要通过端口 5 转发该数据包；端口 5 的门控可以通过识别数据包中的 PCP 来控制。   但是，我不确定如何在 S32DS 的 SJA1110 SDK 上进行配置。 我尝试按如下方式设置一个新的 L2 查找表条目： GuilhermeS32G_0-1786505280150.png 我还尝试在 VLAN 查找表中设置 VING_MIRR 和 VEGR_MIRR： GuilhermeS32G_1-1786505432456.png 另外，已在“常规参数”中将 MIRR_PORT 设置为 5： GuilhermeS32G_2-1786505483489.png 在 MAC 配置表中，我已将端口 7 的 ING_MIRR 设置为 1，将端口 5 的 EGR_MIRR 设置为 1。 但这并没有奏效。 对于这种配置，正确的做法是什么？ 非常感谢您的支持！ 吉列尔梅 Re: MAC Forwarding Configuration on the SJA1110 switch 你好@GuilhermeS32G ， 是的，没错。由于 SJA1110 SDK 字段不接受冒号分隔的 MAC 地址格式，因此 MAC 地址 00:00:01:00:00:50 可以输入为十进制值或十六进制值，即 16777296 或 0x1000050。 前导零不会改变值，因此 0x1000050 等价于 0x000001000050。 关于 MASK 字段，掩码定义了 L2 查找键的哪些部分用于匹配，哪些部分被视为通配符。设置为 1 的位表示将与对应的位进行比较，而设置为 0 的位表示忽略对应的位。 因此，如果您只想匹配 MAC 地址而忽略 IOTAG、VLANID 和 SRCPORT，那么您提出的掩码是正确的： 掩码 = 0x0000FFFFFFFFFFFF0 在这种情况下，无论入口端口和 VLAN ID 如何，L2 查找条目都将与配置的 MACADDR 匹配。 针对您最初的使用场景，您希望匹配以下内容： VLANID = 10 MAC地址 = 00:00:01:00:00:50 源端口 = 7 但不能明确匹配 IOTAG，建议的掩码为： 掩码 = 0x0FFFFFFFFFFFFFFFF 然后，L2 查找条目应配置如下： VLANID = 10 MAC地址 = 0x000001000050 源端口 = 7 目标端口 = 端口 5 掩码 = 0x0FFFFFFFFFFFFFFFF 另请注意，L2 查找表中的最终目标向量仍然会受到 L2 转发表的过滤。因此，对于在端口 7 上接收的流量，也必须在相应的 REACH_PORT 配置中允许端口 5。 顺祝商祺！ 帕维尔 Re: MAC Forwarding Configuration on the SJA1110 switch 你好@PavelL ， 再次感谢您的支持。 需要澄清的是，在 S32DS 的 SJA1110 SDK 中，MACADDR 字段支持整数或十六进制输入，由于冒号的存在，我无法输入：00:00:01:00:00:50。所以我可以将其转换为整数格式：16777296 或用作输入 0x1000050。是这样吗？ 然后，对于 MASK 字段，它似乎支持介于 0 和 36893488147419103231 之间的整数格式（十六进制为 0x1FFFFFFFFFFFFFFFF）。 但我不太理解这些 MASK 通配符。 如果我只想匹配 MAC 地址，而不需要匹配源端口和 VLAN ID，我应该使用： MASK = 0x0000FFFFFFFFFFFF0 ? 如果我想匹配 VLAN ID 10 和源端口 7 呢？ 顺祝商祺！ 吉列尔梅 Re: MAC Forwarding Configuration on the SJA1110 switch 你好@GuilhermeS32G ， 有关 SJA1110 转发表的详细说明，请参阅 UM11107 和 AN12925 中的相关章节。所使用的字段名称遵循 S32DS SJA1110 SDK 配置中使用的术语。   对于此用例，正确的方法是使用L2 查找表，而不是镜像功能。 如果要求将端口 7 上接收的、目标 MAC 地址为 00:00:01:00:00:50、VLAN ID 为 10 的帧转发到端口 5，则应创建一个与此目标 MAC 地址、VLAN ID 和源端口匹配的L2 查找表条目，并将 DESTPORTS 设置为端口 5。 请同时检查以下几点： 1.MACADDR 字段应与您要匹配的 MAC 地址相对应。例如，目标 MAC 地址应该是 00:00:01:00:00:50，而不是其他值。 2. 请检查 MASK 字段。掩码定义了要比较 L2 查找键的哪些部分。为了实现精确匹配，掩码不能对 MAC 地址、VLAN ID 和源端口等相关字段使用通配符。根据 UM11107 标准，MASK 由以下几位组成： PavelL_0-1786518971668.png 3. 请同时查看 L2 转发表。L2 查找表中的目标向量仍然会根据入口端口的 REACH_PORT 字段进行筛选。因此，对于在端口 7 上接收的流量，必须在相应的 L2 转发表条目中允许端口 5。 4. 正常转发不需要VING_MIRR、VEGR_MIRR、MIRR_PORT、ING_MIRR、EGR_MIRR等镜像相关设置。这些设置旨在实现流量镜像，而不是定义标准转发路径。 对于 PCP 7，如果帧已经用 PCP 7 进行了 VLAN 标记，则转发决策仍然可以通过 L2 查找表做出。然后，端口 5 上的出口优先级/调度/门控配置可以使用 PCP。除非您特别想根据 PCP 对流量进行分类，否则它不需要成为 L2 查找规则的一部分。 顺祝商祺！ 帕维尔

i.MX95(ELE)上のキーインポートAPIの代替 — 事前共有されたAESキーを注入する必要がある imx-セキュア・エンクレーブ リポジトリの Readme.md ファイルには次の文がありました:「Key Import APIはサポートされていません。」(リンク)リポジトリ: https://github.com/nxp-imx/imx-secure-enclave ) 私たちのユースケースでは、事前共有されたAESキーをELEに注入し、暗号処理に使えるようにしたいと考えています この機能をサポートするための計画は何ですか？ 他におすすめの代替案はありますか? Re: Alternative to Key Import API on i.MX95 (ELE) — need to inject a pre-shared AES key こんにちは、 以下のアプリケーションノートをご参照ください。 https://www.nxp.com/webapp/Download?colCode=AN14898&isHTMLorPDF=HTML 敬具/サルドス、 アルド。

研修資料を探しています こんにちは。EISに関するコースを受講したいのですが、NXPのEISBMSチップを使用してバッテリーをより安全かつ迅速に充電する方法（ソフトウェアサポート、システム統合、励起）に関するセクションが現在利用できず、コース教材も入手できません。 これらの部分はどのように勉強すれば良いですか？ Re: 寻求培训资料 こんにちは、殺人者 良い一日！ 残念ながら、この情報をより深く扱うトレーニングは機密扱いとされています。したがって、当社にアカウントを持ち、その後NDAを申請する必要があります。しかし、NDAの手続きは非常に制限されており、企業や既存の合意がある特定のケースに限定されています。 出発点として使える書類は以下の通りかもしれません: UG10341 – EISエンイブルメントパッケージ クイックスタートガイド。これはユーザーがEISソフトウェアパッケージを使い始めるのを支援するために特別に意図されています。 NXPのeisBMSチップセットでバッテリーを安全かつ高速に充電する方法｜パート1 これらの文書を閲覧するには、弊社のアカウントが必要ですが、秘密保持契約（NDA）は不要です。 この情報がお役に立てば幸いです。他に何かご不明な点がありましたら、お気軽にお問い合わせください。 良い一日をお過ごしください。幸運を祈ります。

SC18IS606 - 阅读往期内容 你好， 我们有恩智浦半导体（NXP）生产的 I2C 转 SPI 变流器 SC18IS606。我们使用 Raspberry Pi 通过 I2C 向 SC18IS606 写入和读取数据。设备 SC18IS606 显示在 Raspberry Pi OS 终端中，并且通过在终端中使用“i2cdetect -y 1”命令检测到，地址正确。 作为一个简单的测试，我们尝试对 GPIO 0 到 2 进行写入操作（设置/清除），并使它们在循环中切换，中间有一些延迟。这部分功能正常。 但是当我们从 SC18IS606 读取数据时，读取到的是 0x80 而不是 0x00。 后来，我们用跳线将引脚 MISO 和 MOSI 连接在一起，形成 SPI 环回。我们正在向 SPI 发送模式 0x00 到 0x07。我们读取到的数据是 0x80 到 0x87。 在环回测试中，当我们读取 SPI 数据时，最高有效位 (MSB) 始终为 1。 我们测试了两颗从贸泽（Mouser）购买的SC18IS606芯片，结果相同。 有人知道可能是什么问题吗？如何解决？ Re: SC18IS606 - reading back issue 你好 johnpeter 再会！ 1. 请检查订单位 SC18IS606 SPI 配置寄存器包含一个 ORDER 位： ORDER = 0 → 最高有效位优先（默认） 顺序 = 1 → 最低有效位优先 如果 SC18IS606 配置为 LSB 优先，但您的软件将接收到的字节解释为 MSB 优先，则模式可能会出现偏移，并且看起来就像 MSB 始终被设置一样。 请您确认一下您使用 F0h 配置 SPI 接口命令写入的值是什么？ 2. 你是否正确读取了缓冲区？ SC18IS606 在执行命令后不会立即返回 GPIO 或 SPI 数据。序列如下： 发送 GPIO 读取 (F5h) 或 SPI 事务。 等待完成（轮询设备或使用 INT）。 对缓冲区执行 I²C 读取操作。 对于 SPI 操作，接收到的 MISO 数据存储在内部缓冲中，然后必须通过 I²C 读取事务将其读回。 读取缓冲区时出现的协议错误（例如将地址字节视为数据，或读取一位偏移量）可能会产生精确的“+0x80”。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。 Re: SC18IS606 - reading back issue 我已附上在树莓派上运行的 Python 代码及其在终端上的输出结果。SC18IS606 连接到 MAX31865。查看原始二进制数据，其中每次读取寄存器时，最高有效位（第7位）均为高电平。 例如，RTD MSB 原始数据为 0xC6。在对 Python 代码中的第 7 位进行掩码处理后，我们得到 0x41。为什么每次读取寄存器都会得到第7位为高电平？ 38.png38.png 39.png39.png 20260818_00h49m35s_grim_01.png20260818_00h49m35s_grim_01.png

TJA1043 Problem Consultation Hello to all the experts at NXP: We have two questions regarding the TJA1043 chip used in our project: 1. When our controller enters sleep mode, the MCU pulls down the STBN and EN pins of the 1043 to enter standby mode. At this time, the VBAT of the 1043 is 24V, VCC is 5V, and VIO is 3.3V. At this time, INH should still be at a high level of 24V, right? If a CAN message arrives on the CAN bus at this time, the 1043 will be woken up. During this period (from standby to normal), will the level on INH remain high, or will there be a high-low-high transition? 2. In a 24V system, during short-power supply testing, the power supply voltage is 32V. Using a controller with TJA1043 and CAN configured as a terminal node (120ohm), during CANH short-power supply testing, according to Fig. 39 of AH1014: smarklink_0-1786504166890.png What is the maximum IP value? What is the resistance value of the resistor in the red box in the image above? Considering WCCA, what power rating should I choose for my RT/2 resistor? Please help me answer this, I would be extremely grateful! TJA1043 Re: TJA1043问题咨询 Okay, thank you so much for your reply! Re: TJA1043问题咨询 Hi 1: Always high level 2. Normal Applications : 60 Ω, 0.1 W / 0.125 W is generally sufficient for normal communication power consumption. RT/2 power is determined by the customer's short-to-battery test conditions. The diagram in the NXP documentation illustrates the failure mechanism, not the RT/2 power rating. We cannot provide specifications beyond those in the datasheet for the TJA1043.

MPXM2053GS 漏气 我们已将MPXM2053GS压力传感器组装到我们的PCB板上。在初步测试中，我们发现一些单元的输出电压为 0V，我们猜测这是由于漏气造成的。从板上拆下故障设备后，我们检查了底部通风孔，发现它们与正常设备的通风孔有明显的不同。具体来说，失效部件上的通风孔内部似乎含有熔化或受热损坏的材料。这种缺陷的可能根本原因是什么？ Re: MPXM2053GS air leakage 嗨，大卫， 最有效的预防措施是在PCB钢网上通风孔正下方划定焊膏禁区。这样可以确保该区域不会沉积焊膏，并且在回流焊过程中焊膏不会被吸入孔中。此外，使用免清洗助焊剂可以最大限度地减少残留物，否则残留物可能会迁移到开口处。 如需进一步支持，我建议直接联系意法半导体，因为他们是 MPXM2053 的当前所有者，最能提供支持。 BRs，托马斯 Re: MPXM2053GS air leakage 您有什么方法可以防止焊膏或助焊剂渗入底部通风口吗？ Re: MPXM2053GS air leakage 嗨，大卫， 通风孔内熔化/受热损坏的材料很可能是由于回流焊过程中焊膏或助焊剂渗入，或封装体温度超过最大允许峰值温度 250°C (max.30秒）。由于 MPXM2053GS 是一个通风式压力表传感器，它使用底部通风口作为大气参考，因此该孔的任何堵塞都会导致参考丢失，并导致 0V 输出。 另需注意：自 2026 年 2 月 2 日起，NXP MEMS 传感器产品（包括 MPXM2053 系列）已过渡到 STM。如需进行正式的故障分析或持续的产品支持，请联系 STM。 BRs，托马斯 Re: MPXM2053GS air leakage 你好， 我们拆开了一台零输出单元，发现里面的芯片裂了。这个裂缝是由异物造成的，还是还有其他因素导致的？我们怀疑吸嘴可能是罪魁祸首，因为它直接接触进料口；但是，我们不确定吸嘴压力是否高到足以使模具破裂。