Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
33FS45xx - VAUX 过压能力 我正在使用 33FS4500,目前将 VAUX 电源用作跟踪器,作为外部传感器电源。该用例包括故障情况下对电池电平(32/40V)短路。 33FS* 数据表显示最大值。芯片本身所有引脚的电压为 40V,但没有说明过压情况下外部 pnp 晶体管的后果,也没有说明 VAUX 和 Buck 之间是否有反向电流保护。 - VAUX 的预期用途之一是为外部传感器供电吗? - 我的 VAUX 接口需要额外的保护吗? 如果电路是这样的——它的结构是怎样的? 第一个想法可能是在晶体管和 VAUX(及其反馈)之间使用肖特基二极管。 Re: 33FS45xx - overvoltage capability of VAUX 亲爱的HajoV, 使用 VAUX 作为外部/板外传感器电源是 FS4500 的一个预期用途。VAUX 还可以以跟踪模式运行,以跟踪 VCCA,用于比率传感器应用。   对于可能发生的电池短路情况(32 V 至 40 V),FS4500 文档规定,VAUX 相关引脚的额定绝对最大值为 40 V,并明确指出 VAUX 适用于板外电源。建议使用额定电压高于 40V 的输出电容。   我们在数据表、安全手册或常见问题解答中找不到任何声明来确认 VAUX 和 Buck/VPRE 稳压器之间是否存在内部反向电流保护。因此,对于稳健的汽车设计,我们建议考虑外部保护,例如肖特基阻断二极管和/或 TVS 钳位电路,以防止反向馈电并提高对故障条件和瞬态的鲁棒性。   最诚挚的问候, 约瑟夫
記事全体を表示
33FS45xx - VAUXの過電圧耐性 私は33FS4500を使っており、現在はVAUX電源をトラッカーとして外部センサ電源として使っています。ユースケースには、エラーCASEでバッテリーレベル(32/40V)までの短絡が含まれます。 33FS* データシートには最大値が記載されています。チップ本体のすべてのピンに対して40Vですが、過電圧が発生した場合の外部pnpトランジスタへの影響や、VAUXとバックスの間に逆流保護があるかどうかは明記されていません。 - 外部センサ供給はVAUXの意図されたユースケースか? - VAUXに追加の保護が必要か? もしそうなら、回路はどのような形ですか? 最初のアイデアとしては、トランジスタとVAUX(およびそのフィードバック)の間にショットキーダイオードを設置するのが考えられます。 Re: 33FS45xx - overvoltage capability of VAUX HajoV様、 VAUXを外部/オフボードのセンサ電源として使用することは、FS4500の意図された用途です。VAUXはまた、比率測定センサー用途向けにVCCAに従う追跡モードで動作することも可能です。   バッテリーへのショート(32Vから40V)の可能性がある場合、FS4500のドキュメントにはVAUX関連ピンは最大40Vまで定格されており、VAUXはオフボード電源にも適していることが明記されています。出力コンデンサは40V以上の定格のものを使用することをお勧めします。   データシート、セーフティマニュアル、FAQには、VAUXとバック/VPREレギュレーター間の内部逆流保護を肯定する記述は見つかりませんでした。したがって、堅牢なオートモーティブ設計には、逆流防止や故障状況や過渡現象に対する堅強性を高めるために、ショットキーブロッキングダイオードやTVSクランプなどの外部保護を検討することを推奨します。   敬具、 ヨゼフ
記事全体を表示
Cool Cove 评测:紧凑设计,舒适贴合,尽享个人舒适体验 随着气温升高,营造舒适的室内环境对于提高工作效率和放松身心都变得愈发重要。无论您是在家办公、学习,还是只是待在室内,良好的空气流通都能让您的周围环境更加清新宜人。Cool Cove旨在通过增强个人空间的空气流通来提升室内舒适度,同时兼具小巧便携的设计。 Cool Cove 最吸引人的特点之一 就是它的简洁性。这款设备安装简便,上手使用也毫不费力。与可能需要复杂安装或永久放置的大型制冷系统不同,Cool Cove的设计宗旨是快速便捷地运行。用户只需将其放置在稳定的平面上,打开开关,然后通过直观的控制面板调节设置即可。这种简单易用的设计使其适合所有年龄段和经验水平的用户。 Cool Cove 体积小巧, 可轻松融入各种室内空间。无论放置于书桌、床头柜、厨房台面还是办公工作台,它都占用空间极小,同时又能与周围环境完美融合。其现代外观可与不同室内风格相得益彰,因此适用于家庭、公寓、宿舍和办公场所等各种环境。
記事全体を表示
Setting up Smart Cards...where do I begin? First post on here, love that this resource is available and I refer to it frequently! Had a question regarding setting up 2FA smart cards for my end users. We currently use HID 1386 contactless cards to badge into the building (125Khz...?), and I'd like to be able to use them for the PCs as well. I don't know if this is feasible however, seeing as the cards come pre-programmed and I dont even know if it would meet NIST 800-171 guidelines. I got a quote for some HID cards model 1597 that include a smart chip, and the contactless standard we use to enter the building. My question is, would these work to authenticate with Windows? By this I mean, could we use these cards for entry, and would the chip be compatible with Windows AD? Or is there a standard these chips have to meet to work properly? The standard I kept seeing was ISO 7816. Also, what would I be looking for cost-wise to deploy this? The quote I got was for ~$1100 for 100 of the aforementioned cards. I'm willing to entertain this as it means we only have to carry one card, but if it would be considerably cheaper to just get new smart cards and have to carry an extra I'm willing to entertain that as well. Thanks in advance! Automotive Smart Cards Re: Setting up Smart Cards...where do I begin? Hello @ichiha68 Hope you are doing well. My apologies, I am not completely aware of the requirements of Windows AD and the specifications of the contactless cards you are using (please consider contacting the manufacturer for further support). After some quick research, HID 1386 cards appear to be 125 kHz LF proximity credentials intended for physical access control. That LF proximity technology by itself would not be sufficient for native Windows/Active Directory smart-card logon, because Windows smart-card sign-in seems to expect a supported smart-card interface/middleware where Windows can enumerate a user certificate and use the corresponding private key for authentication. Regards, Eduardo.
記事全体を表示
LS-CGT 工具(zip)安装 您好,我想知道如何下载LS-CGT工具,或者在哪里可以申请访问该工具。 Smart Card
記事全体を表示
MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog I'm currently having a situation with my RT1050 where I'm trying to breakpoint inside a particular FreeRTOS task, but when the breakpoint is reached, the debugger fails to suspend itself and instead throws up a dialog stating "Interrupt failed" when I try to manually suspend the debugger afterward. So my application boots normally.  If I manually pause the program, I get a valid debugger context: This happens to be the task I want to step into, so I've got a breakpoint set at the switch() statement just after the message queue receive call returns.  I also have a second breakpoint set inside the method NetIfInit() just below there; I would expect the debugger to hit both of those, or at least one. I've also set a breakpoint inside my test function that will initiate the message queue send.  When I press my keys on the serial console, the debugger hits that breakpoint and halts. Then I step into that NetInit() function, which eventually calls xQueueSend(), which after a pregnant pause the debugger steps into.  I then step through the body of xQueueGenericSend() until I get to this point right here: Once I try stepping over line 846, the debugger pauses for some time, then loses context.  Note that I've lost my Resume All / Suspend All / Terminate All buttons, and also my thread list at the left.  The only available buttons are Suspend and Terminate for this session.  If I click Suspend (pause), the IDE sits for a few seconds, then throws up this dialog: And that's it, game over for the debugger.  Meanwhile, my serial console is stalled with some half-written UART output.  One might think that oh crap, I've gone and blown my stack or something, target must be dead... nope.  The only button remaining is the red Terminate (stop) button, and if I click that, the debug session terminates, and execution resumes... my tasks are good and alive. Initialize eth0. #DA4 12.996 | eth: netif init #DA4 12.999 | eth: NV MAC = 00-07-F0-00-56-03 #DA4 12.999 | eth: NV cfg: address = 192.168.1.180, netmask = 255.255.252.0, gateway = 192.168.1.1, static #DA4 13.000 | eth: netif add: MAC 00-07-F0-00-56-03, PHY address 3 Returning to main menu. #BB4 17.572 | No Handle Base Curr HiWByte State Name #BB4 17.575 | 10 80010db8 19 19 824 Blocked Tmr Svc #BB4 17.575 | 05 20206b68 12 12 1396 Suspended led_act #BB4 17.576 | 04 20206500 12 12 1388 Blocked led_cpu #BB4 17.576 | 08 2020ba18 8 8 7216 Blocked tcpip_thread #BB4 17.576 | 07 20209868 7 7 6900 Blocked eth_mgr #BB4 17.577 | 06 20207818 4 4 1912 Blocked gui #BB4 17.577 | 01 20203538 3 3 2812 Suspended debug_mgr #BB4 17.577 | 02 20204a68 2 2 4248 Running test #BB4 17.577 | 03 20205e88 1 1 3948 Blocked backgrnd #BB4 17.579 | 09 80010d40 0 0 748 Ready IDLE‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ So it seems that execution did in fact stop at the breakpoint I set, it's just that the debugger crapped itself. Any idea why the debugger would lose its mind like this? (EDIT: Added console output attachement, if that's useful at all.) David Rodgers Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog I had a similar situation where the debugger doesn't stop at main() and then can't be paused, displaying "Interrupt Failed" instead.  I fixed my issue by replacing workspace directories ".mcuxpressoide_packages_support" and ".metadata" with backups that I had. Perhaps these directories could be obtained from another computer's installation.  Perhaps simply re-importing the project(s) would work, too. Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog I would also like to know if this question was ever resolved. I'm having the exact same issue - in the sense that I am using MCUXpresso (v11.4), and my FreeRTOS application can fine for hours. I can manually pause the debugger and step through the code. However, my program will eventually crash, and the debugger (through a Segger JLink) just reports "interrupt failed" - I lose all debugging functionality. Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog Hi all, we are currently having the same problems. We'd like to debug into an issue, but the J-Link debugger states "Interrupt failed", after hitting the breakpoint. As this thread stops with the hint to the support system, Is there already a solution? Kind Regards David Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog Hi Erich, Wait... you still have a ticket system?  I thought NXP shut that avenue of support down years ago when they told everyone to go to the forums instead.  (At the time I was not terribly thrilled, as I took it to be a reduction in customer service, i.e. "don't come to us, go ask the general public for help".  However, NXP's engineers do seem well-engaged with the forums, and having third-party input is usually helpful.) Do you have a quick link for where to submit support tickets?  If I manage to break off some time this week (ha), I'll see if I can put together a version of my project that at least behaves correctly on an EVKB and still exhibits the breakpoint failure.  Thanks. David R. Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog Hi David, You could use the normal support ticket way to submit your project. I think it will only help the IDE engineers if it would run on a EVK as they have that hardware available, and the smaller the project, the better. Thanks for your help! Erich Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog I've got a lot of other items on my plate at the moment, but I will try to get some additional information to you in the next few days.  You're correct, I'm definitely not going to be posting my project here in the forums, but if you have a back channel where I can send my project directly to either you or an NXP engineer, I would be OK with that.  But yes, in the project's present form, it's 100% reproducible.  So if it's possible to send you my project privately, then I'll see about making an altered version that runs on an EVKB and still exhibits the issue. David R. Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog Hi David, I had this occasionally too, but never was able to really have a reproducible case, and I guess you won't be able to share your project (otherwise: please do). What I noticed or thing is that it might be an issue in the SEGGER FreeRTOS awareness implementation: I noticed that it does a lot of data reading, causing many view refreshs. There is a ticket pending with SEGGER on that subject. What for sure helped was to disable the SEGGER FreeRTOS awareness in the debugger (but I admit that this makes debugging FreeRTOS applications less user friendly). The other thing I did was closing as many views as possible (especially the disassembly view) to reduce traffic. I know that this is not ideal, and if you could share anything else for the IDE engineering team, that would be great. One thing which might be helpful are the GDB traces, see Board Bring-Up Tips, GDB Logs and Traces in Eclipse | MCU on Eclipse  I hope this helps, Erich
記事全体を表示
aft05ms004nt1 我遇到问题了,各位帮帮我 我有一个芯片 AFT05MS004NT1,但我希望它以 30-45 MHz 的频率发射信号。 请问有人能帮我计算一下 zload 和 zsource 的值吗? 请参阅附件中的表格。 Re: aft05ms004nt1 你好 arkazains 再会! 你远远超出了这个晶体管的工作范围。遗憾的是,由于该PN晶体管所处理的电压等级,我们目前没有替代品。但是,如果您愿意在设计中集成电平转换器,您或许可以找到其他合适的PN晶体管,例如: MRFE6VP61K25H 另一个选择是AFT05MS003N ;它已被标记为停产,不再生产,但您可以咨询我们的代理商,看看他们是否还有库存。 祝你的项目一切顺利。 祝你今天过得愉快,一切顺利。
記事全体を表示
MCUxpresso for VS-code 连接后复位 / IMXRT1176 中断 RESET 后仍保持有效 各位亲爱的朋友们, 请问有人知道当 isAttach 标志设置为 true 时,连接后是否支持硬件 RESET 吗?如果可以,该如何做到呢? 我们在 IMXRT1176 EVKB 上遇到了奇怪的行为,在连接到运行中的核心后,通过 RESET 按钮复位板,但某些中断仍然处于活动状态。 如果还有其他方法可以避免这种情况,我将不胜感激,希望有人能给我一些提示。 此致, 雅库布 Re: MCUxpresso for VS-code reset after connect / IMXRT1176 interrupts remain active after reset 你好@jslota13245 , 为了了解并重现该问题,请您提供以下信息? -当问题发生时,您正在采取哪些步骤? -重置发生时,哪些中断仍然处于活动状态? -您能否使用我们的任何 SDK 示例重现此问题?如果是,是哪一个? -调试过程中重置电路板的目的是什么? BR 哈比卜 Re: MCUxpresso for VS-code reset after connect / IMXRT1176 interrupts remain active after reset 亲爱的哈比卜, 谢谢你的回复。 当问题出现时,您正在执行哪些步骤? -> 我的应用程序中定义了 void LPUART2_IRQHandler(void)。我覆盖了启动文件中的弱定义。我用调试符号烧录二进制文件,然后将其连接到正在运行的核心。为了简单起见,我们假设有第二个板通过 LPUART2 连接,它正在向我们写入一些数据,我们假设这种情况或多或少一直在发生,因为我们无法预测它何时向我们发送数据。连接后,我们可以看到kLPUART_RxDataRegFullFlag被触发。这是预期结果,因为我们启用了这个中断。 我们使用 VS Code 扩展进行调试。它提供了两个 RESET 按钮。据我所知,你可以重置调试会话并重置 CPU。我们采用第二个。按下RESET按钮后,正如预期的那样,我们在主程序启动时遇到了断点。然后我运行核心程序,它在到达启用此中断的代码之前就到达了带有 kLPUART_RxDataRegFullFlag 的 LPUART2_IRQHandler。这是个问题所在。 <-重置发生时,哪些中断仍然处于活动状态? -> kLPUART_RxDataRegFullFlag <-您能否使用我们的任何 SDK 示例重现此行为?如果是,是哪一个? 我还没试过。不过,我认为如果有一个异步 UART 接收示例,并且你确保通信的另一端不断地向 UART 端口写入数据,那么这个问题应该是可以重现的。连接操作可能是一个关键线索,因为我们不执行“启动”操作,所以硬件可能在连接会话开始时没有重置? <-调试时重置电路板的目的是什么? -> 我说重置板,意思是重置调试会话或者直接跳转到 main 函数的开头。至少在启动配置状态下是这样工作的——它会将你带回到主程序的开头,这样你就可以在不重新连接的情况下再次进行调试。我认为这是一种相当常见的操作,不过如果您发现任何异常情况,请告诉我。 如果您需要任何其他信息,请告诉我。 🙂 此致, 雅库布 Re: MCUxpresso for VS-code reset after connect / IMXRT1176 interrupts remain active after reset 你好@jslota13245 , 我这边测试过了,确认 RDRF(接收数据寄存器已满)标志已正确清除。为了更好地了解您所观察到的行为,请您提供以下信息? -当出现此问题时,您是否看到在触发 RESET 之前设置了 RDRF 标志? 当您单击“RESET”按钮并停留在 main 函数(在任何应用程序代码执行之前)时,LPUART2 STAT 寄存器的值是多少? 如果您使用的是“外设”视图,请在检查寄存器值之前单击“刷新”按钮,以确保显示的信息是最新的: - 复位发生时,UART 接收事务是否正在进行中? -你是否对主板进行了任何硬件改动? -您目前使用的是哪个版本的 MCUxpresso for VS Code 扩展? -您使用的是哪个版本的SDK? BR 哈比卜
記事全体を表示
OV5640 与 i.MX RT1170(无显示器)连接,实现图像捕获和流式传输至桌面 你好, 我正在使用 i.MX RT1170-EVKB 板,我的目标是从 OV5640 摄像头捕获图像,并在我的台式电脑上查看捕获的图像或实时视频流,而无需使用 LCD 显示器。 我尝试了 MIPI CSI SDK 示例,并能够以 RAW 格式捕获图像数据。但是,我遇到了一些问题。 捕获的输出是 RAW 格式,我找不到任何文档解释如何正确转换或查看这些图像。 捕获的图像似乎颜色不正确或有滤镜般的伪影,因此很难验证相机输出是否正确。 我找不到任何官方文档、应用笔记或视频教程来描述从 OV5640 捕获图像并在台式电脑上查看图像的完整工作流程。 目前还没有明确的参考资料解释如何在不使用机载显示屏的情况下,通过以太网或 USB 传输摄像机输出。 我也尝试了 sd_jpeg 示例,但遇到了多个问题。 在集成过程中,该项目报告缺少 JPEG 库配置文件,例如 jconfig.h。 在解决了一些构建问题之后,我在将 JPEG 编码器与 MIPI CSI 相机示例结合使用时,仍然遇到编译和集成错误。 我无法从捕获的相机帧中生成有效的 JPEG 图像。 我的目标是: 无需使用液晶显示屏,即可将 OV5640 相机与 i.MX RT1170-EVKB 板连接。 捕获图像并将其传输到我的台式电脑上进行查看。 如果支持,请通过以太网将摄像头的实时视频流传输到我的台式电脑。 我希望您能就以下问题提供指导: 是否有针对此用例的官方 SDK 示例或参考项目? 是否有任何文档解释从 OV5640 到 MIPI CSI、内存、JPEG 或 RAW 处理,再到以太网或 USB 传输到台式电脑的完整图像捕获流程? RT1170-EVKB 是否支持以太网实时流媒体传输?如果可以,能否推荐合适的 SDK 示例或中间件? sd jpeg 示例是否存在已知问题?或者将其与 MIPI CSI 相机示例集成是否需要任何额外的配置步骤? 任何指导、文档或参考项目都将不胜感激。 感谢您的支持。 Re: OV5640 Interfacing with i.MX RT1170 (Without Display) Image Capture and Streaming to Desktop 嗨@Sureshk123 , 我们没有适用于您应用程序的官方示例项目或参考设计。也就是说,根据我的了解,我建议您按以下步骤完成整个申请流程: 摄像头采集路径(OV5640 > MIPI CSI > cameraBuffer):这部分我们提供了一个示例应用程序,即前面提到的 MIPI CSI SDK 示例。请注意,根据错误代码 ERR051248:“视频复用控制器 (VIDEO_MUX) 不支持将原始数据和 YUV422 (10 位) 格式发送到 MIPI_CSI2 模块。” 使用并行 CSI 或视频解码器是一种可选的解决方法。 一旦您的 cameraBuffer 中有足够的数据,您就可以集成我们 SDK 中基于 USB 或 lwIP 的示例项目,将此数据传输到您的 PC。我建议只有在确认缓冲区工作正常后才考虑 JPEG 编码。 BR, 埃德温。
記事全体を表示
MCUXpresso for VS Codeは接続後にリセットされ、IMXRT1176の割り込みはリセット後も有効のままです 皆様へ isAttachフラグがtrueに設定されている場合、接続時にハードウェアリセットがサポートされているかどうかご存知の方はいらっしゃいますか?SOなら、どうCANのでしょうか? IMXRT1176 EVKBにおいて、実行中のコアに接続した後、リセットボタンでボードをリセットしても、一部の割り込みがアクティブなままになるという奇妙な動作が発生しています。 もしそれを防ぐ他の方法があれば、何かヒントをいただけるととてもありがたいです。 よろしくお願いします、 ヤクブ Re: MCUxpresso for VS-code reset after connect / IMXRT1176 interrupts remain active after reset こんにちは、 @jslota13245。 問題を理解し再現するために、以下の情報を教えていただけますか? 問題が発生した場合、どのような手順を踏んでいますか? -リセットが起きてもどの中断が有効なままですか? -この動作をSDKの例で再現できますか?もしそうなら、どの学校ですか? -デバッグ中にボードをリセットする目的は何ですか? BR ハビブ Re: MCUxpresso for VS-code reset after connect / IMXRT1176 interrupts remain active after reset ハビブ様、 ご回答ありがとうございます。 ←問題発生時にどのような手順を踏んでいますか? -> 申請書に無効LPUART2_IRQHandler(無効)を定義しています。起動ファイルから弱い定義を上書きします。デバッグシンボル付きのバイナリをフラッシュしてから、実行中のコアに接続します。簡単にするために、LPUART2を介して接続されたもう一台の基板がデータを書き込んでいると仮定します。これはほぼ常に起こっているとしましょう。いつ送ってくるか予測できないからです。取り付けた後、kLPUART_RxDataRegFullFlagがトリガーされているのが見えます。この割り込みを有効にしたため、これは想定内の動作です。 デバッグにはVS Codeの拡張機能を使用しています。リセット用のボタンが2つ用意されています。私の理解では、デバッグセッションをリセットしCPUをリセットすることは可能です。私たちは2番目を使います。リセットボタンを押した後、予想通りメイン関数の開始位置にあるブレークポイントに到達しました。次にコアを実行すると、この割り込みを有効にするコードに到達する前に、kLPUART_RxDataRegFullFlag を持つ LPUART2_IRQHandler に到達します。これは問題のある部分だ。 ←リセットが発生したときにアクティブなままになる割り込みはどれですか? -> kLPUART_RxDataRegFullFlag < 私たちのSDKの例でこの動作を再現できますか?もしそうなら、どの学校ですか? ->まだ試してない。非同期UART受信の例があり、通信の相手側が常にUARTポートに書き込みを行っていることを確認できれば、再現可能だと思います。アタッチが重要な手がかりかもしれません。私たちは「起動」を行っていないので、アタッチセッションの開始時にハードウェアがリセットされていないのかもしれません。 <-デバッグ中に基板をリセットする目的は何ですか? -> ボードをリセットすると言ったのは、デバッグセッションをリセットするか、メイン関数の先頭にジャンプするという意味です。少なくとも起動設定中はそういう仕組みで、メインのスタートに戻って再接続せずにデバッグできます。これはかなり一般的な操作だと思いますが、何か異常な点があればお知らせください。 もし追加情報を提供できるなら、ぜひ教えてください 🙂 よろしくお願いします、 ヤクブ Re: MCUxpresso for VS-code reset after connect / IMXRT1176 interrupts remain active after reset こんにちは、 @jslota13245 さん、 私自身もテストを行い、RDRF(受信データレジスタ満杯)フラグが正しくクリアされることを確認しました。観察している行動をよりよく理解するために、以下の情報を教えていただけますか? この問題が発生した際、リセットがトリガーされる前にRDRFフラグが設定されているのが確認できますか? リセットをクリックし、メインで停止している(アプリケーションコードが実行される前)とき、LPUART2 STATレジスタの値は何になりますか? 周辺機器ビューを使用している場合は、表示情報が最新かどうかを確認するためにレジスタ値を確認する前にリフレッシュボタンをクリックしてください。 リセットが発生した時点で、UART受信トランザクションは進行中ですか? 基板にハードウェアの変更を加えましたか? -現在、VS Code拡張機能用のMCUxpressoのどのバージョンを使っていますか? -どのバージョンのSDKを使っていますか? BR ハビブ
記事全体を表示
MCUX 11.0.1 - デバッガーが「割り込み失敗」ダイアログを表示する <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 現在、RT1050で特定のFreeRTOSタスク内でブレークポイントを試みているのですが、ブレークポイントに達したときにデバッガーが自ら一時停止できず、手動でデバッガーを一時停止しようとすると「割り込み失敗」というダイアログが表示されます。 なので、私のアプリケーションは正常に起動します。プログラムを手動で一時停止すると、有効なデバッガーコンテキストが得られます。 これは私が介入したいタスクなので、メッセージキューの受信コールが戻った直後のswitch()文にブレークポイントを設定しています。また、そのすぐ下にNetIfInit()という方法内に2つ目のブレークポイントを設定しています。デバッガはその両方、あるいは少なくともどちらかに当てると思います。 また、メッセージキューへの送信を開始するブレークポイントをテスト関数内に設定しました。シリアルコンソールでキーを押すと、デバッガーがそのブレークポイントに到達して停止します。 次に、NetInit() 関数にステップインします。この関数は最終的に xQueueSend() を呼び出し、デバッガーはしばらくの待機の後、その関数にステップインします。次に、xQueueGenericSend() の本体を順に処理していき、この箇所に到達します。 846行目をステップオーバーしようとすると、デバッガーがしばらく停止した後、コンテキストを失います。履歴書の全て、すべてを一時停止、全て終了するボタンを失い、左側のスレッドリストも失っています。このセッションで使用できるボタンは、「一時停止」と「終了」のみです。一時停止をクリックすると、IDEは数秒間待機し、その後次のダイアログが表示されます。 これで終わりだ。デバッガーのゲームオーバーだ。一方、私のシリアルコンソールは、書きかけのUART出力で停止している。「やばい、スタックを全部使い果たしちゃった、ターゲットは死んだに違いない」と思うかもしれないが、そうではない。残っているボタンは赤い「終了(停止)」ボタンだけで、それをクリックするとデバッグセッションが終了し、実行が再開されます。タスクは正常に動作しています。 Initialize eth0. #DA4 12.996 | eth: netif init #DA4 12.999 | eth: NV MAC = 00-07-F0-00-56-03 #DA4 12.999 | eth: NV cfg: address = 192.168.1.180, netmask = 255.255.252.0, gateway = 192.168.1.1, static #DA4 13.000 | eth: netif add: MAC 00-07-F0-00-56-03, PHY address 3 Returning to main menu. #BB4 17.572 | No Handle Base Curr HiWByte State Name #BB4 17.575 | 10 80010db8 19 19 824 Blocked Tmr Svc #BB4 17.575 | 05 20206b68 12 12 1396 Suspended led_act #BB4 17.576 | 04 20206500 12 12 1388 Blocked led_cpu #BB4 17.576 | 08 2020ba18 8 8 7216 Blocked tcpip_thread #BB4 17.576 | 07 20209868 7 7 6900 Blocked eth_mgr #BB4 17.577 | 06 20207818 4 4 1912 Blocked gui #BB4 17.577 | 01 20203538 3 3 2812 Suspended debug_mgr #BB4 17.577 | 02 20204a68 2 2 4248 Running test #BB4 17.577 | 03 20205e88 1 1 3948 Blocked backgrnd #BB4 17.579 | 09 80010d40 0 0 748 Ready IDLE‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ つまり、実行は設定したブレークポイントで実際に止まったようですが、デバッガが自ら故障しただけです。 なぜデバッガがこんなふうに狂ったのか、心当たりはありますか? (追記:コンソール出力の添付ファイルを追加しました。もし役に立つようでしたら。) デビッド・ロジャース Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog 私も似たような状況で、デバッガがmain()で停止せず、その後は一時停止できず、「割り込み失敗」と表示されることがあります。ワークスペースディレクトリ「.mcuxpressoide_packages_support」を置き換えることで問題を解決しました。および「.metadata」私が持っていたバックアップを使って。 これらのディレクトリは別のコンピュータのインストールから入手できるかもしれません。 プロジェクトを再インポートするだけでも解決するかもしれません。 Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog この問題が解決されたかどうかも知りたいです。私もまったく同じ問題を抱えています。MCUXpresso(v11.4)を使っているのですが、FreeRTOSアプリは何時間も問題なく動作します。手動でデバッガーを一時停止してコードをステップで進めることができます。しかし、私のプログラムは最終的にクラッシュし、デバッガ(Segger JLink経由)は「割り込み失敗」と報告するだけで、デバッグ機能がすべて失われてしまいます。 Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog こんにちは、皆さん。 私たちも現在、同じ問題を抱えています。 問題のデバッグを行おうとしたのですが、ブレークポイントに到達した後、J-Linkデバッガーに「割り込みに失敗しました」と表示されます。 このスレッドはサポートシステムへのヒントで終わりますが、もう解決策はあるのでしょうか? 敬具 デビッド Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、エーリッヒさん。 えっ…まだチケット制なの?NXPは何年も前にフォーラムに行くように言ってそのサポートを閉ざしたと思っていました。(当時はあまり喜びませんでした。なぜなら、これはカスタマーサービスの削減、つまり「私たちに来るな、一般の方に助けを求めろ」と受け取ったからです。)しかし、NXPのエンジニアたちはフォーラムに積極的に参加しているようで、第三者からの意見は通常役に立つ。 サポートチケットをどこで送信できるか、簡単なリンクはありますか?もし今週中に割り切れるなら(笑)、少なくともEVKB上で正しく動作しつつ、ブレークポイントの失敗を示すバージョンを作れるか試してみます。ありがとう。 デビッド・R. Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、デイビッドさん。 通常のサポートチケットを使ってプロジェクトを提出することもできます。IDEエンジニアにとっては、EVK上で動作するハードウェアが手元にあるので、プロジェクトが小さいほど良いと思います。 ご協力いただきありがとうございます! エーリッヒ Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 現在、他にも多くの案件を抱えていますが、数日中に追加情報をお伝えできるよう努めます。おっしゃる通り、私はフォーラムに自分のプロジェクトを投稿するつもりはありませんが、もしあなたやNXPのエンジニアに直接プロジェクトを送れる裏ルートがあれば、それで構いません。しかし、現在のプロジェクトの形態では、100%再現可能です。もし私のプロジェクトをプライベートで送ってもらえるなら、EVKB上で動作しつつも問題が残る修正版を作ってみます。 デビッド・R. Re: MCUX 11.0.1 - Debugger gives "Interrupt failed" dialog <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、デイビッドさん。 私も時々同じ経験がありましたが、再現可能なケースはできなかったので、プロジェクトを共有することはできないと思います(そうでなければ、ぜひ共有してください)。 私が気づいたこと、あるいは考えていることは、SEGGER FreeRTOSの認識実装に問題がある可能性があるということです。大量のデータ読み取りが行われ、ビューの更新が頻繁に発生していることに気づきました。その件に関して、SEGGER社に問い合わせが保留されています。 確実に効果があったのは、デバッガでSEGGER FreeRTOS認識を無効にしたことです(ただし、これだとFreeRTOSアプリケーションのデバッグがユーザーフレンドリーで劣るのは認めます)。 もう一つやったことは、トラフィックを減らすために、できるだけ多くのビュー(特に分解ビュー)を閉じることでした。 理想的ではないことは承知していますし、もしIDEエンジニアリングチームのために他に何か教えていただけると助かります。 役立つかもしれないのはGDBトレースです。 EclipseのBoard Bring-Up Tips、GDBログとトレースを参照してください。MCUのエクリプス  お役に立てば幸いです。 エーリッヒ
記事全体を表示
lpc4078 eeprom page erase clarification required I'm using an LPC4078 and MCUXpresso and experimenting with storing values in Eeprom. I want to write a few bytes in the middle of a page without clearing the whole page. Looking in the datasheet, it says that after writing the data to be written int he page register, it still has to be programmed into non-volatile memeory and that is done with the erase/program operation. Does the Erase/Program operation erase the whole page or just the area of the page I have new data for, and how does it know? - the address setting for Erase/Program ignores the 6 lsbs so it only knows the page. The UM10562.pdf isn't explicitly clear on this matter. Thanks Alex Re: lpc4078 eeprom page erase clarification required I attach a workspace with the mentioned project in it. I ran it on an LPC4078 using a lpc-link2 debugger. (I couldn't be bothered to get semihosting to work, so I used breakpoints and inspected the data) Re: lpc4078 eeprom page erase clarification required Hello @alex_conway  For LPC4078 EEPROM, the minimum erase/program unit is one page (64 bytes). Therefore, each erase/program operation will erase the entire page. If you want to write only a few bytes, please first read the whole page, then modify the required bytes, and finally perform an erase/program operation on the page. You can test this on your side.   Thank you.   BR Alice Re: lpc4078 eeprom page erase clarification required Hi Alice, My experiments demonstrate otherwise: I wrote a small program using the lpc_board_ea_devkin_4088 library and the periph_eeprom demo project to start me up. I erase a page of Eeprom and read it back. To my surprise the results are all '\0' instead of 0xFF Then I write 'ABCDEFG\0' to address 0 in that page and read the page back. I receive 'ABCDEFG\0' Then I write 'ABCDEFG\0' to address 7 in that page and read the page back. I receive 'ABCDEFGABCDEFG\0' This is all as expected except for two things: 1. after erasing the eeprom reads 0 2. looking at the implementation of Chip_EEPROM_Write() is can seem no read-modify-erase-write sequence. There is only Chip_EEPROM_WritePageRegister followed by Chip_EEPROM_EraseProgramPag. This is why I asked the question. Thanks Alex Re: lpc4078 eeprom page erase clarification required I've got semihosting to work after adding a newline to all my printf strings! Also clearer evidence of everything I have said: Erasing sets Eeprom to 0x00 The code does not perform a read-modify-erase-write sequence, just erase-write. The LPC4078 seems to only erase the locations that are written to when erasing. I would really like clarification on this. Thanks Alex Re: lpc4078 eeprom page erase clarification required Despite "Escalating" whatever that means, there has been no further response from NXP on this. I still need clarification. 
記事全体を表示
s32k312 HSE AB SWAP 您好: 我目前正在使用 S32K312 上的 HSE 的 AB 交换功能。 例如,程序当前正在分区 A 上运行。在首次更新期间,我们会擦除/写入分区 B 中的闪存,然后调用 HSE 接口启用分区 B。此时,不会执行任何重置操作。 在第二次更新过程中,我们仍然需要擦除/编程分区 B 中的闪存。但是,如果在编程过程中断电,然后设备再次通电,则程序将无法运行。 我想请问:如果我们启用安全启动,我们能否使用 SMR 和安全恢复模式来实现基于软件的分区 A 和分区 B 之间的切换/跳转? Re: s32k312 HSE AB SWAP 嗨@ruller 请查看帖子“如何在 S32K3 上启用 HSE AB_SWAP 的回滚功能?”它针对回滚和恢复提出了一些建议,这些建议可能对您的实施有所帮助。 BR,VaneB
記事全体を表示
S32 Design Studio for ARM 2.2 – 许可证激活错误(CLLReason errorNo=27) 您好,NXP授权团队, 我的 S32 Design Studio for ARM v2.2 许可证即将到期,我想继续使用它。许可证到期日和授权到期日均显示为 2026 年 7 月 5 日,因此授权本身将到期,使用现有激活码重新激活将不再产生有效的许可证。 细节 : 产品:S32 Design Studio for ARM v2.2 激活码:CCB1-BEC2-FF96-4859 如果我点击 激活 输入我的激活码后,立即出现以下错误: CLLReason [errorNo=27, errorString=向远程激活服务器发送返回请求并处理响应时出错。退货次数已达上限,如有需要请联系产品供应商寻求帮助。(FNP 错误 0),flxActMajorErrNo=0,flxActMinorErrNo=0,flxActSysErrNo=0,flxCommErrNo=0] 请您重置此激活码的返回计数器,或者发放一个新的激活码,以便我可以在当前的PC上激活S32 Design Studio for ARM 2.2? 非常感谢您的帮助。
記事全体を表示
Clarification on FMEDA Results for MC33772C I’m currently working with the MC33772CTC1AE component and have been referring to the AN12638 functional safety document. The document mentions that it applies to MC3377xC devices (where x can be 1 or 2). However, the FMEDA results included are only for the MC33771C, not for MC33772C or MC3377xC for both the variants Could anyone clarify whether the FMEDA results provided for MC33771C can also be applied to MC33772C? Re: Clarification on FMEDA Results for MC33772C Hello, I have already provided a response in your support ticket 00990450. I will continue following up with you through that ticket.
記事全体を表示
LX2080 After the LX2080 processor operates for a period of time in a high-temperature environment, the on-board temperature sensor reads 86°C. Upon power cycling, printing freezes at the message "Fixed DDR on board", and the serial port becomes unresponsive. Re: LX2080 Thank you for your reply. Only one board in this batch has this issue. The problem reproduces after full power cycle, but rebooting via the kernel does not trigger the fault. We are unable to run verification tools in high-temperature environments, and the board functions normally at room temperature.@June_Lu Re: LX2080 Please validate the DDR on the high-temperature environment with QCVS DDR to confirm DDR works well. Thanks
記事全体を表示
S32K328 – 启用多核时,FIRC 时钟分频器 (DIV16) 不生效 您好,NXP技术支持团队, 我有一个关于 S32K328 的 FIRC 时钟配置的问题。 在单核设置中,我将 STM2 模块的 FIRC 时钟源配置为 3MHz(16 格)。在单核配置中,我确认 FIRC 时钟源以 3MHz 的频率正确输出。 但是,一旦我启用多核,即使分频器仍设置为 16,FIRC 时钟源的输出频率也会从 3MHz 变为 48MHz。 在我目前的架构中,MCU 初始化和设置模式只能在 Core 0 上执行。我的问题是,MCU 时钟是否也可以从 Core 1 访问(或重新配置),以及这是否可能是问题的原因。 关于我的配置的补充信息: 我正在使用 AUTOSAR 环境,并添加了 RM(资源管理器)模块以实现多核支持。 Domain0 主服务器:核心 0,Domain1 主服务器:核心 1。已为每个功能域授予所有内存和外围设备访问权限。 工具环境: MCAL RTD 3.0.0 EB Tresos 27.1.0 我自身分析得出的结论: 在运行时读取 CONFIG_REG_GPR 寄存器中的 FIRC_DIV_SEL 字段时,其值为 3,根据驱动程序代码,这对应于 48MHz(分频器值映射:48MHz→3,24MHz→1,3MHz→2)。我还注意到时钟驱动程序中的分频器写入路径包括 APP_CORE_ACC 权限检查,以及等待安全 BAF (CORE2) 进入 WFI(通过轮询 PRTN0_CORE2_STAT)。我怀疑在多核配置中可能会跳过除法器写入操作。 请问您能否就以下问题提供建议: 为什么启用多核时 FIRC 分频器设置(DIV 16)没有生效,导致输出频率为 48MHz 而不是 3MHz? 在这种情况下,是否支持或需要从 Core 1 访问或重新配置 MCU 时钟。 在多核配置中,是否由于 APP_CORE_ACC 权限检查或 Secure BAF WFI 超时而跳过分频器写入,以及如何确保正确应用分频器。 感谢您的支持。期待您的回复。 此致, AWS-LIBRARIES-S32K3 Re: S32K328 – FIRC Clock Divider (DIV16) Not Applied When Multicore Is Enabled 你好, 我已经找到了 问题的 根本原因 。 请查看下面的相关驱动函数 (位于 \Mcu_TS_T40D34M30I0R0\src\Clock_Ip_IntOsc.c 中的 Clock_Ip_SetFircDivSelHSEb) 。😞 c /* Application can write this divider */ if ( ((IP_CONFIGURATION_GPR->CONFIG_REG_GPR & CONFIGURATION_GPR_CONFIG_REG_GPR_APP_CORE_ACC_MASK) >> CONFIGURATION_GPR_CONFIG_REG_GPR_APP_CORE_ACC_SHIFT) == CLOCK_IP_APP_CAN_WRITE) { ... /* FIRC_DIV_SEL write happens here */ } else { /* HSE firmware doesn't allow to write FIRC post divider. */ Clock_Ip_ReportClockErrors(CLOCK_IP_REPORT_WRITE_PROTECTION_ERROR, Config->Name); } 问题在于,在我的多核配置中,代码在全速运行时永远不会进入 if (APP_CORE_ACC == CLOCK_IP_APP_CAN_WRITE) 代码块。我通过在该代码块内添加一个 while(1) 循环验证了这一点——它永远不会被执行。结果, FIRC_DIV_SEL 写入操作被跳过,寄存器保持在复位值 3 (48MHz),而不是配置的 2 (3MHz)。这导致我的 STM 时钟频率比预期快了 16 倍。 然而, 当我在调试模式下运行(单步执行/设置断点)时,同一个代码块执行正常 ,FIRC_DIV_SEL 也 被正确设置为 2(3MHz)。 这种 全速执行和调试执行 之间的差异 是 关键症状。 因此,在 全速多核启动期间, 当 Mcu_InitClock 读取 CONFIG_REG_GPR 中的 APP_CORE_ACC 位时,该位 并未设置为 CLOCK_IP_APP_CAN_WRITE ,但当 我 使用调试器减慢执行速度时,该位就变为可写。 关于我的配置,还有以下补充信息: Mcu_InitClock和 Mcu_SetMode仅在 Core 0 上调用。Core 1 (CM7_1) 不调用任何 MCU时钟 API。 核心 1通过 MC_ME (PRTN0_CORE1_*) 从核心 0 启动。 我没有加载任何HSE 应用固件。 同样的配置在单核处理器中也能正常工作(FIRC_DIV_SEL = 2 / 3MHz)。 工具环境:MCAL RTD 3.0.0,EB Tresos 27.1.0。 请问您能否帮我理解以下问题: CONFIG_REG_GPR 中的 APP_CORE_ACC 位由什么控制 ? SBAF 在什么条件下 授予 应用程序核心对 FIRC_DIV_SEL 的写入权限 ? 为什么 在 单核 模式下该 位会被正确设置, 而 在多核配置下(以全速运行时) 却不会被设置 ?启动 CM7_1 或添加多核启动 流程是否会改变 SBAF 授予此访问权限的时间和方式? 由于该代码块 在调试器下 执行 正确 ,但速度并非全速, 这强烈暗示 SBAF 授予写入权限与 Core 0 调用 MCU_InitClock 之间存在时序/顺序问题。如何 确保 在 Core 0 执行时钟 初始化 之前, SBAF 已授予 APP_CORE_ACC = APP_CAN_WRITE 权限 ? 在多核配置中,是否存在特定的启动配置(IVT、生命周期或SBAF相关设置)来决定是否授予应用程序核心此访问权限? 感谢您的支持。期待您的指导。 此致, Re: S32K328 – FIRC Clock Divider (DIV16) Not Applied When Multicore Is Enabled 你好, 感谢您进行测试并提供详细答复。 关于您提出的关于我实现方式的问题: 1. 我如何配置 FIRC_DIV_SEL: 在我的 Clock_Ip_IrcoscConfigurations_0结构中,FIRC 时钟配置的 IRCOSC 范围设置为 CLOCK_IP_SUPPORTS_3MHZ_FREQUENCY 。因此,预期配置为 3MHz,与您的测试相同。 2. 如何初始化第二个核心/是否需要在另一个核心上调用时钟初始化: Mcu_InitClock和 Mcu_SetMode都只在 Core 0 上调用。在Core 1 上,我没有调用任何与 MCU时钟相关的 API。 也就是说,我将 通过 进一步的调试来 再次检查这种行为 ,以确认 核心 1 上 没有意外地发生时钟重新配置 。 补充说明: 在单核模式下,FIRC_DIV_SEL 读取为 2 (3MHz),并且工作正常。 在多核处理器中,FIRC_DIV_SEL 读取为 3 (48MHz),导致 STM 时钟周期比预期快 16 倍。 我也会按照您的建议,评估是否迁移到最新的RTD版本。 我会尽快将调试结果反馈给您 。同时,如果 您对 导致 FIRC_DIV_SEL 最终值为 3(48MHz) 的原因有任何建议(即使时钟 初始化仅在 Core 0 上以 3MHz 配置 执行 ),我 将不胜感激。 此致, Re: S32K328 – FIRC Clock Divider (DIV16) Not Applied When Multicore Is Enabled 嗨@dpsdprtmvl 首先,您使用的软件版本比当前版本落后好几个版本,因此我建议您迁移到最新的软件版本。 关于 FIRC_DIV_SEL,我在 S32K3X8EVB-Q289 板上使用 S32K3 IPCF v4.3.0 中的 IPCF_Example_S32K358 进行了一个简单的测试。为了进行本次测试,我修改了 IRCOSC 配置结构(Clock_Ip_IrcoscConfigurations_0),将 IRCOSC 范围从 CLOCK_IP_SUPPORTS_48MHZ_FREQUENCY 更改为 CLOCK_IP_SUPPORTS_3MHZ_FREQUENCY。 运行应用程序并允许内核之间的乒乓通信完成后,我验证了 CONFIG_REG_GPR[FIRC_DIV_SEL] 已正确配置为预期值 (10b),如下图所示。 您能否提供更多关于您实施方案的细节?您是如何配置 FIRC_DIV_SEL 的?你是如何初始化第二个核心的?你是否也在另一个核心上调用了时钟初始化函数? BR,VaneB
記事全体を表示
RW612 SDK 26.06 您好,我下载了适用于 RW612 的 SDK 26.06,但它在 VS Code 中不可用。我已经导入了 SDK,但无法生成项目,它不在列表中,也无法打开我使用 26.03 版本创建的现有项目。 它不在下拉列表中 Re: rw612 sdk 26.06 你好。我试过了,但是没成功。当我尝试导入项目时,它显示“不支持的板”(或类似信息)。但我已从https://mcuxpresso.nxp.com/为我的开发板生成了 SDK。 Re: rw612 sdk 26.06 你好, 希望你一切都好。我无法重现此现象。 我建议更新 MCUXpresso 安装程序,并检查所有软件包是否已更新。 顺祝商祺! 里卡多 Re: rw612 sdk 26.06 你好, 请问您能否尝试导入仓库? 此致, 里卡多 Re: rw612 sdk 26.06 嗨,它奏效了,但我应该先删除其他 SDK,然后再添加。
記事全体を表示
LS1043AXN8QQB DVFS Dear support,  The customer used the LS1043AXN8QQB platform and set the CPU dynamic frequency adjustment from 1.6GHz to 800MHz and 500MHz. It was found that RCU stall and PCIE communication abnormality occurred when the CPU ran at 500MHz. According to the RM and datasheet of the chip, LS1043 supports 1GHz to 1.6GHz. The official document does not mention the minimum supported frequency for dynamic frequency adjustment. It is uncertain whether 500MHz is supported? Does LS1043A support dynamic frequency adjustment when the CPU is running normally? Re: LS1043AXN8QQB DVFS 500 MHz CPU runtime operation is supported if it is achieved by the CPU clock divider / cpufreq path, not by lowering the CGA PLL itself below 1 GHz. For the PCIe abnormality: if the frequency change is done through the normal CPU DFS path, NXP evidence says only the CPU frequency is affected, while AHB/APB remains unchanged . Therefore PCIe should not be impacted by CPU DFS alone. If PCIe becomes abnormal, check whether the implementation is also changing platform/SYSCLK/PLL ratios, because the datasheet requires the platform clock settings to remain within their valid limits and states a PCIe platform-clock requirement for proper PCIe operation. LS1043A does support runtime CPU frequency scaling to 500 MHz, but the CGA PLL must stay at ≥1 GHz and PCIe/platform clocks must not be disturbed.
記事全体を表示
Clarification on sharing Ethernet PHY interrupt pins on i.MX8M Plus Hi NXP Team, We are designing an i.MX8M Plus-based SOM with two Ethernet PHYs. Currently, each PHY has a dedicated interrupt GPIO connected to the i.MX8M Plus. We need clarification on the following: What are the main software use cases of the Ethernet PHY interrupt pins? Are they mainly used for link up/down, auto-negotiation, speed/duplex change, and Wake-on-LAN events? Can both Ethernet PHY interrupt outputs be combined and connected to a single i.MX8M Plus GPIO, with software reading both PHY status registers through MDIO to identify the interrupt source? If direct sharing is not recommended, can one or both Ethernet PHYs be operated using PHY polling without an interrupt pin? Will using PHY polling affect normal Ethernet data communication, apart from a small delay in detecting link-status changes? Our intention is to free one GPIO and use it for an ADC data-ready interrupt.
記事全体を表示