source: azure_iot_hub_f767zi/trunk/asp_baseplatform/arch/arm_m_gcc/common/core_design.txt@ 457

Last change on this file since 457 was 457, checked in by coas-nagasima, 4 years ago

ファイルを追加

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/plain;charset=UTF-8
File size: 38.3 KB
Line 
1=====================================================================
2 ARM-Mプロセッサ依存部設計メモ
3 Last Modified:2015 Nov 23 08:57:56
4=====================================================================
5
6○このドキュメントの位置づけ
7
8このドキュメントは,TOPPERS/ASPカーネルをARMvX-Mプロセッサに移植するため
9の設計メモである.
10
11
12○ARMVx-Mの仕様まとめ(FPU以外)
13
14ARMvX-Mの仕様のうち,カーネルの設計に関係する事項について,まずARMv7-M
15についてまとめる.ARMv6-Mは最後にARMv7-Mとの差分として説明する.
16
17●参考資料
18
19ARMv7-M Architecture Reference Manual E.b
20DDI0403E_B_armv7m_arm.pdf
21
22●レジスタ
23
24汎用レジスタはR0~R15の16種類あり,R13のみが2バンク構成(PSP,MSP)とな
25っている.R15はPC, R14はリンクレジスタ(LR)となっている.R0~R3,R12は
26スクラッチレジスタである.
27
28●コーリングコンベンション
29
30R0~R4が引数,それ以上はスタック.戻り値は,R0~R1に格納される.(ARMに
31より規定されているため,コンパイラに依存せずこのルールとなる.)
32
33●CONTROLレジスタ
34
35PSP,MSPの切り替え,PrivilageとUserモードのレジスタ.変更後は,インスト
36ラクションバッファフラッシュ命令を実行する必要がある(isb).CONTROLレ
37ジスタの詳細は,ARMv7-M Architecture Application Level Reference
38Manual の B1-9 を参照のこと.
39
40●割込みベクタ
41
42ベクタテーブル型で,ベクタテーブルのアドレスは,リセット時は0x00で,
43Vector Table Offset Register(メモリマップドレジスタ) を操作すること
44で,任意のアドレスに配置可能である.
45
46●優先度
47
48値が小さい方が高優先度となり,0が最高優先度となる.一方,後述するプロ
49セッサの割込み優先度を設定するBASEPRIレジスタは'0'をセットすると,全て
50の割込みを許可するため,最高優先度は,有効なビットのLSBを'1'とした値で
51ある(3bitの場合は0x20).また,割込みの優先度に'0'を設定すると,
52BASEPRIレジスタでマスクできない割込みとなる.
53
54優先度は最大8bitであり,SoC毎に実装されているビット幅が異なる.実装さ
55れるビットが8bit以下の場合は,LSBから無効になる.例えば,実装されてい
56るビット幅が7bitの場合は,ビット0が無効となる.
57
58優先度のビットフィールドのLSBから数ビットをサブ優先度と呼ぶフィールド
59に設定することが可能である.残りの上位ビットをプリエンプション優先度と
60呼ぶ.プリエンプション優先度が同じで,サブ優先度が異なる優先度のグルー
61プは,お互いをプリエンプトすることができない.
62
63Reset,NMI,Hard Fault 以外の例外は割込みと同様に優先度が設定可能であり,
64割込みマスク機能により,発生を禁止することが可能である.
65
66
67●CPUモード
68
69プロセッサは,ThreadモードもしくはHandlerモードのいずれかのモードとな
70る.
71
72●リセット時の状態
73
74リセット時はThreadモード,MSPが有効となっている.
75
76●Handlerモード
77
78例外/割込みを受け付けると遷移するモード.受け付けた例外/割込みの例外番
79号が,IPSRにセットされる.例外番号は,TRMで定められている番号である.
80
81 例外 例外番号
82 Reset 1
83 Non-makable Interrupt 2
84 Hard Fault 3
85 Memory Management 4
86 Bus Fault 5
87 Usage Fault 6
88 SVCall 11
89 Debug Monitor 12
90 PendSV 14
91 SysTick 15
92 IRQ0 16
93 IRQ1 17
94 ..
95
96例外/割込みを受け付けると,受け付けた例外/割込みの優先度以下の例外/割
97込みを禁止する.この優先度マスクを"NVIC優先度マスク"と呼ぶ.この優先度
98は,ソフトウェアから変更することができず,例外/割込みのリターンにより
99割込み前の値に自動的に戻る.
100
101●スタックポインタ(PSPとMSP)
102
103スタックポインタは,PSPとMSPがあり,排他的に使用可能である.Handlerモ
104ードではMSPのみ使用可能であり,ThreadモードではCONTROLレジスタで選択可
105能である.CONTROLレジスタの1ビット目をセットするとPSPが有効に,クリア
106すると,MSPが有効になる.
107
108●ThreadモードとHandlerモードの遷移
109
110ThreadモードからHandlerモードへの遷移は,例外/割込みを受け付けることで
111発生する.一方,HandlerモードからThreadモードへの遷移は,PCに
112EXC_RETURN(0xfffffffx)の値を設定することにより行う(例外リターン処理と
113呼ぶ).EXC_RETURNの下位4bitにより,遷移先のモードや使用するスタックポ
114インタを変更可能である.例外リターンにより,PRIMASKやBASEPRIの値は変化
115しない.一方,FAULTMASKの値は'0'にクリアさせる.
116
117●EXC_RETURN
118
119例外/割込み受付け時にlrに設定される値.ビット31~4ビットは全て'1'で,
120下位4bitは,受付け時のCPUモードやスタックを反映した値となっている.
121
122 0b0001 : Handlerモード
123 0b1001 : Threadモード with MSP
124 0b1101 : Threadモード with PSP
125
126●ThreadモードとHandlerモードの判定
127
128現状のモードを判定するには,IPSRを見て,'0'ならThreadモード,それ以外
129なら,Handlerモードとなる.
130
131●BASEPRIレジスタ
132
133設定した優先度以下の優先度の割込みの受付を禁止する.この優先度マスクを
134"BASEPRI優先度マスク"と呼ぶ.'0'を設定すると,全ての割込みを許可する.
135例外/割込みの受付とリターンにより変化しない.例外/割込みに対する割込み
136優先度マスクは,NVIC優先度マスクとBASEPRIの設定値の高い方(値が小さい
137方)となる.
138
139●FAULTMASK
140
141FAULTMASKは'1'をセットすることにより,NMI以外の全ての割込みを禁止する.
142FAULTMASKは,例外のリターン処理により'0'にクリアさせる.
143
144●PRIMASKとWFI
145
146PRIMASKを'1'に設定すると,NMI と Hardware Fault 以外の例外/割込みを禁
147止する.PRIMASKは割込みの許可と割込み待ちをアトミックに行うために用い
148る.具体的には,PRIMASKがセットされている状態でwfiを実行すると,割り込
149み待ちとなり,割込み受付けるとハンドラを実行せずに,wfiからリターンし
150てくる.
151
152●例外/割込みの受付
153
154・例外/割込みを受付けると,受付け時にアクティブなスタック上に以下のコ
155 ンテキストを保存する(例外フレームと呼ぶ).
156
157 -----------
158 | R0 | <- new SP
159 -----------
160 | R1 |
161 -----------
162 | R2 |
163 -----------
164 | R3 |
165 -----------
166 | R12 |
167 -----------
168 | LR |
169 -----------
170 | PC |
171 -----------
172 | xPSR |
173 -----------
174 | | <- old SP
175
176・プロセッサをHandlerモードとする.MSPが有効となる.
177・受付けた例外/割込みの例外番号をIPSRに設定する.
178・NVIC割込み優先度マスクを受付けた例外/割込みの優先度に設定する.
179・lrにEXC_RETURNの値が設定される.
180・ベクタテーブルを読み込みハンドラを実行する.
181・スタックフレームは,Configureation and Control Register(CCR)の
182 STKALIGNが'1'の場合は,8byte境界にアラインされる.
183
184●例外/割込みからのリターン
185
186pcにEXC_RETURNの値を設定することにより,例外/割込みからリターンする.
187pcへの設定に使用可能な命令には制限があり,以下命令が使用可能である.
188
189 ・POP/LDM, LDR, BX
190
191●未解決課題
192
193・ベクターテーブルに登録する関数のアドレスのLSBは'1'にするべきか?
194・NVICは例外・割込みのネスト回数を内部的に管理しているらしい.
195 (!リファレンスを明らかに).
196 ソフトウェアでは,ネストの帳尻を合わせれば,リターンスタックを偽造し
197 ても問題ないか.
198
199●stmfdの制限
200
201stmfdはレジスタリストが1個の場合の動作は不定となっている.そのため,レ
202ジスタリストが1個の記述をアセンブラにした場合は,アセンブラがstr.w に
203変換するが,アセンブラによってはワーニングを出すため,レジスタリストが
2041個の場合は,str.wを使用する.
205
206なお,ldmfdにはこの制限がない.
207
208●ARMv6-M
209
210カーネルの設計に対して,ARMv6-MのARMv7-Mに対する差分は次の通りである.
211
212・BASEPRIレジスタ
213 ARMv6-MではBASEPRIレジスタを持たない.
214
215・FAULTMASK
216 ARMv6-MではFAULTMASKレジスタを持たない.
217
218・命令
219 一部命令が使用出来ない.
220 同じ命令でも指定可能なレジスタに制限がある
221
222・外部割込み数
223 最大32個
224
225
226○FPU関連の仕様
227
228●参考資料
229
230ARMv7-M Architecture Reference Manual E.b
231DDI0403E_B_armv7m_arm.pdf
232
233ARM CortexR-M4 Processor Technical Reference Manual Revision: r0p1
234arm_cortexm4_processor_trm_100166_0001_00_en.pdf
235
236Cortex-M4(F) Lazy Stacking and Context Switching Application Note 298
237DAI0298A_cortex_m4f_lazy_stacking_and_context_switching.pdf
238
239●概要
240
241Cortex-M4はARMv7E-Mをベースとしている.FPUサポートした実装とサポートし
242ていない実装がある.FPUをサポートした実装をCortex-M4Fと呼ぶ.
243在する.
244
245FPUはARMv7E-M Floatng Point Extension(FPv4-SP)をサポートしている.
246
247FPv4-SPは次の仕様となっている.
248
249レジスタ : 単精度レジスタ S0~S32 / 倍精度レジスタ D0~D15
250 D0は(S0とS1)と等価.
251命令 : 単精度命令をサポート
252
253●制御レジスタ
254
255FPSCR : Floating-point Status and Control Register
256・FPUのステータスとコントロールフィールドを持つ
257
258CPACR : Coprocessor Access Control Register
259・FPUを有効にする場合にセットする必要がある
260
261FPCCR : Floating-point Context Control Register
262・FPU関連のコンテキストの保存方法を選択可能
263
264FPCAR : Floating Point Context Address Register
265・例外フレームのFPUレジスタの保存アドレス(S0のアドレス)を保持.
266
267FPDSCR : Floating-point Default Status Control Register
268・FPSCRのディフォルト値を保存
269・FPUを初めて使用した場合に[26:22]がFPSCRにコピーされる.
270
271CONTROLの拡張
272・.FPCA(Bit[2])
273 ・FPUを使用すると'1'にセットされる.
274
275EXC_RETURNの拡張
276
277EXC_RETURN[4]
278 '0' : FPUの領域あり(保存されているかは別の制御)
279 S0~S15とFPSCRのための領域.
280 '1' : FPUの領域なし
281
282●ABI
283
284S0~S15,FPSCR : caller saved registers
285S16~S17 : callee saved registers
286
287●例外・割込み発生時の振る舞い
288
289詳細は ARMv7-M Architecture Reference Manual E.bの B1.5.6 Exception
290entry behavior と B1.5.8 Exception return behavior を参照のこと.
291
292コンテキストの保存パターン
293 FPCCR
294 LSPEN ASPEN 名称(本ドキュメントオリジナル)
295 0 0 : NoAutomatic
296 0 1 : DisableLazystacking
297 1 1 : Lazystacking
298
299NoAutomatic
300・自動保存なし
301
302DisableLazystacking
303・自動保存あり.Lazystackingしない.
304・FPUを使用すると CONTROL.FPCA に'1'がセットされる.
305・CONTROL.FPCA == 1の場合に例外/割込みが発生するとFPUコンテキストをス
306 タックに保存する.
307
308Lazystacking
309・自動保存あり.Lazystacking を行う.
310・FPUを使用すると CONTROL.FPCA に'1'がセットされる.
311・CONTROL.FPCA == '1'の場合に例外/割込みが発生するとFPUコンテキストの保
312 存用の領域のみ確保され,FPCCR.LSPACT に'1'に設定される.
313・FPCCR.LSPACT == '1' の場合にFPU命令を使用するとFPUのコンテキストが保
314 存領域に保存される.
315
316FPUに関する例外/割込みの入り口処理
317
318・DisableLazystacking or Lazystacking の場合
319 ・CONTROL.FPCA == 1の場合
320 ・例外フレームにFPUレジスタ保存用の領域を確保
321 ・DisableLazystacking の場合
322 ・FPUレジスタ保存用の領域にFPUレジスタ(S0~S15,FPSCR)を保存
323 ・Lazystacking
324 ・FPCAR に例外フレームのFPUレジスタの保存アドレス(S0のアドレス)を保持.
325 ・FPCCR.LSPACT を1に.
326・CONTROL.FPCAを0にクリア
327
328FPUに関する例外/割込みの出口処理
329
330・EXC_RETURNの4ビット目が'0'の場合(戻り先でFPUを使用していた)
331 ・FPCCR.LSPACT == '1'の場合(割込みハンドラでFPUを使用しなかった)
332 ・FPCCR.LSPACTを'0'に
333 ・FPCCR.LSPACT == '0'の場合(割込みハンドラでFPUを使用した)
334 ・S0~S32とFPSCRを例外フレームから戻す
335・EXC_RETURNの4ビット目の否定をCONTROL.FPCAに設定
336 ・実質,戻り先のCONTROL.FPCAを復帰
337
338ISRでのFPUの振る舞い
339
340FPCCR.LSPACT==1時(Lazystackingの時にのみ発生)にFPU命令を使用した場合
341・FPCARのアドレスにFPUレジスタ(S0~S15,FPSCR)を保存
342・FPCCR.LSPACT を0にする.
343
344○OSの実装
345
3461.ターゲット名
347
348 1-1 cm3(Cortex-M3)
349 1-2 armv7m(ARMv7-M)
350 1-3 arm_m
351
352cm3では,ARMv6-Mをサポートする場合に問題となる.armv7mでは,armv8mがリ
353リースされた場合に問題となる.ARM依存部はJSPでは,armv4となっていたが,
354armv5やarmv7も動作するためASPでは単にarmとした.そのため,arm_mが無難
355と考えられる.
356
357
3582.ThreadモードとHandlerモードの使い分け
359
360 2-1
361 タスクコンテキストはThreadモード,非タスクコンテキストはHandlerモー
362 ドで動作させる.
363
364 2-2
365 タスクコンテキストと非タスクコンテキスト共にHandlerモードで動作させ
366 る.
367
368プロセッサの設計方針を考慮すると2-1が有力.2-1での問題点としては,割込
369みハンドラからタスクへのリターン時にモードの変更が以下の様に多発するこ
370とが挙げられる.
371
3721.割込みハンドラ : Handlerモード
3732.タスク例外ハンドラの呼び出し : Threadモード
3743.タスクへのリターン処理 : Handlerモード
3754.タスクの再開 : Threadモード
376
3773でHandlerモードに移行する必要があるのは,例外フレームを用いて復帰する
378には,Handlerモードで例外リターン処理を行う必要があるためである.ARMで
379は,複数レジスタのロードとCPSRの復帰を同時に行えるが,M3は行えないため,
380この方法で割込み先のタスクにリターンする必要がある.
381
3822-2の場合の割込みハンドラからタスクへのリターン時にモードの変更を以下
383に示す.また,2-2では割込み優先度の最低値をタスクの実行時の優先度とし
384てリザーブする必要がある.
385
3861.割込みハンドラ : Handlerモード
3872.NVIC優先度マスク'0'を0へ : Threadモード
3883.最低優先度のHandlerモードへ : Handlerモード
3894.タスク例外ハンドラの呼び出し : Handlerモード
3905.タスクへのリターンの前処理 : Threadモード
3913.タスクへのリターン : Handlerモード
3924.タスクの再開 : Handlerモード
393
394割込みハンドラからタスクのリターンに関しては,2-2であっても,2を実行す
395る場合に,NVIC優先度マスクを'0'にするため,例外リターン処理を行う必要
396がある.また,NVIC自体が,割込みのネスト回数を管理しているため,3から4
397への遷移のために,いったん例外/割込みを受付けた状態にする必要があるた
398め,結果的に2-1以上の遷移が必要となる.
399
4002-2の場合は,MSPしか使えないため,割込みの入り口でネスト回数を判断して,
401スタックを入れ替える必要がある.
402
403HRP等でメモリ保護を用いる場合は2-1となる.
404
405以上の理由により,2-1を採用する.ただし2-1は,カーネル起動時とIDLEルー
406プの扱いを検討する必要がある.これらについては別途議論する.
407
408
4093.ディスパッチャの実行モード
410
411 3-1
412 Threadモードで実行する
413
414 3-2
415 Handlerモードで実行する
416
417ディスパッチャをThreadモードで実行すると,割込みによりプリエンプトされ
418たタスクに戻る場合は次のようなパスになる.
419
420 1. ディスパッチャ呼び出し : Threadモード
421 2. ディスパッチャ実行 : Threadモード
422 3. タスク例外実行 : Threadモード
423 4.タスクへのリターン処理 : Handlerモード
424 5. タスクの再開 : Threadモード
425
426割込みハンドラから自らディスパッチしたタスクへリターンする場合は次のパ
427スになる.
428
429 1.割込みハンドラ : Handlerモード
430 2.ディスパッチャ実行 : Threadモード
431 3.タスク例外ハンドラの呼び出し : Threadモード
432 4.タスクへのリターン : Handlerモード
433 5.タスクの再開 : Threadモード
434
435一方,ディスパッチャをHandlerモードで実行すると,割込みによりプリエン
436プトされたタスクに戻る場合は次のようなパスになる.
437
438 1. ディスパッチャ呼び出し : Threadモード
439 2. ディスパッチャ実行 : Handlerモード
440 3. タスク例外実行 : Threadモード
441 4.タスクへのリターン : Handlerモード
442 5. タスクの再開 : Threadモード
443
444割込みハンドラの出口から自らディスパッチしたタスクへリターンする場合は
445次のパスになる.
446
447 1.割込みハンドラ : Handlerモード
448 2.ディスパッチャ実行 : Handlerモード
449 3.タスク例外ハンドラの呼び出し : Threadモード
450 4.タスクへのリターン : Handlerモード
451 5.タスクの再開 : Threadモード
452
453タスク例外ハンドラがないOSの場合は,Handlerモードで実行した方がモード
454の遷移の回数が減るが,タスク例外ハンドラがあると,Threadモードの方が遷
455移回数が減るため,Threadモードとする.
456
457メモリ保護を考慮すると,ディスパッチャはHandlerモードで動作させた方が
458効率がよいと考えられる(SVCでハンドラを呼び出すとHandlerモードとなるた
459め).
460
461
4624.スタックの使い分け
463
464 4-1
465 タスクコンテキストをPSP, 非タスクコンテキストをMSP
466 4-2
467 タスクコンテキスト,非タスクコンテキスト共にMSP
468
4694-2の場合,割込みの入り口でネスト回数を判断して,スタックを入れ替える
470必要がある.2でタスクコンテキストはThreadモード,非タスクコンテキスト
471はHandlerモードで動作させるとしたため,4-1を採用すると,割込みの入り口
472で自動的にスタックが切り替わる.ThreadモードでのPSPのアクセスも,
473mrs/msr命令で行えるため,4-1を採用する.
474
475
4765.コンテキストの判定
477
478 5-1
479 IPSRが'0'(Threadモード)ならタスクタスクコンテキスト,'1'(Handlerモー
480 ド)なら非タスクコンテキストとする.
481
482 5-2
483 割込みのネスト回数を保持する変数を用意.1以上で非タスクコンテキスト.
484
485 5-3
486 アクティブなスタックにより判断(MSPなら非タスクコンテキスト,PSPなら
487 タスクコンテキストとする)
488
4895-1は,ソフトウェア側でコンテキスト管理のための処理を行う必要がないと
490いうメリットがある.しかしながら,カーネルの起動時Threadモードであるた
491め,Handlerモードへ移行する必要がある.ASPカーネルでは,IDLEループ実行
492は非タスクコンテキストとして動作させる必要があるため,IDLEループは
493Handlerモードで動作させる必要がある.IDLEループはディスパッチャから呼
494び出される.3で定めたように,ディスパッチャをThreadモードで動作させる
495ため,IDLEループを呼び出す際には,Handlerモードへ遷移する必要がある.
496Handlerモードへの遷移は,SVC/PendSVCを用いると実現可能であるが,6の割
497込みにプリエンプトされたタスクへのリターン時のHandlerモードへの移行で
498もSVC/PendSVCの使用が必要となるため,SVCハンドラでは,どの目的で呼び出
499されたか判定する必要が出てくるため,オーバヘッドが増大する.
500
5015-2では,カーネル起動時やIDLEループ時に変数を'1'に設定すればよいことに
502なる.この場合,カーネル起動時やIDLEループ時にThreadモードで実行しても
503動作に問題がないよう,特に割込みの出入り口の設計を注意する必要がある.
504
505カーネル起動時に関しては,全割込みを禁止しており,割込みが入らないので
506特に問題はない.IDLEループ時は,ThreadモードでMSPとPSPの選択が可能であ
507ることを利用して,非タスクコンテキストのスタックであるMSPに変更する.
508例外/割込みの入り口では,多重割込みであるかをEXC_RETURNのモード判定の
509ビットではなく,スタックの判定ビットで行えば問題ない.例外/割込みから
510のリターンに関しては,多重割込みの判定は,入り口と同様にEXC_RETURNのス
511タック判定ビットで行えばよい.例外リターン処理時にpcに代入する
512EXC_RETURNの値を一律0xfffffffd (Threadモード with MSP)とするのではなく,
513例外/割込み受付け時にLRに設定されるEXC_RETURNを用いることにより,IDLE
514ループに割り込んだ場合でも問題なくリターンする.
515
516カーネル起動時は,MSPがアクティブであり,割込みハンドラ実行時はHandler
517モードであることからMSPがアクティブでり,IDLEループ時にMSPをアクティブ
518に設定すると,非タスクコンテキストは全て,MSPをアクティブにして動作す
519ることになる.また,割込み時は割込み前にアクティブなスタックの情報が,
520EXC_RETURNに設定される.そのため,コンテキストの判定は,割込みネスト回
521数を保持する変数がなくとも,アクティブなスタックを見ればよいことになる.
522また,exc_sense_context()に関しては,例外フレーム中にEXC_RETURNを追加
523し,その内容により判断すればよい.以上の理由により,5-3を採用する.
524
525
5266.割込みにプリエンプトされたタスクへのリターン時のHandlerモードへの移
527 行方法
528
529 6-1
530 SVCを用いる
531 6-2
532 PendSVCを用いる
533
534PendSVCとSVCの違いは,PendSVCが要求がキューイングされ,SVCは要求がキュ
535ーイングされないことである.割込みにプリエンプトされたタスクへのリター
536ン時のHandlerモードへの移行は,キューイングされずに即座に処理される必
537要があるため,どちらで実現しても問題ない.どちらをカーネルのリソースし
538て使用するかの選択だけである.
539
540どちらを使うとしても,優先度の設定が問題となる.ディスパッチャから割込
541みにプリエンプトされたタスクへのリターンまでの処理は,少なくともCPUロ
542ック状態で実行されなければならない.SVCやPendSVCはどちらも割込み優先度
543を持つため,NVIC優先度マスクよりBASEPRI優先度マスクの方が高い場合,処
544理されない.
545
546CPUロック状態をBASEPRIの設定で実現した場合,その設定値をSVCやPendSVCに
547設定した値より低くする必要がある.言い換えると,SVCやPendSVCの優先度を
548CPUロック時の優先度マスクの値より高い値(他の割込みより高い優先度)と
549する必要がある.
550
551CPUロック状態をFAULTMASKやPRIMASKで実現した場合は,これらが設定される
552と,SVCやPendSVCが受付けられないため,いったんBASEPRIにより割込みをマ
553スクするように設定する必要がある.この場合も,SVCやPendSVCは他の割込み
554より高い優先度を設定する必要がある.
555
556以上により,Handlerモードへの移行のためには,CPUロック状態をBASEPRIで
557実現し,SVCやPendSVCに設定する優先度をカーネル管理内の最高優先度より一
558つ高い優先度に設定する必要がある.
559
560ARMv7-MではSVCにより実現する.SVNの方がPendSVCより実行オーバヘッドが小
561さいため,SVCを使用する
562
563ARMv6-MではSVCにより実現する.ARMv6-MはCPUロック状態をPRIMASKで実現し
564ているPRIMASKをセットした状態でSVCを実行するとフォールトとなるため,
565PendSVCを発行して,PRIMASKをクリアすることで実現する.PendSVCの割込み
566優先度は最高としているため,この間で割込みが入ることはない.
567
568
5697. 例外/割込み出入り口での多重割込みの判断
570
5717-1
572 EXC_RETURNのモード判定ビット
5737-2
574 EXC_RETURNのスタック判定ビット
5757-3
576 割込みネスト回数の管理変数
577
578例外/割込み受付け時は,受付けた例外/割込み以下の割込みは禁止するが,全
579割込み禁止状態にはならない.そのため,割込みネスト回数の管理変数をイン
580クリメントする前に割込みが入る可能性があるため,7-3は使用することがで
581きない.
582
5835で議論した通り,IDLEループをThreadモードで実行するため,7-1ではなく,
5847-2で判断する必要がある.
585
586
5878. IDLEループ
588
5898-1
590 Threadモードで実行
5918-2
592 Handlerモードで実行
593
5945で議論した通り,Threadモードで実行できた方がオーバヘッドが小さい.ま
595た,Threadモードで実行しても,割り込みの出入り口で正しく非タスクコンテ
596キストと判定できれば,Threadモードで問題ない.
597
598
5999.カーネル管理外の割込みのサポート
600
6019-1
602 カーネル管理外の割込みをサポートしない
6039-2
604 カーネル管理外の割込みをサポートする
605
606ARMv7-Mでは,CPUロックをBASEPRIで実現していること,ベクタテーブルをサ
607ポートしており,割込みハンドラもC言語で記述可能であるため,サポートが
608容易であるため,サポートする.
609
610ARMv6-Mでは,CPUロックをPRIMASKで実現しているため,サーポートしない.
611
612
61310. CPUロック
614
61510-1
616 BASEPRIを使用(ARMv7-M)
617 個別の割込み禁止許可でエミュレーション(ARMv6-M)
61810-2
619 FAULTMASK/PRIMASKを使用
620
621カーネルの管理外の割込みをサポートするなら,BASEPRIを使用する必要があ
622る.
623
624ARMv7-MではCPUロックにBASEPRIを使用する.
625
626ARMv6-MではCPUロックにPRIMASKを使用する.個別の割込み禁止許可でエミュ
627レーションする方法は,SysTicのみ別のレジスタで設定する必要があり,実行
628オーバヘッドが大きいという問題がある.
629
63011. 割込みロックとCPU例外の関係
631
63211-1
633 BASEPRIを使用(ARMv7-M)
63411-2
635 FAULTMASK/PRIMASKを使用
636
637FAULTMASK/PRIMASKを使用すると,NMI と Hardware Fault 以外のCPU例外も禁
638止されてしまう.
639
640BASEPRIを用いると,割込みロック中にもCPU例外を受付けたい場合は,
641BASEPRIを用いて,最高優先度をCPU例外のためにリザーブする必要がある.
642
643割込みロック時も,CPU例外を受付けるようにしたければBASEPRIを使用する必
644要がある.
645
646μIRON4.0仕様の3.5.3では,CPU例外の優先度は次のように定められている.
647
648"CPU例外ハンドラの優先順位は,CPU例外が発生した処理の優先度と,ディス
649パッチャの優先順位のいずれかよりも高い."
650
651CPU例外が発生した処理の優先度よりも高いとあるので,CPUロックや割込みロ
652ック状態のタスクで発生した場合でも,優先して実行されるべきだとも考えら
653れる.
654
655一方,TOPPERS標準割込み処理モデルの仕様書では,CPU例外は,プロセッサ毎
656に異なるため,CPU例外の処理モデルの標準化検討の対象外としている.その
657ため,ARM-Mでの扱いを決めて,マニュアルに明記すればよいと考えられる.
658
659ARMv7-Mでは割込みロックはBASEPRIを使用する.
660
661ARMv6-Mでは割込みロックはPRIMASKを使用する.
662
663
66412. 外部優先度と内部優先度の変換
665
666外部優先度とはAPIで指定する割込み優先度(PRI型)のことであり,値が小さい
667ほど優先度が高い.割込みハンドラには,-1から連続した負の値を設定可能で
668ある.内部優先度は,BASEPRIやNVICの優先度レジスタに設定する値である.
669
670実装される割込み優先度のビット幅を TBITW_IPRI とすると,設定可能な外部
671優先度は次のようになる.
672
673 TIPM_ENAALL(=0)~ -(1 << TBITW_IPRI)
674
675
67613. カーネル管理内の最高優先度(CPUロック状態での優先度マスク)
677
6786.で述べたように,割込みの出口でSVCハンドラを呼び出す必要があるため,
679SVCハンドラはCPUロック状態のBASEPRIに設定する優先度マスクより高い優先度
680を設定する必要がある.
681
682実装される割込み優先度のビット幅を TBITW_IPRI,優先度中のサブ優先度の
683ビット幅をTBIT_IPRIとすると,CPUロック状態(カーネル管理内割込みに設定
684可能な最高優先度)として指定可能な優先度マスクの設定範囲は以下の値の範
685囲となる.
686
687 -(2^(TBIW_IPRI) - 1) + (2^TBITW_SUBIPRI) ~ -1
688
689
69014. 割込み優先度マスク
691
692ARMv7-MではBASEPRIにより実現する.
693
694ARMv6-Mでは個別の割込み禁止許可機能を用いてエミュレーションする.
695
696
69715. FPUのサポート
698
69915-1
700 FPUを使用するタスク/ISRをユーザが指定する. 指定していないタスク/ISR
701 ではFPUを使用すると例外となる.
70215-2
703 FPUを使用するタスク/ISRをユーザは指定しない.全てのタスク/ISRでFPUを
704 使用可能である.
705
70615-1は一般にコンテキストの保存復帰のオーバヘッドを低減する目的で採用さ
707れる.15-1を採用すると,タスクとISRの属性の拡張が必要となる.
708
709ARMv7-Mでは,FPUを使用した場合のみ例外・割込みの入り口でFPUコンテキス
710トを保存する機能があるため,15-2を選択しても,FPUを使わない限りはペナ
711ルティはないと考え,15-2を採用する.
712
713FPUに関するサポートのバリエーションは次の組み合わせが可能である.
714
715 FPCCR コンテキスト
716 LSPEN ASPEN コンパイルオプション 保存復帰 FPU
717NO_FPU - - 指定なし なし 無効
718FPU_NO_PRESERV 0 0 -mfpu=fpv4-sp-d16 なし 有効
719FPU_NO_LAZYSTACKING 0 1 -mfpu=fpv4-sp-d16 あり 有効
720FPU_LAZYSTACKING 1 1 -mfpu=fpv4-sp-d16 あり 有効
721
722NO_FPU
723FPUを使用しない.Cortex-M0/Cortex-M0+/Cortex-M3/Cortex-M4 の場合に指定.
724ディスパッチャ等ではFPUコンテキストの保存復帰を行わない.
725
726FPU_NO_PRESERV
727FPUを使用する.Cortex-M4F の場合に指定可能.
728ディスパッチャ等ではFPUコンテキストの保存復帰を行わない.
729FPUを使用可能なタスクは1個もしくは,システム中の最高優先度のISR群で使
730用可能.
731
732FPU_NO_LAZYSTACKING
733FPUを使用する.Cortex-M4F の場合に指定可能.
734ディスパッチャ等ではFPUコンテキストの保存復帰を行う.Lazy stacking は
735使用しない.
736全てのタスク/ISRでFPUを使用可能.
737
738FPU_LAZYSTACKING
739FPUを使用する.Cortex-M4F の場合に指定可能.
740ディスパッチャ等ではFPUコンテキストの保存復帰を行う.Lazy stacking を
741使用する.
742全てのタスク/ISRでFPUを使用可能.
743
744
745FPU_NO_LAZYSTACKING時のレジスタの保存・復帰コード
746
747FPU_NO_LAZYSTACKING の場合は一般レジスタと同じタイミングで,ディスパッ
748チ元のタスクがFPUを使用していたかを判断してレジスタを保存・復帰すれば
749よい.該当する箇所は次の通りである.
750
751ディスパッチ(dispatch)
752・CONTROL.FPCAをチェックして'1'ならs16-s31を保存する
753・復帰用にCONTROL.FPCAをタスクスタックに保存
754
755ディスパッチからの復帰(dispatch)
756・CONTROL.FPCAをタスクスタックから復帰する
757・復帰したCONTROL.FPCAをチェックして'1'ならs16-s31をタスクスタックから
758 復帰する.
759
760遅延ディスパッチ(ret_int_4)
761・タスクが割り込まれた際のEXC_RETURNをタスクスタックに保存しておく
762・EXC_RETURNをタスクスタックから復帰
763・復帰したEXC_RETURN[4] == 0(FPU使用)ならs16-s31をタスクスタックに保存
764 する.
765・復帰用にEXC_RETURNの値をタスクスタックに保存
766
767遅延ディスパッチからの復帰(ret_int_r)
768・タスクが割り込まれた際のEXC_RETURNの値をタスクスタックから復帰
769・復帰したEXC_RETURN[4] == 0(FPU使用)ならs16-s31をタスクスタックから復帰
770・先のSVCハンドラ呼び出し時にFPUレジスタを積まないようにCONTROL.FPCAをクリア.
771
772FPU_LAZYSTACKING時のレジスタの保存・復帰コード
773
774FPU_NO_LAZYSTACKING時のコードをそのまま使用するとFPU_LAZYSTACKINGの場
775合は,割込み・例外発生後に次のタイミングで例外フレームにFPUのコンテキ
776ストがハードウェアによって自動的に保存される.
777
778例外・割込みハンドラ実行中
779FPUを使用したタスク/ISR実行中に例外・割込みが発生し,例外・割込みハン
780ドラでFPU命令を実行した場合.FPCCR.LSPACT==1 となっているため.
781
782遅延ディスパッチ時(ret_int_4)
783例外・割込みハンドラでFPUを使用しなかった場合は,ret_int_4実行時にはコ
784ンテキストは保存されていない.さらに各レジスタの値は次のようになってい
785る.
786・FPCCR.LSPACT == '1'
787・FPCAR = 例外フレームのFPUレジスタの保存アドレス(S0のアドレス)
788ret_int_4では,s16-s31 をタスクスタックに保存する.ここでFPUを使用する
789ため,s0-s15,FPSRは例外フレームに保存される.
790
791以下の箇所はFPU_LAZYSTACKINGの場合にのみ必要である.
792
793割込み出口でのタスク例外呼び出し時
794FPUを使用したタスク実行中に例外/割込みが発生し,例外/割込みの出口から
795タスク例外処理を呼び出した場合には,FPCCR.LSPACT == '1' とFPUコンテキ
796ストが保存されていない状態でタスク例外が呼び出される可能性がある.タス
797ク例外でext_tsk()を呼び出した場合や他のタスクにディスパッチされ,
798ter_tsk()で終了させられた場合には,FPCCR.LSPACT を '0'にクリアする必要
799がある.ext_tsk()のケースはターゲット依存部exit_and_dispatch()が呼び出
800されるため,ここでクリアすれば良いが,ter_tsk()ではターゲット依存部を
801呼び出さないため,クリアすることが出来ない.そのため,割込み出口でのタ
802スク例外呼び出すタイミングでFPUコンテキストをスタックに格納するため,
803副作用のないFPU命令を発行する.
804なお,他のタスクにディスパッチされた場合は,CONTROL.FPCAが'1'で無いた
805め(タスク例外でFPUを使用しなかった場合),s16~s31のFPUレジスタの保存が
806行われず,例外フレームへの書き戻しが発生しない.
807
808CONTROL.FPCAのセット・クリアのタイミング
809
810クリアする箇所が複数箇所になると把握が困難であるため,ディスパッチャの先頭で
811は一律CONTROL.FPCAを'0'にクリアする.
812
813dispatchを呼び出したタスクへのリターンする際には,戻り先のタスクがFPU
814を使用しいた場合は,s16~s31の復帰を行うため,この処理により
815CONTROL.FPCAが'1'にセットされる.
816
817また,EXC_RETURNによるリータン時はEXC_RETURNの値によってリーターン時に
818ハードウェア的に自動的にCONTROL.FPCAが元の状態に復帰されるのでソフトウ
819ェアによる処理は必要ない.
820
821タスク例外の扱い
822
823タスク例外でFPUを使用して,通常の処理でFPUを使用しない場合は,タスク例
824外の呼び出しの前後で CONTROL.FPCA を保存復帰する方法もあるが,レアケー
825スであると考えられるためサポートしない.
826
827ABI
828
829GCCでは3種類選択可能.
830
831hard : 浮動小数点命令を使用してABIはFPUレジスタを使用.
832soft : 浮動小数点命令を使用しない.
833softfp : 浮動小数点命令を使用するがABIはsoftと同じ.
834
835既存のライブラリとリンクする場合はsoftfpが有効だが,ユーザーカスタマイ
836ズとしてディフォルトは,hardとする.
837
838マクロ
839
840FPUコンテキスト復帰保存を有効化するマクロ.
841
842TOPPERS_FPU_CONTEXT
843
844FPUの使用を有効化するマクロ.
845
846TOPPERS_FPU_ENABLE
847
848FPUのアーキテクチャを指定するマクロ.ARMCCと合わせて次のマクロを使用する.
849__TARGET_FPU_FPV4_SP
850
851FPU_NO_PRESERV/FPU_NO_LAZYSTACKING/FPU_LAZYSTACKINGの場合は次のマクロを定義する.
852
853TOPPERS_FPU_NO_PRESERV
854
855TOPPERS_FPU_NO_LAZYSTACKING
856
857TOPPERS_FPU_LAZYSTACKING
858
859
86016. 未解決課題
861・割込みロックとCPU例外の関係
862 BASEPRIを使ったとしても,あるCPU例外処理中に他の例外が発生すると,そ
863 の例外は受け付けられないため,ITRON仕様は満たせない.
864 ->あきらめてマニュアル記載に逃げるか.
865 メモリプロテクションの例外もマスク可能であるため要件等.
866
867以上.
Note: See TracBrowser for help on using the repository browser.