(toppers-users 3086) Re: [H8]E_CTX reported by `isig_tim()' in line 63 of `../jsp/systask/timer.c'. 頻発

[中村和博]

おはようございます。中村です。

To：小南 様

先日、ご指摘いただいた環境の違いですが、
早速、gcc2.95.4のソースを手に入れてローカルでビルドしてみたのですが
コンパイルエラーとなってビルドができませんでした。
手元のgccが新しすぎるのかと、gcc3.3でもビルドしてみたのですが、
やはり変わらず、ビルドエラー(^^;。
2.95.4の環境を新たに作るのは難しいようです。
コンパイラ本体は普通に考えて対象バージョンよりバージョンでコンパイル
される事が前提なので仕方ないのかもしれません(^^;。

そこで、とりあえずTOPPERSのページで紹介されていた、gcc3.2.3にて
環境を作ってみました。ホームページに掲載されているパッチも直接は
関係なさそうですが当ててあります。
これからいろいろと試してみたいとおもいます。

2010/2/14 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の場合デフォルトで汎用シリアルポートを介して出力)
>
> 汎用シリアルポートは、タスクから呼び出されることを想定した、セマフォによる排他制御
> を実現する汎用シリアルドライバと、各依存部で提供されるシリアルハードウェアを制御
> する割込みハンドラからなります。
>
> 上記の仕組みから、メッセージの優先度により、重複して出力される場合があります。
> もしこのメッセージが
>
>
>
> 以上。
>
>