#ftm_pwm_S32K116 こんにちは、NXPの同僚の皆様： ftm_pwm_s32k116プロジェクトについて助けを求めています。実際のところ、コードや設定をどう変えても、MCUはデフォルトチャネル(FTM0-チャネル0、つまりPTD15）。 これが私の手順です。 1.サンプルから新しいプロジェクトをインポートします。 2.コンパイルするとすべて合格し、ピンマルチプレクサとフレックスタイマーの設定を確認しましたが問題はありませんでした（実際にはNXPのサンプルからなので、完全に正しいと思います）。 3.次に、それをS32K116に書き込みます。 4.PTD15の波形を観察しましたが、何も見つかりませんでした。ほぼ2日間試しました。 私のプロジェクトのzipファイルは以下のとおりです。ありがとうございます。 Re: #ftm_pwm_S32K116 プロジェクトを添付してください Re: #ftm_pwm_S32K116 こんにちは、 @Tracy_Lu さん。 まず、プロセッサ Expertを使っているので、古いソフトウェアバージョンを使っているようですね。S32K1デバイスで開発を始める場合は、最新のソフトウェアとツール、現在S32K1_S32M24X リアルタイム・ドライバ AUTOSAR R21-11 バージョン3.0.0の使用をお勧めします(S32K1用のリアルタイム・ドライバ)とS32プラットフォーム向けのS32 Design Studio(S32 Design Studio |NXP Semiconductors)を共同で提供しています。 しかし、S32K1 SDKsを使い続けたい場合は、最新のSDKsバージョンがS32 Design Studio for S32 プラットフォーム 3.4に付属していました。 また、EVBを使っているのかカスタムボードなのか教えていただけますか? 現在のソフトウェア環境を維持したい場合は、使っている正確なS32K1 SDKバージョンも共有していただけると助かります。 BR、VaneB Re: #ftm_pwm_S32K116 こんにちは、NXPの同僚の皆様： 迅速かつプロフェッショナルなご回答ありがとうございます。サンプルから別のプロジェクトS32K116_Project_FTMに変更し、コードを修正しました（gemini AIの支援を受けて）。コンパイルとデバッグ中に問題が発生するエンジニアの方々が解決できるよう、以下の点を共有したいと思います。 1.私はFTM機能を使用して、PMIC（TPS650366）のESM（エラー信号モニタリング）に応答します。 2.at 最初にftm_pwm_S32k116プロジェクトを使い、約2日間コンパイルとデバッグに失敗しました。割り当てられたピンで出力PWMが見当たりません。そして、Gemini AIの助けを借りて正しい設定とデバッグをしているはずです。 3.次に、S32K116_Project_FTM という名前の別の例を見つけ、それを試してコンパイルしましたが、エラーはありませんでした。そして、PTD15(FTM0CH0)/16(FTM0CH1) という構成済みピンの出力が得られました。初期周波数は 1Hz/5Hz ですが、ゴールが近いことがわかりました。 4. 実はPWM周波数は40KHz付近で必要なので、次のステップはシステムの周波数プリスケーラ、MOD値、CnV(デューティサイクル)を変更することだと分かっていますが、MOD値は変更できません(値は変えるだけでMCUのルート場所に書き込めません)。何度も試して、役立つ情報を探しました。 5.最後に、MOD値を変更したい場合は、いくつかの前提条件を満たす必要があることがわかりました。たとえば、クロックを閉じ、書き込み保護を解除する必要があります...。 6.以下はコンパイル後の私のコードで、正常に動作します（PTD16で約48KHzの出力）。 int main(void) { /*! * 初期化: * ======================= */ WDOG_disable(); /* ウォッチドッグを無効にする */ SOSC_init_40MHz(); /* 40 MHz水晶発振器用のシステム発振器を初期化します */ RUN_mode_48MHz(); /* クロックを初期化: 48 MHz システム、コア、バス、 24 MHz フラッシュ。*/    FTM0_init(); /* 8 MHz SIRCDIV1_CLK を使用して FTM0 を初期化します */    //FTM0_CH0_OC_init();    /* FTM0 CH0、PTD15 を初期化 */   FTM0_CH1_PWM_init();    /* FTM0 CH1、PTD16 を初期化 */   FTM0_CH6_IC_init();    /* FTM0 CH6、PTE8 を初期化します  */ FTM1_Init(); FTM1_CH1_PWM_init(); PORT_init(); /* ポートの設定 */   start_FTM0_counter();  /* FTM0カウンタを開始 */   /*! * 無限： * ======================== */ のために（;;）   { //FTM0_CH0_output_compare();/* 出力比較が一致した場合: */   /* ピンの切り替え（ハードウェアによる自動切り替え） */   /* フラグ 8 をクリア */   /* リロードタイマー */ //FTM0_CH6_input_capture(); /* 入力がキャプチャされた場合：フラグをクリアし、タイマーを読み取る */   } } 7.インポートコードは以下のとおりです（FTM0_init()、FTM0_CH1_PWM_init()）： void FTM0_init(void) {/** * FTM0 クロック: * ================================================== */ PCC->PCCn[PCC_FTM0_INDEX] &= ~PCC_PCCn_CGC_MASK; /* 設定のためにクロックが無効になっていることを確認します */ PCC->PCCn[PCC_FTM0_INDEX] |= PCC_PCCn_PCS(0b010) /* クロックソース=1、8 MHz SIRCDIV1_CLK */ | PCC_PCCn_CGC_MASK; /* FTMレジスタのクロックを有効にする */ /*! * FTM0 の初期化: * =================================================== */ // 1. 最初のステップ：FTM 時間钟彻底关闭（CLKS = 0）、この時点では完全に構成可能な状態です FTM0->SC = 0x00000000; // 2. 2 番目：写保护并开启 FTM 完全モード volatile uint32_t dummy = FTM0->MODE; FTM0->MODE |= FTM_MODE_WPDIS_MASK; /* 禁止用写保护 */ FTM0->MODE |= FTM_MODE_FTMEN_MASK; /* 开启 FTM 完全モード */ // 3. 第三步：時钟关闭の安全状態下、顺利ハンドルMODと比较值写进去 FTM0->CNTIN = 0U; FTM0->MOD = 166 - 1; /* 8MHz / 166 ≈ 48.19 kHz */ // 4. 4 番目: 構成チャネル 1 (PTD16) は周縁 PWM モードです FTM0->CONTROLS[1].CnSC = FTM_CnSC_MSB_MASK | FTM_CnSC_ELSB_MASK; FTM0->コントロール[1].CnV = 83; /* 50% 占空比 (83 < 165) */ // 5. 第五章：极性と組み合わせモード清零 FTM0->COMBINE = 0x00000000; FTM0->POL = 0x00000000; // 6. 最後の一步：すべてのパラメータ已经安稳書入後，才真正开启道输出和時間钟源！ FTM0->SC = FTM_SC_PWMEN0_MASK | FTM_SC_PWMEN1_マスク | FTM_SC_PS(0) /* PS = 0 (不分周波数) */ | FTM_SC_CLKS(1); /* CLKS = 1 (最終启アニメーション计数器) */ } void FTM0_CH1_PWM_init(void) { /** * FTM0、PWMモードでのチャネル1: * ================================================== */ FTM0->CONTROLS[1].CnSC = FTM_CnSC_MSB_MASK |FTM_CnSC_ELSB_MASK;  /* FTM0 ch1: エッジアラインメント PWM、低真パルス */ /* CHIE (ちゃん割り込みエナ) = 0 (デフォルト) */ /* MSB:MSA (チャンネルモード選択)=0b10、エッジアラインPWM */ /* ELSB:ELSA (chan Edge/Level Select)=0b10、low true */   FTM0->CONTROLS[1].CnV =  46875; /* FTM0 ch1 比較値 (デューティサイクル約75%) */ }

KW47 Deep Sleep During BLE Advertising - Recommended Approach and Reference Example Dear NXP Support, I would like to inquire about the low power functionality of the KW47. Environment MCU: KW47 SDK: SDK_26_03_00_KW47-EVK IDE: IAR Embedded Workbench RTOS: FreeRTOS Hardware: Custom Board Our goal is to reduce power consumption while operating as a BLE Peripheral. I have attached a diagram illustrating the intended behavior. Please note that the figure is a conceptual illustration and does not represent actual current consumption values. It is intended to show the expected relationship between Deep Sleep operation and BLE-related events. The intended behavior is as follows: Deep Sleep is used as the low power mode. Advertising transmission is handled by the BLE stack and SDK. Low power operation is enabled immediately after startup. The device automatically enters Deep Sleep when FreeRTOS enters the Idle state. While operating as a BLE Peripheral and continuing advertising, the CPU enters Deep Sleep whenever it becomes idle. The device wakes only when BLE stack processing is required, such as during Advertising Events, Connection Requests, or Connection Events, and returns to Deep Sleep after the required processing has completed. Based on the Low Power Application Developers Guide, it appears that Bluetooth LE applications can use Deep Sleep even while advertising. However, we could not determine which SDK example project should be used as a reference for this implementation. Could you please advise on the following points? What is the recommended approach to achieve the behavior described above? Which SDK example project should be used as a reference? Is there any example that automatically enters Sleep/Deep Sleep while advertising and automatically wakes up when BLE events occur? What is the recommended behavior while a BLE connection is established? Is it recommended to enter Deep Sleep between Connection Intervals, or should the device remain active while connected? Thank you for your support. Best regards,     Protocol: Bluetooth Re: KW47 Deep Sleep During BLE Advertising - Recommended Approach and Reference Example Hi Habib, Thank you for the information and for sharing AN14554. I will review the document, especially Sections 3.2.1 and 4.2.2.6, to better understand the recommended low-power software configuration and Deep Sleep behavior during BLE connection. I appreciate your support. Best regards, hyama Re: KW47 Deep Sleep During BLE Advertising - Recommended Approach and Reference Example Hello @hyama, Please refer to AN14554, which provides the configuration steps to achieve an optimized low-power profile while maintaining high system performance. It also describes the measurement setup and procedures used to measure the current consumption of the KW47. Specifically, Section 3.2.1 describes the recommended software configuration for low-power operation. this example is available in both baremetal and FreeRTOS versions. Also, section 4.2.2.6 covers the connection mode measurements and confirms that the device enters Deep Sleep between Connection Intervals.  BR, Habib

LPC55S66 Flash Controller READ_SINGLE_WORD Initialization and ECC Handling at 96 MHz I'm developing firmware for an LPC55S66JBD64 and need to read internal flash reliably, including erased or partially programmed pages that may contain invalid ECC information. The application stores configuration data in two redundant flash regions, with CRC validation and power-loss recovery. At startup, it must determine which copy is valid without risking a HardFault when reading erased or corrupted flash. Hardware identification: MCU: LPC55S66JBD64 DEVICE_ID0: 0x501022C2 DIEID: 0x000426B1 Boot ROM version: 4.3.0 ROM Flash API version: 1.0.0 SDK: SDK_2.x_LPC55S66, version 26.06.00 FLASHIAP driver: 2.1.5 Background: I initially investigated the SDK's FLASH_Read() function. For boot ROM major version 4, the driver selects the hardcoded address 0x130043A3. However, examining the ROM using GDB indicates that this address points into the middle of another routine, after its stack initialization. Therefore, I am reluctant to call this function without confirmation that it is compatible with ROM 4.3.0. I subsequently found NXP's example project lpcxpresso55s69_led_blinky_memoryread.zip, which demonstrates reading flash through the controller's READ_SINGLE_WORD command rather than using the ROM FLASH_Read() function. I would prefer to use this documented controller-based method. My questions: When running at 96 MHz, what initialization and timing configuration is required before issuing the flash controller's READ_SINGLE_WORD, BLANK_CHECK, and REPORT_ECC commands? Can the controller's automatic initialization following reset be relied upon, or must software explicitly configure additional timing or trim settings? If a READ_SINGLE_WORD command fails to complete, what is the supported recovery procedure? Is a system reset sufficient, or is a controller-specific reset or abort sequence required? Is there an official NXP example showing robust handling of erased or ECC-corrupted flash pages on the LPC55S66? Alternatively, can NXP confirm whether the SDK's FLASH_Read() ROM address 0x130043A3 is valid for boot ROM 4.3.0? I have reviewed UM11126, AN12949, the FLASHIAP SDK driver, and the LPC55S69 memory-read demonstration. The demonstration clarifies the read-command sequence but does not appear to address timeout recovery or the precise initialization requirements. Any clarification or reference to a supported implementation would be appreciated. Thank you. Re: LPC55S66 Flash Controller READ_SINGLE_WORD Initialization and ECC Handling at 96 MHz Hello @ICE  Based on your requirements, I recommend referring to AN12327. https://www.nxp.com.cn/docs/en/application-note/AN12327.pdf    This application note demonstrates a dual-image secondary bootloader, which similarly checks multiple Flash regions during startup and determines whether the stored images are valid. It uses CRC32, version information, and an image marker/header to verify image integrity.   Referring to this application can help save development time.   Thank you.   BR Alice Re: LPC55S66 Flash Controller READ_SINGLE_WORD Initialization and ECC Handling at 96 MHz Thank you for recommending AN12327. I looked at the application note and its associated source code. The example confirms that controller-based reads using READ_SINGLE_WORD can avoid the AHB HardFault issue associated with erased flash. I also found that the MCUXpresso example configures SET_READ_MODE with a value of 8 when operating at 96 MHz. I have three remaining questions: Timing: For the LPC55S66JBD64 at 96 MHz, is it correct to configure SET_READ_MODE using DATAW0 = 0x00000008, or are additional fields or trim values required? Initialization: Can I rely on the flash controller's automatic initialization and trim loading after reset, or must I call the ROM FLASH_Init function before using READ_SINGLE_WORD and BLANK_CHECK? Timeout recovery: If a flash-controller command fails to set DONE, or a controller register access stalls, what is the recommended recovery procedure? Is a system reset sufficient? My hardware reports: DEVICE_ID0: 0x501022C2 DIEID: 0x000426B1 Boot ROM: 4.3.0 Flash API version: 1.0.0 I'm specifically trying to ensure that startup reads of erased or partially programmed configuration flash are safe. Thank you.

KW47 在 BLE 广播期间进入深度睡眠状态 - 推荐方法和参考示例 尊敬的NXP技术支持： 我想咨询一下KW47的低功耗功能。 环境 MCU：KW47 SDK：SDK_26_03_00_KW47-EVK IDE：IAR Embedded Workbench 实时操作系统：FreeRTOS 硬件：定制板 我们的目标是在作为 BLE 外设运行时降低功耗。 我附上了一张图表，说明了预期的行为。 请注意，该图为概念示意图，并不代表实际的当前消耗值。其目的是展示深度睡眠操作与 BLE 相关事件之间的预期关系。 预期行为如下： 深度睡眠模式用作低电源模式。 广告传输由 BLE 协议栈和 SDK 处理。 启动后立即启用低功耗模式。 当 FreeRTOS 进入IDLE状态时，设备会自动进入深度睡眠状态。 当 CPU 作为 BLE 外围设备运行并持续广播时，CPU 会在空闲时进入深度睡眠状态。 设备仅在需要 BLE 协议栈处理时才会唤醒，例如在广播事件、连接请求或连接事件期间，并在所需处理完成后返回深度睡眠。 根据低功耗应用开发者指南，蓝牙低功耗应用即使在广播期间也可以使用深度睡眠模式。但是，我们无法确定应该使用哪个 SDK 示例项目作为此实现的参考。 请您就以下几点提供建议？ 为实现上述行为，推荐采用什么方法？ 应该使用哪个 SDK 示例项目作为参考？ 是否有任何示例可以在广播时自动进入睡眠/深度睡眠状态，并在发生 BLE 事件时自动唤醒？ 建立 BLE 连接时，建议采取哪些行为？是否建议在连接间隔期间让设备进入深度睡眠状态，还是应该在连接期间保持设备处于活动状态？ 感谢您的支持。 顺祝商祺！     协议：蓝牙 Re: KW47 Deep Sleep During BLE Advertising - Recommended Approach and Reference Example 你好，哈比卜， 感谢您提供的信息和分享 AN14554。 我将仔细阅读该文档，特别是第 3.2.1 节和第 4.2.2.6 节，以便更好地了解推荐的低功耗软件配置和 BLE 连接期间的深度睡眠行为。 感谢您的支持。 此致， 海马 Re: KW47 Deep Sleep During BLE Advertising - Recommended Approach and Reference Example 你好@hyama ， 请参考AN14554 ，其中提供了在保持高系统性能的同时实现优化低功耗我的的配置步骤。它还描述了用于测量 KW47 电流消耗的测量装置和程序。 具体而言，第 3.2.1 节描述了低功耗运行的推荐软件配置。此示例在裸机和 FreeRTOS 版本中均可用。此外，4.2.2.6 节涵盖了连接模式的测量，并确认设备在连接间隔期间进入深度睡眠状态。 BR， 哈比卜

i.MX 93 AHAB Keys revocation procedure doubts Hello, we are working on SRK revocation for an i.MX93 product that is updated over the air, and we could not find a complete description of the procedure. We have read the thread imx93: SRK revocation (https://community.nxp.com/t5/i-MX-Processors/imx93-SRK-revocation/td-p/1827004), the Reference Manual (§9.5.1.3.2.3, SRK revoke) and AN14954, and we would like to confirm a few points. 1. ahab_commit in the field In the thread above, a container signed with SRK2 and Revocations = 0x1 did not revoke SRK1 until ahab_commit 0x10 was run. We would like to understand how the commit is meant to be used on devices that receive later updates: - Is it enough to run the commit once, after the container carrying the revoke mask has been authenticated? - Or can the commit be left permanently in the boot command once at least one key has been revoked, so that any build installed afterwards applies the revocation? Is it safe and without effect when there is nothing new to commit? - Must the containers of later builds keep the same srk_revocations value (the Reference Manual says the ELE checks that the revoke bits in the container match what is already set in the fuses), and which containers have to carry it (the boot container and the OS container)? 2. Multiple or cross revocation A container signed with one SRK can revoke a different one (as in the thread). Can the revoke mask contain several bits, including all the other SRKs? Is there a check in the ELE that prevents a container signed with a compromised SRK from revoking the remaining ones, or is this something that has to be handled by key management? 3. Checking the revocation state Is there a supported way to know which SRKs are revoked, from U-Boot or from Linux? With fuse sense most words beyond bank 6 return ERROR on our board, and the nvmem interface shows zeros for them. Would a functional check (authenticating a small container signed with each SRK and looking at the ELE events) be a reasonable approach? 4. fuse override for tests From AN14954 we understood that the shadow fuses can be overridden in OEM Open without burning the e-fuses. Does the ELE use the shadow value of the SRK hash fuses when authenticating containers, so that the signing chain can be tested this way without writing the hash? And is there any way to simulate a revocation with this mechanism? 5. SRK table after closing The hash covers the whole SRK table (4 keys). Once the hash is written, can the table still be changed (guess no since they are fused), even for positions that were left empty at the time? So basically, is it possible to only write 2 keys and add 2 later? We understand that part of the fuse information is covered by the Security Reference Manual under NDA. If so, a pointer to the relevant document or section, or even a high-level description of the procedure, would already help a lot. Given the upcoming Cyber Resilience Act, key revocation is going to become a standard requirement for many products, so a clear public description would be very valuable Thanks in advance

LPC55S66 フラッシュコントローラ READ_SINGLE_WORD 96 MHzでの初期化およびECC処理 私はLPC55S66JBD64用のファームウェアを開発しており、内部フラッシュを確実に読み取る必要があります。消去されたページや部分的にプログラムされたページも含めて、無効なECC情報が含まれている可能性があります。 このアプリケーションは、CRC検証と電力損失回復機能を備えた2つの冗長フラッシュ領域に設定データを格納します。起動時に、消去または破損したフラッシュメモリを読み取る際にハードフォルトが発生するリスクを冒すことなく、どのコピーが有効であるかを判断する必要がある。 ハードウェア識別: MCU:LPC55S66JBD64 DEVICE_ID0: 0x501022C2 DIEID: 0x000426B1 ブートROMバージョン：4.3.0 ROMフラッシュAPIバージョン：1.0.0 SDK: SDK_2.x_LPC55S66,バージョン 26.06.00 FLASHIAPドライバ:2.1.5 バックグラウンド: 最初はSDKのFLASH_Read()機能を調べました。起動ROMメジャーバージョン4では、ドライバがハードコードされたアドレス0x130043A3を選択します。 しかし、GDBを使用してROMを調べたところ、このアドレスはスタック初期化後の別のルーチンの途中を指していることがわかった。したがって、ROM 4.3.0との互換性が確認されない限り、この関数を呼び出すことには抵抗があります。 その後、NXPのプロジェクトlpcxpresso55s69_led_blinky_memoryread.zip例を見つけ ました。これはROM FLASH_Read() 関数 を使うのではなく 、コントローラのREAD_SINGLE_WORDコマンドでフラッシュを読み取 るデモンストレーション です。 私はこのドキュメント化されたコントローラベースの方法を使いたいと思っています。 私の質問： 96 MHzで動作する場合、フラッシュコントローラのREAD_SINGLE_WORD、BLANK_CHECK、REPORT_ECCコマンドを出す前に、どのような初期化やタイミング設定が必要です か? リセット後のコントローラの自動初期化は信頼できるのでしょうか、それともソフトウェアが追加のタイミングやトリム設定を明示的に設定しなければならないのでしょうか? READ_SINGLE_WORDコマンドが 完了しない場合、対応可能な復旧手順は何でしょうか?システムリセットで十分ですか?それともコントローラ固有のリセットやアボートシーケンスが必要ですか? LPC55S66上で、消去されたフラッシュページやECCエラーが発生したフラッシュページを確実に処理するNXPの公式サンプルはありますか？ あるいは、NXPはSDKのFLASH_Read()ROM アドレス0x130043A3がブートROM 4.3.0に有効かどうかを確認できますか? UM11126、AN12949、FLASHIAP SDKドライバ、LPC55S69メモリ読み取りデモンストレーションをレビューしました。このデモンストレーションでは読み取りコマンドのシーケンスは明確に示されているが、タイムアウトからの復旧や正確な初期化要件については触れられていないようだ。 ご説明や、サポートされている実装例に関する情報があれば幸いです。 よろしくお願いします。 Re: LPC55S66 Flash Controller READ_SINGLE_WORD Initialization and ECC Handling at 96 MHz こんにちは@ICE お客様のご要望に基づき、AN12327を参照することをお勧めします。 https://www.nxp.com.cn/docs/en/application-note/AN12327.pdf   このアプリケーションノートでは、起動時に複数のFlash領域をチェックし、保存されたイメージの有効性を判断するデュアルイメージセカンダリブートローダーを示しています。画像の整合性を検証するために、CRC32、バージョン情報、および画像マーカー／ヘッダーを使用します。   このアプリケーションを参照することで、開発時間の節約に役立ちます。   よろしくお願いします。   BR アリス Re: LPC55S66 Flash Controller READ_SINGLE_WORD Initialization and ECC Handling at 96 MHz AN12327をお勧めいただきありがとうございます。アプリケーションノートとそれに関連するソースコードを確認しました。 この例は、READ_SINGLE_WORDを用いたコントローラベースの読み取りが消去フラッシュに関連するAHBハードフォールト問題を回避できることを確認しています。 また、MCUXpressoのサンプルでは、96MHzで動作する場合、SET_READ_MODEの値が8に設定されていることも分かりました。 私にはまだ３つの質問があります。 タイミング： LPC55S66JBD64（96MHz）の場合、DATAW0 = 0x00000008を使用してSET_READ_MODEを設定するのは正しいでしょうか、それとも追加のフィールドやトリム値が必要でしょうか？ 初期化: リセット後のフラッシュコントローラの自動初期化とトリムロードに頼れますか?それともREAD_SINGLE_WORDやBLANK_CHECKを使う前にROM FLASH_Init機能を呼び出すべきでしょうか? タイムアウト回復: フラッシュコントローラコマンドがDONEを設定できなかったり、コントローラレジスタアクセスが停止した場合、推奨される復旧手順は何でしょうか?システムのリセットで十分でしょうか? 私のハードウェアレポート： DEVICE_ID0: 0x501022C2 DIEID: 0x000426B1 ブートROM: 4.3.0 Flash API バージョン: 1.0.0 私が特に目指しているのは、消去済みまたは部分的にプログラムされた設定フラッシュメモリの起動時の読み出しが安全であることを確認することです。 よろしくお願いします。

i.MX 93 AHABキーの失効手続きに関する疑問 こんにちは、 現在、i.MX93製品のSRK取り消しを進めており、無線で更新されていますが、手順の完全な説明は見つかりませんでした。私たちはThread imx93を読みました:SRK取り消し(https://community.nxp.com/t5/i-MX-Processors/imx93-SRK-revocation/td-p/1827004)、リファレンス・マニュアル(§9.5.1.3.2.3、SRK取り消し)、およびAN14954。いくつかの点を確認したいと思います。 1. 現場でのahab_commit 上記のThreadでは、SRK2とRevocations = 0x1で署名されたコンテナは、ahab_commit 0x10実行されるまでSRK1を取り消しませんでした。私たちは、コミットが後のアップデートを受けるデバイスでどのように使われるのかを理解したいと考えています。 - リヴォークマスクを搭載したコンテナが認証された後、コミットを一度実行するだけで十分でしょうか? - あるいは、少なくとも1つのキーが取り消された後も、コミットをブートコマンドに永久に残し、SO、その後インストールされたビルドがその取り消しを適用できるようにできますか?新しい行動がなければ安全で効果がないのでしょうか? - 後のビルドのコンテナは同じsrk_revocations値を保持しなければなりませんか?(リファレンス・マニュアルによると、ELEはコンテナ内のリボークビットがヒューズに既に設定されているものと一致しているかを確認します)、どのコンテナ(ブートコンテナとOSコンテナ)がそれを運ぶ必要がありますか? 2. 複数またはクロスの取り消し 1つのSRKで署名されたコンテナは、別のSRKを取り消すことができます(Threadのように)。リヴォークマスクは他のすべてのSRKを含めて複数のビットを含めることはできますか?ELEに、侵害されたSRKで署名されたコンテナが残りのSRKを取り消すのを防ぐチェック機能はありますか?それとも鍵マネジメントが処理しなければならないのでしょうか? 3. 取り消し状態の確認 どのSRKが取り消されたか、U-BootからかLinux側で確認できるサポートされた方法はありますか?ヒューズセンスを使うと、バンク6以降のほとんどのワードはボード上でエラーを返し、nvmemインターフェースではそれらに対してゼロが表示されます。機能チェック(各SRKに署名された小さなコンテナを認証し、ELEイベント情報を確認する)は妥当な方法でしょうか? 4. 試験用のヒューズオーバーライド AN14954から、OEM Openではシャドウヒューズを上書きしてもeヒューズを焼き切れないと分かりました。ELEはコンテナ認証時にSRKハッシュヒューズのシャドウ値を使い、ハッシュを書かずにこの方法で署名チェーンをテストできるのでしょうか?この仕組みを使って、免許の取り消しをシミュレートする方法はありますか？ 5. 閉鎖後のSRKテーブル このハッシュはSRKテーブル全体（4つのキー）をカバーしています。ハッシュが書き込まれた後、テーブルは(フュージョンされているのでおそらく無理です)変更できますか?その時点で空いた位置でも?SO、2つのキーだけを書いて後で2つ追加することは可能でしょうか? 信管情報の一部はNDAに基づくセキュリティリファレンスマニュアルでカバーされていると理解しています。もしそうなら、関連する文書やセクションへのポインタ、あるいは手順の高レベルの説明があれば、すでに大いに役立ちます。今後のサイバーレジリエンス法(Cyber Resilience Act)を踏まえ、キーの取り消しは多くの製品で標準的な要件となるため、明確な公開説明は非常に価値があります 前もって感謝します

KW47 BLEアドバタイジング中のディープスリープ - 推奨アプローチと参考例 NXPサポートの皆様、 KW47の低電力機能についてお伺いしたいのですが。 環境 MCU:KW47 SDK:SDK_26_03_00_KW47-EVK IDE:IAR Embedded Workbench RTOS: FreeRTOS ハードウェア: カスタムボード 私たちの目標は、BLEペリフェラルとして運用する際の消費電力を削減することです。 意図した動作を示す図を添付しました。 この図は概念的な図解であり、実際の現在の消費量を表すものではないことにご注意ください。これは、ディープスリープ作戦とBLE関連イベント情報との期待される関係を示すことを目的としています。 意図された動作は以下のとおりです。 ディープスリープは低電力モードとして使用されます。 広告の送信はBLEスタックとSDKによって処理されます。 起動直後から低消費電力動作が有効になります。 FreeRTOSがアイドル状態になると、デバイスは自動的にディープスリープ状態に入ります。 BLEペリフェラルとして動作し、広告を続けている間、CPUはアイドルになるとディープスリープに入ります。 デバイスはBLEスタックプロセッシングが必要な場合のみ、例えば広告イベント情報、接続リクエスト、接続イベント情報の際にのみ起動し、必要なプロセッシングが完了するとディープスリープに戻ります。 Low Power Application Developers Guideによると、Bluetooth LEアプリケーションは広告中でもディープスリープを利用できるようです。しかし、この実装の参照としてどのSDKサンプルプロジェクトを使うべきかは判断できませんでした。 以下の点についてアドバイスいただけますか? 上記のような動作を実現するための推奨されるアプローチは何ですか？ どのSDK例プロジェクトを参考にすべきでしょうか? 広告中に自動的にスリープ/ディープスリープに入り、BLEイベント情報が発生すると自動的に起きる例はありますか? BLE接続確立時の推奨される動作は何ですか？接続間隔の間にディープスリープに入るのが推奨されますか?それともコネクテッド中はデバイスはアクティブのままにすべきでしょうか? 再開まで今しばらくお待ちください。 よろしくお願いいたします。     プロトコル：Bluetooth Re: KW47 Deep Sleep During BLE Advertising - Recommended Approach and Reference Example こんにちは、ハビブさん。 情報提供とAN14554の共有、ありがとうございます。 特に3.2.1および4.2.2.6のセクションを確認し、BLE接続時の推奨される低消費電力ソフトウェア構成とディープスリープの挙動をよりよく理解します。 サポートいただき感謝します。 よろしくお願いします、 ヒヤマ Re: KW47 Deep Sleep During BLE Advertising - Recommended Approach and Reference Example こんにちは、 @hyama さん。 最適な低消費電力プロファイルを実現しつつ、高いシステム性能を維持するための設定手順については、 AN14554を参照してください。また、KW47の電流消費量を測定するために使用された測定設定と手順についても説明しています。 具体的には、セクション3.2.1は低消費電力動作のための推奨ソフトウェア構成を説明しています。このサンプルは、ベアメタル版とFreeRTOS版の両方で利用可能です。また、4.2.2.6項では接続モードの測定について説明し、接続間隔中にデバイスがディープスリープ状態に入ることを確認しています。 BR、 ハビブ

Flexcan callback is not executed ocassionally I have implemented flexcan callback to receive FLEXCAN_EVENT_RX_COMPLETE and FLEXCAN_EVENT_TX_COMPLETE events. When RX event is generated, the received can buffer is copied into a queue. And when TX event is generated a can_available flag is set to true to send the next can frame.  Please find the code snippet below void flexcan1_callback(uint8 instance, Flexcan_Ip_EventType eventType, uint32 buffIdx, const Flexcan_Ip_StateType *flexcanState) { (void)flexcanState; (void)buffIdx; if (eventType == FLEXCAN_EVENT_RX_COMPLETE) { can_frame_t cebms_can_frame = {.type_e=CAN_EXTD_ID}; if (buffIdx == can_md_idx_rx_u8[CAN_STD_ID]) { cebms_can_frame.type_e = CAN_STD_ID; } xQueueSendFromISR(chg_rx_queue[1], (const void*)&cebms_can_frame, &xHigherPriorityTaskWoken); FlexCAN_Ip_Receive(instance, buffIdx, &rxData[instance][cebms_can_frame.type_e], FALSE); } else if ((FLEXCAN_EVENT_TX_COMPLETE == eventType)) { can_tx_available[instance] = TRUE; } }       boolean Can_Tx(uint8_t instance, can_frame_t* can_frame) { uint16_t can_timeout = 0xFFFFU; boolean can_return = FALSE; while ((can_tx_available[instance] == FALSE) && (can_timeout)) { can_timeout--; } if (can_tx_available[instance] == TRUE) { can_tx_available[instance] = FALSE; FlexCAN_Ip_Send(instance, can_md_idx_tx_u8[can_frame->type_e], &can_data_info[can_frame->type_e], can_frame->id.u32, (uint8 *)&can_frame->data.u8a); can_return = TRUE; printf("SUCCESS: 0x%08X", (unsigned int)can_frame->id.u32); } else { printf("FAILED: 0x%08X", (unsigned int)can_frame->id.u32); } return can_return; }   Here, sometimes when I try to transmit multiple can frames sequentially using the above function, FAILED is printed multiple times for those can ids in the sequence for approx 20 seconds. And suddenly can frames start getting transmitted and SUCCESS is printed. I have also attached a CAN logger to verify this, and the result is same on the CAN logger. When FAILED is printed, no messages are seen on the CAN logger.   Please help me out on this matter and whether my implementation is correct or not.   Thanks Gauri   #s32k311 #flexcan   Re: Flexcan callback is not executed ocassionally Hello @geeznxp, I will assume RTD 3.0.0 is used (based on you post history). I will also assume your other node is the PCAN-USB analyzer. From your description, I cannot immediately diagnose your application, however, here are some points to check: 1. Is can_tx_available declared as volatile? Since it is written inside an ISR (TX_COMPLETE callback) and read inside a task-level while-loop. Without the volatile qualifier, the compiler is free to cache false or never reload the variable in other iterations. 2. The ~20 second interval may also point to a bus-off event. Add a bus-off error case in the callback, to detect and handle the bus-off event.  3. I would also check ESR1 registers in the interval where FAILED is printed multiple times. Lastly, general points to check, CAN bus termination, bit rate configuration, FlexCAN_Ip return value, FlexCAN error callback registered. Best regards, Julián

S32DS 3.5のライセンス延長申請 こんにちは、 私のS32 Design Studioのライセンスがもうすぐ切れる。延長を手伝ってもらえますか? アクティベーションID: 5E5E-87D6-4F85-9A22 バージョン: 3.5 よろしくお願い申し上げます。 製品に適用されるライセンス: バージョン説明 3.5S32 プラットフォーム v.3.5 Design Studio ライセンス数:1 フルフィルメントID:201997687 有効期限:2026年11月4日 製品:S32 プラットフォーム v.3.5用 S32 Design Studio 機械: 6EF78E1197D8A04DBC0B058E7DE51D3F39A0F67C アクティベーションコード：5E5E-87D6-4F85-9A22

LPC55s16セキュアブートデバイスリカバリ 親愛なるnxpコミュニティの皆様、 私は以下のようにLPC55s16-EVKのセキュアブート機能をテストしていましたが、すべて予想通りにうまく動作したものの、最終的にボードが応答しなくなりました。 セキュアプロビジョニングツール用のワークスペースを作成し、 ビルドしたELFファイルから署名付きのプレーンイメージを生成し、それをフラッシュした。アプリケーションは稼働していました。 - その後、CMPAフラッシュリージョンでデバッグ認証を設定し、デバッグ認証を使い、これも動作しました。 次に、別のテストワークスペースを作成し、同じelfファイルに署名するための新しいROTKキーとイメージキーを生成しました。これは、CMPA領域に格納されているハッシュが異なるため、ROMブートローダーがこのファームウェアを拒否することをテストするためです。 - 新しいワークスペースでは、CMPA領域で何も変更していません。デフォルト設定が使用されていますが、私の考えではデバッグポートが有効になっているはずなのに、デバイスが応答しなくなってしまいました。 - 両方のCASEで、ライフサイクルは「発酵」として選ばれ、封印されたものではありません。 - nxpdebugmboxがタイムアウトエラーを返します。 - ISPピンをローに長押ししてリセットピンを押して離してISPモードにしようとすると、BLHostツールからpingの応答が全くありません。 - SPIやUSBインターフェースも使ってみましたが、結果は同じでした。 参考資料として、cmpa.json ファイルと、テストワークスペースである 2 番目のワークスペースのログファイルを添付します。 このデバイスをどうやって復旧させる方法はありますか?どんなご支援でも大変ありがたく思います。ありがとう Re: LPC55s16 secure boot device recovery こんにちは、 @Alice_Yang さん。 ご回答ありがとうございます。私には、2回目のCMPAリージョン書き込みでおそらくすべてCC_SOCU_DFLT CC_SOCU_PIN 0が書かれたため、デバッグインターフェースが永久に無効になっているように見えます。nxpdebugmboxというデバッグメールボックスツールを使ってみましたが、今回と同じエラーで応答タイムアウトが出ます。 Re: LPC55s16 secure boot device recovery こんにちは、 @xavier_es_developer さん。 ご質問ありがとうございます。 MCUXpressoのSecure Provisioning Tool(SEC)のDM-AP方法を使ってデバイスを消去してください。 MCUXpressoセキュアプロビジョニングツールからSECをダウンロードしインストールできます。NXP Semiconductors。 この方法でデバイスが正常に消去できるか確認してください。 もし問題が続く場合は、どうぞお気軽にお問い合わせください。 BR アリス Re: LPC55s16 secure boot device recovery こんにちは、 @xavier_es_developer さん。 検査結果から判断すると、基板は回収できないようです。 セキュアブートには、MCUXpresso Secure Provisioning Tool (SEC) の使用をお勧めします。シンプルで使いやすく、設定ミスのリスクを減らすのに役立ちます。 ダウンロードはこちらから： MCUXpressoセキュアプロビジョニングツール MCUXpressoセキュアプロビジョニングツールユーザーガイドのセクション6.5「LPC55(S)0x/1x/2x/6x またはNHS52SxxまたはMCXW23xデバイスワークフロー」をご参照ください。 よろしくお願いします。 アリス

FS26 can't enter LPOFF/StandBy state We use the infineon MCU TC37x With FS26 SBC. when request power down, SBC can't entry LPOFF/StandBy mode from Normal mode. the request command is normal, but sbc still in normal mode. I want to know which conditions prevent the state transform？ Re: FS26 can't enter LPOFF/StandBy state Hi Liu, Please check the following: 1. Confirm the fail-safe state before requesting low-power mode The low-power transition shown in the state diagram starts from the fail-safe Normal mode. Before sending the request, please read: FS_STATES at address 0x57 FS_DIAG_SAFETY1 at address 0x54 FS_DIAG_SAFETY2 at address 0x55 FS_OVUV_REG_STATUS at address 0x50 FS_STATES[4:0] = 0x0B indicates that the fail-safe state machine is in Normal mode. The diagnostic registers can also show whether a watchdog, SPI, FCCU, ERRMON, BIST or voltage-monitoring event has occurred. 2. Verify the complete two-step command sequence For LPOFF mode, write the following values to FS_LP_REQ at address 0x58: FS_LP_REQ[7:0] = 0xA5, which requests Pre-LPOFF mode. FS_LP_REQ[7:0] = 0x5A, which completes the transition to LPOFF mode. For Standby mode, the corresponding sequence is: 0xAA, which requests Pre-Standby mode. 0x55, which completes the transition to Standby mode. The second command must be received within 10 ms of the first. Please send the two commands back-to-back and confirm that both SPI frames use the correct fail-safe register selection, address, CRC and number of clock cycles. If the second command is missing, invalid or not received within the required interval, the requested low-power transition will not be completed.  3. Check for SPI errors Immediately after the first request, check FS_DIAG_SAFETY1 for: SPI_FS_CLK SPI_FS_REQ SPI_FS_CRC These bits indicate an incorrect number of SPI clocks, an invalid fail-safe SPI access, or a CRC error. Any of these conditions can explain why the low-power command was not accepted. 4. Exclude an immediate wake-up An enabled wake-up source that is already active, or that becomes active during the transition, can make the device wake up immediately and therefore appear to remain in Normal mode. Please check M_WIO_CFG for the enabled wake-up sources and their configured polarities: WAKE1 and WAKE2 GPIO1 and GPIO2 LDT SPI CSB transition In particular, if CSBWUEN = 1, subsequent SPI activity can wake the FS26 through a high-to-low CSB transition. After the device wakes up, M_WIO_FLG.WUEVENT[3:0] can be read to identify the detected wake-up source. Finally, please note that VPRE remains enabled in Standby mode and LDO1 or LDO2 may also remain enabled depending on the OTP configuration. Therefore, the presence of these rails alone does not prove that the FS26 remained in Normal mode. In LPOFF, the regulators are switched off and RSTB is low. BRs, Tomas

country of origin of S32Z280ABCK0MJFT which is the COO of S32Z280ABCK0MJFT Re: country of origin of S32Z280ABCK0MJFT Please, contact export control team at: [email protected] for more information.

S32Z280ABCK0MJFT 的原产国 他是 S32Z280ABCK0MJFT 的首席运营官 Re: country of origin of S32Z280ABCK0MJFT 请联系出口管制团队： [email protected] 了解更多信息。

FS26 无法进入 LPOFF/待机状态 我们使用英飞凌 TC37x MCU 和 FS26 单板计算机 (SBC)。当发出断电请求时，SBC 无法从正常模式进入 LPOFF/待机模式。断电请求命令正常，但 SBC 仍然处于正常模式。我想知道哪些条件会阻止状态转换？ Re: FS26 can't enter LPOFF/StandBy state 您好，刘， 请检查以下内容： 1. 在请求低功耗模式之前，请确认故障保护状态。 状态图中所示的低功耗转换从故障保护正常模式开始。发送请求前，请阅读以下内容： FS_STATES 地址 0x57 FS_DIAG_SAFETY1 地址 0x54 FS_DIAG_SAFETY2 地址 0x55 FS_OVUV_REG_STATUS 地址 0x50 FS_STATES[4:0] = 0x0B 表示故障保护状态机处于正常模式。诊断寄存器还可以显示是否发生了看门狗、SPI、FCCU、ERRMON、BIST 或电压监控事件。 2. 验证完整的两步命令序列 对于 LPOFF 模式，将以下值写入地址 0x58 处的 FS_LP_REQ： FS_LP_REQ[7:0] = 0xA5，请求 Pre-LPOFF 模式。 FS_LP_REQ[7:0] = 0x5A，完成向 LPOFF 模式的转换。 待机模式下，相应的序列为： 0xAA，请求进入预待机模式。 0x55，完成向待机模式的转换。 第二条命令必须在收到第一条命令后的 10 毫秒内收到。请连续发送这两个命令，并确认两个 SPI 帧都使用了正确的故障保护寄存器选择、地址、CRC 和时钟周期数。 如果第二个命令缺失、无效或未在规定时间内收到，则请求的低功耗转换将无法完成。 3. 检查 SPI 错误 首次请求后，立即检查 FS_DIAG_SAFETY1 是否存在以下情况： SPI_FS_CLK SPI_FS_REQ SPI_FS_CRC 这些位表示 SPI 时钟数不正确、故障保护 SPI 访问无效或 CRC 错误。以上任何一种情况都可能解释为什么低功耗命令未被接受。 4. 排除立即唤醒 如果已启用的唤醒源处于活动状态，或者在转换过程中变为活动状态，则设备可以立即唤醒，因此看起来仍处于正常模式。 请检查 M_WIO_CFG 以了解已启用的唤醒源及其配置的极性： WAKE1 和 WAKE2 GPIO1 和 GPIO2 激光动力测试 SPI CSB 过渡 特别是，如果 CSBWUEN = 1，则后续的 SPI 活动可以通过 CSB 从高到低的转换唤醒 FS26。设备唤醒后，可以读取 M_WIO_FLG.WUEVENT[3:0] 来识别检测到的唤醒源。 最后请注意，VPRE 在待机模式下仍保持启用状态，并且 LDO1 或 LDO2 也可能根据 OTP 配置保持启用状态。因此，仅凭这些轨道的存在并不能证明 FS26 保持正常模式。在 LPOFF 状态下，稳压器关闭，RSTB 为低电平。 BRs，托马斯

LPC55s16 安全引导设备恢复 尊敬的恩智浦社区成员： 我正在测试 LPC55s16-EVK 的安全启动功能，如下所示，一切都按预期运行良好，但最终我遇到了板子无响应的情况。 我创建了一个用于安全配置工具的工作区， - 从我构建的 elf 文件生成了一个纯签名映像，并将其刷入。应用程序正在运行。 - 然后我在 cmpa flash 区域中设置了调试身份验证，使用了调试凭据，它也正常工作。 然后我创建了另一个测试工作区，并生成了新的 ROTK 和镜像密钥来对同一个 elf 文件进行签名，目的是测试 ROM 引导加载程序是否会拒绝此固件，因为它在 cmpa 区域中存储的哈希值不同。 - 在新的工作区中，我没有更改 cmpa 区域的任何设置，它使用了默认设置，我认为默认设置启用了调试端口，但最终设备却无响应。 - 在这两种情况下，生命周期都被选择为发展阶段而非封闭阶段。 - nxpdebugmbox 返回超时错误。 当我尝试将设备置于ISP模式（方法是按住ISP引脚至低电平，然后按下并松开RESET引脚）时，BLHost工具无法ping通设备。 我也尝试过使用SPI和USB接口，但结果还是一样。 - 我附上了 cmpa.json 文件和我的第二个工作区（即测试工作区）的日志文件，供您参考。 有什么办法可以恢复这个设备吗？非常感谢您的帮助。谢谢 Re: LPC55s16 secure boot device recovery 你好@Alice_Yang 感谢您的回复。在我看来，调试接口似乎被永久禁用了，原因是第二次CMPA区域写入操作可能将CC_SOCU_PIN和CC_SOCU_DFLT的值全部写入了0。我尝试使用调试邮箱工具nxpdebugmbox，但遇到了和这次一样的响应超时错误。 Re: LPC55s16 secure boot device recovery 你好@xavier_es_developer 谢谢你的提问。 请使用 MCUXpresso 安全配置工具 (高效密码学标准\(SEC\)) 中的 DM-AP 方法擦除设备。 您可以从MCUXpresso Secure 配置 Tool | NXP 半导体下载并安装高效密码学标准\(SEC\)。 请检查是否可以使用此方法成功擦除设备数据。 如果问题仍然存在，请随时与我联系。 BR 爱丽丝 Re: LPC55s16 secure boot device recovery 你好@xavier_es_developer 根据您的测试结果，该板似乎无法修复。 为了确保安全启动，我建议使用 MCUXpresso 安全配置工具 高效密码学标准\(SEC\)。它简单易用，有助于降低配置错误的风险。 下载地址： MCUXpresso 安全配置工具 请参阅 MCUXpresso 安全配置工具用户指南中的第 6.5 节“LPC55(S)0x/1x/2x/6x 或 NHS52Sxx 或 MCXW23x 设备工作流程”。 谢谢！ 爱丽丝

LPC55s16 secure boot device recovery Dear nxp community, i was testing LPC55s16-EVK for the secure boot features as follows and everything worked well as expected but in the i ended up with non-responsive baord. I created a workspace for secure provisioning tool and - generated a plain signed image from my built elf file, and flashed it. Application was running. - Then in cmpa flash region i setup debug authentication for, with debug credentials and it worked as well. - Then i created another test workspace and generated new ROTK and Image keys to sign the same elf file, in order to test ROM bootloader will reject this firmware as it has different hash stored in cmpa region.  - In the new work space i did not change anything in cmpa region, it used default settings, that in my opinion are with debug port enabled, but i ended up with non responsive device,  - In both case the life cycle was selected as development not sealed. - nxpdebugmbox responds with timeout error.  -  when i try to bring the device in ISP mode by holding ISP pin low and pressing and releasing the reset pin then i cannot get any response of ping from BLHost tool.  -  I tried to use SPI and USB interfaces as well but the result is the same.  - i am attaching the cmpa.json file and the logfile of my 2nd workspace that is test workspace for the reference. Is there a way, how can recover this device? Any help will be much appreciated. Thanks Re: LPC55s16 secure boot device recovery Hello @xavier_es_developer  Thanks for your question. Please use the DM-AP method in MCUXpresso Secure Provisioning Tool (SEC) to erase the device. You can download and install SEC from MCUXpresso Secure Provisioning Tool | NXP Semiconductors. Please check whether the device can be erased successfully using this method. If the issue persists, please feel free to contact me. BR Alice Re: LPC55s16 secure boot device recovery Hello @Alice_Yang  Thank you for your response. To me it looks like the debug interface is disabled permanently because of the 2nd cmpa region write that probably wrote all 0 in  CC_SOCU_PIN and CC_SOCU_DFLT, I have tried using debug mailbox tool that is nxpdebugmbox, but i get the same error as response timeout as in this case.  Re: LPC55s16 secure boot device recovery Hello @xavier_es_developer  Based on your test results, it seems that the board cannot be recovered. For secure boot, I recommend using the MCUXpresso Secure Provisioning Tool (SEC). It is simple and easy to use, and can help reduce the risk of configuration errors. Download it from: MCUXpresso Secure Provisioning Tool Please refer to Section 6.5, "LPC55(S)0x/1x/2x/6x or NHS52Sxx or MCXW23x device workflow," in the MCUXpresso Secure Provisioning Tool User Guide. Thank you. Alice

S32Z280ABCK0MJFTの原産国 これはS32Z280ABCK0MJFTのCOOです。 Re: country of origin of S32Z280ABCK0MJFT どうぞ、輸出管理チームまでお問い合わせください: [email protected] 詳細については、こちらをご覧ください。

License Extension Request for S32DS 3.5 Hello, My S32 Design Studio license is about to expire. Could you please help extend it? Activation ID: 5E5E-87D6-4F85-9A22 Version: 3.5 Thank you License Applicable to Product(s):    Version    Description    3.5    S32 Design Studio for S32 Platform v.3.5 License Quantity: 1 Fulfillment ID: 201997687 Expiration Date: Nov 4, 2026 Product: S32 Design Studio for S32 Platform v.3.5 Machine: 6EF78E1197D8A04DBC0B058E7DE51D3F39A0F67C Activation Code: 5E5E-87D6-4F85-9A22

FS26はLPOFF/スタンバイ状態に入ることができません 私たちはInfineon MCU TC37xとFS26 SBCを使用しています。電源を要求停止すると、SBCは通常モードからLPOFF/スタンバイモードに入ることができません。リクエストコマンドは通常ですが、SBCはまだ通常モードです。状態変化を阻害する条件を知りたいのですが？ Re: FS26 can't enter LPOFF/StandBy state こんにちは、劉さん 以下の点をご確認ください。 1. 低電力モードを要求する前に、フェイルセーフ状態を確認してください。 状態図に示されている低電力遷移は、フェイルセーフな通常モードから始まります。リクエストを送信する前に、以下をお読みください。 アドレス0x57のFS_STATES FS_DIAG_SAFETY1 (アドレス 0x54) FS_DIAG_SAFETY2 (アドレス 0x55) アドレス0x50のFS_OVUV_REG_STATUS FS_STATES[4:0] = 0x0B は、フェイルセーフ状態マシンが通常モードであることを示します。診断レジスタは、ウォッチドッグ、SPI、FCCU、ERRMON、BIST、または電圧監視イベント情報が発生しているかどうかも示すことができます。 2. 2段階のコマンドシーケンス全体を確認する LPOFFモードの場合、アドレス0x58のFS_LP_REQに以下の値を書き込みます。 FS_LP_REQ[7:0] = 0xA5 は、Pre-LPOFF モードを要求します。 FS_LP_REQ[7:0] = 0x5Aとなり、LPOFFモードへの移行が完了します。 スタンバイモードの場合、対応するシーケンスは次のとおりです。 0xAAは、プリスタンバイモードを要求する。 0x55 はスタンバイモードへの移行を完了します。 2番目のコマンドは、最初のコマンドから10ミリ秒以内に受信されなければならない。2つのコマンドを連続して送信し、両方のSPIフレームが正しいフェイルセーフレジスタの選択、アドレス、CRC、およびクロックサイクル数を使用していることを確認してください。 2番目のコマンドが欠落している場合、無効な場合、または規定の間隔内に受信されなかった場合、要求された低電力遷移は完了しません。 3. SPIエラーを確認する 最初の要求直後に、FS_DIAG_SAFETY1 で以下を確認してください。 SPI_FS_CLK SPI_FS_REQ SPI_FS_CRC これらのビットは、SPIクロック数の誤り、フェイルセーフSPIアクセスの無効、またはCRCエラーを示します。これらの条件のいずれかが、低出力指令が受け入れられなかった理由を説明できます。 4. すぐに起こさない すでに有効であるか、移行中に活性化される起動源は、デバイスを即座に起動させ、通常モードのままに見えることがあります。 有効になっているウェイクアップソースとその設定済み極性については、M_WIO_CFG を確認してください。 WAKE1とWAKE2 GPIO1とGPIO2 LDT SPI CSB遷移 特に、CSBWUEN = 1の場合、その後のSPI活性によりFS26は高低CSB遷移を経て覚醒することがあります。デバイスが起動した後、M_WIO_FLG。WUEVENT[3:0]を読み取り、検出された起動源を特定することができます。 最後に、スタンバイモードでもVPREは有効なままであり、OTPの設定によってはLDO1またはLDO2も有効なままになる場合があることにご注意ください。したがって、これらのレールが存在することだけでは、FS26が通常モードのままであったことを証明するものではない。LPOFFではレギュレーターがオフになり、RSTBが低くなります。 BRs、トーマス