S32K1_S32M24XとS32K1のRTDパッケージの違いは何ですか? 私はS32K116向けに開発を行っています。 S32DS拡張機能とdUpdatesを使っているときに、2つのS32K1パッケージがインストールされていることに気づきました: 「S32K1_S32M24X リアルタイム・ドライバ AUTOSAR R21-11 バージョン 3.0.0QLP06" および 「S32K1 リアルタイム・ドライバ AUTOSAR R21-11 バージョン 3.0.0」QLP06" この2つの違いは何ですか？ もし私のケースでも同じように対応するなら、どちらを残しておくべきか、アンインストールすべきでしょうか? そのうちの1つ（S32K1）を削除してみましたが、そうするとプロジェクトが.mexファイルを読み込めなくなってしまいました。もうファイルはありません。 Re: Difference between S32K1_S32M24X and S32K1 RTD packages? こんにちは、 @daniel_meier さん。 パッケージは似ているように見えますが、互いに依存関係があり、互いに独立して使用できる独立したコンポーネントとして扱うことを意図していません。 したがって、プロジェクトの適切な機能を確保するために、パッケージを再インストールし、両方のパッケージを同時にインストールしておくことをお勧めします。 BR、VaneB

Impossible to integrare new node in FreeMaster Lite NODE Red Dear All I would like to integrate widgets in NodeRed usinf FreeMaster Lite. Following the NXP training titled FreeMASTER Lite 1.1 + Node-RED Integration https://www.nxp.com/design/design-center/training/TIP-FREEMASTER-LITE-NODE-RED It is shown that (@ minute 0:40) the widget shuld be added accessing to Setting -> Managing Palette . But Managing Palett option is not available in the latest installation of FreeMaster Lite, just downloaded from NXP site Thanks for any support Paolo Re: Impossible to integrare new node in FreeMaster Lite NODE Red Hi @pberna67, Could you confirm that you are running FreeMASTER Lite version 1.5.1: 2.png2.png2.png and that the Node-RED version is 4.0.9: 1.png1.png1.png I did a clean install and could access the `Manage palette` option.  A quick check - could you try removing (or renaming) the `.node_red` folder from your user folder to make sure that any older Node-RED settings do not interfere with the latest installation. If that does not help you could you provide additional details: Are you running FreeMASTER Lite from the stand-alone installer or the one bundled with the main FreeMASTER 3.2 ? What is you host OS system ? Do you have any external Node-RED installations ? Kind regards, Iulian  Re: Impossible to integrare new node in FreeMaster Lite NODE Red Dear Iulian  Thanks for your quick answer ! I confirm that the FrieeMaster I'm  running is FreeMASTER Lite version 1.5.1: pberna67_0-1790026466167.pngpberna67_0-1790026466167.png Node RED version is 4.09 pberna67_1-1790026600039.pngpberna67_1-1790026600039.png Are you running FreeMASTER Lite from the stand-alone installer or the one bundled with the main FreeMASTER 3.2 ? I've installed only the following package: pberna67_2-1790027196038.pngpberna67_2-1790027196038.png There were NO previous FreeMASTER package installed. What is you host OS system ? Still Windows 10 Do you have any external Node-RED installations ? No, I haven't Thanks Paolo Re: Impossible to integrare new node in FreeMaster Lite NODE Red Hi @pberna67, I checked Node-RED documentation and it seems to be an expected behavior if NPM is not installed on the system. Manage Palette functionality relies in NPM tool for dependencies download and installation. NPM should be installed separately. There is a thread on Node-RED community explaining this topic in more details: https://discourse.nodered.org/t/why-isnt-manage-palette-showing-up/27219/9 Hope it helps, Iulian Re: Impossible to integrare new node in FreeMaster Lite NODE Red Dear  Iulian I don't see any npm program installed anywhere. Do I need to install node-red package too , or everything should be installed by  ? It is strange that part of node-red works and part no. In the thread you have indicated is not shown how to install the additional component NPM. Any additional idea? It is declared: https://www.nxp.com/design/design-center/software/development-software/freemaster-run-time-debugging-tool:FREEMASTER that FreeMaster has Integration with Graphical User Interface (GUI) Guider  design tool. Do you have any examples or additional integration details of the GUI builder in FreeMaster ? Regards Paolo

Config Tools for i.MX 26.09 Now Available We are pleased to announce that Config Tools for i.MX 26.09 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) Version 26.09 Framework Added support for downloading all boards associated with a processor when downloading the processor. DDR tool Added support for i.MX 937 Added DDR3 support for i.MX 8MP FRDM board Added support for i.MX93W FRDM and EVK boards at 3600 MT/s Enabled PMIC PF9453 support for i.MX 91 Minor improvements, enhancements, and bug fixes SerDes tool Added support for i.MX 952 System Manager Multiple validation ID issues are resolved. DDR tool – NXP-validated memory configurations for multiple vendors is available System Manager – extended CLI support for a headless setting      

MCUXpresso Config Tools 26.09 Now Available We are pleased to announce that MCUXpresso Config Tools 26.09 are now available. Downloads Also via installer in MCUXpresso for VS Code https://marketplace.visualstudio.com/items?itemName=NXPSemiconductors.mcuxpresso In order to use it with other toolchains, download the installer for all platforms, please login to our download site via:  https://www.nxp.com/mcuxpresso/config Please refer to https://docs.mcuxpresso.nxp.com/config/latest/ for installation and quick start guides. For online version, login into MCUXpresso site: MCUXpresso WEB Release Notes Full details at https://docs.mcuxpresso.nxp.com/config/latest/ Version 26.09 Framework Support public releases of “preliminary” EAR/PRC processor data. Added support for downloading all boards associated with a processor when downloading the processor.

Introduction DNPU Training Introduction DNPU Training   Explore the evolution of AI at the edge, from perception AI and generative AI to the emerging era of Agentic AI. This session introduces NXP’s discrete NPU strategy and examines how neural networks, transformer models, and AI agents enable intelligent decision-making for industrial, healthcare, and automation applications. Participants will gain an understanding of the technologies driving the next generation of intelligent edge systems.   This video is currently being processed. Please try again in a few minutes. (view in My Videos) ARA240 DNPU Hands-On Training

Ara240 DNPU Hands-On Training Welcome to the Ara240 DNPU Training! This page provides access to training materials, presentations, demos, recordings, and supporting resources related to the Ara240 DNPU. While live Q&A support will be available during the training period, all content will remain accessible for future reference and self-paced learning. Required Hardware The following boards are supported: FRDM i.MX 95 Pro FRDM i.MX 95 FRDM i.MX 8M Plus Ara240 DNPU Ara240 16GB M.2 Module microSD >= 64GB storage USB-C debug cable Internet (Ethernet) HDMI Monitor 100 W power supply (Anker Charger is recommended) USB mouse USB keyword 1080p USB Camera Instructions Step1. Watch introduction DNPU Training Introduction Step2. Check the Hardware and Software Pre-requisites Getting Started Guide with FRDM-IMX8MPLUS Step3. Run the rest of the Software demo packages After completing the pre-work, each lab has its own guide document and a video guide you can use as support material in case you have any question at any step: Lab1: Running a GStreamer Pipeline for 8 Video Streams with YOLOv8n on Ara240 DNPU Ara Vision Multi-Stream YOLOv8 Object Detection Lab2: Running Unimodal Large Language Models on Ara240 DNPU LLM Edge Studio Lab3: Interacting with Vision-Language Models on Ara240 DNPU VLM Edge Studio Lab4: Enabling REST-Based LLM and VLM Inference on Ara240 DNPU eIQ AAF Connector Lab5: Running the Smart Device Gateway server on Ara240 DNPU  Smart Device Gateway  Additional Resources Take advantage of the resources below to deepen your knowledge and support your development efforts: Ara Software Development Kit (ARA SDK) Ara240 DNPU Six Pack Ara240 Discrete Neural Processing Unit (DNPU) Ara240 16GB M.2 Module FRDM i.MX 95 Pro FRDM i.MX 8M Plus ARA240 DNPU Hands-On Training

Transformed and Quantized your model with NPU of the MX8Mplus     Introduction In this article, we will explain in this article which steps you have to take to transform and quantize your model with different TensorFlow versions. We are only looking into post training quantization. We are using the MX8MPlus EVK run our model that have a dedicated neural network accelerator IP from VeriSilicon (Vivante VIP8000). Press enter or click to view image in full size i.mx8MPlus block diagram from NXP Is the neural processing unit (NPU) from NXP need a fully int8 quantized model we have to look into full int8 quantization of a TensorFlow lite or PyTorch model. Both libraries are supported with the eIQ library from NXP. Here we will only look into the TensorFlow variant. The general overview on how to do post training quantization can be found on the TensorFlow website.  The operations for floating point are more complex than for integer (arithmetic’s, avoiding overflow). This results in the ability to use only the much simpler and smaller arithmetic units instead of the larger floating-point units. ​ ​The physical space needed for float32 operation much larger than for int8. This results in:​ Lower power consumption, ​ Less heat development, ​ The ability to join more calculation units decreasing inference time. Prerequisite To create the code on your PC first, we recommend using Anaconda with a virtual environment running Python 3.6, TensorFlow 2.x, numpy, opencv-python and pandas. Post training quantization with TensorFlow Version 2.x If you created and trained a model via tf.keras there are three similar ways of quantizing the model. First Method — Quantizing a Trained Model Directly The trained TensorFlow model has to be converted into a TFlite model and can be directly quantize as described in the following code block. For the trained model we exemplary use the updated tf,keras_vggface model based on the work of rcmalli . The transformation starts at line 28. from keras_vggface_TF.utils import preprocess_input from keras_vggface_TF.vggfaceTF import VGGFace converter.inference_output_type = tf.int8 import tensorflow as tf import numpy as np tfVersion=tf.version.VERSION.replace(".", "") # can be used as savename print(tf.version.VERSION) # TRAIN A MODEL pretrained_model = VGGFace(model='resnet50', include_top=False, input_shape=(224, 224, 3), pooling='avg') # pooling: None, avg or max #Create a generator for representative Dataset folderpath='./All_croped_images/' def prepare(img):          img = np.expand_dims(img,0).astype(np.float32)          img = preprocess_input(img, version=2) return img repDatagen=tf.keras.preprocessing.image.ImageDataGenerator(preprocessing_function=prepare) datagen=repDatagen.flow_from_directory(folderpath,target_size=(224,224),batch_size=1) def representative_dataset_gen():       for _ in range(10):       Img = datagen.next()       yield [img[0]] #CONVERT YOUR MODEL TO TFLITE AND QUANTIZE TO INT8 converter = tf.lite.TFLiteConverter.from_keras_model(pretrained_model) converter.optimizations = [tf.lite.Optimize.DEFAULT] converter.representative_dataset = representative_dataset_gen converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8] converter.experimental_new_converter = True converter.target_spec.supported_types = [tf.int8] converter.inference_input_type = tf.int8 quantized_tflite_model = converter.convert() #SAVE THE QUANTIZED MODEL AS TFLITE FILE open('quant_model.tflite' , "wb").write(quantized_tflite_model) After loading/training your model you first have to create a representative data set. The representative data set is used by the converter to get the max and min values to be able to estimate the scaling factor. This limits the error introduced by the quantization from float32 to intX. The error comes from the different number-space of float and int. Converting from float to int8 limits the number-space to integer values between -128 to 127. Calibrating the model on the dynamic range of the input limits this error. Here you can just loop through your images or create a generator as in our example. We used the tf.keras.preprocessing.image.ImageDataGenerator() to yield images and do the necessary prepossessing on the images. As a generator you can of course also use the tf.data.Dataset.from_tensors() or … from.tensor_slices(). Just keep in mind to do the same pre-processing on your data here as you did on the data you trained your network with (normalization, resizing, de-noising, …). This can all be packed into the preprocessing_function call of the generator (line 19). The conversion starts at line 28. A simple TensorFlow lite conversion would look like this: converter = tf.lite.TFLiteConverter.from_keras_model(pretrained_model) tflite_model = converter.convert() open('model.tflite' , "wb").write(tflite_model) The quantization part is in-between: converter = tf.lite.TFLiteConverter.from_keras_model(pretrained_model) converter.optimizations = [tf.lite.Optimize.DEFAULT] converter.representative_dataset = representative_dataset_gen converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8] converter.experimental_new_converter = True converter.target_spec.supported_types = [tf.int8] converter.inference_input_type = tf.int8 converter.inteference_output_type=tf.int8 quantized_tflite_model = converter.convert() open('quant_model.tflite' , "wb").write(quantized_tflite_model) Line 3 : optimizations other than default are deprecated. No other options are available at the moment (Year 2020). Line 4 : Here we set the representative data set. Line 5 : Here we make sure that we have a full conversion to int8. Without this option, only the weights and biases would be converted but not the activations. This is used when we only want to reduce the model size. However, our NPU needs full int8 quantization. Having the activations still in floating point would result in overall floating-point and could not run on the NPU. Line 6: Enables MLIR-based conversion instead of TOCO conversion, which enables RNN support, easier error tracking. Line 7: Sets the internal constant value to int8. The target_spec corresponds with the TFLITE_BUILTINS from line 5. Line 9 and 10: Set also the input to int8. This is fully available from TF 2.3 Now if we convert the model using TF2.3 with experimental_new_converter=True inference_input_type=tf.int8 inference_output_type=tf.int8 we receive the following model: However if we do not set the inference_input_type and inference_output_type we receive following model: So the effect is that you can determine which input data type the model accepts and returns. This can be important if you work with an embedded camera, as included with the MX8MPEVK. The mipi camera returns 8bit values, so if you want to spare a conversion to float32 int8 input can be handy. But be aware, if you use a model without prediction layers to gain e.g., embeddings, an int8 output will result in very poor performance. Here an output of float32 is recommended. This shows that each problem needs a specific solution. Second and Third Method — Quantize a Saved Model from *.h5 or *.pb Files If you already have your model, you most likely have it saved somewhere either as an Keras h5 file or a TensorFlow protocol buffer pb. We will quickly save our model using TF2.3: import tensorflow as tf f rom keras_vggface_TF.vggfaceTF import VGGFace pretrained_model = VGGFace(model='resnet50', include_top=False, input_shape=(224, 224, 3), pooling='avg') # pooling: None, avg or max # Saving as a protocol buffer !mkdir -p saved_model pretrained_model.save('saved_model/my_model') #saving as a h5 file (if your Tensorflow Version is < 2.0 use this) !mkdir -p keras_model pretrained_model.save('keras_model/my_model.h5') Following the conversion and quantization is very similar as in Method One. The only difference is how we load the model in with the converter. Either load the model and continue as in Method One. #Load the h5 model pretrained_model = tf.keras.models.load_model('my_model.h5') #Then use the converter as before converter = tf.lite.TFLiteConverter.from_keras_model(pretrained_model) Or load the h5 model directly. When using TensorFlow version 2 and above you have to use a compatible converter: # Or load the h5 model from file # TensorFlow version >2.x converter = tf.compat.v1.lite.TFLiteConverter.from_keras_model_file(saved_model_dir + h5_modelname) #works now also with TF2.x # TensorFlowversion < 2.0 converter = tf.lite.TFLiteConverter.from_keras_model_file(saved_model_dir + h5_modelname) If you load from a TensorFlow pb file use: # Or load the pb file from the modelfolder # TensorFlow version >2.x converter = tf.lite.TFLiteConverter.from_saved_model(saved_model_dir) # the folder contains the pb file and a assets and variables folder Converting with TensorFlow Versions below 2.0 If you want to convert a model written in TensorFlow version < 1.15.3 using Keras, not all options are available for TFlite conversion and quantization. The best way is to save the model with the TensorFlow version it was created in (e.g., rcmalli keras-vggface was trained in TF 1.13.2). I would suggest not using the “saving and freeze graph” method to create a pb file as the pb files differ between TF1 and TF2. The TFLiteConverter.from_saved_model does not work, creating quite a hassle to achieve quantization. I would suggest using the above mentioned method using Keras: import keras …. pretrained_model.save('my_model.h5') Then convert and quantize your model with a TensorFlow version from 1.15.3 onward. From this version on a lot of functions where added in preparation for TF2. I suggest using the latest version. This will result in the same models presented here.          

KW43 Knowledge Hub The KW43 product family is a low-power, secure, single-chip wireless MCU that integrates a high performance, Bluetooth Low Energy, Bluetooth Channel Sounding, EdgeLock Secure Accelerators, and various MCU peripherals targeted for Automotive applications. The KW43 family utilizes an Arm® Cortex®-M33 core (Armv8-M architecture) running up to 96 MHz for customer applications. The family includes memory configurations of up to 1.5MB flash and 256 KB SRAM across all listed part numbers. All devices in the family integrate a state-of-the-art, scalable security architecture including Arm’s TrustZone®-M, a resource domain controller and an isolated EdgeLock Secure Accelerators supporting hardware cryptographic accelerators, random number generators and key generation, storage, and management along with secure debug. All members of the KW43 family are designed to be compliant to a SESIP Level 3 certification following the Arm PSA Level 3 profile. KW43 uses dual Arm Core Cortex-M33 (‘CM33’) and supports multiple interfaces and security features. One is for application and system use and other is for radio link layer and both cores share a common flash of 1.5 MB. The devices include a full certified Bluetooth LE 6.x controller stack with support for up to 10 simultaneous connections in any controller/peripheral combination. The multiprotocol radio subsystem integrated in the KW43 Family is energy efficient and is designed for Wi-Fi coexistence. The radio is supported with tested software stacks for Bluetooth Low Energy for standalone and hosted applications to enable a range of Automotive, IoT and industrial applications. There is also software and hardware support for 2.4 GHz proprietary protocols. To address ranging requirements, the Localization Engine (LCE) is integrated into the system for enhanced localization performance. The KW43 series is supported by the MCUXpresso Developer Experience to optimize, ease and help accelerate embedded system development. Early access program The KW43 is in pre-production, developers can get started today with the KW45/KW47, which is pin and software compatible.   you can request access contacting NXP sales team - Pascal Bernard ([email protected]) Join KW47 early access program here: KW43 Early Access Training Bluetooth Low energy 6.0 NXP Introduction Interested in Bluetooth technology? Bluetooth® Low Energy Primer – Essential reading for understanding BLE fundamentals. Bluetooth® Specifications – Full list of standards, protocols, and technical documents. Awards and Recognition - Every year, the Bluetooth Special Interest Group (SIG) celebrates the hard work and commitment of working groups, committee members, and contributors who have been recognized by their peers as making a difference in advancing Bluetooth technology.                2024: Channel Sounding              2025: Channel sounding amplitude-based attack resilience, LE test mode enhancements and Ranging profile and service.  Bluetooth Feature Overview Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview Bluetooth_6.1_Feature_Overview Bluetooth_6.2_Feature_Overview Bluetooth_6.3_Feature_Overview Bluetooth Core Specification Core Specification 4.0 Core Specification 4.1 Bluetooth 4.1 FAQ Core Specification 4.2 Bluetooth 4.2 FAQ Core Specification 5.0 Core Specification 5.1 Core Specification 5.2 Core Specification 5.3 Core Specification 5.4 Core Specification 6.0 Core Specification 6.1 Core Specification 6.2 Core Specification 6.3 RF Switch Comparison Absorptive/Reflective Standards Comparison ETSI / FCC / ARIB requirements BLE Channel Sounding  - Overview BLE Channel Sounding - RF Hardware BLE Channel Sounding - ANSYS Modeling Tools  BLE Channel Sounding - Antenna Prototypes Validation Measurements Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development  Useful Links How to import and run demo examples with MCUXpresso for Visual Studio Code: This article gives information on how to import and run demo examples from the new SDK with ARM GCC toolchain, in MCUXpresso for Visual Studio Code. [MCUXSDK] How to use GitHub SDK for KW4x, MCXW7x, MCXW2x - NXP Community this community post provides step by step how to use GitHub SDK [MCUXSDK] GitHub SDK - Documentation for Bluetooth LE platforms - NXP Community this community post provides the documentation for BLE platforms.  How to use the HCI_bb on Kinetis family products and get access to the DTM mode:  This article is presenting two parts: How to flash the HCI_bb binary into the Kinetis product. Perform RF measurement using the R&S CMW270 BLE HCI Application to set transmitter/receiver test commands: This article provides the steps to show how user could send serial commands to the device. Bluetooth LE HCI Black Box Quick Start Guide: This article describes a simple process for enabling the user controls the radio through serial commands. KW43

KW45ナレッジハブ KW45の3コア・アーキテクチャには、96 MHzのCM33アプリケーション・コア、専用のCM3無線コア、分離型のEdgeLockセキュア・エンクレーブが統合されています。専用のSRAMを備えたフラッシュ・ベースの無線コアにより、高度な設定とアップグレードが可能なソフトウェア実装の無線が得られ、メイン・コア上のリソースをお客様のアプリケーション領域に活用できます。 Bluetooth Low Energy 5.3準拠の無線は、最大24のセキュアな同時接続に対応しています。EdgeLockセキュア・エンクレーブの分離された実行環境は、一連の暗号化アクセラレータ、キー・ストア処理、セキュアなライフサイクル管理を備え、メイン・コアのセキュリティ負荷を最小限に抑えます。 さらに、KW45 MCUにはFlexCANが搭載され、車載用または産業用CAN通信ネットワークへのシームレスな統合を実現できます。FlexCANモジュールは、CANのフレキシブル・データ・レート（CAN FD）に対応でき、帯域幅の拡大とレイテンシの低減に役立ちます。 KW45のブロック図 KW45アーキテクチャブロック図 書類 リファレンス・マニュアル Datasheet Errata Secure Referenceマニュアル** 認証 SESIP認定 SESIP ST PSA認証 RED 認証 欧州連合適合宣言書（EVK） 欧州連合適合宣言書（LOC） 日本MIC KW45-LOC _TELEC-20250221 添付ファイルをご覧ください Bluetooth仕様 Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview Bluetooth_5.2_機能_概要 Bluetooth_5.3_機能_概要 Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview 評価ボード KW45 KW45-EVK KW45-EVK回路図 KW45-EVK 設計ファイル KW45-EVKユーザー・マニュアル KW45-LOCユーザーマニュアル KW45-EVKスタート・ガイド アプリケーション・ノート ソフトウェア、ハードウェア、ペリフェラル： AN14122：KW45でのRTCの使用方法 このアプリケーション・ノートでは、BLEデモでRTCペリフェラルを構成および使用する方法について説明します。 AN14141：KW45 Bluetooth Low Energy用接続スタックでウォッチドッグ・タイマ・モジュールを有効にする このアプリケーション・ノートでは、接続スタック・デモにWDOGタイマを実装するプロセスについて説明します。 AN13855：KW45/K32W1でOTAPクライアント・サービスをBluetooth LEペリフェラル機器に統合する このアプリケーション・ノートでは、Over the Air Programming（OTAP）クライアント・サービスをBLEペリフェラル機器に統合するステップとプロセスを説明します。 AN13584：Kinetis KW45およびK32W1ロードプル・レポート このアプリケーション・ノートでは、ロードプル特性での測定方法と関連する結果について説明します。 AN13860：OTAPツールを使用してKW45/K32W1にファームウェアの更新イメージを作成する このアプリケーション・ノートでは、OTAPを使ってKW45ボードでイメージを作成および更新するステップについて説明します。 AN14077：KW45（1MB）からKW45（512kB）に移行するステップ このアプリケーション・ノートでは、1MBフラッシュから512kBフラッシュへの移行に必要な初期ステップについて説明します。 電力管理： AN13230：Kinetis KW45およびK32W1 Bluetooth LEの電力消費分析 このアプリケーション・ノートでは、KW45ワイヤレスMCUの電力消費、ハードウェアの設計、低電力動作向けの最適化に関する情報を紹介します。 AN13831：KW45/K32W1電力管理ハードウェア このアプリケーション・ノートでは、KW45/K32W1 MCUで電力管理専用の各種モジュールの使用方法について説明します。 RF： AN13687：K32W1による802.15.4アプリケーションの接続テスト このアプリケーション・ノートでは、K32W1 802.15.4のRF性能を実行するために接続テスト・ツールを使用する方法について説明します。 AN13728：KW45 RFシステムでのBluetooth LEおよびIEEE 802.15.4アプリケーションの評価レポート このアプリケーション・ノートでは、BLE（2FSK変調）およびIEEE 802.15.4（OQPSK変調）でKW45ボードを使用する場合の無線周波数（RF）評価テストの結果を報告します。テストの実行時に使用可能なセットアップとツールについても説明します。 AN14098：KW45-LOC RFテスト・レポート このアプリケーション・ノートでは、KW45B41Zローカライゼーション・ボードの基本的なRFテストの結果を報告します。  AN13228：KW45-EVK RFシステムでのBLEアプリケーションに関する評価レポート このアプリケーション・ノートでは、2つの周波数シフト・キー変調を用いて、BLEアプリケーションでKW45B41Z-EVKを使用する場合のRF評価テストの結果を報告します。 AN13229：BLEアプリケーションで、KW45-EVKとRFシステムの共存に関する評価レポート このアプリケーション・ノートでは、KW45B41Z-EVKをBLEアプリケーション（2FSK変調）で使用する場合のRF評価テストの結果を報告します。 AN13512：Kinetisワイヤレス・ファミリ製品のBLEとWi-Fiアプリケーションとの共存 このアプリケーション・ノートでは、K32W1/4X低エネルギー製品のWi-Fi信号に対する耐性、およびWi-Fiとの共存状態の改善方法を取りあげます。  セキュリティ: AN13859：KW45/K32W1システム内プログラミング（ISP）ユーティリティ このアプリケーション・ノートでは、ISPモードでKW45/K32W1 MCUを起動するステップと、MCUと通信するために多様なシリアル接続を確立するステップについて説明します。 AN1403：量産時に、シリアル・ワイヤ・デバッグ（SWD）を介してアプリケーションと無線ファームウェア用にKW45フラッシュをプログラミングする このアプリケーション・ノートでは、量産時にSWDを介して必要なすべての設定を書き込み、焼き込み、プログラミングするステップについて説明します。  AN13883：SPSDKを使用してISP経由でKW45無線ファームウェアを更新する このアプリケーション・ノートでは、ISPモードでKW45/K32W1 MCUを起動するステップと、セキュア・バイナリで無線ファームウェアを更新するステップを説明します。 AN14109：SECツールを使用してKW45およびK32W148セキュアにブートするこのアプリケーション・ノートでは、SEC GUIツールで署名済みイメージとセキュア・バイナリを使用して、KW45/K32W1 MCUをセキュアにブートするステップを説明します。 AN13838：SPSDKコマンド・ライン・ツールを使用してKW45およびK32W148をセキュアにブートする このアプリケーション・ノートでは、SPSDKコマンド・ライン・ツールで署名済みイメージとセキュア・バイナリを使用して、KW45/K32W1 MCUをセキュアにブートするステップを説明します。 AN13931：KW45およびK32W148でのライフサイクルを管理する このアプリケーション・ノートでは、SEC GUIとSPSDKコマンド・ライン・ツールを使用してKW45/K32W1 MCUのライフサイクルを移行するステップを説明します。  AN14174：NPXを使用して、KW45/K32W148のフラッシュ暗号化を実行する このアプリケーション・ノートでは、KW45/K32W1 MCUでオンザフライ暗号化を有効にするステップを説明します。 AN14158：KW45/K32W148で認証をデバッグするこのアプリケーション・ノートでは、フィールドでアプリケーションをセキュアにデバッグするためにデバッグ認証を実行する方法を説明します。  AN14544：MPUおよびMCU向けのEdgeLock 2GOサービス このアプリケーション・ノートでは、NXPデバイス向けのEL2GOサービスを紹介します。このサービスにより信頼できない環境でも信頼できる形でデバイスをプロビジョニングできます。  サポート KW45に関して疑問点がある場合は、ワイヤレスMCUコミュニティ（こちら）に質問を投稿しましょう！ 便利なリンク リファレンスデザイン - NXP Community ［MCUXSDK］KW4x、MCXW7x、MCXW2xにGitHub SDKを使用する方法 - NXPコミュニティ GitHub SDKの使用方法をステップ別に紹介しています。 ［MCUXSDK］GitHub SDK - Bluetooth LEプラットフォームのドキュメント - NXPコミュニティ BLEプラットフォーム用ドキュメントを提供しています。  KW45/KW47/MCXW71/MCXW72でのSignal Frequency Analyzer（SFA）モジュールを使用したクロック測定 - NXPコミュニティ：このコミュニティでは、Signal Frequency Analyzerの使用方法に関する手順を提示しています。 KW45（自動車）またはK32W1/MCXW71（IoT/産業）で初めてPCBを適切に構築する最良の方法... コミュニティ ： KW45またはK32W148、およびMCXW7を使用してPCBを構築するためのリンクと、無線性能、低電力、無線認証（CE/FCC/ICC）に関するあらゆる要素を掲載しています。 HCI_bbをKinetisファミリ製品で使用してDTMモードにアクセスする方法：この記事は次の2つの部分に分かれています。 HCI_bbバイナリを Kinetis製品へフラッシュする方法。 R&S CMW270を使用してRF測定を行う BLE HCIアプリケーションによるトランスミッタ/レシーバテストコマンドの設定：この記事では、ユーザーはどのようにすればシリアルコマンドをデバイスに送信できるかを示す手順を説明します。 Bluetooth LE HCI Black Boxクイックスタートガイド：この記事では、ユーザーが無線をシリアルコマンドで制御できるようにするためのシンプルなプロセスを説明します。 Kinetis（K32/38/KW45およびK32W1/MCXW71）パワー・プロファイル・ツール：Kinetis（KW35/KW38/KW45）およびMCX W7x（MCX W71）パワー・プロファイル・ツールに的を絞ったページです。お使いのアプリケーション（自動車またはIoT）での電力消費量を試算したり、ソリューションのバッテリ寿命を評価したりするのに役立ちます。 KW45/K32W1 32MHzおよび32kHzの発振余裕度：この記事では、回路の発振余裕度の適切な構成について説明しています。 KW45ベースのCSの1対多デモ NXP - チャネル・サウンディング   トレーニング BLE Introduction  RFスイッチの比較 吸収型と反射型 規格の比較 ETSI/FCC/ARIB要件 BLEチャネルサウンディング - 概要 BLEチャネル・サウンディング - RFハードウェア BLEチャネル・サウンディング - ANSYSモデリング・ツール BLEチャネル・サウンディング - アンテナのプロトタイプの検証測定 機器 ワイヤレス機器：この記事には、プロジェクト策定に役立つ機器へのリンクが掲載されています。 開発ツール  SDKビルダ： MCUXpresso SDKは、オープンソースのドライバ、ミドルウェア、リファレンス例のアプリケーションを提供し、ソフトウェア開発を加速させます。 SDK GitHub：GitHubで公開されているSDKのオープンソースのドライバ、ミドルウェア、リファレンス例 NXP MCUXpresso：MCUXpresso IDEは高度な編集、コンパイル、デバッグ機能を提供し、MCU固有のデバッグ機能も追加されています。すべての汎用Arm Cortex-Mとの接続をサポートします。 NXP SPSDK：信頼性が高く使いやすいPython SDK統合ライブラリです。NXP MCUポートフォリオ全体で動作するので、お客様のクイックプロトタイピングから本番環境デプロイまで対応する強力な基盤となります。 NXP SECツール：GUIベースのアプリケーションMCUXpresso Secure Provisioning Toolは、NCP MCUデバイスのブータブル実行ファイルの生成とプロビジョニングをシンプル化するものです。 NXP OTAP Tool：ユーザーがNXP開発ボードのOver-the Air)ファームウェア・アップデートを実行するのに役立つアプリケーションです。 Config Tool： 構成ツールの統合スイート「MCUXpresso Config Tools」を利用すると、開発者はカスタムSDKをすばやく構築したり、ピン、クロック、ペリフェラルを利用して初期化Cコードを生成したり、カスタム・ボード・サポート用の値を登録したりできます。 ワイヤレスMCU用のSDKの例：ワイヤレスの例では、多くの一般的なBluetooth構成を取りあげています。 **セキュア・ファイルには追加のアクセス権をリクエストする必要があります。  ハンズオン・トレーニング 製品: K32W1 プロトコル：802.15.4 プロトコル：BLE→コネクティビティ プロトコル：Bluetooth プロトコル：Matter プロトコル：Thread プロトコル：Zigbee

KW45 Knowledge Hub KW45’s three-core architecture integrates a 96 MHz CM33 application core, dedicated CM3 radio core and an isolated EdgeLock Secure Enclave. The Flash-based radio core with dedicated SRAM delivers a highly configurable and upgradeable software-implemented radio, freeing resources on the main core for customer application space. The Bluetooth Low Energy 5.3-compliant radio supports up to 24 simultaneous secure connections. The EdgeLock Secure Enclave’s isolated execution environment provides a set of cryptographic accelerators, key store operations and secure lifecycle management that minimizes main core security responsibilities. The KW45 MCU additionally integrates FlexCAN, helping enable seamless integration into an automobile’s in-vehicle or industrial CAN communication network. The FlexCAN module can support CAN’s flexible data rate (CAN FD) for increased bandwidth and lower latency. KW45 Block Diagram KW45 Architecture Block Diagram Documents Reference Manual Datasheet Errata Secure Reference manual** Security Certifications  SESIP Level 2 Cert SESIP Level 2 ST PSA Level 2 Certification Regulatory Certifications RED Certification EUROPEAN UNION DECLARATION OF CONFORMITY (EVK) EUROPEAN UNION DECLARATION OF CONFORMITY (LOC) Japan MIC KW45-LOC _TELEC-20250221 Bluetooth Qualifications Qualified Products | Bluetooth® Technology Website Qualification Workspace - KW45/MCX W71 Bluetooth IInterested in Bluetooth technology? Bluetooth® Low Energy Primer – Essential reading for understanding BLE fundamentals. Bluetooth® Specifications – Full list of standards, protocols, and technical documents. Awards and Recognition - Every year, the Bluetooth Special Interest Group (SIG) celebrates the hard work and commitment of working groups, committee members, and contributors who have been recognized by their peers as making a difference in advancing Bluetooth technology, like NXP! 2024: Channel Sounding 2025: Channel sounding amplitude-based attack resilience, LE test mode enhancements and Ranging profile and service.  Bluetooth Feature Overview Bluetooth_5.0_Feature_Overview  Bluetooth_5.1_Feature_Overview  Bluetooth_5.2_Feature_Overview Bluetooth_5.3_Feature_Overview Bluetooth_5.4_Feature_Overview Bluetooth_6_Feature_Overview Bluetooth_6.1_Feature_Overview Bluetooth_6.2_Feature_Overview Bluetooth_6.3_Feature_Overview Bluetooth Core Specification Core Specification 4.0 Core Specification 4.1 Bluetooth 4.1 FAQ Core Specification 4.2 Bluetooth 4.2 FAQ Core Specification 5.0 Core Specification 5.1 Core Specification 5.2 Core Specification 5.3 Core Specification 5.4 Core Specification 6.0 Core Specification 6.1 Core Specification 6.2 Core Specification 6.3 Evaluation boards KW45 KW45-EVK KW45-EVK Schematic KW45-EVK Design Files KW45-EVK User manual KW45-LOC User manual KW45-EVK Getting Started Application Notes Software, Hardware and Peripherals: AN14122 : How to use RTC on KW45 This application note describes how to configure and use the RTC peripheral in a BLE demo AN14141 : Enabling Watchdog Timer Module on KW45 Bluetooth Low Energy Connectivity Stack This application note describes the process to implement the WDOG timer in a Connectivity Stack demo. AN13855 : KW45/K32W1 Integrating the OTAP Client Service into a Bluetooth LE Peripheral Device This Application note provides the steps and process for integrating the Over the Air Programming Client Service into a BLE peripheral device. AN13584 : Kinetis KW45 and K32W1 Loadpull Report This application note describes measurement methodology and associated results on the load-pull characteristics. AN13860 : Creating Firmware Update Image for KW45/K32W1 using OTAP tool This application note provides the steps to create and upgrade the image on the KW45 board via OTAP. AN14077 : Steps to migrating KW45 (1MB) to KW45 (512kB) This application note describes the initial steps require to migrate from 1MB flash to 512kB flash. AN14746 : EEPROM Emulation for the KW45B41Z and K32W148 This document describes the process for the EEPROM emulation for the KW45B41Z and K32W148. AN14298 32kHz Cystal-Less Mode on KW45: This application note provides information on the 32 kHz Crystal-less mode on the KW45 device. This mode allows you to reduce the cost of the system, without compromising the 32 kHz clock accuracy.  AN13227 Hardware Design Considerations for KW45B41Z and K32W148 Bluetooth LE Devices: This application note describes printed-circuit board (PCB) design considerations for the KW45B41Z83AFTA, and KW45B41Z82AFTA and K32W1480VFTAT MKW35A, MKW36A, MKW35Z, and MKW36Z 40-pin HVQFN (6x6) and 48-pin Laminated QFN (HVLQFN-7x7 pitch 0.5 mm) wettable flank) package and KW45B41Z83AFPA and KW45B41Z82AFPA MKW35A, MKW36A, MKW35Z, and MKW36Z 40-pin HVQFN (6x6) and 40-pin Laminated QFN (HVLQFN-6x6 pitch 0.5 mm) wettable flank) package Power Management: AN13230: Kinetis KW45 and K32W1 Bluetooth LE Power Consumption Analysis This application note provides information about the power consumption of KW45 wireless MCUs, the hardware design and optimized for low power operation. AN13831: KW45/K32W1 Power Management Hardware This application note describes the usage of the different modules dedicated to power management in the KW45/K32W1 MCU. AN14664 Coin cell Hardware Recommendations for Kinetis Bluetooth LE Applications: This document describes some hardware and software solutions to minimize the peaks of current at the coin cell level RF: AN13687 : K32W1 Connectivity test for 802.15.4 Application This application note describes how to use the connectivity test tool to perform K32W1 802.15.4 RF performance. AN13728 : KW45 RF System Evaluation Report for Bluetooth LE and IEEE 802.15.4 Applications This application note provides the radio frequency evaluation test results of the KW45 board for BLE (2FSK modulation) and for IEEE 802.15.4 (OQPSK modulation) applications. Also describes the setup and tools that can be used to perform the tests.  AN14098: KW45-LOC RF Test Report This application note provides basic RF test result of the KW45B41Z localization board.  AN13228 : KW45-EVK RF System Evaluation Report for BLE Applications This application note provides the RF evaluation test result of the KW45B41Z-EVK for BLE application using two frequency Shift Keying modulation. AN13229 : KW45-EVK Co-existence with RF System Evaluation Report for BLE application This application note provides the RF evaluation test results of the KW45B41Z-EVK for BLE application (2FSK modulation) AN13512 : Kinetis Wireless Family Products BLE Coexistence with Wi-Fi Application This application note provides the K32W1/4X low energy family products immunity on Wi-Fi signals and methods to improve coexistence with Wi-Fi  AN14294 : Out of Band Implementation with KW45 This document explains the steps required to set up an Out of Band (OOB) pairing connection between two KW45 EVK boards, using UART and CAN communication interfaces to share OOB data. AN2731 Compact Planar Antennas for 2.5GHz Communication: This document is not an exhaustive inquiry into antenna design. It is instead focused on helping the customers understand enough board layout and antenna basics to select a correct antenna type for their application, as well as avoiding typical layout mistakes that cause performance issues that lead to delays AN14645 How to Use Random Static Device Address for Bluetooth Application: This document introduces how to enable Random Static Device Address for a Bluetooth Low Energy application. The default device address type in the SDK is Public Device Address. AN14112 Car Connectivity Consortium (CCC) Digital Key R3 - Bluetooth LE Vehicle Keyless Access System: This document provides a hardware and software platform to implement a simple CCC Digital Key Release 3.0 system. The hardware and software components of this system allow the user to get familiar with the CCC Digital Keys R3 specification and how it can be implemented using NXP products and tools. AN13953 Integrating NFC Reader Library in a KW4X Bluetooth Low Energy Application:  This document gives instructions on how to create a Bluetooth Low Energy (Bluetooth LE) project for the EVK-KW45 development board and MCUXpresso IDE, and how to integrate NFC Reader Library. AN13049 Wi-Fi/Bluetooth/802.15.4 M.2 Key E Pinout Definition: This document defines M.2 usage for both NXP Wi-Fi/Bluetooth and Tri-Radio M.2 module design Security: AN13859 : KW45/K32W1 In-System Programming Utility This application note provides steps to boot KW45/K32W1 MCU in ISP mode and establish various serial connections to communicate with the MCU. AN14003 : Programming the KW45 Flash for Application and Radio Firmware via Serial Wire Debug during mass production This application note describes the steps to write, burn and programming all the necessary settings via SWD in mass production.  AN13883 : Updating KW45 Radio Firmware Via ISP Using SPSDK This application note provides steps to boot KW45/K32W1 MCU in ISP mode and update the radio firmware with secure binary. AN14109 : KW45 and K32W148 Secure  Boot Using the SEC Tool This application note provides steps to do secure boot KW45/K32W1 MCU using signed images and secure binaries on the SEC GUI tool. AN13838 :  KW45 and K32W148 Secure  Boot Using the SPSDK Command line Tool This application note provides steps to do secure boot KW45/K32W1 MCU using signed images and secure binaries on the SPSDK command line tool. AN13931 : Managing Lifecycles on KW45 and K32W148 This application note provides steps to do transition lifecycles KW45/K32W1 MCU using the SEC GUI and SPSDK command line tools.  AN14158: Debug Authentication on KW45/ K32W148 This application note describes how to do debug authentication to securely debug an application in the field.  AN14544 : EdgeLock 2GO Services for MPU and MCU This application note introduces the EL2GO services for NXP devices. This allows trust provisioning of the device in an untrusted environment.  AN14174: KW45/K32W1 Flash Encryption using NPXThis application note provides steps to do enable on-the-fly encryption on KW45/K32W1 MCU. AN14158: debug authentication on KW45/K32W148 This application note describes the steps for debug authentication using the Secure Provisioning SDK tool (SPSDK). AN15038 EdgeLock 2GO Provisioning MCUs via Product Type using Secure Provisioning (SEC) Tool:  This document offers an outline of the EdgeLock 2GO platform and discusses the "Device provisioning via product type" flow. The document focuses on the initial device provisioning using secure objects from the EdgeLock 2GO cloud server. AN14670  EdgeLock 2GO Provisioning via SPSDK for MCUs: This document offers an outline of the EdgeLock 2GO platform and discusses the “Device provisioning via proxy” flow. The document focuses on the initial device provisioning using secure objects from the EdgeLock 2GO cloud server.  AN14624 EdgeLock 2GO Provisioning via Secure Provisioning Tool (SEC) for MCUs: This document offers an outline of the EdgeLock 2GO platform and discusses the "Device provisioning via proxy" flow. Useful Links [MCUXSDK] How to use GitHub SDK for KW4x, MCXW7x, MCXW2x - NXP Community this community post provides step by step how to use GitHub SDK [MCUXSDK] GitHub SDK - Documentation for Bluetooth LE platforms - NXP Community this community post provides the documentation for BLE platforms.  Clock Measuring using the Signal Frequency Analyzer (SFA) module for KW45/KW47/MCXW71/MCXW72 - NXP Community : this community provides the steps on how to use the Signal Frequency Analyzer  The best way to build a PCB first time right with KW45 (Automotive) or K32W1/MCXW71 (IoT/Industrial)... Community : In this community provides the important link to build a PCB using a KW45 or K32W148 and MCXW71 and all concerning the radio performances, low power and radio certification (CE/FCC/ICC) How to use the HCI_bb on Kinetis family products and get access to the DTM mode:  This article is presenting two parts: How to flash the HCI_bb binary into the Kinetis product. Perform RF measurement using the R&S CMW270 BLE HCI Application to set transmitter/receiver test commands: This article provides the steps to show how user could send serial commands to the device. Bluetooth LE HCI Black Box Quick Start Guide : This article describes a simple process for enabling the user controls the radio through serial commands. Kinetis (../45/47/43;MCX W71/72/70) & MCX W23 Power Profile Tools (including Localization):  This page is dedicated to the Kinetis (KW35/KW38/KW45/KW47/KW43) and MCX W7x (MCX W71/W72/W70) Power Profile Tools. It will help you to estimate the power consumption in your application (Automotive or IIoT) and evaluate the battery lifetime of your solution. KW45/K32W1 32MHz & 32kHz Oscillation margins: this article provides the properly configuration for the Oscillation margins for the circuit. KW45/MCXW71 Changing Clocking peripherals from FRO6M to other clock sources:  This article provides a comprehensive guide to selecting and configuring alternative clock sources   Reference Designs Bluetooth Ranging Access Vehicle Enablement System - NXP Community Blue Ravens (Bluetooth Ranging Access Vehicle Enablement System) is a system solution developed by NXP to assist customers in designing their own BLE-based car access solutions using NXP products. Demo (video) KW45 Based CS 1 to Many Demo NXP - Channel Sounding   Training BLE Introduction  RF Switch Comparison Absorptive/Reflective Standards Comparison ETSI / FCC / ARIB requirements BLE Channel Sounding  - Overview BLE Channel Sounding - RF Hardware BLE Channel Sounding - ANSYS Modeling Tools  BLE Channel Sounding - Antenna Prototypes Validation Measurements     Equipment Wireless Equipment: This article provides the links to the Equipment that helps to the project development  Development Tools  SDK builder: The MCUXpresso SDK brings open-source drivers, middleware, and reference example application to speed your software development. SDK GitHub: SDK open-source Drivers, middleware and reference examples in Github NXP MCUXpresso: MCUXpresso IDE offers advanced editing, compiling and debugging features with the addition of MCU-Specific debugging. Supports connections with all general-purpose Arm Cortex-M.  NXP SPSDK: Is a unified, reliable, and easy to use Python SDK library working across the NXP MCU portfolio providing a strong foundation from quick customer prototyping up to production deployment. NXP SEC Tool: The MCUXpresso Secure Provisioning Tool us a GUI-based application provided to simplify generation and provisioning of bootable executables on NCP MCU devices. NXP OTAP Tool: Is an application that helps the user to perform an over the air firmware update of an NXP development board. Config Tool: MCUXpresso Config Tools, an integrated suite of configuration tools, these configuration tools allow developers to quickly build a custom SDK and leverage pins, clocks and peripheral to generate initialization C code or register values for custom board support. SDK Examples for Wireless MCUs: The wireless examples feature many common Bluetooth configurations. **For secure files is necessary to request additional access.  KW45

KW45 知识中心 KW45 的三核架构集成了一个 96 MHz CM33 应用核心、专用 CM3 无线模块内核和一个隔离的 EdgeLock 安全区域。基于闪存的无线模块内核具有专用 SRAM，可提供高度可配置和可升级的软件实施无线模块，从而将主内核上的资源释放给客户应用空间。 符合低功耗蓝牙 5.3 标准的无线模块最多可同时支持 24 个安全连接。EdgeLock 安全区域的隔离执行环境提供了一套加密加速器、密钥存储操作和安全生命周期管理，最大限度地减少了主要内核安全责任。 KW45 MCU 还集成了 FlexCAN，有助于无缝集成到汽车的车载或工业 CAN 通信网络中。FlexCAN 模块可以支持 CAN 的灵活数据传输速率 (CAN FD)，以实现更高带宽和更低延迟。 KW45 方框图 KW45 架构框图 文件 参考手册 Datasheet Errata Secure Reference 手册** 认证 SESIP 认证 SESIP ST PSA认证 RED 认证 欧盟符合性声明 (EVK) 欧盟符合性声明（LOC） 日本 MIC KW45-LOC _TELEC-20250221请参见下方附件 蓝牙规范 蓝牙 5.0 功能概述 蓝牙 5.1 功能概述 蓝牙 5.2 功能概述 Bluetooth_5.3_功能概述 Bluetooth_5.4_功能概述 Bluetooth_6_Feature_Overview 评估板 KW45 KW45-EVK KW45-EVK 原理图 KW45-EVK设计文件 KW45-EVK 用户手册 KW45-LOC 用户手册 KW45-EVK快速入门 应用笔记 软件、硬件和外设： AN14122 ：如何在 KW45 上使用 RTC本应用笔记介绍了如何在 BLE 演示中配置和使用 RTC 外围设备 AN14141：在 KW45 低功耗蓝牙连接堆栈中启用看门狗定时器模块 。本应用笔记描述了在连接堆栈演示中实现 WDOG 定时器的过程。 AN13855：将 OTAP 客户端服务集成到 KW45/K32W1 蓝牙 LE 外围设备中 本应用笔记提供了将空中编程客户端服务集成到 BLE 外围设备的步骤和过程。 AN13584：Kinetis KW45 和 K32W1 负载拉动报告 本应用笔记描述了负载拉动特性的测量方法及相关结果。 AN13860：使用 OTAP 工具为 KW45/K32W1 创建固件更新镜像 本应用笔记提供了通过 OTAP 工具在 KW45 开发板上创建并升级镜像的步骤。 AN14077：将 KW45 (1MB) 迁移至 KW45 (512kB) 的步骤  本应用笔记描述了从 1MB 闪存迁移至 512kB 闪存所需的初始步骤。 电源管理： AN13230：Kinetis KW45 和 K32W1 蓝牙低功耗 (BLE) 功耗分析  本应用笔记提供了关于 KW45 无线微控制器 (MCU) 的功耗信息，包括硬件设计及优化以实现低功耗运行。 AN13831：KW45/K32W1 电源管理硬件  本应用笔记描述了在 KW45/K32W1 微控制器中用于电源管理的不同模块的使用方法。 射频： AN13687：K32W1 802.15.4 应用连接性测试 本应用笔记介绍了如何使用连接性测试工具来测试 K32W1 802.15.4 的射频性能。 AN13728：KW45 射频系统评估报告（适用于蓝牙低功耗和 IEEE 802.15.4 应用）本应用笔记提供了 KW45 开发板在蓝牙低功耗（2FSK 调制）和 IEEE 802.15.4（OQPSK 调制）应用中的射频评估测试结果。还描述了可以用于执行测试的设置和工具。  AN14098: KW45-LOC 射频测试报告  本应用笔记提供了KW45B41Z定位板的基本射频测试结果。  AN13228：用于 BLE 应用的 KW45-EVK 射频系统评估报告 本应用笔记提供了 KW45B41Z-EVK 在 BLE 应用中使用二进制频移键控调制的射频评估测试结果。 AN13229：KW45-EVK 与射频系统共存的评估报告（适用于 BLE 应用）本应用笔记提供了 KW45B41Z-EVK 在 BLE 应用（2FSK 调制）中的射频评估测试结果 AN13512：Kinetis 无线产品系列 BLE 与 Wi-Fi 共存应用  本应用笔记介绍了 K32W1/4X 低功耗产品系列对 Wi-Fi 信号的抗干扰能力，并提供了改善与 Wi-Fi 共存的方法  安全性： AN13859：KW45/K32W1 系统内编程工具  本应用笔记提供了在 ISP 模式下启动 KW45/K32W1 微控制器并建立各种串行连接以与微控制器通信的步骤。 AN1403：在批量生产中通过串行线调试（SWD）为KW45闪存编程以应用和无线固件 。本应用笔记详细介绍了在批量生产中通过SWD编写、烧录和设置所有必要参数的步骤。  AN13883: 通过 SPSDK 使用 ISP 更新 KW45 无线电固件  本应用笔记提供了在 ISP 模式下启动 KW45/K32W1 MCU 并使用安全二进制文件更新无线电固件的步骤。 AN14109：使用SEC工具实现KW45和K32W148安全启动 本应用笔记提供了使用 SEC GUI 工具，通过签名镜像和安全二进制文件实现 KW45/K32W1 MCU 安全启动的步骤。 AN13838：KW45 和 K32W148 安全启动使用 SPSDK 命令行工具本应用笔记提供了使用 SPSDK 命令行工具，通过签名镜像和安全二进制文件实现 KW45/K32W1 MCU 安全启动的步骤。 AN13931：KW45 和 K32W148 的生命周期管理 本应用笔记提供了使用 SEC GUI 和 SPSDK 命令行工具来转换 KW45/K32W1 MCU 的过渡生命周期的步骤。 AN14174：KW45/K32W148 使用 NPX 进行闪存加密本应用笔记提供了在 KW45/K32W1 微控制器上启用实时加密的步骤。 AN14158：KW45/K32W148 上的调试认证本应用笔记介绍了如何进行调试认证，以便在现场安全地调试应用程序。  AN14544：EdgeLock 2GO 服务适用于 MPU 和 MCU 本应用笔记介绍了 NXP 设备的 EL2GO 服务。该服务允许在不受信任的环境中为设备进行信任配置。 支持 如果您对 KW45 有任何疑问，请在我们的无线 MCU 社区中留下您的问题！此处 有用链接 参考设计 - NXP 社区 [MCUXSDK] 如何使用 GitHub SDK 适用于 KW4x、MCXW7x、MCXW2x - NXP 社区此社区帖子逐步介绍了如何使用 GitHub SDK [MCUXSDK] GitHub SDK - 蓝牙 LE 平台文档 - NXP 社区此社区帖子提供了 BLE 平台的文档。  使用 KW45/KW47/MCXW71/MCXW72 的信号频率分析仪 (SFA) 模块进行时钟测量 - NXP 社区：该社区提供了如何使用信号频率分析仪的步骤 首次正确构建 PCB 的最佳方式是使用 KW45（汽车）或 K32W1/MCXW71（物联网/工业）... 社区：在此社区中，您可以找到使用 KW45 或 K32W148 和 MCXW71 构建 PCB 的重要链接，所有链接均涉及无线电性能、低功耗和无线电认证 (CE/FCC/ICC) 如何在 Kinetis 系列产品上使用 HCI_bb 并进入 DTM 模式：本文分为两部分： 如何将HCI_bb二进制文件烧录到Kinetis产品中。 使用 R&S CMW270 进行射频测量 BLE HCI 应用程序设置发射机/接收机测试命令：本文提供了相关步骤，展示用户如何向设备发送串行命令。 Bluetooth LE HCI 黑盒快速入门指南：本文介绍了一个简单流程，能让用户通过串行命令控制无线电。 Kinetis (K32/38/KW45 & K32W1/MCXW71)功率配置工具： 此页面专门介绍 Kinetis (KW35/KW38/KW45) 和 MCX W7x (MCX W71) 功率配置工具。它将帮助您估算您的应用程序（汽车或物联网）的功耗，并评估您解决方案的电池寿命。 KW45/K32W1 32MHz 和 32kHz 振荡裕度：本文提供了电路中振荡裕度的正确配置。 基于 KW45 的 CS 1 对多演示NXP - 信道探测   培训 BLE Introduction  射频开关比较 吸收型/反射型 ETSI / FCC / ARIB 标准比较与要求 BLE 信道探测  - 概述 BLE 信道探测 - RF 硬件 BLE 信道探测 - ANSYS 建模工具 BLE 信道探测 - 天线原型验证测量 设备 无线设备： 本文提供了有助于项目开发的设备链接  开发工具  SDK 构建器： MCUXpresso SDK 提供开源驱动程序、中间件和参考示例应用程序，以加快软件开发。 SDK GitHub：SDK 开源驱动程序、中间件和参考示例在 GitHub 上。 NXP MCUXpresso： MCUXpresso 集成开发环境 (IDE) 提供了高级编辑、编译和调试功能，并增加了 MCU 专用的调试功能。支持与所有通用 Arm Cortex-M 的连接。  NXP SPSDK：是一个统一、可靠且易于使用的Python SDK库，适用于 NXP MCU 产品组合，为客户快速制作原型到生产部署提供坚实的基础。 NXP SEC工具： MCUXpresso安全配置工具是一款基于 GUI 的应用程序，用于简化在 NCP MCU 设备上生成和配置可启动的可执行文件。 NXP OTAP Tool： 是一款帮助用户对 NXP 开发板执行空中固件更新的应用程序。 配置工具： MCUXpresso 配置工具是一套集成的配置工具套件，这些工具允许开发人员快速构建自定义 SDK，并利用引脚、时钟和外设生成初始化 C 代码或自定义板支持的寄存器值。 无线 MCU 的 SDK 示例： 这些无线示例包含许多常见的蓝牙配置。 **对于安全文件，必须请求额外的访问权限。  动手实践培训 产品：K32W1 协议：802.15.4 协议：BLE -> 连接性 协议：蓝牙 协议：Matter 协议：Thread 协议：Zigbee

MFRC531 01T 的设备集成（软件） 我需要将 NXP Mifare 阅读器 (crypto1) MFRC531 01T 集成到系统中，并且我需要一些关于 RS232 相关协议命令的帮助，以便轮询 SID、进行身份验证和读取块/扇区。 Re: Device Integration (Software) for MFRC531 01T 你好@Menspa 遗憾的是，NXP 没有提供基于 MFRC531 的演示示例；因此，您需要参考 MFRC531 数据手册（ MFRC531 标准 ISO/IEC 14443 A/B 读卡器解决方案）并使用 NXP 的 NxpNfcRdLib 库来开发您的读/写卡应用程序。

エマール・ビーチフロントの完成済み4ベッドルームアパートメントを購入するためのステップバイステップの手順 エマールビーチフロントは急速にドバイで最も人気のあるウォーターフロントの目的地の一つとなり、家族や投資家の間で4ベッドルームのアパートメントの需要が高まっています。この島のコミュニティで広々とした入居準備が整った家の購入を検討しているなら、購入プロセスの最初から最後まで理解しておくことで遅延を避け、自信を持って判断できます。 このガイドでは、エマールビーチフロントで4ベッドルームのアパートを購入するための各段階を案内し、ドバイの信頼できる不動産会社タクウェーン・アルダーからの実用的な洞察も添えています。 エマール・ビーチフロントが、すぐに住める4ベッドルームのアパートメントを求める購入者に魅力的な理由 エマールビーチフロントはドバイマリーナとパームジュメイラの間に位置し、プライベートビーチアクセス、リゾートスタイルの施設、スカイラインの眺めを提供しています。ここでの4ベッドルームのアパートは、工事を何年も待たずにより多くの居住空間を求める大家族に適しています。ユニットはすでに建設され引き渡されているため、買い手は実際の物件を検査し、迅速に入居し、賃貸を選べば早く賃貸収入を得始めることができます。 ステップ1：予算と資金調達方法を明確にする リスティングを見る前に、現実的にどれくらいの費用が出せるかを計算しましょう。エマールビーチフロントの4ベッドルームアパートはプレミアムな購入なので、リスティング価格だけでなく全体のコスト面も考慮してください。 次の点を考慮してください。 頭金の要件は、駐在員の場合通常20〜25%です 融資が必要な場合は、UAEの銀行から住宅ローンの事前承認を得てください。 ドバイ土地局の譲渡手数料は、通常、購入価格の4％です。 代理店手数料、通常2パーセント ビルディングおよび地域社会に連動した継続的なサービス料金 早期に住宅ローンの事前承認を得ることで、明確な予算上限ができ、売り手との交渉において自分の立場を強化します。 ステップ2：エマール・ビーチフロントの完成済み物件を絞り込む 予算が決まったら、ニーズに合った、すぐに住める4ベッドルームのアパートを探し始めましょう。エマールビーチフロントにはビーチビスタ、サンライズベイ、ビーチアイルなどのタワーがあるため、建物ごとに利用可能性やレイアウトは大きく異なることがあります。 Takween AlDarのような知識豊富な不動産会社と協力することで、階数、眺望、間取りの効率性、周辺施設への近さなどに基づいて選択肢を絞り込むことができ、最新の在庫状況を反映していない可能性のあるオンラインの物件情報だけに頼る必要がなくなります。 ステップ3：物件の内覧を予約する 完成済みマンションは、未完成物件の購入とは異なり、契約前に実際に物件内を見学することができます。閲覧機能を使って以下の点を確認してください。 実際の部屋のサイズとレイアウトの流れ 仕上げと装備の品質 自然光と眺望の向き 共用エリア、エレベーター、駐車場の状態 以前にその物件が使用されていた場合は、メンテナンス履歴や最近の修理状況について確認してください。 ステップ4：所有権および不動産関連書類の確認 オファーを出す前に、ドバイ土地局を通じて売主の所有権を確認し、権利証を請求してください。担当エージェントは、物件に関連する未払いの住宅ローン、管理費の滞納、または法的紛争がないかどうかも確認する必要があります。この確認手順は、後々の取引におけるトラブルを防ぐためのものです。 ステップ5：覚書を交渉し署名する 物件とドキュメントに満足したら、オファーを提出してください。合意が成立した場合、両当事者はドバイ土地局のTrakheesiシステムを通じて、一般にフォームFとして知られる覚書に署名する。この段階では、通常、購入価格の約10％にあたる手付金を支払います。この手付金は、譲渡手続きが完了するまで保管されます。 ステップ6：異議なし証明書を取得する 売り手は開発者、この場合はEmaarに対して「異議なし証明書」を請求しなければなりません。この証明書は、不動産に未払いのペイメントや制限がないことを確認し、所有権移転の道を切り開きます。プロセッシングは通常数営業日かかり、開発者に料金が支払われます。 ステップ7：ドバイ土地局で譲渡手続きを完了する 異議なし証明書を手に、買主と売主は共にドバイ土地局の事務所、または登録済みの信託センターに出向き、譲渡手続きを完了させる。この面談時に、残高、振込手数料、および適用される諸費用をお支払いいただきます。手続きが完了すると、所有権証書があなたの名義で発行され、正式にあなたがアパートの所有者となります。 ステップ8：公共料金の手続きと入居 移管後は、電気と水道のDEWAに登録し、建物に関連する地域サービスも有効化してください。アパートは準備が整い、入居も準備できているので、工事完了を待たずに引き継ぎ手続きを始め、鍵を受け取り、引っ越しの計画を立てることができます。 Takween AlDarが購入をサポートする方法 エマール・ビーチフロントの即入居可能な4ベッドルームのアパートメントを購入するには複数の手順が必要であり、経験豊富なパートナーがいればストレスとリスクを軽減できます。タクウィーン・アルダールは、物件選び、書類確認、交渉、そして所有権移転に至るまで、購入者を丁寧にサポートし、最初の内覧から最終的な引き渡しまで、透明性と円滑な手続きを保証します。 よくある質問 Q：Emaar Beachfrontで完成済みのマンションを購入するには、どれくらい時間がかかりますか？ A: 資金調達やドキュメントが整っている場合、覚書の署名から権利証書の移転完了まで通常2〜4週間かかります。 Q: 外国人はエマールビーチフロントで4ベッドルームのアパートを購入できますか? A：はい、エマール・ビーチフロントは所有権が完全なフリーホールドエリアに位置しているため、あらゆる国籍の購入者が完全な外国人所有権を取得できます。 質問：物件を見学する前に、住宅ローンの事前承認は必要ですか？ A：必須ではありませんが、事前承認を得ておくことで予算を把握しやすくなり、売り手にとってあなたの提案の信頼性が高まります。 質問：購入価格以外に、どのような費用を予算に組み込むべきでしょうか？ A: 開発業者からはドバイ土地局の譲渡手数料4%、代理手数料2%、そして場合によってはNOCプロセッシング手数料を支払うことを覚悟してください。 Q：エマール・ビーチフロントでは、完成済みのマンションは、未完成の物件よりも良い選択肢でしょうか？ A：完成済みのマンションはすぐに入居でき、購入前に内覧も可能ですが、未完成の物件は購入価格が低い場合もありますが、引き渡しまで待つ必要があります。 まとめ エマール・ビーチフロントで完成済みの4ベッドルーム・アパートメントを購入するには、現実的な予算の設定から書類の確認、ドバイ土地局での所有権移転手続きの完了まで、綿密な計画を立てることが重要なプロセスとなります。適切な指導があれば、買い手は自信を持って各ステップを進め、無駄な遅延なく新しいウォーターフロントの家に落ち着くことができます。Takween AlDarは、最初の物件探しから最終引き渡しまで、この旅のあらゆる段階でサポートいたします。

S32K312：NMI 在 Reset_Handler 执行之前触发，仅在功能（软件）复位之后触发，且仅在特定情况下触发。 设备：S32K312 工具链：Green Hills ELXR（编译器） HSE固件：s32k312_hse_fw_0.13.0_2.55.0_pb250129.bin 调试器：Lauterbach TRACE32 软件：基于AUTOSAR RTD的引导加载程序（FBL）+应用程序（APP），双镜像结构 问题概要 在部分生产单元上，CPU 在执行功能性操作后立即挂起。 （软件）RESET。同样的单位在破坏性 （上电复位）后总能正常启动。在我们的参考/已知良好设备上，不会出现卡顿现象。 证据表明，非军事事件 (NMI) 发生在任何应用程序代码执行之前。 1）在挂起点捕获的 CPU 上下文（自动堆叠的异常帧）： - R0-R3 = 0x00000000，R12 = 0x00000000 - LR = 0xFFFFFFFF（重置默认值 -> 尚未执行任何 BL） - PC = 0x00416904（我们的 Reset_Handler 的第一个指令地址） - xPSR = 0x01000000 2) SCB->ICSR = 0x00000802 Chibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.png - VECTACTIVE[8:0] = 2 -> NMI 是当前活动的异常 - RETTOBASE = 1 这证实 CPU 当前正在 NMI 处理程序内部执行。 3) 我们向量表中的 NMI 偏移量条目正确指向我们自己的 默认异常处理程序，因此这是一个真正的 NMI 事件，而不是向量事件。 表格损坏。 在相同的挂起状态下检查的寄存器（全部读取为干净/非活动状态） - MC_RGM_DES = 0x00000000（非破坏性RESET） - MC_RGM_FES = 0x20000000（仅限第 29 位）（仅限“软件功能RESET”） 标志位已设置，无其他功能 RESET源已标记） - FCCU：STAT、N2AF_STATUS、A2FF_STATUS、N2FF_STATUS、NCF_S0、IRQ_STAT 全部 = 0x00000000 - CMU_FC 实例 0、3、4：SR = 0x00000000（无频率高/低故障） - PMC LVSC = 0x00000000（无 LVD/HVD 标志，已锁存或带电） - ERM (0x4025C000): 无法读取正常单元或故障单元的 ERM 值 （在我们的配置中可能采用时钟门控），因此 ERM 状态未经验证。 问题 1. 除了 FCCU / CMU_FC / PMC / MC_RGM 之外，还有其他 NMI 来源吗？ 这可能会在应用程序的 Reset_Handler 执行之前触发。 第一条指令？ 2. 由于 HSE 子系统独立于应用程序核心运行，因此 应用程序核心功能重置是可能的（但这不会导致） 重置 HSE）以创建状态不匹配，从而触发 NMI。 应用核心？ 3. 是否有与此症状相符的 S32K312 已知勘误表（仅限 NMI） 功能性/软件重置（而非上电复位）？ 任何关于需要检查的其他登记册的指导，或涵盖以下内容的任何文件 非常感谢来自 FCCU / ERM / CMU_FC / PMC 以外的 NMI 信息来源。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， 请您在系统处于挂起状态时读取寄存器 MU_0.MUB CSSR0 和 MU_1.MUB CSSR0，并确认其中任何一个寄存器的第 0 位（NMIC）是否已设置？ 谢谢 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek ， 感谢您指出 MU_0.MUB / MU_1.MUB CSSR0。 MU_0.MUB 和 MU_1.MUB 上的 CSSR0（位 0，NMIC）均读取 0x00000000。 单元处于挂起状态，因此 MU->NMI 请求路径 (CCR0[NMI] / CSSR0[NMIC]) 似乎并非待处理。 然而，在比较已知良好单元和一台设备之间的MU寄存器时， 故障单元（两者均在相同的挂起状态地址范围内捕获）， 我们发现了一个始终存在的差异： 正常单元 故障单元 MU_0.MUB 版本 0x0300000F 0x0300000F（相同） MU_0.MUB PAR 0x20200404 0x20200404（相同） MU_0.MUB CR 0x00000000 0x00000000（相同） MU_0.MUB SR 0x00000000 0x00000002 <- MURIP 集 MU_1.MUB VER/PAR/CR：正常单元和故障单元完全相同 MU_1.MUB SR 0x00000000 0x00000002 <- MURIP 集 因此，在两个 MU 实例上，SR 位 1 (MURIP) 仅在发生故障的实例上设置。 单位，始终如一。根据参考手册，MURIP 指出： “处理器 A”已发出 MU 复位，且只能通过以下方式清除： 系统重置（非 MU 重置）。 由于 CPU 在执行任何操作之前都会在 NMI 处理程序内部冻结，因此无法执行任何操作。 应用程序代码本身无法清除此标志，因此它 必须在启动序列之前（或作为启动序列的一部分）设置。 我们非常希望您能就以下问题提供意见： 1.对于 MU_0.MUB 和 MU_1.MUB，哪个处理器是“处理器 A”（即 谁制定 MURIP？我们的头部信息仅暴露了“MUB”寄存器块。 应用程序核心可访问地址——这是否意味着 应用程序核心始终是“处理器 B”，而 HSE 是“处理器 A”。 在这些情况下呢？ 2. “系统RESET”（清除 MURIP 所必需的操作）是否包含功能/软件 是RESET应用核心，还是仅进行破坏性/上电RESET？如果 MURIP 无法通过我们的功能 RESET 清除，这就能解释为什么了。 SW RESET 后该设置保持不变，但开机后则清除。 3. 独立于 NMI 问题：MURIP 标志本身是否已设置/卡住 在正常运行期间，这是预期之内的还是被认为是异常的？ 4. 由于 CSSR0[NMIC] 当前读取值为 0，硬件是否有可能…… NMI 例外条目出现时是否自动清除 NMIC，还是仅通过以下方式清除： 显式软件写入（在这种情况下，NMIC=0 表示 MU->NMI通道从一开始就从未被钳位？ 再次感谢您一直以来的帮助。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， 很抱歉耽搁了。我离开办公室两天。 1. 是的，HSE_B 核心控制 MU_0 和 MU_1 的 MUA 接口。 2. 任何系统 RESET 都应该 RESET MURIP。 3. 我认为这是一个异常情况，因为我对此了解不多。 4. 由于它是 W1C 寄存器，因此需要显式写入。 能否确保在触发功能 RESET 时 HSE_B 处于非活动状态？ 另外，当应用程序卡在 NMI 处理程序中时，HSE_B 的状态是什么？ 你能读取 MU_0 B 侧的标准 HSE GPR (0x4039_C028)、FSR 和 GSR 寄存器吗？ 您在应用程序中使用NMI引脚吗？ 此致， 丹尼尔 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨，丹尼尔， 请查看附件中的三张合并后的寄存器转储截图，如下所示。 根据您的问题整理我们的研究结果。 -------------------------------------------------------- 附件 -------------------------------------------------------- 附件 1：正常设备（已启用安全调试，运行正常） Chibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.png 附件 2：故障单元，在功能 RESET 之前 已触发信号（正常运行） Chibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.png 附件3：故障单元，功能RESET后，卡在…… NMI 处理程序（挂起状态） [[ ## completed ##]] Chibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.png -------------------------------------------------------- 发现 1）功能RESET触发时的 HSE_B 活动，以及 2）HSE_B 在 NMI 处理程序中卡住时的状态： 比较附件 2（RESET前）和附件 3（RESET后， 在故障单元上（处于挂起状态），我们检查的每个寄存器都显示： 重置前后完全相同： [[ ## completed ##]] - MU_0.MUB / MU_1.MUB TSR = 0x0000000F，RSR = 0x00000000（无待处理 发送/接收通道上的消息（RESET后保持不变） - MU_0.MUB GSR = 0x00000000（不变） - MU_0.MUB FSR = 0x03600000（未更改） - HSE GPR (0x4039C028) = 0x000001C1（未更改） - MU_0.MUB / MU_1.MUB SR 位 1 (MURIP) = 0x00000002 -- 已设置 在RESET触发信号之前，并且保持设置状态，保持不变；在 RESET之后 因此，MURIP 在此次 RESET 周期之前就已经设置好了，并且 功能 RESET 本身并不会改变任何与 HSE 相关的 登记簿。 作为参考，引用，在一台运行良好的设备上，使用相同的安全调试功能 配置（附件 1），MURIP 在两个设备上均读取 0x00000000 MU_0.MUB 和 MU_1.MUB，而 HSE GPR 和 WKPU NCR 读取的是 相同的值。将值视为故障单元。 3）关于设置/卡住的 MURIP 是否属于异常情况： 明白了，谢谢确认。 4) NMI 引脚使用： 我们不使用 WKPU 路由的 NMI 路径（WKPU_IP_USED 未启用； 我们的引导加载程序中没有编译任何 WKPU 驱动程序代码。 应用程序图像）。WKPU NCR (0x402B4008) = 0x60000000 完全相同 在所有三个附件中。在所有情况下，NSR = 0x00000000。自从 我们认为，这一点在所有单位和条件下都保持不变。 涉及外部/WKPU路由的NMI源。 目前为止的调查结果概要 故障 设备上的 MURIP（MU_0.MUB 和 MU_1.MUB SR 位 1）已设置。在功能 RESET 的触发信号发出之前，该单元就已经存在，并且仍然存在。 悬挂期间保持不变。在一台性能良好的设备上，读数为0，与上述相同。 安全调试配置。这是唯一一致且可复现的结果。 我们在比较过的每个注册表中都发现了差异（FCCU， CMU_FC、PMC、WKPU 和 MU CSSR0/GSR/TSR/RSR/GPR/FSR）。 由于 MURIP 由“处理器 A”（HSE_B）设置，因此应该由……清除。 根据您的回答，“任何系统 RESET”，而且它之前已经设置过了。 我们的功能 RESET 已发出触发信号（但 RESET 本身并未显示）。要更改它），这表明 HSE_B 在早些时候发布了 MU RESET。 HSE_B 识别的“系统 RESET”从未清除过该点。 问题 1. 从健康、安全和环境 (HSE) 的角度来看，是否有办法确定什么会导致这种情况发生 首先，HSE_B（处理器 A）是否应该发出 MU RESET 指令？我们会 我想了解为什么会设置 MURIP。 2. 是否有推荐的方法来触发 HSE_B 的 RESET？被应用程序 识别为“系统 RESET”（以清除 MURIP）。除了完全断电重启之外，软件方面还有什么需要改进的地方吗？ 3. 应用程序核心端的 MURIP 标志卡住是否可能与以下情况有关？ 我们正在观察的是NMI，或者这更有可能是两个独立的NMI。 是否出现了与之前同一事件相同的症状？ 再次感谢您一直以来的帮助。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@danielmartynek ， 感谢您提供的最新信息，以及您对 MURIP / NMI 路径的升级处理。 请向您内部的健康、安全与环境（HSE）团队提出问题。我们对此表示感谢，我们会等待。 他们的意见。 与此同时，我们发现了一个可能相关的额外数据点， 所以我们希望现在就分享出来，而不是等待。 在比较UTEST Flash区域中性能良好的单元的OTP字段时 我们发现，在故障单元中，生命周期插槽存在差异。 CUST_DEL (0x1B000220-22F) 和 OEM_PROD (0x1B000230-23F) 完全相同 在好的单元和坏的单元上都编程了（所有字均为 0x55AA50AF） 故障单元。 区别在于 IN_FIELD 插槽 (0x1B000240-24F)： - 良好单元：开始进行编程。 Chibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.png - 故障单元：读取为未编程 (0xFFFFFFFF) Chibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.png 我们仍在仔细核对 IN_FIELD 中的确切字节模式。 我们这边有个位置，但这个位置的好坏差异似乎很明显。 持续的。 请问您能否解释一下： 1.这是否意味着故障单元的配置发生了变化 在过渡过程中途被损坏或不完整 IN_FIELD？ 2. 生命周期推进到 IN_FIELD 是否可能不完整或缺失 请解释我们一直在研究的NMI/挂起行为 线？ 3. 是否有安全的方法来检查或完成此生命周期进展 对于故障单元，是否需要进行全面的生产线重启？ 再次感谢您的帮助。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， 根据内存视图，OEM_PROD = 非活动状态，IN_FIELD = 已擦除。 请先读取DCM寄存器：RM，版本12，第 39.3.1 节 DCM 内存映射。 以及第 38.2.3 节“破坏性重置 3 (DCMROD3) 中的只读 GPR”？ 您也可以使用 HSE_FW API 来获取 LC 属性？ 谢谢 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， 感谢您提供的详细寄存器转储文件。我已经将有关 MURIP 行为以及 HSE_B 和 CM7_0 之间潜在的 NMI 路径的问题上报给了我们内部的 HSE 团队，因为这似乎没有相关文档记录。等我收到他们的反馈后，我会尽快回复你。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， 谢谢你提供的数据。 由于 IN_FIELD 槽仍处于擦除状态，您能否尝试再次设置该属性以推进其更新？ 正如我之前提到的，该案件目前正在内部讨论中。 一旦有任何新消息，我会立即更新此帖。 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek ， 感谢您向我们指出 DCM 内存映射和 DCMROD3。我们在两台设备上捕获了 DCMSTAT (0h)、DCMLCS (8h)、DCMLCS_2 (80h) 和 DCMROD3 (208h)，并根据 RM rev.9 对它们进行了解码。 ---------------------------------------------------- 捕获的值 ---------------------------------------------------- 好单位： Chibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.png - DCMSTAT (0h) = 0x00000E11 - DCMLCS (8h) = 0x00000000 - DCMLCS_2 (80h) = 0x00000000 - DCMROD3 (208h) = 0x00000000 故障单元： Chibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.png - DCMSTAT (0h) = 0x00000E03 - DCMLCS (8h) = 0x06184104 - DCMLCS_2 (80h) = 0x00000006 - DCMROD3 (208h) = 0x00400000 ---------------------------------------------------- 已解码字段（仅限故障单元，因为正常单元读取的值为全零） ---------------------------------------------------- DCMSTAT： - bit1 DCMERR = 1（DCM 完成出错）-- 正常设备的此位值为 0 - bit4 DCMLCST = 0（LC 扫描状态未“成功完成”）——正常设备的此位值为 1 DCMLCS： - 位 21-19 DCMLCC4（IN_FIELD 标记）= 011b = "区域已擦除/未擦除" - 位 15-13 DCMLCC3（OEM_PROD 标记）= 010b = "标记为非活动" - 位 27-25 DCMLCC5（预 FA 标记）= 011b = “已擦除/原始” - 所有关联的 *_ECE/*_CFE/*_CSS 位 = 0。 DCMLCS_2： - 位 3-1 DCMLCC6（FA 标记）= 011b = "已擦除/原始" DCMROD3： - bit22 LC_ERR = 1（“生命周期扫描出错”） 这与我们之前分享的 UTEST OTP 转储一致：故障单元上的 IN_FIELD 插槽读取为已擦除/全新。 ---------------------------------------------------- 故障单元上的 HSE_FW API 结果 (HseReadLifecycle) ---------------------------------------------------- HseReadLifecycle() 返回 0x10 = HSE_LC_IN_FIELD。因此，从 HSE 固件的角度来看，当前生命周期已经是 IN_FIELD。 这似乎与上面的 DCM/OTP 数据相冲突：DCM 的 DCMLCC4 字段读取 IN_FIELD 标记为“已擦除/原始”，而 UTEST OTP IN_FIELD 插槽（0x1B000240h 及之后）读取为未编程（0xFFFFFFFF），但 HSE API 报告生命周期已确认为 IN_FIELD。 我们想按原样分享这些信息，而不是得出结论，因为我们不知道 HSE 是否通过独立于 DCM 闪存标记的单独/安全存储来跟踪生命周期，或者这是否表明标记本身存在问题。 问候， 智范 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@danielmartynek 我们按照建议，再次尝试在故障单元上设置 IN_FIELD 属性。 结果：HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21C) 问候， 智范 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， 可能是负责推进生命周期 (LC) 的 HSE 服务中断了，导致 LC 处于这种状态。 LC 和 LC 控制 (DCMLCC) 寄存器报告的值与 HSE_FW 相同，均为 0x77 (IN_FIELD)，但 UTEST 区域的编程不正确。理论上，您可以使用调试器对 UTEST IN_FIELD 插槽进行编程，这应该可以清除 DCM 错误。 此致， 丹尼尔 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek 感谢您建议使用调试器对 UTEST IN_FIELD 槽进行编程。 我们检查了内部 OTP 字段参考表，发现 IN_FIELD 生命周期槽 (1B00_0240-024F) 在 LC > MCU_PROD (OEM_PROD) 后，除 HSE 外，对任何主设备均被列为写保护。由于该单元上的 HseReadLifecycle() 已经报告 IN_FIELD，因此该 LC 条件似乎已经满足。 能否解释一下，在这种保护规则下，调试器向该插槽写入数据如何才能成功？在这种情况下，要使调试器被视为允许的主设备，是否需要特定的程序、模式或身份验证步骤？ 另外，您是否已经找到任何关于为什么 LC 推进到 IN_FIELD 时最初会处于这种不完整状态的原因？如果可以进行分析，我们希望了解根本原因，而不仅仅是恢复步骤。 谢谢你， 智范 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， 谢谢你提供的信息。 目前看来，似乎没有办法恢复MCU。 一种可能性是，HSE 设置属性服务请求推进 LC 的操作被系统 RESET 中断（据我了解，LC 不是通过 IVT 中的 LCW 推进的）。 您是否阅读了 HSE 对服务请求的回复？你们会记录是否出现错误吗？ 在触发服务之前，您是否验证过 HSE_STATUS_INIT_OK 是否已设置？ 有多少块电路板/MCU受到此问题的影响？这种情况仅限于少数设备，还是在更多设备上都观察到了？ 谢谢！ 丹尼尔 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， 请问有任何最新消息吗？ 谢谢 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek ， 很抱歉回复晚了，感谢您的提问。以下是我们的回答： 1.对于 LC 推进序列，我们读取 HSE 服务响应（来自 DebugAuth、AdvanceLifecycle 和 ReadLifecycle 调用），并使用它们来确定总体成功/失败状态。我们不记录具体是哪个调用失败了，也不记录具体的错误代码——只有总体的 OK/FAIL 结果，并且不会将其保存到任何地方。因此，我们没有关于这些设备最初进行LC推进过程中发生了什么的记录。 2. 我们的 LC 更新函数及其调用者在触发 AdvanceLifecycle 服务之前，都没有显式检查 HSE_STATUS_INIT_OK。我们在下载流程开始时检查一次 HSE_STATUS_INIT_OK，方法是读取 MU_0.MUB FSR 寄存器 (0x4038C104) 并从中导出 hseStatus_t（对 FSR 位 16-31 进行掩码/移位，如在 Hse_Ip_GetHseStatus 中所做的那样）。在流程后续的生命周期推进步骤之前，不会重复进行此检查。 为了提供更多背景信息，我们故障单元的生产设备日志显示了以下顺序：FSR 检查完成（OK）-> 应用程序下载 -> 安全调试启用 -> 失败。请注意，我们设备日志中的“安全调试启用”指的是包含 LC 推进（DebugAuth、AdvanceLifecycle 和 ReadLifecycle 一起）的整个过程——它被记录为一个单独的通过/失败步骤，因此我们无法从该日志中判断哪个子步骤实际失败了。 我们的调试设备（TRACE32）已在现有调试流程中检查了 HSE_STATUS_INIT_OK，但我们的下载/编程设备（生产线）可能没有在 LC 前进触发的序列点上持续检查此状态。 关于受影响的设备数量：目前我们有 2 块板/MCU 出现此问题。 我们还有两个后续问题： - 通过读取 FSR 寄存器并从中导出 hseStatus_t 来检查 HSE_STATUS_INIT_OK 是否是一种有效/推荐的方法？ - 目前，我们在下载流程开始时通过读取寄存器来检查 HSE_STATUS_INIT_OK。在触发生命周期推进之前，是否也应该专门检查一下？ 谢谢你，Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek ， 希望你一切都好。我想查看一下这个帖子有没有什么更新。 如果您有时间，能否提供一些指导？我们将不胜感激。 谢谢你， 智范 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， 很抱歉耽搁了——我一直在等待 HSE 团队的反馈，但还没有收到关于 NMI 的明确解释。 DCMROD3 中的 LC_ERR 标志：只有当 FCCU NCF 3 配置为生成 NMI 时，它才能触发 NMI。 关于您的问题： 是的，没错。 系统 RESET 后应检查 HSE_STATUS_INIT_OK 标志。应用程序必须等待此标志出现后才能更改系统时钟或使用任何 HSE 服务。一旦设定，就不会改变。该应用程序还可以轮询 HSE_B 内核的 WFI 标志 (PRTN0_CORE2_STAT[WFI])，以确定 HSE_B 是忙还是空闲。 关于 LC 推进中断的问题——还有一个值得调查的可能根本原因。更改生命周期会修改 UTEST 闪存的内容，而 UTEST 闪存与代码闪存块 0 位于同一个 RWW（边读边写）分区中。如果在 UTEST 写入期间有任何代码正在从块 0 执行，则会发生 RWW 错误，并可能阻止生命周期更改成功完成。为避免这种情况，应用程序必须确保在 LC 推进服务进行期间没有对 Block 0 的并发访问。请注意，缓存在大多数情况下可能会掩盖此问题，但在某些特殊情况下，特别是当应用程序使用非同步事件时，可能会导致缓存未命中，从而使问题显现出来。 此致， 丹尼尔 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 嗨@danielmartynek ， 感谢您确认 HSE_STATUS_INIT_OK 的两点。 我想就您在上次回复中描述的 RWW 机制（关于 UTEST 和代码闪存块 0）跟进一下。我们参考了 AN13388（S32K3 存储器指南）表 3 对此进行了进一步研究，但对具体的冲突机制仍有疑问。 根据 AN13388 表 3，对于我们的设备 (S32K312)： - 代码闪存块 0：0x0040_0000 - 0x004F_FFFF (1 MB) - 代码闪存块 1：0x0050_0000 - 0x005F_FFFF (1 MB) - UTEST：0x1B00_0000 - 0x1B00_1FFF (8 KB) UTEST 被列为一个独立的区块，与代码闪卡区块 0/1 分开。该文档对 RWW 的一般描述指出，同时读/写“仅适用于操作在不同的块中的情况”，我们理解这意味着只有当读取和写入操作针对*同一*块时才会发生冲突。 鉴于 UTEST 和代码闪存块 0 根据此地址映射是物理上独立的块，您能否解释一下，在生命周期推进期间写入 UTEST 如何会与从块 0 执行的代码产生 RWW 冲突？具体来说： 1. 尽管 UTEST 和 Code Flash Block 0 的地址范围不同，但它们是否共享用于 RWW 目的的内部闪存控制器资源（例如编程/擦除状态机或信号量）？ 2. 参考手册中是否记录了其他/更具体的分区分组（除了 AN13388 中的块表之外）是我们应该参考的？ 我们的应用程序代码从代码闪存块 0 运行，因此我们希望在决定修复方案之前了解其确切机制。 再次感谢您一直以来的支持。 最好的， 智范 Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci 你好@Chibeom ， UTEST 确实在 BLOCK 0 中。 请参阅RM： 表103。闪存块配置 S32K3xx_内存映射.xlsx 此外，AN13388（S32K3 内存指南）第 3 章。闪存状态： “最多有五个街区，最少有两个街区。” Block 0 - 4，而 UTEST 位于 Block 0。 此致， 丹尼尔

2026 年最佳个人数据移除服务：独立测试与比较 ⚡快速结论 经过六个月的实际独立测试， Incogni 在 全自动移除和同类最佳价值方面 排名第一 ，约为 ~6.49 美元 /月 。 ⚡INCOGNI - 立即访问 ➤➤   DeleteMe凭借以人为本的礼宾服务方式和行业领先的 750 多家经纪人覆盖率，在 上排名第 2。这两项服务都包括持续的再监测--这是 2026 年最重要的一项功能。 ⚡DELETEME - 立即访问 ➤➤   快速对比表：2026 年最佳数据移除服务 下表根据最重要的指标对所有五项服务进行了排名：自动化水平、经纪人数据库大小、按年计费的每月大致成本，以及我们经过六个月实际测试后的总体得分。 # 服务价格/月度最佳 自动化经纪人覆盖范围 我们的评分 🥇1 INCOGNI - 立即访问 ➤➤ 编辑推荐 自动化& 价值 ~$6.49 ✔ Full 180+ ★★★★★ 5.0 🥈2 DELETEME - 立即访问 ➤➤ 顶级支持 人力清除 ~$10.75 ✔ 混合动力 750多个 ★★★★★ 4.8 3 Optery 最透明 经核实的搬迁证明 ~$3.99 ✔ Full 200+ ★★★★½ 4.5 4 灵气 一体化 隐私 + AV + VPN 捆绑软件 ~$12.00 ✔ Full 100+ ★★★★ 4.0 5 隐私小蜜蜂 高级用户 粒状控制& 深度 ~$14.99 ✔ Full 150+ ★★★★ 4.0 *价格反映年度计划的大致月费。2026 年 5 月验证。 为什么 2026 年数据删除不再是可选的 2026 年的数字隐私环境甚至与五年前截然不同。您的个人信息——家庭住址、电话号码、家庭详细信息——已经从助长垃圾邮件的滋扰演变为人工智能欺诈的关键基础设施。这不是未来的威胁，而是正在发生的事情。 从定向广告到人工智能驱动的冒名顶替 十年前，数据经纪人对你的个人资料所能做的最糟糕的事情就是把它卖给电话推销员。如今，随着先进的生成式人工智能的广泛使用，相同的配置文件已成为语音克隆和深度伪造身份盗窃的蓝图。不良分子从寻人网站上获得你的详细履历后，就能构建超个性化的网络钓鱼活动，与你认识的人发送的真实通信无异。在2026年，隐私是人身安全的直接先决条件，而不仅仅是一种偏好。 "再曝光生命周期" ：为什么一次移除申请永远不够 隐私界最危险的神话也许就是提交一次退出请求就能永久解决问题。数据中介平台的架构可持续重新抓取公共记录。即使成功删除，他们的自动爬网程序也会在 60 到 90 天内重新抓取您的数据。这种循环（我们称之为 Re-exposure Lifecycle ）正是 Incogni 和 DeleteMe 等服务专注于 持续自动监控 而非一次性扫描的原因。持续压制是唯一真正有效的防御手段。 我们如何对每项服务进行测试和排名 本指南中的所有排名均基于六个月的独立测试，而不是新闻稿或未经验证的用户评论。这正是我们测量的结果： 📊 长期抑制 我们追踪了已删除的个人资料是否在整整六个月的时间内一直处于删除状态，对任何允许数据在不触发新的删除周期的情况下重新出现的服务进行处罚。 🔍 扫描频率 在 2026 年，提供近乎实时或每周监测的服务的排名明显高于按季度或按月扫描的服务，而按季度或按月扫描的服务是不够的。 📁 经纪人数据库覆盖范围 我们对数据经纪商的数量和质量都进行了审核，优先考虑高流量的人员搜索网站和营销数据聚合商，而不是模糊的低风险来源。 💻 用户体验& 透明度 我们评估了仪表板的清晰度、报告的详细程度，以及关键的一点，即每项服务是否提供了可核实的、有文件证明的证据，证明清除工作确实已经完成。 INCOGNI - 立即访问 ➤➤ 回顾 2026：最佳整体数据移除服务 🥇 Incogni - 综合排名第一 编辑推荐 2026 ★★★★★ 5.0 / 5.0 ~6.49 美元/月（年度账单） 🏚由冲浪鲨提供🌎 全球覆盖范围（GDPR + CCPA）📋 180+ 经纪人🔄 持续监测 Incogni 是我们 2026 年的头号选择，也是 市场上整体最佳的个人数据删除服务 。它由Surfshark VPN背后的同一个团队创建，旨在使您在GDPR和CCPA框架下行使删除权的法律程序自动化。设置需要几分钟：您授权Incogni代表您行事，该平台会向180多个数据经纪人发送具有法律约束力的选择退出请求，然后在您的数据重新出现时进行监测并自动重新提交。 Incogni 的独特优势在于 价格、自动化深度和国际影响力。年度计划的月费约为 6.49 美元，与我们测试过的任何竞争服务相比，它都能提供更高的性价比。仪表板简洁直观，进度报告易于解读，持续的再监测循环意味着您在初次扫描后绝不会失去保护--这正是打破再曝光生命周期所需的防御。 适合人群： 任何希望以最具竞争力的价格获得全自动、无需动手、全球法律覆盖的隐私解决方案的人。 ✅优点 市场上最优惠的价格（约 6.49 美元/月） 100% 自动化 - 无需人工操作 180 多个经纪人数据库，完全符合 GDPR 全球标准 持续重新监测和自动清除 简洁、直观的仪表板，可显示实时进度 以久负盛名的 Surfshark 品牌为后盾 ❌缺点 对异常复杂的案件不提供人力支持 经纪人数量少于 DeleteMe（180 对 750+） 手动定制选项有限 DELETEME - 立即访问 ➤➤ 2026 年回顾：最适合由人工引导的支持 🥈 DeleteMe - 综合排名第二 最佳人工引导服务 ★★★★★ 4.8 / 5.0 ~10.75 美元/月（年度账单） 🏚由 Abine 提供🇺🇸 以美国为重点 + 国际性📋 750 多名经纪人👥 人工+自动混合 DeleteMe 在纯自动化领域表现出色，因此排名第二。 750 多家数据经纪商的行业领先数据库，是我们测试过的所有服务中覆盖范围最广的。更重要的是，DeleteMe在其自动化系统之上运用了人工专业知识——一支由隐私专业人员组成的专用的团队负责处理经常忽略或拒绝自动退出的固执经纪人的删除请求。 如果您的情况比较复杂--一个非常普通的名字、多个地址的历史记录或在不知名的地区目录中出现的数据--DeleteMe 的管家式方法可确保万无一失。他们详细的季度报告提供了高度的文件透明度，家庭计划选项使其对家庭来说很实用。价格较高（~10.75 美元/月）对于需要专业级监督的用户来说，这反映了所涉及的人力劳动，是非常合理的。 适合人群： 有复杂隐私需求的用户，他们希望经纪人的覆盖面尽可能广，并保证由人工专家积极管理他们的搬迁。 ✅优点 业内最大的经纪人数据库：750 多个站点 人类隐私专家处理棘手的边缘案例 详细的季度报告，并将结果记录在案 历史悠久，业绩卓著（成立于 2010 年） 家庭计划选项可降低人均成本 ❌缺点 每月费用高于 Incogni（约 10.75 美元/月） 以季度为周期进行报告，而非实时报告 界面不如 Incogni 的仪表板精简 其他推荐服务：Optery、Aura& Privacy Bee Optery - 透明度最高（排名第 3） Optery 通过无与伦比的验证标准赢得了第 3 名的位置。在提交 移除请求 之前 ，其仪表板为用户提供了指向其公开个人资料的直接链接，并且它是我们测试的唯一一项提供 基于屏幕截图的证据以 证明 每项删除都已完成的服务。它的起价约为 3.99 美元/月，也是本列表中最经济实惠的选择--对于注重预算、拒绝信口开河的用户来说，这是一个令人信服的选择。其主要局限性在于，其团队和后续行动的积极性还无法与 Incogni 或 DeleteMe 相提并论。 Aura — 最佳多合一网络安全套件（排名 #4） 对于想要将其整个数字网络安全堆栈整合到单个订阅中的用户来说，Aura是正确的答案。它的价格约为每月12美元，将自动数据删除与防病毒保护、VPN和信用监控捆绑到一个统一的平台中，特别适合家庭使用。该移除工具本身是全自动和有效的，不过其中介数据库中的 100 多个网站明显少于我们的前两个选择。 隐私蜂 - 最适合高级用户（排名第 5 位） Privacy Bee 专为痴迷于隐私的用户而打造，他们希望对其数字足迹进行精细的外科控制。它的价格约为 14.99 美元/月，是本列表中最昂贵的选项，但它提供了最深入的自定义选项--你可以优先处理特定的经纪人类别、锁定特定的数据类型，并精确配置删除计划。同样的复杂性也使它不太适合那些只想不假思索地解决问题的普通用户。 Incogni vs DeleteMe：您应该选择哪个？ 这是个人数据删除中最常被问到的问题，因此这里有一个直接、简单的答案： 如果您需要最优惠的价格、完全端到端自动化、全球 GDPR 和 CCPA 覆盖范围，以及无需持续工作的仪表板，请选择 Incogni 。这对绝大多数用户来说都是正确的选择。 如果您的隐私情况确实非常复杂，需要尽可能广泛的经纪人数据库（750 多个），或者需要专业人员积极管理和验证您的案例，请选择 DeleteMe 。 这两项服务都包括持续的重新监测--这在 2026 年是不可谈判的。与手动删除或不作为相比，这两种方法都能提供更好的长期保护。 数据删除之外：建立完整的隐私战略 暗网监控和信用跟踪 数据删除可以解决一个关键的暴露载体，但它本身并不是一个完整的网络安全解决方案。暗网监控增加了重要的第二层：如果您的凭证出现在泄露中，则需要立即发出警报，而不是延迟发现。如果有人试图以你的名义开立账户或进行交易，你会立即收到通知。 密码管理和多因素身份验证 密码泄露会破坏你为保护隐私所做的一切。专用的密码管理器可确保您在每项服务中维护独特、复杂的凭据，从而消除单一密码失败的风险。在任何可用的地方启用多因素身份验证，并尽可能使用身份验证器应用程序而不是短信；基于 SMS 的 MFA 容易受到 SIM 交换攻击，适当的身份验证器应用程序可以防止这种攻击。 设备级安全：防病毒和指纹拦截器 您的本地设备是最后的边界。2026 年强大的防病毒软件不是可选的——现代恶意软件旨在以静默方式收集文件、凭据和行为数据。与此相辅相成的浏览器扩展程序可以主动屏蔽第三方跟踪器并抵制指纹识别，通过这种技术，数据经纪人可以根据浏览器配置和浏览模式建立您的详细档案，完全不使用 cookie。 2026 年您的法律权利：CCPA、GDPR 以及服务如何使用这些权利 CCPA 和不断扩大的美国隐私框架 《加州消费者隐私法》及其随后的修正案赋予了美国消费者要求数据经纪人删除其个人信息的法律强制执行的权利。截至 2026 年，对违规行为的处罚已变得更加具体，选择退出的基础设施也已成熟。 Incogni 和 DeleteMe 等服务作为法定代理人代表你行事--他们利用你的消费者权利提交具有约束力的退出请求，迫使经纪商在监管处罚的威胁下清除你的记录。 GDPR：全球数据权利标准 对于欧盟或英国的用户来说，《通用数据保护条例》仍然是最有力的隐私保护工具。GDPR 的 "删除权 "对任何处理欧盟居民数据的组织都规定了严格的义务。Incogni 由 Surfshark 背后的欧洲团队开发，专门围绕 GDPR 合规性进行架构设计，使其能够向全球范围内的经纪商提出可强制执行的删除请求，这对国际用户尤为重要。 DIY 方法：如何在不使用付费服务的情况下删除数据 零预算也可以手动删除数据，但需要投入大量时间和持续的纪律。基本流程： 在主要的寻人网站上搜索你的全名、城市和州：Spokeo、Whitepages、BeenVerified、Intelius 和 MyLife 是最优先的起始点。 找到每个网站的退出页面或"Do Not Sell My Personal Information" 页面--通常埋藏在网站页脚的 "隐私政策 "下。 完成每个退出工作流程，并保存确认电子邮件作为记录证据。 安排日历提醒，每三到四个月重复一次整个过程，因为重新刮擦会在固定的周期内撤销你的清除。 对于大多数人来说，手动删除的时间成本使得像 Incogni 这样每月约 6.49 美元的服务 成为显而易见的经济选择。也就是说，如果你的风险状况确实很低，并且你对系统化流程有耐心，那么在投资自动化之前，手动优先的方法可以作为有用的基础。 准备好从互联网上删除您的个人数据了吗？ 停止暴露你的数字足迹。从我们的顶级服务开始，今天就重新掌控您的个人信息。 ↑ 比较以上所有服务 常见问题 2026 年最好的数据移除服务是什么？ Incogni 是我们 2026 年排名第一的数据移除服务--因其集完全自动化、全球法律覆盖面和高级层最低价格（约 6.49 美元/月）于一身而综合排名第一。 DeleteMe 排名第二，是情况复杂、希望由专业人员管理案件的用户的更佳选择。   2026 年 Incogni 的成本是多少？ Incogni 的年度计划费用约为 6.49美元/月 （约 77.88 美元/年）。也可选择按月付费，但费用较高。因此，它是目前市场上最具成本效益的高级数据删除服务。   2026 年 DeleteMe 的成本是多少？ DeleteMe 的年度计划费用约为 ，每月10.75美元 （每年约 129 美元）。家庭计划可用，在涵盖多个家庭成员时，可以显著降低人均成本。   数据删除服务真的有效吗？ 是的，但前提是必须包括持续的再监测。数据经纪商每隔 60 到 90 天就会重新抓取公共记录，因此一次性删除请求无效。像 Incogni 和 DeleteMe 这样的服务可以自动完成整个周期，利用 GDPR 和 CCPA 框架持续压制您的数据。我们为期 6 个月的测试证实，在所有排名靠前的服务中，暴露量都有可衡量的持续减少。   Incogni 比 DeleteMe 更好吗？ 对大多数用户来说，是的，Incogni 提供了一个卓越的价值主张：完全自动化、价格更低和全球法律覆盖范围。DeleteMe 是以下用户的更佳选择：需要处理真正复杂案件的用户、需要尽可能广泛的经纪人数据库（750 多个对 180 多个）的用户，或者特别希望由专业人员验证其移除行为而不是仅仅依赖自动化的用户。   我可以免费从数据经纪商那里删除我的数据吗？ 是的，大多数数据经纪商都提供免费的退出页面，而且可以免费手动删除。这样做的代价是巨大的：这个过程耗费时间，每隔几个月就必须重复一次，而且需要跟踪几十个经纪人。对于持续的自动保护， Incogni对大多数人来说是一种实用的升级。对于预算紧张的低风险个人来说，DIY 方法最适合作为免费的起点。   重新掌控您的数字足迹 2026 年的数据经纪人经济是无情的。您的个人信息不断被收集、打包和出售，如果落入坏人之手，则会成为人工智能欺诈、社会工程和身份盗窃的原材料。等待不是一种中立的选择，而是一种继续暴露的决定。 经过 6 个月的严格独立测试， Incogni 赢得了我们无条件的最高推荐：最具价值、最无缝的自动化和真正的全球覆盖。 DeleteMe 是您需要最广泛的经纪人覆盖范围和人类专业知识保证时的正确选择。这两项服务直接抵消了 "再曝光生命周期 "的影响，使一次性清除工作在几个月内就会过时。 无论您开始使用哪种服务，都可以在其基础上构建：强大的唯一密码、多因素身份验证和设备级安全性构成了 2026 年所需的完整深度防御方法。您的隐私不是一次性配置的设置，而是一种持续的实践。从今天开始 Re: Best Personal Data Removal Services of 2026: Independently Tested and Compared @Mentorstgf快速结论 经过六个月的实际独立测试， Incogni排名第一 全自动移除服务，性价比一流，价格约为 每月约 6.49 美元。 隐身模式 — 立即访问 ➤➤   DeleteMe 排名第二 以人为本的礼宾服务方式和业内领先的750多家经纪公司覆盖范围而闻名。这两项服务都包含持续再监控功能——这是 2026 年最关键的功能。 DELETEME — 立即访问 ➤➤   快速对比表：2026 年最佳数据移除服务 下表根据最重要的指标对所有五项服务进行了排名：自动化水平、经纪人数据库大小、按年计费的每月大致成本，以及我们经过六个月实际测试后的总体得分。 对于任何想要减少其在线足迹的人来说，这都是一个有用的比较——尤其值得关注的是持续监控和重新删除，而不是依赖一次性选择退出。为期六个月的测试方法也使得自动化服务和人工主导的服务之间的差异更容易理解。

secure_provisioning工具烧写sb格式加密签名文件后无法使用mcu链接调试 使用 Secure Provisioning 工具刷写 SB 格式加密签名文件后，将无法再通过 MCU-Link 进行调试。 justdomyself_0-1790073326861.png justdomyself_1-1790073357176.png 当我使用mcuexpress调试代码时，出现错误： justdomyself_2-1790073419631.png 我的开发板可以恢复到之前的状态以使用调试功能吗？ Re: secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug 嗨@justdomyself > 那么，我可以使用安全提供工具来生成新的许可证，并将新的已签名和加密的 sb 格式文件写入芯片吗？ 是的，安全配置工具旨在配置芯片，即安装安全资产（密钥），构建签名或加密的应用程序可启动映像并将其安装到闪存中。 Re: secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug @liborukropec非常感谢。我的问题已经解决了。 justdomyself_0-1790128360736.png 我还有个问题： 如上图所示，此擦除操作已将存储芯片上的所有数据擦除干净。 那么，我可以使用安全提供工具来生成新的许可证，并将新的已签名和加密的 sb 格式文件写入芯片吗？ Re: secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug 您好， 如果将 ROM 配置为仅执行已签名映像，然后从 VSCode（或其他 IDE）编写未签名映像的应用程序，则 ROM 将拒绝运行。 此外，如果推进生命周期，则只能通过调试身份验证打开调试器（请参阅文档）。 如果您没有推进生命周期（在工具栏上），您应该能够删除 CMPA。最简单的办法是使用调试探针，然后在“写入”选项卡上使用“擦除整个芯片...”按钮。 liborukropec_0-1790086908628.png 重启电源后，您应该可以再次进行调试。 此致， 伦敦银行间同业拆借利率 (Libor)

アプリケーションコマンド 皆さん freeMASTERアプリケーションコマンドはNODE REDノードでは利用できないようです。何らかの方法でそれらを呼び出すことは可能でしょうか？ よろしくお願いいたします パオロ Re: Application commands こんにちは、@pberna67 さん。 残念ながら、アプリケーションコマンドはFreeMASTERに追加されませんでした。Node-REDノードです。 現時点で追加できる唯一の方法は、『FreeMASTER Node.js Modules』で利用可能な「node-red-contrib-freemaster」Node.jsモジュールを拡張し、手動でインストールすることで以下の動作を実行することです: npm i path_to_the_updated_node-red-contrib-freemaster Node-REDのホームフォルダ($HOME/.node-red)から。 敬具、 イウリアン Re: Application commands 親愛なるイウリアン それは残念だ 😞 ! コマンドが必要です 1) freeMASTER / FreeMaster lite はまだ開発中ですか？ 2) 次のリリースでアプリケーションコマンドを統合する計画はありますか?   FreeMaster(ライト版ではなく)でアプリケーションコマンドがあるバージョンにアプローチしようとしていますが、ここではNode Redはサポートされていません 😞 ! パオロ Re: Application commands こんにちは、パオロさん。 FreeMASTERは積極的に開発・改良されている一方、 FreeMASTER Liteは主にバグ修正と重要なアップデートによって維持されている。 アプリケーションコマンド機能は長年利用可能です。FreeMASTERでは現在もメンテナンスとテストが行われていますが、現時点ではさらなる機能強化の予定はありません。可能な限り、アプリケーションを制御するための代替的な仕組み(例:フラグ変数の使用)を推奨します。   Iulian  

secure_provisioning ツール烧写 sb格式加密签名文件后無法用mcuリンクデバッグ Secure ProvisioningツールでSB形式の暗号化・署名済みファイルをフラッシュした後、MCU-Linkによるデバッグはもはやできません。 justdomyself_0-1790073326861.png justdomyself_1-1790073357176.png mcuexpress を使用してコードをデバッグすると、エラーが発生しました。 justdomyself_2-1790073419631.png このボードはデバッグ機能を使うために元の状態に戻ることはできますか? Re: secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug こんにちは、 @justdomyself >では、Secure Provisingツールを使って新しいライセンスを作成し、新しい署名付き暗号化されたSBフォーマットファイルをチップに書き込むことはできますか? はい、Secure Provisioningツールはchipのプロビジョニング、つまり安全な資産(鍵)をインストールし、署名済みまたは暗号化されたアプリケーションのブート可能なイメージを構築し、フラッシュにインストールするために設計されています。 Re: secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug @liborukropecどうもありがとうございます。疑問は解決しました。 justdomyself_0-1790128360736.png もう一つ質問があります。 上記の図のように、この消去操作によりメモリチップ全体が消去されました。 では、Secure Provisingツールを使って新しいライセンスを作成し、新しい署名付きで暗号化されたSBフォーマットのファイルをチップに書き込むことはできますか? Re: secure_provisioning 工具烧写 sb格式 加密签名文件后无法用mcu link debug こんにちは、 ROMを署名済みイメージのみを実行するように設定し、その後VSCode(または他のIDE)の非署名イメージからアプリケーションを書き込むと、ROMは実行を拒否します。 また、ライフサイクルを進めると、デバッガはデバッグ認証(Debug Authentication)でのみ開けられます(ドキュメント参照)。 もしライフサイクルを進めていなければ(ツールバーで)、CMPAを消去できるはずです。最も簡単な方法は、デバッグプローブを使用し、[書き込み] タブで「チップ全体を消去...」ボタンを使用することです。 liborukropec_0-1790086908628.png 電源を入れ直せば、再びデバッグできるようになるはずです。 よろしくお願いいたします。 リボル

应用程序命令 各位 我发现 node red 节点中没有 freeMASTER 应用程序命令。是否有可能以某种方式调用它们？ 问候 Paolo Re: Application commands 嗨@pberna67 ， 遗憾的是，FreeMASTER 的 Node-RED 节点中没有添加应用程序命令。 目前，添加这些模块的唯一方法是扩展 `FreeMASTER Node.js Modules` 中提供的 `node-red-contrib-freemaster` Node.js 模块，然后手动运行以下命令进行安装： npm i path_to_the_updated_node-red-contrib-freemaster 从 Node-RED 的主文件夹（ $HOME/.node-red）。 亲切的问候， 尤利安 Re: Application commands 亲爱的尤利安 很可惜 😞 需要命令 1）freeMASTER/FreeMaster lite还在开发中吗？ 2）是否有计划在下一个版本中集成应用程序命令？ 我尝试使用带有应用程序命令的 FreeMaster（非精简版），但是它不支持 Node-RED。 😞 ！ Paolo Re: Application commands 嗨，保罗， FreeMASTER正在积极开发和改进，而FreeMASTER Lite主要通过修复错误和进行关键更新来维护。 应用程序命令功能已经推出多年。虽然FreeMASTER仍在维护和测试该功能，但目前没有进一步增强的计划。如果可能，我们建议使用替代机制来控制应用程序（例如：使用标志变量）。   Iulian  

S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on specific Device: S32K312 Toolchain: Green Hills ELXR (compiler) HSE Firmware: s32k312_hse_fw_0.13.0_2.55.0_pb250129.bin Debugger: Lauterbach TRACE32 Software: AUTOSAR RTD-based Bootloader (FBL) + Application (APP), two-image structure ISSUE SUMMARY On a subset of production units, the CPU hangs immediately after a Functional (software) reset. The same units always boot correctly after a Destructive (power-on) reset. The hang does not reproduce on our reference/known-good units. EVIDENCE THAT AN NMI OCCURS BEFORE ANY APPLICATION CODE EXECUTES 1) CPU context captured at the hang point (auto-stacked exception frame): - R0-R3 = 0x00000000, R12 = 0x00000000 - LR = 0xFFFFFFFF (reset default -> no BL has executed yet) - PC = 0x00416904 (the very first instruction address of our Reset_Handler) - xPSR = 0x01000000 2) SCB->ICSR = 0x00000802 Chibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.pngChibeom_3-1785136456875.png - VECTACTIVE[8:0] = 2 -> NMI is the currently active exception - RETTOBASE = 1 This confirms the CPU is currently executing inside the NMI handler. 3) Our vector table entry for the NMI offset correctly points to our own default exception handler, so this is a genuine NMI event, not vector table corruption. REGISTERS CHECKED AT THE SAME HANG STATE (all read as clean / inactive) - MC_RGM_DES = 0x00000000 (not a destructive reset) - MC_RGM_FES = 0x20000000 (bit 29 only) (only "software functional reset" flag set, no other functional reset source flagged) - FCCU: STAT, N2AF_STATUS, A2FF_STATUS, N2FF_STATUS, NCF_S0, IRQ_STAT all = 0x00000000 - CMU_FC instances 0, 3, 4: SR = 0x00000000 (no frequency high/low fault) - PMC LVSC = 0x00000000 (no LVD/HVD flag, latched or live) - ERM (0x4025C000): could not be read on either good or failing units (likely clock-gated in our configuration), so ERM status is unverified. QUESTIONS 1. Are there any NMI sources -- other than FCCU / CMU_FC / PMC / MC_RGM -- that could fire before the application's Reset_Handler executes its first instruction? 2. Since the HSE subsystem runs independently of the application core, is it possible for an application-core Functional reset (which does not reset HSE) to create a state mismatch that triggers an NMI on the application core? 3. Is there a known errata for S32K312 matching this symptom (NMI only on functional/software reset, never on power-on reset)? Any guidance on additional registers to check, or documentation covering NMI sources outside FCCU / ERM / CMU_FC / PMC, would be greatly appreciated. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Could you please read registers MU_0.MUB CSSR0 and MU_1.MUB CSSR0 at the hang state, and confirm whether bit 0 (NMIC) is set in either of them? Thank you Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Thank you for pointing us to MU_0.MUB / MU_1.MUB CSSR0. CSSR0 (bit 0, NMIC) on both MU_0.MUB and MU_1.MUB reads 0x00000000 on the failing unit at the hang state, so the MU->NMI request path (CCR0[NMI] / CSSR0[NMIC]) does not appear to be pending. However, while comparing MU registers between a known-good unit and a failing unit (both captured at the identical hang-state address range), we found a consistent difference:                                Good unit Failing unit MU_0.MUB VER 0x0300000F 0x0300000F (identical) MU_0.MUB PAR 0x20200404 0x20200404 (identical) MU_0.MUB CR 0x00000000 0x00000000 (identical) MU_0.MUB SR 0x00000000 0x00000002 <- MURIP set MU_1.MUB VER/PAR/CR: identical between good and failing units MU_1.MUB SR 0x00000000 0x00000002 <- MURIP set So on BOTH MU instances, SR bit 1 (MURIP) is set only on the failing unit, consistently. Per the reference manual, MURIP indicates that "processor A" has issued an MU reset, and can only be cleared by a system reset (not by an MU reset). Since the CPU is frozen inside the NMI handler before executing any application code, it could not have cleared this flag itself, so it must have been set prior to (or as part of) this boot sequence. We'd appreciate your input on the following: 1. For MU_0.MUB and MU_1.MUB, which processor is "processor A" (i.e. who sets MURIP)? Our header only exposes the "MUB" register block at the application-core-accessible address -- does this imply the application core is always "processor B" and HSE is "processor A" for these instances? 2. Does "system reset" (required to clear MURIP) include a Functional/SW reset of the application core, or only a Destructive/POR reset? If MURIP is not cleared by our functional reset, that would explain why it stays set across SW reset while it is clear after power-on. 3. Independent of the NMI question: is a set/stuck MURIP flag itself expected or considered anomalous during normal operation? 4. Since CSSR0[NMIC] currently reads 0, is it possible for hardware to auto-clear NMIC upon NMI exception entry, or does it only clear via an explicit software write (in which case NMIC=0 would mean the MU->NMI channel was never asserted in the first place)? Thanks again for your help so far. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, I'm sorry for the delay. I was out of office for two days. 1. Yes, the HSE_B core controls the MUA interfaces of MU_0 and MU_1. 2. Any system reset should reset MURIP. 3. I would consider this an anomaly, as I do not have much information about it. 4. It requires an explicit write, as it is a W1C register. Can you make sure that HSE_B is inactive at the time the functional reset is triggered? Also, what is the state of HSE_B while the application is stuck in the NMI handler? Can you read the standard HSE GPR (0x4039_C028), FSR, and GSR registers on the MU_0 B side? Do you use the NMI pin in the application? Regards, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi Daniel, Please find three combined register-dump screenshots attached, followed by our findings organized by your questions. -------------------------------------------------------- ATTACHMENTS -------------------------------------------------------- Attachment 1: GOOD unit (Secure Debug enabled, running normally) Chibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.pngChibeom_3-1785730814252.png Attachment 2: FAILING unit, immediately BEFORE the functional reset is triggered (normal operation) Chibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.pngChibeom_4-1785730831377.png Attachment 3: FAILING unit, AFTER the functional reset, stuck in the NMI handler (hang state) Chibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.pngChibeom_5-1785730838688.png -------------------------------------------------------- FINDINGS 1) HSE_B activity at the time the functional reset is triggered, and 2) state of HSE_B while stuck in the NMI handler: Comparing Attachment 2 (before reset) and Attachment 3 (after reset, hang state) on the failing unit, every register we checked reads IDENTICALLY before and after the reset: - MU_0.MUB / MU_1.MUB TSR = 0x0000000F, RSR = 0x00000000 (no pending messages on transmit/receive channels, unchanged by the reset) - MU_0.MUB GSR = 0x00000000 (unchanged) - MU_0.MUB FSR = 0x03600000 (unchanged) - HSE GPR (0x4039C028) = 0x000001C1 (unchanged) - MU_0.MUB / MU_1.MUB SR bit 1 (MURIP) = 0x00000002 -- already set BEFORE the reset is triggered, and remains set, unchanged, after the reset So MURIP was already set prior to this reset cycle, and the functional reset itself does not change any of these HSE-related registers. For reference, on a good unit with the same Secure Debug configuration (Attachment 1), MURIP reads 0x00000000 on both MU_0.MUB and MU_1.MUB, while HSE GPR and WKPU NCR read the same values as the failing unit. 3) Regarding whether a set/stuck MURIP is anomalous: Understood, thank you for confirming. 4) NMI pin usage: We do not use the WKPU-routed NMI path (WKPU_IP_USED is not enabled; no WKPU driver code is compiled into either our bootloader or application image). WKPU NCR (0x402B4008) = 0x60000000 identically across all three attachments. NSR = 0x00000000 in all cases. Since this is unchanged across all units and conditions, we don't believe an external/WKPU-routed NMI source is involved. SUMMARY OF FINDINGS SO FAR MURIP (MU_0.MUB and MU_1.MUB SR bit 1) is already set on the failing unit BEFORE the functional reset is even triggered, and remains unchanged throughout the hang. It reads 0 on a good unit with the same Secure Debug configuration. This is the only consistent, reproducible difference we have found across every register we've compared (FCCU, CMU_FC, PMC, WKPU, and MU CSSR0/GSR/TSR/RSR/GPR/FSR). Since MURIP is set by "processor A" (HSE_B) and should be cleared by "any system reset" per your answer, and since it is already set before our functional reset is triggered (and the reset itself does not appear to change it), this suggests HSE_B issued an MU reset at some earlier point that was never cleared by a "system reset" recognized by HSE_B. QUESTIONS 1. Is there a way to determine, from the HSE side, what would cause HSE_B (processor A) to issue an MU reset in the first place? We'd like to understand why MURIP gets set at all. 2. Is there a recommended way for us to trigger a reset that HSE_B recognizes as a "system reset" (to clear MURIP) from application software, short of a full power cycle? 3. Could a stuck MURIP flag on the application-core side be related to the NMI we are observing, or are these more likely two independent symptoms of the same earlier event? Thanks again for your continued help with this. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @Chibeom, Thank you for the detailed register dumps. I have escalated the questions around MURIP behavior and the potential NMI path between HSE_B and CM7_0 to our internal HSE team, as this seems to be not documented. I will get back to you once I have their input. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @danielmartynek,  Thank you for the update, and for escalating the MURIP / NMI path question to your internal HSE team. We appreciate it, and we'll wait for their input. In the meantime, we found an additional data point that may be relevant, so we wanted to share it now rather than wait. While comparing OTP fields in the UTEST Flash area between a good unit and a failing unit, we found a difference in the Lifecycle slots. CUST_DEL (0x1B000220-22F) and OEM_PROD (0x1B000230-23F) are identically programmed (0x55AA50AF across all words) on both the good unit and the failing unit. The difference is in the IN_FIELD slot (0x1B000240-24F): - Good unit: begins being programmed Chibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.pngChibeom_2-1786069927793.png - Failing unit: reads as unprogrammed (0xFFFFFFFF) Chibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.pngChibeom_1-1786069910918.png We are still double-checking the exact byte pattern within the IN_FIELD slot on our side, but the good/failing difference at this slot appears consistent. Could you clarify: 1. Does this suggest that the failing unit's configuration became corrupted or incomplete partway through the transition into IN_FIELD? 2. Could an incomplete or missing lifecycle advancement to IN_FIELD explain the NMI/hang behavior we have been investigating in this thread? 3. Is there a safe way to check or complete this lifecycle advancement on the failing units, without a full production re-flow? Thanks again for your help. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Based on the memory view, OEM_PROD = Inactive, IN_FIELD = Erased. Can you please first read the DCM registers: RM, rev.12, Section 39.3.1 DCM memory map. And Section 38.2.3 Read-Only GPR On Destructive Reset 3 (DCMROD3)? You can also use the HSE_FW APIs to get the LC attribute? Thank you Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Thank you for pointing us to the DCM memory map and DCMROD3. We captured DCMSTAT (0h), DCMLCS (8h), DCMLCS_2 (80h), and DCMROD3 (208h) on both units, and decoded them against RM rev.9. ---------------------------------------------------- CAPTURED VALUES ---------------------------------------------------- Good unit: Chibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.pngChibeom_0-1786500129171.png - DCMSTAT (0h) = 0x00000E11 - DCMLCS (8h) = 0x00000000 - DCMLCS_2 (80h) = 0x00000000 - DCMROD3 (208h) = 0x00000000 Failing unit: Chibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.pngChibeom_1-1786500144600.png - DCMSTAT (0h) = 0x00000E03 - DCMLCS (8h) = 0x06184104 - DCMLCS_2 (80h) = 0x00000006 - DCMROD3 (208h) = 0x00400000 ---------------------------------------------------- DECODED FIELDS (FAILING UNIT ONLY, since good unit reads all-zero) ---------------------------------------------------- DCMSTAT: - bit1 DCMERR = 1 (DCM completed with error) -- good unit has this bit = 0 - bit4 DCMLCST = 0 (LC scanning status not "completed successfully") -- good unit has this bit = 1 DCMLCS: - bits 21-19 DCMLCC4 (IN_FIELD Marking) = 011b = "Region is erased/virgin" - bits 15-13 DCMLCC3 (OEM_PROD Marking) = 010b = "Marked as inactive" - bits 27-25 DCMLCC5 (Pre-FA Marking) = 011b = "erased/virgin" - All associated *_ECE/*_CFE/*_CSS bits = 0. DCMLCS_2: - bits 3-1 DCMLCC6 (FA Marking) = 011b = "erased/virgin" DCMROD3: - bit22 LC_ERR = 1 ("Error In Life Cycle Scanning") This is consistent with the UTEST OTP dump we shared earlier: the IN_FIELD slot on the failing unit reads as erased/virgin. ---------------------------------------------------- HSE_FW API RESULT (HseReadLifecycle) ON THE FAILING UNIT ---------------------------------------------------- HseReadLifecycle() returns 0x10 = HSE_LC_IN_FIELD. So from the HSE firmware's point of view, the current lifecycle is already IN_FIELD. This appears to conflict with the DCM/OTP data above: DCM's DCMLCC4 field reads IN_FIELD marking as "erased/virgin," and the UTEST OTP IN_FIELD slot (0x1B000240h onward) reads as unprogrammed (0xFFFFFFFF), yet the HSE API reports the lifecycle as confirmed IN_FIELD. We wanted to share this as-is rather than draw a conclusion, since we don't know whether HSE tracks lifecycle through a separate/secure store independent of the DCM flash marking, or whether this indicates the marking itself is the problem. Regards, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @Chibeom, Thanks for the data. Since the IN_FIELD slot is still in the erased state, could you try setting the attribute again to advance it? As I mentioned, the case is currently under internal discussion. I will update this thread as soon as I have any new information. Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Probably the HSE service responsible for advancing the Life Cycle (LC) was interrupted, leaving the LC in this state. The LC and LC Control (DCMLCC) register reports 0x77 (IN_FIELD) as the HSE_FW does, but the UTEST area is not programmed correctly. In theory, you could program the UTEST IN_FIELD slot using a debugger, which should clear the DCM error.  Regards, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hello @danielmartynek  We tried setting the IN_FIELD attribute again on the failing unit, as suggested. Result: HSE_SRV_RSP_NOT_ALLOWED (0xAA55A21C) Regards, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek  Thank you for the suggestion to program the UTEST IN_FIELD slot using a debugger. We checked our internal OTP field reference table, and the IN_FIELD lifecycle slot (1B00_0240-024F) is listed as write-protected for any master except HSE once LC > MCU_PROD (OEM_PROD). Since HseReadLifecycle() on this unit already reports IN_FIELD, this LC condition appears to already be met. Could you clarify how a debugger write to this slot would be expected to succeed under this protection rule? Is there a specific procedure, mode, or authentication step required for the debugger to be treated as an allowed master in this case? Separately, do you have any findings yet on why the LC advancement to IN_FIELD was left in this partial state in the first place? We'd like to understand the root cause, not just the recovery step, if that analysis is available. Thank you, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Thank you for the information. It seems there is no option to recover the MCU at this point. One possibility is that the HSE set attribute service request to advance the LC was interrupted by a system reset (I understand the LC was not advanced using the LCW within the IVT).: Do you read the HSE response of the service request? Do you log whether there was an error? Before triggering the service, do you verify that HSE_STATUS_INIT_OK is set? How many boards/MCUs are affected by this issue? Is it limited to a few units, or have you observed it across a larger number of devices? Thank you, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Do you have any update? Thank you Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Apologies for the delayed response, and thank you for the questions. Here are our answers: 1. For the LC advance sequence, we read the HSE service responses (from the DebugAuth, AdvanceLifecycle, and ReadLifecycle calls) and use them to determine an overall success/fail status. We don't log which specific call failed or the individual error code -- only the overall OK/FAIL result exists, and it is not persisted anywhere. So we have no record of what happened during the original LC advancement on these units. 2. Neither our LC-update function nor its caller explicitly checks HSE_STATUS_INIT_OK before triggering the AdvanceLifecycle service. We check HSE_STATUS_INIT_OK once at the beginning of our download flow, by reading the MU_0.MUB FSR register (0x4038C104) and deriving hseStatus_t from it (mask/shift on FSR bits 16-31, as done in Hse_Ip_GetHseStatus). This check is not repeated before the lifecycle advancement step later in the flow. For additional context, our production equipment log for the failing units shows the following sequence: FSR check completed (OK) -> App download -> Secure Debug Enable -> FAIL Note that "Secure Debug Enable" in our equipment log refers to the entire procedure that includes the LC advancement (DebugAuth, AdvanceLifecycle, and ReadLifecycle together) -- it's logged as a single pass/fail step, so we cannot tell from this log which of the sub-steps actually failed. Our debug equipment (TRACE32) has checked HSE_STATUS_INIT_OK as part of our existing debug flow, but our download/programming equipment (production line) may not have consistently checked this at the point in the sequence where the LC advancement is triggered. Regarding the number of affected units: we currently have 2 boards/MCUs showing this issue. We also have two follow-up questions: - Is reading the FSR register and deriving hseStatus_t from it this way a valid/recommended way to check HSE_STATUS_INIT_OK? - We currently check HSE_STATUS_INIT_OK once at the beginning of our download flow, via this register read. Should it also be checked specifically before triggering the lifecycle advancement? Thank you, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , I hope you're doing well. I wanted to check in and see if there have been any updates on this thread. We'd appreciate any guidance you can share when you get a chance. Thank you, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, Apologies for the delay — I have been waiting for feedback from the HSE team, but have not received a clear explanation for the NMI. The LC_ERR flag in DCMROD3: it can trigger an NMI only if FCCU NCF 3 is configured to generate one. To your questions: Yes, that is correct. The HSE_STATUS_INIT_OK flag should be checked after any system reset. The application must wait for this flag before changing system clocks or using any HSE service. Once set, it remains set. The application can additionally poll the WFI flag of the HSE_B core (PRTN0_CORE2_STAT[WFI]) to determine whether the HSE_B is busy or idle. On the topic of the interrupted LC advancement — there is one more possible root cause worth investigating. Changing the lifecycle modifies the contents of the UTEST flash, and the UTEST flash resides in the same RWW (Read-While-Write) partition as Code Flash Block 0. If any code is executing from Block 0 during the UTEST write, an RWW error will occur and can prevent the lifecycle change from completing successfully. To avoid this, the application must ensure there is no concurrent access to Block 0 while the LC advancement service is in progress. Note that the cache may mask this issue in most cases, but in certain corner cases, particularly when the application uses a non-synchronized event, it can result in a cache miss, making the problem visible. Regards, Daniel Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @danielmartynek , Thank you for confirming the two points on HSE_STATUS_INIT_OK. I'd like to follow up on the RWW mechanism you described in your last reply, regarding UTEST and Code Flash Block 0. We looked into this further using AN13388 (S32K3 Memories Guide), Table 3, and have a question about the exact conflict mechanism. Per AN13388 Table 3, for our device (S32K312): - Code Flash Block 0: 0x0040_0000 - 0x004F_FFFF (1 MB) - Code Flash Block 1: 0x0050_0000 - 0x005F_FFFF (1 MB) - UTEST: 0x1B00_0000 - 0x1B00_1FFF (8 KB) UTEST is listed as its own distinct block, separate from Code Flash Block 0/1. The document's general RWW description states that simultaneous read/write "applies only when operations are in different blocks," which we understand to mean a conflict only arises when a read and a write target the *same* block. Given that UTEST and Code Flash Block 0 are physically separate blocks by this address map, could you clarify how a write to UTEST (during lifecycle advancement) would create an RWW conflict with code executing from Block 0? Specifically: 1. Do UTEST and Code Flash Block 0 share an internal flash controller resource (e.g. a program/erase state machine or semaphore) for RWW purposes, despite having separate address ranges? 2. Is there a different/more specific partition grouping (beyond the block table in AN13388) documented in the Reference Manual that we should be looking at? Our application code runs from Code Flash Block 0, so we'd like to understand the exact mechanism before deciding on a fix. Thank you again for your continued support. Best, Chibeom Re: S32K312: NMI triggered before Reset_Handler executes, only after Functional (SW) Reset, on speci Hi @Chibeom, UTEST in indeed in BLOCK 0. Refer to the RM:  Table 103. Flash block configuration S32K3xx_Memory_map.xlsx Also, AN13388 (S32K3 Memories Guide) Chapter 3. Flash memory states: "There are five blocks as maximum and two blocks as minimum." Block 0 - 4, while UTEST is in Block 0. Regards, Daniel