S32K146 送信遅延 こんにちは 当社は、CANFD 通信機能を備えた S32K146 MCU をベースにブートローダ ソフトウェアを開発しています。しかし、私たちを本当に困惑させる問題に遭遇しました。それは、ECU が柔軟な遅延でメッセージを送信し、テストからの要求を受信してから 1 ミリ秒以内に肯定応答を CAN バスに送信することもあれば、遅延が非常に「大きく」、CAN_TP 送信タイマー制限 (As) を超える 224 ミリ秒になることもあります。誰かこの問題を解決するのを手伝ってくれませんか? 当社の ECU に関する情報は以下に示されており、添付の写真も掲載されています。 1. 2 つのメッセージを受信するには 2 MB を使用する必要があります (物理アドレスの ID: 0x714、機能アドレスの ID: 0x7DF)。 2. 1つのメッセージを送信するには1MBを使用する必要があります（ID:0x794） 3. CANFD調停ボーレートは500K/秒、データフィールドボーレートは2MB/秒 4. フレーム DLC は 64 バイトです。 5. ブートローダ ソフトウェアでは、受信または送信に割り込みを使用せず、代わりにポーリング タイプを使用します。 6. 私たちのトランシーバはTLE9263です 7. CANクロックソースはSYS_CLK(80MHZ)です 8. MB を書き込む直前に、Can_write 関数にモニター ポイントを配置します。ロジック アナライザーを使用して、モニター ポイントから CANTx PIN にメッセージが送信されるまでの期間を測定すると、次の結果が得られます。MB を書き込んだ後、CAN Tx PIN に肯定的な応答を送信するには約 223.95 ミリ秒かかります。(添付の画像を参照してください)。 使用されている合計MBはわずか7であり、CANループにはECUとテスター（CANOE VIN1640）以外のノードがないため、この大きな遅延は調停から発生したものではないようです。 私の CAN_init() 関数は以下のように投稿されました: void Can_Init(void) { /** * GPIO * CAN_RX U4_9_CAN0_RX PE4 ALT5 * CAN_TX U4_8_CAN0_TX PE5 ALT5 */ PORTE->PCR[4] = PORT_PCR_MUX(5); PORTE->PCR[5] = PORT_PCR_MUX(5); #CAN_FD == CAN_FD_TYPE_EN の場合 uint32_t i = 0; uint32_t tempECR; uint32_t 待機カウンタ = 0; /* 時計 */ PCC->PCCn[PCC_FlexCAN0_INDEX] |= PCC_PCCn_CGC_MASK; /* CGC=1: FlexCAN0へのクロックを有効にする */ /* できる */ CAN0->MCR |= CAN_MCR_SOFTRST_MASK; CAN0->MCR |= CAN_MCR_MDIS_MASK; /* MDIS=1: クロックを選択する前にモジュールを無効にする */ 待機カウンタ = 0; while(!((CAN0->MCR & CAN_MCR_SOFTRST_MASK) >> CAN_MCR_SOFTRST_SHIFT)) {WaitCounter++;} CAN0->IMASK1 = 0x00000000ul; CAN0->ESR1 &= ~CAN_ESR1_BOFFINT_MASK; CAN0->CTRL1 |= (CAN_CTRL1_CLKSRC(1) /* CLKsrc=1: クロックソース = SYS_CLK (80 MHz) */ |CAN_CTRL1_BOFFMSK(0) /* バスオフ割り込み有効 */ |CAN_CTRL1_BOFFREC(0)); /* バスオフ車載回復を有効にする。*/ CAN0->MCR &= ~CAN_MCR_MDIS_MASK; /* MDIS=0; モジュール構成を有効にします。（FRZ、HALTを設定）*/ CAN0->MCR |= (CAN_MCR_FRZ_MASK | CAN_MCR_HALT_MASK); 待機カウンタ = 0; while(!((CAN0->MCR & CAN_MCR_FRZACK_MASK) >> CAN_MCR_FRZACK_SHIFT)) {WaitCounter++;} /* 良い習慣: フリーズモードの開始/終了時に FRZACK=1 を待つ */ tempECR = CAN0->ECR; CAN0->ECR = 0x00000000UL; tempECR = tempECR; /* 公称位相を設定: 500 KHz ビット時間、80 MHz クロック */ CAN0->CBT = CAN_CBT_BTF(1) /* ビットタイム定義の有効化。*/ |CAN_CBT_EPRESDIV(1) /* EPRESDIV = プリスケーラ + 1 = 2 */ |CAN_CBT_EPSEG2(15) /* EPSEG2 = 15 */ |CAN_CBT_EPSEG1(15) /* EPSEG1 = 15 */ |CAN_CBT_EPROPSEG(46)/* EPROPSEG = 46 */ |CAN_CBT_ERJW(15);/* ERJW = 15 */ /* BITRATEn =Fcanclk /( [(1 + (EPSEG1+1) + (EPSEG2+1) + (EPROPSEG + 1)] x (EPRESSDIV+1)) = 80 MHz /([(1 + ( 15 +1) + ( 15 +1) + ( 46 + 1)] x ( 1 +1)) = 80 MHz / ( [1 + 16 + 16 + 47] x 2) = 80 MHz / (80 x 2) = 500 Kz サンプルポイント = (3 + PSEG1 + PROPSEG) /(4+ PSEG1 + PSEG2 + PROPSEG) (17 + 15 + 46) / (18 + 15 + 15 + 46) = 80% */ /* データ位相を設定: 2 MHz ビット時間、80 MHz クロック */ CAN0->FDCBT = CAN_CBT_EPSEG2(3) /* FPSEG2 = 3 */ |CAN_CBT_EPSEG1(7) /* EPSEG1 = 7 */ |CAN_CBT_EPROPSEG(7) /* FPROPSEG = 7 */ |CAN_CBT_ERJW(3) /* FRJW = 3 */ |CAN_FDCBT_FPRESDIV(1);/* FPRESDIV = プリスケーラ + 1 = 2 */ /* BITRATEf = Fcanclk /( [(1 + (FPSEG1+1) + (FPSEG2+1) + (FPROPSEG)] x (FPRESDIV+1)) = 80 MHz /([(1 + ( 7 +1) + ( 3 +1) + ( 7 )] x ( 1 +1)) = 80 MHz /([1+8+4+7] x 2) = 80 MHz /(20x2) = 80 MHz / 40 = 2 MHz サンプルポイント = (2 + PSEG1 + PROPSEG) /(3 + PSEG1 + PSEG2 + PROPSEG) (4 + 7 + 7) / (5 + 7 + 3 + 7) = 80% */ CAN0->FDCTRL = CAN_FDCTRL_FDRATE(1) /* BRS=1: フレームのヘッダーでビットレートスイッチを有効にし、ビットレートスイッチ、データサイズ、トランシーバ遅延を設定します */ |CAN_FDCTRL_MBDSR0(3) /* MBDSR0=3: 領域0にはフレームのペイロードに64バイトのデータ（7Mb）があります */ |CAN_FDCTRL_TDCEN(1) /* MBDSR1: 該当なし */ |CAN_FDCTRL_TDCOFF(31); /* トランシーバ遅延補正オフセット15 */ /* PRIO = 0: CANFD が使用され、ISO CAN FD の CRC 修正が有効になります */ CAN0->CTRL2 |= CAN_CTRL2_TASD(30) | CAN_CTRL2_ISOCANFDEN(1); /* TDCEN=1: トランシーバ遅延補正を有効にする */ /* TDCOFF=5: 5 CANクロック（300us）のオフセットを使用 */ for(i = 0; i < 128u; i++) { /* CAN0: FlexCAN 0の128ワードのRAMをクリアする メッセージ バッファの単語をクリアします。すべてのバッファ CODE=0 (非アクティブ) */ CAN0->RAMn[i] = 0; } for(i=0; i < 16u; i++ ) { /* FRZ モードでは、CAN0 16 msg buf フィルターを初期化します 受信メッセージのすべてのIDビットをチェックする*/ CAN0->RXIMR[i] = 0x1ffffffful; } /* グローバル受け入れマスク: すべてのIDビットをチェック */ CAN0->RXMGMASK = 0xFFFFFFFFul; CAN0->RX14MASK = 0xFFFFFFFFul; CAN0->RX15MASK = 0xFFFFFFFFul; /* メッセージバッファ 0 - 受信セットアップ: */ /* メッセージバッファ 0、ワード 0: 受信を有効にする */ /* EDL = 1: CAN FDの拡張データ長 */ /* BRS = 1: ビットレートスイッチが有効 */ /* ESI = 0: エラー状態 */ /* CODE = 4: MBをRX非アクティブに設定 */ /* IDE = 0: 標準ID */ /* SRR、RTR、TIME STAMP = 0: 該当なし */ CAN0->RAMn[0 * CAN_MSG_BUF_SIZE + 0] = CAN_RAMn_EDL(1) + CAN_RAMn_BRS(1) + CAN_RAMn_ESI(0) + CAN_RAMn_CODE(CAN_MSG_BUF_RX_EMPTY) + CAN_RAMn_IDE(0) + CAN_RAMn_SRR(0) + CAN_RAMn_RTR(0); CAN0->RAMn[0 * CAN_MSG_BUF_SIZE + 1] = ((uint32_t)ID_REQUEST_PHY) << 18u; // CAN0->RXIMR[0] = (((uint32_t)(~(ID_REQUEST_PHY ^ ID_REQUEST_FUN))) << 18u) & 0x1ffffffful; CAN0->RXIMR[0] = 0x1ffffffful; CAN0->RAMn[1 * CAN_MSG_BUF_SIZE + 0] = CAN_RAMn_EDL(1) + CAN_RAMn_BRS(1) + CAN_RAMn_ESI(0) + CAN_RAMn_CODE(CAN_MSG_BUF_RX_EMPTY) + CAN_RAMn_IDE(0) + CAN_RAMn_SRR(0) + CAN_RAMn_RTR(0); CAN0->RAMn[1 * CAN_MSG_BUF_SIZE + 1] = ((uint32_t)ID_REQUEST_FUN) << 18u; CAN0->RXIMR[1] = 0x1ffffffful; CAN0->MCR = 0x00030806ul; /* FlexCAN 0 停止状態を否定し、7 MB 間 CAN FD を有効にする */ gs_CanControllerStatus[0] = CAN_STATUS_IDLE; 待機カウンタ = 0; while ((CAN0->MCR & CAN_MCR_FRZACK_MASK) >> CAN_MCR_FRZACK_SHIFT){WaitCounter++;} /* 良い方法: FRZACK がクリアされるまで待つ (フリーズモードではない) */ 待機カウンタ = 0; while ((CAN0->MCR & CAN_MCR_NOTRDY_MASK) >> CAN_MCR_NOTRDY_SHIFT){WaitCounter++;} } そして、私のCan_write()関数は以下のように投稿されました: bl_Error_t Can_Write(bl_CanHandle_t ハンドル、const bl_Buffer_t *バッファ、bl_Size_t サイズ) { #CAN_FD == CAN_FD_TYPE_EN の場合 bl_Error_t ret = BL_ERR_NOT_OK; uint32_t Can_ID = 0x0; uint8_t 送信ハンドル = 0; uint8_t dlc; CAN_message_t msg_tx; dlc = Can__SizeToDlc(サイズ); if (ハンドル > CAN_TXHANDLE_NUM) { ret を返します。 } Tx_handle = g_CanTxHandleCfg[ハンドル].コントローラ; (gs_CanControllerStatus[Tx_handle] != CAN_STATUS_IDLE) の場合 { ret = BL_ERR_CAN_BUSY; ret を返します。 } Can_ID = g_CanTxHandleCfg[ハンドル].id<< 18; する { (uint8_t i = 0; i < CAN_MAX_NUMBER_OF_CONTROLLER; i++) の場合 { gs_CanControllerCfg[i].usage == CAN_CONTROLLER_UNUSED の場合 { 続く; } if ( (Tx_handle == gs_CanControllerCfg[i].phyId) && (CAN_STATUS_IDLE == gs_CanControllerStatus[i])) { msg_tx.id = Can_ID; Can__CopyData(msg_tx.data.bytes,buffer,size); msg_tx.length = dlc; TLE9261_Write(0x40, 0x5F);/*これは私がここに置いたソフトウェアモニターポイントです*/ S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 17] = SWAP_UINT32(msg_tx.data.longs[15]);//((uint32_t)バッファ[60])<< 24 | ((uint32_t)バッファ[61]) << 16 | ((uint32_t)バッファ[62]) << 8 | ((uint32_t)バッファ[63]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 16] = SWAP_UINT32(msg_tx.data.longs[14]);//((uint32_t)バッファ[56])<< 24 | ((uint32_t)バッファ[57]) << 16 | ((uint32_t)バッファ[58]) << 8 | ((uint32_t)バッファ[59]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 15] = SWAP_UINT32(msg_tx.data.longs[13]);//((uint32_t)バッファ[52])<< 24 | ((uint32_t)バッファ[53]) << 16 | ((uint32_t)バッファ[53]) << 8 | ((uint32_t)バッファ[55]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 14] = SWAP_UINT32(msg_tx.data.longs[12]);//((uint32_t)バッファ[48])<< 24 | ((uint32_t)バッファ[49]) << 16 | ((uint32_t)バッファ[50]) << 8 | ((uint32_t)バッファ[51]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 13] = SWAP_UINT32(msg_tx.data.longs[11]);//((uint32_t)バッファ[44])<< 24 | ((uint32_t)バッファ[45]) << 16 | ((uint32_t)バッファ[46]) << 8 | ((uint32_t)バッファ[47]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 12] = SWAP_UINT32(msg_tx.data.longs[10]);//((uint32_t)バッファ[40])<< 24 | ((uint32_t)バッファ[41]) << 16 | ((uint32_t)バッファ[42]) << 8 | ((uint32_t)バッファ[43]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 11] = SWAP_UINT32(msg_tx.data.longs[9]);//((uint32_t)バッファ[36])<< 24 | ((uint32_t)バッファ[37]) << 16 | ((uint32_t)バッファ[38]) << 8 | ((uint32_t)バッファ[39]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 10] = SWAP_UINT32(msg_tx.data.longs[8]);//((uint32_t)バッファ[32])<< 24 | ((uint32_t)バッファ[33]) << 16 | ((uint32_t)バッファ[34]) << 8 | ((uint32_t)バッファ[35]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 9] = SWAP_UINT32(msg_tx.data.longs[7]);//((uint32_t)バッファ[28])<< 24 | ((uint32_t)バッファ[29]) << 16 | ((uint32_t)バッファ[30]) << 8 | ((uint32_t)バッファ[31]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 8] = SWAP_UINT32(msg_tx.data.longs[6]);//((uint32_t)バッファ[24])<< 24 | ((uint32_t)バッファ[25]) << 16 | ((uint32_t)バッファ[26]) << 8 | ((uint32_t)バッファ[27]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 7] = SWAP_UINT32(msg_tx.data.longs[5]);//((uint32_t)バッファ[20])<< 24 | ((uint32_t)バッファ[21]) << 16 | ((uint32_t)バッファ[22]) << 8 | ((uint32_t)バッファ[23]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 6] = SWAP_UINT32(msg_tx.data.longs[4]);//((uint32_t)バッファ[16])<< 24 | ((uint32_t)バッファ[17]) << 16 | ((uint32_t)バッファ[18]) << 8 | ((uint32_t)バッファ[19]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 5] = SWAP_UINT32(msg_tx.data.longs[3]);//((uint32_t)バッファ[12])<< 24 | ((uint32_t)バッファ[13]) << 16 | ((uint32_t)バッファ[14]) << 8 | ((uint32_t)バッファ[15]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 4] = SWAP_UINT32(msg_tx.data.longs[2]);//((uint32_t)バッファ[8])<< 24 | ((uint32_t)バッファ[9]) << 16 | ((uint32_t)バッファ[10]) << 8 | ((uint32_t)バッファ[11]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 3] = SWAP_UINT32(msg_tx.data.longs[1]);//((uint32_t)バッファ[4])<< 24 | ((uint32_t)バッファ[5]) << 16 | ((uint32_t)バッファ[6]) << 8 | ((uint32_t)バッファ[7]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 2] = SWAP_UINT32(msg_tx.data.longs[0]);//((uint32_t)バッファ[0])<< 24 | ((uint32_t)バッファ[1]) << 16 | ((uint32_t)バッファ[2]) << 8 | ((uint32_t)バッファ[3]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 1] = Can_ID; /* MB8ワード1: 指定されたIDの送信メッセージ */ S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 0] = CAN_RAMn_EDL(1) /* EDL=1 CAN FDフォーマットフレーム*/ |CAN_RAMn_BRS(1) /* BRS=1: ビットレートはメッセージ内で切り替えられます */ |CAN_RAMn_ESI(0) /* ESI=0: ??? */ |CAN_RAMn_CODE(CAN_TX_MB_CODE_TRANS) /* CODE=0xC: 送信するためにメッセージバッファをアクティブにする */ |CAN_RAMn_SRR(0) /* SRR=1 送信フレーム（標準IDには必要ありません）*/ |CAN_RAMn_IDE(0) /* IDE=0: 標準ID */ |CAN_RAMn_RTR(0) /* RTR = 0: データ、リモート送信要求フレームではない*/ |CAN_RAMn_DLC(dlc); /* DLC=x; 1,2,3,4,5,6,7,8, 9-12,10-16, 11-20, 12-24, 13-32, 14-48, 15-64バイト */ // while (!(S32K_CAN(Tx_handle).IFLAG1 & 0x100)) {}; /* CAN 0 MB 8 フラグを待つ */ // S32K_CAN(Tx_handle).IFLAG1 = 0x00000100; /* CAN 0 MB 8フラグをクリアするが、他のフラグはクリアしない*/ gs_CanControllerStatus[i] = CAN_STATUS_TRANSMITTING; ret = BL_ERR_OK; } } } while(0); ret を返します。 } Re: Re S32K146 Transmit Delay こんにちは、 正確な設定と使用されているコードがわからないため、この動作の原因を正確に説明することはできません。仲裁は停止されるか、何らかの理由で保留中になっているようです。たとえば、仲裁が MB 全体をスキャンする前に、任意の MB CS ワードに書き込むことが考えられます。 調停プロセスは MB をスキャンし、次の機会に送信するメッセージを保持している送信 MB を検索します。スキャンは最も小さい数値の MB から始まり、より大きな数値へと続きます。MB0 が送信に使用される場合、この MB に書き込むと、調停プロセスが開始され、すぐに勝者が見つかります。 BR、ペトル Re: Re S32K146 Transmit Delay こんにちは、ペトルス MB シーケンスを調整してみましたが、正常に送信できました。しかし、なぜ問題ないのかという深いロジックがまだ理解できません。私の方法を簡単に説明しましょう: 受信または送信に使用する MB インデックスを調整します。つまり、元々 MB0 は物理アドレス診断メッセージ (ID:0x714) を受信するために使用され、MB1 は機能アドレス診断メッセージ (ID:0x7DF) を受信するために使用され、MB6 は ECU 応答メッセージ (ID:0x794) を送信するために使用されます。 新しいものは、MB0 は ECU 応答メッセージ (ID:0x794) の送信に使用され、MB1 は物理アドレス診断メッセージ (ID:0x714) の受信に使用され、MB2 は機能アドレス診断メッセージ (ID:0x7DF) の受信に使用されます。 この調整後、ECU は正常に受信または送信できるようになります。SO、MB6がflexCAN0内での調停に勝てないため、ECUがメッセージをSMBに移動しないということでしょうか？送信するメッセージは1つしかないので、MB6と調停する他のMBはないようです。 また、新しい送信を開始する必要があるときに MB がまだ送信中の場合は、MB を中止しようとします。 よろしくお願いします。 Re: Re S32K146 Transmit Delay こんにちは、 何らかの理由で、MB が書き込まれた後、仲裁が開始されないか終了せず、メッセージが TX SMB に移動されないようです。バスはアイドル状態なので、通常通り実行されるはずです。 その後、別のメッセージが受信されると、CRC 部分で新しい仲裁が開始され、勝者 (単一の TX MB から) が選択され、SMB に移動されます。ようやく最初の機会に送信されました。 しかし、「新しい受信リクエストが、最後のリクエストへの応答の送信をトリガーしました。」という図は、送信MBが実際に正常に送信される前に更新されていることを示しています。MBの転送/可用性のチェックが適切に行われていれば、監視ポイント1に到達することはありません。 他に何を提案すればよいか分かりません。システムとモジュールのクロックを確認してください。コードを確認して、前回の転送が完了した時点でTXが書き込まれていることを確認してください。コード内でMBの無効化/中止を行っていますか？ BR、ペトル Re S32K146 Transmit Delay こんにちは ご返信SOありがとうございます。ここで引用した最初の質問にお答えしたいと思います。「SO MeasurementStartPoint,jpg から、0x714 メッセージが受信され、約 150us 後に 0x5FC0 が SPI SOUT に送信されていますが、このフレームはコードで使用される TLE9261_Write(0x40,0x5F) と同等ですか?」 はい、コードで使用されるTLE9261_Write(0x40,0x5F)と同等です。 測定停止ポイントについては、コードに別の 2 つの TLE9261_Write(0x40,0x5F) 関数を導入しました。これらは、「モニター ポイント」という名前の添付画像で確認できます。また、ここにコードも投稿します。 bl_Error_t Can_Write(bl_CanHandle_t ハンドル、const bl_Buffer_t *バッファ、bl_Size_t サイズ) { bl_Error_t ret = BL_ERR_NOT_OK; uint32_t Can_ID = 0x0; uint8_t 送信ハンドル = 0; uint8_t dlc; CAN_message_t msg_tx; dlc = Can__SizeToDlc(サイズ); if (ハンドル > CAN_TXHANDLE_NUM)     { ret を返します。    } Tx_handle = g_CanTxHandleCfg[ハンドル].コントローラ; (gs_CanControllerStatus[Tx_handle] != CAN_STATUS_IDLE) の場合     { ret = BL_ERR_CAN_BUSY; ret を返します。    } Can_ID = g_CanTxHandleCfg[ハンドル].id<< 18; する     { (uint8_t i = 0; i < CAN_MAX_NUMBER_OF_CONTROLLER; i++) の場合 { gs_CanControllerCfg[i].usage == CAN_CONTROLLER_UNUSED の場合 { 続く;        } if ( (Tx_handle == gs_CanControllerCfg[i].phyId) && (CAN_STATUS_IDLE == gs_CanControllerStatus[i])) { msg_tx.id = Can_ID; Can__CopyData(msg_tx.data.bytes,buffer,size); msg_tx.length = dlc; TLE9261_Write(0x40, 0x5F);/*モニターポイント1*/ S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 17] = SWAP_UINT32(msg_tx.data.longs[15]);//((uint32_t)バッファ[60])<< 24 | ((uint32_t)バッファ[61]) << 16 | ((uint32_t)バッファ[62]) << 8 | ((uint32_t)バッファ[63]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 16] = SWAP_UINT32(msg_tx.data.longs[14]);//((uint32_t)バッファ[56])<< 24 | ((uint32_t)バッファ[57]) << 16 | ((uint32_t)バッファ[58]) << 8 | ((uint32_t)バッファ[59]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 15] = SWAP_UINT32(msg_tx.data.longs[13]);//((uint32_t)バッファ[52])<< 24 | ((uint32_t)バッファ[53]) << 16 | ((uint32_t)バッファ[53]) << 8 | ((uint32_t)バッファ[55]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 14] = SWAP_UINT32(msg_tx.data.longs[12]);//((uint32_t)バッファ[48])<< 24 | ((uint32_t)バッファ[49]) << 16 | ((uint32_t)バッファ[50]) << 8 | ((uint32_t)バッファ[51]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 13] = SWAP_UINT32(msg_tx.data.longs[11]);//((uint32_t)バッファ[44])<< 24 | ((uint32_t)バッファ[45]) << 16 | ((uint32_t)バッファ[46]) << 8 | ((uint32_t)バッファ[47]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 12] = SWAP_UINT32(msg_tx.data.longs[10]);//((uint32_t)バッファ[40])<< 24 | ((uint32_t)バッファ[41]) << 16 | ((uint32_t)バッファ[42]) << 8 | ((uint32_t)バッファ[43]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 11] = SWAP_UINT32(msg_tx.data.longs[9]);//((uint32_t)バッファ[36])<< 24 | ((uint32_t)バッファ[37]) << 16 | ((uint32_t)バッファ[38]) << 8 | ((uint32_t)バッファ[39]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 10] = SWAP_UINT32(msg_tx.data.longs[8]);//((uint32_t)バッファ[32])<< 24 | ((uint32_t)バッファ[33]) << 16 | ((uint32_t)バッファ[34]) << 8 | ((uint32_t)バッファ[35]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 9] = SWAP_UINT32(msg_tx.data.longs[7]);//((uint32_t)バッファ[28])<< 24 | ((uint32_t)バッファ[29]) << 16 | ((uint32_t)バッファ[30]) << 8 | ((uint32_t)バッファ[31]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 8] = SWAP_UINT32(msg_tx.data.longs[6]);//((uint32_t)バッファ[24])<< 24 | ((uint32_t)バッファ[25]) << 16 | ((uint32_t)バッファ[26]) << 8 | ((uint32_t)バッファ[27]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 7] = SWAP_UINT32(msg_tx.data.longs[5]);//((uint32_t)バッファ[20])<< 24 | ((uint32_t)バッファ[21]) << 16 | ((uint32_t)バッファ[22]) << 8 | ((uint32_t)バッファ[23]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 6] = SWAP_UINT32(msg_tx.data.longs[4]);//((uint32_t)バッファ[16])<< 24 | ((uint32_t)バッファ[17]) << 16 | ((uint32_t)バッファ[18]) << 8 | ((uint32_t)バッファ[19]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 5] = SWAP_UINT32(msg_tx.data.longs[3]);//((uint32_t)バッファ[12])<< 24 | ((uint32_t)バッファ[13]) << 16 | ((uint32_t)バッファ[14]) << 8 | ((uint32_t)バッファ[15]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 4] = SWAP_UINT32(msg_tx.data.longs[2]);//((uint32_t)バッファ[8])<< 24 | ((uint32_t)バッファ[9]) << 16 | ((uint32_t)バッファ[10]) << 8 | ((uint32_t)バッファ[11]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 3] = SWAP_UINT32(msg_tx.data.longs[1]);//((uint32_t)バッファ[4])<< 24 | ((uint32_t)バッファ[5]) << 16 | ((uint32_t)バッファ[6]) << 8 | ((uint32_t)バッファ[7]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 2] = SWAP_UINT32(msg_tx.data.longs[0]);//((uint32_t)バッファ[0])<< 24 | ((uint32_t)バッファ[1]) << 16 | ((uint32_t)バッファ[2]) << 8 | ((uint32_t)バッファ[3]); S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 1] = Can_ID; /* MB8ワード1: 指定されたIDの送信メッセージ */ TLE9261_Write(0x40, 0x5F);/*モニターポイント2*/ S32K_CAN(Tx_handle).RAMn[CAN_USED_HRH_NUM*CAN_MSG_BUF_SIZE + 0] = CAN_RAMn_EDL(1) /* EDL=1 CAN FDフォーマットフレーム*/ |CAN_RAMn_BRS(1) /* BRS=1: ビットレートはメッセージ内でスイッチされます */ |CAN_RAMn_ESI(0) /* ESI=0: ??? */ |CAN_RAMn_CODE(CAN_TX_MB_CODE_TRANS) /* CODE=0xC: 送信するためにメッセージバッファをアクティブにする */ |CAN_RAMn_SRR(0) /* SRR=1 送信フレーム（標準IDには必要ありません）*/ |CAN_RAMn_IDE(0) /* IDE=0: 標準ID */ |CAN_RAMn_RTR(0) /* RTR = 0: データ、リモート送信要求フレームではない*/ |CAN_RAMn_DLC(dlc); /* DLC=x; 1,2,3,4,5,6,7,8, 9-12,10-16, 11-20, 12-24, 13-32, 14-48, 15-64バイト */ TLE9261_Write(0x40, 0x5F);/*モニターポイント3*/ // while (!(S32K_CAN(Tx_handle).IFLAG1 & 0x100)) {}; /* CAN 0 MB 8 フラグを待つ */ // S32K_CAN(Tx_handle).IFLAG1 = 0x00000100; /* CAN 0 MB 8フラグをクリアするが、他のフラグはクリアしない*/ gs_CanControllerStatus[i] = CAN_STATUS_TRANSMITTING; ret = BL_ERR_OK;        }      } } while(0); ret を返します。 } 最初の監視ポイントは MB の ID を設定する前に配置され、2 番目の監視コードは MB のコードを 0xC(送信) に更新する直前に配置され、3 番目の監視ポイントは送信する MB のコード更新直後に配置されます。 コードをデバッグすると、以下に説明する 2 つの現象が見つかりました。 1. まず、DID を読み取るために診断要求サービスを送信し、バス上で 0x22 F1 87 をテスト送信しましたが、ECU は応答しません。添付の「要求を受信したが応答がない」という画像から、ECU が実際に要求メッセージを受信し、応答を送信して MB を更新しようとしていることがわかります (このスナップショットでは監視ポイント 1、2、および 3 がキャプチャされています)。ただし、CAN Tx PIN では応答メッセージが監視されていません。 2. 次に、ESR1、IFALG1、および RAM レジスタを監視し、送信 MB のコードが 0xC (送信) に正常に更新され、CAN バスがアイドル状態であり、ESR1 レジスタに他のエラーがないことを確認します。ただし、メッセージは CANTx で送信されませんでした。flexCAN0 が送信を開始する準備ができていないため、メッセージが SMB でスタックしているようです。 3. 3 番目に、別の診断要求を送信しようとして、0x10 01 サービスを送信すると、ECU はすぐに 0x62 F1 87 で応答します。添付の「新しく受信した要求によって、最後の要求の応答の送信がトリガーされました。」という画像で確認できます。メッセージは、モニター ポイント 1、2、3 のコードが実行される前に送信されました。SO、新たな要求メッセージが ECU をトリガーして、最後の要求の応答を送信するようです!!! これはSO不合理に思えます。 この問題を解決するには、皆様のご親切なサポートが本当に必要です。よろしくお願いします。 Re: S32K146 Transmit Delay こんにちは、 したがって、MeasurementStartPoint,jpg から、0x714 メッセージが受信され、約 150us 後に 0x5FC0 が SPI SO に送信されていることがわかります。このフレームは、コードで使用される TLE9261_Write(0x40,0x5F) と同等ですか? TX メッセージが送信されるときに停止時間にズーム機能はありますか? 通常の応答（1 ミリ秒以内）のスクリーンショットを取得できますか? CANメッセージ間の周期的（30us）SPI転送とは何ですか？コードではどのように処理されますか？ TLE9261_Write(0x40,0x5F) と MB6 CS ワード書き込みの間のコードが中断されないことをテストする場合は、その前後の割り込みを無効/有効にするだけです。 BR、ペトル Re: S32K146 Transmit Delay こんにちは、PetrS ご丁寧なご返信SOありがとうございます。まず最初にいくつかの点を明確にさせてください。 1.TDCOFF については、RF マニュアルを参照し、お客様の CAN 仕様で定義されているパラメータを使用して計算しているので、ここでは問題ないと思います。 2. 私のコードでは、MB0 は物理アドレス ID (0x714) メッセージの受信に使用され、MB1 は関数アドレス ID (0x7DF) メッセージの受信に使用されます。MB2 ～ MB5 は予約済みで、MB6 は送信に使用されます。S32K146 Flex CAN0 にはペイロード 64 バイトのメッセージ用に 7 MB がある。SO、私のコード内の CAN_USED_HRH_NUM は 6 です。 3. バスの仲裁については、おっしゃる意味は理解しています。写真から一部のスナップショットが抜けてしまっていることをお詫びします。こちらに追加しましたので、添付ファイルをご参照ください。私のテスト ベンチには ECU という 1 つのノードだけがあり、テスター (Vector CANOE VIN1640) を除いて ECU と調停する他のノードはありません。フラッシュが終了した後に ECU を起動するために、100 ミリ秒周期で NM メッセージを送信します。SO、私の観点からすると、この遅延はバスの調停によるものではないはずです。 4. 遅延が発生する場所を捕捉するために、コードにモニター ポイント TLE9261_Write (返信でも言及されています) を追加しました。こうすることで、TLE9261_Write() の呼び出しによってトリガーされる SPI 信号をキャプチャできます。これは、ロジック アナライザ プロジェクトの測定開始ポイントの名前です。つまり、このポイントはメッセージの送信直前です (送信 MB にデータを書き込むと、MB の CS コードも更新されます)。また、CANRx および CANTx PIN のデータも測定します。こうすることで、TLE9261_Write() を呼び出してからメッセージが CAN Tx PIN に送信されるまでの遅延が約 223 ミリ秒であることがわかります。それは本当に長いですね。測定結果は添付ファイルでCANます。 5. SO、返信で述べられているように、遅延は TLE9261_Write と CAN_USED_HRH_NUM MB CS ワード書き込み間のコードから発生すると考えられます。しかし、ブートローダ コードで使用した割り込みは、時間をカウントするために使用するシステム ティックと、いくつかの障害シナリオに対処するために使用するハードフォールトのみです。これによってSO大きな遅延が発生することはないと思います。 SO、これらの情報をもう一度確認して、遅延の原因を突き止めるのにご協力いただけますか? SOありがとう。 Re: S32K146 Transmit Delay こんにちは、 CAN init は正常に見えます。2Mbit では TDC はまったく必要ありません。とにかく、TDCOFF は適切に構成されているように見えます。デフォルトの TASD 値を維持することもCANますが、違いは期待できません。 説明によると、送信には単一のMBのみが使用されていますが、コードではCAN_USED_HRH_NUM（値？）となっています。このメッセージバッファのCSワードが書き込まれると、MBは調停プロセスへの参加を開始し、勝者として選択されてTX SMBに移動され、バス上で実際に送信される最初の機会を待ちます。ここで、バス上にIDが低い他のメッセージがある場合、バス調停によって遅延が発生する可能性があります。他のノードがコネクテッドされていないにもかかわらず、RXメッセージの1つがより高い調停値（IDが低い）を持っていることを確認してください。 遅延のもう一つの原因は、コード自体にある可能性があります。TLE9261_WriteとCAN_USED_HRH_NUM MB CSワード書き込みの間に何らかのコードがあります。他のコードやタスクによって中断されないことを確認し、SOここにソフトウェア遅延を追加してはいかがでしょうか？ また、送信中にエラーが検出されると実際の送信が遅れますが、バス/CAN ツールで間違ったメッセージやエラー メッセージが表示されることがあります。 BR、ペトル

关于 K5 HAL 演示版安装的问题 你好，团队 请问 S32K5 HAL 演示如何？ 我按照下面的步骤进行了操作。 之后，我导入了 HAL 演示项目。 我双击了 MEX 文件，更新了代码。 结果如下。 我的问题是 我没有在 DS 项目中找到启动程序，"src "文件夹中也没有（没有找到 main.c）。 Q1.你知道原因吗？ Q2.在 HAL 演示版中，它不支持 S32DS 版本。这样做对吗？ 谢谢。 S32DS 来源：恩智浦内部来源：恩智浦内部 Re: Question about K5 HAL demo install Hi Cuong 我自己找到了解决办法。 ^^ 谢谢 Re: Question about K5 HAL demo install @Luke_Chun 是的，您可以在这里发布问题。 我的意思是，这些标签可以帮助相关团队过滤请求，并根据其范围提供支持。 Re: Question about K5 HAL demo install 你好， 我不确定，我的问题是否可以得到这个社区的支持。 因此，我也向产品社区提出了同样的问题。 谢谢。 Re: Question about K5 HAL demo install 此演示不是 RTD 代码包，移除 RTD 标签

使用 LCD 针座时相机针座上的可用引脚 - FRDM-MCXN947 我想弄明白，在使用 smartdma 的 LCD-PAR-S035 显示器上使用 LCD 接头（J8）时，相机接头（J9）上的引脚是否可以用作 GPIO？ 在配置工具中，它们并不显示为冲突，但当设置为 GPIO 时，我似乎仍无法正确读取。 有人能确认（J9）引脚不能同时用作 GPIO 吗？ 谢谢   开发板 FRDM 培训 MCX N Re: Available pins on the camera header when using LCD header - FRDM-MCXN947 你好@cyberhelmer、 谢谢您的帖子。 我认为您可以参考 frdm-mcxn947 的用户手册。它列出了 FlexIO 和相机标头的所有潜在冲突。 从技术上讲，J9 上的引脚可以配置为 GPIO。 但是，如果 SmartDMA 正在积极使用 FlexIO for LCD，并且 J9 引脚与 FlexIO 或其他有源外设共享，则由于总线争用或引脚多路复用器冲突，GPIO 读取可能会失败。 我建议您检查项目配置中的引脚复用器，确保 J9 引脚没有同时分配给 FlexIO、CAN、I3C 或以太网。如果需要，还可检查和调整焊接跳线。您可以暂时禁用 SmartDMA，并测试从 J9 读取的 GPIO 数据，以确认它们能独立工作。 希望对你有所帮助。 BR 西莱斯特

S32G3 PFE fci デモ のソース コードはどこで入手できますか?ドキュメントから直接コードをコピーしようとしましたが、一部のヘッダー ファイルが欠落しているためコンパイルできません。 pmboat_0-1761214545300.png   Re: S32G3 PFE fci demo こんにちは、 @pmboat 投稿ありがとうございます。 詳細については、 https://github.com/nxp-auto-linux/pfeng/tree/release/linux_1.9.0/sw/libfci_cliのサンプルを参照することをお勧めします。 BR チェイン

Cortex-A 实时操作系统和 Cortex-M 实时操作系统之间的 RPMSG？ 您好， ，我正在开发 FRDM-imx93，我想知道是否有可能在 Cortex-A 实时操作系统和 Cortex-M 实时操作系统之间创建 RPMSG？ 文档中没有 .REALTIMEEDGEUG.pdf 示例：REALTIMEEDGEUG.pdf 我们只有这个 3.4.3.1.2构建并运行 RPMSG 演示（Cortex-A 和 Cortex-M 内核） 但是，它使用的是 Linux 而不是 RTOS。 此致， Re: RPMSG between Cortex-A RTOS and Cortex-M RTOS ? 您好， 非常感谢。 谢谢、 Re: RPMSG between Cortex-A RTOS and Cortex-M RTOS ? 你好 正如您在实时边缘软件中看到的，可用选项有 Screenshot 2025-10-28 115319.png 这是可能的，但遗憾的是，我们没有实例可以提供。 顺祝商祺！ 

S32K1: LPUART BAUDレジスタのOSRビットがスタックしています こんにちは。 ターゲット MCU は、S32K14W-Q064 評価ボード上の S32K144W です。LPUART0 ボー レートを設定しているのですが、BAUD レジスタの下位 4 つの OSR ビットをクリアできないことに気付きました。これらのビットはリセット時にデフォルトで 1 に設定されますが、その後は書き込み/クリア可能になるはずです。上位の OSR ビットを設定またはクリアCANますが、下位 4 ビットは固定され、常に設定されており、そのレジスタに対するいかなる操作でもクリアできません。 ネタバレ （ハイライトして読む） Screenshot_RM_BAUD_OSR.png 明らかに、これにより UART の機能が制限され、適切なボー レートの選択が難しくなります。ドキュメントを何度も精査しましたが、これらのビットに対する制限や、それらをクリアまたは変更するために満たさなければならない条件についての言及は見つかりませんでした。たぶん見逃したのでしょう。 他のフォーラム投稿 2 件を見つけましたが、そこではユーザーが同じ問題 (ただし、別の部分) について言及していました。 "SO、OSR フィールド (15 と 31) に設定できるのは 16 と 32 の値のみで、他の値を設定すると 16/32 になることに気づきました。" 残念ながら解決策は見当たりません。 https://community.nxp.com/t5/Kinetis-Microcontrollers/FRDM-K82F-uart-problem/mp/845950 https://community.nxp.com/t5/Kinetis-Microcontrollers/LPUART0-baudrate/mp/792047/highlight/true#M48190 これらのビットが詰まっている理由や、変更方法について何かご意見はありますか? ご協力いただきありがとうございます！ トレバー Re: S32K1: LPUART BAUD register OSR bits stuck こんにちは、トレバーさん。 情報をいただきありがとうございます。 OSRビットを個別にクリアできないことにはこれまで気付いていませんでしたが、RTD のBAUDレジスタへの書き込みも一度に行われることがわかりました。 よろしくお願いいたします ロビン Re: S32K1: LPUART BAUD register OSR bits stuck こんにちは、ロビン。 私は S32K1 RTD を使用していません。UART を LPUART レジスタで直接構成しています。 明確に言うと、最初に OSR ビットと SBR ビットをクリアし (LPUART_BAUD_OSR_MASK と LPUART_BAUD_SBR_MASK を使用)、次に必要なビットを設定して (LPUART_BAUD_OSR(x) と LPUART_BAUD_SBR(x) を使用)、必要なボー レートを取得しようとしていました。重要なのは、OSR ビットをすべてクリアすると、オーバーサンプリング比が 16 になり、下位 4 ビットが設定されたデフォルトと同じになることです。リファレンスマニュアルにはこのように書かれていますが、OSR ビットをクリアすると何が起こるのかは十分に説明されていないようです。 Screenshot_RM_OSR.png 私が理解できなかったのは、OSR ビットをすべてクリアすると、ハードウェアはそれをオーバーサンプリング比 16 を使用していると解釈するのではなく、下位 4 ビットを文字通り 1 に戻し、デフォルト設定に戻すということです。SO、最初にそれらのビットをマスクしてクリアし、次に必要なビットを設定するという一般的なパターンは使用できません。代わりに、すべてのビット グループで必要な値を使用して、BAUD レジスタを一度に設定する必要があります。 SO、これを変更することで: IP_LPUART0->BAUD &= ~( LPUART_BAUD_OSR_MASK ); IP_LPUART0->BAUD |= ( LPUART_BAUD_OSR(10u) ); ... これに対して: IP_LPUART0->BAUD = ( LPUART_BAUD_OSR(10u) | ... ); 期待通りに動作しているようです。 ご協力ありがとうございました。 よろしくお願いいたします。 トレバー Re: S32K1: LPUART BAUD register OSR bits stuck ハイ BAUD[BOTHEDGE]を設定しましたか?S32K1 RTD を使用している場合は、以下を参照して設定する必要があります。 BAUD[OSR][BOTHEDGE] Lpuart_Uart_Ip_SetUp_Baudrate RTD.png よろしくお願いします、 ロビン --------------------------------------------------------------------------------- 注記： - この投稿があなたの質問への回答である場合は、「解決策として承認」ボタンをクリックしてください。ありがとう！ - Threadは最後の投稿から7週間フォローされます。それ以降の返信は無視されます。 後ほど関連する質問がある場合は、新しいThreadを開いて、閉じたThreadを参照してください。 ---------------------------------------------------------------------------------

リセット後、s32k312は異常なHardFault_Handlerに入ります 使用されるチップは s32k312 で、コンパイラのバージョンは S32DS3.5 と RTD3.0 です。uds-boot の生成中に、いくつかの有効な情報がアドレス 0x0043E000 の pflash に固定されます。 sensen_1_0-1762236756459.png sensen_1_1-1762236817623.png sensen_1_2-1762236843789.png sensen_1_3-1762236858994.png ブートローダーをチップにプログラムし、ホストコンピューター経由でアプリ プログラムをフラッシュします。最初のフラッシュ後、内部ウォッチドッグ タイムアウト リセットを使用して、プログラムがアプリに正しく入力されることを確認CAN。ただし、アプリ内でプログラムが実行されているときに別のアプリのフラッシュ操作が実行されると、プログラムはリセット後に HardFault_Handler に入ります。設定に問題があるかどうか、または標準的な設定方法があるかどうかの確認にご協力ください。情報が p_flash に固定されず、後続の命令を通じて 0x0043E000 に書き込まれる限り、プログラムは正常にCAN実行します。 どうぞよろしくお願いいたします。 Re: After resetting, the s32k312 enters the HardFault_Handler abnormally RTD ドライバを使用していますか? INFLS MCAL ドライバには、コードを SRAM に再配置できる機能が含まれています。 danielmartynek_0-1762249915732.png C40_Ip ドライバを使用する場合は、次の例を参照してください。 https://community.nxp.com/t5/S32K-Knowledge-Base/S32K312-C40-Ip-SRAM-RTD-500-DS35/ta-p/2074245 よろしくお願いいたします。 ダニエル Re: After resetting, the s32k312 enters the HardFault_Handler abnormally これらのコードは実際には同じブロック 0 領域、具体的には s32k312 のブロック 0 領域に格納されており、有効アドレスは 0x00400000 から 0x00500000 の範囲です。ただし、これらが修正されず、後でプログラム内の p_flash プログラミング操作を通じて書き込まれる場合、HardFault_Handler は表示されません。次のような感じです。 sensen_1_0-1762248268141.png Re: After resetting, the s32k312 enters the HardFault_Handler abnormally こんにちは@sensen_1さん、 これは、フラッシュ ブロックでの RWW (Read-While-Write) 衝突が原因であると考えられます。 実行されるコードは、現在プログラム中のフラッシュ ブロック内に存在してはなりません。 これが問題かどうかCAN確認できますか? よろしくお願いいたします。 ダニエル

i.MX95 Neutron NPU における推論の劣化 NXPテクニカルサポートチーム様 現在、ResNetをバックボーンとしてポーズ推定モデルを開発しており、i.MX95プラットフォームをベースにした製品への展開を検討しています。 しかし、Neutron NPU で量子化モデルを実行すると、推論精度が大幅に低下します。調査の結果、標準的な分類モデルであっても、CPU 上で正しく実行される量子化モデルは、NPU 実行用に変換すると結果が劣化することが明らかになりました。この問題は、私たちがバックボーンとして使用している ResNet にも影響します。 部分的なNPU割り当てテストを通じて Neutron-converterでは、特定のConv2Dレイヤー以外のレイヤーをNPUに割り当てると劣化が発生することを確認しました。 以下の点についてご意見をお聞かせいただければ幸いです。 推論性能の低下の原因は何でしょうか? たとえば、量子化または変換パラメータの問題、NPU のハードウェア制限、または Neutron コンバータのバグ。 この問題に関連する既知の問題はありますか? たとえば、BSP 6.12.20 や eIQ Toolkit 1.16.0 のバグなど、NPU 上で ResNet モデルを実行する場合の既知の制限、または i.MX95 NPU に関するその他の文書化された問題。 この問題を緩和するためにどのような対策を講じるCANますか? 開発環境 ハードウェア: i.MX95 EVK BSPバージョン: 6.12.20_2.0.0(NXP) eIQ ツールキット: 1.16.0 (Windows) モデル変換パイプライン PyTorch → ONNX : トーチ.onnx （オプセットバージョン15） ONNX → TensorFlow (.pb) : PINTO0309/onnx2tf INT8量子化: tensorflow.lite.TFLiteコンバータ （バージョン2.12.0） NPU変換: Neutronコンバータ （バージョン 2.0.2+0X0cebb80a） 推論結果 NPU で実行すると、推論の精度が大幅に低下します。 我々は量子化モデルを用いてテストした。 モバイルネットV2 そして ResNet18 （から トーチビジョンを使用して ImageNetV2 (500 サンプル) : モデル float32 CPU 精度 (トップ 1 / トップ 5) int8 CPU 精度 (トップ 1 / トップ 5) int8 NPU 精度 (トップ 1 / トップ 5) モバイルネットV2 70.2% / 89.4% 68.4% / 88.6% 0.2% / 0.8% ResNet18 64.0% / 86.6% 63.6% / 87.4% 0.0% / 0.6% 追加テスト 部分的なNPU割り当てテストを、 --include演算子 オプション Neutronコンバータ 量子化された ResNet18 モデル上。 特定の Conv2D レイヤー以外のレイヤーを NPU に割り当てると、推論のパフォーマンスが低下することがわかりました。 ケース NPU割り当て 結果 精度トップ1 / トップ5 ベースライン なし（すべてCPU） ー(ベースライン) 63.6 / 87.4 % CASE 1 即日 悪い 0.0 / 0.6 % CASE 2 入出力形状が[1×56×56×64]であるConv2Dレイヤー 良い 64.0 / 87.4 % CASE3 CASE 2 + レイヤーの追加 悪い 0.0 / 0.6 % 事例４ CASE 2 + その他のConv2Dレイヤー 悪い 0.0 / 0.8 % サポートしていただき誠にありがとうございます。 よろしくお願いします、 涼介 Re: Inference Degradation on i.MX95 Neutron NPU こんにちは、 i.MX95 はまだ試作段階であるため、サポートを提供することはできませんのでご了承ください。詳細については、お近くの NXP セールス/NXP FAE にお問い合わせください。 よろしくお願いいたします。 アルド。

T2080 CPUのCCSRBARを変更する方法 親愛なる友人の皆様 私は T2080 CPU を使用し、vxworks が提供するブートローダーを使用しています。 次のブートローダー設定で正常に起動しています。 - フラッシュ1: 0xFF00_0000~0xFFFF_FFFF (16MB) - ブートローダー: 0xFFF0_0000~ 0xFFFF_FFFF (1MB、ブートROM) - CCSBAR: 0xFE00_0000~ 0xFEFF_FFFF (16MB、デフォルトアドレス) 私のボードには Flash1 のサイズがより多くあります。SO、Flash1 を再マップしようとしています。 ただし、次の設定では起動に失敗します。 - フラッシュ1: 0xFE00_0000~0xFFFF_FFFF (48MB) - ブートローダー: 0xFFF0_0000~ 0xFFFF_FFFF (1MB、ブートROM) - CCSBAR: 0xFE00_0000~ 0xFEFF_FFFF (16MB) この問題は CCSBAR の重複によって発生したものと思われます。 ただし、CCSBAR を 0xFD00_0000 に設定した後でも、ブートは失敗します。 CCSBAR を変更する方法を教えてください。 （T2080 RM 4.3.11に記載されていますしかし、それが何を意味するのかは分かりません。 Re: How to change CCSRBAR in T2080 CPU はい、スタートコードで再配置できるようです。以下のソースを参照できるかもしれません。 https://github.com/nxp-qoriq/u-boot/blob/f3363c060497515ca8b71451cb56f3ec0abacaa9/arch/powerpc/cpu/mpc85xx/start.S#L505 Re: How to change CCSRBAR in T2080 CPU June_Lu様 NXP コミュニティ フォーラムを見ると、以前誰かが私と同じ問題を解決したことがわかります。タイトルと日付は以下の通りです。 * T2080 プロセッサにおける CCSRBAR 再配置の問題。karnakaranradh 著、2017 年 1 月 31 日。 返信ではU-bootのソースコードが以下のように参照されている。 * フリースケール PowerPC u-boot ツリー ただし、参照にアクセスできません。 参照にアクセスする方法はありますか? Re: How to change CCSRBAR in T2080 CPU 申し訳ありませんが、公式コードは SDK2.0 であり、 CCSRBAR を変更するような例はありません。 CCSR は多数のレジスタに影響するため、そのアドレスを変更する場合は、関連するすべてのソース コードがこの変更を反映するように適切に更新されていることを確認してください。 Re: How to change CCSRBAR in T2080 CPU まずは追加のご返信ありがとうございます。 ブートローダーは CCSR (0xFE00_0000 -> 0xFD00_0000) を変更していますが、ブートプロセスが機能していないため、CCSR レジスタにアクセスできるかどうかを確認できません。 CCSR 構成には、VXWorks7 (windriver 製) が提供する「vxbl-1.0.4.1」を使用します。 CCSRBAR=0xFE00_0000 の場合、ブート プロセスは正常です。ただし、CCSRBAR が 0xFD00_0000 に設定されている場合、ブート プロセスは機能しません。 CCSRBAR はフラッシュ領域と重なってはいけませんよね? CCSRBAR を変更するための例や公開されているコードはありますか?(VXBLと比較する必要があります。) Re: How to change CCSRBAR in T2080 CPU CCSR はどこに設定しますか。T2080 RMのルール、177 ページのガイドラインに従っていますか。 法律が変更された後、CCSR レジスタにアクセスできますか?CCSR レジスタ アクセスも変更する必要があるようです。RM 表 2-5 を参照してください。 Re: How to change CCSRBAR in T2080 CPU ご返信ありがとうございます。 ただし、変更されたフラッシュ サイズに合わせて、ブートローダー内の TLB と LAW のサイズを既に変更しています。 Re: How to change CCSRBAR in T2080 CPU QorIQ ® SDK 2.0-1703 ドキュメント では 、LAW を使用して特定のアドレスを設定します。 以下のリンクは法律に関連している可能性がありますので、参照していただければ幸いです。 https://github.com/nxp-qoriq/u-boot/blob/f3363c060497515ca8b71451cb56f3ec0abacaa9/board/freescale/t208xrdb/law.c#L10 https://github.com/nxp-qoriq/u-boot/blob/f3363c060497515ca8b71451cb56f3ec0abacaa9/arch/powerpc/include/asm/fsl_law.h よろしくお願いします。

CAN FD 8Mbps 評価ボードS32K3X4EVB-T172では、 CAN FD伝送速度を4Mbpsから5Mbpsまたは8Mbpsに上げると、データ位相波形の出力が停止します。この問題を解決する方法についてアドバイスを頂きたいです。 データ転送は 500 kbps ～ 4 Mbps の範囲で正常に動作しています。 調停フェーズは 1 Mbps、ペイロードは 64 バイトです。 Re: CAN FD 8Mbps ご返答ありがとうございます。CANトランシーバを 8Mbps をサポートするものに交換して、もう一度試してみます。 Re: CAN FD 8Mbps こんにちは@ Tomato1 TJA1443 は S32K3X4EVB-T172 で使用されており、TJA1443 では速度が制限されていることがわかります。 これが 8Mbps CAN 正常に実行できない理由である可能性があります。 2025-11-17_9-54-19.png

S32DS3.5 更新中的 DDR 训练失败14 你好，专家 客户报告 DDR 培训在 S32DS3.5 更新14 中失败，但该系统之前正常运行，硬件也没有重大变化。 PHY Init 似乎只有 50% 左右的时间能通过，而 Diag Write 和 Operational 测试则有 100% 的时间不能通过。 我已经检查了客户填写的设备信息，没有发现错误。 请查看所附的截图/日志，并就可能出现的问题提出建议。 S32_CONFIG_TOOL S32DS

出力電圧閾値と電源電流の関係 こんにちは、 VDD = 3.3V の範囲に供給される電流に基づいて、S32K1xx シリーズの論理デジタル出力しきい値を知る必要があります。 表 17 - データシート (S32K-DS) をすでに参照しましたが、特定の電流 (VDD = 3.3V に対して 3mA ～ 3.5mA) に対してのみ指定されており、図 8 - AN2434 でも VDD = 5V に対してのみ指定されています。 Re: Output voltaje thersholds versus Source Current こんにちは、デビッド： S32K1 には VOL と VOH のしきい値データがありますか?ソース/シンク電流に依存する場合は?VOL_max は、MOS トランジスタの抵抗 * シンク最大電流の式で CAN 計算できますか?このデータは入手CANますか？ Re: Output voltaje thersholds versus Source Current どのように定義されるか（つまり定義された電圧での最小電流)は基本的に最悪のCASEです。 弊社が提供するIBISモデルもご利用いただけます。 Re: Output voltaje thersholds versus Source Current こんにちは。サポートありがとうございます。 見積もりとしては妥当なようです。しかし、これは「最悪のCASEの分析」ではありません（私の場合はそうです）。 それはしきい値を取得するための唯一の理論的な方法ですか? そんなデータはないのでしょうか？ Re: Output voltaje thersholds versus Source Current 指定された Voh/Vol は、ソース/シンク電流が指定どおり Ioh/Iol である場合の最小/最大値です。 ロジック 1 (出力) の VI 特性は、ポイント と <0mA; VDD> 間の線形近似によって推定できます。同じ方法で、ロジック 0 の VI 特性を推定CAN。

SW32K3_TCPIP_STACK_1_0_3 インストールに失敗しました S32DS：V3.5 測温抵抗体：V3.0.0 S32K314 を使用していますが、TCPIP プラグイン パッケージをインストールしてもサンプルを作成できません。 SW32K3_TCPIP_STACK_1_0_3_HF1_Release_Note.pdf のインストール手順に従ってください。 S32K314 を使用していますが、TCPIP プラグイン パッケージをインストールした後、サンプルを作成できません。 shunyizhang_1-1704876580503.png shunyizhang_0-1704876557991.png shunyizhang_2-1704876608538.png Re: SW32K3_TCPIP_STACK_1_0_3 Installation failed こんにちは@sw_maさん、 Flexeraポータルを通じてRTD 3.0.0をCANS32K396 をサポートする P07: https://nxp.flexnetoperations.com/control/frse/download?element=14273227 。 ダウンロードしてインストールCANか確認してください。 Snag_161a3fa8.png   Snag_161a65ae.png よろしくお願いします、 ジュリアン Re: SW32K3_TCPIP_STACK_1_0_3 Installation failed こんにちは、@Julián_AragónM ガイドのPDF参照を使って試してみましたが、まだ3.0.0が見つかりませんk396 に必要な ver RTD。 https://nxp.flexnetoperations.com/control/frse/product?child_plneID=830617 Re: SW32K3_TCPIP_STACK_1_0_3 Installation failed こんにちは@sw_maさん、 オートモーティブ ソフトウェア Package Manager に問題があるようですが、代わりに flexera ポータルから RTD パッケージをダウンロードしてみてはいかがでしょうか?この返信に添付されているガイドに従ってください。 よろしくお願いします、 ジュリアン Re: SW32K3_TCPIP_STACK_1_0_3 Installation failed ありがとう。でも、下記を見つけました sw_ma_0-1761903011027.png 回复： SW32K3_TCPIP_STACK_1_0_3 Installation failed こんにちは@sw_maさん、 「対応する K396 ソフトウェアが利用できない」とはどういう意味ですか?RTD 3.0.0 は、Flexera ポータルまたは オートモーティブ ソフトウェア パッケージ マネージャ を通じて引き続き入手可能です。ここからアクセスできます:リアルタイム・ドライバ (RTD)。 よろしくお願いします、 ジュリアン 回复： SW32K3_TCPIP_STACK_1_0_3 Installation failed 私のコンピューターでも同じ問題が発生していますが、対応する K396 ソフトウェア をダウンロードできなくなりました (公式 Web サイトでは入手できません)。これを解決するにはどうすればよいですか? 失敗のコメントは以下にあります 1 つ以上の必須項目が見つからなかったため、インストールを完了できません。 インストール中のソフトウェア: TCPIP_STACK S32K3 1.0.3.202306190957(com.nxp.TCPIP_STACK.S32K3.root.1.0.3.feature.feature.group 1.0.3.202306190957) 不足している要件: TCPIP_STACK S32K3 1.0.3.202306190957(com.nxp.TCPIP_STACK.S32K3.root.1.0.3.feature.feature.グループ 1.0.3.202306190957)'org.eclipse.equinox.p2.iu; com.nxp.RTD.S32K396.root.feature.feature.group 0.0.0' が必要ですが、見つかりませんでした Re: SW32K3_TCPIP_STACK_1_0_3 Installation failed 問題は解決しました。S32K396 関連のプラグインがインストールされていないことが原因のはずです。 Re: SW32K3_TCPIP_STACK_1_0_3 Installation failed こんにちは@shunyizhangさん このコミュニティ投稿の指示に従ってください: 解決済み: Re: tcpip 1.0.3 をインストールできません - NXPコミュニティ また、「 SW32K3_TCPIP_1_0_3_D2306_updatesite.zip」をダウンロードしていること、および RTD および FreeRTOS パッケージがインストールされていることを確認してください。 インストール後のログのスクリーンショットも提供していただけますか？エラーメッセージはありますか？ よろしくお願いします、 ジュリアン Re: SW32K3_TCPIP_STACK_1_0_3 Installation failed ご提案ありがとうございます。バージョン3.5.0を放棄しました最新の IDEs バージョンを使用しました。問題は解決されました。

XIP 知识库 亲爱的各位， 有没有我能读的 pdf 可以解释为什么我需要将修改 nor_flash（flexspi 驱动程序、闪存驱动程序）的代码放在与 flexspi 内存不同的位置，这会导致 AHB 总线故障？ 致以最崇高的敬意 Re: Knowledge base for XIP 不客气。 祝你愉快 Re: Knowledge base for XIP 你好，MayLiu， ，非常感谢你的答复。 🙂 最美好的祝愿， Jakub Re: Knowledge base for XIP 你好@jslota13245、 非常感谢您关注我们的产品并使用我们的社区。 关于你的问题，我建议你可以参考这个应用笔记。 https://www.nxp.com/docs/en/application-note/AN12564.pdf mayliu1_1-1753166605758.png 希望它能帮到你。 如果您还有疑问，请告诉我。 祝你愉快 敬上 MayLiu

s32k312芯片串口通信问题 使用S32K312芯片开发一款上装信息化控制器（类似TBOX），使用串口6和4G-DTU模块进行板载的TTL串口通信，现在遇到问题波特率在19200bps以下（包含19200bps），数据接收正常，当波特率大于19200bps后，出现接收数据中存在乱码数据问题（现在使用4G-DTU模块出场固件的波特率为115200bps），经过对硬件的排查，使用示波器检测数据，波特率及发送数据均正常（示波器具备解析串口协议的功能），最后问题点锁定在软件层面(串口的传输类型基于中断的方式实现)，但是暂时没有找出具体原因，希望芯片厂商能给出技术上面支持，进行问题的解决。 Re: s32k312芯片串口通信问题 Hi@米化 这看不出来有问题 Re: s32k312芯片串口通信问题 你好 我们这边使用外部晶振  晶振频率是16MHz,图片是我们时钟树图，麻烦看下是否设计合理 1753843226120.bmp Re: s32k312芯片串口通信问题 Hi@米化 虽然两块板子是相同硬件，但它们的晶振或内部时钟可能存在微小偏差，尤其在115200bps这种较高波特率下，时钟偏差更容易导致采样错误。 示波器解析的是电平信号，不依赖内部时钟，因此不会显示误码 1.时钟配置，是否采用的是外部晶振时钟，外部晶振时钟通常jitter很小 2.两块板子可以尝试共地连接再测试 3.如果你觉得是软件中断接收的方式，那么你可以改为DMA 4.尝试在TX线上串联一个47欧姆的小电阻再测试，这可以改善信号的完整性 Re: s32k312芯片串口通信问题 你好 我把我们测试的现象再完整给你描述下   希望您能给我一些建议：①我们单块板子115200bps下自发自收(我们使用一根5厘米左右的杜邦线将串口RX和TX进行了短接)，测试也是没问题的。②.我们还是单块板子进行自发自收，与①不同的是我们把5厘米的短接杜邦线增长至100里面左右，同时将此跟线缠绕至干扰电源进行干扰，测试也是没问题。③.我们使用两块硬件状态完全一样的控制器(也可以称为开发板)进行测试（为了排除电源的干扰，我们把两块板子上面的其它电源转换芯片直接拆除了），两块板子串口通讯线长度约10厘米，115200bps接收端控制器接收的数据还是存在误码，这两块板子之间通讯我们使用示波器进行监控（示波器具备串口通讯协议解析功能），整个测试过程示波器检测的数据均未出现误码现象。 Re: s32k312芯片串口通信问题 Hi@米化 按你的新的测试结果来看，MCU本身的收发测试是没有问题的呀，速率放低之后两个板子也没有问题的，这除了干扰之类的想不到还有什么因素能造成这种现象。 Re: s32k312芯片串口通信问题 你好 现在我们自测了 单块板子自发自收数据没有问题 两块板子之间串口通信一个板子发一个板子收就存在误码的问题 我们自己已经排除了非干扰问题 请问还有什么方向建议我们排查下 Re: s32k312芯片串口通信问题 Hi@米化 请先告知我们该如何复现你的问题，然后提供你们的测试工程，我们才能帮你分析。

Re: ZLG通信問題 こんにちは、MichaIH: 質問したいのですが、CANFD ツールのサポートは現在 freeMaster で利用できますか? Re: ZLG communication problem こんにちは： CAN FD は現在追加中で、ZLG、Kvaser、IXXAT デバイスの初期サポートが含まれています。10 月の次の 3.2.6 リリースにこれを含める予定です。 MCU 用のFreeMASTER ドライバではすでに CAN-FD オプションの設定が可能になっており、CAN-FD に適合したサンプル アプリケーション ( FRDM-MCXN947 アプリなど) も用意されています。もちろん、FreeMASTER アプリケーションがこの通信をサポートするまで、この作業は現在使用できません。 CAN プラグインのプロトタイプ バージョンをテストすることに興味がある場合は、 [email protected]までご連絡ください。 よろしくお願いいたします。 ミハル Re: ZLG communication problem わかりました。ありがとうございます Re: ZLG communication problem こんにちは、 あなたの投稿を新しいトピックに移動し、すぐにそこで回答します。 ありがとう、 ミハル

MPC5748G FLASH 写入过程电源中断 您好，我在使用 MPC5748G-176 写 FLASH 程序时，不小心关机，导致以后无法写入 FLASH。芯片锁定了吗？如何解锁或强制擦除？ 回复： MPC5748G FLASH write process power interruption 我用 PKGPPCNEXUSSTARTER 擦除了闪存，解决了这个问题。

s32g llce insmod llce_can.ko err 我使用S 3 2 G 399 A芯片，手动编译kernel，将L L C E 固件 和 驱动集成到根文件系统，手动加载L L CE CAN驱动报错，如下图。 请问是固件匹配问吗？还是缺少其他依赖？ 期待回复！ Dear engineers I am using the S 3 2 G 3 9 9 A chip, manually compiling the kernel, integrating the L L C E firmware and drivers into the root file system, and manually loading the L L C E CAN driver, but encountering an error, as shown below. Is there a firmware compatibility issue or is there a lack of other dependencies? Looking forward to your reply! liuchi_0-1753877704319.png Re: s32g llce insmod llce_can.ko err 问题已经解决了，更新kernel image为 编译 llce相关驱动统一版本image后，可正常加载。 Re: s32g llce insmod llce_can.ko err 您好 从Log来看，可能是llce_can.ko依赖的其他module没有提前加载，您可以参考下BSPUM中的以下部分重新试一下 chenyin_h_0-1753933304930.png BR Chenyin

在 S32g3 RDB3 上，PFE 性能低于 GMAC 我们试图使用 udp 通信在 S32G3 上测量 PFE 和 GMAC 的性能。 测试设置： 板 1：采用 BSP43 的 RDB3 板 2：采用 BSP43 的 RDB3 两个 RBD 均使用以太网电缆连接并进行了测量。 缓冲区大小：64 字节 使用简单的 UDP 客户端服务器应用程序进行了测试。在 Board1 上运行的 udp_client 和在 Board2 上运行的 udp_server。这是一个简单的 ping pong udp 测试，测量 udp 数据包的往返时间。 我们尝试了四种组合，结果附后。 eth<->eth, eth<->pfe2, pfe2<->eth, pfe2<->pfe2 从结果中我们可以发现，与其他组合相比，PFE 对 PFE 通信的性能非常低。与 GMAC 相比，我们预计 PFE 的通信量会更高。 Re: PFE performance is lower compared to GMAC on S32g3 RDB3 你好@kamal_n、 感谢您的耐心等待，内部团队分享了以下内容： ” 不使用 L2 桥配置时（将 PFE 作为普通网络接口使用），PFE 的延迟理论上比 GMAC 更差。这是因为 PFE 会尝试检查配置，查看数据包是否符合规则，而这需要时间。 PFE 的优势在于可用作交换机或路由器，从而卸载 CPU。典型的情况是，您可以从 PC1 向 EMAC1 发送帧，PFE 会根据您的配置将其转发到 EMAC0 或 EMAC2。在这种情况下，CPU 不参与转发，延迟肯定比 CPU 处理转发的情况短。 “ 要配置 PFE 桥接，请查看PFE_S32G_A53_LNX_UserManual.pdf，该手册可在 FlexNet 中找到，打包在PFE-DRV_S32G_A53_LNX_1.9.0_DOC.zip 中。请特别检查以下章节： 3 版本过程 2.10 Linux 的 FCI 用例 如果您在配置 PFE 桥接时遇到任何问题，请告诉我。 Re: PFE performance is lower compared to GMAC on S32g3 RDB3 你好@kamal_n、 我可以重现您的结果，但我只测试了 PFE-PFE 和 GMAC-GMAC，得到的结果相似，PFE 的性能比 GMAC 低。 我无法在文档中找到任何明确的信息，我将与内部团队分享这一主题，并等待他们的反馈。 预先感谢您的耐心等待。 Re: PFE performance is lower compared to GMAC on S32g3 RDB3 你好@kamal_n、 感谢您提供的所有详细信息，请给我一些时间来重复您的测试，并确认我看到了相同的行为，同时我将搜索更多有关 Linux 下 PFE 延迟的信息。 感谢您的耐心等待。 Re: PFE performance is lower compared to GMAC on S32g3 RDB3 你好@alejandro_e、 详情如下 1.MAC 配置 RGMII 2.以文件形式附上 printenv 结果 3.GMAC0 和 PFE_MAC2 使用 RGMII 的 1000Base-T 端口 4.没有对SJA1110 进行专门修改，我们也没有使用 SJA1110。 5.我方未做任何针对网络的改动。 我们已经使用64字节的缓冲区进行了测试，还尝试了1024字节。 能否建议缓冲区的大小，以便注意 PFE 性能的差异。 先行致谢。 Re: PFE performance is lower compared to GMAC on S32g3 RDB3 你好@kamal_n、 感谢您联系我们。您能告诉我有关测试的更多细节吗？请分享以下内容： 每个 MAC 接口（SGMII 或 RGMII）使用的配置 u-boot 中以下命令的输出： => printenv 您在两块板的每次测试中使用的确切的 RDB3 端口。 设置中与串行解串器（SGMII）有关的任何更改 您的设置中与 SJA1110 有关的任何更改 您的设置中与 Linux 网络有关的任何更改 预先致谢

S32K314 J-LINKを使用してAPPイメージをフラッシュすると、APPにジャンプできません こんにちは、チームの皆さん APP を更新するために、S32K314 ブートローダ デモと ECUBus を使用しました (このリンクに従ってください: https://community.nxp.com/t5/S32K-Knowledge-Base/Unified-bootloader-Demo/ta-p/1423099 )。それは大丈夫です。 しかし、J-LINK lite を使用して APP イメージをフラッシュすると、ブートローダーは APP にジャンプできません。J-LINK でアプリをフラッシュするにはどうすればいいですか? J-LINKの設定はこちら AmyHuang666_0-1753955596421.png そして.ldファイルは下記に添付されています。 Re: S32K314 Can't not jump to APP when use J-LINK to flash APP image こんにちは@AmyHuang666 重要な点は、アプリケーションがブートローダを介してロードされるときに、ブートローダがアプリケーション関連のメタデータをフラッシュ メモリに保存することです。構造 tAppFlashStatus を見てみましょう。 構造には以下が含まれます。 フラッシュプログラム成功 フラッシュ消去成功 フラッシュ構造有効 appCnt（アプリケーションカウンター） aFingerPrint（指紋バッファ） appStartAddr と appStartAddrLen (ハンドラーのアドレスと長さをリセット) crc (構造体のCRCチェックサム) この構造体は、アプリケーションのプログラミング後の最終ステップの一部としてブートローダによって呼び出される関数 Flash_WriteFlashAppInfo() を使用してフラッシュに保存されます。 アプリケーションがデバッグ インターフェース経由でロードされると、このメタデータは更新されません。つまり、次のようになります。 ブートローダーがアプリケーションを有効なものとして認識しない可能性があります。 CRC チェックまたは指紋検証が失敗する可能性があります。 メタデータが欠落しているか無効であるため、アプリケーションが正しく起動しない可能性があります。 デバッガー経由で新しいアプリケーションをロードするときに、その構造も何らかの方法で更新する必要があります。 よろしくお願いいたします。 ルーカス Re: S32K314 Can't not jump to APP when use J-LINK to flash APP image ここに.ldがありますファイル