(toppers-users 4728) Re: TOPPERS/ASP3ディスパッチ部におけるフリーズについて

Hiroaki TAKADA hiro ＠ ertl.jp
2018年 1月 18日 (木) 10:07:34 JST
前の記事 (toppers-users 4726) Re: TOPPERS/ASP3ディスパッチ部におけるフリーズについて
次の記事 (toppers-users 4733) Re: TOPPERS/ASP3ディスパッチ部におけるフリーズについて
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
株式会社ヌマタ様

まず，新しい対策コードを添付します。結果的には，前のコードでも，
シングルコアなら問題ありませんでした。マルチコアでの使用を考え
ると，今回のコードにする必要があります。これでテストくださると
幸いです。

> これは、弊社でエラッタ情報を入手したのではなく、前に使用していたOS（RTX）
> の該当ソースにエラッタに関する記述がありました。そのため、「記載があるようです」
> という表現としました。弊社でもエラッタ情報を探しましたが入手には至っておりません。
> ソース内容は、次の通りです。

私の方でも類似情報を探したところ，mbed に類似のコードを見つけま
した。

https://os.mbed.com/users/mbed_official/code/mbed-src/file/35c2c1cf29cd/targets/cmsis/TARGET_RENESAS/TARGET_RZ_A1H/TOOLCHAIN_ARM_STD/startup_MBRZA1H.s/

売り物のOSのコードを参考にするわけには行きませんので，mbed（こち
らはオープンソース）を参考に修正しました。

送って下さったコードと比べて，GIC 390 errata 733075 への対策が
違っています。mbed のコードの方が，RZ1A のマニュアルに忠実な対
策がされていますので，添付のものは，mbed の対策に合わせた対策
にしてあります。

高田広章
名古屋大学

On 2018/01/18 9:48, kaneko-nao wrote:
> 名古屋大学
> 高田広章 様
> 
> 毎々お世話になります。株式会社ヌマタです。
> 早々にご対応いただき、感謝申し上げます。
> 
>> GIC に Errata があるのは，気付いていませんでした。GIC の Errata
>> 情報がどこに記載されているか（または，どこから入手できるのか），
>> お知らせくださると幸いです。検索してみたのですが，すぐには出てこ
>> ないようです。
> 
> これは、弊社でエラッタ情報を入手したのではなく、前に使用していたOS（RTX）
> の該当ソースにエラッタに関する記述がありました。そのため、「記載があるようです」
> という表現としました。弊社でもエラッタ情報を探しましたが入手には至っておりません。
> ソース内容は、次の通りです。
> 
> ------------------------------------------------------
> LDR     R1, =GICI_BASE
> LDR     R0, [R1, #ICCHPIR_OFFSET]   ; Dummy Read ICCHPIR (GIC CPU Interface register) to avoid GIC 390 errata 801120
> LDR     R0, [R1, #ICCIAR_OFFSET]    ; Read ICCIAR (GIC CPU Interface register)
> DSB                                 ; Ensure that interrupt acknowledge completes before re-enabling interrupts
> 
> ; Workaround GIC 390 errata 733075
> ; If the ID is not 0, then service the interrupt as normal.
> ; If the ID is 0 and active, then service interrupt ID 0 as normal.
> ; If the ID is 0 but not active, then the GIC CPU interface may be locked-up, so unlock it
> ;   with a dummy write to ICDIPR0.  This interrupt should be treated as spurious and not serviced.
> ;
> CMP     R0, #0
> BNE     int_active                    ; If the ID is not 0, then service the interrupt
> LDR     R2, =GICD_BASE
> LDR     R3, [R2, #ICDABR0_OFFSET]   ; Get the interrupt state
> TST     R3, #1
> BNE     int_active                  ; If active, then service the interrupt
> ----------------------------------------------------------
> 
> 以上、よろしくお願いいたします。
> 
> 株式会社ヌマタ
> 
> 
> 
> 
> 
> 株式会社ヌマタ様，皆様
> 
> さきほどの修正コードですが，ちゃんと修正できていませんでした。
> 再度修正しますので，(toppers-users 4723) に添付したものは破棄
> してくださると幸いです。
> 
> 高田広章
> 名古屋大学
> 
> On 2018/01/18 8:31, Hiroaki TAKADA wrote:
>> 株式会社ヌマタ様
>>
>> 名古屋大学の高田です。原因（と思われること）が明らかになって，
>> ホッとしています。
>>
>>> (2) RZA1のマニュアルの「7.6.2 割り込み動作の流れ」の図7.3では，・・・・・
>>> 2命令を追加し、評価テストを行ったところ、フリーズは起こりませんでした。
>> （中略）
>>> また、この箇所は、GIC-390 errata 801120 として記載があるようです。
>>
>> GIC に Errata があるのは，気付いていませんでした。GIC の Errata
>> 情報がどこに記載されているか（または，どこから入手できるのか），
>> お知らせくださると幸いです。検索してみたのですが，すぐには出てこ
>> ないようです。
>>
>>> 現時点で、これが原因で何らかの不具合が起こったかどうかは分かりかねますが、
>>> できれば回避策を実装したいと考えています。一応、RZA1のマニュアルの「7.8.3
>>> 割り込み応答・・・の注意」の記述に沿ってコードを作成しましたが、これをどこに
>>> 挿入するかで悩んでいます。
>>> 恐れ入りますが、良い方法がありましたらご指摘いただきたく、お願いいたします。
>>
>> 私の方で作成した対策コードを添付します。Errata 対策ということで，
>> 既存のコードをなるべく修正しない方針で作成しました。そのため，実
>> 行効率的には，ややムダな部分があります。
>>
>> 割込みの入口処理で，システムによっては，性能がクリティカルな場合
>> があると思います。その場合は，御社の方で最適化していただければと
>> 思います（それができるのが，オープンソースソフトの利点だと考えて
>> います）。
>>
>> 高田広章
>> 名古屋大学
>>
>> On 2018/01/17 16:29, kaneko-nao wrote:
>>> 名古屋大学
>>> 高田広章 様
>>>
>>> 毎々お世話になります。株式会社ヌマタです。
>>> ご解析並びに対処法をご指摘いただき、ありがとうございました。
>>> コードを追加し、評価テストを行いましたので、ご報告いたします。
>>>
>>> ■ ご質問について
>>>> 念のための確認ですが，カーネル以外に，GIC にアクセスしているコードは
>>>> ありませんよね？
>>> ありません
>>>
>>> ■ ご指摘いただいた3点について
>>> (1) arm_user.txt に記載のある，以下の注意事項は守られているでしょうか？
>>> 問題ありません
>>>
>>> (2) RZA1のマニュアルの「7.6.2 割り込み動作の流れ」の図7.3では，・・・・・
>>> 2命令を追加し、評価テストを行ったところ、フリーズは起こりませんでした。
>>>
>>> 前回同様、割り込みと優先順位を
>>> INT1（OS高分解能割り込み） -2
>>> INT2（例えばSCI） -15
>>> INT3（例えばIIC） -15
>>> とした場合、
>>>   ・INT1+INT2+INT3 → OK（フリーズしない）
>>>
>>> となりました。
>>>
>>> また、この箇所は、GIC-390 errata 801120 として記載があるようです。
>>>
>>> (3) RZA1のマニュアルの「7.8.3 割り込み応答レジスタ (ICCIAR) で・・・・・
>>> こちらも、GIC-390 errata 733075 として記載があるようです。
>>>
>>> 現時点で、これが原因で何らかの不具合が起こったかどうかは分かりかねますが、
>>> できれば回避策を実装したいと考えています。一応、RZA1のマニュアルの「7.8.3
>>> 割り込み応答・・・の注意」の記述に沿ってコードを作成しましたが、これをどこに
>>> 挿入するかで悩んでいます。
>>> 恐れ入りますが、良い方法がありましたらご指摘いただきたく、お願いいたします。
>>>
>>> 株式会社ヌマタ
>>>
>>>
>>>
>>>
>>>
>>>
>>> 株式会社ヌマタ様
>>>
>>> I wrote:
>>>> いくつか気になることがあるのですが，それは別のメールにします。
>>>
>>> いろいろ調査して気になる点が3つ出てきましたので，お知らせします。
>>>
>>> (1) arm_user.txt に記載のある，以下の注意事項は守られているでしょうか？
>>> これが原因とは考えにくいのですが，念のため確認ください。
>>>
>>> ----------
>>> CPUからの割込みと内蔵周辺モジュール割込みは，レベルトリガで使用するかエッ
>>> ジトリガで使用するかが，チップで決められている．チップでの指定と異なる
>>> 設定をした場合の動作は保証されない（異なる設定をしても，エラーにはなら
>>> ない）．チップでの指定については，チップのマニュアルを参照すること．
>>> ----------
>>>
>>> (2) RZA1のマニュアルの「7.6.2 割り込み動作の流れ」の図7.3では，ICCIAR
>>> を読む前に，ICCHPIR を読むシーケンスになっています。ここで ICCHPIR を
>>> 読むべきであることは，ARMのマニュアルには（調べた限りでは）記載されて
>>> おらず，ASP3カーネルでは実施していません。RZA1の実装上の制約で，これが
>>> 必要になっている可能性は考えられます。これを実施するには，irc_begin_int
>>> の最初に次の2命令を入れてもらえればOKです。
>>>
>>> ----------
>>>      ldr     r1, =GICC_HPPIR
>>>      ldr     r0, [r1]
>>> ----------
>>>
>>> なぜ ICCHPIR を読む必要があるかわかりませんが，これが原因である可能性
>>> は考えられます。
>>>
>>> (3) RZA1のマニュアルの「7.8.3 割り込み応答レジスタ (ICCIAR) で割り込み
>>> IDの値を読み出すときの注意」の内容が気になりました。ASP3カーネルのター
>>> ゲット依存部では，この注意事項に対応していません。これも，これが原因だ
>>> とは考えにくいのですが，気にはなります。
>>>
>>> 高田広章
>>> 名古屋大学
>>>
>>> On 2018/01/15 0:06, Hiroaki TAKADA wrote:
>>>> 株式会社ヌマタ様
>>>>
>>>> 名古屋大学の高田です。返信が遅くなってしまいました。
>>>>
>>>> 現時点の結論から言いますと，情報提供いただいた状況から，割込みが発生
>>>> しない直接的な理由はわかりました（詳しくは以下に記載します）。が，そ
>>>> のようになる原因は，いろいろ調べているのですが，突き止められていませ
>>>> ん。
>>>>
>>>> いくつか気になることがあるのですが，それは別のメールにします。まずは，
>>>> いただいた情報にコメントさせていただきます。
>>>>
>>>>> 割り込みと優先順位を
>>>>> INT1 -2
>>>>> INT2 -2
>>>>> INT3 -2
>>>>> とした場合、
>>>>> ・INT1+INT2+INT3 → OK
>>>>
>>>> 割込み優先度をすべて同じにした場合（多重割込みが起こらない状況）では，
>>>> フリーズしないということですね。これは，非常に重要な情報です。
>>>>
>>>>> 割り込みと優先順位を
>>>>> INT1（OS高分解能割り込み） -2
>>>>> INT2（例えばSCI） -15
>>>>> INT3（例えばIIC） -15
>>>>> とした場合、
>>>>> ・INT1+INT2+INT3 → NG（フリーズする）
>>>>> ・INT1+INT2 → OK（フリーズしない）
>>>>> ・INT1+INT3 → OK
>>>>
>>>> 一方，多重割込みが起こる状況でも，必ずフリーズが起こるわけではないと
>>>> いうことですね。これは，正直なところ，不思議な現象です。
>>>>
>>>>> リリース3.2.0での、ディスパッチャのアイドル処理内では、
>>>>> msr   cpsr_c, #CPSR_SVC_MODE
>>>>>   b     dispatcher_1
>>>>> をループします。（この2行のみステップ実行可です）
>>>>
>>>> プログラム自身は動いているということで，これも重要な情報です。
>>>>
>>>>>> フリーズ時の割込みコントローラの状態
>>>>> ICCPMR 0x0000_00f8
>>>>> ICCHPIR 0x0000_0087
>>>>> ICCRPR 0x0000_0080
>>>>> ICCIAR 0x0000_03ff
>>>>> ICCIAR を最後にリードしています
>>>>
>>>> ICCRPR の値が 0x80 であることが，割込みが発生しない理由と思われます。
>>>> 以下，各レジスタの値の意味を解説します。
>>>>
>>>>> ICCPMR 0x0000_00f8
>>>>
>>>> 割込み優先度マスクレジスタが 0xf8 というのは，最低優先度を意味してお
>>>> り，このレジスタによってマスクされている割込みはありません。
>>>>
>>>>> ICCHPIR 0x0000_0087
>>>>
>>>> この時点で，割込み135（＝0x87）が GIC に対して要求されていることを意
>>>> 味しています。割込み 135 は，OSタイマ1ですね。
>>>>
>>>>> ICCRPR 0x0000_0080
>>>>
>>>> 実行中の割込み優先度が，16 であることを意味しています。TOPPERS/ASP3の
>>>> 優先度表現では，-15 に当たります。これにより，-15 と同じかより低い優
>>>> 先度の割込みは受け付けられません。これが，割込みが発生しない理由と思
>>>> われます。
>>>>
>>>>> ICCIAR 0x0000_03ff
>>>>
>>>> 0x3ff は割込みがないことを意味しています。これは，受け付けるべき割込み
>>>> がないという意味です。割込み135はGICに対して要求されているが，優先度が
>>>> 低いために，このようになると思われます。
>>>>
>>>> 以上より，実行中の割込み優先度が 16 になっていることが，割込みが発生し
>>>> ない直接的な理由と思われます。
>>>>
>>>> 実行中の割込み優先度は，割込みを受け付けた後（ICCIAR を読み出した後），
>>>> 割込みを完了するまでの間（ICCEOIR に書き込むまでの間）に，その割込みの
>>>> 優先度（厳密にはグループ優先度）になります。つまり，割込みを受け付けた
>>>> が，完了していない割込みを残したまま，アイドルループに戻ってきてしまっ
>>>> たことになります。ちなみに，割込みを実行していない時は，ICCRPR の値は
>>>> 0xff になっているはずです。
>>>>
>>>> こういう状況が起こるかですが，ASP3カーネルで ICCIAR を読み出すのは，
>>>> 初期化時を除くと，gic_support.S 中の irc_begin_int の中だけです。こ
>>>> こで ICCIAR を読むと，約10命令後に ICCEOIR に書き込んでいます。この
>>>> 間に分岐命令はなく，かつ irc_begin_int は割込み禁止状態で呼び出され
>>>> ますので，割込みを受け付けたが完了していないという状況は，起こりそう
>>>> にありません。
>>>>
>>>> 念のための確認ですが，カーネル以外に，GIC にアクセスしているコードは
>>>> ありませんよね？
>>>>
>>>> 割込みハンドラ／ISRの中で，ICCRPR を読み出してもらって，0xff 以外の
>>>> 値になっていれば，何か異常が起きていることになります。この情報が解決
>>>> へのヒントになるかもしれません。
>>>>
>>>> なお，ASP3カーネルでは，irc_begin_int内の10命令程度の間以外は，ICCRPR
>>>> は 0xff になっているはずです。
>>>>
>>>> 高田広章
>>>> 名古屋大学
>>>>
>>>> On 2018/01/09 9:09, kaneko-nao wrote:
>>>>> 名古屋大学
>>>>> 高田広章 様
>>>>>
>>>>> 毎々お世話になります。株式会社ヌマタです。
>>>>>
>>>>> ■ これまでの弊社からのご報告で、多重割り込みにつきましては、同一優先順位云々と申し上げてきましたが、OSが使用する割り込みがそれら（OS以外の割り込み）に含まれていないことに気付き、改めて1/5から評価テストをしたところ、フリーズしないことが分かりました。これまでの経緯を纏めると、次のようになります。
>>>>>
>>>>> 割り込みと優先順位を
>>>>> INT1（OS高分解能割り込み） -2
>>>>> INT2（例えばSCI） -15
>>>>> INT3（例えばIIC） -15
>>>>> とした場合、
>>>>> ・INT1+INT2+INT3 → NG（フリーズする）
>>>>> ・INT1+INT2 → OK（フリーズしない）
>>>>> ・INT1+INT3 → OK
>>>>>
>>>>> 割り込みと優先順位を
>>>>> INT1 -2
>>>>> INT2 -2
>>>>> INT3 -2
>>>>> とした場合、
>>>>> ・INT1+INT2+INT3 → OK
>>>>>
>>>>>
>>>>> ■ また、前回の回答で不十分であった箇所につきましても確認いたしました。
>>>>>
>>>>>> ディスパッチャ内でフリーズしてステップ実行できないということは，
>>>>>> アイドル処理内のループも回っていないということですね？（確認）
>>>>>
>>>>> リリース3.2.0での、ディスパッチャのアイドル処理内では、
>>>>>
>>>>> msr   cpsr_c, #CPSR_SVC_MODE
>>>>>   b     dispatcher_1
>>>>>
>>>>> をループします。（この2行のみステップ実行可です）
>>>>>
>>>>>> フリーズ時の割込みコントローラの状態
>>>>> ICCPMR 0x0000_00f8
>>>>> ICCHPIR 0x0000_0087
>>>>> ICCRPR 0x0000_0080
>>>>> ICCIAR 0x0000_03ff
>>>>>
>>>>> ICCIAR を最後にリードしています
>>>>>
>>>>>
>>>>> 以上、ご連絡します。よろしくお願いいたします。
>>>>>
>>>>> 株式会社ヌマタ
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 名古屋大学
>>>>> 高田広章 様
>>>>>
>>>>> 毎々お世話になります。株式会社ヌマタです。
>>>>> 年末年始でご連絡が遅くなり、申し訳ありませんでした。本年もよろしくお願いいたします。
>>>>> 現在もフリーズ再現待ち状態ですが、思うように再現しないため、ご質問について、現時点で分かる範囲で回答いたします。
>>>>>
>>>>>> ディスパッチャ内でフリーズしてステップ実行できないということは，
>>>>>> アイドル処理内のループも回っていないということですね？（確認）
>>>>>
>>>>> フリーズが起こり始めたのがバージョン3.1.0であったため、ディスパッチャのアイドル処理内では、
>>>>>
>>>>>      b     dispatcher_1
>>>>>
>>>>> で、固まっており、ステップ実行ができない状況でした。（3.2.0ではアイドルタスクを入れたため未確認です。そのため、アイドルタスクを外し、現在確認中です）
>>>>>
>>>>>
>>>>>> それに対してアイドルタスクを設けた場合は，ループを回っていると
>>>>>> いうことは，2つの状況で違う現象が出ているものと理解しました。ア
>>>>>> イドルタスクには，ディスパッチャ内のアイドル処理と同じものを入
>>>>>> れられたということですが，以下の2命令をループしているということ
>>>>>> で正しいでしょうか？
>>>>>
>>>>> アイドルタスクでは、動作中のタスク状態を参照するための処理をしており、
>>>>> フリーズ時は以下をループしています。（正常動作しています）
>>>>>
>>>>> while(  1 ){
>>>>>     ref_tsk( TASK_1 )
>>>>>     ref_tsk( TASK_2 )
>>>>> .
>>>>> .
>>>>> }
>>>>>
>>>>>
>>>>>> フリーズ時の割込みコントローラの状態
>>>>> ICCPMR 0x0000_00f8
>>>>> ICCHPIR 0x0000_00be
>>>>> ICCRPR 0x0000_0070
>>>>> ICCIAR 0x0000_03ff
>>>>>
>>>>> 但し、一斉にリードしたため、ご指摘のICCIARが最後のリードとなるよう、改めて確認します。
>>>>>
>>>>>
>>>>> 以上、よろしくお願いいたします。
>>>>>
>>>>> 株式会社ヌマタ
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message----- From: Hiroaki TAKADA
>>>>> Sent: Thursday, December 28, 2017 10:01 AM
>>>>> To: users ＠ toppers.jp
>>>>> Subject: (toppers-users 4715) Re: TOPPERS/ASP3ディスパッチ部におけるフリーズについて
>>>>>
>>>>> 株式会社ヌマタ様
>>>>>
>>>>> 名古屋大学の高田です。いただいた情報から，原因を検討してみました。
>>>>> フリーズしてICEでステップ実行もできない，という状況は，純粋なソフ
>>>>> トウェアの問題ではないものと思われます。
>>>>>
>>>>> まず状況を確認させてください。
>>>>>
>>>>>> 先ほど、「フリーズ状態になると、そのアドレスで固まってしまい、ICEでも、
>>>>>> ステップ実行すらできない状況です。」と表現しましたが、これはディスパッチャ内で
>>>>>> フリーズした場合であり、アイドルタスクを設けた場合は、そのアイドルタスク内を
>>>>>> ループしている状況です。誤解を招く表現でしたので一部訂正いたします。
>>>>>
>>>>> ディスパッチャ内でフリーズしてステップ実行できないということは，
>>>>> アイドル処理内のループも回っていないということですね？（確認）
>>>>>
>>>>> それに対してアイドルタスクを設けた場合は，ループを回っていると
>>>>> いうことは，2つの状況で違う現象が出ているものと理解しました。ア
>>>>> イドルタスクには，ディスパッチャ内のアイドル処理と同じものを入
>>>>> れられたということですが，以下の2命令をループしているということ
>>>>> で正しいでしょうか？
>>>>>
>>>>>      msr   cpsr_c, #CPSR_SVC_MODE
>>>>>      b     dispatcher_1
>>>>>
>>>>> 現時点では，状況から判断して，カーネルそのものの不具合の可能性
>>>>> は低いと考えています。その理由は次の通りです。
>>>>>
>>>>> (1) すべての割込みを同じ優先度にしても発生するということは，多
>>>>> 重割込みの処理が原因ではないことになる。そうなると，ディスパッ
>>>>> チャ内の実行パスは限られており，不具合の再現性はもっと高くなる
>>>>> と思われる。
>>>>>
>>>>> (2) アイドルタスクを設けた場合には，ASP3カーネルで導入した新し
>>>>> いディスパッチャのロジックは使われていないはずで，その場合にも
>>>>> 発生するということは，ディスパッチャのロジックの問題は考えにく
>>>>> い。
>>>>>
>>>>> (3) （最初に書いた通り）フリーズしてステップ実行もできないとい
>>>>> うのは，純粋なソフトウェアの問題ではないと思われる。
>>>>>
>>>>> もちろん，カーネルの不具合でないと断言はできません（予断を持た
>>>>> ずに当たるべきですので）。
>>>>>
>>>>>> 但し、前述の通り、割り込みは、受け付けません。
>>>>>
>>>>> 原因解明のためにいろいろ調べてみたいことは考えられるのですが，
>>>>> まず調べやすいと思われるのは，アイドルタスク内でループしている
>>>>> 時に，割込みが受け付けられないのはなぜか？だと考えます。ループ
>>>>> している時にICEでプロセッサの状態が観測できるのであれば，PSWの
>>>>> 値が何になっているか（上の2命令をループしていれば，割込み許可
>>>>> 状態のはず）と，割込みコントローラの状態（具体的には，ICCPMRの
>>>>> 値が何になっているか。また，ICCHPIR，ICCRPR，ICCIARの値も手掛か
>>>>> りになる可能性があります。ただし，ICCIARの値をリードすると，割
>>>>> 込みコントローラの状態が変わるので，最後にリードすべき）を見て
>>>>> もらえると，手掛かりになりそうに思います。
>>>>>
>>>>> 高田広章
>>>>> 名古屋大学
>>>>>
>>>>> On 2017/12/26 10:21, kaneko-nao wrote:
>>>>>> 名古屋大学
>>>>>> 高田広章 様
>>>>>>
>>>>>> 何度も失礼いたします。株式会社ヌマタです。
>>>>>>
>>>>>> 先ほど、「フリーズ状態になると、そのアドレスで固まってしまい、ICEでも、
>>>>>> ステップ実行すらできない状況です。」と表現しましたが、これはディスパッチャ内で
>>>>>> フリーズした場合であり、アイドルタスクを設けた場合は、そのアイドルタスク内を
>>>>>> ループしている状況です。誤解を招く表現でしたので一部訂正いたします。
>>>>>> 但し、前述の通り、割り込みは、受け付けません。
>>>>>>
>>>>>> 以上、よろしくお願いいたします。
>>>>>>
>>>>>> 株式会社ヌマタ
>>>>>>
>>>>>>
>>>>>>
>>>>>> 名古屋大学
>>>>>> 高田広章 様
>>>>>>
>>>>>> ご連絡、ありがとうございます。株式会社ヌマタです。
>>>>>>
>>>>>>> 質問を変えさせてください。ここで「フリーズする」というのは，無限
>>>>>>> ループから抜けてこなくなるということだと思うのですが，その時に，
>>>>>>> 割込みも発生していないということでしょうか？
>>>>>>
>>>>>> 割り込みは、タイマ周期割り込みやVSYNC割り込みのような、周期的に入る
>>>>>> ものがあるので、それらが起動してもおかしくないのですが、フリーズ状態
>>>>>> になると、そのアドレスで固まってしまい、ICEでも、ステップ実行すらできない
>>>>>> 状況です。
>>>>>>
>>>>>> 以上、取り急ぎ、回答いたします。
>>>>>>
>>>>>> 株式会社ヌマタ
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: Hiroaki TAKADA
>>>>>> Sent: Tuesday, December 26, 2017 9:18 AM
>>>>>> To: users ＠ toppers.jp
>>>>>> Subject: (toppers-users 4711) Re: TOPPERS/ASP3ディスパッチ部におけるフリーズについて
>>>>>>
>>>>>> 株式会社ヌマタ様
>>>>>>
>>>>>> 名古屋大学の高田です。すみませんが，昨日のメールを修正させてくだ
>>>>>> さい。
>>>>>>
>>>>>>> (1) slp_tsk() で割り込み待ちをしているということですが，その時
>>>>>>> に，他に動作しているタスクが無い状況があるでしょうか？（ディス
>>>>>>> パッチャ内のアイドル処理を実行しているかどうか）
>>>>>>
>>>>>> これは，不要な質問でした。「core_support.s」の223行目の割り込み待
>>>>>> ちのところでフリーズ，ということは，当然 YES ということですね。
>>>>>>
>>>>>> 質問を変えさせてください。ここで「フリーズする」というのは，無限
>>>>>> ループから抜けてこなくなるということだと思うのですが，その時に，
>>>>>> 割込みも発生していないということでしょうか？
>>>>>>
>>>>>> もし割込みが発生していないとすると，ループ内で割込みを許可してい
>>>>>> ますので，割込みコントローラ側の設定がおかしくなっているものと思
>>>>>> われます。
>>>>>>
>>>>>> 割込みが発生しているのであれば，割込みの出口処理でタスク切り換え
>>>>>> に失敗しているものと思われます。
>>>>>>
>>>>>> この件，わかりましたら，お知らせ下さると幸いです。
>>>>>>
>>>>>> 高田広章
>>>>>> 名古屋大学
>>>>>>
>>>>>> On 2017/12/25 17:51, Hiroaki TAKADA wrote:
>>>>>>> 株式会社ヌマタ様
>>>>>>>
>>>>>>> ご報告，ありがとうございます。
>>>>>>>
>>>>>>> TOPPERS/ASP3 のディスパッチャのロジックは，ASP のものと考え方を
>>>>>>> 変えており，何か問題が残っている可能性は無いとは言えません。ま
>>>>>>> た，Release 3.1.0 と 3.2.0 でもロジックの修正を行っており，歴史
>>>>>>> が浅いコードになります。
>>>>>>>
>>>>>>> こちらでも調査したいと思いますが，まれにしか起こらない現象とい
>>>>>>> うことで，原因を絞り込むのにご協力いただけるとありがたいです。
>>>>>>>
>>>>>>> (1) slp_tsk() で割り込み待ちをしているということですが，その時
>>>>>>> に，他に動作しているタスクが無い状況があるでしょうか？（ディス
>>>>>>> パッチャ内のアイドル処理を実行しているかどうか）
>>>>>>>
>>>>>>> (2) もし可能なら，Release 3.1.0 でも同じ問題が発生するか，調べ
>>>>>>> てくださると助かります。
>>>>>>>
>>>>>>> よろしくお願いします。
>>>>>>>
>>>>>>> 高田広章
>>>>>>> 名古屋大学
>>>>>>>
>>>>>>> On 2017/12/25 15:05, kaneko-nao wrote:
>>>>>>>> はじめまして。
>>>>>>>> 株式会社ヌマタと申します。弊社では次の環境で設計をしていますが、ディスパッチ部でフリーズをするという現象があります。
>>>>>>>>
>>>>>>>> OS：TOPPERS/ASP3 3.2.0
>>>>>>>> CPU：ルネサス RZA1/L
>>>>>>>>
>>>>>>>> slp_tsk( )で割り込み待ちをし、割り込み内で当該タスクをiwup_tsk( )で起床する、というタスクを複数作成していると、ディスパッチ部でフリーズをするという現象が発生しました。フリーズする箇所は、「core_support.s」の223行目の割り込み待ちのところです。フリーズの頻度は、数時間に1回程度で、24時間正常動作を続ける場合もあります。
>>>>>>>>
>>>>>>>>     ALABEL(dispatcher_1)
>>>>>>>> #ifdef TOPPERS_CUSTOM_IDLE
>>>>>>>>     toppers_asm_custom_idle
>>>>>>>> #else /* TOPPERS_CUSTOM_IDLE */
>>>>>>>>     msr        cpsr_c, #CPSR_SVC_MODE    /* 割込みを許可（スーパバイザモード）*/
>>>>>>>> #endif /* TOPPERS_CUSTOM_IDLE */
>>>>>>>>     b        dispatcher_1            /* 割込み待ち */ ←ここでフリーズ
>>>>>>>>
>>>>>>>> そこで試行錯誤の結果、割り込みを1個（OSが使用するタイマ割り込みを除く）にすればフリーズしない、ということが分かりました。現在、弊社のお取引先でも、全く同じ現象のトラブルがあるとの報告を受けておりますが、過去にこのような事例についてのご対応はおありでしょうか。ご指導を賜りたく、お願いいたします。因みに、「core_support.s」は、一切変更せずに使用しています。
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
> 
> 
-------------- next part --------------
Index: arch/arm_gcc/common/gic_support.S
===================================================================
--- arch/arm_gcc/common/gic_support.S	(revision 874)
+++ arch/arm_gcc/common/gic_support.S	(revision 876)
@@ -4,7 +4,7 @@
  * 
  *  Copyright (C) 2000-2003 by Embedded and Real-Time Systems Laboratory
  *                              Toyohashi Univ. of Technology, JAPAN
- *  Copyright (C) 2006-2017 by Embedded and Real-Time Systems Laboratory
+ *  Copyright (C) 2006-2018 by Embedded and Real-Time Systems Laboratory
  *              Graduate School of Information Science, Nagoya Univ., JAPAN
  * 
  *  上記著作権者は，以下の(1)～(4)の条件を満たす場合に限り，本ソフトウェ
@@ -69,9 +69,37 @@
 	/*
 	 *  割込み要因を取得する．
 	 */
+#ifdef GIC_PL390_ERRATA			/* GIC 390 Errata 801120への対策 */
+	ldr		r1, =GICC_HPPIR
+	ldr		r0, [r1]	
+#endif /* GIC_PL390_ERRATA */
 	ldr		r1, =GICC_IAR
 	ldr		r3, [r1]
+	lsl		r4, r3, #22			/* 下位10ビットを取り出す */
+	lsr		r4, r4, #22
 
+#ifdef GIC_PL390_ERRATA			/* GIC 390 Errata 733075への対策 */
+	movw	r0, #1023
+	cmp		r4, r0
+	beq		irc_begin_int_errata_1
+	movw	r0, #1022
+	cmp		r4, r0
+	beq		irc_begin_int_errata_1
+	cmp		r4, #0
+	bne		irc_begin_int_errata_2
+	ldr		r1, =GICD_ISACTIVER(0)		/* 割込み要求があるかチェック */
+	ldr		r0, [r1]
+	tst		r0, #0x01
+	bne		irc_begin_int_errata_2
+	movw	r4, #1024					/* 無効な割込みとみなす */
+ALABEL(irc_begin_int_errata_1)
+	ldr		r1, =GICD_IPRIORITYR(0)		/* 割込み優先度レジスタ0に書き込み */
+	ldr		r0, [r1]
+	str		r0, [r1]
+	asm_data_sync_barrier r0
+ALABEL(irc_begin_int_errata_2)
+#endif /* GIC_PL390_ERRATA */
+
 	/*
 	 *  割込み要因の割込み優先度を求め，割込み優先度マスクに設定する．
 	 */
@@ -90,10 +118,8 @@
 	str		r3, [r1]
 
 	/*
-	 *  割込み番号を返値としてリターンする．
+	 *  r4に割込み番号を入れた状態でリターンする．
 	 */
-	lsl		r4, r3, #22			/* 下位10ビットを取り出す */
-	lsr		r4, r4, #22
 	bx		lr
 
 /*
Index: arch/arm_gcc/common/gic_kernel_impl.h
===================================================================
--- arch/arm_gcc/common/gic_kernel_impl.h	(revision 874)
+++ arch/arm_gcc/common/gic_kernel_impl.h	(revision 876)
@@ -125,7 +125,7 @@
 #define GICC_IAR		GIC_REG(GICC_BASE, 0x0C)
 #define GICC_EOIR		GIC_REG(GICC_BASE, 0x10)
 #define GICC_RPR		GIC_REG(GICC_BASE, 0x14)
-#define GICC_HPIR		GIC_REG(GICC_BASE, 0x18)
+#define GICC_HPPIR		GIC_REG(GICC_BASE, 0x18)
 
 /*
  *  CPUインタフェース制御レジスタ（GICC_CTLR）の設定値（GICv1でセキュリ
Index: arch/arm_gcc/rza1/chip_kernel_impl.h
===================================================================
--- arch/arm_gcc/rza1/chip_kernel_impl.h	(revision 874)
+++ arch/arm_gcc/rza1/chip_kernel_impl.h	(revision 876)
@@ -5,7 +5,7 @@
  * 
  *  Copyright (C) 2000-2003 by Embedded and Real-Time Systems Laboratory
  *                              Toyohashi Univ. of Technology, JAPAN
- *  Copyright (C) 2006-2016 by Embedded and Real-Time Systems Laboratory
+ *  Copyright (C) 2006-2018 by Embedded and Real-Time Systems Laboratory
  *              Graduate School of Information Science, Nagoya Univ., JAPAN
  * 
  *  上記著作権者は，以下の(1)～(4)の条件を満たす場合に限り，本ソフトウェ
@@ -69,6 +69,11 @@
 #define GIC_ARM11MPCORE
 
 /*
+ *  GIC 390 Errataへの対策を実施する．
+ */
+#define GIC_PL390_ERRATA
+
+/*
  *  GIC依存部の割込み管理機能の初期化は使用しない．
  */
 #define OMIT_GIC_INITIALIZE_INTERRUPT
前の記事 (toppers-users 4726) Re: TOPPERS/ASP3ディスパッチ部におけるフリーズについて
次の記事 (toppers-users 4733) Re: TOPPERS/ASP3ディスパッチ部におけるフリーズについて
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]