SAM3+CrossWorksの覚え書き

引き続き、MBAへの引っ越し作業を継続中です。いつも参照するドキュメントやコードをコピーするとともに、動作の確認。先週、CrossWorksを使ってビルドを確認したBlueSAMのコードもJTAGで書き込んで、動作確認。今回、引っ越しとともにCrossWorksとj-Linkのドライバを最新版にバージョンアップしたので、この機会にすべて設定をやり直してみながら、これまで疑問に思っていた点を再度確認してみました。

• j-Linkのクロック設定。TargetのJTAGとしてj-Linkを選択すると、ディフォルトではJTAG Speedは Best Possibleになる。ところが、これではJTAGがうまく動いてくれないので、500KHzに設定。仮想マシンで動かすことによるオーバヘッドがUSB JTAG動作に影響しないか心配だったけど、問題なく動いてくれているようだ。
• Flash書き込み時のVerifyエラー。SAM3S4Bのフラッシュへの書き込みをおこなうと必ずVerifyエラーとなる問題は解消されず。実際には問題ないので、スルーすることにする。SAM3S4Aへの書き込みでは、この問題は発生しない。
• CrossWorksプロジェクトのProject Properties -> Preprocessor Definitionsには、次の２つを追加する。STARTUP_FROM_RESET, EEFC_FMR_FWS_VAL=3.

いずれもバージョンアップでは解決されませんでした。追加する定義は、ふたつともSAM3Sのスタート・アップコードに関連するもの。STARTUP_FROM_RESETがないと、スタートアップコードの先頭で無限ループしているだけで、コードが実行されない。これは意図的にそのようなコードになっているのですが、JTAGつないでいた時にはちゃんと動いていたコードが、JTAGなしで動かすと何も動かないことになってしまうので覚えておく必要があります。

EEFC_FMR_FWS_VALは、内蔵フラッシュにアクセスする際のウェイト数を指定する。ディフォルトでは2になっていますが、3にしないとSAM3Sの動作がとっても不安定。しばしばHard Faultを発生してくれる困り者。データシートでは64MHzまでのMCKで動かす場合には2でもいいことになっているのですが、実際にちょうど64MHで動かしてみるとアウト。マイコンのチップ固有の問題かもしれないと思っていましたが、SAM3S4AとSAM3S4Bの両方で経験したので、これはもはやレビジョンあるいはフラッシュの基本的な問題なのでしょう。SAM7の時もそうでしたが、ATMELのフラッシュはアクセスにウェイトが必要となる結果、実際のアプリでの性能が他社に劣る場合がみられます。このあたり改善してもらわないと、クロックが72MHzとか96MHzとかになってもあまり嬉しくないよなぁ。

さて、こうしてビルドしたバイナリをフラッシュに焼いて、その動作確認のためにシリアルでつなごうとして、わかったこと２点。

1. Windows 7にはHyper Terminalがない。皆さんよくご存知のことでしょう。わたしもどこかで読んだ覚えはあるのですが、これまでずっとXPを使ってきたのですっかり忘れており、スタートメニューの中を探してしまいました。
2. 一方、Mac OS Lionには まだ cuコマンドが残っている!!

レガシーなデバイスを代表する扱いとなってしまったシリアルポート。Windows 7でHyper Terminalがなくなっても、普通の人は何の不自由も感じない時代になったということなんですね。Mac OS Lionでもモデムのサポートがなくなったと聞いていたので、cuが残っていることには逆の意味での驚き。いまだにuucp時代の遺物を必要とするアプリがあるんでしょうか？「さすがにcuはチョットねー」と思ったら、screenがあったのでシリアル接続にはこいつを使うことに。screenも原型は 4.2BSDだか4.3BSDの頃からあったと記憶していますが、ずいぶんと機能が増えているようですね。



９月２９日追記：
SAM3S CPUサポートパッケージのアップデートがあったので、これを当てたことろSAM3S4Bへのフラッシュ書き込みエラーの問題が解決された。また、このアップデートによりEEFC_FMR_FWS_VALのディフォルト値も変更になったので、自分で変更を指示する必要がなくなった。