Hi All-

I'm currently experiencing a very frustrating issue with the LPC2138 
bootloader. I can successfully and reliably use the Philips flash 
utility to download an image to a blank LPC2138 once and only once. 
After that, the flash utility is never able to communicate with the 
LPC2138.

I have been monitoring the recent bootloader thread that was 
resolved by manipulating the watchdog overflow flag which, if set, 
will cause the bootloader reques to be ignored. Unfortunately, this 
is not the same problem I am having because I'm never enabling the 
watchdog.

I've been working with an evaluation board for 6 months now so I 
felt confident I understood the processor because I never had this 
issue. Now that I am bringing up custom hardware, I removed 
everything from the board except the processor, JTAG, and power 
supplies. I thought perhaps my code was inadvertently configuring an 
I/O pin in conflict, so I modified the application code to simply 
sit in a loop after disabling interrupts and other basic init steps.

The signals to the processor are exactly what I would expect:
1.) The reset line and P0.14 are pulled low by the Philips Flash 
application at t=0.
2.) The P0.14 line is held low for about 470mS before being 
released, and the reset is held low for about 820mS before being 
released.
3.) After these transitions, the processor sees the 0x3F being 
transmitted by the flash utility.

So, as far as I can tell, everything is ocuring correctly, but I am 
unable to access the bootloader after the first initial image 
download. I was initially swapping processors, but each one behaves 
the same way.

Thanks-
Tim
	

tah2k wrote:
> Hi All-
> 
> I'm currently experiencing a very frustrating issue with the LPC2138 
> bootloader. I can successfully and reliably use the Philips flash 
> utility to download an image to a blank LPC2138 once and only once. 
> After that, the flash utility is never able to communicate with the 
> LPC2138.
> 
> I have been monitoring the recent bootloader thread that was 
> resolved by manipulating the watchdog overflow flag which, if set, 
> will cause the bootloader reques to be ignored. Unfortunately, this 
> is not the same problem I am having because I'm never enabling the 
> watchdog.
> 
> I've been working with an evaluation board for 6 months now so I 
> felt confident I understood the processor because I never had this 
> issue. Now that I am bringing up custom hardware, I removed 
> everything from the board except the processor, JTAG, and power 
> supplies. I thought perhaps my code was inadvertently configuring an 
> I/O pin in conflict, so I modified the application code to simply 
> sit in a loop after disabling interrupts and other basic init steps.
> 
> The signals to the processor are exactly what I would expect:
> 1.) The reset line and P0.14 are pulled low by the Philips Flash 
> application at t=0.
> 2.) The P0.14 line is held low for about 470mS before being 
> released, and the reset is held low for about 820mS before being 
> released.
> 3.) After these transitions, the processor sees the 0x3F being 
> transmitted by the flash utility.
> 
> So, as far as I can tell, everything is ocuring correctly, but I am 
> unable to access the bootloader after the first initial image 
> download. I was initially swapping processors, but each one behaves 
> the same way.
> 
> Thanks-
> Tim
> 

Hello Tim,

I think I know your problem. You are writing that (from t0 on) P0.14 is released
after 470ms and
/Reset after 820ms? That's simple to explain!

Here is a small flow of what will happen after reset:

* /Reset is going high
* LPC enters bootloader (vector-table located in boot flash; see manual)
* bootloader is checking P0.14:

  if (P0.14 is high) {
    goto bootloader_shell		/* wait for communication with flash-utility */
  }
  else  {
    /* check if for valid checksum of user-vector-table */

    if (checksum is OK)
      goto reset-vector-at-user-table	/* jump to your code (user-vector-table at
0x00000000) */
    else
      goto bootloader_shell		/* wait for communication with falsh-utility */
  }

That means P0.14 must be held down as long as the bootloader has checked this
pin. The reason why
you can programm your LPC only the first time is checking of
user-vector-table's checksum. If you
have blank device this checksum is invalid. In this case the bootloader remains
in bootloader state.
Keep in mind that P0.14 is a simple GPIO pin and LPC's bootloader is still
a piece of code. There is
nothing magic.

You can talk with your bootloader by hand too. Just open a serial terminal
program; enter bootloader
mode on LPC (P0.14, /Reset) and type '?' until LPC returns
"Syncronized" (Auto-baudrate detection).
After that you must reply this with the string
"Synchronized<CR>" too. Then you can enter bootloader
commands decribed in manual.
If you want you can download my open-source flash utility (see below) and use
the secrete option
"-vvv" for debugging.

  Sten

-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/

Hi Tim,
I haven't checked this on my own hardware, but it sounds to me like
you have RESET and P0.14 swapped over.
The bootloader can only look at P0.14 after RESET has been released.
So I would expect P0.14 to be asserted (low) for longer than RESET. 

Hope this helps,
Danish
--- In lpc2000@lpc2..., "tah2k" <tah2k@...> wrote:
> I'm currently experiencing a very frustrating
issue with the LPC2138 
> bootloader. I can successfully and reliably use the Philips flash 
> utility to download an image to a blank LPC2138 once and only once. 
> After that, the flash utility is never able to communicate with the 
> LPC2138.
> 
> I have been monitoring the recent bootloader thread that was 
> resolved by manipulating the watchdog overflow flag which, if set, 
> will cause the bootloader reques to be ignored. Unfortunately, this 
> is not the same problem I am having because I'm never enabling the 
> watchdog.
> 
> I've been working with an evaluation board for 6 months now so I 
> felt confident I understood the processor because I never had this 
> issue. Now that I am bringing up custom hardware, I removed 
> everything from the board except the processor, JTAG, and power 
> supplies. I thought perhaps my code was inadvertently configuring an 
> I/O pin in conflict, so I modified the application code to simply 
> sit in a loop after disabling interrupts and other basic init steps.
> 
> The signals to the processor are exactly what I would expect:
> 1.) The reset line and P0.14 are pulled low by the Philips Flash 
> application at t=0.
> 2.) The P0.14 line is held low for about 470mS before being 
> released, and the reset is held low for about 820mS before being 
> released.
> 3.) After these transitions, the processor sees the 0x3F being 
> transmitted by the flash utility.
> 
> So, as far as I can tell, everything is ocuring correctly, but I am 
> unable to access the bootloader after the first initial image 
> download. I was initially swapping processors, but each one behaves 
> the same way.
	

Quoting tah2k <tah2k@tah2...>:

> The signals to the processor are exactly what I
would expect:
> 1.) The reset line and P0.14 are pulled low by the Philips Flash
> application at t=0.
> 2.) The P0.14 line is held low for about 470mS before being
> released, and the reset is held low for about 820mS before being
> released.
> 3.) After these transitions, the processor sees the 0x3F being
> transmitted by the flash utility.

That sounds like the reset and P0.14 lines are reversed.  P0.14 must be low
coming out of reset.  Something like

Reset ---|____________|---------------

P0.14 ---|______________________|----------

Actually there's no need for P0.14 to go high until you are done but it
won't
hurt either way.

See http://www.aeolusdevelopment.com/Articles/InSystemProgramming.html and
http://www.open-research.org.uk/ARMuC/index.cgi?Standard_ISP_Header for some
discussion on how to do this with a standard ISP header.

Robert
	

Thanks, you are correct and the problem is solved. I have been 
looking at those two lines for days knowing what they 'should' be.
Kills me.
Thanks-
Tim
	--- In lpc2000@lpc2..., Robert Adsett <subscriptions@...> 
wrote:
>
> Quoting tah2k <tah2k@...>:
> 
> > The signals to the processor are exactly what I would expect:
> > 1.) The reset line and P0.14 are pulled low by the Philips Flash
> > application at t=0.
> > 2.) The P0.14 line is held low for about 470mS before being
> > released, and the reset is held low for about 820mS before being
> > released.
> > 3.) After these transitions, the processor sees the 0x3F being
> > transmitted by the flash utility.
> 
> That sounds like the reset and P0.14 lines are reversed.  P0.14 
must be low
> coming out of reset.  Something like
> 
> Reset ---|____________|---------------
> 
> P0.14 ---|______________________|----------
> 
> Actually there's no need for P0.14 to go high until you are done 
but it won't
> hurt either way.
> 
> See 
http://www.aeolusdevelopment.com/Articles/InSystemProgramming.html 
and
> http://www.open-research.org.uk/ARMuC/index.cgi?
Standard_ISP_Header for some
> discussion on how to do this with a standard ISP
header.
> 
> Robert
>
	

Tim,

 >> 2.) The P0.14 line is held low for about 470mS before being
 >> released, and the reset is held low for about 820mS before being
 >> released.

Is it correct that P0.14 is high after reset in the sequence that you 
outlined ? I believe that you need to insure that P0.14 is low for 
greater than 3mS after reset has been released to enter the bootloader.

I am pretty new to the LPC so I hope this helps,

Bryce

tah2k wrote:

> Hi All-
>
> I'm currently experiencing a very frustrating issue with the LPC2138
> bootloader. I can successfully and reliably use the Philips flash
> utility to download an image to a blank LPC2138 once and only once.
> After that, the flash utility is never able to communicate with the
> LPC2138.
>
> I have been monitoring the recent bootloader thread that was
> resolved by manipulating the watchdog overflow flag which, if set,
> will cause the bootloader reques to be ignored. Unfortunately, this
> is not the same problem I am having because I'm never enabling the
> watchdog.
>
> I've been working with an evaluation board for 6 months now so I
> felt confident I understood the processor because I never had this
> issue. Now that I am bringing up custom hardware, I removed
> everything from the board except the processor, JTAG, and power
> supplies. I thought perhaps my code was inadvertently configuring an
> I/O pin in conflict, so I modified the application code to simply
> sit in a loop after disabling interrupts and other basic init steps.
>
> The signals to the processor are exactly what I would expect:
> 1.) The reset line and P0.14 are pulled low by the Philips Flash
> application at t=0.
> 2.) The P0.14 line is held low for about 470mS before being
> released, and the reset is held low for about 820mS before being
> released.
> 3.) After these transitions, the processor sees the 0x3F being
> transmitted by the flash utility.
>
> So, as far as I can tell, everything is ocuring correctly, but I am
> unable to access the bootloader after the first initial image
> download. I was initially swapping processors, but each one behaves
> the same way.
>
> Thanks-
> Tim
>
>
>
>
>
>
> SPONSORED LINKS
> Microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ>

> 	Microprocessor 
>
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA>

> 	Intel microprocessors 
>
<http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw>

>
> Pic microcontrollers 
>
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw>

>
>
>
> 
> >.
>
>
> 
>
	-- 
Bryce Himebaugh
Design Engineer
Indiana University Computer Science Dept.
(812) 855-6984
http://www.cs.indiana.edu/~bhimebau/
	

--- In lpc2000@lpc2..., Sten <list@...> wrote:
>
> tah2k wrote:
> > Hi All-
> > 
> > I'm currently experiencing a very frustrating issue with the 
LPC2138 
> > bootloader. I can successfully and reliably
use the Philips 
flash 
> > utility to download an image to a blank
LPC2138 once and only 
once. 
> > After that, the flash utility is never able
to communicate with 
the 
> > LPC2138.
> > 
> > I have been monitoring the recent bootloader thread that was 
> > resolved by manipulating the watchdog overflow flag which, if 
set, 
> > will cause the bootloader reques to be
ignored. Unfortunately, 
this 
> > is not the same problem I am having because
I'm never enabling 
the 
> > watchdog.
> > 
> > I've been working with an evaluation board for 6 months now so I 
> > felt confident I understood the processor because I never had 
this 
> > issue. Now that I am bringing up custom
hardware, I removed 
> > everything from the board except the processor, JTAG, and power 
> > supplies. I thought perhaps my code was inadvertently 
configuring an 
> > I/O pin in conflict, so I modified the
application code to 
simply 
> > sit in a loop after disabling interrupts and
other basic init 
steps.
> > 
> > The signals to the processor are exactly what I would expect:
> > 1.) The reset line and P0.14 are pulled low by the Philips Flash 
> > application at t=0.
> > 2.) The P0.14 line is held low for about 470mS before being 
> > released, and the reset is held low for about 820mS before being 
> > released.
> > 3.) After these transitions, the processor sees the 0x3F being 
> > transmitted by the flash utility.
> > 
> > So, as far as I can tell, everything is ocuring correctly, but I 
am 
> > unable to access the bootloader after the
first initial image 
> > download. I was initially swapping processors, but each one 
behaves 
> > the same way.
> > 
> > Thanks-
> > Tim
> > 
> 
Hello Tim.

As long as the Philips flash utility can drive the \RESET and P0.14 
with DTR and RTS there should be no problem with the bootloader.

-Sergei