Is there a way to re-attach the debugger to the MSP430 without reset? My
device is running (JTAG not connected), I connect the JTAG adapter, start
crossowrks and connect the FET. I choose the option "Attach debugger".
Now
it seems connected and I have the options break or stop available, but 
break has no effect and stop does a reset. Any ideas?

        Matthias

Hi Ivan,

What do you mean with "Stop" ?
Disconnecting the Debugger will normally reset the Target, so it runs on its
own.
What are you doing code wise for the break not to work ?
have you ticked "Clear ALL breakpoints", somtimes it'll need
flushing out in the EEM.

I have NEVER had a problem with that, and I've used CW for years now.
There must be clock issue, ie. your setup is not right.
(PS : and that's on WIN98SE, works a dream, always)

B rgds
Kris



> Good Point Matthias,
> I am able to confirm your experiences.
> 
> Although the attach seems to work (ie does not complain) the break has no
> effect.
> 
> I am using CS 1.3 rel 1 on WinXP
> 
> Anyone else tried this?
> Regards
> Ivan
> 
> ----- Original Message ----- 
> From: "Matthias Weingart" <msp430@msp4...>
> To: <msp430@msp4...>
> Sent: Monday, May 16, 2005 7:53 PM
> Subject: [msp430] re-attach the debugger, crossworks
> 
> 
> > Is there a way to re-attach the debugger to the MSP430 without reset?
My
> > device is running (JTAG not connected), I connect the JTAG adapter,
start
> > crossowrks and connect the FET. I choose the option "Attach
debugger". Now
> > it seems connected and I have the options break or stop available, but
> > break has no effect and stop does a reset. Any ideas?
> >
> >         Matthias
> >
> >
> > .
> >
> >
> > . 
> 
> 

Good Point Matthias,
I am able to confirm your experiences.

Although the attach seems to work (ie does not complain) the break has no
effect.

I am using CS 1.3 rel 1 on WinXP

Anyone else tried this?
Regards
Ivan

----- Original Message ----- 
From: "Matthias Weingart" <msp430@msp4...>
To: <msp430@msp4...>
Sent: Monday, May 16, 2005 7:53 PM
Subject: [msp430] re-attach the debugger, crossworks


> Is there a way to re-attach the debugger to the
MSP430 without reset? My
> device is running (JTAG not connected), I connect the JTAG adapter, start
> crossowrks and connect the FET. I choose the option "Attach
debugger". Now
> it seems connected and I have the options break or stop available, but
> break has no effect and stop does a reset. Any ideas?
>
>         Matthias
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hi Chris,
Thanks for the reply - my clarification in-line below
----- Original Message ----- 
From: "microbit" <microbit@micr...>
To: <msp430@msp4...>
Sent: Tuesday, May 17, 2005 10:24 AM
Subject: Re: [msp430] re-attach the debugger, crossworks


> Hi Ivan,
>
> What do you mean with "Stop" ?
> Disconnecting the Debugger will normally reset the Target, so it runs on
its own.

I have the JTAG physically connected to the target but CS NOT in
'debug'
mode.
The target runs just fine.
Now I hit a bug and want to go into debug mode WHILE the condition still
exists. This does not seem to work properly.

Ok so this is a bit of a contrived example but  (I hope) illustrates the
point

> What are you doing code wise for the break not to
work ?
> have you ticked "Clear ALL breakpoints", sometimes it'll
need flushing out
in the EEM.
Sorry, what's the EEM? Where can I find more info on this?

It not so much that I am not hitting a (previously set) breakpoint it is
that I want to 'break' the CPU execution at whatever location it might
currently be at - to example registers, globals vars etc.
>
> I have NEVER had a problem with that, and I've used CW for years now.
Yes, I know ;-) - as you know I am new to the MSP430 and CS  first
assumed
its me ;-)
The reason I mentioned it is because some one lese did first ;-) (I am not
alone! ;-))

> There must be clock issue, ie. your setup is not
right.

Well if that is it I cannot think what to check - the target runs fine
normally, and I debug normally (except for the issue I mentions)

BTW: (since I have a friendly ear ;-))
What is supposed to happen (in CS) when one downloads  a new build to the
target (ie F7 then F5)?

I assume that after the code is d/l the micro will be automatically reset by
the debugger so that the new code runs 'from scratch'.
For me, this does not happen the majority of the time.
I must press 'Break (Ctrl+.) ' then 'restart Debugging'
(Ctrl_Shift+F5) for
the micro to reset.

Is this 'normal behaviour' or is it something at my end?
I seem to get this with either the CrossConnect or the TI FET adaptors.
Any ideas?

Thanks
Ivan

> (PS : and that's on WIN98SE, works a dream,
always)
>
> B rgds
> Kris
>
>
>
> > Good Point Matthias,
> > I am able to confirm your experiences.
> >
> > Although the attach seems to work (ie does not complain) the break has
no
> > effect.
> >
> > I am using CS 1.3 rel 1 on WinXP
> >
> > Anyone else tried this?
> > Regards
> > Ivan
> >
> > ----- Original Message ----- 
> > From: "Matthias Weingart" <msp430@msp4...>
> > To: <msp430@msp4...>
> > Sent: Monday, May 16, 2005 7:53 PM
> > Subject: [msp430] re-attach the debugger, crossworks
> >
> >
> > > Is there a way to re-attach the debugger to the MSP430 without
reset?
My
> > > device is running (JTAG not connected),
I connect the JTAG adapter,
start
> > > crossowrks and connect the FET. I choose
the option "Attach debugger".
Now
> > > it seems connected and I have the
options break or stop available, but
> > > break has no effect and stop does a reset. Any ideas?
> > >
> > >         Matthias
> > >
> > >
> > > .
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > 
> >
> >
> >
> > .
> >
> >
> >
> >
> >
>
> --
------
> > Yahoo! Groups Links
> >
> >   a.. To visit your group on the web, go to:
> >   http://groups.yahoo.com/group/msp430/
> >
> >   b.. .
> >
> >   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
> >
> >
>
> 
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

Hi Ivan et al,

> I have the JTAG physically connected to the target
but CS NOT in 'debug'
> mode.
> The target runs just fine.
> Now I hit a bug and want to go into debug mode WHILE the condition still
> exists. This does not seem to work properly.

But how can you hit a bug while the condition still exists and _then_ go into
debug mode ?
You must create the circumstances of the program or logical error while in debug
mode ??
No debugger AFAIK on MSP430 will let you connect while the target is running,
and then
auto sync/anchor to the C code.
You have to start with a Reset so it's sync'd.

> Ok so this is a bit of a contrived example but  (I
hope) illustrates the
> point

Not clear yet...

> > What are you doing code wise for the break
not to work ?
> > have you ticked "Clear ALL breakpoints", sometimes
it'll need flushing out
> in the EEM.

> Sorry, what's the EEM? Where can I find more
info on this?

Enhanced Emulation Module. Only some MSP430 have this. (eg. tracing etc)
 
> It not so much that I am not hitting a (previously
set) breakpoint it is
> that I want to 'break' the CPU execution at whatever location it
might
> currently be at - to example registers, globals vars etc.

If the target is connect - and in sync with debugger - CTRL "." will
break it.
Perhaps there's some unknown factor at work here, which I haven't come
across yet.

> Well if that is it I cannot think what to check -
the target runs fine
> normally, and I debug normally (except for the issue I mentions)

I'm stumped then.
 
> BTW: (since I have a friendly ear ;-))
> What is supposed to happen (in CS) when one downloads  a new build to the
> target (ie F7 then F5)?

By default (if ticked) the target should be flashed, then verified, and then the
debugger 
should stop at the first line of "Main". (default)

PS : Are you using header Files that result in object code, but where
you've changed 
something in such a matter that the linker cannot know about it ?
In that ase - if unsure - press ALT - F7, ie. rebuild ALL.
Perhaps there's bad sync between symbol table etc. and linked code.

> I assume that after the code is d/l the micro will
be automatically reset by
> the debugger so that the new code runs 'from scratch'.
> For me, this does not happen the majority of the time.
> I must press 'Break (Ctrl+.) ' then 'restart Debugging'
(Ctrl_Shift+F5) for
> the micro to reset.

Is "Break at main" enabled ? It should be the default.
Eklse, you might have an inconsistency between target and actual setting (what
processor).
Also, check your mem placement file.

> Is this 'normal behaviour' or is it
something at my end?

This is not normal IMO, see above

-- Kris

On Tue, May 17, 2005 at 03:20:59PM +1000, microbit wrote:

> > I have the JTAG physically connected to the
target but CS NOT in 'debug'
> > mode.
> > The target runs just fine.
> > Now I hit a bug and want to go into debug mode WHILE the condition
still
> > exists. This does not seem to work properly.
> 
> But how can you hit a bug while the condition still exists and _then_ go
into debug mode ?
> You must create the circumstances of the program or logical error while in
debug mode ??
> No debugger AFAIK on MSP430 will let you connect while the target is
running, and then
> auto sync/anchor to the C code.
> You have to start with a Reset so it's sync'd.

Well - what I really want: 
1) connect JTAG and press break to stop somewhere in my code (maybe especially
  in the deadlock that causes the bug)
If this is not possible I want at least 
2) to see the state of the registers (esp. SP).
Well this still not possible? I want 
3) to see the contents of my RAM.

I think 3) should at least be possible, because a Reset does not clear RAM.
(if the breakpoint after reset is before any startup code).
Maybe you can also see the state of the registers? (I assume only PC and the
CPU-flags and all SFR's are reset, SP still in old state?)
But it seems that I cannot connect to my target without downloading code 
and flashing? (I assume that this will destroy the register states and or 
RAM?) "Attach Debugger" is doing something, but I cannot see any
contents
of the RAM/registers - because the target is still running, break not 
possible, no chance to access it!

Fortunately the cases to connect JTAG afterwards were very seldom, so I
did not yet invest much time to see how I can do this and what is possible.

> > Sorry, what's the EEM? Where can I find
more info on this?
> 
> Enhanced Emulation Module. Only some MSP430 have this. (eg. tracing etc)

CW has some nice windows concerning the EEM; quite mystical - I would like
to know what I can do with it. Unfortunately the docs are VERY limited (I do 
not know any document, does somebody here know more and can publish it?

> > I assume that after the code is d/l the micro
will be automatically reset by
> > the debugger so that the new code runs 'from scratch'.
> > For me, this does not happen the majority of the time.
> > I must press 'Break (Ctrl+.) ' then 'restart
Debugging' (Ctrl_Shift+F5) for
> > the micro to reset.
> 
> Is "Break at main" enabled ? It should be the default. Eklse, you
might
> have an inconsistency between target and actual setting (what processor).
> Also, check your mem placement file.
> 
> > Is this 'normal behaviour' or is it something at my end?
> 
> This is not normal IMO, see above

It is normal in my case too (in app. 30% of all rebuilts/downloads).
It _seems_ to run - but no reaction, Break/Restart again and it works.
(I remember I had the same problem with the mspgcc JTAG tool, I added
a additional reset, and I had no problems anymore:
	msp430-jtag -r -m ${NAME}.elf 
	msp430-jtag -r 
 -r is doing a real reset (toggling resetpin), this is done by the tool
before any download. It than reflashs the target but does not toggling reset
again - this is done internally (over the EEM?), what sometimes is unreliable?).
Maybe Paul or Michael can add a option for a second reset at the end of all
downloads/verify etc? I guess this is a hardware issue (problem of the
LPT-FET tool?)

M.