problems programming PIC24EP128GP202

[starfire151]

I set up a small testbed for the PIC24EP128GP202 processor. I'm using the ICD-U64 module. I am running CCSLOAD V4.053. My compiler version is PCWHD V4.137.

I connected the PIC to the ICD as follows:

ICD pin 1 to PIC pin 1. There is a 10K pullup to Vcc, also
ICD pin 2 to Vcc
ICD pin 3 to Gnd
ICD pin 4 to PIC pin 4 (PGED3 interface)
ICD pin 5 to PIC pin 5 (PGEC3 interface)
ICD pin 6 was optional and not connected

I looked at the connection diagram under the "?" "Connection to chip" to confirm the pinouts. The diagram specifies connections to PGEC1 and PGED1 (pins 6 and 7, respectively).

Do I have to do an initial program to the chip using the PGED1/C1 interface before using the PGED3/C3 interface specified in code?

I just programmed a PIC24FV32KA301 using the PGED3/C3 interface and it found it right away.

Is there something else I need to do to get the connection to the PIC24EP128GP202 working?

Thanks.

[starfire151]

Some additional information...

I tried to program through the PGEC3/D3 interface and it failed.
I tried to program through the PGEC1/D1 interface and it failed.
I tried pulling the 10K pullup and it still fails to program.
I confirmed the power on the board is 3.3VDC.

I tried to "Test" the chip from the CCSLOAD program and it fails stating it cannot detect the chip.

[newguy]

Some time back (I think it was this past August or September) CCS published a FW update for the Load-n-Go, which CCSload found when I attached the programmer. It gave me a FW out of date message, so I blindly updated it. I then updated some of our shop equipment (with customers watching me, by the way), and it all "bricked". The Load-n-Go programmed everything (seemed to anyway), but none of it would power up after that.

I then excused myself, reverted back to the old Load-n-Go FW rev (and shot CCS a nasty email at the same time), then went back down and reflashed our stuff. ...Which then worked properly.

Point of the story - check the FW rev of the programmer and if available, try flashing it with a different FW rev, then try again. Contact CCS directly if you still have issues.

Edit: this is assuming that there isn't anything wrong with your hardware.

[jeremiah]

If it programs the KA301 fine, then it most likely boils down to a couple of scenarios:

1. As stated above...Programmer FW (also verify this chip is fully supported...ran into that a few times with a "marginally" supported chip).

2. I know everyone wants to think their boards are fine, but honestly, 9/10 times this happens to me, it was something like a bad solder joint, a flake of metal between two pins, lifted pad/trace, too much resistance, etc. Really really check out your board. Heck, if you can find a somewhat pin compatible PIC that normally works with your programmer, throw it on your board just to check the connections.


For Future:
PGEC/D 1, 2, and 3 are all ok to use first time. A few chips have fuses/configuration bits related to them, but those are for DEBUG related features

[starfire151]

Thanks for the responses.

I updated the firmware via CCSLOAD and it appears to program correctly now. The new version is 3.01.

I did really check out the board thoroughly because it is also MY experience to check the hardware first. As you say, 9 out of 10 times this is the problem. This appears to be that 10th instance, though The hardware is fine. I used this same hardware and programmer interface with the PIC24FV32KA301 with no problems, also.

Thanks for info on PGEC/D 1, 2, & 3. That's what I suspected. It's nice to have it confirmed.

I set up pin 6 on the PIC (RPI34 function) as U1RX and pin 7 (RP35 function) as U1TX via #pin_select directives. I set up pin 9 (RA2) as an output to drive a heartbeat indicator. I see no com interface and the heartbeat doesn't toggle.

I'm including a minimized version of the program...

[Ttelmah]

Generally the compiler doesn't 'know' if you have 'selected' a pin. The syntax for using the UART, is:

[starfire151]

Thanks for the response. I tried the #use rs232() line but still get no com interface.

I looked at the I/O pins of virtually all other pins and see the same thing... the lines are normally high but pulse low for about 500ns every 15us to 20us (verified by scope). This is nothing I can see that I programmed into the I/O pins. According to the device datasheet, all unused I/O pins are supposed to be programmed as outputs. All outputs were driven low. I'm not sure where they are getting this weird waveform... javascript:emoticon('')

I changed the heartbeat output to pin A3, just in case pin A2 couldn't be used as an output. I specified the #fuses OSCIO to use the pin as an output. The clock is specified as internal (#use delay(internal=32000000)), as I had done with the PIC24FV32KA301. I must be missing something else?

Thanks, again.

[jeremiah]

Can you post the entire FUSE settings from the bottom of the LST file? You don't specify some important fuses, so it might help to see what the compiler defaults the chip to for the ones you don't specify.

EDIT:

Also note that your calls to output_a() and output_b() will override all your tris settings and make all pins on A and B output. I'm not sure what that does on your board.

[starfire151]

The fuse section from the .lst file is:


Configuration Fuses:
Word 3L: 0089 ICSP3 NOJTAG NODEBUG
H: FF00
Word 4L: 00F0 NOALTI2C1 NOALTI2C2 WDTWIN_25%
H: FF00
Word 5L: 007F WPOSTS16 WPRES128 PLLWAIT WINDIS NOWDT
H: FF00
Word 6L: 00E3 NOPR OSCIO IOL1WAY
H: FF00
Word 7L: 0081 FRC_PLL IESO
H: FF00
Word 8L: 0003 NOWRT NOPROTECT
H: FF00
Word 9L: 0000
H: FF00
Word 10L: 0000
H: FF00

Won't the output_a() and output_b() only affect the output values selected with the tris_a and tris_b settings? That's the way it worked with other processors I've used, like the PIC24FV32KA301, PIC18LF2620, etc. Is this PIC is a little different, though?

[jeremiah]

FUSES look ok as far as I can tell. Though in the future, you should specify more than what you have. I've seen various compiler versions mess up the defaults. I didn't have 4.137 to check against. I usually specify NOIESO and also NOCKSNOFSM on that family of chips unless I specifically want those features.

There were a couple of fuses that dealt with the PLL, but I am unfamiliar with them. Any chance you can change your clock to just the internal speed (no PLL) and drop your baud and see if the serial works?

TRIS settings are automatically changed when you call input/output functions unless you specify fast_io. It's the same for all PICs. It's a compiler feature and has nothing to do with a specific PIC.

EDIT:
Here is a list output for your output calls:

[Ttelmah]

Lets step through things slowly.

First, forget RS232. The very first thing that should be done with any processor, is the 'flash an LED' test. This proves several things:
1) That the chip is programming properly.
2) That you are controlling a pin.
3) By timing the flash, you can also verify that the clock is at the right rate.
4) That all external connections needed are present (MCLR etc.).

Only try to go further, _once_ this is working.

Things 'special' to these chips, relative to older ones, are the need for a filter capacitor on the Vcap pin, The requirement that AVss, and AVdd _must_ be present, even if the ADC is not used, and the more stringent filter capacitor requirements round the chip (look at section 2.2, and 2.3 in the data sheet).

Now, things that might be 'problematic', are the PLL division ratio (on these chips, this has to be set _after_ initial boot). Most newer compilers will set this up automatically, but your's is old enough that this may not fully happen. This would however still leave the chip running, just at the wrong speed. You may need the NOIOL1WAY fuse, otherwise pin reprogramming is limited to one time only. Again though should only affect more complex things. I'd be most suspicious that the smoothing round the chip may not be adequate. This can then stop it booting, with PLLWAIT selected, since the PLL fails to stabilise well enough.

Best Wishes

[starfire151]

Excellent idea about minimizing the testbed to start. I should have known that...

I commented out the serial interface stuff and concentrated on just toggling an LED (pin RA4, pin 12 on the PIC). I also commented out the output_a() and output_b() lines. I went back and double-checked the cap I was using on the Vcap line and found it was leaky/bad. I replaced it with a known good one. The output lines are all nice and stable now. All the unused pins are holding at 0.

I just changed the #delay (internal=clk_freq) line (where clk_freq is the desired operational clock frequency). I tried 16000000 and saw a 2us wide low-going pulse every 20us. I tried 24000000 and saw a 1.6us wide low-going pulse every 10.4us. These were very stable.

I tried 32000000 and 64000000 but they were very unstable.

Does anyone have a simple program I could try to verify the processor is working with a correct timing? Something like toggle a pin every second or something? It would be great if it used the timer1 ISR...

Thanks.

[Ttelmah]

The standard 'flash an LED' program, is just:

[starfire151]

I've reduced the code to the following:

[Ttelmah]

You can't select 'LPRC' for the high power oscillator (needed for 32MHz)...
The low power oscillator only offers 32KHz.
The clock selection will be overriding this, but it is never a good start to be relying on such overrides...
What is actually connected to the pin?. Toggle won't work, if the pin is overloaded.

I took this: