weird power-up condition with PIC24EP256GP202

[starfire151]

Using PCWHD V5.030 and Windows 7.

I have a system powered from, and communicating through, a USB interface adapter. It is using the Adafruit USB to TTL Serial Cable - Debug / Console Cable for Raspberry Pi. This uses the Prolific PL2303 driver. This cable provides +5.0VDC, Gnd, TXD, and RXD. The TXD and RXD lines are at 3.3VDC levels.

My circuit uses the +5.0VDC line to run two MCP1802 3.3VDC voltage regulators and a MAX6043 3.3VDC voltage reference. One 3.3VDC regulator is used for the digital circuits on the board. One is used for the analog circuits on the board. My PIC24EP256GP202 processor is running from the digital regulator. Total circuit current draw (all digital and analog circuits) from the 5.0VDC supply is about 25mA - 40mA.

When I first connected the USB cable to a USB plug on my desktop, the system powered up correctly. I was able to establish a Teraterm session to the board and have two-way communications with the PIC. When I disconnected the power, though, and waited about 30 seconds to reconnect, the PIC did not start normal operation. Examination of the digital 3.3VDC supply showed it to be a stable 3.3VDC. When I unplugged and replugged the USB cable a few times, the system started up again with normal operation. It was fairly inconsistent in starting up with unplug/replug attempts, though.

Has anyone else seen this kind of behavior? If so, what was the solution?

Is there a fuse to specify a power-up delay before normal operation starts? The older PIC18LF2620 has a fuse for PUT (power-up timer), which I think adds a delay before the PIC starts trying to execute code. The delay was to allow the power supply to stabilize.

Any other thoughts on this problem?

Thanks for any help...

[Ttelmah]

The PUT fuse is to allow the oscillator time to stabilise after power is applied.

The PIC24, doesn't use this. Instead it does a 'fast' power up, using the internal oscillator. It is then up to your code to check if the oscillator is running at the speed you want, before proceeding. Simply delay, or read the LOCK status bit (you can access this directly, or by the return from the setup_oscillator function), and wait for this to go true.
The whole point of the fast wake up, is so that 'non timing' operations can be done ASAP.

[starfire151]

Thanks, very much, for your reply.

I looked at the description for the setup_oscillator() function. It stated some chips return a state such as OSC_STATE_STABLE to indicate the oscillator is stable. It also stated if I specified a #USE DELAY to specify the operational frequency, the compiler should do the startup delay automatically. I'm using a #USE DELAY(internal=58960000) statement. If I understand this correctly, it also stated if I did a setup_oscillator() function after that, the setup_oscillator() function would take precedence. In looking at the processor file description for arguments for the setup_oscillator() function, it listed OSC_INTERNAL, OSC_CRYSTAL, OSC_CLOCK, OSC_RC, and OSC_SECONDARY as options. I assume I should be using the OSC_INTERNAL option (?). It also stated the setup_oscillator() function did not had a (void) return value. The second argument for the setup_oscillator() function is listed as "target", which I assume is my target operational frequency?

I looked in the getenv() function for anything related to the stablility of the oscillator but didn't see anything there.

How would I look for the LOCK status to look for it to be true?

Thanks, again.

[Ttelmah]

The lock bit is available as:

#bit LOCK=getenv("BIT:LOCK")

[starfire151]

Thanks very much for that.

I define the LOCK bit in my main header file:

#bit LOCK=getenv("BIT:LOCK")

and then included the following code at the beginning of the main() section:

[PCM programmer]

Experiment. What happens if you get rid of the USB cable and just hook
up the board to a +5v power supply ? Does the PIC still fail to start
when you flip the power switch on/off ? Also try this with the power
supply on, and put a power switch on the board itself. Flip that switch.

Also do Ttelmah's experiment. Get rid of the Lock routine and just put in
a delay_ms(1000) statement at the start of main(). Does it still fail ?

The PIC data sheet shows a 10uF Vcap capacitor is required. Do you
have it installed ?

[starfire151]

I have been doing a LOT of experimenting with this thing...

I tried the suggestion of putting a delay_ms(1000) statement at the beginning of the main() section. I could not get it to start up at all with that configuration.

I disconnected the TXD and RXD lines from the interface and only connected the +5VDC power and ground lines. It still fails most of the time but sometimes starts correctly.

With ONLY the +5VDC and ground lines connected, I plugged the USB connector into an AC-to-USB adapter so it was getting the +5VDC power from the adapter not a USB port. THAT configuration starts correctly every time (with or without the checking for the LOCK bit or a delay at the beginning of code).

I have a 10uF, MLCC (low ESR) cap connected from the VCap pin (pin 20 of this device) to ground.

I tried to power it from and external +5VDC power supply. The first time I switched on the power, it ran correctly, showing a current draw of around 23mA. I disconnected power, waited a few seconds, and reconnected power. The system did NOT start correctly and it showed a current draw of only around 5mA. I disconnected the power supply power and reconnected it a few times. It started some times and failed to start some times. It seemed to start if I waited about 1 minute before trying to start it up again.

[temtronic]

preface. I have zero hands on experience with the 24 series
but...

saying that you have to wait a minute and then it works OK sounds like a cap is holding a charge and not allowing the PIC to startup properly.
When it's totally 'dead' it starts fine....to me that kinda says you need a discharge path for the 'mystery' cap. If you're running a 3v reg from the USB +5 have you a reverse diode across the reg output to input ?

Are all I/O pins pulled up ? Maybe one floating is an issue ?

Maybe not enough bypass caps or an unsoldered one that's floating ?

It's really a head scratcher without being there to test 'this and try that'!

hth
jay

[gpsmikey]

Or a heating issue.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[Ttelmah]

You could always test the serial RX line, and not start the code till this goes high.
However I have to agree there sounds like an issue somewhere. Is it possible that your 3.3v regulators are perhaps oscillating?.

[PCM programmer]

It sounds like Brownout reset circuit inside the PIC is not working correctly.
What happens if you get the failure mode, and then do an MCLR reset ?
Does the PIC start running ? In other words, wire up a pushbutton
circuit on your MCLR pin. Do the thing with the USB connector to get it
to fail. Leave USB power applied to the board. Then press the reset
button. Does it now start running ?

There is an errata on a PIC32, where the internal brownout feature
just doesn't work. So it's possible that bug could be in your silicon
even though it's a different PIC family:
http://ww1.microchip.com/downloads/en/DeviceDoc/80000531E.pdf

Here is a thread on brownout problems with the PIC24. Maybe add an
external reset supervisor chip to fix it:
http://www.microchip.com/forums/m796992.aspx

[starfire151]

I think I found it!

I put a 1000uF cap across the 5V input line to the board to control the rise time of the power. It works every time now!

In looking at the response when plugging in the power to an AC adapter with a USB output, the rise time is very controlled. I tried to mimic this behavior by putting a cap on the 5V line. The response when plugging directly into a USB socket was very vertical (very little rise time). Apparently this was a problem.

Thanks to everyone who responded. A class act forum if ever there was one!