Lpc2000

Hello again,
 I have built a board on which I intend to use the secondary JTAG
functionality to debug my application. However after adding the code
snippet to enable the alternate function for the JTAG pins,Programming
the part using the primary JTAG port, and then moving the connections
from the primary JTAG to the secondary JTAG ports, I encounter the
following problem:

 *** The JTAG will not connect - the following has been observed.

  - Durring reset (ARM LPC2104 reset pin held low) the JTAG signals are   
    seen on the proper lines (Pod tries to contact LPC2104).

  - After releasing the reset line, the processor applies a hard
    pulldown to the JTAG pins, and the POD isn't able to control the
    lines, it tries (evidenced by 300mv signals on proper pins) but
    is simply not able to overcome the pulldown effect.

  - Other code which is in control of other IO pins is running
    correctly so code execution is happening.

----------------------- assumption: ------------

I have made the assumption that since the code 0x554000 has bee placed
into the pinsel1 register, the port direction register has no effect
on the pins any longer.

()()()()() please help.

Check through the notes on Philips microcontroller discussion list.  I seem 
to remember a mention that the pin directions had to be set to match what 
the JTAG required.

Robert

At 09:53 PM 1/20/04 +0000, you wrote:
>----------------------- assumption: ------------
>
>I have made the assumption that since the code 0x554000 has bee placed
>into the pinsel1 register, the port direction register has no effect
>on the pins any longer.

" '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

After Much hair pulling, I discovered you are partially correct. The
IO pins must be set as "Input". port 0.27 - 0.31 all must be set as
inputs, after this the device will come up under the secondary JTAG
control.

HOWEVER - the connection can only be made marginally, sometimes it
will, sometimes it wont. Reason unknown. After finally succesfully
connecting using the Secondary JTAG, I tried to reprogram, and the
program cycle failed (Right after it managed to erase the part), DOPE,
now it's back to square 1.

My suggestion for would be users of this feature would be: Make sure
you make your board such that no modification is required to switch
between Primary, and Secondary JTAG. Use the Primary to program, and
secondary to debug.

QUESTION: why does the pinsel block not actually disconnect the IO
from the Direction register?

--- In lpc2100@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> Check through the notes on Philips microcontroller discussion list.
 I seem 
> to remember a mention that the pin directions had to be set to match
what 

> the JTAG required.
> 
> Robert
> 
> At 09:53 PM 1/20/04 +0000, you wrote:
> >----------------------- assumption: ------------
> >
> >I have made the assumption that since the code 0x554000 has bee placed
> >into the pinsel1 register, the port direction register has no effect
> >on the pins any longer.
> 
> " '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

Using the Primary for program, and then switching to secondary for
debug works fine. Attempting to program in Secondary mode fails at
every attempt, and only serves to corrupt the currently flashed
program, after which the primary port is required to aleviate the
problem. 

After programming with the primary port, I am able to switch my header
to Secondary, and debug from there.

Thank you for the help.

--- In lpc2100@yahoogroups.com, "Jim Beagley" <jim5272@h...> wrote:
> After Much hair pulling, I discovered you are partially correct. The
> IO pins must be set as "Input". port 0.27 - 0.31 all must be set as
> inputs, after this the device will come up under the secondary JTAG
> control.
> 
> HOWEVER - the connection can only be made marginally, sometimes it
> will, sometimes it wont. Reason unknown. After finally succesfully
> connecting using the Secondary JTAG, I tried to reprogram, and the
> program cycle failed (Right after it managed to erase the part), DOPE,
> now it's back to square 1.
> 
> My suggestion for would be users of this feature would be: Make sure
> you make your board such that no modification is required to switch
> between Primary, and Secondary JTAG. Use the Primary to program, and
> secondary to debug.
> 
> QUESTION: why does the pinsel block not actually disconnect the IO
> from the Direction register?
> 
> --- In lpc2100@yahoogroups.com, Robert Adsett <subscriptions@a...>
wrote:
> > Check through the notes on Philips microcontroller discussion list.
>  I seem 
> > to remember a mention that the pin directions had to be set to match
> what 
> > the JTAG required.
> > 
> > Robert
> > 
> > At 09:53 PM 1/20/04 +0000, you wrote:
> > >----------------------- assumption: ------------
> > >
> > >I have made the assumption that since the code 0x554000 has bee
placed

> > >into the pinsel1 register, the port direction register has no effect
> > >on the pins any longer.
> > 
> > " '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

Ashling have seen problems with the secondary debug port as well.
Sometimes it works, sometimes it doesn't. We have been able to
debug/flash via the secondary port, however, not consistently and
reliably. From a recent batch of twenty of our EVBA7 boards we had five
secondary debug failures. We are confident we are doing the right thing
and that it is not a tool issue (we have reproduced the problem with ARM
MultiICE as well).
 

Hugh @ http://www.ashling.com/support/lpc2100/  

 -----Original Message-----
From: Jim Beagley [mailto:jim5272@...] 
Sent: 21 January 2004 00:59
To: lpc2100@yahoogroups.com
Subject: [lpc2100] Re: Secondary JTAG problem. -> succesfull solution



Using the Primary for program, and then switching to secondary for
debug works fine. Attempting to program in Secondary mode fails at
every attempt, and only serves to corrupt the currently flashed
program, after which the primary port is required to aleviate the
problem. 

After programming with the primary port, I am able to switch my header
to Secondary, and debug from there.

Thank you for the help.

--- In lpc2100@yahoogroups.com, "Jim Beagley" <jim5272@h...> wrote:
> After Much hair pulling, I discovered you are partially correct. The
> IO pins must be set as "Input". port 0.27 - 0.31 all must be set as
> inputs, after this the device will come up under the secondary JTAG
> control.
> 
> HOWEVER - the connection can only be made marginally, sometimes it
> will, sometimes it wont. Reason unknown. After finally succesfully
> connecting using the Secondary JTAG, I tried to reprogram, and the
> program cycle failed (Right after it managed to erase the part), DOPE,
> now it's back to square 1.
> 
> My suggestion for would be users of this feature would be: Make sure
> you make your board such that no modification is required to switch
> between Primary, and Secondary JTAG. Use the Primary to program, and
> secondary to debug.
> 
> QUESTION: why does the pinsel block not actually disconnect the IO
> from the Direction register?
> 
> --- In lpc2100@yahoogroups.com, Robert Adsett <subscriptions@a...>
wrote:
> > Check through the notes on Philips microcontroller discussion list.
>  I seem 
> > to remember a mention that the pin directions had to be set to match
> what 
> > the JTAG required.
> > 
> > Robert
> > 
> > At 09:53 PM 1/20/04 +0000, you wrote:
> > >----------------------- assumption: ------------
> > >
> > >I have made the assumption that since the code 0x554000 has bee
placed
> > >into the pinsel1 register, the port direction register has no
effect
> > >on the pins any longer.
> > 
> > " '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



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/SIG=12cll0nd6/M=267637.4116732.5333197.1261774/D=eg
roupweb/S=1706554205:HM/EXP=1074733151/A=1945637/R=0/*http://www.netflix
.com/Default?mqso=60178397&partid=4116732> click here	
 
<http://us.adserver.yahoo.com/l?M=267637.4116732.5333197.1261774/D=egrou
pmail/S=:HM/A=1945637/rand=937791682> 	


  _____  

Yahoo! Groups Links


*	To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2100/
  

*	To unsubscribe from this group, send an email to:
lpc2100-unsubscribe@yahoogroups.com
<mailto:lpc2100-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
  

*	Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> .

--- In lpc2100@yahoogroups.com, "Hugh O'Keeffe" <hugh.okeeffe@a...> wrote:
> Ashling have seen problems with the secondary debug port as well.
> Sometimes it works, sometimes it doesn't. We have been able to
> debug/flash via the secondary port, however, not consistently and
> reliably. From a recent batch of twenty of our EVBA7 boards we had five
> secondary debug failures. We are confident we are doing the right thing
> and that it is not a tool issue (we have reproduced the problem with ARM
> MultiICE as well).
>  
> 
> Hugh @ http://www.ashling.com/support/lpc2100/  
>  
>  
>  -----Original Message-----
> From: Jim Beagley [mailto:jim5272@h...] 
> Sent: 21 January 2004 00:59
> To: lpc2100@yahoogroups.com
> Subject: [lpc2100] Re: Secondary JTAG problem. -> succesfull solution
> 
> 
> 
> Using the Primary for program, and then switching to secondary for
> debug works fine. Attempting to program in Secondary mode fails at
> every attempt, and only serves to corrupt the currently flashed
> program, after which the primary port is required to aleviate the
> problem. 

The following points out that that the secondary JTAG is *only*
intended for debugging:

http://www.semiconductors.philips.com/acrobat/applicationnotes/AN10255_1.pdf

Leon