Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
S32K314 CAN 発行 私はS32K314を使っていますが、最近テスト中に発振器がショートしてしまい、CANに関する問題が発生しました。 回復後、SPI、ADCを監視しました。これらのモジュールは正常に動作しますが、CANモジュールは通常通り動作しません。 デバッカはこれらの情報を表示しますが、この状態ではCANの受信や送信ができません。 どうしてこんなことが起きたのか、そしてSWでこの故障をどうやって回復すればいいのでしょうか? Snipaste_2026-08-04_13-32-47.jpg   Re: S32K314 CAN issue こんにちは、 ご返信ありがとうございます。 「Mcu_ClockSourceFailure_Notification」にテストコードを追加しようとしましたが、この通知はトリガーされません。 ソフトウェア側からは、この問題が起きてCANモジュールをリセットするにはどうすればいいのでしょうか? よろしくお願いします。 下記は、ご指摘いただいたレジスタの値です。 MCR KidhRobin_0-1785975444257.png CTRL1 KidhRobin_1-1785975470032.png CBT: KidhRobin_2-1785975496485.png FDCBT: KidhRobin_6-1785975801928.png ECR KidhRobin_4-1785975599003.png ESR1 KidhRobin_5-1785975618985.png Re: S32K314 CAN issue こんにちは、 提供されたスクリーンショットから、受信エラーカウンタ(RXERRCNT)が増加している一方で、TXERRCNTは0のままであり、ESR1が送信試行中であることを示しているにもかかわらず、典型的な送信関連の問題とは完全には一致しません。 発振器のショートサーキットがクロックに影響を及ぼし、例えば回復後のCANビットタイミングの誤差を引き起こす可能性があります。しかし、現在の情報だけではこれを裏付けるには不十分である。 以下の情報を提供していただけますか: FlexCANレジスタ(MCR/CTRL1/CBT/FDCBT、ECR、ESR1を含む)のより広い範囲 モジュールおよびCANプロトコルのクロック構成は、 故障時に記録されたTX、RX、CANバスの測定値は? FlexCANモジュールのクロックとCANプロトコルのクロックが動作し、期待される周波数であれば、FlexCANモジュールのソフトウェアリセットを実行し、モジュールの初期化を完全に行い、通信が回復しているか確認することもできます。 BR、ペトル Re: S32K314 CAN issue こんにちは、 Mcu_ClockSourceFailure_Notification()が入力されていない場合、私の最初の仮定は、対応するMCU割り込み/通知経路がプロジェクト内で設定または有効化されていないということです。 以下を確認していただけませんか: 影響を受けるクロックソースに対してクロックモニタリング(CMU)が有効になっているかどうか。 CMU割り込みが有効になっているかどうか。 MCUモジュールがクロック障害検出時にMcu_ClockSourceFailure_Notification()を呼び出すように設定されているかどうか。 また、発振器ショートサーキットイベント後にCMUおよびRGMの状態レジスタを検査し、クロック障害が実際に検出されているかを確認することも有用です。 FlexCANレジスタダンプから、モジュールは有効化され、バスと同期している(SYNCH=1)ように見えますが、RXERRCNTが増加し、TXERRCNTは0のままで、バスアクティビティがありません。表示されているビットタイミングレジスタ(CTRL1、CBT、FDCBT)には有効なCANタイミング設定が含まれていないようですが、強化されたCANビットタイミングを使用し、実際のタイミングがそれぞれの強化CANビットタイミングレジスタを通じて設定されている場合は予想されるかもしれません。 したがって、CANリセット戦略を実装する前に、クロック障害イベントが検出されているかどうか、通知機構が適切に設定されているかを確認することが望ましいです。 BR、ペトル
查看全文
关于存储在 NVM 密钥目录中的 ECC 公钥的 安全散列算法(SHA)-512 校验和的问题 尊敬的恩智浦专家: 我们有一个关于 HSE 关键管理功能的问题。 我们正在使用 带有 HSE-B 的 S32K312 ,并将 ECC 公钥 存储 在 NVM 密钥目录 中 。 在我们的应用中,我们需要获取存储在 NVM 密钥目录中的 ECC 公钥的安全散列算法(SHA)-512 哈希值。 密钥存储后,我们希望通过比较其安全散列算法(SHA)-512 哈希值来验证它是否已正确存储。 例如: 令K为存储在 NVM 密钥目录中的 ECC 公钥。 我们想要获取SHA-512(K) 的值。 HSE 是否提供任何 API 或机制来获取 存储在 NVM 密钥目录中的密钥的 SHA-512 哈希值 ? 如果没有,是否有推荐的方法来计算或验证 存储在目录中的密钥的 安全散列算法(SHA)-512(K) 值? 感谢您的支持。 Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog 我得到了它。感谢您的支持 Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog 你好@NghiaLX308 目前没有 API 允许用户直接对密钥材料执行 安全散列算法(SHA)-512。 作为一种变通方法,您可以导出 ECC 公钥(使用服务 HSE_SRV_ID_EXPORT_KEY),然后执行 SHA-512 操作(使用服务 HSE_SRV_ID_HASH)。由于 ECC 公钥不是秘密的,因此可以以明文形式导出。无需以加密或认证格式导出。 此致, Lukas
查看全文
サスペンド中に短いノイズパルスによってトリガーされるGPIOウェイクアップ こんにちは、NXPチームの皆様、 カスタムボード上でi.MX8MPを使い、Linux BSP LF-6.12.20を使用しています。複数のGPIOピンがウェイクアップソースとして設定されている。 問題点:EMC過渡試験(ESD)中に、これらのGPIOライン上の短いノイズパルスによって、サスペンド状態だったシステムが誤って起動してしまう。 ソフトウェアデバウンスではこの問題は解決できないことがすでに確認されています。ウェイクアップの決定はCPUが一時停止中にハードウェアによって行われ、GPIO割り込みハンドラ(GPIOキーのデバウンスを含む)はシステムが再開した後にのみ実行されるため、ソフトウェア自体がウェイクアップを防ぐことはできません。 Linuxドライバー(LF-6.12.20)やi.MX8MPのリファレンスマニュアルも確認しましたが、GPIOウェイクアップパス用のハードウェアフィルターは見つかりませんでした。この理解が正しいかどうか確認してください。 質問: 1. i.MX8MPには、ウェイクアップピン上の非常に短いパルスを無視するためのハードウェアオプション(GPIO、GPC、またはATF経由で設定可能)はありますか?(例えば、グリッチフィルタや最小パルス幅設定など)これにはレベルトリガーモードも含まれます。レベルを一定時間保持する必要があるのか、それとも瞬間的なパルスでもウェイクアップがトリガーされるのか? 2. そのようなハードウェアオプションが存在しない場合、NXPはこの種の誤起動に対してどのような解決策を推奨していますか?GPIOウェイクアップ入力のESD保護に関するアプリケーションノートがあれば教えていただけると助かります。 3. Cortex-M7がウェイクアップ信号をチェック・フィルタリングし、A53がサスペンド状態のままにするNXPのリファレンスデザインはありますか? プラットフォーム:i.MX8MPカスタムボード、BSP:LF-6.12.20 よろしくお願いいたします。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: GPIO wakeup triggered by short noise pulses during suspend こんにちは、 @Leo_dev お元気でお過ごしのことと思います。 Q1. あなたの理解は正しいです。i.MX8MPのGPIO/GPCウェイクアップパスには、ハードウェアグリッチフィルタ、最小パルス幅設定、デバウンスレジスタがありません。 Q2. オンチップの解決策がないため、推奨される設計はPADにフィルターを追加することです。 Q3. はい、この種のアーキテクチャに関する主要なNXPリファレンスである「i.MX 8M Low Power Design By M Core Running In System Suspend」AN13400 を参照してください。 よろしくお願いいたします。 サラス。
查看全文
MINISASTOCSI 最新原理图 大家好, 请问您能否帮忙分享一下MINISASTOCSI的最新原理图? Re: MINISASTOCSI Latest Schematics 嗨@ramkrish , MINISASTOCSI 板的最新版本是 A1。 我已将文件发送到您的邮箱,供您参考。 如果您在接收过程中遇到任何问题,或者需要与此次电路板修订相关的任何其他信息,请告诉我。 此致, 查维拉 Re: MINISASTOCSI Latest Schematics 嗨@Chavira 已收到,谢谢。
查看全文
IGGM积分系统及规则详解 | 如何赚取积分、兑换积分以及更多? 为了向玩家提供更具性价比的游戏产品和服务,IGGM平台正式推出全新积分系统,旨在让您在享受更优质购物体验的同时,花费更少!   下面,我们将详细介绍您需要了解的一切:如何高效赚取积分、如何用积分享受折扣或兑换丰厚奖励,以及如何叠加 VIP 福利以最大程度地节省开支。   使用积分系统前 - 需要注册   请注意,IGGM 的新积分系统仅对新注册并登录的用户开放。如果您尚未注册或登录,则需要进行注册或登录才能访问签到和积分页面。   如何赚取积分?   在 IGGM 积累积分非常简单直接,主要通过两个渠道:每日签到和订单奖励。   1.每日签到   只需点击 IGGM 签到中心页面上的“今日签到”按钮即可完成签到;按钮变为“已签到(明天再来)”后,您的积分就已成功计入!或者,您也可以点击日历上的当前日期进行签到。   一键入住(彩蛋)   这里面藏着个小彩蛋!如果您忘记当天签到,直接进入优惠券兑换页面,只需点击列表底部的“小火箭”表情符号即可立即签到 - 无需返回签到中心。您仍然可以因连续签到而获得递增奖励。   请注意PC版和移动版在视觉上的差异!对于 PC 用户来说,只有当你将光标悬停在小火箭上时,它才会开始摇晃并喷出火焰;单击一下即可发射火箭并获得你的签到积分。对于手机用户,火箭图标会持续摇晃——只需点击它即可签到并立即获得积分!   其他入住登记   此外,IGGM还提供以下便捷的日常签到方式:   1. 在优惠券兑换页面点击“立即前往”前往登记中心。   2. 点击首页底部的优惠券部分,进入签到中心。   3. 点击 IGGM 上任何产品页面底部的横幅,即可进入登记中心。   连续签到可获得额外奖励   IGGM的签到系统奖励一致性。如果您不间断地签到,您的每日积分将随着时间的推移而增加:第一天 5 分,第二天 6 分,第三天 8 分。从第四天开始,只要你保持连续参与,你每天都将持续获得最高奖励 10 点。   注意:如果您在购物过程中通过产品页面上的签到横幅进行签到,完成签到并触发积分累积后,您可以通过页面底部的“返回购物”返回到您的原始页面。您不必担心购物进度会受到影响!   中断后重置   如果你错过一天或因任何原因中断连续记录,你的进度将重置为零。您的下次入住将恢复到第一天的 5 积分制。请注意,每日签到重置时间取决于服务器的时区;请务必准时签到,以免因网络问题或其他中断而丢失进度。   2. 订单积分   此外,每当您在 IGGM 平台上下单时,系统都会根据您的订单小计金额奖励您积分。   积分累积速度:1 美元 = 1 积分   在标准情况下,您实际消费的每一美元都可以直接转化为1积分。为了简化涉及小数的订单金额的计算,IGGM 在确定所获积分时会四舍五入到最接近的整数。例如,如果您支付 17.35 美元,您将获得 17 个积分;如果您支付 34.86 美元,您将获得 35 个积分。   为确保小额交易的系统效率,订单支付的小计金额必须至少为 1 美元才能触发积分累积;低于 1 美元的订单不会产生任何积分。   此外,所有订单的积分只有在订单状态正式变为“已完成”后才会由系统自动计入您的账户;积分数量与符合条件的购买金额相对应。   新用户福利:10倍积分奖励   IGGM 为新用户准备了欢迎礼物!您在 IGGM 上的第一笔付费订单将自动获得丰厚的 10 倍积分奖励(即每消费 1 美元即可获得 10 积分)。   请注意计算方法:先将小计金额四舍五入到最接近的整数,然后乘以 10 以确定您的首单积分。例如,如果您的第一笔订单小计为 17.35 美元,您将获得 170 积分(17.35 美元 → 17 × 10 = 170 积分),而不是先乘以 10 再四舍五入(17.35 美元 × 10 = 173.5 → 174 积分)。   但是,如果您的首单小计金额不足 1 美元,您将不会获得任何积分,并且您作为新用户的首单优惠将被用完。因此,IGGM 建议您在首次下单时购买您需要的高价值商品,以充分利用 10 倍积分奖励。   由于此优惠价值巨大,首单积分将在订单成功送达并通过安全审核后发放,前提是24小时内没有发生退款。   您可以在 IGGM.com 的“我的账户 → 我的订单”部分查看完成订单后获得的具体积分。如果您刚刚完成付款但没有立即看到积分,请不要担心 - 只需稍等片刻即可。   点值和有效性   了解积分的价值有助于你更好地利用它们。在IGGM积分系统中, 100分=1美元 (意味着每分约值0.01美元)。   请注意,积分并非永久有效;每个积分自获得之日起 90 天后过期。IGGM 采用用户友好的滚动过期政策:第 1 天获得的积分将在第 91 天结束时过期。滚动到期的具体计算时间取决于您帐户 IP 地址的时区。   您可随时在账户的“我的积分”页面查看积分即将到期的通知,以确保您不会错过任何优惠。   积分有多种使用方式:直接现金抵扣和优惠券兑换   在 IGGM 上购买商品时,您可以选择使用累积的积分直接抵扣订单的现金费用,或者在IGGM 优惠券兑换中心兑换大幅折扣。完全由你选择!   选项A:结账时直接现金扣款   在结账页面,您可以使用账户余额中的积分来减少当前订单的费用。但是,为了维护 IGGM 积分系统的完整性,可以用积分抵扣的订单总额比例与您的订单小计直接相关。   请参考下表,了解基于订单小计范围的具体扣减比例:   订单小计范围最大扣分率 1.00 美元 - 9.99 美元 5% 10.00 美元 - 49.99 美元         8% 50.00 美元 + 10%   关于使用积分抵扣现金的重要说明:   1.只有成功完成的订单才能获得积分;自愿取消的订单、被标记为涉嫌欺诈的订单或全额退款的订单均不符合获得积分的条件;   2.您的首单积分不会立即到账;积分将在成功发货后 24 小时内发放,前提是没有发生退款;   3.如果涉及积分的订单发生部分退款,系统将扣除相应的积分(根据退款金额四舍五入),并返还已消耗的积分。返还的已消费积分 = 已消费积分 × (退款金额 / 小计金额) ;   4.积分可与VIP折扣同时使用;   5.不能与折扣码或现金券同时使用;   6.不可兑换现金;   7.不可提取现金;   8. 不能在账户之间转移;   9.IGGM.com 保留对所有积分相关政策的最终解释权。   选项B:兑换折扣码或现金券   您还可以访问积分兑换页面,将积分(100 至 500 积分不等)兑换成折扣码(各种折扣)或现金券(需满足最低订单要求)。例如,只有当您的订单小计金额达到或超过 100 美元时,才能使用 10 美元的现金优惠券。如果您的商品小计金额低于 100 美元,优惠券将不会在结账时自动显示。   积分消费折扣码现金券(最低)订单要求) 100 3% $1(订单金额≥10美元) 200 4% $3(订单金额≥$30) 300 5% $5(订单金额≥$50) 400 8% $8(订单金额≥$80) 500 10% $10(订单金额≥$100)   所有折扣码和现金券每周限量 30 个,先到先得!不同的颜色清楚地表明了当前的库存状态:绿色表示剩余 21-30 个,橙色表示剩余 11-20 个,红色表示剩余 1-10 个。当库存降至零时,将显示“缺货”。别担心,下周再来就好!   顺便一提,如果您忘记当天签到,此优惠券页面上的小火箭表情符号就是您快速签到的方法!只需轻轻一点,摇晃一下小火箭,你的积分就到账啦!   优惠券固然好,但请记住,所有折扣码或现金券的有效期仅为 3 天。请谨慎兑换积分,并确保您想购买的商品有库存,以免浪费积分。   您可以在“我的账户 → 我的优惠券”页面查看您的优惠券及其当前到期状态。   注意:您可以通过 IGGM 主页底部的“优惠券中心”快速访问优惠券兑换页面。我们建议您将此页面添加至书签,以便日后方便办理入住和兑换手续,从而节省您的时间和精力。   关于积分兑换券的说明:   1.每周每项奖励仅限前30 名用户,先到先得。   2.所有折扣码和现金券在兑换时都需要进行CF验证。   3.已兑换的折扣码/现金券自兑换之日起3天内有效。   4.每笔订单只能使用一个折扣码/现金券。不能与VIP折扣或积分扣除同时使用。   5.折扣码/现金券不适用于礼品卡和充值服务。   6.已兑换的折扣码、现金券和免费订单一经领取,概不退换。   7.IGGM.com保留最终解释权。   隐藏选项C:直接兑换游戏内货币/物品(即将推出)   除了优惠券外,IGGM 还将很快在兑换页面添加选项,允许您直接将积分兑换成特定的游戏内物品,例如 Monopoly GO 卡牌、Diablo 4 材料或 POE 1/2 货币。   当您达到积分要求并点击兑换时,会弹出一个窗口提示您输入游戏所需的配送详情。准确填写信息并完成验证后,系统将自动生成免费订单并将其显示在优惠券订单列表中;您只需等待安全送达即可。更多积分兑换功能和选项即将推出——敬请期待!   如果在兑换验证过程中遇到错误,请检查您的网络连接,并使用可靠的 VPN 重试。   此外,鉴于虚拟物品的特殊性,一旦订单开始处理,则无法退货或换货;但是,如果由于 IGGM 平台的问题导致交付失败,则已使用的积分将全额退还。   VIP等级及福利   IGGM 为 VIP 会员提供根据累计消费额度分级的折扣。一旦您的累计消费达到特定门槛,您将自动解锁永久VIP折扣:   VIP 1:消费满 1000 美元,即可享受 1% 的折扣。   VIP 2:消费金额(≥ 1,000 美元且 < 3,000 美元),即可享受 2% 的折扣。   VIP 3:消费金额(≥ 3,000 美元且 < 6,000 美元),可享 3% 折扣。   VIP 4:消费金额(≥ 6,000 美元且 < 10,000 美元),可享 4% 折扣。   VIP 5:消费满 10,000 美元,即可享受 5% 的折扣。   折扣叠加规则:   VIP折扣可以与积分减免同时使用。 VIP折扣不能与折扣码或现金券叠加使用。   结账时,您可以选择以下两种方式之一:   选项A:折扣码或现金券(单独使用) 方案B:VIP折扣+积分抵扣(注:折扣码和现金券不适用于礼品卡或充值服务。)   叠加折扣,最大程度节省开支   结账时如何才能节省最多费用?IGGM 根据我们的 VIP 等级和积分兑换规则设计了一套智能结账系统。   在 IGGM,VIP 折扣与直接积分扣除可完美叠加。但是请注意,已兑换的折扣码或现金券不能与 VIP 折扣或积分扣除同时使用。此外,每笔订单只能使用一张优惠券。   结账时,系统会自动比较“选项 1(VIP 福利 + 直接积分扣除) ”和“选项 2(单次折扣码或现金券) ”的最终成本,为您选择最具性价比的选择,省去您手动计算的麻烦。哪个选项最划算将显示在该选项旁边(最佳性价比)。当然,如果您对优惠券和积分的使用有自己的偏好,您可以自由选择您喜欢的折扣方式。   退款和积分返还   IGGM的退款政策允许您在交货完成前的任何时间申请退款。但是,对于这种情况下的积分退款和返还,我们有具体的规定:   情况一:全额退款   如果您因个人原因取消订单,涉嫌欺诈或需要全额退款的订单将不会获得积分;此外,此类订单中已使用的积分也不会退还。   但是,如果由于 IGGM 的原因导致全额退款,则该订单消耗的积分将全额退还到您的账户。   情况二:部分退款   如果涉及奖励积分的订单由于特殊情况而进行部分退款,系统将按退款金额的比例退还已消耗积分的一部分。当然,您原本在订单完成后应获得的积分返还也会进行调整;相应的积分将根据退款金额扣除,金额四舍五入到最接近的整数。   以下是退款时计算积分返还的公式:   已退还积分 = 已消耗积分 × (退款金额 / 小计金额) 扣除已赚取积分 = 小计金额 - 退款金额(四舍五入到最接近的整数)   全新的IGGM会员积分系统旨在为您提供更多可行的长期游戏购买折扣选择。每一分积分都是我们对您支持的真挚感谢。   立即登录您的 IGGM 账户,前往签到中心开始累积积分,体验前所未有的更智能、更有奖励的结账流程!   关于IGGM积分系统的常见问题   Q1: 我能否将旧账户中的 VIP 5 特权转移到新创建的账户,并在新账户中开始累积签到积分?   A:不。为确保账户安全和平台公平性,VIP 等级和积分被视为个人账户的专属资产。根据我们的系统安全规则,严禁在不同账户之间转移、合并或赠送特权。   Q2:我的账户目前有277积分。如果我购买价值 34.68 美元的商品,并使用我的所有积分获得 2.77 美元的抵扣,但后来由于某些因素收到 15.44 美元的部分退款,我最终会得到多少积分?   A:您最初 34.68 美元的订单根据四舍五入可获得 35 个积分。由于部分退款金额为 15.44 美元,系统将按比例扣除 15 分(四舍五入到最接近的整数)。因此,本次购买获得的净积分将为:35 - 15 = 20 积分。此外,系统还会返还您消耗的积分。根据以下计算公式:已消耗积分 ×(退款金额 / 总购买金额),您将获得 123 积分返还。因此,您的最终账户余额将为 123 + 20 = 143 点。   Q3:我可以创建无限个新的IGGM账户并下小额订单来利用10倍积分的新用户奖励吗?   答:不。IGGM 严禁恶意注册多个账户、利用技术漏洞或操纵订单来获取新手福利。我们的系统配备了严格的反欺诈和风险控制机制:首单的 10 倍积分奖励只有在订单成功交付并通过 24 小时反滥用系统审核后才会发放。如果风险控制系统检测到使用同一 IP 地址、同一设备、同一支付方式或恶意账户关联进行多账户刷钱,平台保留永久封禁相关账户并清空所有已累积收益的权利。   Q4:我刚刚注册了一个账户,我的第一笔订单是一件价值 0.9 美元的小商品。因为金额低于 1 美元,系统没有给我任何积分。然后,我的第二笔订单金额为 100 美元。为什么我的第二笔订单没有获得10倍积分?我的第一笔订单本来就没有获得任何积分,这第二笔订单难道不应该算作我真正的“有效第一笔订单”吗?   A:不。系统会根据你账户下的第一笔付款订单严格识别“新用户优先订单”,无论交易金额如何。排除小计分数低于1美元的门槛是基础平台政策。因此,我们强烈建议新用户在首次购买时合并购物车,并将高价值商品捆绑在首单中,以最大化10倍积分奖励的价值。   Q5:如果网站错误导致我无法当天签到,从而中断了我的连续签到记录,IGGM 将采取哪些措施来补偿我的积分损失?   答:对于由此造成的不便,我们深表歉意。每日签到会根据与服务器时区相匹配的特定时间重置。如果由于网络延迟或错过刷新窗口导致连胜中断,系统将严格执行自动重置策略。我们建议您每天尽早完成签到,并确保网络环境稳定。如果中断最终被证实是由平台的大规模服务器故障引起的,一旦问题解决,将会发布全站官方积分补偿公告。请注意,客服人员没有权限手动更改个人入住记录。感谢您的理解。   Q6:我花了 300 积分兑换了 5 美元的现金券,但我想要的游戏道具在过去几天里一直缺货。结果,这张优惠券在3天内过期,而且没有被使用。缺货是平台的问题,为什么我的 300 积分要白白扣除?   答:很抱歉,奖励一旦在奖励中心兑换,相应的积分将被扣除且无法退款。由于每项奖励每周仅限前 30 位用户,先到先得,且现金券有效期为 3 天,我们强烈建议您在兑换前确认当前产品库存和购买意向,以免现金券意外过期。   Q7:如果我的订单状态为“已完成”,我还能申请退款吗?积分可以退还吗?   答:如果 IGGM 已成功完成交付,并且您已确认订单完成,则很遗憾,我们无法受理退款请求。已花费的积分将不予退还。但是,如果由于我们自身的问题导致 IGGM 未能完成服务(例如,如果 Tycoon Racers 代运服务未能帮助您达到排名第 1),我们将根据退款比例退还您花费的积分。   Q8:为什么我在兑换优惠券时总是遇到错误?   答:优惠券兑换错误通常是由于网络不稳定或系统安全协议引起的。您的IP地址可能被标记为来自高风险地区。我们建议您调整 VPN 设置或连接到其他网络,然后重试。如果问题仍然存在,请联系我们的 24/7 全天候客户支持团队以获得进一步帮助。   Q9:我可以使用脚本或插件来领取每周限量提供的 30 个折扣码/现金券吗?   答:为了确保所有玩家的公平性,我们实施了严格的网络安全措施。兑换任何折扣码或现金券都需要通过验证,因此任何基于脚本的模拟点击都无效。IGGM 保留对任何使用不正当手段(例如多开账号、模拟器或第三方软件)强行领取优惠券的账户取消优惠券并实施账户限制的权利。   Q10:如果我使用积分抵扣费用,但之后由于特殊情况获得退款,退回积分的有效期会延长吗?   答:不会。退回的积分保留其原始获取日期,并继续遵循 90 天的有效期规则;IGGM 平台不会因为退款而重置或延长有效期。请尽快使用返还的积分,以免过期!
查看全文
S32K3 高速スタンバイ起動失敗 こんにちは、 高速スタンバイのサンプルプロジェクトで、配列を定義しました。 到着 で .standby_data セクションにありますが、この配列はコードのどこにも使用されていません。ただし、この配列の定義をコメントアウトすると、デバイスは高速スタンバイから復帰できません。そのままにしておくと、ウェイクアップは期待どおりに動作します。さらに、最適化レベルも動作に影響することに気づきました。 -O0 最適化、ウェイクアップ失敗、しかし変更して -オス するとうまくいく。なぜ変数を定義するとうまくいくのか .standby_data このセクションはウェイクアップ機能に影響を与えますか?また、最適化レベルがこれほど大きな影響を与えるのはなぜですか? Jason22_0-1785895168596.png S32K312 RTD400 S32DS BR、 ジェイソン Re: S32K3 fast standby wake up fail こんにちは、@Senlent ご返信いただき、誠にありがとうございます。住所を0x20408000に変更したことで、以前は失敗していたケースが正常に動作するようになりました。 ちなみに、私の別のThread(S32K3 ADC Optimize DMA Streaming)については、会社のメールアドレスに登録した新しいアカウント(Jason07)で返信しましたが、返信時にアカウント変更を忘れていました。 Re: S32K3 fast standby wake up fail こんにちは、@ Jason22 プログラム内で「arr」配列をコメントアウトするかどうかは、高速ウェイクアップ後のMSPの初期値として使用される__BSS_SRAM_STARTの値に影響します。 この値が小さすぎるとスタックオーバーフローを引き起こすことがあります。 このサンプルプロジェクトでは、この値をスタンバイRAMの終了アドレスである0x20408000に設定することをお勧めします。
查看全文
GPIO 唤醒由睡眠期间的短噪声脉冲触发。 您好,NXP团队: 我们在定制板上使用 i.MX8MP,并搭载 Linux 电路板支持包。LF-6.12.20。多个 GPIO 引脚配置为唤醒源。 问题:在 EMC 瞬态测试 (ESD) 期间,这些 GPIO 线路上的短噪声脉冲会错误地唤醒已挂起的系统。 我们已经确认软件防抖无法解决这个问题:唤醒决定是由硬件在 CPU 挂起时做出的,而 GPIO 中断处理程序(包括 gpio-keys 防抖)只有在系统恢复后才会运行,因此软件无法阻止唤醒本身。 我们还查看了 Linux 驱动程序 (LF-6.12.20) 和 i.MX8MP 参考手册,但没有找到任何用于 GPIO 唤醒路径的硬件过滤器。请确认我的理解是否正确。 问题: 1. i.MX8MP 是否有任何硬件选项(在 GPIO、GPC 或可通过 ATF 配置)来忽略唤醒引脚上的极短脉冲——例如毛刺滤波器或最小脉冲宽度设置?这包括电平触发模式:是否需要按住电平至少一段时间,还是任何瞬时脉冲都能触发唤醒? 2. 如果没有这样的硬件选项,NXP 针对这种错误唤醒推荐的解决方案是什么?如有关于GPIO唤醒输入端ESD保护的应用笔记,敬请提供。 3. NXP 是否有任何参考设计,其中 Cortex-M7 检查/过滤唤醒信号,而 A53 保持挂起状态? 平台:i.MX8MP 定制板,BSP:LF-6.12.20 顺祝商祺! i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: GPIO wakeup triggered by short noise pulses during suspend 你好@Leo_dev 希望你一切都好。 Q1. 你的理解是正确的。i.MX8MP GPIO/GPC 唤醒路径没有硬件毛刺滤波器、最小脉冲宽度设置或消抖寄存器。 Q2. 由于没有片上解决方案,建议的设计是在 PAD 中添加滤波器。 Q3. 是的,您可以查看AN13400 “i.MX 8M 低功耗设计,M 内核在系统挂起状态下运行”,这是 NXP 针对此类架构的主要参考文档。 顺祝商祺! 萨拉斯。
查看全文
SJA1110経由のPTP こんにちは、 私たちはSJA1110スイッチを介して接続されたPolarFire SoC GEMでPTPをデバッグしています。 我々は以下のことを観察した。 Layer 2上のPTP(ptp4l -2)はスイッチで受信されます(入力カウンターが増加します)が、転送はされません(出口カウンターが増加しません)。 PTP over UDP (ptp4l) は、同じブリッジパスを介して正しく転送されます。 通常のイーサネットトラフィック(ICMP/ARP)も正しく転送されます。 SJA1110で、レイヤ2 PTPフレーム(宛先MACアドレス01:1B:19:00:00:00)をブリッジポート経由で転送するために、特別な処理や追加の設定が必要ですか?レイヤ2 PTPの転送に関して、既知の制限事項はありますか? また、PolarFire SoC GEMでは、UDP over PTP(ptp4l)は完全にサポートされ推奨されているのでしょうか、それともレイヤー2のみがサポート/推奨されているトランスポートなのでしょうか? 何かアドバイスをいただければ幸いです。 Re: PTP over SJA1110 こんにちは、 @Ankur_pixl さん、 典型的なgPTPや時間認識ブリッジのケースでは、スイッチがすべてのgPTPフレームを通常のマルチキャストトラフィックとして透過的に転送することは期待されません。 通常の流れは、スイッチがグランドマスターからgPTPフレームを受け取り、内部Cortex-M7上で動作するgPTPスタックを通じて処理し、接続された下流デバイスに向けて適切なタイムスタンプを持つ独自のgPTPフレームを生成するというものです。   SJA1110通常、レイヤー2オートモーティブプロファイル向けに設定されており、PTP宛先MACアドレスは01:80:C2:00:00:0Eです。このアドレスは802.1AS/gPTPスタイルのレイヤー2トランスポートに使用され、そのようなフレームは通常、単にブリッジされる通常のマルチキャストトラフィックではなく、スイッチのPTP/gPTP機能によって処理されます。   イングレスカウンターが増加する一方で、エグレスカウンターが増加しないというあなたの観察は、レイヤー2のPTPフレームがスイッチに受信されているものの、通常のブリッジパスを経由して転送されていないことを示唆しています。一つの考えられる説明としては、使用されるPTPマルチキャストMACアドレスがSJA1110設定(例えばGeneral Parametersテーブル、DPI構成、L2ルックアップテーブル、その他のPTP/トラップ関連設定項目)によってマッチングされ、フレームが期待される外部エグレスポートに転送されるのではなく、ホストポート、特に内部Cortex-M7ホストにトラップされるというものがあります。   これにより、PTP over UDPや通常のイーサネットトラフィック(ICMP/ARP)が正しく転送される理由も説明できます。これらのフレームは、同じレイヤ2 PTP/gPTP分類ルールに一致しないため、通常のブリッジトラフィックとして処理されます。   SJA1110の設定において、以下の点を確認してください。   1. スイッチでどのPTP宛先MACアドレスが設定されているか、特に一般パラメータテーブルで。 2. PTP/gPTPフレームがホストポートにトラップされるように設定されているかどうか。 3. 内部Cortex-M7ホストがgPTPスタックを実行しているか、トラップされたPTPフレームを受信しているか。 4. 使用される宛先MACアドレスが01:1B:19:00:00:00か01:80:C2:00:00:0Eか。 5. L2ルックアップテーブルまたはマルチキャスト転送設定に、この宛先MACアドレスを必要な外部ポートに転送するエントリが含まれているかどうか。 6. このトラフィックに関して、入力ポートと出力ポートが同じ VLAN および転送ドメインに属しているかどうか。   SJA1110をgPTP/時間認識ブリッジとして使用する場合、通常想定される構成は、元のgPTPフレームを単純に透過的に転送するものではありません。スイッチはgPTPタイミングドメインに参加し、接続されたデバイスに対して対応するgPTPメッセージを生成します。   もしSJA1110を生のレイヤー2 PTPフレームの単純なイーサネットブリッジとしてのみ使用する意図であれば、このトラフィックに対してPTPトラップや特殊処理を無効化または回避し、対応するマルチキャスト宛先MACアドレスをL2転送設定で明示的に許可する必要があります。   PolarFire SoC GEMについては、推奨または完全にサポートされているPTPトランスポートモードについて断言することはできません。SJA1110の観点からすると、ブリッジパスが許可する場合、UDP上のPTPは通常のIP/UDPトラフィックとして転送される可能性があります。しかし、これは必ずしもPolarFire GEMドライバーがハードウェアタイムスタンプでUDPトランスポートをサポートしたり推奨されたりしているという意味ではありません。対応するPTPトランスポートおよびタイムスタンプモードについては、PolarFire SoC GEMドキュメントまたはMicrochipサポートで確認してください。   よろしくお願いいたします。 パベル Re: PTP over SJA1110 こんにちは、 宛先MACアドレスは01:1B:19:00:00:00です。私たちはLinux DSAブリッジでスイッチを使っており、Cortex-M7コアを操作したり設定したりすることはできません。 L2構成でこのトラフィックを通過させるにはどうすればよいでしょうか?ブリッジmdbを使用しましたが、うまくいきません。エントリはインストールされ、オフロード済みとして表示されますが、フレームはポート間で転送されません。これはCortex-M7コアで明示的に設定する必要がありますか? 当社のシステムに関する追加情報: 当社のMACアドレス/ポート構成は以下のとおりです。 bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent bridge mdb add dev br-EPS port t1-6 grp 01:1b:19:00:00:00 permanent これらは bridge -d mdb show ではオフロードされていると表示されますが、一方のポートに到着した L2 PTP フレームはもう一方のポートには転送されません。 重要なのは、スイッチのポートの一つに動作するCPUポートがないことです。これは純粋に2つのポート間のルート(ポート間転送)として動作し、そのパスにはホストやCPUポートは含まれません。予約済みマルチキャスト01:1b:19:00:00:00はデフォルトでマネジメント/CPUルートに閉じ込められているようで、そのルートはここでは利用できないため、フレームは転送ではなくドロップされているのではないかと推測しています。 CPUや管理ポートに頼らずに、この予約済みPTPマルチキャストMACをハードウェア内で2つのユーザーポート間で転送するスイッチの設定方法についてアドバイスいただけますか? -- アンクル Re: PTP over SJA1110 こんにちは、 @Ankur_pixl さん、 宛先MACアドレス01:1B:19:00:00:00は、IEEE 1588レイヤ2 PTPマルチキャストアドレスです。これは、通常、SJA1110 gPTPオートモーティブプロファイル構成で使用される802.1AS / Automotive Profile gPTP宛先MACアドレス01:80:C2:00:0Eとは異なります。   あなたの説明からすると、これは標準的なLinuxブリッジMDBの問題とは思えません。MDBエントリが正しくインストールされ、オフロードされたと報告されていても、フレームが通常のマルチキャスト転送パスに到達しない場合があります。   おそらく、SJA1110ハードウェアやSJA1110 DSAドライバーが、通常のL2マルチキャスト転送決定が適用される前に、この宛先MACをPTP/制御フレームとして分類しているのが考えられます。その場合、フレームは2つのユーザーポート間で直接転送されるのではなく、CPUやマネジメントパスにリダイレクトされることがあります。   これは、観察された挙動を説明するだろう。   - 入力カウンターが増加し、フレームがスイッチに受信される、 - MDBエントリがインストールされ、オフロード済みとして表示されます。 - しかし、通常のポート間転送が適用される前にフレームがCPUやマネジメントルートに閉じ込められている可能性が高いため、エグレスカウンターは増加しません。   ポート間転送パスにCPUやマネジメントルートが存在しない場合、トラップされたフレームは事実上ドロップされる可能性があります。   Cortex-M7についてですが、Linux DSAブリッジ経由でスイッチを使用し、内部Cortex-M7上でgPTPスタックを実行・制御していない場合、通常はCortex-M7アプリケーションから設定するものではありません。このユースケースでは、関連する構成はLinux DSAドライバーと、そのドライバーによってプログラムされたスイッチハードウェア構成によって所有されます。   ただし、01:1B:19:00:00:00 に対して専用の PTP/制御フレームトラップ ルールがアクティブになっている場合は、「bridge mdb」だけでは不十分な場合があります。このトラフィックをハードウェア上で2つのユーザーポート間で直接転送するには、スイッチの設定で以下を満たす必要があります:   1. 01:1B:19:00:00:00 の PTP/制御フレームトラップはこのトラフィックに対して無効化またはバイパスされており、 2. 必要なユーザーポートに向けて有効なL2マルチキャスト転送エントリが01:1B:19:00:00:00に存在します。   現時点では、SJA1110 DSA構成でそのようなルールが有効になっている場合、標準の`bridge mdb`コマンドだけでは、下位レベルのPTP/制御フレームトラップルールを上書きすることはできないと考えられます。   次のステップとして、SJA1110 DSAドライバーまたはBSPがPTPハードウェアのタイムスタンプを有効にしているか、01:1B:19:00:00:00のMACフィルター/PTPトラップルールをインストールしているか確認してください。そのようなルールが存在する場合、解決策は単に実行時のLinuxブリッジMDBコマンドだけでなく、ドライバーレベルの変更やスイッチの静的設定変更を必要とする可能性が高いです。   以下の情報を教えていただけますか?   - Linux BSP/カーネル版 - SJA1110 DSAドライバのソースベースライン、 - 「bridge -d mdb show」の完全な出力、 - 関与するDSAポート名および物理スイッチポート番号、 - SJA1110 DSAドライバーでPTPハードウェアのタイムスタンプが有効かどうか、 - 可能であれば、DSAマスター/CPUインターフェース上でパケットキャプチャを行い、レイヤー2のPTPフレームがCPUパスにトラップされているかどうかを確認すること。   この情報をもとに、フレームがPTP/コントロールトラップパスに消費されているか、あるいは別のL2マルチキャスト転送制限があるかをさらに確認できます。 よろしくお願いいたします。 パベル
查看全文
PNEV5190B 无法工作 从 NFC Cockpit 的“附加”选项卡上的“加载辅助固件”选项加载 Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin 后,我的 PNEV5190B 不再响应,也无法通过 NFC Cockpit 进行操作。 根据更新日志,固件下载已成功完成,未报告任何错误。更新完成后,主板才停止响应。 我在这个帖子里找到了类似的问题,但我想要了解根本原因。 固件更新成功后,什么原因会导致主板无响应? 我是否有可能使用了与我的主板不匹配的备用固件镜像或固件版本? 为什么加载辅助固件会导致 NFC Cockpit 无法再与板通信? 感谢您的支持。 Re: PNEV5190B does not work 你好@Miyazaki001 希望你一切都好。 请问您能否提供更多关于您设备配置的详细信息?你们遵循的是什么步骤? 我尝试了以下设置: -PNEV5190B-FW v2.0b-NFC Cockpit v9.0.0 -" Extra " 选项卡 > " 辅助固件 > 加载辅助固件 ——选择 nxpnfccockpit_v9.0.0 \ 固件\ Secondary_pn5190\ k8x\ nfcrdlib_Simplified api_emvco_secondary.nc.bin " NFC Cockpit 应该提示关闭 COM 端口并重新打开: EduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.png 重新打开 COM 端口后,您应该能够在“附加”选项卡中启动辅助固件。 问候, 爱德华多。 Re: PNEV5190B does not work 嗨@EduardoZamora , 感谢您的回复。 我的配置如下: - PNEV5190B(B1芯片) - PN5190 固件版本 v02.05 - NFC Cockpit v7.4 - 额外选项卡 → 辅助固件 → 加载辅助固件 已选: -NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin 二次固件更新似乎已成功完成。根据日志显示,固件下载已完成,未报告任何错误。 下面显示的是日志的相关部分。 20260803.png20260803.png20260803.png20260803.png20260803.png 更新后,NFC Cockpit 提示我手动关闭并重新打开 板连接。我按照这个步骤操作了,我还尝试手动断开并重新连接 COM 端口。 但是,重新连接后,电路板不再响应任何命令。日志显示 NFC Cockpit 尝试与板通信时超时。 我已附上相关日志供您参考。 请问您能否提供以下建议: - PN5190 FW v02.05 与此辅助固件兼容吗? - NFC Cockpit v7.4 与此辅助固件之间是否存在已知问题? 我在这个帖子里找到了类似的问题,但我想要了解根本原因。 感谢您的支持。 顺祝商祺! Re: PNEV5190B does not work 您好, 我找不到任何关于使用此特定配置时出现意外行为的已记录案例。 NFC Cockpit v7.4.0 已过时;请更新到最新版本 (v9.0.0) 并对 PN5190 执行固件更新。之后,请将你的发现告诉我。 如果在更新设置后此问题仍然存在,请告知您的跳线配置和电源连接(最好能提供一张电路板的照片)。 问候, 爱德华多。 Re: PNEV5190B does not work 嗨@EduardoZamora , 感谢您的回复。 根据您的评论,我们将 NFC Cockpit 版本更改为最新版本 v9.0.0。我们还把 PN5190 固件从 v02.05 更新到了 v02.0D,这是 NXP 网站上提供的最新版本,然后重新尝试了二级固件更新。 然而,结果还是一样,问题依然存在。 画像.png画像.png画像.png画像.png肖像.png 我们还附上了板的照片供您参考。 画像.jpg画像.jpg画像.jpg画像.jpg肖像.jpg 使用以下跳线设置: J8:已关闭 J9:2–3(外部电源) J12:关闭 J22:关闭 J23:关闭 本次测试中,我们使用外部 5V 直流电源,限流为 1A。 如果您发现还有其他设置或需要我们检查的地方,请与我们联系。 Re: PNEV5190B does not work 您好, 您的跳线和电源配置看起来没问题。 请问您是否能够刷写并运行任何演示应用程序(例如,DiscoveryLoop)是否包含在PN5190的NFC读取器库中?有关此内容的更多信息,请参阅PNEV5190B 评估板快速入门指南第 5.3 章。 作为一项补充测试,请您尝试使用另一台电脑,并将系统语言(不仅仅是显示语言)设置为英语? 问候, 爱德华多。 Re: PNEV5190B does not work 嗨@EduardoZamora , 感谢您的回复。 我们会单独尝试您建议的方法。 与此同时,我们进行了额外的测试,并得到了以下结果。 首先,我们通过 J-Link 对 NFC Cockpit v9.0.0 附带的以下固件进行了编程: BootLoader_And_Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.bin 之后,我们使用 NFC Cockpit 更新了以下辅助固件: Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin 采用此方法后,之前遇到的错误没有再发生,更新成功完成。 根据这一结果,我们怀疑引导加载程序和辅助固件版本之间可能存在兼容性依赖关系。 请您澄清以下几点? 1.更改 NFC Cockpit 版本时,是否不仅需要将辅助固件更新到兼容版本,还需要将引导加载程序更新到兼容版本? 2. 是否可以通过 NFC Cockpit 更新 BootLoader? 或者是否需要像 J-Link 这样的外部调试器/编程器来更新引导加载程序? 3. 是否有任何文档描述每个 NFC Cockpit 版本附带的辅助固件和引导加载程序之间的兼容性? 例如,我们想知道哪些版本的辅助固件可以与同一个引导加载程序一起使用。 这些问题背后还有另一个我们希望解决的问题。 我们一直使用自己的应用程序(而不是 NFC Cockpit)通过 COM 端口进行串行通信来控制 PNEV5190B。 使用 NFC Cockpit v7.4.0 附带的辅助固件时,我们的应用程序能够成功地与 PNEV5190B 进行通信和控制。 但是,在更新到 NFC Cockpit v9.0.0 附带的辅助固件后,使用相同通信方法的同一应用程序会遇到通信错误。 您能否也澄清一下以下这一点? 4. NFC Cockpit v7.4.0 和 v9.0.0 附带的辅助固件在初始化顺序、COM 通信设置、通信协议、命令规范或相关行为方面是否有任何变化? 如果有任何描述这些变更的发布说明或文档,我们非常感谢您能与我们分享。 Re: PNEV5190B does not work 您好, 如PNEV5190B 评估板快速入门指南第 5.1 节所述,建议使用最新版本的 NFC Cockpit 将固件更新到最新版本。固件编程需要使用外部调试器,如NXP NFC Cockpit 用户指南第 3.3 节所述。 遗憾的是,目前还没有文档提供引导加载程序版本和二级固件版本之间的正式兼容性矩阵。最接近的参考资料是 VCOM 源代码包 中的 版本变更日志 (NxpNfcCockpit_VCOM_UcBalFW\NNC_UcBalFW\phUcBal\src\NNC_uC_VCOM_Ver.h)。 问候, 爱德华多。
查看全文
MINISASTOCSI 最新回路図 こんにちは、チームのみなさん。 MINISASTOCSIの最新の設計図を共有していただけませんか? Re: MINISASTOCSI Latest Schematics こんにちは、 @ramkrish さん。 MINISASTOCSI ボードの最新版は A1 です。 ご参考までに、ファイルをあなたのメールアドレスに送信しました。 受信に問題があった場合、または今回のボード改訂に関して追加情報が必要な場合は、お知らせください。 よろしくお願いします、 チャビラ Re: MINISASTOCSI Latest Schematics こんにちは、 @Chaviraさん 受け取りました、ありがとうございます
查看全文
S32K314 CAN 问题 我正在使用 S32K314,最近在通过短路振荡器进行测试时遇到了 CAN 问题; 恢复后,我监测了SPI和ADC模块,这些模块工作正常,但CAN模块无法正常工作。 调试器显示以下信息:在此状态下,CAN 总线无法接收或发送任何帧。 这是怎么回事?如何通过软件修复这个故障? Snipaste_2026-08-04_13-32-47.jpg   Re: S32K314 CAN issue 你好, 谢谢你的回复。 我尝试在“Mcu_ClockSourceFailure_Notification”中添加一些测试代码,但此通知没有被触发; 那么从软件方面来说,我们如何才能注意到这个问题并重置CAN模块呢? 谢谢! 以下是您提到的寄存器的值: MCR KidhRobin_0-1785975444257.png CTRL1 KidhRobin_1-1785975470032.png 认知行为疗法: KidhRobin_2-1785975496485.png FDCBT: KidhRobin_6-1785975801928.png ECR KidhRobin_4-1785975599003.png ESR1 KidhRobin_5-1785975618985.png Re: S32K314 CAN issue 您好, 从提供的屏幕截图来看,接收错误计数器 (RXERRCNT) 正在增加,而 TXERRCNT 保持为 0,这与典型的发送相关问题并不完全吻合,即使 ESR1 指示正在进行传输尝试。 振荡器短路可能会影响时钟,例如导致恢复后 CAN 位时序不正确。然而,目前的信息不足以证实这一点。 请问您能否提供以下信息: 更全面地了解 FlexCAN 寄存器(包括 MCR/CTRL1/CBT/FDCBT、ECR 和 ESR1), 恢复后模块和CAN协议时钟配置, 故障期间是否捕获了TX、RX和CAN总线测量数据? 如果 FlexCAN 模块时钟和 CAN 协议时钟正在运行且频率符合预期,您还可以尝试执行 FlexCAN 模块软件重置,然后完全重新初始化模块,并检查通信是否恢复。 BR,彼得 Re: S32K314 CAN issue 您好, 如果没有进入 Mcu_ClockSourceFailure_Notification(),我的第一个假设是项目中没有配置或启用相应的 MCU 中断/通知路径。 请您核查一下: 是否对受影响的时钟源启用时钟监控(CMU)。 CMU中断是否已启用。 MCU 模块是否配置为在检测到时钟故障时调用 Mcu_ClockSourceFailure_Notification()。 在振荡器短路事件发生后,检查 CMU 和 RGM 状态寄存器也可能很有用,以验证是否确实检测到了时钟故障。 从 FlexCAN 寄存器转储可以看出,该模块似乎已启用并与总线同步 (SYNCH=1),而 RXERRCNT 增加,TXERRCNT 保持 0,现在没有总线活动。我看到显示的位定时寄存器(CTRL1、CBT、FDCBT)不包含有效的 CAN 定时配置,尽管如果使用增强型 CAN 位定时并且实际定时是通过相应的增强型 CAN 位定时寄存器配置的,这是可以预期的。 因此,在实施 CAN 复位策略之前,最好先验证是否检测到时钟故障事件以及通知机制是否已正确配置。 BR,彼得
查看全文
ddr_stress_tester一部のDDRでは動作しません 私は長年ddr_stress_testerこのツールを使ってきましたが、今年、新しい製造プロセスのDDR(20nmや25nmのDDR)ではうまく動作しないことに気づきました。CPUの周波数を選択するとバイナリがフリーズすることがありました。例えば、winbond w631gu6rbやISSI IS43TR166640C-125JBLI-TRなどです。ちなみにCPUモデルはmx6solo/dlです i.MX6DL Re: ddr_stress_tester cannot work on some DDRs この症状は、DDRダイのプロセスノード自体というよりも、DDRの初期化/MMDC設定、あるいはボードレベルのマージンに関連している可能性が高い。NXPのドキュメントで、i.MX6Solo/DL ddr_stress_testerが20nm/25nmだからハングするという問題は見つかりませんでしたし、NXPのライブラリやコミュニティパスで部品番号、プロセスノード、「CPU周波数」のハング表現で確認してもWinbond W631GU6RBやISSI IS43TR166640C特有の情報も見つかりませんでした。 まず最初に確認すべきこと: 古い固定スクリプトではなく、i.MX6/7 DDRツールフローを使用してください。 i.MX6/7 DDRツールは、実際のデバイス構成(密度、チップセレクト、バス幅、ボードレイアウト/スウィズリングなど)に基づいてカスタムDRAM初期化を生成およびテストすることを目的としており、 i.MX6DL/Sデバイスを明示的にサポートしています。 DDRベンダーまたはDDRのジオメトリ/タイミングを変更した場合は、DRAMレジスタプログラミング支援ツール/DDRツールフローを使用して.inc初期化スクリプトを再生成してください。NXPは、スクリプトは「カスタムボードとメモリに合わせて変更する必要がある場合がある」と述べています。 古い校正値が依然として適用されると想定しないでください このストレスツールは、i.MX6ボードに対して、書き込みレベリング、DQSゲーティング、読み書き遅延キャリブレーション、およびストレステストを実行します。 周波数選択直後にハングすると、キャリブレーション完了前にDDRがすでに限界になっている可能性があります。NXPコミュニティのガイドラインでは、類似のi.MX6 DDRストレスハングは、MMDCパラメータの誤り、電力のブラウンアウト、基板ノイズ、レイアウトの問題にポイントを挙げます。 DDR電圧/モードおよび周波数選択を確認してください i.MX6Solo/DualLite DDRパッドはLPDDR2およびDDR3/DDR3Lモードをサポートしています。 DDR3/DDR3L I/O電源については、i.MX6Solo/DLのデータシートの抜粋によると、DDR3は1.425–1.575 V、DDR3Lは1.283–1.45 Vとされています。 i.MX6 DDRストレスツールは135 MHzから672 MHzまでのDDRストレステストをサポートします。まず保守的なDDR周波数を選択し、キャリブレーションが完了した後に上位に進めます。 更新タイミングを確認する i.MX6のケースでは、低周波ハングがMMDC0_MDREFを補正することで解決され、tREFIが3.9μsから7.8μsに変化しました。 NXPのドキュメントでは、MMDCx_MDREFがDDRリフレッシュ動作を制御するレジスタとして示されており、一部のDDR3デバイスでは温度依存のリフレッシュ変更が必要であることも指摘されています。85℃以下の場合は64ms、85℃を超える場合は32msのリフレッシュ周期。 既知のツール環境のハングアップ原因を排除する U-Bootから動作する場合は、スプラッシュ画面やIPU、またはDRAMにアクセスできる可能性のあるDMAを無効にしてください。NXPは、アクティブなIPU/スプラッシュアクセスがDDRストレスフロー中にシステムがハングする可能性があると指摘しています。 ウォッチドッグヒューズや設定が有効かどうか確認してください。NXPは、i.MX6Soloではウォッチドッグがキャリブレーションやストレステスト中にデバイスをリセットできるDDR_Stress_Tester指摘しています。 JTAG版を使っている場合、DDRの周波数選択後にi.MX6のケースが停止したと報告され、その際のガイダンスはJTAGモード/接続を確認し、簡単なSDKのDDRテストと信号・電力プロービングを使うよう指示されていました。 私の推奨事項は、新しいDDR部品ごとにDDR初期化スクリプトを再生成し、低いMMDC/DDR周波数から開始し、MDREF/タイミング値をDDRデータシートと照合して確認してから、キャリブレーションを再実行することです。それでもCPU/DDR周波数選択の段階で処理が停止する場合は、その移行中にDDRの電源レールとクロックをオシロスコープで測定し、正常に動作していた古いDDRと新しいWinbond/ISSI製部品のMMDCレジスタ値を比較してください。 この問題は、まず i.MX6Solo/DL DDR の初期化とマージンの問題として対処する必要があります。NXP が 20 nm/25 nm DDR3 プロセス自体を ddr_stress_tester の非互換性として認識しているという証拠は見つかりませんでした。
查看全文
S32K3 FS26 新 WDG 周期无法工作 你好, 在我的板上,上电复位后,我将 FS26 看门狗周期配置为 无限 在初始化期间。然后我退出调试模式并进入正常模式(读取的值来自 SBC_FS26_FS_STATES_ADDR 是 0xB )。 之后,我将监视程序周期更改为 64毫秒 (如屏幕截图所示),执行一次看门狗刷新(馈送),返回值表示成功。 WD_RFR_CNT 增加 1,阅读 SBC_FS26_FS_WDW_DURATION_ADDR 给予 0xB0CD ,确认周期已成功更新为 64 毫秒。 但是,如果我之后停止喂养看门狗, 没有发生错误或RESET。 相反,如果我将看门狗周期配置为 64 毫秒 初始化期间 然后,在退出调试模式后,不再向看门狗提供数据。 做 按预期触发重置。 为什么在正常模式下,即使寄存器写入和刷新都成功,当周期从无限变为 64ms 时,看门狗仍然不起作用? Jason22_0-1785918605528.pngJason22_0-1785918605528.pngJason22_0-1785918605528.pngJason22_0-1785918605528.png S32K344 RTD7.0.0 FS26 6.0.0 S32DS3.6.4 EB30.0 BR, 杰森 Re: S32K3 FS26 new WDG period not work 你好, 哦!回复时我忘记切换账号了——Jason07是我的另一个账号。 BR, 杰森 Re: S32K3 FS26 new WDG period not work 你好, 非常感谢您的回复。 我将监视周期设置为 无限 在初始化期间,根据驱动程序代码,某些操作仅在周期为 INFINITE 时执行——例如,在执行期间关闭 INIT_FS。 Sbc_fs26_InitDevice() 函数,并调用 Sbc_fs26_WdRefresh 里面 Sbc_fs26_清除故障错误计数器 清除故障错误计数器。 Jason07_1-1785986004068.pngJason07_1-1785986004068.pngJason07_1-1785986004068.pngJason07_1-1785986004068.png Jason07_2-1785986074130.pngJason07_2-1785986074130.pngJason07_2-1785986074130.pngJason07_2-1785986074130.png 如果我将周期设置为有限值,则 Sbc_fs26_WaitFailsafeRelease 在 Sbc_fs26_FsxbRelease 中返回 E_NOT_OK ,并且 FS26 会一直处于待处理状态。 FS_STATES_FS0B_ASSERT 状态,无法过渡到 FS_STATES_NORMAL_FS 。 Jason07_0-1785985959468.pngJason07_0-1785985959468.pngJason07_0-1785985959468.pngJason07_0-1785985959468.png BR, 杰森 Re: S32K3 FS26 new WDG period not work 你好, 由于在 INIT_FS 关闭时监视程序已被禁用,因此监视程序不会启动。 配置 WDW_PERIOD[3:0] = 0000 选择无限打开窗口。根据 FS26 看门狗规范,看门狗窗口只能在初始化阶段禁用,并且禁用会在初始化阶段结束后生效。以这种方式禁用的看门狗随后不能通过向 FS_WDW_DURATION 写入有限值而在正常模式下启用。 寄存器读取成功确认新的 WDW_PERIOD 字段已写入,递增的 WD_RFR_CNT 确认刷新已被接受。这些观察结果表明,看门狗超时监控功能并未重新启用。 如果在初始化期间启用了有限周期的看门狗,则支持运行时周期更改。因此,在 INIT_FS 期间配置有限的看门狗周期,例如,如果需要较长的初始化间隔,则最大有限周期为 1024 毫秒。进入正常模式后,周期可以更改为 64 毫秒。新的有限期限将在下一次监控程序刷新后生效。 这种行为也解释了为什么在初始化期间配置 64 毫秒时会发生 RESET:在这种情况下,当 INIT_FS 关闭时,看门狗将被启用。 petervlna_0-1785930476258.pngpetervlna_0-1785930476258.pngpetervlna_0-1785930476258.pngpetervlna_0-1785930476258.png 从功能安全角度来看,禁用看门狗会导致无限状态,因为比较是在硬件中进行的,匹配成功时标志位总是会上升。 顺祝商祺! Peter Re: S32K3 FS26 new WDG period not work 你好, 根据观察到的行为,在 NORMAL_FS 中将 WDW_PERIOD 从无限打开窗口更改为 64 毫秒后,FS26 看门狗监控似乎没有启动。 寄存器写入成功,读取值 (0xB0CD) 证实了这一点,并且看门狗刷新命令继续被接受,WD_RFR_CNT 递增表明了这一点。然而,在刷新停止后没有任何看门狗超时反应,这表明看门狗的监督本身并未激活。 当看门狗周期配置为无限打开窗口时,Sbc_fs26_NormalFSSequence() 通过发出立即看门狗刷新来关闭 INIT_FS。同样,Sbc_fs26_ClearFaultErrorCounter() 使用连续的看门狗刷新来清除故障错误计数器,因为在无限模式下没有看门狗窗口时间限制。 当配置了有限的监视周期时,驱动程序会遵循不同的路径。看门狗刷新必须与有效的看门狗窗口同步,驱动程序使用看门狗定时机制(pfWdgNotification、定时器同步和 Sbc_fs26_TimeWaitClearFault()),而不是发出连续的立即刷新。 petervlna_0-1786002507583.pngpetervlna_0-1786002507583.pngpetervlna_0-1786002507583.pngpetervlna_0-1786002507583.png Re: S32K3 FS26 new WDG period not work 你好@Jason22 你解决这个问题了吗? 在调用 Sbc_fs26_InitDevice 之后,您是否成功地将 FS26 从 FS0B_ASSERT 状态切换到NORMAL_FS 状态? 谢谢。 Re: S32K3 FS26 new WDG period not work 感谢您的解答。 Re: S32K3 FS26 new WDG period not work 你好@Djuric 只有当看门狗周期初始化为无穷大时,才能进入正常模式。如果监视周期的初始值是有限的,则无法进入正常模式。
查看全文
S32DS5.5のライセンス更新にご協力ください。 チームの皆さん、こんにちは。 私のS32DS5.5のライセンスは期限切れになりましたが、古いプロジェクトでまだ必要です。更新手続きを手伝ってください。 ご回答をお待ちしています。 JoaquinL_0-1785918181438.png BR、ホアキン
查看全文
NVMキーカタログに保存されているECC公開鍵のSHA-512に関する質問 NXPエキスパート様、 HSEの鍵マネジメント機能について質問があります。 私たちは HSE-B を搭載した S32K312 を使用しており 、 ECC公開鍵 を NVMキーカタログ に 保存しています 。 私たちのアプリケーションでは、NVMキーカタログに保存されているECC公開鍵の SHA-512ハッシュ を取得する必要があります。 キーを保存した後、 SHA-512ハッシュ を比較することで、キーが正しく保存されていることを検証します 。 例: Kを NVMキーカタログに格納されているECC公開鍵とする 。 SHA-512(K) の値を取得したいです 。 HSEは、NVMキーカタログに保存されているキーのSHA-512ハッシュを取得するためのAPIまたはメカニズムを提供していますか? そうでない場合、カタログに保存されているキーのSHA-512(K)を計算または検証するための推奨される方法はありますか? 再開まで今しばらくお待ちください。 Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog わかった。サポートありがとうございます Re: Question About SHA-512 of an ECC Public Key Stored in the NVM Key Catalog こんにちは、@NghiaLX308さん ユーザーがSHA-512をキーマテリアルに直接実行できるAPIはありません。 回避策として、ECC公開鍵をエクスポート(サービスHSE_SRV_ID_EXPORT_KEYを使い)、その後SHA-512操作(サービスHSE_SRV_ID_HASHを使って)実行できます。ECC公開鍵は秘密ではないため、平文でエクスポート可能です。暗号化または認証された形式でエクスポートする必要はありません。 よろしくお願いいたします。 ルーカス
查看全文
PNEV5190Bは動作しません NFC CockpitのExtraタブにある「Load Secondary Firmware」オプションからNfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.binをロードした後、PNEV5190Bが反応せず、NFC Cockpitから操作できません。 アップデートログによると、ファームウェアのダウンロードはエラー報告もなく正常に完了しました。アップデートが完了した後、ボードが応答しなくなった。 このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。 ファームウェアのアップデートが成功したにもかかわらず、なぜ基板が反応しなくなるのでしょうか? 私のボードまたはファームウェアのバージョンに対して、間違ったセカンダリファームウェアイメージを使用した可能性はありますか? なぜセカンダリファームウェアをロードすると、NFCコックピットがボードと通信できなくなる状態になるのでしょうか? 再開まで今しばらくお待ちください。 Re: PNEV5190B does not work こんにちは、 @Miyazaki001さん あなたの調子が良いといいのですが。 あなたのセットアップについてもう少し詳しく教えていただけますか?どのような手順に従っていますか? 私は以下の設定を試してみました。 - PNEV5190B - FW v2.0B - NFC Cockpit v9.0.0 - 「追加」タブ > 「セカンダリファームウェア」タブ > セカンダリファームウェアのロード - NxpNfcCockpit_v9.0.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin を選択してください NFC Cockpitは、COMポートを閉じてから再度開くように指示するはずです。 EduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.png COMポートを再度開いた後、「Extra」タブでセカンダリファームウェアを起動できるようになります。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 私のシステム構成は以下のとおりです。 - PNEV5190B(B1チップ) - PN5190 FW v02.05 - NFC Cockpit v7.4 - 追加タブ → セカンダリファームウェア → セカンダリファームウェアのロード 選択済み: -NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin 二次ファームウェアアップデートは正常に完了したようです。ログによると、ファームウェアのダウンロードはエラー報告なしに完了した。 ログの該当箇所を以下に示します。 20260803.png20260803.png20260803.png20260803.png20260803.png アップデート後、NFC Cockpitからボード接続を手動で閉じてから再度開くように指示されます。私はこの手順に従い、さらにCOMポートを手動で切断して再接続することも試しました。 しかし、接続を再開した後、ボードはどのコマンドにも応答しなくなった。ログには、NFC Cockpitがボードとの通信を試みた際にタイムアウトが発生したことが記録されている。 参考までに、関連するログファイルを添付しました。 何かアドバイスをいただけますか: PN5190 FW v02.05は、このセカンダリファームウェアと互換性がありますか? NFC Cockpit v7.4とこのセカンダリファームウェアに関して、既知の問題はありますか? このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 Re: PNEV5190B does not work こんにちは、 この特定のセットアップで予期せぬ挙動が記録された例を見つけることはできませんでした。 NFC Cockpit v7.4.0は旧バージョンです。最新バージョン(v9.0.0)にアップデートし、PN5190のファームウェアアップデートを実行してください。その後、あなたの調査結果を教えてください。 設定を更新した後もこの症状が続く場合は、ジャンパーの設定と電源接続についてお知らせください(基板の写真も添付していただけると助かります)。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 お客様からのご意見に基づき、NFC Cockpitのバージョンを最新バージョンであるv9.0.0に変更いたしました。また、PN5190のファームウェアをv02.05からv02.0D(NXPのウェブサイトで入手可能な最新バージョン)にアップデートし、セカンダリファームウェアのアップデートを再試行しました。 しかし、結果は同じで、問題は依然として解決されていない。 画像.png画像.png画像.png画像.png画像.png 参考までに、ボードの写真も添付しました。 画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg 以下のジャンパー設定が使用されます。 J8:閉鎖 J9:2-3(外部電源) J12:閉鎖 J22:閉鎖 J23:閉鎖 このテストでは、電流制限が1Aの外部5V DC電源を使用します。 他に確認すべき設定や項目があればお知らせください。 Re: PNEV5190B does not work こんにちは、 ジャンパー設定と電源構成は問題ないようです。 もしかして、デモ用のアプリケーション(例:)をフラッシュして実行することはできますか?PN5190の NFCリーダーライブラリ で提供されているDiscoveryLoop?詳細 PNEV5190B評価ボードクイックスタートガイド、第5.3章を参照してください。 追加のテストとして、別のPCとシステム言語(ディスプレイだけでなく)を英語に設定してみていただけますか? よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、 評価ボードのクイックスタートガイドのセクション5.1 PNEV5190B述べているように、最新のNFCコックピットを使用してファームウェアの最新バージョンにアップデートすることが推奨されています。ファームウェアプログラミングには外部デバッガが必要であり、 これはNXP NFCコックピットユーザーガイド3.3節に記載されています。 残念ながら、ブートローダーバージョンとセカンダリFWバージョン間の正式な互換性マトリックスを提供する文書は存在しません。最も近い参照は 、VCOMソースパッケージ 内の バージョン変更ログ(NxpNfcCockpit_VCOM_UcBalFW\NNC_UcBalFW\phUcBal\src\NNC_uC_VCOM_Ver.h)です。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 ご提案いただいた方法を別途試してみます。 その間、弊社側でも追加のテストを実施し、以下の結果を得ました。 まず、J-Linkを介してNFC Cockpit v9.0.0に付属する以下のファームウェアをプログラムしました。 BootLoader_And_Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.bin その後、NFC Cockpitを使用して以下のセカンダリファームウェアをアップデートしました。 Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin この手順により、以前発生していたエラーは発生せず、アップデートは正常に完了しました。 この結果に基づき、ブートローダーとセカンダリーファームウェアのバージョン間に互換性の依存関係が存在する可能性があると推測されます。 以下の点について説明していただけますか? 1.NFC Cockpitのバージョンを変更する場合、セカンダリファームウェアだけでなく、ブートローダーも互換性のあるバージョンにアップデートする必要がありますか? 2. NFC Cockpitを使用してブートローダーをアップデートする方法はありますか? それとも、ブートローダーをアップデートするには、J-Linkのような外部デバッガー/プログラマーが必要なのでしょうか? 3. 各NFCコックピットバージョンに付属するセカンダリファームウェアとブートローダーの互換性を説明するドキュメントはありますか? 例えば、どのバージョンのセカンダリファームウェアが同じブートローダーで使えるか知りたいです。 これらの疑問の背景には、私たちが解決したいと考えている別の問題も存在します。 私たちはNFC Cockpitではなく、COMポートを通じたシリアル通信を使って自社のアプリケーションからPNEV5190Bを制御しています。 NFC Cockpit v7.4.0に付属するセカンダリファームウェアを使用すると、アプリケーションはPNEV5190Bと正常に通信し制御できました。 しかし、NFC Cockpit v9.0.0に含まれるセカンダリファームウェアにアップデートした後、同じ通信方法で同じアプリケーションが通信エラーに遭遇します。 次の点についても説明していただけますか? 4. NFC Cockpit v7.4.0とv9.0.0に付属するセカンダリファームウェアの間で、初期化シーケンス、COM通信設定、通信プロトコル、コマンド仕様、または関連する動作に関して変更点はありますか? これらの変更を説明したリリースノートやドキュメントがあれば、ぜひ共有していただけるとありがたいです。
查看全文
PTP over SJA1110 您好, 我们正在调试通过 SJA1110 交换机连接的 PolarFire SoC GEM 上的 PTP。 我们观察到: 交换机接收到二层 PTP (ptp4l -2) 数据包(入口计数器增加),但未转发(出口计数器不增加)。 通过 UDP 的 PTP(ptp4l)通过同一桥接路径正确转发。 正常的以太网流量(ICMP/ARP)也能正确转发。 SJA1110 是否需要特殊处理或额外配置才能通过桥接端口转发第 2 层 PTP 帧(目标 MAC 01:1B:19:00:00:00)?对二层点对点传输协议(PTP)的转发是否存在任何已知的限制? 另外,PolarFire SoC GEM 是否完全支持并推荐使用 PTP over UDP (ptp4l),还是只支持/推荐使用 第 2 层 传输? 任何指导都将不胜感激。 Re: PTP over SJA1110 你好@Ankur_pixl , 在典型的 gPTP/时间感知桥接应用场景中,交换机无需将所有 gPTP 帧透明地转发为普通组播流量。通常的流程是,交换机从主控服务器接收 gPTP 帧,通过运行在内部 Cortex-M7 上的 gPTP 协议栈进行处理,然后生成带有相应时间戳的 gPTP 帧,发送给连接的下游设备。   SJA1110 通常配置为第 2 层汽车配置文件,其中 PTP 目标 MAC 地址为 01:80:C2:00:00:0E。此地址用于 802.1AS/gPTP 风格的第 2 层传输,此类帧通常由交换机的 PTP/gPTP 功能处理,而不是简单地作为常规组播流量进行桥接。   你观察到入口计数器增加,而出口计数器没有增加,这表明交换机接收到了第 2 层 PTP 帧,但没有通过正常的桥接路径转发。一个可能的解释是,所使用的 PTP 组播 MAC 地址与 SJA1110 配置相匹配,例如在通用参数表、DPI 配置、L2 查找表或其他与 PTP/trap 相关的配置项中,因此帧被捕获到主机端口,很可能是内部 Cortex-M7 主机,而不是转发到预期的外部出口端口。   这也解释了为什么 PTP over UDP 和 ICMP/ARP 等普通以太网流量能够正确转发。这些帧不符合相同的第 2 层 PTP/gPTP 分类规则,因此按普通桥梁交通处理。   请检查您的 SJA1110 配置中的以下几点:   1. 交换机中配置了哪个 PTP 目标 MAC 地址,尤其是在常规参数表中。 2. PTP/gPTP 帧是否配置为捕获到主机端口。 3. 内部 Cortex-M7 主机是否正在运行 gPTP 协议栈或接收捕获的 PTP 帧。 4. 使用的目标 MAC 地址是 01:1B:19:00:00:00 还是 01:80:C2:00:00:0E。 5. L2 查找表或组播转发配置中是否包含将此目标 MAC 转发到所需外部端口的条目。 6. 此流量的入口端口和出口端口是否在同一个 VLAN 和转发功能域中。   如果您打算将 SJA1110 用作 gPTP/时间感知桥接器,那么预期的配置通常不是简单地透明转发原始 gPTP 帧。交换机应参与 gPTP 时序域,并向连接的设备生成相应的 gPTP 消息。   如果您打算仅将 SJA1110 用作普通的以太网桥,用于原始的二层 PTP 帧,则必须禁用或避免此流量的 PTP 捕获/特殊处理,并且必须在二层转发配置中明确允许相应的组播目标 MAC 地址。   关于 PolarFire SoC GEM,我无法就该设备推荐或完全支持的 PTP 传输模式做出明确的声明。从 SJA1110 的角度来看,如果桥接路径允许,则 PTP over UDP 可以作为普通的 IP/UDP 流量转发。然而,这并不一定意味着 PolarFire GEM 驱动程序支持或推荐使用 UDP 传输进行硬件时间戳。请参考 PolarFire SoC GEM 文档或咨询 Microchip 支持部门,确认支持的 PTP 传输和时间戳模式。   顺祝商祺! 帕维尔 Re: PTP over SJA1110 你好, 目标 MAC 地址为 01:1B:19:00:00:00。我们正在使用带有 Linux DSA 桥接器的交换机,并且无法控制或配置 Cortex-M7 内核。 在 L2 配置中,我们如何允许此流量通过?我们使用了桥接 mdb,但它不起作用;条目已安装,甚至显示为已卸载,但帧仍然无法在端口之间转发。这是否需要在 Cortex-M7 内核上显式设置? 关于我们设置的其他信息: 我们的MAC地址/端口配置如下: bridge mdb add dev br-EPS port epc2-uplink grp 01:1b:19:00:00:00 permanent bridge mdb add dev br-EPS port t1-6 grp 01:1b:19:00:00:00 permanent 这些在 bridge -d mdb show 中显示为已卸载,但到达一个端口的 L2 PTP 帧不会从另一个端口转发出去。 重要的是,其中一个交换机端口没有可用的 CPU 端口;它纯粹作为两个端口之间的路由(端口到端口转发)运行,该路径上没有主机/CPU 端口。由于保留的多播 01:1b:19:00:00:00 默认似乎被捕获到管理/CPU 路由,而该路由在此处不可用,因此我们怀疑帧被丢弃而不是转发。 请问如何配置交换机,使其能够在两个用户端口之间通过硬件转发此保留的 PTP 组播 MAC 地址,而无需依赖 CPU/管理端口? ——安库尔 Re: PTP over SJA1110 你好@Ankur_pixl , 目标 MAC 地址 01:1B:19:00:00:00 是 IEEE 1588 二层 PTP 组播地址。这与 802.1AS / 汽车配置文件 gPTP 目标 MAC 地址 01:80:C2:00:00:0E 不同,后者通常用于 SJA1110 gPTP 汽车配置文件。   根据您的描述,这看起来不像是一个标准的 Linux 网桥 MDB 问题。MDB 条目可能已正确安装,甚至报告为已卸载,但帧仍然可能无法到达正常的组播转发路径。   一个可能的解释是,SJA1110 硬件或 SJA1110 DSA 驱动程序在应用正常的 L2 组播转发决策之前,将此目标 MAC 分类为 PTP/控制帧。在这种情况下,帧可能会被重定向到 CPU/管理路径,而不是直接在两个用户端口之间转发。   这可以解释观察到的现象:   - 入站计数器增加,表示交换机已接收到该帧。 MDB条目已安装并显示为已卸载, 但出口计数器不会增加,因为帧很可能在应用正常的端口到端口转发之前就被困在了 CPU/管理路由中。   如果 CPU/管理路由在端口到端口的转发路径中不可用,则捕获的帧可能会被有效地丢弃。   关于 Cortex-M7:如果您通过 Linux DSA 网桥使用交换机,并且您没有在内部 Cortex-M7 上运行或控制 gPTP 协议栈,那么这通常不应该是 Cortex-M7 应用程序配置的内容。在这种情况下,相关的配置由 Linux DSA 驱动程序和该驱动程序编程的交换机硬件配置所有。   但是,如果针对 01:1B:19:00:00:00 激活了专用的 PTP/控制帧陷阱规则,则“桥接 mdb”可能不够用。要通过硬件直接在两个用户端口之间转发此流量,交换机配置需要确保:   1. 针对此流量,01:1B:19:00:00:00 的 PTP/控制帧陷阱已被禁用或绕过,并且 2. 存在指向所需用户端口的 01:1B:19:00:00:00 的有效 L2 组播转发条目。   此时,如果 SJA1110 DSA 配置中存在激活的较低级别的 PTP/控制帧陷阱规则,我预计仅使用标准的 `bridge mdb` 命令无法覆盖该规则。   下一步,请检查您的 SJA1110 DSA 驱动程序或 BSP 是否启用 PTP 硬件时间戳,或者是否为 01:1B:19:00:00:00 安装任何 MAC 过滤器/PTP 陷阱规则。如果存在这样的规则,则解决方案可能需要驱动程序级别的更改或交换机静态配置更改,而不仅仅是运行时 Linux 网桥 MDB 命令。   请问您能否提供以下信息?   - Linux 电路板支持包。/内核版本, - SJA1110 DSA 驱动程序源基线, - “bridge -d mdb show”的完整输出, - 相关DSA端口名称和物理交换机端口号, - SJA1110 DSA 驱动程序中是否启用了 PTP 硬件时间戳功能, - 如果可能的话,在 DSA 主/CPU 接口上进行数据包捕获,以确认第 2 层 PTP 帧是否被捕获到 CPU 路径。   有了这些信息,我们可以进一步检查帧是否被 PTP/控制陷阱路径消耗,或者是否存在其他 L2 组播转发限制。 顺祝商祺! 帕维尔
查看全文
AB_SWAPアップデート失敗時のフォールバックメカニズム こんにちは、 私たちは、S32K342のHSEファームウェアのAB_SWAPメカニズムを利用してOTAアップデートを行うアプリケーションを開発しています。現在、フラッシュメモリのパッシブ領域への書き込みが完了した時点で、パッシブブロックをアクティブ化するように設定しています。 起動元イメージが破損していないか確認できるフォールバックの仕組みがあるのか、またリセット後にパッシブ領域になった「既知の有効」領域にフォールバックできるのか知りたいです。 これは、時にはリセットを出さずにパッシブ領域を上書きし、途中でプロセッサをリセットしてしまい、フラッシュの映像が破損してしまうことがあるためです。 Re: Fallback mechanism for failed AB_SWAP update やあ、 @lukaszadrapa 、 ご説明ありがとうございます。私たちはまだ、アプリケーションでどのタイプのセキュアブート戦略を使うべきかを理解しようとしています。高度なセキュアブートは、SMRとCRをインストールする必要があるため、少し複雑に思える。 一方、ベーシックセキュアブートはインストールがやや容易なようだが、具体的な実装方法やインストール手順は不明瞭なようだ。 これらの選択肢について何かアドバイスをいただけませんか?私はHSE Bリファレンス・マニュアルを指しており、これに関して参照すべき追加ドキュメントがあるかどうかも知りたいです。 よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update こんにちは、 @Shiv_peak さん。 数日前に非常によく似た質問に回答しましたので、そちらをご覧ください。 https://community.nxp.com/t5/S32K/S32K-OTA-Rollback/m-p/2400332/highlight/true#M60125 さらに詳しい情報が必要な場合は、遠慮なくお申し付けください。 よろしくお願いいたします。 ルーカス Re: Fallback mechanism for failed AB_SWAP update 下記の私のコメントをご覧ください。 イメージ検証が失敗した場合、基本セキュアブートはリカバリーモードに移行します。 はい。 このリカバリーモードは、属性HSE_SECURE_RECOVERY_CONFIG_ATTR_IDを使ってSecure Recoveryとして設定できます。 はい。 このモードを設定するには、UTESTモードをプログラミングする必要があります。 UTESTは、設定属性HSE_SECURE_RECOVERY_CONFIG_ATTR_IDサービスを呼び出す際にHSEによってプログラムされます。共通の問題は、フラッシュブロック0とUTESTが同じ読み取りパーティション内にあることに注意することです。この属性をプログラムする際、フラッシュブロック0からはコードが実行できません。 これを設定するには、IVTでBOOT_SEQ == 1にする必要もあります。 はい。 GMACを計算するには、ADKPをHSE_APP_DEBUG_KEY_ATTR_IDを使用して構成する必要があります。 はい。 この件について理解を深めるにあたり、いくつか補足させてください。 あなたが共有したアプリケーションノートには、ADKPの設定はCUST_DELライフサイクル内でしかできないと書かれていました。システムのライフサイクルをどのように確認すればよいのでしょうか?また、それは安全でしょうか? はい、ADKPが設定されるまでライフサイクルを進めることはできません。ライフサイクルが進んだらセキュアデバッグが有効になるので、接続を確立するためにデバッガの設定が必要です。この投稿をご覧ください: https://community.nxp.com/t5/S32K/S32K3-HSE/m-p/2066312/highlight/true#M47070 ライフサイクルの状態はDCMモジュールのレジスタDCMLCCから読み取ることができます。 AppBLは、Basic Secure BootにおけるIVTと同じものですか? AppBLとIVTは同じ方法で署名・検証されます。IVとGMACもIVTに付録されています。それは「表118」で見ることができます。 HSEファームウェアリファレンスマニュアルの「IVT構造」と記載されています。 IVTにGMACアドレスとリカバリイメージのアドレスを追加する必要がありますか? IVTを検証する場合は、前述のとおりIVとGMACをIVTに追加する必要があります。セキュアリカバリイメージを使用する場合は、イメージへのポインタとイメージの長さをIVTに追加する必要があります。 よろしくお願いいたします。 ルーカス Re: Fallback mechanism for failed AB_SWAP update ルカスさん、返信ありがとうございます。おかげでよく分かりました!Basic Secure Bootの実装を始め、ご質問やご不明点があればご連絡いたします。 よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update 「2.6.1.3」の項をご覧ください。HSEファームウェアのリファレンスマニュアルに記載されている「リカバリーモード」と記載されています。2.7. つまり、2つのモードがあります。 JTAGベースのリカバリーモードでは、デバイスはRAM上で無限ループにハングする(このコードはSBAFによってRAMにロードされます)。ユーザーがデバッガに接続していくつかのリカバリーステップを実行できます。 セキュアリカバリーモード - これは属性 HSE_SECURE_RECOVERY_CONFIG_ATTR_ID によって有効にする必要があります。これはUTESTメモリにプログラムされたOTP属性であることに注意してください。これによりリカバリイメージが起動しますが、まずこれを検証する必要があります。つまり、基本的なセキュアブートに似ています。検証に失敗した場合は、JTAGリカバリモードに移行します。 セキュアリカバリモードは実行時のリカバリーやロールバックに使用できます。しかし、パッシブパーティションからこれを実行することはお勧めしません。すべてのコードはアクティブパーティションから実行される必要があります。ABスワップモードでは、いずれにせよ両方のパーティションにセキュアリカバリイメージのコピーが存在します。 別の選択肢としては、十分な空き容量があれば、このコードをデータフラッシュメモリに保存する方法もあります。 Re: Fallback mechanism for failed AB_SWAP update 私たちはこのアプリケーションノートを提供します: https://www.nxp.com/webapp/Download?colCode=AN13465   Secure Bootアプリケーションノートの最新バージョンv0.1.1.0です(AN744511)2021年にリリースされ、以下からダウンロード可能です: https://www.nxp.com/products/S32K3 申請書はこちらでご覧いただけます: ドキュメント -> Secure Files -> Secure Boot アプリケーションノート v0.1.1.0(AN744511) 関連するデモプロジェクトはこちらからダウンロードできます: Design Resources - > ソフトウェア - > Secure Files - > SecureBootAppNoteDemo(SW745310) ソフトウェアは更新されていないので、 興味があれば前述SW745310を使ってください。 セキュアブートの他の例は、HSEデモ例(推奨)で見つけることができます: https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples 高度なセキュアブート、基本的なセキュアブート、およびSHEセキュアブートの3つのモードすべてについて例があります。 一般的に、高度なセキュアブートモードが推奨されます。はい、このモードでセキュアブートを設定するのは簡単な作業ではありません。しかし、最高の保護性能と設定の柔軟性を提供します。利点は、好きな署名方式を選べ、複数の地域をカバーでき、セキュアブートが失敗した場合に異なる制裁を設定できることです。 一方、基本的なセキュアブートモードは常にGMACタグのみを使用し、これはADKPから派生したキーで計算され、1つの地域のみをカバーできます。失敗した場合、デバイスは直接リカバリーモードに移行します。 HSE DemoExamplesに掲載されている以下のプロジェクトを学習することをお勧めします。 S32K344_アドバンストセキュアブート S32K344_ベーシックセキュアブート これらは、それらにリンクされたアプリケーションS32K344_SecureBootBlinkyを保護するための構成プロジェクトです。 よろしくお願いいたします。 ルーカス Re: Fallback mechanism for failed AB_SWAP update なるほど、これでよく分かりました。ありがとうございます! 私の理解では: イメージ検証が失敗した場合、基本セキュアブートはリカバリーモードに移行します。 このリカバリーモードは、属性HSE_SECURE_RECOVERY_CONFIG_ATTR_IDを使ってSecure Recoveryとして設定できます。 このモードを設定するには、UTESTモードをプログラミングする必要があります。 これを設定するには、IVTでBOOT_SEQ == 1にする必要もあります。 GMACを計算するには、ADKPをHSE_APP_DEBUG_KEY_ATTR_IDを使用して構成する必要があります。 この件について理解を深めるにあたり、いくつか補足させてください。 あなたが共有したアプリケーションノートには、ADKPの設定はCUST_DELライフサイクル内でしかできないと書かれていました。システムのライフサイクルをどのように確認すればよいのでしょうか?また、それは安全でしょうか? AppBLは、Basic Secure BootにおけるIVTと同じものですか? IVTにGMACアドレスとリカバリイメージのアドレスを追加する必要がありますか? 実装と基板上でのテストを開始する前に、これらの点についてもう少し明確な情報を得たいと思っています。ご連絡いただき、疑問を解消してくださり本当にありがとうございます! よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update ルーカスさん、分かりやすく説明してくれてありがとう。 I will look into the アプリケーションノート and the HSE demo examples and revert back in case of any queries. よろしくお願いいたします。 シヴ Re: Fallback mechanism for failed AB_SWAP update 基本的なセキュアブートが失敗した場合に「デバイスがリカバリーモードに入る」とはどういう意味か、もう少し詳しく教えてもらえますか?これはつまり、コアはリセットから解放されず、フォールバックやリカバリーも存在しないということですか? セキュアブートが失敗した場合に、別のイメージ(おそらくパッシブバンクにあるイメージ)を起動する機能を持たせたいので、この質問をしています。
查看全文
S32K3 快速备用唤醒失败 你好, 在一个快速备用示例项目中,我定义了一个数组 编曲 在 .standby_data 虽然代码中包含这个数组,但它在代码中并没有被使用。然而,如果我注释掉这个数组定义,设备就无法从快速待机状态唤醒;如果我保留它,唤醒功能就能正常工作。此外,我还注意到优化级别也会影响设备的行为: -O0 优化失败,唤醒失败,但正在更改为 -Os 这样就能解决问题。为什么在……中定义变量会起作用? .standby_data 该部分是否会影响唤醒功能?为什么优化级别会产生如此大的影响? Jason22_0-1785895168596.png S32K312 RTD400 S32DS BR, 杰森 Re: S32K3 fast standby wake up fail 嗨@Senlent 非常感谢您的回复。将地址更改为 0x20408000 后,之前失败的案例现在可以正常工作了。 顺便说一下,关于我的另一个帖子(S32K3 ADC Optimize DMA Streaming),我用公司邮箱注册的新账号(Jason07)回复了你——回复的时候我忘记切换账号了。 Re: S32K3 fast standby wake up fail 嗨@ Jason22 程序中是否注释掉“arr”数组会影响__BSS_SRAM_START的值,该值将用作快速唤醒后MSP的初始值。 如果这个值太小,可能会导致堆栈溢出。 在我们的示例项目中,我们建议将此值设置为 0x20408000,这是备用 RAM 的结束地址。
查看全文
S32K144のPWM周波数が周期的に変化する問題について。 現在、NXP S32K144 の開発を行っており、問題が発生しました。EB 構成ツールを使用して、FTM0 の 4 つの出力チャネルを構成し、コード内で `PWM_Init();setdutycycle(8129)` を呼び出しました。構成では、中央揃えモード、デッドタイムなし、他のチャネルとのバインディングなしを選択しました。周期は 0.00125 に設定され、各チャネルは独立モードとなり、結果として 250µs%的方波,这显然不对,我希望是25% のデューティサイクルが 20% になりました。そこで、デューティサイクルを `setdutycycle(16339)` に変更しましたが、結果として波形が正しくなくなりました。チャネルは、デューティサイクル 66% の 150µs の矩形波と、デューティサイクル 50% の 100µs の矩形波を交互に出力します。なぜこのようなことが起こるのでしょうか。これが実際の波形です。 実際、私には2つの問題があることは明らかです。1. なぜPWMデューティサイクルが正しく動作しないのか? 2. なぜPWMサイクルが常に変化するのか? Re: 关于S32k144的pwm频率会周期变化的问题 こんにちは S32K1用リアルタイムドライバのどのバージョンをテストしているのか、またはS32K1デバイス用AUTOSAR MCALのどの以前のバージョンをテストしているのか教えてください。 MPC5xxxおよびS32K1xxデバイスに対するMCALのサポートは終了いたしましたのでご注意ください。今後のサポートにはマーケティングチームの承認が必要となりますので、NXPの営業担当者までお問い合わせください。 よろしくお願いします、 ロビン Re: 关于S32k144的pwm频率会周期变化的问题 お使いのソフトウェアのバージョンがわからないのですが、読み込みポイントの設定に注意してください。以下の2つのディスカッションを参照してください。 FTM_PWMの周期とデューティサイクルを変更する S32K116のPWM出力の問題
查看全文