如何获取BMA8420的完整数据手册？非产品简介   主题：关于氢燃料电池堆电化学阻抗谱测量用BMA8420的咨询   尊敬的技术支持团队： 我目前正在开发用于氢燃料电池的电化学阻抗谱（EIS）测量系统。   为了使用BMA8420 ，我想查看其技术规格，但我一直没能在网上找到数据表。   非常感谢您能就以下问题提供指导： BMA8420 能否用于测量氢燃料电池堆的电化学阻抗谱 (EIS)？ 如何获取BMA8420的完整数据手册（非产品简介）？ 韩国的联系点？ 感谢您的支持，期待您的回复。   此致， 金杨     BMA8420 <-- 链接 image.png #BMA8420

外部启动 S32k S32k344 设备最初是否从内部 ROM 执行不可变的第一阶段引导加载程序？如果可以，能否将此 ROM 引导加载程序配置为从外部源（例如外部闪存）加载辅助引导加载程序（或应用程序映像）？ 如果支持外部启动，应该如何配置才能让初始引导加载程序知道从哪里获取启动项？ Re: External Boot S32k 嗨@CTCoder1 是的，S32K344 包含 SBAF 代码，该代码在 RESET 后执行。然而，这不应被视为可以直接从任意外部存储器加载应用程序的可配置引导加载程序。不支持外部启动。 正常的 S32K3 启动流程仅要求启动信息/应用程序位于内部代码闪存中。例如，可以将用户引导加载程序放置在内部闪存的开头（IVT 地址为 0x00400000），然后执行所需的任何更新/加载机制。 因此，如果目的是将应用程序存储在外部闪存中，通常的解决方案是将用户引导加载程序放在内部闪存中。该引导加载程序初始化所需的外部/外部存储器接口，从外部设备读取映像，然后将其编程到内部闪存中，或根据应用程序的要求对其进行处理。 没有 SBAF（或者我们可以说 BootROM）配置，您只需指定外部闪存地址/设备，S32K344 SBAF 就可以直接从那里启动应用程序。这需要完全由您的软件来管理。 此致， Lukas

S32K3xx 主ECU密钥或客户/OEM授权密钥导入 您好，NXP， 一如既往地感谢大家的支持。 根据您之前对我们 FBL 相关询问的回复，我们了解到，当生命周期处于现场状态时，必须预先配置 MASTER_ECU_KEY 或 CUST/OEM 授权密钥才能获得超级用户 (SU) 权限，并且一旦设备已处于现场状态，就无法配置 MASTER_ECU_KEY。 请问我们的理解是否正确？ 目前，这两个密钥都尚未配置。为防止将来出现类似问题，我们希望预先配置 MASTER_ECU_KEY 或 CUST/OEM 授权密钥，以便在设备进入现场状态后格式化 NVM/RAM 密钥目录并注入 HMAC 密钥。 我们有几个问题，如下所示： 1.在这个项目中，FBL认证不是基于SHE的。它采用的是RSA公钥签名验证。但是，CRYPTO_SPT_SHE 配置为 STD_ON。 在这种情况下，我们应该配置 MASTER_ECU_KEY，还是应该配置 CUST/OEM 授权密钥？ 2. 是否有任何指南或参考文档说明如何导入 MASTER_ECU_KEY 或 CUST/OEM 授权密钥？ 谢谢。 顺祝商祺！ Re: S32K3xx Master_ECU_KEY or CUST/OEM authorization key import 嗨@jeongwoo 授权密钥应根据当前生命周期和您需要与之操作的密钥所有者进行配置。 在 CUST_DEL 中，您可以配置 CUST 授权密钥。将设备升级到 OEM_PROD 后，即可配置 OEM 授权密钥，并使用该密钥获取 OEM 拥有的密钥的超级用户权限。 在 CUST_DEL 状态下，您无法配置 OEM 拥有的密钥，因为此时您没有可以授权该操作的 OEM 授权密钥。因此，在设备处于 CUST_DEL 状态时，在推进生命周期之前，应该已经定义了所需所有者的关键目录。 迁移到 OEM_PROD 后，目录无法重新格式化，因为关键目录格式仅限于 CUST_DEL。这种生命周期转变也是不可逆的。 因此，如果您打算同时拥有 CUST 和 OEM 授权功能，请先在目录中定义所需的 CUST 和 OEM 密钥组，在 CUST_DEL 中配置 CUST 授权密钥，然后进入 OEM_PROD，最后配置 OEM 授权密钥。 您可以查看这个帖子了解详情： https://community.nxp.com/t5/S32K/Change-is-not-possible-in-LC-OEM-PROD/m-p/2356576 在 HSE 层面，密钥导入程序在 HSE-B 固件参考手册 rev. 中的“6.2.3 密钥导入”部分进行了描述。2.8 然后查看 HSE 固件版本的 HSE 服务 API 参考手册中“struct hseImportKeySrv_t”的描述。 在 Autosar Crypto 驱动程序层面，它由 Autosar 规范规定。您可以在 RTD_CRYPTO_43_HSE_UM.pdf 中阅读 Crypto_43_HSE_KeyElementSet() 和 Crypto_43_HSE_KeySetValid() API 的描述。 授权密钥的导入方式与其他密钥相同，只需在配置器中为该密钥设置 USAGE_AUTHORIZATION 和 USAGE_VERIFY 密钥标志即可。 此致， Lukas

S32DS S32K358 プロジェクトに関するお問い合わせ wj_kwak_0-1789777426372.pngwj_kwak_0-1789777426372.png S32K358プロジェクトの作成について質問があります。 M7_0とM7_2という2つのプロジェクトが作成されている理由が気になります。 「ブートコアツールチェーンを継承する」ボタンの機能を知りたいです。 チームメイトによると、参考ドキュメントではM7_0がブートローダー領域、M7_2がアプリケーションエリアと書かれていますが、ドキュメントで確認できていません。この点について確認させてください。 Re: S32DS S32K358 Project Inquiry こんにちは、 @wj_kwak S32K358の場合、S32DSはデフォルトで2つの独立したプロジェクトを作成します。1つはM7_0用、もう1つはM7_2用です。これらのプロジェクトは2つのプロセッシングコアに対応しています。これらはブートローダー領域やアプリケーション領域を表していません。 S32DSのプロジェクト作成ウィザードは通常、両方のコアのアプリケーションを含む単一のプロジェクトを作成することはありません。そのようなプロジェクト構造が必要な場合は、手動で作成／設定する必要があります。しかし、ほとんどの場合、これは必要なく、一般的なアプローチは各コアごとに独立したプロジェクトを2つずつ使うことです。 「ブートコアツールチェーンを継承する」オプションは、ブートコアプロジェクトからツールチェーン構成を継承するために使えます。有効にすれば、ツールチェーンはCortex-M7_0_0専用に選択できます。Cortex-M7_0_2のツールチェーン選択は、Cortex-M7_0_0の設定が適用されるためグレーアウトになります。 また、ここに提供されているマルチコアの例やドキュメントも参照できます: community.nxp.com/t5/S32K/S32K324-Multi-Core-Example-Project-based-on-Whiteboard/m-p/1547771 このパッケージは両方のアプローチを示しています:各コアごとに独立したプロジェクト、そして両方のコアに対して単一のプロジェクトを単一のELFファイルにコンパイルします。 SO、M7_0とM7_2はブートローダーやアプリケーションプロジェクトとして理解すべきではありません。これらは、それぞれのコアに関連付けられたプロジェクトにすぎません。 よろしくお願いいたします。 ルーカス

外部ブート S32k S32k344デバイスは、最初に内部ROMから変更不可能な第1段階ブートローダーを実行しますか？もしそうなら、このROMブートローダーは外部フラッシュなどの外部ソースから二次ブートローダー(またはアプリケーションイメージ)をロードするように設定できますか? 外部ブートをサポートしている場合、初期ブートローダーがどこから引き出せばよいか、どのように設定すればよいのでしょうか? Re: External Boot S32k こんにちは、 @CTCoder1さん はい、S32K344にはリセット後に実行されるSBAFコードが含まれています。しかし、これは任意の外部メモリから直接アプリケーションをロードできる設定可能なブートローダーとは見なすべきではありません。外部ブートはサポートされていません。 通常のS32K3ブートフローでは、内部コードのフラッシュのみにブート情報やアプリケーションが反映されることを期待します。例えば、ユーザーのブートローダーを内部フラッシュの開始(IVTは0x00400000)に配置し、必要な更新/読み込みメカニズムを実行することができます。 したがって、アプリケーションを外部フラッシュに保存する意図がある場合、通常の解決策はユーザーブートローダーを内部フラッシュに設定することです。このブートローダーは必要なペリフェラル/外部メモリインターフェースを初期化し、外部デバイスからイメージを読み込み、それを内部フラッシュにプログラムするか、アプリケーションの要件に応じて処理します。 SBAF(あるいはBootROM)構成は存在しません。単に外部フラッシュアドレスやデバイスを指定して、S32K344 SBAFがそこからアプリケーションを直接起動させるようなものです。これは完全にソフトウェアで管理する必要があります。 よろしくお願いいたします。 ルーカス

i.MX6ULL以太网接口在接头温度高于95℃时断开连接 您好，NXP， 我们使用 i.mx6ull 08AB 版本设计了我们的产品，并发现了一个如下所示的问题。 1>零件编号： MCIMX6Y2CVM08AB 2>问题： 当接头温度高于 95℃ 时，部分板会出现以太网断开连接的问题。 您有什么建议可以帮助我们解决这个问题吗？ 非常感谢。 i.MX6UL Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ 您的客户中有多少家主板存在这个问题？他们测试的是哪个版本的BSP？

E6500 / E5500割り込みパス、RFI対RFCIおよびその他のファミリ命令 こんにちは、 RFIやその他のファミリ命令は、さまざまな割り込みや例外からの返却に使用されます。 E5500およびE6500プロセッサで、SRR0とSRR1が正しい値に戻されている限り(CSRR0、CRSRR1、MCSRR0、MCSRR1などから最初に読み取れる可能性が高い)、それともプロセッサ内部の機構が壊れるのか知りたいです。 よろしくお願いいたします。 アレクシー・トーレス QorIQ T1 デバイス QorIQ T2デバイス Re: E6500 / E5500 Interrupt Path, RFI vs RFCI and other family instructions 迅速なご回答ありがとうございます。それは我々が考えていたことを裏付けるものだ。 Re: E6500 / E5500 Interrupt Path, RFI vs RFCI and other family instructions E5500およびE6500では、SRR0/SRR1レジスタにCSRR0/CSRR1またはMCSRR0/MCSRR1からコピーした値を手動でプリロードした場合でも、「RFI」を他の割り込み復帰命令（「RFCI」、「RFMCI」など）に普遍的に置き換えることは推奨されません。 各リターン命令は、特定の保存/復元レジスタペアからMSRを復元します。「RFI」を使うと必ずSRR1から復元されますが、回復されるMSRビット(マスクや強制されるもの)は命令によって異なる場合があります。レジスタ値だけでなく、ハードウェアレベルでは、`RFCI` または `RFMCI` によって一部のビットの処理方法が異なる場合があります。 「RFCI」と「RFMCI」は「CSSR」/「MCSR」の状態をクリアし、割り込みレベルの内部プロセッサトラッキングを更新します(例:MSRの「CE」/「ME」有効ビット)。手動でコピーした値を「RFI」だけ使用すると、クリティカル/マシンチェック割り込み状態が正しく再有効化またはクリアされず、プロセッサが内部的に不整合な状態に陥る可能性があります。 Power Architecture Embedded Environment(EREF)仕様では、各例外クラスから返すためにどの命令を使うべきかを明示的に定義しています。これから逸脱するとアーキテクチャ的に定義された挙動の範囲外であり、これらのコアに予測不可能な結果をもたらす可能性があります。 推奨される方法は、rfi は標準/非クリティカルな戻り値にのみ使用し、関連する割り込みクラスには rfci、rfdi、rfgi、または rfmci を使用することです。

RT685 DPD wake via PMIC_IRQ_N not working HW: RT685 + PCA9420, PMIC_IRQ_N connected to RT685 dedicated pin. Problem: POWER_EnterDeepPowerDown(exclude_from_pd={0,0,0,0}) → MCU loses power (VDDCORE off). Pull PMIC_IRQ_N low → no wake. Manually shorting PMIC_IRQ_N to GND for ~1s also does not wake.  Code before entry  :   BOARD_InitPmic(); BOARD_ConfigPMICModes(); BOARD_SetPmicVoltageBeforeDeepPowerDown(); POWER_EnableInterrupts(kPMC_INT_INTRPAD); EnableDeepSleepIRQ(PMC_PMIC_IRQn); BOARD_EnterDeepPowerDown(exclude_from_pd); ```   PMC->FLAGS after failed wake: 0x60170000, DEEPPDF (bit31) = 0. WAKE_UP_WITH_PMIC_IRQ_N = 1. Questions : Is additional RT685-side config needed to make PMIC_IRQ_N a valid DPD wake source? Does PCA9420 stop driving PMIC_IRQ_N when VDDCORE is cut via DPD Anyone successfully used PMIC_IRQ_N to wake RT685 from DPD? Working config?     i.MX-RT600  SERVER-POWER-CONTROL                       Power Re: RT685 DPD wake via PMIC_IRQ_N not working Hi @wx1 , Regarding PMC->FLAGS after failed wake: 0x60170000, DEEPPDF (bit31) = 0. WAKE_UP_WITH_PMIC_IRQ_N = 1.  The reason to have this result is due to that  DEEPPDF (bit 31 of PMC->FLAGS ) is only set when the MCU successfully completes a full DPD cycle and wakes from it. A value of 0 means the MCU never cleanly entered DPD. The co-existing WAKE_UP_WITH_PMIC_IRQ_N = 1 tells you that the PMC detected a low pulse on PMIC_IRQ_N, but the DPD state was never committed. This pattern almost always means PMIC_IRQ_N was already asserted (logic-low) at the moment DPD entry was attempted, causing an immediate phantom wake before DPD could latch. When PMIC_MODE[1:0] transitions to 0b10 (DPD mode, VDDCORE off), the PCA9420 internally detects that SW1_OUT is dropping. This can trigger a brief INTB pulse due to the PCA9420's voltage supervisor logic firing on the SW1 output. If that pulse reaches the PMC before DPD is fully committed, you get exactly what you are seeing. Is additional RT685-side config needed to make PMIC_IRQ_N a valid DPD wake source? Before arming DPD, drain any pending PCA9420 interrupts so that INTB is deasserted (high) when DPD latches. Does PCA9420 stop driving PMIC_IRQ_N when VDDCORE is cut via DPD PMIC_IRQ_N is on the VDD_AO1V8 always-on domain, which stays powered throughout DPD. The PCA9420 INTB output is open-drain and powered from VIN, so as long as VIN (your system supply) is present the PCA9420 can still drive INTB low.   Hope that makes sense,   Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

S32K314 get stuck at 0x2040012C WFI during HSE recovery in AB swap Hello NXP Support Team, I am testing HSE recovery in AB swap as following steps. Firstly, I use lauterbach to execute HSE FW erase to erase HW, then test the recovery process. The CPU always stops at at 0x2040012C WFI instruction after step 9 issue a functional reset, I need to power off, then power on to get out of this.  Could you please give some tips on what's going wrong?  leo_cheng_0-1789995644535.png leo_cheng_1-1789995683683.png Re: S32K314 get stuck at 0x2040012C WFI during HSE recovery in AB swap Hi @leo_cheng  If it hangs at 0x2040012C after reset, it means that the device entered JTAG based recovery  mode. You can take a look at “2.6.1.3 Recovery Mode” section in the HSE-B Firmware reference manual. If you want to recover using Lauterbach debugger, I wrote attached script which follows section “3.3.1  MU Installation Steps by Host in AB_SWAP Configuration”. It works for installation of the firmware on brand new device and it works for recovery when the firmware is erased completely or when there’s backup image in passive partition. Regards, Lukas

CBTL04083ABS こんにちは、みんな、 現在、 CBTL04083ABS (4チャンネル、2:1 PCIe Gen3マルチプレクサ/デマルチプレクサ)を含むレイアウトおよび信号整合性シミュレーションプロジェクトに取り組んでいます。 残念ながら、公開製品ページやデザインリソースの中から直接IBISモデルを見つけることはできませんでした。私は個人開発者で企業向けの企業アカウントを持っていないので、このデバイスのIBISモデル(または利用可能ならタッチストーン/Sパラメータファイル)をどなたか教えていただけませんか? よろしくお願いいたします。 よろしくお願いします、 ヴォルフガング Re: CBTL04083ABS こんにちは、ヴォルフガングさん。 添付の報復IBISモデルをご覧ください。 BRs、トーマス

S32K314 が AB スワップ中の HSE リカバリ中に 0x2040012C WFI で停止する こんにちは、NXPサポートチームの皆さん、 以下の手順で、ABスワップにおけるHSEリカバリのテストを行っています。まず、lauterbachを使用してHSE FW eraseを実行し、ハードウェアを消去してから、リカバリプロセスをテストします。ステップ9で機能リセットを発行した後、CPUは常に0x2040012CのWFI命令で停止します。この状態から抜け出すには、電源をオフにしてからオンにする必要があります。何がうまくいっていないのか、アドバイスをいただけますか? leo_cheng_0-1789995644535.png leo_cheng_1-1789995683683.png Re: S32K314 get stuck at 0x2040012C WFI during HSE recovery in AB swap こんにちは、 @leo_cheng さん。 リセット後に0x2040012Cでハングアップする場合、デバイスがJTAGベースのリカバリモードに入ったことを意味します。「2.6.1.3」をご覧ください。HSE-Bファームウェアリファレンスマニュアルの「リカバリーモード」セクションに記載されています。 Lauterbach デバッガーを使用して復旧したい場合は、セクション「3.3.1」に従って、添付のスクリプトを作成しました。「AB_SWAP構成におけるホストごとのMUインストール手順」これは、新品のデバイスへのファームウェアのインストールに有効であり、ファームウェアが完全に消去された場合や、パッシブパーティションにバックアップイメージが存在する場合の復旧にも有効です。 よろしくお願いいたします。 ルーカス

CBTL04083ABS 大家好， 我目前正在进行一个布局和信号完整性仿真项目，其中包括CBTL04083ABS （4 通道，2:1 PCIe Gen3 多路复用器/解复用器）。 遗憾的是，我在公开产品页面或设计资源中都找不到 IBIS 型号。由于我是一名独立开发者，没有企业账户，请问谁能提供该设备的 IBIS 模型（或者如果有的话，提供 touchstone/S 参数文件）？ 非常感谢您的帮助！ 此致， 沃尔夫冈 Re: CBTL04083ABS 你好，沃尔夫冈， 请查收附件中所需的IBIS模型。 BRs，托马斯

CBTL04083ABS Hello everyone, I am currently working on a layout and signal integrity simulation project that includes the CBTL04083ABS (4-channel, 2:1 PCIe Gen3 multiplexer/demultiplexer). Unfortunately, I couldn't find an IBIS model directly on the public product page or under the design resources. Since I am an individual developer and do not have an enterprise corporate account, could anyone please provide me with the IBIS model (or touchstone/S-parameter files if available) for this device? Thank you very much for your help! Best regards, Wolfgang Re: CBTL04083ABS Hello Wolfgang, Please find attached the requited IBIS model. BRs, Tomas

RT685 DPDのPMIC_IRQ_Nによるウェイクアップが機能しない HW:RT685 + PCA9420、PMIC_IRQ_N RT685専用ピンに接続されています。 問題: POWER_EnterDeepPowerDown(exclude_from_pd={0,0,0}) →MCUが電源を失います(VDDコアがオフ)。ウェイク→PMIC_IRQ_Nを下げてください。手動でGNDにショートPMIC_IRQ_Nさせて~1秒も起動しません。 入力前にコードを入力してください  :   BOARD_InitPmic(); BOARD_ConfigPMICModes(); BOARD_SetPmicVoltageBeforeDeepPowerDown(); POWER_EnableInterrupts(kPMC_INT_INTRPAD); EnableDeepSleepIRQ(PMC_PMIC_IRQn); BOARD_EnterDeepPowerDown(exclude_from_pd); 「`」   PMC->FLAGS ウェイク失敗後: 0x60170000、DEEPPDF (bit31) = 0。 PMIC_IRQ_Nで起動 = 1. 質問 : PMIC_IRQ_Nを有効なDPDウェイクソースにするには、RT685側で追加の設定が必要ですか？ DPD を介して VDDCORE が切断された場合、PCA9420 は PMIC_IRQ_N の駆動を停止しますか? PMIC_IRQ_Nを使用してRT685をDPDからウェイクアップすることに成功した方はいますか？動作する設定はありますか？     i.MX-RT600サーバー電源制御                     パワー Re: RT685 DPD wake via PMIC_IRQ_N not working こんにちは、 @wx1 さん。 PMC->FLAGSについて:0x60170000、DEEPPDF(ビット31)= 0. WAKE_UP_WITH_PMIC_IRQ_N = 1。この結果が出る理由は 、 DEEPPDF ( PMC->FLAGS のビット31)がMCUが完全なDPDサイクルを完了し、そこからウェイクアップした場合にのみ設定されるためです。値が 0 の場合は、MCUがDPDにきれいに入っていなかったことを意味します。共存する WAKE_UP_WITH_PMIC_IRQ_N = 1 は、PMC が PMIC_IRQ_N で低パルスを検出したが、DPD 状態がコミットされなかったことを示しています。このパターンはほとんどの場合、 DPDの入力が試みられた時点ですでにPMIC_IRQ_Nが主張されていた(論理低値)であり、DPDがラッチする前に即座にファントムウェイクが発生しています。 PMIC_MODE[1:0] が 0b10 に遷移すると（DPDモード、VDDCOREオフ）、PCA9420は内部的にSW1_OUTが低下していることを検出します。これにより、PCA9420の電圧スーパーバイザロジックがSW1出力で発動するため、短いINTBパルスがトリガーされることがあります。そのパルスがDPDが完全に作動する前にPMCに到達すると、まさに今見ているような現象が起こります。 PMIC_IRQ_Nを有効なDPDウェイクソースにするには、RT685側で追加の設定が必要ですか？ DPDを起動する前に、保留中のPCA9420中断中の割り込みを排水し、DPDがラッチしたときにINTBが解除される(高く)します。 DPD を介して VDDCORE が切断された場合、PCA9420 は PMIC_IRQ_N の駆動を停止しますか? PMIC_IRQ_Nは VDD_AO1V8 常時オンドメイン上にあり、DPD期間中ずっと電源が供給されています。PCA9420のINTB出力はオープンドレインでVINから電力が供給されているため、VINが存在している限りPCA9420はINTBの低電圧を駆動できます。   これで意味が通じるといいのですが。   すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

S32K3 MCU secure unlock error I am using the P&E Cyclone FX programmer to unlock an S32K311 MCU that may be an abnormal part. When executing the script, an error is reported. Sometimes the script executes successfully, but even in those cases, the programmer still shows "Enable Secure" when connecting. Could you please help me investigate the possible cause? The error information is as follows: Authenticating S32K3xx in Password Mode. Connecting to debug hardware ... ok. Requesting Debug Module Power On via SWD ... ok. Reading SDA AP ID Register ... ok. Reading/Writing SDA AP KEYRESP0 ... ok. Reading/Writing SDA AP KEYRESP1 ... ok. Reading/Writing SDA AP KEYRESP2 ... ok. Reading/Writing SDA AP KEYRESP3 ... ok. Writing SDA AP AUTHCTL.HSEAUTHREQ ... ok. Writing SDA AP DBGENCTRL.GDBGEN and DBGENCTRL.CDBGEN ... ok. Reading SDA AP ID Register ... ERROR !!!!!!!!!!!!!!!!!!!!! . ( 0xf0e0d0c ) Re: S32K3 MCU secure unlock error Have you ever get it to run? Are you trying to unsecure previsously secured device or it is somehow unexpected response? Do you have mutliple boards acting like this or it is just this one? Please provide further details. Thanks

LPC845 PINT 中断延迟 你好 我正在开发一个有严格限制的应用程序。 我的问题与 PINT 延迟有关。据我了解，Arm Cortex M0+ 中断的典型延迟时间约为 15 个时钟周期。我的时钟频率为 30Mhz。 因此，我希望延迟时间在 0.5 到 1uSec 之间。 我测量了信号和中断之间的时间，在中断头之后立即撬起一个引脚，实际上我得到了 7uSecs 的时间。 在检查汇编程序时，我只看到中断头部有几条指令（不到 10 条）。 PINT 中断是唯一一个优先级为 0 的中断。 这是正常现象还是我做错了什么？ 感谢所有回答问题的人、 Re: LPC845 PINT Interrupt latency 你好@carlos_o，感谢您的回答。 我使用的是定制硬件。我使用 2400Hz 的方波发生器进行测量，输出连接到 LPC 的一个引脚。进入 irq 的第一条指令会改变另一个引脚的状态。比方说，我有一个带有两个探头的示波器：一个在输入引脚上，另一个在输出引脚上。我测量的是两条战线之间的时间差。 我真的弄丢了 IRQLATENCY 寄存器！谢谢你指出来。实际上，它的默认配置是 0x10。 引脚中的输入滤波器被禁用，但我激活了磁滞。 据我所知，GPIO 的管理频率与内核相同，改变引脚状态需要一个周期。我想输入也是如此。我有一个问题：从数据表来看，似乎GPIO绕过了总线，直接连接到内核，但是指令和数据访问需要总线。那么，如果 DMA 使用总线进行突发传输，中断能否延迟？ 谢谢 Re: LPC845 PINT Interrupt latency 你好@xs_graziano 感谢您的来信 你能确认一下你是否在使用定制主板吗？如果不是，请说明您使用的是哪个主板。 请分享你是如何测量触发中断的时间的。 您是否修改过 IRQLATENCY 寄存器？ BR 卡洛斯 Re: LPC845 PINT Interrupt latency 我又做了一些检查。将引脚设置为高电平再立即设置为低电平需要 4 条 asm 指令，总共最多 5 个时钟周期。我得到了 255 nSecs，这与 20Mhz 的时钟频率相匹配（我的预期是 160 nSecs）。 所以，我把主时钟设置为别针上的时钟，而且我的示波器上有一个清晰的 30Mhz。 系统配置为 30Mhz FRO 作为主时钟，SYSAHBCLKDIV 设置为 1（一），因此没有分频。 如果主时钟在时钟输出端（通过 SYSCON 连接）显示为 30Mhz，那么它的内核运行时钟频率也可能较低？ 还是有什么东西拖慢了核心的运行速度？ ...我想我找到了问题的部分原因：FLASH 的访问时间拖慢了内核的运行速度。更改闪存访问时间会带来很大的改进。 但我没有在数据表中看到任何关于最短保证访问时间的细节，也没有看到它的条件。 如果说指令时间有所改善，那么中断延迟则有所改善（现在为 5uSec，闪存的访问时间为 2 个系统时钟），但仍与预期相去甚远。 Re: LPC845 PINT Interrupt latency 7 µs 的延迟（在 30 MHz 时约为 210 个周期）超过了内核的 15 个周期的理论最小值，这主要是由于外设总线同步、GPIO 输入毛刺滤波器和内存等待状态，而不是内核执行时间。引脚中断 (PINT) 需要多个外设时钟周期才能将异步外部信号与系统时钟同步，此外，如果代码或向量表位于闪存而不是 RAM 中，还可能存在总线仲裁延迟和闪存延迟。

RVT70HSTNWC00-B (ILI2132A) 和 MIMXRT1176-evkb 您好， 我目前正在使用MIMXRT1176-EVKB进行一个项目。在这个项目中，我希望在RVT70HSTNWC00-B显示屏上显示一些屏幕，并能够注册触摸坐标。 我已经通过NXP论坛上的另一篇文章获得了一个可以正常工作的屏幕： https://community.nxp.com/t5/i-MX-Processors/Creating-a-driver-for-a-MIPI-LCD/mp/1772322 我唯一的问题是，此显示器的触摸驱动程序（ ILI2132A ）与其他驱动程序（例如 GT911）的工作方式略有不同，但仍然使用 I²C 作为协议，而 SDK 中没有使用此驱动程序的示例。 有没有人有基于 MIMXRT1170 系列芯片的解决方案？ 欢迎提供任何帮助和信息。 提前感谢！ 通信与控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） Re: RVT70HSTNWC00-B (ILI2132A) with MIMXRT1176-evkb 嗨@KobeV ， 我们目前没有为 ILI2132A 提供合适的驱动程序，但 RT1170-EVKB 支持 Zephyr，Zephyr 有一个名为“input_ili2132a.c”的触摸 IC 驱动程序（文档， GitHub ）。 考虑到 ILI2132A 触摸 IC 的具体功能已经在该驱动程序中实现，迁移到裸机驱动程序的过程是完全可以实现的。该驱动程序中使用的所有 GPIO 和 I2C 功能在我们的 SDK 中都应该已经有了对应的底层硬件版本，所以我建议迁移或基于该 SDK 创建您自己的驱动程序。 此外，由于 Zephyr 已经支持 RT1170-EVKB，因此您可以使用基于 Zephyr 的项目进行测试场景，以确保驱动程序的功能，并在任何迁移过程之前调试其功能。 BR， 埃德温。 Re: RVT70HSTNWC00-B (ILI2132A) with MIMXRT1176-evkb 您好， 经过大量的测试和故障排除，我仍然无法使用 ILI2132A 驱动程序使 RVT70HSTNWC00-B 显示屏的触摸功能正常工作。 为了让您对我的设置有所了解，我正在使用 MCUXpresso，该项目还集成了 Crank Storyboard。我的目标是轮询触摸驱动程序，并根据触摸输入触发相应的 Storyboard 事件（例如移动、按下和释放）。 最近，我发现了一个 GitHub 存储库，其中实现了 ILI2132A 驱动程序，但它使用的是 Arduino (.ino) 项目。我尝试修改附加文件，并将 Arduino 代码转换为适合我的环境的 C 文件。以下是我用以下代码实现的方案（请查看： sbengine_task_vglite.c ）。 尽管做了这些改变，触摸显示屏仍然没有任何反应。我想知道我的代码中是否存在错误，或者我的项目中的其他外部配置和设置是否需要调整。 作为参考，以下是原始 Arduino 项目的 GitHub 页面链接： https://github.com/riverdi/ctp-ilitek-arduino-demo/tree/master 非常感谢您能提供任何指导或见解。 Re: RVT70HSTNWC00-B (ILI2132A) with MIMXRT1176-evkb 您好， 这是对我在本论坛上回复的回应。经过几周的努力，这个问题终于成功解决了。来自https://github.com/riverdi/ctp-ilitek-arduino-demo的 Arduino 代码如果你自己把它转换成C代码，就能完美运行。 驱动程序和板的问题在于 MIPI LCD 连接器 J48 没有自己的 3.3V 或更高的电源（它有，但没有连接到外部引脚）。我认为，显示屏背光需要大约 8V 电压，触摸需要 3.3V 电压。作为解决方案，我使用实验室电源提供了这些电压。背光灯工作正常，但触摸屏显示的形状却很奇怪。信号强度保持在最高 1.8V。可以看到 CLK 引脚上有一个漂亮的方波，但是电压是 1.8V 而不是 3.3V。此外，驱动芯片消耗了巨大的电流，我至今仍不知道是什么原因造成的。 通过施加单独的 3.3V 电源解决了这个问题。这可以通过从另一个 GPIO 引脚取 3.3V 电压来实现。请注意，所有不同电源的 GND 都必须与 NXP 板的 GND 连接在一起，否则会出现奇怪的情况。 触摸功能目前还不完善，但这更多是固件问题，而不是硬件问题。我认为，对于遇到同样问题的人来说，由于时间因素，需要采用不同的解决方案。具体来说，我的项目中使用的是 FreeRTOS，这使得固件中的时序略有不同。 希望这些信息能帮助到其他人。如果还有疑问，请随时提问！

S32K314 在 AB 交换期间的 HSE 恢复中卡在 0x2040012C WFI。 您好，NXP支持团队， 我正在按以下步骤测试 AB 互换中的 HSE 恢复情况。首先，我使用 lauterbach 执行 HSE FW erase 来擦除硬件，然后测试恢复过程。CPU 在步骤 9 发出功能性复位指令后，总是停留在 0x2040012C WFI 指令处，我需要断电重启才能解决这个问题。请问您能否就哪里出了问题提供一些建议？ leo_cheng_0-1789995644535.png leo_cheng_1-1789995683683.png Re: S32K314 get stuck at 0x2040012C WFI during HSE recovery in AB swap 嗨@leo_cheng 如果 RESET 后卡在 0x2040012C，则表示设备已进入基于 JTAG 的恢复模式。您可以查看“2.6.1.3”。HSE-B 固件参考手册中的“恢复模式”部分。 如果您想使用 Lauterbach 调试器进行恢复，我编写了附件脚本，该脚本遵循“3.3.1”节。AB_SWAP 配置中主机 MU 安装步骤”。它适用于在新设备上安装固件，也适用于固件完全擦除或被动分区中有备份映像时的恢复。 此致， Lukas

RT685 DPD 通过 PMIC_IRQ_N 唤醒不起作用 硬件：RT685 + PCA9420，PMIC_IRQ_N 连接到 RT685 专用引脚。 问题： POWER_EnterDeepPowerDown(exclude_from_pd={0,0,0,0}) → MCU 断电（VDDCORE 关闭）。将 PMIC_IRQ_N 拉低 → 无法唤醒。手动将 PMIC_IRQ_N 短接到 GND 约 1 秒也无法唤醒。 入口前需输入代码  ：   BOARD_InitPmic(); BOARD_ConfigPMICModes(); BOARD_SetPmicVoltageBeforeDeepPowerDown(); POWER_EnableInterrupts(kPMC_INT_INTRPAD); EnableDeepSleepIRQ(PMC_PMIC_IRQn); BOARD_EnterDeepPowerDown(exclude_from_pd); ```   PMC->FLAGS 唤醒失败后：0x60170000，DEEPPDF（位31）= 0。 WAKE_UP_WITH_PMIC_IRQ_N = 1. 问题 ： 是否需要额外的 RT685 端配置才能使 PMIC_IRQ_N 成为有效的 DPD 唤醒源？ 当通过 DPD 切断 VDDCORE 时，PCA9420 是否会停止驱动 PMIC_IRQ_N？ 有人成功使用 PMIC_IRQ_N 从 DPD 唤醒 RT685 吗？配置可行吗？     i.MX-RT600服务器电源控制                     电源 Re: RT685 DPD wake via PMIC_IRQ_N not working 嗨@wx1 ， 关于唤醒失败后的 PMC->FLAGS ：0x60170000，DEEPPDF（位31）= 0。 WAKE_UP_WITH_PMIC_IRQ_N = 1. 出现此结果的原因是，只有当 MCU 成功完成一个完整的 DPD 周期并从中唤醒时， DEEPPDF （ PMC->FLAGS 的第 31 位）才会设置。值为 0 表示 MCU 从未干净地进入 DPD。共存的 WAKE_UP_WITH_PMIC_IRQ_N = 1 表示 PMC检测到 PMIC_IRQ_N 上的低脉冲，但 DPD 状态从未被提交。这种模式几乎总是意味着在尝试进入 DPD 时 PMIC_IRQ_N 已经钳位（逻辑低） ，导致在 DPD 锁存之前立即出现幻觉唤醒。 当 PMIC_MODE[1:0] 过渡到 0b10 （DPD 模式，VDDCORE 关闭）时，PCA9420 内部检测到 SW1_OUT 正在下降。由于 PCA9420 的电压监控逻辑在 SW1 输出端触发，这可能会触发短暂的 INTB 脉冲。如果该脉冲在 DPD 完全执行之前到达 PMC，就会出现你现在看到的情况。 是否需要额外的 RT685 端配置才能使 PMIC_IRQ_N 成为有效的 DPD 唤醒源？ 在启用 DPD 之前，清除所有待处理的 PCA9420 中断，以便在 DPD 锁存时 INTB 被取消置位（高电平）。 当通过 DPD 切断 VDDCORE 时，PCA9420 是否会停止驱动 PMIC_IRQ_N？ PMIC_IRQ_N 位于 VDD_AO1V8 始终开启功能域中，在整个 DPD 期间保持通电状态。PCA9420 INTB 输出为开漏输出，由 VIN 供电，因此只要 VIN（您的系统电源）存在，PCA9420 仍然可以将 INTB 拉低。   希望我解释清楚了。   祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

E6500 / E5500 Interrupt Path, RFI vs RFCI and other family instructions Hello, The RFI and other family instructions are used to return from different types of interrupts / exceptions.  I would like to know if it is possible on the E5500 and E6500 processor to always use RFI as long as the SRR0 and SRR1 are restored to the correct value (potentially initially read from CSRR0, CRSRR1 or MCSRR0, MCSRR1, etc.) or if it would break some internal mechanism of the processor. Best Regards, Alexy Torres QorIQ T1 Devices QorIQ T2 Devices Re: E6500 / E5500 Interrupt Path, RFI vs RFCI and other family instructions Thank you for the quick answer. That confirms what we have been thinking. Re: E6500 / E5500 Interrupt Path, RFI vs RFCI and other family instructions On the E5500 and E6500, it is not recommended to universally substitute  “RFI” for the other return-from-interrupt instructions (“RFCI”, “RFMCI”, etc.), even if the SRR0/SRR1 registers are manually pre-loaded with values copied from CSRR0/CSRR1 or MCSRR0/MCSRR1. Each return instruction restores the MSR from a specific save/restore register pair. Using `RFI` always restores from SRR1, but the MSR bits that are restored (and which are masked or forced) can differ depending on the instruction. Some bits may be handled differently by `RFCI` or `RFMCI` at the hardware level, beyond just the register values. `RFCI` and `RFMCI` also clear the `CSSR`/`MCSR` state and update internal processor tracking of the interrupt level (e.g., the `CE`/`ME` enable bits in MSR). Simply using `RFI` with manually copied values may not correctly re-enable or clear the critical/machine-check interrupt state, potentially leaving the processor in an inconsistent internal state. The Power Architecture Embedded Environment (EREF) specification explicitly defines which instruction must be used to return from each exception class. Deviating from this is outside the architecturally defined behavior and could produce unpredictable results on these cores. The recommended approach is to use rfi only for standard/noncritical returns, and use rfci , rfdi , rfgi , or rfmci for their associated interrupt classes.