|
|
View previous topic :: View next topic |
Author |
Message |
Torello
Joined: 29 Sep 2006 Posts: 120
|
Disabling MCLR temporarily "on the run" |
Posted: Thu Dec 04, 2008 4:58 pm |
|
|
Hi,
The Mclr reset pin can be disabled by a configuration bit. For what I understand (chapter 23.1 18LF4620) it is possible to program the configuration bit by the pic self.
Has anyone done this? I use the Mclr, but at some (short) moments (writing to eeprom, modifying circular buffer pointers etc.), I really don't want the user to (async) reset the mcu. It will corrupt that data. Applying save copies and locking flags is quite a pain in the behind. So temporally disabling the Mclr would be great.
Any jump start sample code much appreciated
Regards,
Edwin
Last edited by Torello on Fri Dec 05, 2008 1:08 am; edited 2 times in total |
|
|
RLScott
Joined: 10 Jul 2007 Posts: 465
|
Re: Disabling Mclr temporarely "on the run" |
Posted: Thu Dec 04, 2008 5:24 pm |
|
|
Quote: | ...I use the Mclr, but at some (short) moments (writing to eeprom, modifying circular buffer pointers etc.), I really don't want the user to (async) reset the mcu... |
Why are you letting the user push the MCLR button? That should not be a user-interface item. If you design your system right, there will never be a need to do a MCLR reset at the user level. _________________ Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
Torello
Joined: 29 Sep 2006 Posts: 120
|
|
Posted: Thu Dec 04, 2008 5:28 pm |
|
|
Yep, you're quite right.
But at this moment it is easier to find a software workaround, than modify 200 pcb's hardware.... |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Fri Dec 05, 2008 12:34 am |
|
|
Two remarks:
Configuration bits are self-programmable with some PIC families, e. g. 18F, but have a limited endurance as any flash cells. They are not intended for frequent reprogramming.
In a typical application utilizing self-programming, e.g. with a bootloader, ID locations would be write protected (same as the bootloader area) to achieve fail-safe behaviour. |
|
|
Torello
Joined: 29 Sep 2006 Posts: 120
|
|
Posted: Fri Dec 05, 2008 1:06 am |
|
|
Hi Fvm,
You're absolutely right! After one nights sleep, I though of that also. Assuming it would be possible, the pic would program these bits very frequently and wear out the flash.
Conclusion: idea rejected.
Thanks all! |
|
|
Ttelmah Guest
|
|
Posted: Fri Dec 05, 2008 3:25 am |
|
|
In most cases, where you can reprogram these bits, the change _doesn't come into effect till the next restart_.
Why not just program the pin as a normal I/O.
Have a 'heartbeat' tick inside the machine, use this for everything that needs timings, and have it as one 'job', simply read the state of the pin. If the same heartbeat is also used to reset the watchdog, based on a counter being fed from the 'main' code, when the pin is seen, you can simply stop resetting the watchdog. Have this set to some interval like perhaps 10*the heartbeat (so with a 50Hz heartbeat, perhaps a 0.2 second watchdog), and when you stop resetting it, yu will get a hardware restart. A reset 1/5th second after the pin is pushed, is quite fast enough to seem 'immediate' to a user, and since it is software controlled, you can disable it when wanted.
Best Wishes |
|
|
Torello
Joined: 29 Sep 2006 Posts: 120
|
|
Posted: Mon Dec 08, 2008 4:11 am |
|
|
Hi Ttelmah,
To give some insight in "though" decisions:
The application I'm working on is fully sealed and waterproof. The user can wake up the device by activating it with a little magnet. A normal switch would not survive (salt) water.
If I would not use the Mclr, I would never be able to get out of a hangup situation (tricky). If I would make two magnetic switches, a wrong "approach" of the user would trigger a reset anyway...
Maybe using an external interrupt as reset line could be an alternative. Athough this will not absolutely aways get you out of a hangup I think.
Thanks,
Edwin |
|
|
RLScott
Joined: 10 Jul 2007 Posts: 465
|
|
Posted: Mon Dec 08, 2008 7:39 am |
|
|
Torello wrote: | ...If I would not use the Mclr, I would never be able to get out of a hangup situation... |
You are indeed "stuck". Nothing short of a true MCLR will get the code out of a hangup where the interrupts had been disabled. But having an MCLR at the wrong time can certainly mess up an EEPROM write.
Since you have said that changing the hardware is too expensive, the best you can do is minimize the probability of EEPROM corruption.
One thing you can do with coding is to add some redundancy check to the EEPROM data, and to maintain two separate copies of the EEPROM data. When it is time to update the EEPROM data, switch to the alternate area in the EEPROM and update that (with redundancy check to ensure data integrety) so you normally have two generations of data stored. Sure, it takes twice as much EEPROM memory, but maybe you can afford it. Also maintain a counter in each of the EEPROM data areas. When it is time to read the EEPROM data, you read both copies and use the copy with the latest counter value and a valid redundancy check.
You can further reduce the probability of failure by limiting the times and frequency of EEPROM writes as much as possible, consistent with the needs of your application. If your code has any knowledge of the presense of human use (such as particular kinds of activity) then you can try to avoid EEPROM writes during those times too. _________________ Robert Scott
Real-Time Specialties
Embedded Systems Consulting |
|
|
Torello
Joined: 29 Sep 2006 Posts: 120
|
|
Posted: Mon Dec 08, 2008 8:04 am |
|
|
Hi RLScott,
That is exactly what I've implemented. Note, that if one invalid set is detected at startup and the valid one is read, you want to rewrite the eeprom. Be sure to take the invalid set first! (nice pitfall).
Not only eeprom stuff but also a circular buffer (ram) pointers I need to maintain save copies. Pitfall at this is that the backup write pointer, not always exactly points to the last location written. Because you don't know if the last (interrupted) write has been completed. A possible overwrite of this location can happen, creating garbled data. etc, etc
Thanks,
Edwin. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|