Multi Source Translation Content

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

Multi Source Translation Content

讨论

排序依据:
External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals Hello, I am trying to connect an external JTAG debugger to the FRDM-i.MX95 board. According to the board schematic, the JTAG/DAP signals appear to be routed to test points on the PCB, and some related components are marked as DNP. Based on this, I modified the board as follows: Connected the JTAG signals from the test points Mounted the DNP resistors related to the JTAG/DAP signal path Added a connector for an external debugger Connected VTref, GND, TCK, TMS, TDI, TDO, and RESET to the external debugger However, I cannot observe the expected JTAG signal output from the debugger/board side. For example, TCK/TMS/TDI do not appear as expected during the debugger connection sequence. Could you please confirm the following points? Is the above modification method correct for connecting an external JTAG debugger to the FRDM-i.MX95 board? Are there any additional resistors, jumpers, solder bridges, or board modifications required to enable the external JTAG/DAP interface? Is there any requirement for VTref voltage level or power sequencing before the external debugger starts driving JTAG signals? Does the i.MX95 on FRDM-i.MX95 require any boot mode, fuse setting, security setting, or software initialization before the JTAG/DAP interface becomes accessible? Can the external JTAG debugger access the Cortex-A55, Cortex-M33, and Cortex-M7 cores directly on this board, or is additional initialization by the bootloader/firmware required? Is there any recommended connector pin assignment or reference modification guide for using an external debugger with FRDM-i.MX95? I would appreciate it if you could provide any guidance, schematic references, or required modification details for enabling external JTAG debugging on the FRDM-i.MX95 board. Best regards, Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. Is your modification approach correct? In principle, yes. If the FRDM schematic exposes: TCK TMS TDI TDO nTRST or RESET VTref GND through test points and DNP stuffing options, then routing those signals to a connector is generally the correct approach. However, I cannot confirm that all required DNP resistors have been populated because the schematic itself was not returned by the search results. The user manual does not contain the JTAG circuitry. 2. Why would no TCK/TMS/TDI activity be seen? Normally, when a JTAG probe is connected: TCK/TMS/TDI are driven by the debugger. The target board does not generate them. If you see absolutely no toggling on TCK/TMS: Most common cause #1: VTref not detected Many probes (Lauterbach, J-Link, PE Micro, ULINK, etc.) will not drive JTAG pins until VTref is present and within a valid range. Check: VTref voltage at the connector. Common ground connection. Probe software reports the target voltage. For FRDM-i.MX95, the DAP I/O supply appears related to the 3.3 V domain (NVCC_CCM_DAP). The board documentation shows this domain powered from VDD_3V3. Most common cause #2: Board not powered Most debuggers use VTref for sensing only. They do not power the target. Verify: Board powered from J25. PMIC started. VDD_3V3 present. Board LEDs active. The board requires external PD power. Most common cause #3: Missing signal routing rework If the JTAG path contains: 0-Ω DNP resistors isolation resistors alternative stuffing options then missing even a single resistor can leave TCK/TMS disconnected. Since the schematic is not available in the search results, I cannot verify the exact resistor population list. Most common cause #4: Wrong pin mapping Verify with an ohmmeter: Probe pin → connector pin → resistor → test point → i.MX95 ball. Do not assume the test point labels match standard ARM 20-pin ordering. 3. Is a special boot mode required? For a non-secure device: No boot mode should be required just to observe JTAG clock activity. TCK/TMS should toggle as soon as the debugger detects VTref and starts a scan sequence. The boot switches affect: eMMC boot SD boot serial downloader and are unrelated to whether the debugger generates TCK. 4. Are security settings/fuses involved? Potentially. The i.MX95 implements authenticated debug and debug access control. [i.MX95RM_Rev4 | PDF], [i.MX95RM_Rev2 | PDF], [i.MX95 Sec...2026-final | PowerPoint] However: Security settings would usually prevent successful debug access. They would not normally prevent the debugger from generating TCK/TMS itself. Since you report no TCK activity at all, I would first investigate: VTref Probe configuration Cable pinout Missing population options before suspecting security. 5. Can A55, M33, and M7 be debugged? The i.MX95 debug architecture supports: Cortex-A55 Cortex-M33 Cortex-M7 through the CoreSight/DAP infrastructure. [i.MX95RM_Rev2 | PDF], [i.MX95RM_Rev5 | PDF] So from a silicon capability perspective, yes. Whether all domains are immediately visible depends on: system state, security configuration, debugger support. But no additional bootloader initialization is generally required for the debugger to detect the DAP itself. Recommended measurements Before further board rework, I would check: Power VTref = ? V VDD_3V3 present Board booting normally Continuity TCK connector ↔ SoC path TMS connector ↔ SoC path TDI connector ↔ SoC path TDO connector ↔ SoC path RESET connector ↔ SoC path Probe side Does the debugger software report target voltage? Does it show "target detected"? Does it report JTAG chain scan attempted? Oscilloscope Probe directly at: debugger connector pin SoC-side test point during connect attempt. If TCK is present at the debugger connector but absent at the SoC test point, the issue is almost certainly in the board rework. Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals Thank you for your support. We reviewed our external JTAG debugger connection and found that the issue was caused by the wiring length between the FRDM-i.MX95 board and the external JTAG debugger. After shortening and rearranging the JTAG signal wires, the debugger was able to detect the target correctly and the JTAG signals were observed as expected. Therefore, this issue has been resolved by improving the JTAG wiring length and connection quality. Thank you again for your assistance.
查看全文
USB OUTトランザクションでACKが欠落しています 私のチームは、USB OUTトランザクションでACKが欠落するという問題に直面しています。 当システムに関する情報: * MCUはLPC5528 * SDK バージョンは 26.03.00 です。 * Call to USB_DeviceInitでは、最初のパラメータ(controllerId)としてkUSB_ControllerLpcIp3511Fs0を提供しているので、USBフルスピードを使用しています。 パターンについて多くを語るのは難しい。私たちがCANのは次の通りです: * USB経由で大量のメッセージを送信する場合、まれにOUTトランザクションでACKが欠落することがあります。Ellisys USBアナライザーでこれを検出しました。抜けたものが見え、その後PCから3回の再試行、そしてUSBリセットが確認できます。 * それはめったに起こらない。同じ単純なUSBメッセージを繰り返し送信するスクリプトを設定しました(ターゲットは単にデータを返すだけで、複雑な計算などは行いません)。エラーが発生するまでに、数回の反復処理で済む場合もあれば、数千回の反復処理が必要な場合もある。 これが既知の問題なのか、あるいはデバッグのための何らかのコツがあるのかを知りたいです。 Re: Missing ACK on USB OUT Transactions こんにちは、 @JacobBerggreenさん LPC55S2x/LPC552xのエラータを確認しましたが、USB0フルスピードデバイス出力に直接対応するACKの欠如に関する既知の問題は見つかりませんでした。現在、USBの訂正表は主に高速モードに焦点を当てているため、あなたの構成に直接適用できるわけではありません。 この現象から考えられるより可能性の高い理由は、OUTエンドポイントが特定のタイミングで受信バッファを適時に準備しなかったため、ホストがOUTを送信した際にデバイスがACKに応答できず、再試行やリセットがトリガーされたということである。各アウトが完了した直後にUSB_SeviceRecvRequest()が呼び出されるかどうかを確認し、コールバックのプロセッシングを最小限に抑えることが推奨されます。USB割り込みの優先順位を確認し、長時間のシャットダウン割り込みを避けることも推奨されます。 BR ハリー
查看全文
工业堆栈支撑 我们计划启动一个涉及多种工业协议的项目。 以下是我的问题。 NXP是否为其MCU和MPU平台提供工业通信协议栈?这些功能仅限于 i.MX94 和 i.MX-RT1180 吗?  NXP目前支持哪些工业通信协议? PROFINET EtherNet/IP EtherCAT Modbus TCP/RTU OPC UA TSN PROFIsafe CIP 功能安全 IO-Link HART-IP 其他 哪些 NXP 硬件平台支持这些协议栈? i.MX系列 S32系列 MCX系列 LPC系列 其他平台 是否有平台与协议支持矩阵? 协议栈是否提供示例应用程序、参考设计和演示项目? 是否有Linux和RTOS集成的示例? 工业协议栈的许可模式是什么? 协议栈是否免费提供?如果是,资格标准和使用条件是什么? 对评估、开发或商业部署是否有任何限制? 协议栈以何种形式提供? 二进制库 目标代码 源代码 SDK 包 是否可以访问协议栈的源代码? 如果源代码可用,获取源代码需要满足哪些商业、许可或保密协议要求? 协议栈是否可以由客户进行定制和修改? 使用 NXP 协议栈实现产品商业化的流程是什么? 商业产品部署是否涉及一次性许可费用? 是否有任何按设备计费的版税、经常性费用或年度维护费? 与评估用途相比,生产部署是否存在任何额外成本? Re: Industrial stack support 你好, 1. PROFINET - 支持。 EtherNet/IP - 支持。 EtherCAT - 支持。 Modbus TCP/RTU - 支持。 OPC UA - 支持。 TSN - 支持。 PROFIsafe - 不支持。 CIP 功能安全 - 已支持 IO-Link - 支持。 HART-IP - 不支持。 2. 这些家庭都支持前面提到的一些协议,但并非同时支持所有协议。正如您所提到的,i.MX94 和 i.MX-RT1180 都专注于支持这些协议。您也可以看看 Layerscape 处理器。 3. 不,我们没有这样的资源。 4. 是的,我们的 BSP/SDK 中有示例。 5. 是的,有例子可供参考。 6. 7. 8.这取决于提供给客户的方式,需要检查每项资源以确认许可模式。 9. 提供源代码和 SDK 包。 10. 提供源代码。 11.这取决于提供给客户的方式,需要检查每项资源以确认许可模式。 12. 可由客户修改。 13.这取决于提供给客户的方式,需要检查每项资源以确认许可模式。 14. 15. 16.NXP 无法就何时、何地以及如何获得许可提供法律指导,因为这些许可是由第三方提供的,条款各不相同(有时还会变化)。 我建议您联系您希望使用的特定协议的所有者,以获取有关版税的信息。 顺祝商祺!
查看全文
Missing ACK on USB OUT Transactions My team is having some issues with missing ACKs on USB OUT transactions. Some info on our system: * The MCU is LPC5528 * SDK version is 26.03.00. * For call to USB_DeviceInit, we supply kUSB_ControllerLpcIp3511Fs0 as the first parameter (controllerId) so we're using USB full speed. It's hard to say much about patterns. What we can state is: * When we send a lot of messages over USB, once in a while an OUT transaction is missing the ACK. We've caught this with an Ellisys USB analyser. We can see the missing OUT, then 3 retries from the PC and then a USB reset. * It happens rarely. We set up a script repeating the same simple USB message (target just returns some data, no heavy computing etc.). Sometimes it takes a few iterations, other times thousands of iterations, before the error happens. We'd like to know if this is a known issue or perhaps there are some tricks to debugging it. Re: Missing ACK on USB OUT Transactions Hi @JacobBerggreen  We have checked the  errata of LPC55S2x/LPC552x and have not found any known issues with the lack of ACK directy corresponding to USB0 full speed device OUT. Currently, USB errata mainly focuses on high-speed mode, so it is not directly applicable to your configuration. From the phenomenon, the more likely reason is that the OUT endpoint did not prepare the receiving buffer in a timely manner at certain moments, resulting in the device being unable to respond to ACK when the host sends OUT, triggering retry or even reset. It is recommended to focus on confirming whether USB_SeviceRecvRequest() is immediately called after each OUT is completed, and try to minimize the processing in the callback. It is also recommended to check the priority of USB interrupts, avoid long shutdown interrupts. BR Harry
查看全文
nfclibを使ってInfineon Mifare Classicを読み込む こんにちは、 私の製品 では、PN5190とNFC Libを使って 様々な種類のカードを読み取っています。ある お客様 で 問題 が発生し ています。 デバイス は オリジナル の MIFARE Classic カード を 問題 なく 読み込む のですが、 その お客様は すでに NXP チップ と インフィニオン チップ を 使ったカードを混用しています。 The NXP cards CAN be read just fine.しかし、インフィニオン製カードの場合、デバイスは認証を行うことができません。私は簡略化されたAPIデモをベースに使用していますが、これらのカードは「 ATQAが統合されたタイプAレイヤー3カード」として検出されます。ATQA は 0x0400 、 SAK は 0x88 です が 、 NXP チップ では SAK が 0x08 と 表示されます 。 まず、 MIFARE Classicで使っている のと同じコードを実行しようとしました が、 認証が失敗しました。PeerInfo.uTi.uInitiator.tIso14443_3a.bSakのSAKを変更すると、私も同じ結果になります。おそらく、実際のデータはリーダーに保存されており、ピア情報は「双方向」ではない。例を確認しましたが、この特定の状況に関する情報はありませんでした。互換性のあるカードの読み取り方法に関する情報はありますか? スマホ でカード をCAN読み取 れて問題なく動作 します(元のNXPカードより遅いかもしれませんが、動作します)。 セクター0のダンプは以下のとおりです。 XXXXXXXXC188040043242BCE0001020E XXXXXXXXXXXXXXXX0000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF XXXXXXXXXXXXFF078069XXXXXXXXXXXX NFCライブラリは、以下のエラーコードを返します。 エラー情報 Comp: 0x0 タイプ: 0x0 の 結果 の 送信中 の 認証する 指示 は 0x20000 。 何か例はありますか? 前もって感謝します。 Re: Reading infineon mifare classic using nfclib こんにちは、 @Saydev さん。 あなたの調子が良いといいのですが。 レイヤ3は衝突防止、UID選択、カードのアクティベーションをカバーし、ISO 14443のレイヤ4はデータ交換のための標準化されたコマンドのセットを提供します。基本的なタグ/カードはレイヤー3で処理を停止し、レイヤー4の代わりに独自のメモリ読み書きコマンドを使用します。 お客様がサードパーティのPICC(中身)を使っている場合、デバイス向けに独自のカスタムコマンドセットを実装する必要があります。 また、NxpNfcRdlib -> types -> ph_Status.h も参照してください。ステータスコードの定義については、こちらをご覧ください。 よろしくお願いいたします。 エドゥアルド。 Re: Reading infineon mifare classic using nfclib こんにちは、エドゥアルドさん。 このカードはスマホアプリでMIFARE Classic 1kとして認識され、適切なキーを読み込めば問題なく読み取れます(専用ソフトウェアは不要で、Android用のMIFARE Classicツールだけで済みます)。したがって、このカードは標準的なコマンドを受け付けていると思います(チップのモデルはまだ調べていませんが、ファミリのSLE 78CLXxxxPの一つだと思います)。 データシートには「MIFARE™ 互換インターフェース」と書かれていますが、互換性はエミュレートされているかもしれませんが、動作します。nfclibに付属していた例コードを確認しましたが、ATQAは0x0400、SAKは0x08と期待されています。問題はSAK値が予想値と異なることに関係していると思います。読者にSAKが0x08だと信じ込ませる方法はありますか? Re: Reading infineon mifare classic using nfclib 良いニュースです、 カードの読み取りはできました。カードの読み取り方法を簡略化されたAPIからNfcrdlibEx4_MIFAREClassic.cに示されている方法に変更しただけです。例えば、マクロ phalMfc_Authenticate はこれらのカードで問題なく動作するようですが、MFC_AUTHENTICATE は失敗していました。
查看全文
Reading infineon mifare classic using nfclib Hi, In my product, I use the PN5190 with NFC Lib to read different types of cards. I’m having an issue with one customer: the device reads original MIFARE Classic cards without problems, but this customer has already deployed a mix of cards using NXP chips and Infineon chips. The NXP cards can be read just fine. However, with the Infineon cards, the device is unable to authenticate. I’m using as a base the simplified API demo, and these cards are detected as: “Type A Layer 3 card with merged ATQA”. The ATQA is 0x0400 and the SAK is 0x88, but on the NXP chip the SAK shows 0x08. First, I tried running the same code that I use for MIFARE Classic, but authentication fails. If I modify the SAK in PeerInfo.uTi.uInitiator.tIso14443_3a.bSak, I get the same result. Likely, the real data is kept in the reader and the peer info isn’t “bidirectional.” I’ve checked the examples, but there’s no information for this specific situation. Any info on how to read compatible cards? I can read the card with my phone and it works fine (maybe slower than an original NXP card, but it works). The sector 0 dump is: XXXXXXXXC188040043242BCE0001020E XXXXXXXXXXXXXXXX0000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF XXXXXXXXXXXXFF078069XXXXXXXXXXXX NFC Lib returns this error code: ErrorInfo Comp: 0x0 type: 0x0 The result of sending the authenticate command is 0x20000. Any example? Thanks in advance. Re: Reading infineon mifare classic using nfclib Hello @Saydev Hope you are doing well. Layer 3 covers anti-collision, UID selection and card activation, while ISO 14443 layer 4 presents a set of standardized commands for data exchange. Basic Tags/Cards stop after Layer 3 and use proprietary memory-read/write commands instead of Layer 4. Since your customer is using third-party PICCs, you will need to implement the proprietary/custom command set for your device. Also, please refer to NxpNfcRdlib -> types -> ph_Status.h for the Status Code definitions. Regards, Eduardo. Re: Reading infineon mifare classic using nfclib Good news, I've been able to read the card, i simply changed the way to read the card from simplified API to the approach shown in the NfcrdlibEx4_MIFAREClassic.c example, the macro phalMfc_Authenticate seems to work just fine with these cards while MFC_AUTHENTICATE was failing. Re: Reading infineon mifare classic using nfclib Hi Eduardo, The card is detected by the phone app as mifare classic 1k and it can be read just fine once the proper keys are loaded (no proprietary software is needed, just mifare classic tool for android), therefore i think the card accepts standard commands (i still need to discover the chip model, but i think it's one of the family SLE 78CLXxxxP, on the datasheet it says to have " Mifare™ compatible interface"), maybe the compatibility is emulated but it works, I've checked the example code that came with nfclib and it expects to have a ATQA of 0x0400 and SAK of 0x08, i think that the problem is related to the SAK value having a different value than expected. is there any way to force the reader to believe the SAK is 0x08?
查看全文
使用 nfclib 读取英飞凌 Mifare Classic 卡 您好, 在我的产品中,我使用PN5190和NFC Lib来读取不同类型的卡片。我遇到一个客户的问题:该设备可以毫无问题地读取原装MIFARE Classic卡,但这位客户已经部署了使用NXP芯片和Infineon芯片的混合卡。 NXP卡可以正常读取。​​但是,使用英飞凌卡时,该设备无法进行身份验证。我以简化的API演示为基础,这些卡片被检测为: “带有合并ATQA的A类3层卡” 。ATQA 为 0x0400 , SAK 为 0x88 , 但 在 NXP 芯片 上 , SAK 显示为 0x08 。 首先,我尝试运行与MIFARE Classic相同的代码,但身份验证失败。如果我修改PeerInfo.uTi.uInitiator.tIso14443_3a.bSak中的SAK ,我得到的结果也一样。很可能,真实数据保存在阅读器中,而同伴信息不是“双向的” 。我查阅了示例,但没有找到针对这种情况的信息。有关于如何读取兼容存储卡的信息吗? 我可以用手机读取这张卡,而且读取效果很好(可能比原装NXP卡慢一些,但能用) 。0 区转储内容为: XXXXXXXXC188040043242BCE0001020E XXXXXXXXXXXXXXXX0000000000000000 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF XXXXXXXXXXXXFF078069XXXXXXXXXXXX NFC Lib返回此错误代码: ErrorInfo Comp: 0x0 type: 0x0 这 结果 的 发送 这 认证 命令 是 0x20000 。 有例子吗? 提前致谢。 Re: Reading infineon mifare classic using nfclib 你好@Saydev 希望你一切都好。 第 3 层涵盖防碰撞、UID 选择和卡激活,而 ISO 14443 第 4 层提供了一组用于数据交换的标准化命令。基本标签/卡片在第 3 层之后停止,并使用专有的内存读取命令和写入命令,而不是第 4 层。 由于您的客户使用的是第三方 PICC,您需要为您的设备实现专有/自定义命令集。 另外,请参阅 NxpNfcRdlib -> types -> ph_Status.h用于状态码定义。 问候, 爱德华多。 Re: Reading infineon mifare classic using nfclib 好消息, 我已经能够读取这张卡了,我只是把读取卡片的方式从简化的 API 改成了 NfcrdlibEx4_MIFAREClassic.c 文件中所示的方法。例如,宏 phalMfc_Authenticate 似乎可以很好地处理这些卡,而 MFC_AUTHENTICATE 却失败了。 Re: Reading infineon mifare classic using nfclib 你好,爱德华多, 手机应用能识别出这张卡是 Mifare Classic 1k,加载正确的密钥后也能正常读取(无需任何专用软件,只需安卓版的 Mifare Classic 工具即可)。因此,我认为这张卡可以接受标准命令(我还需要查一下芯片型号,但我认为它是 SLE 78CLXxxxP 系列的其中一款,数据手册上写着“兼容 Mifare ™接口”)。也许这种兼容性是模拟的,但它确实有效。我查看了 nfclib 自带的示例代码,它预期 ATQA 值为 0x0400,SAK 值为 0x08。我认为问题出在 SAK 值与预期值不同上。有没有办法让读者相信 SAK 是 0x08?
查看全文
FRDM-i.MX95 上的外部 JTAG 调试器连接未输出预期的 JTAG 信号 你好, 我正在尝试将外部 JTAG 调试器连接到 FRDM-i.MX95 板。 根据板原理图,JTAG/DAP 信号似乎被连接到 PCB 上的测试点,一些相关元器件被标记为 DNP。 基于此,我对电路板进行了如下修改: 连接测试点的 JTAG 信号 安装与 JTAG/DAP 信号路径相关的 DNP 电阻器 添加了外部调试器的连接器 将 VTref、GND、TCK、TMS、TDI、TDO 和 RESET 连接到外部调试器 但是,我无法从调试器/电路板端观察到预期的 JTAG 信号输出。 例如,在调试器连接序列期间,TCK/TMS/TDI 没有按预期出现。 请您确认以下几点? 上述修改方法是否适用于将外部 JTAG 调试器连接到 FRDM-i.MX95 板? 要启用外部 JTAG/DAP 接口,是否需要额外的电阻器、跳线、焊桥或板修改? 外部调试器开始驱动 JTAG 信号之前,VTref 电压等级或电源时序是否有任何要求? FRDM-i.MX95 上的 i.MX95 在 JTAG/DAP 接口可访问之前是否需要任何启动模式、熔丝设置、网络安全设置或软件初始化? 外部 JTAG 调试器能否直接访问该板上的 Cortex-A55、Cortex-M33 和 Cortex-M7 内核,还是需要引导加载程序/固件进行额外的初始化? 在使用 FRDM-i.MX95 时,是否有推荐的连接器引脚分配或参考修改指南,以便将外部调试器与 FRDM-i.MX95 配合使用? 如果您能提供在 FRDM-i.MX95 板上启用外部 JTAG 调试的任何指导、原理图参考或所需修改细节,我将不胜感激。 顺祝商祺! Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. 你的修改方法是否正确? 原则上,是的。 如果 FRDM 原理图显示: TCK TMS TDI TDO nTRST 或 RESET VTREF GND 通过测试点和 DNP 填充选项,然后将这些信号路由到连接器通常是正确的方法。 但是,由于搜索结果中没有返回原理图,因此我无法确认所有必需的 DNP 电阻器是否都已安装到位。用户手册中不包含 JTAG 电路图。 2. 为什么检测不到 TCK/TMS/TDI 活性? 通常情况下,当连接 JTAG 探针时: TCK/TMS/TDI 由调试器驱动。 目标板不会生成它们。 如果您在 TCK/TMS 上完全看不到任何切换: 最常见原因 1:未检测到 VTref 许多探针(Lauterbach、J-Link、PE Micro、ULINK 等)只有在 VTref 存在且在有效范围内时才会驱动 JTAG 引脚。 检查: 连接器处的 VTref 电压。 共用接地连接。 探针软件会报告目标电压。 对于 FRDM-i.MX95,DAP I/O 电源似乎与 3.3 V 功能域 (NVCC_CCM_DAP) 有关。板文档显示该功能域由VDD_3V3供电。 最常见原因二:电路板未通电 大多数调试器仅使用 VTref 进行检测。 它们不会为目标提供动力。 核实: 电路板由 J25 供电。 PMIC启动。 VDD_3V3 存在。 电路板上的LED指示灯亮起。 该板需要外部PD电源。 最常见原因#3:缺少信号路由重构 如果 JTAG 路径包含: 0Ω DNP电阻器 隔离电阻器 其他馅料选择 即使缺少一个电阻,也可能导致 TCK/TMS 断开连接。 由于搜索结果中没有原理图,我无法核实电阻器的确切配置。 最常见原因#4:引脚映射错误 用欧姆表验证: 探针引脚 → 连接器引脚 → 电阻器 → 测试点 → i.MX95 球。 不要假设测试点标签与标准的 ARM 20 引脚顺序一致。 3. 是否需要特殊的启动模式? 对于不安全的设备: 观察 JTAG 时钟活动不应该需要启动模式。 一旦调试器检测到 VTref 并开始扫描序列,TCK/TMS 就应该切换。 启动开关会影响: eMMC启动 SD启动 序列号下载器 这与调试器是否生成 TCK 无关。 4. 是否涉及安全设置/熔丝? 有可能。 i.MX95 实现了认证调试和调试访问控制。[i.MX95RM_Rev4 | PDF] 、 [i.MX95RM_Rev2 | PDF] 、 [i.MX95 Sec...2026-final | PowerPoint] 然而: 网络安全设置通常会阻止成功的调试访问。 它们通常不会阻止调试器生成 TCK/TMS 本身。 由于您报告完全没有 TCK 活性,我首先会调查以下问题: VTREF 探针配置 电缆引脚排列 缺失的人口选项 在怀疑网络安全之前。 5. A55、M33 和 M7 可以调试吗? i.MX95调试架构支持: Cortex-A55 Cortex-M33 Cortex-M7 通过 CoreSight/DAP 基础设施。[i.MX95RM_Rev2 | PDF] , [i.MX95RM_Rev5 | PDF] 所以从硅芯片的性能角度来看,是的。 所有功能域是否立即可见取决于: 系统状态, 网络安全配置, 支持调试器。 但调试器通常不需要额外的引导加载程序初始化即可检测到 DAP 本身。 推荐测量方法 在进一步修改电路板之前,我会检查以下几点: 电源 VTref = ?V VDD_3V3 存在 板正常启动 连续性 TCK 连接器 ↔ SoC 路径 TMS连接器↔SoC路径 TDI 连接器 ↔ SoC 路径 TDO 连接器 ↔ SoC 路径 RESET 连接器 ↔ SoC 路径 探针侧 调试软件是否报告目标电压? 它是否显示“检测到目标”? 它是否报告尝试进行 JTAG 链扫描? 示波器 直接探测: 调试器连接器引脚 SoC侧测试点 连接尝试期间。 如果调试器连接器处存在 TCK,但 SoC 测试点处不存在 TCK,则问题几乎肯定出在电路板返工上。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 感谢您的支持。 我们检查了外部 JTAG 调试器连接,发现 问题是由FRDM-i.MX95板和电路板之间的线路长度引起的。 外部 JTAG 调试器。 缩短并重新排列 JTAG 信号线后,调试器…… 能够正确检测到目标,并观察到了JTAG信号。 预期的。 因此,通过改进JTAG接线方式,这个问题已经得到解决。 长度和连接质量。 再次感谢您的帮助。
查看全文
USB 输出事务缺少 ACK 我的团队在 USB 输出事务中遇到了 ACK 缺失的问题。 关于我们系统的一些信息: * MCU 型号为 LPC5528 * SDK 版本为 26.03.00。 * 对于 USB_DeviceInit 的调用,我们将 kUSB_ControllerLpcIp3511Fs0 作为第一个参数(controllerId)提供,以便我们使用 USB 全速。 很难对模式做出太多评价。我们可以肯定的是: * 当我们通过 USB 发送大量消息时,偶尔会出现 OUT 事务缺少 ACK 的情况。我们用Ellisys USB分析仪检测到了这个问题。我们可以看到缺少 OUT 信号,然后 PC 进行了 3 次重试,最后通过 USB RESET。 这种情况很少发生。我们编写了一个脚本,重复发送相同的简单 USB 消息(目标只是返回一些数据,没有繁重的计算等)。有时只需几次迭代,有时则需要数千次迭代才会出现错误。 我们想知道这是否是一个已知问题,或者是否有调试技巧。 Re: Missing ACK on USB OUT Transactions 嗨@JacobBerggreen 我们已经检查了 LPC55S2x/LPC552x 的勘误表,没有发现任何与 USB0 全速设备输出直接对应的缺少 ACK 相关的已知问题。目前,USB勘误表主要集中在高速模式上,因此并不直接适用于您的配置。 从这种现象来看,更可能的原因是 OUT 端点在某些时刻没有及时准备接收缓冲区,导致主机发送 OUT 时设备无法响应 ACK,从而触发信号重试甚至 RESET。建议重点确认每次 OUT 完成后是否立即调用 USB_ServiceRecvRequest(),并尽量减少回调中的处理。还建议检查 USB 中断的优先级,避免长时间的关机中断。 BR 哈里
查看全文
iMX8M Plus - SW1 开/关按钮 你好, 我们正在研究 iMX8M Plus EVK,我们发现按住 SW1 约 5 秒钟会关闭 EVK,而按住 SW1 约 1 秒钟会再次打开 EVK。请确认此行为是由硬件/电源管理集成电路 (PMIC) 还是软件处理的。 另外,当 SW3 移到 ON 位置时,板会自动通电,无需按下 SW1。请确认这是否是 i.MX8M Plus EVK 的预期默认行为。 Re: iMX8M Plus - SW1 ON/OFF Button 你好@Govind1807 , 感谢您联系恩智浦技术支持。 这种行为与处理器内部实现的有限状态机有关。 为了更好地理解,我附上了相应的框图,该框图说明了有限状态机的行为及其状态转换。 Chavira_0-1782509945998.png 此致, 查维拉
查看全文
Industrial stack support We are planning to start a project that will have multiple Industrial protocol. Below are my queries. Does NXP provide industrial communication protocol stacks for its MCU and MPU platforms? Is these limited to i.MX94 & i.MX-RT1180?  Which industrial communication protocols are currently supported by NXP? PROFINET EtherNet/IP EtherCAT Modbus TCP/RTU OPC UA TSN PROFIsafe CIP Safety IO-Link HART-IP Others  Which NXP hardware platforms support these protocol stacks? i.MX series S32 series MCX series LPC series Other platforms  Is there a platform-versus-protocol support matrix available?  Are sample applications, reference designs, and demonstration projects provided with the protocol stacks?  Are Linux and RTOS integration examples available?  What is the licensing model for the industrial protocol stacks?  Are the protocol stacks available free of charge? If yes, what are the eligibility criteria and usage conditions?  Are there any restrictions on evaluation, development, or commercial deployment?  In what form are the protocol stacks provided? Binary library Object code Source code SDK package  Is source code access available for the protocol stacks?  If source code is available, what are the commercial, licensing, or NDA requirements to obtain it?  Can the protocol stacks be customized and modified by customers?  What is the process for commercializing a product using the NXP protocol stacks?  Are there any one-time licensing fees associated with commercial product deployment?  Are there any per-device royalties, recurring charges, or annual maintenance fees?  Are there any additional costs associated with production deployment versus evaluation use? Re: Industrial stack support Hello, 1. PROFINET - Supported. EtherNet/IP - Supported. EtherCAT - Supported. Modbus TCP/RTU - Supported. OPC UA - Supported. TSN - Supported. PROFIsafe - Not supported. CIP Safety - Supported IO-Link - Supported. HART-IP - Not supported. 2. All of these families support some of previous mentioned protocols but not all at the same time. As you mention i.MX94 and i.MX-RT1180 are focused to support these protocols. You can also take a look in Layerscape processors. 3. No, we do not have a resource like this. 4. Yes, there are examples in our BSPs/SDKs. 5. Yes, there are examples available. 6. 7. 8. This depends on the way that is provided to the customer and each resource needs to be checked to confirm licensing model. 9. Source code and SDK packages are available. 10. Source code is available. 11. This depends on the way that is provided to the customer and each resource needs to be checked to confirm licensing model. 12. Can be modified by customer. 13. This depends on the way that is provided to the customer and each resource needs to be checked to confirm licensing model. 14. 15. 16. NXP is legally unable to provide guidance on when, where and how to obtain licenses as these are done by 3rd parties with varying and (sometimes) changing terms. I would suggest you contact the owner of the specific protocol you wish to use for information regarding royalties. Best regards.
查看全文
iMX8M Plus - SW1 電源オン/オフボタン こんにちは、 iMX8M Plus EVK の開発に取り組んでおり、SW1 を約 5 秒間押し続けると EVK の電源がオフになり、約 1 秒間押すと再び電源がオンになることを確認しました。この動作がハードウェアやPMICによって処理されるのか、それともソフトウェアによって処理されているのかを確認してください。 また、SW3をON位置に移動させると、SW1を押さずに自動的に電源が入ります。これがi.MX8M Plus EVKの想定されるデフォルト動作であるかどうかをご確認ください。 Re: iMX8M Plus - SW1 ON/OFF Button こんにちは、@Govind1807。 NXPサポートまでご連絡いただきありがとうございます。 この挙動はプロセッサ内に実装された内部FSMに関連しています。 より理解を深めていただくために、FSMの動作と状態遷移を示す対応するブロック図を添付しました。 Chavira_0-1782509945998.png よろしくお願いします、 チャビラ
查看全文
FRDM-i.MX95の外部JTAGデバッガ接続で、期待されるJTAG信号が出力されない。 こんにちは、 FRDM-i.MX95ボードに外部JTAGデバッガを接続しようとしています。 基板の回路図によると、JTAG/DAP信号はPCB上のテストポイントに配線されているようで、関連する一部の部品はDNP(未実装)とマークされている。 これに基づき、基板を以下のように改造しました。 テストポイントからのJTAG信号をコネクテッド JTAG/DAP信号経路に関連するDNP抵抗器を取り付けました 外部デバッガ用のコネクタを追加しました VTref、GND、TCK、TMS、TDI、TDO、RESETを外部デバッガにコネクテッド しかし、デバッガやボード側からの期待されるJTAG信号の出力は観測できません。 例えば、デバッガ接続シーケンス中にTCK/TMS/TDIが期待どおりに表示されない。 以下の点を確認していただけますか? 上記の改造方法は、外部JTAGデバッガをFRDM-i.MX95ボードに接続するのに正しいのでしょうか? 外部JTAG/DAPインターフェースを有効にするために追加の抵抗、ジャンパー、はんだブリッジ、基板の改造などが必要ですか? 外部デバッガがJTAG信号の駆動を開始する前に、VTref電圧レベルや電源シーケンスに関する要件はありますか? FRDM-i.MX95上のi.MX95は、JTAG/DAPインターフェースにアクセスできるようになる前に、ブートモード、ヒューズ設定、セキュリティ設定、ソフトウェア初期化が必要ですか? 外部JTAGデバッガはこのボード上でCortex-A55、Cortex-M33、Cortex-M7コアに直接アクセスできますか?それともブートローダーやファームウェアによる追加の初期化が必要ですか? FRDM-i.MX95で外部デバッガを使用する際に推奨されるコネクタピンの割り当てや、参照変更ガイドはありますか? FRDM-i.MX95ボードで外部JTAGデバッグを有効にするためのガイダンスや回路図の参考、必要な改造の詳細を教えていただけるとありがたいです。 よろしくお願いいたします。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 1. あなたの修正方法は正しいですか? 原則的には、そうです。 FRDM回路図に以下が含まれている場合: TCK TMS TDI TDO nTRST または RESET VTref GND テストポイントやDNP(デジタルノイズプロテクタリング)オプションを通して信号を取り出し、それらの信号をコネクタにルーティングするのが、一般的に正しいアプローチです。 しかし、回路図自体が検索結果に返ってこなかったため、 必要なDNP抵抗 がすべて入力されているかは確認できません。ユーザーマニュアルにはJTAG回路は含まれていません。 2. なぜTCK/TMS/TDIの活性が見られないのでしょうか? 通常、JTAGプローブが接続されると: TCK/TMS/TDIはデバッガによって駆動されます。 ターゲットボードはそれらを生成しません。 TCK/TMSで全く切り替えが見られない場合: 最も一般的な原因その1:VTrefが検出されない 多くのプローブ(Lauterbach、J-Link、PE Micro、ULINKなど)は、VTrefが存在し、かつ有効な範囲内にあるまでJTAGピンを駆動しません。 確認: コネクタにおけるVTref電圧。 共通接地接続。 プローブソフトウェアは目標電圧を報告します。 FRDM-i.MX95の場合、DAP I/O電源は3.3Vドメイン(NVCC_CCM_DAP)に関連しているようです。ボードのドキュメントには、このドメインがVDD_3V3から電源を供給されていることが示されています。 最も一般的な原因その2:ボードに電源が供給されていない ほとんどのデバッガは、センシングのためだけにVTrefを使用します。 それらは標的に電力を供給しない。 確認する: 基板はJ25から給電されます。 PMICが起動しました。 VDD_3V3が存在します。 基板のLEDが点灯しています。 この基板には外部PD電源が必要です。 最も一般的な原因その3:信号ルーティングの再作業の不足 JTAGパスに以下が含まれる場合: 0Ω DNP抵抗器 絶縁抵抗 代替の詰め物オプション 抵抗が1つでも欠けていると、TCK/TMSが切断されることがあります。 回路図は検索結果に含まれていないため、正確な抵抗数リストを検証できません。 最も一般的な原因その4:ピンマッピングの間違い オームメーターで確認してください。 プローブピン → コネクタピン → 抵抗器 → テストポイント → i.MX95 ボール。 テストポイントラベルが標準的なARM 20ピンの順序と一致しているとは限りません。 3. 特別な起動モードが必要ですか? セキュリティ保護されていないデバイスの場合: JTAGクロックの動作を監視するだけであれば、ブートモードは必要ないはずです。 TCK/TMSは、デバッガがVTrefを検出してスキャンシーケンスを開始するとすぐに切り替わるはずです。 ブートスイッチは以下に影響します: eMMCブート SDブート シリアルダウンローダー そして、これらはデバッガがTCKを生成するかどうかとは無関係です。 4. セキュリティ設定やヒューズは関係していますか? 可能性はある。 i.MX95は認証済みデバッグおよびデバッグアクセス制御を実装しています。[i.MX95RM_Rev4 | PDF] 、 [i.MX95RM_Rev2 | PDF] 、 [i.MX95 Sec...2026-final | PowerPoint] しかし: セキュリティ設定は通常、デバッグアクセスを妨げます。 通常、それらはデバッガがTCK/TMS自体を生成することを妨げるものではありません。 TCK活性が全く見られないとの報告ですので、まずは以下を調査します。 VTref プローブ構成 ケーブルのピン配列 人口に関する選択肢が不足しています セキュリティを疑う前に。 5. A55、M33、M7はデバッグ可能か? i.MX95デバッグアーキテクチャは以下をサポートしています: コルテックス-A55 Cortex-M33 Cortex-M7 CoreSight/DAPインフラストラクチャを通じて。[i.MX95RM_Rev2 | PDF] 、 [i.MX95RM_Rev5 | PDF] シリコンの能力の観点から見ると、はい、そうです。 すべてのドメインがすぐに表示されるかどうかは、以下の要因によって決まります。 システムの状態、 セキュリティ構成、 デバッガのサポート。 しかし、デバッガがDAP自体を検出するために、通常は追加のブートローダー初期化は必要ありません。 推奨寸法 基板の再加工を行う前に、以下の点を確認します。 パワー VTref = ?V VDD_3V3 が存在する ボードは正常に起動しています 連続 TCKコネクタ ↔ SoCパス TMSコネクタ↔SoCパス TDIコネクタ↔SoCパス TDOコネクタ↔SoCパス リセットコネクタ ↔ SoCパス プローブ側 デバッガソフトはターゲット電圧を報告しますか? 「ターゲット検出」と表示されますか? JTAGチェーンスキャンが試行されたと報告されますか? オシロスコープ プローブを直接以下へ: デバッガーコネクタピン SoC側テストポイント 接続試行中。 デバッガーコネクタにTCKが存在するのに、SoCテストポイントにTCKが存在しない場合、問題はほぼ間違いなく基板の再加工にある。 Re: External JTAG debugger connection on FRDM-i.MX95 does not output expected JTAG signals 再開まで今しばらくお待ちください。 外部JTAGデバッガー接続を見直したところ、 問題は、FRDM-i.MX95 ボードと 外部JTAGデバッガ。 JTAG信号線を短くして再配置した後、デバッガは ターゲットを正しく検出することができ、JTAG信号は次のように観測された。 期待される。 そのため、この問題はJTAG配線の改良によって解決されました 長さと接続品質。 ご協力いただき、改めて感謝申し上げます。
查看全文
インダストリアルスタックサポート 複数のインダストリアルプロトコルを持つプロジェクトを開始する予定です。 以下は私の質問です。 NXPはMCUおよびMPUプラットフォーム向けに産業用通信プロトコルスタックを提供していますか?これらはi.MX94とi.MX-RT1180に限定されているのでしょうか?  現在NXPがサポートしているインダストリアル通信プロトコルは? プロフィネット イーサネット/IP EtherCAT Modbus TCP/RTU OPC UA TSN プロフィセーフ CIPセーフティ IO-Link ハートイップ その他 - これらのプロトコルスタックをサポートしているNXPハードウェアプラットフォームは? i.MXシリーズ S32シリーズ MCXシリーズ LPCシリーズ その他のプラットフォーム  プラットフォームとプロトコルのサポートマトリックスは存在しますか? ‚� サンプルアプリケーション、リファレンスデザイン、デモンストレーションプロジェクトはプロトコルスタックに含まれているか? ― LinuxとRTOSの統合例はありますか?  産業用プロトコルスタックのライセンスモデルとは? ― プロトコルスタックは無料で利用可能ですか?もしそうなら、適格基準や使用条件はどのようなものですか? ・評価、開発、または商用展開に関して、何らかの制限はありますか? ― プロトコルスタックはどのような形で提供されているのか? バイナリライブラリ オブジェクトコード ソースコード SDKパッケージ ― プロトコルスタックのソースコードアクセスは可能か? ・ソースコードが入手可能な場合、それを入手するための商用、ライセンス、または秘密保持契約(NDA)に関する要件は何ですか? ― プロトコル・スタックはお客様によってカスタマイズ・修正可能か? • NXPプロトコルスタックを用いた製品の商業化プロセスはどのようなものですか? ― 商用製品の展開に伴う一度限りのライセンス料はありますか? ・デバイスごとの使用料、定期料金、または年間保守料金は発生しますか? ・本番環境への導入と評価利用では、追加費用が発生しますか? Re: Industrial stack support こんにちは、 1. PROFINET - サポート対象。 イーサネット/IP - サポート済み。 EtherCAT - 対応しています。 Modbus TCP/RTU - 対応。 OPC UA - サポートされています。 TSN - サポート中。 PROFIsafe - サポート対象外です。 CIPセーフティ - サポート済み IO-Link - サポートされています。 HART-IP - サポートされていません。 2. これらのファミリは、前述のプロトコルのいくつかをサポートしていますが、同時にすべてをサポートしているわけではありません。ご指摘の通り、i.MX94とi.MX-RT1180はこれらのプロトコルをサポートすることに重点を置いています。Layerscapeプロセッサも検討できます。 3. いいえ、そのようなリソースはございません。 4. はい、私たちのBSP/SDKsには例があります。 5. はい、例はあります。 6. 7. 8.これはお客様に提供される方法により、各リソースがライセンスモデルを確認するためにチェックする必要があります。 9. ソースコードおよびSDKsパッケージが利用可能です。 10. ソースコードが利用可能です。 11.これはお客様に提供される方法により、各リソースがライセンスモデルを確認するためにチェックする必要があります。 12. お客様によってCAN。 13.これはお客様に提供される方法により、各リソースがライセンスモデルを確認するためにチェックする必要があります。 14. 15. 16.NXPは、ライセンスの取得時期、場所、方法について法的にガイダンスを提供することはできません。ライセンスの取得は第三者によって行われ、その条件は様々であり、(場合によっては)変更されるからです。 ロイヤリティに関する情報については、使いたいプロトコルの所有者にお問い合わせいただくことをお勧めします。 よろしくお願いいたします。
查看全文
LX2160A 对 FlexSPI DDR/DTR 模式的支持 - 需要 DQS 说明 你好, 我们正在开发 LX2160A-RDB 板的 FlexSPI 驱动程序,并且对 DDR(八进制 DTR)模式支持有一个疑问。 我们的板上有两个 MT35XU512ABA 闪存芯片连接到 FlexSPI 控制器。从板原理图可以确认,XSPI_A_DQS 信号从闪存(引脚 C3)路由到 LX2160A。 处理器(引脚 E23)。 但是,当我们尝试使用 DTR 模式时,闪存读取返回无效数据(全为零)。SDR八进制模式(1-8-8)在各种频率下都能正常工作。 我们还注意到,在 Linux 内核中,LX2160A FlexSPI 驱动程序设置了 FSPI_QUIRK_DISABLE_DTR。 https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html 请问您能否澄清一下: 1. LX2160A FlexSPI 控制器是否支持 DTR/DDR 模式下的基于 DQS 的数据采样,还是这是已知的芯片限制? 2. 如果芯片不支持 DQS,那么 RDB 板上的 XSPI_A_DQS 引脚布线的目的是什么? 3. 是否有任何配置或勘误表可以让 DTR 模式在 LX2160A 上运行? 电路板:LX2160A-RDB Rev B 闪存:MT35XU512ABA(*2,八进制) 参考手册:LX2160A 参考设计板参考手册,修订版 5,2021 年 9 月 28 日 云实验室 在线调试 在线实验室 虚拟测试 Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed MT35XU512ABA 将具有特定的 SPI 协议,称为 Xccela。不确定LX 2160A是否支持。 Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed 你好, 实际的解决方法是:除非 NXP 确认有针对特定芯片版本的变通方案,否则 Linux/LSDK 中对 LX2160A-RDB 上的八进制 DTR 不予支持。最有力的实现证据是您找到的 NXP Linux 补丁:它为 LX2160A 添加了 FSPI_QUIRK_DISABLE_DTR 因为“lx2160a 没有实现 DQS”,并指出这会导致八进制 DTR 模式下的闪存探测失败。 针对您的具体问题: LX2160A FlexSPI 是否支持基于 DQS 的 DTR/DDR 采样? 参考手册将 FlexSPI IP 描述为具有 DQS/读取选通采样模式: MCR0[RXCLKSRC] = 0x3 选择“闪存提供的读取选通和来自 DQS 焊盘的输入”,并且输入时序部分明确描述了使用闪存提供的读取选通进行采样。然而,LX2160A 的 Linux 平台数据明确禁用了 DTR,因为该平台“不实现 DQS”。因此,我不会依赖通用的 FlexSPI IP 描述来证明 LX2160A 芯片可以使用外部 DQS 进行八进制 DTR。 为什么 XSPI_A_DQS 被路由到 LX2160A-RDB? DQS 引脚不仅仅是闪光灯提供的读取频闪信号。该手册将 A_DQS 描述为具有多种可能功能的 I/O:外部读取选通、延迟信息和环回虚拟读取选通;它还指出,可以在此引脚上进行板级加载,以补偿环回模式下的 DATA/SCLK 加载。同一个 FlexSPI 模块还使用 DQS/RWDS 作为某些写入操作的写掩码相关信号。因此,RDB 布线与 FlexSPI 引脚/功能集和板兼容性一致,但这本身并不能证明 LX2160A 支持基于外部 DQS 的八进制 DTR 读取。 LX2160A 是否有任何配置或勘误表可以启用 DTR? 我找到了 DQS 模式的文档配置 MCR0[RXCLKSRC] = 0x3 ,当使用闪存提供的读取选通时,DLL 设置如下: SLVDLYTARGET=0xF , DLLEN=1 , OVRDEN=0 ;对于低于 100 MHz 的串行根时钟,手册建议使用 DLL 覆盖模式, OVRDEN=1 ,并调整 OVRDVAL ,其中 N = 18 是一个推荐值,可能需要调整。但LX2160A特有的Linux问题指出,由于LX2160A未实现DQS,因此DTR功能被禁用。我查阅了LX2160A参考手册/数据手册、RDB参考手册、NXP/Linux补丁文本以及公开的勘误表,均未找到任何关于重新启用DQS/DTR的LX2160A勘误或已记录的解决方法。 https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html 推荐的驱动程序位置:对 LX2160A 保持 FSPI_QUIRK_DISABLE_DTR ,并使用 SDR 八进制 1-8-8 。您的症状——SDR 八进制工作,DTR 读取返回零——与上游决定阻止此 SoC 上的 DTR 一致,而不是简单的板布线问题。 此致
查看全文
LX2160AにおけるFlexSPI DDR/DTRモードのサポート - DQSの説明が必要です こんにちは、 私たちはLX2160A-RDBボード用のFlexSPIドライバを開発中で、DDR(オクタルDTR)モードのサポートについて質問があります。 私たちのボードにはFlexSPIコントローラにコネクテッドされた2つのMT35XU512ABAフラッシュチップがあります。基板の回路図から、XSPI_A_DQS信号がフラッシュ(ピンC3)からLX2160Aにルーティングされていることが確認できます プロセッサ(ピンE23)。 しかし、DTRモードを使用しようとすると、フラッシュメモリの読み取り結果が不正なデータ(すべてゼロ)を返します。SDRのオクタルモード(1-8-8)は、様々な周波数で正しく動作します。 また、LinuxカーネルではLX2160A FlexSPIドライバが設定されていることにも気づきましたFSPI_QUIRK_DISABLE_DTR。 https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html もう少し詳しく教えていただけますか: 1. LX2160A FlexSPIコントローラはDTR/DDRモード用のDQSベースのデータサンプリングをサポートしていますか?それともこれはシリコンの限界として知られていますか? 2. シリコンでDQSをサポートしていない場合、RDBボード上のXSPI_A_DQSピン配線の目的は何でしょうか? 3. DTRモードが機能する設定や訂正表はありますかLX2160A? 理事会:LX2160A-RDB Rev B フラッシュ:MT35XU512ABA(*2、オクタル) リファレンスマニュアル:LX2160Aリファレンスデザインボードリファレンスマニュアル、Rev. 5、2021年9月28日 クラウド・ラボ オンラインデバッグ オンラインラボ 仮想テスト Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed MT35XU512ABAには、Xccelaと呼ばれる特定のSPIプロトコルが搭載されます。LX 2160Aがサポートできるかどうかは分かりません Re: FlexSPI DDR/DTR mode support on LX2160A - DQS clarification needed こんにちは、 実際の答えとしては、NXPがシリコンリビジョン特有の回避策を認めない限り、Linux/LSDKのLX2160A-RDB上のオクタルDTRはサポートされていないとみなすことです。最も強力な実装証拠は、あなたが見つけたNXP Linuxパッチです。そこでは「lx2160aはDQSを実装していない」という理由でLX2160A FSPI_QUIRK_DISABLE_DTR が追加され、これがOctal DTRモードでフラッシュプローブの失敗を引き起こすと書かれています。 ご質問にお答えします。 FlexSPI LX2160A DQSベースのDTR/DDRサンプリングをサポートしていますか? リファレンスマニュアルでは、FlexSPI IPがDQS/リードストロボサンプリングモードを持つと説明されており、 MCR0[RXCLKSRC] = 0x3 「フラッシュ提供のリードストロボとDQSパッドからの入力」を選択し、入力タイミングセクションにはフラッシュ提供のリードストロボによるサンプリングが明示的に説明されています。しかし、LinuxプラットフォームのLX2160Aデータは「DQSを実装していない」としてDTRを無効化しています。ですので、汎用的なFlexSPIのIP説明だけでシリコンが外部DQSをオクタルDTRに使える証拠LX2160Aないと思います。 LX2160A-RDBでは、なぜ XSPI_A_DQS ルーティングされているのですか? DQSピンは、フラッシュメモリから提供される読み出しストロボであるだけでなく、マニュアルでは A_DQS 複数の機能を持つI/Oとして説明されています:外部読み取りストローブ、レイテンシ情報、ループバックダミー読み取りストローブなどです。また、このピンの基板レベルの負荷をループバックモードでのデータ/SCLKロードを補正することも可能だと記されています。同じFlexSPIブロックは、一部の書き込み操作において、書き込みマスク関連の信号としてDQS/RWDSも使用する。したがって、RDBルーティングはFlexSPIのピン/機能セットおよびボード互換性と整合していますが、それだけでは外部DQSベースのオクタルDTR読み取りをサポートしているLX2160A証明できません。 LX2160AでDTRを有効にするための設定や修正プログラムはありますか? DQS モードのドキュメントに記載されている構成は、 MCR0[RXCLKSRC] = 0x3 で、フラッシュメモリから提供される読み出しストローブを使用する場合は、DLL 設定として SLVDLYTARGET=0xF 、 DLLEN=1 、 OVRDEN=0 なります。シリアル ルート クロックが 100 MHz 未満の場合、マニュアルには、DLL オーバーライド モードを OVRDEN=1 で使用し、 OVRDVAL 調整するように記載されています。N N = 18 は推奨値として示されていますが、調整が必要になる場合があります。しかし、LX2160A特有のLinuxのクセは、LX2160AでDQSが実装されていないためDTRが無効化されていると言っており、LX2160Aリファレンスマニュアル/データシート資料、RDBリファレンスマニュアル、NXP/Linuxパッチテキスト、公開エラッタスタイルの検索を確認した後でも、DQS/DTRを再有効化するLX2160Aエラタや文書化された回避策は見つかりませんでした https://lists.infradead.org/pipermail/linux-mtd/2022-July/094127.html ドライバの推奨位置:LX2160AはSDRオクタル 1-8-8 を使い、 FSPI_QUIRK_DISABLE_DTR を保持してください。 あなたの症状(SDR Octalは動作するが、DTRの読み取りでゼロが返される)は、単純な基板配線の問題ではなく、このSoCでDTRをブロックするという上流側の決定と一致しています。 よろしくお願いします。
查看全文
Developing a Dual-Motor EV Control System with Model-Based Design Toolbox 1 Introduction This article series presents the Motor Control System (MCS) within an electric vehicle (EV) architecture. It introduces the end-to-end development flow, from controller and plant modeling to simulation, code generation, hardware deployment, and integration with the rest of the vehicle network. This opening article establishes the technical foundation for a series focused on the architecture, implementation, and integration of a dual-motor control system for EV traction applications. The series also shows how MathWorks tools can be used together with NXP software and hardware to support a Model-Based Design workflow. This approach helps engineers develop, verify, and deploy motor control applications more efficiently while maintaining traceability across the development cycle. RoleOfMCS.jpg Figure 1-1. Role of the Motor Control System within the EV traction domain 2 Table of Contents • Introduction • Overview • Context • References • Conclusion 3 Overview 3.1. What will this series of articles cover? The articles in this series define the development roadmap for the Motor Control System within a broader EV architecture. The series covers the following topics: Software and Hardware Environment - Overview of the MathWorks and NXP tools used to develop, test, and validate a dual-motor control system. Architecture and Model Description - Description of the model architecture, signal interfaces, and core control algorithms implemented in the Motor Control System. Model-in-the-Loop Development - Simulation of the controller and plant in Simulink to validate algorithms before code generation. Software-in-the-Loop Validation - Code generation for the validated controller and comparison of the generated software against the Model-in-the-Loop baseline. Processor-in-the-Loop Validation - Execution of the controller on NXP hardware while the plant remains simulated on the host system. Deployment and Validation on Real Hardware - Integration with physical hardware, scaling from single-motor to dual-motor operation, and configuration of the NXP MCU peripherals required for motor control. CAN Integration - Definition of the CAN communication interface, including database design and integration on the target NXP platform. Results and System Validation - Presentation of the final implementation results and validation of the complete system behavior. 3.2. What is the Motor Control System? Electric vehicles depend on traction systems that deliver efficient propulsion, accurate torque control, and safe operation. At the center of this functionality is the Motor Control System (MCS), which combines real-time control software, power electronics, sensing, actuation, and communication interfaces into a tightly coordinated embedded system. PMSM.jpg Figure 3-1. PMSM motor and controller as core elements of the traction system In modern EVs, the traction system delivers the torque and power needed to propel the vehicle. It is typically composed of the following elements: Electric motor - converts electrical energy from the battery into mechanical power at the wheels. Inverter system - converts DC energy from the battery into the controlled AC waveforms required by the motor. Transmission system - transfers the generated torque from the motor to the wheels. At its core, the Motor Control System regulates motor torque, speed, and position by controlling the voltage and current applied to the motor phases. A typical MCS includes the following functional layers: Control Algorithm - implements torque and current control strategies such as Field-Oriented Control (FOC). Sensing and Feedback - measures motor currents, voltages, rotor position, and temperature. Power Electronics - inverter circuitry that switches DC power into AC waveforms for motor drive. Embedded Processor - microcontroller executing real-time control loops. Communication Interfaces - CAN, LIN, or Ethernet for integration with other system modules. Together, these layers form a closed-loop control system that operates at high switching frequencies and under strict real-time constraints. FOC.png Figure 3-2. Field-Oriented Control (FOC) architecture EV traction systems can be implemented using different architectures depending on the required balance of efficiency, performance, cost, and system complexity. A single-motor architecture uses one traction motor to drive either the front or rear axle. This approach reduces hardware complexity and cost, and it often improves vehicle range because of lower mass and lower overall energy consumption. A dual-motor architecture uses two independent traction machines that can be arranged in several drivetrain topologies. This configuration enables higher total power, better traction, improved vehicle dynamics, and stronger acceleration. The tradeoff is increased electrical and mechanical complexity, together with higher system cost. DualMotor.png Figure 3-3. Example dual-motor traction architecture Advantages & Disadvantages of Dual Motor: Acceleration faster due to torque from both motors Superior traction and handling, especially in snow, rain or off-road conditions Slightly lower range due to increased weight and power consumption More expensive but can include AWD and performance benefits Advantages & Disadvantages of Single Motor: Slightly better range due to less energy consumption More affordable Moderate traction, suitable for most road conditions Slower acceleration Note: The example used throughout this series is based on a dual-motor rear-axle architecture, where each rear wheel is driven by its own motor. 3.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric drive systems, including the following audiences: Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Hardware Engineers Model-Based Design and Simulink Developers Academic and Research Communities 4 Context In the electric vehicle architecture presented in this series, the Motor Control System is located in the rear zone of the vehicle. Each rear wheel is driven by an independent Permanent Magnet Synchronous Motor (PMSM). The Motor Control System ECU coordinates both motors and exchanges real-time data with the rest of the vehicle over the CAN network. DemoArch.png Figure 4-1. Motor Control System highlighted within the EV architecture The traction ECU is built around NXP's S32K396 microcontroller, which supports both single 6-phase motor control and dual 3-phase motor configurations. The inverter stage is driven by the MC33937 pre-driver, which provides three high-side and three low-side FET pre-drivers for automotive motor control applications. Note: The inverter receives DC power from the vehicle battery, while battery operation and safety are supervised by the Battery Management System. The Motor Control System communicates over CAN with the Zone Node controller, which in turn exchanges commands and status information with the main vehicle control node responsible for speed and torque requests. 5 References PMSM Control Workshop BLDC Control Workshop A Model-Based Design (MBDT) Environment for Motor Control Algorithm Development Deploy Motor Control Algorithms on NXP S32K3 from Simulink Motor Control Rapid Prototyping on NXP S32M2 with MathWorks and Model-Based Design Toolbox Next Generation of NXP EV Traction Inverter with S32K39 MCU and FS26 SBC AN14326: 3-phase Motor Control Kit with S32K396 Application Note AN13884: 3-phase Sensorless PMSM Motor Control Kit with S32K344 using RTD AUTOSAR API Application Note Advancing Motor Control Performance with Digital Twins Extended Range Dual-Motor Electric Vehicle Model 6 Conclusion This article introduced the Motor Control System within an EV architecture and established the technical context for the rest of the series. It explained the role of the Motor Control System, compared single-motor and dual-motor traction topologies, and outlined how a Model-Based Design workflow can be applied using MathWorks tools together with NXP software and hardware. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the Motor Control System using MathWorks and NXP solutions.
查看全文
Automotive Lighting Control Using FRDM-A-S32K3XX Microcontrollers 1. Overview This module demonstrates how to implement a vehicle lighting control system using analog input acquisition and FlexIO-based LED driving on NXP S32K3 microcontrollers. The application reads analog inputs from the Analog Key Click module (six push-buttons, each generating a distinct voltage level) and converts them into commands that drive a 4x4 RGB LED matrix. Each button press activates a specific lighting function — low beam, high beam, turn signals, brake lights, or hazard lights — while safety interlocks and blinking patterns run continuously in the background, mimicking how a real automotive Body Control Module (BCM) manages vehicle lighting. This example is based on Application Code Hub demonstrations for: Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 In this workshop, the Analog Key Click simulates six vehicle lighting controls. When the student presses a button, an analog voltage proportional to the pressed key is read by the MCU through the ADC (with software debouncing), decoded into a specific lighting command, and translated into an RGB pattern generated by the FlexIO peripheral. The 4x4 RGB Click then displays the corresponding automotive lighting behavior in real time — warm white for low beams, cool white for high beams, blinking amber for turn signals and hazards, and red for brake lights. Beyond the technical implementation, the course serves as a foundation for the Eat-Sleep-Code-Repeat learning initiative, encouraging a hands-on approach where students continuously learn, develop, test, and improve automotive embedded applications using real hardware and practical examples. 2. Learning Scope After completing this course, participants should be able to:   Understand a basic vehicle lighting control system and the ideas behind an automotive Body Control Module (BCM). Use the Analog Key Click as a simulated multi-button user interface (six inputs on a single analog line). Acquire analog values (0–3.3 V) using the ADC and understand how multiple buttons share one channel through voltage division. Perform software debouncing and decode which button was pressed based on ADC value ranges. Drive an RGB LED matrix using the FlexIO peripheral, generating precise timing for WS2812-style LEDs. Implement safety interlocks between lighting functions (e.g., high beam requires low beam ON). Implement continuous background patterns such as blinking turn signals and synchronized hazards. Recognize the actuation data flow: analog input → ADC → command decoding → FlexIO LED output. Import, build, flash, and debug an ACH project in S32 Design Studio 3.6.5. Understand why lighting functions are relevant for automotive safety and driver visibility. 3. System Architecture The three elements capture exactly the basic idea of the system in the demo: Input: Analog Key Click (six buttons T1–T6, each generating a distinct analog voltage level) Processing: S32K3 MCU (reads the ADC, decodes the button, applies BCM logic, updates the LED state) Output: 4x4 RGB Click (16-LED matrix driven by FlexIO to display lighting patterns) This matches the classic flow of an embedded body-control system: sensor → processing → actuator. Functional Flow The system operates continuously as follows: The user presses a button on the Analog Key Click (T1–T6) Each button generates a distinct analog voltage on the shared output line The ADC samples the voltage and converts it into a digital value The application decodes which button was pressed (with debouncing) The BCM logic applies interlocks and dependencies (e.g., high beam requires low beam) The FlexIO peripheral drives the RGB Click LEDs with the corresponding color pattern This loop runs continuously to ensure real-time lighting control, with blinking patterns and safety interlocks maintained in the background. System_Architecture_Lights.pngVehicle Lighting Control Application Architecture  4. Key Concepts 4.1 ADC (Analog-to-Digital Converter) The Analog Key Click outputs 0–3.3 V on a single analog line, with each button generating a specific voltage step. The ADC samples this voltage on ADC0_P0 (pin PTD1) at regular intervals and quantizes it into a digital code (a 12-bit ADC produces values between 0 and 4095). Each button corresponds to a specific value range, allowing six digital inputs to be read through a single ADC channel. ADC acquisition is the foundation of automotive sensing — used for switches, buttons, sensors, and many others. 4.2 Analog Multi-Button Decoding Instead of using six separate GPIO pins, the Analog Key Click uses a resistor ladder that produces a different voltage for each button press. The application performs software debouncing (multiple ADC samples must agree before a press is confirmed) and then compares the ADC value against predefined thresholds to identify which button (T1–T6) was pressed. This technique is common in automotive steering-wheel controls, where many buttons share a single analog line to save wiring and pins. 4.3 FlexIO — Driving the RGB Click LEDs FlexIO is a highly flexible peripheral on S32K3 that can emulate serial protocols like WS2812/NeoPixel. The RGB Click uses individually addressable LEDs that require precise timing (~800 kHz with strict pulse widths). FlexIO on PTA13 (FlexIO_D8) generates this waveform in hardware, without loading the CPU. Each of the 16 LEDs receives its color data through a serial stream, allowing independent control of color and brightness per LED. 4.4 RGB LED Mapping and Lighting Zones The 16 LEDs of the RGB Click are logically grouped into automotive lighting zones: LEDs 13, 14 → Low Beam Headlights (warm white) LEDs 8, 9, 10, 11 → High Beam Headlights (cool white) LEDs 0, 12 → Left Turn Signal (blinking amber) LEDs 3, 15 → Right Turn Signal (blinking amber) LEDs 1, 2, 5, 6 → Brake Lights (red) LEDs 0, 3, 12, 15 → Hazard Lights (synchronized blinking amber) 4.5 BCM Safety Interlocks and State Dependencies The application implements safety logic typical of a real Body Control Module: high beam can only be activated when low beam is already ON; turning OFF the low beam automatically disables the high beam; hazard lights synchronize left and right turn signals simultaneously; high beam state is preserved during hazard blinking and restored between cycles. These interlocks illustrate how real automotive lighting logic prevents unsafe combinations and preserves driver intent. 4.6 Data Flow at a Glance Button press → analog voltage on shared line → ADC sample → software debouncing → button decoding → BCM logic (interlocks + dependencies) → FlexIO WS2812 output stream → RGB LED color update. This direct chain from the student's finger to the LEDs is the main educational value of the demo. 5. Hardware and Software Setup Required Hardware Component Image Purpose FRDM-A-S32K312 FRDM-A-S32K312.png Alternative MCU platform used to run the lighting application and process user inputs. FRDM-A-S32K344 S32K344MINI-EVB.png Alternative MCU platform used to run the lighting application and control connected peripherals. FRDM-K64 Click Shield frdm-k64-click.jpg mikroBUS expansion board used to connect Click modules to the FRDM platform. Analog Key Click analog-click.jpg Six-button analog module used to simulate the vehicle lighting controls (headlights, indicators, brakes, hazards). 4x4 RGB Click 4x4-rgb-click.jpg 16-LED RGB matrix used to display the automotive lighting patterns in real time. USB-C / 12 V supply — Provides power and enables programming and debugging of the system through a single USB-C connection. The example applications demonstrate how these peripherals are connected to the MCU pins and used to simulate a complete vehicle lighting control system. Vehicle Lighting Control on FRDM-A-S32K312 Vehicle Lighting Control on FRDM-A-S32K344 Lights_k312.png Lights_k344.png Software Environment S32 Design Studio IDE S32K3 Automotive Software Package Application Code Hub project import Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K344 Vehicle Lighting Control for Daylight and Hazard Signals on FRDM-A-S32K312 6. Implementation Guide Step Action Sub-steps Expected Result 1 Import the Project Open S32 Design Studio 3.6.5 Select “Import project from Application Code Hub” Search for “Lighting” Select the desired project for your FRDM board Use the GitHub link for automatic configuration Select main branch Import project Project successfully appears in workspace 2 Build the Application Right-click project Select “Update Code and Build Project” Confirm SDK component management Build completes with no errors and generates .elf file 3 Connect Hardware Connect USB-C cable (and 12 V supply for FRDM-A-S32K312) Attach FRDM-K64 Click Shield, Analog Key Click and 4x4 RGB Click Verify wiring on PTA13 (FlexIO) and PTD1 (ADC) Board is powered and detected by IDE 4 Flash and Run Open Debug Configurations Select “debug_flash_pemicro” Start debugging Application runs continuously; LEDs perform startup test sequence 5 Functional Validation Press buttons T1–T6 on the Analog Key Click Observe corresponding LED patterns on the RGB Click Verify safety interlocks (high beam requires low beam) Verify continuous blinking on turn signals and hazards RGB LEDs display the correct automotive lighting patterns for each button 7. Signal Behavior and Control Logic   The following diagram illustrates how each user input on the Analog Key Click is mapped to a specific lighting function and to the individual LEDs of the 4×4 RGB Click matrix. Each button (T1–T6) triggers a unique combination of LEDs, colors, and patterns, reproducing the behavior of a simplified automotive lighting system.   Led_Matrix_Mapping.png  The MCU continuously monitors the analog input from the Analog Key Click and decodes which button is pressed. Based on the detected input, the application activates the corresponding lighting function by driving the assigned LEDs on the 4×4 RGB Click through the FlexIO serial interface. Steady functions (Low Beam, High Beam, Brake) keep the associated LEDs constantly ON, while directional functions (Left Turn, Right Turn, Hazard) toggle the LEDs at approximately 1 Hz to reproduce the blinking behavior of real vehicle indicators. Additional control rules — such as High Beam requiring Low Beam to be active, or Hazard Lights preserving and restoring the High Beam state — reflect the interdependencies found in a real automotive body control module. 8. Troubleshooting Issue Possible Actions Board Not Detected Check USB-C cable and drivers Verify debugger connection Restart IDE No LEDs Lighting Up Verify FlexIO configuration on PTA13 Check 3.3 V and GND wiring on RGB Click Confirm data-line wiring to IN1 Buttons Not Detected Verify ADC0_P0 configuration on PTD1 Check 3.3 V and GND wiring on Analog Key Click Confirm software debouncing thresholds Wrong Button Triggered Recalibrate ADC value ranges for each button Verify power supply stability (3.3 V) Check for noise on the analog line Incorrect LED Colors or Timing Verify FlexIO clock configuration (WS2812 timing) Check LED index → color mapping in code Ensure RGB order (GRB vs. RGB) matches the LED type High Beam Not Activating Ensure low beam (T1) is ON first — BCM interlock Check application logic for beam dependencies 9. Extending the Application The basic implementation can be extended in several ways: Additional Lighting Functions Add fog lights, parking lights, or daytime running lights (DRL) Simulate reverse lights that activate when a specific input is triggered Adaptive Front Lighting Integrate a steering angle input (e.g., POT Click) to swivel the headlights Simulate cornering lights that turn on when indicators are active Ambient Light Sensing Add a light sensor to automatically enable low beams at dusk Implement smooth dimming between day and night modes Brake Light Enhancements Add an emergency brake flashing pattern for hard braking Implement a third brake light (single LED, always ON with brakes) CAN Communication Enable communication with other vehicle ECUs (e.g., BCM master, doors) Receive lighting commands over the vehicle network State Machine Implementation A more advanced approach is to implement a formal state machine covering: Off DRL / Parking Low Beam High Beam Hazard / Fault 10. Safety Context This example reflects key automotive principles: Continuous monitoring of driver input Immediate response to control signals Reliable actuator (LED) control with predictable timing Safety interlocks between lighting functions (high beam requires low beam) In real systems: Redundancy is required for safety-relevant functions (e.g., brake lights, hazards) Fault detection mechanisms are implemented (open lamp, short circuit, overcurrent) Systems must comply with ISO 26262 (functional safety standard) Vehicle lighting is one of the most safety-critical automotive functions because it directly affects driver visibility and vehicle conspicuity. Modern Body Control Modules implement extensive diagnostics, backup lighting strategies, and fail-safe defaults (e.g., hazard lights activated on power-loss recovery). 11. Conclusion This module demonstrates how a simple embedded system can implement complete vehicle lighting control using ADC input and FlexIO output on the S32K3 platform. It shows how: Multiple digital inputs can share a single analog line through resistor-ladder decoding Analog data is acquired, debounced and processed in real time Complex automotive lighting patterns are controlled through FlexIO-driven WS2812 LEDs Safety interlocks and background blinking patterns are managed by BCM-style logic Result on FRDM-A-S32K312 Result on FRDM-A-S32K344 FRDM-A-S32K312FRDM-A-S32K312 FRDM-A-S32K344FRDM-A-S32K344 The course provides a strong foundation for more advanced systems, including adaptive lighting, CAN networking, ambient sensing, and safety-oriented designs typical of automotive body-control modules.
查看全文
找不到 FRDM MCX A266 的引脚配置工具 找不到现场引脚配置工具。 FRDM 培训 Re: Can't find pin configuration tool for FRDM MCX A266 你好, 如果您是该工具的初学者,以下信息或许对您有所帮助。 MCUXpresso 配置工具的快速入门指南 MCUXpresso 配置工具用户指南(IDE) 如果您需要查找某些信息或工具,与我们联系。 此致敬礼,路易斯 Re: Can't find pin configuration tool for FRDM MCX A266 找到https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-config-tools-pins-clocks-and-peripherals:MCUXpresso-Config-Tools Re: Can't find pin configuration tool for FRDM MCX A266 感谢您的回复。 如果可以的话,请您提供这些工具的逐步配置示例,我将不胜感激。 Re: Can't find pin configuration tool for FRDM MCX A266 你好, 这取决于您想要达成的目标,如果您能确认或描述一下您需要协助完成哪个流程,那就太好了。 此外, MCUXpresso 配置工具用户指南(IDE)第 3 章是引脚配置说明,其中包含步骤和照片,可引导您了解工具功能并匹配您的配置。 此致敬礼,路易斯 Re: Can't find pin configuration tool for FRDM MCX A266 好的,谢谢。我现在想做的是一件很简单的事。 定义 4 个 DAC 通道和 4 个 ADC 通道。 将它们内部路由到 4 个 ADC 通道,以形成闭合回路。 测试这些信号是否到达,然后乘以输入的数量。 再次乘以该数并衡量其性能。 定义通过 USB 串口输出日志信息的功能,用于调试和结果展示。
查看全文
FRDM i.MX 93 Hi. I am interested in use the FRDM i.MX 93 in a project where I need Linux operating system, and control other devices by RS232, SPI and I2C ports. I see that there is an UART port used to USB debug, there are another UART port, I2C and SPI ports that I can use?   Re: FRDM i.MX 93 Hi @alberto83  Yes, the IMX93 has 8 UART interfaces, 8 I²C interfaces, and 8 SPI interfaces available. For more information, you can refer to the following link about imx93 FRDM: https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX93 B.R
查看全文