View previous topic :: View next topic |
Author |
Message |
oxo
Joined: 13 Nov 2012 Posts: 219 Location: France
|
NOPUT risky? |
Posted: Fri Sep 09, 2016 7:35 am |
|
|
Is there any risk in using no power up timer?
This is on an 18F26K22 with no timing sensitive things on power-up. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Fri Sep 09, 2016 7:57 am |
|
|
Is the application very strictly dependent on a very short power up to run delay? If not, in my opinion it's honestly not worth the risk of omitting the power up timer. |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Sep 09, 2016 8:27 am |
|
|
agreed - if you can stand having all your I/O as inputs for that time slice PUT protects against slow rising power and i would ALWAYS use that fuse |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Fri Sep 09, 2016 10:57 am |
|
|
agreed.. I've always used PUT, 2 decades now. ANYTHING to get the PIC safely 'organised' is a good thing. I also use a 500ms delay before running an LCD_init().
BTW hardware should be designed for 'powerup mode' so that the
device' doesn't do anything 'bad'.
Jay |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Sep 09, 2016 11:28 am |
|
|
careful designers use appropriate pull up or pull down resistors to prevent accidental or unintended I/O pin states DURING power up too.
A critical design failure along those lines can make smoke and ruin in certain high power circuits. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Fri Sep 09, 2016 11:36 am |
|
|
Another potential issue that just hit me: the project may work on your bench but fails at extremes of temperature (especially low).
I once had a field support call (regarding a non-Microchip processor) where at very low ambient temperatures, first thing in the morning, the product was losing its config data (stored in an external EEPROM). I had inherited this product and, as I found out, there wasn't a power-up delay between when the processor started to run and when it tried to access the EEPROM. At very low temperatures the EEPROM wouldn't "boot" as fast as the processor - and would read back 0xff until it was properly configured. The processor would interpret that as "config hasn't been set", which triggered a later write of default config values, which the EEPROM would then accept. I inserted a 100ms delay between processor boot and subsequent accesses to the external EEPROM and the problem went away. |
|
|
|