(toppers-users 3081) Re: [H8]E_CTX reported by `isig_tim()' in line 63 of `../jsp/systask/timer.c'. 頻発
中村和博
norichan1108 ＠ gmail.com
2010年 2月 14日 (日) 18:13:14 JST
こんばんは、中村です。
To: 小南 様
今回はお手数をおかけして申し訳ありませんでした。
現状は取り急ぎTOPPERSをあきらめて作り直していますが、次回は現在の仕様にイーサネットが
追加になるためTINETを使いたいとおもっているので後日改めて検討してみたいとおもいます。
特に、ご指摘のあった環境の違いについては気づいてはいました。
いろいろネットを見て回ったところgcc-3.4.3での動作報告が結構あったのとsmple1は問題なく
動いているようだったので現環境でやっていますが、あらためて開発と同様の環境で試してみたいと
おもいます。
それにしてもH8のRTOS環境はどんどんサポートが切られていきますね。
MESもすでにV2の配布そのものがなくなっていますし、（そこでJSPを使うよう推薦されいて
いるのですが）TOPPERS/JSP(ASPも？)でもやはりすでにサポート外。昨今は安価な
ARMチップが入手できるようになったのもありニーズが少ないのかもしれないですが寂しい限りです。
2010年2月14日16:48 yasuo kominami(nifty) <ykominami ＠ nifty.com>:
> 中村様
>
> 小南と申します。
>
> TOPPERSプロジェクトの個人会員です。
> 私自身、TOPPERS/JSPをだいぶ長い間フォローしていますが、中村様のところで
> 発生している現象は初耳です。
> 念のため、TOPPERS USERSメーリングリストやTOPPERSプロジェクト会員用
> のメーリングリスト、BTSなどでH8をキーワードに調べてみましたが、該当する
> ような現象の報告は見つかりませんでした。
>
> 現在私の手元にはH8/3069用のGNU開発環境や実機自体もなく、報告された現象
> を確認する手段がありません。
>
> 月曜日までになんとか動かさなければならないという状況に対して、手助けになるか
> は分かりませんが、私の方で気がついた点を述べます。
>
> 以下はTOPPERS/JSP 1.4.3の配布パッケージを前提とします。
>
> 1.中村様の開発環境が、TOPPERS/JSP 1.4.3 H8/3069F依存部開発時の
> 開発環境が異なています。
>
> doc/h8.txt
>> 4. 開発
>>
>> 4. 1 開発環境の構築
>>
>> 開発環境は、 Windows 2000上の cygwin の開発環境を用いた。本実装に用
>> いたバージョンを以下に示す。
>>
>> binutils-2.11.2
>> gcc-2.95.3
>> newlib-1.9.0
>>
>> 補助的な意味でNKEV-010H8については以下のバージョンでも確認を行った。
>>
>> binutiles-2.16.1
>> gcc-3.4.3
>> newlib-1.13.0
>
> 中村様の開発環境
>> 環境：
>> ubuntu 8.04TLS(on VMWare)
>> gcc-3.4.3 非パッチ(with-newlib disable-nls)
>> binutils-1.15 (disable-nld)
>> newlib-1.13.0
>> make 3.81
>
> GNUツールチェインでは、CPUの種類やバージョンの違いによる品質のばらつきや、
> 仕様変更による影響などが大きいです。
> 同一ソースコードでもツールのバージョンにより、同じ動作になるとは言い切れません。
>
> 特に、H8/3069Fに対してはJSP1.4.3 H8(GNU版)でシリアルドライバの3ch化に対応
> しましたので、開発時点でその中村様の報告された現象が起こっていれば、そもそも
> リリースされていないと言えます。
>
>> 環境：
>> ubuntu 8.04TLS(on VMWare)
>> gcc-3.4.3 非パッチ(with-newlib disable-nls)
>> binutils-1.15 (disable-nld)
>> newlib-1.13.0
>> make 3.81
>
>
> ただし、現在入手可能なバージョンで適切に動かすためには、修正が必要になるかも
> しれません。
>
>
> 2.以下のご指摘は、ソースコードを見た限りは発生しそうだと思いました。
> この点はBTSに登録したいと思います。
>
>> それから、ざっとH8のハードウェアマニュアルを斜め見したところ、
>> t_cpu_lock()で呼ばれているdisintの実装でORCでCCRのI,UIフラグをセットした
>> 直後にcpulockフラグを設定していますが、ORC実行中に割り込みを受けた場合、
>> H8はORCの次の命令を実行してから割り込み先に分岐するようです。
>> そうなると、CPUロック状態で割り込みに入ってしまう可能性があります。
>> なので、disintのORCの後にNOPなりの無効な処理を入れたほうが良いように思えます。
>>
>> --引用ここから--
>> 5.5.2 割り込みの受け付けを禁止している命令
>> 割り込みを禁止している命令には、LDC、ANDC、ORC、XORC 命令があります。
>> 割り込み要求が発生すると、割り込みコントローラが優先順位を判定した後、CPUに対
>> して割り込みを要求します。そのとき、CPUが割り込みを禁止している命令を実行してい
>> る場合は、その命令の実行を終了した後、必ず次の命令を実行します。
>> --引用ここまで--
>
> 3.E_CTXについて
>
>> 表示周りの動作が確認でき、デバイスとのシリアル通信もいくらかはできているの
>> ですが、シリアル通信中にフリーズしたり、E_CTXとなりisig_tim()がエラーを
>> 返したりしてしまいなかなかうまくいきません。
>>
>> E_CTX reported by `isig_tim()' in line 63 of `../jsp/systask/timer.c'.
>
> E_CTXは、各サービスコールの入り口でパラメータや呼び出し時のコンテキスト
> チェックの時にチェックされて、返されるエラーコードです。
> isig_timの場合、タスクコンテキストで呼び出されたか、CPUロック状態で呼び出された
> ときに返されます。
> タイマドライバは、TOPPERS/JSPカーネルにとってはタイムティックを供給する重要な
> 部分（時間待ちやタイムアウト付きのサービスコールを実装するのに不可欠）ですが、
> 形式上は他の(必須でない)ユーザ定義の割込みハンドラと同じように扱われます。
>
> つまり、isig_tim()でE_CTXが返されるならば、isig_tim()を呼び出す時点でおかしな
> 状態になっているということです。
> 他の割込みハンドラから非タスクコンテキストで呼び出し可能なサービスコールを
> 呼び出しても、同じエラーを返す状態だということです。
>
> 4.エラーメッセージ「E_CTX reported by `isig_tim()' in line 63 of
> `../jsp/systask/timer.c'.]
> について
>
> マクロ_syscall()でインライン関数syslog_*を呼び出し、最終的にサービスコールvwri_log
> 内の、低レベル出力で出力されたものだと思います。
> H8依存部では、デフォルトでJSPのシステム用のシリアルポートのハードウェアを直接たたいています。
>
> TOPPERS/JSPのsyslog機能は2段構えになっています。
>
> 1.メッセージをカーネル内のメモリ領域に記憶する
> 重要度に応じて、この時点で低レベル出力されるメッセージもある
>
> 2.ログタスクがサービスコールを用いて、カーネルのメモリ領域に保存されたメッセージ
> を呼び出し、出力する(H8の場合デフォルトで汎用シリアルポートを介して出力)
>
> 汎用シリアルポートは、タスクから呼び出されることを想定した、セマフォによる排他制御
> を実現する汎用シリアルドライバと、各依存部で提供されるシリアルハードウェアを制御
> する割込みハンドラからなります。
>
> 上記の仕組みから、メッセージの優先度により、重複して出力される場合があります。
> もしこのメッセージが
>
>
>
> 以上。
>
>
