Vcc rises, then falls to zero, in CCSLoad diagnostics

[johngriswold]

I'm new to PIC (well, I did use one 5-6 years ago), and I'm having issues with the MACHX debugger. When I connect to the PIC, the CCSLoad program can program the device. If I go to the Diagnostics part of CCSLoad, Vcc jumps to 2.0V (the correct number), but immediately drops to zero again. I thought it was a sequence issue, but no matter in what order I plug in, power up, start software, etc. the voltage doesn't come up properly.

A side effect (maybe not?) is that when debugging, it will execute instructions improperly, i.e. a JMP 103 might end up going to 143 or something. It's pretty weird.

Has anybody solved a problem like this? There's at least a 50% chance that I am doing something completely inappropriate, but I haven't been able to figure it out yet.

All answers welcome.
_________________
John Griswold KK1X
High Tech Migrant Worker

[PCM programmer]

MachX can supply power to your target board. This is an option.
Do you have this enabled ?

If you do, suppose your board consumes more power than the MachX can
supply. This would explain the 2.0v dropping quickly to zero. Your board
could be overloading the MachX's output power circuit.

The CCS FAQ explains how to setup MachX to supply power to the target:

[temtronic]

It's not just a MACHX issue. When I upgraded from the Picstart PLUS to the PICkit3 years ago, I'd power the test PCB from the PK3. Went through similar 'fun' the day I added a power hungry peripheral. Took couple of head scratching hours, finally READ the PK3 manual, disabled the 'power from PK3' option, added a USB<>TTL module to supply power from PC. That solved the 'issue'. By using the USB<>TTL module I also got 'free' serial communications to the PC as well as a stable power supply for the test PCBs. These modules also have both 5 AND 3 volts, rather handy when using newer PICs and 3V only peripherals.
Jay

[johngriswold]

We have tried using the MACHX to supply power. Same behavior. The other chip on the board consumes (at 3.6V - we're running at 2.0) 1.6uA max. The PIC consumes something on the order of 30uA. The supply voltage is right at 2.0V, measured, so I don't think overcurrent is the problem.

I'm still entertaining answers, but I'm going to contact CCS support.

Thanks again,
John
_________________
John Griswold KK1X
High Tech Migrant Worker

[Ttelmah]

I would be suspicious of overcurrent.

Question.
Is there anything on the board that drives or could drive power?.
Problem is that all the PIC I/O lines when in program mode, are set as inputs.
If you have any circuitry attached that can float 'on' (does not have 'turn off' resistors in the hardware), this can then come on, and draw unexpected power. Lines that normally start 'low' and only float up slowly, unfortunately with the time needed for programming can float into the transition or 'on' regions. This is why well designed boards will always have external hardware to ensure floating signals are biased 'off'.

[johngriswold]

I contacted CCS Tech Support about the issue. After a few days of head-scratching, they came back with a suggestion that I not use the dreaded Multiple Compilation Units. I used an #include directive to suck in the second C file, and it appears to be much better behaved.

Go figure.

Thank you all for your suggestions.
_________________
John Griswold KK1X
High Tech Migrant Worker

[temtronic]

Well THAT makes zero sense to me. Your original post sounds like a power supply problem NOT a code issue. I'd really like to hear the true solution to your headache though.
Jay

[johngriswold]

So would I, Jay. So would I.
_________________
John Griswold KK1X
High Tech Migrant Worker