On my new version of Keil, version 4.01 of uVision, I still have a
loading issue of code 30000H (196K) and up. Keil says they can't
reproduce the problem, so they say I have a bootloader problem that is
protecting sectors 30000H and up.

I have a bootloader from 0-4FFF. All it does it transfer control to
5000H if the code is OK. I have a byte in offboard RAM that indicates
whether the last upload of remote code from SD card programmed and
verified OK. This byte is always valid, if SD card is not used to
program flash. Thus, thru JTAG or serial flash, this is not an issue.
If the byte is not valid, it starts a procedure that prompts for a valid
SD card with code.

The things that I have tried are:

- With the bootloader loaded (I don't overwrite or change this much), if
my application code crosses over the 30000H threshold, the code
verification thru the JTAG fails and thus doesn't load the code past
30000H. If I click, 'don't verify', the code loads fine, but still
doesn't run.

- if I erase the chip, program the application code first at 5000H, then
the bootloader at 0 (all thru JTAG), it works fine. Until the next time
I recompile the app code and try to reload at 5000H.

- if I program thru serial flash, everything works OK. I've never had
any problems thru this method.

- Everything works fine if the app code does not cross over the 30000H
threshold and has always worked prior to discovery of this. I verify
this by commenting out some code, recompiling, and loading successfully.

- I have the 256K version, not the full 512K version.

What do I need to look for to see what is causing this 30000H to be an
issue? What do I look for in the bootloader? There is nothing that I
know of that is even remotely close to accessing any location that high.
Is there some type of security lock of particular sectors that could
be getting activated somehow without me knowing? This is what Keil
support thinks is happening.

Any ideas?

--
Sutton

An Engineer's Guide to the LPC2100 Series

> The things that I have tried are:
>
> - With the bootloader loaded (I don't overwrite or change this much), if
> my application code crosses over the 30000H threshold, the code
> verification thru the JTAG fails and thus doesn't load the code past
> 30000H. If I click, 'don't verify', the code loads fine, but still
> doesn't run.
>
> - if I erase the chip, program the application code first at 5000H, then
> the bootloader at 0 (all thru JTAG), it works fine. Until the next time
> I recompile the app code and try to reload at 5000H.

There are a number of things that can cause problems with intermittent
programming.

I believe this is what you are seeing:

(1) Completely erase chip
(2) Program app that flashes 0x5000-0x30000+, all ok
(3) Program booloader that flashes 0x0-0x4fff, all ok
(4) Reset board, "all ok" (bootloader and app probably runs, code works
"as expected")
(5) Stop and Repogram app that flashes 0x5000-0x30000+, app won't flash
correctly, bummer.

This suggests that the bootloader interferes with the programming of the
flash.

Causes? Many. As you may well know, it is impossible for the LPC2000 to
be reset and then immediately stopped before the ROM bootloader and user
code starts. Hence, havoc ensues because by the time JTAG has got hold of
the processor, peripherals can be initialized, DMA can be running,
watchdogs programmed and so on. There is *NO WAY* to reset the processor
into a SANE STATE with the periphery held. Hence, programming *can* fail.

Solution?

First, try verify this is the case by rerunning the steps above *BUT*
forcing your board into the ROM bootloader by inserting step
(4-and-a-half) which is "bring P0.14 low to cause ROM bootloader entry".
(I've no idea whether this is a different pin on your processor.) Hence,
after the CPU has been reset it enters the ROM bootloader and stays there,
not your bootloader. NOTE: I am not an expert on Keil's flash programming
methodology, KEEP P0.14 LOW ALL THE TIME frim steps (4.5) onwards! If you
have a Keil board, P0.14 is actually brought out to a user button which
you can keep pressed in steps (4.5) and (5).

Ok, whether that did or didn't work, the NEXT thing to do it to try to
alleviate the problem. How? By putting the LPC2000 to sleep for a while
before it enters your app and starts programming up peripherals. Hence,
in YOUR BOOTLOADER startup code, just after reset and before programing
the PLL or entering main(), shove in a BIG DELAY. Something you can
*see*, your bootloader doesn't get running for a second or more as the
loop executes.

Now, after doing that, see whether (1) to (5) work for you. The LPC2000
will be in a mostly-reset state and you should be able to reprogram your
board AS LONG AS the Keil flash programmer issues a reset through the JTAG
interface (which it should).

Cripes. Keil software support too...

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!

--- In l..., Sutton Mehaffey wrote:
>
> On my new version of Keil, version 4.01 of uVision, I still have a
> loading issue of code 30000H (196K) and up. Keil says they can't
> reproduce the problem, so they say I have a bootloader problem that is
> protecting sectors 30000H and up.
>
> I have a bootloader from 0-4FFF. All it does it transfer control to
> 5000H if the code is OK. I have a byte in offboard RAM that indicates
> whether the last upload of remote code from SD card programmed and
> verified OK. This byte is always valid, if SD card is not used to
> program flash. Thus, thru JTAG or serial flash, this is not an issue.
> If the byte is not valid, it starts a procedure that prompts for a valid
> SD card with code.
>
> The things that I have tried are:
>
> - With the bootloader loaded (I don't overwrite or change this much), if
> my application code crosses over the 30000H threshold, the code
> verification thru the JTAG fails and thus doesn't load the code past
> 30000H. If I click, 'don't verify', the code loads fine, but still
> doesn't run.
>
> - if I erase the chip, program the application code first at 5000H, then
> the bootloader at 0 (all thru JTAG), it works fine. Until the next time
> I recompile the app code and try to reload at 5000H.
>
> - if I program thru serial flash, everything works OK. I've never had
> any problems thru this method.
>
> - Everything works fine if the app code does not cross over the 30000H
> threshold and has always worked prior to discovery of this. I verify
> this by commenting out some code, recompiling, and loading successfully.
>
> - I have the 256K version, not the full 512K version.
>
> What do I need to look for to see what is causing this 30000H to be an
> issue? What do I look for in the bootloader? There is nothing that I
> know of that is even remotely close to accessing any location that high.
> Is there some type of security lock of particular sectors that could
> be getting activated somehow without me knowing? This is what Keil
> support thinks is happening.
>
> Any ideas?
>
> --
> Sutton
>

Hi Sutton,

What Keil support indicates is something that happened in the past. There is also an area that the NXP bootloader protect from overwriting. So, the programming routine calls the bootloader, the bootloader does an address check and if it is not a protected block, it programs as requested. The protected blocks for a LPC2148 are some KB at the upper end of the internal flash, ergo from 500K to 512K according to page 13 on the latest data sheet.
As there is no 192 KB device I know of, there is no reason for the bootloader to stop programming at this address limit. Did you already check the Keil Forum for an answer? The problem does definitely sound like a software limitation for programming, not a chip problem. Can't say though which software, Keil, bootloader or your software?

Bob

I'm back on this. I didn't try anything complicated. I reduced my
bootloader code to:

typedef void (*LOOKOUT_APP)(void);

int main()
{
LOOKOUT_APP lookout_app = (LOOKOUT_APP)0x00005010;

lookout_app();
}

which solely transfers execution to my main code at 5010. With Startup,
the code size is 716 bytes. Still does the same thing.

Contents mismatch at 00030001H (Flash=xxH Required=yyH)
..
..
Contents mismatch at 0003001BH (Flash=xxH Required=yyH)

Could it be the Startup file? It's the same startup file used for the
normal code. Which is the same startup provided by NXP or Keil for the
LPC2148.

Keil still says it's my bootloader causing the problem. I think I
proved otherwise, unless it's in the startup file.

Again, if I program the bootloader file, then the main code, it fails.
If I program the main code, then the bootloader, it loads fine.

Sutton

Paul Curtis wrote:
>> The things that I have tried are:
>>
>> - With the bootloader loaded (I don't overwrite or change this much), if
>> my application code crosses over the 30000H threshold, the code
>> verification thru the JTAG fails and thus doesn't load the code past
>> 30000H. If I click, 'don't verify', the code loads fine, but still
>> doesn't run.
>>
>> - if I erase the chip, program the application code first at 5000H, then
>> the bootloader at 0 (all thru JTAG), it works fine. Until the next time
>> I recompile the app code and try to reload at 5000H.
>
> There are a number of things that can cause problems with intermittent
> programming.
>
> I believe this is what you are seeing:
>
> (1) Completely erase chip
> (2) Program app that flashes 0x5000-0x30000+, all ok
> (3) Program booloader that flashes 0x0-0x4fff, all ok
> (4) Reset board, "all ok" (bootloader and app probably runs, code works
> "as expected")
> (5) Stop and Repogram app that flashes 0x5000-0x30000+, app won't flash
> correctly, bummer.
>
> This suggests that the bootloader interferes with the programming of the
> flash.
>
> Causes? Many. As you may well know, it is impossible for the LPC2000 to
> be reset and then immediately stopped before the ROM bootloader and user
> code starts. Hence, havoc ensues because by the time JTAG has got hold of
> the processor, peripherals can be initialized, DMA can be running,
> watchdogs programmed and so on. There is *NO WAY* to reset the processor
> into a SANE STATE with the periphery held. Hence, programming *can* fail.
>
> Solution?
>
> First, try verify this is the case by rerunning the steps above *BUT*
> forcing your board into the ROM bootloader by inserting step
> (4-and-a-half) which is "bring P0.14 low to cause ROM bootloader entry".
> (I've no idea whether this is a different pin on your processor.) Hence,
> after the CPU has been reset it enters the ROM bootloader and stays there,
> not your bootloader. NOTE: I am not an expert on Keil's flash programming
> methodology, KEEP P0.14 LOW ALL THE TIME frim steps (4.5) onwards! If you
> have a Keil board, P0.14 is actually brought out to a user button which
> you can keep pressed in steps (4.5) and (5).
>
> Ok, whether that did or didn't work, the NEXT thing to do it to try to
> alleviate the problem. How? By putting the LPC2000 to sleep for a while
> before it enters your app and starts programming up peripherals. Hence,
> in YOUR BOOTLOADER startup code, just after reset and before programing
> the PLL or entering main(), shove in a BIG DELAY. Something you can
> *see*, your bootloader doesn't get running for a second or more as the
> loop executes.
>
> Now, after doing that, see whether (1) to (5) work for you. The LPC2000
> will be in a mostly-reset state and you should be able to reprogram your
> board AS LONG AS the Keil flash programmer issues a reset through the JTAG
> interface (which it should).
>
> Cripes. Keil software support too...
>

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com

Christ, tell you what to do to diagnose your bloody problem, and you do
something completely different to "prove" your code is fine, still doesn't
work, and you ask for more help.

What a joke. No wonder Keil don't really want to help you. And this is a
polite reply.

Merry Christmas,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!

> -----Original Message-----
> From: l... [mailto:l...] On Behalf
Of
> Sutton Mehaffey
> Sent: 17 December 2009 17:50
> To: l...
> Subject: Re: [lpc2000] Keil JTAG loading issue - LPC2148
>
> I'm back on this. I didn't try anything complicated. I reduced my
> bootloader code to:
>
> typedef void (*LOOKOUT_APP)(void);
>
> int main()
> {
> LOOKOUT_APP lookout_app = (LOOKOUT_APP)0x00005010;
>
> lookout_app();
> }
>
> which solely transfers execution to my main code at 5010. With Startup,
> the code size is 716 bytes. Still does the same thing.
>
> Contents mismatch at 00030001H (Flash=xxH Required=yyH)
> ..
> ..
> Contents mismatch at 0003001BH (Flash=xxH Required=yyH)
>
> Could it be the Startup file? It's the same startup file used for the
> normal code. Which is the same startup provided by NXP or Keil for the
> LPC2148.
>
> Keil still says it's my bootloader causing the problem. I think I
> proved otherwise, unless it's in the startup file.
>
> Again, if I program the bootloader file, then the main code, it fails.
> If I program the main code, then the bootloader, it loads fine.
>
> Sutton
>
>
>
>
> Paul Curtis wrote:
> >> The things that I have tried are:
> >>
> >> - With the bootloader loaded (I don't overwrite or change this much),
if
> >> my application code crosses over the 30000H threshold, the code
> >> verification thru the JTAG fails and thus doesn't load the code past
> >> 30000H. If I click, 'don't verify', the code loads fine, but still
> >> doesn't run.
> >>
> >> - if I erase the chip, program the application code first at 5000H,
then
> >> the bootloader at 0 (all thru JTAG), it works fine. Until the next
time
> >> I recompile the app code and try to reload at 5000H.
> >
> > There are a number of things that can cause problems with intermittent
> > programming.
> >
> > I believe this is what you are seeing:
> >
> > (1) Completely erase chip
> > (2) Program app that flashes 0x5000-0x30000+, all ok
> > (3) Program booloader that flashes 0x0-0x4fff, all ok
> > (4) Reset board, "all ok" (bootloader and app probably runs, code works
> > "as expected")
> > (5) Stop and Repogram app that flashes 0x5000-0x30000+, app won't flash
> > correctly, bummer.
> >
> > This suggests that the bootloader interferes with the programming of the
> > flash.
> >
> > Causes? Many. As you may well know, it is impossible for the LPC2000
to
> > be reset and then immediately stopped before the ROM bootloader and user
> > code starts. Hence, havoc ensues because by the time JTAG has got hold
> of
> > the processor, peripherals can be initialized, DMA can be running,
> > watchdogs programmed and so on. There is *NO WAY* to reset the
processor
> > into a SANE STATE with the periphery held. Hence, programming *can*
> fail.
> >
> > Solution?
> >
> > First, try verify this is the case by rerunning the steps above *BUT*
> > forcing your board into the ROM bootloader by inserting step
> > (4-and-a-half) which is "bring P0.14 low to cause ROM bootloader entry".
> > (I've no idea whether this is a different pin on your processor.)
Hence,
> > after the CPU has been reset it enters the ROM bootloader and stays
> there,
> > not your bootloader. NOTE: I am not an expert on Keil's flash
> programming
> > methodology, KEEP P0.14 LOW ALL THE TIME frim steps (4.5) onwards! If
> you
> > have a Keil board, P0.14 is actually brought out to a user button which
> > you can keep pressed in steps (4.5) and (5).
> >
> > Ok, whether that did or didn't work, the NEXT thing to do it to try to
> > alleviate the problem. How? By putting the LPC2000 to sleep for a
while
> > before it enters your app and starts programming up peripherals. Hence,
> > in YOUR BOOTLOADER startup code, just after reset and before programing
> > the PLL or entering main(), shove in a BIG DELAY. Something you can
> > *see*, your bootloader doesn't get running for a second or more as the
> > loop executes.
> >
> > Now, after doing that, see whether (1) to (5) work for you. The LPC2000
> > will be in a mostly-reset state and you should be able to reprogram your
> > board AS LONG AS the Keil flash programmer issues a reset through the
> JTAG
> > interface (which it should).
> >
> > Cripes. Keil software support too...
> >
>
> --
> Sutton Mehaffey
> Lookout Portable Security
> 4040 Royal Dr.
> Kennesaw, GA 30144
> 770-514-7999, 800-207-6269
> Fax: 770-514-1285
> http://www.lookoutportablesecurity.com
> s...@lookoutportablesecurity.com
>
>
>
>
>
>

Paul,

I tried that. All I got was 'JTAG communication failure'. I couldn't
get that to work at all. I did that right after you commented. Sorry,
forgot to mention that. Then, I had to go out of town.

Sutton

Paul Curtis wrote:
>
>
> Christ, tell you what to do to diagnose your bloody problem, and you do
> something completely different to "prove" your code is fine, still doesn't
> work, and you ask for more help.
>
> What a joke. No wonder Keil don't really want to help you. And this is a
> polite reply.
>
> Merry Christmas,
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
>
> > -----Original Message-----
> > From: l...
> [mailto:l... ] On
> Behalf
> Of
> > Sutton Mehaffey
> > Sent: 17 December 2009 17:50
> > To: l...
> > Subject: Re: [lpc2000] Keil JTAG loading issue - LPC2148
> >
> > I'm back on this. I didn't try anything complicated. I reduced my
> > bootloader code to:
> >
> > typedef void (*LOOKOUT_APP)(void);
> >
> > int main()
> > {
> > LOOKOUT_APP lookout_app = (LOOKOUT_APP)0x00005010;
> >
> > lookout_app();
> > }
> >
> > which solely transfers execution to my main code at 5010. With Startup,
> > the code size is 716 bytes. Still does the same thing.
> >
> > Contents mismatch at 00030001H (Flash=xxH Required=yyH)
> > ..
> > ..
> > Contents mismatch at 0003001BH (Flash=xxH Required=yyH)
> >
> > Could it be the Startup file? It's the same startup file used for the
> > normal code. Which is the same startup provided by NXP or Keil for the
> > LPC2148.
> >
> > Keil still says it's my bootloader causing the problem. I think I
> > proved otherwise, unless it's in the startup file.
> >
> > Again, if I program the bootloader file, then the main code, it fails.
> > If I program the main code, then the bootloader, it loads fine.
> >
> > Sutton
> >
> >
> >
> >
> > Paul Curtis wrote:
> > >> The things that I have tried are:
> > >>
> > >> - With the bootloader loaded (I don't overwrite or change this much),
> if
> > >> my application code crosses over the 30000H threshold, the code
> > >> verification thru the JTAG fails and thus doesn't load the code past
> > >> 30000H. If I click, 'don't verify', the code loads fine, but still
> > >> doesn't run.
> > >>
> > >> - if I erase the chip, program the application code first at 5000H,
> then
> > >> the bootloader at 0 (all thru JTAG), it works fine. Until the next
> time
> > >> I recompile the app code and try to reload at 5000H.
> > >
> > > There are a number of things that can cause problems with intermittent
> > > programming.
> > >
> > > I believe this is what you are seeing:
> > >
> > > (1) Completely erase chip
> > > (2) Program app that flashes 0x5000-0x30000+, all ok
> > > (3) Program booloader that flashes 0x0-0x4fff, all ok
> > > (4) Reset board, "all ok" (bootloader and app probably runs, code works
> > > "as expected")
> > > (5) Stop and Repogram app that flashes 0x5000-0x30000+, app won't flash
> > > correctly, bummer.
> > >
> > > This suggests that the bootloader interferes with the programming
> of the
> > > flash.
> > >
> > > Causes? Many. As you may well know, it is impossible for the LPC2000
> to
> > > be reset and then immediately stopped before the ROM bootloader and
> user
> > > code starts. Hence, havoc ensues because by the time JTAG has got hold
> > of
> > > the processor, peripherals can be initialized, DMA can be running,
> > > watchdogs programmed and so on. There is *NO WAY* to reset the
> processor
> > > into a SANE STATE with the periphery held. Hence, programming *can*
> > fail.
> > >
> > > Solution?
> > >
> > > First, try verify this is the case by rerunning the steps above *BUT*
> > > forcing your board into the ROM bootloader by inserting step
> > > (4-and-a-half) which is "bring P0.14 low to cause ROM bootloader
> entry".
> > > (I've no idea whether this is a different pin on your processor.)
> Hence,
> > > after the CPU has been reset it enters the ROM bootloader and stays
> > there,
> > > not your bootloader. NOTE: I am not an expert on Keil's flash
> > programming
> > > methodology, KEEP P0.14 LOW ALL THE TIME frim steps (4.5) onwards! If
> > you
> > > have a Keil board, P0.14 is actually brought out to a user button which
> > > you can keep pressed in steps (4.5) and (5).
> > >
> > > Ok, whether that did or didn't work, the NEXT thing to do it to try to
> > > alleviate the problem. How? By putting the LPC2000 to sleep for a
> while
> > > before it enters your app and starts programming up peripherals. Hence,
> > > in YOUR BOOTLOADER startup code, just after reset and before programing
> > > the PLL or entering main(), shove in a BIG DELAY. Something you can
> > > *see*, your bootloader doesn't get running for a second or more as the
> > > loop executes.
> > >
> > > Now, after doing that, see whether (1) to (5) work for you. The LPC2000
> > > will be in a mostly-reset state and you should be able to reprogram
> your
> > > board AS LONG AS the Keil flash programmer issues a reset through the
> > JTAG
> > > interface (which it should).
> > >
> > > Cripes. Keil software support too...
> > >
> >
> > --
> > Sutton Mehaffey
> > Lookout Portable Security
> > 4040 Royal Dr.
> > Kennesaw, GA 30144
> > 770-514-7999, 800-207-6269
> > Fax: 770-514-1285
> > http://www.lookoutportablesecurity.com
>
> > s...@lookoutportablesecurity.com
>
> >
> >
> >
> >
> >
> >

On Thu, 17 Dec 2009 19:11:52 -0000, Sutton Mehaffey
wrote:

> Paul,
>
> I tried that.

You tried what? "That" singular, one thing?
> All I got was 'JTAG communication failure'. I couldn't
> get that to work at all.

"that?"

> I did that right after you commented. Sorry,
> forgot to mention that. Then, I had to go out of town.

IT IS 100% OBVIOUS TO ME WHAT THE PROBLEM IS. Unfortunately you still
can't diagnose it, which is a shame. Keil's diagnosis is 100% On The
Money too. You've already said what you do: erase, program app, program
bootloader: OK. erase, program bootloader, program app not ok. Hence
programming and operation of bootloader nukes programming app. QED.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!

--- In l..., Sutton Mehaffey wrote:
>
> Paul,
>
> I tried that. All I got was 'JTAG communication failure'. I couldn't
> get that to work at all. I did that right after you commented. Sorry,
> forgot to mention that. Then, I had to go out of town.
>
> Sutton
All I can say is that I hear you, on the JTAG communications problems.
I'm using IAR Workbench and the Segger JTAG box and sometimes get this.

Sometimes I can get it to work again by re-programming or at least erasing the parts using the Serial ISP method.

Also, if you use a USB network expander hub, I have found that they can get corrupted sometimes and need to be unplugged and plugged back in. Sometimes the PC itself has to be restarted and/or the main host application.

You may already know and/or have tried all of this, but there has been little response about these problems. At least, now, an LPC2000 Yahoo group search search about these problems will come up with something to show that it is not just one person's problem. It does happen for some weird reason. I wish there was more in depth information about how these particular parts JTAG ports work.

Then again, I have, for no apparent reason, found 2 LPC2366 JTAG pins go defective on me. Low impedance in this case. One was the RCTK line and the other was the part's RESET line all of a sudden was like, 125 Ohms to ground. You might check all of those lines and see
what you measure, too. I would be very interested in what you find out.

The RCTK line, as I remember, did not measure 0 Ohms to Vss, (more like 15K Ohms), but was a solid low (0.040 V) even with 5K Ohms of pullup. It was like it turned into an output instead of an input line.

boB

>
> Paul Curtis wrote:
> >
> >
> > Christ, tell you what to do to diagnose your bloody problem, and you do
> > something completely different to "prove" your code is fine, still doesn't
> > work, and you ask for more help.
> >
> > What a joke. No wonder Keil don't really want to help you. And this is a
> > polite reply.
> >
> > Merry Christmas,
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> >
> > CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
> >
> > > -----Original Message-----
> > > From: l...
> > [mailto:l... ] On
> > Behalf
> > Of
> > > Sutton Mehaffey
> > > Sent: 17 December 2009 17:50
> > > To: l...
> > > Subject: Re: [lpc2000] Keil JTAG loading issue - LPC2148
> > >
> > > I'm back on this. I didn't try anything complicated. I reduced my
> > > bootloader code to:
> > >
> > > typedef void (*LOOKOUT_APP)(void);
> > >
> > > int main()
> > > {
> > > LOOKOUT_APP lookout_app = (LOOKOUT_APP)0x00005010;
> > >
> > > lookout_app();
> > > }
> > >
> > > which solely transfers execution to my main code at 5010. With Startup,
> > > the code size is 716 bytes. Still does the same thing.
> > >
> > > Contents mismatch at 00030001H (Flash=xxH Required=yyH)
> > > ..
> > > ..
> > > Contents mismatch at 0003001BH (Flash=xxH Required=yyH)
> > >
> > > Could it be the Startup file? It's the same startup file used for the
> > > normal code. Which is the same startup provided by NXP or Keil for the
> > > LPC2148.
> > >
> > > Keil still says it's my bootloader causing the problem. I think I
> > > proved otherwise, unless it's in the startup file.
> > >
> > > Again, if I program the bootloader file, then the main code, it fails.
> > > If I program the main code, then the bootloader, it loads fine.
> > >
> > > Sutton
> > >
> > >
> > >
> > >
> > > Paul Curtis wrote:
> > > >> The things that I have tried are:
> > > >>
> > > >> - With the bootloader loaded (I don't overwrite or change this much),
> > if
> > > >> my application code crosses over the 30000H threshold, the code
> > > >> verification thru the JTAG fails and thus doesn't load the code past
> > > >> 30000H. If I click, 'don't verify', the code loads fine, but still
> > > >> doesn't run.
> > > >>
> > > >> - if I erase the chip, program the application code first at 5000H,
> > then
> > > >> the bootloader at 0 (all thru JTAG), it works fine. Until the next
> > time
> > > >> I recompile the app code and try to reload at 5000H.
> > > >
> > > > There are a number of things that can cause problems with intermittent
> > > > programming.
> > > >
> > > > I believe this is what you are seeing:
> > > >
> > > > (1) Completely erase chip
> > > > (2) Program app that flashes 0x5000-0x30000+, all ok
> > > > (3) Program booloader that flashes 0x0-0x4fff, all ok
> > > > (4) Reset board, "all ok" (bootloader and app probably runs, code works
> > > > "as expected")
> > > > (5) Stop and Repogram app that flashes 0x5000-0x30000+, app won't flash
> > > > correctly, bummer.
> > > >
> > > > This suggests that the bootloader interferes with the programming
> > of the
> > > > flash.
> > > >
> > > > Causes? Many. As you may well know, it is impossible for the LPC2000
> > to
> > > > be reset and then immediately stopped before the ROM bootloader and
> > user
> > > > code starts. Hence, havoc ensues because by the time JTAG has got hold
> > > of
> > > > the processor, peripherals can be initialized, DMA can be running,
> > > > watchdogs programmed and so on. There is *NO WAY* to reset the
> > processor
> > > > into a SANE STATE with the periphery held. Hence, programming *can*
> > > fail.
> > > >
> > > > Solution?
> > > >
> > > > First, try verify this is the case by rerunning the steps above *BUT*
> > > > forcing your board into the ROM bootloader by inserting step
> > > > (4-and-a-half) which is "bring P0.14 low to cause ROM bootloader
> > entry".
> > > > (I've no idea whether this is a different pin on your processor.)
> > Hence,
> > > > after the CPU has been reset it enters the ROM bootloader and stays
> > > there,
> > > > not your bootloader. NOTE: I am not an expert on Keil's flash
> > > programming
> > > > methodology, KEEP P0.14 LOW ALL THE TIME frim steps (4.5) onwards! If
> > > you
> > > > have a Keil board, P0.14 is actually brought out to a user button which
> > > > you can keep pressed in steps (4.5) and (5).
> > > >
> > > > Ok, whether that did or didn't work, the NEXT thing to do it to try to
> > > > alleviate the problem. How? By putting the LPC2000 to sleep for a
> > while
> > > > before it enters your app and starts programming up peripherals. Hence,
> > > > in YOUR BOOTLOADER startup code, just after reset and before programing
> > > > the PLL or entering main(), shove in a BIG DELAY. Something you can
> > > > *see*, your bootloader doesn't get running for a second or more as the
> > > > loop executes.
> > > >
> > > > Now, after doing that, see whether (1) to (5) work for you. The LPC2000
> > > > will be in a mostly-reset state and you should be able to reprogram
> > your
> > > > board AS LONG AS the Keil flash programmer issues a reset through the
> > > JTAG
> > > > interface (which it should).
> > > >
> > > > Cripes. Keil software support too...
> > > >
> > >
> > > --
> > > Sutton Mehaffey
> > > Lookout Portable Security
> > > 4040 Royal Dr.
> > > Kennesaw, GA 30144
> > > 770-514-7999, 800-207-6269
> > > Fax: 770-514-1285
> > > http://www.lookoutportablesecurity.com
> >
> > > sutton@...
> >
> > >
> > >
> > >
> > >
> > >
> > >

At 01:37 PM 12/17/2009, you wrote:
>On Thu, 17 Dec 2009 19:11:52 -0000, Sutton Mehaffey
> wrote:
>
> > Paul,
> >
> > I tried that.
>
>You tried what? "That" singular, one thing?
> > All I got was 'JTAG communication failure'. I couldn't
> > get that to work at all.
>
>"that?"
>
> > I did that right after you commented. Sorry,
> > forgot to mention that. Then, I had to go out of town.
>
>IT IS 100% OBVIOUS TO ME WHAT THE PROBLEM IS. Unfortunately you still
>can't diagnose it, which is a shame. Keil's diagnosis is 100% On The
>Money too. You've already said what you do: erase, program app, program
>bootloader: OK. erase, program bootloader, program app not ok. Hence
>programming and operation of bootloader nukes programming app. QED.
>
>--
>Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>CrossWorks V2 is out for LPC1700, LPC3100, LPC3200, SAM9, and more!
>

Maybe my insanity signature applies once in a while.

Cecil Bayona
K5NWA
www.softrockradio.org www.qrpradio.com

I fail to see why doing the same thing over and over and getting the
same results every time is insanity: I've almost proved it isn't;
only a few more tests now and I'm sure results will differ this time ...

Keil JTAG loading issue - LPC2148

An Engineer's Guide to the LPC2100 Series

Sign in

You might also like...

Search forums

Free PDF Downloads

Blogs - Hall of Fame

Discussion Groups

Quick Links

About EmbeddedRelated.com

Social Networks

The Related Media Group