在 NXPS32K388 中，RTD5 与 EB tresos PWM 通道和 MCU 频率参考关系 你好， 我正在使用eMIOS通道进行PWM频率生成。 我使用同一个主计数器总线（A）作为全局参考，因为我需要所有 PWM 通道输出相同的频率（67kHz）。 所有 eMIOS 通道的 PWM 模式均选择为 EMIOS_PWM_IP_MODE_OPWMB。 已附上配置截图 我的疑问是：频率是如何根据时钟源计算出来的？ eMIOS 的时钟频率为 CORE_CLOCK = 160 MHz（是否仅用于主计数器总线）？ 对于 PWM 通道，我给出的 MCU 时钟参考值为 80 MHz，PWM 脉冲是否会基于 80 MHz 时钟生成？ 或者说，源时钟和MCU参考时钟应该配置相同？ 请确认PWM触发所使用的频率是多少？     已附上配置选项相关的屏幕截图。 Re: in NXPS32K388, RTD5 with EB tresos PWM Channel and MCU frequency Reference Relation 你好@Sambasiva 80 MHz PwmMcuClockReferencePoint 主要是一个软件/配置参考，供 PWM/RTD 配置用于计算时序/滴答。它不会为已选择总线 A 的 OPWMB 通道创建另一个物理 80 MHz 时基。 事实上，NXP 的 RTD 版本说明明确讨论了这种关系。 他们指出，对于使用主总线的 eMIOS 通道，周期应通过 MCL 主总线配置提供，并且 PWM 默认周期应使用 MCU 频率和主总线配置计算。 他们还指出 PwmMcuClockReferencePoint 用于确定 PWM 频率/滴答计算。 所以你的问题是： 1. eMIOS 的时钟频率为 CORE_CLOCK = 160 MHz，这是否仅适用于主计数器总线？ 否。 它作为 eMIOS 模块时钟系统的上游时钟； 总线 A 使用它（以及相应的预分频器）来建立计数器时间基准。 2.对于PWM通道，我给出的MCU时钟参考频率为80MHz，PWM脉冲是否会基于80MHz时钟生成？ 对于 eMIOS、FlexIO 和 FlexPWM 通道，当未选择“周期（以滴答为单位）”时，使用此参考值将以秒为单位配置的周期转换为滴答数。 时钟参考应与最终实际 PWM 时基相匹配；否则，周期滴答计算将不正确。

BCLKは使わず、LRCKはRW612 Zephyrのi2sペリフェラルを使っています 学生インターンとして、現在Zephyrでi2sの例を作っています。コードに合わせて、オーディオアンプとスピーカーを使って音を出力できるように改造しました。MCUXpresso設定ツールでピンを設定した後、J1.7にMCLK信号を追加することに成功しました。 IO_MUX_SetPinMux ( IO_MUX_MCLK ); を main に挿入します。 しかし、 IO_MUX_SetPinMux ( IO_MUX_FC1_I2S ); を実行しても、J1.15、13、9 には何も表示されません。以下が私のコードです。 /* * 著作権 (c) 2020 Antmicro < www.antmicro.com > * * SPDX-License-Identifier: Apache-2.0 */   #include #include #include #include #include #include "fsl_io_mux.h" #define AUDIO_SAMPLE_FREQ ( 44100 ) #define AUDIO_SAMPLES_PER_CH_PER_FRAME ( 128 ) #define AUDIO_NUM_CHANNELS ( 2 ) #define AUDIO_SAMPLES_PER_FRAME                                                \ ( AUDIO_SAMPLES_PER_CH_PER_FRAME * AUDIO_NUM_CHANNELS ) #define AUDIO_SAMPLE_BYTES ( 3 ) #define AUDIO_SAMPLE_BIT_WIDTH ( 24 ) #define AUDIO_FRAME_BUF_BYTES ( AUDIO_SAMPLES_PER_FRAME * AUDIO_SAMPLE_BYTES ) #define I2S_PLAY_BUF_COUNT ( 500 ) #define I2S_DEV_NODE_TX DT_ALIAS (i2s_node0) static const struct device * host_i2s_tx_dev ; static struct k_mem_slab i2s_tx_mem_slab ; static char tx_buffer [ AUDIO_FRAME_BUF_BYTES * I2S_PLAY_BUF_COUNT ]; static struct i2s_config i2s_tx_cfg ; static int ret ; static void init ( void ) {     printk ( "INIT ENTERED \n " );         //送信デバイスの設定     host_i2s_tx_dev = DEVICE_DT_GET_OR_NULL ( I2S_DEV_NODE_TX );     if ( host_i2s_tx_dev == NULL ) {      printk ( "I2S TXデバイスが見つかりません\n " );      終了（ -1 ）​    }     if ( ! device_is_ready ( host_i2s_tx_dev )) {         printk ( "I2S TXデバイスが準備できていません\n " );         終了（ -1 ）​    }     printk ( "I2S TXデバイス準備完了\n " );     k_mem_slab_init ( & i2s_tx_mem_slab , tx_buffer , AUDIO_FRAME_BUF_BYTES ,             I2S_PLAY_BUF_COUNT );     オーディオ再生のためのi2Sの設定     i2s_tx_cfg .ワードサイズ= AUDIO_SAMPLE_BIT_WIDTH ;     i2s_tx_cfg。チャネル = AUDIO_NUM_CHANNELS;     i2s_tx_cfg.format = I2S_FMT_DATA_FORMAT_I2S ;​​     i2s_tx_cfg . options = I2S_OPT_BIT_CLK_CONTROLLER |                          I2S_OPT_FRAME_CLK_CONTROLLER ;     i2s_tx_cfg . frame_clk_freq= AUDIO_SAMPLE_FREQ ;     i2s_tx_cfg . block_size= AUDIO_FRAME_BUF_BYTES ;     i2s_tx_cfg . mem_slab= & i2s_tx_mem_slab ;     i2s_tx_cfg.timeout = -1 ;​​​     ret = i2s_configure ( host_i2s_tx_dev , I2S_DIR_TX , & i2s_tx_cfg );     if ( ret != 0 ) {         printk ( "i2s_configure が%dエラーで失敗しました\n " , ret );         終了（ -1 ）​    }         } int main ( void ) {     printk ( "メイン開始\n " );     IO_MUX_SetPinMux ( IO_MUX_FC1_I2S );     IO_MUX_SetPinMux ( IO_MUX_MCLK );     init ();             printk ( "初期化が完了しました\n " );     void * tx_mem_block ;     uint32_t phase = 0 ;     const uint32_t tone_freq = 1000 ;     const int32_t amplitude = 0x200000 ; /* 中程度の 24 ビット音量 */     bool started = false ;     while ( true ) {                 ret = k_mem_slab_alloc ( & i2s_tx_mem_slab ,                        & tx_mem_block 、                        K_FOREVER );                         printk ( "バッファが割り当てられました\n " );         if ( ret != 0 ) {             printk ( "TXバッファの割り当てに失敗しました\n " );             続く;      }         uint8_t * buf = tx_mem_block ;         for ( int i = 0 ; i < AUDIO_SAMPLES_PER_CH_PER_FRAME ; i ++ ) {             int32_tサンプル;             /* 1 kHz の矩形波トーンを生成する */             if ( phase < ( AUDIO_SAMPLE_FREQ / 2 )) {                 サンプル=振幅; }それ以外{                 サンプル= -振幅;        }             phase += tone_freq ;             if ( phase >= AUDIO_SAMPLE_FREQ ) {                 phase -= AUDIO_SAMPLE_FREQ ;        }             /* 左チャネル - 24ビット */             * buf ++ = sample & 0xFF ;             * buf ++ = ( sample >> 8 ) & 0xFF ;             * buf ++ = ( sample >> 16 ) & 0xFF ; /* 右チャネル - 同じ信号 */             * buf ++ = sample & 0xFF ;             * buf ++ = ( sample >> 8 ) & 0xFF ;             * buf ++ = ( sample >> 16 ) & 0xFF ;      }         printk ( "BEFORE I2S_WRITE \n " );         ret = i2s_write ( host_i2s_tx_dev ,                 tx_mem_block 、                 オーディオフレームバッファバイト);         printk ( "AFTER I2S_WRITE %d \n " , ret );         if ( ret != 0 ) {             printk ( "i2s_write に失敗しました: %d \n " , ret );             k_mem_slab_free ( & i2s_tx_mem_slab , tx_mem_block );             続く;      }         /* 最初のバッファがキューに入れられた後に送信を開始する */         if ( !開始) {             printk ( "書き込み前\n " );             ret = i2s_trigger ( host_i2s_tx_dev ,                       I2S_DIR_TX 、                       I2S_TRIGGER_START );             printk ( "AFTER WRITE %d \n " , ret );             if ( ret != 0 ) {                 printk ( "I2S 開始に失敗しました: %d \n " , ret );                 return ret ;        }             printk ( "I2S TX が開始されました\n " );             開始= true ;      }    }     0を返す; } コードのどの部分が実行されているかを把握するために、コメントを追加しました。シリアルモニターを見ると、印刷は数回のサイクル後に停止していることがわかります。バッファが数サイクル後にいっぱいになり、プログラムが停止するのではないかと推測しています。 このプロジェクトを成功させるために助けてくれる人はいますか? よろしくお願いします Re: No bclk, LRCK using i2s peripheral on RW612 zephyr プロジェクト開発の共通基盤を築くため、以下の情報をご提供いただけますようお願いいたします。 Zephyr版(下流リポジトリかアップストリームかを明確にしてください)。 ベースのI2S Zephyrの例。 FRDM-RW612をご使用かどうかご確認ください。 Kconfigsを設定します（prj.confファイル内）。 使用しているオーバーレイ（もしあれば）を共有してください。 適用されたピン多重化設定「IO_MUX_SetPinMux(IO_MUX_FC1_I2S);」については、flexcommインスタンスに割り当てられたI2Sノードのデバイスツリー/オーバーレイレベルで定義する必要があります。デバイスツリーでI2Sノードを定義しているか教えていただけますか? また、共有されるオシロスコープのキャプチャがMCLK出力ピンからのものかどうかも教えていただけますか? Re: No bclk, LRCK using i2s peripheral on RW612 zephyr まずは、ありがとうございました。 - バージョン4.4.1 アップストリームリポジトリ - 例:Zephyr/サンプルS/ドライバ/i2/出力 元のi2s/出力例と比較した主な変更点: 1. RXパスの削除 元のプロジェクトはRX/TX運用を想定して設計されました。 RX関連のコードは、目的は音声再生のみ(TX)であるため削除されました。 2. オーディオフォーマットを24ビットに変更 word_size = 24 意図された24ビットオーディオ出力フォーマットに合わせるために。 3. 波形生成の変更 正弦波を1kHzの方形波に置き換えました。 4. バッファ処理の変更 有限のバッファを送る代わりに、whileループ内でオーディオデータが連続的に生成されます。 目標:連続オーディオ出力を提供すること。 5. RW612専用ピンマルチマックス構成の追加 追加:IO_MUX_SetPinMux(IO_MUX_FC1_I2S); IO_MUX_SetPinMux(IO_MUX_MCLK); - FRDM-RW612を使っています - prj.conf: CONFIG_LOG=y CONFIG_I2S=y CONFIG_I2S_LITEX_RX_BLOCK_COUNT=500 CONFIG_I2S_LITEX_DATA_BIG_ENDIAN=n CONFIG_ETH_LITEX_LITEETH=n CONFIG_PRINTK=y CONFIG_CONSOLE=y CONFIG_UART_CONSOLE=y - App.オーバーレイ / { 別名 { i2S-node0 = &flexcomm1; }; }; &flexcomm1 { 互換 = "NXP,LPC-i2s"; pinCtrl-0 = <&pinmux_flexcomm1_i2s>; pinCtrl-names = "default"; status = "OK"; }; オシロスコープの映像はMCLK出力ピンからのものです。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr i2s_outputのサンプルをそのままテストしたところ、I2S信号が正しく生成されました。 I2S_BCLK、I2S_DATA、I2S_WSの寸法が、FRDMボードの以下のヘッダー接続から取られていることを確認していただけますか? I2S_DATA - J1.2 I2S_WS - J1.4 I2S_BCLK - J2.12 また、以下のLITEX設定を行っていることに気づきました。 CONFIG_I2S_LITEX_RX_BLOCK_COUNT=500 CONFIG_I2S_LITEX_DATA_BIG_ENDIAN=n CONFIG_ETH_LITEX_LITEETH=n これらの設定は、他社製のLitex対応ハードウェアで使用することを想定していますが、お客様のプロジェクト構成には適用されない可能性があります。その場合は、以下のFlexcomm固有の設定に置き換えて、アプリケーションの要件に合わせて調整してください。 CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS さらに、デバイスツリーの説明から設定されているため、「IO_MUX_SetPinMux(IO_MUX_FC1_I2S);」という呼び出しを削除してください。 この情報がお役に立てば幸いです。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr ありがとうございました。いただいたご回答は大変参考になりました。 ご提案いただいた内容に基づき、以下の変更を行いました。 追加: CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT=4 LITEXの設定を削除しました。 "IO_MUX_SetPinMux(IO_MUX_FC1_I2S)" を削除しました。 私は以下を追加しなかった。 CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS なぜなら、ZephyrツリーのどこにもこのKconfigオプションが見つからなかったからです。ドライバの情報源を検索しましたが、以下の参照しか見つかりませんでした。 CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT = 4 信号測定に関して、私は最初に以下の項目で測定を行いました。 J1.15,13 & 7 は、それらが flexcomm1 へのピンmux 上に構成されているのを見たためである。   ご指定いただいたピンで測定を繰り返したところ、以下の結果が得られました。 I2S_DATA (J1.2):観測可能な信号なし I2S_WS (J1.4):約51kHzの矩形波 I2S_BCLK (J2.12): 約2.46MHz方形波 現時点ではMCLK、BCLK、WSの信号は観測できますが、DATAピンの活動は観察できません。 DATA信号がないことは、送信されたオーディオサンプルやI2S構成に問題があるのか、それとも次に調べるべき他の点があるのか教えていただけますか? Re: No bclk, LRCK using i2s peripheral on RW612 zephyr こんにちは、 @Zakintern さん。進歩があったと聞いて嬉しいです。 前回のログから、書き込みはあなたが設定した「CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT = 4」の定義設定に従って行われているようで、これによりI2S TXキューは4ブロックに定義されています。アプリケーションの要件に応じてブロック数を調整して試してみてください。 ちなみに、構成「CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS」はZephyrメインブランチに追加されており、Zephyr v4.5.0リリースで使えるかもしれません。 これが役に立つかどうか教えてください。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 問題のある射撃の後、最初の数回の i2s_write() 通話は正常に戻ってくるものの、最終的にアプリケーションが内部でブロックしてしまうことがわかりました: printk ( "BEFORE I2S_WRITE \n " );         ret = i2s_write ( host_i2s_tx_dev ,                 tx_mem_block 、                 オーディオフレームバッファバイト);         printk ( "AFTER I2S_WRITE %d \n " , ret ); バッファはキューに格納されているようですが、最終的には満杯になってしまいます。ハードウェアがキューにされたオーディオデータを消費していないのかもしれません。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr こんにちは、ローマンさん。 ご指摘ありがとうございます。 Zephyrの4.5バージョンも確実にダウンロードしました。これには以下が含まれます CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT = 8 CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS = 8 これらは私の正しい設定でもあります。 シリアルモニターではI2Sの読み取りが正常に行われていることが示されていますが、最終的にログはデータピンGPIO8 J1にデータが出力されないまま停止します。 どうやらバッファが最終的に満杯になり、ハードウェアによって解放されるものは何もないようだ。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr こんにちは、 @Zakintern さん。詳細情報を提供していただきありがとうございます。 バニラ版で「変更なし」というi2s_output例を試したことがあるか、教えていただけますか? この点についてさらに踏み切ると、まずベースサンプルをテストし、それに応じて修正を実装することをお勧めします。ベースサンプルは正常に動作し、ハードウェアを通じてデータを出力するために必要なAPIフローの参照にもなります。 サンプルをテストしたところ、記載されているピン（FRDMボードのヘッダーJ1の端子2）でデータを確認できました。GPIO8はI2S_WS端子、GPIO9はI2S_DATA端子ですので、必ずこのピンで測定を行ってください。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 基本となるサンプルは現在正常に動作しています。 変更後、なんとか動作させることができました prj.conf の CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT を 8 から 16 に変更します。 ご協力ありがとうございます。これをベースに、私なりの修正を加えて実装させていただきます。

MCXA156VLH ADC 内部二极管额定值 我们需要第 36 页 - 图 12 中提到的二极管的额定值的详细信息。ADC 输入阻抗等效图。 我们需要了解可接受的评分标准，以便据此设计我们的应用程序。 模拟（ADC|CMP|DAC|运算放大器） 电路板设计 Re: MCXA156VLH ADC INTERNAL DIODE RATINGS 你好@TEMCEFF ， 感谢您的帖子。请参阅我们的产品数据表： 对于 MCXA156，当 VIN 低于 VSS − 0.3 V 或高于 VDD + 0.3 V 时，每个 I/O 引脚的直流注入限流为 ±3 mA。此外，16 个连续引脚的区域注入电流限流为 ±25 mA。如果输入电压可能超过这些电压限制，则应使用外部限流电阻。 希望对您有所帮助。 BR 塞莱斯特 Re: MCXA156VLH ADC INTERNAL DIODE RATINGS 感谢您提供 ADC 注入限流（每个 I/O 引脚 ±3 mA 和 ±25 mA 区域限制）。 我们正在为 MCXA156 ADC 设计模拟前端，并希望更好地了解 ADC 输入等效电路（图 12 / ADC 输入阻抗等效图）中所示的内部保护结构的行为和局限性。 具体而言，我们希望您能就以下几点进行澄清： 钳位行为 当ADC输入电压超过VDD_ANA（例如VDD_ANA = 3.3 V，VIN = 5 V）时，内部保护结构是否会钳位输入电压？ 如果是这样，钳位期间 ADC 引脚的典型电压是多少（例如，大约 VDD_ANA + 0.3 V、VDD_ANA + 0.7 V 等）？ 夹具特性 是否有以下方面的特征数据： 钳位电压与注入电流的关系 防护结构的动态阻力 内部钳位路径的正向电压 过电压/耐受能力 如果外部将注入电流限制在规定的±3 mA限制以下，是否存在一个最大可承受的ADC输入电压，而不会损坏设备？ 例如，在注入电流保持在规定限值以下的情况下，ADC 输入能否安全地承受 5V、12V 或更高的瞬态电压？ 瞬态和浪涌能力 是否有关于以下方面的信息： 最大瞬态脉冲电流 最大瞬态持续时间 内部防护结构能够吸收的最大能量 系统级保护建议 内部保护网络是否仅被视为静电放电/注入电流保护结构，而对于重复性过电压情况则需要外部保护元器件？ 我们的目标是确定可能暴露于故障情况或短时过电压尖峰的 ADC 通道所需的外部保护电路和电阻器尺寸。 Re: MCXA156VLH ADC INTERNAL DIODE RATINGS 你好@TEMCEFF ， 感谢您提出的详细问题。 我查阅了MCXA156的公开文档。根据数据表，您的一些问题可以得到解答，而内部保护结构的详细特性则需要我们内部团队进一步确认。 根据数据表： I/O 引脚通过 ESD 保护结构对 VSS 和 VDD 进行内部钳位。 每个引脚的最大直流注入电流为±3 mA ， 16 个连续引脚的区域限制为±25 mA 。 对于正注入电流，数据手册将注入条件定义为VIN > VDD + 0.3 V。 数据手册提供了以下用于计算正向注入限流电阻的公式： R = (VIN - VDD_MAX) / IICIOmax 对于瞬态电压，数据手册建议使用比基本方程计算出的值高一个数量级的电阻值。 然而， VDD + 0.3 V 不应被视为保证的或固定的钳位电压。公开文档并未提供钳位电压 IV 特性的详细描述。 我也找不到以下项目的公开规格说明： 钳位电压与注入电流的关系 内部钳位的动态电阻或详细正向电压特性 当注入电流限制在 3 mA 以下时，最大外部施加电压为 5 V、12 V 或更高。 最大瞬态脉冲电流和脉冲持续时间 内部防护结构能够吸收的最大能量 内部钳位电路在重复系统级过电压条件下的验证 因此，我不想仅仅根据注入电流规格来对这些限制做出假设。这些问题需要上报给内部团队进行进一步确认。 根据我们的升级处理流程，请您提供以下信息？ 最终客户姓名 最终应用程序名称 一旦我们掌握了这些信息，就可以启动升级程序。   BR 塞莱斯特 Re: MCXA156VLH ADC INTERNAL DIODE RATINGS 请参考以下所列详情。 最终客户名称 - 印度铁路 最终应用名称 - 智能现场设备 应用描述 - 用于监测和控制铁路资产（如照明、自动扶梯、电梯等）的物联网设备； Re: MCXA156VLH ADC INTERNAL DIODE RATINGS 你好@TEMCEFF ， 感谢您的耐心等待。请查看我们内部的回复： ” 虽然数据手册规定每引脚±3 mA和区域±25 mA直流注入电流限流，但这些限制并不会凌驾于ADC/I/O输入电压绝对最大额定值之上。因此，仅将注入电流保持在 3 mA 以下并不能保证临时 5 V、12 V 或更高输入是安全的。 数据手册中没有对内部 ESD 钳位电路进行表征，例如保证钳位电压、I-V 曲线、动态电阻或瞬态脉冲/能量能力。因此，我们不建议依靠内部夹具进行重复性或系统级故障保护。 对于此应用，我们建议采用外部保护，例如串联电阻器与合适的低正向电压肖特基钳位电路相结合，以使 ADC 引脚保持在规定的电压范围内。 ” 如果您需要更多详细信息，请告诉我。 BR 塞莱斯特

in NXPS32K388, RTD5 with EB tresos PWM Channel and MCU frequency Reference Relation Hello, i am using the eMIOS channels for PWM frequency generation.  I am using the same Master Counter BuS (A) as a global reference as i need the same frequency(67kHz) output on all the PWM channels. PWM mode is selected as EMIOS_PWM_IP_MODE_OPWMB for all eMIOS channels. Attached the Screenshots of configuration My doubt is How the Frequency is calculated based on Clock Source? eMIOS is clocked with CORE_CLOCK = 160 Mhz (Is it only for the Master Counter Bus)? For PWM channel i am giving the MCU clock Reference (80 Mhz) , Is PWM pulse will be generated based on 80 Mhz Clock? Or The Source clock and mcu Reference clock Should be Configured  Same?  Please confirm which frequency is used for PWM triggering?     Configuration options related screenshots are attached. Re: in NXPS32K388, RTD5 with EB tresos PWM Channel and MCU frequency Reference Relation Hi@Sambasiva The 80 MHz PwmMcuClockReferencePoint is primarily a software/configuration reference used by the PWM/RTD configuration to calculate timing/ticks. It does not create another physical 80 MHz time base for an OPWMB channel that has selected Bus A. In fact, NXP's RTD release notes explicitly discuss this relationship. They state that for eMIOS channels using a Master Bus, the period should be provided through the MCL Master Bus configuration and that the PWM default period should be calculated using the MCU frequency and the master-bus configuration. They also identify PwmMcuClockReferencePoint as being used to determine PWM frequency/tick calculations. So your question: 1.eMIOS is clocked with CORE_CLOCK = 160 Mhz ,Is it only for the Master Counter Bus? No. It serves as the upstream clock for the eMIOS module clock system; Bus A uses it—along with a corresponding prescaler—to establish a counter timebase. 2.For PWM channel i am giving the MCU clock Reference (80 Mhz) , Is PWM pulse will be generated based on 80 Mhz Clock? For eMIOS, FlexIO, and FlexPWM channels, this reference is used—when "Period In Ticks" is not selected—to convert a period configured in seconds into ticks. The Clock Reference should match the actual final PWM timebase; otherwise, the period tick calculation will be incorrect.

Free RTOS package issue. Dear Team, I am facing one problem please help me to fix this. while configuration time i am tyring to select the free RTOS packege picking,  refere the below image which you can get the issue. looking forward your response. thankyou & regards, sunil ladwa. Re: Free RTOS package issue. Hello @sunil0509, SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603 package requires RTD 7.0.1, as stated in the release notes, can you confirm it is indeed installed?  SW32K3 FreeRTOS 11.1.0 version 0.8.0 CD1 Release NotesSW32K3 FreeRTOS 11.1.0 version 0.8.0 CD1 Release NotesSW32K3 FreeRTOS 11.1.0 version 0.8.0 CD1 Release Notes The "Freertos is not found in the toolchain/IDE project. The project Will not compile!" warning you are sharing is expected when the package is not added to the project yet. This means that after adding the "FreeRTOS" component, and clicking "Update Code", the warning should disappear. Can you confirm you can add, update code and build a project with FreeRTOS package?  Peripherals PerspectivePeripherals PerspectivePeripherals Perspective Correct view for FreeRTOS component added to projectCorrect view for FreeRTOS component added to projectCorrect view for FreeRTOS component added to project Best regards, Julián Re: Free RTOS package issue. Hello Team, i also tell you that i am using GCC 10.2 for S32DS.3.6.12 IDE, i installed "SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603" this but still issue is coming. please help me to fix this. thank you and regards, sunil ladwa. Re: Free RTOS package issue. Hello  , please check these error, please help me to fix these error. thank you and regards, sunil ladwa

i.MX93 FRDM：使用 ISI 进行 RAW10 捕获时，IMX219 和 IMX708 每帧仅写入一行。 你好， 我们正在FRDM-IMX93上安装MIPI CSI-2 RAW相机，希望得到NXP的帮助。IMX219 和 IMX708 都能启动并传输数据帧，但每种传感器只能捕获一行数据。 帧包含数据。其他所有行均为零。在 IMX219 上，我们测试的每个分辨率都会出现这种情况。我们不清楚原因，恳请您指点。 这里曾报道过内核 6.12.20 上出现过类似的症状，但没有找到解决方案： https://community.nxp.com/t5/i-MX-Graphics/i-MX93-RAW10-capture-issue-only-first-line-valid-IMX219-ISI/mp/2321729 环境 - 板：FRDM-IMX93（机器型号 = imx93-11x11-lpddr4x-frdm），摄像头位于 P6 MIPI CSI 连接器上 - 电路板支持包。：imx-6.18.37-2.1.0来自 nxp-imx/imx-清单 (meta-imx rel_imx_6.18.37_2.1.0)Yocto 6.0.2 wrynose，发行版 = fsl-imx-wayland - 内核：6.18.37-2.1.0-gddef48f9b907 - Pipeline: sensor --csidev-4ae00000.csi (dwc-mipi-csi2) --crossbar --mxc_isi.0-> mxc_isi.0.捕获 (/dev/video0) - 格式：SRGGB10_1X10 / RG10，2 条数据通道 传感器 1. Raspberry Pi 相机模块 v2 NoIR (IMX219) - 内置 imx219 驱动程序以及未修改的 电路板支持包。 CSI 和 ISI 驱动程序 - 链路频率：456 MHz 2. 树莓派摄像头模块 3 NoIR (IMX708) - 驱动程序移植自 Raspberry Pi 内核 (rpi-6.12.y) - 链路频率：450 MHz - 如果不做进一步的更改，该传感器会产生 IPI FIFO 溢出，并且没有帧。当传感器寄存器 0x3095 设置为 0 时，帧速率为 56 fps，分辨率为 2304x1296。 结果 传感器分辨率图像源结果 IMX219 640x480 实时图像，彩色条形帧已输出，但只有第 0 行有数据。 已交付 IMX219 1640x1232 彩色条形帧，但只有第 0 行包含数据。 IMX219 1920x1080 实时图像，彩色条形帧已输出，但只有第 0 行有数据。 IMX219 3280x2464 彩色条形帧已输出（14.5 fps），但只有第 0 行有数据。 IMX708 2304x1296 彩色条形帧已输出（56 fps），但只有第 0 行有数据。 在每种情况下，缓冲区的大小都符合预期（宽度 x 高度 x 2 字节）。第 0 行包含预期数据，例如颜色条。其余所有行均为零。IMX219 测试结果显示未检测到 CSI 或 ISI。 dmesg 中出现错误。 命令（IMX219，640x480） media-ctl -V "'imx219 2-0010':0[fmt:SRGGB10_1X10/640x480]" media-ctl -V "'csidev-4ae00000.csi':0[fmt:SRGGB10_1X10/640x480 field:none]" media-ctl -V "'crossbar':0[fmt:SRGGB10_1X10/640x480 field:none]" media-ctl -V "'mxc_isi.0':0[fmt:SRGGB10_1X10/640x480字段：无]" media-ctl -V "'mxc_isi.0':1[fmt:SRGGB10_1X10/640x480字段：无]" v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=RG10 \ --stream-mmap --stream-count=10 --stream-to=/tmp/cap.bin 流式传输期间读取的寄存器值（IMX219，640x480，调试 CSI 版本，症状相同） ISI 0x4ae40000: CHNL_CTRL (0x00) = 0xe0000000 CHNL_IMG_CTRL (0x04) = 0x0f008001 CHNL_IMG_CFG (0x0c) = 0x01e00280 媒体混合 0x4ac10000: 0x30 = 0x00010158 0x3c = 0x00000e07 0x40 = 0x00000001 0x44 = 0x00019140（帧间值） 0x48 = 0x0002291c 问题 1.i.MX93 是否验证了通过 ISI 从 CSI-2 传感器捕获 RAW 数据的功能？如果是，请问使用了哪种传感器、电路板支持包。版本和配置？ 2. 是否有适用于此用例的已知问题、勘误或必需设置？ 3. 接下来我们应该检查什么？请与我们联系，告知我们需要哪些注册表、日志或捕获文件，我们将提供这些文件。 4. FRDM-IMX93 上是否有适用于 IMX219 或其他 RAW 传感器的参考设备树或补丁？ 我们可以根据要求分享完整日志、设备树叠加图和原始捕获数据。 感谢您的支持。 Linux Yocto Project Re: i.MX93 FRDM: RAW10 capture through ISI writes only one line per frame with IMX219 and IMX708 我已经把imx219的补丁发给你了，请参考这个。

S32DS for ARM 2018R1 license Hi: My license of S32DS for ARM 2018R1 IDE has expired. Could you help check and extend it for me?  Thanks. Re: S32DS for ARM 2018R1 license Hi,  your S32DS license has been extended, please activate S32DS again with your old code.  Re: S32DS for ARM 2018R1 license Thanks!!

请求审查 i.MX95-15x15-FRDM 上的双 LAN9646 以太网交换机集成。 您好，NXP团队， 我创建了一个设备树补丁（ 2Xlan9646_imx95_15x15.patch ），将两个 LAN9646 以太网交换机 IC 与我的自定义 i.MX95 15×15 板上的 ETH1 和 ETH2 集成在一起。 请您仔细审核一下补丁，并确认以太网交换机集成是否正确？ 请重点关注： LAN9646 配置、SPI 接口、片选、RESET GPIO 和中断设置。 两个交换机与 ENETC 端口 ETH1 和 ETH2 之间的连接。 任何缺失或不正确的属性都可能导致两个以太网接口无法正常工作。 请特别注意两台 LAN9646 交换机是否可以同时运行，以及它们的端口和 PHY 配置是否正确。 该补丁还包含 HDMI、音频、LVDS 和其他设备树更改。请忽略这些更改，仅查看双 LAN9646 以太网集成。 请提出必要的修改建议，并尽可能提供参考设备树示例或文档。 感谢您的支持。 Re: Request for Review of Dual LAN9646 Ethernet Switch Integration on i.MX95-15x15-FRDM. 您好， 感谢您对恩智浦半导体产品的关注， 我们没有用 i.MX 95 测试过 LAN9646 以太网交换机，所以我查看了相关信息，但无法确认它是否有效。 1.拥有可用的 DTS 是一个好习惯，所以我不会注释掉 Reset 和 IRQ 行，并且我会设置一个默认的 GPIO，最好是将值覆盖或保存在其他文件中，而不是留下一个不完整的节点。 2. DTS 中的映射被交换，原理图中 pinctrl_enetc1 映射到 LPSPI3，可以看到 ENET1/ETH0 与 LPSPI3 一起连接到 PHY1，ENET2/ETH1 连接到 PHY2 和 LPSPI6。这与DTS不同。 3. 由于两台交换机共享 LAN 命名属性，我会在 LAN 名称前添加一个前缀。 以上是我的评测，如果您想进一步测试您的 DTS，请尝试 dtbs_check 。 此致

RTOSパッケージの無料配布。 チームの皆様へ 一つ問題に直面しています。どうかこれを直す手助けをしてください。 設定中、無料のRTOSパックピックを選択しようとしています。 以下の画像を参照すれば問題の原因がわかります。 ご回答をお待ちしております。 ありがとうございます。よろしくお願いいたします。 スニル・ラドワ。 Re: Free RTOS package issue. こんにちは、 @sunil0509 さん。 SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603パッケージはリリースノートに記載されている通りRTD 7.0.1が必要ですが、本当にインストールされているか確認できますか? SW32K3 FreeRTOS 11.1.0 version 0.8.0 CD1 Release NotesSW32K3 FreeRTOS 11.1.0 version 0.8.0 CD1 Release NotesSW32K3 FreeRTOS 11.1.0 バージョン 0.8.0 CD1 リリースノート 「Freertos」はツールチェーン/IDEプロジェクトには存在しません。プロジェクトはコンパイルされません！パッケージがまだプロジェクトに追加されていない場合、共有している警告は期待されます。つまり、「FreeRTOS」コンポーネントを追加して「コードの更新」をクリックすると、警告は消えるはずです。 FreeRTOSパッケージでコードの追加、更新、プロジェクト構築が可能か確認できますか? Peripherals PerspectivePeripherals Perspectiveペリフェラルの視点 Correct view for FreeRTOS component added to projectCorrect view for FreeRTOS component added to projectプロジェクトに追加されたFreeRTOSコンポーネントの正しい表示 よろしくお願いします、 ジュリアン Re: Free RTOS package issue. こんにちは、チームの皆さん、 また、S32DS.3.6.12にはGCC 10.2を使用していることもお伝えしておきます。IDEで「SW32K3_FreeRTOS_11.1.0_0.8.0_CD1_D2603」をインストールしましたが、それでも問題が出ています。 これを直すのを手伝ってください。 ありがとうございます。 スニル・ラドワ。 Re: Free RTOS package issue. こんにちは 、 これらのエラーを確認してください。これらのエラーを修正するのを手伝ってください。 ありがとうございます。 スニル・ラドワ

No bclk, LRCK using i2s peripheral on RW612 zephyr As a student intern i'm currently working on the i2s example in zephyr. i modified to code so i could output a sound using an audio amplifier and a speaker. after configuring the pins in MCUXpresso config tools, i have managed to get a signal on MCLK on J1.7 after adding  IO_MUX_SetPinMux(IO_MUX_MCLK); in to the main. But adding  IO_MUX_SetPinMux(IO_MUX_FC1_I2S); doesn't show anything on J1.15, 13 and 9. Bellow is my code: /*  * Copyright (c) 2020 Antmicro <www.antmicro.com>  *  * SPDX-License-Identifier: Apache-2.0  */   #include #include #include #include #include #include "fsl_io_mux.h" #define AUDIO_SAMPLE_FREQ (44100) #define AUDIO_SAMPLES_PER_CH_PER_FRAME (128) #define AUDIO_NUM_CHANNELS (2) #define AUDIO_SAMPLES_PER_FRAME                                                \     (AUDIO_SAMPLES_PER_CH_PER_FRAME * AUDIO_NUM_CHANNELS) #define AUDIO_SAMPLE_BYTES (3) #define AUDIO_SAMPLE_BIT_WIDTH (24) #define AUDIO_FRAME_BUF_BYTES (AUDIO_SAMPLES_PER_FRAME * AUDIO_SAMPLE_BYTES) #define I2S_PLAY_BUF_COUNT (500) #define I2S_DEV_NODE_TX DT_ALIAS(i2s_node0) static const struct device *host_i2s_tx_dev; static struct k_mem_slab i2s_tx_mem_slab; static char tx_buffer[AUDIO_FRAME_BUF_BYTES * I2S_PLAY_BUF_COUNT]; static struct i2s_config i2s_tx_cfg; static int ret; static void init(void) {     printk("INIT ENTERED\n");         //configure tx device     host_i2s_tx_dev = DEVICE_DT_GET_OR_NULL(I2S_DEV_NODE_TX);     if (host_i2s_tx_dev == NULL) {      printk("I2S TX device not found\n");      exit(-1);     }     if (!device_is_ready(host_i2s_tx_dev)) {         printk("I2S TX device not ready\n");         exit(-1);     }     printk("I2S TX device ready\n");     k_mem_slab_init(&i2s_tx_mem_slab, tx_buffer, AUDIO_FRAME_BUF_BYTES,             I2S_PLAY_BUF_COUNT);     // configure i2s for audio playback     i2s_tx_cfg.word_size = AUDIO_SAMPLE_BIT_WIDTH;     i2s_tx_cfg.channels = AUDIO_NUM_CHANNELS;     i2s_tx_cfg.format = I2S_FMT_DATA_FORMAT_I2S;     i2s_tx_cfg.options = I2S_OPT_BIT_CLK_CONTROLLER |                          I2S_OPT_FRAME_CLK_CONTROLLER;     i2s_tx_cfg.frame_clk_freq = AUDIO_SAMPLE_FREQ;     i2s_tx_cfg.block_size = AUDIO_FRAME_BUF_BYTES;     i2s_tx_cfg.mem_slab = &i2s_tx_mem_slab;     i2s_tx_cfg.timeout = -1;     ret = i2s_configure(host_i2s_tx_dev, I2S_DIR_TX, &i2s_tx_cfg);     if (ret != 0) {         printk("i2s_configure failed with %d error\n", ret);         exit(-1);     }         } int main(void) {     printk("MAIN START\n");     IO_MUX_SetPinMux(IO_MUX_FC1_I2S);     IO_MUX_SetPinMux(IO_MUX_MCLK);     init();             printk("INIT FINISHED\n");     void *tx_mem_block;     uint32_t phase = 0;     const uint32_t tone_freq = 1000;     const int32_t amplitude = 0x200000;   /* moderate 24-bit volume */     bool started = false;     while (true) {                 ret = k_mem_slab_alloc(&i2s_tx_mem_slab,                        &tx_mem_block,                        K_FOREVER);                         printk("BUFFER ALLOCATED\n");         if (ret != 0) {             printk("TX buffer allocation failed\n");             continue;         }         uint8_t *buf = tx_mem_block;         for (int i = 0; i < AUDIO_SAMPLES_PER_CH_PER_FRAME; i++) {             int32_t sample;             /* Generate 1 kHz square-wave tone */             if (phase < (AUDIO_SAMPLE_FREQ / 2)) {                 sample = amplitude;             } else {                 sample = -amplitude;             }             phase += tone_freq;             if (phase >= AUDIO_SAMPLE_FREQ) {                 phase -= AUDIO_SAMPLE_FREQ;             }             /* Left channel - 24 bit */             *buf++ = sample & 0xFF;             *buf++ = (sample >> 8) & 0xFF;             *buf++ = (sample >> 16) & 0xFF;             /* Right channel - same signal */             *buf++ = sample & 0xFF;             *buf++ = (sample >> 8) & 0xFF;             *buf++ = (sample >> 16) & 0xFF;         }         printk("BEFORE I2S_WRITE\n");         ret = i2s_write(host_i2s_tx_dev,                 tx_mem_block,                 AUDIO_FRAME_BUF_BYTES);         printk("AFTER I2S_WRITE %d\n", ret);         if (ret != 0) {             printk("i2s_write failed: %d\n", ret);             k_mem_slab_free(&i2s_tx_mem_slab, tx_mem_block);             continue;         }         /* Start TX after the first buffer has been queued */         if (!started) {             printk("BEFORE WRITE\n");             ret = i2s_trigger(host_i2s_tx_dev,                       I2S_DIR_TX,                       I2S_TRIGGER_START);             printk("AFTER WRITE %d\n", ret);             if (ret != 0) {                 printk("I2S start failed: %d\n", ret);                 return ret;             }             printk("I2S TX started\n");             started = true;         }     }     return 0; } I've added comments to find out what part of the code is being executed. my serial monitor is showing that the printing stops after a few cycles. I suspect that the buffer gets filled after a few cycles makes the program stop.  IS there anyone that can assist me in making this project work? Thank you in advance Re: No bclk, LRCK using i2s peripheral on RW612 zephyr To have a common ground for your project development, please help me providing the following: Zephyr version (please clarify if downstream or upstream repository). Base I2S Zephyr example. Please confirm if you are using FRDM-RW612. Set Kconfigs (in prj.conf file) Share the overlay being used (if any). Regarding your applied pin mux settings "IO_MUX_SetPinMux(IO_MUX_FC1_I2S);" this should be defined at device tree/overlay level in an I2S node assigned to a flexcomm instance. Could you please clarify if you have defined the I2S node in your device tree? Also, could you please clarify if the shared oscilloscope capture is from the MCLK output pin? Re: No bclk, LRCK using i2s peripheral on RW612 zephyr First off all thank you reponse, - version 4.4.1 upstream repository - example zephyr/sample s/drivers/i2s/output Main modifications compared to the original i2s/output example: 1. Removed RX path The original project was designed for RX/TX operation. RX-related code was removed because the goal is audio playback only (TX). 2. Changed audio format to 24-bit word_size = 24 to match the intended 24-bit audio output format. 3. Changed waveform generation Replaced the sine wave with a 1 kHz square wave. 4. Changed buffer handling Instead of sending a finite number of buffers, audio data is generated continuously inside the while loop. Goal: provide continuous audio output. 5. Added RW612-specific pin mux configuration Added: IO_MUX_SetPinMux(IO_MUX_FC1_I2S); IO_MUX_SetPinMux(IO_MUX_MCLK); - I'm making use of the FRDM-RW612 - prj.conf: CONFIG_LOG=y CONFIG_I2S=y CONFIG_I2S_LITEX_RX_BLOCK_COUNT=500 CONFIG_I2S_LITEX_DATA_BIG_ENDIAN=n CONFIG_ETH_LITEX_LITEETH=n CONFIG_PRINTK=y CONFIG_CONSOLE=y CONFIG_UART_CONSOLE=y - app.overlay / { aliases { i2s-node0 = &flexcomm1; }; }; &flexcomm1 { compatible = "nxp,lpc-i2s"; pinctrl-0 = <&pinmux_flexcomm1_i2s>; pinctrl-names = "default"; status = "okay"; }; The oscilloscope picture is from the MCLK output pin. Re: No bclk, LRCK using i2s peripheral on RW612 zephyr I have tested the i2s_output example vanilla and it generates properly the I2S signals.  Could you please confirm that the measurements of I2S_BCLK, I2S_DATA & I2S_WS are being taken from the following header connections of the FRDM board? I2S_DATA - J1.2 I2S_WS - J1.4 I2S_BCLK - J2.12 Also, I noticed that you are setting the following LITEX configurations: CONFIG_I2S_LITEX_RX_BLOCK_COUNT=500 CONFIG_I2S_LITEX_DATA_BIG_ENDIAN=n CONFIG_ETH_LITEX_LITEETH=n These configurations are meant to use along Litex-enabled hardware from another vendor, while these might not be applying to your project build, please replace them with Flexcomm specific configurations as below adjusted to your app requirements: CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS Additionally, please remove the "IO_MUX_SetPinMux(IO_MUX_FC1_I2S);" call, since this is being configured from the device tree description. Please let me know if this information helps. Re: No bclk, LRCK using i2s peripheral on RW612 zephyr Thank you, I was really able to benefit from your replies. Following your suggestions, I made the following changes: Added: CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT=4 removed the  LITEX configurations. Removed the "IO_MUX_SetPinMux(IO_MUX_FC1_I2S) I did not add:  CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS because I could not find this Kconfig option anywhere in my Zephyr tree. I searched through the driver sources and only found references to CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT = 4 Regarding the signal measurements, I initially measured on: J1.15,13 & 7 due to seeing them configured on the pinmux to flexcomm1   I repeated the measurements on the pins you specified and obtained the following results: I2S_DATA (J1.2): No observable signal I2S_WS   (J1.4): ~51 kHz square wave I2S_BCLK (J2.12):  ~2.46 MHz square wave So at the moment I can observe MCLK, BCLK and WS signals, but I do not observe activity on the DATA pin. Could you please advise whether the absence of a DATA signal suggests an issue with the transmitted audio samples, I2S configuration, or if there is another aspect I should investigate next? Re: No bclk, LRCK using i2s peripheral on RW612 zephyr Hi @Zakintern, glad to know you made progress. From your last log, it seems that the writings are performed per the defined configuration you have set "CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT = 4", which defines the I2S TX queue to 4 blocks, please try by adjusting the number of blocks as per your application requirements. As a side note, the configuration "CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS" has been added to Zephyr main branch, it might be available to be used on Zephyr v4.5.0 release. Please let me know if this helps. Re: No bclk, LRCK using i2s peripheral on RW612 zephyr After troubling shooting I've found out that the The first several i2s_write() calls return successfully but the application eventually blocks inside: printk("BEFORE I2S_WRITE\n");         ret = i2s_write(host_i2s_tx_dev,                 tx_mem_block,                 AUDIO_FRAME_BUF_BYTES);         printk("AFTER I2S_WRITE %d\n", ret); It looks like the buffers are being queued but it eventually fills up. The hardware may not be consuming the queued audio data? Re: No bclk, LRCK using i2s peripheral on RW612 zephyr Hi Roman,  Thanks for point this out. I've made sure to download the 4.5 version of zephyr which includes  CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT=8 CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS=8 These are also my correct configuration.  My serial monitor  shows that I2S right happens successfully, but the the log eventually stops without outputting any data on the data pin GPIO8 J1.   It looks like the buffer eventually fills up and noting gets freed up by the hardware.  Re: No bclk, LRCK using i2s peripheral on RW612 zephyr Hi @Zakintern, thanks for providing more details. Could you please clarify if you have tried the i2s_output example no modifications done (vanilla)? To follow up on this regard, I'd suggest to first test the base example and then implement your modifications accordingly, since the base example works properly and can serve as reference to know the required API flow to output the data through the hardware. I tested the example and I'm able to see data in the mentioned pin (header J1 terminal 2 from the FRDM board), please make sure to do the measurement in this pin, as GPIO8 is the I2S_WS terminal; GPIO9 is the I2S_DATA terminal. Re: No bclk, LRCK using i2s peripheral on RW612 zephyr The base example does work now, I've managed to get it to work after changing CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT from 8 to 16 in the prj.conf. Thank you for your help, I will use this as a base and implement my modifications.

RW612 Zephyr 芯片上不使用 BCLK，LRCK 使用 I2S 外设。 作为一名学生实习生，我目前正在研究 Zephyr 中的 i2s 示例。我修改了代码，以便可以使用音频放大器和扬声器输出声音。在MCUXpresso配置工具中配置引脚后，我成功地在J1.7上获得了MCLK信号。 在主函数中调用 IO_MUX_SetPinMux ( IO_MUX_MCLK ); 但添加 IO_MUX_SetPinMux ( IO_MUX_FC1_I2S ); 在 J1.15、13 和 9 引脚上没有任何输出。以下是我的代码： /* 版权所有 (c) 2020 Antmicro < www.antmicro.com > * * SPDX 许可证标识符：Apache-2.0 */   #include #include #include #include #include #include "fsl_io_mux.h" #define AUDIO_SAMPLE_FREQ ( 44100 ) #define AUDIO_SAMPLES_PER_CH_PER_FRAME ( 128 ) #define AUDIO_NUM_CHANNELS ( 2 ) #define AUDIO_SAMPLES_PER_FRAME                                                \ （每帧每通道音频采样数*音频通道数） #define AUDIO_SAMPLE_BYTES ( 3 ) #define AUDIO_SAMPLE_BIT_WIDTH ( 24 ) #define AUDIO_FRAME_BUF_BYTES ( AUDIO_SAMPLES_PER_FRAME * AUDIO_SAMPLE_BYTES ) #define I2S_PLAY_BUF_COUNT ( 500 ) #define I2S_DEV_NODE_TX DT_ALIAS (i2s_node0) static const struct 设备 * host_i2s_tx_dev ; static struct k_mem_slab i2s_tx_mem_slab ; static char tx_buffer [ AUDIO_FRAME_BUF_BYTES * I2S_PLAY_BUF_COUNT ]; static struct i2s_config i2s_tx_cfg ; static int ret ; static void init ( void ) {     printk ( "初始化已输入\n " );         //配置发送设备     host_i2s_tx_dev = DEVICE_DT_GET_OR_NULL ( I2S_DEV_NODE_TX );     如果( host_i2s_tx_dev == NULL ) {      printk ( "未找到 I2S TX 设备\n " );      退出（ -1 ） ；    }     如果( ! device_is_ready ( host_i2s_tx_dev )) {         printk ( "I2S TX 设备未就绪\n " );         退出（ -1 ） ；    }     printk ( "I2S TX 设备已准备就绪\n " );     k_mem_slab_init ( & i2s_tx_mem_slab , tx_buffer , AUDIO_FRAME_BUF_BYTES ,             I2S_PLAY_BUF_COUNT );     // 配置 i2s 进行音频播放     i2s_tx_cfg.word_size​​= AUDIO_SAMPLE_BIT_WIDTH ;     i2s_tx_cfg.channels = AUDIO_NUM_CHANNELS ;​​     i2s_tx_cfg.format = I2S_FMT_DATA_FORMAT_I2S ;​​     i2s_tx_cfg.options = I2S_OPT_BIT_CLK_CONTROLLER |​​                          I2S_OPT_FRAME_CLK_CONTROLLER ；     i2s_tx_cfg.frame_clk_freq​​= AUDIO_SAMPLE_FREQ ；     i2s_tx_cfg.block_size​​= AUDIO_FRAME_BUF_BYTES ；     i2s_tx_cfg.mem_slab​​= & i2s_tx_mem_slab ；     i2s_tx_cfg.timeout = -1 ;​​​     ret = i2s_configure ( host_i2s_tx_dev , I2S_DIR_TX , & i2s_tx_cfg );     如果( ret != 0 ) {         printk ( "i2s_configure 失败，错误代码为%d \n " , ret );         退出（ -1 ） ；    }         } int main ( void ) {     printk ( "主程序开始\n " );     IO_MUX_SetPinMux ( IO_MUX_FC1_I2S );     IO_MUX_SetPinMux ( IO_MUX_MCLK );     初始化();             printk ( "初始化完成\n " );     void * tx_mem_block ;     uint32_t phase = 0 ;     const uint32_t tone_freq = 1000 ;     const int32_t amplitude = 0x200000 ; /* 适中的 24 位音量 */     bool started = false ;     while ( true ) {                 ret = k_mem_slab_alloc ( & i2s_tx_mem_slab ,                        & tx_mem_block ，                        K_FOREVER );                         printk ( "缓冲区已分配\n " );         如果( ret != 0 ) {             printk ( "TX 缓冲区分配失败\n " );             继续;      }         uint8_t * buf = tx_mem_block ;         for ( int i = 0 ; i < AUDIO_SAMPLES_PER_CH_PER_FRAME ; i ++ ) {             int32_t样本； /* 生成 1 kHz 方波信号 */             如果（相位< （音频采样频率/ 2 ））{                 样本=振幅； }别的{                 样本= -振幅；        }             phase += tone_freq ;             如果（相位>= AUDIO_SAMPLE_FREQ ）{                 phase -= AUDIO_SAMPLE_FREQ ;        } /* 左声道 - 24 位 */             * buf ++ = sample & 0xFF ;             * buf ++ = ( sample >> 8 ) & 0xFF ;             * buf ++ = ( sample >> 16 ) & 0xFF ; /* 右声道 - 相同信号 */             * buf ++ = sample & 0xFF ;             * buf ++ = ( sample >> 8 ) & 0xFF ;             * buf ++ = ( sample >> 16 ) & 0xFF ;      }         printk ( "在 I2S_WRITE 之前\n " );         ret = i2s_write ( host_i2s_tx_dev ,                 tx_mem_block ，                 AUDIO_FRAME_BUF_BYTES );         printk ( "I2S_WRITE %d后\n " , ret );         如果( ret != 0 ) {             printk ( "i2s_write 失败： %d \n " , ret );             k_mem_slab_free ( & i2s_tx_mem_slab , tx_mem_block );             继续;      } /* 第一个缓冲区数据入队后开始发送 */         如果（ ！开始）{             printk ( "写入之前\n " );             ret = i2s_trigger ( host_i2s_tx_dev ,                       I2S_DIR_TX ，                       I2S_TRIGGER_START );             printk ( "写入%d后\n " , ret );             如果( ret != 0 ) {                 printk ( "I2S 启动失败： %d \n " , ret );                 返回ret ；        }             printk ( "I2S TX 已启动\n " );             started = true ;      }    }     返回0 ； } 我添加了注释，以便找出正在执行的代码部分。我的串口监测显示，打印在几个循环后就停止了。我怀疑是缓冲区在几次循环后被填满导致程序停止运行。 有没有人可以协助我完成这个项目？ 先感谢您 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 为了便于项目开发，请您提供以下信息： Zephyr 版本（请说明是下游仓库还是上游仓库）。 基本的 I2S Zephyr 示例。 请确认您是否正在使用 FRDM-RW612。 设置 Kconfigs（在 prj.conf 文件中） 请分享所使用的叠加层（如有）。 关于您应用的引脚复用设置“IO_MUX_SetPinMux(IO_MUX_FC1_I2S);”，这应该在分配给 flexcomm 实例的 I2S 节点的设备树/覆盖层级别定义。请问您是否已在设备树中定义了 I2S 节点？ 另外，能否请您确认一下，共享示波器捕获的信号是否来自 MCLK 输出引脚？ Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 首先感谢您的回复。 - 版本 4.4.1 上游仓库 - 例如 zephyr/sample s/drivers/i2s/output 与原 i2s/output 示例相比的主要修改： 1. 移除 RX 路径 原项目设计用于接收/发送操作。 RX 相关代码已被移除，因为目标仅为音频播放 (TX)。 2. 将音频格式更改为 24 位 单词长度 = 24 为了匹配预期的 24 位音频输出格式。 3. 波形生成方式的改变 将正弦波替换为 1 kHz 的方波。 4. 更改了缓冲区处理 音频数据不是发送有限数量的缓冲区，而是在 while 循环内持续生成。 目标：提供持续的音频输出。 5. 添加了RW612专用引脚复用配置 新增：IO_MUX_SetPinMux(IO_MUX_FC1_I2S); IO_MUX_SetPinMux(IO_MUX_MCLK); 我正在使用FRDM-RW612 - prj.conf： 配置日志=y CONFIG_I2S=y CONFIG_I2S_LITEX_RX_BLOCK_COUNT=500 CONFIG_I2S_LITEX_DATA_BIG_ENDIAN=n CONFIG_ETH_LITEX_LITEETH=n CONFIG_PRINTK=y 配置控制台=y CONFIG_UART_CONSOLE=y - app.overlay / { 别名 { i2s-node0 = &flexcomm1; }; }; &flexcomm1 { 兼容 = "nxp,lpc-i2s"; pinctrl-0 = <&pinmux_flexcomm1_i2s>; pinctrl-names = "default"; 状态 = "正常"; }; 示波器图像来自 MCLK 输出引脚。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 我测试了 i2s_output 示例的原始版本，它能正确生成 I2S 信号。 请确认 I2S_BCLK、I2S_DATA 和 I2S_WS 的测量值是否取自 FRDM 板的以下接头连接？ I2S_DATA - J1.2 I2S_WS - J1.4 I2S_BCLK - J2.12 另外，我注意到您正在设置以下 LITEX 配置： CONFIG_I2S_LITEX_RX_BLOCK_COUNT=500 CONFIG_I2S_LITEX_DATA_BIG_ENDIAN=n CONFIG_ETH_LITEX_LITEETH=n 这些配置旨在与来自其他供应商的 Litex 硬件配合使用，但可能不适用于您的项目版本，请根据您的应用程序要求，将其替换为如下所示的 Flexcomm 特定配置： CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS 另外，请删除“IO_MUX_SetPinMux(IO_MUX_FC1_I2S);”调用，因为这是设备树描述中配置的。 请告诉我这些信息是否有帮助。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 非常感谢，您的回复让我受益匪浅。 根据您的建议，我做了以下修改： 已添加：CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT=4 移除了LITEX配置。 移除了“IO_MUX_SetPinMux(IO_MUX_FC1_I2S) 我没有添加： 配置 I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS 因为我在 Zephyr 配置树中找不到这个 Kconfig 选项。我查阅了驱动程序源代码，只找到了对以下内容的参考，引用： CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT = 4 关于信号测量，我最初是在以下条件下进行的测量： J1.15、13 和 7，因为在引脚复用器上看到它们配置为 flexcomm1   我重复测量了您指定的引脚，并得到了以下结果： I2S_DATA (J1.2):未观察到信号 I2S_WS（J1.4）：约 51 kHz 方波 I2S_BCLK (J2.12): 约 2.46MHz 方波 目前我可以观察到 MCLK、BCLK 和 WS 信号，但是没有观察到 DATA 引脚上的活动。 请问，缺少 DATA 信号是否意味着传输的音频样本存在问题、I2S 配置存在问题，或者我接下来应该调查其他方面？ Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 嗨@Zakintern ，很高兴得知你取得了进展。 从您上次的日志来看，写入操作似乎是按照您定义的配置“CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT = 4”执行的，该配置将 I2S TX 队列定义为 4 个块，请尝试根据您的应用程序需求调整块数。 另外，配置“CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS”已添加到 Zephyr 主分支，它可能可以在 Zephyr v4.5.0 版本中使用。 请告诉我这是否有帮助。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 经过故障排除，我发现前几次 i2s_write() 调用都能成功返回，但应用程序最终会在内部阻塞： printk ( "在 I2S_WRITE 之前\n " );         ret = i2s_write ( host_i2s_tx_dev ,                 tx_mem_block ，                 AUDIO_FRAME_BUF_BYTES );         printk ( "I2S_WRITE %d后\n " , ret ); 缓冲区似乎正在排队，但最终还是会被填满。硬件可能没有消耗已排队的音频数据？ Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 嗨，罗曼， 谢谢指出这一点。 我已经下载了 Zephyr 的 4.5 版本，其中包含…… CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT = 8 CONFIG_I2S_MCUX_FLEXCOMM_DMA_TX_BLOCKS = 8 这些也是我的正确配置。 我的串口监测显示 I2S 连接成功，但日志最终停止，没有在数据引脚 GPIO8 J1 上输出任何数据。 看起来缓冲区最终会被填满，硬件也无法释放任何空间。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr @Zakintern你好，感谢你提供更多细节。 请问您是否尝试过未做任何修改的 i2s_output 示例（原版）？ 关于这一点，我建议先测试基础示例，然后根据示例进行相应的修改，因为基础示例运行正常，可以作为参考，帮助您了解通过硬件输出数据所需的 API 流程。 我测试了示例，并且能够在所提到的引脚（FRDM 板上的 J1 端子 2）中看到数据，请务必在此引脚上进行测量，因为 GPIO8 是 I2S_WS 端子；GPIO9 是 I2S_DATA 端子。 Re: No bclk, LRCK using i2s peripheral on RW612 zephyr 基础示例现在可以正常运行了。 修改之后，我终于让它运行起来了。 在 prj.conf 中将 CONFIG_I2S_MCUX_FLEXCOMM_TX_BLOCK_COUNT 从 8 改为 16。 谢谢你的帮助，我会以此为基础进行修改。

Request for Review of Dual LAN9646 Ethernet Switch Integration on i.MX95-15x15-FRDM. Hello NXP Team, I have created a device-tree patch (2Xlan9646_imx95_15x15.patch) to integrate two LAN9646 Ethernet switch ICs with ETH1 and ETH2 on my custom i.MX95 15×15 board. Could you please carefully review the patch and verify whether the Ethernet switch integration is correct? Please focus on: LAN9646 configuration, SPI interfaces, chip-selects, reset GPIOs, and interrupt settings. Connections between the two switches and ENETC ports ETH1 and ETH2. Any missing or incorrect properties that could prevent both Ethernet interfaces from working correctly. Please pay particular attention to whether both LAN9646 switches can operate simultaneously and whether their port and PHY configurations are correct. The patch also contains HDMI, audio, LVDS, and other device-tree changes. Please ignore those changes and review only the dual LAN9646 Ethernet integration. Please suggest the necessary corrections and provide a reference device-tree example or documentation if available. Thank you for your support. Re: Request for Review of Dual LAN9646 Ethernet Switch Integration on i.MX95-15x15-FRDM. Hi, Thank you for your interest in NXP Semiconductor products, We don't have LAN9646 Ethernet Switch tested with i.MX 95, so I reviewed the information but can't confirm that it works. 1. It is a good practice to have workable DTS, so I would not comment the Reset and IRQ lines and I would put a default GPIO, is preferred that values are overwritten or kept in other files than leaving an incomplete node. 2. Mapping is swapped in DTS, pinctrl_enetc1 is mapped to LPSPI3 in schematic is seen that ENET1/ETH0 is connected to PHY1 along with LPSPI3, ENET2/ETH1 to PHY2 and LPSPI6. This differs from DTS. 3. I would add a prefix to LAN naming since both switches share their LAN naming properties. That is the review from my side, if you want to further test your DTS, try  dtbs_check . Regards

ARM 2018R1ライセンス用のS32DS こんにちは： 私のARM 2018R1 IDE用のS32DSライセンスが期限切れです。確認して延長してもらえますか? ありがとうございます。 Re: S32DS for ARM 2018R1 license こんにちは、 S32DSのライセンス期間が延長されました。以前のコードを使用してS32DSを再度アクティベートしてください。 Re: S32DS for ARM 2018R1 license ありがとうございました。

S32DS for ARM 2018R1 许可证 您好： 我的 S32DS for ARM 2018R1 IDE 许可证已过期。您能帮我检查并延长一下吗？ 谢谢。 Re: S32DS for ARM 2018R1 license 你好， 您的S32DS许可证已延期，请使用您之前的激活码重新激活S32DS。 Re: S32DS for ARM 2018R1 license 谢谢！！

i.MX93 FRDM: RAW10 capture through ISI writes only one line per frame with IMX219 and IMX708 Hello, We are bringing up MIPI CSI-2 RAW cameras on the FRDM-IMX93 and would appreciate NXP's help. With both an IMX219 and an IMX708, streaming starts and frames are delivered, but only one line of each captured frame contains data. All other lines are zero. On the IMX219 this happens at every resolution we tested. We do not know the cause and would be grateful for your guidance. A similar symptom was reported here on kernel 6.12.20, without a resolution: https://community.nxp.com/t5/i-MX-Graphics/i-MX93-RAW10-capture-issue-only-first-line-valid-IMX219-ISI/m-p/2321729 Environment - Board: FRDM-IMX93 (MACHINE = imx93-11x11-lpddr4x-frdm), camera on the P6 MIPI CSI connector - BSP: imx-6.18.37-2.1.0 from nxp-imx/imx-manifest (meta-imx rel_imx_6.18.37_2.1.0), Yocto 6.0.2 wrynose, DISTRO = fsl-imx-wayland - Kernel: 6.18.37-2.1.0-gddef48f9b907 - Pipeline: sensor -> csidev-4ae00000.csi (dwc-mipi-csi2) -> crossbar -> mxc_isi.0 -> mxc_isi.0.capture (/dev/video0) - Format: SRGGB10_1X10 / RG10, 2 data lanes Sensors 1. Raspberry Pi Camera Module v2 NoIR (IMX219) - In-tree imx219 driver and the unmodified BSP CSI and ISI drivers - Link frequency: 456 MHz 2. Raspberry Pi Camera Module 3 NoIR (IMX708) - Driver ported from the Raspberry Pi kernel (rpi-6.12.y) - Link frequency: 450 MHz - Without further changes, this sensor produces an IPI FIFO overflow and no frames. With sensor register 0x3095 set to 0, frames are delivered at 56 fps at 2304x1296. Results Sensor Resolution Image source Result IMX219 640x480 live image, colour bars frames delivered, only line 0 has data IMX219 1640x1232 colour bars frames delivered, only line 0 has data IMX219 1920x1080 live image, colour bars frames delivered, only line 0 has data IMX219 3280x2464 colour bars frames delivered (14.5 fps), only line 0 has data IMX708 2304x1296 colour bars frames delivered (56 fps), only line 0 has data In each case the buffer has the expected size (width x height x 2 bytes). Line 0 contains the expected data, for example the colour bars. All remaining lines are zero. The IMX219 tests reported no CSI or ISI errors in dmesg. Commands (IMX219, 640x480) media-ctl -V "'imx219 2-0010':0[fmt:SRGGB10_1X10/640x480]" media-ctl -V "'csidev-4ae00000.csi':0[fmt:SRGGB10_1X10/640x480 field:none]" media-ctl -V "'crossbar':0[fmt:SRGGB10_1X10/640x480 field:none]" media-ctl -V "'mxc_isi.0':0[fmt:SRGGB10_1X10/640x480 field:none]" media-ctl -V "'mxc_isi.0':1[fmt:SRGGB10_1X10/640x480 field:none]" v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=RG10 \ --stream-mmap --stream-count=10 --stream-to=/tmp/cap.bin Register values read during streaming (IMX219, 640x480, debug CSI build, same symptom) ISI 0x4ae40000: CHNL_CTRL (0x00) = 0xe0000000 CHNL_IMG_CTRL (0x04) = 0x0f008001 CHNL_IMG_CFG (0x0c) = 0x01e00280 Media mix 0x4ac10000: 0x30 = 0x00010158 0x3c = 0x00000e07 0x40 = 0x00000001 0x44 = 0x00019140 (value between frames) 0x48 = 0x0002291c Questions 1. Is RAW capture from a CSI-2 sensor through the ISI validated on i.MX93? If so, which sensor, BSP version and configuration were used? 2. Are there known issues, errata or required settings that apply to this use case? 3. What should we check next? Please let us know which registers, logs or captures would be useful, and we will provide them. 4. Is a reference device tree or patch available for IMX219 or another RAW sensor on FRDM-IMX93? We can share full logs, the device tree overlay and raw captures on request. Thank you for your support. Linux Yocto Project Re: i.MX93 FRDM: RAW10 capture through ISI writes only one line per frame with IMX219 and IMX708 I sent to you the patch for imx219 already, pls refer to this 

I.MX95 Neutron NPU - ONNX ランタイム EP 現在、Neutron NPU と ONNX ランタイムを使用していますが、量子化された INT8 モデルを実行しようとすると問題が発生します。誰かが指導してくれるかもしれないので、私のワークフローと問題を詳しく共有したいと思います。 実行した手順: QDQ 形式を使用した INT8 へのモデル量子化 私はオリジナルの FP32 ONNX モデルを取得し、QDQ (Quantize-DeQuantize) アプローチを使用して INT8 に量子化を適用しました。 サポートされているすべての演算子が正しく量子化されていることを確認するために、ONNX ツールを使用して量子化モデルを検証しました。 ONNXランタイムの設定 私のシステムには ONNX ランタイム 1.22.0 がインストールされています。 /usr/lib で見つかったライブラリ:   libonnxruntime.so.1 libonnxruntime.so.1.22.0   Neutron NPU 実行プロバイダーに対応する、別の libonnxruntime_neutron.so または類似のものがありませんでした。 Neutron NPUでモデルを実行してみる プロバイダーを ['NeutronExecutionProvider', 'CPUExecutionProvider'] に設定して、Python で InferenceSession を初期化しようとしました。     観察された行動 Neutron EP を指定しているにもかかわらず、ランタイムはすべての操作を CPU に委任します。 NPU アクセラレーションは確認されません。これは、Neutron 実行プロバイダーが利用できないか、ロードされていないことを示しています。 ONNX ランタイムでは、NPU に実行を委任するために特定の Neutron NPU EP (.so) が必要であることを理解しています。 現在のインストールには汎用 ONNX ランタイム ライブラリ (libonnxruntime.so.*) のみが含まれており、Neutron 固有の実行プロバイダーは含まれていません。 NXP SDK と GitHub リポジトリを確認しましたが、事前にビルドされた EP ライブラリが提供されているかどうか、または Neutron サポートを使用して ONNX ランタイムをコンパイルする必要があるかどうかはわかりません。 当社のロードマップと開発計画を明確にするために、NXP は以下の点についてご確認ください。 サポート状況: 将来の BSP リリースで、 i.MX95 プラットフォーム用のNeutron NPU 実行プロバイダー(Neutron EP) に ONNX ランタイム ライブラリを含める公式の計画はありますか? QDQ INT8との互換性: Neutron EP では、そのリリースの一部としてINT8 QDQ 量子化モデルがサポートされますか、それとも既知の制限がありますか? どうぞよろしくお願い致します！！ Re: I.MX95 Neutron NPU - ONNX runtime EP こんにちは@ACasCen 、 NXP サポートにお問い合わせいただきありがとうございます。 弊社の i.MX 機械学習ユーザー ガイドによると、Neutron 用の ONNX ランタイム実行プロバイダ (Neutron EP) はまだ実験的な機能であり、主に CNN タイプのワークロードと一部の量子化 LLM カーネルなど、限られた演算子のサブセットのみをサポートしています。つまり、多くの ONNX モデルは Neutron NPU に完全にオフロードできず、CPU 実行にフォールバックする可能性があります。 このため、Neutron NPU での安定した実行を確保するために、モデルを TensorFlow Lite に変換してから、eIQ ツールキットに含まれる Neutron コンバーターを使用して変換することを強くお勧めします。TFLite モデル、特に量子化された INT8 は、Neutron Delegate を使用して Neutron-S NPU で完全な高速化を実現するための、公式にサポートされ検証されたパスです。 推奨ワークフロー モデルを TFLite (INT8 が望ましい) に変換します。 Neutron コンバーター (eIQ ツールキット) を使用してモデルを実行します。 Neutron Delegate を使用してデプロイします。 --external_delegate_path=/usr/lib/libneutron_delegate.so TFLite/Neutron プロファイリング ツールを使用して、オペレータの互換性とパフォーマンスを確認します。 このアプローチにより、Neutron NPU で最高の信頼性とハードウェア カバレッジが保証されます。 よろしくお願いします、 チャビラ Re: I.MX95 Neutron NPU - ONNX runtime EP @Chaviraさん、サポートしていただき本当にありがとうございます。感謝します!!つまり、現在、ONNX ランタイムを使用するモデルの公式サポートが含まれる予定または推定の BSP リリースはないということですね? ありがとう、よろしく。 アレハンドロ Re: I.MX95 Neutron NPU - ONNX runtime EP こんにちは@ACasCen 、 現時点では、NPU で ONNX モデルをサポートする公式の計画はありません。ただし、eIQ ツールキットには、ONNX モデルを TFLite に変換し、i.MX95 の NPU で実行できるツールが用意されています。 Re: I.MX95 Neutron NPU - ONNX runtime EP タイトル: [FRDM-i.MX95] ONNX Runtime 1.24.3Neutron実行プロバイダ選択時のセグメンテーション・フォルト こんにちは、NXPサポートチームの皆さん、 私はFRDM-i.MX95の開発ボードを使って作業しており、Neutron NPUを使ってONNXモデルを動かそうとしています。 システム情報: ボード: NXP FRDM-i.MX95 BSP: LF6.18.37_2.1.0 カーネル: 6.18.37-2.1.0 ONNXランタイム：1.24.3 建築：AArch64 中性子デバイス: /dev/neutron0 が存在します Neutronファームウェア: NeutronFirmware.elf が存在します 問題： ONNXランタイムはCPU実行プロバイダーと正しく連携します。 しかし、Neutron実行プロバイダを選択すると即座にセグメンテーションの故障を引き起こします。 モデルが提供されていなくても問題が発生します。 再現手順： cd /usr/bin/onnxruntime-1.24.3 ./onnxruntime_perf_test -e neutron 結果: Segmentation fault (core dumped) ONNXモデルもテストしました: ./onnxruntime_perf_test \ -e neutron \ -I \ -m times \ -r 10 \ tests/testdata/matmul_integer_to_float_int8_bias.onnx これにより、同じセグメンテーション違反が発生します。 モデルは-e CPUで正常に動作します。 GDBバックトレース: Program received signal SIGSEGV, Segmentation fault. #0 __GI_strcmp () at ../sysdeps/aarch64/strcmp.S:76 #1 0x0000aaaaaaac58f8 in ?? () #2 0x0000aaaaaaacf468 in ?? () #3 0x0000aaaaaaac056c in ?? () 質問: これは、BSP LF6.18.37_2.1.0 の ONNX Runtime 1.24.3 における既知の問題でしょうか？ Neutron Execution プロバイダはonnxruntime_perf_testとこのBSPで連携することが期待されているのでしょうか? 特定のデバイスツリー、ファームウェア構成、または追加の初期化が必要ですか？ このBSPバージョンのFRDM-i.MX95の検証済みNeutron NPUデモを提供していただけますか? 私たちの目標は、Neutron NPU推論を検証し、その後、ボード上で量子化された言語モデルを実行することです。 再開まで今しばらくお待ちください。

KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or adv Hardware and software Board: KW45B41Z-LOC, board/PCB revision [fill in], manual KW45B41Z-LOCUM Rev. 2 Host: Windows, MCUXpresso IDE 25.6.136, LinkServer 26.9.130, SPSDK 3.12.0 (blhost) SDK: kw45b41z-loc SDK package (version 25.12.0 in the folder name) MCU-Link: onboard, CMSIS-DAP firmware V3.160, later V3.174 Powered from USB (J3) only, no CAN 12 V supply connected Jumpers: defaults per Table 3, JP12 open, JP16 shorted only for ISP. [Confirm actual positions of JP1, JP2, JP3, JP10, JP13, JP14, JP21, JP22, JP25.] Problem SWD debug and flash access to the KW45 fail whenever an application is in flash. Flashing only works when the chip is first held in ISP mode with SW4. What we observed Initial failure (stock kw45b41zloc_wireless_uart_freertos): the probe connects (DAP ID 6BA02477, Cortex-M33, “processor is in secure mode”), then fails with Nn(05) Wire ACK Fault in DAP access and Failed on connect. Erase and program both fail the same way. ISP works: with JP16 shorted and SW4 held during reset, blhost -p COMxx,115200 -- get-property 1 returns Success (K3.1.0), and flash-erase-all returns Success. Without SW4 held, there is no response to ping. After erase, flashing works but ends with an error: flash write completes (“Flash Program Summary”, “Finished writing Flash successfully”). The final step then fails with: Starting execution using system reset and halt target with a stall address ... Wire ACK Fault in DAP access ... Warning - processor did not halt ... flash - system reset failed - Ep(04). Cannot halt processor. This happens with both the stock LOC wireless_uart_freertos and our CAN_BLE project derived from the EVK wireless_uart_bm. Once the app runs, SWD is lost again: typical errors are Ee(42) Could not connect to core, Em(17) Debug port inaccessible after access at location 0x20008838, and Em(12) Target rejected debug access at location 0x20008848. At one point LED1/LED2 were blinking while this happened. J-Link firmware test: we briefly switched MCU-Link to J-Link firmware. SWD then failed even on a blank chip (Wrong DM-AP IDCODE 0x00000000/0xFFFFFFFF, VTref 3.300 V). ISP over the J-Link VCOM port still worked. We reverted to CMSIS-DAP V3.174. NBU: after the erase we sent kw45b41_nbu_ble_hosted.sb3 with blhost ... receive-sb-file (Success). We are not sure it is the correct image for wireless_uart on the LOC board. Current state: after flashing and a replug (JP16 removed, SW4 not held, SW1 pressed): LED1/LED2 do not blink and there is no output on the VCOM port (115200 8N1) the board does not advertise over BLE D3 is dim and D7 is fading (MCU-Link normal mode) Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello @priyanshua1, In order to support you better, could you please provide me the following information? -Before the error occurred, were you following any application note or procedure to configure any security features on the device? -Which image did you flash before the error occurred? -Have any fuses been programmed on this device previously? -I understand that the device is not running the image you flashed. Is my understanding correct? -Could you please perform a mass erase, flash the led_blinky example without making any modifications, and let me know the results? I also suggest migrating to the latest SDK release, as it includes the most recent bug fixes, enhancements, and overall improvements. The latest SDK releases are fully supported by the MCUXpresso extension for Visual Studio Code, which I also strongly recommend considering. Besides supporting the newest SDK versions, the extension provides a modern and optimized development environment with support for open standards such as Zephyr and Matter, along with several other advantages. If you are interested, you can find a summary of its benefits in their Fact Sheet. BR Habib Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello, Please find my responses to your questions below: Before the error occurred, the board was flashed with the Wireless UART and FlexCAN applications. However, no changes were made to the device's security configuration. No fuses have been programmed on the device. Yes, image flashing is currently failing. As suggested, I installed MCUXpresso for VS Code and downloaded the latest KW45-LOC SDK (version 26.09.00). However, I am still encountering the same errors. [2026-10-27T13:03:36.504] [proc] [info] Cmd: C":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [2026-10-27T13:03:36.511] [proc] [info] Cmd: C:\NXP\LinkServer_26.9.130\LinkServer.exe probes --json [2026-10-27T13:03:38.049] [proc] [info] Cmd: C:\Users\Hondaconceptbench\.mcuxpressotools\arm-gnu-toolchain-14.2.rel1-mingw-w64-x86_64-arm-none-eabi\bin\arm-none-eabi-gcc.exe --version [2026-10-27T13:03:38.061] [proc] [info] Cmd: C:\NXP\MCUXpressoIDE_25.6.136\ide\tools\bin\arm-none-eabi-gcc.exe --version [2026-10-27T13:03:38.328] [proc] [info] Cmd: C:\Users\Hondaconceptbench\.mcuxpressotools\arm-gnu-toolchain-14.2.rel1-mingw-w64-x86_64-arm-none-eabi\bin\arm-none-eabi-gcc.exe --version [2026-10-27T13:03:38.337] [proc] [info] Cmd: C:\NXP\MCUXpressoIDE_25.6.136\ide\tools\bin\arm-none-eabi-gcc.exe --version [2026-10-27T13:03:40.870] [proc] [info] Cmd: taskkill /PID 28160 /F /T [2026-10-27T13:03:41.291] [proc] [info] Cmd: pkill -P 28160 [2026-10-27T13:03:41.296] [proc] [error] pkill exited with code Error: spawn pkill ENOENT [2026-10-27T13:03:41.296] [proc] [error] [2026-10-27T13:03:41.296] [error] [2026-10-27T13:03:41.296] [proc] [info] Cmd: kill -9 28160 [2026-10-27T13:03:41.299] [proc] [error] kill exited with code Error: spawn kill ENOENT [2026-10-27T13:03:41.299] [proc] [error] [2026-10-27T13:03:41.300] [proc] [error] kill exited with code -4058 [2026-10-27T13:03:41.300] [proc] [error] [2026-10-27T13:03:41.300] [proc] [error] pkill exited with code -4058 [2026-10-27T13:03:41.300] [proc] [error] [2026-10-27T13:04:19.506] [proc] [info] Cmd: C":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [2026-10-27T13:04:19.513] [proc] [info] Cmd: C:\NXP\LinkServer_26.9.130\LinkServer.exe probes --json [2026-10-27T13:04:20.830] [proc] [info] Cmd: C:\NXP\LinkServer_26.9.130\LinkServer.exe probes --json [2026-10-27T13:04:20.840] [proc] [info] Cmd: C":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [2026-10-27T13:04:21.776] [proc] [info] Cmd: C:\NXP\LinkServer_26.9.130\LinkServer.exe flash --probe WXZBCIEABA3EA --no-boot KW45B41Z83xxxA:KW45B41Z-LOC erase --sector [2026-10-27T13:04:30.403] [proc] [error] C:\NXP\LinkServer_26.9.130\LinkServer.exe exited with code 4294967295 [2026-10-27T13:04:30.403] [proc] [error] Firmware update `check`: not required - forced update can be performed using: `LinkServer probe #1 update forced` Ns: LinkServer RedlinkMulti Driver v26.9 (Sep 18 2026 19:34:33 - crt_emu_cm_redlink.exe build 1382) Pc: (  0) Reading remote configuration Wc(03). No cache support. Nc: Found generic directory XML file in C:\Users\HONDAC~1\AppData\Local\Temp\tmpa5n5cx_7\crt_directory.xml Pc: (  5) Remote configuration complete Nc: Reconnected to existing LinkServer process. Nc: Connecting to probe 1 core 0 (using server started externally) reports:     'Ee(42). Could not connect to core.' Nc: Retrying... Nc: Reconnected to existing LinkServer process. Nc: Server OK but no connection to probe 1 core 0 (after 3 attempts) - Ee(42). Could not connect to core. Wc: ============= SCRIPT: KW45B41_connect.scp ============= Wc: KW45B41 connect script Wc: Connecting to Probe Index = 1 Wc: DpID = 6BA02477 Wc: Error: AP not ready Wc: ============= END SCRIPT ============================== Nc: Probe Firmware: MCU-LINK on-board (r0E3) CMSIS-DAP V3.174 (NXP Semiconductors) Nc: Serial Number:  WXZBCIEABA3EA Nc: VID:PID:  1FC9:0143 Nc: USB Path: 0001:0014:00 Nc: connection failed - Em(01). Cannot find MEM-AP selected by core index (check target power).. Retrying Ed:02: Failed on connect: Em(01). Cannot find MEM-AP selected by core index (check target power) Et: Probe(0😞 Connected&Reset. Was: NotConnected. DpID: 6BA02477. CpuID: 00000000. Info: Nc:   Last stub error 0: OK Nc:   Last sticky error: 0x0 AIndex: 0 Nc:   No debug bus (MemAp) selected Nc:   DAP Speed test unexecuted or failed Nc: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled. Pc: (100) Target Operation Failed -------------------- Flash erase summary: Error: Flash: 0x00000000-0x00100000 (0x00100000 bytes) [KW45B41.cfx] INFO: Exact match for KW45B41Z83xxxA:KW45B41Z-LOC found INFO: Selected device KW45B41Z83xxxA:KW45B41Z-LOC INFO: Selected probe #1 WXZBCIEABA3EA (MCU-LINK on-board (r0E3) CMSIS-DAP V3.174) INFO: MCU-Link firmware update `check`: Probe ([WXZBCIEABA3EA] [MCU-LINK on-board (r0E3) CMSIS-DAP V3.174]) is already running the same firmware version as the included firmware version [3.174] ERROR: Error: Flash: 0x00000000-0x00100000 (0x00100000 bytes) [KW45B41.cfx] ERRMSG: Exception: Flash operation exited with code 1 CRITICAL: Critical error ERRMSG: Exception: Failed to erase one or more flash memories Additional observations: When attempting to erase the memory or scan for NXP devices using the SPSDK components, I need to short the JP16 jumper and keep SW4 pressed for the board to be detected or the erase operation to proceed. Could you please advise on the possible cause of this behavior and suggest the next steps to resolve the issue? PS C:\Users\Hondaconceptbench> blhost -p COM19,115200 -- get-property 1 SpsdkNoDeviceFoundError: Interface 'uart' with parameters 'port=COM19, baudrate=115200, timeout=5000': Device found on port(s) COM19 but did not respond to PING at 115200 baud. Ensure the device is in bootloader mode. See debug log file: C:\Users\Hondaconceptbench\AppData\Local\nxp\spsdk\3.12.0\Logs\debug.log for more info PS C:\Users\Hondaconceptbench> blhost -p COM19,115200 -- get-property 1 Response status = 0 (0x0) Success. Response word 1 = 1258488064 (0x4b030100) Current Version = K3.1.0 PS C:\Users\Hondaconceptbench> blhost -p COM19,115200 -- flash-erase-all SpsdkNoDeviceFoundError: Interface 'uart' with parameters 'port=COM19, baudrate=115200, timeout=5000': Device found on port(s) COM19 but did not respond to PING at 115200 baud. Ensure the device is in bootloader mode. See debug log file: C:\Users\Hondaconceptbench\AppData\Local\nxp\spsdk\3.12.0\Logs\debug.log for more info PS C:\Users\Hondaconceptbench> blhost -p COM19,115200 -- flash-erase-all Response status = 0 (0x0) Success. PS C:\Users\Hondaconceptbench> Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello @priyanshua1, To help determine whether the issue is related to the debug connection, could you please perform the following test using the Secure Provisioning Tool? SPT is a GUI-based application that simplifies the generation and provisioning of bootable images for NXP MCU devices. Could you please test the debugger connection using the Connection With Target Processor feature in SPT by following these steps? Enter ISP mode on the KW45B41Z-LOC board following the same steps you are currently using. Open the Connection with Target Processor window in SPT. Select the appropriate COM port. Click Test and let me know the result. If the Test result is marked as OK, could you please follow the steps mentioned in the Booting plain or CRC image section using the .elf file of a built led bliny project. You can find the .elf file in the debug folder in VS Code.   If you are not familiar with the Secure Provisioning Tool, the SPT User's Guide includes a section on creating a new workspace, which may be helpful for getting started. BR Habib Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or In the first image, I was holding the SW4 when I started the test, and it completed successfully. In the second image, I wasn’t holding the SW4, which caused the test to fail. Here are the results of the two tests. 1. SPT Connection test ISP mode (JP16 shorted, SW4 held during reset), COM19, 115200: Result OK. Mode: ROM bootloader, Life cycle: OEM Open, KW45Z41083 match. Screenshot attached. 2. Boot a plain image I built a Plain unsigned image from the kw45b41zloc_led_blinky project (ELF converted to BIN, bootable image created) and wrote it with SPT “Write image”. The result was Success (get-property, pre-erase and write-memory all succeeded). Log attached. After the write I released SW4, removed JP16, power cycled the board and pressed SW1. The LED does not blink, so the board does not visibly run the application. blhost -p COM19,115200 -- get-property 1 without SW4 held: responds Summary of the issue ISP connection and programming work. The failures happen over SWD with MCUXpresso/LinkServer (“Wire ACK Fault in DAP access”, “Cannot halt processor”, “Debug port inaccessible”) whenever an application is in flash. With the flash erased, SWD connects and flashes, but the final reset-and-halt step fails. Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello @priyanshua1, I noticed that you are currently using the KW45Z41083 processor in your workspace. Is there a specific reason for using this device? For example, are you following the AN14003? The KW47-LOC uses the KW45B41Z processor, as mentioned in Chapter 1.2 "Device Features" of the KW45B41Z-LOC Board User Manual. Could you please create a new workspace using the KW45B41Z processor and repeat the steps mentioned previously? This time, please also erase the entire on-chip Flash before programming the image using the flash programmer tool. After that, could you please provide the following: The logs generated when you write the image. The results of reading the memory region where the image was written using again the Flash Programmer tool. Also, could you please provide me the OTP values from your processor using the OTP/IFR configuration? BR Habib Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello @Habib_MS, Apologies for wrong input. I have performed the test with correct processor now, please note that the connection test failed when I had selected KW45B41Z5 as a processor. But with KW45B41Z8 test connection passed. Please find the attached logs and images for your reference. Write Image Logs: ELF image converted to BIN: source_images\kw45b41zloc_led_blinky.bin ELF image converted to BIN: source_images\kw45b41zloc_led_blinky.bin Status of the operation: Success: A new workspace is created: C:\Users\Hondaconceptbench\secure_provisioning00 ELF image converted to BIN: source_images\kw45b41zloc_led_blinky.bin ########################################################################################################## Build image - operation started at 2026-11-06 16:54:25 ########################################################################################################## Build script is generated: build_image_lnx.sh Build script is generated: build_image_win.bat Build script is generated: build_image_mac.sh Executing script C:\Users\Hondaconceptbench\secure_provisioning00\build_image_win.bat ### SCRIPT: Building image: C:\Users\Hondaconceptbench\secure_provisioning00\build_image_win.bat ### Create Master Boot Image using nxpimage tool ### WARNING:spsdk.image.mbi.mbi:MBI-kw45b41z8-MbiImageTypeEnum.PLAIN_IMAGE-xip(Warning) ======================================== TrustZone Configuration (Warning) ========================================= Validates TrustZone settings and configuration type ==================================================================================================================== Feature 'tz' verification(Warning) Implementation(Warning): Not implemented (1808ms since start, mbi.py:689) Success. (Master Boot Image: C:/Users/Hondaconceptbench/secure_provisioning00/bootable_images/kw45b41zloc_led_blinky.bin created.) ### RESULT of the script `Building image`: Success (return code = [0]SUCCESS) Status of the operation: Success: Building image Built image: "C:\Users\Hondaconceptbench\secure_provisioning00\bootable_images\kw45b41zloc_led_blinky.bin" ########################################################################################################## Write image - operation started at 2026-11-06 16:54:46 ########################################################################################################## The following fuses status was detected: OTP request: LIFECYCLE |= 0x7 (mask: 0xff); current value=0x7; status=MATCHES SUMMARY: Detected status of fuses for write operation: all fuse(s) match with the requested value(s) Write script generated: write_image_lnx.sh Write script generated: write_image_win.bat Write script generated: write_image_mac.sh Executing script C:\Users\Hondaconceptbench\secure_provisioning00\write_image_win.bat pre_erase ### SCRIPT: Writing image: C:\Users\Hondaconceptbench\secure_provisioning00\write_image_win.bat ### SCRIPT arguments: pre_erase ### Parse input arguments ### ### Check connection ### blhost -t 2000 -p COM19,115200 -j -- get-property 1 0 { "command": "get-property", "response": [ 1258488064 ], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded ### Erase flash ### ### Pre erase flash to prevent potential application start after the reset is done ### blhost -t 50081 -p COM19,115200 -j -- flash-erase-region 0x00000000 8192 0 { "command": "flash-erase-region", "response": [], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded blhost -t 50163 -p COM19,115200 -j -- flash-erase-region 0x00000000 16384 0 { "command": "flash-erase-region", "response": [], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded ### Write image ### blhost -t 5000 -p COM19,115200 -j -- write-memory 0x00000000 "C:\Users\Hondaconceptbench\secure_provisioning00\bootable_images\kw45b41zloc_led_blinky.bin" { "command": "write-memory", "response": [ 9732 ], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded ### RESULT of the script `Writing image`: Success (return code = [0]SUCCESS) Status of the operation: Success: Writing image Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello @priyanshua1, Thank you for the information. Based on the logs, it appears that the image was written correctly. Are you able to see the image using the Flash Programmer tool? You can find this tool in the Tools window: Additionally, could you please help me clarify the following points? Did the last steps result in the same behavior? If so, could you please repeat the same steps but using a hello_world example, but this time using the .elf file generated from VS Code?? Are you able to see the "Hello World" in the terminal? Could you please confirm whether the jumpers are configured exactly as shown in figure 3 "KW45B41Z-LOC jumpers" of the KW45B41Z-LOC Board User Manual before performing the test? Could you confirm whether this board has been reworked at any point? If so, could you please provide more details about the rework? BR Habib Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello, Here are the results with the KW45B41Z83 workspace (all in ISP mode: JP16 shorted, SW4 held during reset). Flash Programmer: I erased all, wrote the plain unsigned image, then read 0x00000000-0x000027DF (status: success). The vector table is present (SP 0x2001C000, reset vector 0x00000195 in the read-back). Screenshots attached. Boot result: after releasing SW4, removing JP16 and power cycling, LED1 (PTC0) does not blink. The project’s pin_mux configures PTC0 as a GPIO output for LED1.  hello_world: Repeating the same steps using the .elf, there is no “Hello World” on the MCU-Link VCOM port (115200 8N1). Additionally, from VS Code, GDB reports 0x14816fdc in ?? () and Error 103: Failed to launch GDB: Error finishing flash operation. Terminal output attached.: Launching GDB: "C:\\NXP\\MCUXpressoIDE_25.6.136\\ide\\tools\\bin\\arm-none-eabi-gdb.exe" -q --interpreter=mi2 IMPORTANT: Set "showDevDebugOutput": "raw" in "launch.json" to see all GDB transactions. Launching GDB server: "C:\\NXP\\LinkServer_26.9.130\\LinkServer.exe" -l3 gdbserver "KW45B41Z83xxxA:KW45B41Z-LOC" --probe WXZBCIEABA3EA --gdb-port 2336 --no-boot --core primary Please check TERMINAL tab (GDB server console) for output from "C:\NXP\LinkServer_26.9.130\LinkServer.exe" Output radix now set to decimal 10, hex a, octal 12. Input radix now set to decimal 10, hex a, octal 12. NMI_Handler () at C:/Users/Hondaconceptbench/Documents/MCUXpresso_VSC/SDK_26_09_00_KW45B41Z-LOC/mcuxsdk/devices/Wireless/KW/KW45B41Z83/gcc\startup_KW45B41Z83.S:446 446 ldr r0,=HardFault_Handler Program stopped, probably due to a reset and/or halt issued by the debugger. Error 103: Failed to launch GDB: Error finishing flash operation (from target-download) Jumpers: match Figure 3. MCU-Link firmware:  MCU-LINK on-board (r0E3) CMSIS-DAP V3.174 LOGS when flashing the helloworld.elf using the linkserver flash programmer from vs code. [2026-11-09T15:04:18.756] [proc] [info] Cmd: C:\NXP\LinkServer_26.9.130\LinkServer.exe probes --json [2026-11-09T15:04:18.767] [proc] [info] Cmd: C":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [2026-11-09T15:04:20.075] [proc] [info] Cmd: C":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [2026-11-09T15:04:20.083] [proc] [info] Cmd: C:\NXP\LinkServer_26.9.130\LinkServer.exe probes --json [2026-11-09T15:04:21.857] [proc] [info] Cmd: C:\NXP\LinkServer_26.9.130\LinkServer.exe flash --probe WXZBCIEABA3EA --no-boot KW45B41Z83xxxA:KW45B41Z-LOC load C:\Users\Hondaconceptbench\Documents\MCUXpresso_VSC\SDK_26_09_00_KW45B41Z-LOC\mcuxsdk\examples\demo_apps\hello_world\debug\hello_world.elf --erase-all [2026-11-09T15:04:25.241] [proc] [info] INFO: Exact match for KW45B41Z83xxxA:KW45B41Z-LOC found INFO: Selected device KW45B41Z83xxxA:KW45B41Z-LOC INFO: Selected probe #1 WXZBCIEABA3EA (MCU-LINK on-board (r0E3) CMSIS-DAP V3.174) INFO: MCU-Link firmware update `check`: Probe ([WXZBCIEABA3EA] [MCU-LINK on-board (r0E3) CMSIS-DAP V3.174]) is already running the same firmware version as the included firmware version [3.174] [2026-11-09T15:04:25.241] [LinkServer] [info] LinkServer flash operation completed successfully: Firmware update `check`: not required - forced update can be performed using: `LinkServer probe #1 update forced` Ns: LinkServer RedlinkMulti Driver v26.9 (Sep 18 2026 19:34:33 - crt_emu_cm_redlink.exe build 1382) Pc: (  0) Reading remote configuration Wc(03). No cache support. Nc: Found generic directory XML file in C:\Users\HONDAC~1\AppData\Local\Temp\tmp62t_evtb\crt_directory.xml Pc: (  5) Remote configuration complete Nc: Reconnected to existing LinkServer process. Wc: ============= SCRIPT: KW45B41_connect.scp ============= Wc: KW45B41 connect script Wc: Connecting to Probe Index = 1 Wc: DpID = 6BA02477 Wc: APID = 0x84770001 Wc: ============= END SCRIPT ============================== Nc: Probe Firmware: MCU-LINK on-board (r0E3) CMSIS-DAP V3.174 (NXP Semiconductors) Nc: Serial Number:  WXZBCIEABA3EA Nc: VID:PID:  1FC9:0143 Nc: USB Path: 0001:0016:00 Nc: Using memory from core 0 after searching for a good core Pc: ( 30) Emulator Connected Nc: processor is in secure mode Pc: ( 40) Debug Halt Pc: ( 50) CPU ID Nc: debug interface type      = CoreSight DP (DAP DP ID 6BA02477) over SWD TAP 0 Nc: processor type            = Cortex-M33 (CPU ID 00000D21) on DAP AP 0 Nc: number of h/w breakpoints = 8 Nc: number of flash patches   = 0 Nc: number of h/w watchpoints = 4 Nc: Probe(0😞 Connected&Reset. DpID: 6BA02477. CpuID: 00000D21. Info: Nc: Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled. Ns: Content of CoreSight Debug ROM(s): Nc: RBASE E00FF000: CID B105100D PID 04000BB4C9 ROM (type 0x1) Nc: ROM 1 E000E000: CID B105900D PID 04000BBD21 CSt ARM ARMv8-M type 0x0 Misc - Undefined Nc: ROM 1 E0001000: CID B105900D PID 04000BBD21 CSt ARM DWTv2 type 0x0 Misc - Undefined Nc: ROM 1 E0002000: CID B105900D PID 04000BBD21 CSt ARM FPBv2 type 0x0 Misc - Undefined Nc: ROM 1 E0000000: CID B105900D PID 04000BBD21 CSt ARM ITMv2 type 0x43 Trace Source - Bus Nc: ROM 1 E0042000: CID B105900D PID 04000BBD21 CSt ARM CTIv2 type 0x14 Debug Control - Trigger, e.g. ECT Nc: NXP: KW45B41Z83xxxA Nc: DAP stride is 1024 bytes (256 words) Nc: Inspected v.2 On-chip Flash Memory KW45B41.cfx Nc: Image 'FMU Sep 18 2026 19:14:27' Nc: Opening flash driver KW45B41.cfx Nc: VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Nc: Using SOFT reset to run the flash driver Nc: Flash variant 'FMU 1MB' detected (1MB = 128*8K at 0x0) Nc: Closing flash driver KW45B41.cfx Nc: Inspected v.2 On-chip Flash Memory KW45B41_S.cfx Nc: Image 'FMU (Secure) Sep 18 2026 19:14:02' Nc: Opening flash driver KW45B41_S.cfx Nc: VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Nc: Using SOFT reset to run the flash driver Nc: Flash variant 'FMU 1MB (Secure)' detected (1MB = 128*8K at 0x10000000) Nc: Closing flash driver KW45B41_S.cfx Pc: ( 65) Chip Setup Complete Pc: ( 70) License Check Complete Nt: Loading 'hello_world.elf' ELF 0x00000000 len 0x37F4 Nc: Opening flash driver KW45B41.cfx Nc: VECTRESET requested, but not supported on ARMv8-M CPUs. Using SOFTRESET instead. Nc: Using SOFT reset to run the flash driver Nc: Flash variant 'FMU 1MB' detected (1MB = 128*8K at 0x0) Pb: (  0) Mass erasing Flash Pb: 1 of 1 (  0) Writing sectors 0-1 at 0x00000000 with 14324 bytes Ps: (  0) at 00000000: 0 bytes - 0/14324 Ps: (100) at 00000000: 16384 bytes - 16384/14324 Nc: 00004000 done 100% (16384 out of 14324) Nc: Sectors written: 2, unchanged: 0, total: 2 Nc: Closing flash driver KW45B41.cfx Pb: (100) Finished writing Flash successfully. Nt: Loaded 0x37F4 bytes in 380ms (about 37kB/s) Nt: Reset target (system) Nc: Starting execution using system reset with a stall address Nc: Retask read watchpoint 1 at 0xE000ED08 to use for boot ROM stall Nc: state - running or following reset request - re-read of state failed - rc Nn(05). Wire ACK Fault in DAP access Nc: error closing down debug session - Nn(05). Wire ACK Fault in DAP access Conclusion and Request: We have invested considerable time troubleshooting the KW45B41Z-LOC board, and unfortunately, our project activities are now being delayed due to the unresolved issues with the hardware. Furthermore, our project requirements involve both Angle of Arrival (AoA) and Channel Sounding (CS), which are not fully supported by the KW45 LOC. Despite these limitations, we have continued our efforts to evaluate the board. However, we are currently stuck at a very basic stage, unable to achieve the expected results. Considering the time already spent and the impact on our project schedule, we would like to request NXP to provide a BLE development board with the latest hardware revision as a replacement. This would allow us to resume our development activities without further delays. We are willing to ship the existing KW45B41Z-LOC board back to NXP for further inspection and failure analysis.  We would appreciate your prompt response and support in resolving this matter so that we can get our project activities back on track. Best regards, Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello again @priyanshua1, The KW45-LOC was provided as a reference design for experimentation and prototyping, as the KW45 does not include all the capabilities required to support the full Bluetooth Channel Sounding specification. Additionally, the KW45-LOC is no longer manufactured, as indicated on the NXP product page. As an alternative, you can consider the KW47-LOC, which was designed to demonstrate Bluetooth Channel Sounding for both automotive and IoT applications. The design incorporates two on-board monopole PCB antennas and an RF switch to support antenna diversity. This is possible because the KW47 processor supports Channel Sounding. It also provides several enhancements over the KW45, including increased memory capacity, a dedicated Arm Cortex-M33 radio core running at up to 64 MHz, and support for Bluetooth LE 6.x. If you are interested, you may also refer to AN14796 for additional information about the feature differences and migration considerations between the KW45 and KW47. BR Habib Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello, Thank you for the information. Could you please let us know whether the logs and test results we shared were useful in identifying or analyzing the root cause of the issue on the board? If they provided sufficient insight, we would appreciate your recommendations on the appropriate troubleshooting and recovery steps. If the information was not sufficient, please advise on the additional actions or data required from our side to move the investigation forward. Additionally, I would like to request a sample KW47 board. While the KW45 issue is being resolved, having access to a KW47 board would allow us to continue our development and evaluation activities without further delays. This could also be beneficial for NXP, as we plan to extensively evaluate a broad range of KW47 features, including Channel Sounding (CS), AoA, CAN, BLE, UART, and other relevant functionalities. We would be happy to provide detailed feedback based on our findings and usage experience. We would greatly appreciate your consideration of this request and look forward to your guidance. Thank you for your support. Best regards, Priyanshu Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or Hello @priyanshua1, Since your project requires Channel Sounding, the most recommended path is to focus your development efforts on the KW47-LOC. It was designed specifically for experimenting with Channel Sounding applications like this one. The KW45 supports Bluetooth LE 6.0, but it does not include the capabilities required for Channel Sounding, so for this type of application we strongly recommend migrating to the KW47. I understand how important it is for your team to keep the project moving. The KW47-LOC can be obtained through the official NXP product page, where you can find the available purchasing options. Once you have the board, feel free to post any technical questions that come up during your Channel Sounding evaluation. That said, based on the information, the behavior appears to be related to the device staying in the ROM bootloader instead of jumping to the application in flash. According to the KW45 RM (section 15.2.8, "Initiate a debug session"), the debug access port of the CM33 is disabled while the ROM bootloader is executing, and also when the ROM goes into ISP mode. This would be consistent with what you are seeing, including the PC reported by GDB (0x14816fdc) being inside the ROM address range. To understand why the ROM may not be jumping to the image, I would like to review the ROM configuration stored in the IFR. Could you please send me the IFR values from the Secure Provisioning Tool using the OTP/IFR configuration? I would also like to ask a few additional questions:   Could you please provide more details about the CAN_BLE project you mentioned in your initial post? Also, have you worked with OTAP functionality in that project or in any other application? I could not find the Flash Programmer screenshots you mentioned previously. Could you please confirm whether you are able to see the image using the Flash Programmer tool? Could you confirm whether this board has been reworked at any point? If so, could you please provide more details about the rework? BR Habib

i.MX93 FRDM: ISI を介した RAW10 キャプチャでは、IMX219 および IMX708 ではフレームごとに 1 行しか書き込まれません こんにちは、 FRDM-IMX93上でMIPI CSI-2 RAWカメラを起動させようとしており、NXPのご協力をいただければ幸いです。IMX219とIMX708の両方で、ストリーミングの開始とフレームが配信されますが、キャプチャされるのはそれぞれ1ラインのみです。 フレームにはデータが含まれています。その他の行はすべてゼロです。IMX219では、テストしたすべての解像度でこの現象が発生します。原因が不明なため、ご助言いただければ幸いです。 同様の症状がカーネル6.12.20でも報告されていますが、解決策は見つかっていません。 https://community.nxp.com/t5/i-MX-Graphics/i-MX93-RAW10-capture-issue-only-first-line-valid-IMX219-ISI/mp/2321729 環境 - ボード: FRDM-IMX93 (マシン = imx93-11x11-lpddr4x-frdm)、カメラはP6 MIPI CSIコネクタに接続 - BSP: imx-6.18.37-2.1.0nxp-imx/imx-manifest (meta-imx rel_imx_6.18.37_2.1.0) から、Yocto 6.0.2 wrynose, DISTRO = fsl-imx-wayland - カーネル:6.18.37-2.1.0-gddef48f9b907 - パイプライン:センサ -> csidev-4ae00000.csi (dwc-mipi-csi2) -> クロスバー -> mxc_isi.0-> mxc_isi.0.capture (/dev/video0) - フォーマット: SRGGB10_1X10 / RG10、2データレーン センサ 1. ラズベリーパイカメラモジュールv2 NoIR(IMX219) - インツリーのimx219ドライバおよび修正されていないBSP CSIおよびISIドライバ - リンク周波数:456 MHz 2. ラズベリーパイカメラモジュール3 NoIR(IMX708) - Raspberry Piカーネル(rpi-6.12.y)から移植されたドライバ - リンク周波数:450 MHz - 追加変更なしでは、このセンサはIPI FIFOオーバーフローを生成し、フレームは発生しません。センサーレジスタ0x3095を0に設定すると、フレームは2304x1296で56fpsで配信されます。 結果 センサ解像度画像ソースの結果 IMX219 640x480のライブ画像、カラーバーフレームが配信中、データがあるのはライン0のみです IMX219 1640x1232カラーバーフレームが届きましたが、データがあるのはライン0のみです IMX219 1920x1080 ライブ画像、カラーバーフレームを配信、データがあるのはライン0のみ IMX219 3280x2464カラーバーのフレームは14.5fpsで配信され、データがあるのはライン0のみです IMX708 2304x1296カラーバーのフレームが配信されました(56fps)、データがあるのはライン0のみです 各CASEで、バッファは期待されるサイズ(幅×高さ×2バイト)を持ちます。0行目には、例えばカラーバーなど、期待されるデータが含まれています。残りの行はすべてゼロです。IMX219のテストでは、CSIまたはISIは報告されませんでした。 dmesg にエラーが表示されます。 コマンド(IMX219、640x480) media-ctl -V "'imx219 2-0010':0[fmt:SRGGB10_1X10/640x480]" media-ctl -V "'csidev-4ae00000.csi':0[fmt:SRGGB10_1X10/640x480 field:none]" media-ctl -V "'crossbar':0[fmt:SRGGB10_1X10/640x480 field:none]" media-ctl -V "'mxc_isi.0':0[fmt:SRGGB10_1X10/640x480field:noe]" media-ctl -V "'mxc_isi.0':1[fmt:SRGGB10_1X10/640x480フィールド:なし]" v4l2-ctl -d /dev/video0 --set-fmt-video=width=640,height=480,pixelformat=RG10 \ --stream-mmap --stream-count=10 --stream-to=/tmp/cap.bin ストリーミング中のレジスタ値の読み取り(IMX219、640x480、デバッグCSIビルド、同じ症状) ISI 0x4ae40000: CHNL_CTRL (0x00) = 0xe0000000 CHNL_IMG_CTRL (0x04) = 0x0f008001 CHNL_IMG_CFG (0x0c) = 0x01e00280 メディアミックス0x4ac10000: 0x30 = 0x00010158 0x3c = 0x00000e07 0x40 = 0x00000001 0x44 = 0x00019140(フレーム間の値) 0x48 = 0x0002291c 質問 1.ISIを経由したCSI-2センサからのRAWキャプチャはi.MX93で検証されますか?もしCASEなら、どのセンサ、BSPバージョン、構成が使われましたか? 2. このユースCASEに適用される既知の問題、訂正表、または必須設定はありますか? 3. 次に何を調べるべきか?どのレジスタ、ログ、キャプチャが役立つかをお知らせいただければ、ご提供いたします。 4. FRDM-IMX93上のIMX219や他のRAWセンサの参照デバイスツリーやパッチはありますか? リクエストに応じて、完全なログ、デバイスツリーのオーバーレイ、生のキャプチャも共有可能です。 再開まで今しばらくお待ちください。 Linux Yocto Project Re: i.MX93 FRDM: RAW10 capture through ISI writes only one line per frame with IMX219 and IMX708 imx219用のパッチは既にお送りしましたので、こちらをご参照ください。

NXPS32K388年には、RTD5にEBのtresos PWMチャネルとMCU周波数参照関係が使われています こんにちは、 私はeMIOSチャネルを使ってPWM周波数生成をしています。 すべてのPWMチャネルで同じ周波数(67kHz)出力が必要なため、同じMaster Counter BuS(A)をグローバルリファレンスとして使っています。 すべてのeMIOSチャネルでPWMモードがEMIOS_PWM_IP_MODE_OPWMBとして選択されます。 設定画面のスクリーンショットを添付しました。 私の疑問は、クロックソースに基づいて周波数がどのように計算されるのかということです。 eMIOSはCORE_CLOCK = 160MHzでクロックされています（これはマスターカウンタバスのみに適用されますか）？ PWMチャネルについてはMCUクロック参照(80MHz)を表示していますが、PWMパルスは80MHzクロックに基づいて生成されるのでしょうか? それともSourceクロックとMCUリファレンスクロックは同じように設定されるべきでしょうか? PWMトリガーに使用される周波数を確認してください。     設定オプションに関するスクリーンショットを添付しました。 Re: in NXPS32K388, RTD5 with EB tresos PWM Channel and MCU frequency Reference Relation こんにちは、@Sambasivaさん 80 MHz PwmMcuClockReferencePointは、主にPWM/RTD構成でタイミングやティックを計算するためのソフトウェア/設定参照です。これにより、Bus Aを選択したOPWMBチャネルに対して別の物理的な80 MHzのタイムベースが作成されることはありません。 実際、NXPのRTDリリースノートには、この関係性が明確に記載されています。 彼らは、マスターバスを使用するeMIOSチャネルの場合、周期はMCLマスターバス構成を通じて提供すべきであり、PWMのデフォルト周期はMCU周波数とマスターバス構成で計算すべきだと述べています。 また、PwmMcuClockReferencePointはPWM周波数/ティック計算を決定するために使用されていることも特定されています。 SO、あなたの質問は: 1. eMIOSはCORE_CLOCK = 160MHzでクロックされますが、これはマスターカウンタバスのみに適用されますか？ No. これは、eMIOSモジュールのクロックシステムのアップストリームクロックとして機能します。 バスAは、対応するプリスケーラとともにこれを使用して、カウンタのタイムベースを確立します。 2. PWMチャネルについてはMCUクロック参照(80MHz)を付けていますが、PWMパルスは80MHzクロックに基づいて生成されますか? eMIOS、FlexIO、FlexPWMチャネルでは、「Period In Ticks」を選択していない場合、この参照は秒単位で設定された期間をティックに変換するために使われます。 クロック基準値は実際の最終PWMタイムベースと一致している必要があります。一致していない場合、周期ティックの計算が不正確になります。

MCXA156VLH ADC INTERNAL DIODE RATINGS we require details of ratings of diodes mentioend in Pg:36 - Figure 12. ADC input impedance equivalency diagram. We want to know tolerable rating to design our application accordingly. Analog(ADC|CMP|DAC|OpAmps) Board Design Re: MCXA156VLH ADC INTERNAL DIODE RATINGS Hello @TEMCEFF , Thanks for your post. Please refer to our datasheet: For MCXA156, the DC injection current limit is ±3 mA per I/O pin when VIN goes below VSS − 0.3 V or above VDD + 0.3 V. In addition, the regional injection-current limit for 16 contiguous pins is ±25 mA. If the input voltage can exceed these voltage boundaries, an external current-limiting resistor should be used. Hope it helps. BR Celeste Re: MCXA156VLH ADC INTERNAL DIODE RATINGS Thank you for providing the ADC injection current limits (±3 mA per I/O pin and ±25 mA regional limit). We are designing an analog front-end for the MCXA156 ADC and would like to better understand the behavior and limitations of the internal protection structure shown in the ADC input equivalent circuit (Figure 12 / ADC input impedance equivalency diagram). Specifically, we would appreciate clarification on the following points: Clamp Behavior When an ADC input voltage exceeds VDD_ANA (for example, VDD_ANA = 3.3 V and VIN = 5 V), does the internal protection structure clamp the input voltage? If so, what is the typical voltage at the ADC pin during clamping (for example, approximately VDD_ANA + 0.3 V, VDD_ANA + 0.7 V, etc.)? Clamp Characteristics Is there any characterization data available for: Clamp voltage versus injection current Dynamic resistance of the protection structure Forward voltage of the internal clamp path Overvoltage / Withstand Capability If the injection current is externally limited to less than the specified ±3 mA limit, is there a maximum ADC input voltage that can be tolerated without device damage? For example, can the ADC input safely withstand temporary 5 V, 12 V, or higher transient voltages provided the injection current remains below the specified limit? Transient and Surge Capability Is there any available information regarding: Maximum transient pulse current Maximum transient duration Maximum energy that the internal protection structure can absorb System-Level Protection Recommendation Should the internal protection network be considered only as an ESD/injection-current protection structure, requiring external protection components for repetitive overvoltage conditions? Our goal is to determine the required external protection circuitry and resistor sizing for ADC channels that may be exposed to fault conditions or short-duration overvoltage spikes. Re: MCXA156VLH ADC INTERNAL DIODE RATINGS Hello @TEMCEFF , Thank you for the detailed questions. I checked the available public documentation for the MCXA156. Some of your questions can be answered based on the datasheet, while the detailed characteristics of the internal protection structure will require further confirmation from our internal team. Based on the datasheet: The I/O pins have internal clamping to VSS and VDD through the ESD protection structure. The maximum DC injection current is ±3 mA per pin, with a ±25 mA regional limit for 16 contiguous pins. For positive injection current, the datasheet defines the injection condition as VIN > VDD + 0.3 V. The datasheet provides the following equation for calculating the current-limiting resistor for positive injection:          R = (VIN - VDD_MAX) / IICIOmax For transient voltages, the datasheet recommends using a resistor value approximately one order of magnitude higher than the value calculated from the basic equation. However, VDD + 0.3 V should not be interpreted as a guaranteed or fixed clamp voltage. The public documentation does not provide detailed characterization of the clamp I-V behavior. I also could not find public specifications for the following items: Clamp voltage versus injection current Dynamic resistance or detailed forward-voltage characteristics of the internal clamp Maximum externally applied voltage, such as 5 V, 12 V, or higher, when the injection current is limited below 3 mA Maximum transient pulse current and pulse duration Maximum energy that the internal protection structure can absorb Qualification of the internal clamp for repetitive system-level overvoltage conditions Therefore, I do not want to make assumptions about these limits based only on the injection-current specification. These questions need to be escalated to our internal team for further confirmation. According to our escalation process, could you please provide the following information? End customer name End application name Once we have this information, we can proceed with the escalation.   BR Celeste Re: MCXA156VLH ADC INTERNAL DIODE RATINGS Consider below mentioned details as requested. End customer name - Indian Railways End application name - Intelligent Field device Application description - IoT device to monitor and control Railway assets like Lighting, Escalators, lift etc; Re: MCXA156VLH ADC INTERNAL DIODE RATINGS Hello @TEMCEFF , Thanks for your patience. Please see the reply from our internal: " Although the datasheet specifies ±3 mA per-pin and ±25 mA regional DC injection-current limits, these limits do not override the ADC/I/O input-voltage Absolute Maximum Rating. Therefore, keeping the injection current below 3 mA alone does not guarantee that temporary 5 V, 12 V, or higher inputs are safe. The internal ESD clamp is not characterized in the datasheet with guaranteed clamp voltage, I-V curve, dynamic resistance, or transient pulse/energy capability. Therefore, we do not recommend relying on the internal clamp for repetitive or system-level fault protection. For this application, we recommend external protection, such as a series resistor combined with a suitable low-forward-voltage Schottky clamp, to keep the ADC pin within the specified voltage limits. " If you need any further details, please let me know. BR Celeste