Lpc2000

I was just trying to help track down some odd compare behaviour someone had 
seen using my serial ISP adaptor and I believe we've run into a bug in the 
latest version of the Philips ISP utility.

It fails if a compare is asked for.  The version that fails is the latest 
2.2.0.  Version 2.0.3 works fine (the same micro with the same hex compares 
fine using 2.0.3 and not with 2.2.0).  Oh and the program does work.

I've tried this with both the automatic control of reset and mode pins and 
using manual control with no difference.

Has anyone else run into this?

I've also posted to Philips forum to see if they have any thoughts.


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Robert,

we will look into this problem of the ISP program. Expect a feedback
by next week, the ISP Guru is on vacation.

Robert

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> I was just trying to help track down some odd compare behaviour
someone had 
> seen using my serial ISP adaptor and I believe we've run into a bug
in the 
> latest version of the Philips ISP utility.
> 
> It fails if a compare is asked for.  The version that fails is the
latest 
> 2.2.0.  Version 2.0.3 works fine (the same micro with the same hex
compares 
> fine using 2.0.3 and not with 2.2.0).  Oh and the program does work.
> 
> I've tried this with both the automatic control of reset and mode
pins and 

> using manual control with no difference.
> 
> Has anyone else run into this?
> 
> I've also posted to Philips forum to see if they have any thoughts.
> 
> 
> " 'Freedom' has no meaning of itself.  There are always restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try to
> chew a radio signal. "
> 
>                          Kelvin Throop, III

At 11:28 AM 7/27/04 -0400, you wrote:
>I was just trying to help track down some odd compare behaviour someone had
>seen using my serial ISP adaptor and I believe we've run into a bug in the
>latest version of the Philips ISP utility.
>
>It fails if a compare is asked for.  The version that fails is the latest
>2.2.0.  Version 2.0.3 works fine (the same micro with the same hex compares
>fine using 2.0.3 and not with 2.2.0).  Oh and the program does work.
>
>I've tried this with both the automatic control of reset and mode pins and
>using manual control with no difference.
>
>Has anyone else run into this?
Perhaps as much to the point, has anyone used 2.2.0 to successfully compare 
a file with the micro's contents?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

At 04:42 PM 7/27/04 +0000, you wrote:
>we will look into this problem of the ISP program. Expect a feedback
>by next week, the ISP Guru is on vacation.


Thanks, I appreciate that.

Robert



" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Hello Robert,

I believe what you are seeing was actually meant as an improvement in 
the latest version of the ISP tool. Previous versions could not 
compare (or read out) the first 64 bytes of flash (vector table) due 
to mapping issues (usually you would only get the first 64 bytes of 
the boot loader but not of the flash). So the first 64 bytes were 
always disregarded for a comparison in previous versions. 

Now with the ISP tool being able to read these first 64 bytes 
correctly you can run into new trouble when comparing: The vector 
check sum (used to verify that a valid user code exists in the 
flash)! The ISP tool calcualtes it automatically when you upload a 
program from the main screen of the ISP tool. If you do the compare 
then the flash contents is actually compared against the original hex 
file which does not match with respect to the vector check sum.

You can work aroun this by opening the hex file in the flash buffer 
screen, press the button to calculate the check sum and then save the 
flash buffer again as a hex file that can be used as reference for 
the comparison.

Hopefully that will solve the problem that you are seeing.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> I was just trying to help track down some odd compare behaviour 
someone had 
> seen using my serial ISP adaptor and I believe we've run into a bug 
in the 
> latest version of the Philips ISP utility.
> 
> It fails if a compare is asked for.  The version that fails is the 
latest 
> 2.2.0.  Version 2.0.3 works fine (the same micro with the same hex 
compares 
> fine using 2.0.3 and not with 2.2.0).  Oh and the program does work.
> 
> I've tried this with both the automatic control of reset and mode 
pins and 
> using manual control with no difference.
> 
> Has anyone else run into this?
> 
> I've also posted to Philips forum to see if they have any thoughts.
> 
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

Hello Robert,

I believe what you are seeing was actually meant as an improvement in 
the latest version of the ISP tool. Previous versions could not 
compare (or read out) the first 64 bytes of flash (vector table) due 
to mapping issues (usually you would only get the first 64 bytes of 
the boot loader but not of the flash). So the first 64 bytes were 
always disregarded for a comparison in previous versions. 

Now with the ISP tool being able to read these first 64 bytes 
correctly you can run into new trouble when comparing: The vector 
check sum (used to verify that a valid user code exists in the 
flash)! The ISP tool calcualtes it automatically when you upload a 
program from the main screen of the ISP tool. If you do the compare 
then the flash contents is actually compared against the original hex 
file which does not match with respect to the vector check sum.

You can work aroun this by opening the hex file in the flash buffer 
screen, press the button to calculate the check sum and then save the 
flash buffer again as a hex file that can be used as reference for 
the comparison.

Hopefully that will solve the problem that you are seeing.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> I was just trying to help track down some odd compare behaviour 
someone had 
> seen using my serial ISP adaptor and I believe we've run into a bug 
in the 
> latest version of the Philips ISP utility.
> 
> It fails if a compare is asked for.  The version that fails is the 
latest 
> 2.2.0.  Version 2.0.3 works fine (the same micro with the same hex 
compares 
> fine using 2.0.3 and not with 2.2.0).  Oh and the program does work.
> 
> I've tried this with both the automatic control of reset and mode 
pins and 
> using manual control with no difference.
> 
> Has anyone else run into this?
> 
> I've also posted to Philips forum to see if they have any thoughts.
> 
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

At 07:03 PM 8/3/04 +0000, you wrote:
>I believe what you are seeing was actually meant as an improvement in
>the latest version of the ISP tool. Previous versions could not
>compare (or read out) the first 64 bytes of flash (vector table) due
>to mapping issues (usually you would only get the first 64 bytes of
>the boot loader but not of the flash). So the first 64 bytes were
>always disregarded for a comparison in previous versions.
>
>Now with the ISP tool being able to read these first 64 bytes
>correctly you can run into new trouble when comparing: The vector
>check sum (used to verify that a valid user code exists in the
>flash)! The ISP tool calcualtes it automatically when you upload a
>program from the main screen of the ISP tool. If you do the compare
>then the flash contents is actually compared against the original hex
>file which does not match with respect to the vector check sum.

Given a choice between a program that on rare occasions misses an error and 
one that almost always claims a non-existent error (and doesn't finish the 
test) I'd have preferred the first approach had been chosen.

I take it most of the in-house testing was done using files that already 
had a correct vector checksum ;( ?


>You can work aroun this by opening the hex file in the flash buffer
>screen, press the button to calculate the check sum and then save the
>flash buffer again as a hex file that can be used as reference for
>the comparison.

That seems to work.

That is a work around but this does need fixing.  I'd like to suggest that 
either the program revert to earlier behaviour and ignore the first 64 
bytes, or that (like the download) it calculate the check before 
comparing.  The later would be nicer but even the former would be better 
behaviour than a 100% failure rate.

It seems to I'll pass the information along.

Thanks for the quick response.


Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III