Lpc2000

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:

> I was hoping for something a little more substantive
> than the third party link to the site you already posted.

Google search on "Philips SP uC ProdOv" gives quite a few hits, and I
am quite sure they are from the same source in Philips.

> Philips, you need to clarify this.  Can these parts be
> parallel programmed or not?  Is the literature on your
> site wrong or is the letter that was sent to Jaya wrong.
> They cannot both be right.

I am as anxious as you are to clarification by Philips.

> >I am not sure about others, but from what I learnt in the
> >last couple of weeks in relation to: a) on-chip flash
> >programming algorithm; b) parallel programming info;
> >c) errata sheets for LPC2105; and d) source for the
> >supplied boot loader code, it is now pretty clear to
> >me why Philips has chosen to provide boot loader code
> >so that they do not *have* to release the kind of
> >information I discovered.
> 
> Well, don't just leave us hanging ;)

For example, from version 1.48 of boot loader for LPC2104/5/6, one
could derive code to erase entire on-chip flash as follows:

> // select all sectors
> FMDEV[7] = 0xff0000ff;
> FMDEV[6] = 4;
> fmDelay(90);
> FMDEV[6] = 0;

> // wipe marked sectors(s)
> FMDEV[10] = CCLK/200;
> FMDEV[11] = (400*CCLK)/2048 + 1;
> FM_DEV[6] = 2;
> fmDelay(CCLK/90 + (400*CCLK + 2048)/9);
> FM_DEV[6] = 0;

> // wait for completion ...
> while ((FMDEV[6] & 0x1f) != 0)
>     ;
> while ((FMDEV[36]) & 4) == 0)
>     ;

Accidentally trashing FM_DEV[6] can result in disaster!

FMDEV[10] and FMDEV[11] appear to hold on-chip charge pump parameters
for generating erase (and write) voltages.  It is possible trashing
these locations can fry the part for good.

Now do you see why Philips would withold release of such information? 

Jaya