2015Araiさんこちらでも現象の再現を確認できました。原因を解析した結果、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()のバラツキの方で報告させていただきます。こちらでも現象の再現を確認できました。原因を解析した結果、us_ticker_read()の不具合が原因であることがわかりました。[[http://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5344/?page=1#comment-26841|Akagawaさんからのご報告]]と、関連する内容と思われます。MailやMessageのQueueサイズ以上にputした場合にも、コールされます。tickerハンドラ処理を抜けられず、main.cのqueue_isr0()を何度もコールしていました。このため、生成したQueue数以上をputしており、os_error()がコールされておりました。現在、us_ticker_readの戻り値がなぜ異常値となるのか、解析中です。us_ticker_read()の解析結果等につきましては、[[http://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5344/|delay_ms()のバラツキ]]の方で報告させていただきます。2015Hamanakaさんレポート、ご苦労様です。確かに、I2Cセンサー読み込みスレッドの起動周期が乱れる現象は確認されていました。いずれにしても先ずは、最終対策でなくても更なる現象解析と解説をお待ちします。レポート、ご苦労様です。確かに、I2Cセンサー読み込みスレッドの起動周期が乱れる現象は確認されていました。いずれにしても先ずは、最終対策でなくても更なる現象解析と解説をお待ちします。2015Araiさん報告が遅くなり、すいません。現象が改善されていることを確認しました。社内にてレビュー後、詳細についてご連絡致します。報告が遅くなり、すいません。現象が改善されていることを確認しました。社内にてレビュー後、詳細についてご連絡致します。2015Araiさん、大変お待たせしました。プログラムを実行し、しばらくするとos_error()が発生する。原因は、us_ticker_read()の戻り値が異常値となることにありました。wait_us())からもコールされます。APIをコールされています。API処理中にTickerの割り込みが入ると、us_ticker_read()の値が異常値になる事がありました。現象発生時の詳細は以下です。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にて展開予定です。本日の確認で問題なければ、1/21頃返送の予定です。再度もしくは別の問題が発生した場合は、別途、延長をご相談させてください。Araiさん、大変お待たせしました。解析結果をコメント致します。プログラムを実行し、しばらくするとos_error()が発生する。原因は、us_ticker_read()の戻り値が異常値となることにありました。wait_us())からもコールされます。APIをコールされています。us_ticker_read()の値が異常値になる事がありました。現象発生時の詳細は以下です。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にて展開予定です。本日の確認で問題なければ、1/21頃返送の予定です。再度もしくは別の問題が発生した場合は、別途、延長をご相談させてください。今後に対しての質問です。「RTX_Conf_CA.cの各種定義数もそれに合わせてありますので、気にしなくてもほとんどの場合は済むはずです」と言えないでしょうか?はいかがでしょうか?私は各タスク1024Byteで十分な気がしますが・・・・・5)HW返却は平日受取は無理でしょうから土日指定願います。今週でなくても来週でも結構ですからスタック調査にお役立てください。今後に対しての質問です。5)HW返却は平日受取は無理でしょうから土日指定願います。今週でなくても来週でも結構ですからスタック調査にお役立てください。2015昨日(1/19)の長時間稼働の結果と、今後の展開についてお知らせします。一度検討したいと思います。明日あらためて回答します。過去の経緯を含め、ARMさんへ確認中ですので、もう少しお時間をください。昨日(1/19)の長時間稼働の結果と、今後の展開についてお知らせします。一度検討したいと思います。明日あらためて回答します。過去の経緯を含め、ARMさんへ確認中ですので、もう少しお時間をください。2015Hamanakaさん了解しました。「GR-PEACHのI2C(master)が使用できるようになりました」での停止問題の3つかがあると認識しています。正式見解なしが現時点の状況と判断します。3つかがあると認識しています。現時点の状況と判断します。2015Araiさんお待たせしました。以下の順でコメント致します。issues」をアップデートし、「defects」に残っている問題点を記載しました。No.4」に情報を記載しております。issues」「fixes」に、mbed-srcに反映されている内容を記載しました。⇒mbed-src-v442-preは、mbed-src(v440)を元に作成しております。(公開の際、Revision番号を間違え、442としてしまいました。)mbed-srcには、これまでアップデートしたmbed-src-v442-preの内容が全て含まれております。>3)問題を再現し対策した経緯で、修正した部分はus_ticker_read()部分だけですか?⇒修正箇所は、us_ticker_read()のみとなります。delay_ms()のバラツキの修正、および、今回の割り込み禁止の修正を行っております。rtosは現在公開されているmbed-rtos-v60-preには一切修正がありませんか?⇒mbed-rtos-v60-preに修正はありません。>4)私の公開したGR-PEACH_test_on_rtos_not_fixed_yetに修正はありませんか?⇒GR-PEACH_test_on_rtos_not_fixed_yetに修正はありません。スタックは変更なしでテストしたのでしょうか?⇒スタックの変更もなしでテストを実施しました。No.7」に、課題としてアップしました。進展があり次第、情報更新致します。>5)HW返却は平日受取は無理でしょうから土日指定願います。今週でなくても来週でも結構ですからスタック調査にお役立てください。⇒土日指定の件、承知しました。返却予定日は、別途ご連絡致します。意図した周期より短いタイミングで発生する現象を確認しました。ご指摘いただいた不具合は解消の確認ができましたが、継続して新たな問題を調査中です。No.6」として追加しました。上記状況ですが、us_ticker_read()の修正を、mbed-src-v442-preへ反映しました。【本日いただいたコメントへの回答】us_ticker_read()に関する情報のまとめ、ありがとうございます。正式見解なし⇒明日、GR-PEACHのI2C(master)が使用できるようになりましたへコメント致します。以下の順でコメント致します。issues」をアップデートし、「defects」に残っている問題点を記載しました。No.4」に情報を記載しております。issues」「fixes」に、mbed-srcに反映されている内容を記載しました。⇒mbed-src-v442-preは、mbed-src(v440)を元に作成しております。(公開の際、Revision番号を間違え、442としてしまいました。mbed-srcには、これまでアップデートしたmbed-src-v442-preの内容が全て含まれております。⇒修正箇所は、us_ticker_read()のみとなります。[[http://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5344/?page=1#comment-26991|delay_ms()のバラツキ]]の修正、および、今回の[[http://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5365/?page=2#comment-26992|割り込み禁止の修正]]を行っております。⇒mbed-rtos-v60-preに修正はありません。⇒GR-PEACH_test_on_rtos_not_fixed_yetに修正はありません。⇒スタックの変更もなしでテストを実施しました。No.7」に、課題としてアップしました。進展があり次第、情報更新致します。>5)HW返却は平日受取は無理でしょうから土日指定願います。今週でなくても来週でも結構ですからスタック調査にお役立てください。⇒土日指定の件、承知しました。返却予定日は、別途ご連絡致します。意図した周期より短いタイミングで発生する現象を確認しました。ご指摘いただいた不具合は解消の確認ができましたが、継続して新たな問題を調査中です。No.6」として追加しました。上記状況ですが、us_ticker_read()の修正を、mbed-src-v442-preへ反映しました。us_ticker_read()に関する情報のまとめ、ありがとうございます。⇒明日、[[http://developer.mbed.org/forum/team-886-GR-PEACH_producer_meeting-community/topic/5326/|GR-PEACHのI2C(master)が使用できるようになりました]]へコメント致します。2015ご苦労様でした。本日19:40から新しいmbed-src-v442-preでGR-PEACH_test_on_rtos_not_fixed_yetを動作させています。スタックを1024バイトにして、現在まで順調に動いています(22:20)。停止モードが無くなったことで、作りたいものに専念できると思います。再度、ご苦労様でした。issues」もゆっくり見させてもらいます。本日19:40から新しいmbed-src-v442-preでGR-PEACH_test_on_rtos_not_fixed_yetを動作させています。スタックを1024バイトにして、現在まで順調に動いています(22:20)。停止モードが無くなったことで、作りたいものに専念できると思います。再度、ご苦労様でした。issues」もゆっくり見させてもらいます。2015Araiさん大変お待たせしました。スタックに関して以下の順で回答致します。変更するのは、ユーザー側の仕事である」>とも取れますが、そのような解釈でしょうか?⇒回答の際の意図としては、ご認識のとおり「ユーザさんの方でRTX_Conf_CA.cの変更をお願いします」となります。>何度も言いますが、私の公開しているプログラムは他のmbedでは、動作しています。スタックを意識して作成しなくても、1KBから多くて2KBのスタックサイズでフリーズなく動作し続けます。>またmbedの思想から考えても、Lib内に存在する意味がすぐに分からない定義をいちいちユーザーが気にしながら作らないといけないのでしょうか?⇒Araiさんからのコメントを受け、ARMさんへの過去経緯確認の上、こちらでも検討しました。こちらとしても他のmbedで動作するものの多くがGR-PEACH上で動くことを望んでいますので、OSの差分解消を目指し、ARMさんと議論を進めて行く方針としました。OSのコアとなる部分の変更となりますので、最終的なライブラリ更新までには時間を要します。この部分についてはお時間ください。以下、OS差分に関する情報です。RTXではユーザにスレッドの総スタックサイズの調整を任せる仕様となっています。下記に、双方の仕様を示します。:スタック領域をスレッド別に動的に確保。⇒スレッド生成時、スタックサイズに関しては気にする必要がない。RAMが許す限り、スレッドを生成できる。・Cortex-A9:スレッドの総スタックサイズをOSのコンフィギュレータ設定にて静的に確保。⇒総スタックサイズを最初に検討/調整する必要がある。コンフィギュレータにて設定したスタックサイズ内でスレッドを生成する必要がある。⇒試行として、main関数から同じ関数をコールするサンプルプログラムをARMコンパイラでビルドし、Cortex-M(LPC1347)とCortex-A9(RZ_A1H)でmain関数のスタック消費量を比較しましたが、差分はありませんでした。今回のスタックサイズに関する問題は、上記スレッドのスタック確保方法の仕様差分のみに起因します。RTXでは、ユーザ側でのスレッドの総スタックサイズ調整(不足時)が必要になります。調整方法に関しては、2/4までにWikiに掲載します。【借用物返却に関して】デバッグにご協力いただきまして、誠にありがとうございました。Araiさんより借用しておりましたボード一式を、1/31(土)指定で返却させていただきます。スタックに関して以下の順で回答致します。⇒回答の際の意図としては、ご認識のとおり「ユーザさんの方でRTX_Conf_CA.cの変更をお願いします」となります。>何度も言いますが、私の公開しているプログラムは他のmbedでは、動作しています。スタックを意識して作成しなくても、1KBから多くて2KBのスタックサイズでフリーズなく動作し続けます。⇒Araiさんからのコメントを受け、ARMさんへの過去経緯確認の上、こちらでも検討しました。OSの差分解消を目指し、ARMさんと議論を進めて行く方針としました。OSのコアとなる部分の変更となりますので、最終的なライブラリ更新までには時間を要します。この部分についてはお時間ください。以下、OS差分に関する情報です。RTXではユーザにスレッドの総スタックサイズの調整を任せる仕様となっています。下記に、双方の仕様を示します。:スタック領域をスレッド別に動的に確保。⇒スレッド生成時、スタックサイズに関しては気にする必要がない。RAMが許す限り、スレッドを生成できる。・Cortex-A9:スレッドの総スタックサイズをOSのコンフィギュレータ設定にて静的に確保。⇒総スタックサイズを最初に検討/調整する必要がある。コンフィギュレータにて設定したスタックサイズ内でスレッドを生成する必要がある。Cortex-M(LPC1347)とCortex-A9(RZ_A1H)でmain関数のスタック消費量を比較しましたが、差分はありませんでした。今回のスタックサイズに関する問題は、上記スレッドのスタック確保方法の仕様差分のみに起因します。ユーザ側でのスレッドの総スタックサイズ調整(不足時)が必要になります。調整方法に関しては、2/4までにWikiに掲載します。デバッグにご協力いただきまして、誠にありがとうございました。1/31(土)指定で返却させていただきます。2015Hamanakaさん詳細解説、ありがとうございました。下記にコメントを残します。1)スタックに関して状況は判りました。スタックサイズが、M3&M4と殆ど変わらなことは安心しました。RTX_Conf_CA.cの変更は、残念ですが仕方なさそうですね。RAMが充実しているCortex-A9(RZ_A1H)ですから、一般的なユーザーアプリでは、頻繁に変更しなくても済むように標準的な設定をお願いしたいと思います。rtosに関するWikiの充実を望みます(期限を急ぐより、徐々にupdateしながら充実していただければと思います)。rtosは頻繁にupdateされているために、間違ってupdateしたときに自分のConfigをうまく残す方法はないのでしょうか?例えば、ユーザー側のファイルをIncludeで読み込むような手段とか・・・?2)返却31日であれば、留守にする時間帯が殆どないと思いますので、問題ありません。詳細解説、ありがとうございました。下記にコメントを残します。スタックサイズが、M3&M4と殆ど変わらなことは安心しました。RTX_Conf_CA.cの変更は、残念ですが仕方なさそうですね。RAMが充実しているCortex-A9(RZ_A1H)ですから、一般的なユーザーアプリでは、頻繁に変更しなくても済むように標準的な設定をお願いしたいと思います。rtosに関するWikiの充実を望みます(期限を急ぐより、徐々にupdateしながら充実していただければと思います)。31日であれば、留守にする時間帯が殆どないと思いますので、問題ありません。2015追加でコメントしておきます。私のrtos使用経験ですと、紹介したGR-PEACH_test_on_rtos_not_fixed_yetが大きいほうの部類に入ります。各スレッドのスタックサイズは私の場合、過去の経験からすると512バイトあれば、ほとんど大丈夫だと思われます。8192の現在の値が上記に合致しており、スレッド数が少なくなれば、各スタックの値をRTX_Conf_CA.cを変更しなくても1024バイトより大きくすることが可能で、8KBを越えなければ問題ないと解釈しています。結論として、私の場合には現在のRTX_Conf_CA.cでよいと思います。要望os_error関数の使い方事例をWikでに解説いただき、そのルーチン内でエラー解析(どのスレッドで問題発生したか、スタックがオーバーフローしたなど)する手法があれば発表していただけませんか?尚、GR-PEACH_test_on_rtos_not_fixed_yetの役目は終了したので、2月上旬には削除しておきます。追加でコメントしておきます。私のrtos使用経験ですと、紹介したGR-PEACH_test_on_rtos_not_fixed_yetが大きいほうの部類に入ります。各スレッドのスタックサイズは私の場合、過去の経験からすると512バイトあれば、ほとんど大丈夫だと思われます。現在の値が上記に合致しており、スレッド数が少なくなれば、各スタックの値をRTX_Conf_CA.cを変更しなくても1024バイトより大きくすることが可能で、8KBを越えなければ問題ないと解釈しています。結論として、私の場合には現在のRTX_Conf_CA.cでよいと思います。GR-PEACH_test_on_rtos_not_fixed_yetの役目は終了したので、2月上旬には削除しておきます。2015Araiさんスタックサイズに関するコメント、どうもありがとうございます。この後、プロデューサの皆さんへのお願いを出すことにします。現在ARMさんへ確認しているところです。スタックサイズに関するコメント、どうもありがとうございます。この後、プロデューサの皆さんへのお願いを出すことにします。現在ARMさんへ確認しているところです。2015プロデューサの皆様プロデューサの皆様からスレッドの総スタックサイズについてヒアリングさせていただきたいと思います。設定内容に関してご要望のある方はコメントをお願いします。RTXの仕様に差分があり、Cortex-A9ではユーザにてスレッドの総スタックサイズを調整する必要があります。以下にそれぞれの仕様を記載します。:スタック領域をスレッド別に動的に確保。⇒スレッド生成時、スタックサイズに関しては気にする必要がない。RAMが許す限り、スレッドを生成できる。・Cortex-A9:スレッドの総スタックサイズをOSのコンフィギュレータ設定にて静的に確保。⇒総スタックサイズを最初に検討/調整する必要がある。コンフィギュレータにて設定したスタックサイズ内でスレッドを生成する必要がある。この仕様差分を解消するよう、対応を進める方針ですが、OSのコアとなる部分の変更となりますので、最終的なライブラリ更新までには時間を要します。対応が完了するまでは現状のCortex-A9仕様でmbed-rtosをご使用いただく必要があり、プロデューサの皆様へのヒアリング結果により、スレッドの総スタックサイズの設定値を決定したいと考えています。までスタックサイズを指定できます。あれば十分と考えていますが、これまでの経緯を考慮し、余裕を持った設定としています。試行として、main関数から同じ関数をコールするサンプルプログラムをARMコンパイラでビルドし、Cortex-M(LPC1347)とCortex-A9(RZ_A1H)でmain関数のスタック消費量を比較しましたが、差分はありませんでした。上記から、Cortex-Mで作成したコードも、問題なく動作すると考えています。期限】2/13(金)までにご要望をお聞かせください。プロデューサの皆様からスレッドの総スタックサイズについてヒアリングさせていただきたいと思います。設定内容に関してご要望のある方はコメントをお願いします。Cortex-A9ではユーザにてスレッドの総スタックサイズを調整する必要があります。以下にそれぞれの仕様を記載します。:スタック領域をスレッド別に動的に確保。⇒スレッド生成時、スタックサイズに関しては気にする必要がない。RAMが許す限り、スレッドを生成できる。・Cortex-A9:スレッドの総スタックサイズをOSのコンフィギュレータ設定にて静的に確保。⇒総スタックサイズを最初に検討/調整する必要がある。コンフィギュレータにて設定したスタックサイズ内でスレッドを生成する必要がある。OSのコアとなる部分の変更となりますので、最終的なライブラリ更新までには時間を要します。プロデューサの皆様へのヒアリング結果により、スレッドの総スタックサイズの設定値を決定したいと考えています。までスタックサイズを指定できます。あれば十分と考えていますが、これまでの経緯を考慮し、余裕を持った設定としています。Cortex-M(LPC1347)とCortex-A9(RZ_A1H)でmain関数のスタック消費量を比較しましたが、差分はありませんでした。上記から、Cortex-Mで作成したコードも、問題なく動作すると考えています。2/13(金)までにご要望をお聞かせください。2015Hamanakaさん質問です。合計32KB確保されている。合計32KB確保されている。2015Araiさん説明がわかりづらく、すみません。合計32KB確保されている。と4KBを掛け合わせた数値ですか?いいえ、ご認識とは異なります。4倍したサイズが確保されます。40Kbyteとなります。OS_PRIVCNTにて定義したスレッド数で分け合います。目安として、1スレッドあたりの平均スタックサイズは、以下のように見積もれます。4Kbyte各スレッドのスタックサイズの内訳はユーザが自由に設定できます。第三引数でスレッドのスタックサイズを指定します。以下のように10スレッドのスタックを設定することもできます。4※()内は現在の設定です。説明がわかりづらく、すみません。合計32KB確保されている。いいえ、ご認識とは異なります。4倍したサイズが確保されます。OS_PRIVCNTにて定義したスレッド数で分け合います。目安として、1スレッドあたりの平均スタックサイズは、以下のように見積もれます。各スレッドのスタックサイズの内訳はユーザが自由に設定できます。第三引数でスレッドのスタックサイズを指定します。以下のように10スレッドのスタックを設定することもできます。※()内は現在の設定です。2015Hamanakaさん4倍しないといけない理由は、Byte単位と32Bit(4Bytes)単位の違いと理解しました。8192を、私としては推薦します。4倍しないといけない理由は、Byte単位と32Bit(4Bytes)単位の違いと理解しました。私としては推薦します。2015Araiさん要望いただき、ありがとうございます。8192>を、私としては推薦します。いただきました内容で、設定を修正したいと思います。この後、プロデューサの皆様へその旨、報告します。「OS_PRIVSTKSIZE」=「#/4」という意味で記載(定義)しているようです。要望いただき、ありがとうございます。>を、私としては推薦します。いただきました内容で、設定を修正したいと思います。この後、プロデューサの皆様へその旨、報告します。いう意味で記載(定義)しているようです。2015プロデューサーの皆様スレッドの総スタックサイズに関するご意見、どうもありがとうございました。Araiさんよりご推薦を頂きましたので、以下で更新することにしました。8192mbed-rtosへの反映は、3/4(水)を予定しております。スレッドの総スタックサイズに関するご意見、どうもありがとうございました。Araiさんよりご推薦を頂きましたので、以下で更新することにしました。mbed-rtosへの反映は、3/4(水)を予定しております。66(2/23更新)にて反映されましたのでご連絡いたします。ご連絡が遅くなり、申し訳ありません。66(2/23更新)にて反映されましたのでご連絡いたします。ご連絡が遅くなり、申し訳ありません。