Araiさん
こちらでも現象の再現を確認できました。
原因を解析した結果、us_ticker_read()の不具合が原因であることがわかりました。
Akagawaさんからのご報告と、関連する内容と思われます。

まず、os_error()なのですが、スタックエラーの他に、
MailやMessageのQueueサイズ以上にputした場合にも、コールされます。

us_ticker_read()の戻り値が異常値となるため、
tickerハンドラ処理を抜けられず、main.cのqueue_isr0()を何度もコールしていました。
このため、生成したQueue数以上をputしており、os_error()がコールされておりました。
現在、us_ticker_readの戻り値がなぜ異常値となるのか、解析中です。

Akagawaさん
us_ticker_read()の解析結果等につきましては、delay_ms()のバラツキの方で報告させていただきます。

Hamanakaさん
レポート、ご苦労様です。
了解です。
確かに、I2Cセンサー読み込みスレッドの起動周期が乱れる現象は確認されていました。
いずれにしても先ずは、最終対策でなくても更なる現象解析と解説をお待ちします。

Araiさん
報告が遅くなり、すいません。

暫定コードを埋め込み、週末に長時間稼働を行ったところ、
現象が改善されていることを確認しました。

社内にてレビュー後、詳細についてご連絡致します。

Araiさん、大変お待たせしました。

解析結果をコメント致します。

【不具合内容】
プログラムを実行し、しばらくするとos_error()が発生する。

【原因】
原因は、us_ticker_read()の戻り値が異常値となることにありました。

us_ticker_read()は、割り込みハンドラからコールされますが、
wait API(wait_api.cのwait(), wait_ms(), wait_us())からもコールされます。
プログラムを拝見したところ、タスクコンテキストからwait APIをコールされています。
wait API処理中にTickerの割り込みが入ると、
us_ticker_read()の値が異常値になる事がありました。

現象発生時の詳細は以下です。

①　タスクコンテキストからwait API経由でus_ticker_read()がコールされる。
②　wrap_arroundをインクリメント後、last_readを更新する前に割り込みが発生。
③　割り込み処理内でus_ticker_read()がコールされ、wrap_arroundをインクリメント。
④　us_ticker_read()の戻り値が、期待値を大幅に上回る。
⑤　割り込みハンドラ(us_ticker_api.cのus_ticker_irq_handler())を抜けられず、何度もqueue_isr0()をコール。
⑥　定義Queueサイズ以上にputするため、os_error()発生。

【対策】
us_ticker_read()の処理中は割り込み禁止としました。

【対策版コードの展開時期】
本日、再度長時間稼働を行います。
問題がなければ、明日中に修正コードをmbed-src-v442-preにて展開予定です。

【H/Wのご返却時期】
本日の確認で問題なければ、1/21頃返送の予定です。
再度もしくは別の問題が発生した場合は、別途、延長をご相談させてください。

Hamanakaさん及び中の人、各位
対応ご苦労様でした。

今後に対しての質問です。
１）修正コードをmbed-src-v442-preにて展開とありますが、known issueも同時にアップデートしていただき、何が残っているか明確にしていただけませんか？
２）mbed-srcが現時点(6:30JST)で6時間前に更新されていますが、こちらに反映されたものとされないものを明確にしてもらえますか?
　言い方を変えれば、mbed-srcのどのRevisionをベースにmbed-src-v442-preを作成しているのか？すでにv441ではないと思われるが・・・
３）問題を再現し対策した経緯で、修正した部分はus_ticker_read()部分だけですか?
　rtosは現在公開されているmbed-rtos-v60-preには一切修正がありませんか？
４）私の公開したGR-PEACH_test_on_rtos_not_fixed_yetに修正はありませんか？
　スタックは変更なしでテストしたのでしょうか？
　修正なしであれば、最適値はどのくらいがだとうですか？
以前お聞きした、

今回のスタックの件で言えば、
１）　他のmbedのスタック消費量の測定や推定（ARMさんからの情報提供など、printfなどの最大値等々）
２）　RZ/A1H のスタック消費量
３）　おおよその比率
から、
「一般的にM3に比較して、スタックサイズを3倍(?)くらいに設定してもらえれば、他のmbedから移植できるはずです」
と言っていただき、
「RTX_Conf_CA.cの各種定義数もそれに合わせてありますので、気にしなくてもほとんどの場合は済むはずです」
と言えないでしょうか?

はいかがでしょうか？
私は各タスク1024Byteで十分な気がしますが・・・・・

５）HW返却は平日受取は無理でしょうから土日指定願います。今週でなくても来週でも結構ですからスタック調査にお役立てください。

昨日(1/19)の長時間稼働の結果と、今後の展開についてお知らせします。
【長時間稼働の結果】
問題の再現せず
【今後の展開】
ご指摘いただいた点(ご質問)について、内部で検討の上、
known issuesと更新ライブラリとの関係等、プロデューサの皆さんに分かり易い形での展開について、
一度検討したいと思います。明日あらためて回答します。
ただし、スタックサイズの件については、Cortex-A9とCortex-MとでCMSIS-RTOS RTXの仕様に差分があり、
過去の経緯を含め、ARMさんへ確認中ですので、もう少しお時間をください。

Hamanakaさん
了解しました。
us_ticker_read()による影響は、
①　この件
②　「delay_ms()について」で議論されている件
③　「GR-PEACHのI2C(master)が使用できるようになりました」での停止問題
の3つかがあると認識しています。
①　OK
②　Akagawaさんの指摘事項で再検討要
③　正式見解なし
が現時点の状況と判断します。
③の見解を、別のスレッドへ回答いただけないでしょうか?

Araiさん
お待たせしました。
以下の順でコメント致します。

・昨日ご指摘いただいた点(ご質問)について
・mbed-src-v442-preのアップデートのご案内
・本日いただいたコメントへの回答


【昨日ご指摘いただいた点(ご質問)について】
＞１）修正コードをmbed-src-v442-preにて展開とありますが、known issueも同時にアップデートしていただき、何が残っているか明確にしていただけませんか？
⇒「known issues」をアップデートし、「defects」に残っている問題点を記載しました。
　本スレッドの問題は、「known issues」「defects No.4」に情報を記載しております。

＞２）mbed-srcが現時点(6:30JST)で6時間前に更新されていますが、こちらに反映されたものとされないものを明確にしてもらえますか?
⇒「known issues」「fixes」に、mbed-srcに反映されている内容を記載しました。

＞ 　言い方を変えれば、mbed-srcのどのRevisionをベースにmbed-src-v442-preを作成しているのか？すでにv441ではないと思われるが・・・
⇒mbed-src-v442-preは、mbed-src(v440)を元に作成しております。(公開の際、Revision番号を間違え、442としてしまいました。すみません。)
　mbed-srcには、これまでアップデートしたmbed-src-v442-preの内容が全て含まれております。

＞３）問題を再現し対策した経緯で、修正した部分はus_ticker_read()部分だけですか?
⇒修正箇所は、us_ticker_read()のみとなります。
　delay_ms()のバラツキの修正、および、今回の割り込み禁止の修正を行っております。

＞ 　rtosは現在公開されているmbed-rtos-v60-preには一切修正がありませんか？
⇒mbed-rtos-v60-preに修正はありません。

＞４）私の公開したGR-PEACH_test_on_rtos_not_fixed_yetに修正はありませんか？
⇒GR-PEACH_test_on_rtos_not_fixed_yetに修正はありません。

＞ 　スタックは変更なしでテストしたのでしょうか？
⇒スタックの変更もなしでテストを実施しました。

＞ 　修正なしであれば、最適値はどのくらいがだとうですか？
⇒スタックに関しては、「known issues」「issues No.7」に、課題としてアップしました。
　進展があり次第、情報更新致します。

＞５）HW返却は平日受取は無理でしょうから土日指定願います。今週でなくても来週でも結構ですからスタック調査にお役立てください。
⇒土日指定の件、承知しました。返却予定日は、別途ご連絡致します。


【mbed-src-v442-preのアップデートのご案内】
こちらの追試において、Tickerを二つ定義して動作させた場合、割り込みのコールバックが、
意図した周期より短いタイミングで発生する現象を確認しました。
ご指摘いただいた不具合は解消の確認ができましたが、継続して新たな問題を調査中です。
この問題は、「known issues」の「defects No.6」として追加しました。

上記状況ですが、us_ticker_read()の修正を、mbed-src-v442-preへ反映しました。
「known issues」「defects No.4」 を参照ください。


【本日いただいたコメントへの回答】
us_ticker_read()に関する情報のまとめ、ありがとうございます。
＞③　正式見解なし
⇒明日、GR-PEACHのI2C(master)が使用できるようになりましたへコメント致します。

ご苦労様でした。
本日１９：４０から新しいmbed-src-v442-preでGR-PEACH_test_on_rtos_not_fixed_yetを動作させています。
スタックを1024バイトにして、現在まで順調に動いています（２２：２０）。
停止モードが無くなったことで、作りたいものに専念できると思います。
再度、ご苦労様でした。
「known issues」もゆっくり見させてもらいます。

Araiさん
大変お待たせしました。
スタックに関して以下の順で回答致します。

・コメントに対する回答
　　Araiさんよりいただきました、コメントについての回答
・借用物返却に関して

【コメントに対する回答】
＞Hamanakaさんの説明ですと、
＞「rtosを使用するときには、ユーザープログラムが何をするかでスタックサイズが異なるので、RTX_Conf_CA.c を変更するのは、ユーザー側の仕事である」
＞とも取れますが、そのような解釈でしょうか?
⇒回答の際の意図としては、ご認識のとおり「ユーザさんの方でRTX_Conf_CA.cの変更をお願いします」となります。


＞何度も言いますが、私の公開しているプログラムは他のmbedでは、動作しています。
＞ 特にスタックを意識して作成しなくても、１KBから多くて2KBのスタックサイズでフリーズなく動作し続けます。
＞またmbedの思想から考えても、Lib内に存在する意味がすぐに分からない定義をいちいちユーザーが気にしながら作らないといけないのでしょうか?
⇒Araiさんからのコメントを受け、ARMさんへの過去経緯確認の上、こちらでも検討しました。
　こちらとしても他のmbedで動作するものの多くがGR-PEACH上で動くことを望んでいますので、
　OSの差分解消を目指し、ARMさんと議論を進めて行く方針としました。
　ただし、OSのコアとなる部分の変更となりますので、最終的なライブラリ更新までには時間を要します。
　この部分についてはお時間ください。
　以下、OS差分に関する情報です。

　Cortex-M用 CMSIS-RTOS RTXでは、ユーザがスレッドの総スタックサイズを意識しないでよい仕様となっており、
　Cortex-A9用 CMSIS-RTOS RTXではユーザにスレッドの総スタックサイズの調整を任せる仕様となっています。
　下記に、双方の仕様を示します。

　・Cortex-M ：スタック領域をスレッド別に動的に確保。
　　　　　　　 ⇒スレッド生成時、スタックサイズに関しては気にする必要がない。
　　　　　　　 　RAMが許す限り、スレッドを生成できる。

　・Cortex-A9：スレッドの総スタックサイズをOSのコンフィギュレータ設定にて静的に確保。
　　　　　　　 ⇒総スタックサイズを最初に検討/調整する必要がある。
　　　　　　　 　コンフィギュレータにて設定したスタックサイズ内でスレッドを生成する必要がある。


＞今回のスタックの件で言えば、
＞ １）　他のmbedのスタック消費量の測定や推定（ARMさんからの情報提供など、printfなどの最大値等々）
＞ ２）　RZ/A1H のスタック消費量
＞ ３）　おおよその比率
＞から、
＞ 「一般的にM3に比較して、スタックサイズを3倍(?)くらいに設定してもらえれば、他のmbedから移植できるはずです」
＞と言っていただき、
⇒試行として、main関数から同じ関数をコールするサンプルプログラムをARMコンパイラでビルドし、
　Cortex-M(LPC1347)とCortex-A9(RZ_A1H)でmain関数のスタック消費量を比較しましたが、差分はありませんでした。
　今回のスタックサイズに関する問題は、上記スレッドのスタック確保方法の仕様差分のみに起因します。

＞ 「RTX_Conf_CA.cの各種定義数もそれに合わせてありますので、気にしなくてもほとんどの場合は済むはずです」
＞と言えないでしょうか?
⇒上記のとおり、OS差分がありますので、現状のCortex-A9用CMSIS-RTOS RTXでは、
　ユーザ側でのスレッドの総スタックサイズ調整(不足時)が必要になります。
　調整方法に関しては、2/4までにWikiに掲載します。

【借用物返却に関して】
デバッグにご協力いただきまして、誠にありがとうございました。
Araiさんより借用しておりましたボード一式を、
1/31(土)指定で返却させていただきます。

Hamanakaさん
詳細解説、ありがとうございました。
下記にコメントを残します。

１）スタックに関して
状況は判りました。
スタックサイズが、M3&M4と殆ど変わらなことは安心しました。
RTX_Conf_CA.cの変更は、残念ですが仕方なさそうですね。
RAMが充実しているCortex-A9(RZ_A1H)ですから、一般的なユーザーアプリでは、頻繁に変更しなくても済むように標準的な設定をお願いしたいと思います。
rtosに関するWikiの充実を望みます（期限を急ぐより、徐々にupdateしながら充実していただければと思います）。
rtosは頻繁にupdateされているために、間違ってupdateしたときに自分のConfigをうまく残す方法はないのでしょうか?
例えば、ユーザー側のファイルをIncludeで読み込むような手段とか・・・？

２）返却
３１日であれば、留守にする時間帯が殆どないと思いますので、問題ありません。

追加でコメントしておきます。
私のrtos使用経験ですと、紹介したGR-PEACH_test_on_rtos_not_fixed_yetが大きいほうの部類に入ります。
各スレッドのスタックサイズは私の場合、過去の経験からすると512バイトあれば、ほとんど大丈夫だと思われます。
皆さんからの製作事例で、コメントをいただき、おおよその値を決めたらいかがでしょうか?

Arai事例からのスタック確保サイズ
スタックサイズ　1024バイト／スレッド
スレッド総数　８

私の認識では、
　OS_PRIVCNT 8
　OS_PRIVSTKSIZE 8192
の現在の値が上記に合致しており、スレッド数が少なくなれば、各スタックの値をRTX_Conf_CA.cを変更しなくても1024バイトより大きくすることが可能で、８KBを越えなければ問題ないと解釈しています。
結論として、私の場合には現在のRTX_Conf_CA.cでよいと思います。

要望
os_error関数の使い方事例をWikでに解説いただき、そのルーチン内でエラー解析(どのスレッドで問題発生したか、スタックがオーバーフローしたなど）する手法があれば発表していただけませんか？

尚、GR-PEACH_test_on_rtos_not_fixed_yetの役目は終了したので、2月上旬には削除しておきます。
名前があまり良くないですから・・・・

Araiさん

スタックサイズに関するコメント、どうもありがとうございます。
この後、プロデューサの皆さんへのお願いを出すことにします。
また頂きましたご要望ですが、os_error関数はどのスレッドで問題発生したかを知る手法がなく、
現在ARMさんへ確認しているところです。少々お時間ください。

プロデューサの皆様

プロデューサの皆様からスレッドの総スタックサイズについてヒアリングさせていただきたいと思います。
設定内容に関してご要望のある方はコメントをお願いします。


【背景】
Cortex-A9とCortex-MとでCMSIS-RTOS RTXの仕様に差分があり、
Cortex-A9ではユーザにてスレッドの総スタックサイズを調整する必要があります。
以下にそれぞれの仕様を記載します。

・Cortex-M ：スタック領域をスレッド別に動的に確保。
　　　　　　 ⇒スレッド生成時、スタックサイズに関しては気にする必要がない。
　　　　　　 　RAMが許す限り、スレッドを生成できる。

・Cortex-A9：スレッドの総スタックサイズをOSのコンフィギュレータ設定にて静的に確保。
　　　　　　 ⇒総スタックサイズを最初に検討/調整する必要がある。
　　　　　　 　コンフィギュレータにて設定したスタックサイズ内でスレッドを生成する必要がある。

この仕様差分を解消するよう、対応を進める方針ですが、
OSのコアとなる部分の変更となりますので、最終的なライブラリ更新までには時間を要します。
対応が完了するまでは現状のCortex-A9仕様でmbed-rtosをご使用いただく必要があり、
プロデューサの皆様へのヒアリング結果により、スレッドの総スタックサイズの設定値を決定したいと考えています。


【現在の設定値】
OS_PRIVCNT 　　8 ⇒ stacksz != 0で定義するスレッド総数
OS_PRIVSTKSIZE 8192　　⇒ stacksz != 0で定義するスレッドの、総スタックサイズ
　 　8Kbyte * 4 = 32KB

現在の設定では、1スレッドあたり平均 4Kbyte までスタックサイズを指定できます。
過去の経験より、1スレッドあたり 1Kbyte あれば十分と考えていますが、これまでの経緯を考慮し、余裕を持った設定としています。
試行として、main関数から同じ関数をコールするサンプルプログラムをARMコンパイラでビルドし、
Cortex-M(LPC1347)とCortex-A9(RZ_A1H)でmain関数のスタック消費量を比較しましたが、差分はありませんでした。
上記から、Cortex-Mで作成したコードも、問題なく動作すると考えています。


【ヒアリング　期限】
2/13(金)までにご要望をお聞かせください。

Hamanakaさん
質問です。
1スレッドあたり平均 4Kbyte までで、合計32KB確保されている。
これは、OS_PRIVCNT 　　8 と4KBを掛け合わせた数値ですか?
OS_PRIVSTKSIZE 8192にも、stacksz != 0で定義するスレッドの、総スタックサイズとありますが、32KBとOS_PRIVSTKSIZEの関係は？
関係を教えてもらえませんか?

Araiさん

説明がわかりづらく、すみません。

＞1スレッドあたり平均 4Kbyte までで、合計32KB確保されている。
＞これは、OS_PRIVCNT 　　8 と4KBを掛け合わせた数値ですか?
いいえ、ご認識とは異なります。
Cortex-A9 CMSIS-RTOS RTXの仕様で、
スレッドの総スタックサイズは OS_PRIVSTKSIZE を4倍したサイズが確保されます。

例えば、

OS_PRIVCNT 　　10
OS_PRIVSTKSIZE 10240

とした場合、総スタックサイズは、

　総スタックサイズ = OS_PRIVSTKSIZE * 4 = 10240 * 4 = 40Kbyte

となります。
上記、総スタックサイズ 40Kbyte を、OS_PRIVCNTにて定義したスレッド数で分け合います。
目安として、1スレッドあたりの平均スタックサイズは、以下のように見積もれます。

　総スタックサイズ / OS_PRIVCNT = 40Kbyte / 10 = 4Kbyte

各スレッドのスタックサイズの内訳はユーザが自由に設定できます。
具体的にはソースコード上で、osThreadDef()を定義した際、
第三引数でスレッドのスタックサイズを指定します。
例えば、以下のように10スレッドのスタックを設定することもできます。

Thread 1：　　　1 Kbyte
Thread 2：　　　1 Kbyte
Thread 3：　　　2 Kbyte
Thread 4：　　　5 Kbyte
Thread 5：　　10 Kbyte
Thread 6：　　10 Kbyte
Thread 7：　　　1 Kbyte
Thread 8：　　　3 Kbyte
Thread 9：　　　2 Kbyte
Thread 10：　　 5 Kbyte
――――――――――
合計　　　　 　 40 Kbyte


＞OS_PRIVSTKSIZE 8192にも、stacksz != 0で定義するスレッドの、総スタックサイズとありますが、32KBとOS_PRIVSTKSIZEの関係は？
＞ 関係を教えてもらえませんか?
上記の通り、

　総スタックサイズ(32Kbyte) = OS_PRIVSTKSIZE(8Kbyte) * 4
※()内は現在の設定です。

という関係になります。

Hamanakaさん
４倍しないといけない理由は、Byte単位と32Bit(4Bytes)単位の違いと理解しました。
そうであれば、上記の説明を受けた後では、
OS_PRIVCNT 　　10
OS_PRIVSTKSIZE 8192
を、私としては推薦します。

追記(10分後)

//   <o>Total stack size [bytes] for threads with user-provided stack size <0-4096:8><#/4>
//   <i> Defines the combined stack size for threads with user-provided stack size.
//   <i> Default: 0
#ifndef OS_PRIVSTKSIZE
 #define OS_PRIVSTKSIZE 8192
#endif

Total stack size [bytes]と書かれているのは気になりますね！

Araiさん

要望いただき、ありがとうございます。

＞OS_PRIVCNT 　　10
＞OS_PRIVSTKSIZE 8192
＞を、私としては推薦します。
いただきました内容で、設定を修正したいと思います。
この後、プロデューサの皆様へその旨、報告します。

＞Total stack size [bytes]と書かれているのは気になりますね！
該当部分はARMさんオリジナルのコメントになりますが、
「<o>Total stack size [bytes] for threads with user-provided stack size <0-4096:8><#/4>」
において、
「総スタックサイズ」＝「＃」
「OS_PRIVSTKSIZE」＝「＃/4」
という意味で記載(定義)しているようです。

プロデューサーの皆様

スレッドの総スタックサイズに関するご意見、どうもありがとうございました。
Araiさんよりご推薦を頂きましたので、以下で更新することにしました。

OS_PRIVCNT 　　10
OS_PRIVSTKSIZE 8192

mbed-rtosへの反映は、3/4(水)を予定しております。

プロデューサーの皆様

スレッドの総スタックサイズに関する変更が、
mbed-rtos rev 66(2/23更新)にて反映されましたのでご連絡いたします。
ご連絡が遅くなり、申し訳ありません。