Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
UWB Single beacon + AoA for doorway inside/outside detection advice I'm building a wall-mounted single-anchor UWB system (doorway exit-detection use case) that needs to determine whether a tag is inside or outside a doorway using AoA — including doors that are already open, so I can't gate on a door contact sensor. Background: I was running Qorvo QM33120W/DW3000 (2-antenna PDoA) and hit a hard architectural wall; with the anchor mounted ~7ft up facing straight down, walking/circling under it produces false "outside" angle commits even on clean, strong signal. My plan was to have the UWB antennas face directly down toward the ground so that I can capture both positive and negative angles (inside and outside) signals to determine when a tag moves from inside to outside (exit detection). Currently with the Qorvo devices, if I hold the tag in the optimal straight forward/antenna on top, everything is fine but when moving/rotating the tag (DW3000), I start seeing different AoA values even when standing in the same place. Sign convention issue: My expectation is a consistent convention — positive angle while inside, negative once the tag crosses to outside. In practice, while unambiguously still inside, I'm seeing both positive and negative angles, correlated with the tag being rotated and moved in random directions/speeds — not with actual crossing of the doorway. This is the specific symptom I'm trying to design around before committing to new hardware. I'm now evaluating a move to NXP silicon and would appreciate community input: Qorvo 2D AoA boards use an RF switch to capture the UWB PDoA between the two antennas. Will switching to the NXP SR150 dual rx chain solve my AoA jumping issues? For a single overhead-mounted anchor with a tag moving through a doorway below it, is SR150's 2D/software-assisted-3-antenna-3D AoA mode sufficient to resolve front/back ambiguity, or does this really need SR250's 3 simultaneous RX chains for a true second baseline? Any recommended antenna geometry/mounting orientation for this specific top-down overhead use case? Any real-world experience with SR150's antenna-switched 3rd-antenna mode vs. SR250 in ambiguity-prone geometries like this? Thanks. kamaln16_0-1785454764324.png Re: UWB Single beacon + AoA for doorway inside/outside detection advice Hello, Hope you are doing well. For a single overhead-mounted anchor doing inside/outside doorway detection with a freely rotating tag, the Trimension SR250 is the right platform and is our recommended UWB product for IoT and Industrial anchor designs. The core reason for this recommendation is hardware architecture. The SR250 integrates 3 simultaneous RX paths for one-shot 3D AoA with no external RF switches required, delivering both azimuth and elevation from a single ranging frame. The SR250 also brings additional capabilities that are valuable for this use case: 360° AoA support with antenna diversity up to 9 antennas On-chip UWB radar (OCPD) for presence detection, a useful complementary layer alongside ranging-based crossing detection FiRa 4.0 and Aliro 1.0 ready, ensuring interoperability with the broader UWB ecosystem Where to Start Dev kit: SR250 Development Board, Arduino-compatible, integrated PCB antennas, plug-and-play demos for ranging, AoA, and radar out of the box Software: SR250 UWBIOT for Zephyr OS Partner modules & kits: TrueSense (ETNA TS 250 DevKit), MobileKnowledge (MK UWB Kit Mobile edition 2.0), Amotech (SR250 Integrated 3D Antenna Module), all available via the NXP Partner Marketplace Hope this helps. Best Regards, Ricardo Re: UWB Single beacon + AoA for doorway inside/outside detection advice Thanks Ricardo, appreciate the detailed response. Update: I've ordered both the Murata Type2BP (SR150) dev board and the NXP SR250UWBSHIELD dev board. Unfortunately, the SR250UWBSHIELD is showing a 14-week backorder on my end, so I'll be starting bench work on SR150 in the meantime and moving to SR250 once it arrives. A few follow-ups while I wait: 1. SR150 vs. SR250 for my specific application: given that I only need azimuth (inside/outside), not elevation, what benefit would I actually see moving from SR150 to SR250 beyond the architecture difference (true 3 simultaneous RX chains vs. SR150's 2 native chains + switched 3rd antenna)? Is the accuracy/stability improvement meaningful enough for a single-axis use case to justify the wait, or would SR150 likely get me there on its own once I have my mounting/multipath mitigations in place? 2. RF switching and tag rotation: one specific symptom I'm trying to root-cause, on the Qorvo hardware, if I stand in exactly the same spot and just rotate the tag on the X plane (no position change at all), the AoA value jumps around noticeably even appearing to flip polarity. Qorvo's 2D AoA uses an RF switch to time-multiplex the two antennas rather than sampling them simultaneously. Do you think that switching architecture is a likely contributor to this rotation-correlated instability, or is this more consistent with something else (tag radiation pattern/polarization sensitivity as it rotates, multipath, etc.)? Trying to understand whether SR150/SR250's simultaneous RX sampling would be expected to resolve this specific symptom or if it's a separate issue I'd need to address regardless of chip. 3. 2D vs. 3D AoA for my use case: since I only need to know inside vs. outside (azimuth), and elevation isn't meaningful for my application, is there any accuracy or reliability benefit to running full 3D AoA anyway, or would I be better off configuring azimuth-only and ignoring elevation? Specifically wondering if the elevation measurement helps discriminate reflected/NLoS signals from valid ones even if I don't use elevation for the actual inside/outside decision. 4. Power draw, 2D vs. 3D: this will be a battery-powered install. Is there a meaningful current draw difference between running 2D-only vs. full 3D AoA on SR250, given it's 3 simultaneous RX chains either way? Or is the power cost basically fixed once all 3 chains are active regardless of which axes I use in software? 5. Multipath mitigation for my specific install: the beacon will be wall-mounted above a doorway with a nearby glass door and a ceiling roughly 5ft above the unit. I've been seeing what looks like reflection-driven angle instability on my current Qorvo hardware (correlates with tag rotation, worse in higher-ceiling rooms, worse with the glass door closed). Any recommended mounting practices, antenna beamwidth/pattern choices, or firmware-side filtering (FOM/NLoS thresholds) specifically for suppressing near-field reflections off glass and adjacent walls? Or are there any features on either the NXP SR150 or SR250 that would suppress this issue? 6. Radar-based motion gating for battery savings: I'd like to use SR250's on-chip radar (OCPD) purely as a low-power wake trigger: stay in radar mode, only spin up full ranging/AoA once motion is detected. With the anchor mounted above a ~2m-high doorway, antennas facing straight down, roughly what motion detection range/coverage should I expect directly below the unit? Trying to size the radar's effective "wake zone" against the doorway footprint. I would want to detect movement as the person is walking toward and away from the doorway. Thanks again for the help.
記事全体を表示
EZH-VのユースケースIMXRT700 こんにちは、NXPチームの皆さん! IMXRT700の仕様から、プレスリリース、製品ニュース、コンピュート、センスの3ドメインに分類されており、チップ上の各コアが動作するためにそれぞれ独立したイメージを必要とするとされていました。しかし、EZH-Vコアの使用例に関する文書は非常に少ないようです。 アプリケーションノートAN14614、AN14618、AN14654は読みましたが、このコアやRT700のグラフィカルプロセッシングにおける役割に関する情報はまだほとんどありません。SmartDMAエンジンの実装に使われると言われていましたが、他のMCXファミリのMCUではこのコアの存在が記載されておらず、スマートDMAはmcuxpresso SDKが提供するAPIを通じてArm CM33コアで直接利用可能です。 今は非常に混乱しています。iMXRT700でsmartDMAを直接使うことはできますか?それともAN14614指示に従ってLLVM経由でEZH-Vのイメージを構築しなければならないのでしょうか?ただし、IPC通信はCpu0によって直接制御されるはずなのに、RPMsgに頼らざるを得ないというのは、非常に直感に反するように思えます。 さらに、NXPがこのEZH-Vコアを明示的に活用した実際のデモやユースケースを提供した例は私の知る限りありません。入手可能なソースヘッダーの一部も確認しましたが、ごく基本的な操作しか提供されていませんでした。EZH-Vの用途を教えていただけますか? Re: EZH-V use case for IMXRT700 さて、簡単なアップデートです。メインラインのZephyrにあるSmartDMAドライバを見て、状況が理解できました。 スマートDMAは常に、独自のコアを持つスタンドアロンのサブシステムとして計画されてきましたが、完全に独立したRISC-Vコアとして提示されたことはありません。 TomC818_0-1785476896221.png 現在の例では、smartDMAはカスタムファームウェアのインストールパスに実際には一切触れておらず、わずかに特殊なDMA IPとしてのみ使用されています。 さて、今度は昔ながらのスマートDMAを使い続けられるかどうかに軸足を移すべきです。複雑なIPC設定を行う代わりにCM33経由で直接呼び出しされるもので、執筆時点でスマートDMAのIPは公式管理mimxrt700_evkのサポートIPとしてまだ公開されていません。 TomC818_1-1785477330180.png Re: EZH-V use case for IMXRT700 こんにちは@mayliu1 迅速な返信ありがとうございます。つまり、スマートDMAはもはやCM33コアと結合されておらず、EZH-Vコア経由で使わなければならないということですか? NXPの他のMCUファミリであるMCXでは、スマートDMAはCM33と連結されており、API経由で直接呼び出すことができます。これらのユースケースを文書化したアプリケーションノートAN14172、AN14916、RISC-Vコアのスタンドアロンイメージビルディングには関わりません。 TomC818_0-1785417939531.png では、i.MXRT700の現在のアーキテクチャはどのようなものですか?EZH-Vに関する資料はどれも非常に曖昧で、EZH-Vの使い方を網羅的に解説したデモやガイドは今のところ見当たりません。 NXPはスマートDMAのアーキテクチャを改訂し、もはやコアのCM33システムの一部から外し、RISC-Vのコンパニオンコアにグループ化したのでしょうか?CM33経由でスマートDMAを直接呼び出すことはCANか? Re: EZH-V use case for IMXRT700 こんにちは、 @TomC818 さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 AN14614および i.MX RT700リファレンス・マニュアルによると、私の理解では、i.MX RT700のSmartDMA機能は、eDMAのような従来のDMAペリフェラルではなく、EZH-V RISC-Vコアを通じて実装されているようです。 一般的に、eDMAは標準的なメモリ転送操作において依然として推奨されており、CM33コアから直接設定可能です。しかし、特定のグラフィックス/データ後処理やデータフォーマット変換タスクなどのSmartDMA関連プロセッシングは、通常EZH-Vコア上で動作するファームウェアによって実装されます。 AN14614に基づき、CPU0はEZH-Vファームウェアのロードと起動を担当し、その後実際のプロセッシングはEZH-Vによって行われます。この観点から見ると、EZH-Vは従来のDMAエンジンよりもプログラム可能なコプロセッサのように振る舞います。 したがって、RT700上のSmartDMAは、CM33のみで直接駆動される従来のDMAペリフェラルよりも、EZH-Vコア上で動作するプログラム可能なプロセッシングエンジンとして見るべきです。 お役に立てれば幸いです。 よろしくお願いいたします。 5月 Re: EZH-V use case for IMXRT700 あの、あの...もしNXPが実際に準備やサポート計画を持たなかった場合、"EZH-Vの支援により、Cortex-M33コアは他の作業に自由に使える。EZH-Vが割り当てられたタスクを実行する間、CM33コアは他のタスクを並列実行できます。" 説明のリファレンス・マニュアルによると、RT700のドキュメントや例はまだ非常に未完成で散漫なため、STやInfineonとは別の選択肢を追求しようと思います。このMCUのマーケティングされている独特な機能のサポートは非常に少なく、ほとんどありません。このような複雑で異種混在のアーキテクチャでは、このようなわずかな例やガイドは全く役に立たない。 Re: EZH-V use case for IMXRT700 i.MX RT700では、SmartDMAはCM33が直接制御する従来のスタンドアロンDMAペリフェラルとは異なり、露出されません。 SmartDMAスタイルの機能はEZH-Vエンジンを通じて提供されるため、一般的な使用モデルはCM33がEZH-Vファームウェアを読み込み起動し、必要に応じて連携するというものです。 mayliu1_1-1785830645435.png
記事全体を表示
S32K3 待机 + FIRC + 看门狗 你好, 我正在尝试按照 NXP 社区帖子中提供的示例,为 S32K3 系列 (K312) 实现待机模式。 我的项目在正常运行期间使用外部时钟源,并配置看门狗定时器。 根据文档/示例,我的理解是,在进入待机模式之前,我必须切换到使用 FIRC。 如果在进入待机状态之前切换到 FIRC 模式,看门狗定时器会触发信号,从而 RESET MCU。这是预期行为吗?此外,如果我禁用看门狗,MCU 会进入低功耗状态,但不会从唤醒源 RESET。 同时,如果我直接进入待机状态而不切换到 FIRC,看门狗不会触发信号 RESET,MCU 将进入低功耗状态,并会从唤醒源 RESET,正如人们对待机状态的预期一样。 显然,乍一看,方法 2(不切换到 FIRC)似乎有效,但我想澄清一下,因为我观察到垫子保持方面存在一些奇怪的行为。 如果在进入待机状态之前将一个焊盘切换为高电平(方法 2),无论该焊盘是否启用或禁用保持功能,MCU 进入待机状态后,该焊盘仍保持高电平。这让我怀疑MCU是否真的进入了待机状态,还是处于某种中间状态。 我知道这篇帖子写得比较笼统——请告诉我还需要提供哪些背景信息。 此致敬礼, 哈里什 Re: S32K3 STANDBY + FIRC + Watchdog 你好@Hareesh_S , 首先,在进入待机状态之前,必须将系统时钟源更改为 48 MHz 的 FIRC,因为 PLLDIG 在待机模式下不可用。如果不按此顺序操作,可能会导致时钟行为出现意外或无法预料的情况。 如果在进入待机状态之前切换到 FIRC 模式,看门狗定时器会触发信号,从而 RESET MCU。这是预期行为吗?此外,如果我禁用看门狗,MCU 会进入低功耗状态,但不会从唤醒源 RESET。 默认情况下,POR_WDG 已启用,用于监控备用机进入/退出序列,以防出现卡顿情况: Julin_AragnM_0-1785518283148.png 社区提供的示例也会出现这种现象吗?您是否使用RTD API来更改时钟源? S32K3 低功耗管理 AN 和演示 示例 S32K312 在待机状态下通过 CAN-0-RX 和 GPIO 开关 DS3.5 唤醒 RTD300 [RTD600 IP] S32K312EVB-Q172 待机 RAM GPIO 唤醒 如果在进入待机状态之前将一个焊盘切换为高电平(方法 2),无论该焊盘是否启用或禁用保持功能,MCU 进入待机状态后,该焊盘仍保持高电平。这让我怀疑MCU是否真的进入了待机状态,还是处于某种中间状态。 1.待机模式下,所有引脚将保持其在运行模式下的最后设置状态。 2. 默认情况下,RESET事件后所有引脚都将恢复到其默认状态。 PadKeeping 配置会影响引脚状态 在 K3 的唤醒复位和用户端口初始化之间,存在待机退出序列,在此期间引脚可能进入不可控状态: Julin_AragnM_2-1785519093000.png 此致, 朱利安 Re: S32K3 STANDBY + FIRC + Watchdog 你好@Julián_AragónM , 很抱歉回复晚了。 关于垫子保留功能——看来我误解了垫子保留功能的预期用途。感谢您的澄清。 关于 STANDBY 条目 - 此行为在未经修改的社区示例中无法重现。该序列与社区示例中的预期结果一致。 此外,我现在可以确认,当我的项目切换到 FIRC 时,MCU 会发生硬故障,这就是看门狗触发信号 RESET 的原因。 我已在一个空白项目中重现了这种行为,但无法找出根本原因。我附上了项目文件,请您检查一下,并告诉我我遗漏了什么? 此致, 哈里什·S Re: S32K3 STANDBY + FIRC + Watchdog 你好@Hareesh_S , 我很高兴 PadKeeping 功能的问题已经解决。 关于您的项目,在调用 Clock_Ip_Init() 之后,我可以看到Clock_Ip_SetRtcRtccClksel_TrustedCall()处出现硬故障。启用PRTN1_COFB1_CLKEN[REQ34] 后,我可以按预期通过 Clock_Ip_Init() API 更改时钟源。 您能否在项目中尝试一下这个修复方法? Julin_AragnM_0-1786382290784.png Julin_AragnM_1-1786382522241.png Julin_AragnM_2-1786382602253.png 此致, 朱利安 Re: S32K3 STANDBY + FIRC + Watchdog 你好@Julián_AragónM 在 RUN 域中启用 RTC 模块/外设后,切换到 FIRC 可以按预期工作,并且不会触发硬故障。 我没想到 RTC 会被强制启用,但无论如何,非常感谢你们的快速解决!
記事全体を表示
i.MX8MP S错误。远程进程启动 M7 核心并录制 plughw:wm8962audio,0 您好, 在 FRDM-i.MX8MP (Linux 6.12.34-lts-next) 上,在通过 remoteproc 启动 Cortex-M7 之前,wm8962 上的 ALSA 捕获工作正常。任何 M7 固件启动后,arecord 都会触发信号内核崩溃。   摘要: - 没有 M7:记录正常 - 启动 M7 后:fsl_sai_runtime_resume 出现 panic → regmap_write (SError 0xbf000002) - 使用电路板支持包。官方固件复现: - imx8mp_m7_DDR_hello_world.elf - imx8mp_m7_DDR_rpmsg_lite_str_echo_rtos.elf 所以这看起来并不局限于我们定制的M7应用程序。   复制: 1)启动Linux,保持M7停止运行。 2) arecord -Dplughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t.wav→ 确定 3) echo stop > /sys/class/remoteproc/remoteproc0/state echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware echo start > /sys/class/remoteproc/remoteproc0/state 4) 相同记录 → 内核崩溃 (SError)   恐慌路径(缩写): snd_pcm_capture_open → ... → fsl_sai_runtime_resume → regmap_write → SError 0xbf000002   已尝试: - 从 imx8mp-cm7 DT 节点中移除可选的“音频”(AUDPLL)时钟 → 仍然失败 - 在我们的 M7 clock_config 中禁用 AudioMIX 所有权/音频 PLL 初始化 → 仍然无法使用默认的 hello_world 程序运行。   问题: 1) i.MX8MP 是否支持同时使用 Linux SAI/wm8962 和 M7 remoteproc? 2) SDK BOARD_BootClockRUN() 将 AudioMIX 映射到 M7 是否与 A53 音频功率域冲突? 3) 是否有针对 AudioMIX / fsl_sai 运行时恢复 SError 的 6.12 版本已知修复方案? 4) 当音频必须由 Linux 控制时(M7 仅支持 UART/RPMSg),推荐的 M7 时钟配置是什么?   谢谢。   ------------------------- imx8mp-cm7 dts 节点 -------------------------- imx8mp-cm7 {         compatible = "fsl,imx8mn-cm7" ;         rsc-da = < 0x55000000 >;         clocks = < & clk IMX8MP_CLK_M7_DIV >;              //<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;         clock-names = "core" , "uart4" ;         mbox-names = "tx" , "rx" , "rxdb" ;         mboxes = < & mu 0 1               & mu 1 1               & mu 3 1 >;         memory-region = < & vdevbuffer >, < & vdev0vring0 >, < & vdev0vring1 >, < & rsc_table >, < & m4_reserved >;         状态= "正常" ;         fsl,启动延迟毫秒= < 500 >;     };   ------------------ 崩溃日志 ------------------ root@FRDM-test:/lib/firmware# echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware root@FRDM-test:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t_ex.wav [58.448085]CPU0上的SError中断,代码0x00000000bf000002——SError [ 58.448101] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448109] 已污染:[C]=CRAP,[O]=OOT_MODULE [ 58.448111] 硬件名称:NXP FRDM-IMX8MPLUS (DT) [58.448113]pstate:20000005(nzCv daif-PAN-UAO-TCO-DIT-SSBS BTYPE=--) [ 58.448118] pc : _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448130] lr : regmap_unlock_spinlock+0x14/0x20 [ 58.448136] sp : ffff8000854e3670 [58.448138]x29:ffff8000854e3670 x28:ffff8000854e3c30 x27:0000000000000001 [ 58.448147] x26: ffff0000d06da088 x25: 00000000000000000 x24: ffff0000d06da390 [ 58.448153] x23: ffff0000d1c18f60 x22: ffff0000d0363c10 x21: 0000000001000000 [ 58.448160] x20: 0000000000000000 x19: ffff0000d14a3000 x18: 0000000000000002 [ 58.448168] x17: 0000000000000000 x16: 00000000000000000 x15: 0000000000000000 [ 58.448174] x14: 0000000000000000 x13: 00000000000000000 x12: 0000000000000000 [ 58.448180] x11: 0000000000000000 x10: ffff0000dccabb90 x9 : 0000000000000390 [ 58.448188] x8 : ffff0000dccabbac x7 : ffff8000854e3940 x6 : ffff0000dccabba0 [ 58.448194] x5 : ffff8000808ed440 x4 : 0000000000000008 x3 : ffff8000808ece60 [ 58.448200] x2 : 0000000001000000 x1 : ffff0000dcca5280 x0 : 0000000100000001 [ 58.448208] 内核崩溃 - 未同步:异步 SError 中断 [ 58.448211] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448217] 已污染:[C]=CRAP,[O]=OOT_MODULE [ 58.448221] 硬件名称:NXP FRDM-IMX8MPLUS (DT) [ 58.448223]调用跟踪: [ 58.448225] dump_backtrace.part.0+0xd4/0xe0 [ 58.448234] show_stack+0x18/0x30 [ 58.448240] dump_stack_lvl+0x60/0x80 [ 58.448246] dump_stack+0x18/0x24 [ 58.448251] panic+0x168/0x360 [ 58.448258] 添加污点+0x0/0xbc [ 58.448264] arm64_serror_panic+0x64/0x70 [58.448269]do_serror+0x3c/0x70 [ 58.448273] el1h_64_error_handler+0x30/0x54 [ 58.448279] el1h_64_error+0x64/0x68 [ 58.448283] _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448289] regmap_write+0x58/0x80 [ 58.448294] fsl_sai_runtime_resume+0xc4/0x280 [snd_soc_fsl_sai] [ 58.448304] pm_generic_runtime_resume+0x2c/0x44 [ 58.448312] __genpd_runtime_resume+0x30/0x80 [ 58.448318] genpd_runtime_resume+0x130/0x2c4 [ 58.448325] __rpm_callback+0x48/0x1e0 [ 58.448330] rpm_callback+0x68/0x80 [ 58.448334] rpm_resume+0x3bc/0x6a0 [ 58.448340] __pm_runtime_resume+0x50/0x9c [ 58.448344] snd_soc_pcm_component_pm_runtime_get+0x3c/0x138 [ 58.448350] __soc_pcm_open+0x60/0x488 [ 58.448355] soc_pcm_open+0x30/0x58 [ 58.448359] snd_pcm_open_substream+0x594/0x850 [ 58.448364] snd_pcm_open+0x118/0x24c [ 58.448368] snd_pcm_capture_open+0x4c/0x7c [ 58.448372] snd_open+0xa0/0x19c [ 58.448379] chrdev_open+0xb0/0x21c [ 58.448386] do_dentry_open+0x138/0x4c4 [ 58.448392] vfs_open+0x2c/0xf0 [ 58.448397] path_openat+0x6fc/0x1074 [ 58.448403] do_filp_open+0xa0/0x15c [ 58.448407] do_sys_openat2+0xc8/0x100 [ 58.448413] __arm64_sys_openat+0x64/0xc0 [ 58.448420] invoke_syscall+0x48/0x104 [ 58.448427] el0_svc_common.constprop.0+0xc0/0xe0 [ 58.448433] do_el0_svc+0x1c/0x28 [ 58.448438] el0_svc+0x30/0x100 [ 58.448444] el0t_64_sync_handler+0x120/0x12c [ 58.448450] el0t_64_sync+0x190/0x194 [ 58.448458] SMP:停止辅助 CPU [ 58.448464] 内核偏移:已禁用 [ 58.448466] CPU 特性:0x00,00000080,00200000,4200420b [ 58.448469] 内存限制:无 [ 58.762124] ---[ 内核崩溃结束 - 未同步:异步 SError 中断 ]---   i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 嗨@humm Q1. 是的,但前提是两者不能争夺相同的音频资源。 Q2. 是的,会有冲突。在 Linux 控制音频的情况下,M7 端必须移除 AUDIOMIX 映射以及与开机和 SAI PLL 初始化相关的代码,将 AUDIOMIX 完全交给 A53/Linux 的 audiomix_pd 管理。 Q3. 不——因为这不是 fsl_sai 驱动程序中的错误,而是资源所有权配置问题。 Q4.M7 SDK BOARD_RdcInit() — 最关键的一步:移除 SAI3/SDMA3/I2C3 的 M7 (DID1) 分配。移除分配给 DID1 的 RDC_PDAP_SAI3、RDC_MDA_SDMA3*、RDC_PDAP_SDMA3 和 RDC_PDAP_I2C3,同时保持 A53 可以访问这些资源。 B.R Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 嗨@pengyong_zhang 非常感谢您的指导。 根据您的建议,我更新了 RDC 配置,将 SDMA3 分配给功能域 0 (A53/Linux),并在功能域 0 和功能域 1 之间共享了 SAI3、I2C3 和 SDMA3 权限。 以下是我应用的RDC更改的差异: -RDC_MDA RDC_MDA_SDMA3p DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3p DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3b DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3b DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3_SPBA2 DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3_SPBA2 DID0 0x0 0x0 -RDC_PDAP RDC_PDAP_SAI3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SAI3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_SDMA3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SDMA3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_I2C3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_I2C3 PDAP_D0D1_ACCESS 0x0 0x0 应用这些更改后,arecord 在 Linux 上可以正常工作,不会触发任何 SError,即使 M7 内核正在运行其 RTOS 固件。 再次感谢你的帮助!
記事全体を表示
PN7642 RF Debug signal如何设置 您好,请回复一下https://community.nxp.com/t5/NFC/PN7642-RF-Debug-Signals如何设置/m-p/2399084中的疑问(按照提示在CTS_TESTBUS_Signals.png中找到了模拟信号,但是并未找到数字信号,请问有完整的映射表可以提供吗?),谢谢。
記事全体を表示
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は再びクリーンな状態になり、フル機能が有効になりました。
記事全体を表示
Secure debug on i.MX93 with NXP keys The current version of the nxpdebugmbox tool from the SPSDK has a parameter --nxp-keys that is described as "Use the ROM NXP keys to authenticate." Does this mean that NXP can unlock secure debug on all devices? If yes, is there any fuse to restrict secure debug to the OEM SRK keys? Security Re: Secure debug on i.MX93 with NXP keys But if you have control over the ELE, you have access to the DDR memory and can monitor the inputs and outputs of all crypto operations requested by the OEM domain from the ELE domain. You can decrypt all ELE blobs and have therefore access to all secret data stored on the device. And unless writing to DDR memory is prevented, you can inject code into the OEM domain. Re: Secure debug on i.MX93 with NXP keys Hello, No, NXP cannot unlock secure debug on OEM devices with --nxp-keys. The --nxp-keys flag only authenticates the NXP/ELE internal debug domain (using ROM-embedded NXP keys). The OEM SoC debug domain (Cortex-A55, M33, etc.) is completely separate and can only be unlocked with the OEM's own SRK keys. No additional fuse is needed to enforce this, it is architectural by design. Once the device is in OEM_CLOSED lifecycle with the OEM SRK hash fused, the ELE hardware enforces that NXP keys have zero authority over the OEM debug domain. Best regards/Saludos, Aldo.
記事全体を表示
i.MX8MP Sエラー。リモートプロセスがM7コアとarecordプラグインを起動しますhw:wm8962audio,0 こんにちは、 FRDM-i.MX8MP(Linux 6.12.34-lts-next)では、WM8962でのALSAキャプチャは、Cortex-M7をリモートプロックで起動するまで問題なく動作します。M7ファームウェアが起動すると、arecordによってカーネルパニックが発生します。   要約: - M7なし: arecord OK - M7 の起動後: fsl_sai_runtime_resume でパニックが発生 → regmap_write (SError 0xbf000002) - BSP純正ファームウェアで再現しました: - imx8mp_m7_DDR_hello_world.elf - imx8mp_m7_DDR_rpmsg_lite_str_echo_rtos.elf SO、これはカスタムM7アプリに特有のものではありません。   再現: 1) Linuxを起動し、M7を停止したままにする 2) arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t.wav→ OK 3) echo stop > /sys/class/remoteproc/remoteproc0/state echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware echo start > /sys/class/remoteproc/remoteproc0/state 4) 同じ arecord → カーネルパニック (SError)   パニック経路(略式): snd_pcm_capture_open → ... → fsl_sai_runtime_resume → regmap_write → SError 0xbf000002   試した内容: - imx8mp-cm7 DTノードからオプションの「オーディオ」(AUDPLL)クロックを削除→それでも失敗します - M7でAudioMIX所有権/Audio PLL initを無効にするclock_config →純正のままhello_worldでも失敗します   質問: 1) i.MX8MPでLinuxのSAI/wm8962とM7リモートプロックの同時使用はサポートされていますか? 2) SDK BOARD_BootClockRUN()をM7にマッピングすることは、A53のオーディオパワードメインと衝突しますか? 3) AudioMIX / fsl_sai のランタイム再開時に発生する SError に対する、6.12 の既知の修正方法はありますか? 4) オーディオがLinuxに所有されている必要がある場合(M7ではUART/RPMsgのみ)M7におすすめclock_configはありますか?   ありがとうございます。   ------------------------- imx8mp-cm7 dts ノード -------------------------- imx8mp-cm7 {         compatible = "fsl,imx8mn-cm7" ;         rsc-da = < 0x55000000 >;         クロック= < & clk IMX8MP_CLK_M7_DIV >;              //<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;         クロック名= "core" , "uart4" ;         mbox-names = "tx" , "rx" , "rxdb" ;         mboxes = < & mu 0 1               & mu 1 1               & mu 3 1 >;         メモリ領域= < & vdevbuffer >, < & vdev0vring0 >, < & vdev0vring1 >, < & rsc_table >, < & m4_reserved >;         ステータス= "正常" ;         fsl、起動遅延ミリ秒= < 500 >;     };   ------------------ パニックログ ------------------ root@FRDM-test:/lib/firmware# echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware root@FRDM-test:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t_ex.wav [ 58.448085] CPU0 の SError 割り込み、コード 0x00000000bf000002 -- SError [ 58.448101] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448109] 汚染: [C]=CRAP、[O]=OOT_MODULE [ 58.448111] ハードウェア名: NXP FRDM-IMX8MPLUS (DT) [ 58.448113] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 58.448118] pc : _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448130] lr : regmap_unlock_spinlock+0x14/0x20 [ 58.448136] sp : ffff8000854e3670 [ 58.448138] x29: ffff8000854e3670 x28: ffff8000854e3c30 x27: 0000000000000001 [ 58.448147] x26: ffff0000d06da088 x25: 0000000000000000 x24: ffff0000d06da390 [ 58.448153] x23: ffff0000d1c18f60 x22: ffff0000d0363c10 x21: 0000000001000000 [ 58.448160] x20: 0000000000000000 x19: ffff0000d14a3000 x18: 0000000000000002 [ 58.448168] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 58.448174] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 58.448180] x11: 0000000000000000 x10: ffff0000dccabb90 x9 : 0000000000000390 [ 58.448188] x8 : ffff0000dccabbac x7 : ffff8000854e3940 x6 : ffff0000dccabba0 [ 58.448194] x5 : ffff8000808ed440 x4 : 0000000000000008 x3 : ffff8000808ece60 [ 58.448200] x2 : 0000000001000000 x1 : ffff0000dcca5280 x0 : 0000000100000001 [ 58.448208] カーネルパニック - 同期していません: 非同期SError割り込み [ 58.448211] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: GCO 6.12.34-lts-next #1 [ 58.448217] 汚染: [C]=CRAP、[O]=OOT_MODULE [ 58.448221] ハードウェア名: NXP FRDM-IMX8MPLUS (DT) [ 58.448223]通話追跡: [ 58.448225] dump_backtrace.part.0+0xd4/0xe0 [ 58.448234] show_stack+0x18/0x30 [ 58.448240] dump_stack_lvl+0x60/0x80 [ 58.448246] dump_stack+0x18/0x24 [ 58.448251] パニック+0x168/0x360 [ 58.448258] add_taint+0x0/0xbc [ 58.448264] arm64_serror_panic+0x64/0x70 [ 58.448269] do_serror+0x3c/0x70 [ 58.448273] el1h_64_error_handler+0x30/0x54 [ 58.448279] el1h_64_error+0x64/0x68 [ 58.448283] _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448289] regmap_write+0x58/0x80 [ 58.448294] fsl_sai_runtime_resume+0xc4/0x280 [snd_soc_fsl_sai] [ 58.448304] pm_generic_runtime_resume+0x2c/0x44 [ 58.448312] __genpd_runtime_resume+0x30/0x80 [ 58.448318] genpd_runtime_resume+0x130/0x2c4 [ 58.448325] __rpm_callback+0x48/0x1e0 [ 58.448330] rpm_callback+0x68/0x80 [ 58.448334] rpm_resume+0x3bc/0x6a0 [ 58.448340] __pm_runtime_resume+0x50/0x9c [ 58.448344] snd_soc_pcm_component_pm_runtime_get+0x3c/0x138 [ 58.448350] __soc_pcm_open+0x60/0x488 [ 58.448355] soc_pcm_open+0x30/0x58 [ 58.448359] snd_pcm_open_substream+0x594/0x850 [ 58.448364] snd_pcm_open+0x118/0x24c [ 58.448368] snd_pcm_capture_open+0x4c/0x7c [ 58.448372] snd_open+0xa0/0x19c [ 58.448379] chrdev_open+0xb0/0x21c [ 58.448386] do_dentry_open+0x138/0x4c4 [ 58.448392] vfs_open+0x2c/0xf0 [ 58.448397] path_openat+0x6fc/0x1074 [ 58.448403] do_filp_open+0xa0/0x15c [ 58.448407] do_sys_openat2+0xc8/0x100 [ 58.448413] __arm64_sys_openat+0x64/0xc0 [ 58.448420] invoke_syscall+0x48/0x104 [ 58.448427] el0_svc_common.constprop.0+0xc0/0xe0 [ 58.448433] do_el0_svc+0x1c/0x28 [ 58.448438] el0_svc+0x30/0x100 [ 58.448444] el0t_64_sync_handler+0x120/0x12c [ 58.448450] el0t_64_sync+0x190/0x194 [58.448458] SMP: セカンダリCPUを停止します [ 58.448464] カーネルオフセット: 無効 [ 58.448466] CPU機能: 0x00,00000080,00200000,4200420b [ 58.448469] メモリ制限: なし [ 58.762124] ---[ カーネルパニック終了 - 同期していません: 非同期SError割り込み ]---   i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 こんにちは@humm Q1。はい、ただし両者が同じオーディオ資源を競合できない場合に限ります。 Q2。はい、対立は起こります。Linuxがオーディオを制御する場合、M7側はAUDIOMIXのマッピングや電源オンおよびSAI PLL初期化に関するコードを削除し、AUDIOMIXは完全にA53/Linuxのaudiomix_pdマネジメントに委ねられます。 Q3。いいえ、これはfsl_saiドライバーのバグではなく、リソース所有設定の問題です。 Q4。M7 SDK BOARD_RdcInit() — 最も重要なステップ:SAI3/SDMA3/I2C3のM7(DID1)割り当てを取り除くことです。RDC_PDAP_SAI3、RDC_MDA_SDMA3*、RDC_PDAP_SDMA3、およびRDC_PDAP_I2C3のDID1への割り当てを削除し、これらのリソースがA53からアクセスできるようにします。 B.R Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 こんにちは@pengyong_zhang ご指導いただき、誠にありがとうございました。 ご助言に従い、RDCの設定を更新し、SDMA3をドメイン0(A53/Linux)に割り当て、ドメイン0とドメイン1間でSAI3、I2C3、SDMA3の権限を共有しました。 以下は、私が適用したRDCの変更点の差分です。 -RDC_MDA RDC_MDA_SDMA3p DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3p DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3b DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3b DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3_SPBA2 DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3_SPBA2 DID0 0x0 0x0 -RDC_PDAP RDC_PDAP_SAI3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SAI3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_SDMA3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SDMA3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_I2C3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_I2C3 PDAP_D0D1_ACCESS 0x0 0x0 これらの変更を適用すると、ArecordはLinux上でSErrorをトリガーせずに動作し、M7コアがRTOSファームウェアを動かしている間も問題ありません。 ご協力ありがとうございました!
記事全体を表示
How to configure the PN7642 RF debug signal? Hello, please reply to the question in https://community.nxp.com/t5/NFC/PN7642-RF-Debug-Signals setting/mp/2399084 ( I found the analog signals in CTS_TESTBUS_Signals.png as instructed, but I couldn't find the digital signals. Could you please provide a complete mapping table?). Thank you.
記事全体を表示
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.
記事全体を表示
S32K3 スタンバイ + FIRC + ウォッチドッグ こんにちは、 NXPのコミュニティ投稿で提供されている例を参考に、S32K3シリーズ(K312)のスタンバイモードを実装しようとしています。 私のプロジェクトでは、通常動作時に外部クロックソースを使用し、ウォッチドッグタイマーを設定します。 ドキュメントや例から理解しているのは、スタンバイモードに入る前にFIRECを使う必要があるということです。 STANDBYに入る前にFIRCに切り替えると、ウォッチドッグタイマーが作動し、MCUがリセットされます。これは想定される動作ですか?さらに、ウォッチドッグを無効にするとMCUは低消費電力状態に入りますが、ウェイクアップソースからのリセットはしません。 一方、FIRCに切り替えずに直接STANDBYに入ると、ウォッチドッグはリセットをトリガーせず、MCUは低消費電力状態に入り、STANDBYで期待されるウェイクアップソースからリセットされます。 一見すると、アプローチ2(FIRCに切り替えない方法)がうまくいくように見えますが、パッドキーピングで奇妙な挙動を目撃しているので、確認しておきたいと思います。 STANDBY(アプローチ2)に入る前にパッドをハイに切り替えると、パッドキーピングが有効か無効かに関わらず、MCUがSTANDBYに入った後もパッドは高いままです。これを見て、MCUが本当にSTANDBYに入っているのか、それとも中間状態にあるのか疑問に思います。 この投稿はかなり曖昧だと承知していますが、追加で説明できる情報があれば教えてください。 よろしくお願いいたします。 ハリーシュ Re: S32K3 STANDBY + FIRC + Watchdog こんにちは、 @Hareesh_S さん、 まず、スタンバイモードに入る前に、システムクロックソースを48MHzのFIRCに変更する必要があります。これは、スタンバイモードではPLLDIGが使用できないためです。この手順に従わない場合、予期しない/定義されていないクロック動作が発生する可能性があります。 STANDBYに入る前にFIRCに切り替えると、ウォッチドッグタイマーが作動し、MCUがリセットされます。これは想定される動作ですか?さらに、ウォッチドッグを無効にするとMCUは低消費電力状態に入りますが、ウェイクアップソースからのリセットはしません。 デフォルトでは、POR_WDGはスタックシナリオにおけるスタンバイ入退出シーケンス監視のために有効になっています。 Julin_AragnM_0-1785518283148.png コミュニティで提供されているサンプルでも、同様の現象が発生しますか?クロックソースを変更するためにRTD APIを使用していますか? S32K3の低消費電力管理ANとデモ 例:CAN-0-RXおよびGPIOスイッチDS3.5 RTD300を使用してS32K312スタンバイ・モードからウェイクアップする [RTD600 IP] S32K312EVB-Q172 スタンバイRAM GPIOウェイクアップ STANDBY(アプローチ2)に入る前にパッドをハイに切り替えると、パッドキーピングが有効か無効かに関わらず、MCUがSTANDBYに入った後もパッドは高いままです。これを見て、MCUが本当にSTANDBYに入っているのか、それとも中間状態にあるのか疑問に思います。 1.スタンバイモード中も、すべてのピンは実行モードで最後に設定された状態を保持します。 2. リセットイベント後、すべてのピンはデフォルト状態に戻されます。 PadKeepingの設定は 、K3のウェイクアップリセットとユーザーのポート初期化の間に、スタンバイ終了シーケンス 後の ピン状態に影響を与えます。この間、ピンが制御不能な状態に入ることがあります。 Julin_AragnM_2-1785519093000.png よろしくお願いします、 ジュリアン Re: S32K3 STANDBY + FIRC + Watchdog こんにちは、 @Julián_AragónM さん、 返信が遅くなり申し訳ありません。 パッド保持機能についてですが、どうやら私はパッド保持機能の本来の機能を誤解していたようです。ご説明いただきありがとうございます。 STANDBYエントリに関して - この動作は、変更されていないコミュニティのサンプルでは再現できません。コミュニティのサンプルコードでは、この手順は期待どおりに動作します。 さらに、私のプロジェクトでFIRCに切り替えるとMCUがハードフォールトを起こし、それがウォッチドッグがリセットをトリガーする理由であることを今確認できました。 この挙動を空のプロジェクトで再現することはできましたが、根本原因がわかりません。プロジェクトを添付していますが、同じ内容を確認して、私が見落としていることを教えていただけませんか? よろしくお願いいたします。 ハリーシュS Re: S32K3 STANDBY + FIRC + Watchdog こんにちは、 @Hareesh_S さん、 PadKeepingの機能に関する疑問が解消されてよかったです。 あなたのプロジェクトについてですが、Clock_Ip_Init()に電話をかけたところ、 Clock_Ip_SetRtcRtccClksel_TrustedCall()にハードフォールトが見えます。PRTN1_COFB1_CLKEN[REQ34]を有効にすると、Clock_Ip_Init() APIを通じてクロックソースを変更できます。 この修正をあなたのプロジェクトで試してみてはどうですか? Julin_AragnM_0-1786382290784.png Julin_AragnM_1-1786382522241.png Julin_AragnM_2-1786382602253.png よろしくお願いします、 ジュリアン Re: S32K3 STANDBY + FIRC + Watchdog こんにちは@Julián_AragónM  RUNドメインでRTCモジュール/ペリフェラルを有効にした後、FIRCへの切り替えは期待通りに動作し、ハードフォルトを引き起こしません。 RTCの有効化が必須だとは予想していませんでしたが、迅速な対応に感謝いたします!
記事全体を表示
UWBシングルビーコン+AoAによる出入口内外検出に関するアドバイス 私は壁掛けのシングルアンカーUWBシステム(ドア出口検知のユースケース)をビルディングしており、AoAを使ってタグがドアの内側か外側かを判別する必要があります。すでに開いているドアも含めて、ドアお問い合わせセンサでゲートを付けることができません。 背景: Qorvo QM33120W/DW3000 (2アンテナPDoA) を運用していたところ、硬い建築物の壁に直面しました。アンカーを約7フィートの高さに真下に向けて設置した状態で、その下を歩いたり旋回したりすると、クリーンで強力な信号であっても、誤った「外側」角度コミットが発生します。 私の計画は、UWBアンテナを地面に真下に向けて配置し、正の角度と負の角度(内外)信号を捉えてタグが内側から外側に移動するタイミング(出口検出)を判断CANるようにすることでした。 現在、Qorvoデバイスでは、タグを最適な正面向き(アンテナが上)に保持している場合は問題ありませんが、タグ(DW3000)を動かしたり回転させたりすると、同じ場所に立っていても異なるAoA値が表示されるようになります。 標識の表記規則に関する問題:私が期待するのは、一貫した表記規則です。標識が内側にある間は正の角度、外側に出た後は負の角度となります。実際には、明らかにまだ内部にいるにもかかわらず、タグが回転したり、ランダムな方向や速度で移動したりすることに関連した、正と負の両方の角度が見られます。これは、実際にドアを横切ったこととは関係ありません。これは新しいハードウェアにコミットする前にデザインしようとしている特定の症状です。 現在、NXP製シリコンへの移行を検討しており、皆様からのご意見を伺いたいと思っています。 Qorvo 2D AoAボードはRFスイッチを使って2つのアンテナ間のUWB PDoAをキャプチャします。NXP SR150デュアル受信機チェーンに切り替えれば、迎角の変動問題は解決するでしょうか? 単一のオーバーヘッドマウントアンカーで、その下のドアを通ってタグが移動する場合、SR150の2D/ソフトウェア支援による3-アンテナ-3DのAoAモードで前後の曖昧さを解決するのに十分でしょうか?それとも真のセカンドベースラインにはSR250の3つの同時送信チェーンが必要ですか? この特定のトップダウンオーバーヘッドCASEに合ったおすすめのアンテナの形状や取り付け方はありますか? このような曖昧さが多いジオメトリで、SR150のアンテナスイッチ第3アンテナモードとSR250の実際の経験はありますか? ありがとうございます。 kamaln16_0-1785454764324.png Re: UWB Single beacon + AoA for doorway inside/outside detection advice こんにちは、 あなたの調子が良いといいのですが。屋根に取り付けた単一のアンカーで、自由に回転するタグで内外のドア検知を行う場合、 Trimension SR250 は適切なプラットフォームであり、IoTおよびインダストリアルアンカーデザインに推奨されるUWB製品です。 この推奨事項の根本的な理由は、ハードウェアアーキテクチャにある。SR250は外部RFスイッチを不要に3つの同時受信経路を統合し、1つの測距フレームから方位角と仰角の両方を提供できるワンショット3D AoAを実現しています。 SR250はこの用途に価値のある追加機能も備えています: アンテナダイバーシティ最大9本まで、360° AoA対応 オンチップUWBレーダー(OCPD)はプレゼンス検出用で、距離を使った交差検知と並行して有用な補完層となります FiRa 4.0およびAliro 1.0に対応し、より広範なUWBエコシステムとの相互運用性を確保。 どこから始めるか 開発キット: SR250開発ボード、Arduino対応の統合PCBアンテナ、端子探知、AoA、レーダーのプラグアンドプレイデモを箱から出して提供 ソフトウェア: Zephyr OS用のSR250 UWBIOT パートナーモジュールおよびキット:TrueSense(ETNA TS 250 DevKit)、MobileKnowledge(MK UWB Kit Mobile edition 2.0)、Amotech(SR250統合3Dアンテナモジュール)、すべてNXPパートナー市場で入手可能です これがお役に立てば幸いです。 よろしくお願いいたします。 リカルド Re: UWB Single beacon + AoA for doorway inside/outside detection advice リカルドさん、ありがとうございます。詳細なご回答に感謝いたします。 更新:村田製作所のType2BP(SR150)開発ボードとNXPのSR250UWBSHIELD開発ボードの両方を注文しました。残念ながら、SR250UWBSHIELD側では14週間のバックオーダーが表示されているので、その間にSR150のベンチワークを始め、SR250が届いたらそれに移行するつもりです。 待っている間にいくつかフォローアップしておきます。 1. 私のアプリケーションにおけるSR150とSR250の違い:仰角ではなく方位角(内側・外側)だけが必要だと考えると、SR150からSR250に移行することに、アーキテクチャの違い(真の3つの同時受信チェーンとSR150の2つのネイティブチェーン+スイッチされた3番目のアンテナ)を乗り換えることに実際にどんなメリットがあるのでしょうか?精度や安定性の向上は単軸用途で待つ価値があるのでしょうか?それとも、取り付けや多重経路対策が整えばSR150だけで十分に達成できるでしょうか? 2. RFスイッチングとタグ回転:根本原因を探している特定の症状の一つですが、Qorvoハードウェアで全く同じ場所に立ってX平面でタグを回転させるだけで(位置が全く変わらない)、AoA値が明らかに跳ね回り、極性が逆に変わっているように見えます。Qorvoの2D AoAは、RFスイッチを使って2つのアンテナを同時にサンプリングするのではなく、タイムマルチプレックスを行います。スイッチングアーキテクチャがこの回転に関連した不安定性の一因となっている可能性が高いとお考えですか?それとも、これは他の要因(タグの回転に伴う放射パターン/偏光感度、マルチパスなど)とより整合性が高いでしょうか?SR150/SR250の同時RXサンプリングによってこの特定の症状が解消されるのか、それともチップの種類に関係なく対処する必要のある別の問題なのかを理解しようとしています。 3. 私の用途における2D vs. 3D AoA:内側か外側(方位角)だけ知ればよく、標高は私の用途には意味がないので、完全な3D自立Aを運用することに精度や信頼性の向上はありますか?それとも方位角のみ設定して標高を無視した方が良いでしょうか?具体的には、標高測定が、屋内/屋外の判定に標高を使用しない場合でも、反射信号/非見通し信号と有効な信号を区別するのに役立つかどうかを知りたいです。 4. 消費電力、2D vs. 3D: これはバッテリー駆動の設置となります。SR250では、2DのみのAoAとフル3D AoAのどちらを使用した場合も、同時に3つのRXチェーンが動作することを考慮すると、消費電流に意味のある違いはありますか?それとも、ソフトウェアでどの軸を使っていても3つのチェーンすべてが有効になると、電力コストはほぼ固定されるのでしょうか? 5. 私の設置場所におけるマルチパス対策:ビーコンは、近くにガラス扉があり、天井がユニットから約5フィート上にある出入口の上の壁に取り付けられます。現在使用しているQorvo製ハードウェアで、反射による角度の不安定性と思われる現象が発生しています(タグの回転と相関があり、天井の高い部屋で悪化し、ガラス扉を閉めているときに悪化します)。ガラスや隣接する壁からの近距離反射を抑制するために推奨される設置方法、アンテナのビーム幅/パターン選択、またはファームウェア側のフィルタリング(FOM/NLoSしきい値)はありますか?あるいは、NXP SR150またはSR250には、この問題を抑制するような機能はありますか? 6. バッテリー節約のためのレーダーベースのモーションゲーティング:SR250のオンチップレーダー(OCPD)を、純粋に低消費電力のウェイクトリガーとして使いたいです。レーダーモードのままで、動きが検出されたら全範囲/AoAを起動します。アンカーを高さ約2mの出入口の上に設置し、アンテナを真下に向けている場合、ユニット直下ではおおよそどのくらいのモーション検知範囲/カバー率が期待できますか?レーダーの有効「ウェイクゾーン」をドアのフットプリントに対して測ろうとしています。人が出入り口に向かって歩いているときと、出入り口から離れていくときの動きを検知したい。 ご協力ありがとうございました。
記事全体を表示
PN7642のRFデバッグ信号をどのように設定すればよいですか? こんにちは。https ://community.nxp.com/t5/NFC/PN7642-RF-Debug-Signals setting/mp/2399084 の質問にご回答いただけますでしょうか(指示通りにCTS_TESTBUS_Signals.pngでアナログ信号は見つけましたが、デジタル信号が見つかりませんでした。完全なマッピングテーブルをご提供いただけますでしょうか?)。よろしくお願いいたします。
記事全体を表示
单独设置 CONFIG_FIT_CIPHER=y 会导致 hab_status 您好,客服人员, 单独设置 CONFIG_FIT_CIPHER=y 会导致 i.MX8M Plus EVK (开放模式) 上的 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 分支 HAB 签名:其他方面均正常工作 — CST 签名 imx-启动(SPL CSF + FIT CSF),自定义版本时任务,用于验证嵌入偏移量处的 CSF 标签字节,并在任何不匹配时使版本失败(始终通过) 我有一个干净的基线,在这个板上,hab_status 报告“未找到 HAB 事件!”,使用的是我正常的 HAB 签名 imx-启动。我最近添加了内核 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. 基线(现有 HAB 签名 imx-boot,无 kernel-FIT 工作):0 个事件 2. 已启用完整的内核 FIT 功能(FIT 公钥/AES 密钥 DTB 嵌入 + 我自己的 cmd/bootm.c)。补丁 + CONFIG_FIT_CIPHER=y + CONFIG_SYS_BOOTM_LEN=0x8000000): 4 个事件 3. 仅禁用 FIT 公钥/AES 密钥 DTB 嵌入:事件仍然存在,且相同 4. 还删除了我的 cmd/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 文件)。patch、FIT 公钥/AES 密钥 DTB 嵌入、CONFIG_SYS_BOOTM_LEN)单独或组合都很重要;只有 CONFIG_FIT_CIPHER=y 会将 hab_status 从 0 个事件翻转为这 4 个事件。 我仔细检查过,我自己的 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 的有关 HAB v4.4.0 之前的版本在封闭配置中锁定作业环/DECO 主 ID 寄存器的说明,但这并没有直接描述这种开放模式、CONFIG_FIT_CIPHER 特有的情况。 问题: 1.这是 i.MX8M Plus 上 CONFIG_FIT_CIPHER 和 HABv4 CSF 认证之间已知的交互吗?是 CAAM 资源相关问题,还是其他问题(例如,编译后的二进制文件大小/布局以某种方式移动了 FIT CSF 元器件边界,而我自己的自检无法发现这个问题,因为它验证的是我计算的偏移量,而不是 ROM 独立推导出的偏移量)? 2. CONFIG_FIT_CIPHER 是否能够安全地与此 SoC 上的 HABv4 CSF 签名结合使用,或者这是一个真正的限制? 3. 如果这是根本原因,是否有任何关于正确的 CAAM 作业环分配/解锁顺序的指示? Yocto Project Re: CONFIG_FIT_CIPHER=y alone causes hab_status 将此问题标记为已解决,以防其他人需要进行二分查找——感谢 [ https://community.nxp.com/t5/i-MX-Processors/i-MX8MP-EVK-HABv4-hab-status-shows-HAB-FAILURE-before-fuses-are/mp/2344924/highlight/true#M244756 ] 提供的真正修复方法,我找到后立即应用了该方法。 症状:使用我们正常的 HAB 签名 imx-启动 进行清洁基线(hab_status 报告“未发现 HAB 事件!”)。启用 CONFIG_FIT_CIPHER=y 后(为了支持 U-Boot 解密 AES-256 加密的内核 FIT 映像——一种与 HAB 不同的机制,与 SRK 熔丝无关),hab_status 开始在每次启动时报告 4 个事件:2× HAB_INV_ASSERTION,2× HAB_INV_SIGNATURE。 二分法:逐一隔离我们修改过的每个变量,每次都在真实硬件上执行重建+刷新+hab_status操作——最终只隔离了CONFIG_FIT_CIPHER=y(禁用FIT公钥/AES密钥DTB嵌入,并移除一个无关的cmd/bootm.c文件)。打补丁、保留/删除 CONFIG_SYS_BOOTM_LEN — 这些都不重要;只有 CONFIG_FIT_CIPHER 重要)。 根本原因 + 修复:我们通过自定义 Yocto 任务版本化 imx-启动,该任务移植了手动 HAB 签名工作流程(解析 SPL IVT,通过 print_fit_hab.sh 计算 FIT 元器件块,(使用 CST 签名)进入自动版本步骤。该任务假设 mkimage_imx8 自身版本留在版本暂存目录中的 DTB 副本已经正确地进行了 16 字节对齐——但这并不能保证每个配置都是如此。CONFIG_FIT_CIPHER 会改变 U-启动 本身的编译 DTB 大小,在我们的例子中,导致其大小不对齐。未对齐的 DTB 会悄悄地移动 print_fit_hab.sh 计算的每个后续 FIT 元器件边界,因此 CST 会对错误的字节范围进行签名。我们自己的版本时自检(在我们计算出的偏移量处是否存在 CSF 标签字节)每次都顺利通过——它并没有检查 ROM 独立正确的边界概念。只有真正的硬件才能捕获它。 修复方法与另一个帖子中的方法类似:在计算 FIT 元器件块之前,立即在 DTB 上显式运行 pad_image.sh(imx-mkimage 自己的脚本),而不是信任暂存目录的现有状态。已确认确实填充了数据(不是空操作),并且启用完整功能后,hab_status 再次变为干净状态。
記事全体を表示
i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 Hi, On FRDM-i.MX8MP (Linux 6.12.34-lts-next), ALSA capture on wm8962 works fine until the Cortex-M7 is started via remoteproc. After any M7 firmware starts, arecord triggers a kernel panic.   Summary: - Without M7: arecord OK - After starting M7: panic in fsl_sai_runtime_resume → regmap_write (SError 0xbf000002) - Reproduced with BSP stock firmwares: - imx8mp_m7_DDR_hello_world.elf - imx8mp_m7_DDR_rpmsg_lite_str_echo_rtos.elf So this does not look specific to our custom M7 app.   Reproduce: 1) Boot Linux, keep M7 stopped 2) arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t.wav → OK 3) echo stop > /sys/class/remoteproc/remoteproc0/state echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware echo start > /sys/class/remoteproc/remoteproc0/state 4) same arecord → Kernel panic (SError)   Panic path (abbreviated): snd_pcm_capture_open → ... → fsl_sai_runtime_resume → regmap_write → SError 0xbf000002   Tried: - Remove optional "audio" (AUDPLL) clock from imx8mp-cm7 DT node → still fails - Disable AudioMIX ownership / Audio PLL init in our M7 clock_config → still fails with stock hello_world anyway   Questions: 1) Is concurrent use of Linux SAI/wm8962 and M7 remoteproc supported on i.MX8MP? 2) Does SDK BOARD_BootClockRUN() mapping AudioMIX to M7 conflict with A53 audio power domain? 3) Any known 6.12 fixes for AudioMIX / fsl_sai runtime resume SError? 4) Recommended clock_config for M7 when audio must remain owned by Linux (UART/RPMsg only on M7)?   Thanks.   ------------------------- imx8mp-cm7 dts node -------------------------- imx8mp-cm7 {         compatible = "fsl,imx8mn-cm7";         rsc-da = <0x55000000>;         clocks = <&clk IMX8MP_CLK_M7_DIV>;              //<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>;         clock-names = "core", "uart4";         mbox-names = "tx", "rx", "rxdb";         mboxes = <&mu 0 1               &mu 1 1               &mu 3 1>;         memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&rsc_table>,                 <&m4_reserved>;         status = "okay";         fsl,startup-delay-ms = <500>;     };   ------------------ Panic log ------------------ root@FRDM-test:/lib/firmware# echo imx8mp_m7_DDR_hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware root@FRDM-test:/lib/firmware# echo start > /sys/class/remoteproc/remoteproc0/state root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# root@FRDM-test:/lib/firmware# arecord -D plughw:wm8962audio,0 -f S16_LE -r 16000 -c 1 -d 1 /tmp/t_ex.wav [ 58.448085] SError Interrupt on CPU0, code 0x00000000bf000002 -- SError [ 58.448101] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: G C O 6.12.34-lts-next #1 [ 58.448109] Tainted: [C]=CRAP, [O]=OOT_MODULE [ 58.448111] Hardware name: NXP FRDM-IMX8MPLUS (DT) [ 58.448113] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 58.448118] pc : _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448130] lr : regmap_unlock_spinlock+0x14/0x20 [ 58.448136] sp : ffff8000854e3670 [ 58.448138] x29: ffff8000854e3670 x28: ffff8000854e3c30 x27: 0000000000000001 [ 58.448147] x26: ffff0000d06da088 x25: 0000000000000000 x24: ffff0000d06da390 [ 58.448153] x23: ffff0000d1c18f60 x22: ffff0000d0363c10 x21: 0000000001000000 [ 58.448160] x20: 0000000000000000 x19: ffff0000d14a3000 x18: 0000000000000002 [ 58.448168] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 58.448174] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 58.448180] x11: 0000000000000000 x10: ffff0000dccabb90 x9 : 0000000000000390 [ 58.448188] x8 : ffff0000dccabbac x7 : ffff8000854e3940 x6 : ffff0000dccabba0 [ 58.448194] x5 : ffff8000808ed440 x4 : 0000000000000008 x3 : ffff8000808ece60 [ 58.448200] x2 : 0000000001000000 x1 : ffff0000dcca5280 x0 : 0000000100000001 [ 58.448208] Kernel panic - not syncing: Asynchronous SError Interrupt [ 58.448211] CPU: 0 UID: 0 PID: 644 Comm: arecord Tainted: G C O 6.12.34-lts-next #1 [ 58.448217] Tainted: [C]=CRAP, [O]=OOT_MODULE [ 58.448221] Hardware name: NXP FRDM-IMX8MPLUS (DT) [ 58.448223] Call trace: [ 58.448225] dump_backtrace.part.0+0xd4/0xe0 [ 58.448234] show_stack+0x18/0x30 [ 58.448240] dump_stack_lvl+0x60/0x80 [ 58.448246] dump_stack+0x18/0x24 [ 58.448251] panic+0x168/0x360 [ 58.448258] add_taint+0x0/0xbc [ 58.448264] arm64_serror_panic+0x64/0x70 [ 58.448269] do_serror+0x3c/0x70 [ 58.448273] el1h_64_error_handler+0x30/0x54 [ 58.448279] el1h_64_error+0x64/0x68 [ 58.448283] _raw_spin_unlock_irqrestore+0x10/0x50 [ 58.448289] regmap_write+0x58/0x80 [ 58.448294] fsl_sai_runtime_resume+0xc4/0x280 [snd_soc_fsl_sai] [ 58.448304] pm_generic_runtime_resume+0x2c/0x44 [ 58.448312] __genpd_runtime_resume+0x30/0x80 [ 58.448318] genpd_runtime_resume+0x130/0x2c4 [ 58.448325] __rpm_callback+0x48/0x1e0 [ 58.448330] rpm_callback+0x68/0x80 [ 58.448334] rpm_resume+0x3bc/0x6a0 [ 58.448340] __pm_runtime_resume+0x50/0x9c [ 58.448344] snd_soc_pcm_component_pm_runtime_get+0x3c/0x138 [ 58.448350] __soc_pcm_open+0x60/0x488 [ 58.448355] soc_pcm_open+0x30/0x58 [ 58.448359] snd_pcm_open_substream+0x594/0x850 [ 58.448364] snd_pcm_open+0x118/0x24c [ 58.448368] snd_pcm_capture_open+0x4c/0x7c [ 58.448372] snd_open+0xa0/0x19c [ 58.448379] chrdev_open+0xb0/0x21c [ 58.448386] do_dentry_open+0x138/0x4c4 [ 58.448392] vfs_open+0x2c/0xf0 [ 58.448397] path_openat+0x6fc/0x1074 [ 58.448403] do_filp_open+0xa0/0x15c [ 58.448407] do_sys_openat2+0xc8/0x100 [ 58.448413] __arm64_sys_openat+0x64/0xc0 [ 58.448420] invoke_syscall+0x48/0x104 [ 58.448427] el0_svc_common.constprop.0+0xc0/0xe0 [ 58.448433] do_el0_svc+0x1c/0x28 [ 58.448438] el0_svc+0x30/0x100 [ 58.448444] el0t_64_sync_handler+0x120/0x12c [ 58.448450] el0t_64_sync+0x190/0x194 [ 58.448458] SMP: stopping secondary CPUs [ 58.448464] Kernel Offset: disabled [ 58.448466] CPU features: 0x00,00000080,00200000,4200420b [ 58.448469] Memory Limit: none [ 58.762124] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---   i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Yocto Project Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 Hi @humm  Q1. Yes, but only if the two cannot compete for the same audio resources. Q2. Yes, there will be conflicts. In scenarios where Linux controls the audio, the M7 side must remove the AUDIOMIX mapping and the code related to power-on and SAI PLL initialization, leaving AUDIOMIX entirely to the A53/Linux's audiomix_pd management. Q3. No—because this isn't a bug in the fsl_sai driver, but rather a resource ownership configuration issue. Q4.M7 SDK BOARD_RdcInit() — The most crucial step: Removes the M7 (DID1) allocation for SAI3/SDMA3/I2C3. Remove the allocations of RDC_PDAP_SAI3, RDC_MDA_SDMA3*, RDC_PDAP_SDMA3, and RDC_PDAP_I2C3 to DID1, keeping these resources accessible to A53. B.R Re: i.MX8MP SError. remote proc starts M7 core and arecord plughw:wm8962audio,0 Hi @pengyong_zhang  Thank you very much for your guidance. Following your advice, I updated the RDC configurations to assign SDMA3 to Domain 0 (A53/Linux) and shared SAI3, I2C3, and SDMA3 permissions between Domain 0 and Domain 1. Here is the diff of the RDC changes I applied: -RDC_MDA RDC_MDA_SDMA3p DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3p DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3b DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3b DID0 0x0 0x0 -RDC_MDA RDC_MDA_SDMA3_SPBA2 DID1 0x0 0x0 +RDC_MDA RDC_MDA_SDMA3_SPBA2 DID0 0x0 0x0 -RDC_PDAP RDC_PDAP_SAI3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SAI3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_SDMA3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_SDMA3 PDAP_D0D1_ACCESS 0x0 0x0 -RDC_PDAP RDC_PDAP_I2C3 PDAP_D1_ACCESS 0x0 0x0 +RDC_PDAP RDC_PDAP_I2C3 PDAP_D0D1_ACCESS 0x0 0x0 After applying these changes, arecord works on Linux without triggering any SError, even while the M7 core is running its RTOS firmware. Thanks again for your help!
記事全体を表示
S32K3 STANDBY + FIRC + Watchdog Hello, I am trying to implement standby mode for the S32K3 series (K312) following the examples provided in the community posts by NXP. My project uses an external clock source during regular operation and configures the watchdog timer. It is my understanding from the documentation/examples that before entering STANDBY mode I must switch to using the FIRC. If I switch to FIRC before entering STANDBY, the watchdog timer triggers, resetting the MCU. Is this expected behaviour? Additionally, if I disable the watchdog, the MCU does go into a low-power state, but will not not reset from a wakeup source. Meanwhile, if I directly enter STANDBY without switching to FIRC, the watchdog does not trigger a reset and the MCU goes into a low-power state and will reset from a wakeup source, as one would expect from STANDBY. Evidently, it seems at first glance that approach 2 (not switching to FIRC) works, but I would like to clarify as I am witnessing peculiar behaviour with pad keeping. If I toggle a pad high before entering STANDBY(approach 2), regardless of whether pad keeping is enabled or disabled for the pad, it remains high after the MCU has entered STANDBY. This has me questioning if the MCU is truly entering STANDBY, or is in some intermediary state. I realize this post is rather vague - do let me know what additional context I can provide. With regards, Hareesh Re: S32K3 STANDBY + FIRC + Watchdog Hello @Hareesh_S, Firstly, before entering Standby, the system clock source must be changed to FIRC at 48 MHz because PLLDIG is not available in Standby mode. If this sequence is not followed, this may result in unexpected/undefined clock behavior.  If I switch to FIRC before entering STANDBY, the watchdog timer triggers, resetting the MCU. Is this expected behaviour? Additionally, if I disable the watchdog, the MCU does go into a low-power state, but will not not reset from a wakeup source. By default, POR_WDG is enabled for standby entry/exit sequence monitoring for stuck scenarios: Julin_AragnM_0-1785518283148.png Does this behavior happen with the provided examples in community? Are you using RTD APIs to change clock source?  S32K3 Low Power Management AN and demos Example S32K312 STANDBY wake up using CAN-0-RX and GPIO Switch DS3.5 RTD300 [RTD600 IP] S32K312EVB-Q172 Standby RAM GPIO Wake-up If I toggle a pad high before entering STANDBY(approach 2), regardless of whether pad keeping is enabled or disabled for the pad, it remains high after the MCU has entered STANDBY. This has me questioning if the MCU is truly entering STANDBY, or is in some intermediary state. 1. All pins will retain its last set states in run mode during standby mode. 2. All pins will be placed to its default states after reset event by default. PadKeeping configuration affects pin state after Standby exit sequence, in between K3's wake-up reset, and user's port initialization, in which pins may enter an uncontrollable state: Julin_AragnM_2-1785519093000.png Best regards, Julián Re: S32K3 STANDBY + FIRC + Watchdog Hello @Julián_AragónM , Apologies for my delayed response. Regarding the pad keeping behaviour - it seems I had misunderstood the intended functionality of padkeeping. I appreciate you clarifying the same. Regarding STANDBY entry - This behaviour is not replicable for the unmodified community examples. The sequence works as expected with the community examples. Additionally, I can now confirm that when switching to FIRC in my project, the MCU hardfaults, and that is why the watchdog triggers a reset. I have managed to replicate this behaviour in a blank project, but cannot figure out what the root cause is. I am attaching the project, could you please check the same and let me know what I am missing? With regards, Hareesh S Re: S32K3 STANDBY + FIRC + Watchdog Hello @Hareesh_S, I'm glad PadKeeping functionality has been cleared up. Regarding your project, after calling Clock_Ip_Init(), I can see a hardfault at Clock_Ip_SetRtcRtccClksel_TrustedCall(). After enabling PRTN1_COFB1_CLKEN[REQ34], I can change clock source through Clock_Ip_Init() API as expected.  Can you try this fix in your project?  Julin_AragnM_0-1786382290784.png Julin_AragnM_1-1786382522241.png Julin_AragnM_2-1786382602253.png Best regards, Julián Re: S32K3 STANDBY + FIRC + Watchdog Hello @Julián_AragónM  After enabling the RTC module/peripheral in the RUN domain switching to the FIRC works as expected and does not trigger a hardfault. I was not expecting RTC to be enabled mandatorily, but nevertheless, much thanks for the quick resolution!
記事全体を表示
UWB 单信标 + AoA 用于门口内外检测的建议 我正在构建一个壁挂式单锚定 UWB 系统(用于门口出口检测),需要使用到达角 (AoA) 来确定标签是在门口内还是门口外——包括已经打开的门,所以我不能使用门接触传感器进行门禁控制。 背景:我当时正在使用 Qorvo QM33120W/DW3000(2 天线 PDoA),遇到了一堵坚硬的建筑墙;由于锚点安装在约 7 英尺高的地方,并且垂直向下,即使在信号清晰、强劲的情况下,从它下面走动/绕行也会产生错误的“外部”角度承诺。 我的计划是让 UWB 天线直接朝下朝向地面,这样我就可以捕获正角度和负角度(内部和外部)的信号,以确定标签何时从内部移动到外部(出口检测)。 目前使用 Qorvo 设备时,如果我将标签保持最佳的直线方向/天线朝上,一切正常,但当移动/旋转标签(DW3000)时,即使站在同一个位置,我也开始看到不同的 AoA 值。 标志惯例问题:我期望采用一致的惯例——在内部时为正角,一旦标签越过边界进入外部,则为负角。实际上,即使我明确地还在门内,我也看到了正角度和负角度,这与标签以随机方向/速度旋转和移动有关——与实际穿过门口无关。这是我在决定购买新硬件之前,试图针对的具体症状进行设计。 我现在正在评估是否要改用恩智浦半导体(NXP)的芯片,希望听听大家的意见: Qorvo 2D AoA 板使用射频开关来捕获两个天线之间的 UWB PDoA。换用NXP SR150双接收链能否解决我的迎角跳动问题? 对于一个安装在头顶的锚点,其下方的标签正在穿过门口移动,SR150 的 2D/软件辅助 3 天线 3D AoA 模式是否足以解决前后模糊性,还是真的需要 SR250 的 3 个同步 RX 链才能获得真正的第二基线? 针对这种自上而下的顶部使用场景,有什么推荐的天线几何形状/安装方向吗? 在像这样容易产生歧义的几何结构中,SR150 的天线切换第三天线模式与 SR250 相比,有哪些实际应用经验? 谢谢。 kamaln16_0-1785454764324.png Re: UWB Single beacon + AoA for doorway inside/outside detection advice 你好, 希望你一切都好。对于使用自由旋转标签进行内外门检测的单个顶置式锚点, Trimension SR250是合适的平台,也是我们推荐的用于物联网和工业锚点设计的 UWB 产品。 提出此建议的核心原因是硬件架构。SR250 集成了 3 个同步接收路径,可实现一次 3D 迎角测量,无需外部射频开关,即可从单个测距帧中同时提供方位角和仰角。 SR250 还具备一些对这种使用场景非常有价值的额外功能: 支持360°迎角,最多可连接9根天线进行天线分集连接 用于存在检测的片上超宽带雷达(OCPD)是基于测距的穿越检测的有效补充层 兼容 FiRa 4.0 和 Aliro 1.0,确保与更广泛的 UWB 生态系统互操作性 从哪里开始 开发套件: SR250 开发板,兼容 Arduino,集成 PCB 天线,即插即用,提供测距、迎角和雷达演示功能。 软件:适用于 Zephyr OS 的 SR250 UWBIOT 合作伙伴模块和套件:TrueSense(ETNA TS 250 开发套件)、MobileKnowledge(MK UWB 套件移动版 2.0)、Amotech(SR250 集成 3D 天线模块),均可通过NXP 合作伙伴市场获取。 希望这能帮到您。 顺祝商祺! 里卡多 Re: UWB Single beacon + AoA for doorway inside/outside detection advice 谢谢Ricardo,感谢您的详细解答。 更新:我已经订购了 Murata Type2BP (SR150) 开发板和 NXP SR250UWBSHIELD 开发板。很遗憾,SR250UWBSHIELD 在我这边显示需要 14 周才能到货,所以在此期间我将开始对 SR150 进行测试,等 SR250 到货后再进行测试。 在等待期间,我想问几个后续问题: 1. SR150 与 SR250 在我特定应用中的比较:鉴于我只需要方位角(内/外),不需要仰角,除了架构差异(真正的 3 个同时接收链路 vs. SR150 的 2 个原生链路 + 可切换的第 3 个天线)之外,从 SR150 升级到 SR250 究竟有什么好处?对于单轴应用场景而言,精度/稳定性提升是否足够显著,值得等待?或者,一旦我解决了安装/多路径缓解问题,SR150 本身就能满足我的需求吗? 2. 射频切换和标签旋转:我正在尝试找出 Qorvo 硬件上一个具体症状的根本原因,如果我站在完全相同的位置,只是在 X 平面上旋转标签(位置完全没有变化),AoA 值会明显跳动,甚至看起来极性会反转。Qorvo 的 2D AoA 使用射频开关对两个天线进行时分复用,而不是同时对它们进行采样。您认为开关架构是造成这种旋转相关不稳定性的一个可能因素吗?还是说这更可能与其他因素有关(例如旋转时的标签辐射模式/偏振敏感性、多径效应等)?我正在尝试了解 SR150/SR250 的同步 RX 采样是否能够解决这个特定的症状,或者这是否是一个与芯片无关的独立问题,需要我去解决。 3. 2D 与 3D 迎角在我的使用场景中的区别:由于我只需要知道方位角(内/外),而仰角对我的应用来说没有意义,那么运行完整的 3D 迎角是否能提高精度或可靠性,或者我是否最好只配置方位角而忽略仰角?我特别想知道,即使我不使用高度来实际判断室内/室外,高度测量是否有助于区分反射/非视距信号和有效信号。 4. 功耗,2D 与 3D:这将是一个电池供电的装置。SR250 上只运行 2D 模式和运行全 3D 模式,电流消耗会有明显差异吗?因为无论哪种方式,它都有 3 个同时运行的接收链。或者说,无论我在软件中使用哪些轴,只要所有 3 个轴都处于活动状态,功耗就基本固定了吗? 5. 多径缓解措施(针对我的特定安装):信标将安装在门口上方的墙壁上,附近有一扇玻璃门,天花板距离设备大约 5 英尺。我发现我目前的 Qorvo 硬件似乎存在反射驱动的角度不稳定现象(与标签旋转有关,在天花板较高的房间里更严重,玻璃门关闭时更严重)。是否有推荐的安装方法、天线波束宽度/方向图选择,或者固件端滤波(FOM/NLoS阈值)专门用于抑制玻璃和相邻墙壁的近场反射?或者NXP SR150或SR250是否有任何功能可以抑制这个问题? 6. 基于雷达的运动门控以节省电池电量:我希望将 SR250 的片上雷达 (OCPD) 纯粹用作低功耗唤醒触发信号:保持雷达模式,仅在检测到运动时才启动全测距/AoA。如果将锚点安装在约 2 米高的门口上方,天线垂直向下,那么在设备正下方,我应该预期大致有多少运动检测范围/覆盖范围?试图根据门洞面积确定雷达的有效“尾流区”大小。我想检测人走向和远离门口时的运动情况。 再次感谢你的帮助。
記事全体を表示
Originality Signature by ntag424 Hello: Our company has signed a confidentiality agreement, but we are unsure how to implement ECDSA verification on an embedded hardware platform using the natg424 uid, public key, and the 56-byte signature obtained from Read_Sig. The documentation for AN11350 does not provide detailed steps for implementing ECDSA verification (secp224r1). Could you please tell me what resources I need to apply for to achieve this? Thank you. Re: ntag424的Originality Signature Hello @qinzhi Hope you are doing well. My apologies, the Application Note that is used as reference for NTAG Signature Validation (AN11350) is intended for other NTAG products holding 32-byte signature and different curves. Available procedure for asymmetric signature verification is described in NTAG 424 DNA and NTAG 424 DNA TagTamper features and hints, Section 7.2. However, there is no information specific to ECDSA verification as this procedure is done outside the card. I apologize again for the inconvenience. Regards, Eduardo.
記事全体を表示
CRANK、mpc5775eによるCPSのキャプチャ こんにちは、 私はNXP eTPUのCRANK機能を36-2クランクホイールで使用しています。CPS信号は、回転数(加速プロファイル)の増加に伴って生成されます。CRANKパラメータ(gap_ratio、win_ratio_normal、win_ratio_across_gap、win_ratio_after_gap、win_ratio_after_timeout)は、ファンクションセレクタに付属するExcelシートを使って計算されます。 エンジンの位置がFS_ETPU_ENG_POS_PRE_FULL_SYNCに達したら、TCR2を同期するためにfs_etpu_crank_set_sync()を一度呼びます。呼び出しの前後でTCR2の値を確認することで、同期が正しく適用されていることを確認しました。値は期待どおりに変化しています。 RPMを計算するために、FS_ETPU_CRANK_TOOTH_AFTER_GAPからCRANK状態が変化した後、fs_etpu_crank_copy_tooth_period_log()を使用して歯周期ログをコピーし、平均歯周期を計算してからRPMを計算します。最初の回転数(RPM)の値は正しく計算されています。 しかし、1回か数回転すると、CRANK機能がFS_ETPU_CRANK_ERR_TIMEOUTとFS_ETPU_CRANK_ERR_STALLを報告します。これらのエラーが発生すると同期が失われ、回転数を計算できなくなります。 混乱するのは、デバッガをリセットして同じCPS信号と設定で再度アプリケーションを実行すると、正常に動作し続けてRPM値を長期間記録できる場合もあれば、エラーがほぼ即座に現れることもあります。入力信号と構成は変更されていないのに、なぜ動作が矛盾するのか理解できません。 これはウィンドウ比率のパラメータに関連しているのでしょうか?もしSOなら、加速するクランク信号に対してどのパラメータを最初に調整すればよいでしょうか(win_ratio_normal、win_ratio_after_timeout、gap_ratioなど)。急速に加速する信号に対して、これらのパラメータを調整するための推奨手順はありますか? よろしくお願いします! Re: Capturing CPS with CRANK, mpc5775e こんにちは、 現在のところ、最も可能性の高い原因は、適用されたアクセラレーションプロファイルに対してウィンドウの余白が狭すぎるか、デバッガーのリセット後に異なる開始条件が生じる不完全な再初期化のいずれかであると考えられます。 現時点では、根本原因が確定したとは言えません。提供された情報に基づくと、CRANK機能は初期段階で同期を達成し、有効なRPM値を生成するため、基本構成は正常に機能していることがわかります。この問題は、関数がタイミングの許容範囲を失い、最終的にFS_ETPU_CRANK_ERR_TIMEOUTとFS_ETPU_CRANK_ERR_STALLを報告するときに後から発生します。 根本原因を効率的に絞り込むために、まずは2つの簡単な実験から始めます。 関連するウィンドウ比率を増やして、タイムアウト/停止状態が遅延するか解消されるかを確認してください。 加速度勾配を小さくして試験を繰り返し、元のプロファイルとの挙動を比較してください。 ウィンドウ幅を広げたり、加速ランプを緩やかにしたりすることで問題が改善される場合は、根本的な設定の問題ではなく、タイミングマージンに関連している可能性が高いと考えられます。 よろしくお願いいたします。 ピーター
記事全体を表示
ntag424によるオリジナリティシグネチャー こんにちは: 弊社は機密保持契約を締結済みですが、natg424のUID、公開鍵、およびRead_Sigから取得した56バイトの署名を使用して、組み込みハードウェアプラットフォーム上でECDSA検証を実装する方法が不明です。AN11350のドキュメントには、ECDSA検証(secp224r1)の実装に関する詳細な手順が記載されていません。この目的を達成するために必要なリソースを教えていただけますでしょうか。よろしくお願いいたします。 Re: ntag424的Originality Signature こんにちは@qinzhi あなたの調子が良いといいのですが。 申し訳ありませんが、NTAG署名検証(AN11350)の参照として使われているアプリケーションノートは、32バイト署名や異なる曲線を持つ他のNTAG製品向けに意図されています。 非対称署名検証の利用可能な手順は 、NTAG 424 DNAおよびNTAG 424 DNA TagTamperの特徴とヒント、セクション7.2に記載されています。ただし、ECDSA認証に関する具体的な情報はありません。この手続きはカードとは別に行われるためです。 ご迷惑をおかけして、重ねてお詫び申し上げます。 よろしくお願いいたします。 エドゥアルド。
記事全体を表示