Lpc2000

I'm not sure what's going on here, but I appear to be having a reset 
problem with the Keil development board.

I am using CrossWorks for the ARM and a Olimex Parallel JTAG adapter, or 
a USB CrossConnect (both exhibit the same problem).

On initial powerup, download of code and debug the code runs as expected 
(some interrupt code and a counter to indicate that the interrupt is 
being run).

If I recompile (with or without change, it doesn't matter) and reload it 
then sometimes the code won't work. Or will partially work (eg. running 
in the main loop flashing LEDS ok, but the irq isn't executed -- counter 
is at 0).

I've tried various combinations of stopping and reloading, software 
reset of jtag adapter, etc. Pushing the reset button on the board, etc. 
The only thing that consistently works is pulling power from the board 
before reloading. If I have to do that every time I change the code I'm 
going to go nuts.

Has anyone seen this before? Or has any ideas?

Thanks,

Brian

-- 
-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

> I'm not sure what's going on here, but I appear to be having a reset 
> problem with the Keil development board.
> 
> I am using CrossWorks for the ARM and a Olimex Parallel JTAG adapter, or 
> a USB CrossConnect (both exhibit the same problem).
> 
> On initial powerup, download of code and debug the code runs as expected 
> (some interrupt code and a counter to indicate that the interrupt is 
> being run).
> 
> If I recompile (with or without change, it doesn't matter) and reload it 
> then sometimes the code won't work. Or will partially work (eg. running 
> in the main loop flashing LEDS ok, but the irq isn't executed -- counter 
> is at 0).
> 
> I've tried various combinations of stopping and reloading, software 
> reset of jtag adapter, etc. Pushing the reset button on the board, etc. 
> The only thing that consistently works is pulling power from the board 
> before reloading. If I have to do that every time I change the code I'm 
> going to go nuts.
> 
> Has anyone seen this before? Or has any ideas?

An idea:

When debugging with JTAG, often the program runs out of SRAM. 
Unless the loader explicitly clears RAM (eg. the .bss area),
then there is a chance that you will see differences between
a cold start (pulling the plug) versus a warm start (any form
of reset). 

So, if you code looks at some variable that you assume to be
zero - change it to explicitly set that variable to zero
(making it part of the data section).

Dave

David Hawkins wrote:

> 
>  > I'm not sure what's going on here, but I appear to be having a reset
>  > problem with the Keil development board.
>  >
>  > I am using CrossWorks for the ARM and a Olimex Parallel JTAG adapter, or
>  > a USB CrossConnect (both exhibit the same problem).
>  >
>  > On initial powerup, download of code and debug the code runs as expected
>  > (some interrupt code and a counter to indicate that the interrupt is
>  > being run).
>  >
>  > If I recompile (with or without change, it doesn't matter) and reload it
>  > then sometimes the code won't work. Or will partially work (eg. running
>  > in the main loop flashing LEDS ok, but the irq isn't executed -- counter
>  > is at 0).
>  >
>  > I've tried various combinations of stopping and reloading, software
>  > reset of jtag adapter, etc. Pushing the reset button on the board, etc.
>  > The only thing that consistently works is pulling power from the board
>  > before reloading. If I have to do that every time I change the code I'm
>  > going to go nuts.
>  >
>  > Has anyone seen this before? Or has any ideas?
> 
> An idea:
> 
> When debugging with JTAG, often the program runs out of SRAM.
> Unless the loader explicitly clears RAM (eg. the .bss area),
> then there is a chance that you will see differences between
> a cold start (pulling the plug) versus a warm start (any form
> of reset).
> 
> So, if you code looks at some variable that you assume to be
> zero - change it to explicitly set that variable to zero
> (making it part of the data section).
> 

The startup code from Rowley clears ram first I think, and all my 
variables are initialized at powerup anyway. It seems to be related to 
the hardware registers, maybe the VIC setup, that are causing problems.

Brian


-- 
-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

> > An idea:
> > 
> > When debugging with JTAG, often the program runs out of SRAM.
> > Unless the loader explicitly clears RAM (eg. the .bss area),
> > then there is a chance that you will see differences between
> > a cold start (pulling the plug) versus a warm start (any form
> > of reset).
> > 
> > So, if you code looks at some variable that you assume to be
> > zero - change it to explicitly set that variable to zero
> > (making it part of the data section).
> > 
> 
> The startup code from Rowley clears ram first I think, and all my 
> variables are initialized at powerup anyway. It seems to be related to 
> the hardware registers, maybe the VIC setup, that are causing problems.
>

The data sheet usually specifies a 'reset value' for registers,
so normally those registers will be cleared. 

Try a flash RAM version of the program. Hit reset with that
loaded. At least that will convince you that the problem is RAM 
program related. Since in that case the VIC will be reset the same 
as in the RAM test case.

Good luck with the debugging.

Dave

David Hawkins wrote:

>  > > An idea:
>  > >
>  > > When debugging with JTAG, often the program runs out of SRAM.
>  > > Unless the loader explicitly clears RAM (eg. the .bss area),
>  > > then there is a chance that you will see differences between
>  > > a cold start (pulling the plug) versus a warm start (any form
>  > > of reset).
>  > >
>  > > So, if you code looks at some variable that you assume to be
>  > > zero - change it to explicitly set that variable to zero
>  > > (making it part of the data section).
>  > >
>  >
>  > The startup code from Rowley clears ram first I think, and all my
>  > variables are initialized at powerup anyway. It seems to be related to
>  > the hardware registers, maybe the VIC setup, that are causing problems.
>  >
> 
> The data sheet usually specifies a 'reset value' for registers,
> so normally those registers will be cleared.
> 
> Try a flash RAM version of the program. Hit reset with that
> loaded. At least that will convince you that the problem is RAM
> program related. Since in that case the VIC will be reset the same
> as in the RAM test case.
> 

Actually it is running from flash. It looks like it gets reflashed each 
time it reloads. I'm wondering if there is a difference between a soft 
reset and a powerup reset? Time to dig through the PDF's again (this is 
on a LPC2138).

Thanks,

Brian

-- 
-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

Hi Brian,

The LPC2xxx series can't be brought out of reset under JTAG debug 
control. So you are not getting a hardware reset on each debug run. The 
worse case is a flash resident program that disables JTAG (explicitly or 
going into low power mode). Someone sent one of these to us asking why 
the debugger didn't work - we had to use the serial boot loader to make 
the board JTAG debuggable. The LPC2xxx isn't unique in this respect - 
the same problem affects most ARM chips with on-board flash. It came as 
a pleasent surprise when we discovered that the STR730 can be brought 
out of reset under debug control - a better debug selling point than the 
ETM in my opinion.

Regards
Michael

>I'm not sure what's going on here, but I appear to be having a reset 
>problem with the Keil development board.
>
>I am using CrossWorks for the ARM and a Olimex Parallel JTAG adapter, or 
>a USB CrossConnect (both exhibit the same problem).
>
>On initial powerup, download of code and debug the code runs as expected 
>(some interrupt code and a counter to indicate that the interrupt is 
>being run).
>
>If I recompile (with or without change, it doesn't matter) and reload it 
>then sometimes the code won't work. Or will partially work (eg. running 
>in the main loop flashing LEDS ok, but the irq isn't executed -- counter 
>is at 0).
>
>I've tried various combinations of stopping and reloading, software 
>reset of jtag adapter, etc. Pushing the reset button on the board, etc. 
>The only thing that consistently works is pulling power from the board 
>before reloading. If I have to do that every time I change the code I'm 
>going to go nuts.
>
>Has anyone seen this before? Or has any ideas?
>
>Thanks,
>
>Brian
>
>  
>