Lpc2000

Hello,

We had a problem with refalshing the chip untill we upgraded the 
boot loader to 1.63 (LPC2114) no problems anymore!

MY question is that there is a step where you have to enter the 
oscillator frequency in the loader code. How do you do that when you 
order 1000 chips in the future? Will this be fixed somehow or we 
have to program every single chip with boot loader and our code!


We wre happy about the idea of new chips having boot loader from 
manufacture but now we realized that is a problem!


Thanks,

Gus Issa

Why is the oscillator frequency needed in the first place? Isn't the
interface baud rate detected by the bootloader?

--- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:

> 
> Hello,
> 
> We had a problem with refalshing the chip untill we upgraded the 
> boot loader to 1.63 (LPC2114) no problems anymore!
> 
> MY question is that there is a step where you have to enter the 
> oscillator frequency in the loader code. How do you do that when you 
> order 1000 chips in the future? Will this be fixed somehow or we 
> have to program every single chip with boot loader and our code!
> 
> 
> We wre happy about the idea of new chips having boot loader from 
> manufacture but now we realized that is a problem!
> 
> 
> Thanks,
> 
> Gus Issa

At 10:23 PM 11/17/04 +0000, you wrote:
>Why is the oscillator frequency needed in the first place? Isn't the
>interface baud rate detected by the bootloader?

Timing, They need to know the speed of the clock so they can determine the 
timing for programming the flash.  IE 6 counts at 20Mhz and 12 counts at 
10MHz in some internal timing loop.

The information has to come from somewhere.  The Analog Devices chips don't 
need it (in a similar case) since they only allow a single Xtal frequency.

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

For ISP the PLL is not active after a reset. The baudrate can be 
calculated for a given frequency range. But during runtime, 
reflashing uses IAP (In Application Programming) calls. The PLL could 
be on or off. The timing for Flash programming is critical and 
everybody wants to have a fast programming algorithm. So asking us 
users for the frequency seems quite resonable to do!?

Cheers, Bob

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 10:23 PM 11/17/04 +0000, you wrote:
> >Why is the oscillator frequency needed in the first place? Isn't 
the
> >interface baud rate detected by the bootloader?
> 
> Timing, They need to know the speed of the clock so they can 
determine the 
> timing for programming the flash.  IE 6 counts at 20Mhz and 12 
counts at 
> 10MHz in some internal timing loop.
> 
> The information has to come from somewhere.  The Analog Devices 
chips don't 
> need it (in a similar case) since they only allow a single Xtal 
frequency.
> 
> 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 11:28 PM 11/17/04 +0000, you wrote:
>For ISP the PLL is not active after a reset. The baudrate can be
>calculated for a given frequency range. But during runtime,
>reflashing uses IAP (In Application Programming) calls. The PLL could
>be on or off. The timing for Flash programming is critical and
>everybody wants to have a fast programming algorithm. So asking us
>users for the frequency seems quite resonable to do!?

Not only reasonable but necessary (even for ISP).  The micro has no way of 
knowing what the baud rate is (only that it matched it, was that 120bd, 
1200bd, 12000 or something else entirely).  There is no absolute timing 
reference it can use so it must be given one.  It could be given the baud 
rate in the case of ISP but given the inaccuracy of baud rates that's a 
poor second choice to the oscillator frequency.  In any case it must be 
given a number independent of it's auto baud match.

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

but you pass the clock freq. to the IAP at run time!!! why on earth 
philips wants you to program thier boot loader  then program your 
boot loader then program your firmware!!!!!!!!! Can you imagine the 
cost of doing this for 1000 chips?

My point is, this is done WRONG and Philips better fix it.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 10:23 PM 11/17/04 +0000, you wrote:
> >Why is the oscillator frequency needed in the first place? Isn't 
the
> >interface baud rate detected by the bootloader?
> 
> Timing, They need to know the speed of the clock so they can 
determine the 
> timing for programming the flash.  IE 6 counts at 20Mhz and 12 
counts at 
> 10MHz in some internal timing loop.
> 
> The information has to come from somewhere.  The Analog Devices 
chips don't 
> need it (in a similar case) since they only allow a single Xtal 
frequency.
> 
> 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 01:29 PM 11/18/04 +0000, you wrote:
>but you pass the clock freq. to the IAP at run time!!! why on earth
>philips wants you to program thier boot loader  then program your
>boot loader then program your firmware!!!!!!!!! Can you imagine the
>cost of doing this for 1000 chips?

Cost I would expect less than twice the cost of programming the application 
itself (which obviously must be done anyway).  There is a fixed overhead 
(time and fixtures), plus download time.  Download time will vary with 
program size and if you have a reasonably large application it's download 
time will easily exceed that for the boot loader by several times.

It seems to me you have one too many programming steps in there.  That is a 
separate issue from needing to know the clock frequency.

In any case how else would you suggest the timing information get passed to 
the flash programming routines?  You (or your program) are the only source 
that knows this information.

>My point is, this is done WRONG and Philips better fix it.

I expect the fix for the bootloader will be incorporated (if it hasn't been 
already on the production line) but the need for the clock frequency (or 
something similar) is likely to remain.

You could ask Philips how long it will take to see updated bootloaders in 
production.  It is possible they are just working their way through the 
supply chain.  As a note on how lengthy that chain can be I just bought 
some new SMT resistors from Digikey and noted as I was verifying the order 
that they had a 2000 date code.

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

passing the clock speed in my code should be enough. I don't want to 
re-do thier job! Or they program the chips for me before they ship.

By the way, does anyone know if someone out there is programming LPC 
ships for a fee? Someone ALREADY did it? I contacted ARROW and never 
heard back from them in regards of programing LPC chips!


Gus

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 01:29 PM 11/18/04 +0000, you wrote:
> >but you pass the clock freq. to the IAP at run time!!! why on 
earth
> >philips wants you to program thier boot loader  then program your
> >boot loader then program your firmware!!!!!!!!! Can you imagine 
the
> >cost of doing this for 1000 chips?
> 
> Cost I would expect less than twice the cost of programming the 
application 
> itself (which obviously must be done anyway).  There is a fixed 
overhead 
> (time and fixtures), plus download time.  Download time will vary 
with 
> program size and if you have a reasonably large application it's 
download 
> time will easily exceed that for the boot loader by several times.
> 
> It seems to me you have one too many programming steps in there.  
That is a 
> separate issue from needing to know the clock frequency.
> 
> In any case how else would you suggest the timing information get 
passed to 
> the flash programming routines?  You (or your program) are the 
only source 
> that knows this information.
> 
> >My point is, this is done WRONG and Philips better fix it.
> 
> I expect the fix for the bootloader will be incorporated (if it 
hasn't been 
> already on the production line) but the need for the clock 
frequency (or 
> something similar) is likely to remain.
> 
> You could ask Philips how long it will take to see updated 
bootloaders in 
> production.  It is possible they are just working their way 
through the 
> supply chain.  As a note on how lengthy that chain can be I just 
bought 
> some new SMT resistors from Digikey and noted as I was verifying 
the order 
> that they had a 2000 date code.
> 
> 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

Hi Gus,

I can't follow your problems

1. If the 1000 device are unmounted, return them to your disti and get
a replacement with the actual bootloader.  
Here in Germany I had the bootloader problem very early in june and
get help from Philips.
My disti Spoerle told me that they return all devices on stock back to
Philips for reprogramming.

2. If your devices are mounted on the PCB. Edit the bootloader hex
file and enter your clock freq. and you must not enter the value again
in the ISP tool for every single device.

3. Why you don't put your bootloader and your firmware in one hex file
for download and load both at the same time.

Why you don't write your own tool for your production line that do all
in one step?

Andreas


--- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:

> 
> but you pass the clock freq. to the IAP at run time!!! why on earth 
> philips wants you to program thier boot loader  then program your 
> boot loader then program your firmware!!!!!!!!! Can you imagine the 
> cost of doing this for 1000 chips?
> 
> My point is, this is done WRONG and Philips better fix it.
> 
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
> wrote:
> > At 10:23 PM 11/17/04 +0000, you wrote:
> > >Why is the oscillator frequency needed in the first place? Isn't 
> the
> > >interface baud rate detected by the bootloader?
> > 
> > Timing, They need to know the speed of the clock so they can 
> determine the 
> > timing for programming the flash.  IE 6 counts at 20Mhz and 12 
> counts at 
> > 10MHz in some internal timing loop.
> > 
> > The information has to come from somewhere.  The Analog Devices 
> chips don't 
> > need it (in a similar case) since they only allow a single Xtal 
> frequency.
> > 
> > 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

> 3. Why you don't put your bootloader and your firmware in one hex file
> for download and load both at the same time.

I thought the boot loader can not be overwritten by a regular flash
upload - or is it? So is it just a question putting the bootloader at
a specific address in the hex file? How about the step that runs the code?

> Why you don't write your own tool for your production line that do all
> in one step?

Do we have enough specs to do this?  Martin Maurer's utility could be
a good choice to extend - but it seems to be handling the update only.
We might need to upload to RAM, and run from a specific address. I
guess it's just the question of reverse engineering the Philips
protocol right?

--


- In lpc2000@yahoogroups.com, "ggindele" <ggindele@y...> wrote:
> 
> > 3. Why you don't put your bootloader and your firmware in one hex file
> > for download and load both at the same time.
> 
> I thought the boot loader can not be overwritten by a regular flash
> upload - or is it? So is it just a question putting the bootloader at
I mean not the Plilips bootlader if I understand gus right he has in
addition his own bootloader.

> a specific address in the hex file? How about the step that runs the
code?
> 
> > Why you don't write your own tool for your production line that do all
> > in one step?
> 
> Do we have enough specs to do this?  Martin Maurer's utility could be
> a good choice to extend - but it seems to be handling the update only.
> We might need to upload to RAM, and run from a specific address. I
> guess it's just the question of reverse engineering the Philips
> protocol right?
There is no reverse engineering necessary, take a look at the UM and
the Philips bootloader update description.

Andreas

At 02:38 PM 11/18/04 +0000, you wrote:
>passing the clock speed in my code should be enough. I don't want to
>re-do thier job! Or they program the chips for me before they ship.

I'm confused.  Are you complaining about loading an updated boot program or 
about telling the micro what the clock speed is when it has to program flash?

If it's updating the boot program, check with Philips (and the errata?) and 
find out what date codes you have to avoid and make it part of your 
purchase spec.

The clock speed you are going to need no matter what part of the flash you 
are updating (it's not getting burned into the flash after all).

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

I guess so far no one understood my point! When you use the philips 
bootloader from your code, you pass (address, data, clock) so far 
everything seems fine. Now, in the philips update bootloader 
document, there is a step telling us to enter the clock in the RAM 
buffer before running the code.

My concern is that, if I get a new chip with boot loader version 
1.63 (newest) and I use philips boot loader (address, data, clock) 
do I have to update the philips boot loader with the clock?


In other words, why the clock variable is needed twice? One, inside 
the boot loader and second passing it through code?


Gus

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 02:38 PM 11/18/04 +0000, you wrote:
> >passing the clock speed in my code should be enough. I don't want 
to
> >re-do thier job! Or they program the chips for me before they 
ship.
> 
> I'm confused.  Are you complaining about loading an updated boot 
program or 
> about telling the micro what the clock speed is when it has to 
program flash?
> 
> If it's updating the boot program, check with Philips (and the 
errata?) and 
> find out what date codes you have to avoid and make it part of 
your 
> purchase spec.
> 
> The clock speed you are going to need no matter what part of the 
flash you 
> are updating (it's not getting burned into the flash after all).
> 
> 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

--- In lpc2000@yahoogroups.com, "haack0815" <lpc_arm@s...> wrote:
> 
> Hi Gus,
> 
> I can't follow your problems
> 
> 1. If the 1000 device are unmounted, return them to your disti and 
get
> a replacement with the actual bootloader.  
> Here in Germany I had the bootloader problem very early in june and
> get help from Philips.
> My disti Spoerle told me that they return all devices on stock 
back to
> Philips for reprogramming.
My concern is that "my clock" must be preprogramed in philips 
bootloader!!! That is one of the step in updating philips bootloader 
document. How would philips program indivisual chip according to 
your system? Unless I missid out on something!

> 2. If your devices are mounted on the PCB. Edit the bootloader hex
> file and enter your clock freq. and you must not enter the value 
again
> in the ISP tool for every single device.
I missing on something here, what value over write the other? WE 
have "clock freq" inside hex file and there is "clock freq" in our 
code!!

> 3. Why you don't put your bootloader and your firmware in one hex 
file
> for download and load both at the same time.
We did that already. 
> Why you don't write your own tool for your production line that do 
all
> in one step?
Working on it.......to me, it seems to be an extra work for other 
people's (philips) mistakes.

> Andreas
> 
> 
> --- In lpc2000@yahoogroups.com, "Gus" <gus_is_working@y...> wrote:
> > 
> > but you pass the clock freq. to the IAP at run time!!! why on 
earth 
> > philips wants you to program thier boot loader  then program 
your 
> > boot loader then program your firmware!!!!!!!!! Can you imagine 
the 
> > cost of doing this for 1000 chips?
> > 
> > My point is, this is done WRONG and Philips better fix it.
> > 
> > --- In lpc2000@yahoogroups.com, Robert Adsett 
<subscriptions@a...> 
> > wrote:
> > > At 10:23 PM 11/17/04 +0000, you wrote:
> > > >Why is the oscillator frequency needed in the first place? 
Isn't 
> > the
> > > >interface baud rate detected by the bootloader?
> > > 
> > > Timing, They need to know the speed of the clock so they can 
> > determine the 
> > > timing for programming the flash.  IE 6 counts at 20Mhz and 12 
> > counts at 
> > > 10MHz in some internal timing loop.
> > > 
> > > The information has to come from somewhere.  The Analog 
Devices 
> > chips don't 
> > > need it (in a similar case) since they only allow a single 
Xtal 
> > frequency.
> > > 
> > > 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

Gus wrote:
> I guess so far no one understood my point! When you use the philips 
> bootloader from your code, you pass (address, data, clock) so far 
> everything seems fine. Now, in the philips update bootloader 
> document, there is a step telling us to enter the clock in the RAM 
> buffer before running the code.

I and I suspect everyone else here had trouble understanding what your 
actual question was amidst all the shouting about Philips making 
mistakes and the cost of reprogramming 1000 chips.

What I _think_ you are asking is "do I need to update the on-chip 
bootloader a second time if my system's clock frequency will be 
different to the one I was using when I first updated the bootloader?"

I believe the answer is no. The reason you need to set the clock 
frequency variable in the RAM buffer before executing the 
bootloader-update program from RAM is because the bootloader-update code 
needs to know what the _current_ frequency (while the bootloader update 
is taking place) is for flash timing purposes.

Note that you could speed up the process if you have to run the 
bootloader update on 1000 chips by modifying the frequency variable in 
the hex file and using a hacked version of l21isp to upload the 
bootloader-updater to ram and execute it in a single step.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

At 02:01 PM 11/19/04 +0000, you wrote:


>--- In lpc2000@yahoogroups.com, "haack0815" <lpc_arm@s...> wrote:
> >
> > Hi Gus,
> >
> > I can't follow your problems
> >
> > 1. If the 1000 device are unmounted, return them to your disti and
>get
> > a replacement with the actual bootloader.
> > Here in Germany I had the bootloader problem very early in june and
> > get help from Philips.
> > My disti Spoerle told me that they return all devices on stock
>back to
> > Philips for reprogramming.
>My concern is that "my clock" must be preprogramed in philips
>bootloader!!! That is one of the step in updating philips bootloader
>document. How would philips program indivisual chip according to
>your system? Unless I missid out on something!

I believe you did.  Philips is bootstrapping the boot update.  The normal 
ISP process does not allow you to program the boot sector so they are 
downloading a program into RAM to update the boot sector.  That program 
needs to know the timing information and that is what you are giving 
it.  The timing information passed by the ISP utility is not available to 
it and it is not being placed into the boot sector.

You could just patch the hex permanently and save yourself the step.


> > 3. Why you don't put your bootloader and your firmware in one hex
>file
> > for download and load both at the same time.
>We did that already.
> > Why you don't write your own tool for your production line that do
>all
> > in one step?
>Working on it.......to me, it seems to be an extra work for other
>people's (philips) mistakes.

In their defence on this issue, they have made it possible for you to 
change it.  In some cases it would have just been noted as an errata and 
even if it had been fixed in production no patch would have been issued 
(even if technically possible).  How annoyed would you have been if there 
was no patch?

Bugs exist in most chips of reasonable complexity.  The variables are 
quantity, severity and openness.  I will give considerable credit to a 
company that's open about their errata since I can deal with problems I 
know about.  It's the ones they hide that give major grief.  This one is 
particularly minor since it is in fact completely correctable.  Race 
conditions on the other hand are potentially far more severe (mostly since 
some kinds cannot be worked around).

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 02:22 PM 11/19/04 +0000, you wrote:
>Note that you could speed up the process if you have to run the
>bootloader update on 1000 chips by modifying the frequency variable in
>the hex file and using a hacked version of l21isp to upload the
>bootloader-updater to ram and execute it in a single step.

Good idea, I expect that would work quite well.  I don't think it would be 
difficult to do either.  And if you are using the standard ISP header or 
another auto reset setup it becomes an almost mechanical process.

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