I have a board containing an LPC2138. I cannot get the chip to come
out of bootloader mode or at least that is what I think is
happening. I can load programs with no errors through a Keil ULINK
but when I go into debug, the code I see starting at address 0 is
not my code but instead is a mirror of the bootloader. I can also
use the LPC2000 Flash Utility to load the chip, examine the buffer,
etc.
P0.14 is held high through a 10K pullup and there is no other
connection to P0.14. I see in the manual that the other condition
that can keep the bootloader from branching to my code is an invalid
checksum for the user program. I can download the exact code into an
Embedded Artists LPC2138 board and have no problems. My +3.3V looks
very solid with almost no ripple. I am using a 14.7456 MHz crystal.
The clock looks identical on a scope to the one on the Embedded
Artists board.
I designed the board, had it made by PCBExpress, and hand soldered
the components. I have only populated the 3.3V supply and the
LPC2138 and supporting parts so far. I feel pretty sure I have good
soldering, no shorts, etc. I have checked and re-checked and
reheated all the joints around the processor. It is working very
reliably with the downloading process.
Can anyone suggest what could be going on? I am pulling what little
hair I have out over this.
LPC2138 will not come out of bootloader mode
Started by ●January 10, 2007
Reply by ●January 11, 20072007-01-11
Hi,
I can't think what could cause this - usually people have the
opposite problem!!!
I can think of a few tests you can do though......
Try the following:
Using your JTAG debugger, take a look at the P0.14 pin, see what
level the processor thinks it is, perhaps that pins IO function is
damaged?
I use OpenOCD, you can telnet to the OpenOCD and type:-
mdw 0xE0028000
This will display the value on Port0 pins. Bit 14 of the result is
the value the CPU sees for pin P0.14
No idea how you do this in keil, not used it in a long time, and I
have no idea if anybody has patched OpenOCD to work with the ULINK
hardware.
Are you sure you have calculated the correct checksum from the
interrupt vectors and placed the correct data in the flash?
I think if you cause a watchdog reset, the bootloader does not run,
even if P0.14 is low. (I use this feature in my external FLASH
loader) Write a little program to force a watchdog reset, place a
breakpoint at the end of it. Load it and call that program using
the debugger, then take a look at the first 64 bytes of memory. Are
they what you expect?
regards,
Jason.
--- In l..., "kennytrussell"
wrote:
>
> I have a board containing an LPC2138. I cannot get the chip to
come
> out of bootloader mode or at least that is what I think is
> happening. I can load programs with no errors through a Keil ULINK
> but when I go into debug, the code I see starting at address 0 is
> not my code but instead is a mirror of the bootloader. I can also
> use the LPC2000 Flash Utility to load the chip, examine the
buffer,
> etc.
>
> P0.14 is held high through a 10K pullup and there is no other
> connection to P0.14. I see in the manual that the other condition
> that can keep the bootloader from branching to my code is an
invalid
> checksum for the user program. I can download the exact code into
an
> Embedded Artists LPC2138 board and have no problems. My +3.3V
looks
> very solid with almost no ripple. I am using a 14.7456 MHz
crystal.
> The clock looks identical on a scope to the one on the Embedded
> Artists board.
>
> I designed the board, had it made by PCBExpress, and hand soldered
> the components. I have only populated the 3.3V supply and the
> LPC2138 and supporting parts so far. I feel pretty sure I have
good
> soldering, no shorts, etc. I have checked and re-checked and
> reheated all the joints around the processor. It is working very
> reliably with the downloading process.
>
> Can anyone suggest what could be going on? I am pulling what
little
> hair I have out over this.
>
I can't think what could cause this - usually people have the
opposite problem!!!
I can think of a few tests you can do though......
Try the following:
Using your JTAG debugger, take a look at the P0.14 pin, see what
level the processor thinks it is, perhaps that pins IO function is
damaged?
I use OpenOCD, you can telnet to the OpenOCD and type:-
mdw 0xE0028000
This will display the value on Port0 pins. Bit 14 of the result is
the value the CPU sees for pin P0.14
No idea how you do this in keil, not used it in a long time, and I
have no idea if anybody has patched OpenOCD to work with the ULINK
hardware.
Are you sure you have calculated the correct checksum from the
interrupt vectors and placed the correct data in the flash?
I think if you cause a watchdog reset, the bootloader does not run,
even if P0.14 is low. (I use this feature in my external FLASH
loader) Write a little program to force a watchdog reset, place a
breakpoint at the end of it. Load it and call that program using
the debugger, then take a look at the first 64 bytes of memory. Are
they what you expect?
regards,
Jason.
--- In l..., "kennytrussell"
wrote:
>
> I have a board containing an LPC2138. I cannot get the chip to
come
> out of bootloader mode or at least that is what I think is
> happening. I can load programs with no errors through a Keil ULINK
> but when I go into debug, the code I see starting at address 0 is
> not my code but instead is a mirror of the bootloader. I can also
> use the LPC2000 Flash Utility to load the chip, examine the
buffer,
> etc.
>
> P0.14 is held high through a 10K pullup and there is no other
> connection to P0.14. I see in the manual that the other condition
> that can keep the bootloader from branching to my code is an
invalid
> checksum for the user program. I can download the exact code into
an
> Embedded Artists LPC2138 board and have no problems. My +3.3V
looks
> very solid with almost no ripple. I am using a 14.7456 MHz
crystal.
> The clock looks identical on a scope to the one on the Embedded
> Artists board.
>
> I designed the board, had it made by PCBExpress, and hand soldered
> the components. I have only populated the 3.3V supply and the
> LPC2138 and supporting parts so far. I feel pretty sure I have
good
> soldering, no shorts, etc. I have checked and re-checked and
> reheated all the joints around the processor. It is working very
> reliably with the downloading process.
>
> Can anyone suggest what could be going on? I am pulling what
little
> hair I have out over this.
>
Reply by ●January 11, 20072007-01-11
Thanks Jason for the suggestions. I will not be able to try these
until later today but I will. One question about the checksum,
however. I have been developing with Realview in Keil with Embedded
Artists boards for about a year now and I have never had to
calculate a checksum. All that is done by the debugger in Keil, I
suppose. Is there something I need to look at? What makes this so
wierd is that I can load the exact program to an Embedded Artists
board without recompile, just move the JTAG from one board to
another.
I believe I checked P0.14 in the debugger but it was a few days ago.
I will definitely do that again.
I have 3 more identical blank PC boards. My next step will be to
populate one of them to see if the problem repeats.
Thank you for responding!
--- In l..., "Jason Morgan"
wrote:
>
> Hi,
>
> I can't think what could cause this - usually people have the
> opposite problem!!!
>
> I can think of a few tests you can do though......
>
> Try the following:
>
> Using your JTAG debugger, take a look at the P0.14 pin, see what
> level the processor thinks it is, perhaps that pins IO function is
> damaged?
>
> I use OpenOCD, you can telnet to the OpenOCD and type:-
>
> mdw 0xE0028000
>
> This will display the value on Port0 pins. Bit 14 of the result
is
> the value the CPU sees for pin P0.14
>
> No idea how you do this in keil, not used it in a long time, and I
> have no idea if anybody has patched OpenOCD to work with the ULINK
> hardware.
>
> Are you sure you have calculated the correct checksum from the
> interrupt vectors and placed the correct data in the flash?
>
> I think if you cause a watchdog reset, the bootloader does not
run,
> even if P0.14 is low. (I use this feature in my external FLASH
> loader) Write a little program to force a watchdog reset, place a
> breakpoint at the end of it. Load it and call that program using
> the debugger, then take a look at the first 64 bytes of memory.
Are
> they what you expect?
> regards,
> Jason.
>
> --- In l..., "kennytrussell"
> wrote:
> >
> > I have a board containing an LPC2138. I cannot get the chip to
> come
> > out of bootloader mode or at least that is what I think is
> > happening. I can load programs with no errors through a Keil
ULINK
> > but when I go into debug, the code I see starting at address 0
is
> > not my code but instead is a mirror of the bootloader. I can
also
> > use the LPC2000 Flash Utility to load the chip, examine the
> buffer,
> > etc.
> >
> > P0.14 is held high through a 10K pullup and there is no other
> > connection to P0.14. I see in the manual that the other
condition
> > that can keep the bootloader from branching to my code is an
> invalid
> > checksum for the user program. I can download the exact code
into
> an
> > Embedded Artists LPC2138 board and have no problems. My +3.3V
> looks
> > very solid with almost no ripple. I am using a 14.7456 MHz
> crystal.
> > The clock looks identical on a scope to the one on the Embedded
> > Artists board.
> >
> > I designed the board, had it made by PCBExpress, and hand
soldered
> > the components. I have only populated the 3.3V supply and the
> > LPC2138 and supporting parts so far. I feel pretty sure I have
> good
> > soldering, no shorts, etc. I have checked and re-checked and
> > reheated all the joints around the processor. It is working very
> > reliably with the downloading process.
> >
> > Can anyone suggest what could be going on? I am pulling what
> little
> > hair I have out over this.
>
until later today but I will. One question about the checksum,
however. I have been developing with Realview in Keil with Embedded
Artists boards for about a year now and I have never had to
calculate a checksum. All that is done by the debugger in Keil, I
suppose. Is there something I need to look at? What makes this so
wierd is that I can load the exact program to an Embedded Artists
board without recompile, just move the JTAG from one board to
another.
I believe I checked P0.14 in the debugger but it was a few days ago.
I will definitely do that again.
I have 3 more identical blank PC boards. My next step will be to
populate one of them to see if the problem repeats.
Thank you for responding!
--- In l..., "Jason Morgan"
wrote:
>
> Hi,
>
> I can't think what could cause this - usually people have the
> opposite problem!!!
>
> I can think of a few tests you can do though......
>
> Try the following:
>
> Using your JTAG debugger, take a look at the P0.14 pin, see what
> level the processor thinks it is, perhaps that pins IO function is
> damaged?
>
> I use OpenOCD, you can telnet to the OpenOCD and type:-
>
> mdw 0xE0028000
>
> This will display the value on Port0 pins. Bit 14 of the result
is
> the value the CPU sees for pin P0.14
>
> No idea how you do this in keil, not used it in a long time, and I
> have no idea if anybody has patched OpenOCD to work with the ULINK
> hardware.
>
> Are you sure you have calculated the correct checksum from the
> interrupt vectors and placed the correct data in the flash?
>
> I think if you cause a watchdog reset, the bootloader does not
run,
> even if P0.14 is low. (I use this feature in my external FLASH
> loader) Write a little program to force a watchdog reset, place a
> breakpoint at the end of it. Load it and call that program using
> the debugger, then take a look at the first 64 bytes of memory.
Are
> they what you expect?
> regards,
> Jason.
>
> --- In l..., "kennytrussell"
> wrote:
> >
> > I have a board containing an LPC2138. I cannot get the chip to
> come
> > out of bootloader mode or at least that is what I think is
> > happening. I can load programs with no errors through a Keil
ULINK
> > but when I go into debug, the code I see starting at address 0
is
> > not my code but instead is a mirror of the bootloader. I can
also
> > use the LPC2000 Flash Utility to load the chip, examine the
> buffer,
> > etc.
> >
> > P0.14 is held high through a 10K pullup and there is no other
> > connection to P0.14. I see in the manual that the other
condition
> > that can keep the bootloader from branching to my code is an
> invalid
> > checksum for the user program. I can download the exact code
into
> an
> > Embedded Artists LPC2138 board and have no problems. My +3.3V
> looks
> > very solid with almost no ripple. I am using a 14.7456 MHz
> crystal.
> > The clock looks identical on a scope to the one on the Embedded
> > Artists board.
> >
> > I designed the board, had it made by PCBExpress, and hand
soldered
> > the components. I have only populated the 3.3V supply and the
> > LPC2138 and supporting parts so far. I feel pretty sure I have
> good
> > soldering, no shorts, etc. I have checked and re-checked and
> > reheated all the joints around the processor. It is working very
> > reliably with the downloading process.
> >
> > Can anyone suggest what could be going on? I am pulling what
> little
> > hair I have out over this.
>
Reply by ●January 11, 20072007-01-11
Use you scope and actually measure the voltage at
P0.14 and make sure that it is high.
--- kennytrussell
wrote:
> Thanks Jason for the suggestions. I will not be able
> to try these
> until later today but I will. One question about the
> checksum,
> however. I have been developing with Realview in
> Keil with Embedded
> Artists boards for about a year now and I have never
> had to
> calculate a checksum. All that is done by the
> debugger in Keil, I
> suppose. Is there something I need to look at? What
> makes this so
> wierd is that I can load the exact program to an
> Embedded Artists
> board without recompile, just move the JTAG from one
> board to
> another.
>
> I believe I checked P0.14 in the debugger but it was
> a few days ago.
> I will definitely do that again.
>
> I have 3 more identical blank PC boards. My next
> step will be to
> populate one of them to see if the problem repeats.
>
> Thank you for responding!
>
> --- In l..., "Jason Morgan"
>
> wrote:
> >
> > Hi,
> >
> > I can't think what could cause this - usually
> people have the
> > opposite problem!!!
> >
> > I can think of a few tests you can do though......
> >
> > Try the following:
> >
> > Using your JTAG debugger, take a look at the P0.14
> pin, see what
> > level the processor thinks it is, perhaps that
> pins IO function is
> > damaged?
> >
> > I use OpenOCD, you can telnet to the OpenOCD and
> type:-
> >
> > mdw 0xE0028000
> >
> > This will display the value on Port0 pins. Bit 14
> of the result
> is
> > the value the CPU sees for pin P0.14
> >
> > No idea how you do this in keil, not used it in a
> long time, and I
> > have no idea if anybody has patched OpenOCD to
> work with the ULINK
> > hardware.
> >
> > Are you sure you have calculated the correct
> checksum from the
> > interrupt vectors and placed the correct data in
> the flash?
> >
> > I think if you cause a watchdog reset, the
> bootloader does not
> run,
> > even if P0.14 is low. (I use this feature in my
> external FLASH
> > loader) Write a little program to force a watchdog
> reset, place a
> > breakpoint at the end of it. Load it and call
> that program using
> > the debugger, then take a look at the first 64
> bytes of memory.
> Are
> > they what you expect?
> >
> >
> > regards,
> > Jason.
> >
> >
> >
> > --- In l..., "kennytrussell"
> > wrote:
> > >
> > > I have a board containing an LPC2138. I cannot
> get the chip to
> > come
> > > out of bootloader mode or at least that is what
> I think is
> > > happening. I can load programs with no errors
> through a Keil
> ULINK
> > > but when I go into debug, the code I see
> starting at address 0
> is
> > > not my code but instead is a mirror of the
> bootloader. I can
> also
> > > use the LPC2000 Flash Utility to load the chip,
> examine the
> > buffer,
> > > etc.
> > >
> > > P0.14 is held high through a 10K pullup and
> there is no other
> > > connection to P0.14. I see in the manual that
> the other
> condition
> > > that can keep the bootloader from branching to
> my code is an
> > invalid
> > > checksum for the user program. I can download
> the exact code
> into
> > an
> > > Embedded Artists LPC2138 board and have no
> problems. My +3.3V
> > looks
> > > very solid with almost no ripple. I am using a
> 14.7456 MHz
> > crystal.
> > > The clock looks identical on a scope to the one
> on the Embedded
> > > Artists board.
> > >
> > > I designed the board, had it made by PCBExpress,
> and hand
> soldered
> > > the components. I have only populated the 3.3V
> supply and the
> > > LPC2138 and supporting parts so far. I feel
> pretty sure I have
> > good
> > > soldering, no shorts, etc. I have checked and
> re-checked and
> > > reheated all the joints around the processor. It
> is working very
> > > reliably with the downloading process.
> > >
> > > Can anyone suggest what could be going on? I am
> pulling what
> > little
> > > hair I have out over this.
> > >
>
____________________________________________________________________________________
Never Miss an Email
Stay connected with Yahoo! Mail on your mobile. Get started!
http://mobile.yahoo.com/services?promote=mail
P0.14 and make sure that it is high.
--- kennytrussell
wrote:
> Thanks Jason for the suggestions. I will not be able
> to try these
> until later today but I will. One question about the
> checksum,
> however. I have been developing with Realview in
> Keil with Embedded
> Artists boards for about a year now and I have never
> had to
> calculate a checksum. All that is done by the
> debugger in Keil, I
> suppose. Is there something I need to look at? What
> makes this so
> wierd is that I can load the exact program to an
> Embedded Artists
> board without recompile, just move the JTAG from one
> board to
> another.
>
> I believe I checked P0.14 in the debugger but it was
> a few days ago.
> I will definitely do that again.
>
> I have 3 more identical blank PC boards. My next
> step will be to
> populate one of them to see if the problem repeats.
>
> Thank you for responding!
>
> --- In l..., "Jason Morgan"
>
> wrote:
> >
> > Hi,
> >
> > I can't think what could cause this - usually
> people have the
> > opposite problem!!!
> >
> > I can think of a few tests you can do though......
> >
> > Try the following:
> >
> > Using your JTAG debugger, take a look at the P0.14
> pin, see what
> > level the processor thinks it is, perhaps that
> pins IO function is
> > damaged?
> >
> > I use OpenOCD, you can telnet to the OpenOCD and
> type:-
> >
> > mdw 0xE0028000
> >
> > This will display the value on Port0 pins. Bit 14
> of the result
> is
> > the value the CPU sees for pin P0.14
> >
> > No idea how you do this in keil, not used it in a
> long time, and I
> > have no idea if anybody has patched OpenOCD to
> work with the ULINK
> > hardware.
> >
> > Are you sure you have calculated the correct
> checksum from the
> > interrupt vectors and placed the correct data in
> the flash?
> >
> > I think if you cause a watchdog reset, the
> bootloader does not
> run,
> > even if P0.14 is low. (I use this feature in my
> external FLASH
> > loader) Write a little program to force a watchdog
> reset, place a
> > breakpoint at the end of it. Load it and call
> that program using
> > the debugger, then take a look at the first 64
> bytes of memory.
> Are
> > they what you expect?
> >
> >
> > regards,
> > Jason.
> >
> >
> >
> > --- In l..., "kennytrussell"
> > wrote:
> > >
> > > I have a board containing an LPC2138. I cannot
> get the chip to
> > come
> > > out of bootloader mode or at least that is what
> I think is
> > > happening. I can load programs with no errors
> through a Keil
> ULINK
> > > but when I go into debug, the code I see
> starting at address 0
> is
> > > not my code but instead is a mirror of the
> bootloader. I can
> also
> > > use the LPC2000 Flash Utility to load the chip,
> examine the
> > buffer,
> > > etc.
> > >
> > > P0.14 is held high through a 10K pullup and
> there is no other
> > > connection to P0.14. I see in the manual that
> the other
> condition
> > > that can keep the bootloader from branching to
> my code is an
> > invalid
> > > checksum for the user program. I can download
> the exact code
> into
> > an
> > > Embedded Artists LPC2138 board and have no
> problems. My +3.3V
> > looks
> > > very solid with almost no ripple. I am using a
> 14.7456 MHz
> > crystal.
> > > The clock looks identical on a scope to the one
> on the Embedded
> > > Artists board.
> > >
> > > I designed the board, had it made by PCBExpress,
> and hand
> soldered
> > > the components. I have only populated the 3.3V
> supply and the
> > > LPC2138 and supporting parts so far. I feel
> pretty sure I have
> > good
> > > soldering, no shorts, etc. I have checked and
> re-checked and
> > > reheated all the joints around the processor. It
> is working very
> > > reliably with the downloading process.
> > >
> > > Can anyone suggest what could be going on? I am
> pulling what
> > little
> > > hair I have out over this.
> > >
>
____________________________________________________________________________________
Never Miss an Email
Stay connected with Yahoo! Mail on your mobile. Get started!
http://mobile.yahoo.com/services?promote=mail
