INS-N1981 ワイヤレスMCUの概要 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> スマートホームが勢いを増し始めると、多くの競合する無線通信規格が覇権を争っています。ZigBee®が低電力ネットワーク市場で支配的になりつつある今、新しいMesh機能を備えた2つの新しい低電力技術であるThreadとBluetooth® Low Energyが、どちらもこの市場に参入しようとしていることは驚くことではありません。さらに、Thread Group(Google/Nest)、Allseen Alliance(Qualcomm)、AppleのHomekit、Open Interconnect Consortium(Intel)、その他多くの競合するIoTプラットフォームが、さらに混乱を招いています。では、この紛らわしい一連の無線通信規格とIoTプラットフォームでは、それぞれの主な機能は何であり、NXPにとって何を意味するのでしょうか。このセッションでは、これらのワイヤレス接続規格とIoTプラットフォームの概要、それらの機能、およびNXP IoTへの影響について説明します。 ビデオプレゼンテーションを見る <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> スマートホームが勢いを増し始めると、多くの競合する無線通信規格が覇権を争っています。ZigBee®が低電力ネットワーク市場で支配的になりつつある今、新しいMesh機能を備えた2つの新しい低電力技術であるThreadとBluetooth® Low Energyが、どちらもこの市場に参入しようとしていることは驚くことではありません。さらに、Thread Group(Google/Nest)、Allseen Alliance(Qualcomm)、AppleのHomekit、Open Interconnect Consortium(Intel)、その他多くの競合するIoTプラットフォームが、さらに混乱を招いています。では、この紛らわしい一連の無線通信規格とIoTプラットフォームでは、それぞれの主な機能は何であり、NXPにとって何を意味するのでしょうか。このセッションでは、これらのワイヤレス接続規格とIoTプラットフォームの概要、それらの機能、およびNXP IoTへの影響について説明します。 ビデオプレゼンテーションを見る インサイト&イノベーション

New CodeWarrior for MCU V10.7 is available Greetings, CodeWarrior for MCU V10.7 is now available for download from nxp.com at CodeWarrior for Microcontrollers-Eclipse IDE|NXP   Major features Combines all the previous CodeWarrior for MCU V10.6.x downloads into a single download and installer Windows 8 and 10 support Added S12Z and S08 device support Updated P&E and Segger debug libraries Various enhancements and bug fixes See attached release notes for details.   It is available as 'offline' and 'online' version: The offline package contains all architectures supported (ColdFire, ColdFire+, S08, RS08, S12, S12/XGATE, S12Z, DSC, Qorivva, Kinetis), while the online setup executuble contains the common parts, and the selected architectures are downloaded on demand. The setup will install a 30 day temporary professional license which afterwards default to 'special' edition (code size limited) mode. CodeWarrior for MCU V10.7 is compatible with V10.6 and any existing professional V10.6 license can be used with V10.7. It is not necessary to uinstall any previous CodeWarrior version, as V10.7 can be installed side by side with existing CodeArrior versions.     NXP CodeWarrior Team General Re: New CodeWarrior for MCU V10.7 is available hi       Does this software support MPC5748G development? Re: New CodeWarrior for MCU V10.7 is available thank you very much! Re: New CodeWarrior for MCU V10.7 is available Hello, yes, the offline package contains all the architectures shown in your last screenshot. So it supports the S12Z, and *not* the normal S12 you are showing in your previous screenshot: If you want to use S12, you have to use Codewarrior (classic, not Eclipse based) 5.x. And yes, USBDM is not included in that installation, but I think you can add it (refer to the USBDM pages for this). I hope this helps, Erich Re: New CodeWarrior for MCU V10.7 is available Hi Erich Styger，This offline package contains all architectures supported (ColdFire, ColdFire+, S08, RS08, S12, S12/XGATE, S12Z, DSC, Qorivva, Kinetis)？ I want to add same S12 derivatives (For example,MC9S12G48).What do I need to do?  I need to use USBDM，but CodeWarrior5.1/5.2 don't support it.

MQX FlashXドライバー – FlexNVMの書き方は? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 1. FlexNVMとFlashXに関する基本的な質問と回答をいくつか紹介します。 1.1 FlexNVMとは何ですか? FlexNVMは、データフラッシュとして、エミュレートされたEEPROMの不揮発性ストレージとして、または両方のオプションの組み合わせとして使用できるフラッシュメモリの追加の個別のブロックです。このドキュメントでは、最初のオプションであるFlexNVMが単にデータフラッシュとして機能することに焦点を当てます。 FlexNVMは、部品番号の専用箇所に「X」を含むMCU部品に含まれています。例えば： MK64FX512VMD12 には、1 ブロック (512 KB) のプログラムフラッシュと 1 ブロック (128 KB) の FlexNVM が含まれています。 MK64FN1M0VMD12 には、2 ブロック (各 512 KB) のプログラムフラッシュのみが含まれています。 FlexNVMとフラッシュブロックの詳細については、MCUリファレンスマニュアルを参照してください。たとえば、「フラッシュメモリサイズ」の章です。 1.2 FlashXとは何ですか? MQX FlashXドライバは、内部フラッシュへの書き込みと内部フラッシュからの読み出し機能を提供します。残念ながら、FlexNVM メモリはデフォルト ステートでは部分的にしかサポートされておらず、一部の BSP ではエミュレートされた EEPROM の設定と機能が実装されています (flexnvm サンプル コード)。詳細については、c:\Freescale\Freescale_MQX_4_2\doc\mqx フォルダの MQX_IO_User_Guide.pdf を確認してください。 1.3 FlexNVMを搭載したマイコンを搭載した自分のボードで、FlexNVMのないマイコン用BSPを使用できますか? お勧めしません。ただし、この BSP を独自のボード BSP のベースとして使用することができます。MQX_BSP_Cloning_Wizard_Getting_Started.pdfご確認ください。ドキュメントをC:\Freescale\Freescale_MQX_4_2\docフォルダにMQX_BSP_Porting_Guide.pdfおよびMQX_BSP_Porting_Example_User_Guide.pdfします。 1.4 KSDKプロジェクトでFlashXを使用できますか? 残念ながら、FlashXドライバはKSDKに実装されていませんでした。KSDKには、C90TFS/FTFxフラッシュファミリ用の独自の標準ソフトウェアドライバ(SSD)が含まれていますが、これはFlashXドライバの場合のような高レベルの抽象化レイヤーがない低レベルのドライバです。 2. FlexNVMをサポートするためのMQX FlashXドライバーのアップデート手順。 2.1これらのファイルをバックアップしてください: user_config.h、 .h 、init_flashx.c、flash_ftfl.c と flash_ftfe.cファイル。注: user_config.h、 .h および init_flashx.cBSPコードの一部です。 2.2 user_config.h で FlashX を有効にする定義によるファイル: #define BSPCFG_ENABLE_FLASHX 1 2.3 .h の更新ファイル： 2.3.1 MCUリファレンスマニュアルを確認し、必要に応じてBSP_INTERNAL_FLASH_BASE、BSP_INTERNAL_FLASH_SIZE、BSP_INTERNAL_FLASH_SECTOR_SIZEを更新してください。通常、FlexNVMのないBSPが自身のBSPのベースとして使用された場合は、BSP_INTERNAL_FLASH_SIZEを減らす必要があります。 2.3.2メモリマップでFlexNVMを定義する新しいマクロを追加します。例えば： #define BSP_INTERNAL_FLEXNVM_BASE 0x10000000 #define BSP_FLEXNVM_SECTOR_SIZE 0x400 #define BSP_INTERNAL_FLEXNVM_SIZE 0x00008000 2.4 BSPフォルダの init_flashx.c を更新します。 2.4.1 FlexNVMファイルブロックを_bsp_flashx_file_blocks[]テーブルに追加します。例えば：     データフラッシュファイルブロック { "dflash", BSP_INTERNAL_FLEXNVM_BASE, (uint32_t) (BSP_INTERNAL_FLEXNVM_BASE+ BSP_INTERNAL_FLEXNVM_SIZE - 1) }, パラメータは{ファイルブロック名、開始アドレス、終了アドレス}です。 注:これは純粋なソフトウェアインターフェースです。アドレスの範囲は、物理フラッシュ ブロック パラメーターに合わせる必要はありません。必要に応じてファイルブロックを整理できます。 2.4.2FlexNVM BSP をベースとして非 FlexNVM BSP を使用していた場合は、KinetisX デバイスの HW ブロック マップを変更する必要があります。_bsp_flashx_init構造で_flashx_kinetisN_block_mapを_flashx_kinetisX_block_mapに変更してください。 2.5 flash_ftfl.c または flash_ftfe.c を更新するファイル： 2.5.1 お使いのMCUにFTFLまたはFTFEフラッシュメモリモジュールがあるかどうかをMCUリファレンスマニュアルを参照し、編集する適切なファイルを選択してください。 2.5.2FlexNVMメモリブロックを_flashx_kinetisX_block_map[]テーブルに追加します。例えば： { BSP_INTERNAL_FLEXNVM_SIZE / BSP_FLEXNVM_SECTOR_SIZE, (_mem_size) BSP_INTERNAL_FLEXNVM_BASE, BSP_FLEXNVM_SECTOR_SIZE }, // FlexNVMブロック パラメータは{number of sectors, start address, sector size}です。 注:これは、物理ハードウェアメモリブロックの説明です。アドレスの範囲は、物理フラッシュ ブロック パラメーターに適合する必要があります。 2.5.3次に、FlexNVMアドレスの問題を修正する必要があります。プログラムフラッシュとFlexNVMフラッシュはFTFE_FCCOBn FTFL_FCCOBnどちらも、FCCOB1..FCCOB3には、24ビット形式のアドレスが含まれています。したがって、FlexNVMアドレスを直接操作することはできません - FlexNVMベース0x10000000のため、24ビットに収まりません。 FTFL/FTFE モジュールでは、24 ビット アドレスの最上位ビット (ビット 23) がプログラム フラッシュと FlexNVM フラッシュの区別に使用されるように指定されています。たとえば、次のようなコードを使用できます。 FlexNVMフラッシュアドレスのときに23ビットを設定 IF(write_addr & BSP_INTERNAL_FLEXNVM_BASE)     { write_addr = write_addr |(1<<23);     }   そして、このコードを必要な関数に追加してから、command_array[]に書き込みます( command_array[] の内容はFTFL_FCCOBn/FTFE_FCCOBnレジスタの埋めに使用されます)。 FlashXサンプルコードの基本的な作業には、少なくともftfl_flash_erase_sector()/ftfe_flash_erase_sector()およびftfl_flash_write_sector()/ftfe_flash_write_sector()関数を更新する必要があります。 2.6.これらの変更後、flash_demo.c で FlashX のサンプルコードを使用してみてくださいデフォルトのプログラムフラッシュファイルブロックの代わりにFlexNVMファイルブロックを開くだけです。例えば： #define FLASH_NAME 「flashx:bank0」 #define FLASH_NAME「flashx:dflash」 添付ファイルには、MQX4.2.0およびMK20DX72 MCUの変更例があります。 3.フラッシュの書き換え方法 - 一般的な注意事項: フラッシュ・データは、プログラミングされる前に消去済みの状態にある必要があります。 ビットの累積的なプログラミング（より多くのゼロの追加）は許可されません。 FTFLモジュールとFTFEモジュールの両方の場合、整列されたフレーズ(通常は64ビット)でフラッシュをプログラムします。より小さなチャンク(バイト単位など)でプログラムが必要な場合、FTFLモジュールでは、推奨されていなくてもこのフレーズに書き込むことができます。ただし、FTFEモジュールは、同じフレーズに2回目の書き込みを行うとバス障害を引き起こします。したがって、すでに書き込まれたFTFEフレーズのデータを変更する方法を保存する方法は、セクター全体を消去してデータを書き換え直すだけです。そのため、FTFEモジュールにはioctlコマンドFLASH_IOCTL_ENABLE_SECTOR_CACHEを使用してください。セクタ キャッシュの割り当ては、フル セクタ書き込みと、デスティネーション領域 (フレーズに揃えられた) が空白の部分的なセクタ上書きの場合には必要ありません。 Re:MQX FlashXドライバ - FlexNVMの書き方は? <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちはシュリダール、 FlexNVM の場合: flash_ftfl.cの_flashx_kinetisX_block_map[]テーブルも編集する必要がありますファイルを作成し、FlexNVMブロックの説明を追加します。 FlexRAM の場合: 電源を切る前にフラッシュ/クローズ機能を使用しましたか? FlexRAMの使用例については、c:\Freescale\Freescale_MQX_4_2\mqx\examples\flexnvmを参照してください。 EEPROM エミュレーションを有効にするまで、ターゲットの FlexRAM メモリ範囲は「標準」RAM のように機能します。 もちろん、FlexNVMメモリをデータフラッシュとして使用するか、エミュレートされたEEPROMとして使用するか、FlexNVMメモリを2つのセクションに分割して両方のオプションを使用するかを選択する必要があります(その場合、メモリ範囲はそれに応じて更新する必要があります)。 いずれにせよ、空のMCUをデフォルト設定のFlexNVMメモリはデータフラッシュとして、FlexRAMは「標準」RAMとして使用できます。エミュレートされたEEPROM(FlexRAM)を使用する場合は、FlexNVMメモリを設定する必要があります(Program PartitionコマンドおよびSet FlexRAM Functionコマンド)。flexnvm サンプルコードを参照してください...

S32K344 - Six-step commutation control S32K344 - Six-step commutation control These examples demonstrate a a 3-phase Brushless DC (BLDC) motor control drive using a Six-step commutation control with Hall position sensor and without any position sensor (sensorless). This design serves as an example of motor control design using NXP S32K3 automotive family. Examples were designed on S32K344 Brushless Direct Current and Permanent Magnet Synchronous Motor Control Development Kit.  C-project based examples are part of MCSPTE1AK344 Development Kit Application Software. An innovative drivers set, Real-Time Drivers (RTD),are used to configure and control the MCU. It complies with Automotive-SPICE, ISO 26262, ISO 9001 and IATF 16949. Production-ready Automotive Math and Motor Control Library set provides essential building blocks for algorithm. FreeMASTER is used as useful run-time debugging tool. Application software contains:  MCSPTE1AK344_BLDC_6Step_hall_ll-. Hall sensor-based example. Detailed description of the example can be found in attachment to this article MCSPTE1AK344 - 6-step hall.pdf. MCSPTE1AK344_BLDC_6Step_sensorless_ll – Sensorless based example. Detailed description of the example can be found in attachment to this article MCSPTE1AK344_- 6-step sensorless.pdf. MATLAB Simulink based project (Motor Control BLDC Example - s32k344_mc_bldc_ebt) is build using Model-Based Design Toolbox (MBDT) and can be downloaded from NXP Model-Based Design Toolbox for S32K3xx - version 1.4.0 or newer releases.

s32k344 罐 你好，我正在使用 s32k344 电机驱动器代码，并有几个原型。我发现其中一台 CAN 机器在运行一段时间后会脱机，发送和接收都会出现异常。我打开了离线回复，发现信息会丢失 200 毫秒的帧。我更换了 CAN 收发器，但同样的现象依然存在。我已经阅读了勘误手册，是否是芯片本身存在这个错误？ Re: s32k344 can Hi@qicbeng 示例代码"MCSPTE1AK344_PMSM_FOC_2Sh_ll" 不提供 FLEXCAN 功能；您必须自行添加 CAN 相关功能。 请提供您的 CAN 测试项目，以便我检查您的配置是否正确。

S32K144 引导加载程序和 CAN over UDS 应用程序闪存工具指南 你好@JonAnder_Amante   我看到了您关于使用 S32K 统一引导加载器的讨论，并注意到您已经实现了引导加载器和应用程序闪存。我正在研究 S32K144 EVB，需要您的实际指导。 能否请您分享一下 您使用的具体工具和设置尤其是 硬件工具 调试探头（PE Micro、Segger J-Link、OpenSDA 等） CAN 接口硬件（PEAK、Vector、USB-CAN 等） 任何特殊布线或终端要求 软件工具 集成开发环境（S32 Design Studio 版本） CAN 刷机工具（ECU-总线 Pro、Open总线、CANoe 等） 使用的 JSON / flash 驱动程序配置文件 通过 UDS 闪存应用程序的脚本或实用程序 测试程序 如何验证启动加载程序和应用程序切换 您如何通过 CAN 测试 UDS 闪烁 您的实践经验对我顺利完成项目大有帮助。

S32N55: ストリームゲートを無効にするRTD API こんにちは、チームの皆さん S32N55 リファレンス マニュアルによると、1588 タイマーの TMROFF_H/L を変更する前に、ストリーム ゲート インスタンスを無効にする必要があります。 現在、RTD のストリーム ゲート機能を無効にする API があるかどうか教えてください。 BR、 ブリジット RTD Re: S32N55: RTD API to disable the Stream Gate こんにちは、 ユーザーマニュアルを再度確認して確認します Re: S32N55: RTD API to disable the Stream Gate こんにちは@Bridget S32N_RTD_R21-11_1.8.0_CD07 のユーザー マニュアルによると、ストリーム ゲートを有効/無効にするには、構成ツール (EB Tresos) で設定します。 EthCtrlConfigEnableStreamGating = FALSE 設定 Re: S32N55: RTD API to disable the Stream Gate こんにちは、クオンさん。 gPTP 同期中など、場合によっては、実行時に TMROFF_H/L の値を更新する必要がある場合があります。S32N55 リファレンス マニュアルによると、1588 タイマーの TMROFF_H/L を変更する前に、Stream Gate インスタンスを無効にする必要があります。 このような状況では、Stream Gate 機能を無効/有効にする API が必要であると考えます。あなたが言及した EB の構成では、このシナリオを処理できないようです。 現在、RTD にストリーム ゲート機能を無効/有効にする API があるかどうか教えてください。 BR、 ブリジット

S32K148 ロック 誤ってJ-LINKを使用してS32K148 MCUをフラッシュしてしまったため、再度接続しようとした際に「JLINK unsecured is no longer working」というエラーが発生しました。どうすれば解決できますか？ 接続中... - USB経由でプローブ/プログラマデバイス0に接続 - プローブ/プログラマーファームウェア: J-Link V9 コンパイル日: 2022年12月13日 11:14:50 - プローブ/プログラマー S/N: 25994751 - デバイス「S32K148」が選択されました。 - ターゲットインターフェース速度: 50 kHz (固定) - VTarget = 3.301V - ConfigTargetSettings() の開始 - ConfigTargetSettings() 終了 - 305us かかりました - InitTarget() 開始 - SWDが選択されました。JTAG -> SWD切り替えシーケンスを実行しています。 - フラッシュ内のアドレス 0x400 - 0x40F の保護バイトは、読み出し保護が設定されていることを示します。 デバッガー接続の場合、デバイスはセキュリティ保護されていない必要があります。 注意: セキュリティを解除すると、内部フラッシュの一括消去が実行されます。 - 以前にレジストリに保存されたデフォルトの動作を実行します。 - デバイスは保護されなくなります。 - デバイスのセキュリティ解除中にタイムアウトが発生しました。消去は停止しません。 - InitTarget() 終了 - 2.17秒かかりました - ID 0x2BA01477 の SW-DP が見つかりました - DPv0が検出されました - CoreSight SoC-400 以前 - APマップをスキャンして利用可能なすべてのAPを見つける - AP[2]: APマップの終端に達したため、APスキャンを停止しました - AP[0]: AHB-AP (IDR: 0x24770011, ADDR: 0x00000000) - AP[1]: JTAG-AP (IDR: 0x001C0000, ADDR: 0x01000000) - APマップを反復処理して使用するAHB-APを見つける - AP[0]: スキップ。CPUIDレジスタを読み取れませんでした - AP[1]: スキップ。AHB-APではない - CPUへの接続に失敗しました。リセット状態で接続を実行しています。 Re: S32K148锁死 こんにちは@ドンクイリ まず、暗号化されたセグメントは永続的なエラー値で書き込まれており、大量消去ではサポートされない可能性があるため、回復は保証されません。 ドキュメント6. S32K1xxシリーズMCUチップロックアップ現象についてお読みください。 https://mp.weixin.qq.com/s?__biz=MzI0MDk0ODcxMw==&mid=2247485716&idx=1&sn=979631aa2385a4e3c7651ee75ee252b4&chksm=e9124d92de65c484f1cfec7de451958cfd5cf818c46a4f71a7d3dd8a522af229c5a18aad58ff&scene=21#wechat_redirect Re: S32K148锁死 お返事ありがとうございます。 リンク先のドキュメントとチップのマニュアルをよく読みましたが、何度か試しても一括消去では復元できませんでした。S32FlashTool_v2.3.4を使いたかったのですが、S32K148をサポートしていません。S32K148をサポートするS32FlashToolはありますか？ Re: S32K148锁死 こんにちは@ドンクイリ これは使用しているソフトウェアとは関係ありません。記事にもあるように、リセットピンの波形をテストして、復旧できるかどうかを確認してください。復旧できない場合は、時間を無駄にしないでください。

KW47 知识中心 KW47 系列具备 96 MHz Arm® Cortex®-M33 内核，并搭载蓝牙低功耗（LE）子系统。独立的无线子系统具有专用核心和存储器，可减轻主CPU的负载，将其留给主要应用，并允许固件更新以支持未来的无线标准。KW47 还通过集成的 EdgeLock® 安全飞地核心配置文件提供高级安全性，并将由 NXP 的 EdgeLock 2GO 云服务支持凭证共享。 KW47 系列具备蓝牙信道探测功能，以及专用的片上定位计算引擎，可降低测距延迟。它集成了额外的内存，可支持特定应用代码、连接协议栈和无线固件更新。这意味着无线电子系统的实时活动在能够与应用程序不同的核心上运行，实现可靠的无线性能。 基于 NXP 在汽车解决方案领域的深厚历史，KW47 系列提供从 -40 °C 到 125 °C 的宽操作温度范围以及用于汽车应用的外围设备。KW47 将成为 NXP 15 年产品寿命计划的一部分，以支持长期使用。 KW47 系列配备 MCUXpresso Developer Experience 支持，可优化、简化和加速嵌入式系统的开发工作。 KW47 处于试生产阶段，开发人员可以立即开始使用与其引脚和软件兼容的 KW45。       早期访问计划 立即加入KW47早期访问计划：KW47 Early Access 您可以通过联系 NXP 销售团队来申请访问权限。   信道探测 信道探测简介 演示文稿 CCC CS 功率估算工具可用（附有 Excel 文件）   蓝牙规范 蓝牙 5.0 功能概述 蓝牙 5.1 功能概述 蓝牙 5.2 功能概述 Bluetooth_5.3_功能概述 Bluetooth_5.4_功能概述 Bluetooth_6_Feature_Overview   培训 蓝牙低能耗 6.0 NXP 简介 射频开关比较 吸收型/反射型 ETSI / FCC / ARIB 标准比较与要求 BLE 信道探测  - 概述 BLE 信道探测 - RF 硬件 BLE 信道探测 - ANSYS 建模工具 BLE 信道探测 - 天线原型验证测量 设备 无线设备： 本文提供了有助于项目开发的设备链接  有用链接 参考设计 - NXP 社区 使用 KW45/KW47/MCXW71/MCXW72 的信号频率分析仪 (SFA) 模块进行时钟测量 - NXP 社区：该社区提供了如何使用信号频率分析仪的步骤 [MCUXSDK] 如何使用 GitHub SDK 适用于 KW4x、MCXW7x、MCXW2x - NXP 社区此社区帖子逐步介绍了如何使用 GitHub SDK [MCUXSDK] GitHub SDK - 蓝牙 LE 平台文档 - NXP 社区此社区帖子提供了 BLE 平台的文档。  首次正确构建 PCB 的最佳方法，使用 KW47（汽车）或 MCXW712（IIoT）…… 社区：在此社区中，提供了使用 KW45 或 K32W148 和 MCXW71 构建 PCB 的重要链接，以及所有关于无线性能、低功耗和无线认证（CE/FCC/ICC）的内容。 如何在 Kinetis 系列产品上使用 HCI_bb 并进入 DTM 模式：本文分为两部分： 如何将HCI_bb二进制文件烧录到Kinetis产品中。 使用 R&S CMW270 进行射频测量 BLE HCI 应用程序用于设置发射机/接收机测试命令：本文提供了步骤，展示用户如何向设备发送串行命令 。Bluetooth LE HCI Black Box Quick Start Guide：本文介绍了一个简单的过程，用户可以通过串行命令控制无线电。 Kinetis (K32/38/KW45 & K32W1/MCXW71)功率配置工具： 此页面专门介绍 Kinetis (KW35/KW38/KW45) 和 MCX W7x (MCX W71) 功率配置工具。它将帮助您估算您的应用程序（汽车或物联网）的功耗，并评估您解决方案的电池寿命。  

imx95 电源模式 我正在开发一款运行 Linux 6.12（基于 Yocto）的自定义 i.MX95 板。我遇到了与 USB3 主机控制器有关的挂起到内存（深度睡眠）故障。当执行 echo mem> /sys/power/state 时，系统会中止 xhci-hcd 的挂起：WARN: xHC CMD_RUN 超时，紧接着 PM: failed to suspend async: error -110.启用 USB 主机模式时，即使没有活动的 USB 流量，问题也会持续出现。我使用的是由 GPIO 控制的固定 5V VBUS 稳压器，USB3 控制器、PHY、时钟和功率域在 DTS（附后）中定义。我的要求是在低电源模式下完全关闭 USB VBUS 的电源，同时允许系统成功进入深度睡眠。我附上了完整的暂停/恢复 dmesg 日志和与 USB 相关的相关 DTS 节点以供参考。我希望得到指导，了解在 i.MX95 上避免 xHCI 挂起超时所需的正确 DTS 和/或驱动程序处理方法。 Re: imx95 low power mode 您能否向我们分享详细步骤，以便我们在 EVK 板上复现它？谢谢 Re: imx95 low power mode 在自定义板中我使用 fusb302 但未作为 usb3.0 启用，我们将其用作 usb2.0。 但在进入深度睡眠时（echo mem> /sys/power/state ），xhci-hcd 驱动程序出现错误。 测试设置： • SoC：i.MX95 • 操作系统：Yocto Linux（内核 6.x、电路板支持包） • USB 模式：主机（xHCI、USB3）• 连接设备：USB 闪存盘（大容量存储） 正常启动板。 将 USB 存储设备连接到 USB3 主机端口。 使用 lsusb 验证枚举并确认设备可访问。 使用以下命令进入电源模式： echo mem > /sys/power/state 在此步骤本身之后它会显示错误。 使用配置的唤醒源（电源按钮/ GPIO）恢复系统。 恢复后，观察到 USB 设备是： 未检测到，或 在 dmesg 中显示 xHCI / DWC3 相关错误，或 需要重新插入 USB 才能重新工作。 ERROR LOGS : echo mem> /sys/power/state [ 117.057281] PM: suspend entry (deep) [ 117.066009] Filesystems sync：0.005 seconds [ 117.071209] Freezing user space processes [ 117.076800] Freezing user space processes completed (elapsed 0.001 seconds) [ 117.083781] OOM killer disabled. [117.087011] 冻结剩余的可冻结任务 [117.132725] 冻结剩余已完成的可冻结任务（已经 0.041 秒） [117.140164] printk：暂停主机（使用 no_console_suspend 调试） [117.156868] sd 0:0:0：0：0：[sda] 同步 SCSI 缓存 [117.267552] xhci52-hcd xhci-hcd.2.auto：警告：xHC CMD_RUN 超时 [117.267611] xhci-hcd xhci-hcd.2.auto：PM：dpm_run_callback ()：platform_pm_suspend 返回 -110 [117.267631] xhci-hcd xhci-hcd.2.auto：无法暂停异步：-110 [117.267702] 下午：一些 设备无法挂起，或者检测到提前唤醒事件 [117.268017] hub 1-0:1.0：hub_ext_port_status 失败（错误 = -108） [117.268044] USB usb1-port1：无法禁用（错误 = -108）[117.516365] 下午：恢复设备花了 0.248 秒 [117.570639] OOM 杀手已启用。 [ 117.573777] 重新启动任务......完成。 [ 117.575261] sd 0:0:0:0: [sda] 测试单元就绪失败：Result: hostbyte=0x01 driverbyte=DRIVER_OK [ 117.578423] random: crng reseeded on system resumption [ 117.587117] sda: detected capacity change from 120164352 to 0 [ 117.598136] PM: suspend exit -sh: echo: write error：连接超时 Re: imx95 low power mode 嗨@kannappan、 好了，我们要放元旦假期了。当我回到办公室时我会在我们的板上试一试然后给你回复。 祝您有美好的一天 顺祝商祺！ Rita Re: imx95 low power mode 嗨@kannappan、 对不起，这周太忙了，我下周会为您测试并与您分享结果。 祝您有美好的一天 顺祝商祺！ Rita Re: imx95 low power mode HI@Rita_Wang, 对于上述问题是否有任何答复。 谨致 Kannappan

S32Design studio 中的 S32k322 ADC 双用途问题 你好、 我使用 ADC1 有两个目的。我为高速电流检测配置了两个通道，这需要启用特定的"控制模式"。但是，我还需要使用同一 ADC 上的其他几个通道进行电压和温度检测，并配置为"正常链式转换"，而这些通道目前无法工作。造成这种冲突的原因是什么？如果可以将 ADC 用于双重目的，请访问" ，这里附有 FYR 的配置图像。 芯片为 s32k322 系列 Re: S32k322 ADC Dual Purpose issue in S32Design studio 您好， 这是我写的，在 BCTU 控制模式下，无法启动正常转换。你需要更改设置才能使用 "触发信号模式" 作为 Adc Ctu Mode 选项 BR, Petr Re: S32k322 ADC Dual Purpose issue in S32Design studio control modecontrol modecontrol mode控制模式 Normal ChainNormal ChainNormal ChainNormalChain 抱歉，我现在附上了配置图像。问题是，当我启用电流检测控制模式时，正常的链式转换（电压和温度）就会停止工作。 我使用 ADC1 有两个目的。 这就是我问这个问题的主要原因：是否有可能将 ADC1 配置和用于双重目的，即同时使用控制模式（用于电流检测）和普通链式转换（用于电压/温度检测）？ Re: S32k322 ADC Dual Purpose issue in S32Design studio 您好， 这里似乎没有附上配置图像。 总之，如果 ADC 配置为 BCTU 控制模式（MCR[BCTU_MODE] = 0），则只有 BCTU 才能启动转换。所有其他触发信号都将被忽略。 在触发信号模式（MCR [BCTU_MODE] = 1）下，也可以执行普通和注入转换。所有类型的转换都可以在此模式下启动。设备 RM 的 BCTU 触发信号模式第 60.3.6.1 章中讨论了三种转换类型的优先级。 BR, Petr Re: S32k322 ADC Internal Temperature issue in S32Design studio 你好@PetrS、 我将 14 位 ADC 配置为内部温度传感，但 RTD 温度传感宏仅定义为 12 位分辨率，并在 Adc_Sar_Ip.h 和 Adc_Sar_Ip.c 中使用 12 位温度实例。因此，计算的温度、ADC 原始读数和测量的电压都会发生振荡，且不正确。在配置 14 位 ADC 时，RTD 功能是否应自动切换到 14 位，还是需要定义 14 位分辨率宏并手动更新 API 功能？此处附上图片供您参考。 RTD Function Defined MacrosRTD 函数定义的宏 Calculated Value Configuration tab计算值配置选项卡

MCXW716C 在高温下运行 你好 我使用的是 #mcxw71，根据数据表，其工作温度范围为 -40 °C 至 +125 °C。我对无线电和 CAN PHY 都进行了测试，但无法在大约 85 °C 以上实现稳定运行。微控制器似乎进入保护模式，或以其他方式限制其功能。 我还注意到，在 SDK 应用程序接口中有向 NBU 发送内部温度的函数。 我的问题是：NBU 是否需要温度信息来进行热调节或维持系统正常运行？ 一般来说，是否需要任何特定的程序（配置、校准、所需的 API 调用等）来确保 MCXW716C 在最高额定温度下正常运行？ 提前感谢您的帮助。 开发板 Re: MCXW716C operation at high temperature 你好，希望你一切都好。 您使用的是 FRDM 板还是自定义板？您进行了哪些测试，观察到的行为是什么？ 能否请您分享一下您所指的是哪些 SDK API？您是否正在研究一个具体的示例或应用？ 致以最诚挚的问候， Ana Sofia。 Re: MCXW716C operation at high temperature 你好，@sofiaurueta、 我正在使用参考编号为 #MCXW716CMFTAT 的自定义板。我将解释我的测试和配置 我使用 MCXW716CMFTAT 为无线应用设计了 PCB。我已创建了软件，并使用名为"connectivity_test" 的示例程序中的逻辑来使用无线电协议。 我使用的是 SDK SDK_2.X_MCXW716CxxxA 版本 25.09.00。 两个董事会正在一起工作。我已经实施了所有模块。测试时，我使用了热风枪，温度为 80 °C。15 秒后，微控制器停止工作；它似乎被阻塞了，GPIO 被锁定，通信总线停止发送数据，30 秒后，温度下降后，微控制器恢复正常运行。 因此，我研究了监测温度的功能，以了解问题所在。我使用了 SDK 中 fwk_platform_sensors 文件中的 PLATFORM_StartTemperatureMonitor() 函数。 我的目标是知道微控制器堵塞的确切温度，而令人惊讶的是，这解决了问题。现在，我可以在 +120 °C 的温度下进行测试，微控制器工作正常。我甚至尝试删除该功能，以确保问题是否与软件有关，结果问题又出现了。 您能给我更多的解释吗？使用该功能读取温度是否会将数据分发到不同的内核并调整某些参数？ Re: MCXW716C operation at high temperature 你好 您能否确认使用 FRDM 板时是否也会出现这种行为？在未作任何修改的情况下运行 connectivity_test 示例时是否会出现问题，调用 PLATFORM_StartTemperatureMonitor 函数后问题是否会改变？ Ana Sofia。

PBRIDGE accessed by two resources at the same time Please, in MPC5777C what happens if SPI is sending data through the PBRIDGE at the same time another resource is sending data as well, for example the temperature sensor. What data will be processed first? How bridge chooses the data to be processed first? Re: PBRIDGE accessed by two resources at the same time Yes, this is managed by XBAR (if it is the same PBRIDGE as some devices has two or more). Re: PBRIDGE accessed by two resources at the same time If two cores try to simultaneously access resources connected in PBRIDGE, will these accesses be arbitrated by XBAR or there is another arbitration mechanism in bridge? Re: PBRIDGE accessed by two resources at the same time SPI does not initiate any data transfer over PBRIDGE as it is XBAR slave port. XBAR master initiates (core, eDMA, ..) data transfers (but it can be according interrupt or trigger signal from XBAR slave). However transfers over XBAR are processed according XBAR priority.

S32K144: Integration of FlexCAN inside lin_master_s32k144 (S32DS.ARM2.2) Good morning: Currently using the S32K144EVB board to prepare a system demo, where we must manage 1 classical CAN-HS network (500k) and 3 LINs. (19200, multiple slaves in each LIN)  k144EVB board will behave as LIN master for the 3 LINs, that's why as starting point I've selected the LIN_master_S32K144 example. LINStACK is working fine and now I've started to check the integration of the CAN communication into the project. Reviewing S32K144 documentation and examples, i see that the K144 has 2 different ways to manage the CAN communication... either via FIFO or either via MBs... Unclear the benefits of one over the other...  for a system where i must receive 4-5 CAN messages, process some of the content data and transmit periodically 1 or 2 CAN messages: 1) which configuration is easier/better to use, considering that my LIN master will operate at full capacity?FIFO or MB? 2) do we expect any registers/clock/interrupts conflicts between NXP linstack and the FlexCAN integration? 3) is there any example available already with such an integration (LIN-MASTER + CAN-HS)? Re: S32K144: Integration of FlexCAN inside lin_master_s32k144 (S32DS.ARM2.2) Hi@rricart There's no relationship between LIN and CAN; they are two independent peripheral modules. For the S32K1 FlexCAN, the CAN FIFO does not support CAN FD, so you need to consider whether need to support CAN FD or not. If your project doesn't require CAN FD feature, either the MB or the FIFO will fine. You can refer to the demo provided in this link, which categorizes the different ways to use FlexCan and provides a simple test demo. https://community.nxp.com/t5/S32K-Knowledge-Base/S32K1xx-FlexCAN-Mask-Setting-Demo/ta-p/1519753

串行线调试的乐趣与游戏 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 我为我的 LPC1517 项目重新铺设了电路板，以移动 SWD 插座。数据和时钟直接传输，但 0V 电压则绕到一个小型（1 瓦）降压稳压器的后面。如果我想从麦克风前置放大器中获得 -130dBV/√Hz 的信号，我不会使用这种 PCB 跟踪技术，但对于具有 1V 抗噪能力的数字信号来说，速度并不快，我想应该没问题--但是没有--出现了大量 ACK、Flash 写入失败之类的错误。 我剪断了轨道，换上了一条沿着数据和时钟轨道走向的导线，然后就成功了。 因此，SWD 就像是 SPI 的半双工版本，MOSI 和 MISO 复用到一个引脚上，运行频率为 1MHz；所以重要的时间是时钟转换。其他都不重要。因此，可能有三种情况会妨碍它的工作：边沿过快导致接地反弹，边沿过慢导致抖动，或者目标阻抗过高导致干扰进入。因此，我尝试了几种方法--220pF 跨时钟到地、1k 下拉和 10k 串联阻抗--1k 似乎最有希望，但没有真正成功。 LPCXpresso 崩溃了 - 我强行退出，然后重新启动。 然后一切正常 所以，我比以往任何时候都更加困惑。 同一批的另一块板容易出错，但是如果我的示波器接地夹连接到电路 0V，则可以正常工作。 我听您说过，这意味着电路应正确接地，但电路 0V 与电源接地相连，而示波器却没有。 另一个令人困惑的问题是，从提交闪存写入" 时出现的"目标错误显示"system rejected access at location x"; 但我遇到的所有错误中，位置 x 都在 RAM 中。 不同的电路在机柜中与开关电源相邻时不会连接。把它从柜子里拿出来，就可以正常使用了。 我觉得这一切都很令人费解，因为我一直使用 SPI，速度是它的十倍，而且没有过多考虑 PCB 跟踪问题。如果效果这么差，我的 LED 显示器就会像启动器失灵的荧光灯管一样闪烁。 有人有什么想法吗？ LPC13XX lpc15xx LPC800 Re: Fun and games with Serial Wire Debug 我花了三天时间确信这是硬件故障，直到我意识到我在初始化代码中翻转了两个引脚。突然之间，传感器数据变得有感知了，但是在我玩 Slope Game 时为了放松而发生迷你崩溃之前，情况并非如此。 Re: Fun and games with Serial Wire Debug 有趣的是，即使是微小的 PCB 布线选择也会导致重大问题，尤其是像 SWD 这样的敏感信号。这让我想起了大米纯度分数的不可预测性--有时，看似简单的事情会呈现出意想不到的复杂性！ Re: Fun and games with Serial Wire Debug > 有人有什么想法吗？ 我会尝试降低 SWD 时钟频率，看看效果如何。 我建议是一个数量级，即 100 千赫或更低。 这样调试并不有趣，但可以证明一点。 Re: Fun and games with Serial Wire Debug 我创建了一个名为 Debug 的单例和一个始终位于顶部的基本文本框。我现在可以不打印，而是 Debug.output(text) 因此，在我测试时，它就会出现在游戏中。当你只有一台监测时，有时，几乎每时每刻都会让事情变得容易得多。 模拟人生 4》满意度积分作弊器最近派上了大用场，当时调试任何东西的唯一方法就是实时更新我的视网膜所观察到的确切坐标，而使用 print() 会很麻烦，而且会激怒戈多。"减少文字印刷量" 此外，它还能实时捕捉仅出现的问题，而无需密切关注 Godot 输出日志。 Re: Fun and games with Serial Wire Debug <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 不太确定你期望我在参考手册中找到什么，而我在帖子中还没有提到过。在 LPC15xx 手册的三页中，除了连接图和两个引脚都有上拉功能外，几乎没有其他内容。它甚至没有说明 SWCLK 只是输入，而 SWDIO 是双向的。我的大部分信息来自ARM关于该主题的白皮书。 至少我很高兴恩智浦不再建议在 SWCLK 上使用下拉电阻（pullDOWN）了--那会严重破坏抗噪能力，尤其是在您碰巧获得与内部上拉电阻相同的电阻时。 无论如何，我进一步进行了实验，并在SWCLK输入中添加了施密特触发信号。我尝试了 74LVC1G17 和一对 74HC14 的栅极。结果令人震惊。在我追踪不太好的板上，错误率从65％下降到零。100 次尝试中没有一次编程失败（1G17 和 HC14 没有区别） 然后，我将导线延长到标准的 150 毫米以外。在 LPC-LINK 和 targert 之间的 1 米引线上没有出现过任何故障。3 米处仍未出现故障。除此之外，无缓冲 SWDIO 线路上电缆的体电容也成了问题，误差逐渐增大。 下一步是在使用高噪声开关电源的电路上进行试验！ 磁滞似乎可以解决问题，PIO0_18 引脚也有一个磁滞选项，但我敢打赌，在 SWD 操作期间，它不会打开。但我想知道，如果我在软件中设置了 IOCON 寄存器的第 5 位，那么在下一次编程时，迟滞功能是否仍会开启？ 想尝试的人请注意：您的 SWCLK 输入（74LVC1G17 的输入）现在需要一个下拉电阻。我用的是 3.3kΩ。这个值并不重要，因为连接太短，不能被视为传输线，所以从技术上讲，它不是"终端" 。 Re: Fun and games with Serial Wire Debug <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好 IanBenton、 为了提供尽可能快的支持，我想请你参考参考手册中的串行线调试章节 查看详情。 祝你愉快 TIC   ----------------------------------------------------------------------------------------------------------------------- 注：如果本帖回答了您的问题，请点击正确答案按钮。Thank you! -----------------------------------------------------------------------------------------------------------------------

SEMC Configuration for SDRAM Hi, I am using a custom NXP RT1176 board, and in the SEMC interface for SDRAM, the hardware only provides address lines A0–A11. With this configuration, we can access a maximum of 16MB of SDRAM. However, I would like to use 32MB, so I selected a 64MB SDRAM part (Alliance AS4C32M16SB) and left the A12 address line floating. My intention is to use the lower 32MB of the device. I have configured SEMC for 64MB, mapping the memory range from 0x80000000 to 0x80FFFFFF. In this region, I am observing 16-bit read/write failures at certain addresses. Interestingly, when I access memory from 0x81000000 to 0x81FFFFFF (the upper 32MB), it works correctly. I’ve attached the code I used for configuration. Can you please review it and let me know if any improvements are needed, or if this kind of setup (with A12 floating) is valid and supported by SEMC? Best regards, Pavanakumar A G Re: SEMC Configuration for SDRAM A12 should be held low on the SDRAM side(I suggest confirming this with the manufacturer).  BR, Omar Re: SEMC Configuration for SDRAM Thank you, @Omar_Anguiano, for your reply. On our board, A12 is floating on both the controller side and the SDRAM side. As you mentioned, A12 should be held at a known logic level. Could you please clarify: What logic level should we use for A12 in this case (HIGH or LOW)? Do we need to drive A12 to the same known level on both sides, or is it sufficient to set it only on the SDRAM side? Re: SEMC Configuration for SDRAM Avoid floating  Lines. Ideally, do not leave A12 floating; tie it to a known logic level so you can access the lower half.  BR, Omar

S32G 无法通过串行端口编程的问题 S32G3 你好，根据问题，我再次使用 S32G399A 芯片。正常启动后，我连接串行端口，然后使用闪存工具进行刻录。错误报告界面如下所示，电流可下降约 30mA（12V 电源）。请您帮我找出原因，并确定我应该从哪个方向进行调查。谢谢。 Re: The issue of S32G failing to be programmed through the serial port 此问题已解决，谢谢回复。 Re: The issue of S32G failing to be programmed through the serial port 您好，从您更新的信息来看，问题有可能与您的时钟设计有关。 目前而言，在 S32 Flash 工具中，没有支持S32G3 custom board+Oscillator的功能，我并没有看到有目前可用的相关二进制文件来支持您的情况。 给您带来的不便很抱歉。 BR Chenyin Re: The issue of S32G failing to be programmed through the serial port 你好， 1、我现在根据S32G-VNP-RDB3设计的自己主板。 2，Flash Tool ：Version: 2.3.2,如下图。 3、我自己的主板，Flash型号是：MX25UW51245GXDQ00。 我现在遇到的这个问题，是否是因为时钟的问题引起? 我的时钟现在使用的是单端时钟。部分原理图如下。 然后，我下午把我的BOOTMOD[1:0]改为1:0后，可以烧录到SRAM中，并且串口也能打印出“hello world”，但是仍不能烧录到Flash。帮忙分析下原因。谢谢。 Re: The issue of S32G failing to be programmed through the serial port 你好，@龙岗素 谢谢您的帖子。 我知道你愿意刷新 S32G 板的 QSPI。 1。我能知道你是否在使用定制板吗？还是恩智浦的 RDB3/EVB3？ 2.使用的是哪个版本的闪存工具？ 3.如果是定制板，QSPI 的部件号是多少，它是你在 Flash 工具中选择的吗？ BR 切宁

i.MX93 RGMII connection PHY and MAC to MAC connection tips This article describe i.M93 RGMII to PHY connection, delay adding tips. i.MX93 don't support delay in both FEC and QOS port in i.MX93 side. It also provide solution on i.MX93 how to connect MAC to MAC in HW & SW. Thanks! 

Understanding LPC55S6x Revisions and Tools At the time of the latest update to this article, the latest silicon revision of the LPC55S6x is revision 1B. Since Nov,2019, all the LPCXpresso55S69 EVK boards marked as Revision A2 or A3 are equipped with revision 1B silicon. Initial production boards that have 0A silicon installed are marked Revision A1.                                   NXP introduced its new debug session request functionality on silicon revision 1B. For some IDE versions, the method of initiating a debug session is designed for current 1B silicon revisions and will result in an endless loop when used on older revision 0A parts due to the older revision not implementing some aspects of the handshake protocol. The protocol for this debug connection method, including handling of both 0A and later silicon revisions correctly, is included in the latest LPC55S6x/S2x/2x User Manual, section Debug session protocol.   IDE Considerations MCUXpresso IDE MCUXpresso IDE v11.0.1, incorrectly only supports silicon revision 1B debug session requests and cannot silicon to revision 0A parts in some situations. When connecting LPCXpresso55S69 Revision A1 board, you may have connection error like this: NXP released an MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix1 for this issue. Please follow the steps to fix the issue below if you have to use IDE v11.0.1 with silicon revision 0A; however it is recommended to update to the latest version of the IDE instead of taking this approach: https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/10/30/mcuxpresso-ide-v1101-lpc55xx-debug-hotfix IAR According to our test: IAR Embedded Workbench for ARM v8.42 and later can support both silicon revision 1B and 0A production without issue, which can be downloaded from https://www.iar.com/iar-embedded-workbench/tools-for-arm/arm-cortex-m-edition/ Note: The IAR 8.50.5 changed the CMSIS-DAP debug support for trustzone feature. There is known debug issue with the combination of IAR 8.50.5+SDK2.8.0. Thus our recommendation is:        Use IAR 8.50.5 with SDK2.8.0       Use IAR 8.40.2 with SDK 2.7.1 Keil MDK Both Keil MDK v5.28 and v5.29+ latest LPC55S69 pack v12.01 can support silicon revision 1B without problem but cannot support silicon revision 0A. LPC55S69 Revision 0A vs. 1B differences summary Silicon Revision 0A production 1B production Board Revision A1 A2 Deliver Date Before Nov,2019 After Nov,2019 Debug Access handshake Supported but not required. Handshake signaling partially supported Required Secure Boot Revision SB2.0 SB2.1 Maximum CPU Frequency 100MHz 150MHz IDE revision required 1.      MCUXpresso IDE v11.0.0 and older 2.      MCUXpresso IDE v11.0.1 + hotfix1 3.      MCUXpresso IDE 11.1 and later MCUXpresso IDE v11.0.0 and newer SDK version SDK2.5 and newer are supported; SDK2.6.3 and newer are recommended SDK2.6.3 and newer   LPC55S69 Defect Fix: 0A vs. 1B 0A Production 1B Production Defect: For PRINCE encrypted region, partial erase cannot be performed Fixed Defect: For PUF based key provisioning, a reset must be performed Fixed Defect: Unprotected sub regions in PRINCE defined regions cannot be used. Fixed Defect: Last page of image is erased when simultaneously programming the signed image and CFPA region Fixed Defect: PHY does not auto-power down in suspend mode Fixed For more detail, see Errata sheet LPC55S6x which can be downloaded  from NXP web site.   Pre-production Silicon: Note that NO BOARDS WERE EVER SOLD THROUGH DISTRIBUTION WITH PRE-PRODUCTION SILICON. In case you have board marked with Revision 1, 2 ,A, or A1 board with 1B silicon, contact NXP to ask for production replacement.   Get Silicon Revision: The silicon revision info is marked on the chip and board revision is marked on the board silkscreen. For silicon revision marking information, please consult LPC55S6x Data Sheet section 4. Marking . Below is an example of silicon revision marking information where revision is highlighted in red: The user application can also get the silicon revision through chip revision ID and number: SYSCON->DIEID:   The English and Chinese version documents are attached.   LPC Marketing LPC55xx 中国用户论坛

ADAS: NXP Secure V2X Solution As the US Government prepares to mandate Car-to-Car communication in the US, the car industry is gearing up to provide cars which support this Dedicated Short Range Communications technology. We look at what benefits this will bring to road users, how the ITS-G5 standard is being deployed around the globe, and the challenges faced by the car industry in bringing this to market, and NXP’s leadership role in this deployment. As the US Government prepares to mandate Car-to-Car communication in the US, the car industry is gearing up to provide cars which support this Dedicated Short Range Communications technology. We look at what benefits this will bring to road users, how the ITS-G5 standard is being deployed around the globe, and the challenges faced by the car industry in bringing this to market, and NXP’s leadership role in this deployment.