|
|
View previous topic :: View next topic |
Author |
Message |
JamesW
Joined: 23 Apr 2007 Posts: 91 Location: Rochester, England
|
PIC18F87K22 spurious outputs/results when powered down |
Posted: Wed May 09, 2012 7:46 am |
|
|
I am using a PIC18F87K22 in an updated version of a design we've been making for the last few years using an 18F4685. (Never saw the problem on this device)
The system has a permanent 5V supply that does not run the PIC.
The 5V supply to the pic is turned on by an external event, that triggers a hardware latch, which then keeps the 5V to the PIC on - until the processor has completed it's task - at which point it turns itself off by raising an output, which is connected to the clear pin of the above latch.
There is a large reservoir capacitor connected to the PIC power supply, and this takes about a second to decay after the latch has been cleared.
All this works fine. However I am occasionally seeing random outputs of the PIC change state for a fraction of a second after we have cleared the latch.
Unfortunately one of these outputs is the pin that turns the entire power to the unit off - which means that the unit is physically off (requiring a visit to the ON button on the front panel - rather than in standby).
Along the same lines we have a setup memory routine, which is only run once. The unit reads from eeprom address 0, if this is not 0xAA - then it runs the setup memory, and then sets this address to 0xAA so next time it is not run.
Occasionally - the unit comes out of standby, and then re-initialises the memory.
My gut feel is that this is brownout related, and the processor is crasing and going off somewhere it shouldn't. However we are running on 5V and the brownout thresholds for this device seem to start at 3V according to the latest version of the compiler.
I have contemplated putting a sleep() command into the code, after the unit clears the power latch, would this help?
I don't believe it is being corrupted in startup, as it only takes 20mS to reach 5V. (I have enabled PUT - but none of the other PUTXXX fuses).
Can anyone offer any pointers please? |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Wed May 09, 2012 8:19 am |
|
|
The PICs, both old and new, have brownout hardware. That does not mean that the firmware uses it, or uses it correctly. The K part runs its processor core at 3.3V and has an internal regulator, so if the brownout detect was used it would have to be set to account for the drop out of the on-chip regulator. That may be different from the setting required on the old chip.
When all PICs are inactive their I/O pins act as inputs, and they float. If the hardware design has not been designed to deal with this there can be problems. Floating behaviour can vary chip to chip, and certainly PIC to PIC. Its easy to get a design that, by chance, works on the old PIC but doesn't on the new. That's a hardware design problem that needs to be sorted (by a HW designer who know about microcontrollers/processors). Its simple, it just needs doing right.
I have used a ARM based NXP microcontroller, the LPC2214, for a handheld device. That also did power control. Everything worked well until NXP up-issued the silicon, with faster IO cells. Then the power off behaviour changed, possibly not unlike yours, and the design wouldn't work with the new chips. NOT different chips, just new rev versions of old chips!
The problem turned out to be glitch-like behaviour on the IO lines during the start of reset as the unit powered up, not as it powered down.
We went through the gamut of last-time buys, grey market and finally had RS (a big UK distributer) reps running around for us, finding the very last of the old rev chips in the UK. Not a good way to build product. I refused to play that game and held out for a redesign to solve the problem properly. I, and the project guy who went to hell and back to get those chips were sacked for our trouble. Apparently we were supposed to keep on building thse forever without even mentioning any real world problems as trivial as our inability to source the key component! Grrrrrrr.
RF Developer. |
|
|
JamesW
Joined: 23 Apr 2007 Posts: 91 Location: Rochester, England
|
|
Posted: Wed May 09, 2012 9:50 am |
|
|
As an update, we have tried inserting a sleep() command after we clear the power latch.
However the unit then needs to be turned off for a *very* long period of time before it actually is off sufficiently to turn back on again, and not end up in the permanent for(;;) loop I put after the sleep.
I then tried inserting a reset_cpu() routine after the sleep() command, and that hasn't solved anything either. |
|
|
Mike Walne
Joined: 19 Feb 2004 Posts: 1785 Location: Boston Spa UK
|
|
Posted: Wed May 09, 2012 11:40 am |
|
|
My next move would be run the PIC from a bench power supply.
VERY SLOWLY ramp the voltage up and down, see what happens over a range of temperature with several PICs, sort out the hardware problems.
Mike |
|
|
JamesW
Joined: 23 Apr 2007 Posts: 91 Location: Rochester, England
|
|
Posted: Thu May 10, 2012 8:48 am |
|
|
CCS support last night suggested, that as we know in the code when we are about to switch off, we switch from our external 20MHz crystal to the internal 31KHz oscillator just before we do it - as this will be stable down to 2V. (And then do a while(1) after this).
We have tried this, and are now running 8 units on test - and up to an hour ago, thought we'd solved it. Certainly we have not seen any memory corruption.
We are running a test where every two minutes our RTC clock wakes us up, we send a text message, and go back to standby.
However, one unit just "kicked its' legs up into the air" as the power went down, and tripped the clear pin on the latch.
Is there any means of "write protecting" an I/O port?
It is a little strange, as the only port that seems to do this is PORT B. We see no strange activity on any of the other ports.
The power supply is incredibly stable, and regulated - and is derived from a 12V battery - but there are |
|
|
|
|
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
|