ＰＩＣのデータシートを読むと、プログラム用のフラッシュメモリ消去／書き込みサイクル１０００回、また
データ用の内蔵ＥＥＰＲＯＭ消去／書き込みサイクル１０，０００，０００回と書いてある。
これは最低保証値と思うが、本当かなあって思うことあるよねえ。本当にそうなのか試してみたいじゃ
ん！！ なんか、サディスティック（笑）。
なにしろ工場出荷時にはテストできないわけだ。壊しちゃいかんし、時間がかかる。品質管理では、
おそらく抜き取りで、何個かをテストしてるぐらいだろう？極端に違う事は無いと思うけど。
秋月のＨ８／３０４８Ｆボードを、試作実験用に使っていたけど、あれは確か最低保証１００回書き換え
だった。実験のときは頻繁に書き換えをしていたから、時々気になっていた。まあ、壊れたら交換すりゃ
いいんだけどね。
０．５ピッチだから、カッターで足を切って、ハンダを溶かしながら除去して、吸い取り線で残ったハンダを
とって、新しいやつをのっけて、という感じで交換するのが、設備を必要とせず簡単だ。
おもちゃデジカメが内蔵しているフラッシュメモリだって、使っていくうちに不良ビットが増えていくのかね？
代替処理とかするのかね。いろいろ心配の種がある。確かめたくてたまらない。
家にはＰＩＣ用のＩＣＥがないから、趣味でプログラムを作る時は、何度も書き換え、ソケットから抜き差しを
しながらデバッグしていく。このサイクルで１０００回は気が遠くなりそうな話だし、そんなに書き換え回数が
多い事のほうが問題だ。
インサーキットで書けって？ いや、今はそういう問題じゃないんだね。インサーキット対応するには、
ターゲットの回路を工夫しないといけないでしょう。そのへんが面倒で・・・。
１０００回も書き換えする前に、ピンが傷んでダメになるほうが早いだろう。ソケットを１段余分にかませて
足を保護してるけど、って、きりがないからいいか。
用途によっては、電源を切る前にＥＥＰＲＯＭへ学習値をセーブするなど、比較的、書き換え回数が多い事
がある。こんな時は、ＥＥＰＲＯＭの書き換え回数が気になるもんだね。
それで、書き換えの頻度を計算して、だいたい寿命はこのくらいかなあと計算してみたりする。
とにかく、確認してみようじゃないかというのが、今回の趣旨。
プログラムのメモリじゃなくて、ターゲットは、１０，０００，０００回の消去・書き込みサイクルのＥＥＰＲＯＭに
する。
テストプログラムの処理をどうするか考えてみた。
書き込みは０番地だけいじめる（笑）。
テストデータは２種類で、５５ＨとＡＡＨにする。これを１回ごと交代で書いてベリファイする。一致しなかったら
エラーを出して止める。
ＰＩＣ１６Ｆ８ｘのデータシートによると、ＥＥＰＲＯＭの書き込み失敗は、１を書いたのが０と読めるようだが？
１回ごとにカウントする。１０，０００，０００回だから、８ビットのレジスタを何個も重ねていかにゃならん。うーむ。
処理に時間がかかりそうだ。処理速度を考えたら、いかんいかんそんな事では・・・。
プログラムはベタ詰めにする。サブルーチンは使わない。とにかくストレートに走るようにする。・・・と思ったが
こんなプログラムに手間をかけられないので、他のプログラムから必要なルーチンをひっぱってきてくっつけた。
そうだ！ＥＥＰＲＯＭの書き込み待ちで、ポーリングしてる所の前後で、オンオフさせてパルスをポートに出す。
このパルスを、外につないだ周波数カウンタ（カウントモードにする）で数える。どうだ！
そのパルスは、１回の書き込みにかかる時間を測定するのにも使える。オシロで観測して、パルス幅を測ればよい。
この方法ならプログラムでカウントするより処理速度が上がるし簡単だ。
ＥＥＰＲＯＭの書き込みは１０ｍＳｅｃ前後らしい。
一応、１０ｍＳｅｃとして計算すると、１秒間に１００回で、１時間に３６０，０００回で、１日で８，６４０，０００回だ。
ということは、丸２日間つけっぱなしにすれば、結果が出るってことやね。
処理速度をいろいろ気にしていたが、このミリセコンドが大きいから、他の処理時間はほとんど無視できるかも。
さすがに、データ保持４０年以上というのはテストしようがないが・・・。４０年も使うわけないし。
ＥＥＰＲＯＭの寿命末期って、どうなるんだろう？
もしベリファイでエラーが出たら、もう１回書けば大丈夫だったりしないかなあ。それは何度もやれないかもしれ
ないような気がするがどうか？
書き込みはポーリングでやっているが、この時間は何を根拠に決まるのだろう。内部のハードウェアで決まる
ようだが、どんな仕掛けになっているんだろう？
新しいうちは短時間で書けるが、古くなると時間がのびるなんて事はあるんだろうか？
書き込みを繰り返すとそのバイトは劣化するんだろうか？そこへ書き込みをしたら、データが早期に消失したり
しないだろうか？
「窓付きＥＰＲＯＭ」をさかんに使っていた頃は、確か、書けなくなるか、または消えなくなっておしまいだった。
消えなかったから書けなかったのだろう。
うーむ、とにかく試してみないとわかんないぞ。
・・・ということで、いま取り組んでいる物件が済んだら、この実験をやって、このページで結果報告したいと思い
ます。
●３月３日
簡単そうなので、さっそくやってみた。
上の基板がターゲットボード、そしてＬＧ電子のＦＣ−７１５０周波数カウンタ（秋月の広告を見れば値段がわかる）。
ターゲットボードは、とりあえずＰＩＣが動かせるなら何でも良いので、そのへんにあったジグ基板を拝借した。
１回の書き込みごとにパルスを出力するようにして、これを周波数カウンタのＴＯＴＡＬモードでカウントしている。
一応、１回の書き込みに１０ｍＳｅｃと仮定して、所要時間を考えていたが、実際にやってみると１秒間に２００回程度
進んでいるようだ。
１０ｍＳｅｃでの計算では１時間３６０，０００カウントだったが、実際には１時間７００，０００カウントいっている。だから
１０，０００，０００回は１４時間半ぐらいで到達するはずだ。
私が寝ている間にＰＩＣは逝く（笑）。
プログラムのテストを何回かしたので、その分のＥＥＰＲＯＭの書き込み回数があるが、とりあえず考えない事にする。
ところで、プログラムを作りながら思ったのだが、ベリファイエラーの処理って試しようが無いんだよね（方法がないことは
ないが、困難）。実際にＥＥＰＲＯＭからバケたデータが来ないと。机上では間違いないプログラムだったが。
ベリファイエラーが出たら、その時のテストデータと、化けたデータをＥＥＰＲＯＭの他の番地に保存して、ＬＥＤを点灯し
無限ループするように組んであるが、試したことがない、いや試しようがない（笑）。
ＥＥＰＲＯＭの読み書きルーチンは、基本的に形が決まっている。書き込みシーケンスが指定されているからだ。その
へんの参考書からひっぱってきたが、だまされた！
おかしいなあと思って、「ＰＩＣ活用ガイドブック」と見比べてみたり、ＰＩＣ１６Ｆ８Ｘデータシートをしつこく読み返したりして
やっとハッキリした。このプログラムでは、いつまでたっても書き込み開始しない。
「ＰＩＣインターフェースハンドブック」（第３版）の６７ページのＥＥＲＯＭＷＲは間違っている。私は、この本の初版から
買っているが、３版でもまだ間違っていた。
初版は初めてＰＩＣを勉強するのに使ったから、何度も何度も読み返してボロボロになっている。間違いが多かったから、
自分であちこち書き込みをしたり、紙を貼り付けたりしている。
問題のある部分を抜粋すると・・・
ＭＯＶＷＦ ＥＥＣＯＮ２
ＢＣＦ ＥＥＣＯＮ１，１
ＥＲＷＲＬＰ ＢＴＦＳＣ ＥＥＣＯＮ１，１
赤い字（下線）がＣになっているが、ライトコントロールビットはソフトじゃクリアできないし、そもそも、ここでは、
「セット」してライトサイクルを開始させるわけだから、Ｓにしなければならない。
やられた！！
この本を出しているところのＷｅｂで、修正情報を見たが、この件については書いてなかった。むっ。
あとＥＥＰＲＯＭで思い出すのは、むかしパソコン通信をやっていた頃のこと。
当時は、いちいちコマンドを設定してからでないと使えなかった。ＡＴＭ３Ｌ１￥なんとかかんとか、というふうに、
今ではデフォルトで使えるのが当たり前だが、なぜか当時はそうなっていなかった。指定しないとちゃんと使えなかっ
たのである。個人的には、ロックウェルのチップセットマニュアルと、各社モデムのマニュアルを集めて、初期値の違い
と、機種ごとの設定例を調べて、こんなふうに設定するといいですよと発表したりしていた。
ところで、ＫＴＢＢＳのホストプログラムに関連して、モデムの設定例がいろいろ公開されていたが、中にはマヌケな
奴があった。＆Ｗを入れてあるのである。
＆Ｗというのは、モデム内部のＥＥＰＲＯＭに、設定を書き込むためのコマンドだ。記憶されたものが初期値になる。
これは設定する時だけしか使わないものだ。この設定の意味をとり違えたのか、ホストプログラムの初期化のコマンド
のところに入れてるもんだから、ユーザが切断後の初期化で、毎回これが実行されていた。明らかに無駄というか、
ＥＥＰＲＯＭの寿命にも関わる問題だという認識がなかったと思う。
ここでいう設定とは、一度だけ、ＷＴＥＲＭなりＫＴＸなり通信プログラムで、手動で初期設定コマンドを書き連ねて
最後に＆Ｗする事を言う。決して、通信の前後に毎回行われる初期化の時に＆Ｗをするもんじゃないということ。
あと、変態だなと思ったのがＳ○ＮＹのモデムだった。ＳＭＤ−２８０Ｗはクソ高かったが、こいつにはＥＥＰＲＯＭが
内蔵されていなかった。他には無い特徴だった。おかげで、初期化コマンドは延々長くなっていた（笑）。
いま思えば、チップセットのマニュアルを持っていたから、どのピンにＥＥＰＲＯＭをつなげばいいかわかっていたん
だよなあ・・・他のモデムからはずして、くっつけてみればよかったな。もう捨てたから試しようがないし出番もないけど。
Ｖ．ＦＣだったけどＶ．３４アップグレード対応しますという言葉を信じて買い、ひたすら待っていたら、そのころには新品が、
アップグレード料金と同じ値段だった（笑）。
●３月４日
午前１時ぐらいに、１０００万回に達したのを確認してから寝たが、朝起きたら、止まらず健闘していた。
すでにＴｙｐ値１０００万回をこえて、１４５２万回の証拠写真！
でも本当かなあって、心配になった。思わず、ソースプログラムを開いて、エラーチェックの部分を見直したりした。
大丈夫のはずだが・・・。
１千万回というのは、データシートの一番最初のページに書いてあるのだがこれはＭＡＸ値なのか？ 日本語の
データシートを見たが特性欄が空っぽ。そう、英文を見てくれという事だ。わざわざ最新版をダウンロードしてきた。
Data EEPROM Memory Endurance Min1M Typ10M Max- E/W 25℃ at 5V
最低１００万回、標準１千万回、最高は不明だな。１千万回は最低保証じゃなくて、標準値だからクリアできて当然
という解釈でいいのかなあ。１００万回で早死にするやつもあるという意味か。
MinとTypが１０倍違うが、TypとMaxは１０倍違うという事は無いと思うがどうか。
あと、消去／書き込みサイクルはTyp4mS Max8mSと書いてあった。
結果発表です！！
ＰＩＣ１６Ｆ８４−１０／Ｐ 製造ロット９７１２ＳＡＭ １個は、２００２年３月４日２１時前、ＥＥＰＲＯＭ０番地の機能不全に
より、お亡くなりになりました。
ここにつつしんで、一度も世の中の役に立たなかったＰＩＣ君の数奇な運命に同情しつつ、お悔やみ申し上げます。
テレビを見ていて気づかなかったが、いつの間にかカウンターが止まっていた。
なお書き込みサイクル数は、［２３，０６２，００３回］です。テストで何度か走らせたので、本当の値はこれよりも若干多い
です。
エラー発生時の、書き込もうとしたデータは［55h］で、ベリファイ値は、［D5h］でした。読む方はミスしないと思うから、
正しく書けなかったという解釈で良いと考えます。
５５ｈを書いて５５ｈと読めるべきデータがＤ５ｈになった。Ｄは１１０１で、おそらく前回にＡ（１０１０）を書き込んだ時の
１が消えずに残っていたのではないか。
リセットして再起動してもすぐエラー終了したので、０番地には書き込みができなくなったのでしょう。ＰＩＣライターで読み
出したら０番地はＦＦｈになっていました（この値は、プログラムを再起動した時に書き込まれたと思う）。
なお、クレーム対策として・・・これらのデータはあくまでも実験値であり、もちろんメーカーはこれを保証するものでは
ありません。単なる技術的興味に基づくヒマつぶしの実験であることをお忘れなく。
ついに訪れた静寂 （カウンタの数字が止まった）
遺影 （鉛筆で描いたＸ印が哀しい）
でも、ＥＥＰＲＯＭの０番地以外は、まだ使い道があるっす。０番地を何かのテストに利用することもできるし。あるいは
他の番地をどんどんつぶしていくか？（をいをい）
いや、まてよ・・・実際にやってみたら、ＰＩＣライターが書き込みの一連の流れの中で、ＥＥＰＲＯＭにも書き込み＆ベリ
ファイするから、エラーが出てしまった！
このＰＩＣ使えなくなっちゃったよ！（あるいは、ＥＥＰＲＯＭの書き込みを禁止する設定ができるライターを使うか？）
にょ？ プログラムを先に書いて次にデータＥＥＰＲＯＭを書くから、たとえＥＥＰＲＯＭの書き込みでエラーが出ても
すでにその段階でプログラムは書き込まれているから大丈夫か。
ＰＩＣ死す！
分かったこと。
１． ＰＩＣのデータＥＥＰＲＯＭには、書き込み回数の寿命があることを確かめた。
２． 書き込み回数はＴｙｐ１千万回だが、およそ２倍以上の実力があった。
（しかし、データシートによればＭｉｎ１００万回なので、早死にするものもあると思われる。）
３． ＥＥＰＲＯＭ全体が死ぬのではなく、その番地だけ。つまり、ある番地が寿命に達したら、他の番地で代替可。
４． ＥＥＰＲＯＭが死んだＰＩＣへ、新たにプログラムを書き込むとき、ＥＥＰＲＯＭエラーになるのが厄介。
５． 周波数カウンタを買って以来、初めてＴＯＴＡＬモードを使い、役に立った。
６． 一度書き込みエラーした番地へ、再度書き込みをしようとしてもできない。リトライで解決できない。永久破壊。
７． 特にＰＩＣが発熱するという事はなかった（パッケージ表面の触感）。
ちょっと疑問に思ったが、違うデータではなく同じデータを繰り返し書いた場合、また特定のビットに１または０を繰り返し
書いた場合はどうなるか。やはりこれも、「消去→書き込み」の手順のため、寿命的には、特に大差ないと推測している。
あと試してみたい事は、放射性物質をのせてみてどうなるかだな。むかしザイリンクスのデータブックに、放射線に
対する影響というページがあった。
そういえば、ＰＩＣのワンタイム版を書き込みミスしてどうにかならないかという話がセミナーの時に出ていたらしい。パッ
ケージの色が変わるぐらい放射線を当てたが消えなかったとか。ウソか本当か知らない。むかし、人から聞いた話。
窓付きとワンタイムのチップは同じもので、単にワンタイムは窓が付いてないから紫外線を当てて消せないという話だっ
たと思う。だからＸ線を当ててみたようだ。
ＰＩＣじゃないけどワンタイムのマイコンに、硝酸で穴をあけて紫外線が当てられるようにして使っていた奴も見た事がある。
大丈夫かと思ったけど、ちゃんと使えてるよとの事・・・。
窓付きＥＰＲＯＭのサンプル品なんか、フタが接着されてなくて、セロテープで仮止めしたやつだもんな。型名も印字されて
ないという・・・どこかで見た。
「電子立国日本の自叙伝」で、「西洋ガンバコ」と呼ばれていた初期のＩＣが紹介されていた。形が棺桶に似ていたから
西洋ガンバコだったらしい。
当時、電電公社に納入する交換機に使われていたＩＣだが、そのテストが厳しく、毒ガスにさらしたり、グツグツ煮込んだり
叩きつけたりと、半端じゃなかったそうだ。
最近Ｈ２Ａ型ロケットで打ち上げられた衛星には、民生部品をテストするという使命があるそうだ。従来、宇宙開発に使われて
きた部品は、信頼性確保のため、「枯れた」部品が使われていて、民生品と比べて２世代ぐらい古い技術だったそうだ。
そういや、むかし、宇宙開発用のバイポーラＲＯＭとか、雑誌で見たぞ。ヒューズ式だから放射線には強いのでしょう。
中学生の頃、「マエダ衛星」という事で、カメラのストロボを積んで、夜にピカピカ光る衛星を飛ばすことはできんかなあと
アホな事を考えていたっけ（笑）。
むかしアマチュア無線衛星のＡＯ−１０だったか、当時「ラジオの製作」に記事が載っていた。興味深かったのは、宇宙の
放射線によって、搭載コンピュータのメモリが壊れて、使えないビットがあり、そこをバイパスするようにプログラムを修正
して動かしていたという話があった。どんどんメモリが壊れていくので、運用を継続するのが大変だったようです。
使えないアドレスを回避するということは、たぶんアセンブラで作っていたんだろうね。
不良アドレスにＮＯＰを書いて飛ばしても、壊れているのだから違うコードになる可能性もある。きっとジャンプ命令でその
番地をバイパスしたに違いない。すきまうめはＮＯＰだろうけど。
仮にＺ８０だったとして、２番地が壊れていたら、ギリギリ０、１番地にＪＲ命令（相対ジャンプ）が入るよな・・・。相対ジャンプ
で、３番地にジャンプする。ところが４番地がまた壊れていて、幸いにしてリード値が００ｈだったからＮＯＰということで、
からくも生き延びて、かと思ったら１０番地から３００バイトぐらい壊れているから絶対ジャンプで飛ばしたいが３バイト入る
かなあ・・・って感じ？（笑）
どうしても１バイトしかなくて、ＲＳＴ命令でとりあえず飛ばして・・・とか。
なぜか不良アドレスが、ＸＯＲ Ａ命令と同じコードに読めて、プログラムのこの部分でＡレジがクリアされたら困るし、前後を
入れ替えてみるかとか。こんなふうにやっていたら、きっとザルソバスパゲティになるだろう。
通信でプログラムをロードしていたようだが、そのためのプログラムは当然ＲＯＭだったんだろうか。
放射線がメモリセルを通過する時のエネルギーで、ビット化けが生じることもあるようですね。半導体のパッケージ樹脂に
含まれていた微量の放射性物質が、メモリ不良の原因だったという話をどこかで読んだことがあります。もちろんすでに
対策されていますが、みんな最初は気づかなかったのでしょうね。
メモリテストのアルゴリズムって意外に難しいって知ってた？
なに？メモリテストなんか適当なデータを書いて、同じ値が読めればいいだろって、そんなわけにはいかんのよ。
全部の番地に同じ値を書いたら、アドレスが死んでてもわかんないでしょ。データビットが隣同士ショートの検出とか
ある番地だけ単独でテストする方法とか、１バイトずつ０〜ＦＦｈが全部書けるかテストしていたら気が遠くなるよね。
パソコンが起動するときのメモリチェックの値がガガーッと増えるやつ、あの内部動作はたぶん、５５ｈ書いてベリファイ、
ａａｈ書いてベリファイとか、そのくらいのもんじゃないの？（ソースを見たことは無いが） なんせメインメモリが１ギガバイト
とか、普通になりつつあるからなあ。１ギガを真面目にテストしてたら時間が・・・。
最近の大容量メモリには、確かセルフテスト機能無かったっけなあ・・・忘れた。たぶん工場検査での必要性もあって
機能を備えていたと思う。
確実そうなのは、ある番地から次の番地へデータを移動していって、最後の番地になったら最初に移動するようにして
グルグル回す方法がある。これで延々とコピーを繰り返させて、データが化けなければＯＫというわけだ。
データじゃなくてプログラムでも良いと思う。リロケータブルにしておいて、どんどん次のブロックに自分自身を移動させて
いく。このプログラムの動きによって、正常か異常かわかるようにすると良いと思う。「生きて」いる限り、正常ステータスを
返すようにするとか。