始めまして。M16C/65Cのデータフラッシュに関して質問します。
M16C/65Cを使用し、DCモータを回転させる機器を作成しています。耐久テストをするために、ADに外部から信号を入力して一定期間ごとにオンオフさせ、モータが停止しているタイミングで動作時間をデータフラッシュに書き込むプログラムを作成しました。機器を５台作成して、E8aを使用しFDTでプログラムを書き込み、テストを行っていました。途中１台について、ADに信号を入力する治具が故障（可変抵抗器が破損）して停止したため、治具を修理して再開させましたが、データフラッシュに時間が書き込まれなくなっていることが分かりました。調べてみると、データフラッシュのロックビットが立っていました。ロックビットは通常、フラッシュROMにプログラムを書き込む際に設定する物だと思うのですが、外的要因で書き換わってしまうようなことが起こり得るのでしょうか？
こんにちは
M16Cは詳しくないのですが、教えて下さい。
ロックビットが立っていたとは、データフラッシュからリードロックビットのフローを実行してFMR16を読み出すと0(ロック)となっていたということでしょうか？
それとも1(非ロック)となっていたのでしょうか？
わわいです。
電源ラインにスパイクノイズが乗っていないか調べてみましょう。
モータを駆動している、ということで、いかにも乗ってそうな感じですねー
CPUなりフラッシュメモリなりの定格から外れた使い方をしていれば、何が起きても不思議はないってことですね
まーしかし、電源のスパイクってのは、ふつーのオシロをふつーに繋いでふつーに見ても、見ることができなかったりするんで難しいところですが。
その個体で1回しか発生しておらず、別の機器でも発生していないので、イレギュラーな事象だとは思うのですが。。。
全く再現しないので気味が悪いところです。
ただ、製造しているのがコンシューマー製品なんですが、稼働時間等を記録するような機能を組み込んだ場合、ユーザーがいつ電源を落とすかわからないので、書き込み最中に電源が落とされる可能性があると思います。そうなるとこの様な事象が起こることがあり得るということなのでしょうか。だとすると何らかの回避策を考える必要がありそうです。
マイコンの乗った基板とは別の電源基板からモーターとマイコン基板にそれぞれ24Vと5Vを供給して、モータはPWMで制御していています。ADは電圧を直接操作するのではなくPWMの幅を決めるのに使っています。（ソフトが専門なので回路についてはあまり詳しく説明できなくて済みません）
可変抵抗器を物理的に動作させる耐久試験器があったのでそれを接続していたのですが、試験機自体が壊れてしまって（抵抗器が破損）おかしくなりました。抵抗器が壊れるときに変なノイズの様なものが発生して、書き込み動作中のマイコンに悪さををしたのかもしれません。
うーん、その「耐久試験器」ってのを、ナニやってどう壊れたかにも寄るでしょうか。
シンプルに考えるなら可変抵抗の両端に電源GNDでセンターがAD入力接続でしょうけど、例えば落下破損等であれば、瞬間に可変抵抗器の両端の接続線が短絡する可能性もある、でしょうか。となれば通常は、可変抵抗器の接続電源はマイコン電源と同じ電源ソースを用いていると思われますので、瞬間停電状態が発生したとも考えられます。という状況が発生し得るなら、どういう挙動が起きても不思議ではないかと。
と、これくらい妄想と嘘が言えれば、上長は納得してくれるのではないでしょうか？あとは当初予定通りの台数と時間でエージングが完了したなら、製品出荷でいいんじゃないかなー。なんか動作仕様を聞いてると、フラッシュの書き換え寿命回数の方が気になりましたけど。仕様書では1万回までって書かれてる？１日に10回モーター止まるとして３年？
電源が不安であれば、電源監視ICとかを外付けで4.5vくらいにして出力をマイコン割り込み端子に入力し、マイコン電源のみ逆流防止のうえ大きいCを抱かせといて、割り込み入った瞬間にCの電荷だけで2.7vまで降下する間にデータフラッシュ操作を即停止する、といった構成になるですかね？詳しくないですが。。
ケイイチNさん
一般的に低電圧検出を搭載していない(有効になっていない場合)は、どこのフラッシュも同様で書き込み中に電源を落としてはいけないはずです。fluxさんの書いてあるような対策が必要でしょうね。
ちなみに、ルネサスからデータ公開がないので、参考値ですけれども、書き込み回数が１０倍になればデータ保持期間はだいたい1/10になると考えておけば良いと思います。55℃で１万回２０年保証なら、10万回では2年、100万回では2ヶ月とか。
PS もしかしてロックビットの問題はM16C固有かもしれません。ユーザーズマニュアルによるとロックビットとデータの消去が同じタイミングなので、ロックビットとデータを同じブロックで管理していそうです。 そのため電源が落ちたせいで書き込み中にブロック内のデータに不整合が生じてロックビットが掛かった?!
書き込み中に電源断が起きるという構造はまずいですね。。
意図せぬアドレスのデータ化けが起きても仕方がない気がします
こういう場合は、電源電圧減を検出して、NMIを発生させ、減電圧リセットが発生する前にフラッシュの書き込み中断を行うようにしなければなりません。
また、フラッシュROMは書き込み回数に制限があるので、こういう用途には向かないですね。
稼働から数年たってフラッシュの寿命が来て書き込み不良発生、クレームが来るパターンですね
これも、フラッシュに保存しないで、IICなんかで駆動できる不揮発メモリデバイスがあるのでそれを使うようにしないといけません
＃まあ、この場合もNMIでアクセス保護する必要があります
ということで、とりあえずルネサスにフラッシュ書き換え中に電源を落とした場合にロックビットが掛かることがあるか、問い合わせをすることをお勧めします。
フラッシュの書き込みは、1回24byteを積み上げていって、満タンになったらeraseするようにしていたので、5分おきに書いても15年は持つ計算でした。なので寿命ではないと考えています。今回はテスト用のプログラムだったので、電源遮断などは考えていなかったのですが、検討してみたいと思います。
仕事の都合でなかなかres出来ませんでした。アドバイスありがとうございます。やはり、電源遮断が変な状況を招いたと考えるべきなのでしょうね。いろいろと方法を模索したいと思います。
今回はテスト用ということもあり、エラー処理などもちゃんと書いていなかったのですが、書き込めない状態で延々と書き込み処理に行っていたところ、なんかのきっかけでマイコン自体がリセットされてしまうという現象がありました。テスト用といえ、ちゃんと処理は書かないと駄目ですね。
スタックオーバーフローでも起こしてるんですかね？となるとエラー処理とか書いても解決されないような気もします。（どっかに時限爆弾系のバグが棲んでるかも）