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ファイルを提供しています。 ご迷惑をおかけして申し訳ございませんが、ご理解いただけますようお願い申し上げます。

RW610/RW612 支持TLS 1.2及以上版本么 RW610/RW612 支持TLS 1.2及以上版本么

BCTU制御モードとトリガーモードにおけるADCノイズの差 こんにちは、 私は [S32k322] を使って、 eMIOSタイマー を使って100μsごとに BCTU をトリガーし、アナログデータを読み取るアプリケーションを開発しています。 2つの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  テストコードを添付しました。 BCTUの作業と、選ばれた一部のチャンネル(ADC_Instance0とADC_Instance1)の通常の変換は可能でしょうか?

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

IMX8QX DDR RPA_tool 構成、レジスタ情報が欠落しています こんにちは、 IMX8QX 上の DDR3L 用の RPA_tool の構成に記載されているいくつかのレジスタに関する情報が必要です。次のようなレジスタ アドレスが記述されています。 0x41C80044 0x41C80208 0x41C80204 0x41C82C00 0x41C83800 しかし、それらはドキュメントのどこにも記載されていません。 それぞれの機能と設定フィールドを教えていただけますか。 よろしくお願い申し上げます。 Re: IMX8QX DDR RPA_tool configuration, missing register information こんにちは、 @CPE さん。 この設定ファイルは、サードパーティのIPベンダーによって提供されています。ポイント付きレジスタはNDAドキュメントには表示されていません。i.MX8X実装の場合、提供された値以外に選択肢はないとご理解ください。 よろしくお願いいたします。

Do RW610/RW612 support TLS 1.2 and above? Do RW610/RW612 support TLS 1.2 and above?

The S32K311 chip cannot enter the PIT interrupt Software environment: S32DS 3.6.0  RTD 6.0.0 The program did not enter an interrupt during execution, and pit_notification was not called. Software environment: S32DS 3.6.0  RTD 6.0.0 Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 I added a breakpoint inside the function to test it, but the function wasn’t called. What could be the possible reasons for this? The counter is incrementing normally, and no interrupt has been triggered. Could different software versions be a factor? Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  Currently, I do not have access to an S32K311 board. However, I tested the same configuration and code on an FRDM-A-S32K312, and I was able to confirm that PitNotification is called and the counter increments as expected. Could you set a breakpoint inside the notification function to verify whether it is being called? BR, VaneB Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 When running at full speed, pit_notification is not triggered , and the PitCount value remains at 0. The register parameters when paused are shown in the figure. Could this be related to the clock configuration? The configuration is as follows: Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  I was able to test your code on my side using an S32K311EVB, and everything is working as expected. To help rule out any issues related to your custom hardware, could you please try switching the clock source to FIRC and see if there is any change in the behavior? Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  As observed in your code, the counter only increments when PitNotification is called. This indicates that the PIT interrupt is being triggered correctly. For a simpler and more visible test, you can use printf to output the counter value inside the PitNotification function. If you are able to see the printed values, this will further confirm that the interrupt is being executed as expected. For example, I implemented it as follows: Also, if you need help setting up printf, refer to the thread how to use the printf function in S32DS 3.5? Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  It seems that the problem might not be software related; it may instead be associated with your custom board. Do you have access to another board with an S32K311 device that you could use to run the same test for comparison? Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 It also fails to enter pit_notifaction when using the internal clock. Furthermore, communication interrupts and other interrupts do not function correctly. I tested the same program and configuration on an S32K312, and it ran normally. Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 There are currently no other boards equipped with the S32K311, and several of the same boards exhibit the same problem. Only the S32K312 chip runs normally with the same program and configuration. The cause of the K311 malfunction has not been found. Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  Since the code is working as expected on my side with both the FRDM-A-S32K312 and the S32K31XEVB-Q100, and also on your side using the S32K312, it seems that the issue might not be software-related. Based on the behavior you described, this could potentially be related to the hardware. However, it is difficult to determine the exact root cause without further analysis. It might be helpful to take a look at the S32K31XEVB-Q100 schematic and the Hardware Design Guidelines for S32K3xx Microcontrollers file (included in the S32K3 General Purpose Hardware Design Package) to compare your custom board against the recommended design practices. If you think the issue could be related to the MCU itself, please contact your NXP representative or the distributor from whom the parts were purchased for further assistance. Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 During testing, adding an LED toggle function in the `Pit_notifaction` function revealed that after the program download was complete, the board needed to be powered on again for the LED to blink, indicating that an interrupt had been entered. However, a power cycle was required after each download for the program to run normally, making it impossible to enter debug mode. Re: S32K311 芯片 pit无法进入中断 软件环境 S32DS 3.6.0  RTD 6.0.0 Hi @Finnc  Have you tried using another debugger? Also, are you still working with the code you initially shared?

[S32K324 / カスタムボード] HSEファームウェアがインストールされましたが(0x4039C028=1)、初期化に失敗しました(0x4038C107=0) こんにちは、皆さん S32K324カスタムボード上でHSEファームウェアの初期化が完了しない問題について、アドバイスを求めています。 1. 開発環境 MCU:S32K324(カスタムボード) HSE FW: 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) こんにちは、 明確なご案内をありがとうございます。 まず、デモアプリを使用してファームウェアのインストールを進め、その後、system.up状態中に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:

KW47 NBUのプログラミングとアップグレード こんにちは： KW47 NBUのプログラミングやアップグレード方法を知りたいです。手順がもっと詳しく説明できることを願っています。 ご回答をお待ちしています。 Re: KW47 NBU programming and upgrade こんにちは： サポートありがとうございます。ご提供いただいた方法でNBUのファームウェアを更新できるようになりました。 ご提供の方法には、ファームウェア経由でNBUをアップデートする方法が含まれていないようですね? 例えば、私のデバイスがマーケットに出てNBUバージョンをアップデートする必要がある場合、どうすればよいでしょうか? ご回答をお待ちしています。 Re: KW47 NBU programming and upgrade こんにちは、お元気でお過ごしでしょうか。 KW45からKW47への移行ガイドAN14796 6.2節「KW47にNBUファームウェアをロードする」を参照してください。 このドキュメントでは、KB47のNBUを更新するためのいくつかの方法(手順はKW47-EVKを用いて示されています)を紹介しており、blhost、Secure Provisioning Tool、LinkServerなど、開発に最適な方法を自由に選択できます。各方法の詳細手順も含まれています。 お役に立てば幸いです！他に質問があれば、遠慮なくお尋ねください。 よろしくお願いします、 アナ・ソフィア。 Re: KW47 NBU programming and upgrade こんにちは、 ROMブートローダーには、メインフラッシュおよびラジオフラッシュのファームウェアの更新に使用できるファームウェア更新機能があります。 現場でのNBUアップデートのワークフローは通常次の順序に従います。アプリケーションはアップデートイメージを保存し、対応するメタデータをUser IFR0 OTACFG領域に書き込み、その後システムリセットをトリガーしてROMブートローダーが引き継ぎ、無線ファームウェアの更新を行います。 詳細は KW47セキュリティリファレンスマニュアル の4.2.6「ファームウェア更新機能」および4.2.2.3のオーバーエア(OTA)アップデート構成のセクションで確認できます。 よろしくお願いします、 アナ・ソフィア。

S32G274A 实现SHA256+RSA2048算法 NXPサポートチームの皆様、こんにちは。 現在、S32G274Aプラットフォーム上でHSEの評価を行っており、推奨される実装方法についてご助言いただければ幸いです。 現在の環境： * デバイス: S32G274A * コア：Cortex-M7 * IDE: S32 Design Studio 3.6 * HSEパッケージ: HSE_DEMOAPP_S32G2XX_0_1_0_16 * HSEファームウェア：HSE_FW_S32G2XX_0_1_0_16 現在の進捗状況： * 私はAN14070（「S32G2のCortex-M7コアでHSEデモアプリケーションを実行する方法」）に従っています。 * HSEデモプロジェクトは正常にインポートおよびコンパイルできます。 * ただし、IVTビューを開く際に、S32DSは例外を報告し、IVTビューを作成できません。 com.nxp.swtools.ivt.views.IVTView （必要であれば、エラーログ全体を提供できます。） プロジェクトの目的： 現在、当社のブートローダーはソフトウェアベースのセキュアブートを実装しています。 1. アプリケーションイメージのSHA-256を計算します。 2. フラッシュメモリに保存されている公開鍵を使用して、RSA-2048署名を検証します。 3. 検証が成功した場合のみ、アプリケーションを起動します。 この実装をCortex-M7上のHSEベースのサービスに移行したいと考えています。 質問: 1. AN14070は、S32DS 3.6を搭載したS32G274AのHSE評価における推奨される出発点として、依然として有効ですか？ 2. IVT Viewは、以下のようなHSEサービスの評価に必須ですか？ * SHA-256 * AES * RSA署名検証 それとも、ブロブイメージの生成とHSEファームウェアのインストールにのみ必要なのでしょうか？ 3. HSEファームウェアのインストール後、以下の内容を示す参考例はありますか？ * HSEによるSHA-256計算 * HSEによるRSA-2048署名検証 * HSEキーカタログへの公開鍵のインポート 4. Cortex-M7上でソフトウェアベースのセキュアブート実装をHSEサービスに移行する方法を示すアプリケーションノート、トレーニング・マテリアル、またはデモプロジェクトはありますか？ 5. アプリケーションにジャンプする前にSHA-256 + RSA2048検証を実行するブートローダーの場合、HSEを使用した推奨移行パスは何ですか？ 何かご助言、参考となるプロジェクト、または推奨ドキュメントがあれば大変ありがたいです。 よろしくお願いいたします。 Re: S32G274A 实现SHA256+RSA2048算法 私は3を照合します。次の図に示すIVTViewには、DCD、HSE、アプリケーションブートローダー、ブートの各ブロックが表示されます。 BLOB イメージの生成に関連する構成と自動位置合わせ 我的 S32 Design Studio for S32 Platform 3.6.0打不开IVTビューエラー：ビューを作成できませんでした：com.nxp.swtools.ivt.views.IVTView java.lang.Exception at org.eclipse.ui.internal.ViewReference.createErrorPart(ViewReference.java:115) at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:101) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.createPart(CompatibilityPart.java:304) at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:342) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(ネイティブ方法) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.方法.invoke(方法.java:568) org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:58) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:976) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:938) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.internalInject(InjectorImpl.java:138) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:385) で発生 org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:311) で発生 Re: S32G274A 实现SHA256+RSA2048算法 こんにちは、 tom9 お問い合わせいただきありがとうございます。 AN14070はCortex-M7の評価における有効な出発点であり続けるが、HSEデモアプリパッケージおよびHSEファームウェアのリファレンスドキュメントと併用することを推奨する。テスト中に発生したエラーの詳細情報を私と共有していただけますか？ S32Gへのセキュアブートの適用については、以下の内容を参考にしてください。 S32G_Secure_bootの中国語/英語バージョン。 現時点では、お客様のご要望に直接合致する特定の文書はございません。確認のお手伝いをするために、内部チャネルをご案内します。結果が出たらご連絡します。 BR ジョーイ Re: S32G274A 实现SHA256+RSA2048算法 こんにちは、 tom9 ご返信よろしくお願いします。 この問題はS32DSのバージョンに関連しているはずです。HSE_DEMOAPP_S32G2XX_0_1_0_16_ReadMe.pdf を参照してください。推奨バージョンのご利用をお試しください。 BR ジョーイ Re: S32G274A 实现SHA256+RSA2048算法 ブロブの作成と書き込みは完了しましたが、シリアルポートに印刷情報が表示されず、Trace32でも読み込めません。どこからトラブルシューティングを始めればよいでしょうか？できるだけ早く確認していただけると助かります。 Re: S32G274A 实现SHA256+RSA2048算法 こんにちは、 tom9 1. AN14070に基づいて、ブロブが作成され、フラッシュされます。その後、QSPI経由でブートしてHSEファームウェアをロードし、M7_0を起動します。QSPIブート後、Trace32を使用してM7_0に接続し、SRAMの内容を確認して、アプリケーションが正しいアドレスにロードされているかどうかを確認できます。 2. アプリケーションが正常に起動した後でのみ、HSE デモの .elf ファイルをロードしてください。次に、プロセスの次のステップであるSRAMへの移行に進みます。 BR ジョーイ Re: S32G274A 实现SHA256+RSA2048算法 あなたの回答は私の期待を裏切ります。以下に示すように、現在は正常に情報を印刷できます。 HSE FW バージョン: 0.1.0_1.0.9 HSE FW 画像: ピンク HSE FWが稼働開始しました！状態： HSE_STATUS_RNG_INIT_OK HSE_STATUS_INIT_OK HSE_STATUS_CUST_SUPER_USER プログラムはここで停止し、先に進めませんでした。`DEBUG_LOOP(gZero);` をコメントアウトしたところ、`HSE_Config();` で停止していることがわかりました。/* プライマリイメージのバックアップ */ ASSERT(FLASH_OP_OK == Flash_WriteData_FromFlash(IVT.pSysImage_bck,コード`ITV.pSysImage, MAX_SYS_IMG_SIZE)`がここで停止します。`HSE_Aes_Example`などの後続コードも実行に失敗します。 Re: S32G274A 实现SHA256+RSA2048算法 こんにちは、 tom9 お客様からのご質問は弊社のサポートシステムにて受け付けております。ご依頼内容には複数の問題が含まれており、社内の専門家が既にサポートと回答を開始しております。 BR ジョーイ

Mac OS Tahoe アップデート LinkServer プローブが見つかりません そこでTahoeにアップデートしましたが、LinkServerを使ってもプローブは見つかりませんでした。LinkServerを最新にアップデートしましたが、ターミナルでディレクトリに入って手動で実行しないと動作しません ./LinkServer プローブ その後プローブが見つかり、MCUXpressoを使えます。どうやらこれは他の人にも起こる現象のようだ。 https://community.nxp.com/t5/MCUXpresso-General/LPC-Link2-not-found/mp/2200131/highlight/true#M5741 これはIDEがLinkServerを使おうとしたときに表示されるエラーです redlink>プローブリスト エラー: プローブが見つかりませんでした 私もNXPについてで働いていますが、OSをアップデートした人たちも同じ問題を抱え、同じことをしなければならないと感じています。 もっと良い解決策をご存知の方はいらっしゃいますか？ Re: Mac OS Tahoe update LinkServer No Probes found こんにちは、 @davidinsulet さん、 残念ながら、これは最新バージョンのMCUXpresso IDEにプリインストールされているLinkServerビルドの現在の制限です。とはいえ、この制限はIDEチームに特定され報告されており、将来のリリースでLinkServerのバージョンを修正できるようになっています。 その間に、あなたが共有した投稿で説明されている回避策が、MCUXpresso IDEに関してこの問題を回避する最も効果的な方法です。 あるいは、 MCUXpresso for VS Codeを使うこともおすすめします。これは私たちの最新開発プラットフォームで、IDEsのような制限はありません。 ご迷惑をおかけして申し訳ございません。 BR、 エドウィン。

How to install S32K344 A/B swap HSE FW using PeMicro debugger on S32K3x4EVB-T172 (S32K344). Hi, I want to test an OTA A/B swap demo on S32K344.  For that i'll have to install HSE (A/B) firmware on my S32K344 chip which is not having any HSE FW on it.  I have following hardware with me 1. S32K3x4EVB-T172 (S32K344) 2. PeMicro Debugger. (Note - I dont have Lauterbach TRACE32 tool ) So i request you to please provide me a proper procedure to install HSE (A/B) firmware on s32k344 using PE micro debugger with the help of S32 design studio. Please try to provide me a proper procedure where everything is mentioned like which DS version, RTD, HSE pink file etc to be used. Thanks. Re: How to install S32K344 A/B swap HSE FW using PeMicro debugger on S32K3x4EVB-T172 (S32K344). HSE DEMO code (that can be downloaded with HSE FW) use Lauterbach TRACE32. There is not dedicated examples using different debugger, but there is HSE examples package: https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples It is basically the same functionality as HSE DEMO ported to the code which is debugger independent. For instance if you use S32K344_HSE_FW_INSTALL, you may install HSE FW with using of any debugger.

IMX8QX DDR RPA_tool 配置，缺少寄存器信息 你好 我们需要有关 IMX8QX 上 DDR3L 的 RPA_tool 配置中提到的一些寄存器的信息。这里提到的寄存器地址如下 0x41C80044 0x41C80208 0x41C80204 0x41C82C00 0x41C83800 但文件中没有提供。 能否提供它们的功能及其配置字段。 谢谢 Re: IMX8QX DDR RPA_tool configuration, missing register information 你好@CPE ， 此配置文件由第三方IP供应商提供。受 NDA 约束的文档中未显示所指向的寄存器，请注意，在 i.MX8X 实现的情况下，除了提供的值之外没有其他选择。 顺祝商祺！

Difference in ADC noise between BCTU Control Mode and Trigger Mode Hello, I am working on an application using the [S32k322] where I use the eMIOS timer to trigger the BCTU every 100 µs to read analog data. I am observing a strange behavior between the two BCTU modes: Control Mode: When the ADC CTU mode is set to Control Mode, the ADC conversions are completely stable. The data read via FreeMASTER is clean and free of noise or glitches. Trigger Mode: When I switch the ADC CTU mode to Trigger Mode (keeping the 100 µs eMIOS trigger identical), the sampled analog data becomes noisy and exhibits noticeable glitches in FreeMASTER. Are there specific architectural configurations, timing constraints, or register settings (such as trigger delays, FIFO configurations, or clock synchronization) required for Trigger Mode to prevent this noise? Thank you for your help. Output with ADC ctu mode : Trigger Mode output with ADC ctu mode : Control Mode Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi@Stark_ could you please share the test project and i will test it on myside. Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi @Senlent ,    Thanks for the response. My ADC clock is 160MHz, and I've attached my ADC configuration and register values below. Clock ADC Configuration Output with ADC ctu mode : Trigger Mode output with ADC ctu mode : Control Mode Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi@Stark_ Based on the configuration screenshot you provided, there are some configuration issues, specifically the division ratios for the module clock and calibration clock. The ADC clock configuration must strictly follow the table below. please change it and test  again, Re: Difference in ADC noise between BCTU Control Mode and Trigger Mode Hi @Senlent  I have attached test code. is it possible to work on BCTU and normal conversion for the some selected channels (ADC_Instance0 and ADC_Instance1)?

i.MX8MP RAW 捕获最大几何尺寸 NXP社区的各位好， 我们正在尝试在 i.MX8MP 上使用特定的图像传感器。 我们正在尝试将 RAW12 捕获从 MIPI 推送到 RAM。看来唯一的方法是通过如下所述的 ISI 模块： 问题在于，关于几何限制的文档含糊不清，我们正在尝试确定 i.MX8MP 是否适合我们的应用。 图像的高度和宽度在 ISI 中使用 CHNL_IMG_CFG[WIDTH/HEIGHT] 寄存器定义。这些条目是 13 位的，理论上将我们限制在 8191 x 8191 的几何尺寸。 宽度似乎受到硬件的限制，因为行缓冲区实际上只能容纳 2K 像素，但文档概述了通过组合其他通道的行缓冲区来实现 4K 的方法。文档中没有说明是否可以达到 8191 像素的线宽寄存器限制。我们可以绕过 ISI 处理，我们的目标是直接将 RAW MIPI 捕获的数据推送到 RAM 中。 此外，与宽度限制不同，高度限制似乎并非由物理硬件引起。 是否有任何证据表明我们可以支持 CHNL_IMG_CFG[HEIGHT] 寄存器 13 位最大值所定义的 8191 行高度？ 任何支持都将不胜感激。我已阅读过其他类似帖子，例如以下这些： https://community.nxp.com/t5/i-MX-Processors/Direct-MIPI-CSI2-to-memory-access-on-i-MX8MP/mp/2158946 https://community.nxp.com/t5/i-MX-Processors/I-MX8MP-ISI-maximum-supported-width/mp/1224069 但是，目前尚未确认是否支持 8191 宽度，我想知道这方面是否有任何更新。 此外，高度限制也没有明确规定。 谢谢 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: i.MX8MP Maximum Geometry for RAW Capture i.MX8MP 的 ISI 驱动程序限制在 2K 分辨率，但如果使用链式缓冲区，ISI 可以支持高达 4K 的分辨率，但不支持 8191 像素宽。在 i.MX8MP 上，单个摄像头最高可支持 4K@30Hz 的分辨率。 Re: i.MX8MP Maximum Geometry for RAW Capture 感谢您的回复。 所以宽度限制与我最初的发现相符。 请问ISI模块的高度限制是多少？我们能否通过 ISI 实现 8191 车道高度？ 谢谢

LPC55S28 VBAT_PMU 电流消耗 我有一块PCB板，原理图如下。我备有一颗纽扣电池，以防PCB主电源断开。据我了解，MCU 上的 VBAT_PMU（引脚 51）专用于Always‑On (PD_AON) 域。 当我测量电池的电流消耗时（没有主电源，只有电池供电），我得到大约 102uA 的电流。这远远高于 RTC 的预期功耗，即使移除 D12 也是如此。Vbat 仅连接到 VBAT_PMU 引脚，没有连接到其他任何引脚。 这里预期会出现什么情况？我预计 VBAT_PMU 只会消耗足够的电流，以确保在断电期间 RTC 能够保持时间。102uA 的电流会很快耗尽 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 °C 和 3.0 V 的深度睡眠模式下，典型总供电电流为 110 µA；而 RTC 振荡器禁用时的深度掉电电流为 590 nA；RTC 由外部晶体供电时的深度掉电电流为 790 nA。 要使 LPC55S28 上的纽扣电池电流小于 1 µA，只需从电池为 VBAT_PMU 供电，并在移除主电源之前使固件进入深度掉电状态。 BR 哈里 Re: LPC55S28 VBAT_PMU Current Draw 感谢你的回复！ 我编写了一段代码，可以在发生低电压中断时触发深度掉电，效果很好。但这种方法存在一个巨大的问题。如果 ROM 引导加载程序正在执行，并且电源被移除，则不会设置掉电中断，也没有代码将其置于掉电状态。 有没有什么好办法可以保证我能进入深度关机模式？如果任何状态使MCU处于正常模式，电池就会耗尽。或许我遗漏了什么。如果不行，我可能就得在板子上加装一个外置实时时钟芯片了。