Lpc2000

Hello,

In response to requests for documentation I have put up a brief page
on my boot sector diagnostics tool that I made public recently.

  http://www.cse.unsw.edu.au/~jayas/esdk/bsdc.html

If you are looking at batch programming of LPC devices in bulk the
approach I have used in BSDC is one way of doing this.

BSDC downloads a small (50-byte) agent to on-chip RAM and gets this
agent to do whatever it needs.

This agent could program on-chip flash using IAP (or other methods) in
a production line environment where devices are initialised using ISP.

Regards,

Jaya

Interesting. Can you say what advantage your method would have over 
using the built-in loader for production programming?

Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
>
> Hello,
> 
> In response to requests for documentation I have put up a brief 
page
> on my boot sector diagnostics tool that I made public recently.
> 
>   http://www.cse.unsw.edu.au/~jayas/esdk/bsdc.html
> 
> If you are looking at batch programming of LPC devices in bulk the
> approach I have used in BSDC is one way of doing this.
> 
> BSDC downloads a small (50-byte) agent to on-chip RAM and gets this
> agent to do whatever it needs.
> 
> This agent could program on-chip flash using IAP (or other 
methods) in
> a production line environment where devices are initialised using 
ISP.

> 
> Regards,
> 
> Jaya
>

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

> Interesting. Can you say what advantage your method would have over 
> using the built-in loader for production programming?

Batch programming as stated in my post you refer to:

> > If you are looking at batch programming of LPC devices in bulk the
> > approach I have used in BSDC is one way of doing this.

I misunderstood: I thought you were saying there was some advantage to 
loading an on-target application to do the programming, rathar than 
just using the built-in loader.

Batch programing can be done using the part's built-in loader easily 
enough. There's a few open source host programs in the "files" section 
of this group that can be used in a batch environment (command-line is 
easier to handle for this than the Philips Windows tool).

Since you need to talk to the existing boot-loader in any case to load 
a program into RAM, why not just get it to program the flash? Or am I 
missing something?

Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:

>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> <brendanmurphy37@> wrote:
> 
> > Interesting. Can you say what advantage your method would have over 
> > using the built-in loader for production programming?
> 
> Batch programming as stated in my post you refer to:
> 
> > > If you are looking at batch programming of LPC devices in bulk the
> > > approach I have used in BSDC is one way of doing this.
>

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

> I misunderstood: I thought you were saying ...

Have a play with BSDC and you may understand it better.

When I find time I will explin more in my page on how it does what it
does, and how the full version of is used on a production environment
and handles target boards with mixed CPU variants and crystal speeds.

Jaya

I await further information with interest, though it would be unlikely 
we'd be interested in using it unless it was open source. Our 
production programming is integrated into an automated test system. 
After programming, the device is reset (into normal mode), the POST 
information retrieved and further self-tests run under the command of 
the production test software. The result is then displayed (a simple 
good/bad status for the operator) and details recorded with the unit 
serial number to a back-end database. It's all fully automated and 
integrated. A fairly standard approach too, I would imagine (I'm no 
production expert). 

By the way, the interface to the Philips built-in boot loader is the 
same regardless of CPU variant (unless you're talking about non-LPC2xxx 
CPUs?), or the crystal speed. 

As I say, I await further information with interest: it's always good 
to see alternative approaches and ideas.

Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:

>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> <brendanmurphy37@> wrote:
> 
> > I misunderstood: I thought you were saying ...
> 
> Have a play with BSDC and you may understand it better.
> 
> When I find time I will explin more in my page on how it does what it
> does, and how the full version of is used on a production environment
> and handles target boards with mixed CPU variants and crystal speeds.
> 
> Jaya
>

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:

> I await further information with interest, though it would
> be unlikely we'd be interested in using it unless it was
> open source.

Source code is available but is not free.  The binary as-is was
developed using EnkOS library and this component is commercial
binary-only product.

May be one day when I find enough money to buy out the licences, I
will make EnkOS library open source but I am not holding my breadth.

There is a way out I suggested in my boot loader proposal.  I can
release the source relating what it really does such that someone with
a good knowledge of multi-threaded applications can fill in the host
interface using open/free library calls.

This can then be a separate open source initiative and is less likely
to offend clients who have paid good money for it.

> Our 
> production programming is integrated into an automated test system. 
> After programming, the device is reset (into normal mode), the POST 
> information retrieved and further selftests run under the command of 
> the production test software. The result is then displayed (a simple 
> good/bad status for the operator) and details recorded with the unit 
> serial number to a back-end database. It's all fully automated and 
> integrated. A fairly standard approach too, I would imagine (I'm no 
> production expert).

The full version of this utility (in a different platform) generates
crypto (SHA1) serial numbers like the xxxx-xxxx-xxxx-xxxx that you see
in all my utilities.  Clients find this useful as a firmware serial
number and one client has used it to discover unauthorised clones.

> By the way, the interface to the Philips built-in boot loader
> is the same regardless of CPU variant (unless you're talking
> about non-LPC2xxx CPUs?), or the crystal speed.

BSDC uses ISP to download the agent component.  The rest is done
through the agent to provide functinoaly not available through ISP.

Before it can do this, it needs to know where the boot sector is.  For
current parts this is either 0x7fffe000 or 0x7fffc000.  The agent does
auto-sizing (using documented features) for LPC2000 family to find the
start of boot sector.

It also auto-sizes on-chip RAM so that it can locate its data and
stack segments at the top of memory.  This avoids problems of the type
in Philips boot loader where you cannot load a program and run it from
start of ram.  You like to be able to do this during development if
you are mapping vectors to on-chip ram.

> As I say, I await further information with interest: it's always
> good to see alternative approaches and ideas.

The further information I plan to put on the page (as and when I get
the time) is for teaching and training purposes.  I think it is not
going to be of much help for making a commercial decision on whether
or not you want to use this tool in the production line.

Jaya