FW behavior after it was downloaded

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hello,

  About MB9BF124K, we downloaded FW though SWD by using EWARM, and went INITX to Low. We think the FW is going to start after INITX released. But the FW did not run although FM3 was reset.

  We cheked whether FM3 was reset or not when INITX was Low. We decided that FM3 was reset because the program downloaded did not run and external liqued crystal did not also work.

Why dose not FM3  run after FW downloaded regardless INITX is Low?

[From ARM TRM]

I understood Debugger controls DHCSR.C_DEBUGEN and DEMCR.VC_CORERESET. if C_DEBUGEN is set to 1, core enter to debug mode and DHCSR.C_HALT is set to 1. Therefore, even if INITX is set to Low, during C_DEBUGEN = 1, C_HALT keep to 1. The result of this, CPU can not run because it stay in debug mode as long as C_DEBUGEN is not set to 0.

Best regards,

0 Likes
12 Replies
Anonymous
Not applicable

Hi,

Since EWARM seems to be used, after connect to the target device (MB9BF124K) with EWARM by connecting the debugger (Project menu→Download and Debug), open the memory window and check whether FW is properly write in the flash memory area.

At that time, enable the "bypass memory cache" option of the debugger.

Also, execute Project menu → Download → Erase Memory, erase the built-in flash,

then, connect the debugger with "Connect without downloading", and check the flash memory area of ​​the memory window.

Please check whether it is properly erased.

In the above operation, if write/erase to the flash can be performed,

please try to write a small program as FW (such as a program that only toggles GPIO repeatedly in the main function).

With the FW written,

1) Execute on the debugger

2) Disconnect the debugger and reset with INITX

3) Disconnect the debugger, turn it off, turn it on again

Please check whether FW works (GPIO toggles) with each of the above.

If all of 1) to 3) operate correctly, there is a possibility that there is a problem with the original FW. Please check whether the source code is correct.

If 1) is OK, and 2) or 3) is NG, there is a possibility that there is an error in the FW initialization (clock setting, watchdog timer etc. in particular).

Please check whether the initialization code is correct.

It seems like the external crystal does not working, but the external clock is disabled in the initial state after resetting.

Please check whether the external clock is properly enabled during FW initialization.

If it is enabled, please confirm that the oscillation stabilization wait time is sufficiently secured.

Also, in the initial state after reset, the hardware watchdog timer is enabled.

Please note that the watchdog timer will be reset if you turn off the hardware watchdog timer on the FW or if you do not clear the counter at regular intervals.

EWARM使用されているようですので、EWARMでターゲットデバイス(MB9BF124K)にデバッガ接続(プロジェクトメニュー  ダウンロードしてデバッグ)してから、

メモリウィンドウを開き、フラッシュメモリ領域に適切にFWが書き込まれているかどうかご確認ください。

その際、デバッガの「メモリキャッシュをバイパス」オプションを有効にしてください。

また、プロジェクトメニュー  ダウンロード  メモリ消去 を実行して、内蔵フラッシュを消去した後、

「ダウンロードせずに接続」でデバッガ接続してから、メモリウィンドウのフラッシュメモリ領域を確認し、

適切に消去されているかを確認してください。

以上の操作にて、フラッシュへの書き込み/消去が確実に行われていることが確認できた場合、

できる限り小さなプログラム(main関数内で、GPIOを繰り返しトグルするだけのプログラムなど)をFWとして書き込んでみてください。

このFWを書き込んだ状態で、

1)デバッガ上で実行

2)デバッガを切断しINITXによるリセット

3)デバッガを切断し、念のため、電源をOFFしてから再度ON

のそれぞれで、FWが動作するか(GPIOがトグルするか)を確認してください。

1)~3)の全てが動作する場合、元のFWに問題がある可能性があります。ソースコードに誤りがないかご確認ください。

1)で動作し、2)または3)で動作しない場合、FWの初期化処理(特にクロック設定やウォッチドッグタイマなど)に誤りがある可能性があります。

初期化処理のコードに誤りが無いかご確認ください。

外部クリスタルが動作していないようですが、リセット後の初期状態では外部クロックは無効の状態です。

FWの初期化処理の中で、適切に外部クロックを有効にしているかどうかご確認ください。

有効にしている場合、発振安定待ち時間が十分確保されているかご確認ください。

また、リセット後の初期状態ではハードウェアウォッチドッグタイマが有効になっています。

FW上でハードウェアウォッチドッグタイマをOFFにするか定期的にカウンタをクリアしないと、

ウォッチドッグタイマリセットがかかってしまいますのでご注意ください。

Thanks,

Nada

0 Likes
Anonymous
Not applicable

Hello Nada-san,

再度、状況をまとめます。

今回の論点は、プログラムダウンロード後に、デバッガを接続した状態で、

INITXをLow->Highしても、書き込みプログラムが動作しないが、

Power Onリセットをかけるとプログラムが動作開始する点にあります。

1) 書き込みツールとして、Computex 社の FP-10でも、EWAERMでも同じ結果です。

2) 書き込み後、電源OFF->ONにより、プログラムは正常動作します。

3) 書き込み後に、INITXをLOW->Highしてもプログラムは動作しません。(Lowの期間は数秒間)

FM3は、プログラムダウンロード直後に、デバッガをつないだ状態で、

INITXをLow->Highにすることで正常にプログラムが動作する仕様でしょうか?

以上、よろしくお願いいたします。

0 Likes
Anonymous
Not applicable

お世話になっております。

念のため確認ですが、「デバッガを接続した状態」とはどのような状態でしょうか。

例えば、EWARMであれば、対象デバイスとPCがI-jetなどのICE機器と接続されていて、

かつEWARMのC-SPYデバッガが起動している状態(C-SPYデバッガと対象デバイスがICEを通じて

接続状態にあり、PCからデバイスの動作確認が可能な状態)でしょうか。

もしそうであれば、デバッガがデバイスの制御権をつかんだままの状態ですので、

ハードウェアリセット(INITXをLow->High)にしても、プログラムが始動しない可能性があります。

その場合、デバッガを終了してからハードウェアリセットをかけてみてください。

一方、単にPCとデバイスがICE機器を通じて物理的に結線されているものの、

C-SPYデバッガ等が起動しておらず、デバッガがデバイスの制御権を保持していない場合、

ハードウェアリセット後にプログラムは始動するはずです。

それでも始動しない場合、プログラムでのデバイスの初期化処理に何か異常がある可能性があります。

パワーオンリセットではすべてのレジスタ設定/ハードウェアを初期化しますが、

INITXによるハードウェアリセットでは一部のレジスタ設定/ハードウェアが初期化されません。

その結果、パワーオンリセット時とハードウェアリセット時で、プログラムの初期化処理に差異が生じ、

結果として、プログラムの挙動に違いが生じる可能性があります。

よろしくお願いいたします。

Nada

0 Likes
Anonymous
Not applicable

お世話になっております。

EWARMについては、「プロジェクト>>ダウンロード>>アクティブなアプリケーションのダウンロード」を実行しているので、C-SPYは起動していない状態です。この状態でも、INITXを入力してもプログラムが走りません。

その後、東京エレテック社の評価ボードにてデバイスを交換したり、

EWARMのバージョンを変える等を試すと、状況が変わることがわかりました。

*手元にMB9BF124Kがない為、MB9BF524Mにて試しています。

     Device       |  EWARM ver.  |  ICE  |   OK/NG

-------------------+-------------------+--------+-------------

MB9BF524M  |    v 7.60.2        |  IJet  |      NG      

-------------------+-------------------+--------+-------------

S6E1A11C0A    |    v 7.70.1        |  IJet   |     NG

-------------------+-------------------+--------+-------------

S6E1A11C0A     |    v 8.11.3       |  IJet  |    OK

-------------------+-------------------+--------+-------------

S6E2HG6G0A    |    v 7.70.1       |  IJet   |     OK

-------------------------------------------------+-------------

*「アクティブなアプリケーションのダウンロード」成功後、INITXを入れて、単純なIOのHigh/Lowプログラムが走るかを見ています。

  NG:プログラムが走りません。

  OK:プログラムが走ります。

上記の結果となっておりますので、単純にツールのバージョンやデバイス個体に起因はしていないと考えています。

以上、よろしくお願いいたします。

0 Likes
Anonymous
Not applicable

お世話になっております。

Flashへ書き込む直前のデバイスの状態は全て同じ条件と理解して良いでしょうか?

先に回答しました通り、INITXによるリセットでは一部のレジスタ/ハードウェアが初期化されません。

Flashに書き込みを行う際、すでにデバイスの電源はON状態になっていると思います。

その時Flashにすでに何らかのプログラムが書かれているとすると、電源をONした時にそのプログラムが実行されますので、そのプログラムによって、デバイスのレジスタやハードウェア(INITXで初期化されない部分も含む)を何らかの状態に設定すると思われます。

その状態で、Flash書き込みを行いINITXでリセットをかけると、

INITXで初期化されないレジスタ/ハードウェアは、Flash書き込みを行う前に実行されたプログラムによって行われた設定を引き継ぐことになります。

そこに対して後から書き込んだプログラムが再設定を行おうとした時に、前から引き継がれた状態となんらかの不整合があると、期待と異なる挙動を示してしまう可能性があります。

以下をお試しください。

1) デバイス消去を行い、Flashの内容を一旦ブランクにする

2) 電源をOFFする

3) 電源をONする

4) Flash書き込みを行う

5) INITXでリセットをかける

よろしくお願いします。

Nada

0 Likes
Anonymous
Not applicable

Hello Nada-san,

同じ条件となります。

まず、IOをHigh/Lowするだけのプログラムで試していますので、仰られている条件で挙動が変わること自体がありえないと思っています。

また、INITXを入れた際に、プログラムが走らない事が問題であり、挙動が変わることは一切話しには出しておりませんので、ご懸念の点は忘れて頂いた方が良いと思います。

プログラムが動作していないときは、外部発信も動作していませんが、電源再投入(Power on Reset)の際には、クロックが動き出します。

さらに、Flashをブランクにした状態で試していますので、仰られている条件には当てはまりません。

以上、よろしくお願いいたします。

0 Likes
Anonymous
Not applicable

ご確認ありがとうございます。

同じ条件(Flashがブランク後、電源OFF → ON)ということで承知いたしました。

ご指摘の点は理解しています。ただし、文字通りプログラムが一切動いていない(リセット後の最初の一命令すら実行できていない)のか、

または、ブログラムは走り出す(最初の数命令は実行される)もののどこかで予期せぬ問題が生じ命令実行が期待と異なる状態に陥ってしまった結果

見かけ上「プログラムが走らない」ように見えてしまっている(これを「挙動が変わる」と表現しています)のかを切り分けたいと考えています。

ハードウェアに何らかの物理的な異常が無い限り、INITXリセットでプログラムが一命令も実行できないということは可能性として考えにくいため、

プログラム実行開始後、特にクロックの初期設定処理の周辺で何かしら異常が起きているのではないかと想定しています。

電源再投入時は外部発振を開始するとのことですので、プログラムのどこかで外部クロックの初期化処理を行っている箇所があるかと思います。

※FMシリーズは、パワーオンリセット後はデフォルトで外部発振が無効ですので、プログラムで有効処理を行わない限り外部発振が始まることはありません。

そこで、それらの初期化処理をすべて無効にし、内蔵クロック(CLKHC)だけ(PLLも使用しない)で動作するプログラムで動作確認をお試しいただけませんでしょうか。

よろしくお願いいたします。

Nada

0 Likes
Anonymous
Not applicable

Nada-san,

担当変更があり、SE1A11C0Aのみで確認をしております。

内蔵CRのみ(外部発信は無効)に設定して、I/OのHi/Lo確認をしました。

結果は、変化ありませんでした。

また、J-Linkでも確認しましたが、J-Linkではすべて正常に動作しています。

** 外部発信で動作

| Device            | EWARM ver.  | ICE     | OK/NG  |

|--------------------+------------------+---------+------------|

| MB9BF524M  | v 7.60.2          | I-Jet    | NG        |

|--------------------+------------------+----------+-----------|

|                        |                        | I-JEt    | OK        |

| S6E1A11C0A | v 8.11.3          | --------- | ---------- |

|                        |                        | J-Link  | OK        |

|-------------------+-------------------+----------+-----------|

|                        |                        | I-Jet     | NG       |

| S6E1A11C0A | v 7.70.1          | --------- | ---------- |

|                        |                        | J-Link  | OK        |

|--------------------+------------------+----------+-----------|

** 内蔵CRのみで動作

| Device            | EWARM ver. | ICE     | OK/NG  |

|--------------------+-----------------+---------+------------|

|                        |                      | I-Jet    | OK        |

| S6E1A11C0A | v 8.11.3         | --------- | ---------- |

|                        |                      | J-Link  | OK       |

|-------------------+------------------+---------+-----------|

|                        |                      | I-Jet     | NG      |

| S6E1A11C0A | v 7.70.1        | --------- | --------- |

|                        |                      | J-Link  | OK       |

|-------------------+------------------+---------+-----------|

デバッガのバージョンを変更のみでも、NG→OKと変化が出ておりますし、コンパイラ依存とも思えませんので、差分はローダーくらいしかなさそうですが、如何でしょうか。

以上、よろしくお願いいたします。

0 Likes
Anonymous
Not applicable

ご確認ありがとうございます。

同一デバイスで同一プロジェクトを使用しているのであれば、EWARMのバージョンが同じであれば、ローダーも同じものを使用している可能性が高いのではないかと思います。

EWARMのバージョン違いで結果が異なる状況に対してはローダーが要因となる可能性がありますが、

同一EWARMバージョンでICEを切り替えただけで結果が変わる要因としては、ローダーの影響は考えにくいと思います。

むしろ、ICEの設定に依存性はありませんでしょうか?

EWARMであれば、ICEごとに設定オプションが別れていると思いますので、EWARMの異なるバージョン間の違いも含めて、

I-JetまたはJ-Linkの設定に違いがないかご確認いただけませんでしょうか。

よろしくお願いいたします。

Nada

0 Likes
Anonymous
Not applicable

Nada-san,

ICEの設定が問題になるのであれば、ツールのバージョンにより違いは出てこないと思います。

設定を確認をしましたが、関係するであろう項目は、同じになっています。

C_HALTというレジスタに1が設定されていると、CPUが停止するようですが、

このレジスタをHighにするのは、C_DEBUGEN=1のとき以外にもありますでしょうか?

また、他にCPUを止めるようなレジスタはありますでしょうか?

以上、よろしくお願いいたします。

0 Likes
Anonymous
Not applicable

C_DEBUGEN/C_HALTのご質問につきましては、Cortex-Mコアの仕様になりますので、

お手数ですがarm社にお問い合わせください。

また、プログラム書き込み時に弊社MCUがそれらのレジスタやビットを能動的に操作することはありません。

ホストアプリケーション(EWARMなど)がデバッグポート経由でアクセスし制御する形になります。

プログラム書込み時のホストアプリケーションからのアクセス/制御については、ホストアプリケーションの提供元にお問い合わせください。

J-Linkではすべて正常に動作し、I-Jetでのみで症状が発生するとのことですので、

I-Jetによるデバッグポートへのアクセス/制御に何か糸口があるのではないでしょうか。

繰り返しになりますが、INITXリセットでは一部のレジスタ/ハードウェアが初期化されません。

FMシリーズのペリフェラルマニュアルに記載の通り、初期化されないハードウェアの中には、

デバッグ回路も含まれます。

そのため、例えば、プログラム書込み後、デバッガがCPUコアの制御権を解放しないままでいると、

INITXリセット後、CPUコアが動作できない可能性があります。

よろしくお願いいたします。

Nada

0 Likes
Anonymous
Not applicable

何かめちゃくちゃですね。

同じ、I-Jetでもデバイスにより、状況が変わるんですけどね。

0 Likes