#S32K388 增强型 RX FIFO + eDMA：无需 CPU 中断的连续循环缓冲区接收 您好，NXP技术支持， 我正在使用带有FlexCAN 增强型 RX FIFO和 RTD 的S32K388 。我希望实现基于DMA的连续CAN接收，而无需任何CPU中断。 我的要求是： MCU： S32K388 CAN：传统 CAN ，CAN FD 已禁用 CAN 有效载荷： 8 字节 FlexCAN增强型RX FIFO已启用 DMA接收已启用 我需要接收任何 CAN ID的 CAN 消息，无需过滤。 我希望 DMA 将接收到的每个 CAN 帧自动传输到RAM 软件环形缓冲区中。 我不需要 FlexCAN RX 中断。 我也不希望出现 DMA 主循环完成中断。 DMA 应该继续自动运行，而无需 CPU 再次调用 FlexCAN_Ip_RxFifo()。 理想情况下，每个接收到的 FIFO 元素都应该立即触发 DMA 传输，因此我不想等待较大的 FIFO 水印。 我查看了RTD源代码。在 FlexCAN_StartRxMessageEnhancedFifoData() 函数中，我发现驱动程序对 DMA 的配置大致如下： Source address = Enhanced RX FIFO output Source transfer size = 4 bytes Source offset = 4 bytes Destination transfer size = 4 bytes Destination offset = 4 bytes Minor loop size = 80 bytes Major loop count = num_enhanced_watermark EnMajorInt = TRUE DisAutoHwRequest = TRUE 我了解到，当前的 RTD 实现执行有限的 DMA 传输后便停止，需要再次调用 FlexCAN_Ip_RxFifo()。 我的问题是： 在 S32K388 上，是否可以配置 eDMA TCD，使 FlexCAN 增强型 RX FIFO DMA 请求能够连续地将接收到的 FIFO 元素传输到循环 RAM 缓冲区中，而无需任何 CPU 中断或软件重新激活？ 具体来说，能否使用目标模数和/或其他 eDMA TCD 功能来实现这种连续环形缓冲器？ 如果可以的话，能否提供一个配置示例，或者给我推荐一个 NXP 的示例/参考实现？ 如有必要，我愿意修改 RTD FlexCAN 驱动程序或直接配置 eDMA TCD。 谢谢您！

#S32K388 拡張RX FIFO + eDMA: CPU割り込みなしで連続循環バッファ受信 NXPサポートの皆さん、こんにちは。 私はFlexCAN Enhanced RX FIFOとRTDを搭載したS32K388を使用しています。CPU割り込みなしで連続的なDMAベースのCAN受信を実現したいと考えています。 私の要望は以下の通りです。 MCU: S32K388 CAN: クラシックキャン、CAN FD無効 CANペイロード: 8バイト FlexCAN拡張RX FIFO対応 DMA受信が有効 フィルターなしで 、どのCAN IDでもCANメッセージを受け取る必要があります。 DMAが受信したすべてのCANフレームを自動的に RAMソフトウェアのリングバッファに転送したいのです。 FlexCANの受信割り込みは不要です。 DMAのメジャーループ完了割り込みも不要です。 DMAは、CPUがFlexCAN_Ip_RxFifo()を再度呼び出すことなく、自動的に実行を継続するはずです。 理想的には、受信した各FIFO要素が即座にDMA転送を引き起こすべきなので、大きなFIFOウォーターマークを待ちたくありません。 RTDのソースコードを確認しました。FlexCAN_StartRxMessageEnhancedFifoData()で、ドライバがDMAを次のように設定していることがわかりました。 Source address = Enhanced RX FIFO output Source transfer size = 4 bytes Source offset = 4 bytes Destination transfer size = 4 bytes Destination offset = 4 bytes Minor loop size = 80 bytes Major loop count = num_enhanced_watermark EnMajorInt = TRUE DisAutoHwRequest = TRUE 現在のRTD実装では、有限のDMA転送を実行した後、停止するため、FlexCAN_Ip_RxFifo()を再度呼び出す必要があると理解しています。 私の質問は次のとおりです。 S32K388上で、eDMA TCDを設定して、FlexCAN Enhanced RX FIFO DMA要求が、CPU割り込みやソフトウェアの再武装なしに、受信したFIFO要素を円形RAMバッファに継続的に転送する設定は可能でしょうか? 特に、 Destination Modulo や他のeDMA TCD機能を使えば、この連続リングバッファを実装できますか? もし可能であれば、具体的な構成を教えていただけるか、NXPの例やリファレンス実装を教えていただけませんか? 必要に応じてRTD FlexCANドライバーを修正したり、eDMA TCDを直接設定することも可能です。 よろしくお願いします！

#S32K388 Enhanced RX FIFO + eDMA: Continuous Circular Buffer Reception Without CPU Interrupts Hi NXP Support, I am using an S32K388 with the FlexCAN Enhanced RX FIFO and RTD. I would like to implement a continuous DMA-based CAN reception without any CPU interrupt. My requirements are: MCU: S32K388 CAN: Classical CAN, CAN FD disabled CAN payload: 8 bytes FlexCAN Enhanced RX FIFO enabled DMA reception enabled I need to receive CAN messages with any CAN ID, without filtering. I want DMA to automatically transfer every received CAN frame into a RAM software ring buffer. I do not want a FlexCAN RX interrupt. I also do not want a DMA major-loop-complete interrupt. DMA should continue running automatically without the CPU having to call FlexCAN_Ip_RxFifo() again. Ideally, each received FIFO element should trigger a DMA transfer immediately, so I do not want to wait for a large FIFO watermark. I checked the RTD source code. In FlexCAN_StartRxMessageEnhancedFifoData(), I found that the driver configures DMA approximately as follows: Source address = Enhanced RX FIFO output Source transfer size = 4 bytes Source offset = 4 bytes Destination transfer size = 4 bytes Destination offset = 4 bytes Minor loop size = 80 bytes Major loop count = num_enhanced_watermark EnMajorInt = TRUE DisAutoHwRequest = TRUE I understand that the current RTD implementation performs a finite DMA transfer and then stops, requiring FlexCAN_Ip_RxFifo() to be called again. My question is: Is it possible on S32K388 to configure the eDMA TCD so that the FlexCAN Enhanced RX FIFO DMA request continuously transfers received FIFO elements into a circular RAM buffer, without any CPU interrupt or software re-arming? In particular, can Destination Modulo and/or another eDMA TCD feature be used to implement this continuous ring buffer? If this is possible, could you please provide an example configuration or point me to an NXP example/reference implementation? I am willing to modify the RTD FlexCAN driver or configure the eDMA TCD directly if necessary. Thanks!

S32R264 – CLK_OUT0(CLKOUT)60MHzに制限がありますが、80MHzを出力できますか? #S32R2X 私はS32R264を使用しています。CLK_OUT0（図6-3はRMのMCB_CLKOUT_SELによるCLKOUTの選択を示しています）と、このピンでSDPLL_CLK80/AFEPLL_CLK80を80MHzで出力できるかどうかについて質問があります。 しかし、表5-3（「システムレベルのクロック周波数の最大値」）には、CLK_OUT[01]の最大周波数が60MHzと記載されていますが、この制限に関する説明はありません。 出力のうち1つにしかCMUが接続されていないことに気づきました。それが理由かもしれませんが、私はCMUを使用していません。 チャープ信号を生成する外部フロントエンドボードに80MHzのクロックを供給する必要があり、すべてのクロックソースを1つに絞りたいと考えています。 現在、100MHzの発振器を2台(MCU用にCWX813-040.0M、フロントエンド用にCWX813-100.0M)を使っています。良い独立発振器でも位相整列が不十分で信号品質を劣化させる可能性があると疑っています。私の波形生成は100 MHzのクロックから動作し、MCU内のAFEは40(320)MHzから動作しています。波形生成を80MHzに切り替え、そのクロックをMCUから取り入れて、システム全体を同期かつ同位相にしたいと考えています。 CMUが無効になっている場合、CLK_OUT0で80MHzを出力することは可能ですか？ 60MHzという制限の本当の理由は何ですか？

S32K314 HSE設置に関する問題 助けてください！公式デモプロジェクトをベースにHSEファームウェアインストーラを作成しましたが、2回リセットした後、HSEインストールアドレス0x007E0000にデータがありません。これはHSEのインストールが失敗したということでしょうか？S32のバージョンは3.6.8で、チップは...S32K314、RTDバージョン7.0.1 1131_0-1788767775138.png1131_0-1788767775138.png これはldファイルです。 1131_1-1788767805874.png1131_1-1788767805874.png これは書き換えられたIVTベクトルです。 1131_2-1788767830677.png1131_2-1788767830677.png 1131_3-1788767849116.png1131_3-1788767849116.png 1131_4-1788767872384.png1131_4-1788767872384.png 最後に、HSEインストールデモプロジェクトを添付しました。 回复： S32K314 HSE 安装问题 @VaneBこんにちは ご提案に従ってリンカー ファイルを修正し、ivt.c ファイルのすべてのエントリをコメントアウトしました。プログラムを 2 回再起動した後、デバッグ モードで status = Hse_Ip_GetHseStatus(0u) の状態を確認しました。ステータス値は 1001 0110 0000 でしたが、9 番目のビットが 0 だったので、HSE が正常にインストールされなかったことを示しています。さらに、バージョン情報も取得できませんでした。srvResponse = Hse_Ip_ServiceRequest(0u, u8MuChannel, &request, &pHseSrvDesc) の戻り値は 0xaa55a11e です。 次のように 1131_1-1788838145743.png1131_1-1788838145743.png 1131_2-1788838165453.png1131_2-1788838165453.png 1131_3-1788838180700.png1131_3-1788838180700.png 1131_4-1788838213520.png1131_4-1788838213520.png Re: S32K314 HSE 安装问题 こんにちは@杨工1131 いくつか気づいた点があります。 リンカファイル内のコメントによると、HSEファームウェアはブロック0に配置されるべきです。しかし、現在HSE_BINARYに割り当てられているアドレスはブロック1に属しています。次のように設定する必要があります HSE_BINARY (R) : ORIGIN = 0x00400000 PFlash領域はブロック1から開始する必要があります。 int_pflash : ORIGIN = 0x00500000, LENGTH = 0x00300000 - __HSE_CODE_SIZE /* 4096KB - __HSE_CODE_SIZE (sBAF + HSE) */ 提案として、ハードコードされたアドレスを使う代わりに、HSE_FW_ADDR を次のように定義することができます。 #define HSE_FW_ADDR (__HSE_BIN_START) 別途ivt.cファイルを作成する必要はありません。画像ベクトルテーブル構造は、 Project_Settings → Startup_Code → startup_cm7.sで既に定義されています。 IVTに関しては、S32K3xxリファレンス・マニュアル改訂版12のセクション32.5.3を参照すると、CM7_2開始住所の後に続く記述は以下の通りです。 .long 0xffffffff /* Offset 0x20: Reserved */ .long LC_CONFIG_ADDR /* Offset 0x24: Lifecycle configuration pointer */ .long CM7_3_VTOR_ADDR /* Offset 0x28: CM7_3 Start address */ .long HSE_FW_ADDR /* Offset 0x2C: Reserved */ コードについては、例と同じ構造を使っているので、その部分で問題はないと思います。 BR、VaneB

Deadtime Correction Hi NXP Community, I am looking for some clarification regarding the PWM-X deadtime correction feature. From the documentation, I understand that PWM-X can modify the PWM pulses based on the current/load condition. However, I am not clear about how the PWM pattern is generated and how the required feedback signal is connected and routed. In my application, the switches and current-sensing circuitry are external to the MCU: Is the sensed current signal expected to be connected directly to an MCU pin? Or should it first go through LPCMP and then be internally routed to PWM-X through TRGMUX or another internal connection? What is the expected signal path and configuration for this feature? I have attached an image from the NXP reference design/documentation showing the slightly decaying output waveform obtained across the load. What I am particularly trying to understand is the PWM pulse pattern used to generate this waveform. The waveform shown in the reference design is the resulting waveform at the load/power stage. However, the PWM signal generated by the MCU will pass through the gate driver and switching stage, so the PWM signal itself will not have the same shape as the waveform shown. PWM-X generated pulses → gate driver/power stage → resulting waveform across the load Specifically, I would like to understand how PWM-X determines the pulse width/duty cycle and timing required to obtain the shown output waveform, including how the deadtime correction is applied. Is there any reference design, application note, example code, or reference software where this PWM-X feature is implemented? An example showing the PWM configuration, pulse pattern, pin configuration, internal signal routing, and required external circuitry would be very helpful. FlexPWM Synchronization I also have a question regarding FlexPWM synchronization. Can the synchronization signal be generated internally by another peripheral, or does it have to originate from an external MCU pin? For example, can a signal generated by eMIOS be internally routed to the FlexPWM synchronization input? Any example or clarification regarding the internal routing/configuration would be very helpful. Thanks in advance. Best regards, Ganesh

S32K314 HSE 安装问题 求助！我参考官方演示项目编写了HSE固件安装程序，但执行两次复位后，HSE安装地址0x007E0000处没有任何数据。这是否意味着HSE安装失败了？S32 版本为 3.6.8，芯片为 S32K314，RTD 版本为 7.0.1 1131_0-1788767775138.png1131_0-1788767775138.png 这是 ld 文件 1131_1-1788767805874.png1131_1-1788767805874.png 这是重写后的IVT向量 1131_2-1788767830677.png1131_2-1788767830677.png 1131_3-1788767849116.png1131_3-1788767849116.png 1131_4-1788767872384.png1131_4-1788767872384.png 最后，我附上我的 HSE 安装的demo项目。 回复： S32K314 HSE 安装问题 @VaneB 你好 我根据你的建议修改修改了链接器文件，并将ivt.c文件全部注释掉，重新启动程序两次过后，通过调试模式观察status = Hse_Ip_GetHseStatus(0u)的状态status的值 1001 0110 0000，但是第9位为0，说明HSE并未安装成功？而且获取不到任何版本信息，srvResponse = Hse_Ip_ServiceRequest(0u, u8MuChannel, &request, &pHseSrvDesc)，srvResponse 的返回值为0xaa55a11e； 如下 1131_1-1788838145743.png1131_1-1788838145743.png 1131_2-1788838165453.png1131_2-1788838165453.png 1131_3-1788838180700.png1131_3-1788838180700.png 1131_4-1788838213520.png1131_4-1788838213520.png Re: S32K314 HSE 安装问题 嗨@杨工1131 我有几点看法： 根据链接器文件中的注释，HSE 固件应该放在 Block 0 中。但是，当前分配给 HSE_BINARY 的地址属于 Block 1。应该配置为 HSE_BINARY (R) : ORIGIN = 0x00400000 PFlash 区域应从 Block 1 开始： int_pflash : ORIGIN = 0x00500000, LENGTH = 0x00300000 - __HSE_CODE_SIZE /* 4096KB - __HSE_CODE_SIZE (sBAF + HSE) */ 建议不要使用硬编码地址，而是将 HSE_FW_ADDR 定义为： #define HSE_FW_ADDR (__HSE_BIN_START) 无需创建单独的 ivt.c 文件。图像矢量表结构已在Project_Settings → Startup_Code → startup_cm7.s中定义。 关于 IVT，如果您参考 S32K3xx 参考手册第 12 版第 32.5.3 节，CM7_2 起始地址之后的条目如下： .long 0xffffffff /* Offset 0x20: Reserved */ .long LC_CONFIG_ADDR /* Offset 0x24: Lifecycle configuration pointer */ .long CM7_3_VTOR_ADDR /* Offset 0x28: CM7_3 Start address */ .long HSE_FW_ADDR /* Offset 0x2C: Reserved */ 关于代码，我看到你使用了与示例相同的结构，所以我认为这部分不会有任何问题。 BR，VaneB

死时间校正 NXP社区的各位好， 我想了解一下PWM-X 死区时间校正功能的相关情况。 根据文档，我了解到 PWM-X 可以根据电流/负载情况修改 PWM 脉冲。但是，我不清楚 PWM 模式是如何生成的，以及所需的反馈信号是如何连接和路由的。 在我的应用中，开关和电流检测电路都位于MCU外部： 感知到的电流信号是否需要直接连接到MCU引脚？ 或者它应该先经过LPCMP ，然后通过TRGMUX或其他内部连接内部路由到 PWM-X？ 此功能的预期信号路径和配置是什么？ 我附上了一张来自 NXP 参考设计/文档的图片，显示了负载上略微衰减的输出波形。 我特别想了解的是用于生成该波形的PWM脉冲模式。 参考设计中所示的波形是负载/功率级产生的波形。但是，MCU 生成的 PWM 信号会经过栅极驱动器和开关级，因此 PWM 信号本身的形状不会与所示波形相同。 PWM-X 生成的脉冲 → 栅极驱动器/功率级 → 负载两端的最终波形 具体来说，我想了解 PWM-X 如何确定获得所示输出波形所需的脉冲宽度/占空比和定时，包括如何应用死区时间校正。 是否有任何参考设计、应用笔记、示例代码或参考软件实现了此 PWM-X 功能？提供一个示例，展示 PWM 配置、脉冲模式、引脚配置、内部信号路由和所需的外部电路，将非常有帮助。 FlexPWM同步 我还有一个关于FlexPWM同步的问题。 同步信号能否由其他外设在内部生成，还是必须来自外部MCU引脚？ 例如， eMIOS生成的信号能否内部路由到 FlexPWM 同步输入？ 任何关于内部路由/配置的示例或说明都将非常有帮助。 先行致谢。 此致， 象头神

デッドタイム補正 こんにちは、NXPコミュニティの皆さん、 PWM-Xのデッドタイム補正機能について、いくつか説明を求めています。 ドキュメントによると、PWM-Xは電流や負荷の状態に基づいてPWMパルスを修正できると理解しています。しかし、PWMパターンがどのように生成され、必要なフィードバック信号がどのように接続・ルーティングされるのかはよくわかりません。 私のアプリケーションでは、スイッチと電流検出回路はMCUの外部にあります: 検出された電流信号は直接MCUのピンに接続される予定ですか? それとも、まずLPCMPを経由してから、 TRGMUXまたは別の内部接続を介してPWM-Xに内部的にルーティングされるべきでしょうか？ この機能における想定される信号経路と構成はどのようなものですか？ 負荷全体でわずか に減衰する出力波形 を示すNXPの**リファレンス・デザイン**/**ドキュメント**の画像を添付しました。 私が特に理解しようとしているのは、この波形を生成するために使用されるPWMパルスパターンです。 リファレンス・デザインに示されている波形は、負荷/電力段階での得られる波形です。しかし、MCUで生成されるPWM信号はゲートドライバとスイッチングステージを通過するため、PWM信号自体は示された波形とは異なる形状になります。 PWM-Xは負荷全体→ゲートドライバー/パワーステージ→パルスを生成し、その結果として波形を生成します 具体的には、PWM-Xが、図示された出力波形を得るために必要なパルス幅／デューティサイクルとタイミングをどのように決定するのか、また、デッドタイム補正がどのように適用されるのかを理解したいと考えています。 このPWM-X機能が実装されている リファレンスデザイン、アプリケーションノート、例コード、リファレンスソフトウェア などはありますか?PWM構成、パルスパターン、ピン配置、内部信号ルーティング、および必要な外部回路を示す例があると非常に役立ちます。 FlexPWM同期 FlexPWMの同期についても質問があります。 同期信号は他のペリフェラルから内部的に生成できるのでしょうか、それとも外部のMCUピンから発信しなければならないのでしょうか? 例えば、 eMIOS で生成された信号を内部的にFlexPWM同期入力にルーティングすることは可能でしょうか? 内部ルーティング／設定に関する例や説明があれば大変助かります。 よろしくお願いいたします。 よろしくお願いします、 ガネーシャ

S32R264 – CLK_OUT0 (CLKOUT) 限制为 60 MHz，我可以输出 80 MHz 吗？ #S32R2X 我使用的是S32R264。我有一个关于 CLK_OUT0 的问题（图 6-3 显示了通过 RM 中的 MCB_CLKOUT_SEL 选择 CLKOUT），以及是否可以在该引脚上以 80 MHz 的频率输出 SDPLL_CLK80/AFEPLL_CLK80。 然而，表 5-3（“最大系统级时钟频率”）指出 CLK_OUT[01] 的最大频率为 60 MHz，但没有解释此限制的原因。 我注意到只有一个输出端连接了 CMU——也许这就是原因，但我不用 CMU。 我需要为产生啁啾信号的外部前端板提供 80 MHz 的时钟信号，并且我希望所有信号都使用同一个时钟源。 目前我有两个独立的 100 MHz 振荡器（CWX813‑040.0M 用于 MCU，CWX813‑100.0M 用于前端）。我怀疑即使是性能优良的独立振荡器，也可能由于相位不一致而降低信号质量。我的波形生成器运行在 100 MHz 时钟频率下，而 MCU 内部的 AFE 运行在 40 (320) MHz 时钟频率下。我想将波形生成频率切换到 80 MHz，并从 MCU 获取该时钟信号，以便整个系统同步且同相。 如果 CMU 被禁用，是否可以在 CLK_OUT0 上输出 80 MHz 信号？ 60 MHz 频率限制的真正原因是什么？

S32R264 – CLK_OUT0 (CLKOUT) limitation to 60 MHz, can I output 80 MHz? #S32R2X I am using S32R264. I have a question about CLK_OUT0 (Figure 6-3 shows CLKOUT selection via MCB_CLKOUT_SEL in RM) and the possibility to output SDPLL_CLK80/AFEPLL_CLK80 at 80 MHz on this pin. However, Table 5‑3 ("Maximum system level clock frequencies") says the max frequency for CLK_OUT[01] is 60 MHz, with no explanation for this restriction. I noticed only one output has a CMU attached – maybe that's the reason, but I don't use CMU. I need to provide 80 MHz to an external Frontend board that generates Chirp, and I want a single clock source for everything. Currently I have two separate 100 MHz oscillators (CWX813‑040.0M for MCU, CWX813‑100.0M for Frontend). I suspect that even good independent oscillators may degrade signal quality due to lack of phase alignment. My waveform generation runs from the 100 MHz clock, while the AFE inside MCU runs from 40 (320) MHz. I would like to switch waveform generation to 80 MHz and take that clock from MCU, so the whole system is synchronous and in phase. Is it possible to output 80 MHz on CLK_OUT0 if CMU is disabled? What is the real reason for the 60 MHz limit?

IMXRT1024でヒューズを焼損させずにHABをテストする 署名のないledのblinkyコードを使ってHAB監査API(報告状況と報告イベント情報)を実装しました。EVKボードは開いており、ヒューズも焼けていません 署名なしイメージ(CSF=0) - HABが4イベント情報で失敗 署名画像 - HAB パス0イベント情報 なので、ボードでもオープンHAB認証が実行されているのでイベント情報が見られると仮定しました。 しかし今回は同じIVT(CSF=0)でプロジェクトファームウェアを使い、同じHAB監査を実施しました 署名なし画像 - 0 イベント情報 のHABパス リードされた点滅ログ(署名なし): RVTヘッダー 0x 2002c0: tag=0xdd len=0x 038 par=0x43 HAB:RVTバージョン=0x 40305 居住区:report_status() = 0x33(HAB_FAILURE) HAB: config = 0xf0(HAB_CFG_OPEN) HAB: state = 0x66(HAB_STATE_NONSECURE) HAB: event[0], 8バイト HAB: hdr: tag=0xdb len=0x 0 8 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x22(HAB_INV_ADDRESS) context=0x a(HAB_CTX_AUTHENTICATE) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 8 43 33 22 a 0 HAB: event[1], 20バイト HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) コンテキスト=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 0 60 0 10 0 0 0 0 20 HAB: event[2], 20バイト HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 20 0 0 0 1 HAB: event[3], 20バイト HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) コンテキスト=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 0 60 0 20 0 0 0 4 HAB: VERDICT = 4 イベント情報 記録済み -- 上記のデコード済みフィールドを参照 私のプロジェクトファームウェア(署名なし) HAB: RVTヘッダー 0x002002c0 HAB: tag=0xdd len=0x0038 par=0x43 HAB:RVTが確認され有効 居住区:RVTバージョン=0x00040305 居住区:report_status() = 0xf0 HAB: config = 0xf0 HAB: state = 0x66 HAB: 監査イベント情報やクエリなし... HAB: report_event(idx=0) 0x33返されました(イベント情報やクエリなし) HAB: VERDICT = PASS(監査イベント情報なし) なぜ違いがあるのか Re: Test HAB on IMXRT1024 without burning fuses こんにちは、 @Abhay2080 さん。 ご連絡ありがとうございます！LED点滅コードが入っているSDK版と、画像作成に使われているSPT版の両方をいただけますか? ご辛抱いただきありがとうございます！ すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

CIRサンプル・トゥ・タップ・インデックス・マッピングおよびSR150におけるファーストパス後のセカンダリーピークに関する質問 こんにちは、 私は以下のデバイス、SDK、ファームウェアを使用しています。 ・対象デバイス：村田製作所製 2BP EVK型（NXP Trimension SR150） ・SDKバージョン：v05.11.05 ・ファームウェア：PNP_RhodesV4_SE_v05.11.05.bin SR150から取得したCIRデータに関して、2つ質問があります。 1. CIRサンプルとタップ指数の関係 SR150から取得された16のCIRサンプルと対応するTap Indexとの関係について、説明していただけますか? 私の理解では、16個のCIRサンプル（cir[0]からcir[15]まで）には、それらの絶対タップインデックスを直接示す情報は含まれていません。 cir[0]に対応するタップインデックスを特定する方法、または計算式はありますか？ また、診断情報で利用可能なファーストパスインデックスと配列インデックスcir[0]からcir[15]との関係についても理解したいと思っています。 例えば、CIRサンプリングウィンドウがFirst Path Indexを基準に決定される場合、First Path Index cir[0]の前後に何タップが対応しているかを知りたいです。 2. 第一道の直後に観測された二次峰 CIRを調べる中で、検出された第一経路の約3〜4サンプル後に比較的明確な二次ピークが現れるケースを観察しています。 添付図は、この動作の一例を示しています。 この例では、主要なCIRピークはタップインデックス834付近で観測され、別の局所的なピークは、約3タップ後のタップインデックス837付近で現れます。図中の赤い円で示されているのが、二次ピークである。 20260907.png20260907.png この二次ピークの可能な原因を説明していただけますか? 特に、これはSR150の内部相関器処理による既知または予想される応答、例えば送信・受信パルスの自己相関特性や相関応答のサイドローブなどである可能性はありますか? サポートにあらかじめ感謝いたします。 よろしくお願いいたします。 Re: Questions about CIR Sample-to-Tap Index Mapping and Secondary Peak after First Path on SR150 こんにちは、@Ricardo_Zamora さん。 ご回答とSR150のサポート経路の明確化に感謝します。 詳細な情報はNDAの下で公開できないことを理解しています。 これらの技術的な質問については、適切なモジュールパートナーまたは直接の担当者に連絡します。 改めて、サポートとご指導に感謝いたします。 よろしくお願いいたします。 Re: Questions about CIR Sample-to-Tap Index Mapping and Secondary Peak after First Path on SR150 こんにちは、 あなたの調子が良いといいのですが。ご不便をおかけして申し訳ありませんが、この製品の情報はNDA(秘密保持契約)に基づいており、公開されていません。 チップについての詳細は、代理店ネットワークで利用可能な当社の代理店のいずれかにお問い合わせください。NXPですか?または、このデバイスを手に入れるのを手伝った直接の連絡先がいれば、ぜひ連絡してください。 もし当社のUWB製品に関する情報をお探しの方やこのテクノロジに興味がある方は、パートナー(Trimension UWB Partners)のこれらの開発キットとモジュールをご確認いただくことをお勧めします。 これらのキットやモジュールに興味がある場合は、直接彼らに相談してプロセスやサポートを受けられるかを知る必要があります。なぜなら、このテクノロジのサポートは彼らを通じて行われるからです。 ドキュメントとソフトウェアは対応するUWBモジュールパートナーによって配布されます。モジュールを選択すると、パートナーのページに案内され、データシート、アプリケーションノート、必要なイネーブルメントにアクセスできます よろしくお願いいたします。 リカルド

Test HAB on IMXRT1024 without burning fuses I have taken unsigned led blinky code and implemented HAB audit API (report status and report event). EVK board is open and fuses not burnt Unsigned image(CSF=0) - HAB fail with 4 events Signed image - HAB pass 0 events  So i assumed that even board is open HAB authentication runs and hence i can see events. But now i taken project firmware with same IVT (CSF=0) and i implemented same HAB audit but this time Unsigned image - HAB pass with 0 events Led blinky logs (unsigned): RVT header at 0x 2002c0: tag=0xdd len=0x 038 par=0x43 HAB: RVT version = 0x 40305 HAB: report_status() = 0x33(HAB_FAILURE) HAB: config = 0xf0(HAB_CFG_OPEN) HAB: state = 0x66(HAB_STATE_NONSECURE) HAB: event[0], 8 bytes HAB: hdr: tag=0xdb len=0x 0 8 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x22(HAB_INV_ADDRESS) context=0x a(HAB_CTX_AUTHENTICATE) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 8 43 33 22 a 0 HAB: event[1], 20 bytes HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 0 0 0 0 20 HAB: event[2], 20 bytes HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 20 0 0 0 1 HAB: event[3], 20 bytes HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 20 0 0 0 0 4 HAB: VERDICT = 4 EVENT(S) LOGGED -- see decoded fields above but  my  project firmware(unsigned) HAB: RVT header at 0x002002c0 HAB: tag=0xdd len=0x0038 par=0x43 HAB: RVT found and valid HAB: RVT version = 0x00040305 HAB: report_status() = 0xf0 HAB: config = 0xf0 HAB: state = 0x66 HAB: querying audit events... HAB: report_event(idx=0) returned 0x33 (no events or query HAB: VERDICT = PASS (no audit events logged) Why there is a difference  Re: Test HAB on IMXRT1024 without burning fuses Hi @Abhay2080 , Thanks for the reaching out! May I have the sdk version that has the led blinky code and the SPT version used for building the image?  Thank for your patience! Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

关于 SR150 上 CIR 样品到抽头索引映射和第一路径后次峰的问题 您好， 我使用的设备、SDK 和固件如下： ・目标设备：村田 Type 2BP EVK（NXP Trimension SR150） ・SDK 版本：v05.11.05 ・固件：PNP_RhodesV4_SE_v05.11.05.bin 关于从 SR150 获得的 CIR 数据，我有两个问题。 1. CIR 样品与敲击指数的关系 请您解释一下从 SR150 获得的 16 个 CIR 样本与相应的 Tap Index 之间的关系？ 据我了解，16 个 CIR 样本（cir[0] 到 cir[15]）不包含直接指示其绝对 Tap Index 的信息。 是否有方法或公式来确定哪个 Tap Index 对应于 circ[0]？ 我还想了解诊断信息中可用的第一路径索引与数组索引 cir[0] 到 cir[15] 之间的关系。 例如，如果 CIR 采样窗口是相对于第一路径索引确定的，我想知道第一路径索引 cir[0] 之前或之后有多少个抽头。 2. 在第一条路径之后不久观察到的次峰 在检查 CIR 时，我观察到一些案例，在检测到的第一路径之后大约 3-4 个样本（TAP）处出现了一个相对明显的次峰。 附图展示了这种行为的一个例子。 在这个例子中，主要的 CIR 峰值出现在 Tap Index 834 附近，而另一个局部峰值出现在 Tap Index 837 附近，大约在 3 taps 之后。图中红色圆圈标出了次峰。 20260907.png20260907.png 请问您能否解释一下造成这个次峰的可能原因？ 具体来说，这是否可能是 SR150 内部相关器处理引起的已知或预期响应，例如发射/接收脉冲的自相关特性或相关响应的旁瓣？ 感谢您提前给予的支持。 顺祝商祺！ Re: Questions about CIR Sample-to-Tap Index Mapping and Secondary Peak after First Path on SR150 嗨@Ricardo_Zamora ， 感谢您的回复，并感谢您澄清了SR150的支持途径。 我明白详细信息受保密协议约束，不能公开分享。 我会联系相应的模块合作伙伴或我们的直接联系人来解答这些技术问题。 再次感谢您的支持和指导。 顺祝商祺！ Re: Questions about CIR Sample-to-Tap Index Mapping and Secondary Peak after First Path on SR150 你好， 希望你一切都好。很抱歉给您带来不便，但由于该产品的信息受保密协议（NDA）约束，因此不对外公开。 如需了解有关该芯片的更多信息，请联系我们代理商网络|NXP中的一位代理商。或者，如果您有任何直接联系人曾帮助您获得此设备，请与他们联系。 如果您正在寻找有关我们 UWB 产品的信息，或者您对这项技术感兴趣，我建议您查看我们合作伙伴（ Trimension UWB 合作伙伴）提供的这些开发套件和模块。 如果您对这些套件/模块感兴趣，您需要直接与他们联系，了解流程以及他们能够提供的支持，因为这项技术的支持途径是通过他们。 文档和软件由相应的UWB模块合作伙伴分发。选择模块后，您将被引导至我们合作伙伴的页面，您可以在该页面访问数据表、应用笔记和所需的启用信息。 此致， 里卡多

Questions about CIR Sample-to-Tap Index Mapping and Secondary Peak after First Path on SR150 Hi, I am using the following device, SDK, and firmware: ・Target device: Murata Type 2BP EVK (NXP Trimension SR150) ・SDK version: v05.11.05 ・Firmware: PNP_RhodesV4_SE_v05.11.05.bin I have two questions regarding the CIR data obtained from the SR150. 1. Relationship between CIR samples and Tap Index Could you please clarify the relationship between the 16 CIR samples obtained from the SR150 and the corresponding Tap Index? As I understand it, the 16 CIR samples, cir[0] through cir[15], do not contain information that directly indicates their absolute Tap Index. Is there a way, or a formula, to determine which Tap Index corresponds to cir[0]? I would also like to understand the relationship between the First Path Index available in the diagnostic information and the array indices cir[0] through cir[15]. For example, if the CIR sampling window is determined relative to the First Path Index, I would like to know how many taps before or after the First Path Index cir[0] corresponds to. 2. Secondary peak observed shortly after the First Path When examining the CIR, I have observed cases where a relatively distinct secondary peak appears approximately 3–4 samples (taps) after the detected First Path. The attached figure shows an example of this behavior. In this example, the main CIR peak is observed around Tap Index 834, while another local peak appears around Tap Index 837, approximately 3 taps later. The secondary peak is highlighted by the red circle in the figure. 20260907.png20260907.png Could you please clarify the possible cause of this secondary peak? In particular, could this be a known or expected response caused by the SR150's internal correlator processing, such as the autocorrelation characteristics of the transmitted/received pulse or sidelobes of the correlation response? Thank you in advance for your support. Best regards, Re: Questions about CIR Sample-to-Tap Index Mapping and Secondary Peak after First Path on SR150 Hi @Ricardo_Zamora, Thank you for your response and for clarifying the support path for the SR150. I understand that the detailed information is under NDA and cannot be shared publicly. I will contact the appropriate module partner or our direct contact regarding these technical questions. Thank you again for your support and guidance. Best regards, Re: Questions about CIR Sample-to-Tap Index Mapping and Secondary Peak after First Path on SR150 Hello, Hope you are doing well. Sorry for the inconvenience this might cause you but as the information of this product it's under NDA (Non-Disclosure Agreement) the information it's not public. For more information about the chip could you please contact one of our distributors available in the Distributor Network|NXP? Or if you have any direct contact who helped you getting this device, please contact them. If you are looking for information about our UWB products or you are interested in this technology, I would recommend you check these Development Kits and Modules from our Partners (Trimension UWB Partners). In case you are interested in one of these Kits/Modules, you would need to go directly with them to know the process and the support that they can provide them, as the support path for this technology is through them. The documentation and software are distributed by the corresponding UWB Module partner. By selecting a module, you will be guided to our partner’s page where you can access datasheets, application notes, and the required enablement Regards, Ricardo

在不烧断熔丝的情况下测试 IMXRT1024 上的 HAB 功能 我使用了未签名的 LED 闪烁代码，并实现了 HAB 审计 API（报告状态和报告事件）。EVK板开路，熔丝未烧断。 无符号镜像（CSF=0）- HAB 失败，共发生 4 个事件 签名图像 - HAB 通过 0 事件 所以我假设即使板处于打开状态，HAB 认证也会运行，因此我可以看到事件。 但是现在我使用了相同的 IVT (CSF=0) 项目固件，并实施了相同的 HAB 审计，但这次是 未签名图像 - HAB 通过，事件数为 0 LED闪烁日志（未签名） ： RVT 标头位于 0x2002c0：标签=0xdd 长度=0x038 参数=0x43 HAB：RVT 版本 = 0x 40305 HAB：report_status() = 0x33(HAB_FAILURE) HAB：配置 = 0xf0(HAB_CFG_OPEN) HAB：状态 = 0x66(HAB_STATE_NONSECURE) HAB：事件[0]，8 字节 HAB：hdr：标签=0xdb 长度=0x08 参数=0x43 HAB：状态=0x33(HAB_FAILURE) 原因=0x22(HAB_INV_ADDRESS) 上下文=0xa(HAB_CTX_AUTHENTICATE) 引擎=0x0(HAB_ENG_ANY) HAB：原始数据：db 0 8 43 33 22 a 0 HAB：事件[1]，20 字节 HAB：hdr：标签=0xdb 长度=0x014 参数=0x43 HAB：状态=0x33(HAB_FAILURE) 原因=0xc(HAB_INV_ASSERTION) 上下文=0xa0(HAB_CTX_ASSERT) 引擎=0x0(HAB_ENG_ANY) HAB：原始数据：db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 0 0 0 0 20 HAB：事件[2]，20 字节 HAB：hdr：标签=0xdb 长度=0x014 参数=0x43 HAB：状态=0x33(HAB_FAILURE) 原因=0xc(HAB_INV_ASSERTION) 上下文=0xa0(HAB_CTX_ASSERT) 引擎=0x0(HAB_ENG_ANY) HAB：原始数据：db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 20 0 0 0 1 HAB：事件[3]，20 字节 HAB：hdr：标签=0xdb 长度=0x014 参数=0x43 HAB：状态=0x33(HAB_FAILURE) 原因=0xc(HAB_INV_ASSERTION) 上下文=0xa0(HAB_CTX_ASSERT) 引擎=0x0(HAB_ENG_ANY) HAB：原始数据：db 0 14 43 33 c a0 0 0 0 0 0 60 0 20 0 0 0 0 4 HAB：结果 = 4 个事件已记录 -- 请参阅上面的解码字段，但 我的项目固件（未签名） HAB：RVT 标头位于 0x002002c0 HAB：标签=0xdd 长度=0x0038 参数=0x43 HAB：RVT已找到且有效 HAB：RVT 版本 = 0x00040305 HAB：report_status() = 0xf0 HAB：配置 = 0xf0 HAB：状态 = 0x66 HAB：正在查询审计事件... HAB：report_event(idx=0) 返回 0x33（无事件或查询） HAB：结果 = 通过（未记录任何审计事件） 为什么会有差异 Re: Test HAB on IMXRT1024 without burning fuses 你好@Abhay2080 ， 感谢您的联系！请问能否提供包含LED 闪烁代码的 SDK 版本以及用于构建镜像的 SPT 版本？ 感谢您的耐心等待！ 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

[SPSDK][i.MX95] nxpele 读取公共熔丝失败 您好， 我正在研究如何在 IMX95 19x19 EVK 板上启用安全启动。我已经使用 SPSDK 成功对我的镜像进行了签名。现在，在写入熔丝之前，我想使用 `nxpele` 读取它们，但我遇到了以下错误。 ``` $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-熔丝 --index 136 SPSDK解析错误：SPSDK：响应中的消息大小无效：0x4 请查看调试日志文件：/home/user/.local/state/spsdk/3.11.0/log/debug.log 获取更多信息 ``` 日志中显示以下内容： ``` $ tail -60 /home/user/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"响应中的消息 SIZE 无效：{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 调试：spsdk：***************************************************（自启动以来已耗时 206 毫秒，spsdk_logger.py:212） DEBUG:spsdk:* SPSDK 调试日志记录已启动 2026-09-03 15:58:44 * (自启动以来耗时 207 毫秒，spsdk_logger.py:213) 调试信息：spsdk：* SPSDK 版本：3.11.0* (自启动以来耗时 207 毫秒，spsdk_logger.py:215) 调试信息：spsdk：* Python 版本：3.14.4* (自启动以来耗时 207 毫秒，spsdk_logger.py:216) 调试：spsdk：* 操作系统版本：Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * （自启动以来耗时 208 毫秒，spsdk_logger.py:217） DEBUG:spsdk:* 最后一条命令：['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-熔丝', '--index', '136'] * (自启动以来已过去 208 毫秒，spsdk_logger.py:218) 调试：spsdk：***************************************************（自启动以来已运行 208 毫秒，spsdk_logger.py:219） 跟踪：spsdk.uboot.uboot：Uboot写入 -> 无效（自开始以来已耗时 210 毫秒， __init__ .py:50） 调试：spsdk.uboot.uboot：Uboot读取直到 <- => (自启动以来已过去 210 毫秒，uboot.py:271) 调试：spsdk.uboot.uboot：正在检查如果串口控制台因发送无效命令而打开：“无效\r\n未知命令‘无效’ - 请尝试‘帮助’\r\nu-boot=>”（自启动以来 224 毫秒，uboot.py:209） 调试：spsdk.utils.database：当前数据库指纹哈希值：f0f0598d4e6ae6c755d693693f232e30537cfb3b（自启动以来耗时 226 毫秒，database.py:1967） 调试信息：spsdk.utils.database：已加载从缓存读取数据库：/tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache（自启动以来耗时 226 毫秒，database.py:1976） 调试：spsdk.utils.misc：正在加载从 /usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml 读取文本文件（自启动以来耗时 226 毫秒，misc.py:312） 信息：spsdk.ele.ele_comm：ELE通信器在 mimx9596 中使用 92800000 地址处的 196608 B 大小的缓冲区，版本：最新目标。 调试：spsdk.ele.ele_comm：ELE消息 0x92800000 0x30000 0602971788000000 (自启动以来已过去 245 毫秒，ele_comm.py:502) 跟踪：spsdk.uboot.uboot：Uboot写入 -> ele_message 0x92800000 0x30000 0602971788000000 (自开始以来耗时 246 毫秒， __init__ .py:50) 调试：spsdk.uboot.uboot：Uboot读取直到 <- => (自启动以来 246 毫秒，uboot.py:271) 调试：spsdk.ele.ele_comm：原始ELE消息输出： ele_message 0x92800000 0x30000 0602971788000000 060497e1d60000000000000000000200u-boot=> (自启动以来 256 毫秒，ele_comm.py:422) 调试：spsdk.ele.ele_comm：已剥离输出：060497e1d600000000000000（自启动以来耗时 256 毫秒，ele_comm.py:460） 调试：spsdk.apps.utils.utils：SPSDK：响应中的消息大小无效：0x4（自启动以来耗时 257 毫秒，utils.py:182） 回溯（最近一次调用）： 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py”，第 172 行，包装纸 retval = function(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”，在 safe_main 函数的第 2189 行 sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 1631 行，在__call__ 返回 self.main(*args,**kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 1552 行，主线 rv = self.invoke(ctx) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 2032 行，在 invoke 中 返回 _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 1415 行，在 invoke 中 返回 ctx.invoke(self.callback,**ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py”，第 910 行，在 invoke 中 返回回调函数(*args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py”，第 46 行，在 new_func 中 返回 f(get_current_context().obj, *args, **kwargs) 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”，第 575 行，在 cmd_read_common_fuse 中 ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py”，第 588 行，在 ele_read_common_fuse 中 ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py”，第 519 行，在 send_message 函数中 msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”，第 1235 行，在 decode_response 中 super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ 文件“/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py”，第 346 行，在 decode_response 中 raise SPSDKParsingError(f"响应中的消息 SIZE 无效：{hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: 响应中的消息大小无效: 0x4 ``` 注：我使用的是 `SPSDK 3.11.0` 我已在 SPSDK 的 GitHub 页面上创建了一个 issue： https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614 非常感谢您的帮助。 谢谢！ BR， Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 嗨joanxie 我使用的是 Linux 电路板支持包 版本 LF6.18.20_2.0.0 (yocto wrynose) 以下是 nxpele get-info 的输出结果 $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails 请问您执行此命令时使用的是哪个 EL 固件版本？让我再确认一下。

i.MX RT1176 – FlexIO2パラレル受信：達成可能な最大シフトクロックは？わずか約48 MSPSしか到達しなかった iMXR1176 SDK 25.09.00 Manifest 3.15.0 ゴール i.MX RT1176に搭載されているLTC2164 16ビットADCからデータを取得しています。データパスは次のとおりです。 LTC2164（フルレートCMOS出力）→FlexIO2（パラレルRX）→eDMA→外部SDRAM ハードウェアのセットアップ LTC2164フルレートCMOS出力モードで構成され、外部100MHz発振器(100MSPS、16ビット並列)でクロックされます。 ADCデータ出力D0–D15はGPIO_AD_00...GPIO_AD_15。 ADC CLKOUT+はGPIO_AD_30に接続され、FlexIOタイマークロック(外部ピンクロックソース)として使用されました。 ソフトウェアのセットアップ FlexIO2は並列レシーバとして構成され、データはシフター7にラッチされます。シフター7から>0は、DMA要求が主張される前に32バイトバッファリングされるようにチェーンされています。 kDmaRequestMuxFlexIO2Request0Request1によってトリガーされたeDMAは、ピンポン（スキャッター/ギャザー）モードで2つのTCDを使用します。各メジャーループ完了時、つまり16384サンプルごとに割り込みが発生します。 FlexIO2の機能クロック：120MHz。 バスクロック（eDMA/SEMC側）：240MHz。 問題 100 MSPS の場合、16384 サンプルの処理には163.84 µsかかるはずです。連続する 2 つの DMA 割り込み間の時間を測定 (GPIO トグル + オシロスコープ) すると、常に338 µsという結果が得られ、これは約 2.06 倍です。 これは約48 MSPSの実効持続レートに相当し、ボトルネックはADCやSDRAMではなくFlexIO側にあることを示唆している。 質問 RT1176の並列受信モードにおけるFlexIOの最大シフトクロック周波数に関する公式な文書はありますか？RMやデータシートにはそのような数値は見つかりませんでした。 タイマークロックのソースが外部ピンの場合、FlexIOの機能クロックと外部シフトクロックの比率はどのようになりますか？私のFlexIOクロック（120MHz）は、入力される100MHzクロックのわずか1.2倍ですが、それで十分でしょうか？それとも、入力同期ロジックには2倍または4倍が必要ですか？ ほぼ正確な×2の比率を考えると、これはFlexIOタイマーがクロックの両端で減少している(TIMMPの慣例)によるもので、タイマー比較値が実質的にスループットを半分に減らしているのではないでしょうか? この部分でのFlexIO + eDMAの最大現実的な持続スループットについてのガイダンスがあれば、非常に助かります。なぜなら、別のペリフェラルに移行するか外部FIFOに切り替えるかを判断するからです。 よろしくお願いいたします。 通信・制御(I3C |I2C |SPI |FlexCAN |イーサネット |FlexIO) Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached こんにちは、ご返信ありがとうございます。確かに望ましい性能は達成できましたが、Flexioペリフェラルの推奨クロック周波数を最大を超えたことでしかできませんでした。具体的には、120MHzでクロックを設定するのではなく、100MSpsの取得には200MHz以上のクロック速度が必要ですが、120MHz構成ではクロックエッジがミスされます。問題は、200 MHzで動作しているにもかかわらず(リファレンスマニュアルには最大120 MHzと記載されていますが)、温度条件や生産バッチごとに安定して動作する保証がないことです。 Re: i.MX RT1176 – FlexIO2 parallel receive: maximum achievable shift clock? Only ~48 MSPS reached こんにちは、@azed38 さん。 外部ピンをクロックソースとして使用した場合、わずかな同期レイテンシが発生することに注意してください。RMのセクション67.3.3.2によると、このレイテンシは0.5から1.5 FlexIOクロックサイクルの範囲です。 Habib_MS_1-1788818202534.pngHabib_MS_1-1788818202534.png FlexIOとDMAで達成可能な最大スループットに関しては、FlexIOとDMAの性能テストは存在しません。しかし AN12686 、FlexIOとDMAを用いた並列通信実装を示しているため、あなたのユースケースに関連する指針となるかもしれません。 BR ハビブ

MCXW727CMFTBT — 出厂空白设备上的 SWD 连接失败（2 台设备，故障相同） 我们无法与任何MCXW727CMFTBT 样品（2 个单元，定制板）建立 SWD 调试连接，而完全相同的探针/电缆/设置却能立即连接到其他方面完全相同的板（相同的原理图，相同的物料清单，只有 MCU 不同）上的 MCXW716C。 元件： MCXW727CMFTBT，HVQFN-48封装，日期代码9D2604，批号PF2R73.00；板：定制PCB（10引脚Cortex调试SWD，无ISP按钮），出厂空白/从未编程； SDK： MCUXpresso SDK 26.06.00 — 应用程序构建/链接正常，故障仅在调试连接阶段出现。 症状 使用 NXP LinkServer 25.12.83 和正版 SEGGER J-Link Plus 均出现完全相同的故障：   LinkServer: Error: Wire Ack Fault - target connected? Ed:02: Failed on connect: Ee(42). No connection to chip's debug port J-Link: device MCXW727C_M33_0 / connect (VTref correctly read at 3.025V) ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF LinkServer 自身的 MCXW7XX 预连接脚本 (LS_preconnect_MCXW7XX.scp) 会自动发出调试会话请求 — 但仍然失败。nxpdebugmbox (SPSDK) 手动启动调试会话也失败，出现相同的 WIRE ACK FAULT 错误。 已经排除 探头/电缆/适配器：已确认工作正常（同样的配置连接到MCXW716C也没问题） MCU 端的 VDD_IO / P3V3：~3.3V，正确 SWDIO/SWDCLK 连续性：良好 VDD_CORE（内部 低压差线性稳压器(LDO)）：1.065V，在范围内 RESET_b 处于静止状态，电缆拔出：读取0V而不是预期的内部上拉 ~3.3V（参考）。手册第22.3.1节）— 两个单元 连接尝试期间，强制外部将 RESET_b 设置为 3.3V（VTref 读取正确为 3.025V）：无变化，仍然失败，并出现相同的错误：DM-AP IDCODE 错误 0xFFFFFFFF 在两台独立的物理设备/两块独立的电路板上均可复现。 相关帖子 这里报告了完全相同的错误（DM-AP IDCODE 0xFFFFFFFF），设备名称相同，但情况不同（板卡工作正常，但在擦除/重新编程周期后损坏）： FRDM-MCXW72 不再连接。我们的设备从未进行过任何刷机，因此如果像该帖子所暗示的那样与 NBU/核心状态有关联，那么它显然也会影响客户从未触碰过的设备。 问题 对于早期生产的 MCXW727CMFTBT（批号 PF2R73.00），是否存在任何已知的勘误/启动配置要求/默认生命周期状态，导致在标准调试邮箱程序之外的空白设备上阻止 SWD 操作？ 两个单元的 RESET_b 在静止状态下读数均为 0V（与文档中记录的内部上拉电阻相反）——是该批次产品的制造问题，还是上电时会有其他因素驱动该引脚？ 针对这种情况，有没有不需要基于UART的ISP（我们的板子没有板载USB-UART桥接器）的推荐恢复方法？ 乐意根据要求提供完整日志、示波器捕获或其他任何有用的信息。 协议：BLE -> 连接性 协议：Thread Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 感谢您的快速跟进！ 为了澄清，我们使用两种探针分别进行了测试，每种探针都使用各自合适的工具——没有将 LinkServer 与 J-Link 探针混用： NXP MCU-Link Pro ，通过LinkServer 25.12.83访问，通过 MCUXpresso for VS Code 调试/闪存集成（它会在底层启动 LinkServer 的 gdbserver/flash-programmer）。这是我们日常的正常工作安排。 结果：线路确认故障 - 目标已连接？/ Ed:02: 连接失败: Ee(42)。无法连接到芯片的调试端口，即使 LinkServer 自动运行其 MCXW7XX 特定的预连接脚本（LS_preconnect_MCXW7XX.scp，该脚本会发出调试会话请求）时也是如此。 一个独立的、正品的SEGGER J-Link Plus （固件 V11.00）+ J-Link Adapter CortexM（20 针 → 10 针 0.05 英寸），通过J-Link Commander V9.74直接访问（而不是通过 LinkServer）。 结果：错误：检测到错误的 DM-AP IDCODE：连接时为 0xFFFFFFFF，VTref 已正确读取为 3.025 V。 我们专门进行了第二次测试，以排除任何 LinkServer/MCU-Link 特有的问题。使用完全相同的 J-Link Plus + 适配器 + 电缆 + 实验室电源设置，仅将目标板更换为我们的 MCXW716C 型号（PCB 相同，只有 MCU 不同）， J-Link Commander 连接成功并识别出 Cortex-M33 内核——因此确认探针、电缆、适配器和工具工作正常；故障似乎是 MCXW727C 部件/板特有的。 我们还没有专门尝试过 J-Flash 或 LinkFlash，只尝试过 J-Link Commander（连接）和 LinkServer 的内置“调试”和“恢复”闪存编程器模式——如果这有助于进一步缩小问题范围，我们很乐意尝试其中任何一个。 与我们联系，如果需要提供任何其他信息或日志。 顺祝商祺！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@Rwaka ，希望你一切都好。 为了更好地了解您观察到的现象，请您确认一下，在每种情况下，您是否都使用了外部 J-Link 调试器？或者您是否也尝试过使用 MCU-Link Pro？ 此外，请提供您用于通过 SWD 访问的工具（LinkFlash、J-Flash、J-Link Commander），因为 Linkserver 是用于启动和管理 NXP 调试探针的 GDB 服务器的实用程序（例如，因此，MCU-Link Pro），预计 Linkserver 不会检测到 J-Link 探针。J-Link Plus 探针只能与 J-Link Commander/J-Flash 工具一起被检测到和使用。