こんにちは、チームの皆さん
確認関数と送信関数が 2 つの別々のタスクから呼び出されると、NETC 送信で問題が発生しました。
この例をしばらく (数分) 実行した後、TX バッファを取得できなくなります。
以下の条件が満たされていないため、すべての TX バッファが解放されていないことがわかりました。
buff == Netc_Eth_Ip_apxState[ctrlIndex]->TxDataBuffAddr[ring][LastDescrCheckIndex](下図参照)です。
この例は、SW32N5_GRAYVIP_1_0_22_0 内のコホート 2 VIP アプリケーションです。
ソフトウェア: SW32N_RTD_R21-11_1.8.0_CD05 + SW32N5_GRAYVIP_1_0_22_0
ハードウェア: S32N55 RDB
よろしくお願いいたします。
唐生。
こんにちは@Tangsheng_Zhouさん
私は GrayVip で働いていないので、このプロジェクトの運営をコントロールすることはできません。SO、いくつかの情報を提供してください。これは、前の質問に添付された情報と同時に読むことができます (lastTxBd = 14 だが buff = 16 の場合など)。
- Netc_Eth_Ip_apxState[] を完全に読み取ることができますか? Tx リング サイズなど、Tx に関連するすべての情報です。
- Eth_43_NETC_axTransmissionRequests[CtrlIdx][FifoIdx] を読み取ることができますか
- 各タスクに対してどのような順序で呼び出しましたか?Transmit を呼び出す前に ProvideTx のステータスを確認するなど...
よろしくお願いいたします。
ニ
こんにちは@Nhi_Nguyen
ご説明いただきSOありがとうございました。
私はあなたに同意します。問題の瞬間を捉えようとしましたが、失敗しました。
この関数は再入不可能であることを理解しています。
「非再入可能」についての私の理解は、非再入可能とは、関数が実行を終了する前に再度呼び出すことができないことを意味します。ただし、他のThreadが同じ関数を呼び出さない限り、他のThreadによって中断される可能性があります。
私の理解では、非再入可能≠非割り込み可能
現在、関数 Eth_43_NETC_TxConfirmation は、Provide_TxBuf や Transmit などの Thread 呼び出しによって割り込まれることはありません。
このデザインは許容できるものと考えられるべきでしょうか、それとも重要な共有変数に対して安全策を導入する必要があるのでしょうか?
よろしくお願いいたします。
唐生。
こんにちは@Tangsheng_Zhouさん
再入関数の定義を確認しましたが、あなたの意見に同意します。チケットARTDCC1-494をSWチームに提出しました。このチケットをフォローしてステータスを確認してください。
よろしくお願いいたします。
ニ
はい、サポートしていただきありがとうございました。
よろしくお願いいたします。
唐生。