将 CodeWarrior 和 PEmicro 多链路连接至 MCU MKL03Z16VFK4R 您好， 我有 MCU MKL03Z16VFK4R，需要在 winXP 上使用 P 语言编程。EmicroMultilink Universal。根据我收集到的信息，CodeWarrior 10.6 支持 WinXP。 能否共享 CodeWarrior 10.6 软件安装程序？ 或者，您有其他支持 winXP 的软件吗？ 谢谢 Re: CodeWarrior and PEmicro Multilink to MCU MKL03Z16VFK4R 你好@Chalearmrat 感谢您的来信。 没有可用的 10.6 Code Warrior 安装程序你可以查看 CodeWarrior 下载中提供的不同版本的 CodeWarrior | 恩智浦半导体 Kinetis 的推荐版本是 CodeWarrior for MCUs 11.1（可用于 Windows 11），但不包括对 KL03 的支持。 carlos_o_0-1778783252765.pngcarlos_o_0-1778783252765.png MCUXpresso IDE 支持 KL0x 系列，SDK 可从MCUXpresso SDK Builder下载。 carlos_o_1-1778783488621.pngcarlos_o_1-1778783488621.png Re: CodeWarrior and PEmicro Multilink to MCU MKL03Z16VFK4R 您好， CodeWarrior 10.6 版本比较老旧，官方安装程序可能已经无法轻易获取。对于采用 PEmicro Multilink Universal 的 MKL03Z16VFK4R，我建议查看 NXP 存档的 CodeWarrior 下载和 PEmicro 的旧版软件/工具，以确认其与 Windows XP 的兼容性。如果您无法访问安装程序，联系 NXP 或 PEmicro 支持部门并提供确切的 MCU 和调试器型号，是获取受支持的旧版软件包的最安全方法。

Timer triggers DMA transfer Hello, I'm currently working with an MCXN947 microcontroller. I'm trying to trigger a DMA transfer into a sample buffer via a CTIMER match interrupt. The idea is to write into the sample buffer the state of a GPIO register (specifically the input values of some pins) via DMA at every x timer intervals (specifically every 10 us). I can confirm that my GPIO pin is correctly configured as an input. I can confirm that my timer is working correctly and triggering a match at every 10 us. I can confirm that my DMA transfers are working correctly because the buffer gets filled up with values. I can confirm that the source address (GPIO PDIR reg) is correctly set in the DMA configuration. I can confirm that my destination address is also correctly set in the DMA configuration as it is always in between the start and end address of my buffer (meaning it increments and wraps around correctly). But for some reason, the wrong values are being copied into the buffer. I can see in my debugger that the value of the register I'm trying to transfer is 0x00020000 (pin 17 is high, the rest are low). However, my buffer is only being filled with 0s. It's a uint32_t type buffer of 512 elements initialized all at 0xFF. As the DMA transfers increment, the whole buffer progressively gets filled with 0x0 and not the expected value of 0x00020000 (which never changes - pin 17 is always high). Do you have any idea what causes this? Or if I'm possibly missing something? Here are my driver configurations: Timer: CTIMER0 kCTIMER_Match_1 CTIMER0_IRQn (triggering callback on interrupt is optional but I use it in my code for debugging purposes) DMA: DMA0 kDma0RequestMuxCtimer0M1 kINPUTMUX_Ctimer0M1ToDma0Ch8Ena EDMA_0_CH8_IRQn (triggering callback on interrupt is optional but I use it in my code for debugging purposes) GPIO: GPIO3 PORT3 Pin 17 Here are the states of the registers right before I start sampling reg_gpio3.pngreg_gpio3.pngreg_gpio3.pngreg_gpio3.pngreg_gpio3.png reg_port3.pngreg_port3.pngreg_port3.pngreg_port3.pngreg_port3.png reg_edma0_ch8.pngreg_edma0_ch8.pngreg_edma0_ch8.pngreg_edma0_ch8.pngreg_edma0_ch8.png reg_inputmux0_dma.pngreg_inputmux0_dma.pngreg_inputmux0_dma.pngreg_inputmux0_dma.pngreg_inputmux0_dma.png reg_inputmux0_timer.pngreg_inputmux0_timer.pngreg_inputmux0_timer.pngreg_inputmux0_timer.pngreg_inputmux0_timer.png reg_ctimer0.pngreg_ctimer0.pngreg_ctimer0.pngreg_ctimer0.pngreg_ctimer0.png             MCXN Re: Timer triggers DMA transfer Hello @jabitbe2_jcplc  Could you please share your project with us? I would like to try to reproduce the issue and investigate it on my side. Thank you. Best Regards, Alice Re: Timer triggers DMA transfer Hello, Due to IP I cannot send you my whole project. However, I can give you a c file that contains my setup in a little application. The GPIO, DMA and TIMER configurations are the same I have on my side. The file is in attachment. Re: Timer triggers DMA transfer Hello @jabitbe2_jcplc  The MCXN947 supports TrustZone and security attribution control. If the access originates from a security domain that does not match the pin's security configuration, read and write operations to the corresponding GPIO registers may be ineffective. Could you please verify whether the GPIO3 Pin 17 corresponding bit is configured to allow Non-Secure access and test again? If the bit is currently configured as Secure-only, the unexpected GPIO behavior may be related to the TrustZone security settings. Thank you. BR Alice

SE050 セキュアエレメントと i.MX 8M PlusおよびYocto Linuxとの統合 チームの皆さん、こんにちは。 私は8M Plus EVKとNXP SE050セキュアエレメント i.MX 使っています。SE050をLinuxで動かしたいと思っています。i.MX プラットフォーム用のYoctoビルドシステムを使って。 SE050を8M PlusおよびYoctoと統合・テストするための統合・移植ドキュメント、アプリケーションノート、または参考実装 i.MX 教えていただけますか? NXPのPlug & Trustミドルウェアリポジトリに出会い、i.MX6ULとi.MX8MQのLinuxサポートについて言及しています: https://github.com/NXP/plug-and-trust また、既存の実装が i.MX 8M Plusで直接利用できるのか、それとも特にI²CインターフェースやYocto統合に関してプラットフォーム固有の移植が必要なのかも知りたいです。 ありがとう、 ローハン SE050 Re: SE050 Secure Element Integration with i.MX 8M Plus and Yocto Linux こんにちは、 @rohannathi さん。 Plug & TrustミドルウェアのGitHubミニパッケージは Linux向けのサブセットです。nxp.com/se050 のフルパッケージは、例、ツール、完全なドキュメントを含むため、開発に推奨されます。 i.MX 8M Plusは既存の iMXLinux ホストターゲットと完全に互換性があり、i.MXファミリ特有の移植は不要です。 NXPのリファレンス設計であるNavQPlus(8MPNAVQ)は、同じ i.MX 8M Plus SoC(i.MX 8M Plus EVKと同じSOM)をベースにし、オンボードのSE050セキュア要素とYocto LinuxおよびROS2イネーブルメントを備えています。これはSE050 + i.MX 8M Plus + Yoctoの最も近いハードウェアリファレンスであり、そのBSP/Yoctoレイヤー構成は直接的なガイドとして利用できます。 詳細については、 https://community.nxp.com/t5/Secure-Authentication-Knowledge/Integrating-EdgeLock-SE05X-to-FRDM-IMX91/ta-p/2138152を参照してください。 お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

リップルによってVDDが下限値を下回った場合のP2020デバイスの状態/動作 リップルなどでVDDが下限電圧を下回った場合のP2020プロセッサの状態や挙動について知りたいです。 P2020ハードウェア仕様書（文書番号：P2020EC）の表3「推奨動作条件」によると、VDD、AVDD_xxxx、SVDD_SRDS、XVDD_SRDSの推奨値は「1.05 ± 50 mV」です。つまり、下限電圧は1.00Vであるということです。 リップル電圧の下限が指定された最低電圧1.00Vを下回った場合、P2020のデバイスの状態や挙動について教えていただけますか? （例えば、VDDの中心電圧が1.01Vであっても、リップル電圧の下限値は0.99V（1.00V未満）になる。） VDDの中心電圧が1.00V以上であれば、デバイスの正常な動作に問題はありませんか？リップル電圧があっても、動作不良や損傷のリスクはありますか？ お知らせ下さい。 事前に感謝いたします。 Re: P2020 device status/behavior if VDD falls below lower limit due to ripple こんにちは、   P2020ハードウェア仕様書（文書番号：P2020EC）の表3では、VDD、AVDD_xxxx、SVDD_SRDS、およびXVDD_SRDSが1.05±50mVと規定されており、これは有効な動作範囲が1.00V（最小）から1.10V（最大）であることを意味します。これは推奨される動作条件であり、絶対的な最大定格ではありません。 重要な点は、規定されている最小電圧1.00Vは、デバイスのピンにおける瞬時電圧に適用されるものであり、DC中心点のみに適用されるものではないということです。リップルはデバイスが実際に受ける電圧の一部であり、デバイスは規定の範囲内でのみテストおよび特性評価されます。 リップル電圧が1.00Vを下回った場合のリスク 中心（DC）電圧が1.00V以上であっても、リップルトラフが1.00Vを下回ると、推奨動作条件外の動作となります。NXPのこの点に関する立場は、QorIQおよび関連プロセッサファミリ全体で一貫して述べています。 機能的・運用上のリスク:VDDが一時的に最小値を下回ると、プロセッサ内部のロジックが十分な駆動強度やタイミング余裕を持っていない可能性があります。これは以下のように現れることがあります: 命令の実行が間違っています データ破損（例：メモリ比較エラー） 重要なタイミングパスにおける予測不可能な動作 関連するQorIQプロセッサ(P1013)を使った直近のNXPケースでは、「[デバイス]を[限界に近い電圧]で動作させると機能上の問題が発生するリスクがあります。なぜなら、この値はお客様の設定設定ポイントを表すからです。通常の電圧許容範囲、リップル、または過渡的な挙動により、電圧がこのレベルを超えたり、下回ったりする可能性があります。」 「中心電圧 ≥ 1.00 V」という条件は不十分です。デバイスは供給電圧を「平均化」しません。デジタルロジックは瞬時電圧に基づいて動作する。リップルの谷間（例えば、あなたの例では0.99V）の間は、たとえスイッチングサイクルのほんの一部であっても、デバイスは実際に仕様を下回る動作をしています。これにより内部フリップフロップでセットアップやホールドタイム違反が発生し、機能エラーを引き起こすことがあります。 小さな短時間の変動では、永続的な損傷は想定されません。小さなリップル変動（例えば、一般的なスイッチング周波数で最小値より10mV低い場合）では、デバイスに永続的な物理的損傷が発生する可能性は低いです。電圧は依然として絶対最大定格の下限値を十分に上回っています。しかし、機能的正確性は保証されておらず、NXPはこの条件下での動作をサポートしたり特徴付けしたりしていません。 信頼性／耐久性：特にP2020の場合、電圧範囲の下限付近で動作させる方が（上限付近で動作させるよりも）、一般的には最大電圧を超えて動作させるよりも長期的な信頼性の問題は少ない。ただし、仕様外の条件下での繰り返しまたは継続的な動作は推奨もサポートもされません。 NXPの標準ガイダンスは、複数のQorIQおよび関連するプロセッササポートケースで確認されており、以下の通りです。 「仕様外の機器の使用は推奨もサポートもされていません。」 通常の動作時、デバイスのピンにおける電圧波形全体（リップルを含む）は、規定の1.00V～1.10Vの範囲内に収まっていなければならない。   よろしくお願いします。

EMI/EMC適合証明書および試験報告書 チームの皆さん、こんにちは。 下記の15W受信キットがEMI/EMC準拠かどうか、確認していただけませんか? 部品番号：WPR1500-HV 説明 - 高電圧ワイヤレス充電レシーバ よろしくお願いいたします。 パース・バヴサル Re: EMI EMC Compliance certificate and test report こんにちは、セレステさん。 ご返信ありがとうございます。 検査結果と検査結果の共有を手伝っていただけませんか?そこで、このEVKに対して基本的なEMI/EMCテストが行われているかを確認します。 よろしくお願いいたします。 パース・バヴサル Re: EMI EMC Compliance certificate and test report こんにちは、 @P907 さん。 投稿ありがとうございます。このEVKは主に評価用であり、CE規格に準拠するための基本的なEMI/EMC試験に合格する必要があります。一般的に、当社のソリューションと市販の一般的なソリューションの間に大きな違いはありません。 お役に立てば幸いです。 BR セレステ Re: EMI EMC Compliance certificate and test report こんにちは、 @P907 さん。 もちろん、あなたと共有できます。ただし、これらの資料はコミュニティなどの公開プラットフォームでの共有には適していません。後ほど、プライベートメールでお送りします。受信トレイをこまめに確認してください。 よろしくお願いいたします。 セレステ Re: EMI EMC Compliance certificate and test report こんにちは、セレステさん。 ご依頼いただいたEVMのEMI/EMC試験報告書をご共有いただきありがとうございます。 よろしくお願いいたします。 パース・バヴサル

SE050 Secure Element Integration with i.MX 8M Plus and Yocto Linux Hi Team, I am working with  i.MX 8M Plus EVK and an NXP SE050 Secure Element. I would like to get the SE050 up and running with Linux using the Yocto build system for the i.MX platform. Could you please share any available integration/porting documentation, application notes, or reference implementations for integrating and testing the SE050 with i.MX 8M Plus and Yocto? I came across the NXP Plug & Trust middleware repository, which mentions Linux support for i.MX6UL and i.MX8MQ: https://github.com/NXP/plug-and-trust I would also like to understand whether this existing implementation can be directly used with i.MX 8M Plus, or if any platform specific porting is required, particularly for the I²C interface and Yocto integration. Thanks, Rohan SE050 Re: SE050 Secure Element Integration with i.MX 8M Plus and Yocto Linux Hi @rohannathi , The Plug & Trust middleware GitHub mini-package is a subset for Linux use; the full package at nxp.com/se050 is recommended for development as it includes examples, tools, and complete documentation. The i.MX 8M Plus is fully compatible with the existing iMXLinux host target — no i.MX-family-specific porting is needed. There is an NXP reference design — the NavQPlus (8MPNAVQ) — that is based on the same i.MX 8M Plus SoC (identical SOM to the i.MX 8M Plus EVK) and features an onboard SE050 secure element, with Yocto Linux and ROS2 enablement. This is the closest available hardware reference for SE050 + i.MX 8M Plus + Yocto, and its BSP/Yocto layer configuration can be used as a direct guide. You may refer to https://community.nxp.com/t5/Secure-Authentication-Knowledge/Integrating-EdgeLock-SE05X-to-FRDM-IMX91/ta-p/2138152 for more details. Hope that helps, Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

lpc4078 eeprom page erase clarification required I'm using an LPC4078 and MCUXpresso and experimenting with storing values in Eeprom. I want to write a few bytes in the middle of a page without clearing the whole page. Looking in the datasheet, it says that after writing the data to be written int he page register, it still has to be programmed into non-volatile memeory and that is done with the erase/program operation. Does the Erase/Program operation erase the whole page or just the area of the page I have new data for, and how does it know? - the address setting for Erase/Program ignores the 6 lsbs so it only knows the page. The UM10562.pdf isn't explicitly clear on this matter. Thanks Alex Re: lpc4078 eeprom page erase clarification required I attach a workspace with the mentioned project in it. I ran it on an LPC4078 using a lpc-link2 debugger. (I couldn't be bothered to get semihosting to work, so I used breakpoints and inspected the data) Re: lpc4078 eeprom page erase clarification required Hello @alex_conway  For LPC4078 EEPROM, the minimum erase/program unit is one page (64 bytes). Therefore, each erase/program operation will erase the entire page. If you want to write only a few bytes, please first read the whole page, then modify the required bytes, and finally perform an erase/program operation on the page. You can test this on your side.   Thank you.   BR Alice Re: lpc4078 eeprom page erase clarification required Hi Alice, My experiments demonstrate otherwise: I wrote a small program using the lpc_board_ea_devkin_4088 library and the periph_eeprom demo project to start me up. I erase a page of Eeprom and read it back. To my surprise the results are all '\0' instead of 0xFF Then I write 'ABCDEFG\0' to address 0 in that page and read the page back. I receive 'ABCDEFG\0' Then I write 'ABCDEFG\0' to address 7 in that page and read the page back. I receive 'ABCDEFGABCDEFG\0' This is all as expected except for two things: 1. after erasing the eeprom reads 0 2. looking at the implementation of Chip_EEPROM_Write() is can seem no read-modify-erase-write sequence. There is only Chip_EEPROM_WritePageRegister followed by Chip_EEPROM_EraseProgramPag. This is why I asked the question. Thanks Alex Re: lpc4078 eeprom page erase clarification required I've got semihosting to work after adding a newline to all my printf strings! Also clearer evidence of everything I have said: Erasing sets Eeprom to 0x00 The code does not perform a read-modify-erase-write sequence, just erase-write. The LPC4078 seems to only erase the locations that are written to when erasing. I would really like clarification on this. Thanks Alex Re: lpc4078 eeprom page erase clarification required Despite "Escalating" whatever that means, there has been no further response from NXP on this. I still need clarification.  Re: lpc4078 eeprom page erase clarification required Hi @alex_conway  Thanks for your reply, and I apologize for the delayed response. Unfortunately, our community script was previously broken, so customer replies did not trigger case update notifications in our internal system. I sincerely apologize for the delay. Regarding the EEPROM on the LPC4078, according to the User Manual, all communication with the actual EEPROM block is performed through a 64-byte page buffer. Therefore, please make sure your EEPROM operations follow the requirements described in the User Manual. Alice_Yang_1-1788510957201.pngAlice_Yang_1-1788510957201.pngAlice_Yang_1-1788510957201.png Alice_Yang_0-1788510947469.pngAlice_Yang_0-1788510947469.pngAlice_Yang_0-1788510947469.png At this point, we cannot determine whether there is an issue unless the EEPROM is being accessed according to these requirements. Thank you. BR Alice Re: lpc4078 eeprom page erase clarification required Hi Alice, I'm using the functions in eeprom_17xx_40xx.h and eeprom_17xx_40xx.c (provided by NXP and included in the project I attached) The Chip_EEPROM_Write() function calls the Chip_EEPROM_WritePageRegister() function followed by Chip_EEPROM_EraseProgramPage() The Chip_EEPROM_WritePageRegister()function sets the EEPROM Address using the Chip_EEPROM_SetAddr() function which takes care of shifting and blanking the lower 6 bits. Then the data bytes are written to the EEPROM write data register (WDATA) using the Chip_EEPROM_WriteData() function The Chip_EEPROM_EraseProgramPage() uses the Chip_EEPROM_SetAddr() function to set the page address, anables the erase/page-program bit and waits for programming to finish. I cannot see any code that reads the exisitng EEPROM data in the page to perform a page-read-modify-write. However, as demonstrated in my project, It appears that the EEPROM page erase does not erase the whole page, but only erases at the addresses with new data loaded into the write data register. Thanks Alex

S9KEAZN64AMLH FIT値の確認 本プロジェクトでは、MCU S9KEAZN64AMLHを選定しました。車両メーカーは、下図に示すようなチップの適合パラメータを必要とします。ご確認の上、ご返信をお願いいたします。サポートありがとうございます。 mengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.png Re: Confirmation of S9KEAZN64AMLH FIT value こんにちは、 @mengfanpeng さん、 投稿ありがとうございます。 この情報は、公共の場で共有するのに適していません。後ほど、プライベートメールでお送りします。 BR セレステ Re: Confirmation of S9KEAZN64AMLH FIT value 自動車用半導体半導体でFIT(Failures In Time)パラメータの要請(例えばNXP S9KEAZN64AMLH(Kinetis EAシリーズ、ARM Cortex-M0+)に対応する場合、NXPのような半導体メーカーは通常、標準部品データシート内で生のFITレートを直接公開しません。代わりに、これらの信頼性指標は業界標準(例えばAEC-Q100)によって管理され、NXP製品品質報告書(PQR)、AEC-Q100資格報告書、特定のお客様品質要求書(PQA)などの公式文書を通じて提供されます。 Re: Confirmation of S9KEAZN64AMLH FIT value FITは一般的なテストデータであり、NXPが社内で所有しています。OEMから関連データのリクエストがあった場合、そのデータはテスト環境に限定されているため、あくまで参考情報としてのみ提供されます。

P2020 device status/behavior if VDD falls below lower limit due to ripple I would like to know about status/behavior of P2020 processor in case VDD falls below lower limit voltage due to ripple etc. According to Table 3. Recommended Operating Conditions in P2020 Hardware Spec (Doc#: P2020EC), the recommended value for VDD, AVDD_xxxx, SVDD_SRDS and XVDD_SRDS is “1.05 ± 50 mV”. It means that the lower limit voltage is 1.00 V. Could you please let me know about possible P2020 device status/behavior if the lower limit of the ripple voltage falls below the specified minimum voltage of 1.00V ?  (For instance, center voltage of VDD = 1.01V, but the lower side of the ripple voltage goes 0.99V (below 1.00V)) Is there no problem for proper operation of the device if center voltage of VDD keeps higher or equal to 1.00V ? Will there be any operation/damage risks even with ripple voltage ? Please advise. Thank you in advance. Re: P2020 device status/behavior if VDD falls below lower limit due to ripple Hello,   The P2020 Hardware Spec (Doc#: P2020EC) Table 3 specifies VDD, AVDD_xxxx, SVDD_SRDS, and XVDD_SRDS as 1.05 ± 50 mV, meaning the valid operating range is 1.00 V (min) to 1.10 V (max). This is a Recommended Operating Condition, not an Absolute Maximum Rating. The critical point is: the specified minimum voltage of 1.00 V applies to the instantaneous voltage at the device pins — not just the DC center point. Ripple is part of the actual voltage the device sees, and the device is tested and characterized only within the specified range. Risks When Ripple Dips Below 1.00 V Even if the center (DC) voltage is at or above 1.00 V, allowing the ripple trough to fall below 1.00 V constitutes operation outside the Recommended Operating Conditions. NXP's position on this, consistent across QorIQ and related processor families, is: Functional/Operational Risk: When VDD momentarily drops below the minimum, the processor's internal logic may not have sufficient drive strength or timing margin to operate correctly. This can manifest as: Incorrect instruction execution Data corruption (e.g., memory miscompare errors) Unpredictable behavior in critical timing paths A directly analogous NXP case involving a related QorIQ processor (P1013) confirmed: "There is a potential risk of functional issues when running [the device] at [a voltage near the limit], as this value represents the customer's configured set point. Normal voltage tolerance, ripple, or transient behavior could result in the voltage exceeding [or falling below] this level." The "Center Voltage ≥ 1.00 V" Argument Is Not Sufficient: The device does not "average" the supply voltage. Digital logic operates on instantaneous voltage. During the ripple trough (e.g., 0.99 V in your example), the device is genuinely operating below spec, even if only for a fraction of a switching cycle. This can cause setup/hold time violations in internal flip-flops, leading to functional errors. No Permanent Damage Expected for Small, Brief Excursions: For a small ripple excursion (e.g., 10 mV below the minimum, at typical switching frequencies), permanent physical damage to the device is unlikely — the voltage is still well above the absolute maximum ratings floor. However, functional correctness is not guaranteed, and NXP does not support or characterize operation in this condition. Reliability/Longevity: For the P2020 specifically, operating at the lower edge of the voltage range (rather than above it) is generally less of a long-term reliability concern than operating above the maximum. However, repeated or sustained operation outside spec is neither recommended nor supported. NXP's standard guidance, confirmed across multiple QorIQ and related processor support cases, is: "Operating devices outside of specification is neither recommended nor supported." The entire voltage waveform — including ripple — must remain within the specified 1.00 V to 1.10 V window at the device pins during normal operation.   Regards

P2020 设备在纹波导致 VDD 低于下限时的状态/行为 我想了解当 VDD 由于纹波等原因降至下限电压以下时，P2020 处理器的状态/行为。 根据 P2020 硬件规范（文档编号：P2020EC）中的表 3. 推荐工作条件，VDD、AVDD_xxxx、SVDD_SRDS 和 XVDD_SRDS 的推荐值为“1.05 ± 50 mV”。这意味着下限电压为 1.00 V。 请问当纹波电压下限低于规定的最小电压1.00V时，P2020设备可能出现的状态/行为是什么？ （例如，VDD 的中心电压为 1.01V，但纹波电压的下限为 0.99V（低于 1.00V）） 如果VDD中心电压保持在1.00V或更高，这是否会影响设备的正常工作？即使存在纹波电压，是否也会有操作/损坏风险？ 请指教。 提前谢谢您。 Re: P2020 device status/behavior if VDD falls below lower limit due to ripple 你好，   P2020 硬件规范（文档编号：P2020EC）表 3 将 VDD、AVDD_xxxx、SVDD_SRDS 和 XVDD_SRDS 指定为 1.05 ± 50 mV，这意味着有效工作范围为 1.00 V（最小值）至 1.10 V（最大值）。这是推荐运行条件，并非绝对最大额定值。 关键在于：规定的最小电压 1.00V 适用于器件引脚的瞬时电压，而不仅仅是直流中心点。纹波是设备实际电压的一部分，设备的测试和特性分析仅在规定的范围内进行。 当 Ripple 跌破 1.00 V 时的风险 即使中心（直流）电压达到或超过 1.00 V，允许纹波谷值低于 1.00 V 也构成在推荐工作条件之外的操作。恩智浦半导体（NXP）对此的立场，在QorIQ及相关处理器系列中是一致的： 功能/运行风险：当 VDD 瞬间低于最低值时，处理器的内部逻辑可能没有足够的驱动强度或时序裕量来正常工作。这可能表现为： 指令执行错误 数据损坏（例如，内存比较错误） 关键时序路径中出现不可预测的行为 NXP 的一个直接类似的案例涉及一款相关的 QorIQ 处理器 (P1013)，该案例证实： “当[该设备]在[接近极限电压]下运行时，存在出现功能问题的潜在风险，因为该值代表客户配置的设定点。正常的电压容差、纹波或瞬态行为都可能导致电压超过[或低于]该水平。” “中心电压≥1.00V”的论点并不充分：该设备不会对电源电压进行“平均”。数字逻辑电路依靠瞬时电压运行。在纹波谷（例如，您示例中的 0.99 V）期间，即使只是开关周期的一小部分，该器件也确实在低于规格的条件下运行。这会导致内部触发器建立/保持时间违例，从而导致功能错误。 对于小幅、短暂的波动，预计不会造成永久性损坏：对于小幅纹波波动（例如，在典型开关频率下，低于最小值 10 mV），不太可能对器件造成永久性物理损坏——电压仍然远高于绝对最大额定值下限。但是，功能正确性无法保证，NXP 不支持或描述在这种情况下运行的情况。 可靠性/寿命：对于 P2020 而言，在电压范围的下限（而不是上限）运行通常比在上限以上运行的可靠性问题要小。但是，不建议也不支持在超出规格范围的情况下反复或持续操作。 NXP 的标准指导原则（已在多个 QorIQ 及相关处理器支持案例中得到证实）是： “不建议也不支持在规格范围外操作设备。” 在正常工作期间，器件引脚上的整个电压波形（包括纹波）必须保持在规定的 1.00 V 至 1.10 V 范围内。   此致

Confirmation of S9KEAZN64AMLH FIT value The project has selected MCU  S9KEAZN64AMLH. Now, the vehicle manufacturer requires the chip FIT parameters, as shown in the figure below. Please help confirm and reply. Thank you for your support. mengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.png Re: Confirmation of S9KEAZN64AMLH FIT value Hello @mengfanpeng , Thanks for your post. This information is not suitable for sharing in a public community. I will send it to you via private email shortly. BR Celeste Re: Confirmation of S9KEAZN64AMLH FIT value FIT is general test data and own by NXP internally. If OEM request related data，it is just for reference since the data is limited to test enviroment. Re: Confirmation of S9KEAZN64AMLH FIT value When dealing with automotive semiconductor requests for FIT (Failures In Time) parameters—such as for the NXP S9KEAZN64AMLH (Kinetis EA series, ARM Cortex-M0+)—semiconductor manufacturers like NXP typically do not publish raw FIT rates directly inside standard component datasheets. Instead, these reliability metrics are governed by industry standards (like AEC-Q100) and are provided via official documents such as NXP Product Quality Reports (PQRs), AEC-Q100 qualification reports, or specific customer quality requests (PQAs).

lpc4078 EEPROMページ消去に関する説明が必要 私はLPC4078とMCUXpressoを使用して、EEPROMに値を保存する実験を行っています。 ページ全体を消去せずに、ページの中央に数バイトのデータを書き込みたい。 データシートを見ると、ページレジスタに書き込むデータを書き込んだ後、さらに不揮発性メモリにプログラムする必要があり、それは消去/プログラム操作によって行われると記載されている。 消去／プログラム操作は、ページ全体を消去するのか、それとも新しいデータが格納されているページ領域だけを消去するのか、また、どのようにしてそれを判断するのか？- 消去/プログラム用のアドレス設定では、6 つの lsb が無視されるため、ページのみが認識されます。 UM10562.pdfには、このマターについて明確な記載はありません。 よろしくお願いします。 アレックス Re: lpc4078 eeprom page erase clarification required 該当プロジェクトを含むワークスペースを添付します。LPC4078上でlpc-link2デバッガを使って実行しました。 （セミホスティングを動作させるのが面倒だったので、ブレークポイントを使ってデータを検査しました。） Re: lpc4078 eeprom page erase clarification required こんにちは、 @alex_conway さん。 LPC4078 EEPROMの場合、最小消去/書き込み単位は1ページ（64バイト）です。したがって、消去／プログラム操作を行うたびに、ページ全体が消去されます。数バイトだけ書き込みたい場合は、まずページ全体を読み込み、次に必要なバイトを変更し、最後にページに対して消去／書き込み操作を実行してください。そちら側でもテストしてみてください。   よろしくお願いします。   BR アリス Re: lpc4078 eeprom page erase clarification required こんにちは、アリスさん。 私の実験結果はそれとは異なることを示している。 まずは手始めに、lpc_board_ea_devkin_4088ライブラリとperiph_eepromデモプロジェクトを使って小さなプログラムを作成しました。 EEPROMの1ページを消去して、それを読み戻します。驚いたことに、結果は0xFFではなくすべて'\0'だった。 次に、そのページのアドレス0に「ABCDEFG\0」を書き込み、ページを読み戻します。「ABCDEFG\0」を受け取ります 次に、そのページのアドレス7に「ABCDEFG\0」を書き込み、ページを読み戻します。「ABCDEFGABCDEFG\0」を受け取ります これはすべて予想通りだったが、2点だけ例外があった。 1. EEPROMを消去した後、0を読み取る 2. Chip_EEPROM_Write() の実装を見ると、読み出し-変更-消去-書き込みのシーケンスがないように見えます。Chip_EEPROM_WritePageRegister と Chip_EEPROM_EraseProgramPag があるだけです。 だから私はこの質問をしたのです。 よろしくお願いします。 アレックス Re: lpc4078 eeprom page erase clarification required printf文字列にすべて改行を追加したら、セミホスティングがうまく動作するようになりました！また、私が言ったことすべてをより明確に裏付ける証拠もあります。 消去するとEEPROMが0x00に設定されます このコードは、読み取り→変更→消去→書き込みのシーケンスを実行せず、消去→書き込みのみを実行します。 LPC4078は、消去時に書き込みが行われた場所のみを消去するようです。 この点について、ぜひとも明確な説明をいただきたいです。 よろしくお願いします。 アレックス Re: lpc4078 eeprom page erase clarification required 「エスカレーション」という言葉が何を意味するにせよ、NXPからはこれに関してそれ以上の回答は得られていない。 まだ確認が必要です。 Re: lpc4078 eeprom page erase clarification required こんにちは、 @alex_conway さん。 ご返信ありがとうございます。返信が遅くなり申し訳ありません。 残念ながら、以前はコミュニティスクリプトが壊れていたため、お客様からの返信が内部システムでのCASE更新通知を発生させませんでした。遅れてしまい、誠に申し訳ございません。 LPC4078上のEEPROMに関しては、ユーザーマニュアルによると、実際のEEPROMブロックとの通信はすべて64バイトのページバッファを通じて行われます。したがって、EEPROM運用がユーザーマニュアルに記載された要件に従うことを必ず確認してください。 Alice_Yang_1-1788510957201.pngAlice_Yang_1-1788510957201.pngアリス_ヤン_1-1788510957201.png Alice_Yang_0-1788510947469.pngAlice_Yang_0-1788510947469.pngアリス_ヤン_0-1788510947469.png 現時点では、EEPROMがこれらの要件に従ってアクセスされない限り、問題があるかどうか判断できません。 よろしくお願いします。 BR アリス Re: lpc4078 eeprom page erase clarification required こんにちは、アリスさん。 私はeeprom_17xx_40xx.hの関数を使用しています。および eeprom_17xx_40xx.c（NXP社提供、添付プロジェクトに含まれています） Chip_EEPROM_Write() 関数は、Chip_EEPROM_WritePageRegister() 関数を呼び出し、続いて Chip_EEPROM_EraseProgramPage() 関数を呼び出します。 Chip_EEPROM_WritePageRegister()関数は、下位6ビットのシフトとブランキングを処理するChip_EEPROM_SetAddr()関数を使用してEEPROMアドレスを設定します。 次に、Chip_EEPROM_WriteData() 関数を使用して、データバイトが EEPROM 書き込みデータレジスタ (WDATA) に書き込まれます。 Chip_EEPROM_EraseProgramPage() 関数は、Chip_EEPROM_SetAddr() 関数を使用してページ アドレスを設定し、消去/ページ プログラム ビットを有効にして、プログラミングが完了するまで待機します。 ページ内の既存のEEPROMデータを読み込んでページを読み取って、ページを読み書き・修正・書き込みを行うコードは見当たりません。 しかし、私のプロジェクトで実証したように、EEPROMページの消去はページ全体を消去するのではなく、書き込みデータレジスタに新しいデータがロードされたアドレスのみを消去するようです。 よろしくお願いします。 アレックス

确认 S9KEAZN64AMLH FIT 值 该项目选择了 MCU S9KEAZN64AMLH。现在，车辆制造商需要芯片的 FIT 参数，如下图所示。请帮忙确认并回复。感谢您的支持。 mengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.pngmengfanpeng_0-1787884740955.png Re: Confirmation of S9KEAZN64AMLH FIT value 你好@mengfanpeng ， 感谢你的帖子。 这些信息不适合在公共社区分享。我稍后会通过私人邮件发送给你。 BR 塞莱斯特 Re: Confirmation of S9KEAZN64AMLH FIT value 在处理汽车半导体对 FIT（故障率）参数的要求时——例如 NXP S9KEAZN64AMLH（Kinetis EA 系列，ARM Cortex-M0+）——像 NXP 这样的半导体制造商通常不会在标准元器件数据手册中直接发布原始 FIT 率。相反，这些可靠性指标受行业标准（如 AEC-Q100）的约束，并通过官方文件（如 NXP 产品质量报告 (PQR)、AEC-Q100 认证报告或特定客户质量要求 (PQA)）提供。 Re: Confirmation of S9KEAZN64AMLH FIT value FIT 是通用测试数据，归 NXP 内部所有。如果OEM厂商要求提供相关数据，由于数据仅限于测试环境，因此仅供参考。

EMI EMC 合规性证书和测试报告 大家好， 请帮忙确认一下下面提到的15W接收器套件是否符合EMI/EMC标准。 零件号：WPR1500-HV 产品描述 - 高压无线充电接收器 此致， 帕尔特·巴夫萨尔 Re: EMI EMC Compliance certificate and test report 你好@P907 ， 感谢你的帖子。此EVK主要用于评估并通过基本的EMI/EMC测试，以符合CE标准。总的来说，我们的解决方案与市场上通用的解决方案之间并没有什么重大区别。 希望对您有所帮助。 BR 塞莱斯特 Re: EMI EMC Compliance certificate and test report 嗨， Celeste， 感谢您的回复。 能否请您帮忙分享一下测试报告及其结果？因此，我们将检查对这款 EVK 执行了哪些基本的 EMI/EMC 测试。 问候， 帕尔特·巴夫萨尔 Re: EMI EMC Compliance certificate and test report 你好@P907 ， 当然，我可以和你分享。但是，这些材料不适合在社区等公共平台上分享。我稍后会通过私人邮件发送给你。请留意您的收件箱。 此致， 塞莱斯特 Re: EMI EMC Compliance certificate and test report 嗨，Celeste， 感谢您分享所请求的EVM的EMI/EMC测试报告。 此致， 帕尔特·巴夫萨尔

EMI EMC Compliance certificate and test report Hi Team, Could you please help to check and confirm that below mentioned 15W receiver kit is EMI/EMC compliant. P/N: WPR1500-HV Description - High Voltage Wireless Charging Receiver Regards, Parth Bhavsar Re: EMI EMC Compliance certificate and test report Hello @P907 , Thanks for your post. This EVK is mainly for evaluation and pass basic EMI/EMC test to be CE compliance. In general there aren't any major different between our solution and general solution on market. Hope it helps. BR Celeste Re: EMI EMC Compliance certificate and test report Hi Celeste, Thank you for the reply. Could you please help us to share the test report and its results. So, from that we will check which are the basic EMI/EMC test is performed on this EVK. Regards, Parth Bhavsar Re: EMI EMC Compliance certificate and test report Hello @P907 , Of course, I can share them with you. However, these materials are not suitable for sharing on public platforms such as the Community. I will send them to you via private email shortly. Please keep an eye on your inbox. Regards, Celeste Re: EMI EMC Compliance certificate and test report Hi Celeste, Thank you for sharing EMI/EMC test report for the requested EVM. Regards, Parth Bhavsar

定时器触发DMA传输 你好， 我目前正在使用MCXN947微控制器。 我尝试通过 CTIMER 匹配中断触发 DMA 数据传输到采样缓冲区。 其思路是通过 DMA 每隔 x 个定时器间隔（具体来说是每隔 10 微秒）将 GPIO 寄存器的状态（具体来说是某些引脚的输入值）写入采样缓冲区。 我可以确认我的GPIO引脚已正确配置为输入。 我可以确认我的计时器工作正常，每 10 微秒触发一次比赛。 我可以确认我的 DMA 传输工作正常，因为缓冲区会被值填满。 我可以确认源地址（GPIO PDIR 寄存器）在 DMA 配置中已正确设置。 我可以确认我的目标地址在 DMA 配置中也设置正确，因为它始终位于缓冲区起始地址和结束地址之间（这意味着它可以正确递增和循环）。 但不知何故，错误的值被复制到了缓冲区中。我在调试器中看到，我尝试传输的寄存器的值为0x00020000 （引脚 17 为高电平，其余引脚为低电平）。但是，我的缓冲区只填充了0秒。这是一个 uint32_t 类型的缓冲区，包含 512 个元素，全部初始化为0xFF 。随着 DMA 传输的增加，整个缓冲区逐渐被0x0填充，而不是预期的0x00020000值（该值永远不会改变 - 引脚 17 始终为高电平）。 你知道这是什么原因造成的吗？或者我可能遗漏了什么？ 以下是我的驱动程序配置： 计时器： CTIMER0 kCTIMER_Match_1 CTIMER0_IRQn（中断触发回调是可选的，但我为了调试目的在我的代码中使用它） DMA： DMA0 kDma0RequestMuxCtimer0M1 kINPUTMUX_Ctimer0M1ToDma0Ch8Ena EDMA_0_CH8_IRQn（中断触发回调是可选的，但我为了调试目的在我的代码中使用它） GPIO： GPIO3 端口3 引脚 17 以下是开始采样之前寄存器的状态。 reg_gpio3.pngreg_gpio3.pngreg_gpio3.pngreg_gpio3.pngreg_gpio3.png reg_port3.pngreg_port3.pngreg_port3.pngreg_port3.pngreg_port3.png reg_edma0_ch8.pngreg_edma0_ch8.pngreg_edma0_ch8.pngreg_edma0_ch8.pngreg_edma0_ch8.png reg_inputmux0_dma.pngreg_inputmux0_dma.pngreg_inputmux0_dma.pngreg_inputmux0_dma.pngreg_inputmux0_dma.png reg_inputmux0_timer.pngreg_inputmux0_timer.pngreg_inputmux0_timer.pngreg_inputmux0_timer.pngreg_inputmux0_timer.png reg_ctimer0.pngreg_ctimer0.pngreg_ctimer0.pngreg_ctimer0.pngreg_ctimer0.png             MCX N Re: Timer triggers DMA transfer 你好， 由于IP限制，我无法将我的整个项目发送给您。不过，我可以给你一个包含我的设置的小应用程序的 c 文件。GPIO、DMA 和定时器配置与我这边的相同。文件已附上。 Re: Timer triggers DMA transfer 你好@jabitbe2_jcplc 您能否与我们分享一下您的项目？我想尝试重现这个问题，并在我这边进行调查。 谢谢！ 此致， 爱丽丝 Re: Timer triggers DMA transfer 你好@jabitbe2_jcplc MCXN947 支持 TrustZone 和网络安全归因控制。 如果访问源自与引脚安全配置不匹配的安全域，则对相应 GPIO 寄存器的读写操作可能无效。 请您确认 GPIO3 引脚 17 对应的位是否配置为允许非安全访问，并再次进行测试？ 如果该位当前配置为仅安全，则意外的 GPIO 行为可能与 TrustZone 安全设置有关。 谢谢！ BR 爱丽丝

需要对 LPC4078 EEPROM 页面擦除进行说明 我正在使用 LPC4078 和 MCUXpresso，并尝试在 Eeprom 中存储数值。 我想在不清除整个页面的情况下在页面中间写几个字节。 在数据表中可以看到，在将数据写入页面寄存器后，还必须将其编程到非易失性存储器中，而这是通过擦除/编程操作完成的。 擦除/编程操作是擦除整个页面，还是只擦除有新数据的页面区域？- 擦除/编程的地址设置会忽略 6 个 lsbs，因此它只知道页面。 UM10562.pdf 没有明确说明这个问题。 谢谢！ 亚历克斯 Re: lpc4078 eeprom page erase clarification required 我附上了一个工作区，其中包含上述项目。我使用 lpc-link2 调试器在 LPC4078 上运行了它。 (我懒得让半托管工作，所以使用断点来检查数据）。 Re: lpc4078 eeprom page erase clarification required 你好@alex_conway 对于 LPC4078 EEPROM，最小擦除/编程单位为一页（64 字节）。因此，每次擦除/编程操作都会擦除整个页面。如果你只想写入几个字节，请先读取整个页面，然后修改所需的字节，最后在页面上执行擦除/编程操作。您可以在自己身边进行测试。   谢谢！   BR 爱丽丝 Re: lpc4078 eeprom page erase clarification required 嗨，爱丽丝、 我的实验证明并非如此： 我使用 lpc_board_ea_devkin_4088 库和 periph_eeprom 演示项目编写了一个小程序来启动它。 我擦除了一页 Eeprom，然后读了回来。令我惊讶的是，结果都是 "0"，而不是 0xFF 然后，我将 "ABCDEFG/0 "写入该页面的地址 0，并读回页面。我收到 "ABCDEFG\0 然后，我将 "ABCDEFG/0 "写入该页的地址 7，并回读该页。我收到 "ABCDEFGABCDEFG\0 除了两件事之外，一切都在预料之中： 1. 擦除 eeprom 后读数为 0 2. 从Chip_EEPROM_Write()的实现来看，似乎没有读取-修改-擦除-写入的顺序。只有 Chip_EEPROM_WritePageRegister 之后的 Chip_EEPROM_EraseProgramPag。 这就是我提问的原因。 谢谢！ 亚历克斯 Re: lpc4078 eeprom page erase clarification required 在所有 printf 字符串中添加换行符后，我的半托管系统就能正常工作了！还有更清楚的证据证明了我所说的一切： 擦除将 Eeprom 设置为 0x00 该代码不执行读-修改-擦除-写序列，只执行擦除-写序列。 LPC4078 在擦除时似乎只擦除写入的位置。 我真的很想澄清这一点。 谢谢！ 亚历克斯 Re: lpc4078 eeprom page erase clarification required 尽管事态“升级”（无论这意味着什么），但恩智浦方面对此事仍未作出进一步回应。 我还需要进一步澄清。 Re: lpc4078 eeprom page erase clarification required 嗨@alex_conway 感谢您的回复，很抱歉回复晚了。 遗憾的是，我们之前的社区脚本存在故障，因此客户回复无法在我们的内部系统中触发案例更新通知。对于延误，我深表歉意。 关于 LPC4078 上的 EEPROM，根据用户手册，与实际 EEPROM 块的所有通信都是通过 64 字节的页面缓冲区进行的。因此，请确保您的 EEPROM 操作符合用户手册中描述的要求。 Alice_Yang_1-1788510957201.pngAlice_Yang_1-1788510957201.pngAlice_Yang_1-1788510957201.png Alice_Yang_0-1788510947469.pngAlice_Yang_0-1788510947469.pngAlice_Yang_0-1788510947469.png 目前，除非按照这些要求访问 EEPROM，否则我们无法确定是否存在问题。 谢谢！ BR 爱丽丝 Re: lpc4078 eeprom page erase clarification required 嗨，爱丽丝、 我正在使用 eeprom_17xx_40xx.h 中的函数。和 eeprom_17xx_40xx.c（由恩智浦提供，并包含在我附上的项目中） Chip_EEPROM_Write() 函数调用 Chip_EEPROM_WritePageRegister() 函数，然后调用 Chip_EEPROM_EraseProgramPage() 函数。 Chip_EEPROM_WritePageRegister() 函数使用 Chip_EEPROM_SetAddr() 函数设置 EEPROM 地址，该函数负责移位和消隐低 6 位。 然后使用 Chip_EEPROM_WriteData() 函数将数据字节写入 EEPROM 写入数据寄存器 (WDATA)。 Chip_EEPROM_EraseProgramPage() 使用 Chip_EEPROM_SetAddr() 函数设置页地址，启用擦除/页编程位，并等待编程完成。 我找不到任何读取页面中现有 EEPROM 数据以执行页面读取-修改-写入操作的代码。 然而，正如我的项目所展示的那样，EEPROM 页擦除似乎不会擦除整个页面，而只会擦除写入数据寄存器中加载了新数据的地址。 谢谢！ 亚历克斯

SE050 安全元件与 i.MX 8M Plus 和 Yocto Linux 的集成 大家好， 我正在使用 i.MX 8M Plus EVK 和 NXP SE050 安全元件。我想使用适用于 i.MX 平台的 Yocto 构建系统，在 Linux 系统下启动并运行 SE050。 请问是否有任何可用的集成/移植文档、应用笔记或参考实现，用于将 SE050 与 i.MX 8M Plus 和 Yocto 集成和测试？ 我偶然发现了 NXP Plug & Trust 中间件存储库，其中提到了对 Linux 的 i.MX6UL 和 i.MX8MQ 的支持： https://github.com/NXP/plug-and-trust 我还想了解这种现有的实现方式是否可以直接与 i.MX 8M Plus 一起使用，或者是否需要任何平台特定的移植，特别是对于 I²C 接口和 Yocto 集成。 谢谢， 罗汉 SE050 Re: SE050 Secure Element Integration with i.MX 8M Plus and Yocto Linux 你好@rohannathi ， Plug & Trust 中间件 GitHub 迷你包是Linux 使用的子集；建议使用 nxp.com/se050 上的完整软件包进行开发，因为它包含示例、工具和完整的文档。 i.MX 8M Plus 与现有的 iMXLinux 主机目标完全兼容——无需针对 i.MX 系列进行移植。 NXP 有一个参考设计——NavQPlus (8MPNAVQ) ——它基于相同的 i.MX 8M Plus SoC （与 i.MX 8M Plus EVK 相同的 SOM），并具有板载 SE050 安全元件，支持Yocto Linux 和 ROS2 。这是目前最接近 SE050 + i.MX 8M Plus + Yocto 的硬件参考，其 BSP/Yocto 层配置可作为直接指南。 您可以访问https://community.nxp.com/t5/Secure-Authentication-Knowledge/Integrating-EdgeLock-SE05X-to-FRDM-IMX91/ta-p/2138152查看更多详情。 希望对您有所帮助。 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 -------------------------------------------------------------------------------

CodeWarrior and PEmicro Multilink to MCU MKL03Z16VFK4R Hi,  I have MCU MKL03Z16VFK4R and I need to program it on winXP using PEmicro Multilink Universal. According to the information I have gathered, there is CodeWarrior 10.6 that support winXP. Could you share the CodeWarrior 10.6 software installer? or, Do you have other software that support winXP? Thank you Re: CodeWarrior and PEmicro Multilink to MCU MKL03Z16VFK4R Hi @Chalearmrat  Thank you for your post. There is not an available 10.6 Code Warrior installer you could review the different versions of CodeWarrior available at CodeWarrior Downloads | NXP Semiconductors The recommended version for Kinetis is CodeWarrior for MCUs 11.1 (that could be used at Windows 11), but it does not include support for KL03. carlos_o_0-1778783252765.pngcarlos_o_0-1778783252765.png The KL0x series are supported at MCUXpresso IDE and the SDKs could be downloaded from MCUXpresso SDK Builder carlos_o_1-1778783488621.pngcarlos_o_1-1778783488621.png Re: CodeWarrior and PEmicro Multilink to MCU MKL03Z16VFK4R Hi, CodeWarrior 10.6 is quite old, and official installers may no longer be readily available. For the MKL03Z16VFK4R with a PEmicro Multilink Universal, I would recommend checking NXP’s archived CodeWarrior downloads and PEmicro’s legacy software/tools for Windows XP compatibility. If you cannot access the installer, contacting NXP or PEmicro support with the exact MCU and debugger model would be the safest way to obtain a supported legacy package.

CIRサンプル・トゥ・タップ・インデックス・マッピングおよびSR150におけるファーストパス後のセカンダリーピークに関する質問 こんにちは、 私は以下のデバイス、SDK、ファームウェアを使用しています。 ・対象デバイス：村田製作所製 2BP EVK型（NXP Trimension SR150） ・SDKバージョン：v05.11.05 ・ファームウェア：PNP_RhodesV4_SE_v05.11.05.bin SR150から取得したCIRデータに関して、2つ質問があります。 1. CIRサンプルとタップ指数の関係 SR150から取得された16のCIRサンプルと対応するTap Indexとの関係について、説明していただけますか? 私の理解では、16個のCIRサンプル（cir[0]からcir[15]まで）には、それらの絶対タップインデックスを直接示す情報は含まれていません。 cir[0]に対応するタップインデックスを特定する方法、または計算式はありますか？ また、診断情報で利用可能なファーストパスインデックスと配列インデックスcir[0]からcir[15]との関係についても理解したいと思っています。 例えば、CIRサンプリングウィンドウがFirst Path Indexを基準に決定される場合、First Path Index cir[0]の前後に何タップが対応しているかを知りたいです。 2. 第一道の直後に観測された二次峰 CIRを調べる中で、検出された第一経路の約3〜4サンプル後に比較的明確な二次ピークが現れるケースを観察しています。 添付図は、この動作の一例を示しています。 この例では、主要なCIRピークはタップインデックス834付近で観測され、別の局所的なピークは、約3タップ後のタップインデックス837付近で現れます。図中の赤い円で示されているのが、二次ピークである。 20260907.png20260907.png この二次ピークの可能な原因を説明していただけますか? 特に、これはSR150の内部相関器処理による既知または予想される応答、例えば送信・受信パルスの自己相関特性や相関応答のサイドローブなどである可能性はありますか? サポートにあらかじめ感謝いたします。 よろしくお願いいたします。 Re: Questions about CIR Sample-to-Tap Index Mapping and Secondary Peak after First Path on SR150 こんにちは、@Ricardo_Zamora さん。 ご回答とSR150のサポート経路の明確化に感謝します。 詳細な情報はNDAの下で公開できないことを理解しています。 これらの技術的な質問については、適切なモジュールパートナーまたは直接の担当者に連絡します。 改めて、サポートとご指導に感謝いたします。 よろしくお願いいたします。 Re: Questions about CIR Sample-to-Tap Index Mapping and Secondary Peak after First Path on SR150 こんにちは、 あなたの調子が良いといいのですが。ご不便をおかけして申し訳ありませんが、この製品の情報はNDA(秘密保持契約)に基づいており、公開されていません。 チップについての詳細は、代理店ネットワークで利用可能な当社の代理店のいずれかにお問い合わせください。NXPですか?または、このデバイスを手に入れるのを手伝った直接の連絡先がいれば、ぜひ連絡してください。 もし当社のUWB製品に関する情報をお探しの方やこのテクノロジに興味がある方は、パートナー(Trimension UWB Partners)のこれらの開発キットとモジュールをご確認いただくことをお勧めします。 これらのキットやモジュールに興味がある場合は、直接彼らに相談してプロセスやサポートを受けられるかを知る必要があります。なぜなら、このテクノロジのサポートは彼らを通じて行われるからです。 ドキュメントとソフトウェアは対応するUWBモジュールパートナーによって配布されます。モジュールを選択すると、パートナーのページに案内され、データシート、アプリケーションノート、必要なイネーブルメントにアクセスできます よろしくお願いいたします。 リカルド