作成中のクラスライブラリですが、メモリ量が少ないNucleo F303K8に載せてみてえらく苦労することになりました。
結論から書くとメモリ管理がシビアになるため、決め打ちでサイズを決めると痛い目に遭いそうです。
CubeMXでメモリに関する設定する場所は2カ所あります。
一つは全体設定で、ヒープと割り込みスタックのそれぞれのサイズを指定します。システムのヒープからはクラスライブラリのクラスやデバッガのバッファ領域を割り当てますのでそれぞれの領域の総和よりも大きなヒープを確保しなければなりません。
もう一つはFreeRTOSの固有ヒープのサイズを指定する場所です。CubeMXが生成するコードのFreeRTOSを覗いてみると、xTaskCreate() APIの中で、与えられたusStackDepth引数の値を元に、pvPortMalloc()を呼び出してタスク・スタックを取得します。したがって、FreeRTOSの固有ヒープのサイズは、各タスクのスタックの総和まで考えて指定する必要があります。
問題は、どうもシステムのヒープとスタックの領域チェックを実行時に行っていないように思える事です。先に指定したスタックのサイズとヒープのサイズは、リンカがメモリを割り当てるときにヒープとスタックの領域をきちんと確保できたか確認するためのものに過ぎません。malloc()は領域をチェックせずにメモリを割り当てているようです。
ということで、クラスを駆使して動的にオブジェクトをどんどん作るライブラリですので、実行時のヒープ・サイズ管理はかなり重要です。将来的に何らかのメモリ監視コードを開発しておく必要があります。
追記：これ、new/delete演算子を多重定義するべきケースですね。全部pvPortMalloc()に持っていけばいいんだ。