Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
IW611 RU 设置 我想请教一下如何设置RU。 对于射频测试,技术人员参照“UM11749”手册第12章进行RU设置测试。但是,当我们编辑配置文件“TF_Config_20MHz.txt”时按照第 12.6 章的示例加载后,输出波形类似于未调制信号,我们无法确认预期的波形。 由于输出的是波形,我们认为文件已正确加载。 配置文件描述如下。 =================================================================== FRAME_CTRL_TYPE=1 \\IEEE_TYPE_CONTROL FRAME_CTRL_SUBTYPE=2 \\TRIGGER 配置持续时间字段 最大持续时间 帧持续时间=5484 \\0x156C 配置触发帧的通用信息字段 HE_trigger_frame.TrigCommonField.TriggerType = BASIC_TRIGGER; \\ HE_trigger_frame.TrigCommonField.UlLen = 1000; \\ 最大限度 HE_trigger_frame.TrigCommonField.MoreTF = FALSE; HE_trigger_frame.TrigCommonField.CSRequired = FALSE; HE_trigger_frame.TrigCommonField.UlBw = TB_BW_20MHZ; HE_trigger_frame.TrigCommonField.LTFType = LTF_1_GI_1_6uS; HE_trigger_frame.TrigCommonField.LTFMode = MU_MIMO_SINGLE_STREAM; HE_trigger_frame.TrigCommonField.LTFSymbol = 0; HE_trigger_frame.TrigCommonField.UlSTBC = FALSE; HE_trigger_frame.TrigCommonField.LdpcESS = TRUE; HE_trigger_frame.TrigCommonField.ApTxPwr = 0 HE_trigger_frame.TrigCommonField.PreFecPadFct = 1; HE_trigger_frame.TrigCommonField.PeDisambig = 0; HE_trigger_frame.TrigCommonField.SpatialReuse = 65535; HE_trigger_frame.TrigCommonField.Doppler = FALSE; HE_trigger_frame.TrigCommonField.HeSig2 = 0x1FF; 保留 TrigCommonField=0;1000;0;0;0;1;0;0;0;1;0;1;0;65535;0;511 配置触发帧的用户信息字段 HE_trigger_frame.TrigUserInfoField.AID12 = (5 & 0xFFF); HE_trigger_frame.TrigUserInfoField.RUAllocReg = 0; HE_trigger_frame.TrigUserInfoField.RUAlloc = 61; 53 (106 音调) HE_trigger_frame.TrigUserInfoField.UlCodingType = CODING_TYPE_LDPC; HE_trigger_frame.TrigUserInfoField.UlMCS = 0; HE_trigger_frame.TrigUserInfoField.UlDCM = FALSE; HE_trigger_frame.TrigUserInfoField.SSAlloc = 0; HE_trigger_frame.TrigUserInfoField.UlTargetRSSI = 80; TrigUserInfoField=5;0;61;1;0;0;0;80 配置触发信号依赖用户信息字段 HE_trigger_frame.BasicTrigUserInfo.MPDU_MU_SF = MPDU_SPACING_MULT_1; \\ HE_trigger_frame.BasicTrigUserInfo.TID_AL = 0; HE_trigger_frame.BasicTrigUserInfo.AC_PL = FALSE; HE_trigger_frame.BasicTrigUserInfo.Pref_AC = TB_AC_VO; BasicTrigUserInfo=0;0;0;0 =================================================================== 如果此描述有任何错误,请告知我。 另外,如果还有其他方法(不使用文件的方法),请告诉我。 Re: IW611 RU setup 你好@SA2 能否提供测试日志和捕获到的频谱图? 顺祝商祺! 肖恩 Re: IW611 RU setup 你好,肖恩。 感谢你的回复。 我分享一下光谱图的截图。 captured spectrum.png Re: IW611 RU setup 你好@SA2 能否分享一下您在标准样机和待测设备 (DUT) 上执行的命令?包括实验室工具返回值 顺祝商祺! 肖恩 Re: IW611 RU setup 你好,肖恩。 在下达命令之前,我们想确认一些事情。 我们已经复习了第 12 章,但所有射频测试都必须使用传导测量进行。 (测试时,被测器件样品通过SMA电缆连接到频谱分析仪进行传导测量。) 因此,如果我们只使用一组被测器件进行传导测量,是否应该参考第 12.2 章? Re: IW611 RU setup 你好@SA2 建议采用标准测试方法进行测量。这样我们就可以轻松地与测试报告进行比较,并找出是否存在任何问题。 顺祝商祺! 肖恩
查看全文
How to Watch CCTV Overseas When You See "Unavailable in Your Region" Trying to watch CCTV or CCTV-5 from overseas but getting a message that says "This content is unavailable in your region"? You're not alone. Many overseas Chinese, international students, and travelers encounter regional restrictions when using CCTV apps or China Media Group (CMG) streaming platforms. The good news is that there are several ways to improve your access and continue watching your favorite programs. Why Does CCTV Show "Unavailable in Your Region"? CCTV broadcasts many TV channels, live events, sports competitions, news programs, documentaries, and variety shows. However, due to copyright agreements and broadcasting licenses, some content is available only to viewers connecting from mainland China. If you're accessing CCTV from another country, you may experience: "This content is unavailable in your region." Live channels that fail to load. Black screens or playback errors. Sports events that cannot be streamed. Buffering or unstable video quality. These issues are especially common when watching CCTV-5, major sporting events, and exclusive live broadcasts. How to Watch CCTV from Abroad If you're overseas, the following methods can help improve your viewing experience. 1. Use a China-Optimized Network A connection that routes your traffic through mainland China can help the platform recognize your network as a domestic connection, allowing access to more region-restricted content. Many overseas users choose SpeedX China accelerator because it provides optimized China routes with stable speeds for streaming live TV, sports, and on-demand programs. 2. Sign In to Your CCTV or CMG Account Logging into your account can synchronize your viewing history and preferences across different devices. 3. Update the App Regularly Keeping the CCTV or related streaming app up to date helps ensure better compatibility and reduces playback issues caused by outdated software. What Content Is Commonly Restricted? Depending on licensing policies, overseas viewers may have limited access to: CCTV-5 live sports Major football and basketball events TV dramas Variety shows Documentaries Special live broadcasts News content is often available globally, while entertainment and sports programming are more likely to be region-locked. Final Thoughts Regional restrictions can make it difficult to watch CCTV while living or traveling abroad. Fortunately, using a reliable China-optimized connection can greatly improve your ability to access live channels and on-demand content. Whether you're following breaking news, watching CCTV-5 sports, or enjoying Chinese TV programs, SpeedX(回国VPN工具) offers a stable solution for many overseas users looking for a smoother viewing experience. Student Project
查看全文
S32K344 SVD 文件错误 我从 S32DS 中调出了 S32K344 svd 文件(S32K344.svd),并尝试使用它,但文件的结构似乎存在数百个错误。 例如,在 MUXSEL 寄存器中(来自参考手册的第 62.8.10 节)在 SVD 文件中是这样定义的: lu_in LU_IN0 到 LU_IN11 < /description > 0x1 < /valu e > 但是所有枚举值 (LU_IN0 到 LU_IN11)的名称字段都是 " lu_in " 在将它们存储为枚举时会出现错误(多重定义符号 " lu_in ")。此外 - 列举甚至没有正确地涵盖空间。LU_IN 的值应该在 1 到 12 之间(0x1 到 0xC),而枚举值只到 0x9。 再比如,寄存器 MDACFG0 的 NMDAR 字段有一个枚举,除了被破坏之外,基本上没有任何作用。 NUMBER 寄存器数量 0x1 与 lu_in 示例类似,所有枚举都将"NUMBER" 作为每个枚举的名称。 寄存器 RRCR0 的字段 RR_INITMOD 与枚举 MOD_1_63 的问题基本相同,后者也只涵盖了部分可能的枚举值。 有没有人可以帮助我纠正这个问题?这些问题严重阻碍了我们使用 S32K3XX 芯片。 Re: S32K344 SVD File Bugs 你好@kscz、 遗憾的是,目前恩智浦官方还没有为 S32K3 提供 Rust 支持。 您可以创建一个小脚本,在将 SVD 输入到 svd2rust 之前删除/重命名重复内容。 顺祝商祺! 帕维尔 Re: S32K344 SVD File Bugs 我有点困惑--你说得没错,我是想用 Rust 处理这个芯片,但我在这里提出的问题是任何人使用这个 SVD 文件的根本问题--无论是用于 CMSIS 还是 Rust。 MUXSEL 和 RR_INITMOD 等枚举只涵盖了部分可能的值,这似乎是一个错误。在任何字段的所有枚举中,名称字段都是相同的,这似乎是一个错误。 我不是要求恩智浦明确支持 Rust,而是要求修复 SVD 文件! Re: S32K344 SVD File Bugs 你好@kscz、 我明白你的意思。我已将您的问题报告给软件团队。 谢谢你的报告。 顺祝商祺! 帕维尔 Re: S32K344 SVD File Bugs 我需要等多久才能得到更新? Re: S32K344 SVD File Bugs 你好@kscz、 我还没有收到开发团队的更新信息。我提高了优先级。 由于svd文件是RTD的一部分,我希望在下一个RTD版本中修复该问题。 顺祝商祺! 帕维尔 Re: S32K344 SVD File Bugs S32K388 SVD 文件还有很多很多其他错误——我需要把这些错误也记录下来吗?是否有计划像S32K344那样对这款产品进行更新? Re: S32K344 SVD File Bugs 你好@kscz、 感谢您报告此问题。我已将其转发给软件团队并提高了优先级。 顺祝商祺! 帕维尔
查看全文
如何在海外观看监控录像,即使看到“您所在地区无法观看”的提示? 想在海外观看中央电视台或中央电视台五台,却收到“您所在地区无法观看此内容” 的提示 ?您并非个例。许多海外华人、留学生和旅行者在使用中央电视台应用程序或中华媒体集团(CMG)流媒体平台时都会遇到地区限制。 好消息是,有几种方法可以改善您的访问体验,让您继续观看您喜爱的节目。 为什么监控录像显示“您所在地区无法观看”? 中央电视台播出众多电视频道、现场直播活动、体育赛事、新闻节目、纪录片和综艺节目。但是,由于版权协议和广播许可证的限制,部分内容仅供中国大陆观众观看。 如果您从其他国家/地区访问闭路电视监控系统,可能会遇到以下情况: “您所在的地区无法访问此内容。” 直播频道加载失败。 黑屏或播放错误。 无法进行直播的体育赛事。 视频缓冲或视频质量不稳定。 观看中央电视台5台、重大体育赛事和独家直播节目时,这些问题尤其常见。 如何从国外观看监控录像 如果您身在海外,以下方法可以帮助改善您的观看体验。 1. 使用针对中国市场优化的网络 通过中国大陆路由流量的连接可以帮助平台将您的网络识别为国内连接,从而允许您访问更多受地区限制的内容。 许多海外用户选择SpeedX 中国加速器,因为它提供优化的中国线路,速度稳定,可用于流畅观看直播电视、体育赛事和在线点播节目。 2. 登录您的闭路电视或 CMG 帐户 登录您的帐户即可在不同设备上同步您的观看历史记录和偏好设置。 3. 定期更新应用程序 保持监控录像或相关流媒体应用程序的更新有助于确保更好的兼容性,并减少因软件过时而导致的播放问题。 哪些内容通常会受到限制? 根据许可政策,海外观众可能无法观看以下内容: 中央电视台5台体育直播 重大足球和篮球赛事 电视剧 综艺节目 纪录片 特别现场直播 新闻内容通常面向全球,而娱乐和体育节目则更有可能受到地区限制。 总结与展望 地区限制可能会使在国外居住或旅行时难以观看监控录像。幸运的是,使用可靠的、针对中国网络优化的连接可以大大提高您访问直播频道和在线点播内容的能力。 无论您是关注突发新闻、观看中央电视台5台体育频道,还是欣赏中国电视节目, SpeedX(回国VPN工具)都能为众多寻求更流畅观看体验的海外用户提供稳定的解决方案。 学生项目
查看全文
S32K3 spi clk 异常低 我使用 S32K344 EVB 进行 SPI 测试。我使用 LPSPI1 单元作为主控端,引脚从 PTB14 到 PTB17,以及 RTD 4.0.0。P19.SPI 模式为 3:CPOL=1,CPHA=1 调用 Spi_SyncTransmit 后,我按照如下方式测量示波器,时钟引脚在帧真正传输之前变为低电平,这是什么原因造成的?如何解决这个问题? zyt_0-1785493991563.png Re: S32K3 spi clk abnormal low 嗨@zyt 这种行为通常是由 ERR050456 的第一个解决方法引起的,该解决方法会对 LPSPI 模块执行 RESET。这种情况已经在其他帖子中讨论过了,例如[MCU S32K312] 上 CS 线变低之前出现额外的 SPI 时钟脉冲。 正如该帖子中所解释的,可以采用另一种变通方法,预计可以消除低脉冲。要启用此变通方法,请在项目中定义以下宏: ERR_IPV_LPSPIV2_E050456_2ND_SOLUTION BR,VaneB
查看全文
i.MX8MP Heat Spreader Solution We are considering the following passive thermal solution for our i.MX 8M Plus–based infotainment application: Aluminum heat spreader: 20 × 20 × 1.5 mm (up to 30 × 30 × 2 mm) TIM: Henkel Bergquist Gap Filler TGF 2000 The aluminum plate will be used as a heat spreader on top of the i.MX 8M Plus. Would this solution be sufficient for a typical infotainment workload? If not, could you recommend the appropriate heat-spreader size or any additional thermal requirements? Re: i.MX8MP Heat Spreader Solution Hi @Wobaffet, Thank you for contacting NXP Support! For this purpose, I recommend reviewing the i.MX8MP Hardware Design Guide, specifically Chapter 7.8, "Heat Sink Considerations", which provides detailed information and design recommendations for thermal management and heat sink implementation on the i.MX8MP. This chapter covers the key requirements and considerations needed to ensure proper thermal performance and reliable operation of the device. Best regards, Chavira
查看全文
i.MX8MP ヒートスプレッダーソリューション 私たちは i.MX 8M Plusベースのインフォテインメント用途に、以下のパッシブサーマルソリューションを検討しています。 アルミ製ヒートスプレッダー:20×20×1.5mm(最大30×30×2mm) TIM:ヘンケル・ベルクヴィスト ギャップフィラー TGF 2000 アルミ板は、i.MX 8M Plusの上部に設置する放熱板として使用されます。 このソリューションは、一般的なインフォテインメントシステムのワークロードに対して十分でしょうか?もしなければ、適切なヒートスプレッダーのサイズや追加の熱要件を教えてもらえますか? Re: i.MX8MP Heat Spreader Solution こんにちは、@Wobaffet。 NXPサポートにご連絡いただきありがとうございます! この目的のために、 i.MX8MPハードウェアデザインガイド、 特に第7.8章「ヒートシンクの考慮事項」をよく確認することをお勧めします。そこにはi.MX8MPの熱マネジメントやヒートシンク実装に関する詳細な情報とデザイン推奨が載っています。 本章では、デバイスの適切な熱性能と信頼性の高い動作を確保するために必要な主要な要件と考慮事項について説明します。 よろしくお願いします、 チャビラ
查看全文
SE051C2: すべてのセキュアオブジェクト操作が 0x6985 を返す一方、GetRandom は同じ認証情報に対して動作します。 ## 問題点を一行で表すとこうなります **SE051C2では、アプレットのオブジェクトストアに触れるすべてのコマンドが返されます **0x6985(条件が満たされていません)** — 一方で「GetRandom」は*同じ*で成功します 会議、武装プラットフォームSCP03チャネルを通じても含まれます。 ## 私たちの質問 **Q1.この部分は「強制プラットフォームSCP」/制限付き/輸送状態ですか? どちらのサンプルも納品時の状態のままで、片方は工場から出荷されたばかりの新品です。もしSE051C2が オブジェクトストアはプラットフォームSCP03キーがNXPからローテーションされるまでロックされます デフォルトで、それなら以下のすべての観察を正確に説明できる。もしそうなら、 その州を離れるための文書化された手続きはありますか? **Q2.オブジェクト操作は顧客キー(回転)プラットフォームSCP03が必要ですか? デフォルトのプラットフォームキーは?**私たちのチャネルはデフォルトで認証しています。 明らかにトラフィックを運ぶが、その上のすべてのオブジェクトの指令は拒否される。 **Q3.もしQ1/Q2がイエスなら、まずどうやってUNIQUE_IDを読み取るのでしょうか?** これはまさに鶏と卵の関係であり、我々の行く手を阻むものだ。私たちのプラットフォーム鍵導出は次のようになります チップは入力としてUIDですが、「ReadObject(UNIQUE_ID)」自体は拒否されたものの一つです 命令。新品部品に対する作業手順の順序はどのようになっていますか? **Q4.アプレットを報告できるGET DATA / GET STATUSの通知はありますか? ライフサイクル/VCの状態は?**ステートレスコマンドは私たちにとっては*確かに*動作します、SOもしそのようなクエリが存在するなら 推測するのではなく、自分たちでパーツの状態を確認できます。 **Q5.この部分が通常のオブジェクト作成を拒否するのはなぜでしょうか?明らかに機能しているのに。 他の人にとってはどうでしょうか?DeleteAll/0x6985Thread(m-p/1648349)では、ステップ1は `Se05x_API_WriteUserID(...FACTORY_RESET...)`が**0x9000**を返し — WriteSecureObjectがプラットフォームSCP03のみでデフォルトセッションで成功しています。それは まさに、我々にとって失敗に終わる種類の指揮系統だ。つまりオブジェクト書き込みは本質的にそうではありません セッションゲート。違いはバリエーションや構成(SE051C2とSE050の違い)なのか、それとも プラットフォームキーはまだNXPのデフォルトですか? **Q6.m-p/1716555 は同じ根本原因ですか?そこで別のユーザーが報告しています 「Se05x_API_WriteUserID」が返す「SM_ERR_CONDITIONS_OF_USE_NOT_SATISFIED」――私たちとまったく同じ 症状――そしてその疑問は答えが出ていないようです。 **Q7.`kSE05x_ECCurve_NIST_P256` は明示的な `Se05x_API_CreateECCurve` を必要としますか? SE051C2 ですか、それとも内蔵されていますか?** (些細なことですが、試してみたところ、CreateECCurve でさえも 拒否した。) ## 測定対象 |チェック|結果|意味 | |---|---|---| |「Se05x_API_SELECT」アプレット |**0x9000** |IoT applet selected | |『Se05x_API_GetRandom』(単純) |実エントロピー |セッション+輸送作業| |プラットフォームSCP03認証 |**成功** |デフォルトのキーセットが一致 | |**ランダムに話せ、SCP03チャネル越し** |**成功、本物のエントロピー** |暗号化 + C-MAC + 復号検証済み | |連続して2回目のラップコマンド |**成功** |コマンドカウンターが同期を保つ | |「WriteECKey」NIST P-256(生成) |**0x6985** | |'WriteECKey' secp256k1 (import) |**0x6985** |「CreateCurve_secp256k1」は最初に呼ばれます | |『WriteECKey』 Ed25519(インポート) |**0x6985** |組み込みの曲線、CreateCurveは不要 | |『ReadObject(UNIQUE_ID)』 |**0x6985** |政策論争は関係ない | |「WriteBinary_Ver」(ファイルポリシー付き) |**0x6985** |ファイルオブジェクトも失敗する | |『CreateECCurve(NIST_P256)』 |**0x6985** |曲線を作ることさえ拒否されます | |「CheckObjectExists」 |**0x6985** |対象のテストすらできない | **「GetRandom」コマンドだけが動作します。**すべてのオブジェクトストア操作は以下を返します 0x6985 — 通常のサンプルと SCP03 で包装されたサンプルの両方で発生。 ## 実験により既に否定済み 1. **その部分ではありません。**新品のSE051C2も全く同じように動作する。 2. **交通費やセッション費用は含まれません。**SELECT は 0x9000 を返します。GetRandom は実数を返します。 同一セッションにおけるエントロピー。 3. **壊れたり欠落したりしたプラットフォームSCP03チャネルはない。**認証は成功しました デフォルトのキーセットと、決定的に「GetRandom」が発行された**武装された チャネル**は実エントロピーを返し、2回目の連続(コマンドカウンター)も同様です。同期)を組み合わせる。 暗号化+C-MAC+応答復号化のすべてが検証されました。失敗するオブジェクトコマンド 機能が証明されたチャネルで運ばれています。 4. **欠損キーポリシーではありません。**実際の `Se05xPolicy_t` を渡しました すべての `WriteECKey` に対して、(`ALLOW_SIGN|VERIFY|KA|READ|WRITE|GEN`、authID 0) を実行します。変更なし。 (そもそも読みUNIQUE_ID理由は説明できません — 「ReadObject」はポリシーを取らないからです。) 5. **曲線が欠落しているわけではありません。**`CreateCurve_secp256k1`はsecp256k1の前に呼び出されます。 インポート、Ed25519は組み込み、`Se05x_API_CreateECCurve(NIST_P256)`も** 0x6985を返します。 6. **命令のご注文ではない。**プレーンセッションでも、0x6985 認証済みのSCP03チャネル。 7. **ミドルウェア認証ビルド構成ではありません。**再構築 `SSS_HAVE_SE05X_AUTH_PLATFSCP03=1`、`SSS_HAVE_SE05X_AUTH_NONE=0`および `SSSFTR_SE05X_AuthSession=1`(以前はNONE/0でした)。変更なし。 ## 環境 * 部品番号: **SE051C2** — サンプル2個、うち1個は工場出荷時の新品、動作は同一 * ホスト: STM32L562、ベアメタル、TrustZoneセキュアワールド、I2C1 @ 100 kHz、T=1 * ミドルウェア: ベンダー提供の NXP Plug & Trust `Se05x_API_*` をカスタム 上で使用 `smCom_TransceiveRaw`トランスポート(独自のT=1フレーミング - SELECTとGetRandomが証明) それは動作します)。フルミドルウェアで、**ナノパッケージではありません**。 * プラットフォームSCP03:NXPのデフォルトキー;認証は成功し、トラフィックを運びます SE050 Re: SE051C2: all Secure Object operations return 0x6985 while GetRandom works over the same authenti こんにちは、 @winetime さん、 platformSCPを有効にせずに同じ手順を試してみましたか?SE051Cは デフォルトで必須プラットフォームSCPを必要としません。この問題に関するAPDUコマンドログを共有していただければ、さらに確認するかもしれません。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記: この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: SE051C2: all Secure Object operations return 0x6985 while GetRandom works over the same authenti こんにちは カン、 ありがとう のために の 素早い 返事。 はい — プラットフォームSCPなしでテストされたもので、それが私たちの通常のCASEです。 私たちのオブジェクト操作は実行 before se051_scp03_open() が呼ばれているため、すでにプレーンセッション上にあり、そこで失敗します。その後、SCP03プラットフォームを起動しても何の意味もありません — 同じように0x6985 どちら やり方も。 以下はAPDUログです。通常のセッション、SCP03なし(CLA=0x80、なし 0x04 セキュアメッセージングビット。応答は単純な 状態 言葉、 ない (包装済み)     TX (11): 80 04 00 27 06 41 04 20 00 F0 30 RX(2):69 85   それは CheckObjectExists (INS 04 MGMT、P2 27、TAG_1オブジェクトID 0x2000F030) — 読み取り専用存在テスト — CONDITIONS により拒否されました ない 満足。 オブジェクトストアコマンドを試行するたびに、どのオブジェクトIDでも、同じ0x6985が返されます。 CheckObjectExists、 WriteBinary_Ver (ファイルポリシー付き) WriteECKey (生成およびインポート; P-256、secp256k1 CreateCurve_secp256k1 まず、そしてEd25519) CreateECCurve(NIST_P256)、 ReadObject(UNIQUE_ID) 。 同じ平野会で、 仕事 大丈夫: 選択 IoTアプレットの→ 0x9000 ランダムを取得 → 実エントロピー SO、輸送手段とアプレットの選択は良好です。object-store commands are refusedのみです。 質問: 工場出荷時のSE051C2が拒否する原因は何でしょうか CheckObjectExists 通常のセッションで?我々は全く同じ行動を目にする の上 二 サンプル、 1つ ブランド 新しい そして 一度もない 書かれた に。 アプレットのライフサイクル/構成状態を報告するGET DATA(またはそれに類する)クエリはありますか?無状態の命令は 私たちのために機能し、 SO 私たちは CAN 走   逃げて  報告 戻せない。 セットアップ:SE051C2、STM32L562ベアメタルホスト、I2C 100kHz、自社のT=1フレーミング(SELECTとGetRandomが証明)、フルPlug & Trustミドルウェア Se05x_API_*, not nanoパッケージ。 Re: SE051C2: all Secure Object operations return 0x6985 while GetRandom works over the same authenti こんにちは、 @Kan_Li さん。この件はこれでクローズします。**それは我々の側であり、診断は間違っていた。 始める。**誰かの助けになればと思い、解決案を投稿します。   部品自体は問題ありません。ブートAPDUトレース全体を計測した際、 個々の結果では、クリーンな電源投入により 83 個の APDU が生成され、そのうち 80 個が 0x9000 — オブジェクトでした。 作成、secp256k1キー生成、 ` ReadObject` 、 ECDSA署名はすべて正常に動作しています。 0x9000以外の応答は無害であり、既に弊社独自のコードで処理済みです。   80 01 0B 04 CreateECCurve(secp256k1) -> 6985 曲線は既に存在します 80 01 61 00 WriteECKey -> 6A80 オブジェクトが存在します。タイプが間違っています。 80 04 00 27 CheckObjectExists -> 9000 80 04 00 28 DeleteSecureObject -> 9000 80 01 61 00 WriteECKey -> 9000 は削除後に成功します   **私が実際に見ていたもの。 ** SEはすでにウェッジ状態にあり、私の テストブートが開始され、以前のセッションによってそこに残されました。 0x6985 — ` GetRandom` 、 ` GetVersion` 、 ` GetFreeMemory`を含む—そして状態は MCUリセット、T=1インターフェースリセット、そして自身が0x9000を返す再「SELECT」です。ただ 電源を切ると解消されます。つまり、私が報告したすべての測定値はウェッジのものであって、 ブロックされた機能であり、私の「GetRandom」は唯一機能するコマンドであり、「GetVersion」は 「拒否された」という主張はどちらも、そのことの産物だった。騒音で申し訳ありません。   念のため申し添えておくと、正常なブーツの場合、この部分は以下のように報告します。   * ` GetVersion` → ` 07 02 00 3F FF FF FF` —アプレット** 7.2.0 ** 、 AppletConfig ` 0x3FFF` * ` GetFreeMemory(PERSISTENT) ` → ` 0x3E0C` = ** 15,884バイト**空き * プラットフォームSCP03は**OEF 0005A8FA (SE051C)**のデフォルトキーセットで認証します**   **それでもコメントする価値があるかもしれない点が1つあります** 。それは私が理解していない部分だからです。 理解しました。これは私たちにとって配送上の問題となります。   ウェッジ状態でもGPのセキュリティドメインコマンドは動作し続けます — 「80 50 00 00」 INITIALIZE UPDATEと` 84 82 33 00` EXTERNAL AUTHENTICATEはどちらも0x9000を返しますが、IoTは アプレットが全てを拒否します。その形状のアプレットエラー状態は文書化されていますか? 電源を切らずにそれを検出または消去する方法はありますか? 展開済みのデバイス セキュア素子を独立して電源サイクルできないため、ホストがアプレットを駆動できる場合 この状態に陥った場合、そこから抜け出す方法を知る必要がある。   先ほどは迅速なご対応ありがとうございました。
查看全文
IW611 RU setup I would like some advice on how to set up the RU. For the RF test, the technical staff is conducting the test by referring to Chapter 12 of the manual “UM11749” for RU setup. However, when we edited the configuration file “TF_Config_20MHz.txt” and loaded it based on the example in Chapter 12.6, the output waveform resembled an unmodulated signal, and we were unable to confirm the expected waveform. Since a waveform is being output, we believe the file was loaded correctly. The configuration file is described as follows. =================================================================== FRAME_CTRL_TYPE=1 \\IEEE_TYPE_CONTROL FRAME_CTRL_SUBTYPE=2 \\TRIGGER \\configure Duration field \\ Max Duration time FRAME_DURATION=5484 \\0x156C \\configure commoninfo field of trigger frame \\ HE_trigger_frame.TrigCommonField.TriggerType = BASIC_TRIGGER; \\ HE_trigger_frame.TrigCommonField.UlLen = 1000; \\ Max \\ HE_trigger_frame.TrigCommonField.MoreTF = FALSE; \\ HE_trigger_frame.TrigCommonField.CSRequired = FALSE; \\ HE_trigger_frame.TrigCommonField.UlBw = TB_BW_20MHZ; \\ HE_trigger_frame.TrigCommonField.LTFType = LTF_1_GI_1_6uS; \\ HE_trigger_frame.TrigCommonField.LTFMode = MU_MIMO_SINGLE_STREAM; \\ HE_trigger_frame.TrigCommonField.LTFSymbol = 0; \\ HE_trigger_frame.TrigCommonField.UlSTBC = FALSE; \\ HE_trigger_frame.TrigCommonField.LdpcESS = TRUE; \\ HE_trigger_frame.TrigCommonField.ApTxPwr = 0 \\ HE_trigger_frame.TrigCommonField.PreFecPadFct = 1; \\ HE_trigger_frame.TrigCommonField.PeDisambig = 0; \\ HE_trigger_frame.TrigCommonField.SpatialReuse = 65535; \\ HE_trigger_frame.TrigCommonField.Doppler = FALSE; \\ HE_trigger_frame.TrigCommonField.HeSig2 = 0x1FF; \\ reserved TrigCommonField=0;1000;0;0;0;1;0;0;0;1;0;1;0;65535;0;511 \\configure userinfo field of trigger frame \\ HE_trigger_frame.TrigUserInfoField.AID12 = (5 & 0xFFF); \\ HE_trigger_frame.TrigUserInfoField.RUAllocReg = 0; \\ HE_trigger_frame.TrigUserInfoField.RUAlloc = 61; \\ 53 (106 tones) \\ HE_trigger_frame.TrigUserInfoField.UlCodingType = CODING_TYPE_LDPC; \\ HE_trigger_frame.TrigUserInfoField.UlMCS = 0; \\ HE_trigger_frame.TrigUserInfoField.UlDCM = FALSE; \\ HE_trigger_frame.TrigUserInfoField.SSAlloc = 0; \\ HE_trigger_frame.TrigUserInfoField.UlTargetRSSI = 80; TrigUserInfoField=5;0;61;1;0;0;0;80 \\configure trigger dependent user info field \\ HE_trigger_frame.BasicTrigUserInfo.MPDU_MU_SF = MPDU_SPACING_MULT_1; \\ HE_trigger_frame.BasicTrigUserInfo.TID_AL = 0; \\ HE_trigger_frame.BasicTrigUserInfo.AC_PL = FALSE; \\ HE_trigger_frame.BasicTrigUserInfo.Pref_AC = TB_AC_VO; BasicTrigUserInfo=0;0;0;0 =================================================================== If there are any errors in this description, please let me know. Also, if there are any other methods (ones that do not use a file), please let me know. Re: IW611 RU setup Hello @SA2  Could you share test logs and captured spectrum? Best Regards Shaun Re: IW611 RU setup Hello, Shaun. Thank you for your reply. I’m sharing a screenshot of the spectrum. captured spectrum.png Re: IW611 RU setup Hello @SA2  Could you share cmd you issued on both golden unit and DUT? Including labtool return value Best Regards Shaun Re: IW611 RU setup Hello, Shaun. There is something we would like to confirm before providing the command. We have reviewed Chapter 12, but all RF tests must be performed using conducted measurements. (The test is performed with the DUT sample for conducted measurements connected to the spectrum analyzer via an SMA cable.) Therefore, if we are performing conducted measurements using only one set of DUTs, should we refer to Chapter 12.2 ? Re: IW611 RU setup Hello @SA2  It is recommend to use standard test methods to measure. So that we could easy compare with our test report and find out if there are any issue. Best Regards Shaun
查看全文
Kinetis(KW3x/4x、MCX W7x 和 MCX W23)汽车、工业物联网、CGM 和定位电源我的工具 本页面是 Kinetis (KW35/KW38/KW45/KW47) 和 MCX Wx (MCX W71/72) One 连接电源分析工具的专用页面(实验性)。 它将帮助您估算应用(汽车或工业物联网)中的功耗,并评估解决方案的电池寿命。 本页面包含一个专用的电源配置文件工具,名为“One 连接 Power 我的 Tool”,其中包括: 新增:基于仿真的独立组网 \(SA\)产品 KW43(汽车)和 MCX W70(工业物联网)。 KW3x/KW4x(汽车)和 MCX W7x(工业物联网)产品均为独立组网 (SA)。 MCX W23(工业物联网)产品独立组网 (SA)。 MCX W71 & W72 产品独立组网 (SA)(工业物联网)。 新增:基于仿真的独立组网 (SA)(工业物联网)MCX W70 产品。 BLE 802.15.4 物质与ZED id:NXP知识库 [开始日期:2026年7月31日]
查看全文
i.MX8MQ:启动 ROM 是否支持从 FlexSPI/QSPI NOR 闪存启动? 硬件: - i.MX8MQ(REV A0),基于 EVK 设计的定制板 - QSPI 或非:Micron MT25QL256A(32MB,3.3V,四路连接) - 电路板支持包。Yocto Scarthgap、NXP 电路板支持包。、U-启动 2024.04 (u-启动-imx) 目标:从 FlexSPI 或非闪存启动启动加载程序(SPL + ATF + U-Boot)。 内核和根文件系统仍然保留在 eMMC 上。 有效的方法: - U-启动(通过 uuu SDP/SDPV 加载到 RAM 中)运行正常 - “sf probe”正确检测到闪存:mt25ql256a,32 MiB - U-启动 可以可靠地读取和写入闪存(已通过 “sf protect unlock”之后的回读测试验证) - 镜像版本使用了 IMXBOOT_TARGETS = "flash_evk_flexspi" 闪存布局(已通过读取芯片数据验证): 0x000000:FCFB 标头 - “qspihdr 检查”报告 “在 Q(F)SPI 中找到启动配置头” 标签 = 42464346,版本 = 56010000 0x001000: IVT - d1 00 20 41,入口 = 0x007E1000, boot_data = 0x007E0FE0,self = 0x007E0FC0 0x060000:U-Boot 正确的 FIT(d00dfeed),匹配 CONFIG_SYS_SPI_U_BOOT_OFFS=0x60000 问题: 启动开关设置为 QSPI/FlexSPI 启动,并使用 USB 电缆 物理断开连接后,板无法启动。什么都没有 打印在串口控制台上(SPL 横幅从未出现),并且 ROM 回退到串行下载模式: uuu -lsusb 2:1 MX8MQ SDP:0x1FC9 0x012B NXP 闪存 BT_FUSE_SEL 未熔断;启动配置通过 GPIO 完成。 启动引脚。 我已经尝试过: - 两种标头格式:scripts/qspi_header(c0ffee01 标签)和 scripts/fspi_header(FCFB 标签)。修复了 soc.mak,使其 flash_evk_flexspi 使用偏移量为 0 的 fspi_header。 - 改变 FCFB 参数:sflashA1Size、serialClkFreq(50MHz -> 20MHz), dataSetupTime/dataHoldTime,sflashPadType - "uuu -b qspi"(官方内置脚本) - "qspihdr update safe" 和 "qspihdr init safe" - 完全擦除闪存与写入完整图像: 启动行为基本相同(SDP 出现于之后)。 (约 1.6 秒 vs 约 1.8 秒),这表明 ROM 可能没有被读取。 完全不开闪光灯。 问题: 1.i.MX8MQ 启动 ROM 是否支持从串行 或非 卡启动 是否支持通过 FlexSPI 进行闪存刷新?我拥有的参考手册部分 列出了与非闪存和 SD/MMC 作为引导设备,但我无法 找到列出的 FlexSPI/QSPI 或非。i.MX8MM/8MN 文档似乎 可以描述一下,但我不太确定 8MQ。 2. 如果支持,预期的闪存布局具体是什么? 当 FCFB 为真时,IVT 应该位于偏移量 0x400 还是 0x1000? 位于 0x0 处? 3. 应选择正确的 BOOT_MODE / BOOT_CFG 组合。 i.MX8MQ 上采用 FlexSPI 或非 启动? 4. 关于 REV A0 硅片,是否存在任何已知的勘误? FlexSPI 启动? 谢谢!
查看全文
Kinetis(KW3x/4x)オートモーティブ用パワープロファイルツール このページは、Kinetis(KW35/KW38/KW45/KW47)パワープロファイルツール用 オートモーティブに特化しています。 これにより、オートモーティブ アプリケーション(キーフォブ/スマートフォブ、アンカー)での消費電力を推定し、ソリューションのバッテリー寿命を評価するのに役立ちます。 このページには、以下の用途に特化した3つの電源プロファイルツールが含まれています。 KW35/36製品用のBluetooth LEをスタンドアロンで使用。 Bluetooth LEはKW37/38/39製品用のスタンドアロン対応です。 KW45/KW47製品用のBluetooth LEをスタンドアロンで使用。 スマートフォブアプリケーション(BLE/KW45;UWBレンジャー4位;SE;モーション・センサ) スマートフォブアプリケーション(BLE/KW47;UWBレンジャー5;SE;モーション・センサ)    1. KW35/36 Bluetooth LE 電力プロファイリングスタンドアロン:  christophe_menard_0-1785491668653.png 2. KW37/38/39 Bluetooth LE 電力プロファイリングスタンドアロン:  christophe_menard_1-1785491723947.png このツールには、AnchorとKeyfob/スマートフォンの消費電力を大まかに推定するための3つの異なるユースケースが含まれています。 1- CCCモバイル電話が車にコネクテッドされ、パケットを交換して車のドアを解除する 2- 車にコネクテッドされたパケットを継続的に交換するSCAキーフォブ 3- CCCスマートフォンが車にコネクテッドされ、パケットを継続的に交換する:2行モード 3. KW45/KW47 Bluetooth LE 電力プロファイリングスタンドアロン: AN13230 Kinetis KW45 Bluetooth LE 消費電力分析 AN14554 Kinetis KW47 Bluetooth LE パワープロファイル解析release.pdf 4. スマートフォブアプリケーション(BLE/KW45;UWBレンジャー4位;SE;モーション・センサ)パワープロファイリング 5. スマートフォブアプリケーション(BLE/KW47;UWBレンジャー5;SE;モーション・センサ)パワープロファイリング christophe_menard_2-1785493894936.png id:ワイヤレス・コネクティビティ [開始日: 2026年7月31日]
查看全文
Kinetis MCX Wxx (MCX W71/72 & MCX W23) Power Profile Tools for IIoT This page is dedicated to the Kinetis MCX Wx (MCX W71/72 & MCX W23) Power Profile Tools for IIoT. It will help you to estimate the power consumption in your application (Automotive, IIoT, Trackers/Tags and Continuous Glucose Monitoring [CGM]) and evaluate the battery life time of your solution. This page contains 4 dedicated power profile tools for: Bluetooth LE for the MCX W71/MCX W72 product in standalone. Bluetooth LE for the MCX W23 product in standalone. 802.15.4 Matter ICD SIT & LIT and ZED for the MCX W71 & W72 product in standalone. Aliro Doorlock application (BLE MCX W72/UWB/NFC/Motor) 1. MCX W71 / MCX W72 Bluetooth LE power profiling: AN14389 MCX W71 Bluetooth LE Power Consumption Analysis AN14739 MCX W72 Bluetooth LE Power profile analysis.pdf 2. MCX W23 Bluetooth LE power profiling AN14659: MCX W23 Bluetooth Low Energy Power Consumption Analysis | NXP Semiconductors 3. 802.15.4 Matter ICD SIT & LIT and ZED MCX W71/W72 Power profiling AN14841 MCX W72 802.15.4 Matter and Zigbee Power profile analysis.pdf 4. Doorlock application (BLE/UWB/NFC/Motor)
查看全文
CONFIG_FIT_CIPHER=y alone causes hab_status Hello Support, CONFIG_FIT_CIPHER=y alone causes hab_status to report HAB_INV_SIGNATURE/HAB_INV_ASSERTION on i.MX8M Plus EVK (OPEN mode) Board: i.MX8MP LPDDR4 EVK, OPEN/unfused (HAB Configuration: 0xf0, HAB State: 0x66) U-Boot: 2024.04 (lf_v2024.04_6.6.52_2.2.x), NXP fork HAB signing: working correctly otherwise — CST-signed imx-boot (SPL CSF + FIT CSF), custom build-time task that verifies the CSF tag byte at both embed offsets and fails the build on any mismatch (always passes) I have a clean baseline where hab_status reports "No HAB Events Found!" on this board with my normal HAB-signed imx-boot. I recently added kernel FIT image signing + AES-256 encryption (a separate mechanism from HAB — U-Boot's own bootm verifying/decrypting a signed kernel FIT, keys embedded in u-boot.dtb, unrelated to SRK fuses). After enabling this, hab_status started reporting 4 events every boot: HAB Configuration: 0xf0, HAB State: 0x66 HAB Event 1: STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HAB Event 2: STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HAB Event 3: STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY HAB Event 4: STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY I methodically bisected this with isolated rebuild+reflash tests, one variable at a time, confirmed on real hardware: 1. Baseline (existing HAB-signed imx-boot, no kernel-FIT work): 0 events 2. Full kernel-FIT feature enabled (FIT pubkey/AES-key DTB embedding + my own cmd/bootm.c patch + CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000): 4 events 3. Disabled FIT pubkey/AES-key DTB embedding alone: events still present, identical 4. Also removed my cmd/bootm.c patch: events still present, identical 5. Removed CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000 entirely (true pre-kernel-FIT baseline): 0 events, clean 6. Added back only CONFIG_SYS_BOOTM_LEN=0x8000000 (no CONFIG_FIT_CIPHER): 0 events, clean The issue is isolated precisely to CONFIG_FIT_CIPHER=y — nothing else (my bootm.c patch, FIT pubkey/AES-key DTB embedding, CONFIG_SYS_BOOTM_LEN) matters alone or combined; only CONFIG_FIT_CIPHER=y flips hab_status from 0 events to these 4. I double-checked that my own CSF computation is not the problem: my build-time signing task verifies the CSF tag byte at both embed offsets immediately after signing and fails the build on any mismatch — every build, with or without CONFIG_FIT_CIPHER, passes cleanly, and the computed SLD hab block address/FIT CSF offset are byte-identical across all test builds regardless of this config. My best guess is CAAM Job Ring contention — CONFIG_FIT_CIPHER pulls in CONFIG_AES (no separate backend symbol needed on this U-Boot version), and this SoC's runtime dmesg confirms CAAM is genuinely used for AES/SHA elsewhere. The closest relevant documentation I found is doc/imx/habv4/guides/mx8m_secure_boot.txt's note about HAB pre-v4.4.0 locking Job Ring/DECO master ID registers in closed config, but that doesn't directly describe this OPEN-mode, CONFIG_FIT_CIPHER-specific case. Questions: 1. Is this a known interaction between CONFIG_FIT_CIPHER and HABv4 CSF authentication on i.MX8M Plus? Is it CAAM-resource-related, or something else (e.g., compiled binary size/layout shifting a FIT CSF component boundary in a way my own self-check doesn't catch, since it verifies against the offset I computed, not what the ROM independently derives)? 2. Is CONFIG_FIT_CIPHER known-safe to combine with HABv4 CSF signing on this SoC at all, or is this a real limitation? 3. Are there any pointers to the correct CAAM Job Ring allocation/unlock sequence if that turns out to be the root cause? Yocto Project Re: CONFIG_FIT_CIPHER=y alone causes hab_status Posting this as solved in case it saves someone else the bisection — credit to [https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-EVK-HABv4-hab-status-shows-HAB-FAILURE-before-fuses-are/m-p/2344924/highlight/true#M244756] for the actual fix, which applied directly once I found it. Symptom: clean baseline (hab_status reports "No HAB Events Found!") with our normal HAB-signed imx-boot. After enabling CONFIG_FIT_CIPHER=y (to support U-Boot decrypting an AES-256-encrypted kernel FIT image — a separate mechanism from HAB, unrelated to SRK fuses), hab_status started reporting 4 events every boot: 2× HAB_INV_ASSERTION, 2× HAB_INV_SIGNATURE. Bisection: isolated every variable we'd changed, one at a time, rebuild+reflash+hab_status on real hardware each time — down to CONFIG_FIT_CIPHER=y alone (disabling FIT pubkey/AES-key DTB embedding, removing an unrelated cmd/bootm.c patch, keeping/dropping CONFIG_SYS_BOOTM_LEN — none of those mattered; only CONFIG_FIT_CIPHER did). Root cause + fix: we build imx-boot via a custom Yocto task porting the manual HAB-signing workflow (parse SPL IVT, compute FIT component blocks via print_fit_hab.sh, sign with CST) into an automatic build step. That task assumed the DTB copy left in the build staging dir by mkimage_imx8's own build was already correctly 16-byte-aligned — not guaranteed for every config. CONFIG_FIT_CIPHER changes U-Boot proper's compiled DTB size, landing it on a non-aligned size in our case. A misaligned DTB silently shifts every subsequent FIT component boundary print_fit_hab.sh computes,so CST signs the wrong byte range. Our own build-time self-check (CSF tag byte present at the offset we computed) still passed cleanly every time — it wasn't checking against the ROM's independently correct notion of the boundary. Only real hardware caught it. Fix, mirroring what worked in the other thread: explicitly run pad_image.sh (imx-mkimage's own script) on the DTB immediately before computing FIT component blocks, rather than trusting the staging directory's existing state. Confirmed genuinely padded (not a no-op), and hab_status is clean again with the full feature enabled.
查看全文
TDA8954TH 音声出力なし こんにちは! 低音が出ないスピーカー(Mackie Thump12など)をいくつか持っています。出力ICのTDA8954THと10Ωの抵抗器を交換しました。全く音がしない。このICで他に問題が発生している方はいらっしゃいますか? 私はAliExpressで異なる販売者から3つのICを注文しました。 よろしくお願いいたします。 ヨハネス Re: TDA8954TH no sound output こんにちは、ヨハネスさん。 このTDA8954THは旧製品であり、現在は生産中でなく、技術サポートも提供していません。もしかしたら、使っている他の方が助けてくれるかもしれません。   BRs、トーマス
查看全文
Kinetis MCX Wxx(MCX W71/72 和 MCX W23)工业物联网电源我的工具 本页面专用于 Kinetis MCX Wx(MCX W71/72 和 MCX W23)工业物联网电源我的工具。 它将帮助您估算应用(汽车、工业物联网、追踪器/标签和连续血糖监测 [CGM])中的功耗,并评估解决方案的电池寿命。 此页面包含 4 个专用的电源配置文件工具,分别用于: MCX W71/MCX W72 产品独立组网 \(SA\)蓝牙低功耗 (Bluetooth LE) 功能。 MCX W23 产品独立组网 (SA)的蓝牙低功耗 (Bluetooth LE)。 802.15.4 Matter ICD SIT & LIT 和 ZED 用于 MCX W71 & W72 产品的独立组网 \(SA\)。 Aliro 门锁应用(BLE MCX W72/UWB/NFC/电机) 1. MCX W71 / MCX W72 蓝牙低功耗功率配置文件: AN14389 MCX W71 蓝牙低功耗功耗分析 AN14739 MCX W72 蓝牙低功耗功率我的分析.pdf 2. MCX W23 蓝牙低功耗功率配置文件 AN14659:MCX W23 低功耗蓝牙功耗分析 | 恩智浦半导体 3. 802.15.4 Matter ICD SIT & LIT 和 ZED MCX W71/W72 功率分析 AN14841 MCX W72 802.15.4 物质和 Zigbee 功率我的分析.pdf 4.门锁应用(BLE/UWB/NFC/Motor)
查看全文
TDA8954TH no sound output Hello! I have several speakers (Mackie Thump12) with no bass output. I changed the output IC TDA8954TH and the 10R resistors. No sound at all. Does anybody else have problems with this IC? I ordered 3 ICs from different sellers on ALI Express. Best regards, Johannes Re: TDA8954TH no sound output Hello Johannes, The TDA8954TH is a legacy product that is no longer in production and we no longer provide technical support for this device. Perhaps someone else who uses it could help.   BRs, Tomas
查看全文
FreeMaster Over CAN on interrupt fail to compile in polling mode I try to change those 3 mico for enabling polling mode from code generated from  "FreeMaster over CAN" and "s32k3xx_fm_over_can_s32ct"  FMSTR_SHORT_INTR, FMSTR_POLL_DRIVEN, and FMSTR_DEBUG_TX but end with compiling failed, reason is that transfer feature freemaster over can from "s32k3xx_fm_over_can_s32ct"  reply on interrupt, but if motor control case using many irq like least 10khz fast task and bctu and hall , wagtch dog, freemaster received no response from controllewr k312, polling mode is necessary. how to enable those 3 micros and open polling mode for "s32k3xx_fm_over_can_s32ct"  Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Communication modes are mutually exclusive options. That's exactly what the error message means. FreeMASTER Driver routine may require a significative processing time and those 3 settings try to help developers to balance the execution depending on use case as follows: FMSTR_POLL_DRIVEN - FreeMASTER routine is executed entirely in the FMSTR_Poll function - developers decides when it is called but has to make sure that it is invoked at such frequency that allows FreeMASTER to keep up with the communication speed FMSTR_LONG_INTR - FreeMASTER routine is executed entirely in the FMSTR_CanIIsr function - deveopers forces the system to executed it by assigning a higher priority (I assume this one was used as it fits best in case of big number of interrupts) FMSTR_SHORT_INTR - is a mix of the previous two: the communication is happening in the interrupt handler (FMSTR_CanIsr), but the processing - in (FMSTR_Poll) I think what you want to try is the last one (combination of polling + interrupt). Still, while the interrupt may guarantee that the CAN frames will be read, the board may not reply on time if FMSTR_Poll is not invoked frequently enough (due to interrupts with higher priority). As a result - FreeMASTER desktop tool will show timeout errors. The developer has to make sure that the system can allocate sufficient time for FreeMASTER Driver routines in compute intensive applications. Hope it clarifies FreeMASTER's communication modes. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode I did try before using same setting as you: for example,  I changed FMSTR_POLL_DRIVEN as 1 (was 0.as interrupt mode) // Select interrupt or poll-driven serial communication #define FMSTR_LONG_INTR 1 // Complete message processing in interrupt #define FMSTR_SHORT_INTR 0 // Queuing done in interrupt #define FMSTR_POLL_DRIVEN 1/*0 */ 7 error: mainly because of #if (FMSTR_LONG_INTR && (FMSTR_SHORT_INTR || FMSTR_POLL_DRIVEN)) || \ (FMSTR_SHORT_INTR && (FMSTR_LONG_INTR || FMSTR_POLL_DRIVEN)) || \ (FMSTR_POLL_DRIVEN && (FMSTR_LONG_INTR || FMSTR_SHORT_INTR)) || \ !(FMSTR_POLL_DRIVEN || FMSTR_LONG_INTR || FMSTR_SHORT_INTR) /* mismatch in interrupt modes, only one can be selected */ #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN #endif  3 error happen above for compile ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ ../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN 326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN | ^~~~~ one is not enough, but two even all also failed. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, To enable Polling mode you need to update the following macros: #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 only one out of those 3 should be set to 1, overwise the code won't compile. Regarding FMSTR_DEBUG_TX - this is a debug macro that is meant to verify the TX line. Combined with previous definitions this one: #define FMSTR_DEBUG_TX 1 will instruct FreeMASTER Driver to continuously send a debug frame (note: this helps you inspecting the TX line and you won't be able to connect to the board using FreeMASTER tool while this functionality is enabled). Could you share your compilation error logs ? As far as I know, s32k3xx_fm_over_can_s32ct example is implemented by Model-Based Design Toolbox (MBDT) team. If you develop your application using Simulink, it may require updating block configuration instead of manual code changes. In this case, MBDT developers can provide better assistance for your use case through the dedicated MBDT community. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, I would try to troubleshoot the FMSTR_LONG_INTR mode, considering it is the only mode that works, even if only for a short time. The things I would look into are: Can you inspect the CAN bus with a logic analyzer and check whether the CAN messages are no longer being sent from the board, or if they are being sent but become corrupted? How many variables are you reading on the PC side? The number of variables is directly proportional to the amount of data exchanged between the PC tool and the board. If possible, I would start with a few variables and gradually increase the number to see when it breaks. Is the CAN instance used by any routines other than the FreeMASTER Driver? Did you start with a MATLAB/Simulink model or an S32 Design Studio example application? Depending on the original source, the FreeMASTER CAN driver implementation may differ. If possible, please attach the source files (they should be named freemaster_s32_flexcan.h and freemaster_s32_flexcan.c). Re: FreeMaster Over CAN on interrupt fail to compile in polling mode thanks for clarification, yes, combination of polling + interrupt is my target. restate issue: target k312 fail to send response after freeamster running a while. now feedback is following: interrupt mode: freemaster working, issue shown above, FMSTR_LONG_INTR only polling mode: compile,, freemaster not working ,  FMSTR_POLL_DRIVEN even if remove error message on freemaster_private.h:326:2: mixed: freemaster working, can compile  but traffic issue remain , all three of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN set as 1 and removing error message on freemaster_private.h:326:2: now I justify :Could be my CAN driver issue. which information do you need if your can provide further support? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1, I used peakcan view to monitor message flow, yes, CAN messages are no longer being sent from the board when freeamster smoothly working, message flashing very fast; when freeamaster freeze, CAN message sent from S32k312minEVB stopped apparently  but message read from freemaster still visible and slow; 2, totally less 20 variables, but amount is much smaller than demon fm project s32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct" 3.CAN instance solely used by freemaster; you are right,  our BSW use RTD ,to implement FM over CAN,  flexcan_43 and flexcan_ipw  layer from DEMON s32k3xx_fm_over_can_s32ct MCAL driver are integrated. but still working with issue above. by the way, due to CAN IP layer limit, our can driver can accept standard msg ID, so freeamster configue setting : send standard, receeive extension. please find atatched 4 files I have, which are close to you. do you need all CAN IP configure files? actually all 43/ipw configure same as demon s32k3xx_fm_over_can_s32ct. You can also directly email me. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode Hi @millerhughes, Unfortunately, I did not find any attachments on the this thread, but I got those files from MBDT and it indeed differs from the our team's implementation. Could you try replacing MBDT implementation with our version (see attachments - those correspond to freemaster_s32k3xx_can.c and freemaster_s32k3xx_can.h). One inconsistency I noticed is the CAN interrupt handler signature: FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); vs void FMSTR_CanIsr(void); Assuming CAN details (such as buffer IDs) are defined in freemaster_cfg.h we do not need them in the handler. We also use RTD (low hardware layer) and  your configuration should not change. Re: FreeMaster Over CAN on interrupt fail to compile in polling mode I fail to upload files request, how to upload files into this thread Re: FreeMaster Over CAN on interrupt fail to compile in polling mode except request help to find any function to reset CAN read buffer, I  also suspect one change made for MBD CAN driver code Can_43_FLEXCAN_Ipw.c where, function Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer are forced to memcpy to transfer when I integrate MBD MCAL CAN driver into RTD NON-MCAL driver. if no manual transfer, Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer fail to read all can information when using RTD NON-MCAL CAN driver. original MBD DEMON s32k3xx_fm_over_can_s32ct dont need manual transfer, because demon use MCAL CAN 43 driver. is any way to avoid manual trasnfer in function Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer() if it cause Freemaster issue? or manual reset buffer via some function you know? static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer ( const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig, const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig, uint8 u8MbIdx ) { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig->Can_u8ControllerID][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode feedback: thanks for supply rtd version freemaster driver code, I did replace MBD version function FMSTR_CanIsr(*,*,*..*) in mcal driver freemaster_s32k3xx_can  by FMSTR_CanIsr() in rtd driver  freemaster_can_flexcan. integration and run, Freemaster fail to connect with s32k312MINEVB. I start to debug when freemaster freeze when S32K312N=MINEVB fail to send out message, I found out sw in status of busy to read, which cause unfinished CAN read ,indirectly cause can sent delay unlimited; is any functions to manually clear buffer for read like reset if buffer are full?
查看全文
FreeMaster Over CAN on interrupt on 轮询模式 编译失败 我尝试修改“FreeMaster over CAN”和“s32k3xx_fm_over_can_s32ct”生成的代码,以启用轮询模式。 FMSTR_SHORT_INTR 、 FMSTR_POLL_DRIVEN和FMSTR_DEBUG_TX 但最终编译失败,原因是传输功能 freemaster 通过 can 从“s32k3xx_fm_over_can_s32ct”响应中断,但如果电机控制情况使用许多 irq,例如至少 10khz 的快速任务以及 bctu 和 hall、wagtch dog,freemaster 没有收到来自控制器 k312 的响应,因此需要轮询模式。 如何启用这 3 个微控制器并为“s32k3xx_fm_over_can_s32ct”打开轮询模式? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 沟通方式是互斥的选项。错误信息的意思正是如此。 FreeMASTER 驱动程序例程可能需要较长的处理时间,以下 3 个设置旨在帮助开发人员根据不同的使用场景平衡执行时间: FMSTR_POLL_DRIVEN - FreeMASTER 例程完全在 FMSTR_Poll 函数中执行 - 开发人员可以决定何时调用该例程,但必须确保其调用频率足以使 FreeMASTER 跟上通信速度。 FMSTR_LONG_INTR - FreeMASTER 例程完全在 FMSTR_CanIIsr 函数中执行 - 开发人员通过分配更高的优先级强制系统执行它(我假设之所以使用这个优先级,是因为它最适合处理大量中断的情况)。 FMSTR_SHORT_INTR 是前两者的混合体:通信发生在中断处理程序 (FMSTR_CanIsr) 中,但处理发生在 (FMSTR_Poll) 中。 我认为你想尝试的是最后一种方法(轮询+中断的组合)。虽然中断可以保证读取 CAN 帧,但如果 FMSTR_Poll 没有被足够频繁地调用(由于优先级更高的中断),则电路板可能无法及时响应。因此,FreeMASTER桌面工具将显示超时错误。 开发人员必须确保系统能够为计算密集型应用程序中的 FreeMASTER 驱动程序例程分配足够的时间。 希望这能帮助大家了解 FreeMASTER 的通信模式。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 我之前也尝试过使用和你一样的设置: 例如,我将FMSTR_POLL_DRIVEN 改为 1(之前为 0,表示中断模式)。 // 选择中断驱动或轮询驱动的串行通信 #define FMSTR_LONG_INTR 1 // 在中断中完成消息处理 #define FMSTR_SHORT_INTR 0 //中断中完成排队 #define FMSTR_POLL_DRIVEN 1 /*0 */ 7. 错误:主要原因是 #if (FMSTR_LONG_INTR && (FMSTR_SHORT_INTR || FMSTR_POLL_DRIVEN )) || \ (FMSTR_SHORT_INTR && (FMSTR_LONG_INTR || FMSTR_POLL_DRIVEN )) || \ ( FMSTR_POLL_DRIVEN && (FMSTR_LONG_INTR || FMSTR_SHORT_INTR)) || \ !( FMSTR_POLL_DRIVEN || FMSTR_LONG_INTR || FMSTR_SHORT_INTR) /* 中断模式不匹配,只能选择一种 */ #错误您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 #endif 上述编译过程中出现了 3 个错误。 ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ ../FMsrc/freemaster_private.h:326:2: 错误: #error 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 326 | #错误 您必须启用 FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 中的一个。 | ^~~~~ 一个不够,两个也都失败了。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes , 要启用轮询模式,您需要更新以下宏: #define FMSTR_LONG_INTR 0 #define FMSTR_SHORT_INTR 0 #define FMSTR_POLL_DRIVEN 1 这 3 个参数中只能有一个设置为 1,否则代码将无法编译。 关于FMSTR_DEBUG_TX - 这是一个用于验证 TX 线的调试宏。结合之前的定义,得出以下定义: #define FMSTR_DEBUG_TX 1 将指示 FreeMASTER 驱动程序持续发送调试帧(注意:这有助于您检查 TX 线,但启用此功能后,您将无法使用 FreeMASTER 工具连接到电路板)。 能否分享一下编译错误日志? 据我所知, s32k3xx_fm_over_can_s32ct 示例是由基于模型的设计工具箱 (MBDT)团队实现的。如果您使用 Simulink 开发应用程序,则可能需要更新模块配置,而不是手动修改代码。在这种情况下,MBDT 开发人员可以通过专用的 MBDT社区为您的用例提供更好的帮助。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes , 我会尝试排查FMSTR_LONG_INTR模式的问题,因为它是唯一有效的模式,即使只能维持很短的时间。我会调查以下几个方面: 您能否使用逻辑分析仪检查 CAN 总线,并确认 CAN 消息是否不再从电路板发送,或者是否正在发送但已损坏? 在PC端,你读取了多少个变量?变量的数量与PC工具和板之间交换的数据量成正比。如果可能的话,我会先从几个变量开始,然后逐渐增加变量的数量,看看什么时候会出问题。 除了 FreeMASTER 驱动程序之外,还有其他程序使用 CAN 实例吗? 您是从 MATLAB/Simulink 模型还是 S32 Design Studio 示例应用程序开始的?根据原始来源的不同,FreeMASTER CAN 驱动程序的实现方式可能会有所不同。 如果可以,请附上源文件(它们应该命名为freemaster_s32_flexcan.h和freemaster_s32_flexcan.c )。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 感谢你的澄清,是的,我的目标是轮询+中断相结合。 重述问题:目标 k312 在 FreeAmster 运行一段时间后无法发送响应。 以下是反馈意见: 中断模式:freemaster 工作正常,问题如上所述,仅限 FMSTR_LONG_INTR 轮询模式:编译,freemaster 无法工作,即使移除 freemaster_private.h:326:2 中的 FMSTR_POLL_DRIVEN 错误消息: 混合:freemaster 可以运行,可以编译,但流量问题仍然存在,FMSTR_LONG_INTR、FMSTR_SHORT_INTR 或 FMSTR_POLL_DRIVEN 这三个值都设置为 1,并移除 freemaster_private.h:326:2 处的错误消息: 现在我推断:可能是我的 CAN 驱动程序问题。 如果您可以提供进一步的支持,您需要哪些信息? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 1、我使用 PeakCan View 来监控消息流, 是的,板不再发送CAN消息了。 Freemaster 运行正常时,消息闪烁非常快;Freemaster 死机时,从 S32k312minEVB 发送的 CAN 消息明显停止,但从 Freemaster 读取的消息仍然可见且速度很慢; 2,总共少于 20 个变量,但数量远小于 demon fm 项目 s32k312_mc_pmsm_2sh_s32ct.pmpx "s32k344_mc_pmsm_2sh_s32ct" 3. CAN 实例仅供 freemaster 使用; 您说得对,我们的 BSW 使用 RTD 来实现 CAN 上的 FM,集成了 DEMON s32k3xx_fm_over_can_s32ct MCAL 驱动程序中的 flexcan_43 和 flexcan_ipw 层。但上述问题仍在解决中。 顺便说一下,由于 CAN IP 层限制,我们的 can 驱动程序可以接受标准消息 ID,所以 freeamster 配置设置:发送标准,接收扩展。 请查收附件中的 4 个文件,它们与您关系密切。 您需要所有 CAN IP 配置文件吗?实际上所有 43/ipw 配置都与 demon s32k3xx_fm_over_can_s32ct 相同。 您也可以直接给我发邮件。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 嗨@millerhughes , 很遗憾,我没有在这个帖子里找到任何附件,但我从 MBDT 获取了这些文件,它确实与我们团队的实现方式不同。 您能否尝试将 MBDT 实现替换为我们的版本(请参阅附件 - 这些文件对应于freemaster_s32k3xx_can.c和freemaster_s32k3xx_can.h )? 我注意到的一个不一致之处在于 CAN 中断处理程序的签名: FMSTR_BOOL FMSTR_CanIsr(FMSTR_U16 RxObjectId, FMSTR_U32 RxCanId, FMSTR_U32 RxMsgLength, const FMSTR_U8 * RxMsgData, FMSTR_U16 TxMsgBufId); 对比 void FMSTR_CanIsr(void); 假设 CAN 详细信息(例如缓冲区 ID)已在freemaster_cfg.h中定义我们不需要在处理程序中使用它们。我们也使用 RTD(底层硬件层),您的配置不应更改。 Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 我上传文件请求失败,请问如何将文件上传到这个帖子? Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 除了请求帮助查找重置 CAN 读取缓冲区的任何功能之外, 我还怀疑MBD CAN驱动程序代码Can_43_FLEXCAN_Ipw.c中做了一处修改。 其中,函数 当我将 MBD MCAL CAN 驱动程序形容功能时作“内置”,形容器件时作“集成”到 RTD NON-MCAL 驱动程序中时,Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer 被强制使用 memcpy 进行传输。 如果没有手动传输,使用 RTD NON-MCAL CAN 驱动程序时,Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer 将无法读取所有 CAN 信息。 原版 MBD DEMON s32k3xx_fm_over_can_s32ct 不需要手动传输,因为 demon 使用的是 MCAL CAN 43 驱动程序。 如果手动传输会导致 Freemaster 问题,有没有办法避免在函数 Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer() 中进行手动传输? 或者通过你知道的某个功能手动RESET缓冲区? static void Can_43_FLEXCAN_Ipw_ProcessRxMesgBuffer ( const Can_43_FLEXCAN_ControllerConfigType * Can_pControllerConfig, const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObjectConfig, uint8 u8MbIdx ) { Can_HwHandleType u8HwObjectID = 0U; Can_HwType CanIf_Mailbox; PduInfoType CanIf_PduInfo; const Can_43_FLEXCAN_HwObjectConfigType * Can_pHwObject = NULL_PTR; Flexcan_Ip_MsgBuffType * pReceivedDataBuffer = NULL_PTR; /**/ memcpy(&Can_Ipw_xStatus0,&FlexCAN_State0,sizeof(FlexCAN_State0)); /**/ u8HwObjectID = Can_Ipw_au16MbIdxToObjIDMap[Can_pControllerConfig-> Can_u8ControllerID ][u8MbIdx]; Re: FreeMaster Over CAN on interrupt fail to compile in polling mode 反馈:感谢您提供RTD版本的FreeMaster驱动程序代码, 我用 rtd 驱动程序 freemaster_can_flexcan 中的 FMSTR_CanIsr() 替换了 mcal 驱动程序 freemaster_s32k3xx_can 中的 MBD 版本函数 FMSTR_CanIsr(*,*,*..*)。 集成和运行,Freemaster 无法连接到 s32k312MINEVB。 当 S32K312N=MINEVB 无法发送消息时,freemaster 冻结,我开始调试,发现软件处于忙于读取状态,导致 CAN 读取未完成,间接导致 CAN 发送延迟无限长; 是否有类似缓冲区满时RESET读取操作的手动清除缓冲区的功能?
查看全文
CONFIG_FIT_CIPHER=y のみで hab_status が発生します サポートの皆さん、こんにちは。 CONFIG_FIT_CIPHER=yのみを設定すると、i.MX8M Plus EVK (OPENモード) でhab_statusがHAB_INV_SIGNATURE/HAB_INV_ASSERTIONを報告する。 ボード:i.MX8MP LPDDR4 EVK、オープン/非フューズ(HAB構成:0xf0、HAB状態:0x66) U-Boot: 2024.04 (lf_v2024.04_6.6.52_2.2.x), NXP fork HAB署名:それ以外は正しく動作する — CST署名imx-boot(SPL CSF + FIT CSF)、両方の埋め込みオフセットでCSFタグバイトを検証し、不一致があればビルド失敗(必ず合格)するカスタムビルドタイムタスク 通常のHAB署名済みimx-bootでhab_status「HABイベント情報 Found!」と報告するというクリーンなベースラインがあります。最近、カーネルFITイメージ署名+AES-256暗号化を追加しました(HABとは別の仕組みで、U-Boot独自のbootmが署名済みカーネルFITの検証・復号を行い、鍵はu-boot.dtbに埋め込まれています)。SRKヒューズとは無関係です。これを有効にした後、hab_status毎回の起動で4つのイベント情報を報告し始めました: HAB 構成:0xf0、HAB 状態:0x66 HABイベント情報1:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HABイベント情報2:STS=HAB_FAILURE RSN=HAB_INV_ASSERTION(0x0C) CTX=HAB_CTX_ASSERT(0xA0) ENG=HAB_ENG_ANY HABイベント情報3:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY HABイベント情報4:STS=HAB_FAILURE RSN=HAB_INV_SIGNATURE(0x18) CTX=HAB_CTX_COMMAND(0xC0) ENG=HAB_ENG_ANY 私は、実際のハードウェアで確認しながら、一度に1つの変数ずつ、独立した再構築+再フラッシュテストを実施して、この問題を体系的に二分しました。 1. ベースライン(既存のHAB署名imx-boot、カーネルFIT作業なし):イベント情報0 2. 完全なカーネルFIT機能を有効にし(FIT pubkey/AESキーDTB埋め込み+私自身のcmd/bootm.cパッチ + CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000):4つのイベント情報 3. FIT pubkey/AESキーDTB埋め込みのみ無効化:イベント情報が依然存在し、同一 4. また、私のコマンド/bootm.cも削除しましたパッチ:イベント情報は依然として存在し、同一です 5. CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000を完全に除去(真のプレカーネルFITベースライン):イベント情報0、クリーン 6. 復活は CONFIG_SYS_BOOTM_LEN=0x8000000(CONFIG_FIT_CIPHERなし):0イベント情報、クリーン 問題は正確には CONFIG_FIT_CIPHER=y に限定されており、他の要因は関係ありません (私の bootm.c)パッチ、FIT pubkey/AESキーのDTB埋め込み、CONFIG_SYS_BOOTM_LEN)単独または組み合わせでマター;CONFIG_FIT_CIPHER=yだけが0イベント情報からこの4 hab_statusに切り替わります。 私自身の CSF 計算に問題がないことを二重に確認しました。私のビルド時の署名タスクは、署名直後に両方の埋め込みオフセットの CSF タグバイトを検証し、不一致があればビルドを失敗させます。CONFIG_FIT_CIPHER の有無にかかわらず、すべてのビルドは正常にパスし、この構成に関係なく、計算された SLD hab ブロック アドレス/FIT CSF オフセットはすべてのテストビルドでバイト単位で同一です。 私の推測ではCAAMジョブリングの競合が原因です。CONFIG_FIT_CIPHER CONFIG_AESを引く(このU-Bootバージョンでは別のバックエンドシンボルは不要です)、このSoCのランタイムDMESGはCAAMが他のAES/SHAで実際に使われていることを確認しています。私が見つけた最も関連性の高いドキュメントは、doc/imx/habv4/guides/mx8m_secure_boot.txtですv4.4.0以前のHABがクローズド設定でジョブリング/DECOマスターIDレジスタをロックする点に注意が必要ですが、これはこのオープンモードのCONFIG_FIT_CIPHER特有のケースを直接説明しているわけではありません。 質問: 1.i.MX8M Plus上のCONFIG_FIT_CIPHERとHABv4のCSF認証の間に既知のやり取りがあるのでしょうか?これはCAAMリソースに関連する問題でしょうか、それとも別の問題でしょうか(例えば、コンパイルされたバイナリのサイズやレイアウトによってFIT CSFコンポーネントの境界がずれてしまい、私の自己チェックでは検出できないようなずれが生じているなど。自己チェックはROMが独自に導出したオフセットではなく、私が計算したオフセットに対して検証を行うため)。 2. このSoC上では、CONFIG_FIT_CIPHERをHABv4 CSF署名と組み合わせても安全性が確認できるのでしょうか、それともこれは実際の制限事項なのでしょうか? 3. もしそれが根本原因だった場合、正しいCAAMジョブリングの割り当て/ロック解除手順を示すヒントはありますか? Yocto Project Re: CONFIG_FIT_CIPHER=y alone causes hab_status 解決済みとして投稿します。誰かが二分を省く助けになるCASEからです。実際の修正は[https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-EVK-HABv4-hab-status-shows-HAB-FAILURE-before-fuses-are/m-p/2344924/highlight/true#M244756]に感謝します。私が見つけた直後に直接適用されました。 症状:通常のHAB署名済みimxブートで、hab_status "HABイベント情報なし!"と報告するベースラインはクリーンです。CONFIG_FIT_CIPHER=yを有効にして(AES-256で暗号化されたカーネルFITイメージをU-Bootで復号するU-Bootをサポートするためで、HABとは別の仕組みでSRKヒューズとは無関係)、hab_statusは毎回のブートで4つのイベント情報(2× HAB_INV_ASSERTION、2× HAB_INV_SIGNATURE)を報告し始めました。 二分割:変更した変数を一つずつ分離し、実際のハードウェアで毎回リビルド+リフラッシュ+hab_statusを行いCONFIG_FIT_CIPHERました。(FIT pubkey/AESキーのDTB埋め込みを無効にし、無関係なcmd/bootm.cを削除)まで変更しましたパッチや保持・落CONFIG_SYS_BOOTM_LEN――どれもマターではありませんでした。CONFIG_FIT_CIPHERだけがそうした)。 根本原因+修正:手動HAB署名ワークフローを移植したカスタムYoctoタスクでimx-bootを構築しました(SPL IVTを解析し、print_fit_hab.shでFITコンポーネントブロックを計算します。CSTで署名して自動ビルドステップに組み込む。そのタスクは、mkimage_imx8 自身のビルドによってビルドステージング ディレクトリに残された DTB コピーが既に正しく 16 バイト境界にアラインされていることを前提としていましたが、すべての構成で保証されているわけではありません。CONFIG_FIT_CIPHER U-Boot本体のコンパイルされたDTBサイズを変更し、私たちの場合は非アラインサイズに設定します。ずれたDTBは計算print_fit_hab.shすべてのFITコンポーネント境界を静かにシフトするため、CSTは誤ったバイト範囲に符号化します。我々が独自に構築時に行う自己チェック(計算したオフセットにCSFタグバイトが存在するかどうかの確認)は毎回問題なく合格していた。これはROMが独自に正しく定義する境界値と照合していたわけではなかった。本物のハードウェアだけがそれを捉えた。 修正:他のThreadでうまくいったことをミラーリングします。つまり、FITコンポーネントブロックを計算する直前にDTB上で明示的にpad_image.sh(imx-mkimage独自のスクリプト)を実行し、ステージングディレクトリの既存状態を信頼するのではなく、実際にパディングされていたこと(何もしない操作ではなかったこと)が確認され、hab_statusは再びクリーンな状態になり、フル機能が有効になりました。
查看全文