2415516_ja-JP

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

2415516_ja-JP

2415516_ja-JP

FreeRTOSシステムは実行できません(作成直後は実行できません)。

仕様書に従ってプロジェクトプログラムを作成した後、FreeRTOSシステム上で実行できないことがわかりました(調査の結果、メモリ不足の問題ではなく、優先度の高い問題でもないことがわかりました)。S32DSコンパイラのバージョンは、以下の画像に示されています。

sunshine88_0-1790130461254.pngsunshine88_1-1790130512616.png

sunshine88_2-1790130568712.png


タスクの作成に失敗しました。このバージョンはFreeRTOSをサポートしていないのでしょうか?それとも、特別な設定要件があるのでしょうか?

sunshine88_3-1790132595523.png


Re: freertos 系统跑不通问题(创建即跑不通)

こんにちは、@sunshine88 さん。

申請が sys_msleep(5000) コール自体のせいで止まっているわけではありません。この動作は、sys_now()で使用されている時間ベースが増加していないことを示しています。したがって、 sys_msleep() 内のタイムアウト条件には決して到達できません。

OSIF構成のスクリーンショットでは、OsIfUseSystemTimerが有効になっており、オペレーティングシステムの種類はFreeRTOSに設定されています。しかし、OsIfCounterConfig_0 の下の参照、カウンタとシステムタイマークロックの参照を含め、不完全または空であるようです。PITコンポーネントを追加するだけでは、OSIFタイムベースが正しく構成および初期化されることを保証するものではありません。

現時点では、TCP/IPスタックのソースコードを変更したり、別の遅延回避策を実装したりしないでください。代わりに、私は以下のことをお勧めします。

  1. インストールされたTCP/IPスタックパッケージから元の lwip_FreeRTOS_s32K358 例をインポートしてください。
  2. 元のサンプルを一切変更せずにビルドして実行してください。
  3. 元の例でsys_now()が増加するかどうかを確認してください。
  4. FreeRTOS、BaseNXP/OSIF、PIT、クロック、割り込み、およびTCP/IPスタックの設定を、カスタムプロジェクトと比較してください。
  5. 生成された初期化シーケンスに、必要なBaseNXP/OSIFおよびタイマーの初期化が含まれていることを確認してください。

カスタムプロジェクトを正しく分析するためには、以前にご依頼した情報が引き続き必要です。

  • 正確なMCU部品番号;
  • 正確な評価ボードまたはカスタムボード;
  • 出発点として使用された元の事例またはプロジェクトの種類。
  • 変更されていないlwip_FreeRTOS_s32K358の例が同じハードウェアで動作するかどうか。
  • sys_now() の生成された実装。
  • xTaskGetTickCount() によって返される FreeRTOS ティック カウントが増加しているかどうか。

まずxTaskGetTickCount()を確認してください。sys_now()が一定のままでが増加する場合、FreeRTOSスケジューラとティック割り込みが実行されており、問題は具体的にはOSIFタイムベースの設定または初期化にあります。xTaskGetTickCount()も一定のままであれば、問題はより根本的なものであり、FreeRTOSのティック割り込みまたはスケジューラ構成を調査する必要があります。

可能であれば、構成スクリーンショットだけでなく、プロジェクト全体のアーカイブも提供してください。生成された構成コードと初期化コードがないと、sys_now()が実際にどのタイマーまたはクロックソースを使用しているかを判断することはできません。

よろしくお願いいたします。

パベル

Re: freertos 系统跑不通问题(创建即跑不通)

こんにちは。LWIPプログラムルーチンを作成しましたが、Ethernet mainLoopTaskタスクがsys_msleep(5000);で停止してしまい、遅延させることができません。この関数をステップ実行すると、startTime = sys_now(); と表示されますが、sys_now()関数はカウントできません。現在の設定ページは以下のとおりです。何が原因でしょうか?非常に困惑しています。



sunshine88_0-1790145231434.png

sunshine88_2-1790145441575.pngsunshine88_3-1790145507892.pngsunshine88_4-1790145535109.png



Re: freertos 系统跑不通问题(创建即跑不通)

こんにちは、@sunshine88 さん。

スクリーンショットに表示されているバージョンはFreeRTOSをサポートしているはずです。S32 Design Studio 3.5 アップデート14、RTD 4.0.0、FreeRTOS 4.0.0、およびTCP/IPスタック1.0.4これは予想されるパッケージの組み合わせのようで、一般的なバージョン互換性の問題とは思えません。

示されているコードによると、エラーはxTaskCreate()関数内で直接発生しています。以下の情報を教えていただけますか?

  1. 正確なMCU部品番号と評価ボード、またはカスタムボードが使われているのです。以前S32K358とおっしゃっていましたが、正確なデバイス名と基板名をお知らせください。
  2. 出発点として使用された元の例の名前。
  3. xTaskCreate() によって返される値。
  4. xTaskCreate() 呼び出しの前後で xPortGetFreeHeapSize() によって出力される値。
  5. configTOTAL_HEAP_SIZE、configSUPPORT_DYNAMIC_ALLOCATION の設定値、および選択された FreeRTOS ヒープ実装 (例: heap_4.c)。
  6. アプリケーションが停止する正確なポイント、特にアサーション、例外、ハードフォールハンドラに入るデバッガ呼び出しスタックも含まれます。

十分なMCU RAMがあっても、必ずしも十分なFreeRTOSヒープが利用できるとは限りません。xTaskCreate() は、FreeRTOS ヒープからタスク制御ブロックとタスクスタックの両方を動的に割り当てます。また、1024Uのスタック深度引数は通常、バイトではなくスタック要素を表すため、Cortex-M7の実際の割り当ては1024バイトより大きいです。

ベースラインテストとして、オリジナルのlwIP FreeRTOSサンプルを修正せずにインポートして実行することをお勧めします。元のサンプルが正常に動作したら、小さなスタックサイズ、通常の優先度、そしてループ内にvTaskDelay()呼び出しを含む追加タスクを追加してください。これにより、環境やボード構成の問題と、追加タスクによって引き起こされた問題を区別するのに役立ちます。

また、あなたの xTaskCreate() 呼び出しではスタック深度が 1024U であるのに対し、元の動作例では 256U を使用していることに気づきました。まず、元の値である256Uに戻し、変更を加えていないサンプルをテストしてください。このパラメータはバイト数ではなくスタック要素数を指定するため、1024Uを使うには大幅に多くのFreeRTOSヒープが必要です。
 

よろしくお願いします、
パベル

タグ(1)
評価なし
バージョン履歴
最終更新日:
木曜日
更新者: