AMMCLib support for S32R294 e200z7 cores Hello NXP team, We are developing an application for the S32R294 and would like to use AMMCLib on its e200z7 cores. Is there an AMMCLib release that officially supports the S32R294? If not, could you recommend another NXP-provided math library that is compatible with the S32R294 e200z7 core? Please also let us know whether a specific S32 Design Studio toolchain, SDK, or RSDK version is required. Thank you. C|C++ Libraries Re: AMMCLib support for S32R294 e200z7 cores Hi Peter, Thank you for the clarification. Our target application is a radar signal-processing pipeline. We plan to run the following algorithms on the S32R294 e200z7 cores: DML-based direction-of-arrival estimation A small number of FFT operations Kalman filtering, including matrix multiplication, transposition, and linear-system solving or matrix inversion Feature extraction and lightweight radar target classification using vector, matrix, and statistical operations Running these algorithms on the e200z7 cores would reduce data transfers and data-format conversions between the SPT and e200z7, which should improve processing efficiency. We are looking for optimized FFT, complex arithmetic, matrix, vector, and linear algebra functions for the S32R294 e200z7 cores. Does NXP provide a suitable math or DSP library for these use cases?  Best regards, Re: AMMCLib support for S32R294 e200z7 cores Hello, There is not an AMMCLib release that officially supports the S32R294 platform. The AMMCLib device support list currently includes several Power Architecture MCU families (for example MPC577xK/MPC5775E), but S32R294 is not listed as a supported target. For S32R294 development, NXP's primary software offering is the Radar SDK for S32R29x together with the S32 Design Studio Power Architecture toolchain. What should be the target application? Best regards, Peter

Clarifications required for SBCFS2613 Main state Faults reaction Hi NXP, Could you please confirm whether a default fail-safe reaction (assertion of FSXB and RSTB) is configured for the following faults in the respective registers? M_TSD_FLG M_REG_FLG M_VSUP_FLG Since the faults in the above registers are configured to provide an INTB indication, clarification is required on whether they also have any default fail-safe reaction, such as assertion of FSXB and/or RSTB. Thanks, Sivahari G Re: Clarifications required for SBCFS2613 Main state Faults reaction Hi RafaR, I couldn't identify exactly which PN you were referring to? I am using MFS2613AMDA6. A fail-safe reaction such as FS0B (FSXB) and/or RSTB assertion is not automatically associated with the flag itself and depends on the corresponding fail-safe configuration. Yes, absolutely for all regulators UV/OV fault has failsafe configuration registers "FS_I_OVUV_SAFE_REACTION1" and " FS_I_OVUV_SAFE_REACTION2 ". But Is there any provision to configure fail-safe reaction for all regulator Over Current Faults? since we have provisions to configure INTB masking/unmasking for those faults. Example OC Faults(VBSTOV_I, VBSTOC_I, VPREOC_I, TRK1OC_I, COREOC_I) Thanks, Sivahari G Re: Clarifications required for SBCFS2613 Main state Faults reaction Hello Sivahari Good day! I couldn't identify exactly which PN you were referring to, but in general this applies to all versions of FS26. RafaR_0-1787266460038.pngRafaR_0-1787266460038.png In summary, the flags in M_TSD_FLG, M_REG_FLG, and M_VSUP_FLG are interrupt sources by default. A fail-safe reaction such as FS0B (FSXB) and/or RSTB assertion is not automatically associated with the flag itself and depends on the corresponding fail-safe configuration, with TSD faults being an explicit example that can be configured to escalate into Deep Fail Safe. I hope this information has helped you, please let me know if you need help with anything else. Have a great day and best of luck.

NXPはユーザーにPlug and TrustミドルウェアとMBED TLSをどのように統合することを期待しているのでしょうか? NXPはユーザーにPlug & Trustミドルウェアに付属しているMbed TLSのバージョンを使うことを期待しているのでしょうか?もしそうなら、NXPは新しいMbedのTLSバージョンを含む更新されたミドルウェアリリースをタイムリーに提供しているのでしょうか?例えば、現在のミドルウェアバンドルにはMbed TLS 3.6.2が含まれています。Mbed TLS 3.6.7は既に利用可能ですが。 SE050 Re: How Does NXP Expect Users to Integrate Mbed TLS with the Plug & Trust Middleware? こんにちは、@ph-yac さん。 ご連絡ありがとうございます！私の意見は以下の通りです。 Plug & Trust MWはMCUXpresso SDKの下流からMbed TLSを供給し、アップデートはNXPのH1/H2 SDKリリーススケジュールに従って行われ、すべての上流Mbed TLSパッチリリースを追跡するわけではありません。現在同梱されているバージョンは3.6.2です。次のアップデートでは、次のSDKのダウンストリームリリースサイクルが導入されます。 ミドルウェアはバンドルされたバージョンに対して正式に検証されていますが、同じ 3.6.x 内のパッチレベルのアップグレードではLTS支店は一般的にリスクが低い。お客様は、バンドルされたMbedのTLSソースファイルを手動で置き換えることを試みることができます。ビルド互換性は'SSS_HAVE_MBEDTLS_3_X' CMakeフラグで確認してください。NXPは、MWリリース間のすべてのパッチリリースを正式に検証するわけではありません。 最新のMWはMbed TLS 2.28.xと3.6.xの両方をサポートしています`SSS_HAVE_MBEDTLS_2_X` / `SSS_HAVE_MBEDTLS_3_X` CMakeフラグを介して分岐します。Mbed TLS 3.x と統合する場合は、**SSS ALT**（PSA ALT ではありません）を使用する必要があることにご注意ください。 Plug & Trust ミドルウェアにおけるMbed TLS 4.xのサポートは、2027年Q1のリリースに向けて現在検討されています。正式な約束はまだなされていないが、ロードマップには含まれている。 お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

imx8mp-evk SAI5 external I2S mic (SPH0645) - clock derivation fails, need help with correct clock Hello, Board: i.MX8MPLUSLPD4-EVK (8MPLUS-BB base board)   attach an external I2S MEMS microphone (Knowles SPH0645LM4H) to SAI5, using the SoC-side pins that are physically routed to the J21 (EXP_CN) expansion header via level shifters U57/U58, per the base board schematic (SPF-46370).   1. Hardware wiring (confirmed against schematic, verified on scope)   SPH0645 BCLK -> J21 pin 40 ("PDM_CLK",      SoC pad SAI5_RXC) SPH0645 LRCL -> J21 pin 32 ("PWM4_3V3",     SoC pad SAI5_RXFS) SPH0645 DOUT -> J21 pin 38 ("PDM_STREAM_0", SoC pad SAI5_RXD0) SPH0645 SEL  -> GND (left channel) SPH0645 3V   -> J21 pin 1 SPH0645 GND  -> J21 pin 6   We are trying to connect an external I2S MEMS microphone (SPH0645) to SAI5, wired to the J21 expansion header (BCLK -> SAI5_RXC, LRCL -> SAI5_RXFS, DOUT -> SAI5_RXD0, confirmed against the 8MPLUS-BB schematic and verified on oscilloscope).   We are facing this issue and need help resolving it:   The sound card registers correctly:   root@imx8mp-lpddr4-evk:~# arecord -l card 2: sph0645audio [sph0645-audio], device 0: ...   But recording fails with a clock error:   root@imx8mp-lpddr4-evk:~# arecord -D hw:CARD=sph0645audio,DEV=0 \     -f S16_LE -r 48000 -c 1 mic.wav [  140.950940] fsl-sai 30c50000.sai: failed to derive required Rx rate: 3072000 [  140.958042] fsl-sai 30c50000.sai: ASoC: error at snd_soc_dai_hw_params on 30c50000.sai: -22 arecord: set_params:1435: Unable to install hw params   Checking clk_summary shows sai5 is still deriving from the 24MHz oscillator rather than the audio PLL:   sai_pll_out_div2      0  0  50000  Y   0  0  0  24576000 sai5                  0  0  50000  N   0  0  0  24000000 sai5_root             0  0  50000  N   0  0  0  24000000   Our current &sai5 node:   &sai5 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; assigned-clocks = <&clk IMX8MP_CLK_SAI5>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assigned-clock-rates = <12288000>; fsl,sai-mclk-direction-output; fsl,sai-asynchronous; fsl,dataline = <0 0x1 0x0>; status = "okay"; };   pinctrl_sai5: sai5grp { fsl,pins = < MX8MP_IOMUXC_SAI5_RXFS__AUDIOMIX_SAI5_RX_SYNC 0xd6 MX8MP_IOMUXC_SAI5_RXC__AUDIOMIX_SAI5_RX_BCLK 0xd6 MX8MP_IOMUXC_SAI5_RXD0__AUDIOMIX_SAI5_RX_DATA00 0xd6 >; };   We also disabled &micfil and &pwm4, since their pinctrl groups share the same physical pads as SAI5_RXC/RXD0/RXFS on this board.   How do we correctly route SAI5's clock through the audio PLL so it can derive 3072000 Hz (48kHz) instead of sitting on the 24MHz oscillator path?    Also attached the some images for your reference.    Thank you. IMG_8200.jpegIMG_8200.jpeg IMG_8205.jpegIMG_8205.jpeg    preview.jpgpreview.jpg preview (1).jpgpreview (1).jpg    Re: imx8mp-evk SAI5 external I2S mic (SPH0645) - clock derivation fails, need help with correct cloc Hello, I suggest you try with the next configuration: &sai5 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; assigned-clocks = <&clk IMX8MP_CLK_SAI5>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assigned-clock-rates = <12288000>; clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_IPG>, <&clk IMX8MP_CLK_DUMMY>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_MCLK1>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_AUDIO_PLL1_OUT>, <&clk IMX8MP_AUDIO_PLL2_OUT>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k"; fsl,sai-asynchronous; fsl,dataline = <0 0x1 0x0>; status = "okay"; }; Without the clocks/clock-names binding, the driver falls back to the 24 MHz oscillator. Also, there is no need of fsl,sai-mclk-direction-output property if you are not connecting it to the microphone. Best regards.

USB-C版のFRDM-KL25Zドキュメント こんにちは、皆さん。 FRDM-KL25ZのUSB-C版のマニュアルや回路図をどこで見つけられるかご存知の方はいませんか?nxp.com およびその販売店サイトでは、FRDM-KL25Zのmini-B USBバージョンのデータしか持っていません。 ありがとう、 ピーター Freedom開発プラットフォーム

i.MX6Q BOOT_CFG4[6] 自定义载体变体检测 尊敬的恩智浦技术支持团队： 我们的一位 i.MX6Quad 模块客户要求进行自定义载板变体检测（在 U-Boot 中加载不同的设备树）。 该系统仅使用SD卡作为启动源。 客户的想法是使用 BOOT_CFG4[6]（高或低）来检测定制板变体。 由于 BOOT_CFG4[6] 被记录为“EEPROM 恢复启用”，并且保留用于“串行 ROM”启动模式。 我们想知道，如果从SD卡启动时，客户底板上的这个引脚使用不当，是否会有任何限制或问题。 NXP能否就BOOT_CFG4[6]能否安全地用于板变体检测而不对SD卡启动产生任何影响发表评论？ 先感谢您 蒂姆 i.MX6 四核

i.MX6Q BOOT_CFG4[6] カスタムキャリアバリアント検出 親愛なるNXPサポートチームへ、 i.MX6Quadモジュールの**お客様**の一人は、カスタムのキャリアボードバリアント検出(U-Bootで異なるデバイスツリーを読み込む)を必要としています。 システムはSDカードを起動ソースとしてのみ使用します。 顧客のアイデアとして、カスタムボードのバリアントを検出するためにBOOT_CFG4[6](高または低)を使います。 BOOT_CFG4[6]は「EEPROMリカバリ有効化」として文書化されており、「シリアルROM」ブートモード用に予約されています。 SDカードから起動する際にこのピンがお客様の巾木に使われた場合、何か制限や問題があるのか気になっています。 NXPは、BOOT_CFG4[6]がSDカードのブートに影響なくボードバリアント検出に安全に使用できるかどうかについてコメントいただけますか?    よろしくお願いします ティム i.MX6Quad

How Does NXP Expect Users to Integrate Mbed TLS with the Plug & Trust Middleware? Does NXP expect users to use the version of Mbed TLS bundled with the Plug & Trust Middleware? If so, does NXP provide updated middleware releases containing newer Mbed TLS versions in a timely manner? For example, the current middleware bundles Mbed TLS 3.6.2, although Mbed TLS 3.6.7 is already available. SE050 Re: How Does NXP Expect Users to Integrate Mbed TLS with the Plug & Trust Middleware? Hi @ph-yac , Thanks for the reaching out! Please have my comments as below: The Plug & Trust MW sources Mbed TLS from the MCUXpresso SDK downstream, and updates follow NXP's H1/H2 SDK release schedule rather than tracking every upstream Mbed TLS patch release. The currently bundled version is 3.6.2, and the next update will come with the next SDK downstream release cycle. The middleware is formally validated against the bundled version, but patch-level upgrades within the same 3.6.x LTS branch are generally low-risk. Customers are welcome to attempt replacing the bundled Mbed TLS source files manually; just verify build compatibility using the `SSS_HAVE_MBEDTLS_3_X` CMake flag. NXP does not formally validate every patch release between MW releases. The latest MW supports both Mbed TLS 2.28.x and 3.6.x branches via the `SSS_HAVE_MBEDTLS_2_X` / `SSS_HAVE_MBEDTLS_3_X` CMake flags. Please note that **SSS ALT** (not PSA ALT) should be used when integrating with Mbed TLS 3.x. Support for Mbed TLS 4.x in the Plug & Trust Middleware is currently being considered for a Q1 2027 release. No formal commitment has been made yet, but it is on the roadmap. Hope that helps, Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

S32K344 FlexIO I2C DMA こんにちは、 S32K344のFlexIO I2C DMAに関していくつか質問がありますので、ご意見をいただければ幸いです。 1. FlexIOを使用してI2Cをエミュレートする場合、Txの長さは次のように設定されます。 サイズ+1 。これは 「送信シフターは、SCLピンの最後の立ち下がりエッジで追加のワードを1つロードします」 ？ 1.png1.png1.png1.png 2.png2.png2.png2.png 2. DMAを使用してデータを送信する場合、 メジャーループ数 また、 サイズ + 1。これは同じ理由ですか? DMA を使用する場合、送信されるすべてのデータは Master->TxDataを呼び出すとき Flexio_I2c_Ip_MasterSendData 、 送信バッファ 長さは サイズ + 1 、最後のバイトは 0xFF または 0x00 ? 3.png3.png3.png3.png 3. データを受信するには、 メジャーループ数 設定されています サイズ – 1。なぜでしょうか？ 4. S32K344でこれをテストしたところ、FlexIO I2CでDMAを使用してデータを受信すると、受信データが予想より1バイト少ないことがわかりました。オシロスコープで観測すると、最後のバイトのクロック信号には、わずか5～6ビット程度の波形しか見られない。S32K312での同じテストは問題なく動作します。 S32K344 S32DS3.6.4 RTD700   BR、 ジェイソン Re: S32K344 FlexIO I2C DMA こんにちは、 @Jason07さん FlexIOは専用のI2Cペリフェラルではないため、その実装にはI2Cバスシーケンスを正しく完成させるための追加の内部手順が必要です。 伝送における「サイズ + 1U」は、FlexIOがI2Cフレームシーケンスを完了するために必要な最終的なシフター負荷に関連しています。この追加転送は、追加のペイロードバイトを表すものではありません。その代わりに、FlexIOハードウェア内部で最終的なクロックパルスを生成し、バスを正しく転送終了状態に移行させるために使用されます。 受信時のサイズ指定（-1U）が必要なのは、最後に受信したバイトが個別に処理されるためです。これにより、運転者は必要なNACKおよびSTOP条件を適切なタイミングで生成できます。 また、DMA転送モードを使用する場合、データ転送はキャッシュの一貫性の問題によって影響を受ける可能性があることを考慮してください。Dキャッシュが有効になっている場合に発生する可能性のある問題を回避するため、DMA TCDの送信元および送信先として使用されるバッファは、キャッシュ不可能なメモリ領域に割り当てられていることを確認してください。 Flexio_I2c_Ip_MasterReceiveData() 関数を呼び出す際に、TRANSFER_SIZE パラメータを増やす必要はありません。ドライバーは受信シーケンスの必要な内部調整をすでに処理しています。 最後に、あなたの設定を確認していると、両方のDMAチャネルに同じDMA割り込みコールバックが割り当てられていることに気づきました。Flexio_I2c_Ip.cに記載されている説明によると、送信と受信には異なるコールバック関数を使用する必要があります。 FlexIOチャンネル0/1 TX用のFlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter0() FlexIOチャンネル0/1 RX用のFlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter1() BR、VaneB Re: S32K344 FlexIO I2C DMA こんにちは、@ VaneBさん 「最後に受信したバイトは個別に処理される」というコードを見つけました。 しかし、送信に関してまだ疑問があります。割り込み駆動送信を使用する場合、長さはサイズ+1に設定されます。送信時にコードはそれが最後のバイトかどうかをチェックします。もしそうなら、0xFFか0x00を送ります。実際に送信されるデータの長さは依然としてサイズです。しかしDMAで送信を行う場合、DMAは送信バッファからサイズ+1バイトをコピーし、Flexio_I2c_Ip_MasterEndDmaTransfer関数ではShiftBufferに0xFFまたは0x00も埋めます。つまり、実際に送信されるデータ長はサイズではなくサイズ+1です。なぜでしょうか? 1.png1.png1.png 2.png2.png2.png 添付のプロジェクト内のTRANSFER_SIZE + 1のすべての箇所をTRANSFER_SIZE (8)に変更し、説明されているとおりDMA割り込みコールバックも変更しました。また、Dキャッシュも無効にしました。 FlexIO I2C送信にDMAを使用する際、オシロスコープで観察したところ、-Os最適化レベルではクロック信号は8バイトのみで正常でした。しかし、-O0最適化レベルでは、最初の8バイトのクロックは正常でしたが、ACK送信後に期待どおりストップ信号が生成されず、代わりに1ビットの余分なクロックパルスが現れました。 3.jpg3.jpg3.jpg FlexIO I2C を DMA 経由で受信する場合、LPI2C0 はスレーブとして使用され、8 バイト (0x10～0x17) を送信します。-O0最適化レベルでは、7バイト目の送信中にクロック信号が異常になり、FlexIO受信バッファには6バイト（0x10～0x15）しか含まれません。 4.jpg4.jpg4.jpg -Os最適化レベルでは、8バイト目の送信中にクロック信号が異常になり、FlexIO受信バッファには7バイト（0x10～0x16）しか含まれません。 5.jpg5.jpg5.jpg 上記の問題はすべて確実に再現可能です。 Re: S32K344 FlexIO I2C DMA こんにちは、 @Jason07さん 重要な点は、I2Cがオープンドレイン信号方式を採用していることだと思います。 論理0はSDAを積極的にローに引き下げます。 論理値1はSDAを解放し、プルアップ抵抗によってラインがハイレベルに駆動される。 FlexIOは専用のI2Cコントローラではなくプログラム可能な周辺機器であるため、ドライバはシフターに読み込まれるビットパターンを制御してI2Cプロトコルイベントを生成しなければなりません。 このため、末尾の0x00と0xFFの値は、必ずしも追加のペイロードバイトとみなすべきではありません。むしろ、それらはSDAを適切な状態に配置し、ルーチンを完了させるために使用される。 Master->SendStop == TRUEの場合、ドライバーは0x00をロードし、SDAを強制的に低くなります。シフターの処理が完了し、FlexIOがラインを解放すると、プルアップによってSDAがハイになり、SCLは既にハイになっているため、必要な停止条件（SDA：LOW → HIGH、SCLはHIGH）が生成されます。 Master->SendStop == FALSEの場合、ドライバーは0xFFをロードし、SDAは解放されたままになります。プルアップによりSDAがハイレベルに維持され、停止状態が防止され、バスは繰り返し始動（SCLがハイレベルの間、SDA：ハイレベル→ローレベル）の準備が整います。 また、DMA最適化モードを有効にすることをお勧めします。例はスレッドにあります: S32K344 DMA Optimize オプション S32DS 3.6.0 RTD 6.0.0 を用いた FlexIO I2C の例。 最後に、カスタムボードを使用していますか、それともEVB/FRDMを使用していますか？

需要澄清 SBCFS2613 主状态故障反应 您好，NXP， 请确认是否已针对相应寄存器中的以下故障配置了默认的故障保护反应（断言FSXB 和 RSTB）？ M_TSD_FLG M_REG_FLG M_VSUP_FLG 由于上述寄存器中的故障配置为提供INTB 指示，因此需要澄清它们是否也具有任何默认故障安全反应，例如断言FSXB 和/或 RSTB 。 谢谢！ 西瓦哈里·G Re: Clarifications required for SBCFS2613 Main state Faults reaction 你好 RafaR， 我无法确定您具体指的是哪个PN？ 我使用的是 MFS2613AMDA6。 诸如 FS0B (FSXB) 和/或 RSTB 断言之类的故障保护反应不会自动与标志本身关联，而是取决于相应的故障保护配置。 是的，所有稳压器都绝对支持对欠压/过流故障进行故障安全配置，其配置寄存器为“ FS_I_OVUV_SAFE_REACTION1”和“FS_I_OVUV_SAFE_REACTION2”。但是，是否有办法为所有稳压器过流故障配置故障安全响应？因为我们已经有办法配置这些故障的INTB屏蔽/取消屏蔽。 示例 OC 故障（VBSTOV_I、VBSTOC_I、VPREOC_I、TRK1OC_I、COREOC_I） 谢谢！ 西瓦哈里·G Re: Clarifications required for SBCFS2613 Main state Faults reaction 你好， Sivahari 再会！ 我无法确定您具体指的是哪个 PN，但总的来说，这适用于所有版本的 FS26。 RafaR_0-1787266460038.pngRafaR_0-1787266460038.png 总而言之，M_TSD_FLG、M_REG_FLG 和 M_VSUP_FLG 中的标志默认是中断源。诸如 FS0B (FSXB) 和/或 RSTB 断言之类的故障保护反应不会自动与标志本身关联，而是取决于相应的故障保护配置，TSD 故障就是一个明确的例子，可以配置为升级到深度故障保护。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。

DESFire EV3 NDA電子署名リクエストが送信されませんでした MIFARE DESFire EV3のNDA承認されましたが、Adobe Signのリクエストは届かず、サポートがNXP契約へのエスカレーションを拒否しています(ケース00996763) こんにちは、 NXP側の技術的な理由で停滞しているNDAプロセスを終わらせるのを手伝ってくれる方を探しています。 バックグラウンド: 私はチェコ共和国のソフトウェア開発者で、MIFARE DESFire EV3(MF3DHx3)をベースにしたクローズドループNFC決済拡張機能を備えたモバイルPOSアプリケーション(Android/iOS)を開発しています。DocStoreからEV3の機密ドキュメント(完全なデータシート/コマンドセット、セキュアメッセージング、キーマネジメント)が必要です。 2026年8月1日にNXPのオンラインプロセス(サポートケース#00996763)を通じてNDA申請を提出しました。 8月1日から7日の間に、NXPのコンプライアンス要求に応じたすべての書類を提出しました:会社ウェブサイト、公式取引登録簿、所有構造、詳細なプロジェクト説明、ボリューム、設計段階、最終用途。 8月12日、NXPテクニカルサポートはNDAが承認され、NXP Contracts/Adobe Acrobat Signを通じて私の署名メールに送信されたことを確認しました。8月18日、彼らは2回目の電子署名リクエストを確認した。 問題： Adobe Signのリクエストはどちらも届きませんでした。受信トレイにも、迷惑メールフォルダにも、Adobe Signアカウントにも見当たらず、そして最も重要なことに、Microsoft 365 Exchangeのメッセージ追跡記録には、当該期間全体を通してadobesign.com / echosign.comからの配信試行の痕跡が一切残っていない。トランザクションは私のメールサーバーに到達する前に失敗します。 技術サポートは「セキュリティ上の理由からファイルの再送信はできません」と言い、「メールアドレスの確認はこれ以上できない」と言い、認可された代理店を通じてやり直すように言われました。Adobe Sign取引を確認して新しい契約を発行してもらうため、単にNXPコントラクトに案件を転送する(またはNDAをPDF形式で送って手書き署名を求める)という要請は、まだ対応されていません。 問題のメールアドレスは私のドメイン内の唯一の事業用アドレスであり、この件では他のすべてのやり取り、[email protected] からのすべてのメールも有効です。 私が求めているもの： NXP Contracts、MIFARE製品チーム、またはAdobe Sign監査記録にアクセスできる方がいれば、ケース#00996763を見て、eSignの再発行か、別のフォームでNDAを提出していただけませんか?デューデリジェンス審査は完了し承認されました。残っているのは書類1点のみです。 適切なお問い合わせのヒントをいただけると大変ありがたいです。ありがとう。 ペトル・ザフラドニク チェコ共和国 Re: DESFire EV3 NDA eSign request never delivered こんにちは、エドゥアルドさん。 ご返信ありがとうございます。理解していますし、NDAのチケットを続けたいと思います。問題はチケットが事実上閉じられていることです。 テクニカルサポートは2度「オンラインは進めない」と返答し、代理店を通じてやり直すように言われており、法務・契約チームへの転送の要請も対応されていません。 そこでお願いはこれだけです:ケース番号00996763を内部の法務チームに渡していただけますか?Adobe Signの取引が見られる誰かに確認してもらえますか?秘密保持契約は8月12日に承認されましたが、電子署名依頼が私の手元に届きませんでした（メールサーバーの追跡記録にも配信試行の記録が全くありません）。電子署名依頼を再発行するか、手書き署名用のPDF形式のNDAを提供すれば、すぐに解決するでしょう。 このThreadを参照したチケットにメモを追加します。ありがとう。 ペトル Re: DESFire EV3 NDA eSign request never delivered こんにちは、 @clexpert さん。 あなたの調子が良いといいのですが。 申し訳ありませんが、NDAの話題を扱う適切な方法ではありません。すべての手続きは、 NDAオンラインフォームの発行後、当社の法務チームが担当します。 処理状況に関する詳細については、NDAチケットで引き続きお問い合わせください。 よろしくお願いいたします。 エドゥアルド。 Re: DESFire EV3 NDA eSign request never delivered こんにちは、エドゥアルドさん。 改めてありがとうございました。あなたのアドバイスに従い、NDAチケット(CASE 00996763)を継続し、あなたが言ったように法務・契約チームに案件を転送するよう明確にお願いしました。彼らがこれらの案件を担当しています。 今日受け取った唯一の返信は、3回目の一行だけのメッセージでした:「NDAの作成についてはNXP代理店にご連絡ください。」法務部への転送もなく、Adobe Signの納品失敗に関するコメントもなく、私が問い合わせた監査証跡への言及もなかった。 3週間経過した現状をまとめると以下のようになります。 秘密保持契約書は8月12日に審査、承認され、発行されました。 - 2件のAdobe Signリクエストがメールサーバーに届かなかった(完全なメッセージトレースで確認され、配達の試みは全くありません)。 - 技術サポートは再発行できず、代理店のアドバイスを繰り返すのみです。 - 私は並行して認可された代理店に連絡し、待っています。 法務・契約部への内部引き継ぎを自分で行ってもらえるか、直接連絡先を教えていただけますか?既に承認済みの秘密保持契約書を、再発行された電子署名リクエスト、または手書き署名用のPDFファイルとして送付していただきたいです。私は建設的なトーンを保っています。ただ、これで行動できる誰かに届くことが欲しいのです。 ありがとう。 ペトル

FRDM-KL25Z USB-C 版本文档 大家好， 请问有人知道哪里可以找到 FRDM-KL25Z USB-C 版本的说明书和/或电路图吗？nxp.com 及其经销商网站似乎只有 FRDM-KL25Z 的 mini-B USB 版本的数据。 谢谢， 彼得 Freedom开发平台

imx8mp-evk SAI5 外置 I2S 麦克风 (SPH0645) - 时钟推导失败，需要正确的时钟帮助 你好， 主板：i.MX8MPLUSLPD4-EVK（8MPLUS-BB底板）   将外部 I2S MEMS 麦克风（Knowles SPH0645LM4H）连接到 SAI5， 使用物理连接到 J21 (EXP_CN) 的 SoC 端引脚 根据底板原理图，通过电平转换器 U57/U58 连接扩展接口。 （SPF-46370）   1. 硬件接线（已对照原理图确认，并用示波器验证）   SPH0645 BCLK -> J21 引脚 40 ("PDM_CLK", SoC 焊盘 SAI5_RXC) SPH0645 LRCL -> J21 引脚 32 ("PWM4_3V3",     SoC 焊盘 SAI5_RXFS) SPH0645 DOUT -> J21 引脚 38 ("PDM_STREAM_0", SoC 焊盘 SAI5_RXD0) SPH0645 SEL -> GND（左声道） SPH0645 3V -> J21 引脚 1 SPH0645 GND -> J21 引脚 6   我们正在尝试将外部 I2S MEMS 麦克风 (SPH0645) 连接到 SAI5，连接到 J21 扩展接头（BCLK -> SAI5_RXC，LRCL -> SAI5_RXFS，DOUT > SAI5_RXD0，已根据 8MPLUS-BB 原理图确认 并在示波器上进行了验证）。   我们遇到了这个问题，需要帮助解决：   声卡识别正常：   root@imx8mp-lpddr4-evk:~# arecord -l 卡 2：sph0645audio [sph0645-audio]，设备 0：...   但录制失败，出现时钟错误：   root@imx8mp-lpddr4-evk:~# arecord -D hw:CARD=sph0645audio,DEV=0 \ -f S16_LE -r 48000 -c 1 mic.wav [ 140.950940]fsl-sai 30c50000.sai：未能得出所需的处方费率：3072000 [ 140.958042]fsl-sai 30c50000.sai：ASoC：30c50000.sai 上的 snd_soc_dai_hw_params 出错：-22 arecord: set_params:1435: 无法安装硬件参数   检查 clk_summary 显示 sai5 仍然使用 24MHz 的频率。 振荡器而不是音频锁相环：   sai_pll_out_div2      0  0  50000  Y   0  0  0  24576000 sai5 0 0 50000 N 0 0 0 24000000 sai5_root 0 0 50000 N 0 0 0 24000000   我们当前的 &sai5 节点：   &sai5 { #sound-dai-cells = <0> pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; 已分配时钟 = <&clk IMX8MP_CLK_SAI5>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT> 分配的时钟速率 = <12288000>; fsl，sai-mclk-direction-output； fsl，sai-异步； fsl,dataline = <0 0x1 0x0>; 状态 = "好的" };   pinctrl_sai5：sai5grp { fsl，pins = < MX8MP_IOMUXC_SAI5_RXFS__AUDIOMIX_SAI5_RX_SYNC 0xd6 MX8MP_IOMUXC_SAI5_RXC__AUDIOMIX_SAI5_RX_BCLK 0xd6 MX8MP_IOMUXC_SAI5_RXD0__AUDIOMIX_SAI5_RX_DATA00 0xd6 > };   我们还禁用了 &micfil 和 &pwm4，因为它们的 pinctrl 组共享 本主板上与 SAI5_RXC/RXD0/RXFS 具有相同的物理焊盘。   我们如何正确地将SAI5的时钟信号通过音频PLL进行路由，使其能够…… 导出 3072000 Hz (48kHz) 的频率，而不是使用 24MHz 的振荡器。 小路？   另附几张图片供您参考。   谢谢。 IMG_8200.jpegIMG_8200.jpeg IMG_8205.jpegIMG_8205.jpeg    preview.jpg预览.jpg preview (1).jpg预览 (1).jpg    Re: imx8mp-evk SAI5 external I2S mic (SPH0645) - clock derivation fails, need help with correct cloc 你好， 我建议您尝试以下配置： &sai5 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; assigned-clocks = <&clk IMX8MP_CLK_SAI5>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assigned-clock-rates = <12288000>; clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_IPG>, <&clk IMX8MP_CLK_DUMMY>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_MCLK1>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_AUDIO_PLL1_OUT>, <&clk IMX8MP_AUDIO_PLL2_OUT>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k"; fsl,sai-asynchronous; fsl,dataline = <0 0x1 0x0>; status = "okay"; }; 如果没有时钟/时钟名称绑定，驱动程序将回退到 24 MHz 振荡器。另外，如果您没有将麦克风连接到它，则不需要fsl,sai-mclk-direction-output属性。 顺祝商祺！

S32R294 e200z7コアのAMMCLibサポート NXPチームの皆様、こんにちは。 私たちはS32R294向けのアプリケーションを開発しており、AMMCLibをe200z7コアで使用したいと考えています。 公式にS32R294をサポートするAMMCLibのリリースはありますか?もしそうでなければ、NXPが提供する他の、S32R294 e200z7コアに対応した数学ライブラリをおすすめしてもらえますか? また、特定のS32 Design Studioツールチェーン、SDK、またはRSDKのバージョンが必要かどうかもご案内ください。 よろしくお願いします。 C|C++ライブラリ Re: AMMCLib support for S32R294 e200z7 cores こんにちは、ピーターさん。 ご説明いただきありがとうございます。 私たちの対象アプリケーションはレーダー信号プロセッシングパイプラインです。S32R294 e200z7コア上で、以下のアルゴリズムを実行する予定です。 DMLベースの到来方向推定 少数のFFT演算 カルマンフィルタリング(マトリックス乗算、転置、線形系解法またはマトリックス反転を含む) ベクトル、行列、統計演算を用いた特徴抽出および軽量レーダー目標分類 これらのアルゴリズムをe200z7コアで実行することで、SPTとe200z7間のデータ転送やデータフォーマット変換が減少し、プロセッシング効率が向上します。 S32R294 e200z7コア向けに最適化されたFFT、複素算術、マトリックス、ベクトル、線形代数関数を探しています。NXPはこれらの用途に適した数学やDSPライブラリを提供していますか? よろしくお願いいたします。 Re: AMMCLib support for S32R294 e200z7 cores こんにちは、 S32R294プラットフォームを公式にサポートするAMMCLibのリリースはありません。 AMMCLibデバイスのサポートリストには現在、いくつかのPower Architecture MCUファミリ(例:MPC577xK/MPC5775E)が含まれていますが、S32R294はサポート対象としては記載されていません。 S32R294開発向けに、NXPの主なソフトウェアはS32R29x用のレーダー SDKsとS32 Design Studio Power Architectureツールチェーンです。 ターゲットとなるアプリケーションは何でしょうか? よろしくお願いいたします。 ピーター

S32K344 FlexIO I2C DMA Hello, I have some questions regarding the FlexIO I2C DMA  on S32K344, and I would appreciate your insights. 1. When using FlexIO to emulate I2C, the Tx length is set to Size + 1. Is this because "The transmit shifter loads one additional word on the last falling edge of the SCL pin"? 1.png1.png1.png1.png 2.png2.png2.png2.png 2. When using DMA for sending data, the MAJORLOOP_COUNT is also set to Size + 1. Is this for the same reason? When using DMA, all transmitted data comes from Master->TxData. When calling Flexio_I2c_Ip_MasterSendData, should the TxBuff length be Size + 1, and should the last byte be 0xFF or 0x00? 3.png3.png3.png3.png 3. For receiving data, the MAJORLOOP_COUNT is set to Size – 1. Why is this? 4. I tested this on the S32K344 and found that when using DMA for FlexIO I2C receiving data, the received data is one byte less than expected. Observing with an oscilloscope, the clock signal for the last byte shows only about five or six bits of waveform. The same test on the S32K312 works fine. S32K344 S32DS3.6.4 RTD700   BR, Jason Re: S32K344 FlexIO I2C DMA Hi @Jason07  As FlexIO is not a dedicated I2C peripheral, its implementation requires additional internal steps to complete the I2C bus sequence correctly. The Size + 1U in the transmission is related to the final shifter load required by FlexIO to complete the I2C frame sequence. This additional transfer does not represent an extra payload byte. Instead, it is used internally by the FlexIO hardware to generate the final clock pulses and correctly transition the bus to the end-of-transfer state. The Size - 1U in the reception is necessary because the last received byte is handled separately. This allows the driver to generate the required NACK and STOP conditions at the correct time. Also, take into consideration that when using DMA transfer mode, data transfers may be affected by cache coherency issues. To avoid potential problems when D-Cache is enabled, ensure that the buffers used as the source and destination of the DMA TCD are allocated in a non-cacheable memory region. There is no need to increase the TRANSFER_SIZE parameter when calling the Flexio_I2c_Ip_MasterReceiveData() function. The driver already handles the required internal adjustments for the receive sequence. By last, while reviewing your configuration, I noticed that the same DMA interrupt callback has been assigned to both DMA channels. According to the descriptions provided in Flexio_I2c_Ip.c, different callbacks should be used for the transmit and receive: FlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter0() for the FlexIO Channel 0/1 TX FlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter1() for the FlexIO Channel 0/1 RX BR,VaneB Re: S32K344 FlexIO I2C DMA Hi@VaneB I found the code where “the last received byte is handled separately”. However, I still have a question regarding sending. When using interrupt‑driven sending, the length is set to Size + 1. During sending, the code checks whether it is the last byte; if so, it sends 0xFF or 0x00. The actual sent data length is still Size. But when using DMA for sending, the DMA copies Size + 1 bytes from the send buffer, and in the Flexio_I2c_Ip_MasterEndDmaTransfer function, it also fills 0xFF or 0x00 into the ShiftBuffer. This means the actual sent data length is Size + 1, not Size. Why? 1.png1.png1.png 2.png2.png2.png I modified all occurrences of TRANSFER_SIZE + 1 in the attached project to TRANSFER_SIZE (8), and also modified the DMA interrupt callback as described. I also disabled the D‑Cache. When using DMA for FlexIO I2C sending, I observed with an oscilloscope that at -Os optimization level, the clock signal is normal with only 8 bytes. However, at -O0 optimization level, the clock for the first 8 bytes is normal, but after the ACK is sent, the stop signal is not generated as expected; instead, an extra 1‑bit clock pulse appears. 3.jpg3.jpg3.jpg For FlexIO I2C receiving via DMA, LPI2C0 is used as a slave to send 8 bytes (0x10–0x17). At -O0 optimization level, the clock signal becomes abnormal during the transmission of the 7th byte, and the FlexIO receive buffer contains only 6 bytes (0x10–0x15). 4.jpg4.jpg4.jpg At -Os optimization level, the clock signal becomes abnormal during the transmission of the 8th byte, and the FlexIO receive buffer contains only 7 bytes (0x10–0x16). 5.jpg5.jpg5.jpg All of the above issues are reliably reproducible. Re: S32K344 FlexIO I2C DMA Hi @Jason07  I think the key point is that I2C uses open-drain signaling: Logical 0 actively pulls SDA low. Logical 1 releases SDA, allowing the pull-up resistor to drive the line high. Since FlexIO is a programmable peripheral rather than a dedicated I2C controller, the driver must generate I2C protocol events by controlling the bit patterns loaded into the shifters. Because of this, the final 0x00 and 0xFF values should not necessarily be considered additional payload bytes. Instead, they are used to place SDA in the correct state to complete the rotine. When Master->SendStop == TRUE, the driver loads 0x00, forcing SDA low. Once the shifter finishes and FlexIO releases the line, the pull-up brings SDA high while SCL is already high, creating the required STOP condition (SDA: LOW → HIGH while SCL is HIGH). When Master->SendStop == FALSE, the driver loads 0xFF, which keeps SDA released. The pull-up keeps SDA high, preventing a STOP condition and leaving the bus ready for a Repeated START (SDA: HIGH → LOW while SCL is HIGH). Also, I recommend enabling the DMA Optimize mode. An example is available in the thread: Example S32K344 FlexIO I2C with DMA Optimize option S32DS 3.6.0 RTD 6.0.0. By last, Are working with a custom board or an EVB/FRDM?

DESFire EV3 NDA eSign request never delivered MIFARE DESFire EV3 NDA approved but Adobe Sign request never delivered – support refuses to escalate to NXP Contracts (case 00996763) Hello, I am looking for someone at NXP who can help me finish an NDA process that is stuck for purely technical reasons on NXP's side. Background: I am a software developer in the Czech Republic building a mobile POS application (Android/iOS) with a closed-loop NFC payment extension based on MIFARE DESFire EV3 (MF3DHx3). I need the confidential EV3 documentation (full data sheet / command set, secure messaging, key management) from DocStore. On 1 August 2026 I submitted an NDA request through the NXP online process (support case #00996763). Between 1 and 7 August I provided everything NXP compliance asked for: company website, official trade register document, ownership structure, detailed project description, volumes, design stage, end use. On 12 August NXP Technical Support confirmed the NDA was approved and sent via NXP Contracts / Adobe Acrobat Sign to my signatory e-mail. On 18 August they confirmed a second eSign request. The problem: Neither Adobe Sign request ever arrived. Not in the inbox, not in junk, not in my Adobe Sign account, and – most importantly – there is no trace of any delivery attempt from adobesign.com / echosign.com in the Microsoft 365 Exchange message trace for the whole period. The transaction fails before it reaches my mail server. Technical Support says that "for security reasons we cannot resend the file", that they "cannot verify my e-mail address further", and that I should start over through an authorised distributor. A request to simply forward the case to NXP Contracts so they can check the Adobe Sign transaction and issue a new agreement (or send the NDA as a PDF for a handwritten signature) has not been actioned. The e-mail address in question is my only business address on my own domain and has been working for all other correspondence in this case, including all e-mails from [email protected]. What I am asking for: Could someone from NXP Contracts, the MIFARE product team, or anyone with access to the Adobe Sign audit trail please look at case #00996763 and either re-issue the eSign request or provide the NDA in another form? The due-diligence review is complete and approved – the only missing step is delivering one document. Any pointer to the right contact would be greatly appreciated. Thank you. Petr Zahradnik Czech Republic Re: DESFire EV3 NDA eSign request never delivered Hello Eduardo, thank you for the reply. I understand, and I would be glad to continue in the NDA ticket — the problem is that the ticket is effectively closed: Technical Support has twice answered that they "cannot proceed online" and that I should start over through a distributor, and my request to forward the case to the Legal / Contracts team has not been actioned. So my only ask is this: could you please pass case number 00996763 to the Legal team internally, so that someone who can see the Adobe Sign transaction looks at it? The NDA was approved on 12 August; the eSign request just never reached me (no delivery attempt in my mail server trace at all). A re-issued eSign request, or the NDA as a PDF for a handwritten signature, would resolve it immediately. I will add a note to the ticket referencing this thread. Thank you. Petr Re: DESFire EV3 NDA eSign request never delivered Hello @clexpert Hope you are doing well. Please accept my apologies, this is not the proper path to address any NDA topic. All the processes are handled by our Legal team after issuing the NDA online form. For further information about the status of your process, please continue the communication in your NDA ticket. Regards, Eduardo. Re: DESFire EV3 NDA eSign request never delivered Hello Eduardo, thank you again. Following your advice I continued in the NDA ticket (case 00996763) and explicitly asked for the case to be forwarded to the Legal / Contracts team, as you mentioned they handle these. The only reply I received today was, for the third time, a one-line message: "please contact NXP distributor for NDA creation." No forwarding to Legal, no comment on the failed Adobe Sign delivery, no reference to the audit trail I asked about. To summarise where this stands after three weeks: - The NDA was reviewed, approved and issued on 12 August. - Two Adobe Sign requests never reached my mail server (confirmed by a full message trace - no delivery attempt at all). - Technical Support cannot re-issue it and will only repeat the distributor advice. - I have contacted authorised distributors in parallel and am waiting. Could you please make the internal hand-off to Legal / Contracts yourself, or give me a direct contact there? I would simply like the already-approved NDA to be delivered - by a re-issued eSign request or as a PDF for a handwritten signature. I am keeping the tone constructive; I just need this to reach someone who can act on it. Thank you. Petr

S32N55: 高速ウェイクアップ ブート用の BLOB イメージを構築する方法。 こんにちは、チームの皆さん ご存知のとおり、S32N55 は Fast Wake-up Boot をサポートしています。 Full Wake-up Boot と同じ形式を使用して BLOB イメージをビルディングしようとしましたが、ブート プロセスが失敗しました。 Fast Wake-up Boot 用の BLOB イメージを正しく構築する方法を教えてください。 ご回答をお待ちしています。 Tangsheng_Zhou_0-1766369489644.pngTangsheng_Zhou_0-1766369489644.png よろしくお願いいたします。 唐生。 FSS_FW 優先度: 中 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん チームがこのCASEを引き受け、できるだけ早く回答を提供します。 よろしくお願いします、 ラドゥ Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @RaduBragaさん このチケットがクローズされていることに気づきました。進捗状況について何か最新情報はありますか？   よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 私はこのCASEを引き継ぎ、できるだけ早く返答をいたします。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 直接お客様を支援される場合は、以下の書類をご提供ください: BSSM契約：あり／なし 顧客会社*: プロジェクト名*: カスタマーコンタクトポイント*(氏名およびメールアドレス): ソフトウェアおよびハードウェア情報: SWパッケージ情報*: ハードウェア*(ボード/チップセット/プラットフォーム) ソフトウェアバージョン*: *必須 このケースの開発チームとはまだ協力しています よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 このケースは特定の顧客やプロジェクトに縛られていません。しかし、FUTURE的に同様の質問に直面する可能性があると考えており、このリクエストを出したのです。   よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 詳しい情報をありがとうございます。私はこの事件に取り組んでおり、できるだけ早く答えを提供いたします! よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん ブロブ画像を作ろうとした際に実際に踏んだ手順を教えていただけると助かります。そうすれば問題点を特定しやすくなると思います。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 以下に、テストの詳細な手順を示します。   1. AOSRAMメモリ領域内に小さなFSSイメージを構築しました（IVTヘッダーは予約済み）。このイメージにはmain.cのwhileループのみが含まれています。 Tangsheng_Zhou_0-1784553297963.pngTangsheng_Zhou_0-1784553297963.png 2. FSSファームウェアイメージを作成する際、FRBしきい値レジスタを入力する必要がありますか？もしそうなら、どうやって埋めるか、あるいは特別なものを考える必要があります。 Tangsheng_Zhou_1-1784553422329.pngTangsheng_Zhou_1-1784553422329.png 3. IVTツールでIVTブロブイメージを構築し、開始アドレスを0x24800000とする。 4. IVTブロブイメージをフラッシュメモリの0xD00000に書き込みます。 5. システムがスリープ状態に入る前に、IVTブロブイメージをAOSRAMにコピーし、FSS_WKUP0のWKPUモードを高速ウェイクアップモードとして構成します。 Tangsheng_Zhou_2-1784553712231.pngTangsheng_Zhou_2-1784553712231.png Tangsheng_Zhou_3-1784553730808.pngTangsheng_Zhou_3-1784553730808.png 5. FSS_WAKUP0 を介してシステムイメージを起動します。 FSSは while(1) ループに到達できませんでした。ウェイクアップの際に高速ウェイクアップではなく、リセットイベントがトリガーされたようです。   サポートありがとうございます!   よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん FRBはTCMメモリ（ITCM + DTCM）用です。 理論的には2つのケースがあります 1: 高速起動ブート イメージはAON SRAMメモリから起動するため、高速起動にはFRBは必要ありません。 2: フルウェイクアップブート ITCMに起動したいかどうか教えてもらえますか?もしはい、FRBの閾値0はFSSイメージヘッダーで提供されるべきです。アドレスは12ビットマスクされ、FRBの場合は8kbの倍数として計算されます。 少しでもお役に立てれば幸いです。また、IVTの塊も教えてもらえますか? よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 いいえ、私は単にF-CoreをAO-SRAMで動作させたいだけです。 main_app1.binはFSSファームウェアイメージです。 これら2つのフィールドをどのように埋めるべきでしょうか？AO_SRAMアドレス0x24800000から始めるべきでしょうか？私のイメージの開始ポインタとエントリポインタは0x24800240です。 Tangsheng_Zhou_0-1784682563629.pngTangsheng_Zhou_0-1784682563629.png main_blob1.binは、IVTヘッダーを含むブロブイメージです。 よろしくお願いします！ よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 FSSファームウェアではなく、完全なIVTイメージをスリープモードに入る前にAO_SRAMにコピーし、高速ウェイクアップ機能をテストしました。   よろしくお願いします！ よろしくお願いいたします。 唐勝 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 IVTヘッダー、FSS FWヘッダー、およびFSS FWバイナリを含む、IVTブロブイメージ全体がAO_SRAMの先頭にコピーされました。 よろしくお願いします！ よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 流れを正しく理解しているか確認させてください。スリープ前に完全なIVTブロブイメージをAO_SRAMの先頭にコピーしているのですか、それとも高速ウェイクアップブート用のFSSファームウェアイメージのみをコピーしているのですか？ よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん Fast Wake-up Bootが正常に完了しているか確認していただけますか?起動プロセスが正常に動作していることが確認された場合、画像に問題がある可能性があります。 考えられる原因を段階的に絞り込んでいきたいと思います。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 WKPUの設定は正しいと思います。私の理解では、フルウェイクアップとファストウェイクアップの主な違いは、WBMSRの設定にある。それで合っていますか？ 他に考慮すべき設定や要素はありますか？ また、正しい手順や、あなたやチームが確認した速い目覚めのブロブ画像も教えていただけますか? サポートありがとうございます! よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 現在、チームはリリース作業で手一杯の状態です。私の方でも少し働きかけ、調査を行い、できるだけ早く回答をお伝えします。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん WBMSRは、フルウェイクアップブートとファストウェイクアップブートの主な違いの一つです。しかし、それは唯一の要因ではない。 高速ウェイクアップブートの場合、BootROMはスリープに入る前に、AON SRAMに有効なイメージ（IVT + FSS FW、必要に応じてウェイクアップDCDを含む）が存在することを想定しています。WBMSRに加えて、ウェイクアップソースの設定、AON SRAMの保持、および有効なIVT/FSSヘッダーも検証する必要があります。 想定される高速起動フローは以下のとおりです。   1. IVT + FSS FW を含む IVT ブロブイメージを生成します。 2. 必要に応じて、ウェイクアップDCDを追加します。 3. ブロブイメージをAON SRAMの先頭にコピーします。 4. システムを高速起動モードに設定します。 5. スリープモードに入り、ウェイクアップソースをトリガーする 検証済みのFast Wake-upブロブイメージについては、現在社内で確認しており、検証済みの参照イメージが入手可能になり次第、ご連絡いたします。   少しでもお役に立てれば幸いです。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 ご返信ありがとうございます。ご指示いただいた手順に従って高速起動機能をテストしましたが、問題は依然として発生しています。ご自身の側で成功裏にテストしたか確認いただけますか?   ありがとうございます！ よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 提供された回答が適切であり、チケットに関して他に質問がない場合は、回答を「解決策として承認」としてマークしてください。 今後のケースでは、NXP JIRA: Jira Projectをご利用ください  さらに、7日以内に返答がなければ、CASEを終了します。 よろしくお願いいたします。 ポール

S32K3スタンバイRAMデータはリセットハンドラ実行前に変更されました こんにちは、 PE MicroでS32K344をデバッグすると、配列(__attribute__ ((section(".standby_data"))) が見つかりました。スタンバイ RAM セクションにある volatile uint32_t WkupSourcestatus1[64];) が main() に入るときに予期せず変更されます。そして、添付の動画に示すように、スタンバイRAM領域を再初期化するためにレジスタを手動で変更しました。データは正しく0に初期化され、main()関数に入った後はすべて正常に動作しました。しかし、リセット後、Reset_Handlerに入ると、WkupSourcestatus1配列のデータが再び変更されます。なぜこのようなことが起きているのか？配列の中に0x5AA55AA5という値が多数出現していることに気づきました。これはSBAF_BOOT_MARKERに関連していますか？別の基板でも試してみましたが、同じ現象が発生しました。 8.png8.png その後、J-Linkを使ってデバッグに切り替えましたが、リセット中に異常は発生しません。しかし、デバッグセッションを再開すると、スタンバイRAM領域内のすべてのデータが0xDEADBEEFになります。これは想定される動作ですか？ S32K344 S32DS3.6.4 RTD700 PE v.6.0.8 BR、 ジェイソン

在深度掉电状态下，将 J-Link/Ozone 连接到 LPC55(S)28 时，DM-AP 连接行为不一致 您好， 我们发现，当使用 Debug.SetConnectMode(CM_ATTACH_HALT) 将 Ozone (J-Link) 连接到处于关机或深度关机模式的 LPC5528 或 LPC55S28 时，SWD 连接行为不一致。我们在两块运行 LPC5528 的“相同”定制板和一块运行 LPC55S28 的 NXP 评估板上重现了不同的结果（均为 1B 版本），因此希望澄清预期的调试邮箱恢复流程。 设置 MCU：LPC5528 和 LPC55S28 调试探针：J-Link 工具：Ozone，Debug.SetConnectMode(CM_ATTACH_HALT) 测试的电源模式：掉电和深度掉电（通过 POWER_EnterPowerDown() / POWER_EnterDeepPowerDown() 进入） 观察结果 1 — 板 A，定制板，LPC5528，掉电和深度掉电 DM-AP IDCODE始终无法解析；重试4次后连接彻底失败，未发生重置： InitTarget() start ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF InitTarget() end - Took 101ms （重复4次，然后：）   Connection failed. 观察结果 2 — 板 B，定制板，LPC5528，掉电和深度掉电 DM-AP IDCODE 读取 0x00000000 第一次尝试失败后，第二次尝试报告了明确的调试邮箱恢复消息并成功： InitTarget() start ERROR: Wrong DM-AP IDCODE detected: 0x00000000 InitTarget() end - Took 101ms ConfigTargetSettings() start InitTarget() start CPU halted successfully after enabling debug access InitTarget() end - Took 7.40ms Found SW-DP with ID 0x6BA02477 ... Connected to target device. 观察 3 — NXP 评估板，LPC55S28，掉电和深度掉电 DM-AP IDCODE 也读取 0x00000000 第一次尝试失败，但第二次尝试成功了。 没有 打印“启用调试访问”消息后，程序直接进入正常的AP扫描： InitTarget() start ERROR: Wrong DM-AP IDCODE detected: 0x00000000 InitTarget() end - Took 112ms ConfigTargetSettings() start InitTarget() start InitTarget() end - Took 3.93ms Found SW-DP with ID 0x6BA02477 Scanning AP map to find all available APs AP[0]: AHB-AP (IDR: 0x84770001, ADDR: 0x00000000) ... Connected to target device. 在所有能够到达目标设备的情况下，设备都会因连接而发生可观察的副作用——重置，因此设备会退出掉电/深度掉电状态。 补充信息 这两个定制板的硬件版本相同，运行相同的软件，并且具有相同的掉电/深度掉电配置。 对于评估板，我们修改了示例 power_manager_lpc.c，使其使用与自定义板相同（或非常相似）的掉电/深度掉电配置。 所有设备均可通过其配置的唤醒源唤醒，并且在活动状态下（非低功耗模式）均可正常连接到 Ozone/调试器。 所有开发板都运行相同的 SDK 版本（24.12.00）。 问题 将调试器（SWD/Ozone/J-Link）连接到处于掉电或深度掉电状态的 LPC55S28 时，是否总是需要完全 RESET 芯片？或者，在这些模式下，是否有无需重置即可检查/停止内核的受支持方法？ 当目标处于睡眠状态时，是什么因素决定了 DM-AP ID 寄存器读取的是 0xFFFFFFFF 还是 0x00000000？ 报告“启用调试访问后 CPU 已成功停止”（观察 2）的调试邮箱恢复路径与不显示此类消息而静默恢复的路径（观察 3）之间有什么区别？ 是否有办法配置设备或调试会话，以便在目标不可达（睡眠、DP 完全断电）时连接成功，并且连接过程能够干净利落地失败（如观察结果 1 所示），而不是重置设备，从而在所有电路板上保持一致？或者观察结果 1 是异常情况，不应该在正常的硬件上发生？ 提前感谢！ 宝拉 Re: Inconsistent DM-AP attach behavior when attaching J-Link/Ozone to LPC55(S)28 in (Deep)Power Down Hello 睡眠、深度睡眠、断电或深度断电模式下不支持调试模式；此信息来自LPC552x 用户手册第 13.3.1 章； 要将调试器连接到 LPC55S28，必须先将其唤醒，如果处于掉电模式，则需要使用 RESET；当设备处于掉电模式时，无法连接调试会话； DM-AP ID 寄存器读取 0xFFFFFFFF 与 0x00000000 之间的区别可能是，0x00000000 是命令成功返回的响应（如UM11126第 50.5.7.2.1 章表 1064 中所述），而 0xFFFFFFFF 是未检测到的响应。 观察结果 1 看起来很奇怪，可能是因为设备仍处于关机模式而没有响应，或者您无法正确进入 DM-AP，因此无法进行调试；作为一种选择，您可以咨询一下是否是板 A 的硬件问题，因为板 B 可以成功连接。 此致敬礼，路易斯

Inconsistent DM-AP attach behavior when attaching J-Link/Ozone to LPC55(S)28 in (Deep)Power Down Hi, We're seeing inconsistent SWD attach behavior when connecting Ozone (J-Link) to an LPC5528 or LPC55S28 that's in Power Down or Deep Power Down mode, using Debug.SetConnectMode(CM_ATTACH_HALT). We've reproduced different outcomes across two 'identical' custom boards running LPC5528 and an NXP evaluation board running LPC55S28 - all revision 1B -, and would like clarification on the expected Debug Mailbox recovery flow. Setup MCU: LPC5528 and LPC55S28 Debug probe: J-Link Tool: Ozone, Debug.SetConnectMode(CM_ATTACH_HALT) Power modes tested: Power Down and Deep Power Down (entered via POWER_EnterPowerDown() / POWER_EnterDeepPowerDown()) Observation 1 — Board A, custom board, LPC5528, both Power Down and Deep Power Down DM-AP IDCODE never resolves; attach fails outright after 4 retries, no reset occurs: InitTarget() start ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF InitTarget() end - Took 101ms (repeated 4 times, then:)   Connection failed. Observation 2 — Board B, custom board, LPC5528, both Power Down and Deep Power Down DM-AP IDCODE reads 0x00000000 on the first attempt, then a second attempt reports an explicit debug-mailbox recovery message and succeeds:  InitTarget() start ERROR: Wrong DM-AP IDCODE detected: 0x00000000 InitTarget() end - Took 101ms ConfigTargetSettings() start InitTarget() start CPU halted successfully after enabling debug access InitTarget() end - Took 7.40ms Found SW-DP with ID 0x6BA02477 ... Connected to target device. Observation 3 — NXP evaluation board, LPC55S28, both Power Down and Deep Power Down DM-AP IDCODE also reads 0x00000000 on the first attempt, but the second attempt succeeds without printing the "enabling debug access" message — it just proceeds directly into a normal AP scan: InitTarget() start ERROR: Wrong DM-AP IDCODE detected: 0x00000000 InitTarget() end - Took 112ms ConfigTargetSettings() start InitTarget() start InitTarget() end - Took 3.93ms Found SW-DP with ID 0x6BA02477 Scanning AP map to find all available APs AP[0]: AHB-AP (IDR: 0x84770001, ADDR: 0x00000000) ... Connected to target device. In all cases where the target is reachable at all, the device resets as an observable side effect of attaching, so device exits power down/deep power down. Additional context The two custom boards are the same HW revision and run the same SW with the same Power Down/Deep Power Down configuration. For the evaluation board, we modified the example power_manager_lpc.c to use the same (or very similar) Power Down/Deep Power Down configuration as the custom boards. All devices can wake up on their configured wake-up sources, and all can connect to Ozone/the debugger normally while active (not in a reduced power mode). All boards are running the same SDK version (24.12.00). Questions Is a full chip reset always required to attach a debugger (SWD/Ozone/J-Link) to an LPC55S28 that's in Power Down or Deep Power Down? Or is there a supported way to inspect/halt the core without a reset in these modes? What determines whether the DM-AP ID register reads 0xFFFFFFFF versus 0x00000000 when the target is asleep? What's the difference between the debug-mailbox recovery path that reports "CPU halted successfully after enabling debug access" (Observation 2) versus the path that recovers silently with no such message (Observation 3)? Is there a way to configure the device or the debug session so that attaching while the target is unreachable (asleep, DP truly unpowered) fails cleanly (as in Observation 1) rather than resetting the device, across all boards consistently — or is Observation 1 the anomaly and should not occur on healthy hardware? Thanks in advance, Paula Re: Inconsistent DM-AP attach behavior when attaching J-Link/Ozone to LPC55(S)28 in (Deep)Power Down Hello The debug mode is not supported in sleep, deep-sleep, power-down or deep-power down mode; This information is from LPC552x User Manual Chapter 13.3.1; To attach a debugger to an LPC55S28 is necessary that you do the wake up first, using the reset if it was in a power down mode; and while the device is in this power down mode is not possible to attached the debug session; The difference between whether the DM-AP ID register reads 0xFFFFFFFF versus 0x00000000 could be that 0x00000000 is a response that shows a command succeed return as mention in Table 1064 in UM11126 Chapter 50.5.7.2.1, and 0xFFFFFFFF is an not detected response. The observation 1 seems weird, it could be a no response since the device could still be in a power down mode, or that you can't enter DM-AP correctly, therefore you can't debug; as an option you could consult if it's not a hardware issue with the board A, since the board B can be connected successfully. Best Regards, Luis