フォーラムへの返信
-
投稿
-
ttkkttkkさん
ベクタテーブルの記載ですが、提示いただいた資料（TMS320F2837xDのTechnical Reference Manual SPRUHM8H）の記載で間違いありません。資料は Revision i がリリースされておりますが、ベクタテーブルに関しては、変更ございません。
EPWM7の割り込みベクタは、「Table 3-2. PIE Channel Mapping」よりINT3.7が対象となります。
INT3.7のベクタアドレスは、「Table 3-4. PIE Interrupt Vectors」から0x0D6Cになります。レジスタ設定などは、ビットフィールド構造体をご利用いただいていると思いますが、PIEベクタテーブルは構造体変数”PieVectTable”で定義されております。PieVectTableは PIE Interrupt Vectors のアドレスに配置されております。EPWM7割り込みハンドラは、 PieVectTable.EPWM7_INT = &epwm7_isr; と記述いただくだけで、0x0D6Cへ登録できますので、ご活用いただければと思います。
ご確認のほど、よろしくお願いいたします。
リンク時の配置につきましては、大きいモジュールから順に割り当てられます。
弊社環境での確認では、順番が入れ替わっても、PieVectTableの対象ベクタに正しくアドレスが登録されており、プログラムのRAMへのコピーが正しく行われていれば、正常に割り込みハンドラは実行されております。
ePWM7の割り込みベクタは、0xD6C番地ですが、ここにepwm7_isrのアドレスが正しく設定されておりますでしょうか。
ご確認のほど、よろしくお願いいたします。
ttkkttkkさん
ご確認のほど、よろしくお願いいたします。
PWM割り込みのモジュール番号を知る方法ですが、何の割り込みで発生したかは、レジスタでは知ることができません。
PIEIFRxレジスタで、参照時点で発生している割り込み要因は判断できますが、割り込み発生から実際に割り込みハンドラが動作するまでに、別の割り込みが発生した場合は、その要因フラグが発生する可能性があるからです。
ePWM1からePWM7までそれぞれ独立したPIEハンドラが登録できます。
共通のハンドラをPIEベクタテーブルに登録されるのではなく、個々のハンドラをPIEハンドラとしてご登録いただき、共通関数には個々のハンドラから識別子などを引数として共通関数に渡すことをお薦めいたします。なお、異なる質問をご投稿の際には、新しいトピックとしてご投稿頂けますと、私共も管理しやすくなりますので、ご協力のほど、よろしくお願いいたします。
以上、よろしくお願いいたします。
-
この返信は5 年前に Yojiro さんが編集しました。
停止したアドレスと一致する内容がスタックに保存されており、その1word前をみると、それまでの履歴から近いアドレスが保存されていることから、1wordずれていると判断させていただきました。
_stack
C054 0000 952D 0008 95EF 0008 95FB 0008 8920 0008 938B 0008 0000 0001 00C8 0018
0001 0000 0000 0000 0003 FFFF EA0A 0033 0004 001F 958C 0008 0020 0000 0000 0004
0096 FFFF 0000 0001 C1E2 0000 0001 0000 0000 0000 0000 0000 0000上記太字の内容が停止したアドレス「0x0020_0008」と一致しますが、斜体の値にありますように、0x0008_9xxxが問題発生よりも前に動作していたアドレスと推測できます。太字の 0008 0020 から1wordずらすと、0x0008_958C になることから、このような判断しております。
SP-8がReturn Addressというのは、あくまでもITRAP ISRが発生したときのReturn Addressです。その他の通常の関数や、ペリフェラルの割り込みハンドラからの戻りアドレスは、その関数の内部変数の定義内容により変化します。ステップ実行されていたプログラムが何によるものかは、こちらでは判断できませんので、実際のSPとReturn Addressの関係につきましては、ttkkttkkさんにてご確認頂けますでしょうか。
全てステップ実行されているという条件と、頂いたStackの内容から推測すると、0x0008958Cから呼び出した関数（またはその関数から呼び出した関数）でなんらかの問題が起こっている可能性が伺えます。
ご確認のほど、よろしくお願いいたします。
ttkkttkkさん
StepOverで進めると、ITRAPのESTOP0で停止した時点でSTACKが全て0とのことですが、ESTOP0で停止しするF6操作直前のコードは特定できておりますでしょうか。
また、StepIntoで実行されたときには、0x200008で停止するとありますが、Stackの内容を確認すると、本来0x0008958CにReturnするところが、スタックポインタが1word分ずれている、あるいはStack領域が間違って更新されているために発生しているものと推察いたします。
実行コードで、不正なポインタ変数の操作や、内部変数にスタックより大きな配列を定義されていると、スタックの内容がおかしくなります。メモリビューやレジスタビューを参照しながらステップ実行を行うことで、不正アクセスの原因が特定できるのではないかと考えます。
ご確認のほど、よろしくお願いいたします。
ttkkttkkさん
まずはじめに、先日の回答で誤りがありましたので、訂正させていただきます。
ITRAPの発生時は、スタックにReturn Addressとして発生時のプログラムカウンタが保存されています。
SPが偶数の場合はSP+2, SPが奇数の場合はSP+3のスタックに保存されていますので、Disassemblyなどで解析することで発生理由が明確になることがあります。C2000では、スタックはアドレスを加算する方向に積まれます。そのため、ISRからReturn Addressを確認する場合は、SPから減算（SP-2またはSP-3）することになります。実際には、ISRハンドラの内容によっては、CPUレジスタの退避も行われますので、SP-8またはSP-9になることもあります。
SPの内容につきましては、Registersビューの「Core Registers」にて確認いただけます。
また、Memoryビューのアドレス入力欄に”SP”と入力いただくことで、その時点のスタックを表示することができます。ご確認のほど、よろしくお願いいたします。
まずは、メモリビューにて、スタック内容をご確認ください。
メモリビューからReturn Addressを読み出していただき、Disassemblyビューにそのアドレスを入力していただくと、表示されます。あるいはメモリマップから、実行している関数などをご確認いただくことになると思います。
ご確認のほど、よろしくお願いいたします。
コピー処理ですが、コマンドファイルでは、
– LOAD_START
– LOAD_END
– RUN_START
のみの定義となっております。この場合、以下のコピー処理となると思いますが、あっていますでしょうか。
memcpy( &RamfuncsRunStart_epwm7_isr, &RamfuncsLoadStart_epwm7_isr , (size_t)(&RamfuncsLoadEnd_epwm7_isr – &RamfuncsLoadStart_epwm7_isr)+1 );
あるいは、コマンドファイルにLOAD_SIZEを追加いただき、LOAD_SIZEによるサイズ指定でメモリコピーを実施してみて頂けないでしょうか。
ITRAPの発生時は、スタックにReturn Addressとして発生時のプログラムカウンタが保存されています。
SPが偶数の場合はSP+2, SPが奇数の場合はSP+3のスタックに保存されていますので、Disassemblyなどで解析することで発生理由が明確になることがあります。
ESTOP0で停止した際は、発生アドレスとその内容を確認いただくことで、原因特定がスムーズになることがありますので、ご確認頂けますでしょうか。ご確認のほど、よろしくお願いいたします。
ttkkttkkさん
頂いている情報が断片的なため、分かる範囲での回答となりますこと、ご了承ください。
3fe493: 7625 ESTOP0
はITRAP ISRによる停止と思われます。未定義の命令が実行された時に実行されるコードになります。
実行コードがRAMへ正しく展開できていない時に発生いたします。当初のリンカコマンドファイルでは、RAM展開コードのコピー元がRAMLS5(LOAD = RAMLS5)となっていましたが、FLASH ROMに定義してお試し頂いておりますでしょうか。
また、考えられる要因として、GSRAMのアクセス権がCPU2に変更されている場合、CPU1からはプログラムのフェッチが行えません。
コピーサイズを増やしていくと、ESTOP0で停止するとのことですが、コピー先がRAMGS0の範囲に収まっている場合は問題ないなど、問題発生の有無の条件をもう少し絞り込むことはできないでしょうか。ご確認のほど、よろしくお願いいたします。
Tsysdesさん
POLL_RATEの設定が反映されない件につきまして、v3.20では静的ライブラリの不具合により、初期設定が上書きされるとのことです。
次版（v3.30）では修正予定とのことですが、それまではアプリケーション側で明示的にポーリングレートを変更する必要があります。
変更コード例（source\ti\zstack\apps\sw\zcl_samplesw.c line:1448）：
// set poll rate to POLL_RATE after joining
zstack_sysConfigWriteReq_t writeReq = { 0 };
// Set the new poll rates
writeReq.has_pollRate = true;
writeReq.pollRate = POLL_RATE;
writeReq.pollRateType = POLL_RATE_TYPE_DEFAULT;
Zstackapi_sysConfigWriteReq(appServiceTaskId, &writeReq);参考URL）
https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/823450/3046980#3046980お手数をおかけいたしますが、上記対応のほど、よろしくお願いいたします。
ttkkttkkさん
TI-RTOSは、別途TI-RTOSパッケージをインストール頂く必要があります。パッケージをインストールしていなければ、使用されていないと考えます。
インストールの有無につきましては、プロジェクトのプロパティ画面の左にあるリストから「General」をクリックしていただき、右に表示される「Products」パネルに”TI-RTOS for C2000”が表示されているかで判断できます。
表示されていれば、インストールされており、チェックボックスがOnになっていれば使用されています。ご確認をお願いいたします。
ttkkttkkさん
次の2点をご確認いただけますでしょうか。
- ISRのコードは、すべてRAMにコピーできておりますでしょうか。
CCSのメモリビューあるいは逆アセンブルビューでRamfuncsLoadStart_epwm1_isrとRamfuncsRunStart_epwm1_isrを比較いただければ、確認いただけるものと思います - PieVectTable.EPWM1_ISR にepwm1_isrのアドレスが登録されておりますでしょうか。
リンカコマンドファイル「F2837xD_headers\cmd\F2837xD_Headers_BIOS_cpu1.cmd」をお使いいただいているとのことですが、TI-RTOSをご利用されておりますでしょうか。TI-RTOS未使用の場合は、このファイルをF2837xD_Headers_nonBIOS_cpu1.cmdに置き換えてご確認いただけないでしょうか。
ご確認のほど、よろしくお願いいたします。
ttkkttkkさん
頂いた情報には記載がございませんが、ソースコードでepwm1_isrをramfuncs_epwm1_isrセクションに指定（#pragma CODE_SECTION( epwm1_isr, “ramfuncs_epwm1_isr” );）されている前提でしょうか。
FLASHからRAMへのコピーにつきまして、セクション”.TI.ramfunc”は、関数InitSysCtrl()でコピーされますが、ユーザーが作成したセクションに関しては、ユーザーコードでコピーいただく必要があります。
このメモリコピー処理は記述いただいておりますでしょうか。
また、コピー元の配置先がRAMLS5とRAM領域となっておりますが、問題ないでしょうか。CCSでデバッグする際は、デバッガ起動時にRAMLS5へプログラム（コピー元データとして）がロードされますが、ターゲットのリセットや電源の切入でクリアされるため、Standalone（デバッガを起動しない状態）では動作しないものと思われます。
ご確認のほど、よろしくお願いいたします。
miyoさん
XRSピンがLowに落ちる原因としては、以下の2点になります。
・ Power On Reset時
・ CPU1のWatch dogタイマのタイムアウト時CPU1のWatchdogによるリセットが発生すると、XRS信号は512cycle(OSCCLK)の間、Lowを出力します。
OSCCLKはリセット解除直後は、OSCINT2=10MHzが使用されています。今回Low出力される時間は50usecとのことですので、10MHz * 512 cycle = 51.2usecとなりますので、現象として当てはまるのではないかと思います。
数回XRSがLowとなることにつきましては、CPU1がCPU2の動作まちを行っている間にCPU1のWatchdogが発生しているものと推察いたします。CPU1のWatchdogタイムアウトでは、CPU2はリセットされませんので、CPU1がリブートしている間も、CPU2が動作しています。そのため、複数回CPU1がリセットするあいだに、CPU2の動作が完了し、待ち状態が解除されるものと考えます。
電源ON後、Boot codeでも、CPU1がCPU2の起動を待つシーケンスがございますが、このときはWatchdogタイマはDisableにしております。ユーザーコードでWatchdogタイマが有効の状態で、CPU1がCPU2の動作待ちになる状況がないかご確認頂けないでしょうか。
ご確認のほど、よろしくお願いいたします。
amatsu1さん
お問い合わせいただきました内容を確認させていただきましたが、幾つか確認させて頂けないでしょうか。
・信号波形の水色波形の電圧が1.5Vとなっておりますが、トランジスタ（2SC2712）からTMS320F28027まで、回路図に記載されているもの以外はつながっていないでしょうか。
・回路図の3.3Vプルアップ抵抗の値の記載ですが、100kでしょうか。100Ωでしょうか。
水色波形の立ち上がり時間が10msec以上となっており、記載いただいた回路図からだけでは、このような現象となる理由が見当たりません。
pin.37に接続されているということですが、TMS320F28027のピン配置はパッケージにより、次のようになっております。
・TSSOP（38pin）：GPIO0/EPWM1A
・LQFP（48pin）：GPIO2/EPWM2AGPIO37はTDO端子と共用されており、TSSOP:30pin / LQFP:22pin はJTAGコネクタ接続（nTRST端子=high)時は出力設定となります。
37pinが出力設定になっていないかも合わせてご確認頂けないでしょうか。ご確認のほど、よろしくお願いいたします。
-
この返信は5 年前に