Multi Source Translation Content

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

Multi Source Translation Content

讨论

排序依据:
外部ブート 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.
查看全文
E6500 / E5500 中断路径、RFI 与 RFCI 以及其他系列指令 你好, RFI 和其他系列指令用于从不同类型的中断/异常中返回。 我想知道,在 E5500 和 E6500 处理器上,只要 SRR0 和 SRR1 恢复到正确的值(可能最初是从 CSRR0、CRSRR1 或 MCSRR0、MCSRR1 等读取),是否可以始终使用 RFI,或者这样做是否会破坏处理器的某些内部机制。 顺祝商祺! 阿莱克西·托雷斯 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。
查看全文
LPC845 PINT Interrupt latency Hello,  I'm developing an application with tight constrains. My problem is related to PINT latency. For my understanding the typical latency time for an interrupt in an arm Cortex M0+ is around 15 clock cycle. My clock is at 30Mhz.  So I would expect something between 0.5 and 1uSec latency.  I have measured the time between the signal and the interrupt levering up a pin immediatly after the interrupt head, and actually I got 7uSecs.  Checking the assembler I can just see few instructions (less than 10) at the head of the interrupt. The PINT interrupt is the only one with a 0 priority. Is that normal or I'm doing something wrong? Thank to anyone answering, Re: LPC845 PINT Interrupt latency Hi @carlos_o , thank for your answer.  I'm using a custom hardware. I made the measure using a square wave generator, at 2400Hz, with the output connected to a pin of the LPC. The first instruction entering the irq change the status of another pin. Than I have a scope with two probes: one on the input pin, and the other on the out. I measure the time difference between the two fronts. Really I've lost the IRQLATENCY register! Thank you to point it out. Actually it has the default configuration at 0x10. The input filter in the pin is disabled, but I've activated the Hysteresis. For my understanding the GPIO is managed at the same freq then the core, and it requires 1 cycle to change the status of a pin. I suppose is the same with the input. I have a question: from the datasheet, seems that the GPIO is directly connected to the Core, bypassing the BUS, but the BUS is required for instruction and data access. So, if the DMA is using the Bus for a burst transfer, can be an interrupt be retarded?  Thank you Re: LPC845 PINT Interrupt latency Hi @xs_graziano  Thank you for your post Could you please confirm if you are using a custom board? if not, please specify which board you are using. Please share how are you doing the measurement of timing to the interrupt get triggered. Did you do any modification to the IRQLATENCY register?  BR Carlos Re: LPC845 PINT Interrupt latency I have made some more checks. Setting the pin high and than immediately low takes 4 asm instruction for a total of at most 5 clock cycles. I have got 255 nSecs, that is compatible with a clock of 20Mhz (I would have expected ca 160 nSecs). So, I've set up the main clock as clockout on a pin, and I got a clear 30Mhz on the scope. The system is configured for a 30Mhz FRO as main clock and the SYSAHBCLKDIV is set to 1 (one), so no div.  Could be it's core is running at a lower clock frequency also if the main clock, at the clockout output (enbled via SYSCON) is showing 30Mhz? Or something is slowing down the core? ... I think I've found part of the matter: the core is slowed down by the FLASH access time. Changing the Flash access time give a big improvement.  But I don't have seen any details about the minimum guaranties access time in the datasheet, or it's condition. If the instruction time improved, the interrupt latency is better (now 5uSec with 2 system clock access time for flash) but still far from the expectation. Re: LPC845 PINT Interrupt latency A 7 µs latency (roughly 210 cycles at 30 MHz) exceeds the core's 15-cycle theoretical minimum primarily due to peripheral bus synchronization, GPIO input glitch filters, and memory wait states rather than core execution time. Pin interrupts (PINT) require multiple peripheral clock cycles to synchronize asynchronous external signals to the system clock, alongside potential bus arbitration delays and flash latency if your code or vector table resides in flash memory rather than RAM.
查看全文
i. MX6ULLのイーサネット切断は、接合温度が95°Cを超えると切断されます こんにちは、NXPさん、        弊社はi.mx6ull 08ABバージョンで製品を設計しましたが、以下の問題が見つかりました。 1>部品番号: MCIMX6Y2CVM08AB        2>質問: 接合温度が95°Cを超えると、一部の基板でイーサネット切断の問題が発生します。 この問題を解決するためのヒントはありますか? どうもありがとうございました。 i.MX6UL Re: i.MX6ULL ethernet disconnect when joint temperature is higher than 95℃ お客様は何台のボードでこの問題を感じていますか?彼らはどのBSPバージョンをテストしたのですか?
查看全文
RVT70HSTNWC00-B (ILI2132A) with MIMXRT1176-evkb Hi, I'm currently working on a project with the MIMXRT1176-EVKB. In this project, I would like to display some screens on the RVT70HSTNWC00-B display and be able to register touch coordinates. I already have a working screen thanks to another NXP forum post: https://community.nxp.com/t5/i-MX-Processors/Creating-a-driver-for-a-MIPI-LCD/m-p/1772322 The only issue I have is that the touch driver (ILI2132A) for this display works slightly differently than other drivers (e.g., the GT911) but still uses I²C as protocol and there are no examples in the SDK that use this driver. Does anyone have a solution for this that can be built on the MIMXRT1170 series? All help and information are welcome. Thanks in advance! Communication & Control(I3C | I2C | SPI | FlexCAN | Ethernet | FlexIO) Re: RVT70HSTNWC00-B (ILI2132A) with MIMXRT1176-evkb Hi @KobeV, We do not currently provide a proper driver for the ILI2132A, but the RT1170-EVKB does support Zephyr, which has a driver for this touch IC called "input_ili2132a.c" (Doc, GitHub). Considering that the specifics for the ILI2132A touch IC are already implemented on that driver, the migration process to a bare metal driver is quite achievable. All the GPIO and I2C functions that are using on that driver should already have their bare metal equivalent on our SDK, so I suggest migrating or create your own driver based on that one. Also, since the RT1170-EVKB is already supported by Zephyr, you could do testing scenarios with a Zephyr-based projects to ensure the functionality of the driver and debug its functionality before any migration process. BR, Edwin. Re: RVT70HSTNWC00-B (ILI2132A) with MIMXRT1176-evkb Hi, After a significant amount of testing and troubleshooting, I am still unable to get the touch functionality working for the RVT70HSTNWC00-B display using the ILI2132A driver. To give you some background on my setup, I am working within an MCUXpresso project that also incorporates Crank Storyboard. My goal is to poll the touch driver and trigger the appropriate Storyboard events (such as motion, press, and release) based on touch inputs. Recently, I found a GitHub repository where the ILI2132A driver is implemented, but it uses an Arduino (.ino) project. I attempted to adapt the additional files and convert the Arduino code into a C file suitable for my environment. Below is the implementation I came up with following code (check: sbengine_task_vglite.c). Despite these changes, I am still not getting any signs of life from the touch display. I am wondering if there are any bugs in my code or if other external configurations and settings in my project need to be adjusted. For reference, the link to the original Arduino project's GitHub page: https://github.com/riverdi/ctp-ilitek-arduino-demo/tree/master  I would greatly appreciate any guidance or insights you could provide. Re: RVT70HSTNWC00-B (ILI2132A) with MIMXRT1176-evkb Hi, this is a response to my own reply on this forum. The problem was successfully resolved after struggling with it for a few weeks. The Arduino code from https://github.com/riverdi/ctp-ilitek-arduino-demo works perfectly if you convert it to C code yourself. The problem with the driver and the board is that the MIPI LCD connector J48 does not have its own 3.3V or higher power supply (It does but it's not connected to an external pin). For the display's backlight, you need around 8V (in my opinion), and for the touch, a voltage of 3.3V. As a solution, I provided these voltages using a lab power supply. The backlight then worked perfectly, but the touch displayed weird shapes. The signals were kept at a maximum of 1.8V. You could see a nice square wave on the CLK pin, but with 1.8V instead of 3.3V. Also, the driver chip drew a huge amount of current, and I still don't know what caused this. The problem was resolved by applying a separate 3.3V power supply. This can be made possible by taking the 3.3V from another GPIO pin. Please note that all GNDs of the different power supplies must be connected together along with the GND of the NXP board, otherwise you will get weird situations. The touch is not working optimally yet, but this is more of a firmware issue than a hardware issue. I think that for anyone experiencing this same problem, a different solution will be needed because of timing. Specifically, I am using FreeRTOS in my project, which makes the timing in the firmware slightly different. Hopefully, I can help other people with this information. If not, feel free to ask!
查看全文