CSEC GenerateMACAddrMode 地址范围 圣诞快乐 你好 当我使用 CSEC 的 GenerateMACAddrMode 函数时，当地址值超过 0x7DFFF 时，会发生错误。这正常吗？ Re: CSEC GenerateMACAddrMode address range 我的错 我的意思是无法从 512kb CSEC_DRV_GenerateMACAddrMode(CSEC_RAM_KEY,(uint8_t *)0x0007FFFC, 0x00000080, (uint8_t *)cmacout) 中取出； 但我使用 addr = 0x0007FFFC，len = 0x00000080 也没有错误，但超出范围 Re: CSEC GenerateMACAddrMode address range 你好@SaLan 这是 Addr 模式下 CMD_GENERATE_MAC 命令（也称为指针方法）的限制： 分区（即块大小）可以是 128KB、256KB 或 512KB，视衍生产品而定： 此致， Lukas

i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello, I am trying to debug firmware for the Cortex-M33 on an i.MX93 using a Segger J-Link and gdb. I established an SWD connection using the patch from NXP for the J-Link software and can halt the processor, read the registers and memory and so on. My problem is, that resetting the processor does not work. The content of the registers does not change so I assume the reset is ignored: (gdb) monitor regs R0 = 40D000C0, R1 = 2001EFE3, R2 = 40D000C0, R3 = 00000000 R4 = 00000000, R5 = 00000000, R6 = FFFFFFFF, R7 = 2001EEE8 R8 = FFFFFFFF, R9 = FFFFFFFF, R10= 2000F000, R11= 00000000 R12= FFFFFFFF, R13= 2001EEE8, MSP= 2001EEE8, PSP= 00000000 R14(LR) = 0FFE219D, R15(PC) = 0FFE2248 XPSR 49000003, APSR 48000000, EPSR 01000000, IPSR 00000003 CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00 Security extension regs: MSP_S = 2001EEE8, MSPLIM_S = 00000000 PSP_S = 00000000, PSPLIM_S = 00000000 MSP_NS = 00000000, MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC, PSPLIM_NS = 00000000 CONTROL_S 00, FAULTMASK_S 00, BASEPRI_S 00, PRIMASK_S 00 CONTROL_NS 00, FAULTMASK_NS 00, BASEPRI_NS 00, PRIMASK_NS 00 (gdb) monitor reset Resetting target (gdb) monitor regs R0 = 40D000C0, R1 = 2001EFE3, R2 = 40D000C0, R3 = 00000000 R4 = 00000000, R5 = 00000000, R6 = FFFFFFFF, R7 = 2001EEE8 R8 = FFFFFFFF, R9 = FFFFFFFF, R10= 2000F000, R11= 00000000 R12= FFFFFFFF, R13= 2001EEE8, MSP= 2001EEE8, PSP= 00000000 R14(LR) = 0FFE219D, R15(PC) = 0FFE2248 XPSR 49000003, APSR 48000000, EPSR 01000000, IPSR 00000003 CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00 Security extension regs: MSP_S = 2001EEE8, MSPLIM_S = 00000000 PSP_S = 00000000, PSPLIM_S = 00000000 MSP_NS = 00000000, MSPLIM_NS = 00000000 PSP_NS = FFFFFFFC, PSPLIM_NS = 00000000 CONTROL_S 00, FAULTMASK_S 00, BASEPRI_S 00, PRIMASK_S 00 CONTROL_NS 00, FAULTMASK_NS 00, BASEPRI_NS 00, PRIMASK_NS 00 The reset strategy from the J-Link is using SYSRESETREQ and not the reset signal since only the Cortex-M33 core is supposed to be reset. Is it possible that the debug controller does not have the necessary security privileges to write the SYSRESETREQ bit? What is the correct way to perform a reset of the Cortex-M33 using a J-Link? Regards, Malte Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello, Can you also share the details on vlpasha84@gmail.com? More than a yer already from this topic, and still same issue. Thanks. Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working It worked in the sense I never lost again the processor, but the execution time was heavily affected, which I don't understand why. Each operation took 10x more the time. Does it make sense to perform a cold reset but have by default some code in the ROM (contrary on what is suggested by NXP to have no SD card) and attach the debugger to what is ongoing and overwrite ram? Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello, Is it possible to use this JLink script? https://kb.segger.com/images/8/86/Example_Reset_CortexM_Normal.JLinkScript It is a standard strategy for CortexM. Kind Regards Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello, Can you please share your solution? I am currently facing the same situation. Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello Krzysztof, as stated above, I did manage to work out a way to reset the Cortex-M33 in an i.MX93 using a J-Link. If that is what you are looking for, I will gladly share the details with you. Just tell me your e-mail address or another way of contacting you directly. Regards, Malte Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hi, I just found this topic and was wondering if someone was finally able to find some reliable solution for working with M33 in separation from A55. Recently I have started creating development environment for upcoming project and pretty quickly got into the same trouble with triggering software reset. It's been some time since the thread was opened, SEGGER now (v8.10) provides software with builtin IMX targets, although still seems not capable of performing single core reset. I did some experiments with SCB (SYSRESETREQ) and SCR registers but just can't achieve anything stable. I had also quickly tested MCUXpresso plugin for VSCode and didn't notice any custom, working reset strategy implementation. Regards, Krzysztof Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hi Malkai, I am very much interested in a solution as I get exactly the same problem. Is it possible to send me your solution or advice? Many thanks. j.zhang3@krohne.com Best regards Junshu Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hi Malte That would be much appreciated. My mail is nim@develcoproducts.com Best regards Niels Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hi Niels, no thanks to the NXP support, which is less than helpful, I worked out a solution for this problem. If you tell me your e-mail address or any other way of contacting you directly I will be glad to help you. Kind regards, Malte Kaiser Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @Sanket_Parekh  I'm in the exact same situation as the original author. It appears that the JLink script provided by NXP doesn't actually reset the M33 core, but only halts it. This leaves registers and processor state unchanged and if a fault was encountered, I'm not able to continue debugging properly without resetting the core through Linux first. Is there any way that I can trigger such a reset of the M33 core but using the JLink debugger? Best regards Niels Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello Sanket_Parekh, (1) Where can I get the NXP J-Link script patch for i.MX93 Cortex-M33? (2) According to Segger there is no roadmap yet to support i.MX93 in J-Link. But it make come in Q1/Q2. Is there any other possibilities to debug the Cortex-M33? BR Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @malkai , I hope you are doing well. "What is the procedure intended by NXP to reset the Cortex-M33 core in the i.MX93?" ->The System Reset Controller (SRC) is responsible for the generation of all the system reset signals and boot argument latching. ->Its main functions are as follows: • Deals with all global system reset sources from other modules and generates global system reset. • Responsible for power gating of MIXs (Slices) and their memory low power control. ->The SRC takes the POR_B from the PAD and fuse bits to complete the boot sequence and the GPC low power request to complete the power down/up sequence. Please refer to Chapter 33 System Reset Controller (SRC). https://www.nxp.com/webapp/Download?colCode=IMX93RM Thanks & Regards, Sanket Parekh Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @Sanket_Parekhm, thank you for your reply. However, that information does not help to solve the issue. As you know, the Cortex-M33 core in the i.MX93 has the Armv8-M architecture which does not have a VECTRESET bit in the AIRCR register (see D1.2.3 in https://developer.arm.com/documentation/ddi0553/latest/). So the only available reset request is SYSRESETREQ to which there is no reaction by the Cortex-M33 core nor by the entire system. Why is that? I already looked into the reset strategies used by the J-Link. The thing is, that the patch from NXP replaces these with just halting the CPU, as I told you. And the reset line cannot be used here, since it resets the entire SoC. So, the issue still remains: What is the procedure intended by NXP to reset the Cortex-M33 core in the i.MX93? Thank you and kind regards, Malte Kaiser Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @malkai , I hope you are doing well. ->The Reset selection controls the target device reset operation. All reset options apply to Cortex-M processor-based devices, are available in JTAG and SWD mode, and halt the CPU after the reset. ->Core - performs a reset of the Cortex-M core only by setting the VECTRESET bit. On—chip peripherals are not reset. For some Cortex—M devices, this reset method is the only way they may be reset. However, in most cases, this method is not recommended, because most target applications rely on the reset state of some peripherals (PLL, External memory interface, etc.) and may be confused if they boot up, but the peripherals are already configured. ->ResetPin - J-Link pulls its RESET pin low to reset the core and peripherals. Normally, this causes the CPU RESET pin of the device to go low as well, resulting in a reset of the CPU and peripherals. This reset method will fail if the RESET pin of the target device is not pulled low. Please refer to the section reset strategies in the below link. https://community.nxp.com/ pwmxy87654/attachments/ pwmxy87654/kinetis/28743/1/ UM08001_JLink.pdf Thanks & Regards, Sanket Parekh Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @Sanket_Parekh, thank you for your reply. Unfortunately, that information is not helping to solve my problem. In the meantime, I found out multiple things: 1. The J-Link script provided by NXP in the patch for the i.MX93 does not implement a reset. It replaces resetting the CPU with just halting it. 2. Requesting a reset by manually writing AICR.SYSRESETREQ to 1 through the debugger does not result in a reset of the Cortex-M33 core. So, my original question remains: What possibility exits to reset the Cortex-M33 through a debugger? Thanks and regards, Malte Re: i.MX93: Cortex-M33 Reset using J-Link and SYSRESETREQ not working Hello @malkai, I hope you are doing well. Please refer to this link, It will be helpful. https://community.nxp.com/t5/ i-MX-Processors-Knowledge- Base/All-Boards-JTAG/ta-p/ 1106822 ------------------------------ ------------------------------ ------------------------------ ----------------------------- Note: If this post answers your question, please click the Correct Answer button. ------------------------------ ------------------------------ ------------------------------ ----------------------------- Thanks & Regards, Sanket Parekh

88Q9098: STA モードで ofdma/mu-mimo を有効/無効にすることは可能ですか? 私はこの答えを見つけるためにSO一生懸命努力してきましたが、できませんでした。 私が望んでいたのは、有効/無効にする機能を追加することでした DL-OFDMA、UL-OFDMA、DL-MU-MIMO、次回 AP に接続するときの UL-MU-MIMO これらを有効にするのはAPによって行われることは承知していますが、 しかし、それがどのような形をとるかは気にしません。例えば、能力を変えるとか、 私はこれを次のように動作させたいのです: DL-OFDMAを有効にすると、APがそれを使用しようとすると動作します。 STA で無効にすると、AP が無効にしようとしても機能しなくなります。 可能であれば、それは完璧です。 しかし、たとえそれが不可能であっても、私はSO感謝します。 本当にあなたの助けが必要です。 よろしくお願いします。 Re: 88Q9098: Is it possible to enable/disable ofdma/mu-mimo in STA mode? サポートありがとうございます Re: 88Q9098: Is it possible to enable/disable ofdma/mu-mimo in STA mode? こんにちは@nhk OFDMA/MU-MIMO 機能は AP 側でのみ設定できます。STA はこれを無効にできませんでした。STA は AP によって指定された通信プロトコルを使用して通信します。 よろしくお願いいたします。 ショーン

关于使用 FS32K144HAT0MMHT EVK 的热电阻驱动器可用性的说明 大家好， 我想购买FS32K144HAT0MMHTMCU 和相关评估套件 (EVK)。我想知道 EVK 是否包含热电阻驱动器，无需额外费用？ 如果不是，是否需要单独购买 RTD 驱动器？ 预先感谢您的帮助！ Re: Clarification on RTD Driver Availability with FS32K144HAT0MMHT EVK 你好@NagulMeera 实时驱动程序 (RTD) 和 S32 设计工作室 (S32DS) 是免费的。 EB tresos Studio 提供免费评估许可证，但必须向 Elektrobit 订购生产许可证。 我们还提供高级软件，例如： - S32 功能安全软件框架 (SAF) 和功能安全外设驱动器 (SPD) - 结构核心自检 (SCST) 如需高级软件，请联系您的恩智浦代表。 BR、VaneB

[LG]SE051H2HQ1/Z0112Zについて こんにちは、専門家の皆様 AVNET経由でLGより問い合わせがありましたので、詳細は以下をご参照ください。 1. ファームウェアがまだ完成しておらず、後でファームウェアが更新された場合、部品番号が変更になると通知されました。これは正しいですか？ アモテックは会議でLGから情報を得た。お客様によれば、それは LG の唯一の部品番号である可能性があるとのことです。 正しいかどうか確認してください。 2. これが正しい場合、現在の部品番号のどの部分がファームウェア バージョンに対応していますか? 3. 注文後にファームウェアのアップデートが発生した場合、新しいファームウェアを適用した部品を供給することは可能ですか？ 4. ファームウェアが更新された場合、Amotech は現在保有している在庫のファームウェアを更新できますか? 5. お客様からICの事前準備依頼をいただいており、発注後、比較的早く納品できると伺っています。NXP側でも何か準備は進んでいますか？ ご説明をよろしくお願いいたします。 ありがとう、そしてよろしく。 カン Re: [LG]Regarding SE051H2HQ1/Z0112Z こんにちは、カンさん LG とのプロジェクトで新しいタイプが必要になりますが、ここで参照されているタイプであることを確認する必要があります。プロジェクトの参考資料はありますか? 部品番号も常にセキュア エレメントの特定の FW バージョンと構成に対応していることは事実です。配送内容に変更があった場合、明確に区別するために別の部品番号が必要になります。そうしないと、お客様は何を受け取るのか分からなくなってしまいます。部品番号がカスタムタイプのCASEに限り、リリース後にお客様と合意の上、構成を変更することも可能です。 部品がまだリリースされていない場合、ファームウェアを固定する部品がリリースされるまで、配布するサンプルは異なる FW / 構成のままになる可能性があります。 SE051 は基本的にCAN、SO 現場で FW をアップデートできます。ただし、アップデートはリリースされたソース タイプにのみ適用CANため、注意が必要です。 5) については、プロジェクトごとに行われ、事前に計画CANができますが、販売を検討する必要があります。 敬具、 マイケル

Problem of the CAN sampling point test value being too small for S32K3 Hi, NXP When developing with S32K311, an external crystal oscillator of 16 MHz is selected. When configuring CANFD, the CAN clock source uses the AIPS_PLAT_CLK at 60 MHz. 80% sampling point is configured for the data field, and TDC is enabled. However, the actual measured sampling point in CANOE can only reach 72%. This issue also occurs in tests on other models such as the S32K312 and S32K342. The following is one of our configurations where we set the sampling points and test data. We configured the sampling point to be 76%, but the actual test result was 67%. Best Regards， xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong Could you please share your project, i will take time to test it. Re: Problem of the CAN sampling point test value being too small for S32K3 Hi, @Senlent  We have modified multiple configurations. Under the condition that S32K3 is configured to 80%, the best result tested by CANoe is 72% Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong For CAN FD data phase the latest possible sample point must be set in CANoe. Then the VH6501 sends frames and lengthens the individual bits by one tick after each interval. This seems to be a configuration issue with your VH6501. You can try modifying the parameters here to 70%, 76.667%, and 80% and then testing again. Re: Problem of the CAN sampling point test value being too small for S32K3 Hi,@Senlent  We consulted several experienced engineers. They described that there are also problems with the small sampling point test in S32K1 and K3, and this problem may not be strongly related to the MCU.However, the test results vary when different testing instruments are used. When using CANoe for testing, the test results are all on the low side. They suggest that the sampling point configured for S32K3 can be appropriately increased under the actual test requirement of 80%. You can use any NXP demo to conduct a test, and this phenomenon should be reproducible. Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong This should still be a testing issue, not caused by the MCU. However, I will spend some time doing some simple tests. I will probably use an oscilloscope to test directly, which should be the most accurate measurement method. Re: Problem of the CAN sampling point test value being too small for S32K3 Hi,@Senlent  If you have more convincing results, please share them with us as well. We used some other instruments for testing, and the obtained sampling points are relatively close to what we expected in the settings. However, for customers, CANoe has a very high level of industry recognition. Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong It's possible that the client's tests are flawed; please trust your own testing. I will take some time to conduct a few tests, but this isn't a priority for me and may take a few days to get back to you. Re: Problem of the CAN sampling point test value being too small for S32K3 ok Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong I'm sorry, I cannot perform this test. I do not have suitable interference equipment to conduct it, and the test results in the FLEXCAN report already prove that the test passed. I can send you the relevant proof privately. Re: Problem of the CAN sampling point test value being too small for S32K3 Thank you very much.

RT1021：使用 ROM_FLEXSPI_NorFlash_Erase() 擦除闪存扇区 你好 在 EVK 上，我试用了 SDK 25.03.00 中的 evkmimxrt1020_fsl_romapi 示例，它工作正常。 然后，我自己在另一个项目中进行了尝试。它失败了。 ROM_FLEXSPI_NorFlash_Erase() 返回 6001，表示 kStatus_ROM_FLEXSPI_InvalidSequence。 我不知道是哪个顺序。 这两个项目使用完全相同的结构： config->memConfig.tag = FLEXSPI_CFG_BLK_TAG; config->memConfig.version = FLEXSPI_CFG_BLK_VERSION; config->memConfig.readSampleClksrc=kFLEXSPIReadSampleClk_LoopbackInternally; config->memConfig.serialClkFreq = kFLEXSPISerialClk_30MHz; /* Serial Flash Frequencey.See System Boot Chapter for more details */ config->memConfig.sflashA1Size = FLASH_SIZE; config->memConfig.csHoldTime = 3U; /* Data hold time, default value: 3 */ config->memConfig.csSetupTime = 3U; /* Date setup time, default value: 3 */ config->memConfig.deviceType = kFLEXSPIDeviceType_SerialNOR; /* Flash device type default type: Serial NOR */ config->memConfig.deviceModeType = kDeviceConfigCmdType_Generic; config->memConfig.columnAddressWidth = 0U; config->memConfig.deviceModeCfgEnable = 0U; config->memConfig.waitTimeCfgCommands = 0U; config->memConfig.configCmdEnable = 0U; /* Always enable Safe configuration Frequency */ config->memConfig.controllerMiscOption = FSL_ROM_FLEXSPI_BITMASK(kFLEXSPIMiscOffset_SafeConfigFreqEnable); config->memConfig.sflashPadType = kSerialFlash_4Pads; /* Pad Type: 1 - Single, 2 - Dual, 4 - Quad, 8 - Octal */ config->pageSize = FLASH_PAGE_SIZE; config->sectorSize = FLASH_SECTOR_SIZE; config->blockSize = FLASH_BLOCK_SIZE; config->ipcmdSerialClkFreq = kFLEXSPISerialClk_30MHz; /* Clock frequency for IP command */ /* Fast Read Quad I/O */ config->memConfig.lookupTable[4U * NOR_CMD_LUT_SEQ_IDX_READ + 0U] = FSL_ROM_FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xebU, RADDR_SDR, FLEXSPI_4PAD, 0x18U); config->memConfig.lookupTable[4U * NOR_CMD_LUT_SEQ_IDX_READ + 1U] = FSL_ROM_FLEXSPI_LUT_SEQ(DUMMY_SDR, FLEXSPI_4PAD, 0x06U, READ_SDR, FLEXSPI_4PAD, 0x4U); /* Read Status */ config->memConfig.lookupTable[4U * NOR_CMD_LUT_SEQ_IDX_READSTATUS] = FSL_ROM_FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x05U, READ_SDR, FLEXSPI_1PAD, 0x1U); /* Write Enable */ config->memConfig.lookupTable[4U * NOR_CMD_LUT_SEQ_IDX_WRITEENABLE] = FSL_ROM_FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x06U, STOP, FLEXSPI_1PAD, 0x0U); /* Page Program - quad mode */ config->memConfig.lookupTable[4U * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM + 0U] = FSL_ROM_FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0x32U, RADDR_SDR, FLEXSPI_1PAD, 0x18U); config->memConfig.lookupTable[4U * NOR_CMD_LUT_SEQ_IDX_PAGEPROGRAM + 1U] = FSL_ROM_FLEXSPI_LUT_SEQ(WRITE_SDR, FLEXSPI_4PAD, 0x04U, STOP, FLEXSPI_1PAD, 0x0U); /* Sector Erase */ config->memConfig.lookupTable[4U * NOR_CMD_LUT_SEQ_IDX_ERASESECTOR] = FSL_ROM_FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xD7U, RADDR_SDR, FLEXSPI_1PAD, 0x18U); /* Block Erase */ config->memConfig.lookupTable[4U * NOR_CMD_LUT_SEQ_IDX_ERASEBLOCK] = FSL_ROM_FLEXSPI_LUT_SEQ(CMD_SDR, FLEXSPI_1PAD, 0xD8U, RADDR_SDR, FLEXSPI_1PAD, 0x18U); 此外，在这两个项目中，我在调用 ROM_FLEXSPI_NorFlash_Erase() 之前立即验证了 LUT。这些值完全匹配（我还打印了未打包的值）： 0: a1804eb - 1 0 eb - 2 2 18 1: 26043206 - c 2 6 - 9 2 4 2: 0 - 0 0 0 - 0 0 0 3: 0 - 0 0 0 - 0 0 0 4: 406 - 1 0 6 - 0 0 0 5: 0 - 0 0 0 - 0 0 0 6: 0 - 0 0 0 - 0 0 0 7: 0 - 0 0 0 - 0 0 0 8: d33e7f5c - 1f 3 5c - 34 3 3e 9: 450ef151 - 3c 1 51 - 11 1 e 10: 46d155d4 - 15 1 d4 - 11 2 d1 11: 73a1e822 - 3a 0 22 - 1c 3 a1 12: 47bf75f6 - 1d 1 f6 - 11 3 bf 13: a1f5786b - 1e 0 6b - 28 1 f5 14: ed50a7ab - 29 3 ab - 3b 1 50 15: fdf85725 - 15 3 25 - 3f 1 f8 16: 3de09612 - 25 2 12 - f 1 e0 17: 73b47a1d - 1e 2 1d - 1c 3 b4 18: 5cd51237 - 4 2 37 - 17 0 d5 19: 86c0494b - 12 1 4b - 21 2 c0 20: 36343fa5 - f 3 a5 - d 2 34 21: 60d6ddf4 - 37 1 f4 - 18 0 d6 22: fa5745bf - 11 1 bf - 3e 2 57 23: 45fbf74d - 3d 3 4d - 11 1 fb 24: 755471dc - 1c 1 dc - 1d 1 54 25: d5a578c4 - 1e 0 c4 - 35 1 a5 26: 11330943 - 2 1 43 - 4 1 33 27: de5431f6 - c 1 f6 - 37 2 54 28: 2404049f - 1 0 9f - 9 0 4 29: 0 - 0 0 0 - 0 0 0 30: 0 - 0 0 0 - 0 0 0 31: 0 - 0 0 0 - 0 0 0 32: 81750f57 - 3 3 57 - 20 1 75 33: c25ccbf0 - 32 3 f0 - 30 2 5c 34: 8235cd11 - 33 1 11 - 20 2 35 35: 107dccd7 - 33 0 d7 - 4 0 7d 36: c3dde31f - 38 3 1f - 30 3 dd 37: 52185d05 - 17 1 5 - 14 2 18 38: c558911f - 24 1 1f - 31 1 58 39: 6d076d06 - 1b 1 6 - 1b 1 7 40: ad5b6f74 - 1b 3 74 - 2b 1 5b 41: c5d5fe5e - 3f 2 5e - 31 1 d5 42: 80654f09 - 13 3 9 - 20 0 65 43: 407951c6 - 14 1 c6 - 10 0 79 44: b456e9a3 - 3a 1 a3 - 2d 0 56 45: 41a8df34 - 37 3 34 - 10 1 a8 46: f31f6b95 - 1a 3 95 - 3c 3 1f 47: 87dddb44 - 36 3 44 - 21 3 dd 48: 3d917153 - 1c 1 53 - f 1 91 49: 1d205437 - 15 0 37 - 7 1 20 50: 48256685 - 19 2 85 - 12 0 25 51: 546d7544 - 1d 1 44 - 15 0 6d 52: 75741a5c - 6 2 5c - 1d 1 74 53: 7115f5fd - 3d 1 fd - 1c 1 15 54: 4cdff553 - 3d 1 53 - 13 0 df 55: 27c647eb - 11 3 eb - 9 3 c6 56: 7e4c0413 - 1 0 13 - 1f 2 4c 57: 303f0784 - 1 3 84 - c 0 3f 58: 25f045b8 - 11 1 b8 - 9 1 f0 59: a5898157 - 20 1 57 - 29 1 89 60: 4715e747 - 39 3 47 - 11 3 15 61: 554858c4 - 16 0 c4 - 15 1 48 62: cd44c644 - 31 2 44 - 33 1 44 63: 50597dd9 - 1f 1 d9 - 14 0 59 我深信一定存在差异，但我已不知道该去哪里寻找。 两个项目都在 RAM 中运行，时钟配置完全相同。 我应该把问题的重点放在哪里？ 此致问候 最大值 i.MX RT102x Re: RT1021: Erasing flash sector using ROM_FLEXSPI_NorFlash_Erase() 您好@Sam_Gao 我解决了它。问题出在错误的擦除地址上，但错误代码kStatus_ROM_FLEXSPI_InvalidSequence却让我想到了一个完全不同类型的问题，因此我在相当长的一段时间里都把注意力放在了错误的事情上。 顺祝商祺！ 最大值 Re: RT1021: Erasing flash sector using ROM_FLEXSPI_NorFlash_Erase() @mastupristi https://mcuxpresso.nxp.com/api_doc/dev/4490/a00017.html#ga05dc3f1fb8704a958f48f18ad04c2f0f 这似乎是无效序列中的一些问题。我能知道这两个项目是否都来自恩智浦的官方示例，并在同一个EVK板上为你进行了测试吗？

CLRC66301B 掉电模式仍消耗 2 mA 而不是 nA 您好，恩智浦社区 我正在使用 CLRC66301B NFC 读卡器IC 并尝试通过将 PDOWN 引脚设为高电平来激活掉电模式 (3.3)V），详见数据手册。但是，电流消耗保持在2 mA，而数据表显示掉电时电流消耗应在8 nA至40 nA之间。 设置详情： PDOWN 引脚：3.3 V（恒定高电平） VDDs：VDD（TX）、VDD（AUX）、VDD（MCU）电压均为 3.3 V 接口：I²C（测试期间空闲） XTAL：连接 27.12 MHz 晶体 当前测量期间无通信或活动 测量电流： ~2 mA 问题 1.在断言 PDOWN 之前是否需要对寄存器进行配置？ 2。IRQ、XTAL、IFSEL 或其他 GPIO 能否阻止进入真正的掉电模式？ 3.PDOWN 是否需要使用 VDD 或 RESET 进行额外的定时或排序？ 如有任何见解或建议，我们将不胜感激。 谢谢！ 乌玛桑卡尔 NFC 控制器解决方案 Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA 您好， 当您提到当 SDA 和 SCL 物理断开时电流消耗会降低时，是指您移除了该引脚上的所有连接（同时移除主机 MCU 和上拉电阻器），还是指这些线路仅与主机 MCU 断开？ 另外，能否请您描述一下测量所用的方法、设备和测试点？ Eduardo。 Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA 亲爱的恩智浦团队 我使用带有 CLRC66303B 芯片的官方 CLEV6630ARD 板进行了掉电电流测试。只有在进行任何 I²C 通信之前物理断开 SDA 和 SCL 时，电流才会达到 ~40 nA。如果使用一次 I²C，即使将 PDOWN 设为高电平，电流也会保持在 2 mA 以上。 请说明在进入 PDOWN 之前，I²C 线路应该做些什么？具体来说 在断言 PDOWN 之前，MCU 是否应将 SDA 和 SCL 设置为高阻抗（输入，无拉）？ 之前的任何 I²C 通信是否会阻止芯片进入真正的硬掉电？ 谢谢！ Follow-Up: CLRC66303 – High Current in Hard Power-Down Mode (CLEV6630ARD-Based Design) 亲爱的恩智浦团队 我之前曾就 CLRC66301HN 的硬掉电电流提出过问题，你的回复建议迁移到 CLRC663 Plus 系列 (CLRC66303)。此后我改用 CLRC66303B，使用基于 CLEV6630ARD 参考设计的定制板，我想继续提供最新的测试结果。 你之前的回复侧重于 LPCD 行为和 AN11783，但这个问题仅涉及通过 PDOWN 引脚进行硬掉电，没有RF场或 LPCD 处于活动状态。 掉电电流测量 (CLRC66303B)： > 当 PDOWN 处于低电平时（芯片处于活动状态，RF场 开启）：~100 mA >当 PDOWN 为高电平且存在 I²C 上拉时：~1.2 mA >当 PDOWN 为高且 I²C 线路被驱动为低时： ~6.6 mA >当 PDOWN 为高电平且 I²C 线路在使用前已物理断开时：~40 nA 只有在进行任何 I²C 通信之前物理断开 SDA 和 SCL 连接时，芯片才会在 PDOWN 模式下消耗 ~40 nA 电流。如果只使用一次 I²C，则即使在 PDOWN 钳位高电平之后，电流仍保持高电平。 硬件设置摘要： 芯片：CLRC66303B，I²C 模式。 微控制器：TI CC2652R7，100 kHz I²C 电压：3.3 V 调节 上拉：SDA/SCL 上 4.7 kΩ 至 3.3 V 未使用的引脚：按照数据表拉动 未启用射频或 LPCD 功能 方案设计：基于 CLEV6630ARD（附后） 需要澄清的问题： 1.在 PDOWN 模式期间，SDA/SCL 是否内部偏置？ 2。即使后来将PDOWN设置为高电平，之前的任何I²C活动是否会阻止真正的掉电？ 3.在断言 PDOWN 之前，是否有必要将 MCU I²C 引脚设置为 Hi-Z（输入，无拉）？ 4.是否有恩智浦推荐的方法，可在硬 PDOWN 模式下可靠地实现<100 nA，而无需物理断开 I²C 线路？ 我们的目标是确保电池的使用寿命，并且必须实现数据手册中规定的低功耗性能。如果有任何专门关于 PDOWN 行为和 I²C 漏电流的指导或文档，我们将不胜感激。 附上示意图以供参考。 顺祝商祺！ Umasankar C Re: CLRC66301B Power-Down Mode Still Consumes 2 mA Instead of nA 你好@Umasankarc 希望你一切顺利。 我知道你使用的是基于 CLRC66301HN（非增强版）的自定义板，对吗？如果是，请考虑我们建议改用 CLRC663 plus 系列 (CLRC66303)。 引脚 PDOWN 的高电平应启用硬掉电。数据手册中描述的掉电电流 (Ipd) 相当于 CLRC663 芯片中所有电源电流的总和；但是，嵌入在板中的外部元器件可能会消耗额外的功率。 AN11783 CLRC663 plus《电源卡检测》第 3.4 节中描述了一些低功耗设计建议。 Eduardo。

I.MX 93 FRDM 在 hello_world 上崩溃 你好 我下载的版本是： https://github.com/nxp-real-time-edge-sw/heterogeneous-multicore/tree/main(v2.9-202407) 当我启动它时，它会运行几秒钟，然后总是在同一个地方崩溃（这会 RESET 我的 u-boot）。请看截图。总是在同一个地方崩溃正常吗？ 致以最崇高的敬意 Re: I.MX 93 FRDM crashes on hello_world 回复，这里 有预建版本： (Linux 6.12.34_2.1.0):https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX 我使用 UUU 闪存 FRDM-IMX93。 然后停止 linux 启动进入 u-boot，然后输入以下命令： fatload mmc 1:0 0xD0000000 hello_world_ca55_RTOS0_UART2.bin dcache flush; icache flush； cpu 版本 1 0xD0000000 fatload mmc 1:0 0xD1000000 hello_world_ca55_RTOS1_UART1.bin dcache flush; icache flush； 转到 0xD1000000 然后它就可以正常工作了！！ 那么，你能否研究一下如何使用我的 FRDM-IMX93 工具链版本 u-启动 以及用 UUU 刷机的脚本？ 问候， Re: I.MX 93 FRDM crashes on hello_world 您好， 首先，我今天更换了版本的 heterogeneous-multicore v3.2-202507 那么结果也是一样的。 以下是如何生成 hello_world 版本示例的步骤： unzip ./CMSIS_5-Real-Time-Edge-v3.2-202507.zip unzip ./FreeRTOS-Kernel-Real-Time-Edge-v3.2-202507.zip unzip ./heterogeneous-multicore-Real-Time-Edge-v3.2-202507.zip unzip ./lwip-Real-Time-Edge-v3.2-202507.zip 拉开拉链。/mcuxSDK-中间件-多核实时边缘 v3.2-202507.zip unzip ./mcux-sdk-Real-Time-Edge-v3.2-202507.zip unzip ./rpmsg-lite-Real-Time-Edge-v3.2-202507.zip unzip ./soem-Real-Time-Edge-v3.2-202507.zip mv ./FreeRTOS-Kernel-Real-Time-Edge-v3.2-202507 ./FreeRTOS-Kernel mv ./heterogeneous-multicore-Real-Time-Edge-v3.2-202507 ./heterogeneous-multicore mv ./mcux-sdk-Real-Time-Edge-v3.2-202507 ./mcux-sdk mv ./CMSIS_5-Real-Time-Edge-v3.2-202507 ./mcux-sdk/CMSIS mkdir 中间件 mv./mcuxSDK-middleware-Multicore-Real-time-time-Edge-v3.2-202507。/中间件/多核 mv。/lwip-Real-time-Edge-v3.2-202507。/中间件/lwip mv。/rpmsg-Lite-Real-time-Edge-v3.2-202507。/中间件/多核/rpmsg_lite mv。/soem-Real-time-edge-v3.2-202507。/中间件/soem echo 如果没有错误 = 安装成功，请尝试安装 ... echo for a cores : cd ./heterogeneous-multicore export armgcc_dir=~/toolchains/arm-GNU-Toolchain-12.2.rel1-x86_64-aarch64-aarch64-none-elf/ 。/build_apps.sh a-core mcimx93evk_ca55 freertos echo 适用于我的内核：导出 armgcc_dir=~/toolchains/arm-GNU-Toolchains/arm-GNU-Toolchain-12.2.rel1-x86_64-arm-none-eabi/。 /build_apps.sh m-core mcimx93evk_cm33 freertos echo 让我们清理干净...:。 /build_apps.sh clean echo 完成了 所以，如果你想要链接 ： https://github.com/nxp-real-time-edge-sw/heterogeneous-multicore/releases/tag/Real-Time-Edge-v3.2-202507 https://github.com/nxp-mcuxpresso/mcux-sdk/releases/tag/Real-Time-Edge-v3.2-202507 https://github.com/nxp-mcuxpresso/FreeRTOS-Kernel/releases/tag/Real-Time-Edge-v3.2-202507 https://github.com/nxp-mcuxpresso/lwip/releases/tag/Real-Time-Edge-v3.2-202507 https://github.com/nxp-mcuxpresso/mcuxsdk-middleware-multicore/releases/tag/Real-Time-Edge-v3.2-202507 https://github.com/nxp-mcuxpresso/rpmsg-lite/releases/tag/Real-Time-Edge-v3.2-202507 https://github.com/nxp-real-time-edge-sw/soem/releases/tag/Real-Time-Edge-v3.2-202507 https://github.com/nxp-mcuxpresso/CMSIS_5/releases/tag/Real-Time-Edge-v3.2-202507 那么为此版本就没问题了： 上传 .bin在 imx93 上，我使用 SD 卡直接从电脑写入图像，然后将我的 SD 插入评估板。 在这里，我可以看到我的图像 ： 然后你看到的是 u-boot。 这是仓库：https://github.com/u-boot/u-boot/releases/tag/v2025.10 然后我也下载了这个： https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.21.bin https://github.com/nxp-imx/imx-atf/tree/lf_v2.8 https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.11.bin 我使用此文档进行： https://docs.u-boot.org/en/latest/board/nxp/imx93_frdm.html 但在这里，我使用我的工具链来执行这 2 条命令： make plat=imx93 cross_compile=/HOME/tocuille/Toolchains/arm-GNU-Toolchain-12.2.rel1-x86_64-aarch64-none-elf/bin/aarchain64-none-elf-bl31 和 ： $ export CROSS_COMPILE=/home/tcouille/toolchains/arm-gnu-toolchain-12.2.rel1-x86_64-aarch64-none-elf/bin/aarch64-none-elf- $ make imx93_frdm_defconfig $ make 然后，我使用 UUU ::https://github.com/nxp-imx/mfgtools/releases/tag/uuu_1.5.201 然后输入 ： ./uuu -v -b emmc_all .\flash.bin 输入以下命令在 2 Cortex-A 上用上市 2 hello_world 示例： fatload mmc 1:0 0xD0000000 hello_world_ca55_RTOS0_UART2.bin dcache flush; icache flush； cpu 版本 1 0xD0000000 fatload mmc 1:0 0xD1000000 hello_world_ca55_RTOS1_UART1.bin dcache flush; icache flush； 转到 0xD1000000 几秒钟后，u-boot 正在重置... 谢谢、 Re: I.MX 93 FRDM crashes on hello_world 你好 你能试试这个板上的脚本吗： mcimx93evk_ca55 您测试的是哪个版本的 uboot，我将尝试在此重现。 此致敬礼

clrc663 lpcd i 和 q 值 i 得到 0x00 我正在使用 clrc663 作为读卡器我在那里实现了 lpcd 模式我在运行 lpcd 校准功能时遇到了问题我得到了 i 而且 q 值是 0x00 我从天线得到的是什么问题怎么解决这个问题 我使用的这个函数   /* 执行 LPCD 校准 */ phStatus_t Calibrate_LPCD(uint32_t dwLPCDDemo, uint32_t *pdwLPCDRefValue) { phStatus_t wStatus； uint8_t bValueI = 0； uint8_t bValueQ = 0； uint8_t bVersion = 0； uint8_t bDigitalFilter = PH_ON； uint16_t wDetectionOption = PHHAL_HW_RC663_FILTER_OPTION1； uint16_t wPowerDownTimeMs = LPCD_POWERDOWN_TIME； uint16_t wDetectionTimeUs = LPCD_FIELD_ON_DURATION； DEBUG_PRINTF("\nLPCD 校准开始。"); phhalHw_FieldOn(pHal)； phhalHw_Wait(pHal, PHHAL_HW_TIME_MILLISECONDS, 5)；   /* 配置 LPCD 模式默认值，以执行 LPCD 校准循环。 * 提供输入参考 I 和 Q 值为零，并将检测时间提供给 * 在此持续时间内打开射频，使用 I 和 Q 通道值测量负载变化。 * 配置合适的掉电时间以节省 RC663 读卡器IC 的功耗。*/ wStatus = phhalHw_Rc663_Cmd_Lpcd_SetConfig(pHal，PHHAL_HW_RC663_CMD_LPCD_MODE_DEFAULT、 bValueI、bValueQ、wPowerDownTimeMs、wDetectionTimeUs）； CHECK_STATUS(wStatus)； DEBUG_PRINTF("\nphhalHw_Rc663_Cmd_Lpcd_SetConfig.")； /* 读取版本寄存器，以区分 RC663 Old（RC66301、RC66302）和 RC663 Plus（RC66303）。*/ wStatus = phhalHw_Rc663_ReadRegister(pHal,PHHAL_HW_RC663_REG_VERSION,&bVersion)； DEBUG_PRINTF("\nphhalHw_Rc663_ReadRegister.")； CHECK_STATUS(wStatus)； 如果 (bVersion == PHHAL_HW_CLRC663PLUS_VERSION)     { /* 配置充电泵，使其具有较高的检测范围。 * 启用电荷泵会在检测阶段增加功率级 * 探测范围。这导致平均电流消耗增加。*/ wStatus = phhalHw_SetConfig(pHal,PHHAL_HW_RC663_CONFIG_LPCD_CHARGEPUMP,PH_ON)； CHECK_STATUS(wStatus)； DEBUG_PRINTF("\nphhalHw_SetConfig.")； /* 配置数字滤波器会触发信号 RC663 Plus 算法以获得倍数的平均值 * 检测 I 值和 Q 值的变化。这反过来又延长了射频开启时间 * 增加平均电流消耗。*/ wStatus = phhalHw_SetConfig(pHal，PHHAL_HW_RC663_CONFIG_LPCD_FILTER、 ((uint16_t)(bDigitalFilter)|wDetectionOption))； CHECK_STATUS(wStatus)；    }   /* 执行 LPCD 校准周期并获取 LPCD 参考 I 和 Q 值。*/ wStatus = phhalHw_Rc663_Cmd_Lpcd_GetConfig(pHal,&bValueI,&bValueQ)； DEBUG_PRINTF("\nphhalHw_Rc663_Cmd_Lpcd_GetConfig.")； CHECK_STATUS(wStatus)；   *pdwLPCDRefValue = ((bValueI) | (bValueQ<< 0x8))； DEBUG_PRINTF("\npdwLPCDRefValue.")；   DEBUG_PRINTF("\nLPCD 校准成功。");   返回 PH_ERR_SUCCESS； } 然后我在主 while 循环中调用 /* ------------------------------------------------------------------ * 开机后运行一次 LPCD 校准 * ------------------------------------------------------------------ */ phStatus_t LPCD_Calibrate(void) { phStatus_t status; uint32_t refVal; char dbg_buf[64]； // 确保在校准前开启 RF phhalHw_FieldOn(pHal)； phhalHw_Wait(pHal,PHHAL_HW_TIME_MILLISECONDS,5)； status = Calibrate_LPCD(LPCD_DEMO_MODE_DEFAULT，&refVal)； // 校准后关闭射频 phhalHw_FieldOff(pHal)； if (status == PH_ERR_SUCCESS) { gLpcdValueI = (uint8_t)(refVal& 0xFF); gLpcdValueQ = (uint8_t)((refVal 0xFF)); gLpcdValueQ = (uint8_t)((refVal 0xFF)).>> 😎 & 0xFF); gLpcdCalibrated = 1； sprintf(dbg_buf,"LPCD Calibration OK (I=0x%02X, Q=0x%02X)\r\n", gLpcdValueI, gLpcdValueQ)； DEBUG_UART2((unsigned char*)dbg_buf, strlen(dbg_buf)); } else { DEBUG_UART2((unsigned char*)"LPCD Calibration FAILED\r\n", 28); } return status; } 如果 (!lpcdCalibrated)     { 如果 (LPCD_Calibrate() == PH_ERR_SUCCESS) { lpcdCalibrated = 1; // 标记为已完成 DEBUG_UART2((unsigned char*)"LPCD Calibration OK\r\n", 23)；          } 不然 { DEBUG_UART2((unsigned char*)"LPCD Calibration FAILED\r\n", 28)；      }    } Re: clrc663 lpcd i and q value i getting 0x00   您好，先生， 非常感谢您与我们分享您的示意图。不过，我还是要问一下你们天线的史密斯图。我们确实有一份应用笔记，其中显示了使用廉价的纳米VNA进行这些测量的步骤。 Re: clrc663 lpcd i and q value i getting 0x00 我在这里附上我的硬件测试和原理图，在正常模式下，我得到的是 uid，这不是问题；在 lpcd 模式下，我得到的是 0x00,0x00 的 q 值。在此查看我的测试文件。 Re: clrc663 lpcd i and q value i getting 0x00 抱歉，但是对自定义板的支持非常有限。   要提供任何具体信息，我需要您的硬件，因为评估套件的天线设置配置与您的配置存在很大差异。   不过，您是否介意分享一下天线的史密斯图和原理图，这将是我们提供良好建议的一个很好的起点。   正如我在上一篇文章中提到的那样，我们建议从一开始就遵循一些步骤。其中之一是将我们的 EVK 与您的新天线和新的匹配电路一起使用。所有这些都显示在我们的许多文档中。请看 NFC天线设计|恩智浦半导体视频2。   发送 RF 开启命令后，I 和 Q 值应显示与 0x0 不同的值。 Re: clrc663 lpcd i and q value i getting 0x00 我使用的是带有 stm32 硬件的定制 PCB Clrc663，只有在软件中天线调谐是正确的，我使用了 nfcrdlibEx6_rc663_LPCD_Demo.c 库中的校准演示代码，但 i 和 q 值均为 0x00，然后我使用错误寄存器来确定我在其中出现了什么错误。 printf debug i getting === EEPROM / LPCD 检查开始 === VERSION(0x7F)=0x1A ERROR(before)=0x00 ERROR(after LOADREG)=0x80 > > > EEPROM 错误 (0x80) 仍然存在。LPCD 可能无法正确校准！ === EEPROM / LPCD 检查完成 === // 这是代码 phStatus_t Rc663_EepromInitAndCalibrateLPCD( phhalHw_Rc663_DataParams_t *pHal, uint32_t *pdwLPCDRefValue) { phStatus_t status; uint8_t bVersion, bIrq1, bErr； uint8_t bValueI = 0, bValueQ = 0; char dbg[64]; uint8_t eepromVal; uint8_t addr; sprintf(dbg,"\r\n=== EEPROM + LPCD Init ===\r\n"); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); /* 1.读取芯片版本 */ status = phhalHw_Rc663_ReadRegister(pHal, PHHAL_HW_RC663_REG_VERSION,&bVersion)； CHECK_STATUS(status); sprintf(dbg,"VERSION(0x7F)=0x%02X\r\n", bVersion); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); /* 2.清除任何现有错误 */ phhalHw_Rc663_ReadRegister(pHal, PHHAL_HW_RC663_REG_ERROR,&bErr); sprintf(dbg,"ERROR(before)=0x%02X\r\n", bErr); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); /* 3. 强制将 LOADREG 从 EEPROM 写入寄存器 */ status = phhalHw_Rc663_WriteRegister(pHal, PHHAL_HW_RC663_REG_COMMAND, PHHAL_HW_RC663_CMD_LOADREG)； CHECK_STATUS(status); /* EEPROM 加载稍有延迟 */ phhalHw_Wait(pHal, PHHAL_HW_TIME_MILLISECONDS, 5); /* 4.再次检查错误寄存器 */ phhalHw_Rc663_ReadRegister(pHal, PHHAL_HW_RC663_REG_ERROR,&bErr); sprintf(dbg,"ERROR(after LOADREG)=0x%02X\r\n", bErr)； DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); if (bErr& PHHAL_HW_RC663_BIT_EE_ERR) { sprintf(dbg,"> > > EEPROM 错误 (0x%02X) detected！\r\n" 、berR); DEBUG_UART2 ((uint8_t*) dbg、strlen (dbg)); /*---EEPROM 转储（前 16 个字节用于调试）---*/ for (addr = 0；addr < 0x10；addr++) { phalHW_rc663_cmd_reade2 (phAL，addr，1，& eePromade2) val); spr intf (dbg，" EEPROM [0x%02X] = 0x%02X\ r\n "，addr，eepromVal)；DEBUG_UART2 ((uint8_t*) dbg，strlen (dbg))；} /*---绕过 EEPROM 继续手动初始化---*/ sprintf (dbg，" 绕过 EEPROM，使用手动 RF 设置...\ r\n ")； DEBUG_UART2 ((uint8_t*) dbg、strlen (dbg))；phhalHW_rc663_WriteRegister（phal，PHHAL_HW_RC663_RC663_REGISTER，PHAL_HW_RC663_RC663_RC663_）； phalHW_RC663_WriteRegister REG_TXAMP，0x1F）；phhalHW_RC663_WriteRegister（phal，PHHAL_HW_RC663_REG_DRVCON，0x18）；} else {sprintf（dbg，" EEPROM LOADREG OK。 \ r\n "); DEBUG_UART2 ((uint8_t*) dbg，strlen (dbg));} /* 5. 清除 IRQ 标志 */ phHALHW_RC663_WriteRegister（phal、PHHAL_HW_RC663_REG_IRQ0、0x7F）；phalHW_RC663_WriteRegister（phal、PHHAL_HW_RC663_REG_IRQ1、0x7F）；/* 6。 启用校准模式 */ phHALHW_RC663_WriteRegister (phAL、PHHAL_HW_RC663_REG_LPCD_OPTIONS、0x02)；/* 7. 启动 LPCD_CALIBRATE（0x37 是隐藏的校准命令）*/ phhalHW_RC663_WriteRegister（ phal，PHHAL_HW_RC663_REG_COMMAND，0x37）；/* 8。 等待 LPCDIRQ */ 做 {phHalHW_rc663_readRegister ( phAL、PHHAL_HW_RC663_REG_IRQ1、& birQ1);} while (! (birQ1 & PHHAL_HW_RC663_BIT_LPCDIRQ)); /* 9. 读取 I/Q 结果 */ phHALHW_RC663_readRegister（phal、PHHAL_HW_RC663_REG_LPCD_RESULT_I、& bValueI）；phalHW_rc663_readRegister（phal、PHHAL_HW_RC663_REG_LPCD_RESULT_Q、& bValueQ）；/* 10。 存储 */ *pdwLPCDRefValue = (uint32_t)bValueI | ((uint32_t)bValueQ<< 8); sprintf(dbg,"[LPCD] 校准完成：I=0x%02X Q=0x%02X Ref=0x%08X\r\n", bValueI, bValueQ, *pdwLPCDRefValue); DEBUG_UART2((uint8_t*)dbg, strlen(dbg)); return PH_ERR_SUCCESS; } Re: clrc663 lpcd i and q value i getting 0x00 您好，先生， 为了校准 CLRC663 的 LPCD，我们强烈建议您使用NFC Cockpit。 这是一个图形用户界面工具，允许用户以图形方式对天线进行微调，同时进行LPCD 校准（第 4.5 节）。我们鼓励您使用这种方法，因为校准必须根据您自己的设计进行。没有任何手册可以按部就班地完成这一程序。 NFC Cockpit 允许用户在读写器卸载和加载时进行实时校准。 请探讨查看以下天线设计视频系列的第 4 段视频的可能性：NFC 天线设计 | 恩智浦半导体

用于 mcxn947 的 flexio qspi 恩智浦你好， 我需要使用 flexio 来模拟 qspi 接口才能使用或非 flash。我想知道是否有任何方法可以直接对闪光灯进行编程，类似于 ISP 模式的工作方式。 我已经简要地阅读了参考手册，看来MCX无法在flexio上与qspi进行直接交互，只能与可以支持此功能的flexspi进行直接交互。 nxp 提供的现有工具中是否有可以实现此功能的工具？ 我还查看了关于使用 flexio 仿真 qspi 的 AN14175。 我想问一下，中断模式的 flexio qspi 和 edma 模式的 flexio qspi 有什么区别？它们各自的性能如何，每种模式的用例又是什么。 启动 ROM | 启动配置 | 闪存 通信& 控制（I3C | I2C | SPI | FlexCAN | 以太网 | FlexIO） 核心与内存 MCX N Re: flexio qspi for mcxn947 你好@TomC818 我可以像 ISP 使用 FlexsPI 一样通过 Flexio-QSPI 对 NOR Flash 进行编程吗？ 不，不是直接。 ISP 仅通过 FlexSPI 而非 FlexIO 仿真 QSPI 支持外部闪存编程。 MCX 中的 ROM 引导加载程序 (ISP) 无法识别或支持 FlexIO 作为可编程接口。   BR 哈利

使用LPC4370的GPIO产生的脉冲长度无法控制 我尝试使用LPC4370的GPIO来产生一对长度200ns左右的Push，Pull脉冲。一开始我使用定时器中断嵌套GPIO控制的方法实现，但观察示波器发现这种方法实现的脉冲宽度非常不稳定，能明显观察到既有ns级别的脉冲也有us级别的脉冲，并且无法控制。我尝试分析问题，但是无从下手，希望有人能够帮忙提供解决方法，或者帮忙指出问题出在哪里。这是我的中断函数， 其余相关代码及图像在楼下附上。 void TIMER2_IRQHandler(void) { /* Clear timer interrupt */ Chip_TIMER_ClearMatch(LPC_TIMER2, 1); *gpnot = 0x02; for(int j=0;j<2;j++){} *gpnot = 0x42; for(int j=0;j<2;j++){} *gpnot = 0x42; for(int j=0;j<2;j++){} *gpnot = 0x42; for(int j=0;j<2;j++){} *gpnot = 0x40; } 回复： 使用LPC4370的GPIO产生的脉冲长度无法控制 非常感谢，我参考这个示例实现了我的需求 回复： 使用LPC4370的GPIO产生的脉冲长度无法控制 Hi @Maf33  生成对齐互补的脉冲，请参考： https://www.nxp.com/docs/en/application-note/AN11538.zip   这个应用笔记基本涵盖了了SCTimer所有基本的用法。 BR Alice 回复： 使用LPC4370的GPIO产生的脉冲长度无法控制 非常感谢回复，具体时序要求见楼下，似乎sct的pwm控制没办法做到这样子的时序？ 回复： 使用LPC4370的GPIO产生的脉冲长度无法控制 您好，非常感谢回复@Alice_Yang 我这边对push和pull的时序有要求，我之前的尝试过程中，sct的pwm控制的话好像无法做到边沿对齐（50ns以内的延迟也可以）并且发射三个脉冲？我不是很确定，也许只是我sct的做法不对？motorcontrolpwm功能似乎可以达成要求，但很可惜只在bga256封装的LPC4370上面支持，我所使用的是bga100的封装版本。 回复： 使用LPC4370的GPIO产生的脉冲长度无法控制 我的实际工程中需要HSADC配合定时器触发，当我试着产生仅仅一个脉冲的情况下，仍然无法产生200ns的脉冲，大部分时候产生的都是1us多的脉冲，甚至同样的延时方法无法得到相同的延时（包括NOP）。在一些测试中，可以在示波器上同时看到200ns的脉冲和1us的脉冲。 回复： 使用LPC4370的GPIO产生的脉冲长度无法控制 我一开始怀疑问题出在定时器，于是我将定时器移除，使用单纯的for循环的来实现周期，这样可以达成我的需求：产生200ns宽度的Push Pull脉冲各三个，但当我用同样的方法将脉冲个数提高到四个甚至更多的时候，就又不受控制了，从图片中可以很明显看到，200ns的脉冲宽度直接变成了不同长度的us级别脉冲。 #define TICKRATE_HZ 1000 volatile uint32_t *gpset = &LPC_GPIO_PORT->SET[1]; volatile uint32_t *gpclr = &LPC_GPIO_PORT->CLR[1]; volatile uint32_t *gpnot = &LPC_GPIO_PORT->NOT[1]; int main(void){ /* —— 时钟与板级初始化 —— */ SystemCoreClockUpdate(); Board_Init(); DEBUGOUT("SystemCoreClock = %d Hz\r\n", SystemCoreClock); // Chip_GPIO_Init(LPC_GPIO_PORT); DEBUGSTR("GPIO driver init done\r\n"); /* —— PUSH: GPIO1[1] 输出 —— */ Chip_SCU_PinMux(1, 8, MD_EHS, FUNC0); LPC_GPIO_PORT->DIR[1] |= 1<<1; /* —— PULL: GPIO1[6] 输出 —— */ Chip_SCU_PinMux(1, 13, MD_EHS, FUNC0); LPC_GPIO_PORT->DIR[1] |= 1<<6; *gpset=0x42; while (1) { for(int i=0;i<180000;i++){} *gpnot = 0x02; for(int j=0;j<2;j++){} *gpnot = 0x42; for(int j=0;j<2;j++){} *gpnot = 0x42; for(int j=0;j<2;j++){} *gpnot = 0x42; for(int j=0;j<2;j++){} *gpnot = 0x42; for(int j=0;j<2;j++){} *gpnot = 0x42; for(int j=0;j<2;j++){} *gpnot = 0x40; } return 0; }

RW612 FlexSPI PORTB1 アクセス RW612 チップセットを外部 XIP モードで使用しています。コードは FlexSPI PortA1 から実行され、PSRAM (APS6404L) を FlexSPI PortB1 に接続しています。SDKs (25.06 バージョン) が提供する構成を使用してポート B1 にアクセスしています。 PSRAM ID を読み取ろうとすると、PortB1 (CLCK/CS) で信号アクティビティが表示されません。 これらの信号が欠陥のある部品によって保持されていないことを確認するために、SPARM を取り外しました。 これは、APS6404 が DQS 信号を使用しないという事実に関係していますか? DQS を使用しないように PortB1 を構成するにはどうすればよいでしょうか? FlexSPI が PortA1 アクセス用に初期化された後は、FLEXSPI_Init 関数を呼び出すことができないことがわかっています。 ご協力とお時間をありがとうございました。 Re: RW612 FlexSPI PORTB1 access こんにちは、ローマン。 ご協力ありがとうございます。この問題は、バスの実行中に FlexSPI クロックを設定しようとしたことに関連していました。次の行をコメント アウトしました。 CLOCK_EnableClock( kCLOCK_Flexspi ); BOARD_SetFlexspiClock(FLEXSPI、5U、3U); FlexSPI ポート B1 は現在実行されており、AHB キャッシュを使用して PSRAM への書き込み/読み取りをCAN。 助けてくれてありがとう、本当に感謝してるよ。 Re: RW612 FlexSPI PORTB1 access こんにちは@khalidL 。 下の画像のように、MCU 設定で PSRAM メモリ セクションを定義しましたか? プロジェクトのアプリケーション コード ハブ投稿に記載されている手順を必ず実行し、問題が解決しない場合はお知らせください。 Re: RW612 FlexSPI PORTB1 access こんにちは、ローマン。 ご協力とご協力に感謝いたします。上記の例をプロジェクトに統合する過程で、次の問題が発生しました。メインから関数「 __RAMFUNC(SRAM) status_t BOARD_InitPsRam(void) 」を呼び出すと、コードがサイレントにクラッシュします。 リンカーファイル（main_data.ldt、main_txt.ldt および noinit_noload_section.ldt)board.cをコピーするファイル？BOARD_InitPsRam が RAM に正しくコピーされなかったためにコードがクラッシュしたのではないかと思います。 お時間を割いてご協力いただき、改めて感謝申し上げます。 Re: RW612 FlexSPI PORTB1 access この例は私のボードでは動作します。ご協力ありがとうございます。 Re: RW612 FlexSPI PORTB1 access こんにちは@khalidL 、お元気ですか。 アプリケーション コード ハブには、外部 NOR フラッシュからの XIPに関する例があります。共有されたリンクからサンプルをテストして、プロジェクト要件に適合するかどうかをお知らせください。 プロジェクトを MCUXpresso IDE にインポートするには、「アプリケーション コード ハブからインポート」オプションをクリックします。(このサンプルには SDK バージョン 2.16.00 が必要です) アプリケーション コード ハブ ウィンドウに入ったら、サンプルの名前 (外部 NOR フラッシュからの XIP およびマルチポート FlexSPI モジュールを使用した外部 pSRAM の構成) を検索し、それを選択して「Github リンク」をクリックし、「次へ >」ボタンが使用できるようになるまで待ちます。 「次へ > 」ボタンをクリックしたら、手順に従って Git リポジトリからプロジェクトをインポートします。最後に、プロジェクトがワークスペースで使用できるようになると、セットアップでフラッシュしてテストできるようになります。 これが役に立つかどうか教えてください。

i.MX RT700 eIQ Neutron NPU 实验室指南 这些实验室指南提供了分步说明，说明如何制作量化的 TensorFlow Lite 模型，并使用 e IQ Neutron SDK 中的中子转换工具将模型转换成在 i.MX RT700 设备上 的 eIQ Neutron NPU 上运行。适用于 i.MX RT700 的 eIQ Neutron NPU 实验指南 文档 重点介绍使用 eIQ Neutron SDK 中的中子转换器工具转换模型，然后将转换后的模型导入 eIQ mcuxPresso SDK 示例。有 VSCode、GCC 和 MCUXpresso IDE 实验室 。 这些实验室旨在在 i.MX RT700 EVK 上运行，但同样的概念也可以应用于 MCX N 主板，类似于 MCX N eIQ Neutron NP U 实验室。您还可以查阅《TFLM 入门指南》，了解如何使用自己的模型和数据进行推理。 此外，请务必查看AN14700 - i.MX RT700 eIQ Neutron NPU Enablement and Performance，其中详细介绍了 i.MX RT700 上的 eIQ Neutron N3-64 NPU。 --- 2026 年 4 月末更新，适用于 MCUXpresso SDK 26.03 和 eIQ Neutron SDK 3.1.0 实践培训

2015 年飞思卡尔杯 EMEA 球队名单 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 截至 2014 年 11 月 17 日，已有 159 支球队注册参加 2015 年飞思卡尔杯欧洲、中东和非洲赛区比赛 （见附件） 团队名称以 INNOV 开头的团队为创新挑战团队 未举办飞思卡尔杯资格赛的国家的队伍可以自由选择参加比赛的地点。请联系Flavio Stiffan以确保您的选择被记录在案。

Using TWR-SER2 with TWR-K70F120M for Ethernet TWR-K70F120M running MQX and RTCS can work with the Dual Phy on TWR-SER2. Below I list the modifications I did to the default BSP: 1) I add phy_dp83xxx.c and phy_dp83xxx.h to the bsp_twrk70f120m build project. These files are with MQX in /mqx/source/io/enet/Phy 2) I modify the BSP to use DP83xxx PHY for the Ethernet MACNET: in the /mqx/source/bsp/twrk70f120m/init_enet.c: #include "phy_dp83xxx.h" const ENET_IF_STRUCT ENET_0 = {      &MACNET_IF,      //&phy_ksz8041_IF,      &phy_dp83xxx_IF,      MACNET_DEVICE_0,      MACNET_DEVICE_0,      BSP_ENET0_PHY_ADDR,      BSP_ENET0_PHY_MII_SPEED }; 3) MDIO line requires an external pull up resistor, per DP83849I Data sheet. As I didn't have one at the moment, I enable internal pull up on MCU pin PTB0. in the /mqx/source/bsp/twrk70f120m/init_gpio.c: //pctl->PCR[0] = PORT_PCR_MUX(4) | PORT_PCR_ODE_MASK; /* PTB0, RMII0_MDIO/MII0_MDIO   */ /* PTB0, RMII0_MDIO/MII0_MDIO   */ /* internal pull up enabled on MDIO */ pctl->PCR[0] = PORT_PCR_MUX(4) | PORT_PCR_ODE_MASK | PORT_PCR_PE_MASK | PORT_PCR_PS_MASK; With these changes, the RTCS applications work over TWR-SER2 Dual PHY channel A. On TWR-SER2, J8 and J9 are un-shunted, SW1 = 11000000, SW2 = 10100000 on TWR-K70F120M, J18 is configured to disable 50 MHz OSC, as I use 50 MHz clock source from TWR-SER2 U504 50 MHz output. This clock is used to provide reference clock for the MCU (EXTAL), as well as for the Dual PHY X1 input (RMII reference clock). Real-Time TCPIP Communications Suite Re: Using TWR-SER2 with TWR-K70F120M for Ethernet Hi Hafiz, I have successfully used TWR-SER and TWR-SER2 cards with MQX4.1 Ethernet applications for the TWR-K70F120M independently (i.e. only using one tower serial card at a time and not using both cards simultaneously). Both TWR-SER and TWR-SER2 are running RMII and using the clock source from the respective TWR-SER(2) card to clock both the Ethernet PHY and the MCU which synchronizes the clock domains. I can just swap the cards and run the same application code. Note that when using the TWR-SER2 card I am only using one of the Ethernet ports ETH_A/J12. Regards, David Re: Using TWR-SER2 with TWR-K70F120M for Ethernet Hi I had made it work on BSP for TWR-K53N512, besides jumper settings listed above, I just applied changes mentioned in step 3. Thanks and Best Regards, Kan Re: Using TWR-SER2 with TWR-K70F120M for Ethernet Hi I had successfully run my Ethernet Driver on TWR-SER board for TWR-K70F120M but not working on TWR-SER2. 1. Is Ethernet Device in Single/Dual RMII mode is supported on TWR-SER2 board for TWR-K70F120M?  According to this link, (Line: 241) it is not supported? 2. If supported, then is there any change in signal settings like (MDC, MDIO, CRS_DV, RXDn, RXErr, TXDn, TXEN and RMII_REF_CLK) as compared to TWR-SER board? Regards

Example S32K14x SRAM ECC Injection ******************************************************************************** Detailed Description: This example shows SRAM ECC injection. By default, a double-bit ECC error is injected on read access of a location in SRAM_U region. This can be changed with the SRAM_U and DOUBLE_BIT macros. The errors can be detected by both the ERM and MCM modules and the corresponding interrupts can be called. Although only ERM is needed, for demonstration purposes, the MCM interrupt is enabled as well with a lower priority than the ERM interrupts. The ERM interrupts that are called first disable the injection mechanism so that subsequent errors can not be detected during a stack read access. The default S32 Design Studio start_up file copies the vector table to the SRAM_L region. To be able to inject ECC errors in this SRAM region and call the interrupts, the copying is disabled by __flash_vector_table__ symbol  declared in the start_up.h file and defined in the S32K144_64_flash linker file. -------------------------------------------------------------------------------------------- Test HW: S32K144EVB-Q100 MCU: S32K144 0N57U Debugger: S32DSR1 Target: internal_FLASH ********************************************************************************

恩智浦的xEV能源管理解决方案 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 中国预计到2020年，每家汽车制造商将生产和销售12%的零排放电动汽车，大城市将禁止经典内燃机汽车，汽车制造商将以更快的速度推出新型电动汽车。本次会议将概述影响电动汽车市场的主要力量，描述主要的架构方法和系统组件，以及这对恩智浦具有哪些增长潜力。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 中国预计到2020年，每家汽车制造商将生产和销售12%的零排放电动汽车，大城市将禁止经典内燃机汽车，汽车制造商将以更快的速度推出新型电动汽车。本次会议将概述影响电动汽车市场的主要力量，描述主要的架构方法和系统组件，以及这对恩智浦具有哪些增长潜力。

AUT-N1773 - 安全 V2X 简介 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 鉴于美国政府准备在美国强制实施车对车通信，汽车业正加紧推出支持此项专用短程通信技术的汽车。 我们来看看这将为道路使用者带来什么好处，ITS-G5标准如何在全球各地部署，汽车业在引入这项技术时面临的挑战以及恩智浦在这一部署中的领导作用。 观看视频演示 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 鉴于美国政府准备在美国强制实施车对车通信，汽车业正加紧推出支持此项专用短程通信技术的汽车。 我们来看看这将为道路使用者带来什么好处，ITS-G5标准如何在全球各地部署，汽车业在引入这项技术时面临的挑战以及恩智浦在这一部署中的领导作用。 观看视频演示 安全互联汽车和自动化汽车

INS-N1981 Wireless MCU Overview As the Smart Home starts to gather momentum, a number of competing Wireless Communication standards are fighting for dominance. With ZigBee® now becoming dominant in the low-power networking market, there is no surprise that two new low power technology Thread and Bluetooth® Low Energy with the new Mesh capability are both trying to enter this market to get a piece of the cake. Moreover competing IoT platforms from the Thread Group (Google/Nest), Allseen Alliance (Qualcomm), Apple's Homekit, the Open Interconnect Consortium (Intel) and many others are creating even more confusion. So in this confusing array of Wireless Communication standards and Iot platforms, what are the main features of each and what does it means for NXP? This session will provide an overview of these Wireless connectivity standards and IoT platforms, their capabilities, and their implication for NXP IoT. Watch Video Presentation As the Smart Home starts to gather momentum, a number of competing Wireless Communication standards are fighting for dominance. With ZigBee® now becoming dominant in the low-power networking market, there is no surprise that two new low power technology Thread and Bluetooth® Low Energy with the new Mesh capability are both trying to enter this market to get a piece of the cake. Moreover competing IoT platforms from the Thread Group (Google/Nest), Allseen Alliance (Qualcomm), Apple's Homekit, the Open Interconnect Consortium (Intel) and many others are creating even more confusion. So in this confusing array of Wireless Communication standards and Iot platforms, what are the main features of each and what does it means for NXP? This session will provide an overview of these Wireless connectivity standards and IoT platforms, their capabilities, and their implication for NXP IoT. Watch Video Presentation Insight & Innovation