请求 AFT05MP075N 的 Gerber 文件 你好， 我正在使用 AFT05MP075N 设计 VHF/UHF 功率放大器。我从 AFT05MP075N 产品页面获得了 DXF 参考 PCB 文件，但我需要 450–520 MHz 宽带参考板的完整 Gerber 文件包。据我了解，这些资料以前是应客户要求提供的。我需要帮助获取这些文件。 谢谢 射频 Re: Requesting Gerbers for AFT05MP075N 你好， 请注意，NXP 不提供此产品的 Gerber 文件。我们提供的是 DXF 文件，您可以在产品页面的“设计资源”部分找到它。 由此给您带来的不便，我们深表歉意，并感谢您的理解。

BCTU 控制模式和触发模式下 ADC 噪声的差异 你好， 我正在开发一个使用[S32k322]的应用程序，其中我使用eMIOS 定时器每 100 µs 触发一次BCTU来读取模拟数据。 我发现两种 BCTU 模式之间存在一种奇怪的现象： 控制模式：当 ADC CTU 模式设置为控制模式时，ADC 转换完全稳定。通过 FreeMASTER 读取的数据干净，没有噪声或故障。 触发模式：当我将 ADC CTU 模式切换到触发模式（保持 100 µs eMIOS 触发不变）时，采样模拟数据变得嘈杂，并在 FreeMASTER 中出现明显的毛刺。 触发模式是否需要特定的架构配置、时序约束或寄存器设置（例如触发延迟、FIFO 配置或时钟同步）来防止出现这种噪声？ 感谢您的帮助。 ADC CTU 模式输出：触发模式 ADC CTU 模式输出：控制模式 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Stark_ 请您分享一下测试项目，我这边会进行测试。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Senlent ， 谢谢你的回复。我的ADC时钟频率为160MHz，我的ADC配置和寄存器值附在下面。 钟 ADC配置 ADC CTU 模式输出：触发模式 ADC CTU 模式输出：控制模式 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Stark_ 根据您提供的配置截图，存在一些配置问题，特别是模块时钟和校准时钟的分频比。 ADC时钟配置必须严格按照下表执行。 请修改后再测试一次。 Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode 嗨@Senlent 我已附上测试代码。 是否可以对某些选定的通道（ADC_Instance0 和 ADC_Instance1）进行 BCTU 和正常转换？

S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 程序运行时没有进入中断，没调用pit_notifaction 软件环境 S32DS 3.6.0  RTD 6.0.0 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 有在函数内部增加断点进行测试，函数没有被调用，可能的原因有哪些呢？计数器在正常计数，没有进中断。 不同软件版本会有影响吗？ Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 你好@Finnc  目前，我无法访问 S32K311 主板。不过，我在 FRDM-A-S32K312 上测试了相同的配置和代码，并确认 PitNotification 函数被调用，且计数器如预期般递增。 您能否在通知函数内部设置一个断点，以验证该函数是否被调用？ BR、VaneB Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 全速运行时没有进入pit_notifaction，PitCount值一直为0，暂停时寄存器的参数如图所示。 是否和时钟配置有关，配置如下： Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 你好@Finnc  我已经使用 S32K311EVB 在本地测试了您的代码，一切运行正常。 为了排除与您的自定义硬件相关的任何问题，请尝试将时钟源切换为 FIRC，并观察行为是否有所变化。 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 你好@Finnc  如您代码中所示，计数器仅在调用 PitNotification 时才会递增。这表明 PIT 中断已正确触发。 为了获得更简单、更可见的测试，可以使用 printf 在 PITNotification 函数中输出计数器值。如果您能看到打印出的数值，这将进一步证实中断正在按预期执行。 例如，我是这样实现的： 此外，如果您在配置 printf 时需要帮助，请参考主题“如何在 S32DS 3.5 中使用 printf 函数？”。 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 你好@Finnc  看来问题可能与软件无关；相反，它可能与您的定制板有关。您是否有其他搭载 S32K311 设备的板可以用来进行相同的测试以作比较？ Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 使用内部时钟时也无法进入pit_notifaction，此外通讯中断及其他中断也没办法正常运行，我用S32K312测试相同的程序及配置，是可以正常运行的 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 暂时没有其他搭载 S32K311 设备的板，同一块板试了几块都是相同的问题。其他只有S32K312芯片测试相同的程序及配置，是可以正常运行。未找到K311异常原因 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 你好@Finnc  由于代码在我这边使用 FRDM-A-S32K312 和 S32K31XEVB-Q100 都能按预期运行，而且在你那边使用 S32K312 也能正常运行，因此问题可能与软件无关。 根据你描述的情况，这可能与硬件有关。然而，如果没有进一步分析，很难确定确切的根本原因。参考 S32K31XEVB-Q100 原理图和 S32K3xx 微控制器硬件设计指南文件（包含在 S32K3 通用硬件设计包中）可能会有所帮助，以便将您的定制板与推荐的设计实践进行比较。 如果您认为问题可能与 MCU 本身有关，请联系您的 NXP 代表或您购买零件的代理商以获得进一步帮助。 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 在测试的时候，在Pit_notifaction函数中增加LED反转，发现程序下载完成后，需给板子重新上电，LED灯会闪烁，说明进入了中断，但是每次下载完成后都需要重新上电才能正常运行，没办法进入debug调试 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 你好@Finnc  你试过使用其他调试器吗？另外，您还在使用最初分享的那段代码吗？

KW47 NBU 编程和升级 您好： 我想了解如何对KW47 NBU进行编程和升级。希望步骤能更详细一些。 谢谢！ Re: KW47 NBU programming and upgrade 您好： 非常感谢您的支持。我现在可以通过您提供的方法更新nbu固件。 我发现您提供的方法似乎没有包含通过固件更新NBU的方法？例如，如果我的设备已经上市，需要更新NBU版本，我应该如何操作？ 谢谢！ Re: KW47 NBU programming and upgrade 你好，希望你一切都好。 您可以参考AN14796 从 KW45 迁移到 KW47 的指南，第 6.2 节“在 KW47 中加载 NBU 固件”。 本文档将介绍几种更新 KW47 的 NBU 的方法（以 KW47-EVK 为例演示），包括 blhost、安全配置工具和 LinkServer，您可以选择最适合您开发的方法。每种方法的详细步骤也包含在内。 希望这能帮到你！如果您还有其他问题，请告诉我。 此致， 安娜·索菲亚。 Re: KW47 NBU programming and upgrade 你好， ROM引导加载程序具有固件更新功能，可用于更新主闪存以及无线电闪存固件。 对于现场 NBU 更新，工作流程通常遵循以下顺序：应用程序存储更新映像并将相应的元数据写入用户 IFR0 OTACFG 区域，然后触发系统重置，以便 ROM 引导加载程序可以接管并执行无线电固件更新。 更多信息请参阅KW47 安全参考手册第 4.2.6 节“固件更新功能”和第 4.2.2.3 节“空中 (OTA) 更新配置”。 此致， 安娜·索菲亚。

[S32K324 / 定制板] HSE 固件已安装 (0x4039C028=1) 但初始化失败 (0x4038C107=0) 大家好， 我正在寻求有关 S32K324 定制板上 HSE 固件初始化无法完成的问题的建议。 1. 开发环境 MCU：S32K324（定制板） HSE固件：s32k3x4_hse_fw_1.5.0_2.55.0_pb250130.bin.pink 调试器：S32DS + T32 (Trace32) 2. 进度和状态登记册 已成功在 UTEST 区域 (0x1B000000) 中编程 HSE FW 使用标志。 已将粉色图像二进制文件下载到闪存中。 执行上电复位（POR）后，状态寄存器如下： 0x4039C028 (HSE GPR): 0x01 (安装已确认) 0x4038C107 (HSE_STATUS_INIT_OK): 0x00 (启动过程中停止) 3. 问题 我想请教各位专家以下问题： 我首先应该检查什么？ 由于安装成功但初始化失败，是否有任何特定的寄存器（例如，故障状态）或硬件信号需要检查以找出确切的原因？ 自定义板环境是否会影响初始化失败？ 由于我使用的是定制板，我怀疑硬件差异（例如，初始晶振频率）或主核心（M7）的早期时钟（PLL）配置代码可能会干扰 HSE 启动序列。如果这是一个已知问题，能否指导我推荐的启动顺序（例如，在进行任何时钟设置之前轮询 INIT_OK 标志）或可能的解决方案？ 任何线索都将对我们大有帮助。感谢您的支持！ Re: [S32K324 / Custom Board] HSE FW Installed (0x4039C028=1) but Init Failed (0x4038C107=0) 您好， 非常感谢您提供的清晰指导。 首先，我使用演示应用程序进行固件安装，然后在系统启动状态下转储 MU 和 HSE GPR 寄存器值。如果这些注册地址有任何错误，请告知我。 结果如下： 1. MU0 寄存器（基地址：0x4038C000）     2. HSE GPR 寄存器（基地址：0x4039C000）   请您审核一下这些数值好吗？我非常希望您能提供专业意见，帮我判断这些是否表明存在具体的错误原因，例如时钟配置冲突或固件认证失败。 再次感谢您的时间和支持！ Re: [S32K324 / Custom Board] HSE FW Installed (0x4039C028=1) but Init Failed (0x4038C107=0) 请问您能否提供以下信息？ MU寄存器、FSR、GSR等： HSE GPR3：

S32K358 eMIOS ISRが85℃で停止 親愛なるNXPサポートチームへ、 S32K358において、約85℃の温度試験中に問題が発生しています。   私たちのアプリケーションでは6つのeMIOSチャネルを使用し、それぞれが200Hzの周波数で両方のPWMエッジで割り込みを生成するように設定されています。   85°Cでは、MCUが時々1つのeMIOS ISR内に閉じ込められることがあります。ISRは終了しません。コードがeMIOSレジスタを読み取り割り込みフラグを確認するためですが、フラグは0(ファイルEmios_Mcl_Ip_Irq.c)です 😞   もし (0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。S) & (uint32)eMIOS_S_FLAG_MASK))   デバッグの結果、問題が発生するとeMIOSのベースアドレスを含む変数がNULL(Emios_Ip_paxBase)であることに気づきました。アプリケーションが正しく動作すれば、同じポインタが有効で、eMIOSレジスタも正しく読み込まれます。 ある条件下では、ISR実行中にeMIOSペリフェラルへの参照が破損またはクリアされているようです。   スタックオーバーフロー、メモリ破損、同時アクセス、ISR処理、温度関連の挙動など、既知の問題や根本原因について何か兆候はありますか?   よろしくお願いいたします。 サイモン Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、ベインさん。 現在、RTD 7.0.0を使用しています。 Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @simon98さん どのRTDバージョンを使用していますか？追加情報があれば助かります。 また、RTD バージョン 6.0.0 より前のバージョンでは、関数スコープ内の静的変数のメモリ マッピングが正しくないことに関連する既知の問題がありました (ARTD-159985)。 この問題は、Emios_Mcl_Ip.c で定義されている変数 Emios_Ip_paxBase に関する問題です。また、Emios_Mcl_Ip_Irq.c には、一貫性のない初期化特性が割り当てられています。詳細はソフトウェアリリースノートに記載されています。 BR、VaneB Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @simon98さん 観察された挙動を再現できる簡単なアプリケーションを教えていただけますか?また、カスタムボードを使っているのか評価ボードなのか確認してもらえますか? さらに、問題が85°Cで発生していることを確認するための検査方法について教えていただけますか? Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @simon98さん この情報を提供していただき、誠にありがとうございます。 コードがEMIOS1_1_IRQで詰まっているようで、あなたの設定からeMIOS 1チャンネル19に対応しているため、この特定の部分に分析を絞り込んでみます。 デバッグを簡素化し、他のモジュールからの干渉を排除するために、このeMIOS構成のみを含む最小限のテストプロジェクトを作成してください。これにより、問題の動作を特定し、根本原因をより深く理解するのに役立ちます。参考までに、スレッド S32M27x/S32K3 – eMIOSの利用法で示されている例を確認できます。 同じ現象は依然として発生しますか？また、評価ボードがあるなら、同じコードをそこで試せたら素晴らしいです。 Re: S32K358 eMIOS ISR stuck at 85°C こんにちは、 @VaneB さん。 現在、カスタムボードでS32K358を使ってこれらのeMIOS_1チャンネルを使って200HzのPWMを生成しています:ch3、ch9、ch11、ch12、ch13、ch19。コードはSIMulinkを使用して生成されます 自作の基板を85℃の恒温恒湿槽に入れたところ、しばらくすると動作が停止する現象が見られました。 S32DS (3.6.7) でデバッグしていたときISR(EMIOS1_1_IRQ)に組み込まれていることが分かり、エントリ/エグジット近くのカスタムカウンターやEmios_Pwm_IrqHandler・Emios_Pwm_Ip_IrqHandler関数にも組み込み、どのコード部分が実行されているかを検出しました。 いくつかのテストの結果、内部で詰まったときに static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { /* エミオスチャネルでイベントが発生しているか確認してください */ もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。S) & (uint32)eMIOS_S_FLAG_MASK)) { /* EMIOSチャネルでイベントが発生しているか確認してください */ もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))) { Emios_Pwm_Ip_IrqHandler(インスタンス、チャネル); } そうでなければ { /* 何もしない - 偽の中断があった場合は直ちに戻ってください */ } } }   if条件: もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。S) & (uint32)eMIOS_S_FLAG_MASK))   なぜなら、何らかの理由でEmios_Ip_paxBase[インスタンス]が0を指すため、常に0です。つまり、誰も割り込みフラグをクリアしていないため、割り込みフラグは脱出できないループに入ってしまいます。   この問題を検出するために使用したコードは以下のとおりです。 static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { uint32_t s; uint32_t c; uint32_t s_flag; uint32_t s_ovr; dbg_pwm_last_instance = インスタンス; dbg_pwm_last_channel = チャネル; dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[インスタンス]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。S;     dbg_emiosipirq_static_state1++; /* もし (インスタンス == 1) { スイッチ(チャネル) { CASE 16: dbg_emiosipirq_static_cnt_ch16++; 休憩;             CASE 17:                 dbg_emiosipirq_static_cnt_ch17++;                 休憩; ケース18: dbg_emiosipirq_static_cnt_ch18++; 休憩;             case 19:                 dbg_emiosipirq_static_cnt_ch19++;                 休憩; デフォルト： dbg_emiosipirq_static_cnt_oth1++; 壊す; } } それ以外 ヤージュ dbg_emiosipirq_static_cnt_oth2++; } */ /* Lettura reale dei registri vista dal codice */ /* s = Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。S; c = Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。C; s_flag = s & (uint32)eMIOS_S_FLAG_MASK; s_ovr = s & (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s = s; dbg_pwm_last_c = c; dbg_pwm_flag_mask = (uint32)eMIOS_S_FLAG_MASK; dbg_pwm_ovr_mask = (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s_and_flag = s_flag; dbg_pwm_last_s_and_ovr = s_ovr; if (s_flag != 0U) ヤージュ dbg_pwm_s_flag_yes++; } それ以外 ヤージュ dbg_pwm_s_flag_no++; } if (s_ovr != 0U) ヤージュ dbg_pwm_s_ovr_yes++; } それ以外 ヤージュ dbg_pwm_s_ovr_no++; } if ((s_flag == 0U) && (s_ovr != 0U)) ヤージュ dbg_pwm_flag0_ovr1_count++; } そうでなければ、((s_flag != 0U) && (s_ovr != 0U)) ヤージュ dbg_pwm_flag1_ovr1_count++; } else if ((s_flag != 0U) && (s_ovr == 0U)) ヤージュ dbg_pwm_flag1_ovr0_count++; } それ以外 ヤージュ dbg_pwm_flag0_ovr0_count++; } */ /* EMIOSチャネルでイベントが発生しているか確認してください */ もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。S) & (uint32)eMIOS_S_FLAG_MASK)) { dbg_emiosipirq_static_state2++; /* EMIOSチャネルでイベントが発生しているか確認してください */ もし(0U != ((Emios_Ip_paxBase[インスタンス]->CH.UC[チャネル]。C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))) { dbg_emiosipirq_static_state3++; Emios_Pwm_Ip_IrqHandler(インスタンス、チャネル); } そうでなければ { dbg_emiosipirq_static_state4++; /* 何もしない - 偽の中断があった場合は直ちに戻ってください */ } } そうでなければ { dbg_emiosipirq_static_state5++; Emios_Pwm_Ip_IrqHandler(インスタンス、チャネル); Emios_Pwm_Ip_IrqHandler(1, 19); } } Emios_Ip_paxBaseが指すべきアドレスを格納したグローバル変数は以下のとおりです。 dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[インスタンス]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[インスタンス]->CH。UC[チャネル]。S; また、NVICレジスタの実行時を読み取るカスタムコードも入れました。添付すると、Thread、ジェネラルレジスタ、NVICレジスタと変数式、EMIOSレジスタ、6つのテスト用レジスタが入ったファイルがあります。 また、この動作をテストするために使用したS32DSプロジェクトをプライベートメッセージでお送りします。 これらの情報が役に立てば幸いです。何かご不明な点がございましたら、いつでもお気軽にお問い合わせください。 BR、 サイモン

IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized Dear NXP team, We have iMx8M+ based custom board and using BT & WiFi ( module AW-XB583MA-PUR from Azurawave) over PCIe and UART respectively. We are facing issue while BT initializing which takes around 50-60 seconds (fixed duration always) to get response on 1st HCI reset command over UART. We checked/debugged it with Azurawave team and they suggested also to check w/ NXP (as it seems to them) that this might be NXP side issue. Below are the SoC connections to module: NXP: UART1_RXD <---> Module: UART TXD NXP: UART1_TXD <---> Module: UART RXD NXP: UART3_TXD <---> Module: UART RTS NXP: UART3_RXD <---> Module: UART CTS Device tree changes we did: &uart1 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart1>; assigned-clocks = <&clk IMX8MP_CLK_UART1>; assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>; /*fsl,uart-has-rtscts;*/ status = "okay"; }; pinctrl_uart1: uart1grp { fsl,pins = < MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140 MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140 MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140 MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140 >; }; i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized Hello @hiteshviradiya  Hope you are doing very well. Could you please share details on device tree? I just can see the Pinmux code. Also, details about the BSP version you are using and the driver used to connect to the WIFI module. Best regards, Salas. Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized Dear @Manuel_Salas, We are using customized buildroot (version 2024.08) w/ Kernel version: 6.6.36. I already shared BT related device tree code along with Pinmux but sharing it again as below: &uart1 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart1>; assigned-clocks = <&clk IMX8MP_CLK_UART1>; assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>; fsl,uart-has-rtscts; status = "okay"; }; pinctrl_uart1: uart1grp { fsl,pins = < MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140 MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140 MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140 MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140 >; }; Let me know if you want any other specific device tree node.

LPC55S28 VBAT_PMU Current Draw I have a PCB with the schematic below. I have a coin cell battery for backup when the PCB main power is removed. From my understanding, the VBAT_PMU (Pin 51) on the MCU is dedicated for the Always‑On (PD_AON) domain.  When I measure the current draw of the battery, with no main power (only the battery), I get around 102uA. Which is far more than expected for the RTC to consume. Event if D12 is removed. Vbat only is connected to the VBAT_PMU pin and nothing else.  What is the expected behavior here? I would expect the VBAT_PMU to only draw enough current for the RTC to keep time while power is down.  102uA would drain a CR1632 coin cell battery pretty quickly.  How do I power the MCU so the battery only powers the RTC and draws less than 1uA when main power is removed?  Re: LPC55S28 VBAT_PMU Current Draw Hi @guitardenver  On LPC55S28, VBAT_PMU is the supply for the always-on domain , which includes the PMC, RTC, and OS Event Timer, and that domain remains powered as long as a valid VBAT supply is present. The RTC can continue running in deep power-down from that domain. VBAT_PMU by itself does not guarantee “RTC-only current.” To get sub-µA backup current, the device must be in deep power-down mode. So your measured ~102 µA with main power removed is not consistent with RTC-only deep-power-down operation . For LPC55S2x/LPC552x, the datasheet shows typical total supply current of 110 µA in deep-sleep mode at 25 °C and 3.0 V, while deep power-down with RTC oscillator disabled is 590 nA  , and with the RTC running from an external crystal is 790 nA . To get less than 1 µA from the coin cell on LPC55S28, power only VBAT_PMU from the battery and make firmware enter Deep Power-Down before main power is removed. BR Harry Re: LPC55S28 VBAT_PMU Current Draw Thank you for your reply! I have code that will trigger the Deep power down on a brownout interrupt, which works great. But there is a huge problem with this method. If the ROM Bootloader is executing, and power is removed, the brownout interrupt is not setup and does not have code to put it into power down. Is there a good way to guarantee that I can get into the deep power down mode? If there is any state that leaves the MCU in normal mode, the battery will get drained. Maybe there is something I am missing. If not, I may have to put an external RTC chip on the board. 

RT1176 PWMの起動に失敗しました 私はPWM + Fault + QTimerを使ってモーターパルス制御を実装していますが、PWM3サブモジュール0のPWM_Aチャネルが時々起動できず、最初のハイレベル以降は一定のままで、その後のパルスは現れません。検査の結果、PWMの「ラン」部分が正しく設定されていないことが判明しました。後からプログラムに起動時の処理を繰り返し追加したにもかかわらず、この異常は依然として発生した。

i.MX8MP Maximum Geometry for RAW Capture Hi NXP Community, We are trying to use a particular image sensor on the i.MX8MP. We are attempting to push the RAW12 capture from the MIPI to RAM. It seems that the only way to do this is through the ISI module as outlined below: The problem is that the documentation on the geometry limits is vague and we are trying to determine if the i.MX8MP is suitable for our application. The height and width of the image is defined in the ISI using the CHNL_IMG_CFG[WIDTH/HEIGHT] register. These entries are 13-bit, theoretically limiting us to 8191 x 8191 geometry. The width seems to be limited by hardware via the line buffer which can actually only hold 2K pixels but the documentation outlines methods for reaching 4K by combining line buffers from other channels. The documentation does not cover whether the register limit of 8191 pixels for the line width can be achieved. We can bypass the ISI processing and our goal is to simply push the RAW MIPI capture to RAM. Furthermore, unlike the width, the height limitation does not seem to be caused by physical hardware. Is there any confirmation that we can support a height of 8191 lines as defined by the 13-bit max of the CHNL_IMG_CFG[HEIGHT] register? Any support on the matter would be appreciated. I have reviewed other similar posts such as the following: https://community.nxp.com/t5/i-MX-Processors/Direct-MIPI-CSI2-to-memory-access-on-i-MX8MP/m-p/2158946 https://community.nxp.com/t5/i-MX-Processors/I-MX8MP-ISI-maximum-supported-width/m-p/1224069 However, whether 8191 width is supported is not confirmed and I was wondering if there are any updates here. Also, the height limitation is not defined. Thank you i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP Maximum Geometry for RAW Capture i.mx8mp ISI driver has limited to the 2k, but if you use chain buffer, ISI can support up to 4k, couldn't support 8191 width, on the imx8mp, one camera can be supported up to 4k@30 Re: i.MX8MP Maximum Geometry for RAW Capture Thank you for your reply. So the width limitation matches my original findings.  Can you please comment on the height limitations of the ISI module? Can we achieve 8191 lane height through the ISI? Thank you

IMX8M+ 带 BT+WiFi 模块 (AW-XB583MA-PUR) BT 初始化需要 50-60 秒时间 亲爱的恩智浦团队 我们有基于 iMX8M+ 的定制主板，分别在 PCIe 和 UART 上使用 BT & WiFi（来自 Azurawave 的 AW-XB583MA-PUR 模块）。 我们在初始化 BT 时遇到了问题，这需要大约 50-60 秒（持续时间总是固定的）才能通过 UART 获得对第一个 HCI RESET 命令的响应。我们与 Azurawave 团队进行了检查/调试，他们建议我们也与恩智浦进行检查（因为在他们看来），这可能是恩智浦方面的问题。 以下是 SoC 与模块的连接： 恩智浦：UART1_RXD<---> 模块：UART TXD NXP：UART1_TXD<---> 模块：UART RXD NXP：UART3_T<---> XD 模块：UART RTS <---> 恩智浦：UART CTS 设备树更改我们所做的：& uart1 {/* BT */ < >pinctrl- names = " 默认 "；pinctrl- 0 = < & pinctrl_uart1 >；分配的时钟 = < & clk imx8MP_CLK_UART1 >；分配的时钟父母 = < & clk imx8MP_SYS_PLL1_80M >; /*fsl，uart-has-rtscts；*/ 状态 = " 好吧 ";}；p inctrl_uart1：uart1grp {fsl，别针 =;}; i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Linux Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized 你好@hiteshviradiya 希望你一切都好。 你能分享设备树上的详细信息吗？我只看到了 Pinmux 代码。 此外，还有有关您正在使用的电路板支持包 版本以及用于连接到 WIFI 模块的驱动程序的详细信息。 顺祝商祺！ 萨拉斯 Re: IMX8M+ w/ BT+WiFi module (AW-XB583MA-PUR) BT takes 50-60 seconds time to get initialized 亲爱的@Manuel_Salas ， 我们使用的是定制版的Buildroot（版本2024.08）。内核版本：6.6.36。我之前已经分享过与蓝牙相关的设备树代码以及 Pinmux，但下面再次分享： &uart1 { /* BT */ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart1>; 分配时钟 = <&clk IMX8MP_CLK_UART1>; 已分配时钟父级 = <&clk IMX8MP_SYS_PLL1_80M>; fsl，uart-has-rtscts； 状态 = "正常"; }; pinctrl_uart1: uart1grp { fsl,pins = < MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140 MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140 MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140 MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140 >; }; 如果您需要其他特定的设备树节点，请告诉我。

如何使用 PeMicro 调试器在 S32K3x4EVB-T172 (S32K344) 上安装 S32K344 A/B 交换 HSE 固件。 您好， 我想在 S32K344 上测试 OTA A/B 替换演示。 为此，我需要在我的 S32K344 芯片上安装 HSE (A/B) 固件，该芯片上没有任何 HSE 固件。 我携带了以下硬件： 1. S32K3x4EVB-T172 (S32K344) 2. PeMicro 调试器。 （注：我没有 Lauterbach TRACE32 工具） 因此，我请求您提供一个正确的步骤，以便借助 S32 设计工作室，使用 PE 微调试器在 s32k344 上安装 HSE (A/B) 固件。 请尽量提供一个完整的操作流程，其中应包含所有必要信息，例如要使用的 DS 版本、RTD、HSE 粉色文件等。 谢谢。 Re: How to install S32K344 A/B swap HSE FW using PeMicro debugger on S32K3x4EVB-T172 (S32K344). HSE DEMO 代码（可随 HSE FW 下载）使用 Lauterbach TRACE32。虽然没有使用不同调试器的专门示例，但有 HSE 示例包： https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples 它基本上是将 HSE DEMO 的功能移植到与调试器无关的代码中。例如，如果您使用 S32K344_HSE_FW_INSTALL，则可以使用任何调试器安装 HSE 固件。

S32K311チップはPIT（割り込み処理）を介して割り込みソフトウェア環境に入ることができません。（S32DS 3.6.0）RTD 6.0.0 プログラムは実行中に割り込みを発生させず、pit_notifaction も呼び出しませんでした。 ソフトウェア環境：S32DS 3.6.0RTD 6.0.0 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 テストのために関数内にブレークポイントを設定しましたが、関数が呼び出されませんでした。考えられる原因は何でしょうか？カウンターは正常にカウントしていますが、割り込みが発生していません。 ソフトウェアのバージョンが異なると、何か影響はありますか？ Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 こんにちは、 @Finnc 現在、私はS32K311ボードにアクセスできません。しかし、同じ構成とコードをFRDM-A-S32K312でテストしたところ、PitNotificationが呼び出され、カウンタが期待どおりに増加することを確認しました。 通知関数が呼び出されているかどうかを確認するために、通知関数内にブレークポイントを設定していただけますか？ BR、VaneB Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 全速で走行している場合、pit_notifactionは入力されず、PitCountの値は0のままです。一時停止時のレジスタのパラメータを図に示します。 クロック設定に関係していますか？設定は以下のとおりです。 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 こんにちは、 @Finnc あなたのコードで確認できる通り、カウンターはPitNotificationが呼び出されたときにのみ増加します。これは、PIT割り込みが正しくトリガーされていることを示しています。 よりシンプルで分かりやすいテストを行うには、PitNotification 関数内で printf を使用してカウンター値を出力することができます。表示された値を確認できれば、割り込みが想定どおりに実行されていることがさらに確認できます。 例えば、私は以下のように実装しました。 また、printfの設定方法についてサポートが必要な場合は、 「S32DS 3.5でprintf関数を使用する方法」というスレッドを参照してください。 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 こんにちは、 @Finnc S32K311EVBを使って私の環境であなたのコードをテストしたところ、すべて期待どおりに動作しました。 カスタムハードウェアに関連する問題を排除するために、クロックソースをFIRCに切り替えて、動作に変化があるかどうか試していただけますでしょうか？ Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 内部クロックを使用している場合、pit_notifaction 状態に入ることができません。さらに、通信割り込みやその他の割り込みも正しく機能しません。同じプログラムと設定を S32K312 でテストしたところ、正常に動作しました。 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 こんにちは、 @Finnc 問題はソフトウェアに関係ない可能性が高いようです。代わりにカスタムボードに関連付けられている場合もあります。同じテストを比較するために、S32K311デバイス付きの別の基板にアクセスできますか？ Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 現在、S32K311を搭載した他のボードは存在せず、同じボードのいくつかで同様の問題が発生しています。S32K312チップのみ、同じプログラムと構成で正常に動作します。K311の不具合の原因は特定されていません。 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 こんにちは、 @Finnc 私の側ではFRDM-A-S32K312とS32K31XEVB-Q100の両方でコードが正常に動作し、あなたの側もS32K312を使っているので、問題はソフトウェアに関係ない可能性があります。 あなたが説明した挙動からすると、これはハードウェアに関係している可能性があります。しかし、さらなる分析なしに正確な根本原因を特定することは困難である。S32K31XEVB-Q100の回路図やS32K3xx マイクロコントローラのハードウェア設計ガイドラインファイル(S32K3汎用ハードウェア設計パッケージに含まれる)を見て、カスタムボードを推奨設計方法と比較すると良いでしょう。 もし問題がMCU自体に関連している可能性があると思われる場合は、NXPの担当者または部品を購入した代理店にご連絡ください。 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 こんにちは、 @Finnc 別のデバッガーを使ってみましたか？また、最初に共有していただいたコードはまだ使用していますか？ Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 テスト中に、`Pit_notifaction`関数にLEDの切り替え機能を追加したところ、プログラムのダウンロードが完了した後、LEDが点滅して割り込みが発生したことを示すには、ボードの電源を再度オンにする必要があることがわかりました。しかし、プログラムを正常に実行するには、ダウンロードのたびに電源を入れ直す必要があり、デバッグモードに入ることができませんでした。

S32K358 eMIOS ISR stuck at 85°C Dear NXP Support Team, we are facing an issue on S32K358 during temperature tests at around 85°C.   In our application we use 6 eMIOS channels, each one configured to generate interrupts on both PWM edges with a frequency of 200Hz.   At 85°C, the MCU sometimes gets stuck inside one eMIOS ISR. The ISR does not exit because the code checks the interrupt flag by reading the eMIOS registers, but the flag is 0 (file Emios_Mcl_Ip_Irq.c 😞   if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))    After debugging, we noticed that when the issue occurs, the variable containing the eMIOS base address is NULL (Emios_Ip_paxBase). When the application works correctly, the same pointer is valid and the eMIOS registers are read properly. It seems that, in some conditions, the reference to the eMIOS peripheral is corrupted or cleared during ISR execution.   Do you have any indication about possible known issues or root causes, such as stack overflow, memory corruption, concurrent accesses, ISR handling, or temperature-related behavior?   Best regards, Simon Re: S32K358 eMIOS ISR stuck at 85°C Hi vane, I'm currently using RTD 7.0.0 Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Which RTD version are you working with? Any additional information would be helpful. Also, in RTD versions prior to 6.0.0, there was a known issue related to the incorrect memory mapping of static variables within function scope (ARTD-159985). This issue describes a problem where the variable Emios_Ip_paxBase, defined in both Emios_Mcl_Ip.c and Emios_Mcl_Ip_Irq.c, is assigned inconsistent initialization characteristics. Further details are provided in the Software Release Notes. BR, VaneB Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Could you please provide a simple application that reproduces the observed behavior? Also, could you confirm whether you are working with a custom board or an evaluation board? Additionally, could you share how the testing is being performed to confirm that the issue occurs at 85 °C? Re: S32K358 eMIOS ISR stuck at 85°C Hi @VaneB , Currently i'm working with a custom board with S32K358 where i use these eMIOS_1 channels to generate PWM of 200 Hz: ch3, ch9,  ch11, ch12, ch13, ch19. Code is generated using SImulink  Putting my custom board into a climatic cell at 85°C i've observed the stucking behaviour after some time. While i was debugging with S32DS (3.6.7) I've found out that it stuck into the ISR(EMIOS1_1_IRQ) so i've put into it some custom counter near entry/exit function, and also into Emios_Pwm_IrqHandler and Emios_Pwm_Ip_IrqHandler functions, in order to detect what parts of the code are executed.  After some tests i've found out that, when it stucks, inside static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) {     /* Check that an event occurred on Emios channel */     if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))     {         /* Check that an event occurred on EMIOS channel */         if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))))         {             Emios_Pwm_Ip_IrqHandler(Instance, Channel);         }         else         {             /* Do nothing - in case of spurious interrupts, return immediately */         }     } }   the if condition: if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))   is always 0 because, for some reason, Emios_Ip_paxBase[Instance] points to 0. This means that nobody is clearing the interrupt flag so it enters in a loop where it cannot escape.   here's the code i've used to detect this probelm: static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) {     // uint32_t s;     // uint32_t c;     // uint32_t s_flag;     // uint32_t s_ovr;     dbg_pwm_last_instance = Instance;     dbg_pwm_last_channel = Channel;     dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance];     dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C;     dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S;         dbg_emiosipirq_static_state1++;     /* if (Instance == 1)     {         switch (Channel)         {             case 16:                 dbg_emiosipirq_static_cnt_ch16++;                 break;             case 17:                 dbg_emiosipirq_static_cnt_ch17++;                 break;             case 18:                 dbg_emiosipirq_static_cnt_ch18++;                 break;             case 19:                 dbg_emiosipirq_static_cnt_ch19++;                 break;             default:                 dbg_emiosipirq_static_cnt_oth1++;                 break;         }     }     else     {         dbg_emiosipirq_static_cnt_oth2++;     } */     /* Lettura reale dei registri vista dal codice */    /*  s = Emios_Ip_paxBase[Instance]->CH.UC[Channel].S;     c = Emios_Ip_paxBase[Instance]->CH.UC[Channel].C;     s_flag = s & (uint32)eMIOS_S_FLAG_MASK;     s_ovr  = s & (uint32)eMIOS_S_OVR_MASK;     dbg_pwm_last_s = s;     dbg_pwm_last_c = c;     dbg_pwm_flag_mask = (uint32)eMIOS_S_FLAG_MASK;     dbg_pwm_ovr_mask = (uint32)eMIOS_S_OVR_MASK;     dbg_pwm_last_s_and_flag = s_flag;     dbg_pwm_last_s_and_ovr = s_ovr;     if (s_flag != 0U)     {         dbg_pwm_s_flag_yes++;     }     else     {         dbg_pwm_s_flag_no++;     }     if (s_ovr != 0U)     {         dbg_pwm_s_ovr_yes++;     }     else     {         dbg_pwm_s_ovr_no++;     }     if ((s_flag == 0U) && (s_ovr != 0U))     {         dbg_pwm_flag0_ovr1_count++;     }     else if ((s_flag != 0U) && (s_ovr != 0U))     {         dbg_pwm_flag1_ovr1_count++;     }     else if ((s_flag != 0U) && (s_ovr == 0U))     {         dbg_pwm_flag1_ovr0_count++;     }     else     {         dbg_pwm_flag0_ovr0_count++;     } */     /* Check that an event occurred on EMIOS channel */     if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK))     {         dbg_emiosipirq_static_state2++;         /* Check that an event occurred on EMIOS channel */         if (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK))))         {             dbg_emiosipirq_static_state3++;             Emios_Pwm_Ip_IrqHandler(Instance, Channel);         }         else         {             dbg_emiosipirq_static_state4++;             /* Do nothing - in case of spurious interrupts, return immediately */         }     }     else     {         dbg_emiosipirq_static_state5++;         //Emios_Pwm_Ip_IrqHandler(Instance, Channel);         //Emios_Pwm_Ip_IrqHandler(1, 19);     } } These are the global vars in which i've stored the addresses which Emios_Ip_paxBase should point to: dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; I've put also some custom code to read NVIC registers run time: attached you can find the file with Thread, general registers, NVIC registers and variables expressions, EMIOS registers, for 6 tests i made. Also i will provide you the S32DS project i used to test this behaviour in a private message. I hope all these information could be usefull. I remain at your disposal for any further information. BR, SImon Re: S32K358 eMIOS ISR stuck at 85°C Hi @simon98  Thank you very much for providing this information. Since the code appears to be getting stuck in EMIOS1_1_IRQ, which corresponds to eMIOS 1 Channel 19 based on your configuration, let’s try to narrow the analysis to this specific part. To simplify the debugging and rule out any interference from other modules, please create a minimal test project that only includes this eMIOS configuration. This will help us isolate the behavior and better understand the root cause. For guidance, you can review the examples provided in the thread S32M27x/S32K3 – eMIOS Usage. Does the same behavior still occur? Also, if you have an evaluation board, it would be great if you could try the same code there.

RT1176 PWM startup failed I am using PWM + fault + QTimer to implement motor pulse control, but the PWM3 submodule 0 PWM_A channel occasionally fails to start, where after the first high level it remains constant and subsequent pulses do not appear.After the inspection, it was found that the "run" bit of the pwm was not correctly set. Even though repeated startup operations were added in the program later, this anomaly still occurred.

S32K358 eMIOS ISR 卡在 85°C 尊敬的恩智浦技术支持团队： 我们在 S32K358 上进行 85°C 左右的温度测试时遇到了问题。   在我们的应用中，我们使用了 6 个 eMIOS 通道，每个通道都配置为在 PWM 的两个边沿生成中断，频率为 200Hz。   在 85°C 时，MCU 有时会卡在某个 eMIOS 中断服务例程 (ISR) 中。ISR 无法退出，因为代码会通过读取 eMIOS 寄存器来检查中断标志，但该标志的值为 0（文件 Emios_Mcl_Ip_Irq.c）。 😞   如果( 0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32) eMIOS_S_FLAG_MASK ))   调试后我们发现，当问题出现时，包含 eMIOS 基地址的变量（ Emios_Ip_paxBase）为 NULL 。而当应用程序正常运行时，该指针有效，并且 eMIOS 寄存器也能被正确读取。 似乎在某些情况下，对 eMIOS 外设的引用在 ISR 执行期间会被损坏或清除。   您是否有任何关于可能存在的已知问题或根本原因的线索，例如堆栈溢出、内存损坏、并发访问、中断服务例程处理或温度相关行为？   顺祝商祺！ 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨，范恩 我目前使用的是 RTD 7.0.0 版本。 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 你使用的是哪个版本的RTD？任何其他信息都将不胜感激。 此外，在 6.0.0 之前的 RTD 版本中，存在一个与函数作用域内静态变量的内存映射不正确相关的已知问题 (ARTD-159985)。 此问题描述了在 Emios_Mcl_Ip.c 中定义的变量 Emios_Ip_paxBase 存在的问题。Emios_Mcl_Ip_Irq.c 被赋予了不一致的初始化特性。更多详情请参阅软件版本说明。 BR，VaneB Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 能否提供一个能够重现所观察到的现象的简单应用程序？另外，能否确认一下您使用的是定制电路板还是评估电路板？ 另外，能否分享一下测试是如何进行的，以确认该问题是否在 85°C 时出现？ Re: S32K358 eMIOS ISR stuck at 85°C 嗨@VaneB ， 目前我正在使用一块带有 S32K358 的定制板，其中我使用以下 eMIOS_1 通道生成 200 Hz 的 PWM：ch3、ch9、ch11、ch12、ch13、ch19。代码是使用 Simulink 生成的。 我将定制电路板放入 85°C 的气候箱中一段时间后，观察到了卡顿现象。 我在使用 S32DS (3.6.7) 进行调试时我发现它卡在了 ISR(EMIOS1_1_IRQ) 中，所以我在入口/出口函数附近以及 Emios_Pwm_IrqHandler 和 Emios_Pwm_Ip_IrqHandler 函数中都添加了一些自定义计数器，以便检测代码的哪些部分正在执行。 经过一些测试，我发现，当它卡住时，内部…… static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { /* 检查 Emios 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) { /* 检查 EMIOS 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK)))) { Emios_Pwm_Ip_IrqHandler(实例, 通道); } 别的 { /* 什么也不做 - 如果遇到虚假中断，立即返回 */ } } } if 条件： 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) 始终为 0，因为由于某种原因，Emios_Ip_paxBase[Instance] 指向 0。这意味着没有人清除中断标志，因此它进入了一个无法逃脱的循环。 以下是我用来检测此问题的代码： static void Emios_Pwm_IrqHandler(const uint8 Instance, const uint8 Channel) { // uint32_t s; // uint32_t c; // uint32_t s_flag; // uint32_t s_ovr; dbg_pwm_last_instance = 实例; dbg_pwm_last_channel = Channel; dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; dbg_emiosipirq_static_state1++; /* 如果 (实例 == 1) { 切换（通道） { 案例16： dbg_emiosipirq_static_cnt_ch16++; 休息; 案例17： dbg_emiosipirq_static_cnt_ch17++; 休息; 案例18： dbg_emiosipirq_static_cnt_ch18++; 休息; 案例19： dbg_emiosipirq_static_cnt_ch19++; 休息; 默认： dbg_emiosipirq_static_cnt_oth1++; 休息; } } 别的 { dbg_emiosipirq_static_cnt_oth2++; } */ /* Lettura reale dei registri vista dal codice */ /* s = Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; c = Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; s_flag = s & (uint32)eMIOS_S_FLAG_MASK; s_ovr = s & (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s = s; dbg_pwm_last_c = c; dbg_pwm_flag_mask = (uint32)eMIOS_S_FLAG_MASK; dbg_pwm_ovr_mask = (uint32)eMIOS_S_OVR_MASK; dbg_pwm_last_s_and_flag = s_flag; dbg_pwm_last_s_and_ovr = s_ovr; 如果 (s_flag != 0U) { dbg_pwm_s_flag_yes++; } 别的 { dbg_pwm_s_flag_no++; } 如果 (s_ovr != 0U) { dbg_pwm_s_ovr_yes++; } 别的 { dbg_pwm_s_ovr_no++; } 如果 ((s_flag == 0U) && (s_ovr != 0U)) { dbg_pwm_flag0_ovr1_count++; } 否则如果 ((s_flag != 0U) && (s_ovr != 0U)) { dbg_pwm_flag1_ovr1_count++; } 否则如果 ((s_flag != 0U) && (s_ovr == 0U)) { dbg_pwm_flag1_ovr0_count++; } 别的 { dbg_pwm_flag0_ovr0_count++; } */ /* 检查 EMIOS 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].S) & (uint32)eMIOS_S_FLAG_MASK)) { dbg_emiosipirq_static_state2++; /* 检查 EMIOS 通道上是否发生了事件 */ 如果 (0U != ((Emios_Ip_paxBase[Instance]->CH.UC[Channel].C) & ((uint32)(eMIOS_C_DMA_MASK | eMIOS_C_FEN_MASK)))) { dbg_emiosipirq_static_state3++; Emios_Pwm_Ip_IrqHandler(实例, 通道); } 别的 { dbg_emiosipirq_static_state4++; /* 什么也不做 - 如果遇到虚假中断，立即返回 */ } } 别的 { dbg_emiosipirq_static_state5++; //Emios_Pwm_Ip_IrqHandler(Instance, Channel); //Emios_Pwm_Ip_IrqHandler(1, 19); } } 以下是我存储 Emios_Ip_paxBase 应指向的地址的全局变量： dbg_pwm_last_base_addr = (uint32_t)Emios_Ip_paxBase[Instance]; dbg_pwm_last_c_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].C; dbg_pwm_last_s_addr = (uint32_t)&Emios_Ip_paxBase[Instance]->CH.UC[Channel].S; 我还添加了一些自定义代码，用于在运行时读取 NVIC 寄存器：附件中包含线程、通用寄存器、NVIC 寄存器和变量表达式、EMIOS 寄存器等文件，以及我进行的 6 次测试。 另外，我会在私信中提供我用来测试此行为的 S32DS 项目。 希望这些信息对大家有所帮助。如有任何其他疑问，请随时联系我。 BR， 西蒙 Re: S32K358 eMIOS ISR stuck at 85°C 嗨@simon98 非常感谢您提供这些信息。 由于代码似乎卡在了 EMIOS1_1_IRQ 中，根据您的配置，它对应于 eMIOS 1 通道 19，让我们尝试将分析范围缩小到这一特定部分。 为了简化调试并排除其他模块的任何干扰，请创建一个仅包含此 eMIOS 配置的最小测试项目。这将有助于我们找出问题所在，并更好地了解其根本原因。如需指导，您可以查看S32M27x/S32K3 – eMIOS 使用主题中提供的示例。 同样的行为是否仍然存在？另外，如果您有评估板，最好能在上面测试一下相同的代码。

RT1176 PWM启动失败 我使用PWM+故障+QTimer来实现电机脉冲控制，但PWM3子模块0的PWM_A通道偶尔无法启动，在第一个高电平之后就一直保持高电平，后续脉冲不再出现。检查后发现，PWM的“运行”位没有正确设置。即使后来在程序中添加了重复启动操作，这种异常情况仍然发生。

LPC55S28 VBAT_PMU 消費電流 下記の回路図が描かれたプリント基板があります。基板の主電源が切断された場合に備えて、バックアップ用のコイン型電池を用意しています。私の理解では、MCUのVBAT_PMU(ピン51)は常時オン(PD_AON)ドメイン。 メイン電源を使わずにバッテリーだけを使った状態でバッテリーの電流消費量を測ると、約102uAになります。これはRTCが消費する量をはるかに超える。D12が削除された場合のイベントです。VBATはVBAT_PMUピンにのみ接続されており、それ以外は接続されません。 ここで期待される動作は何ですか？VBAT_PMUは、電源が切れている間、RTCが時刻を維持するために必要なだけの電流しか消費しないはずだと私は考えています。102μAの電流では、CR1632型コイン電池はかなり早く消耗してしまうだろう。 MCUに電力を供給するにはどうすればいいですか?バッテリーはRTCだけに電力を供給し、メイン電源を外したときに1uA未満の電力を消費します。 Re: LPC55S28 VBAT_PMU Current Draw こんにちは、 @guitardenver LPC55S28では、VBAT_PMU常時オンドメインの電源であり、PMC、RTC、OSイベントタイマーを含む。有効なVBAT電源が存在する限り、そのドメインは電源を維持します。RTCはそのドメインから深いダウン状態で動作を続けられます。 VBAT_PMU単体では「RTC専用電流」を保証するものではありません。サブマイクロアンペアのバックアップ電流を得るには、デバイスをディープパワーダウンモードにする必要があります。 したがって、主電源を抜いた状態で測定された約102μAは、RTCのみの深切断動作とは一致しません。 LPC55S2x/LPC552xのデータシートによると、25℃、3.0Vでのディープスリープモード時の標準的な総供給電流は110μAですが、RTC発振器を無効にした状態でのディープパワーダウン時は590nA、外部水晶発振器でRTCを動作させた状態では790nAとなっています。 LPC55S28のコイン型電池から1µA未満の電流を得るには、バッテリーからVBAT_PMUのみに電力を供給し、主電源が切断される前にファームウェアがディープパワーダウン状態に入るようにします。 BR ハリー Re: LPC55S28 VBAT_PMU Current Draw お返事ありがとうございます！ 電圧低下割り込みでディープパワーダウンをトリガーするコードがあり、これはうまく機能しています。しかし、この方法には大きな問題があります。ROMブートローダーが実行中に電源が切断された場合、ブラウンアウト割り込みは設定されておらず、電源を切断するためのコードも含まれていません。 ディープパワーダウンモードに入ることを確実にする方法はありますか?もしMCUがノーマルモードに残る状態が現れると、バッテリーが消耗します。何か見落としていることがあるのかもしれない。そうでない場合は、基板上に外部RTCチップを取り付ける必要があるかもしれません。

[S32K324 / Custom Board] HSE FW Installed (0x4039C028=1) but Init Failed (0x4038C107=0) Hi everyone, I am seeking advice regarding an issue where the HSE Firmware initialization fails to complete on an S32K324 custom board. 1. Development Environment MCU: S32K324 (Custom Board) HSE FW: s32k3x4_hse_fw_1.5.0_2.55.0_pb250130.bin.pink Debugger: S32DS + T32 (Trace32) 2. Progress and Status Registers Successfully programmed the HSE FW Usage Flag in the UTEST region (0x1B000000). Downloaded the Pink Image binary into flash memory. After performing a Power-On Reset (POR), the status registers are as follows: 0x4039C028 (HSE GPR): 0x01 (Installation confirmed) 0x4038C107 (HSE_STATUS_INIT_OK): 0x00 (Halted during boot) 3. Questions I would like to ask the experts the following: What is the very first thing I should check? Since the installation succeeded but initialization failed, are there any specific registers (e.g., Fault status) I should dump or hardware signals to inspect to pinpoint the exact cause? Can the Custom Board environment affect the initialization failure? Since I am using a custom board, I suspect hardware differences (e.g., initial XTAL frequency) or the early clock (PLL) configuration code of the main core (M7) might be interfering with the HSE boot sequence. If this is a known issue, could you guide me on the recommended boot sequence (e.g., polling the INIT_OK flag before any clock setup) or potential solutions? Any clues would be a great help. Thank you in advance for your support! Re: [S32K324 / Custom Board] HSE FW Installed (0x4039C028=1) but Init Failed (0x4038C107=0) Hi there, Thank you so much for the clear guidance. First, I proceeded with the firmware installation using the demo app, and then dumped the MU and HSE GPR register values while in the system.up state. Please let me know if any of these register addresses are incorrect. The results are as follows: 1. MU0 Registers (Base Address: 0x4038C000)     2. HSE GPR Registers (Base Address: 0x4039C000)   Could you please review these values? I would highly appreciate your expert opinion on whether these indicate a specific error cause, such as a clock configuration conflict or a firmware authentication failure. Thank you again for your time and support! Re: [S32K324 / Custom Board] HSE FW Installed (0x4039C028=1) but Init Failed (0x4038C107=0) Could you provide following information? MU registers, FSR, GSR, etc: HSE GPR3:

AFT05MP075Nのガーバーデータを要求しています。 こんにちは、 私はこのAFT05MP075Nを使ってVHF/UHFパワーアンプの設計に取り組んでいます。AFT05MP075N製品ページのDXFリファレンスPCBファイルは持っていますが、450–520MHzのブロードバンドリファレンスボード用のGerberファイルパッケージ全体が必要です。これらは以前、お客様にご要望に応じて提供されていたと理解しています。そのファイルを入手するためのサポートが欲しいです。 よろしくお願い申し上げます。 RF Re: Requesting Gerbers for AFT05MP075N こんにちは、 なお、NXPはこの製品向けにGerberファイルを提供していません。代わりに、製品ページのデザインリソースセクションでご覧いただけるDXFファイルを提供しています。 ご迷惑をおかけして申し訳ございませんが、ご理解いただけますようお願い申し上げます。