PICkit2 18F2550 firmware

[Jeff]

Anyone an expert on 18F2550 code? Would it be feasible to write a special
PICkit2 firmware application that would have the sole purpose of reading in
new bootloader code (0x0000-0x1FFF) and reflashing it?

If so, we would be able to update both the bootloader code and the firmware
without having to take apart the PICkit2. The code would have to do some
tricky things to avoid leaving the PICkit2 in an unusable state in case of
USB or other errors. If you wanna tackle it, contact me for details.

Jeff

[xiaofan]

Hi Jeff,

I think this is possible. To have another copy of the bootloader and
then
use that to update the existing copy of bootloader. This is especailly
possible
for PICkit 2 since it uses a big PIC with lots of space.

Here is one example but I have not looked into the details.
http://home.hiwaay.net/~jeffj1/projects/bootloader/

However this will require the re-write of the bootloader and the
Microchip
Windows PC application. Currently the bootloader is protected. So I
think
this may not happen if we are going to keep the compatibility.

I am still learning 18F USB so maybe someone else can point out
a possible solution.

The other solution is to wait for the 18F support of PICKit 2 and get
2 PICkit 2 to program each other. Of course another capable programer
will do the job as well. But the problem is that not many people like
to
open the PICkit 2 and do ICSP there. I've already opened
it quite a few times alreay though and I am lucky to have access to
ICD2 and Promate III at work.

Regards,
Xiaofan

[Mark Rages]

On 11/25/05, Jeff <j_p...@pacbell.net> wrote:
>
>
>
> Anyone an expert on 18F2550 code?

There are Microchip folks on this list. But it's a holiday weekend so
they won't see your message until Monday.

> Would it be feasible to write a special
> PICkit2 firmware application that would have the sole purpose of reading in
> new bootloader code (0x0000-0x1FFF) and reflashing it?
>

(this is from a remembered conversation; I haven't done the research
to verify this). The boot block write protect bit is set, to prevent
accidental corruption of the boot block.

Looking at thedatasheet, it says configuration registers *can* be
changed by user code, but "code protect" bits cannot be turned off.
Quoting the datasheet:

Note: Code protection bits may only be written to
a `0' from a `1' state. It is not possible to
write a `1' to a bit in the `0' state. Code
protection bits are only set to `1' by a full
Chip Erase or Block Erase function. The
full Chip Erase and Block Erase functions
can only be initiated via ICSP operation or
an external programmer.

So the question is, are write-protect bits considered "code protect"
for the purposes of this paragraph?

If not, such a bootloader-bootloader is possible.

> If so, we would be able to update both the bootloader code and the firmware
> without having to take apart the PICkit2. The code would have to do some
> tricky things to avoid leaving the PICkit2 in an unusable state in case of
> USB or other errors. If you wanna tackle it, contact me for details.
>

It doesn't interest me. The current bootloader works fine for me. But
I guess it is a problem on certain operating systems. Someone running
such a system might be motivated to write such a loader. I would
suggest modifying the present bootloader to avoid duplicated effort.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
- fortune cookie

[Mark Rages]

On 11/25/05, xiaofan <xiao...@gmail.com> wrote:
> The other solution is to wait for the 18F support of PICKit 2 and get
> 2 PICkit 2 to program each other. Of course another capable programer
> will do the job as well. But the problem is that not many people like
> to
> open the PICkit 2 and do ICSP there. I've already opened
> it quite a few times alreay though and I am lucky to have access to
> ICD2 and Promate III at work.
>

This is a solution for those of us with two PIckits (well, after the
new firmware is released). But I think most users will just have one
PICkit!

It's very easy to open a PICkit2 to get at the ICSP terminals. I can
do it without using tools.
But how will you close it again after soldering on the ICSP header?

[Jeff]

On Friday 25 November 2005 08:31 pm, Mark Rages wrote:
>
> So the question is, are write-protect bits considered "code protect"
> for the purposes of this paragraph?

Probably, so a firmware bootloader-loader wouldn't be feasible.

>
> It doesn't interest me. The current bootloader works fine for me. But
> I guess it is a problem on certain operating systems. Someone running
> such a system might be motivated to write such a loader.
>

It would be a "nice to have" feature, but it's not a big issue. The interface
software, pk2 in this case, should be compatible with the bootloader firmware
as shipped by Microchip. I wouldn't expect users to have to jump through
hoops to use it.

Initial tests on using pk2 to update the application firmware are going
reasonably well. I expect to have version 1.35 ready for release before
Christmas.

Jeff

[xiaofan]

>It's very easy to open a PICkit2 to get at the ICSP terminals. I can
>do it without using tools.
>But how will you close it again after soldering on the ICSP header?

I soldered a 6-pin SIP header (round pin) there and I can close the
cover easily. I am not so sure how to call this header so maybe SIP
header is a misnomer.

Regards,
Xiaofan

[Mark Rages]

On 11/25/05, xiaofan <xiao...@gmail.com> wrote:
>

How tall is it? Striaght or right angle?

The standard SIP header (that's as good a name as any) seems to rise
0.3" (76mm) from the board. I don't think that will fit inside my
PICkit.

[xiaofan]

>How tall is it? Striaght or right angle?
>
>The standard SIP header (that's as good a name as any) seems to rise
>0.3" (76mm) from the board. I don't think that will fit inside my
>PICkit.

I think 0.3" = 7.6mm and I think we are talking the same thing here.
I measured and it is straight and about 0.25inch tall or 7mm. After
insetion it is about 4mm tall from PCB (1.5mm PCB and 1.5mm leads).
Just nice. ;-)

I hope Microchip could provide this header in future release. ;-)

Regards,
Xiaofan

[Mark Rages]

On 11/26/05, xiaofan <xiao...@gmail.com> wrote:
>
> >How tall is it? Striaght or right angle?
> >
> >The standard SIP header (that's as good a name as any) seems to rise
> >0.3" (76mm) from the board. I don't think that will fit inside my
> >PICkit.
>
> I think 0.3" = 7.6mm and I think we are talking the same thing here.
> I measured and it is straight and about 0.25inch tall or 7mm. After
> insetion it is about 4mm tall from PCB (1.5mm PCB and 1.5mm leads).
> Just nice. ;-)

Right, I meant 7.6mm. Guess I should use a calculator for those conversions. :)

Your header is shorter than the one I've got here. If I need to
populate ICSP on my Pickit I will cut it down some.

>
> I hope Microchip could provide this header in future release. ;-)
>

Well, I haven't needed it yet.

[Jerry Zdenek]

>
> It's very easy to open a PICkit2 to get at the ICSP terminals. I can
> do it without using tools.
> But how will you close it again after soldering on the ICSP header?

You shouldn't actually need to solder it in. My understanding is that
you can just plug a header into the programming pickit2 and set it into
the target pickit 2. IF you use a straight connector, just the weight
of the pickit2 being programmed should hold it well enough to program.

Jerry

[Steven...@microchip.com]

Hi Guys,

Some comments on the firmware bootloader.

The philosophy was the bootloader should be self contained.  This means that the bootloader would include the USB HID drivers.  The application also contains its own USB HID drivers.  The idea was if the USB HID code for the bootloader had a problem, that it could be corrected in the application.  And, of course, that is the case with the USB configurations.  Even though it can be corrected in the application, it still causes problems for the bootloader and the various OS's.

We will fix this in future production units.  But the fix for current PICkit 2's is to open them up and reprogram from the ICSP header in the PCB.  Dan is beta testing PIC18 programming firmware as we speak and is getting good results.  If all goes well he should have the new firmware version out before Christmas.  Then you can program a PICkit 2 with another PICkit 2.  We hoped that the PICKit 2 was inexpensive enough that everyone would own two and even buy a third for a Christmas stocking stuffer :-).  You can also use a ICD-2 or Promate to program the PICkit 2.

On soldering a header to the ICSP pads on the PCB, you could do this if you wish.  I would recommend a low profile one so that you can close the case.  What I have done is use a plain ol' 0.025" square pin header that I plug into the pad holes.  If you hold it gently against the pads, you can program the PICkit 2.  Of course, if you are doing development, you would rather have the connection permanent.  

The bootloader code and the configuration bits are code protected.  This was done to prevent them from being corrupted.   I looked into reprogramming the configuration bits, but I was especially concerned with altering the configuration bits on the fly.  So I decided that they would be fixed and code protected.  I thought it was a small consequence as many of the configuration bits would not be changed anyway.

Finally, the philosophy on the 0x55 at location 0x7FFE was that if someone did not successfully program the application through a bootload process, this location would not be written and thus not run corrupted application code.  We needed a way to know if the application was programmed correctly.  The present PICkit 2 PC software will erase the application code area, then program the application, do a verification, and once the verification is successful, write 0x55 to location 0x7FFE, then perform a soft detact.

I hope this helps understand what we were thinking and give a reason why we did what we did.  

Steven Bible  [steven...@microchip.com]
Principle Applications Engineer
Microchip Technology Inc.