Lpc2000

Hi all (and maybe Phillips)

After having flashed my target and even closed the Flash Utility
it seemingly leaves something behind that prevents me from recieving
the ascii NUL (0x00) character. Transmitting is OK. I have checked
with a serial port monitor. Everything else is there, except NUL.
Has anyboby experienced that or have a solution for it ?
The only solution I have for the moment (besides a reboot Urk!) is
to start Hyperterminal and close it again. Now, Hyperterminal may not
be everybodys favorite, but it seems to be a good "Philips Cleaning Tool"

/Kell

----- Original Message ----- 

From: "Kell J\ufffdrgensen" <kell@...>
To: <lpc2000@yahoogroups.com>
Sent: Friday, April 14, 2006 3:38 PM
Subject: [lpc2000] Strange problem with the Philips Flash Utility


> Hi all (and maybe Phillips)
>
> After having flashed my target and even closed the Flash Utility
> it seemingly leaves something behind that prevents me from recieving
> the ascii NUL (0x00) character. Transmitting is OK. I have checked
> with a serial port monitor. Everything else is there, except NUL.
> Has anyboby experienced that or have a solution for it ?
> The only solution I have for the moment (besides a reboot Urk!) is
> to start Hyperterminal and close it again. Now, Hyperterminal may not
> be everybodys favorite, but it seems to be a good "Philips Cleaning Tool"

I had a similar problem some time ago, but can't remember the details. I was 
able to get round it, somehow.

Leon 

---
[This E-mail has been scanned for viruses but it is your responsibility 
to maintain up to date anti virus software on the device that you are
currently using to read this email. ]

--- In lpc2000@yahoogroups.com, Kell Jørgensen <kell@...> wrote:
>
> Hi all (and maybe Phillips)
> 
> After having flashed my target and even closed the Flash Utility
> it seemingly leaves something behind that prevents me from recieving
> the ascii NUL (0x00) character. Transmitting is OK. I have checked
> with a serial port monitor. Everything else is there, except NUL.
> Has anyboby experienced that or have a solution for it ?
> The only solution I have for the moment (besides a reboot Urk!) is
> to start Hyperterminal and close it again. Now, Hyperterminal may not
> be everybodys favorite, but it seems to be a good "Philips Cleaning
Tool"
> 
> /Kell
>
Hi Kell,

if you use your own program, then take a closer look at the parameter
fNull of the Device-Control Block of your comport settings.
Unfortunately the Philips tool leave the parameter fNull set as true
(null bytes are discarded when received). 

I hope that will help you.

Andreas

> > Hi all (and maybe Phillips)
> > 
> > After having flashed my target and even closed the Flash Utility
> > it seemingly leaves something behind that prevents me from recieving
> > the ascii NUL (0x00) character. Transmitting is OK. I have checked
> > with a serial port monitor. Everything else is there, except NUL.
> > Has anyboby experienced that or have a solution for it ?
> > The only solution I have for the moment (besides a reboot Urk!) is
> > to start Hyperterminal and close it again. Now, Hyperterminal may not
> > be everybodys favorite, but it seems to be a good "Philips Cleaning
> Tool"
> > 
> > /Kell
> >
> Hi Kell,
> 
> if you use your own program, then take a closer look at the parameter
> fNull of the Device-Control Block of your comport settings.
> Unfortunately the Philips tool leave the parameter fNull set as true
> (null bytes are discarded when received). 
> 
> I hope that will help you.
> 
> Andreas

Thanks Andreas,

You are absolutely right. Unfortunately doesn't my Delphi3/AsyncPro
enviroment give direct access to this bit field, so I will have to
handle it at a lower level.
Philips, pleace clean up when you leave.

Kell

--- In lpc2000@yahoogroups.com, Kell Jørgensen <kell@...> wrote:

> > Hi Kell,
> > 
> > if you use your own program, then take a closer look at the parameter
> > fNull of the Device-Control Block of your comport settings.
> > Unfortunately the Philips tool leave the parameter fNull set as true
> > (null bytes are discarded when received). 
> > 
> > I hope that will help you.
> > 
> > Andreas
> 
> Thanks Andreas,
> 
> You are absolutely right. Unfortunately doesn't my Delphi3/AsyncPro
> enviroment give direct access to this bit field, so I will have to
> handle it at a lower level.
> Philips, pleace clean up when you leave.
> 
> Kell

I have a tool that will allow you to download hex files directly to
any target that is available as

  http://www.cse.unsw.edu.au/~jayas/esdk/files/lpc/sill.exe

Although it was to server a different purpose, you can use it to load
any Intel-Hex formatted file into on-chip FLASH or RAM. To program the
contents of file.hex to target on com8 at 9600 baud, and with crystal
frequency of 12MHz, the command line is:

  sill -l com8:9600 -x 12000 file.hex

It understands LPC's vector checksum requirement and does this when
you are loading into flash sector zero.

I would be intrested to know you encounter similar problems with this
tool.

Jaya

At 11:58 AM 4/15/06 +0200, Kell Jørgensen wrote:
> > if you use your own program, then take a closer look at the parameter
> > fNull of the Device-Control Block of your comport settings.
> > Unfortunately the Philips tool leave the parameter fNull set as true
> > (null bytes are discarded when received).
> >
> > I hope that will help you.
> >
> > Andreas
>
>Thanks Andreas,
>
>You are absolutely right. Unfortunately doesn't my Delphi3/AsyncPro
>enviroment give direct access to this bit field, so I will have to
>handle it at a lower level.
>Philips, pleace clean up when you leave.

I don't think this is a Philips problem really.  Any program that sets up 
the serial port has to assume responsibility for doing the whole setup.  It 
cannot assume that it has been left in a providential state.  If 
Delphi3/AsyncPro don't let you at it that's their issue not Philips.

If you are willing to stoop to using a command line utility LPC21ISP may be 
worth a try.

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
http://www.aeolusdevelopment.com/

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

> I have a tool that will allow you to download hex files directly to
> any target that is available as
> 
>   http://www.cse.unsw.edu.au/~jayas/esdk/files/lpc/sill.exe

Jaya,

I looked around your site and I really like your tutorials and
step-by-step walkthoughs related to your analysis of bootloaders! It's
hard to find this kind of detailed information.

Is there any change sill will become open source?

Eric

--- In lpc2000@yahoogroups.com, "Eric Engler" <englere.geo@...> wrote:
> Jaya,
> 
> I looked around your site and I really like your tutorials and
> step-by-step walkthoughs related to your analysis of bootloaders! It's
> hard to find this kind of detailed information.
> 
> Is there any change sill will become open source?
> 
> Eric

I am pleased you liked it.

Open source for the boot loader is still an option when I work out how
not to engage in "disclosure of proprietary information".  Its use is
very much crippled (in terms of the features it can support) because
it is cannot sit in the boot sector.

Open source for the utility does not make much sense because it relies
heavily on custom libraries which support many projects and I do not
control their documentation.

One day I might extract the relevant calls and write a header so that
I could provide the library in binary form ... but no plans at the moment.

Jaya

Hello!!..  Bootloader...
Why not you do something more fantastic for group members here:

=>Something that able is to copy the bootloader from one chip 
to another.

ARM7 firmware #1
- Name "SOURCE.HEX"
- Burn onto chip #1 with newer bootloader

ARM7 firmware #2
- Name "DESTINATION.HEX"
- Burn onto chip #2 with older bootloader

Then
- Connect the 2 chips through UART0.
- Power up the 2 chips together
- Bootloader automatically get copied from Chip #1 to Chip #2
- Chips toggle Txd line at 1Hz once completed copying.

I guess quite some people here will use it.   And no longer need
to wait for Philips releasing of BootLoader Upgrade.

Better if you can make it more plug and play.  You can keep
your source code.   Only need to promise you do not plant a 
Trojan-horse onto the chips.  :)

What can philips complain??  as long as you do not modify
some flash memory area you called "bootsector" (or bootblock??)
May be philips will thank you, Umm...I mean unofficially   :)
Regards 

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
>
> --- In lpc2000@yahoogroups.com, "Eric Engler" <englere.geo@> wrote:
> > Jaya,
> > 
> > I looked around your site and I really like your tutorials and
> > step-by-step walkthoughs related to your analysis of 
bootloaders! It's
> > hard to find this kind of detailed information.
> > 
> > Is there any change sill will become open source?
> > 
> > Eric
> 
> I am pleased you liked it.
> 
> Open source for the boot loader is still an option when I work out 
how
> not to engage in "disclosure of proprietary information".  Its use 
is
> very much crippled (in terms of the features it can support) 
because
> it is cannot sit in the boot sector.
> 
> Open source for the utility does not make much sense because it 
relies
> heavily on custom libraries which support many projects and I do 
not
> control their documentation.
> 
> One day I might extract the relevant calls and write a header so 
that
> I could provide the library in binary form ... but no plans at the 
moment.

> 
> Jaya
>

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@...> wrote:
>
> Hello!!..  Bootloader...
> Why not you do something more fantastic for group members here:
> 
> =>Something that able is to copy the bootloader from one chip 
> to another.

You could (possibly) use it to upgrade LPC2104 to LPC2106 by simply
copying the boot loader across.  Philips will not like this.

[Newer variants of LPC2104/5/6 are rom'ed, but the same applies to any
other compatible variant that is not rom'ed.]

> ARM7 firmware #1
> - Name "SOURCE.HEX"
> - Burn onto chip #1 with newer bootloader
> 
> ARM7 firmware #2
> - Name "DESTINATION.HEX"
> - Burn onto chip #2 with older bootloader
> 
> Then
> - Connect the 2 chips through UART0.
> - Power up the 2 chips together
> - Bootloader automatically get copied from Chip #1 to Chip #2
> - Chips toggle Txd line at 1Hz once completed copying.

Been there, done that.  Not exactly the way you have described though
but by making the two phases independent of each other.

It would be interesting to know what happened to the case were a
poster here claimed got a bunch of chips labelled as one part, but
whose boot loader reported as a different part.

There may be some clues here if we knew how it was resolved.

> I guess quite some people here will use it.   And no longer need
> to wait for Philips releasing of BootLoader Upgrade.

I did not realise people were waiting on boot loader upgrades.  Why?

> Better if you can make it more plug and play.  You can keep
> your source code.   Only need to promise you do not plant a 
> Trojan-horse onto the chips.  :)

Actually I prefer to open the source code (at least the core
components) so that the user assumes some responsibility.

I say "core" because I like the user to tie the final knot.

> What can philips complain??  as long as you do not modify
> some flash memory area you called "bootsector" (or bootblock??)
> May be philips will thank you, Umm...I mean unofficially   :)

I made the offer to Philips through this forum.  Philips declined to
take up the offer.  I refuse to put myself in a position that may
result in my being rendered the next time step into some foreign soil.

Jaya

Hi Jaya,
I suspect that (for example) LPC2104/5/6 do use identical
dies. Devices would be sold as LPC2104 primarily because of
defects in the FLASH memory. Philips could see which / how
many banks of FLASH are usable, and (by way of undocumented
FLASH locations) tell the ARM how to configure the good
memory to appear as a particular chip. It would not surprise
me if Philips built in 10% - 20% more memory than is needed
even for an LPC2106 to allow them to swap out any blocks
which do not pass production testing.

If demand for the smaller devices picks up, first Philips
would start configuring / marking more parts as an LPC2104.
But if demand really takes off, they might spend $100000
(that sort of money) on a new mask set that only has enough
memory for the LPC2104 to get more chips per wafer.

It is possible that you could get an LPC2104 where the other
memory is merely turned off. But it might be turned off
because it doesn't work. And as soon as you start re-mapping
the memory away from what Philips' tests showed to be good,
all bets are off.

Going from Flash to ROM for the bootloader (without any
change in chip area) is probably only one mask change,
say $15000. The saving is that the bootloader does not have
to be programmed. But you still have to test the entire
memory.

My suspicion is based only on previous knowlege of the
semiconductor industry - I have no evidence for this
particular case. And the fact that Philips FLASH includes
error-correction cells does not make me think my suspicion
any less likely.

An interesting article on yeild and quality for
semiconductors was written by Bob Pease of National
Semiconductor and published in EDN in
http://www.elecdesign.com/Articles/ArticleID/6135/6135.html

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

>
> --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@> wrote:
> >
> > Hello!!..  Bootloader...
> > Why not you do something more fantastic for group members here:
> > 
> > =>Something that able is to copy the bootloader from one chip 
> > to another.
> 
> You could (possibly) use it to upgrade LPC2104 to LPC2106 by simply
> copying the boot loader across.  Philips will not like this.
> 
> [Newer variants of LPC2104/5/6 are rom'ed, but the same applies to any
> other compatible variant that is not rom'ed.]

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

> You could (possibly) use it to upgrade LPC2104 to LPC2106 by simply
> copying the boot loader across.  Philips will not like this.

I have updated the section on "LPC Limit Select" register in my Boot
loader Internals page with more specific information that I posted on
this forum a while ago.  Have a look at:

  http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html

Hopefully this will serve to reduce the amount of noise generated by
way of speculation as to what is really going on inside the boot
loader, and to explain why I said "Philips will not like this".

This page also has information (and hex image files) that enables you
to dump the boot sector on your chip in Intel-Hex format.  Select the
file e000.hex or d000.hex depending on the start address of the boot
sector on your part.

You can then compare the boot loader images between differnt parts to
discover what differences.

Jaya