LPC4088 pendrive support Hello. I am implementing USB Host functionality on the LPC4088 for pendrive support. The code works correctly on the LPC QuickStart board, but fails to enumerate devices on our custom hardware. Specifically, `USB_Host_SendControlRequest()` returns `HOST_SENDCONTROL_PipeError` instead of `HOST_SENDCONTROL_Successful` during enumeration. I suspect the issue lies within `HcdControlTransfer()`, possibly related to pipe configuration, but I have been unable to identify the root cause. Any insights would be greatly appreciated. LPC40xx

当使用 FRDM-MCXN947 的 I3C 接口进行 I2C 通信时，时钟拉伸功能失效。 您好，我目前遇到一个问题：我想使用 FRDM-MCXN947 的 I3C 接口进行 I2C 通信，但我连接的从设备在数据准备期间会出现时钟拉伸，因此我必须等待从设备释放 SCL 信号才能开始数据传输。 我尝试使用 MCXNP184M150F70RM 参考，引用文件中的可配置寄存器（例如 MCONFIG[SKEW] = 0、MCONFIG[HKEEP] = 0b11、MCONFIG[MSTENA] = 0b11），但似乎不起作用。我该如何解决这个问题？ #FRDM-MCXN947 #I3C 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） MCX N Re: When using the FRDM-MCXN947's I3C interface for I2C communication, the Clk stretching capability 嗨@kevin_Jhuang 寄存器设置目前在 I3C_MasterInit() 之前应用，因此可能会被 SDK 初始化覆盖。 请启用： masterConfig->disableTimeout = true; 然后在 I3C_MasterInit() 之后配置 MSTENA = 3、HKEEP = 3 和 SKEW = 0。请先清除相应的寄存器字段，然后再写入数据，不要使用 |=。 初始化完成后，请读取 MCONFIG 以验证设置是否仍然有效。同时提供时钟拉伸故障后立即捕获的 MSTATUS 和 MERRWARN 值。 请确认 SCL 和 SDA 是否配置为开漏工作状态，以及是否安装了外部上拉电阻。 BR 哈里

验证 csf 头文件是否与特定的拟合图像相关联。 我已经实现了安全启动，并且大致了解了 Uboot 使用 esbc_validate 所做的操作。但是，我正在尝试创建一个升级实用程序，以验证使用 cst 2.x 生成的特定头文件是否与特定的 fit（内核、dtbs、rootfs）映像相关联。 将 csf 网络安全标头放置在正确的偏移量处，并将 fit 图像放置在正确的偏移量处，启动就完全没问题了。但是，我想在将它们放置到各自位置之前先核实一下。 我知道公钥嵌入在 CSF 文件中，所以我必须把它提取出来。我之后有点困惑。我认为我需要提取 RSA 签名，并使用提取出的公钥对其进行哈希运算，而这个哈希值似乎与拟合图像有关，但它并不是拟合图像的简单哈希值？ 我已经设法从烧断的熔丝中取出了SRKH，这样我就可以进行比较了。 目前谷歌/Gemini公司提供的帮助不大。 有什么想法吗？ QorIQ LS1设备 Re: Verify a csf header file is associated with a specific fit image. 签名不仅仅是 FIT 的哈希值。对于此安全启动流程，它会验证 CSF 标头的 安全散列算法\(SHA\)-256 摘要、该标头指定的映像字节、公钥材料以及（如果使用）SG 表。验证过程还会将密钥与熔丝后的SRKH进行比对。 因此，在安装这两个文件之前，您的实用程序必须解析候选标头，使用其大小和偏移字段从候选 FIT 中选择正确的字节，计算完整签名数据的摘要，并使用已验证的公钥验证提取的 RSA 签名。如果验证通过，则该标头与经过身份验证的 FIT 字节关联。仅使用 FIT 进行 安全散列算法(SHA)-256 比较是行不通的。

MCXN947VKLT packing spec I couldn't find the packing specification for MCXN947VKLT on NXP's website. Where can I locate this document? Thank you. MCXN Re: MCXN947VKLT packing spec For MCXN947VKLT, the packing details are as follows: Packing type: Tray Tray type: Bakeable, multiple in drypack Minimum package quantity: 90 pieces Minimum order quantity: 450 pieces Package: HLQFP100, 100 terminals, 0.5 mm pitch, 14 × 14 × 1.5 mm body If you are specifically looking for the tray drawing/specification with dimensions, please note that this information is not shared publicly and needs to be requested via a Support ticket: https://support.nxp.com/s/?language=en_US Thank you. 

When using the FRDM-MCXN947's I3C interface for I2C communication, the Clk stretching capability fai Hello, I'm currently encountering a problem: I want to use the I3C interface of the FRDM-MCXN947 for I2C communication,but the slave device I'm connecting to experiences clock stretching during data preparation,so I have to wait for the slave device to release the SCL signal before data transfer can begin. I've tried using the configurable registers (such as MCONFIG[SKEW] = 0, MCONFIG[HKEEP] = 0b11, MCONFIG[MSTENA] = 0b11) from the MCXNP184M150F70RM reference file, but it doesn't seem to be working. How can I resolve this? #FRDM-MCXN947 #I3C  Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) MCXN Re: When using the FRDM-MCXN947's I3C interface for I2C communication, the Clk stretching capability Hi @kevin_Jhuang  The register settings are currently applied before I3C_MasterInit(), so they may be overwritten by the SDK initialization. Please enable: masterConfig->disableTimeout = true; Then configure MSTENA = 3, HKEEP = 3, and SKEW = 0 after I3C_MasterInit(). Please clear the corresponding register fields before writing them instead of using |=. After initialization, please read back MCONFIG to verify that the settings are still active. Also provide the MSTATUS and MERRWARN values captured immediately after the clock-stretching failure. Please also confirm that SCL and SDA are configured for open-drain operation and that external pull-up resistors are installed. BR Harry

S32K142无法关闭调试接口 你好，我使用的芯片为S32K142，FSEC配置如下： /* Flash Configuration */ .section .FlashConfig, "a" .long 0xFFFFFFFF /* 8 bytes backdoor comparison key */ .long 0xFFFFFFFF /* */ .long 0xFFFFFFFF /* 4 bytes program flash protection bytes */ .long 0xFFFF7FFF /* FDPROT:FEPROT:FOPT:FSEC(0xFE = unsecured) */ 但是断电重启后仍可以Debug，查看0x0_040C地址数据为0xFFFF7FFE，请问为什么配置未生效？ Re: S32K142无法关闭调试接口 嗨@minsky1 在 S32K1 设备上启用网络安全功能有两种方法： 直接在 startup_S32K1xx.s 文件中修改 Flash 配置字段。应用程序项目的文件。确保地址 0x40C (FSEC[高效密码学标准\(SEC\)]) 处的 FSEC 字段的最低两位设置为除 10b 以外的值，10b 是默认的不安全状态。 使用 Cyclone 等编程工具配置网络安全设置。这种方法常用于生产编程中，并且可以通过编程脚本轻松实现自动化。 另外，如果您正在使用 Lauterbach，请注意，除非发出特定命令，否则不允许修改 FSEC 字段。这是防止意外修改的保护措施。 过去曾就此话题进行过一些讨论。您可能会发现下面的帖子很有帮助，因为它们涵盖了类似的情况，并可能提供更多见解。 使用 cmm 脚本设置 S32K142 FSEC 在 s32k118 中，无法使用 T32 写入 FSEC 位设置 BR，VaneB

TJA1410の受信信号RX+EDに対してRZI復号を行うにはどうすればよいですか？ マニュアルの波形図からわかるように、RXは高インピーダンス（または0）から始まる最初の遷移を無視するため、RXは遷移を見逃し、RZI復号エラーが発生します。 NXP TJA1410について質問させてください。この場合、推奨されるデコード方法はありますか？ イーサネット Re: TJA1410 接收信号RX+ED 如何进行RZI解码？ こんにちは@li_wangさん まず、これは図11に基づく理論的な懸念なのか、それとも実装中に実際のRZIデコードエラーが見られているのか、明確にしていただけますか? 実際にエラーが確認された場合は、以下の情報を提供してください。 TRANSMITコマンドとデータ送信開始時のTX、RX、EDおよび差動線間電圧波形 デジタルPHYまたはカスタムデコード実装はTJA1410に接続されています 実装がRXを有効なものとして扱い始める時点 期待されるデータシーケンスと実際にデコードされたデータシーケンス 図11に関して、強調表示されているVLINEの遷移は、通常モードから送信モードへの遷移中に発生します。この時点でラインインピーダンスはハイZからアクティブインピーダンスに変わり、トランスミッタは差動線を駆動し始めます。この遷移の間、RX出力は明示的に未定義としてマークされます。したがって、強調表示された領域に示されている最初のVLINEの動きは、RX上のパルスによって表されなければならない有効なRZIデータ遷移として解釈されるべきではありません。 通常モードおよび送信モードでは、RXのデフォルトレベルはHIGHです。差動MDI電圧が受信機トリガー閾値を通過すると、TJA1410はRXに低パルスを生成します。この動作は、有効な受信データ間隔に適用されます。 したがって、図11はTJA1410が最初の有効なRZI遷移を無視することを示しているわけではない。トランスミッタの活性化時にRXが定義されていないことを示しています。有効なRZI復号は、RXが有効な動作区間内にある場合にのみ開始すべきであり、モード遷移による初期アナログVLINEの動きからは始めるべきではありません。 よろしくお願いいたします。 パベル

TJA1410 接收信号RX+ED 如何进行RZI解码？ 根据手册中的波形可以看到，RX 忽略了第一次又高阻（或者0）开始的跳变，导致RX少一个跳变，RZI解码出错。 想问一下NXP，TJA1410 这种情况下，有建议的解码方式吗？ Ethernet Re: TJA1410 接收信号RX+ED 如何进行RZI解码？ 你好@li_wang ， 首先，请您澄清一下，这是基于图 11 的理论问题，还是您在实现中观察到的实际 RZI 解码错误？ 如果发现实际错误，请提供以下信息： TX、RX、ED 和差分线路电压波形涵盖了传输命令和数据传输的开始阶段 连接到 TJA1410 的数字 PHY 或自定义解码实现 实现开始将 RX 视为有效值的点 预期和实际解码的数据序列 如图 11 所示，突出显示的 VLINE 转换发生在从正常模式到传输模式的转换过程中。此时，线路阻抗从高阻抗变为有源阻抗，发射器开始驱动差分线路。在此转换过程中，RX 输出被明确标记为未定义。因此，高亮区域中显示的初始 VLINE 移动不应被解释为有效的 RZI 数据转换，该转换必须由 RX 上的脉冲表示。 在正常模式和发射模式下，接收端的默认电平为高电平。当差分 MDI 电压超过接收器触发阈值时，TJA1410 会在 RX 上产生一个低电平脉冲。此行为适用于有效的接收数据间隔。 因此，图 11 并不表明 TJA1410 忽略了第一个有效的 RZI 转换。这表明在发射器激活期间未定义 RX。有效的 RZI 解码应该只在 RX 处于有效工作区间时开始，而不是从模式转换引起的初始模拟 VLINE 移动开始。 顺祝商祺！ 帕维尔

How to perform RZI decoding on the TJA1410 receiving signal RX+ED? As can be seen from the waveform in the manual, RX ignores the first transition starting with high impedance (or 0), resulting in RX missing a transition and RZI decoding error. I'd like to ask about NXP TJA1410. In this case, are there any recommended decoding methods? Ethernet Re: TJA1410 接收信号RX+ED 如何进行RZI解码？ Hello @li_wang , First, could you please clarify whether this is a theoretical concern based on Figure 11 or whether you are observing an actual RZI decoding error in your implementation? If an actual error is observed, please provide: TX, RX, ED and differential line voltage waveforms covering the TRANSMIT command and the beginning of data transmission The digital PHY or custom decoding implementation connected to the TJA1410 The point at which the implementation starts treating RX as valid The expected and actually decoded data sequence Regarding Figure 11, the highlighted VLINE transition occurs during the transition from Normal mode to Transmitting mode. At this time, the line impedance changes from High-Z to active impedance and the transmitter begins driving the differential line. The RX output is explicitly marked as undefined during this transition. Therefore, the initial VLINE movement shown in the highlighted area should not be interpreted as a valid RZI data transition that must be represented by a pulse on RX. In Normal and Transmitting modes, the default level on RX is HIGH. When the differential MDI voltage crosses the receiver trigger threshold, the TJA1410 generates a LOW pulse on RX. This behavior applies to the valid receive-data interval. Consequently, Figure 11 does not indicate that the TJA1410 ignores the first valid RZI transition. It shows that RX is not defined during transmitter activation. Valid RZI decoding should begin only when RX is in its valid operating interval, not from the initial analog VLINE movement caused by the mode transition. Best regards, Pavel

S32K142ではデバッグインターフェースを無効にできません こんにちは。私が使用しているチップはS32K142で、FSECの設定は以下のとおりです。 /* フラッシュ設定 */ 。セクション.FlashConfig、「a」 。長さ0xFFFFFFFF /* 8バイトのバックドア比較キー */ 。長さ0xFFFFFFFF /* */ 。長さ0xFFFFFFFF /* 4バイトのプログラムフラッシュ保護バイト */ 。長さ0xFFFF7FFF /* FDPROT:FEPROT:FOPT:FSEC(0xFE = 保護されていない) */ しかし、停電後や再起動後もデバッグは可能です。アドレス0x0_040Cのデータは0xFFFF7FFEです。なぜ設定が有効にならないのでしょうか？ Re: S32K142无法关闭调试接口 こんにちは、 @minsky1さん S32K1デバイスでセキュリティ機能を有効にする方法は2つあります: startup_S32K1xx.s内のフラッシュ構成フィールドを直接変更します。あなたの応募プロジェクトファイルのファイルです。アドレス0x40CにあるFSECフィールド（FSEC[SEC]）の最下位2ビットが、デフォルトの非保護状態である10b以外の値に設定されていることを確認してください。 Cycloneなどのプログラミングツールを使ってセキュリティ設定を設定しましょう。この方法は本番プログラミング時によく使われ、プログラミングスクリプトを通じて簡単に自動化できます。 また、Lauterbachを使用している場合は、特定のコマンドを発行しない限り、FSECフィールドを変更できないことに注意してください。これは、意図しない改変を防ぐための措置です。 このテーマについては過去にいくつか議論がありました。以下のThreadは似た状況を扱っており、追加の洞察を提供してくれるかもしれません。 S32K142 FSEC を cmm スクリプトを使用して設定します。 s32k118では、T32を使用してFSECビット設定を書き込むことができません。 BR、VaneB

Enable FLEXCAN for IMXRT1064 Hi,  I am working on MIMXRT1064CVJ5B, is FLEXCAN supports on these PINs  GPIO_AD_B1_12 : Chip Select GPIO_AD_B1_13 : MISO GPIO_AD_B1_14 : MOSI  GPIO_AD_B1_15 : CLK I have connected a NAND Flash on these Pin, Does any example code available ?  Re: Enable FLEXCAN for IMXRT1064 Hi  You can find the available pins for the FlexCAN modules in Table 10-1 Muxing Options, of the i.MX RT1064 Processor Reference Manual. You can also find FlexCAN examples available for the i.MX RT1064 in the SDK. I would recommend reviewing the available examples and using the one that most closely matches your application's requirements as a reference for your implementation. Best Regards, Pablo

S32K142 cannot disable debug interface Hello, the chip I'm using is the S32K142, and the FSEC configuration is as follows: /* Flash Configuration */ .section .FlashConfig, "a" .long 0xFFFFFFFF /* 8 bytes backdoor comparison key */ .long 0xFFFFFFFF /* */ .long 0xFFFFFFFF /* 4 bytes program flash protection bytes */ .long 0xFFFF7FFF /* FDPROT:FEPROT:FOPT:FSEC(0xFE = unsecured) */ However, I can still debug after power failure and restart. The data at address 0x0_040C is 0xFFFF7FFE. Why is the configuration not effective? Re: S32K142无法关闭调试接口 Hi @minsky1  There are two ways to enable the security feature on S32K1 devices: Modify the Flash Configuration Field directly in the startup_S32K1xx.s file of your application project. Make sure that the lowest two bits of the FSEC field at address 0x40C (FSEC[SEC]) are set to a value other than 10b, which is the default unsecured state. Configure the security settings using a programming tool, such as Cyclone. This method is often used during production programming and can be easily automated through programming scripts. Also, if you are working with Lauterbach, please note that it does not allow the FSEC field to be modified unless a specific command is issued. This is an protection against unintended modification. There have been a few discussions on this topic in the past. You may find the threads below helpful, as they cover similar situations and could provide additional insights. S32K142 FSEC set using cmm script In s32k118 Cant write FSEC bit Setting using T32 BR, VaneB

NCF[5]の推奨リカバリメカニズムを実装する方法 現在、FCCUを構成しており、NXPの障害マップ文書に基づいて、障害NCF[4]に対する推奨回復メカニズム（割り込みサービスルーチンで開始されるSBC開始POR回復に続く割り込み）を実装しようとしています。 私はS32K312マイクロコントローラとFS65 SBCを併用しています。コントローラーからSPIコマンドを使ってFS65 SBCにソフトウェアリセットを行い、すべての電源レールを再初期化することは可能かどうか、教えていただけますか?もし可能なら、正しい実装についてアドバイスをいただけますか? SBC_FS65_FS_SF_OUTPUT_REQUEST_ADDRレジスタのrstbビットを有効にしようと試みましたが、SBCのリセットは確認できませんでした。 この復旧メカニズムを適切に実装する方法を教えてください。 BRサンディープ・シン   Re: How to implement recommended recovery mechanism for NCF[5] こんにちは、ピーター。 上記の回復メカニズムは、S32K3リファレンスマニュアル(Rev 8, 2024年1月)に添付されたNXPの故障マップ文書に記載されています。 さらに、私たちのCASEでは電源がSBC FS65で構成されており、これはMCUの電源供給に使われているため、MCUをリセットするだけではSBCが生成する電源を安定させることはできません。 よろしくお願いします、 サンディープ・シン Re: How to implement recommended recovery mechanism for NCF[5] こんにちは、 その提案には少し戸惑っています。 割り込みサービスルーチンで開始された、SBC 開始の POR リカバリに続く割り込み。 この推奨されている復旧メカニズムは、技術的に妥当とは思えません。 NCF[4]は、MCUコア電源に影響を与える違反を含む電圧モニター故障を表します。コア電圧が有効な動作範囲を超えると、コアの正しい実行、フラッシュアクセス、SRAMアクセス、割り込みサービスルーチン自体を仮定できなくなります。したがって、ISRにSBCとのSPI通信を確立し、回復を開始することに依存することは、信頼できるセーフティ反応を提供しません。 このような障害はハードウェアセーフティパスを通じて処理されるべきです: PMC → FCCU → MC_RGM → リセット これはR3 FCCU反応に対応し、完全にハードウェアベースでソフトウェア実行に依存せずにチップ機能リセットを開始するものです。S32K3セーフティマニュアルには、R3故障に関するまさにこの挙動が説明されています。 完全なISRおよびSPIトランザクションに対して、明示的に有効なMCU実行を保証する未公開の仕組みや早期警告電圧閾値がない限り、提案された割り込みベースの復旧はアーキテクチャ的または機能安全の観点から正当化されません。 NCF[4]を割り込み後にSBC主導のPORで処理し、電圧違反後に有効なソフトウェア実行を保証するアーキテクチャ上の前提を添えて、正確な文書と改訂版を提供していただけますか? この点が明確になるまでは、割り込みによるリカバリの実装はお勧めしません。 よろしくお願いいたします。 ピーター

IMXRT1064でFLEXCANを有効にする こんにちは、 MIMXRT1064CVJ5B作業中ですが、これらのPINに対してFLEXCANのサポートがあるのでしょうか GPIO_AD_B1_12 : チップセレクト GPIO_AD_B1_13 : MISO GPIO_AD_B1_14 : MOSI GPIO_AD_B1_15 : CLK これらのピンにNANDフラッシュをコネクテッドしましたが、何か例のコードはありますか? Re: Enable FLEXCAN for IMXRT1064 こんにちは FlexCANモジュール用の利用可能なピンは、i.MX RT1064プロセッサリファレンスマニュアルの表10-1 マルチパクシングオプションで確認できます。 また、i.MX RT1064のSDK内で利用可能なFlexCANの例も見つけることができます。利用可能な例を確認し、あなたのアプリケーションの要件に最も近いものを導入の参考にすることをお勧めします。 よろしくお願いします、 パブロ

为 IMXRT1064 启用 FLEXCAN 你好， 我正在研究MIMXRT1064CVJ5B，请问这些引脚是否支持FLEXCAN？ GPIO_AD_B1_12：片选 GPIO_AD_B1_13：MISO GPIO_AD_B1_14：MOSI GPIO_AD_B1_15：时钟 我已将与非闪存芯片连接到这些引脚上，请问是否有示例代码可供参考？ Re: Enable FLEXCAN for IMXRT1064 你好 您可以在 i.MX RT1064 处理器参考手册的表 10-1 多路复用选项中找到 FlexCAN 模块的可用引脚。 您还可以在 SDK 中找到适用于 i.MX RT1064 的 FlexCAN 示例。我建议您查看现有的示例，并选择与您的应用程序要求最接近的示例作为您实现时的参考。 此致， 巴勃罗

如何实现 NCF[5] 推荐的恢复机制 我目前正在配置 FCCU，并尝试根据 NXP 故障映射文档（中断后由 SBC 发起的 POR 恢复在中断服务例程中启动）实现针对故障 NCF[4] 的推荐恢复机制。 我正在使用S32K312微控制器和FS65单板计算机。请问是否可以通过控制器向FS65单板计算机发送SPI命令进行软件RESET，以重新初始化所有电源轨？如果可以，能否提供正确的实现方法？ 我尝试启用 SBC_FS65_FS_SF_OUTPUT_REQUEST_ADDR 寄存器中的 rstb 位，但我没有观察到 SBC 复位。 请告知如何正确实施此恢复机制。 BR Sandeep Singh   Re: How to implement recommended recovery mechanism for NCF[5] 嗨，彼得， 上述恢复机制已记录在 NXP 的故障图文档中，该文档附于 S32K3 参考手册（修订版 8，2024 年 1 月）。 此外，由于我们这里使用的电源是由 SBC FS65 构建的，用于给 MCU 供电，因此单独 RESET MCU 并不能稳定 SBC 产生的电源。 此致， 桑迪普·辛格 Re: How to implement recommended recovery mechanism for NCF[5] 你好， 我对这个建议有点困惑。 中断后，SBC 发起的 POR 恢复在中断服务例程中启动。 我认为这种推荐的恢复机制在技术上似乎行不通。 NCF[4] 表示电压监测故障，包括影响 MCU 内核供电的违规行为。一旦内核电压超出其有效工作范围，就不能再保证内核、闪存访问、SRAM 访问以及中断服务例程本身的正确执行。因此，依靠 ISR 与 SBC 建立 SPI 通信并启动恢复并不能提供可靠的功能安全响应。 此类故障应通过硬件功能安全路径进行处理： PMC → FCCU → MC_RGM → RESET 这对应于 R3 FCCU 反应，该反应完全基于硬件，无需依赖软件执行即可启动芯片功能 RESET。S32K3 功能安全手册对 R3 故障的这种行为进行了详细描述。 除非存在未记录的机制或有保证的早期预警电压阈值，明确保证 MCU 对整个 ISR 和 SPI 事务的有效执行，否则从架构或功能安全的角度来看，所提出的基于中断的恢复是不合理的。 请提供确切的文档和版本说明，说明如何通过中断处理 NCF[4]，然后由 SBC 发起 POR，以及在电压违规后保证有效软件执行的架构假设？ 在这个问题得到澄清之前，我不建议通过中断来实现恢复。 顺祝商祺！ Peter

How to implement recommended recovery mechanism for NCF[5] I am currently configuring the FCCU and attempting to implement the recommended recovery mechanism for fault NCF[4] based on the NXP fault map document (Interrupt followed by SBC-initiated POR recovery initiated in the interrupt service routine). I am using the S32K312 microcontroller alongside the FS65 SBC. Could you please clarify if it is possible to issue a software reset to the FS65 SBC via SPI command from the controller to re-initialize all power rails? If so, could you advise on the correct implementation? I attempted to enable the rstb bit in the SBC_FS65_FS_SF_OUTPUT_REQUEST_ADDR register, but I did not observe an SBC reset. Please let me know how to properly implement this recovery mechanism. BR Sandeep Singh   Re: How to implement recommended recovery mechanism for NCF[5] Hi Peter, The recovery mechanism mentioned above is documented in NXP's Fault Map document, which is attached to the S32K3 Reference Manual (Rev 8, 01/2024). Additionally, since the power supplies are built up by the SBC FS65 in our case which are used to power up MCU, resetting the MCU alone will not stabilize the power supplies generated by the SBC. Best regards, Sandeep Singh Re: How to implement recommended recovery mechanism for NCF[5] Hello, I am bit confused by the recommendation. Interrupt followed by SBC-initiated POR recovery initiated in the interrupt service routine" This recommended recovery mechanism does not appear technically valid to me. NCF[4] represents voltage-monitor faults, including violations affecting the MCU core supply. Once the core voltage is outside its valid operating range, correct execution of the core, flash accesses, SRAM accesses, and the interrupt service routine itself can no longer be assumed. Therefore, relying on an ISR to establish SPI communication with the SBC and initiate recovery does not provide a trustworthy safety reaction. Such faults should be handled through the hardware safety path: PMC → FCCU → MC_RGM → reset This corresponds to an R3 FCCU reaction, which is entirely hardware-based and initiates a chip functional reset without relying on software execution. The S32K3 Safety Manual describes exactly this behavior for R3 faults. Unless there is an undocumented mechanism or a guaranteed early-warning voltage threshold that explicitly ensures valid MCU execution for the complete ISR and SPI transaction, the proposed interrupt-based recovery is not justified from an architectural or functional-safety perspective. Could you please provide the exact document and revision that requires NCF[4] to be handled by an interrupt followed by an SBC-initiated POR, together with the architectural assumption guaranteeing valid software execution after the voltage violation? Until this is clarified, I would not recommend implementing the recovery through an interrupt. Best regards, Peter

MCUXpresso 25.6:Cortex-M0+ EXC_RETURN後のGDB無限メモリ読み取りループ — 回避策:バックトレース l 環境 IDE: MCUXpresso IDE 25.6 デバッガ: GNU Arm GDB 15.2.90.20241130-git ツールチェーン: GNU Arm ツールチェーン 14.2.Rel1 ターゲット: NXP LPC845、Arm Cortex-M0+ デバッグプローブ: LinkServer を使用したオンボード LPC-Link2 ホスト: Windows 問題 SysTickからThreadモードコードへの合成例外スタックフレームを用いるCortex-M0+アプリケーションをデバッグすると、GDBは応答しなくなります。 ファームウェアは、以下の方法で例外戻りを実行します。 bx lr LR = 0xFFFFFFF9 (MSPを使ったThreadモードに戻る)。 合成例外フレームには、有効なサムモード宛先PCとxPSRが含まれています。アプリケーションは物理的ターゲット上で動作しますが、GDBは宛先関数で停止すると応答しなくなります。 症状には以下が含まれます。 可変ホバー検査が機能しなくなりました。 メモリビューには????????が表示されます。 GDBコマンドやインフォThreadは応答しなくなります。 デバッグセッションは通常、終了とクリーンアップが必要です。 例外戻り値をまたいで命令ステップ実行するのではなく、宛先にハードウェアブレークポイントを設定した場合にも、同様の問題が発生します。 再生 アプリケーションを通常通りデバッグし始めてください。 bx lr例外復帰命令の直前で停止してください。 目的関数System()に別のブレークポイントを設定します。 例外処理をスキップして戻るか、目的のブレークポイントまで続行します。 GDBは宛先に到達するが、その後応答しなくなる。 この不具合は、通常のGDB構成でも再現可能です。 遠隔プロトコルの証拠 リモートプロトコルトレースを有効にするには： set logging file gdb-remote.log set logging overwrite on set logging enabled on set debug remote 1 GDBは、リモートメモリの読み取りにおいて、同じシーケンスを繰り返し実行していることが明らかになった。 m1b4,4 -> 91010000 m1ba,4 -> 00000000 m1bc,4 -> 00000001 m1c0,4 -> f9ffffff m190,4 -> 07490868 このシーケンスは無限に繰り返される。 LinkServerはリクエストを認識し、正常に応答します。したがって、このトレースは通常の通信タイムアウトを示すものではありません。 特に、 0x1c0の応答には例外戻り値である0xFFFFFFF9が含まれている。 回避策が確認されました GDBに以下のコマンドを入力します。 set backtrace limit 1 繰り返しテストで観察された不具合を防止する。 この設定を有効にすると： デバッガーが同じ例外戻り値の境界を繰り返し越えています。 どちらのブレークポイントも正常に機能します。 可変ホバー検査は目的地で機能します。 デバッグセッションは応答性を維持しています。 この回避策は、以下の方法で構成された GDB コマンド ファイルに配置した場合にも機能します。 デバッグ構成 → GDBデバッガー → GDBコマンドファイル アプリケーションやアセンブリの改造は不要です。 追加のアイソレータ 同じターゲット、デバッグプローブ、IDEが従来のファームウェアを正常にデバッグします。 合成例外戻り値のシムを使用せずに宛先関数を呼び出す場合も機能します。 従来のSysTickハンドラでは、このような不具合は発生しません。 この問題は、合成例外リターン後の実行状態を処理するGDBに特に関連付けられているようです。 期待される動作 GDBは例外発生後も応答性を維持し、ステップ実行、レジスタ検査、メモリ検査、変数評価を可能にするべきである。 もしGDBが生成されたスタックフレームを解釈できない場合は、エラーを報告するかアンワインドを終了すべきであり、無期限に繰り返されるメモリ-読み込みシーケンスに入るべきではありません。 疑われる原因 セットバックトレース限界1の有効性は、GDBのARM Cortex-Mスタックフレームアンワインドやフレーム解析が関与していることを強く示唆しています。 正確な内部原因は特定されていない。 要求 GDBのARM Cortex-M例外フレーム処理と合成例外リターンの相互作用を調査してください。 特に、なぜデバッガが同じターゲットメモリ位置を繰り返し読み込むのか、フレームアンワインドが無限ループに入る可能性があるかどうかを明らかにします。 この回避策はデバッグ機能を復元しますが、バックトレースの深度を制限するため、有効な例外戻りシーケンスには必要ないはずです。 Re: MCUXpresso 25.6: GDB infinite memory-read loop after Cortex-M0+ EXC_RETURN — workaround: backtra コードクリップを忘れました: 0000015c: 15c: b4f0 プッシュ {r4, r5, r6, r7} 15e: 4640 mov r0, r8 160: 4649 mov r1, r9 162: 4652 mov r2, sl 164: 465b mov r3, fp 166: b40f プッシュ {r0, r1, r2, r3} 168: 4911 ldr r1、[pc、#68] @ (1b0 ) 16a: 6808 ldr r0, [r1, #0] 16c: 3001 は r0、#1 を追加します 16e: 6008 str r0, [r1, #0] 170: 2804 cmp r0、#4 172: dd03 ble.n 17c 174: f000 fa24 bl 5c0 178: f7ff ffcc bl 114 0000017c: 17c: 4d0d ldr r5、[pc、#52] @ (1b4 ) 17e: 4e0e ldr r6、[pc、#56] @ (1b8 ) 180: 4f0e ldr r7、[pc、#56] @ (1bc ) 182: b4ff プッシュ {r0, r1, r2, r3, r4, r5, r6, r7} 184: 480e ldr r0、[pc、#56] @ (1c0 ) 186: 4686 mov lr, r0 188: b500 プッシュ {lr} 18a: bd00 ポップ {pc}

使用 emcem 中提供的接口向缓存位置注入故障 你好@danielmartynek 早上好：-） 我有一个关于向缓存位置注入故障的问题： 我需要在缓存位置注入一个 2 位故障，但我不太确定参考手册中提到的具体含义，我们使用的是 NXP s32K394 微控制器： 我需要调用以下函数两次，以便将错误注入缓存，并获取缓存中如下所示的 2 位错误： 如果我的做法有误，能否请您分享一下如何进行这种注入的示例代码？目前我们的项目中使用的是 SAF 代码包，软件包，如果已经有现成的故障注入代码，请告诉我需要参考哪个文件才能使用 SAF 模块中提供的内存测试接口 (EIM) 注入各种类型的故障。 Re: Fault Injection to cache locations using an interface provide in emcem 你好@Rudved_3366 ， 我刚刚回复了你关于这个话题的第二篇帖子： https://community.nxp.com/t5/S32K/Fault-Injection-to-cache-location-using-an-interface-provide-in/td-p/2419094 BR，丹尼尔

增加MCP，直连codex进行协作 是否可以新增mcp，支持直接使用codex，或者其他的agent来操作IDE，目前已有的使用figma的方式有figma额度的限制，不是很好用