Problem programming a PIC24FJ64 in ICSP mode

Discuss programming specifications for ICSP.

Problem programming a PIC24FJ64 in ICSP mode

Postby rifsky » Mon Aug 11, 2014 6:22 pm

Hello,

I am building an (home-made) PIC24FJ64GA1/GB0 programmer using the ICSP mode.
As a start, I bought a brand new PIC24FJ64GB002 and downloaded its Programming Specification Data Sheet (version DS30009934C).
But there must be something I missed in the datasheet because my brand new PIC doesn't answer when I try to read it's device Id (location 0x00FF0000). It seems it doesn't enter ICSP mode.
Here are details of the process, may be you'll find a bug in it !

On the apparatus I've built, signals (Vdd, MCLR and PGED, PGEC pair) are managed by an other PIC.
This second PIC is a 18LF2550, (last year, I ve already coded a usb-interface between that device and a PC).
So with this usb interface, a PC will be able to send command messages to the pic18 which will program the PIC24FJ.
I just had to write subroutines that manage PGED, PGEC, MCLR and Vdd, using 4 pins of PIC18LF.

Last week, I prepared that code taking in account temporisations and chronograms required by PIC24 Programming Specifications.

I also prepared some hardware :
RA0 of PIC18 directly wired to PGED3 of PIC24FJ, idem RA1 to PGEC3, and RA2 to MCLR
For Vdd's power of the 24FJ : I use a 3.3V regulator which input is connected to a 12V DC via a PNP transitor.
This PNP is driven by a NPN via a 10kohm. And the base of this NPN is in turn driven by 18LF2550 RA3 pin via a 10kohm.
I also took care of Vddcore with a 10µF capacitor.
The volmeter showed Vcap=Vddcore=2.50V and Vdd=3.29V when the PIC18LF sets RA3 to 1.

I tested the delivered sequence of one and zeros produced by command subroutines.
I did so executing the command that reads the device IDs words :
Thanks to a set of 4 Leds, I looked at the sequence of 1 and 0's that goes out onto PGEC, PGED pins.
For this visual test, I slowed down the bit flow by inserting tempos in my PIC18LF subroutines.
(This assume 24FJ core accepts working in a full static way even in ICSP.)

During that test the numbers of 0 and 1 issued from PGED matched the right values :
At the beginning, Vdd is set on,
then a pulse on MCLR,
then a 32bits key (while MCLR is low),
then MCLR is set high (is 3,29V correct ?),
then the first "SIIX" commands (modified to 9pulses) followed by a 24bits-NOPinstruction,
then all other "SIX" commands (normal:4pulses) followed by 24bits-instructions,
I checked all that until VISI register reading step.
More precisely, I checked every bit was correct until data line RA0 needs be tristate (bsf TRISA,PGED).
At that point, the PIC18F is ready for receivieng the 16bits of the VISI register.
In normal conditions, the PIC24FJ should have "taken" the data line PGED and send me 16bits.
... but it did not and that's my problem !

The line was still in hign impedance, a simple test with a 3.3kohm resistor showed it.
Depending on connection as pull-up, between PGED and Vdd, or pull-down, connection between PGED and Vss
the data line was either 3.29V or 0.2V...
If the line had been held by the PIC24FJ as it should, then voltage would not have changed that much.

I also made that test (with resistor connection) at normal speed, without tempo inserted in subroutines,
the result is I either read VISI as 0xFFFF (with a pull-up R connection) or as 0x0000 (if pull-down condition).
This shows the device does not take the data line wathever the speed is.

I don't know what I am doing wrong, may be the 24FJ64 does not enter ICSP mode ...

Thanks for any idea about what could be wrong in all that !


Rifsky


PS:
The PIC18LF2550 has its own 3.3V regulator, directly connected to the 12V DC source,
About PIC18 oscillator : it is a 20MHz quartz, it feeds the PLL for producing 96MHz.
My PIC18 config is so that f0=96/6=16MHz, thus f0/4=4MHz.
So one NOP exec time is 1/4=0.25µs=250ns.
In this condition set up time or hold time shouldn't need particular care when (as they are 40 ns or less).
Unless there is some error in the datasheet (with units for instance) !
rifsky
 
Posts: 3
Joined: Mon Aug 11, 2014 2:34 am
PIC experience: Experienced Hobbyist

Re: Problem programming a PIC24FJ64 in ICSP mode

Postby rifsky » Thu Aug 14, 2014 1:15 am

re-Bonjour,
I ve found my mistake (I've misinterpretated the content of the data sheet (DS30009934C))
As I say in previous message I start dialog with the 24F device by the following steps
a pulse on MCLR,
then a 32bits key 0x4d434851 (while MCLR is low),
then MCLR is set high (I meseared 3,29V and it seems to be a correct value),
then the first "SIIX" commands (modified to be 9pulsesand followed by a 24bits-NOPinstruction),
then all other "SIX" commands (normal:4 pulses that is 4 bits) each command being followed by 24bits-instructions,

In my idea "all other "SIX" commands (normal:4pulses)" represents the instructions given by the documentation tables.
And all those tables start the same way :
Command(binary) Instruction(hexadec) Instruct(Mnemonic)
0 0 0 0 00 00 00 NOP
0 0 0 0 04 02 00 GOTO 0x0200
0 0 0 0 00 00 00 NOP
... etc.

So just after the first modified "SiX" command (which has to be 9 pulses followed by a 24bits-NOPinstruction)
I was sending a normal command of 4 bits at 0, followed by the first instruction of the table (a 2nd NOP).

And this is wrong here to produce a second NOP at this point
The first NOP we see in all tables, is in fact the NOP sent with the special 9 pulses command.
Just after the first command of 9 pulses and its 1rst NOP, it's necessary to set the core Prog Counter to a correct value...
That's what the "GOTO 0x200" does.
So this GOTO 0x200 is the very first instruction to execute before any other one can be executed.
Right now my 24F at last dare give me its device ID and version number !

Rifsky
rifsky
 
Posts: 3
Joined: Mon Aug 11, 2014 2:34 am
PIC experience: Experienced Hobbyist

Re: Problem programming a PIC24FJ64 in ICSP mode

Postby Olin Lathrop » Thu Aug 14, 2014 3:52 am

Your original post was too long to read, but you were apparently having a problem programming a 24F. It looks like you think you have it working, but this illusion will pass as you get deeper into the implementation. The dsPIC programming spec doesn't really tell you how the programming logic works, but what to do. That's bad because then you don't know what else was possible and it's very hard to diagnose when things go wrong. For example, they tell you to load data into the working registers in a certain way, but it really doesn't matter. I don't remember exactly what I did, but I tried to infer the workings of the programming logic, then used it in a way that makes more sense, to me at least.

You can see all my PIC programmer code, both the host software and the firmware. My USBProg also uses a 18F2550, which gets data from the host via USB, then wiggles the PGC, PGD, and MCLR lines appropriately. All the source code is included in the development software release at http://www.embedinc.com/picprg/sw.htm. The firmware source code is in the source > picprg directory within the software installation directory. The LProg firmware source will be the easiest to look at because that hardware has fewer options. It is in files named LPRG*.ASPIC, and there are some common files with the USBProg code called PICPRG*.ASPIC.

If you look around in there, you will see gotchas addressed that you have not yet imagined.
User avatar
Olin Lathrop
Verified identity
 
Posts: 48
Joined: Fri May 30, 2014 3:38 pm
Location: Littleton, MA USA
PIC experience: Professional 5+ years with MCHP products


Return to In Circuit Serial Programming

Who is online

Users browsing this forum: No registered users and 2 guests

cron